Workflow lernen

Ich habe es mir lange gewünscht und nach ungefähr 4 Wochen habe ich die Version 1.0 meiner eigenen Faktuierungssoftware auf Basis von CakePHP fertiggestellt. Das Praktische mit dem Nützlichen verbinden – und so habe ich als Resultat eine Software, die ich benötige, und zum anderen einen dicken Stapel Erfahrungen eingesammelt. Als da wären:

  • Entwicklung mit Frameworks ist easy. Man muss sich aber darauf einlassen.
    Frameworks erleichtern das Entwickeln von Webapplikationen massiv. Meistens erfindet man das Rad nicht neu, sondern hat Standard-Probleme wie Formularvalidierungen. Und da machen Frameworks schon Sinn. Aber nur dann, wenn man bereit ist, sich die interne Logik und Methoden anzueignen. Und das bedeutet doch wieder mehr lernen: nämlich spezifische Methoden und Funktionsaufrufe. Ich glaube dann kann man auch richtig schnell entwickeln. Ein Haken dabei: ich muss mehrere Projekte haben, die von Scratch auf gebaut werden müssen. Und ich muss eigentlich beim selben Framework bleiben, um halbwegs eloquent damit entwickeln zu können. Wenn ich dran denke, dass ich mich jetzt noch direkt in ein andere Framework einarbeiten müsste… Aber aus Gründen des Lernfortschritts ist genau das Anzuraten: erst durch die Differenz und dem Vergleich mit dem Anderen werden bestimmte Zusammenhänge sichtbar. Insofern freue ich mich schon auf das nächste lokale PHP-Usergroup-Treffen, in dem es um Frameworks gehen wird.
  • Frameworks zeigen Schwächen des Programmierers auf
    Und ich stelle fest, dass ich einiges an Schwächen habe. Es hat extrem lange gedauert, sich in CakePHP einzuarbeiten. Teilweise war ich versucht statt auf $this->data auf $_POST zurückzugreifen, da ich Anforderungen hatte, die scheinbar nicht mit der Cake-Methode zu realisieren waren (wobei das auch eher darauf hindeutet, dass man sich auf dem Holzweg befindet: Sind meine Anforderungen wirklich so einzigartig und neu, dass sie nicht in die Framework-Logik passen, oder versuche ich gerade das Rad neu zu erfinden?). Und mir war davor schon klar, dass meine Architektenkenntnisse eher begrenzt sind. Dann gleich mit der Anforderung konfrontiert, alles in MVC-Logik abzubilden und am besten noch Design-Patterns für Probleme – äh, da stellte ich fest, dass das für den Anfang doch recht viel ist. Zumal ich bei meiner Anwendung auch etliche Standard-Anforderungen eher lapidar erfüllt habe: Sicherheit? Brauche ich nicht genauswowenig wie Login- und Userrollen, da das Ding nur von mir benutzt wird und lokal betrieben wird. Formularvalidierung? Auch eher rudimentät behandelt. Ich weiß ja, wer die Software nutzt (ich selbst!) und der wird schon keine Dummheiten anstellen.
  • Frameworks sind der ideale Trainer um Programmieren zu lernen
    Statt selbst zu Hause herumzuwursteln und mit gefährlichem Halbwissen Applikationen zu bauen, bekommt man mit Frameworks eine Best-Practice Zusammenstellung und -Anleitung aktueller Programmiertechniken. Und die wird man nicht erlangen, wenn man so wie ich eher an veralteten CMS herumschraubt. Ich hatte den Eindruck immer nur von oben auf die Logik draufzuschauen, aber nie tiefer eintauchen zu können. Das ist mit der Software-Erstellung von Scratch auf anders: hier komme ich auf einmal an Probleme und Einsichten, die ich davor allenfalls rudimentär hatte: etwa die Abhängigkeiten von Tabellen einer Datenbank. Da lieferte mir die Beschäftigung mit hasOne, belongsTo und HABTM einen Quantensprung an Erkenntnis. Einfach aus dem Grund, da ich davor nie eine Datenbank selbst modeliert hatte. Erkenntnis für mich: Datenbankdesign ist bewältigbar, es ist erlernbar und kann direkt Spaß machen.
