Thursday, July 16, 2009

iPod Touch 2G requires charger adapter

I know this has been blogged before, but I feel so strongly about it, I need to post my own rant as well.

Apple for some obscure reason decided to change the layout of the dock connectors charging pins between the iPod Touch and its 2G successor. The same fate also hits iPhone 3G and 3GS. The older models used the FireWire portion of the dock connector to charge the devices battery. Many accessories, including Apple’s own hifi adapter kit and most car-connectors are now useless in terms of battery recharge, because the new models only access “USB electrons”. I guess we can call us fortunate that we don’t need a Linux kernel module in our cars to keep charging while driving. 

This is really annoying, because before the new device I would just plug the iPod in when I got into the car, listened to podcasts while commuting and could leave with a fully recharged device when I arrived. Now they seriously ask me to pay €25 ($35) for an adapter that will a) provide a cross-over of the power pins and b) prevent me from putting the iPod where it belongs in the car: that special slot in the console where the connector of the car kit emerges!

I am somewhat p*ssed right now!

Technorati Tags: ,,

Thursday, July 09, 2009

Modularizing Software with Ant/Ivy and Eclipse

This is one of the rare times when you get the chance to some technical cleanup and rewrite time from management, so we are trying to get some new things going that were pushed time and again in the past. In the architecture meetings we have been telling ourselves that we’d have to modularize better, so more unit tests could be written and overall quality be improved. Instead for lack of time we had to add new features to an already overloaded codebase and cross our fingers that nothing would go truly wrong in production. So far we have been very lucky.

Having some time now for cleanup and refactoring we quickly came to think about the build process – currently a large pile of Ant scripts, resembling a full blown software project in its own right regarding the complexity. I asked around on StackOverflow for experiences and best practices. I got some interesting answers, including recommendations for using OSGi and maven. I have some experience with OSGi from a previous project, and I think we will go for at least maintaining the relevant metadata in the MANIFEST.MF files we are creating. However as this is a chance for cleanup, not rewrite, getting everything in shape and run inside an OSGi container would both be too time consuming and hard to sell internally.

Currently the product is “organized” in about 45 Eclipse projects, totaling about 3 million lines of code, including a very small fraction generated classes. The real problem here is not really size, but complete and utter chaos concerning dependencies. When the project started out we were under severe time constraints and people took all sorts of shortcuts, not documenting which depends on what and why. Add duplication of functionality (“copy-paste-coding”) to the mix and there you go with a fine spaghetti dish…

But back to building the thing… The build process relies on a specific build order, but everything that gets compiled can “see” everything that came before it. This includes external libraries of course. A full build – and that’s the only thing possible – takes about an hour, excluding findbugs, checkstyle, tagging the repository etc. All in all about 3.5 hours from start to end.  And of course whenever something changes we have to compile the whole thing from start again – reason explained already.

We decided to go for some technical underpinnings to try and separate from each other for starters, as we can do this without needing to exchange and interact with business people. Once we gain some experience and have learned some lessons about what works and what does not we will try and go for the more juicy stuff. When looking at maven we quickly decided that we could not restructure our code in a way that would make it compliant with maven’s project layout. This and the fact that we would not realistically be able to follow the one-project-one-artifact rule maven forces on you (I hope this is still like that, did not check again). Ivy does not impose anything like that, a module (configuration) can consist of as many jar files, zips etc. as you like.

Moreover we also realized that in the beginning we will not be able to get completely rid of some custom logic that would be hard to implement within maven anyway. However we came across Ivy again – which a) we had looked at maybe two years ago but lost sight of again and b) has become an “official” Apache project – and decided to give it another try.

I have to say this was the most pleasing experience with an open source product I have had in a long time – maybe ever. The documentation is really extensive and very well written, despite the author’s self-criticism in terms of his English-skills:

An important thing to be able to use a tool is its amount of documentation. With Ivy, even if they are written in broken english (would you have preferred well written french :-)), the reference documentation is extensive and covers all the features including many examples. We also provide some official tutorials which are maintained with the new versions of Ivy. And since we consider documentation so important, we also provide online versions of documentation per Ivy version since Ivy 2.0.0-alpha2.

