PHP

written by Martin Häcker on

Bäh! = Ich hab mir heute mal mit einigen bekannten die doch etwas besser PHP können angeschaut wie man in die Wikipedia ein plugin einbaut.

Und boah, das ist echt superecklig.

Das geht schon damit los dass man an einen Array nicht vernünftig etwas anhängen kann. Denn, das muss man sich mal auf der Zunge zergehen lassen, arrays sind natürlich keine Objekte - dafür aber auch noch gleich dictionaries.

Und etwas anhängen an einen Array ist daher eine total schwierig. Es gibt zwar eine (globale!) Funktion - so in der art von array_push_value() oder so, aber das will niemand schrieben, desshalb gibt es dafür eine extra Syntax (!!!):

$someArray[] = "fnord";

Geil oder?

Und natürlich ist Wikipedia auch ein total gewachsenes Projekt, daher gibt es tausende von globalen Variablen die man manchmal überschreiben, manchmal anhängen und manchmal irgendwas machen muss.

Auf meine Frage wieso man so etwas so macht, fiel auch meinen Bekannten auch nur ein "das ist halt vermutlich so schneller" ein. Denn, der ganze Code muss ja fĂĽr jeden Seitenabruf neu geparst werden.

Wie krass!

Und es ist nicht so das es dann fĂĽr das Plugin registrieren eine Funktion gibt, in der man vielleicht noch ein Verzeichnis ĂĽbergibt, wo dann nach einem standard-layout die ganzen Files drin sind. Nein! man muss x verschiedene globale variablen von hand anfassen.

kotz

Wers nicht glaubt, schaut selber nach!

Internetsperrungen

written by Martin Häcker on

Der Petitionsserver des deutschen Bundestags hat mal wieder eine vernĂĽnftige Petition - gegen die Internetsperren.

Hier ein Excerpt:

Wir fordern, daß der Deutsche Bundestag die Änderung des Telemediengesetzes nach dem Gesetzentwurf des Bundeskabinetts vom 22.4.09 ablehnt. Wir halten das geplante Vorgehen, Internetseiten vom BKA indizieren & von den Providern sperren zu lassen, für undurchsichtig & unkontrollierbar, da die "Sperrlisten" weder einsehbar sind noch genau festgelegt ist, nach welchen Kriterien Webseiten auf die Liste gesetzt werden. Wir sehen darin eine Gefährdung des Grundrechtes auf Informationsfreiheit.

Ist doch ein Start. Also zeichnen. :)

Agil ist so eine Sache

written by Martin Häcker on

jeder will es sein, und fast niemand ist es wirklich. Zumindest ist das meine Beobachtung.

Um so besser dass es einige Firmen gibt die versuchen ihre Prozesse transparent zu machen und herzeigen wie sie Arbeiten.

Hashrocket hat z.B. einen Vimeo Channel auf dem sie immer wieder Videos veröffentlichen.

Besonders spannend finde ich das Video ĂĽber ihren Daily Standup. Details wie der "Speakers-Ball" find ich einfach klasse. Sehenswert!

Cappuccino und jQuery im Vergleich

written by Martin Häcker on

Ich beschäftige mich ja seit einiger Zeit intensiver mit Web-Entwicklung - und da im besondern mit Cappuccino um damit GUIs in WebBrowsern zu bauen.

Cappuccino ist zwei Sachen - eine dĂĽnne Schicht JavaScript die einen Translator implementiert der aus Objective-J (Quasi Objective-C fĂĽr JavaScript) normales JavaScript macht und eine Bibliothek an Objekten die der [Cocoa Bibliothek] von Apple aus dem Gesicht geschnitten ist.

Und Cocoa ist immer noch die schönste und knackigste Bibliothek die ich kenne - allerdings kenne ich auch noch nicht so viele.

Um so spannender fand ich es daher eines der Beispiele des Cappucino Projektes noch einmal in jQuery implementiert zu sehen (Blog dazu)

jQuery ist nämlich eine Bibliothek die die Möglichkeiten von JavaScript (Closures!) mal wirklich vollständig ausreizt und soweit ich das beurteilen kann ein Musterbeispiel von richtig gutem JavaScript Code ist.

Auf der anderen Seite ist Cappuccino - eine Sprache die von C portiert wurde, und die daher eben keine Closures einsetzt - weder in der Sprache, noch in der Bibliothek.

Und das rennen fängt gut für jQuery an - jQuery braucht für das gleiche Beispiel nur 45 Zeilen Code, während Cappuccino mit 400 Zeilen dabei ist - und enthält an manchen Stellen sogar noch mehr Bling! (Die Bilder faden schön ein statt einfach nur zu erscheinen)

Schaut man sich die Beispiele genauer an, stellt man fest, dass bei jQuery zu den 45 Zeilen Javascript noch mal 200 Zeilen CSS kommen und dass der JavaScript Code völlig ohne Leerzeilen auskommt, während bei Cappuccino besonders auf übersichtlichkeit geachtet wurde.