Advertisements
Veröffentlicht unter Programmierung | Kommentar hinterlassen

Line Breaks

Nachdem ich gestern schon ein fieses Problem mit Line Breaks hatte (den Inhalt einer Textarea mit PHP nachzubauen und in MySQL zu schreiben), kam heute nun in etwa derselbe Klopper, nur mit einer anderen Klasse: für TCPD benötigte ich einen Line Break im Text. Nein, nicht nl2br(), da ich ohne HTML arbeitete. Bei meinen Versuchen kam dann im pdf „Hier steht der Text\nUnd hier ist die nächste Zeile raus“. Dafür hatte ich diesmal nach 10 Minuten die Lösung und musste nicht erfolglos aufgeben. Relativ simple gibt man den LineBreak einfach Ascii-codiert aus und zwar als
$string = "Hier der Text".chr(13).chr(10);

Nachtrag: Funktioniert doch nur bei einigen TCPDF-Methoden. Meine Idee damit einen Line-Break in die Footer()-Methode einzuschleusen, schlug fehl.

Veröffentlicht unter Programmierung | Kommentar hinterlassen

CMS are the path to the dark side, Teil 1

Ich möchte jetzt hier keinen historischen Abriß vorlegen, wie sich CMS entwickelten. Aus der eigenen Erfahrung kann ich nur sagen, dass man Ende der 1990er Jahre als unbedarfter Hobby-Webmaster statische HTML-Seiten baute (mit Frames! das wäre doch auch mal eine tolles Thema: HTML-Konzepte, die ausgestorben sind. Und eine 1a-Trend dazu: Vintage HTML-Coding!).

Irgendwann kamen Systeme auf, in denen der User selbst Inhalte einpflegen konnte und die dann dynamisch Content produzierten. Schnitt: wir befinden uns im Jahr 2011. Meine Perspektive hat sich gewandelt hin zu jemandem, der beruflich Webapplikationen baut. Und aus dieser Sicht stellen sich CMS dann eher als Fluch denn als Segen heraus. Warum das? CMS suggerieren, ein unbedarfter Nutzer könne komplett ohne tieferliegende Kenntnisse Webseiten aufbauen und betreiben. Nur das stellt sich zumeist als Illusion heraus. In der Praxis sind die wenigsten Nutzer so versiert, dass sie ohne Probleme CMS bedienen können. Da wird dann doch eine Agentur angerufen, wenn ein Link in einer dynamisch erzeugten Navigation erscheinen soll. Oft lassen sich solche vermeintlich kleinen Wünsche nicht ohne weiteres im Backend umsetzen. Blöd wird es dann aber für die Agentur: diese darf sich durch vermeintlich tolle Konzepte wie etwa dynamisch erzeugte CSS-Files durchwursteln. Mir zog es jedenfalls fast die Schuhe aus, als ich gerade mit einem Shopsystem konfrontiert wurde, bei dem das komplette CSS in der MySQL-Datenbank zu finden war. Die Idee dahinter: der Shopbetreiber kann in einem Editiermodus Elemente im Frontend herumschieben, das Ganze wird dann aufgezeichnet und gespeichert.

Der Haken bei der Sache: ein User ist in der Regel weder Webdesigner noch Webprogrammierer. Heraus kommt in dem genannten Fall maximal ein Shop, der dilettantisch zusammengesetzt aussieht. Zumal sich bestimmte Elemente so dann doch nicht bearbeiten lassen. Und wenn der professionelle Webentwickler sich der Sache annimmt, braucht er gut 2-3 Mal so lange, um mühsam CSS-Anweisungen in der Datenbank zu editieren und um herauszufinden, an welchen Stellen überall die Inhalte verstreut liegen. Fazit aus dieser Episode wäre, dass CMS – zugegeben: im worst case – Dinge unnötig kompliziert machen. Für den Laien sind die Funktionen zu komplex, für den Experten einfach nervig und so bleibt als Kompromiß, dass alle Beteiligten unzufrieden sind.

