Blog

Remember those “Down for Maintenance” signs? Seeing that on any site means something’s not going right. Behind every ‘Down for Maintenance’ sign is frustrated operations staff, sleep-deprived developers, and angry managers letting everyone know how much money the company is losing with every minute of downtime. It is an awful experience for everyone involved.

In May of 2011, we released LiveRebel 1.0 – a tool that brought the hotpatching technology that powers JRebel to production environments with safeguards like compatibility checks and stop-the-world updates. As more and more users deployed in production, we realized that hotpatching was just the beginning. Wouldn’t it be great if there were a tool that could be dropped into an existing infrastructure, easily start managing the production servers, and would allow any and all updates to be applied with no downtime?

LiveRebel 2.0 is that product.

The most common way of updating an application online is often to take one server at a time from a cluster, stop it, update the application and restart it. Immediately after LiveRebel is installed, it adds the ability to do rolling restarts completely automatically.

Of course, we make this all possible without any changes to the existing infrastructure, due to the fact that with LiveRebel, which is all Java-based, every server can act as a load balancer, redirecting the new sessions to other servers while keeping the existing ones where they should be. So from both a user perspective and the administrator perspective, all servers are alive and functioning at all times, with all the redirection happening as if by magic.

So what does this mean?

• Every single update is an online, transactional, reversible operation that is completely automated and, in case of minor updates, instantaneous.
• When something goes wrong, as it inevitably does, there is a panic button to press that will make it all better.
• The application stays online, the updates can be done during the day and the business doesn’t lose a cent of revenue.
• Developers can see their code in production faster. At an extreme, the code can even be deployed continuously, since fixing or reverting things is so darn easy.

It means that you are happier, and that makes our day.

It is our pride and pleasure to present LiveRebel 2.0.

Don’t let me keep you from your work….

Our ongoing *cough* Developer Productivity Report has given us some valuable insight into what makes developers tick. In Part 1: Developer Timesheet, with commentary provided by Guest Geek Lincoln Baxter III, we took a deep look into how developers spend their days (SPOILER ALERT: only 3 hours each day is spent “writing code”).

In Part 2: Developer Stress, featuring Guest Geek Martijn “The Diabolical Developer” Verburg, we saw that developers are concerned about making deadlines, and their own code quality, continuing education and adherence to “best practices”.

In Part 3: Developer Efficiency, we look at what elements of the job contribute to or decrease efficiency at work. We asked over 1000 developers “What keeps you from doing your work?”, and the following are the Top 5 Show Stoppers at Work:

The majority of respondents felt that Too Much Multitasking was the primary reason for not getting work done. Over 1/3 of devs also mentioned that Boring Tasks where responsible for under-efficiency in the cubicle. This begs the question whether or not it is better to get “boring” tasks over and finished as quickly as possible, but this marketing droid understands how feeling uninspired to attack your work will lead to procrastination.

It is fair to conclude that Boring tasks, Bad management and Lack of motivation are indicative of a sizable gap in communication between management and development teams, or, more interestingly, a lack of self-management for organizing one’s time, one’s mind and one’s life.

Extended Interview with Guest Geek Matt Raible

We asked Matt Raible, Web architecture consultant, frequent speaker and father with a passion for skiing, mountain biking and good beer, to give us some of his insight on the factors that keep developers from finishing their work, so here we go!

ZT: Hey Matt, thanks for joining us. Hey, I heard this rumor that you are mostly Irish-Montanan?

MR: Yep, I grew up in the back woods of Montana with no electricity and I’m mostly Irish. So keep that in mind when asking me how I get things done at work.

ZT: Understood. So what do you think about issues regarding “Too much multitasking”?

MR: I’ve got a couple of suggestions that work for me:

• Work disconnected. To further facilitate not checking e-mail or reading blogs, I’ve found that going to a coffee shop w/o connectivity is my most productive environment. They have liquid motivation in the form of coffee, and you can feed your brain with breakfast/lunch or some kind of snack. My most productive days are the ones where I show up at my local Einstein’s (bagel shop) at 6 a.m., have two cups of coffee, and work with my headphones on. After the coffee and uber-productivity, I often have an awesome ride to work and barely notice the miles. NOTE: I’ve found that I’m more productive writing code late at night and authoring articles/books in the early morning.
• Stop reading e-mail, Twitter and Facebook. One of the ways I can tell I’m in uber-productive mode is my unread (or starred) mail piles up and I haven’t read any blog posts (or blogged myself) in a couple days.
• Sleep. While working late nights can be productive in the short term, doing it consecutively will burn you out quickly. Getting a good night’s sleep can often lead to greater productivity because you’re refreshed and ready to go.

ZT: Yeah, sleep is nice. *yawn* …. Sorry, where were we? Ah, “Boring Tasks”. 

MR: Some tasks are boring and there is nothing really to do about it. I find that music can make a big difference and potentially grow some inspiration where it didn’t exist before. If you’ve got outside projects that you find more interesting, position them at the right time of day.

