Warum hier Ende ist, wird Sie unglaublich schockieren…

In einem Podcast hat René Walter von nerdcore.de das Phänomen sehr schön beschrieben: Am Anfang des Bloggens fühlte er sich wie ein Kind nachts eingesperrt in der Süßwarenabteilung. „Erst ein Blog über Filme aufsetzen, dann eins über Musik, ein weiteres über Bücher und dann…“ So zumindest die Vorstellung. Dann kam die Realität™. Es mag zwar oft ganz interessant wirken, sich Austoben zu können, irgendwann hat man sich aber genügend verausgabt und stellt fest, dass man zig Kanäle unterhält, die es alle zu bespaßen gilt. Eigentlich gehört zu jedem Blog dann auch noch Facebook, Twitter, Tumblr sowie min. 1x Emailadresse. Fazit: Alles viel zu viel.

So ging es mir jedenfalls. Ich dachte zuerst hier auf codecult bestimmte PHP Inhalte anzubieten, die an anderer Stelle nicht funktionieren würden. In der Zwischenzeit hat sich das geändert und ich blogge alles unter meinem Shop Freelancer Blog – das Ecommerce und Shopware Blog. Ursprünglich war mein dort Blog als Ecommerce- und Shopware Blog konzipiert, ich habe dann aber begonnen von Web-Security über Programmierung bis Vermischtes alles dort zu verbloggen. Eben von den Erfahrungen um das Shop-System Shopware bis hin zu Magento, mit denen ich täglich als Web-Developer zu tun habe. Danke für das Interesse hier und weiter dort.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Es spricht der Wutprogrammierer: Die Wurschtigkeit der Agenturwelt

Ich habe für mich eigentlich den Leitsatz aufgestellt, nicht mehr für Agenturen zu arbeiten. Ich kann zusammenfassen, dass meine Erfahrungen mit Agenturen im Schnitt eher schlecht waren. In etwa: wer keine Ahnung von Internet hat, macht eine Webagentur auf. Ohne jetzt völlig Wutprogrammierer-artig vom Leder lassen zu wollen, aber das Ausmaß an Inkompetenz ist teils beachtlich. Ich erfahre lapidar in einer 2zeiligen Mail durch Zufall von einem Agenturchef, „da fällt nix mehr an, die haben gekündigt“. Davor war der Wartungsvertrag schon so aufgestellt, dass die Agentur 10 Stunden im Monat vom Kunden garantiert bezahlt bekam – ich dagegen nicht. Um schon die Antwort vorwegzunehmen, warum man sich darauf einlässt: Geld. Und wenn ich ehrlich bin: bestimmte Erfahrungen muss man erst mal gemacht haben, um hinterher zu sagen „nie wieder“. In dem Fall war das noch nicht mal besonders schlimm.

Bei einer anderen Webagentur aus dem süddeutschen Raum war ich über das Unvermögen der Projektmanager so empört, dass ich dort nach 2 Stunden abgebrochen hatte. Und sorry – wenn ich vom Firmeninhaber nachts um halb 1 eine Email bekomme, dann will ich für diesen Laden nicht arbeiten. Man kann in diesem Segment theoretisch zumindest halbwegs stressfrei arbeiten – wenn man die Arbeit gut organisiert. Wenn ich dagegen die Infos bekomme „uns ist ein Programmierer abhanden gekommen“ (ja, warum wohl nur?) und „das Projekt müsste am besten gestern fertig sein“, dann fällt mir nichts mehr dazu ein. In 5 Wochen sollte angeblich Launch von einem großen Projekt sein (da wurde ich angeschrieben), dann hörte ich 2 Wochen nichts und man wollte Details mit mir besprechen. Bei mir hört es da auf – entweder ich will eine Sache gut machen oder ich betreibe Wurschtelei auf niedrigstem Niveau mit völlig unrealistischen Deadlines.

In etwa so: Webagenturen sind parasitäre Organisationsformen, die lauwarme Luft für teuer Geld verkaufen. Und von nichts eine Ahnung haben. Erst wird das Projekt verkauft, dann wird sich irgendwann über die Umsetzung Gedanken gemacht. Und irgendein Depp wird sich schon finden, der die Drecksarbeit erledit. Aber ohne mich, meine Freunde!