Ich habe noch ein paar weitere Argumente auf Lager. To be continued…

Veröffentlicht unter Programmierung | Kommentar hinterlassen

PDFs erstellen

Nach der Einbindung der TCPDF Library in CakePHP kommen mir Zweifel, ob eine Dokumentenerstellung damit der gangbare Weg ist. Halbwegs entnervt bin ich dann doch von der Aussicht, das Layout zu programmieren. Zielsetzung ist in meinem Fall, ein ansprechendes Layout für Rechnungen zu erstellen. Mit HTML und CSS bekomme ich das ganz gut hin. Angeblich unterstützt TCPDF das Ganze auch, nur ist in der Praxis die Formatierung via CSS nicht wirklich tauglich. Man muss sich durch einen Mix aus direkter Programmierung, HTML-Tabellen und CSS-Anweisungen kämpfen. In Sachen Schriften (font-face Einbindung) und Formatierungen (etliche CSS-Anweisungen funktionieren nicht) bin ich eingeschränkt. Das bedeutet Aufwand für das Resultat: ein pdf-File wird an den Browser gesendet.

Die Alternative zu dem Vorgehen ist ein print-Stylesheet anzulegen und eine Layout-Ansicht (die ich schon erstellt habe) mit diesem Stylesheet zu formatieren. Der Vorteil davon ist, dass ich nicht 2 unterschiedliche Ansichten stylen muss: ich kann ganz bequem via CSS das pdf-Layout gestalten und brauche nicht noch einen zusätzlichen Viewport für die pdf-Erstellung. Nachteile wären: ich muss über den Browser gehen und kann Files nicht direkt auf dem Server speichern (und dann z.B. per Email direkt versenden lassen) und das Print-Layout kann je nach Browser unterschiedlich aussehen. Für meinen konkreten Anwendungsfall dürfte das zu verschmerzen sein und ist – denke ich – der gangbare Weg. Sinn würde die TCPDF Library dann machen, wenn ich schon jetzt weiß, dass ich sie in ähnlichen Projekten einsetzen würde und dementsprechend Vorlagen erstellen könnte. Ohne diese Aussicht sehe ich nur eine Menge Aufwand für ein Resultat, das ich auch auf einem einfacheren Weg haben kann.

Veröffentlicht unter Programmierung | Kommentar hinterlassen

Frameworks

