Shame on me

2 Kommentare

Hier ist er also, mein Code of Shame:

function getValue($path)
{
    return eval("return \$this->xml_config->$path;");
}

Das ist eine Methode einer Config Klasse die ein SimpleXML Objekt kapselt. Irgendwann hatte ich keine Lust mehr, die einzelnen Werte der Config sicher weiterzuleiten, also hab ich diese Methode hinzugefügt. Naja .. damit hätte ich mir das Config Objekt auch sparen können x) … *shame on me*

„The Social Network“ – ein Film von und für Programmierer

5 Kommentare

Gestern Abend hab ich den Film „The Social Network“ über Mark Zuckerberg den Gründer von Facebook gesehen. Meiner Meinung nach ein Must-Seen für Programmierer, denn es werden darin (unter anderem) 3 Punkte aufgezeigt, warum sein „Webprojekt“ so erfolgreich war:

1. Finde die simple Idee
Wenn man mal erfolgreiche Ideen/Produkte vergleicht, wird man feststellen, das bei den allermeisten eine simple Idee zugrunde lag, mit welcher sich das entsprechende Produkt von allen anderen abgegrenzt hat. Die Betonung liegt hierbei auf „simpel“ – einfach, unkompliziert, selbsterklärend. (=> KISS)
Bei Facebook war es die Exclusivität, die man plötzlich mit einer niedrigeren Einstiegshürde erreichen konnte und mit der „das wichtigste“ des Uni Alltags virtuell und einfach abgebildet wurde.

2. Geh in den Tunnel
Immer wieder war davon die Rede, eine Person ist gerade im Tunnel und darf deshalb nicht gestört werden. Ich behaupte mal, dass wenn man sich in seine Programmierung vertieft hat, sich also alle Sinne ohne Ablenkung um den Code drehen, ist man 3 mal so effizient, wie wenn man „aus dem Schlaf heraus“ loslegen soll.

3. Begib dich in eine kreative Umgebung
Als schon klar war, das Facebook „cool“ ist (Zitat), ziehen die Entwickler nach Kalifornien. Die erste Szene in deren Haus zeigt, wie Sie Blödsinn man machen und vom Dach des Hauses in einen Pool springen – drinnen hockt einer gerade an nem Rechner.
Wenig später (im gleichen Haus) sind zwei Mädls am Party machen: Playstation, Bong, Saufen. Dahinter hocken ne Handvoll Entwickler im Tunnel.
Ok, das mag etwas übertrieben sein und scheint schon fast sogar Punkt 2 zu widersprechen, aber Inspiration ist nun mal etwas, was nicht von alleine kommt. Kreative Umgebung sieht immer anders aus, jeder hat seine eigenen kreativen Bedürfnisse: Musik, Kunst, Natur… aber wohl eher selten grauer Büroalltag!
Was ich damit sagen will: macht aus eurem Arbeitsplatz eine Umgebung in der ihr euch wohl fühlt.

Natürlich sind das nicht alle Voraussetzungen um erfolgreich zu sein, geschweige denn guten Code zu schaffen. Aber so zumindest das Grundlegende, was man oft übersieht.
Mehr Tipps und Tricks findet ihr im CCD-Wertesystem. :)

PS: ich mag Facebook nicht. Ich glaub ich lösch mich jetzt.

Stärken und Schwächen von PHP

4 Kommentare

Bei uns in der Firma gibt es „Entwickler-für-Entwickler“ Vorträge. Dabei soll man Einblick in Bereiche der IT bekommen die man eben sonst nicht hat. Diese Woche habe ich als einer der wenigen PHP Entwickler aus der technischen Abteilung meinen anderen Kollegen PHP präsentiert.

Es war ein grober Überblick über den Hintergrund, die Funktionsweise und Syntax der Sprache. Mein Ziel war es, die Vorurteile gegenüber PHP auszuräumen, also habe ich vor allem die objektorientierte Sytax von PHP präsentiert.

Ich glaube kaum, dass ich jemanden der Java und .NET Entwickler von PHP „überzeugen“ konnte, aber ich hatte schon das Gefühl, mit so manchem Vorurteil aufzuräumen.

