Doch auch als SEO gab’s einiges zu lernen in diesem Projekt. So war mir zwar auch vorher schon bewusst, das SEO heute eher Unternehmensberatung als technische Trickserei ist. Trotzdem macht ein monatelanges Projekt in einem der größten Verlage Deutschlands diesen Punkt nochmals ganz deutlich, den leider viele Kunden noch immer nicht verinnerlicht haben. Gerade kleinere Kunden erwarten von einem SEO mehr “Schwarze Google-Magie” als Hilfe zum Bau klar strukturierter und damit erfolgreicher Webprojekte. Die Bauer Digital KG, die lecker.de betreibt, hat Suchmaschinenoptimierung von Anfang als wesentlichen Teil des Projekts begriffen. Damit ist die Website zwar heute noch nicht perfekt optimiert, aber wir sind auf einem guten Weg dorthin.

Der PHP-Blogger Harald Lapp hat nun seine Liebe zu JavaScript erklärt. Zu JavaScript! Wie kann jemand JavaScript, die weiland von Netscape zusammengeschusterte Browser-integrierte Sprache, lieben? Und wie kann diese Liebe erklärt werden mit den Worten: “Ich habe noch keine Programmiersprache kennengelernt, in der es sich ähnlich intuitiv entwickeln lässt.” JavaScript und intuitiv? Das ist wie George W. Bush und UNO, wie CSU und Umweltschutz, wie … – lassen wir das. Doch die Lobpreisung geht noch weiter: “Die Sprache ist absolut logisch aufgebaut.” Ja, in der Tat, die Rede ist noch immer von JavaScript.

Eine derartige Lobeshymne auf JavaScript kann nur ein PHP-gestählter Entwickler verkünden. Klar, wer täglich eine Programmiersprache mit über 5.000 Funktionen im globalen Namensraum bändigen muss, wer array_key_exists() zu tippen hat, wo andere einfach nur x in d schreiben und wer zwar create_function() zur Verfügung hat, diese gefährliche Funktion aber am besten nicht benutzt, dem nehme ich die Liebe zu JavaScript sogar ab. Besser als PHP ist es allemal.

Die Website zum Handbuch: www.website-handbuch.de

Und hier kommt der Werbeblock:
Das Website-Handbuch bei Amazon bestellen.

Das Open Street Map Projekt unternimmt den Versuch, genau das zu ändern. Zigtausende Freiwillige auf der ganzen Welt sind dazu mit GPS-Geräten unterwegs und kartieren die Straßen und Wege in ihrer jeweiligen Heimat oder an ihrem Urlaubsort. All diese einzelnen Daten werden aggregiert und ergeben zum Teil überraschend genaue Daten, die wie in einem Wiki von jedem Nutzer verbessert und korrigiert werden können.

Steve Coast, einer der Gründer des Projekts, weist in seinem Vortrag über Open Street Map darauf hin, dass die freien Karten ähnlich wie Linux als Grundlage für kommerzielle Anwendungen dienen können, was er mit seiner eigenen Firma CloudMade denn auch unter Beweis stellt. Und er zeigt, dass die kommerziellen Karten für die westliche Welt derzeit noch besser sein mögen als die Karten seines Projekts. In anderen Ecken der Erde aber sieht das ganz anders aus; man vergleiche dazu nur die Karten von Teheran des Open Street Map-Projekts mit denen von Google Maps.

Tags: web2expoberlin

Suda vergleicht die Microformats mit dem Konzept der Pipes unter Unix: Einzelne Anwendungen machen genau das, was sie selbst am besten können und reichen ihre Ausgabe an andere Programme weiter. Genau so arbeiten Web Services, die auf Microformats basieren. Konsequent umgesetzt, könnten damit Anwendungen wie ein Addressbook 2.0 realisiert werden, das sich übers Web stets mit den aktuellen Adressdaten versorgt.

Schade, dass der Vortrag etwas kurz und oberflächlich geraten ist, denn Suda hätte definitiv das Wissen und auch das Vortragskönnen, hier deutlich mehr zu bieten.

Tags: web2expoberlin

Beim genaueren Lesen der E-Mail aber überfiel mich ein milder Lachkrampf. 1&1 erklärt, dass sie zum 20. November 2007 die Unterstützung von PHP3 – in Worten: PHP DREI(!) – einstellen werden und man seine Scripte doch auf PHP4 umstellen möge. Sechs Wochen bevor die Weiterentwicklung von PHP4 gestoppt wird, empfiehlt Deutschlands größter Provider seinen Kunden, auf PHP4 umzustellen. Ich verstehe ja, dass Rückwärtskompatibilität für einen Massenprovider essentiell ist, aber dann sollten sie den Kunden doch wenigstens empfehlen, gleich auf PHP5 umzustellen. Auch wenn das erst seit gut drei Jahren verfügbar ist.

