When listening to Boagworld's podcast some weeks ago I heard about the Fancy Form Design book from SitePoint. Since Paul Boag recommended it I thought, well, give it a try. And yes, I think it's a nice book, indeed. I like it because it gives the reader new ideas on how to design and implement modern forms.

So being inspired after reading the book I looked at my own "Your comment" form and thought: "OMG! WTF?" I have to admit I never really spent much time on designing and implementing the form. But after reading the book I though it was about time to give my comment form a little bit of love. During the process of revamping the form I also digged deeper into the world of jQuery which is a good thing imho. I even wrote my first little plugin that handles an example value on form fields like this:

$("#id_author").fancyField({sampleValue: "Joe Cool"});

It will automatically setup everything like registering for focus() and blur() and even registering on the enclosing form tag for the submit event. Anyway, have a look at the form for yourself to get the idea :)

As you already might know I am a great fan of distributed version control systems (DVCS), especially Git. Today I came across an article that explains the differences and advantages of DVCS very well:

The Journey to Git, Part I.

Let's assume you work on an agile software development project and for the next release you have to implement user story A, B and C. A distributed version control system (short DVCS) allows you to create one branch for each user story, so called feature branches.

In letzter Zeit habe ich mich sehr viel mit den sogenannten DeCentralized Versioning Systems (kurz DCVS) beschäftigt. Im Gegensatz zu den bekannten zentralen Systemen wie CVS oder Subversion basiert die Idee der DCVS darauf, dass jeder sein eigenes vollständiges lokales Repository hat. Hieraus ergeben sich nette Vorteile. So wird es z.B. möglich, auch offline arbeiten zu können. Dies ist gerade für mobile Entwickler hilfreich, da nicht immer eine Internetverbindung zum zentralen Server besteht. Dabei geht es nicht nur um die Möglichkeit, Änderungen einchecken/auschecken zu können, sondern auch Funktionen wie diff, log, annotate. Der wichtigste Vorteil für mich persönlich ist, dass ich dank Git lokale Branches anlegen kann. Diese Branches existieren im Gegensatz zu Subversion nur lokal. In Git wird dies typischerweise als "Topic-Branches" bezeichnet. Ich habe mir inzwischen angwöhnt, neue Features immer in eigenen Branches zu entwickeln, um sie dann, sofern sie meinen Ansprüchen genügen, in den Mainbranch zu mergen. Da das Erstellen von Branches eine Sache von Sekunden ist und das Mergen in Git sehr mächtig, wird man durch die Verwendung von Branches meiner Meinung nach sehr viel experimentierfreudiger. Möchte man eine neue Idee mal kurz ausprobieren, so legt man sich schnell einen neuen Branch an und probiert es einfach aus. Ist man sich noch nicht ganz sicher, so lässt man den Branch erstmal ruhen und arbeitet an einem anderen Branch weiter. Diese Flexibilität bietet Subversion so nicht, da jeder Branch aufgrund der zentralen Natur für alle sichtbar ist. Branches in Subversion werden typischerweise eher für Wartungszwecke von Releases verwendet, als denn zum Ausprobieren neuer Features. Ausser es handelt sich um ein zentrales Feature, an dem viele Entwickler mitarbeiten möchten.

Die letzten Tage waren mal wieder sehr anstrengend. Das Projekt, an dem ich gerade arbeite, läuft eher chaotisch, als denn geordnet ab. Zum einem leidet das Projekt darunter, dass es keinen definierten Projektleiter gibt. Alleine dieser Punkt ist schon ein K.O.-Kriterium. Dazu kommt noch, dass es keine Spezifikationen und weitesgehend keine Dokumentation gibt. Als einzige Vorlage dient ein C-Code, der dank wildester Pointer-Arithmetik und einem prozeduralen Programmierstil alles andere als einfach nachzuvollziehen ist. Dies führte dazu, dass ich wesentliche Teile der Logik reverse-engineeren musste.