Zuletzt gab es noch einen Überblick über die Schwächen und Stärken der Sprache, den ich im Folgenden nun etwas ausführlicher Kommentieren möchte.

Ehrlich gesagt ist es schwer die einzelnen Punkte absolut als Stärke oder Schwäche von PHP zu bezeichnen, es ist meistens beides gleichzeitig, eben worauf man bei einem Projekt wert legt:

Die meistgenannte und eindeutigsten Schwäche von PHP ist die Geschwindigkeit oder eher die Langsamkeit. Im Vergleich zu anderen Sprachen soll sie deutlich langsamer sein. Ich habe es noch nie gemessen, aber ich bezweifle es nicht, schließlich muss jede einzelne PHP Datei vor jeder Ausführung interpretiert werden.
Mittlerweile gibt es Code Caches, die ohne großen Aufwand „angeschaltet“ werden können und eine Anwendung beschleunigen.
Seit neustem gibt es ja auch HipHop für PHP, aber das Konzept find ich irgendwie seltsam. Jemand von meinen Kollegen meinte, dass man damit PHP Entwickler einstellen könnte, um C++ Code zu produzieren. :)
Mich wundert vor allem, das so große Anwendungen wie „Facebook“ und „Magento“ auf PHP aufsetzen und damit derart erfolgreich sind. PHP kann also nicht so langsam sein.

Die große Stärke von PHP ist die leichte Erlernbarkeit. Bei meinen Recherchen habe ich folgende Auflösung der Abkürzung PHP gefunden: „People Hate Perl“. Fand ich gut, den Spruch, denn mit Perl kann ich mich nicht anfreunden. ;)
Natürlich sind auch andere Sprachen leicht erlernbar, aber PHP hat sich als interpretierte Sprache extrem gut durchgesetzt [Quelle].
Gleichzeitig ist diese „Stärke“ auch ein Schwäche: man trifft viel zu oft auf Code der einfach gruselig ist. Jeder hat mal solchen Code als Anfänger geschrieben, aber ein Anfänger greift eben eher zu PHP als zu einer anderen Sprache.

Auch ziemlich super finde ich in diesem Rahmen, dass diese eine Sprache für OOP, Skripte und Templates verwendet werden kann. Das heißt, man lernt nur eine Sprache. Smarty, JSPs (für Java) und sonstige separaten Templatesprachen gehn mir auf die Nerven.

Die nächste ähnliche Stärke und Schwäche ist die relativ große Community. Man findet schnell Antwort auf Probleme und auch die Sprache wird stetig weiterentwickelt. Übrigens sehe ich mittlerweile das Zend Framework als ein Teil von PHP, welches eigentlich fast schon als eigene „Stärke“ von PHP durchgehen könnte.
Die gleichzeitige Schwäche ist (ähnlich wie beim vorherigen Punkt), dass oft Code veröffentlicht wird, der im Sinne des „CCD“ schlecht ist. Aber meiner Meinung nach schützt eine „Typsichere“ oder noch sonst so tolle Sprache nicht vor schlechtem Code.

Aufgrund der zwei letzten Punkte, ist PHP eine der Sprachen, die so gut wie bei jedem Webhoster angeboten wird. Daneben gibt es noch eine Menge Freehoster, die das Erlernen der Sprache weiter unterstützen.

Wann also sollte bzw. kann man PHP verwenden?
Ich denke, gerade die letzten Punkte zeigen, dass PHP vor allem bei kleiner Projekten zu einem einfachen und schnellen Ergebnis führen. Kleinere Web-Tools würde ich auf jeden Fall in PHP umsetzen (natürlich auch weil ich es schon erlernt habe) und bei größeren Projekten nur dann, wenn das Budget stark begrenzt ist oder ich eine breite Masse erreichen möchte (Top-Beispiel: Magento).

Ansonsten würde ich mir auf jeden Fall mal andere Sprachen anschauen!
Was ich momentan zum Beispiel an Java cool finde, ist das in Java verwendbare GWT. Es ist einfach umwerfend, wie mit reinem Java Code eine komplette Webanwendung mit AJAX Unterstützung geschrieben werden kann!