• Listen to music while you work. Some noise-cancelling headphones and your favorite music can do wonders for your productivity. Of course, earbuds work just as well – whatever makes the music sound good. Good music can really help you “get into the groove” of what you’re working on, regardless of whether it’s writing or coding.
• Work on open source late at night, with a beer on your desk. While I sometimes get the opportunity to work on open source at my day job, I still find that I’m most productive at night. Maybe this is because no one bugs me via e-mail or IM, or maybe it’s just because the world is asleep. The strange thing is I often find myself motivated at 3 p.m. for my 11 p.m. workload. However, when I get to 11 p.m., I’m not motivated to work on anything. I’ve found that cracking open a beer at 11 when I start helps me focus and quit worrying about all the other computer-related tasks I need to do.

ZT: What can you say about “Bad Management”? In your case, you deal with a lot of self-management for your time and resources…what can you tell us that would apply to both contractors and those of us working in teams?

MR: Yeah, what works great for me is to get used to non-standard work hours, and avoiding inefficient wastes of time.

• Work long hours on Monday and Tuesday. This especially applies if you’re a contractor. If you can only bill 40 hours per week, working 12-14 hours on Monday can get you an early-departure on Friday. Furthermore, by staying late early in the week, you’ll get your productivity ball-rolling early. I’ve often heard the most productive work-day in a week is Wednesday.
• Avoid meetings at all costs. Find a way to walk out of meetings that are unproductive, don’t concern you, or spiral into two co-workers bitching at each other. While meetings in general are a waste of time, some are worse than others. Establish your policy of walking out early on and folks will respect you have stuff to do. Of course, if you aren’t a noticeably productive individual, walking out of a meeting can be perceived as simply “not a team player”, which isn’t a good idea.

ZT: One of the responses was about “Buggy software”. Now, this could refer to buggy software that is being used or developed, but I rather think the latter.

MR: Yeah, I would assume they are talking about productivity inhibitors they use professionally. Well, I could make a suggestion that Java developers might enjoy – start using IntelliJ IDEA instead of other IDEs :-)

ZT: We’ll actually get to see how popular IntelliJ IDEA is compared to other IDEs in the final Developer Productivity Report 2012 … finally, Lack of motivation was cited as another factor preventing developers from being more efficient. Any final thoughts on that?

MR: Look, you have to work on something you’re passionate about. If you don’t like what you’re doing for a living, quit. Find a new job as soon as possible. It’s not about the money, it’s all about happiness. Of course, the best balance is both. It’s unlikely you’ll ever realize this until you have a job that sucks, but pays well. I think one of the most important catalysts for productivity is to be happy at your job. If you’re not happy at work, it’s unlikely you’re going to be inspired to be a more efficient person. Furthermore, if you like what you do, it’s not really “work” is it?

ZT: Our team definitely agrees with you here, Matt. Hey, thanks a lot for your time and contribution. We’ll see you in Madrid at Spring I/O in a couple days!

Final Notes

The findings from Part 1: Developer Timesheet showed us that devs spend less time than we might think actually “writing code”, and more time in meetings and filling out reports. Part 2: Developer Stress showed us that developers are acutely aware of their personal abilities and concerned with learning more in order to do their job better. Now we can see that the work environment, management style, self-discipline and finding ways to stay motivated are major factors in determining developer efficiency.

Stay tuned for the next part, where we shift focus from the Development side of things and check in on our friends in the Operations space – Part 4: Delivery Pipeline (or from code to app and back again).

The last year has been great for ZeroTurnaround. We released JRebel 4.0 and LiveRebel 1.0 to universal acclaim. We grew to a company of 40 people dedicated to building amazing products and keep bringing more value to our users. We won 3 awards in a single year, and hosted GeekOut, the first-ever Java conference in Estonia. We worked hard, we had tons of fun and we stayed very, very geeky.

What’s next? Every year a new set of buzzwords seems to promise salvation for those who embrace them. SOA, OSGi, Cloud, etc. But for most folks they are meaningless, as the architecture and environment have been created ages ago, and now porting apps to a new infrastructure is almost as hard as rewriting them from scratch. We believe that we can offer you an alternative, where tools can be plugged right into your existing infrastructure and eliminate inefficiencies & other problems without creating any new ones. LiveRebel is our first foray in that direction, with others to come down the line.

With all that hard work ahead of us, I’d like to put a piece of news on the table. From the February 9th, 2012, David Booth has left his role as ZeroTurnaround CEO and I have taken over the helm in order to make our vision a reality. I’d like to thank David for his time and hard work. He joined ZeroTurnaround even before we were large enough to be an entity of our own in Estonia. He brought JRebel into the hearts and workplaces of tens of thousands of Java developers, fueled our rapid growth with his passion and worked hard to make our success a reality.

Though David decided to step aside from the leadership role, he will continue assist us in the growth of the company from his position on the Advisory Board. We are grateful for his huge additions to the company, and wish him yet new challenges, and we will look forward to working with him in the future, talking about the good ol’ startup days and having another beer.

Captains come and captains go, but the mission continues.

Best Regards,

Jevgeni Kabanov
Founder & CEO of ZeroTurnaround

Is your inner geek feeling a bit stressed out?