It is very readable and from my (German) point of view it sports a better writing style than many other manuals – if you get documentation at all. In fact trying out Ivy was a profoundly enlightening experience. Without much exaggeration, time and again when we came across a new aspect of the old system which we would have to find some way to redesign and re-implement in a new build, Ivy already presented a viable solution. This combined with an apparently very real-world approach to some problems (e.g. recommending not using a public repository for corporate products, something I always disliked anyway when reading about maven) really impressed us. (You can however use maven2 repositories if you really want to).

The concept of configurations is very useful: You can define a module and give it a name and define its version and then have several views of this module, called configurations. One configuration might be for production use, another one for testing. For both configurations you can define individual dependencies on other modules and their configurations. This combined with the very comprehensive Ant integration library the build.xml scripts of most reworked components simply consist of jar-ing and zip-ing compiled classes and source files together. Once done, we just call an ivy task inherited from a common build script that publishes the new module version first to a local repository for testing and optionally to a shared company repository. For simplicity we currently use a simple fileserver share, but there are other options available as well. All the rest is taken care of by Ivy: just pointing it to the repository it manages to fetch the required module artifacts from there to a local cache to build against. Conflict resolution is very configurable with the built in options already, and for the unlikely event that there is no suitable option available, you could just write a plugin yourself.

Maybe the best part however is the availability of a really useful and thought-through Eclipse plugin called IvyDE. As mentioned earlier our product is modeled and coded in Eclipse. In the past it had always been a chore to keep the poorly defined dependencies somewhat in sync between Ant scripts and Eclipse project definitions. The Ivy plugin solves this very elegantly: You configure the location of your repositories and common settings file (used by Ant and standalone Ivy tools) once and then just add an automatically maintained user-library to your project. If you later edit your ivy.xml file(s) – which include the dependencies and module properties for Ant anyway – upon save the user library gets updated automatically, including source and java doc attachments to allow for step-by-step debugging, source lookup etc. Without this it would have been really difficult to get acceptance with the other developers – they do not really care about too much of the “meta-stuff”. But I also personally have to admit, it makes things much easier to use, you just don’t have to give up any of the comfort you have gotten used to.

The plugin is still a beta release, but more in the Google sense of beta. There are some problems – error messages could sometimes be a little better and from time to time when you have syntax errors in our ivy.xml files the user library is not displayed in the Project Explorer view – but this stuff is really usable already!

We still have ways to go before we can really call our efforts even remotely complete, but I am very sure without Ivy it would be hell of lot more painful! Thank you Ivy!

Monday, July 06, 2009

Domain Hassles - Part 2

I am almost done with the domain changes to this blog. It is currently reachable via which is what you should already be seeing in the address bar right now.

The domain is working partially, I guess some DNS updates have not propagated to everywhere yet. It should redirect to the .com immediately, however currently it still seems to have the CNAME to Blogger in place. This should only be a matter of hours now.

Mail is configured for both domains and seems to work just fine.

During the whole change process I had to contact DomainFactory's support for some tips on which contract types would give me the features I wanted at the minimum possible cost, and even though it was on Sunday I got a (sensible human-written) response within 5 hours. Pretty impressive.

Their web interface is clean and understandable, very nice as well. And the pricing is really affordable: I now have 2 domains in the MyMail package which is 6.60€/year per domain + the domain costs of 1x .de (6.60€/year) and 1x .com (12.60€/year), totalling 32.40€ per year. This is way less expensive than the 1&1 rate (47.88€/year for just the .de domain and no chance of configuring CNAMEs).

The only thing left now is to cancel that 1&1 account.

Using Pages ‘09 in “WriteRoom” Mode

As I am currently in the process of writing a book, I am always on the look for a better way to write stuff down. While the publisher wants to have OpenOffice or Microsoft Word files, I am not perfectly happy with writing in either OpenOffice or NeoOffice. They both seem to bloated and full of stuff, all the time taking my attention away from just pure writing.