Das wirklich Schlimme an der Sache ist aber etwas anderes: Auf meinem 1&1-Server läuft ein Projekt, das ich 2002 gestartet habe und das natürlich in PHP3 programmiert wurde. Ich habe keine Ahnung, wie das Projekt die Umstellung verkraften wird – aber wir haben auch nicht die Zeit, das bis dahin zu ändern, befürchte ich. Also lassen wir uns mal überraschen.

Sein aktueller Artikel geht im Detail auf die Arbeitsphasen und die effiziente Nutzung von Zeit durch Programmierer ein – und auf die Dinge, die einer effizienten Nutzung entgegenstehen können.

Der zentrale Punkt von Grahams Argumentation ist, dass Programmierer, die an einem Projekt arbeiten, den gesamten Code im Kopf haben. Natürlich nicht jede einzelne Zeile, aber das gesamte Code-Layout: Welche Klassen habe ich? Welche Beziehungen haben diese Klassen zueinander? Wo ist welche Funktionalität versteckt? Nur so kann ein Programmierer wirklich gut arbeiten, denn um ein gutes Stück Software zu entwickeln, reicht es nicht, jeweils nur das präsent zu haben, was der Bildschirm gerade anzeigt.

Viele Entwickler scheinen aber genau damit (was der Schirm zeigt) ihre Probleme zu haben. Denn warum wollen sie immer größere Bildschirme haben? Ein Fensterchen hier, ein Fensterchen da – ich habe oft genug den Eindruck, dass für manchen Programmierer der (möglichst große) Bildschirm als Ersatz für seinen Kopf dient. So ganz nach dem alten Kalauer: Was man nicht im Kopf hat, muss man auf dem Bildschirm haben. Aber auch noch so viele Infos, die eine IDE zeigt, ersetzen nicht den Gesamtzusammenhang, der sich im Kopf des Entwicklers befinden und aktiviert sein muss. So wie ja auch einem Computer der Code auf der Festplatte nichts nutzt, sondern erst ins RAM geladen, also aktiviert werden muss.

Dieses Vergegenwärtigen der großen und kleinen Zusammenhänge innerhalb eines Programmierprojekts benötigt Zeit. Offenbar muss unser Gehirn erst in den verschiedenen Langzeitspeichern nachsehen und die jeweils benötigten Infos in unser menschliches RAM laden. Ich erinnere mich, dass mich dieser langwierige Aufbau des Zustands vor etlichen Jahren, als ich mein erstes größeres Software-Projekt anging, regelmäßig in die Nähe des Wahnsinns getrieben hat. Ich konnte nicht verstehen, wieso ich oft genug planlos rumsurfte oder die nutzlosesten Dinge anstellte, anstatt mich voller Elan auf die spannende Arbeit zu stürzen. Erst Jahre später hatte ich mein Aha-Erlebnis, als ich Joel Spolskys Ausführungen dazu las:

Sometimes I just can’t get anything done. Sure, I come into the office, putter around, check my email every ten seconds, read the web, even do a few brainless tasks like paying the American Express bill. But getting back into the flow of writing code just doesn’t happen.

Plötzlich verstand ich, dass es nicht meine Faulheit oder Unfähigkeit war, sondern dass derartiges Verhalten das Normalste der Welt für einen Entwickler ist. Es kann Stunden dauern, bis ich den Zeitpunkt finde, der geeignet ist, diesen komplexen Zustand in meinem Kopf aufzubauen. Bis ich “in the zone” bin, wie Spolsky das formuliert. Sobald ich aber in der “Zone” bin, diesen Zustand der absoluten Konzentration erreicht habe, bin ich auch produktiv für drei, mindestens.

Als ich während des Studiums, zu Zeiten der sich anbahnenden Bubble 1.0, für eine Münchner Webagentur programmierte, verbrachte ich oft den halben Tag damit, mich mit Kollegen zu unterhalten oder rumzusurfen. Manchmal war bereits Nachmittag, bis ich richtig in Fahrt kam. Trotzdem schaffte ich in den sich dann anschließenden wenigen Stunden oft mehr wegzuarbeiten als so mancher Entwickler, der den ganzen Tag stur in seine Kiste starrte. Eine ähnliche Erfahrung hatte ich bereits im Studium gemacht. Etliche Kommilitonen schwörten auf ihre Lerngruppen; ich hingegen hasste diese Kaffeekränzchen mit begleitendem Physikgelaber wie die Pest. Das Ergebnis war, dass ich in wenigen, aber sehr konzentrierten Wochen, mehr lernte, als manche Kumpels über Monate hinweg.