Warum PHP?

5 Kommentare

Diese Frage habe ich mir letztens gestellt, nach dem ich einige Kritiken über PHP gelesen habe.
Zum Beispiel ist PHP keine echte Objektorientierte Programmiersprache und wird es auch nicht sein, die wahre Stärke von PHP ist das „Templating“ / erstellen von HTML usw.
Naja, an dem Tag war ich auf jeden Fall etwas deprimiert, weil ich PHP doch irgendwo gern gewonnen hab.

Trotz der Argumente dagegen, ist PHP immer noch eine der verbreitetsten Programmiersprachen. Nicht das damit diese Sprache automatisch „gut“ ist, aber das hat schon mal einen gewissen „Community“ Vorteil.

Das wichtigste Argument FÜR PHP ist meiner Meinung nach die grundlegende Einfachheit:
– man kapiert schnell, wie aus dem Code das Ergebnis wird
– man kann auch mit wenig Kenntnissen mal was zusammen stricken

Naja und Einfachheit hat schon immer seinen Reiz. Siehe zum Beispiel das KISS Prinzip: „Keep it simple, stupid“. Ein Prinzip auf das zum Beispiel auch Apple großen Wert legt und damit Erfolg hat.
Genau das ist es, was so eine Sprache verbreitet macht und den ein oder anderen User dann auch mal dazu anregt PHP und CCD unter einen Hut zu bringen.

Mein Fazit – auch wenn PHP nicht die leistungsfähigste, schönste und eleganteste Sprache ist – es macht meistens einfach Spaß damit zu programmieren.
Cheers.

Google Wave – ich jetzt auch

2 Kommentare

Als ich das erste mal von Google Wave gehört und mir dann auch gleich die Developer Preview Keynote angeschaut hatte, war ich begeistert!
Seit einigen Wochen hab ich nun auch schon ein Google Wave Account. Ich wurde von einem Kollegen eingeladen, der sich direkt bei Google beworben hatte.
Obwohl noch einige andere Kollegen mit dabei waren, waren die Konversationen eher mager. Nachdem ich nun auch einige andere Freunde einladen konnte bzw. kontaktiert hatte, ging es ein mal so richtig ab, dass selbst der Kühler von meinem Mac Book jaulen musste. ;)
Aber dabei blieb es. Seitdem gab es keine größeren Unterhaltungen mehr. Aber ich denke, ich habe genug gesehen, um einen ersten Schluss zu ziehen:

  • Vorerst: Super Idee! Das beste daran ist meiner Meinung nach die Tatsache, dass es nur eine Version der Nachricht gibt und nicht mit jeder Antwort eine neue erstellt wird.
  • Ein weitere Vorteil ist natürlich die Playback Funktion.
  • Das „just-in-time-typing“ macht zwar Spaß, aber irgendwie ist es unnötig – man verfällt viel zu schnell ins „Chatten“ anstatt ne „ordentliche“ Nachricht zu schreiben.
  • Ansonsten sind die restlichen Funktionen (Extensions, private Nachrichten in der Nachricht, Inline Antworten, etc) ganz schick.

Trotzdem finde ich, man hätte dafür kein neues Protokoll erfinden müssen. Ein anständiger Email Client hätte die meisten Neuerungen auch hin bekommen. Es bewahrheitet sich für mich immer mehr, dass Refactoring besser ist als Neuerfindung: Aber anstatt alles zu vereinen hat man eben doch was Neues gemacht.
Besser fände ich mal einen Client der all die Dinger vereint – da ist zum BeispielFlock ein besserer Ansatz.

Meiner Meinung nach wird Google Wave also keinen der bestehenden Dienste (Email, SocialCommunities, Chat, Twitter, Blogging etc.) verdrängen. Aber das ist meine Meinung. Ich lasse mich gerne vom Gegenteil überzeugen.

Ach ja – mag jemand noch eine Einladung haben? Ich hab noch welche zu vergeben.

persönliche CCD Reflektion Nr.1

Hinterlasse einen Kommentar