When looking for a simple note taking tool for OS X I came across a recommendation for WriteRoom, even though it is not a note taking tool per se. Turns out this is the most useful – and also simple – piece of software I have seen in a long time when it comes to getting the one task it was designed for done right: Write and don’t let anything distract you. This is how it’s done in WriteRoom; a fixed font display in a retro-looking green on an all-black background in fullscreen mode:
Write Room

While at first I was a little skeptical I have come to love it. My iMac screen is not set to a very high brightness by default - but even when I dim it down to a minimum, it still somewhat hurts my eyes to look at the white page background when the room around me is dark (which it usually is at the time I tend to write the most). With DarkRoom this is not a problem anymore, and if you like other colors better than green on black, you can of course customize that as well.

However I am not sure I want to pay $30 for what is basically a standard text control wrapped in a full screen mode. Today I remembered I had never actually used Pages ‘09 from the iLife suite I bought when it came out for iPhoto’s Faces and Places features. But I knew that it sports a full screen mode as well. Unfortunately you cannot configure the display settings to use a different color than white for the “paper”.

So I just went ahead and created an empty document, placed a rectangular shape on it, filled with a black to dark gray gradient and put that into the background. Then I sent it to the page master and adjusted the default font color to white. Voila: A WriteRoom-esque full screen editor:

Pages 09 in Full Screen Mode

This works just as well – and the best is that I have already paid for it.

Saturday, July 04, 2009


I just whipped through the ordering process for with DomainFactory. From ordering to having the domain online and reachable (at least for me) it took less than 30 minutes, including automated SMS message for activation, setting up mailboxes and configuring the CNAME to point to the blog.

I am impressed. Now I will try and test this a little more, before maybe migrating the rest of my domains to them as well…

1&1 Domain Hassles

Earlier this week I (again) thought about changing my Blogger settings to use my own domain - in the end what is it good for to pay every year for my custom domain only to have it forwarded to the one-of-many subdomains.

So - having pushed this for in fact several months now - I finally went to the Dashboard and looked up the instructions on how to configure my own domain name - turns out you need to set up a CNAME and point it to a Blogger subdomain.

Unfortunately my (then) current 1&1 contract did not allow DNS customization - I could just set up an HTTP redirect which I had been using all along. This is when the fun began...

First I tried to find a way to somehow upgrade my contract from within their "control-center" to no avail. I did find - via their homepage - the homepage hosting offerings, however there did not seem to be a way of telling them I already had the domain in a running contract.

So I contacted their support team and was told I needed to sign up for a new webhosting package and transfer my domain in the process - somewhat over-engineered and rather un-intuitive if you ask me. Nevertheless I did as I was told and signed up for a 3,99€/month minimum hosting account and checked all the marks needed to transfer my domain.

After what felt like 35 emails and web forms later the control-center showed me that the domain was being deleted from the old contract and added to the new one. Fortunately the supporter had told me to externally write down my email settings, because in the process of moving from one contract to the next within the same company(!) all configured email addresses and all content in the current webspace would be deleted! Luckily I only use mail-forwardings to GMail, otherwise I would have had to change all IMAP mail clients as well...

In the middle of the whole thing my website suddenly disappeared - accessing brought a 404 error. I could not do anything about that for about 4 hours. Great stuff...

When finally everything seemed to have completed - it was possible to set up the mail addresses in the new contract in the meantime - I went to the DNS settings, just to find out that I can only change A and MX records!

I was however sure I had seen some screenshots on the web before, showing a admin site snippet with a CNAME setting, otherwise I would not have started the whole thing in the first place. Turns out that there seems to be either a difference in the German and US/UK configuration options. Of course when I searched for this very problem Google dug up several forums and blogs of other German customers, all telling about the same experience.

Great... Now I have a 6 months contract, payable in advance for nothing! Looking for a different domain provider now...

Geeez... And all I wanted was a nicer looking address bar...