Auf eine Faustregel (empirisch natürlich völliger Unfug, spiegelt aber zu 100% meine subjektiven Erfahrungen wider): Agenturen aus Hamburg sind die größten Vollpfosten. Ein besonders perfider Fall: „ja, also wir würden dir als Entwickler erst 20 Eur zahlen, dich dann im 2. Monat auf 24 Eur hochstufen und ne Wohnung würden wir dir auch besorgen, du müsstest herziehen“. Jeder weiß, dass es in Hamburg nicht ohne weiteres Wohnungen auf dem Markt gibt. Ich werde also wie ein ukrainischer Leiharbeiter bezahlt und dürfte dann vermutlich in der Penntüte unterm Schreibtisch campieren. Da gehen bei mir sämtliche verfügbaren Mittelfinger nach oben und der imaginäre Iro richtet sich steil auf. Zumal der betreffende Manager sich noch menschlich eine der allerletzten Aktionen leistete, die ich seit längerem erlebt hatte: „Wow, wir hören die gleiche Musik und ich geh ja auch ganz gerne in der Schanze aus, da ist es nicht so Schicki“. Ey fuck you, du Pfeife, das nächste Mal bring ich nen Pflasterstein mit, dann zeig ich dir mal Schanze.
Das war ganz am Anfang meiner Selbstständigkeit und ich bin bis heute froh, damals direkt abgesagt zu haben. Mir fallen nur die Begriffe „Lohnsklaverei“ und „Tretmühle“ ein.

Also doch Wutprogrammierer. Ok, es spricht aber auch einiges dafür bei diesen Verhältnissen leicht stinkig zu werden. Die Geschichten von Kunden, die nicht zahlen wollen, wäre auch nochmal näher zu untersuchen. Aber das vielleicht beim nächsten Mal.

Veröffentlicht unter Programmierung | Kommentar hinterlassen

Wofür nur, oh wofür?

Man macht sich mit dem Schnittstellenbau keine Freunde. Und Ehre winkt auch nicht. Eher schmachvolle Niederlage und der ewige Shitstorm, der an einem kleben bleibt. Die Idee ist aber auch zu verlockend: Hey, ich muss doch nur das Shopsystem an die ERP anflanschen und auf Knopfdruck fließen alle Informationen von links nach rechts und umgekehrt. So zumindest die spinnerte Idee, bar jeglicher Realität. In der Praxis tauchen dann alle Probleme auf, die man nicht bedacht hat. Z.B. dass man mit 2x Software unterschiedlicher Hersteller zu tun hat, wo auch nach Belieben mal die API-Spezifikationen geändert werden. Oder die Tatsache, dass sich eine Schnittstellenentwicklung nur dann finanziell lohnt, wenn man diese an mehrere Kunden verkauft. Dann hat aber jeder Kunde andere Sonderwünsche, die erst nach der Auslieferung klar werden. Und die Schnittstelle muss auf verschiedenen Serverumgebungen laufen. Alles in allem für mich als notorischer Realist genug Gründe von solchen Unterfangen die Finger zu lassen. Zumal auch niemand davor berechnen mag, ob sich solche Entwicklungskosten überhaupt irgendwann mal rechnen. Aber so ist es mit Software: die kann ja angeblich alles. Solange die Welt noch von diesem Wahn befeuert wird, brauche ich mir über meinen Arbeitsplatz keine Gedanken zu machen.

Veröffentlicht unter Programmierung | Kommentar hinterlassen

IT als gesellschaftliches Phantasma

Leider habe ich nicht mehr die Zeit wie früher ellenlange Artikel mit dezidiertem theoretischen Hintergrund zu schreiben. Man müsste das Ganze mal psychoanalytisch begründen, aber meine Schnelldiagnose steht fest: diese Gesellschaft ist Gadget Mad und hat einen generell einen irrationalen Dachschaden, wenn es um Hardware geht. Gadget mad heisst, dass man alles supi findet, was von Apple kommt und man drauf rumdrücken kann. Warum man überhaupt auf so Geräten rumdrücken sollte interessiert weniger. Das hätte man mal Leuten aus der Vergangenheit erzählen sollen: die Zukunft im Jahr 2011 sieht so aus, dass überall wo man hinkommt, Leute auf Bildschirme starren. Die eher unlustige dunkle Seite bedeutet Computerschrott ohne Ende zu produzieren und den Kapitalkreislauf munter weiterzutreiben. Wollen wir so leben? Egal, immer weiter.