In our preliminary release of Developer Productivity Report – Part 1: Developer Timesheet, we asked 1000+ developers how they spend their work week, and got some pretty clear estimates… (SPOILER ALERT: Did you know that the average developers spends only 3 hours per day writing code?)

In Part 2 of our ongoing survey on what makes developers tick (hint: it would rock more if you added your experiences too!), we take a peak into the things that stress out devs, and keep them up at night.To get some valuable perspective on the matter, we’ve invited Martijn “The Diabolical Developer” Verburg, Java community leader, speaker and CTO at TeamSparq, to share his thoughts on Developer Stress. So, let’s get started.

“Usually I sleep like a baby”

The good news is that the most common response to What keeps you up at night? was “Nothing. I sleep like a baby”. But it was followed very closely by some aspects of development that warrant a deeper look.

The following 5 stressors were listed as the top things keeping developers up at night.

1. Making deadlines – 25.00%

2. Application performance issues – 24.10%

3. Is my code good enough? – 23.70%

4. What new stuff do I need to learn? – 23.50%

5. Did I do X in the best way – 22.50%

Developers are quite concerned that their code is correct, innovative and following best practices. It would seem that training and continuing education is also an important factor that gets a lot of thought. What can companies and teams do to make sure devs are able to feel confident about their code, level of expertise and understanding of best practices?

We asked Martijn Verburg to comment on each of these five stressors, as only a “Diabolical Developer” could ;-)

Extended Interview with Guest Geek Martijn Verburg

ZT: Hey Martijn, thanks for being here with us.

MV: It’s a pleasure. I was just thinking to myself, “Hmm, I’ve got sooo much extra time these days, I wonder if anyone wants to interview me!”

ZT: Wow, really?

MV: Nah, I’m totally slammed actually.

ZT: Nice one. So Martijn, as a simple marketing droid I was surprised to see that developers are primarily concerned about Making Deadlines. Isn’t that something The Suits should be worrying about more?

MV: Managing deadlines is something that a lot of developers feel that they cannot learn or is out of their control (e.g. Their manager tells them what the deadline is).  However, managing deadlines is a skill that can definitely be learned! For example, developers can learn to:

• Scope work into manageable (e.g. 1 day) chunks
• Define what _done_ means (95% is not _done_)
• Factor in contingencies
• Communicate risks and issues to stakeholders
• Learn to prototype ideas to keep the overall project flowing

There are a number of tools to assist you in managing the scope and communication around deadlines, but always remember, “Whatever they tell you, it’s a people problem”, so developers should look at their communication and expectation setting first.

ZT: I think that developers can definitely take steps to empower themselves a bit more in this process. Can you recommend any specific tools tools or techniques for managing deadlines better?

MV: Absolutely. For example:

• Simple Lean/Kanban style planning with sticky notes and a whiteboard
• Electronic versions of the above (e.g.  Atlassian’s Greenhopper)
• BDD style tests with an electronic wallboard (therefore the whole business can see exactly where progress is at)
• A publicly shareable issue tracker that tracks timings (e.g. Atlassian’s JIRA)

ZT: I’m sure devs will find that helpful. Next, why do you think Performance Issues would rank so highly on the list of developer stress?

MV: Performance and performance tuning is terrifying for most developers because they have no idea where to start.  Modern software applications are so complex that it can feel like finding a needle in a haystack.  However, performance and performance tuning is actually a _science_, not an art and definitely not guesswork. Kirk Pepperdine (one of Java’s foremost expert in this field) always hammers home the point “Measure, don’t guess”.

By following the sort of scientific methodology that Kirk and others like him teach, you can systematically track down and fix performance issues as well as learning to bake performance in right from the beginning. There is a host of tooling that can assist in this area as well, but it’s the methodology that’s truly important.  I can highly recommend Kirk’s course (www.kodewerk.com – he runs courses worldwide, not just in Crete, so drop him a line).

ZT: Have you ever been asked if you think your Code is Beautiful (or simply “good enough”)?

MV: This is a question that all developers secretly fear. The fact is you can’t definitively state what good code is! The Softwarecraftsmanship folks will beg to differ here ;-). Define what Clean Code is! At the end of the day there are many differing opinions on what defines ‘good code’. However, I’d suggest that there are some clear traits of what is commonly perceived as good code:

• It’s broken up into small classes/methods/blocks each that perform one thing and one thing well
• Some level of interface is used so alternative implementations can be used
• The code is easy to test against
• You can ascertain by the naming used in the code, what the code is used for, e.g. it’s problem domain
• Common language pitfalls are avoided – type1, the sorts of things that static code analysers warn you against
• Common language pitfalls are avoided – type2, the sorts of things you pick up in Josh Bloch’s “Effective Java” title.
• There’s more, the list is fairly long.

So my advice is to try to follow the better practices out there (note I avoid using ‘best practices’, horribly overloaded term), make sure that you’re using the static code analysis tools, try to practice TDD and above all else get a 2nd pair of eyes on the code, preferably via Pair programming to begin with.

ZT: Is it fair to suggest that when devs worry about their code being good enough, it might speak to their next concern about Learning New Stuff?

MV: There’s always the fear of being left behind, can you as a developer guess what’s going to be big next?  If your technology CV is out of date you might struggle to find that next job!

