String is evil

Over the last days I had to fight with legacy sourcecode again. It is always hard to figure out what other developers meant years ago when the code was written. But it gets even harder when every single parameter is a String. It’s annoying and slows you down, because you always have to look up which format the String should be. Is it maybe an Integer? Or some kind of flag? Or is there more information encoded in this String and do you have to rebuild a strange ASCII format filled with information to call that method?

Truth is, you don’t know. You just want to call a method called addToAcl(String role), but what is that parameter? The name of a role? Or the longer display name of the role? Or is it the UID of the role? How is the UID represented?

I have to deal with legacy sourcecode all the time, sometimes it’s years old. Often the developers are not available anymore. And there is a lot of string-passing around, integer return codes and other awful things I try to avoid whenever I write code. It’s not always possible to avoid it myself, but that doesn’t stop me ranting about it here on my blog. 😉 I came upon so many methods were I couldn’t tell what I need to pass by reading the method and parameter names. I had to open the method source, look up what it wanted to do with the parameter and then give the right value to the method.

Stephan wrote a good article about evil Strings over at codemonkeyism, so I won’t give another example here. But if you are tempted to add a integer parameter or a String parameter to any method, ask yourself: Will The Next Guy[tm] know what this parameter means? Or should I use a real object here?

Things to avoid when creating software

Carlos Coliveira has another good blog post about robust software design. I like to comment on his thoughts, because this is something that is on my mind every single day when staring at the screen in front of me. Because I’m working in the defense business, I need to care about the long live of software. It’s not that releases come out every 8 weeks here, and the software is not replaced after only one or two years. So when you start implementing software, you have to take care about the maintainability and readability of your code, most likely it will be continued by someone else anyway.

Carlos has a good point:

Avoid useless abstractions: this is related to the previous topic, but deserves to be treated separately. Abstractions are useful if they simplify the way a feature is implemented. However, some abstractions exist only to satisfy the needs of developers.

I tend to fall into this pit, because I’m a big fan of patterns. And you can throw a bunch of patterns in every day. 😉 But is it always as useful as you might think? I don’t think so. Do you really need the plugin mechanism for a simple file access? Do you really have to implement all the interfaces and classes just to be able to add a new kind of transportation container soon? I try to follow KISS and avoid unneccessary code. A good example for this: I created a small servlet that reads LDAP information and displays them on a web page. All implemented as a servlet. Yes, I know, separation of code and display. But do I have to add a templating layer, JSPs, a model and all that if the application is more likely to vanish than to be continued in a few months?

The next tips in Carlos article are good to keep in mind too.

  • Make it easy to change your implementation
  • Avoid using components that will require effort to understand/change

A few days after implementing my LDAP information servlet, I was asked to add a way to get information from a remote server. I added XML output to my servlet, placed an instance of it on the remote server, added the ability to read the XML, started a local instance and it was ready to go. I invested some time upfront to get my code clean and separated in methods for easy access, so it was not a problem to add this behavior.

But what’s more important: I didn’t had to fight with a templating engine, didn’t had to add dozens of JSPs and used pure JDK for this changes. I think this little servlet is easy enough to change, so if it don’t die in a few months, the next guy can jump right in, read throught my (hopefully clean enough) code and add what is needed then.

Or change to a template engine with an SQL backend, cached LDAP information if the remote host doesn’t respond, AJAX for the frontend and a few plugin algorithms and patterns. 😉

Ich bekomme einen Drobo!

Seit ich das erste Mal mit Rechnern zusammengetroffen bin, habe ich Daten verloren. Quelltexte von 1995? Futsch. Dokumente von früher? Weg. Musik? Verschwunden. Gescannte Rechnungen und Briefe? Im Nirvana.

Seit Tagen mache ich mir deshalb Gedanken über eine gute Backuplösung, die mir auch in Zukunft weiter hilft. Im Moment habe ich eine WD MyBook 1TB hinter dem Monitor stehen, auf die Time Machine meine Backups macht. Aber ein Backup auf 1 Medium ist im Schadensfall so gut wie kein Backup. Also muss etwas anderes her, damit meine Daten sicher sind.

Als erstes fällt mir da das Stichwort RAID ein. Mehrere Festplatten sichern Daten in einer Art, dass eine Festplatte den Geist aufgeben kann, ohne dass die Daten verloren sind. Im Fehlerfall kann also die defekte Platte ersetzt werden und die Daten sind weiter gesichert. So etwas kann man sich in den Desktoprechner einbauen, wenn man einen Laptop hat, muss man auf externe Geräte ausweichen. Was genau genommen auch die richtige Lösung ist, damit man das Backup nicht im Zweifelsfall mit seinem Rechner zusammen verliert.

Geräte gibt es wie Sand am Meer: NAS, USB, externe Steckplätze für 2 Festplatten. Und den Drobo.

Drobo ist ein externes Gerät (bzw eine Produktreihe), in das man in der von mir gewünschten Ausführung bis zu 4 Festplatten (im laufenden Betrieb) einstecken kann und das selbstständig für die Sicherung der Datenüber alle Festplatten sorgt. Der Knackpunkt ist, dass man die jeweils kleinste Platte einfach gegen eine größere austauschen kann, mit der Zeit also mehr Platz erhält und die Daten trotzdem weiter gesichert sind.

Und weil ich keine Daten mehr verlieren möchte und mittlerweile eher der Typ „einfach geht vor durchkonfigurierten Nächten“ bin, hab ich gerade einen Drobo bestellt. Bei Amazon UK, das Angebot war inkl. 1TB Festplatte von Western Digital günstiger als alle deutschen Seiten. Wenn das Gerät angekommen ist, mach ich mal Fotos& Videos. 😉

Autohotkey: Resize windows

I was tired of moving and resizing windows by hand, so I created a small script for AutoHotKey that allows quick window organization. I added only what I need right now, so you have the following actions:

  • WIN+Up: Maximize current window
  • WIN+Down: Restore current window
  • WIN+Left: Put window to the left side of the screen
  • WIN+Right: Put window to the right side of the screen

The Left/Right actions are really useful if you like to work in splitscreen mode. I do that often, so this comes in handy. I think this little script allows for quick modification, so feel free to add any functionality you like to have.

#InstallKeybdHook
#Up::WinMaximize A
#Down::WinRestore A
#Left::LeftHalfWindow()
#Right::RightHalfWindow()

LeftHalfWindow()
{
SysGet, area, MonitorWorkArea
w:=((areaRight-areaLeft)/2)
h:=(areaBottom-areaTop)

WinRestore, A
WinMove, A, , 0, 0,%w%,%h%
}

RightHalfWindow()
{
SysGet, area, MonitorWorkArea
w:=((areaRight-areaLeft)/2)
h:=(areaBottom-areaTop)

WinRestore, A
WinMove, A, , w, 0, w, h   ;Middle of screen is same as w.
}

IX Spezial: Programmieren heute

Falls ihr es noch nicht mitbekommen habt: Ab heute gibt es die iX Spezial: Programmieren am Kiosk. Also, hin und kaufen. Oder abwarten, bis ich die Artikel durch hab und etwas drüber blogge. Wenn ich aber an den Stapel noch zu lesender Bücher denke, kann das noch dauern… 😉