Generell ein Problem: ich komme selten dazu mich soweit in einen Gegenstand zu vertiefen, dass ich dort Expertenstatus erlangen würde. Sich eben noch kurz Typo3 angesehen, dann schleuderte mich eine externe Anfrage und die Recherche nach einem Download Portal schon wieder in ganz andere Gefilde. In meiner vorherigen Tätigkeit kam ich auch nie so recht weiter: der Vertrieb hatte immer sehr klare Vorstellungen von den Produkten und damit meinen Arbeitsinhalten. Konsequenz davon war, dass ich selten bis nie Anfragen nach individuellen Programmierungen bekam. Und irgendwie benötige ich dann doch immer ein konkretes Projekt – nur da fallen mir dann Features, Problemstellungen und Möglichkeiten auf, auf die ich bei den üblichen „Wir bauen uns ein Beispielblog“-Tutorials (beides die Beispiel-Applikationen bei Zend Framework und CakePHP) nie gekommen wäre. Zwar ist es eigentlich dämlich ein Haus „einfach mal so“ ohne Bauplan zu bauen – zum kreativen Lernen ist das aber unerlässlich. Mit einem Kunden würde man das nie machen (außer er zahlt ohne zu Murren den Aufwand), für eigene Projekte ist dieses Vorgehen dagegen genial: sich während dem Programmieren zu Features inspirieren lassen, Dinge auszuprobieren und entgegen dem ursprünglichen Plan auch andere Wege gehen. Konkret läuft das bei mir gerade auf ein CRM- und Fakturierungssystem auf Basis von CakePHP hinaus. CakePHP hatte ich mir vor 2 Jahren kurz angesehen, es dann nicht mehr beachtet, und heute wiederentdeckt. Damals wußte ich nicht so recht etwas damit anzufangen, heute – wohl auch durch die ZF Erfahrungen – geht es mir flüssig von der Hand. Trotzdem bleibt ein leichtes Unbehagen: man muss sich auf die Logik des Frameworks einlassen und die Syntax lernen. Und das ist eben nicht PHP, wo man von Grund auf etwa alle Datenbankabfragen schreiben kann bzw. muss, sondern das Vertrauen, dass $this->Objektname->save() schon das richtige machen wird. Dafür ist die Arbeit aber schon fast zu einfach: es geht unglaublich schnell, Resultate zu erzielen. Cake fällt mir leichter als das ZF. Ich erinnere mich an eine mehrstündige Zugfahrt, in der ich das Smarty-Tuturial aus einer PHP-Zeitschrift im ZF umsetzen wollte – und gnadenlos daran scheiterte. Cake erleichterte dagegen den Einstieg, dass das Layout von Anfang an integriert und diese Beispielseiten da sind. Ich bin gespannt was passiert, wenn ich wieder das ZF aufgreife – vermutlich fällt mir das auch wesentlich leichter aufgrund der neuen Fortschritte mit Cake. Und das war für mich die entscheidende Erfahrung: es fiel mir erstaunlich leicht, mit der Syntax umzugehen. Man kommt nach Jahren mit höheren Voraussetzungen an einen Punkt zurück. Ob ich bei Cake bleiben werde – ich bezweifle es. Die CMS, die ich benutze, basieren auf ZF und da liegt es natürlich nahe zu versuchen darin Ninja zu werden. Dazu scheint CakePHP veraltet zu sein – die meisten Tutorials stammen von 2008 und sind in PHP4 Syntax geschrieben und ein Framework ist immer nur so gut und aktuell wie seine Community. Und wenn es nach „was man so hört“ gehen würde, würde ich mir als nächstes CodeIgniter und Symfony ansehen. Dazu müsste mein Tag dann aber 25 Stunden haben.

Veröffentlicht unter Programmierung | Verschlagwortet mit | Kommentar hinterlassen

Die Sache mit dem Kompilieren

