A few weeks ago, a few of us joined the Jenkins community at the Jenkins User Conference 2012 in San Francisco. Our presentation “Improving Software Quality Using Component Lifecycle Management with Jenkins” given by Manfred Moser, was very well attended and there seemed to be a lot of interest. A video of our presentation has now been posted here and you can download the slides as well.
Branching is boring. Merging is also boring. None of this stuff is fun. But for some strange reason, I still see the occasional branching policy which involves using the largest number of branches you can possibly justify
I wrote about the NetBeans hint "Overridable Method Call in Constructor" in the blog post Seven Indispensable NetBeans Java Hints. In this post, I look at why having an overridable method called from a parent class's constructor is not a good idea.
Let's say you're visiting NYC and need an Internet connection. Where's the nearest Wi-Fi hotspot? How might an HBase application help you answer that question? What kind of design decisions go into solving that problem, and how can it be solved in a scalable way?
In the industry, I see a mindset problem that can be very detrimental to the software quality - and quite opposite to the Software As an Art mindset: shortsightedness to fix only the problem at hand. Let me explain through an example.
Been a couple years ago that I went from Rally to AgileZen. About to move to Atlassian now. In the spirit of keeping the tone the usual combination of acerbic and direct, I‘ve decided to group my reasons for this, first the philosophical ones: