partyguide
Originally uploaded by emeidi.

Von einem versierten Kollegen (Codename: EMC) habe ich gerade folgende URL zugeschickt erhalten:

Google-Suche

Test- und Produktivsystem

Googles Cache liefert manchmal Kompromittierendes zutage *händereib* Die PHP-Warnings lassen erkennen, dass anscheinend bei den Bastlern von Partyguide gar nicht so selten ungetesteter Code auf das Produktivsystem gelangt. Mir wäre so etwas mehr als peinlich … Vor allem, wenn da täglich tausende Besucher vorbeischauen.

Wie wäre es, wenn die Partyguide-Entwickler Test- und Produktivsystem trennen würden? Jungs, ich wäre für eine weitere Gönner-Aktion.

Welche Dateiendung hätten’s denn gerne?

Wer sich gezielt achtet, erkennt die kreative Vielfalt, die auf den Partyguide-Server herrscht: Manchmal enden PHP-Scripts auf .php, manchmal dann doch lieber .php3 – und weil’s zu Dritt am Schönsten ist darf auch das totgeglaubte .phtml nicht fehlen.

Auch für diesen Tipp danke ich für den Hinweis meines Informanten.

Fazit

Partyguide – weiter so! Eine Due Diligence-Prüfung eurer Technik würdet ihr wohl aber nicht überstehen … Schade! Aber ihr habt Wichtigeres zu tun, stimmts?

In meinem ersten Teil der hier vorliegenden Serie, die sich an fortgeschrittene Web-Developers richtet, habe ich bereits einige fundamentale Fehler aufgezeigt, die auf Partyguide anzutreffen sind. Diese Kritik liesse sich ohne weiteres auf viele andere Web-Projekte übertragen – auch Sites von mir, die mehrere Jahre auf dem Buckel haben, könnten an der einen oder anderen „Krankheit“ leiden. Ich versuche aber, ständig an meinem Code zu feilen und ihn zu verbessern. Deshalb sind die meisten Sites, die ich dieses Jahr für Kunden erstellt habe, denn auch mit Hilfe von CSS2 realisiert. Das altgewohnte „Tabellendesign“ konnte ich so erfolgreich in Pension schicken.

Den vorigen Artikel habe ich auch an die Verantwortlichen geschickt, wurde aber mit meinem Votum aber nicht ganz ernst genommen:

Was clientsite programming anbelangt… Ist 2. Priorität. Erste Priorität ist, dass die SQL Statements/Serverkonfigurationen so sind wie sie sollten.

Aber vielleicht bist du ja noch zu unerfahren um irgendwie was über „prioritäten“ zu wissen ;-)

Quelle: Mail von Philippe Knaus vom 28. Dezember 2005

„If it ain’t broken, don’t fix it“ oder schärfer ausgedrückt: „Es läuft ja, wo ist das Problem?“. Der Unterschied zwischen laufen und performant laufen kann aber gross sein. Meine These lautet deshalb: Bei Partyguide werden unnötigerweise Ressourcen verschwendet, weil man lieber neue Features einbaut, anstelle den bestehenden Code zu optimieren (Flickr.com, mein momentaner Star am Web-Himmel kriegt beides unter den Hut – dort sitzen aber auch Profis dahinter).

Übrigens: Wikipedia vermeldet zum Thema ‚Optimieren‘ treffenderweise:

In computing, optimization is the process of modifying a system to improve its efficiency.

Quelle: Optimization (computer science)

Im zweiten „Hands-on-Partyguide“-Teil habe ich wieder zwei Don’ts gefunden, die als gutes Lehrstück herhalten.

On-The-Fly Kuchendiagramm

Im Laufe der Zeit hat PHP gelernt, bei der Erstellung von Grafiken behilflich zu sein. Partyguide nutzt dies aus, um ein Kuchendiagramm zu generieren (s. rechts). Benutzer mit einem Profil sehen auf diese Weise sofort, wieviele Bewertungen („Wow“, „Herzig“, „Nicht mein Typ“) sie (relativ) erhalten haben.

Das Generieren von Grafiken ist speicher- und CPU-intensiv. Während ich das letzte Mal den Fokus eher auf Traffic-Verminderung gelegt habe, geht es in diesem Abschnitt darum, den Performance-Hunger von PHP-Scripts zu mildern.

Das Kuchendiagramm wird bei jedem Aufruf des Profils einer Person angezeigt. Dazu werden die von anderen Benutzern erhaltenen Bewertungen aus der Datenbank gelesen, aggregiert und an ein PHP-Script weitergegeben, das aus den übergebenen Daten ein Kuchendiagramm hervorzaubert:

<img  src="user_details_diagramm.php?
rate1=21.276595744681&
rate2=125.95744680851&
rate3=212.76595744681"
width="100" height="100" border="0" align="left">

Int oder Float?

Auf den ersten Blick fällt dem geübten Auge auf, dass die Zahlen recht lang daherkommen. Muss das so sein? Nein. Denn schliesslich benötigt ein Kuchendiagramm keine Präzision auf über 10 Nachommastellen genau. Optimal wäre es, wenn das Script, dass die URL generiert, die Zahlen gleich in Prozente umwandeln würde. Dann würden sage und schreibe NULL Nachkommastellen reichen, um eine Grafik herzuzaubern.

Übrigens – die URL kann man ohne weiteres in eigene Projekte einbinden und so Kuchendiagramme nach eigenem Gusto anzeigen. Ob dies viel bringt, ist eine andere Frage … Ich jedenfalls stelle das obige Bild genauso dar – ich binde es direkt vom Partyguide-Server ein. Mal schauen, wie lange es geht, bis die Entwickler einen Referer-Filter einbauen *smile*

Statisch oder Dynamisch?

Abgesehen von zu langen Fliesskommazahlen stellt sich mir die viel brennendere Frage, ob man diese Kuchendiagramme wirklich bei jedem Aufruf dynamisch generieren sollte? Wäre es performance-mässig nicht deutlich intelligenter, auf eine statische Grafik zu verweisen?

Dies ist ohne weiteres machbar – und würde den Web-Server entlasten. Anstelle ein PHP-Script aufzurufen, dies durch den PHP-Parser zu jagen, die GDlib (oder was für eine Grafik-Bibliothek auch immer bei Partyguide im Einsatz steht) zu starten, das Bild zusammenzusetzen und die Binärdaten zum Client zu senden würde es ausreichen, wenn Apache ein im Filesystem liegendes GIF oder PNG an den Browser zurückzusenden.

In – sagen wir – 80% der Fälle ist es nämlich gar nicht nötig, das Bild neu zu berechnen, weil das Profil keine neuen Bewertungen erhalten hat. Zudem verändern sich die Diagramme von Accounts mit sehr vielen Bewertungen auch weniger rasch – wenn zu 1000 Bewertungen eine weitere dazu kommt, bedeutet dies Änderungen im Promillebereich, die bei einer derart kleinen Grafik kaum zu erkennen wäre.

Ich würde deshalb ein PHP-Script schreiben, dass ausschliesslich beim Eingehen einer neuen Bewertung aktiv wird. Das Script würde durch eine User-Interaktion („Bewertung“) angestossen und würde das bestehende, statische GIF, das mit der User-ID irgendwo Filesystem des Servers liegt, löschen und sofort darauf ein neues Bild aus den neuen Daten generieren. Apache würde es einem danken.

GET-Variablen

Bei weiteren „Untersuchungen“ am HTML-Code ist mir zudem noch etwas aufgefallen. Die Entwickler scheinen keiner konsequenten Linie zu folgen, wie GET-Variablen benannt werden. Für mich ist eine konsequente Durchsetzung von Namenskonventionen das A und O des Programmierens. Wer dies als lästige Erfindung von Klugscheissern empfindet, sollte sich einen anderen Job suchen. Insbesondere gerade wenn man im Team an einem Projekt arbeitet, sind solche Konventionen unbedingt notwendig:

URL, um das Profil eines Users anzuzeigen:

http://www.partyguide.ch/user_details.php?my_pic_member_id=30689

Andererseits verwendet man innerhalb dieser Rubrik dann etwas völlig anderes:

URL, um hochgeladene Bilder eines Profiles anzuzeigen:

http://www.partyguide.ch/user_details_fotos.php?username=mad4you

Fürchterlich! Einerseits heissen die GET-Variable unterschiedlich, bezeichnen aber schlussendlich denselben user, andererseits scheint man sich bei Partyguide auch nicht im Klaren zu sein, ob man nun jetzt mit dem Usernamen arbeiten will (der törichterweise Umlaute und Sonderzeichen enthalten kann), oder doch der eindeutigen User-ID, die wohl dem Inhalt einer Tabellenspalte entspricht.

Verräterische Cookies

Dieser Punkt hier hat für Partyguide überhaupt keine Auswirkung auf Bandbreite oder Performance der Server. Erwähnenswert ist er aber allemal.

Die Entwickler von Partyguide haben nämlich wieder einmal einen Tritt ins Fettnäpfchen gewagt und zeigen, dass sie sicherheitstechnisch kaum auf dem Laufenden sind. Ich frage mich gar, ob man überhaupt sensibilisiert ist? Wohl kaum …

Jedenfalls haben die Vollprofis dort entschieden, dass das Account-Passwort der Benutzer im Klartext auf der Festplatte der Anwender gespeichert wird (geniales Hilfsmittel: Cocoa Cookies 0.7):

.partyguide.ch        sess_psw        /        ********

Dies geschieht dann, wenn der User ‚Autologin‘ angewählt hat und sich so nicht bei jedem Besuch mit seinen Zugangsdaten authentifizieren muss. Man kann einwenden, dass dies auf Privat-Computern keine grosse Rolle spielt – doch mir ist es nicht wohl, wenn eines meiner Passwörter in Text-Dateien auf dem Computer herumliegt und nur darauf wartet, von einem Trojaner etc. ausgelesen zu werden. (Ich habe einen Mac, weshalb ich mir deutlich weniger Sorgen machen muss als Windows-Anwender).

Auch wenn man die Autologin-Funktion nicht verwendet, steht man mit heruntergelassenen Hosen da. Denn ist man einmal eingeloggt, wird das Passwort bei jedem Request an .partyguide.ch mitgesendet. Das schreit förmlich nach einer fiesen Hacker-Attacke, um das Passwort im Klartext abzufangen. Mittel und Wege dazu gibt es allemal – kommt das HTTP-Paket bei einem Menschen mit bösen Absichten vorbei, ist es passiert.

Vielleicht sollte sich die Verantwortlichen doch überlegen, zumindest einen MD5-Hash des Passwortes zu generieren und diesen auf den Rechnern der Anwender als Cookie zu hinterlegen. So ist immerhin die Gefahr gebannt, dass Profis mit einem Blick erkennen, wie das Passwort im Klartext lautet. Dass damit aber der Missbrauch nicht ausgeschlossen ist, bleibt klar – da man den Hash vorliegen hat, kann man sich auch in Zukunft frischfröhlich anmelden.

Weitere Beispiele folgen garantiert – to be continued …

Bereits in mehreren Blog-Beiträgen (anschliessend hier) habe ich mich über die Amateurhaftigkeit von Partyguide aufgeregt. Da Kritik aber selten etwas bringt, möchte ich in dieser neu gestarteten Serie in unregelmässigen Abständen anhand der Architektur von Partyguide die gröbsten Schnitzer aufzeigen, die Internet-Frickler begehen, wenn man ihnen die nötigen Werkzeuge in die Hand drückt.

Heute ziehe ich hierzu die Seite ‚Personen suchen‘ unter ‚FlirtCity‘ heran. FlirtCity ist die kostenlose Variante von Partnerwinner, auf jüngeres Publikum gemünzt.

Notabene: Hinter gutaussehenden Frauen, die dort nach „Abenteuer“ suchen, stecken mit allergrösster Wahrscheinlichkeit pubertierende Jünglinge, die sich mit Model-Fotos aus dem Internet einen Spass erlauben. Gemäss dem Motto: „On the Internet, nobody knows you’re a dog.“

Standards, Standards, Standards

Kaum hat man den HTML-Quelltext geöffnet, sträuben sich bei mir bereits die Haare:

<script language="JavaScript">
...
</script>

<html>
...
</html>

NEIN! Web-Sites eröffnet man mit dem <html>-Tag. Dass JavaScript-Elemente vor <html> eingebunden werden, zeugt von Stümperhaftigkeit und Unkenntnis geltender Standards. Vor dem <html>-Tag steht höchstens ein

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">

Transfervolumen schonen

Aufrufe auf Partyguide zeigen, dass die „Macher“ Probleme haben, die Infrastruktur (Hardware: Server) resp. den Traffic (Software: Datenfluss) zu finanzieren. Dies ist nicht verwunderlich, denn der Hauptbestandteil von Partyguide sind die unzähligen Bilder, die an Parties in der ganzen Schweiz geschossen wurden und nun dem Publikum zur Schau gestellt werden. Das Problem ist hier einfach, dass Bilder ein Vielfaches grösser sind als normale Text-Seiten. Und leider kostet im Internet heute – vereinfacht gesagt – nur noch die übertragene Datenmenge. Während Partyguide ein Bild überträgt, kann bspw. eine News-Site ihre Artikel für dieselben Kosten – sagen wir – zehnmal übertragen. Ziel müsste es also für das Team hinter Partyguide sein, den Datenfluss so effizient wie möglich zu auszunutzen – und klein zu halten. Kein Byte sollte zuviel übertragen werden, denn bei Tausenden von täglichen Besuchern summieren sich solche „Kleinigkeiten“ zu vielen Megabytes an verschwendetem Traffic an.

Zwei Beispiele, wieso Partyguide hier noch viel zu lernen hat:

Von Benutzern hochgeladene Bilder

Benutzer von Partyguide haben ein eigenes Profil. Dort kann man Angaben über die eigene Person publizieren (Alter, Wohnort, Lieblings-Clubs etc.) und unter anderem auch persönliche Bilder hochladen.

Desöfteren fallen mir bei der Anzeige der persönlichen Bilder aber lange Verzögerungen auf. Ein Blick auf die übertragenen Grafikdateien zeigt dann meistens dieselbe Ursache: Anstatt platzsparende JPEG-Dateien zu übertragen, kommen dann und wann BMPs daher. Notabene mit der Endung .jpg, was eine aktive Täuschung jedes Browsers darstellt – die meisten Browser stören sich aber an der falschen Endung nicht – anscheinend ist die falsche Erweiterung immer noch ein weit grassierendes Problem im Netz. Jeder halbwegs Sachverständige weiss aber, dass BMP keine Komprimierung aufweist und verlustfreie Bilder beinhaltet. Deshalb sind die Bilder teilweise um den Faktor 10 grösser als dasselbe, komprimierte Sujet im JPEG-Format.

Wer ist der Schuldige? Zuerst einmal die unzähligen unbedarften Windows-User, die BMP-Dateien auf Partyguide hochladen. Doch ihnen kann man nicht viel vorhalten – die wenigsten Benutzer kennen Unterschiede der einzelnen Grafik-Formate. Sie sind Endanwender, die sich um solchen „Käse“ nicht kümmern möchten.

Würden bei Partyguide fähige PHP-Entwickler arbeiten, würden spätestens aber diese solchen Unfug abfangen und die empfangenen Bilddateien nach dem Upload in das JPEG-Format umkodieren. Machen sie aber nicht. Und „bezahlen“ bei jedem Aufruf einer BMP-Bilddatei mit verschwendetem Transfervolumen.

Nachtrag: Am 29. September habe ich die Entwickler von Partyguide auf das Problem aufmerksam gemacht. Die läppische Antwort:

werden sie auch [Umkonvertierung von BMP-Dateien]. es kommt jedoch vereinzelt vor, dass die bilder nicht konvertiert werden können, oft wenn die datei zu gross ist…

Ein Kommentar erübrigt sich wohl …

Sich wiederholenden HTML-Code vereinfachen

Auch HTML-Code kann in den Händen von unbedarften, amoklaufenden Entwicklern zu Bloatware verkommen. Ein gutes Beispiel stellt die Seite dar, die Suchresultate nach FlirtCity-Inserenten darstellt. Dort werden alle Benutzer aufgelistet, die den Suchkriterien entsprechen. Eine Tabellenzeile sieht folgendermassen aus:

<tr bordercolor="#000000" valign="middle">
  <td bgcolor="#D5EAF4" height="25" class="text_klein" width="180"><A HREF="../user_details.php?my_pic_member_id=157382" onClick="NewWindow(this.href,'name','775','650','yes');return false">Croatia_Lady                        </td>
  <td bgcolor="#D5EAF4" height="25" class="text_klein" width="25"><IMG onmouseover="return overlib('<center><img src=http://images.partyguide.ch//memberfotos_thumbs/157382.jpg></center>', CAPTION, 'Foto');" onmouseout="return nd();" SRC="http://partyguide.ch/img/foto.gif" BORDER=0>  </td>
  <td bgcolor="#D5EAF4" height="25" class="text_klein" width="25">18 </td>
  <td bgcolor="#D5EAF4" height="25" class="text_klein" width="160">Steffisburg </td>
  <td bgcolor="#D5EAF4" height="25" align="left" class="text_klein" width="25"><IMG SRC="../img/wappen_be.gif"> </td>
  <td bgcolor="#D5EAF4" height="25" align="left" class="text_klein" width="30"><IMG SRC="../img/ch.gif"> </td>
  <td bgcolor="#D5EAF4" height="25" align="right" class="text_klein" width="130">25.12.2005 21:48:00 </td>
  <td bgcolor="#D5EAF4" height="25" align="right" class="text_klein" width="30"><A HREF="../user_details.php?my_pic_member_id=157382" onClick="NewWindow(this.href,'name','775','650','yes');return false"><IMG SRC="../img/info.gif"  BORDER=0></A> </td>
</tr>
<tr bordercolor="#000000" valign="middle">
  <td bgcolor="#FFFFFF" height="25" class="text_klein" width="180"><A HREF="../user_details.php?my_pic_member_id=52676" onClick="NewWindow(this.href,'name','775','650','yes');return false">Nini86                        </td>
  <td bgcolor="#FFFFFF" height="25" class="text_klein" width="25"><IMG onmouseover="return overlib('<center><img src=http://images.partyguide.ch//memberfotos_thumbs/52676.jpg></center>', CAPTION, 'Foto');" onmouseout="return nd();" SRC="http://partyguide.ch/img/foto.gif" BORDER=0>  </td>
  <td bgcolor="#FFFFFF" height="25" class="text_klein" width="25">19 </td>
  <td bgcolor="#FFFFFF" height="25" class="text_klein" width="160">Schliern </td>
  <td bgcolor="#FFFFFF" height="25" align="left" class="text_klein" width="25"><IMG SRC="../img/wappen_be.gif"> </td>
  <td bgcolor="#FFFFFF" height="25" align="left" class="text_klein" width="30"><IMG SRC="../img/ch.gif"> </td>
  <td bgcolor="#FFFFFF" height="25" align="right" class="text_klein" width="130">25.12.2005 20:00:00 </td>
  <td bgcolor="#FFFFFF" height="25" align="right" class="text_klein" width="30"><A HREF="../user_details.php?my_pic_member_id=52676" onClick="NewWindow(this.href,'name','775','650','yes');return false"><IMG SRC="../img/info.gif"  BORDER=0></A> </td>
</tr>

Je nach zurückgelieferten Resultaten wiederholt sich dieser HTML-Block dutzende, ja manchmal hunderte Male.

Schlichtwegs eine Katastrophe! Vielleicht mag man in den späten Neunzigern solchen Code als vorbildlich eingestuft haben – im 2005 ist er es garantiert nicht mehr.

Fehler 1 – Sich wiederholender Code

Jede Tabellenzelle erhält eine Hintergrundfarbe zugewiesen. Jede Zeile soll alternierende Farben aufweisen, um die Lesbarkeit der Resultate zu verbessern. Die Idee dahinter ist löblich – die Umsetzung unter aller Sau. Jeder Tabellenzelle wird auch explizit eine Höhe zugewiesen (height). Manchmal findet man auch das Attribut align, das die Ausrichtung des Textes innerhalb einer Zelle steuer. Und zu guter letzt wird auch fast jeder Zelle noch eine CSS-Klasse zugewiesen.

Die von mir vorgeschlagene Lösung sieht viel einfacher aus – gemäss meinem Credo „Keep it simple^TM„:

Zuerst einmal kreiert man ein CSS-File und bindet dieses per Include in jede Seite ein. Deren Inhalt (auszugsweise):

table.tblListing              {}
table.tblListing tr td        {background-color:#FFFFFF;height:25px;font-size:10px;padding:4px;}
table.tblListing tr.trOdd td  {background-color:#D5EAF4;}

Der korrespondierende HTML-Code für die Tabelle sähe folgendermassen aus:

<table>
<colgroup>
 <col width="180" />
 <col width="25" />
 <col width="25" />
 <col width="160" />
 <col width="25" />
 <col width="30" />
 <col width="130" />
 <col width="30" />
</colgroup>
<tr class="trOdd">
 <td>...</td>
 <td>...</td>
 <td>...</td>
 <td>...</td>
 <td align="right">...</td>
 <td>...</td>
 <td>...</td>
 <td align="right">...</td>
</tr>
<tr>
 <td>...</td>
 <td>...</td>
 <td>...</td>
 <td>...</td>
 <td align="right">...</td>
 <td>...</td>
 <td>...</td>
 <td align="right">...</td>
</tr>
</table>

Fazit: Unmengen an unnötigen Zeichen werden durch einfachste Hilfsmittel wie intelligenteren HTML-Formulierungen und Cascading Stylesheets (CSS) eingespart. Man beachte auch den colgroup-Block zu Beginn der Tabelle. Heutzutage ist es wirklich nicht mehr nötig, die Spaltenbreite in jeder Zeile neu zu definieren. A propos: Wieso hat die Tabelle eine fixe Breite?

Fehler 2 – URIs

Der Inhalt der Zellen weist auch einige Links und Verweise auf Grafikdateien auf. Auch hier könnte man mit intelligenter Strukturierung der Datenablage Doppelläufigkeiten vermeiden. Wieso Bilder mit

<IMG SRC="../img/wappen_be.gif">

eingebunden werden, ist mir schleierhaft. Ich würde immer absolut addressieren und nur dort, wo dies definitiv nicht möglich ist, davon abweichen. So könnte man sich die .. sparen. Hochgerechnet mit Anzahl Zeilen mal Anzahl Besuche mal 8 (ergibt Bytes) sollte für einen Tag dann doch eine stattliche Summe an eingesparter Datenmenge ergeben.

Fehler 3 – JavaScript-Funktionsnamen

Programmierer sollten wenn möglich aussagekräftige Namen für ihre Funktionen verwenden. Auf den ersten Blick ist dies bei

<A HREF="../user_details.php?my_pic_member_id=52676" onClick="NewWindow(this.href,'name','775','650','yes');return false"><IMG SRC="../img/info.gif"  BORDER=0></A>

gut gelöst. Ich sehe auf den ersten Blick, dass hier also ein neues Fenster geöffnet werden soll. Doch vergegenwärtigt man sich, dass diese Funktion in jeder Zeile der Resultate auftaucht, wird es mir übel. Ich würde in einem solchen Fall dann doch auf die Lesbarkeit verzichten und die Funktion zusammenschmelzen:

<a href="#" onclick="win(52676)">...</a>

Die JavaScript-Funktion würde also die redundanten Angaben in der Funktion selber beeinhalten, anstatt all die identischen Angaben in jeder Zeile zu wiederholen:

function win(intUserId) {
 var intWinWidth = 775;
 var intWinHeight = 650;
 var strURL = '/user_details.php?my_pic_member_id=' + intUserId;
 
 window.open(strURL,intWinWidth,intWinHeight,...);
 return false;
}

Fazit

Da ist noch viel zu tun! Ich bleibe dran und bin mir ganz sicher, auch in den nächsten Folgen dieser Serie viele weitere Leckerbissen präsentiert werden können.

Party-Essentials II: Gloves
Originally uploaded by emeidi.
Quelle: Partyguide

Nachdem ich im ersten Teil dieser mehrteiligen Serie bereits auf mitgebrachte iPods bei Partygängern verwiesen habe, darf der am Heilig Abend entdeckte Trend nicht fehlen: Handschuhe. Plant er noch einen Einbruch? Oder an die obligate Schlägerei nach Feierabend? Wir wissen es nicht … Auf jeden Fall ist ein solch vorsichtiges Verhaltenen der heutigen Zeitgenossen genügend zu würdigen. Ich empfehle für den Weihnachtsabend noch einen Velohelm zur Komplettierung der Ausrüstung.

PS: Wird wohl wie Indianer-Winterschuhe für die Damen und dem Wiederaufstieg der VoKuHiLa-Frisur unter Secondos einfach ein weiterer aus Mailand importierter Trend sein …

Partyguide Sucks
Originally uploaded by emeidi.

Letzte Woche (am 29. November) war es (wieder einmal?) soweit: Die Entwickler (ist die Mehrzahl überhaupt korrekt?) hinter Partyguide.ch zeigten sich von ihrer besten Seite.

Dies bestärkte mich im bereits vorher geäusserten Verdacht, dass hier weniger erfahrene PHP-Entwickler als Abkömmlinge des Mr. Bricolage am Werk sind.

Immerhin: Das Verbesserungspotential der Web-Site (HTML-Code, Performance-Tuning bei PHP und MySQL) bleibt so ungewollt enorm.

Anstelle also meterlange Titel wie …

Regionalmanager Zürich Assistent

Quelle: dilorenzo

zu vergeben, sollte man in die Ausbildung von PHP-Cracks investieren.

Denn: Die Idee der Site und die User-Basis wären im Grund genial …

Heute gab es ein Vierteljahrhundert Mario zu feiern – im realen Leben, selbstverständlich (inkl. Geburtstagsständchen, vorgetragen von vier professionel musizierenden Verwandten *grins*), aber auch im virtuellen! Meine Mailbox quoll … gut, das wäre jetzt übertrieben, meine Mailbox füllte sich im Laufe des Tages mit einigen Mails. Keine persönlich verfassten Gratulationsmails aus aller Welt, sondern maschinell von Computern generierte Standardmails.

Erst beim überfliegen all der zugesandten Mails merkt man, wo man alles seine persönlichsten Daten hinterlassen hat. Unheimlich:

• unbekannt: MacUser.de
• 1:15 Uhr: Citydisc mit einem 10% Rabatt-Coupon – keine Erwähnung des Geburtstages, notabene
• 3:00 Uhr: Mr. Lens mit einem 5 Franken-Gutschein
• 6:16 Uhr: Partyguide.ch
• 11:22 Uhr: Orange

Reminder

Aber auch sonst erfreuen sich die elektronischen Kommunikationsmittel grosser Beliebtheit. SMS und E-Mail sind heutzutage die Gratulationsmittel erster Wahl. Und damit niemand die Geburtstage der anderen mehr vergisst, gibt es einige Hilfsmittel, die von findigen Programmierer erfunden wurden. Partyguide ist in der Hinsicht sehr nützlich – informiert es doch alle ‚myfriends‘ eines Users über dessen Geburtstag.

Ausserdem: Zum ersten Mal, seit ich mich erinnern kann, ist es dank Partyguide auch auf einfachste Art und Weise möglich, herauszufinden, wer denn heute auch noch Geburtstag hat. Sehr lustig – es gab am 25. September eine ganze Menge Partyguide-User, die wie ich etwas zu feiern hatten. Nicht schlecht staunte ich, als mir eine wildfremde Person gratulierte und darauf hinwies, dass sie satte 10 Jahre jünger sei als ich (Jahrgang 1990!). Himmel, ich bin wirklich ein alter Knochen!

Software-Tipp

Heute morgen riss ich mich zusammen und machte mich auch auf die Suche nach einem Tool, dass die Geburtstage aus dem Apple Address Book mit Apple iCal synchronisiert. Denn dummerweise sind die Apple-Entwickler anscheinend derartige Geeks, dass sie wohl keine Freunde haben und somit auch nie deren Geburtstage vergessen (diese Synergie wurde glücklicherweise mit Mac OS X Tiger ausgebügelt – die Geburtstage synchronisieren sich jetzt automatisch). Wer aber wie ich mit Mac OS X Panther unterwegs ist, sollte sich unbedingt BirthdayCal reinziehen. Eines der nützlichsten Tools der letzten Wochen und Monaten. Man merkt, dass der Programmierer genau wusste, was wir, die Anwender, uns von einer solcher Applikation wünschen.

Out of Africa

Sehr gefreut habe ich mich heute über das Telefonat von Melanie. Direkt aus dem „Busch“, sozusagen. Die Leitungsqualität wär nicht optimal, aber man konnte sich verständigen. Der Weg ist das Ziel, wie man so schön sagt. Es war sehr schön, ihre Stimme wieder einmal zu hören – gleichzeitig machte es mich aber auch traurig, dass wir den Geburtstag für einmal nicht zusammen feiern konnten. Ich denke, dass es ihr ähnlich ging … *snüff* Irgendwie vermisse ich sie, bereits jetzt, in Woche 3.

Obwohl ich bekennender Benutzer von Partyguide.ch bin – überzeugen konnte mich das Produkt technisch und teilweise auch konzeptionell noch nie.

Partyguide gehört wohl neben Tilllate.ch (Kollege Wittwers Anti-Projekt kommt wohl hoffentlich bald – kreativ ist die Namensgebung auf jeden Fall) und Lautundspitz.ch zu den Top-3 der „Seht-her-ich-war-auch-an-dieser-Hundsverlochete“-Sites, die Photos von Parties zur Schau stellen. Dazu schwärmt mittlerweile die halbe Nation in Form von Hobby-Fotografen mit ihren Hobby-Kameras aus (na gut, einige haben wirklich gute Dinger mit obligatorischem Profi-Blitz dabei – wie die Nikon D70) und hüllt die Location ins Blitzlichtgewitter schlechthin. Dass die Gratis-Eintritte dazu einen grossen Anreiz darstellen, ist nur ein positiver Aspekt – mit einer Kamera in der Hand und etwas aufgelockert durch die promillehaltigen Getränke kommt man hierzulande eben doch noch vorzüglich mit dem anderen Geschlecht in Kontakt. Und noch etwas fällt auf: Insbesondere aufgetakelte Frauen sind mittlerweile derart konditioniert, dass man nur noch die Kamera zu zücken braucht, und man schmeisst sich in Pose :-)

Doch was stört mich nun an Partyguide?

Zu viele Fotos

Partyguide titelt heute Montag, 15. August 2005:

PartyGuide.ch liefert über 10’000 Bilder der Streetparade 2005

Bei der quantitativen Auswertung kriegen die Jungs um den Member und Gründer mit der Partyguide-ID ‚1‘, Jason (Mitgliedschaft zwingend) bzw. für alle anderen: Photos (frei zugänglich dank einem netten eMeidi.com-Script), eine glatte 6.

Die Frage nach der Qualität der Bilder stellt sich aber leider sehr oft – niemals sind es die 10’000 Bilder auch wert, angeschaut zu werden.

Auch wage ich hiermit die These aufzustellen, dass …

Party-Bilder-Sites die Produktivität der vor allem jüngeren Angestellten und Azubis stark zu mindern vermögen. Betroffen davon ist insbesondere die Dienstleistungsbranche (Versicherungen, Banken, Verwaltung, Administration), da die Leute dort in der Regel über einen Internet-Zugang am Arbeitsplatz verfügen und – wichtig! – anscheinend auch massenhaft Zeit, sich solche Angebote während der Arbeit „reinzuziehen“.

Unwissenschaftlich wie ich bin, grenze ich das oben grob definierte Zielpublikum noch genauer ein: Schickimicki-KV-Tussen und deren metrosexuellen Gegenparts, die auffällig häufig im Bankensektor (Credit Suisse & Co.) arbeiten.

Von wo ich diese Infos habe? Per Zufall stiess ich vor einigen Jahren auf die Zugriffs-Statistik von Tilllate.ch – sie war anscheinend für alle Welt offen wie ein Scheunentor. Nur die URL musste man kennen, und schon konnte sich der interessierte Surfer ein sehr schönes Bild über die Zugriffe machen. Ein vorteilhaftes Feature der eingesetzten Statistik-Software Webalizer ist es, die Herkunft der Besucher aufzuschlüsseln. An der Spitze standen mit grossem Abstand der Proxy-Server von Credit Suisse (www-gw*.credit-suisse.com), Winterthur (wv43.winterthur.ch?) und Zürich Versicherungen (ns*.zurich.com?). Leider habe ich die URL der Statistik vergessen – die wohl mittlerweile auch hoffentlich passwortgeschützt ist. Dennoch blieb mir dieses Fakt als Aha-Erlebnis präsent.

HTML aus den 90ern, Pop-Up-Wahnsinn neu erfunden

Die Bedienung der Web-Site ist katastrophal – für alles und jedes öffnet sich ein Pop-Up-Fenster. Das Layout ist für 2005 schlichtweg fürchterlich und hätte längstens eine Auffrischung verdient. Schaut der Web-Developer dann auch noch in den HTML-Quelltext, eröffnen sich weitere Abgründe: Da wird tatsächlich noch der <font>-Tag verwendet. Pfui! Den haben wir doch noch vor der Jahrtausendwende in die Verbannung geschickt – schliesslich gibt es ja heutzutage CSS1+2. Selbstverständlich ist dieser olle Tag nur die Spitze des Eisbergs, doch die meisten meiner Leser würden weitere technische Ausführungen nur ärgern. Zwischenbilanz: Die Kenntnis von CSS2 scheint die Entscheider dort aber noch nicht erreicht zu haben – dabei brächte diese Technologie einige Vorteile mit sich, u.a. der Verzicht auf …

Bandbreiten-Gönner

Der Betrieb einer Photo-Plattform in dieser Grössenordnung zieht (nicht) nur die KV-Angestellten der Banken und Versicherungen an – tagtäglich werden dort Gigabytes an Daten transferiert. Und wenn im Web heutzutage noch etwas kostet, dann ist es der „Traffic“, oder einfacher gesagt, die Daten, die man über Mietleitungen an all die Besucher schicken muss. Anscheinend ist es Partyguide.ch nicht gelungen, diese ausschliesslich mit der nervigen Werbung zu decken (hat schon jemand mal auf eines dieser schicken Banners geklickt?), sondern setzt jetzt auch darauf, die Portemonnaies der Benutzer anzuzapfen:

Mit einem Gönnerbeitrag von Euch ist es möglich, dass wir unsere Hardware schneller aufrüsten können und auch in Zukunft auf agressive & störende Werbung, welche immer auf schlechtes Feedback stösst, grösstenteils verzichten können.

eMeidis Tipp: Statt für viel teures Geld die „Hardware aufzurüsten“ einfach mal das Backend neu programmieren (ich glaube kaum, dass das PHP im Hintergrund auf Performance optimiert wurde), wie auch dank CSS entschlackten, verschlankten und sauberen HTML-Code ausgeben. Das kann schon Wunder wirken.

Heimatgefühle

Der Underdog Lidahun.ch, der nicht nur namentlich auf meine Heimat, das Sensler Oberland hindeutet, ist hier selbstverständlich eine Erwähnung wert. Weiter so!