Take a deep breathe and relax.  Most new technologies are simply short lived fads and it’s impossible to keep up with everything!

There’s no way a developer can stay up to date with the latest Java libraries, learn Scala, pick up Clojure, hack some iOS, and then deploy all that to the cloud on a NoSQL distributed grid environment.  See what I mean?

The trick is to identify trends.  Cloud is a trend, so you should learn about the principles behind it, but don’t sweat if you haven’t learned to deploy to the 5+ different Java cloud providers out there today.  Functional programming is a trend, so learn _why_ (hint – Multi-core processors and concurrency) it is and see if it’s something that you need to learn about now or whether you can wait a few years. The same goes for any new craze you read about or hear at a conference.

At the end of the day, our industry spends a lot of time re-inventing the wheel, and we have memories like goldfish :-). For example, some of the older hands are certainly chuckling away at this new functional fad, they were doing it over 20 years ago…

ZT: I think it’s fair to say that any professional will be concerned about doing X in the “Best Practices” way. You mentioned above that you dislike how “best practices” is poorly used. As a long-time coder yourself, how do developers feel about this?

MV: This is definitely related to developer concerns over “beautiful code”, but I’m going to assume this is more of a fear at the macro design level. Developers can fear that if they chose the wrong web framework or picked the wrong app server or designed the n-tier architecture wrong that they’re doomed.

A common problem here is that developers aren’t standing on the shoulders of Giants, most problems are not actually that unique and there is a wealth of free advice on sites like programmers.stackexchange.com, on mailing lists, in books, at conferences and of course at your local user groups.

Another common problem is in the prototyping space, not enough developers prototype the risky parts of their projects soon enough. Are you worried for example that JBoss might not support AMQP?  Well, spend a day upfront proving that it does or doesn’t!

ZT: Dude/Sir, thanks a lot. It’s always a pleasure to chat with you Martijn. I know we’ll see you speak (along with Kirk Pepperdine and others) at Geekout 2012 in Tallinn June 14-15, but before then the ZeroTurnaround team will be speaking and exhibiting (and drinking beer) in Madrid for Spring I/O Feb 16-17, London for QCon London March 7-9, and Krakow, Poland March 19-21 at 33rd Degree. Hope to catch up with you, and our dear readers there!

It’s 3pm. Do you know where you dev team is?

Using data from over 1000 respondents in a still-in-progess (cough, cough) survey about what makes developers tick, we are trying to hack into the core of the developer work week.

(FYI - Part 2 – Developer Stress, was released February 7th and features commentary from Diabolical Developer Martijn Verburg, so check that one out too!)

Among lots of other information that we unearthed from the depths of the coding den, we wanted to introduce these 3 interesting findings, and get some running commentary from Lincoln Baxter III, Senior Software Engineer at Red Hat (JBoss Forge), founder of OCPsoft, and opensource author / advocate / speaker:

• Finding #1: Devs spend less time writing code than you might think. The median is 15 hours, programmers spend about 3 hours each work day writing code.
• Finding #2: Devs spend more time on non-development activities than you might think. For each coding hour, devs spend nearly 30min in meetings, reporting, writing emails and dealing with timesheets (7 hours to 15 hours)
• Finding #3:  Devs spend more time fighting fires than building solutions

Disclaimer: As with any type of research undertaking, here are a couple of disclaimers: a) This survey is still in progress, and these findings are only preliminary at this point. b) We asked respondents to estimate the time they spend doing activities, so 100% accuracy is not guaranteed. c) Not only developers responded, but also architects, QA folks and system admins, so averages may reflect this too. 

How do Developers spend their work week?

Check out this breakdown of what devs spend their time doing (the top 3 time-consuming activities are marked):

Here are a breakdown of the categories a bit more. We tried to get everything a dev might do during the week, so if you can think of anything we missed, it would be cool to hear about that.

• Writing Code (programming, coding, hacking away)
• Overhead (Building, Deploying, Hardware, Software)
• Communication (Meetings, Chats, Teleconferences, etc)
• Problem-Solving (Debugging, Profiling, Performance Tuning)
• Firefighting (Crashes, Slowdowns, Security, etc)
• QA (Manual & Automatic Testing, Code Reviews)
• Strategy (Architecture, Refactoring, Thinking)
• Process (Bureaucracy, Reporting, Time-keeping, etc)
• Procrastination (slashdot.org, reddit.com,. Twitter, Facebook)

We can see that actually writing code is still the dominant activity of the day, but by no means a majority by itself. There is a distinction between “writing code” and “coding”; “Coding” includes writing code + problem solving, QA, strategy etc.

If we assume a 45-hour work week (9 hours per day, incl. lunch and breaks), developers spend 1/3 of their entire work week producing code.

Is this considered too little, just right or even too much? Let us know what you think in the survey, give your comments below and check out our Extended Interview with Lincoln Baxter III below.

**Next up :: Developer Productivity Report – Part 2: Developer Stress**

Extended Interview with Guest Geek Lincoln Baxter III

ZT: Hey Lincoln, thanks for joining us.

LB3: Glad to be here.

ZT: Can I ask….does it say “The Third” on your passport?

LB3: No, just the Roman Numerals.

ZT: Darn. Anyway, what do you think about Finding #1: Devs spend less time writing code than you think? I mean, according to this, devs spend less than 3 hours each work day writing code?

LB3: To be perfectly honest – and I’m always perfectly honest – I’m not surprised one bit. The biggest drain on productivity is the constant interruptions to our concentration; that can be co-workers, running a build, running tests to check your work, meetings.

It can take up to 25 minutes to regain your focus once you’ve been distracted from your original task#, and if like me, you consider “writing code” to be the task that developers should be focus on, then the size of other pieces in your pie chart begin to make a lot of sense.

Think of a brain as if it were a computer. There is waste every time a computer shifts from one activity to another (called a context switch,) a very expensive operation. But computers are better at this than we are because once the switch is complete they can immediately resume where they left off; we are not so efficient.

When considering context switching, builds and everything else considered “Overhead” are the biggest distractions from writing code. Even though this piece of the pie is only responsible for 4.63 hours of a developer’s week, in reality, the true impact of this problem is much greater.

Once you add in all of the other distractions of the workplace, I’m impressed anyone gets work done at all. Every re-deployment is going to cost you an extra 25 minutes of wasted focus, in addition to the deployment cost itself.

ZT: Alright, on to Finding #2: Devs spend more time on non-development activities than you might think. Based on these numbers, for every 1 hour devs spend writing code, they spend over 30 minutes in meetings, reporting, writing emails and dealing with timesheets (8.25 hours to 14.75 hours). Has it always been like this, or is this something new coming as more IT shops join forces with large enterprise and corporate parents?

LB3: In a desperate attempt to measure and estimate the work that programmers do, we try more and stranger ways to try to gain some kind of understanding. Think about it – in every other type of engineering field, we perform estimates up front, send out quotes, sign a contract, and work follows.

When writing software, however, try as we might, we still have difficulty with this process. Why? Because writing software today has very little to do with engineering.

The cognitive requirements for programming (software engineering) are much more akin to those of composing music, or painting a picture than they are to building a bridge or installing a drainage culvert. The common misconception about us “geeks” is that we are boring, uncreative and dull, but if that’s true then Mozart, Beethoven, and Daft Punk are just as dull.

So why do we insist on measuring software development as if it were an engineering science? We can apply these statistics to bridge building because we have built bridges for thousands of years, and the laws of physics have not changed since then. The laws of computing, however, change daily, and we cannot possibly hope to measure the same way.

This is why the Agile software methodology has had so much success, because unlike when building a bridge, the type and amount of work changes frequently in software development. Agile focuses less on measuring how much work on a task has been completed, but instead how much work remains, and how that relates to how much work can be done during the project timeline.

In fact, at OCPsoft we’re working on a new open-source agile project management called SocialPM, which is being designed specifically for the purpose of creating as few distractions as are necessary, while helping teams stay organized and keep more accurate schedules in an environment prone to change. (You know, to keep managers happy.)

Traditional estimation techniques, they’ve got no hope until we have more standard practices for software development. Let’s give our guys a break eh? Stop with the time-sheets.

ZT: Cool. Ok, so now to our last finding. Finding #3:  Devs spend more time fixing problems than creating solutions. Let’s pretend the non-coding, non-communicating part of the dev day could be split into two parts–Firefighting and Building. Firefighting includes emergencies plus problem solving like debugging and performance tuning. Building includes code reviews and tests, plus strategic planning, daydreaming, refactoring and thinking over architecture.If we break down the work day into parts where devs are spending time actively solving problems or working towards creating solutions, devs spend more time putting out fires.

• Firefighting – Median 7 hours per week
• Building –  Median 6 hours per week

• #1 – Writing a test.
• #2 – Running that test.

We have hugely complex builds that are not properly modularized, and certainly not very testable because how can you test without a database? How can you test without real business logic?If you don’t have automated builds and automated test suites that run in a reasonable amount of time (a few seconds or minutes,) then you are going to spend a good amount of your time running builds and trying to write and run tests; not to mention, you may not see the real issue until you deploy the software to a production environment, because mocks can never hope to replicate a real system.

In terms of Java, we’re seeing new advances in the field of testing – namely a project from JBoss called Arquillian, which allows us to automate the deployment of real tests to a real environment in which all services are available. The fact that you have access to your database, business services, and more is why “Don’t mock me,” is the Arquillian slogan.

If there’s one thing that surprises me about this statistic, it’s that we don’t spend more time fighting fires, because without a good automated build and a solid suite of real tests, we’re going to have problems.

For our readers, customers and fans that didn’t receive this information via email, here is ZeroTurnaround GeekNews for Q4 2011. Feel free to Join the Rebellion.

Quick note: Estonia’s biggest Java conference, GeekOut 2012, has been planned for June 14-15th, and the first speakers to give talked there have been announced. If you have never been to Tallinn and want to see why it’s one of the best cities in Europe, come for a visit!

JRebel News

Over 50 million redeploys prevented…and counting