Ganz inspiriend finde ich derzeit keine konkreten Projekte auf dem Tisch zu haben. Ich wollte die Anfangsphase meiner Selbstständigkeit dazu nutzen, mich intensiv in Themen einzuarbeiten, für die davor einfach keine Zeit blieb. Das mache ich jetzt und so pendle ich munter zwischen Typo3 Grundlagen, Observer Pattern und sonstigem. Gestern führte mich der Weg dahin, auf meinem LAMP Stack Zend Optimizer installieren zu wollen. Die Bilanz der Unternehmung: durchwachsen. Einerseits habe ich jede Menge gelernt, andererseits wüßte ich nicht, was ich damit anfangen soll. Die Installation eines LAMP-Stacks unter Ubuntu 10.10 mit apt-get und Pakten ging mehr als schnell. Ich hatte Ubuntu seit Jahren nicht mehr genutzt (bis auf ein kurzes Interlude und dem Versuch Trac aufzusetzen vor einem Jahr) und war doch erfreut, dass mein ganzes Wissen noch da war. Insbesondere mit der BASH habe ich mich angfreundet, die ich unter OS X 10.6 doch eher selten nutze. Unter Ubuntu auf meinem Netbook dagegen ist das Terminal mein erster Ansprechpartner, da beginnt eher die grafische Oberfläche zu nerven. Das Schreiben geht immer flüssiger von der Hand, mit mehr Übung merkt man doch deutlich den Vorteil von CLI. Jedenfalls benötigte ich für eine Anwendung den Zend Optimizer und damit fingen die Probleme an. So schön einfach Debian Pakete sind – man ist mit ihnen etwa bei PHP auf eine Versionsnummer festgelegt. Für MySQL wäre mir das ehrlich gesagt egal – da habe ich bislang noch nie den Wunsch oder die Notwendigkeit erfahren, hier umsteigen zu müssen. Bei PHP dagegen benötigte ich eine 5.2 Version. Auch unter dem Hinblick, dass ich Ioncube installieren wollte. Nun gut, nach längerer Recherche fand ich ein Migrationsskript zum downgrade. Installiert wurde via älteren Packages dann aber PHP 5.2.10. Und da meckerte gleich das zu installierende CMS, das eine höhere 5.2 Version wollte. Und ab da war ich in dem klassischen Dilemma: „ich wollte doch eigenlich nur…“ während man von einem Problem zum nächsten stolpert. Nur noch das eine Problem lösen – dann hat man es endlich geschafft! So macht man sich dann Mut, während man auf einmal den nebligen Weg in den Hochalpen vor sich sieht: PHP selbst kompilieren. Ja, kann man machen, ist theoretisch auch nicht so schwer – nur können ungeahnte Probleme auftreten. Was dann auch prompt geschah, als „configure: error: libpng.(a|so) not found“ mich beglückte. Nach ewigem googlen so wie weiteren Fehlern beim „configure“-Befehl kam ich endlich dahinter, dass die „dev“-Packages der jeweiligen Libraries benötigt werden und nicht nur die Libraries selbst. Dann noch rausfinden mit welchen Einstellungen PHP konfiguriert werden muss – und es war ein paar Stunden später. Der eigentliche Knaller kam dann aber: Zend Optimizer wurde (bzw. wird!) nicht gefunden. Habe ich das richtige .so File für die PHP Version installiert? Ja. Ist der Pfad in der php.ini und wird diese geladen? Ja. Die Aussagen von Zend zu den Systemvoraussetzungen sind spärlich bis nicht vorhanden. Nach ewiger Suche fand ich ein altes Dokument von Zend zum Optimizer, die etwas von „no-debug“ Mode, „enable versioning“ beschrieben. Auf der Download-Site war nichts davon zu sehen. Änderungen in der php.ini bei anderen Parametern nach einem Neustart des Apache zeigten Wirkung, aber weder via phpinfo() noch „php -v“ wird der Opimizer angezeigt. Frustriert installierte ich ioncube – was innerhalb von 5 Minuten ohne Probleme gelang. Ein Verdacht: der ZendExtensionManager.so fehlt. Der Optimizer tarball scheint diesen früher enthalten zu haben, heute nicht mehr. Keine Angaben von Zend dazu.

Irgendwann stellt sich dann die Frage: will man wirklich weitermachen und Zeit in eher zweitrangige Probleme stecken? Ich könnte auch anders weitermachen – irgendwo scheine ich es aber als ein Aufgeben und Scheitern zu interpretieren, wenn ich an der Stelle das Unterfangen abbreche. Immer wieder der Gedanke: „das kann doch gar nicht sein – es muss doch an irgend etwas liegen.“ Andererseits die Gewissheit: ich verballere hier eine Unmenge von Zeit, die ich besser an anderer Stelle investiert hätte. Und damit wären wir wieder bei der eingangs erwähnten Bilanz: ich wüßte nicht, was ich mit diesem Wissen anfangen soll. I.d.R. arbeite ich auf Shared Hosting Umgebungen und da bringt mir das Wissen PHP aus dem Sourcecode zu kompilieren rein gar nichts. Es ist eher noch eine Belastung – ich könnte ja jetzt, bin aber durch die Umstände eingeschränkt. Ich würde aber wenigstens zu Hause ganz gerne entscheiden können, welche Version ich installiert habe mit welchen Parametern – und dafür muss ich wohl in den saueren Apfel beißen und mich durch die Hölle der Errors beim Kompiliervorgang kämpfen.

Veröffentlicht unter Programmierung | Kommentar hinterlassen

OOP for Dummies

