A year of trying better development practices

Hmm. One would say that I don't seem active on my blog. I'll be a liar if I say otherwise. It's just been hectic at the office and you know, it's not a great idea to write any posts when you are not inspired.

That changed for today! I feel like writing a blog post again, and I need to do some catching up on what happened in the meantime.

My last post was on good development practices and using distributed version control, in the form of Git. It's close to a year now since I started using git, and I got really comfortable using it at the office, although we use a central repository in the form of subversion.
Unfortunately I had to switch back to subversion this past week, and I have to say, it's hell, waiting for updates and committing. But I can't really use git like I used to, since the subversion repo is set up wrong in that multiple sub-folders are used for individual projects. Thus, you'll have revision numbers following on each other across different projects. But hey, subversion is doing its job, forcing its users into submission :P

Having projects set up in a better structure would definitely help. I'm using IntelliJ IDEA and I've noticed that when I checked out the project modules using git, it was pure bliss to create a multi-module project, where all the modules were recognized on using the root folder as the project base.
On the other hand, I had to break a sweat to manually import every module separately since I guess it's something to do with subversion. Or just my lack of knowledge of IntelliJ's subversion support and project creation.

Once a user gets used to the notion of distributed source control management and all the advantages that comes with it, it's hard to go back. Where you used to have the ability to play around with code and branches, that luxury is stripped to the bone when you switch back to subversion.
The only single plus-point for using subversion at work is that you can actually have all the latest changes, whether they break things or not, at the current moment. You of course need to keep back any commits and need to sort out your code once any conflicts are encountered.

I sound biased, but with reason. I've gotten used to distributed source control management in different (2) forms. I've been working on the OpenLP Remote, running on Android. The main project and the Android remote is managed on Canonical's Launchpad, which makes use of Bazaar. It has a great toolkit that nicely integrates with linux and helpful GUI tools too.
The other is from using git on my own and at work, with the git-svn bridge. It isn't bad to use the git-svn bridge on smallish projects with less than 6 modules, but when a project has more components and modules that can influence other parts, it's a big hassle to sync. I did not spend the time to create a script to handle the modules, but I suspect that it will be possible after all, and needs some research.

But for now, there is not enough time to get to everything just yet. So there's one more item on my TODO list :)

Over the Easter weekend I've started playing around with Amazon's Simple Storage Service, or Amazon S3. It seems like a pretty easy-to-use solution, and I have plans to create a small application for the local photo club that will make use of Amazon S3. It will be distributed as the storage will be on S3 and the service will run off a Linode. My mind just wandered along what to do and what not to do, so I did not start on anything yet. It will be a long-term project though, so no haste in finishing anything.
There's been some noise on the Internet on the price of S3 services, but then again, if you take into mind the level of availability, it's not much at all. I will just wait and see for myself how things will work out.