Ebenso obskur ist mir die andere Seite, mit der ich täglich konfrontiert werde. Es herrschen die komischsten Vorstellungen über Software und was Software darstellt und kann. Betriebswirtschaftlich – d.h. irgendwo doch rational nachvollziehbar – wird da in den wenigsten Fällen gedacht. Die Leute sind getrieben von einer Art Heilsversprechen mit einem Glänzen in den Augen: ich muss es haben und alles wird gut. Software kann danach alles, man drückt nur auf einen Knopf und die Magie geht los. Selbst Leute, die eigentlich schon mit Erfahrungen auf die Nase gefallen sind, lernen nicht daraus. Die putzigste Szene hatte ich mal mit einem Agenturchef (selbst BWLer), der doch allen Ernstes mir gegenüber die Problemdiagnose einer Schnittstellenanbindung abgab: „Es lag daran, dass wir eine Software entwickelt hatten und diese Fehler hatte. Das hatten wir nicht bedacht.“ Ah ja – Software hat Bugs. Eine ganz neuartige Erkenntnis, die man so auch noch nie gehört hatte. Da wäre man ja nie drauf gekommen, dass so etwas bedacht werden muss vor der Entwicklung.

So auch generell die Idee: Software wird diesem Irrglauben nach einmal entwickelt, funktioniert dann fehlerfrei und ist für alle Zeiten lauffähig. Die Realität sieht eher so aus: Software funktioniert nicht fehlerfrei, die User beurteilen Software (ok, ich arbeite im Web-Bereich, das sollte ich vielleicht dazu sagen) in erster Linie über deren GUI (das wäre nochmal eine eigenes Thema, dem ich einige Blogeinträge widmen könnte), dann kommt die nächste Software mit anderem Interface und man entscheidet sich für was anderes. Vermutlich auch deswegen, weil man von einem windigen Vertriebler zugequatscht wurde, der die grandiosen Vorzüge der Superlösung anpreist – und den Hype um Software weitertreibt.

Zugegeben, das sind die Erfahrungen in dem Umfeld, in dem ich mich bewege. In der Entwicklung wurden ja die Unzulänglichkeiten und Problem von Software erkannt und man setzt dort dann etwa auf agile Projektmanagement-Methoden wie Scrum, um einige Probleme abzufangen. Das ändert aber nichts an dem gesellschaftlichen Wahn um die Software.

Veröffentlicht unter Uncategorized | Kommentar hinterlassen

Kurze Zusammenfassung BEPHPUG Treffen / 1.2.2011 / PHP Frameworks

Am 1.2.2011 ging es in der PHP Usergroup Berlin BEPHPUG um Frameworks. Zunächst wurde die Referentenverspätung genutzt, um eine Stampede mit blauen Elephanten (das PHP Stoffmaskottchen war an dem Abend äußerst beliebt) auszulösen, dann wurden noch Freebies verteilt und es ging los.

Im ersten Vortrag berichtete Fabian Blechschmidt über seine Erfahrungen mit Symfony 1. Er hat 1 Portalprojekt mit circa 30 Stunden an Symfony umgesetzt. Ein wichtiges Merkmal von Symfony ist die Konfiguration via Yaml-Dateien (was am Abend doch eher kontrovers diskutiert wurde). Es gab eine Wortmeldung auf dem Publikum: Vorteile sind die große Community und Möglichkeit Plugins direkt einzubinden, und es gibt für viele Tasks Plugins. Allerdings sei die Performance eher mässig, sonderlich schnell sei das Framework nicht. Erhellend war für mich der Satz des Referenten „ich fühle mich in Symfony besser“ – denn das ist oft auch für mich ein Auswahlmerkmal: entweder man wird mit der Logik einer Software auf einer intuitiven Ebene warm, oder nicht.