Korrigiert man das und vergleicht erneut, dann sieht das Ergebnis etwas anders aus: jQuery + CSS ~= 200 Zeilen vs. Cappuccino ~= 200 Zeilen.

Whoa.

Also muss der Vergleich inhaltlich stattfinden: Cappuccino isoliert den Applikationsentwickler komplett vom DOM und seinen Schwierigkeiten, während jQuery natürlich komplett damit Arbeitet - und man sich auch selber um die Komplikationen kümmern muss die man mit der Browserkompatibilität hat.

Dafür ist der Code von jQuery inhaltlich wirklich sehr schön kurz - ich finde man sieht ganz hervorragend was man erreichen kann wenn man benannte Parameter (hier durch JavaScript Objekt-Literale Vertreten) und konsequenten Einsatz von Closures kombiniert.

Das hier zum Beispiel:

$.each(data.items, function(i,item){
   img = new Image();
   img.src = item.media.m;
   img.onload = function() {
        $(this).animate({opacity: 1}, "normal");
   }
   $(img).css({opacity: 0}).appendTo("#content").wrap("<div></div>");
   if ( i == 20 ) return false;
   });

ist einfach sehr ausdrukstark. Ich freue mich schon darauf wenn Apple Snow-Leopard herausbringt und damit Closures auch in Objective-C einzug halten - weil dann wird auch Cappuccino diese Möglichkeiten endlich nutzen ohne die Kompatibilität mit Cocoa zu verlieren.

Auf der anderen Seite finde ich den Objective-J Code wie bei Cocoa auch sehr ausdrucksstark - und vielleicht etwas verbose. DafĂĽr dokumentiert sich der Code aber auch ganz excellent.

Und da er nicht länger ist als der andere, sehe ich da überhaupt kein Problem.

Alles in allem also ein guter Grund jQuery zu lernen um die Möglichkeiten von JavaScript wirklich mal zu verstehen.

Interview mit De:Bug

written by Martin Häcker on

Spannend wars, gestern das Interview mit De:bug natürlich gings um die ganzen Piraten-Sachen - wie wir vermitteln dass wir es ernst meinen, warum man uns wählen sollte, etc.

Für mich spannender war danach das Gegeninterview wo wir den Chefredakteur mal ein bisschen zu dem Magazin fragen konnten. Erst mal das Übliche, sie beziehen ca. 80% ihrer Einnahmen aus Anzeigen und nur ca. 20% aus Magazinverkäufen. Auch spannend, das Magazin lebt letztlich seit seiner Gründung von einem Monat auf den nächsten - etwas das ich inzwischen bei vielen Magazinen vermute - auch wenn man das auf den ersten Blick gar nicht sieht.

Aber: Seit die "Wirtschaftskriese" losgebrochen ist hat das Anzeigenvollumen nicht wirklich zurückgegangen (!) - allerdings hat sich das Verhalten der Kunden verändert. Jetzt wird nicht mehr ein Jahr im Voraus geplant und gebucht, sondern nur noch von Monat zu Monat. Und das macht natürlich schlechte Planungsmöglichkeiten.

Auch fand ich sehr spannend aus meiner Sicht als Agiler Softwareentwickler auf die Zeitungsproduktion zu schauen - Jeden Monat ein Produkt von hoher Qualität auf den Punkt produzieren. Und das ganze mit gigantischem Kommunikationsoverhead - schließlich geht es ja beim Magazinproduzieren um nichts anderes.

Spannend. :)

Ein Film ĂĽber Softwareentwicklung

written by Martin Häcker on

Der erste ĂĽberhaupt!

Insbesondere ist einer der betreuenden Professoren mein Onkel - daher hab ich den Link auch. :)

Das Konzept dass das Projekt rollend von einer Generation von Studenten an die nächsten weitergegeben wird find ich klasse. Code, Dokumentation, Bugs - alles kriegt man von den Vorgängern. Und da kommt noch mehr gutes: Kurze Iterationen 3 Wochen pro Iteration, klare review und status Meetings am ende jeder Iteration.

Soweit so gut. Einiges hat mir aber auch nicht so gut gefallen. Z.B.:

  • Ein Semester nur Planung und Einarbeitung - in dieser Zeit wird fĂĽr die simulierte Firma kein Wert erzeugt den sie Verkaufen können. Das haben die Studenten auch selber gemerkt. "Die erste Phase war recht lang und damit auch sehr kostenintensiv." No shit sherlock.
  • Und natĂĽrlich lauter Spezialisten - keine Polivalente Teams
  • Die ganze Suite der Rational Tools wird eingesetzt
  • RUP als Prozess- mit all seiner "Schönheit"