Ich hab schon vor einiger Zeit mir mal die CCD Armbänder bestellt und trage jetzt seit etwa 3 Wochen das rote Band an meinem Arm. Ehrlich gesagt hilft dieses Band wenig, mich während der Arbeit an die Regeln zu erinnern – eher ist es schlechter Code der mich daran erinnert. Ich find die Bänder aber ein bisschen stylisch und hab deshalb auch das schwarze Band ständig an meinem Arm. :-)

Auf jeden Fall bin ich gerade mal die Liste der Prinzipien und Praktiken für den Roten Grad durch gegangen und dabei ist mir mein fatalster Fehler aufgefallen: Ich reflektiere nicht! Das ist auch der Grund, warum ich das Prinzip Favour Composition over Inheritance (FCoI) total unter den Tisch habe fallen lassen. Kein Wunder, dass mir in meinem Posts „private Methoden vermeiden“ nicht aufgefallen ist, dass Vererbung in vielen Fällen gar nicht angebracht ist.

Ansonsten kann ich im Nachhinein sagen, dass ich die anderen Regeln gut einhalten konnte:

  • DRY: Ich liebe dieses Prinzip und es ist mir ins Blut übergegangen. Da muss ich eher aufpassen, dass ich es nicht übertreibe! ;)
  • KISS: Das mach ich meiner Meinung nach sowieso, da ich nicht so der akademische Typ bin und ich zufrieden bin, wenn der Code funktioniert und gut aussieht. Obwohl ich mir vielleicht manchmal mehr Gedanken über eine Lösung machen sollte, anstatt einfach alles auszuprogrammieren. Dies endet nämlich oft in verschachtelten Schleifen die nur noch anhand Ihrer Kommentare zu entziffern sind.
  • Vorsicht vor Optimierung: Davon lass ich generell die Hände weg. Die Gründe sind ähnlich wie im vorherigen Punkt. Die einzige gern gesehene Optimierung ist bei mir Refaktorisierung!
  • Favour Composition over Inheritance (FCoI): Wie schon im einleitenden Text erwähnt, hatte ich diesen Punkt total übersehen. Aber ich denke, dass genau hier zu oft strukturelle Fehler entstehen. Zumindest konnte ich das so bei mir feststellen.
  • Pfadfinderregel beachten: Meiner Meinung nach die beste Regel um alle Praktiken und Prinzipen zu üben: Dreckigen Code aufräumen. Damit gewöhnt man sich schnell ab, selber ekligen Code zu schreiben. Zumindest tut es ganz arg im Hirn weh, wenn man man doch schnell mal etwas hinhackt! ;)
  • Root cause analysis: Das ist eine Sache, an der ich noch einiges arbeiten muss. Denn schneller ist ein Workaround gebaut, als der eigentliche Bug entfernt. Liegt aber auch daran, dass ich in der Dienstleistung und nicht in der Entwicklung arbeite. Da hab ich einfach kein Zeit mit meinem lahmen Rechner die Dependency Projekte zu debuggen, den Fehler zu beheben und dann alles noch hoch zu laden. Wenn es auch noch ganz schlecht läuft, bin ich dann für die Folgefehler verantwortlich und es geht noch mehr Zeit drauf! Meine Alternative: Workaround bauen und den Bug ins Tracking System eintragen.
  • Ein Versionskontrollsystem einsetzen: SVN ist cool! Mehr hab ich nicht zu sagen. Zum Glück darf ich es einfach nur verwenden. (Danke Edu)
  • Erste Refaktorisierungsmuster anwenden: Im roten Grad bedeutet das nur Methoden extrahieren (=> DRY) und Umbenennen. Beides habe ich sehr oft gemacht in letzter Zeit und bin daher ziemlich zufrieden mit mir.
  • Täglich reflektieren: Hatte ich bisher leider vergessen. Vor allem, wenn ich kurz vor Feierabend noch schnell was machen muss und dann einfach keine Lust mehr hab länger zu bleiben. Aber ich denke, dass ich es damit nachgeholt hab. Mal sehen, ob ich es zukünftig besser umsetzen kann.

Mein Fazit: Diese Woche noch roter Grad – nächste Woche widme ich mich dann dem orangenen zu.