Der zweite Vortrag von Michael Schulz behandelte das Zend Framework. Michael arbeitet seit 5 Jahren mit dem ZF. Ein Standardvorwurf an es lautete, dass es „eine große Ansammlung von Komponenten“ sei – also eher Komponentenbibliothek denn Framework. Allerdings sei der modulare Aufbau von Vorteil, wenn man nur einzelne Komponenten nutzen wolle (etwa Zend_pdf). Eine Anbindung an den Zend Server sei möglich, wie Symfony verfüge es auch über ein Command Line Tool.
Auffallend bei der MVC-Umsetzung sei, dass das Model nicht vorgegeben sei – die Logik bei Datenbankabfragen müsse man sich selbst erarbeiten. Auf der Soll-Seite stünden die Action-Stack-Helper als Performancebremsen, auf der Haben-Seite die große und aktive Community sowie die gute Test-Anbindung. Unbedingt empfehlenswert seien die ZendCasts. Der Updateprozess bei ZF Versionen 1 würde problemlos vonstatten gehen(auch da gab es in der Diskussion eine anderslautende Erfahrung).

Im dritten Vortrag hielt Martin Holzhauer ein Plädoyer für Zeta Components. Es ging aus ezComponents hervor und ist bis dato nur via SVN-Checkout zu beziehen. Allerdings sei die derzeitige Version stabil und produktiv nutzbar, da sie direkt die letzte ezComponents Version darstellte. Zeta versteht sich explizit nicht als Framework, sondern als Komponentensammlung. Im Unterschied zu ZF seien diese aber auch wirklich einzeln nutzbar (einzig einer Basiskomponente bedarf es immer), bei ZF dagegen würde man immer recht schnell weitere Komponenenten aufgrund von Abhängigkeiten benötigen. Es wurde anschließend ausführlich über das Lizenzmodell gesprochen, Zeta sei jetzt unter der Apache Lizenz, da das Projekt an die Apache Foundation übergeben wurde. Einzelne Komponenten und Anbindungen wurden vorgestellt (Graph zur Datenvisualisierung, TCPDF-Klasse). Eine MVC-Anwendung sei mit Zeta Components möglich, wurde aber sinngemäß kommentiert mit „bevor man es verstanden hat, lässt man es lieber“.

Sehr kurz fiel dann der vierte Vortrag von Dietmar Erdmann über CodeIgniter aus. Er habe 1,5 Jahre Projekterfahrung mit dem Framework und wolle es kurz an dessen Eigenwerbung messen: eine einfache Lösung, performant, liefert nur minimale Funktionen. Oder: Ein Framework, das kein Framework sein will. Dadurch sei es kein MVC-Framework, das selbst Dateien erzeuge, sondern würde dem User alles überlassen. Es wurde die Frage gestellt, ob man dann ein Framework brauche, wenn „man im Endeffekt alles selbst schreibt“. Und so fielen die Reaktionen zu CodeIgniter insgesamt eher verhalten aus.

Der fünfte Vortrag von Daniel Fahlke erläuterte dann Yii. Dieses setze man am besten ein, wenn eine fertige Datenbank mit Fremdschlüsseln vorhanden sei, daraus würde dann Yii die Model generieren. Möglichkeiten zur Formvalidierungen seien stattdessen nicht umfangreich. Es ging recht ausführlich um die automatisch Codegenerierung ein. Controller und Models würden damit erstellt, Änderungen müssten aber per Hand eingefügt werden
Publikumsmeldung: Cake habe das gleiche Problem, wenn man mit Codegenerator arbeitet)
Doctrine sei eher nicht nutzbar, da Yii eigene DB-Abstraktion nutze. Dazu fiel der Satz: „wer Yii nutzt, will fertig generierte Model nutzen“.
Eine Frage aus dem Publikum zielte auf den Use-Case. Yii solle man am ehesten einsetzen bei einer fertigen Datenbank, an der wenige Änderungen abzusehen seien. Aus dem Publikum wurde das Framework als „Datenbankvisualisierung oder Admin-Backend“ charakterisiert.
Eher ungünstig seien die kaum vorhandenen Tutorials und Dokumentation, dazu scheint sich die Arbeit auf wenige Entwickler zu beschränken, die unter Zeitdruck stünden. Alles in allem, wollte an dem Abend niemand einer Einschätzung wie auf http://www.phpframeworks.com/top-10-php-frameworks/ folgen, wo Yii derzeit auf Platz 1 gelistet wird. Es gab noch eine Bemerkung, das Yii zu Beginn an viele aktuelle Programmiertechniken wie Closures – teils aber nur um ihrer selbst willen – eingesetzt hätte, was seine Beliebtheit erklären könne. Die Diskussion brachte aber noch eine andere interessante Frage hervor: was sind Auswahlkriterien für Frameworks? Eines davon z.B., wie viele Entwickler an dem Projekt arbeiten.