Das Projekt wird als klassischer Wasserfall umgesetzt - und das Feedback der simulierten Kunden war dann auch klar: "Es gab da einige Momente im Projekt, da hätte man schon lange gesagt: 'Ich kündige den Vertrag und wechsle die Firma'".

Man könnte also sagen die Studenten sind optimal auf das Wirtschaftsleben vorbereitet.

Aber alle Kritik zur Seite: Das ist trotzdem noch lange das beste Software-Projekt das ich bisher gesehen habe.

Jaunty Jackalope on VirtualBox 2.2.0

written by Martin Häcker on

Well, das neue Ubuntu sieht gut aus. Viele Details gefallen mir besser als beim vorherigen.

Insbesondere kann es jetzt korrekt die MacBook Pro Tastatur erkennen und die Konfiguration der Alt-Taste als Third-Level Chooser funktioniert jetzt auch etwas logischer (wenn auch immer noch recht versteckt).

Das einzige was absolut nicht gehen wollte war die Maus-Zeiger Integration. Aber Gott sei dank habe ich nach einigem hin und doch im Netz den entscheidenden Hinweis gefunden.

Man muss die xorg.conf mal wieder von hand anpassen...

Hrm.

Dafür geht es jetzt. 3D Integration krieg ich aber nach wie vor nicht zum laufen - während das mit Intrepid Ibex noch prima funktionierte.

Well, man kann halt nicht alles haben. :)

Javascript - the good parts

written by Martin Häcker on

Beim Schimpfen ĂĽber Javascript vergisst man immer gerne dass da doch relativ viel von Scheme drin ist.

Zum GlĂĽck gibt es Douglas Crockford - und der hat bei Google darĂĽber gesprochen was die guten und schlechten sachen sind.

Sehenswert wenn man mit Javascript arbeitet / arbeiten muss.

p.s. Er hat auch JSLint geschrieben.

Ruby Videos

written by Martin Häcker on

Während meinem Urlaub habe ich mir eine Menge Videos angesehen - so viel Zeit hat man ja sonst nicht. Allerdings nicht irgendwas. (OK, etwas Daily Show war auch dabei :)

Diese Videos haben mir besonders gut gefallen:

  • Jive Talkin: DSL Design and Construction From a creator of many DSLs a short overview over the specific techniques and how he goes about doing them. (Test driven of course)
  • Improving the usuability of your Ruby on Rails application A nice talk about website usability and very specific things that you can do to enhance it (with a great example)
  • Tourbus A really nice talk about how to optimize ruby on rails applications (but really it's more general and can be used for anything). He especially talks about how you can easily get one to two orders of magnitude speed improvements on the first optimization pass of an app.
  • BDD with Cucumber A talk about how Behaviour Driven Development works in practice and how it can be used to drive development - from a guy at Thoughtworks who gives very practical examples.
  • La Dolce Vita Rubyista A talk about how agile development should be - shown in a series of short movies which are quite funny.
  • Testing as Communication How Programmer Testing can be used to achieve better communication with your customers.
  • Aristotle and the art of software development A talk about three major currents of philossophy - and how they may relate to software development and which programming language to choose.
  • Using Metrics to take a look at your code Talk about possible code metrics and how to use them to discover and keep an eye on bad parts of your code.
  • Effective and creative coding Talk of a psychologist about directed attention and how to recharge it to be a more effective and creative coder
  • The Grand Unified Theory... ... of Programming. In this talk, Jim Weirich talks about Connescance as a guide to how to determine what is good and what isn't good programming.

Und auf diese Tools bin ich dabei noch mal gestoĂźen - dabei sind wirklich ein paar sachen die extra cool sind:

Core War

written by Martin Häcker on

Ich hab mich schon länger mit dem Gedanken herumgetragen dass es eigentlich mal einen schönen aktuellen CoreWar clienten für den Mac geben müsste.

Und, irgendwie kam es bisher nicht dazu - aus irgend einem Grund hat niemand einen geschrieben.

Well, jetzt hab ich mal einen minimalen Anfang gemacht um herauszufinden wie man so etwas ĂĽberhaupt programmieren mĂĽsste.

[source:open-source/CoreWar Hier] ist das vorläufige Ergebnis.

WARNING: Work In Progress!

Das ist natürlich völlig unfertig - Es läuft genau nur ein Krieger (IMP) - und der auch nur weil er alleine ist. :-)

Aber, ich habe eine Abstraktion für die VM, ein View was das Ergebnis anzeigt, und ein paar Tests die auf der VM herumrödeln und schauen dass sie prinzipiell das richtige tut.

Kleinigkeiten die noch fehlen wären zum Beispiel ein Parser für Redcode, Einstellungen um die Applikation an die verschiedenen Regelwerke anpassen zu können und natürlich eine Implementierung aller Redcode Instruktionen...

Also ein Anfang. Und man sieht schon etwas. :)

Ach ja, hier noch was fĂĽr echte Core War fans...