Irgendwie ist man als Programmierer ja so einer Art Universalgelehrter. Neben dem eigentlich Job ist man auch noch Coach, Berater, Verkäufer und natürlich auch Designer. Des öfteren werd ich aufgefordert mal schnell einen Prototypen einer Webseite zu machen. "Muss nicht toll aus sehen" heisst es dann gerne, aber ein professionelles Look and Feel wird natürlich trotzdem erwartet.
Bisher habe ich dann immer angefangen Sachen aus alten Projekten zusammenzukopieren oder versucht auf die schnelle was zusammenstellen, mit meist mäßigem Erfolg, da die Browser Default Styles meist nicht dem enstrechem was ich mir so wünsche. Das Problem scheinen andere auch gehabt zu haben und haben daraus eine Art Basic Styles für Beginners gemacht: Blueprint. (Hat übrigens nichts mit dem gleichnamigen Hit von den Rainbirds zu tun).
Blueprint selbst ist ein Framework das den Entwicklungsaufwand für CSS reduziert. Es liefert sinnvolle Default Stylesheets, Schriften, ein Basis Layout Raster und sogar eine Druckvorlage.
Februar 2009 Archive
Kürzlich bin ich auf das Blog von Steve McLeod gestoßen, der aus seiner Projekterfahrung ein ganz paar gute Tipps für (Java) Programmierer gesammelt hat.
Die meisten seiner Tipps möchte ich eigentlich jedem Programmierer an Herz legen. Einige Dinge sind sicherlich sehr speziell aber meine persönlichen Favortine sind:
- Vorsicht mit Reflection - Das ist ein mächtiges Werkzeug aber man kann auch viel falsch machen
- Versuche Klassen Immutable (unveränderlich zu machen) - Das führt zu einfachem Code und fast immer guter Performance
- Schau immer erst in den Standard Bibliotheken - Die Java Bibliotheken aus dem JDK oder auch von Apache Commons bieten viele Funktionalität, die man in der selben Qualität einfach nicht selber schreiben kann
- Programmierer Defensiv - Es gibt aus meiner Sicht keine Echte Alternative zur defensiven Programmierung, besonders bei Projekt Code
- Schreibe lesbaren Code - Kurze Methoden, kleine Klassen und lesbare if Statements sind der Schlüssel zu wartbarem Code
- Performance liegt (fast) immer an der Datenbank - Kann ich komplett bestätigen, schlechte SQL Statement, fragmentierte Tabellen. Es gibt immer mal wieder schlechten Java Code, aber wenn es zu langsam ist, liegt es an der Datenbank.
Seit heute habe ich das erste mal Software mit einem "nightly build", also einem komplett automatischen Kompilier, Test- und Installationsprozess. Mein build System besteht jetzt aus einem Hudson server der ein Maven Script ansteuert. Dieses lädt alle Sourcen aus dem SCM, führt alle test aus und installiert es auf dem lokalen Software Artifakt Server.
So langsam greifen die unter dem Hype Namen Web 2.0 bekannt gewordenen Features immer mehr auch auf Business Sites über. Fast jeder möchte heute type ahead und all die anderen coolen Funktionen Nutzen die er aus dem privaten Umfeld kennt. Uns Programmierer stellt das natürlich vor ganz neue Aufgaben, das schöne Request - Response Leben ist vorbei und man kann nich mal mehr sagen was denn überhaupt noch zu der Seite gehört (Stichwort Mashups).
Aber auch ein ganz alter Bekannter kehrt wieder zurück, das Problem der Bandbreite. Nicht nur sind 500 kByte JavaScript auf einer Seite keine Seltenheit mehr, sondern es wird auch oft noch auf jeden Tastendruck mit einer Ajax Query geantwortet. Das führt selbst bei modernen Rechnern und guter Infrastrutkur oft zu ein zähen Gefühl. Die Benutzer sind unzufrieden und verlassen den eigenen Auftritt frustriert. Um das Problem zu vermeiden, habe ich einen ganz netten Artikel im Web gefunden, wie man denn dynamischen (!) Bandbreitenbedarf seiner Seite analysiert und dem Benutzer den Eindruck einer schnellen Seite vermittelt.
Ich schreibe hier bewußt "Eindruck", denn die gefühlte Geschwindigkeit und die tatsächliche Geschwindigkeit können sich bei dynamischen Seiten erheblich unterscheiden.