Alles in allem hat der lange Abend dann doch Licht ins Dunkel der PHP Frameworks gebracht. Denn abseits von Leistungsbeschreibungen zählen dann doch die Praxiserfahrungen. Und da stellte sich für mich die Lage doch anders da, als erwartet. Das von mir genutze CakePHP kam in einigen Randbemerkungen vor, wurde aber nur von wenigen Anwesenden in einer „Wer nutzt welches Framework“-Fragerunde genannt.

Veröffentlicht unter Programmierung | Kommentar hinterlassen

CMS are the path to the dark side, Teil 2

Ich bin gerade dabei eine Site auf WordPress umzustellen. Ich mag WordPress. Es ist einfach, es ist übersichtlich und kann aber zusätzlich mit Funktionen ausgestattet werden. Und genau das ist der Haken an CMS: sie halten zwar Funktionen für alle möglichen Einsatzszenarien bereit, dadurch wird die Sache aber hochgradig unübersichtlich. Bei der Arbeit fiel mir ein weiteres Argumtent ein:

  • CMS produzieren zu viel Markup
    Zwar hat sich jemand sicher etwas dabei gedacht und es auch für HTML-Anfänger ganz übersichtlich – am Ende habe ich aber Navigationen mit vielfach verschachtelten div´s und Klassenbezeichnungen wie „menu-item menu-item-type-post_type menu-item-19“. Und da fängt das substrahierende Arbeiten an: ich muss mühsam das ganze Markup aus dem Quellcode herauslösen. Bei WordPress etwa werden Formulare in Core-PHP-Files eingebaut. Da kann ich nicht einfach dran herumschrauben, sonst verliere ich die Updatefähigkeit. Entweder gehe ich dann meinen eigenen Weg – oder ich muss eben als notwendiges Übel das ganze Markup mit herumschleppen. Ähnlich ist das mit Child-Themes: einerseits eine wunderbare Sache um schnell zu Ergebnissen zu kommen, aber doch mit der unschönen Macke, dass ein riesiger Overhead an CSS und PHP mitgeschleppt wird. Gerade bei kleineren Blogs die auf einem shared Server gehostet werden kann man sich eigentlich nicht erlauben Ressourcen zu verschenken. Und da ist es ärgerlich, wenn Plugins das Javascript in den Bereich laden und Child Themes mit dem überladen von CSS-Files arbeiten. Performant geht anders.

To be continued…

Veröffentlicht unter CMS | Kommentar hinterlassen

Those who survived TCPDF

Ich kann es kaum glauben, dass mein Rechnungslayout auf CakePHP und TCPDF steht. Es war ein extrem harter und zäher Kampf. Wenn ich das jemals als Kundenprojekt haben sollte bzw. die verausgabte Arbeitszeit in Entlohnung umrechnen müsste – ganz und gar schwindlig würde mir dann bei den astronomischen Beträgen. Zumal das ja niemand zahlen würde: 500 Euro für ein PDF-Layout. Die große Preisfrage: wie viele PDF´s müssten mit welcher Marge erstellt werden, damit sich das wieder rechnet? Ich kann jedenfalls meine bisherigen Bemühungen als Vorlage für die nächsten Projekte nehmen: sollte ich einen Auftrag mit PDF-Erstellung erhalten, so habe ich gleich eine Menge Erfahrung und eine Template in der Schublade liegen.

Und aus Sicht eines Designers ist das Layout der Dokumente sicher immer noch suboptimal. Aber es war so umständlich alles umzusetzen, dass ich froh bin, dass jetzt erstmal alles steht. Zwischendurch habe ich die nicht existente Dokumentation der Klasse verflucht. Es gibt allenfalls die Example-Files, die man als Kochbuch verwenden kann. Nur ist das meiste davon unbrauchbar für meine Zwecke: bunte Grafiken mit PDF erstellen… naja, vermutlich würde man da doch anders vorgehen. Was bei TCPDF echt nervte ist, dass HTML und CSS zwar unterstützt wird, aber auch nicht alle Attribute. Eine einfache Sache wie line-height war weder via CSS noch über TCPDF-Methoden zu realisieren.

Veröffentlicht unter Programmierung | 6 Kommentare

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.
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