Heute weiß ich: “In der Zone” zu sein, ist das A und O für jeden “Wissensarbeiter”. Und da es so schwierig ist, diesen Zustand zu erreichen, müssen wir alles unternehmen, dass wir möglichst lange darin verharren. Jede noch so kleine Störung kann dabei tödlich sein für unsere “Zone”. Egal ob ein Kunde sich nach dem Stand des Projekts erkundigt oder der Kollege fragt, wohin denn der Locher verschwunden sei – jede Störung wirft den Entwickler aus seiner “Zone”. Noch schlimmer aber sind Störungen, von denen wir wissen, dass sie anstehen: Das für Nachmittag anberaumte Meeting etwa oder, noch schlimmer, der bevorstehende Anruf (von dem man aber nicht weiß, wann genau er kommen wird) verhindern effektiv, dass ich überhaupt diesen Zustand höchster Konzentration erreiche.

Oddly enough, scheduled distractions may be worse than unscheduled ones. If you know you have a meeting in an hour, you don’t even start working on something hard. (Paul Graham)

Gute Programmierer kennen die damit zusammenhängenden Probleme, zumindest instinktiv; bewusst ist es dem einen oder anderen womöglich nicht. Für Nicht-Entwickler aber ist das oftmals vollkommen unverständlich. Wer nie, oder nur sehr selten, in diesem Zustand höchster Konzentration arbeitet, dem leuchtet nicht ein, dass ein fünfminütiges Telefonat nicht einfach fünf Minuten Zeit kostet, sondern dabei unter Umständen Stunden verloren gehen. Umgekehrt ist es fast noch schlimmer. Ein Programmierer, der sich in der “Zone” befindet, vergisst außen rum alles: Essen, Trinken, rechtzeitig Feierabend zu machen oder den wichtigen Kunden zurückzurufen.

Deshalb kann ich mich auch mit den ach so hippen “agilen” Entwicklungsmethoden wie etwa Pair Programming nicht anfreunden. Gut, dass es da auch anderen Leuten so geht. Natürlich sitz auch ich hin und wieder mit einem anderen Programmierer gemeinsam am Bildschirm; dann geht’s aber genau um ein kleines, klar umrissenes Problem, das zu lösen ist. Ansonsten stört die unmittelbare Anwesenheit eines zweiten Entwicklers die notwendige Konzentration. Und nur mit der entsprechenden Konzentration ist es möglich, ein Problem ganz zu verstehen, wie Paul Graham verdeutlich:

it’s only when you have your code in your head that you really understand the problem.

Weiterer Lesestoff, alles auf Englisch:
Joel on Software: Where do These People Get Their (Unoriginal) Ideas?
Joel on Software: Human Task Switches Considered Harmful
Steve Yegge: Good Agile, Bad Agile

Having a nice command line at hand, there should be an easy way to look at an RSS feed, but wget displays just some crap, if I redirect its output to STDOUT. But wait, I forgot to make wget quiet. And really, now it works and it’s a very simple way to look at my RSS feeds:
wget -qO- http://www.fischerlaender.net/feed | less

Update:
There’s even a way to get syntax highlighting! If you’ve installed a reasonably up-to-date version of vi(m), there is a script called less.sh in your $VIMRUNTIME directory, which acts as an replacement of less providing syntax highlighting.

To use this script on Mac OS X Tiger, you just have to follow these simple steps:

• Launch vi and type :echo $VIMRUNTIME. This shows you the path to the
  vi files. On my MacBook this is /usr/share/vim/vim62.
• Now execute sudo ln -s /usr/share/vim/vim62/macros/less.sh /usr/bin/vless. If you’ve
  got another path before, you have to edit this command appropriately.
• That’s all. Now vless acts nearly as less with syntax highlighting.

Of course, vless can also be used within shell pipes:
wget -qO- http://www.fischerlaender.net/feed | vless

Meine erste spontane Idee war, WordPress dafür einzusetzen. WordPress kennen wir bereits recht gut, auch für SuchmaschinenTricks haben wir ja WordPress als Mini-CMS missbraucht. Doch andererseits enthält die Firmenwebsite ja nicht viele Seiten, wenn ich richtig gezählt habe sind es genau sieben.

Also beschloss ich, ein schon von einer anderen Site vorhandenes Layout zu nehmen und es einfach für die certo GmbH anzupassen. Und dabei habe ich mir jegliche Spielereien mit PHP verkniffen, dafür reines pures HTML – genauer: XHTML 1.0 Strict – benutzt. Innerhalb kürzester Zeit war die Website so überarbeitet. Dass ich anno 2007 eine Website komplett statisch erstellen würde, hätte ich mir vor ein paar Jahren nicht träumen lassen. Aber man muss ja nicht immer mit CMS-Kanonen auf Siebenseitige-Website-Spatzen zielen.

PS: Wir suchen eine(n)n Webentwickler(in) in Osterhofen, Niederbayern.