Slow SecureRandom is always annoying; I just wish Oracle would fix their documentation
I’ve had a new virtual server (CentOS 6.x) commissioned to run as a jenkins slave. After installing all the pre-requisites on the box and configuring various build properties; I started a standard build of the framework on the machine. The build works, but it’s extremely slow.
After some investigation and isolation; we nailed it down to SecureKeyFactory.generateSecret() which is used when we decode passwords. The performance of encoding didn’t really seem to be affected, the big problem was with decoding. We tend to store all our passwords encoded in our various build properties so whenever Password.decode() was called, this would take ~30 to 40 seconds consistently.
Why I think a build step is critical for project collaboration
I started doing Assembly, then C, dabbled in COBOL for a while so I’ve always had to have a build/compile step as of my development workflow. Working with Java hasn’t been anything different, you use ant or maven to compile your source files and then run your tests. Lately I’ve been reading more and more about people hating java and their myriad reasons for that. I don’t think I have anything to add around that subject other than more invective so I shan’t. I happen to know few languages and I just choose the best one for the job at hand, just do the work. Java has it’s idiosyncrasies, but if your reason for hating java is that until recently you couldn’t do a switch statement with Strings; you shouldn’t hate java, you should hate yourself for being a programmer who likes switch statements ;).
Brief notes on upgrading redmine from 1.1.2 to 1.4 on CentOS 5
Recently we upgraded redmine from 1.1.2 to 1.4.2. It was an activity that I had planned for a long time, but as usual things get in the way of doing that. Redmine, perhaps ruby on rails makes that easy for you, has a very well documented path for upgrades so the upgrade itself didn’t take very long, about half an hour. Of course I had run through the process already on a different machine to make sure we weren’t going to hit any odd snags due to the platform / ruby versions or whatever.
Why we settled on redmine as our project management tool
Our main development management tool is Redmine. It has been since December 2010. We tried a lot of tools before settling on redmine. It was the only one that we ended up going back to and using. If, after a month of trying to use something, you end up not using it, then either you’re too set in your ways, or the tool isn’t good enough. Our journey to settling on redmine as our web based project management tool is a long and chequered one, and it all started in 2010.
Tidying up after yourself when you screw things up in mercurial
Our source code management tool of choice is Mercurial; which is a python based DVCS. We switched back in 2009 once we’d gotten fed up with CVS. There are still a few internal projects using CVS, but these days almost all the developers are using mercurial. People always ask why we never moved to subversion and generally my answer has always been because it’s not *significantly* better than CVS. Yes it is better, it might even be CVS done right (not that this is a good advertisement for subversion); but ultimately, I need to use it on the plane or during a proof of concept with no external network access and collaborative development has to take place.
When you have a team of people actively maintaining a code base, someone somewhere is going to break something. It’s unavoidable, skill levels, and interest levels in SCM tools vary massively. We tend to trust the people working on the codebase so more often than not everyone has push access to our repositories. That means mercurial is going to break, at some point, sometime. Just this last week, we had 2 SCM breakages in 2 separate projects, one of which I fixed, and the other was manually merged by the team of devs.