• JRebel Social 2.0 was released, featuring a new dashboard, social points and more!
• JRebel 4.5.3 was launched, improving JRebel with JBoss 7 and Weld/CDI, plus Hibernate 4
• A JRebel/Liferay Integration project has been activated, and there is even an update since then: You can now reload Liferay JSP Hooks without redeploying!
• JRebel-Gradle beta plugin was released, so now Gradle fans can generate the rebel.xml file needed to enable instant builds 
• Learn how to make instantly visible change with JRebel to multi-module projects in IntelliJ

LiveRebel News

Let Continuous Delivery become your reality

• LiveRebel 1.2 is scheduled for a late-January release, so keep your eyes peeled…
• New features planned for LiveRebel 1.2 will include support for multiple upgrade strategies, including out-of-the-box rolling restarts
• Released a new milestone for the LiveRebel-Jenkins Deploy plugin
• The LiveRebel team doubled in size, so expect a lot more to come soon :-)
• LiveRebel’s current 90-day evaluation period is going to be cut shorter soon, so get your Continuous Deployment itch scratched now!

Stats, Data, Knowledge and Power

The most-read articles and posts of Q4…with a cherry on top

1. Java Productivity Report: India vs. Rest of World
2. JRebel vs. OSGi: Use the right tool for the right job
3. JRebel 101: What JRebel is and how it makes Java development lightning fast
4. Part 1 of the Java Reloading Classes series (5 parts in total)
5. Smelly Communication: How the Suits should assign tasks to Geeks

Cheers to an excellent 2012!

The ZeroTurnaround Team

Java is not dead…in fact, it’s got more than enough energy to kick your app in the butt. Too often, critics focus on niche issues and make unfair comparisons to other technologies or languages that do not have the same level of widespread use, applicability or history as Java. It’s like comparing a car to a carpet.

Children today are able to learn Java. It’s widely adopted among Web and Enterprise App producers. It has seen some amazing improvements in recent years and even more good stuff is on the way. But even excluding those latest additions, Java is still pretty darn cool: consider the widespread applicability and excellent engineering behind the JVM platform, the clarity of syntax, the rich ecosystem of tools and libraries and the fact that Oracle says there are over 9 million Java developers out there (and many billions of app/device users). So why do I hear remarks about Java being “on its way out” or, since back in 2007, that it is becoming “the Cobol of the 21st century”?

The Java platform is an engineer’s dream

First there’s the Java platform. The HotSpot JVM is a marvelous piece of engineering. It does stuff the CLR can only dream of and is so heavily optimized that often Java apps can even match the performance of C programs. Also, there is quite a selection of other virtual machines available (such as JRockit, Zing), should your environment have some specialized requirements.

Secondly there’s a multitude of JVM-based languages, which makes the platform even more amazing. It goes way beyond the famous ones like Groovy, Jython, JavaFX and Scala. Java now includes such treats like invokedynamic opcode and the java.lang.invoke package, making it easier to build dynamic languages for the JVM. There’s already a line up of over 50 JVM-based languages, one of the most interesting ones being php.reboot, which aims to keep the philosophy of PHP but remove its shortcomings. And it also works for Android, too.

Java is mature, but not a language for old people

Java as a language has been the target of much criticism, whining and cursing. I say the language is not dying or Cobol’ish either, quite the contrary. When complaining about Java and recommending better alternatives, people often use strange comparisons. Some people seem to think that Java is still in version 1.4, written in Notepad and requires EJB2 to write a simple guestbook. It is then compared to a high level framework or even a CMS!

As a Java developer, this comparison doesn’t make any sense to me. It is wiser to compare how Java measures up to more intelligently-chosen contestants…How about pure Java vs pure PHP, Python or Ruby? Or comparing the Play! Framework vs Ruby on Rails? Or Spring MVC vs Zend Framework? When put in this light, I feel that Java does not seem like a “language for old people” anymore.

Java is verbose? Of course it is!

People say Java is so verbose, and it slows them down. Critics often refer to the strong static typing and lack of bleeding-edge features in the language. However, I believe this is actually deliberate and a good feature of Java.

Dynamic languages are popular when starting a new small project, but consider this – with the help of modern frameworks and proper tools (i.e. consider using an IDE instead of Notepad), creating a “Hello Guestbook” type of application in Java is a simple, 10-minute affair.

If you want to test that, try Spring Roo and use a stopwatch if needed. Now, let’s take a step outside the trivial CRUD matrix used by cool languages and frameworks in their marketing talk.

Imagine you’re building a system for a mobile carrier and want to allow clients to sign up on their website. You will have to collect a lot of data and possibly invoke various subsystems in the backend. Cool frameworks often break down the minute your program model does not match the user model anymore. For more, I can recommend this wonderful post on that topic by Joel Spolsky.

Java is strong with static typing

Strong static typing has many benefits. I love its simple visual appearance. I can glance at a piece of code and usually figure out immediately what’s going on. It’s like the visual feedback in English – the lgnaugae is so esay to raed taht the lettres can be miexd up isinde wrods, and it’s sitll redaalbe.

Some other benefits of the type system include strong IDE support. Dynamic languages will always be at a disadvantage here. Having a simple, no-nonsense language in a huge project with great IDE and tooling support is priceless. Nothing else comes even close IMHO.

Critics have a point that Java may lack some of the expressiveness when reading a file, transforming xml or iterating through a collection, but you can always create a sub method to handle common cases, or use FileUtils.readLines(). There is also a huge number of libraries available for Java that handle most of the “expressiveness shortcomings” of the language.

Java 7 saw some neat enhancements such as auto-closable resources, String support in switch statements and underscores in numeric literals (I urge you to read up on project Coin). Java 8 promises even more (most interesting part being closures).

The takeaway here is that the language is getting some fresh blood. However, the features will not be some experimental ideas which may or may not be around in two years, but proven and mature concepts. This does not mean the philosophy is mutually exclusive with having fun when programming. It isn’t.

A Fanboy Rests His Case

Is everything about pure Java perfect and justifiable? Of course not. And that is why there is Java 8 in the works. And Java 9. What I personally dislike most about Java is the not-so-smooth core API, and there is a debate whether this has actually more to do with the platform than the language. The core contains the evolution of API design spanning two decades, and modernizing it all will break backwards compatibility. Some parts are too abstract, some not abstract enough. Some bits are too fragmented. Some are just plain weird. Looking at the competition, the core API could do well with the unified communications API like .NET for example. Java 8, with the help of project Jigsaw, may change that.

So there you have it. Pure Java, used properly, is an awesome language. Even more so than Klingon. It will continue to improve and will not go away anytime soon. The effort should not be on replacing pure Java, but using it together with other JVM languages where it makes sense. But for my next Pet Clinic, I’ll stick with Java.

***

P.S… An Example of Java in Use

This article, like Java, is a bit verbose, so I’ll leave this example for any readers who want to continue.

Say you need to build a web application and you need control over the html output or http requests. Consider the stack of pure Java, Spring MVC and Hibernate. Yes, it’s an old combination, almost like a cliche, but it works beautifully. It has many benefits and little downsides, most of which can be eliminated with a little help from your tools.

Writing Java code is fast when using a modern IDE (Eclipse, Netbeans, IntelliJ). All of them have code completion and shortcuts that take much verbosity-related angst out of your day. Using relatively modern (i.e. less than 3 years old), versions of Spring and Hibernate, you don’t need to write five miles of xml to have red buttons with rounded corners (it has never been that bad but people love exaggerating). You can use annotations most of the time. Even when you need applicationContext.xml, using a Spring IDE plugin makes that a breeze. With JEE 6, you don’t even need a web.xml. Even if you have to use an older servlet spec, IDE will generate web.xml for you. It can generate a project layout and add servlets just like Grails’s command line console, but better.

The last bit you might complain about is the turnaround. Making a small change and seeing the result has always been fast in PHP, but not so much in Java. Again, tools are there to help you. Without tooting our own horn, JRebel, for example, will instantly reload classes in the running application regardless of your stack. Same goes for refreshing Spring and Hibernate configuration. It goes even further by mapping resources between the workspace and the deployed application. This makes your life easier when working with static resources too – you don’t need to copy jsp’s to the right place or run any build script to see the changes. Just press ctrl-s.

You get to keep all that’s good about Java. In short – you’ll have the best of both worlds.

Tweet

Just as the roads were starting to freeze over in Estonia, the tiny, northern-European country that keeps popping up on the global innovation radar, 25 tech experts met to discuss the upcoming year.

This group, which included investors, CEOs, engineers, advisors and journalists, put together a lineup of the most influential thought leaders and IT companies in Estonia to watch in 2012. Having won three awards in 2011 alone and attracting the attention of Bain Capital Ventures in the USA, ZeroTurnaround was selected as the #1 Estonian IT company to watch in 2012.

IT experts voted ZeroTurnaround #1 company to watch in 2012Sten Tamkivi, Director of Product Focus and Catalogue Operations and General Manager of Skype in Estonia and Advisor to the President of Estonia said (translated from Estonian), “We will see in 2012, how smoothly gears change from [Webmedia to Bain Capital Ventures]. Looking from inside, I like the joyful geek-culture that can be seen beyond the borders of ZeroTurnaround; a team with 50-100 people is just about the size where soft values and unique culture helps the company go further and not break down.”

Undoubtably, 2011 was “the year of JRebel”, winning the Duke’s Choice/Oracle Innovation Award, JAX Innovation Award and Estonian Innovator of the Year Award all in 2011. A visit from the President of Estonia to the company’s offices confirmed ZeroTurnaround’s position as a major innovator in the field of Estonian IT.

In 2012, ZeroTurnaround will focus on introducing LiveRebel to operations teams all over the world, in an attempt to help companies see their Continuous Deployment/Continuous Delivery goals come to fruition.

This year will also see the company investigating what makes developers tick. ZeroTurnaround recently launched a survey to get at the heart of how coders spend their time at work, plus which tools, technologies and employment conditions increase or decrease productivity, stress and work satisfaction.

**Teaser: The average developer spends less time writing code each week than one might think. The survey can be found here: http://0t.ee/prosurvx12

