Here is a story from a year ago, much before I became the Product Manager of XRebel, even before I knew of ZeroTurnaround. This incident just might have influenced me into taking the job as well.. :) It was Memorial Day weekend and we had friends from New Jersey visiting us. We had fun on Friday and Saturday and then came a series of beeps on my husband’s phone – his pager duty alerts – Yes production issues and several of them. Did I mention he’s a Java developer? He had to abandon our Sunday plans and get to work. :(
Summer is coming. You know what that means for you, dear RebelLabs reader. We’re about to publish the results of our annual survey. It’s the one where we ask Java developers to tell us which technologies are they using, what tools they spend most of their time tinkering with, and which frameworks make their lives easier. This information gives us incredible insight into the community and allows us to pick more relevant topics for upcoming blog posts.
Back in February this year, we launched the survey and asked everyone we knew of in the Java community to contribute to the data by answering the questions. We also asked them to share it with their colleagues, peers, friends and anyone else in the community. We also promised to support Devoxx for Kids with a $1000 contribution if we received 2000 responses.
Hi, Sten the Product Manager from JRebel for Android here. People keep asking me about the differences between JRebel for Android and Google’s own Instant Run. Since Android Studio 2.0 has finally been released, this is a good time to compare the two.
Back in November of 2015, Google announced Android Studio 2.0. Complete with a totally new feature titled “Instant Run”. Delivering faster build times to Android developers by supporting hot swapping code and resources in an already running application. The idea itself is nothing that new — it has been present in Java for over a decade. JRebel, the Java code reloading tool for Java SE/EE, has been enhancing developers’ lives for the past 8 years. This leads us to JRebel for Android. A tool that is approximately 1.5 years old, bringing the same technology to Android developers.
Today, I will provide an overview of how Google’s Instant Run and JRebel for Android handle code and resource changes. Side by side.
Android & Java both have quite similar APIs. Naturally, the benefit of Android & Java’s APIs being similar is that it makes it possible to develop frameworks and libraries that work on both platforms. This blogpost takes a look at seven Android libraries which Java developers should at least know about. Also, it’s a good post for Android developers to be aware of too, just in case there are some libraries you may not be aware of.
Have you ever argued about the efficiency of test-driven development in your day job? I certainly have, and on both sides of the argument. I have worked in the software development sector for 9 years as a developer and an architect on seven different projects ranging from mobile apps to a custom made telecom self services. I’m fed up of the pointless arguments – the ones based on solo experiences and anecdotal evidence. In this article I try to remedy this situation and clarify TDD in an objective way. Arguments should be based on a common understanding of what TDD is and your current project situation at hand: people involved, technology, goal, deadline, etc.
Every Java program tends to have one thing in common. They’ll all use Java collections! They’re so fundamental, we could not even avoid thinking to omit them from out RebelLabs cheat sheet collection. This is a tough challenge, since there’s so much you need to know about the collections framework, the implementation details, correct use cases, how to choose the right collection type, what can they do and when to turn to the third party libraries as opposed to using the built in collections in the JDK.
Anyway, no topic as broad as Java collections framework can be fully explained in a single A4 page, but we’ve tried to incorporate the most essential information you will need to reference again and again. The corresponding explanations and details behind the decisions are right here, in this blogpost.
NB! Our ZTLive webinar Microservices For The Enterprise was completed on April 19th. Read on for the topics covered in the webinar, and some background on our speakers. To watch the online recording of the webinar, just click on the REGISTER button below.
I’m the product owner of XRebel — the profiler for Java web applications that developers can use while they’re actually developing their applications. Recently I had to prepare a demo environment that I could easily share with my team mates. If the demo would have consisted of just a web app, without external dependencies, it would have been easy to share with the team: I’d just throw a WAR up on Dropbox and everybody would be free to do whatever they wanted to do with it. However in my scenario, I had an external dependency on MongoDB which made my demo a little less portable.
Naturally, I thought that Docker might be a good solution for this. The prerequisite though, is that my team members would have to install the Docker Toolbox in order to use the environment. But this is a wise thing to do anyway, isn’t it? Docker is an established container management system, with tons of resources available to learn the basics. We even recently published a Docker commands and best practices cheat sheet from which you can learn everything you need to navigate your way around Docker containers.
Let me sketch this out for you. The application is Petclinic – a web application, with a UI, that uses an embedded H2 database. In some scenarios, Petclinic talks to the Supplements application over HTTP. Supplements uses MongoDB to fetch data as JSON back to the Petclinic app, if requested.
Android development is great so long as your project stays relatively small. As the functionality of your project grows you’ll find that your build times follow suit. This puts you in the position where you spend most of your time figuring how to make your build run faster rather than adding more value to your actual app.
The interwebs are packed full with suggestions of how to squeeze the most out of your Gradle builds. There are some great posts on this, including ours “Making Gradle builds faster”. Although you can win back seconds and maybe even minutes, yet some bottlenecks will still remain in your build.
One thing you can try is JRebel for Android. It takes a different approach by not introducing a new apk after each change. Instead apk gets installed once and delta packages are shipped over to the device or emulator and are applied during runtime. This logic is nothing new and has been present in the Java EE/SE with JRebel for more than 8 years.