Nun also doch Java. Der Grund ist einfach: ich lerne am besten dann, wenn ich Unterschiede erkenne: „Aha – so wird das in PHP gelöst und so in einer anderen Sprache.“ Da Javascript mit seiner klassenlosen Objektorientierung definitiv nicht taugt, scheidet diese Sprache aus. Ich hatte mich davor gedrückt, da ich oft den Eindruck habe die Menge an Wissen nicht bewältigen zu können: Theoretisch wäre es auch schön ein Typo3 Crack zu sein, nebenher ein paar Portale mit Drupal hochgezogen zu haben, zum Spaß nebenher ein paar Zeitungsportale realisiert und dann noch in der Freizeit zum Ausgleich einige Kreativprojekte abarbeiten, die es so noch nie gab und das Web revolutionieren.

Dagegen sind in der Realität Zeit und Aufmerksamkeit knappe Ressourcen. Und lernen kostet einfach ganz schön viel Zeit. Java bedeutet für mich erstmal einen Umweg und etwas, dass ich nicht in Kundenprojekte d.h. Geld umsetzen kann. Ich werde voraussichtlich niemals Java Projekte programmieren, der Haken ist nur, dass sich mit Java Objektorientierung am besten erlernen lässt. OOP-Literatur für PHP ist nicht wirklich gut und da ich schon O´Reilly Bücher besitze, deren Codebeispiele auf Java basieren – also Java. Ich lese zum einen in dem frei verfügbaren Java ist auch eine Insel von Christian Ullenboom im Galileo Verlag erschienen, zum anderen habe ich mir Java von Kopf bis Fuß aus dem O´Reilly Verlag besorgt. Damit sollte es möglich sein die Basics in Java so weit zu beherrschen, dass ich weiß was da passiert. Denn als PHPler kann ich etwa mit dieser Instanzierung eines Objektes erstmal wenig anfangen:
Dog d = new Dog();
Warum muss ich vor der Referenzvariable noch den Namen der Klasse erwähnen? Ganz schön redundant. Oder ersetzt das die Angabe eines Variablentyps, die bei Java ja immer streng beachtet werden muss? PHP ist da einfacher gestrickt, da würde das Beispiel dann heißen:
$d = new Dog();
Und genau so lerne ich am besten – sich an solchen einfachen Beispielen Gedanken machen und Code in PHP nachprogrammieren: Wie würde entsprechendes Java Beispiel in PHP lauten? Gerade seit PHP5 gibt es dann doch einige Gemeinsamkeiten in Sachen Objektorientierung mit Java. Insofern bietet es sich schon an, zwischen beiden Sprachen zu switchen um weiter in OOP einzusteigen. Und einiges der Syntax (etwa den Punkt- oder den Plusoperator sowie das Schlüsselwort void) kennt man dann schon aus Javascript, das macht die Sache einfacher. Was die Sache allerdings gar nicht verständlicher macht ist die Tatsache, dass in der Regel in PHP Beschreibungen die Grundlagen der Programmierung außen vor bleiben. Etwa die Speicherbelegung. Bei Java wird gleich von Anfang an peinlich genau beschrieben, wo Objekte und Variablen existieren (Heap und Stack). Bei PHP ist mir das bis heute nicht ganz klar.Vorteil: für Neuanfänger ist die Sache einfacher zu verstehen. Nachteil: man weiß eigentlich gar nicht genau, was passiert, wenn man wie in dem genannten Beispiel Code eingibt. In Javaeinführungen wird das Ganze als Dreisatz zerlegt:

  1. Erstellen der Referenzvariable (Dog d)
  2. Erzeugen des Objektes
  3. Verknüpfung von Referenz mit Objekt

Es macht auf jeden Fall Spaß zu sehen, dass Java von Grund auf eine strikte OOP-Programmierung erzwingt. In PHP kenne ich aus der Praxis allerlei Mischformen. Ich behaupte aber mal, dass sich der Einsatz von PHP immer stärker in Richtung Objektorientierung verschiebt. Wo früher wild durcheinander gecodet wurde, gibt es heute eine stärkere Formalisierung. Etwa ein sich herausbildender Standard des MVC Patterns, auf dem viele Frameworks und CMS aufgebaut sind.

Veröffentlicht unter Programmierung | 1 Kommentar