According to Taavi Kotka, Managing Director of Webmedia Group, Estonia, it is difficult to call ZeroTurnaround a ‘startup’ anymore, but a company that needs to follow an aggressive vision and product goals. “If the ZeroTurnaround team will manage to do this, they will be Estonia’s highest valued software company by the end of 2014.”

Estonia is pushing hard on to become world-leaders in IT innovation, setting up programs (like e-Estonia, a pet project of the country’s president) that make it easier for people to create their own startup. ZeroTurnaround is proud and honored with it’s recognition as the “#1 Company to Watch in Estonia in 2012”.

Tweet

Tweet

If you’ve ever worked in a large team before, then you know that even figuring out where to go for lunch can be a pain. So you can imagine that a large team using JRebel can find it difficult to track and manage overall team usage, see the number of redeploys prevented, how much time has been saved, and so on.

For just these cases, we developed the JRebel License Server, which provides an easy way for companies to manage their multiple enterprise license subscriptions. The JRebel License Server is standalone application written in Java, just like JRebel and LiveRebel, which makes it platform-independent. Using scripts provided with the license server, you can quite easily run the server as a service in Linux; however, running this service in Windows needs an additional software and configuration.

This article will show you how to run the JRebel License Server as a Windows service using a well-known application named Java Service Wrapper from Tanuki Software. Although the configuration process is well described in the product’s documentation, let’s see how Java Service Wrapper can be integrated into the JRebel License Server.

STEP 1. Obtain software

Download the ZIP package of Java Service Wrapper from the Tanuki Software site here: http://wrapper.tanukisoftware.com/doc/english/download.jsp and unzip the archive to your desired location.

Next, download the ZIP package with JRebel License Server available from ZeroTurnaround.com: http://zeroturnaround.com/jrebel/license-server/ and unzip the archive to your desired location.

STEP 2. Put the Pieces Together

The Java Service Wrapper application is able to integrate with applications in four different ways, which are described in the documentation at http://wrapper.tanukisoftware.com/doc/english/integrate.html. We choose the fourth method, because the JRebel License Server is configured to run as an executable jar.

Note: There are four directories that are required to be configured in order to be able to use the Wrapper.

1. bin directory

First, please copy the following files from Java Service Wrapper directory into JRebel License Server bin directory:

{WRAPPER_HOME}\bin\wrapper.exe
{WRAPPER_HOME}\src\bin\App.bat.in
{WRAPPER_HOME}\src\bin\InstallApp-NT.bat.in
{WRAPPER_HOME}\src\bin\UninstallApp-NT.bat.in

Rename the three batch files to ZTLicenseServer.bat, InstallZTLicenseServer.bat, UninstallZTLicenseServer.bat.

You should now have:

2. lib directory

Copy the following two files into the JRebel License Server lib directory:

{WRAPPER_HOME}\lib\wrapper.dll
{WRAPPER_HOME}\lib\wrapper.jar

You should now have:

3. conf directory

Copy the following template file wrapper.conf.in into the conf directory of JRebel License Server and rename it to wrapper.conf

{WRAPPER_HOME}\src\conf\wrapper.conf.in

Obtain your Java Service Wrapper license and put the license code into wrapper-license.conf in the conf directory of JRebel License Server (Hint: you need to register on Tanuki Software site to obtain a trial license).

You should now have:

4. logs directory

Create a logs directory in JRebel License Server folder.

STEP 3. Configuring Java Service Wrapper

Open the wrapper.conf file in an editor and make the following changes below. A detailed description of the configuration steps can be found at http://wrapper.tanukisoftware.com/doc/english/integrate-jar-win.html#wrapperconf, but we will change this file in six places:

1. Add wrapper.java.classpath.2=../lib/zt-license-server.jar after wrapper.java.classpath.1=../lib/wrapper.jar line.
2. Replace <YourMainClass> text with com.zeroturnaround.jrebel.WebServer.
3. Replace @app.long.name@ text with ZeroTurnaround License Server.
4. Replace @app.name@ text with ztlicenseserver.
5. Replace @app.long.name@ text with ZeroTurnaround License Server.
6. Replace @app.description@ text with ZeroTurnaround License Server.

Putting it all together, we get the following:

wrapper.java.classpath.2=../lib/zt-license-server.jar
wrapper.app.parameter.1=com.zeroturnaround.jrebel.WebServer
wrapper.console.title=ZeroTurnaround License Server
wrapper.name=ztlicenseserver
wrapper.displayname=ZeroTurnaround License Server
wrapper.description=ZeroTurnaround License Server

STEP 4. Running JRebel License Server

Your shiny new JRebel License Server now can be run by executing the batch file bin\ZTLicenseServer.bat. Please try to execute the server at least once as a console application to verify the configuration before installing it as a service. If the server is working OK as a console application, you can stop it by pressing Ctrl-C and install it as Windows service by executing bin\InstallZTLicenseServer-NT.bat.

After successfully installing ZeroTurnaround License Server service will appear in the list of Windows services and you can start it like usual Windows service:

That’s it! Your license server is now running as service.

STEP 5: Let us know if it worked!

Please help us, and others, with your feedback. Just post your comments and suggestions to our forum, or below in the comments section.

Older Entries »