Seit meinen Anfängen um 1998 hatte ich eigentlich immer nur mit dem Editor UltraEdit von IDM Computer Solutions gearbeitet, da dieser sich eben hervorragend für sämtliche Sprachsyntax eignet. Da ich um 2005 allerdings vermehrt nur OOP programmierte orientierte ich mich im Jahre 2007 zu einem PHP speziellen Editor und entschied mich für Zend Studio Version 5.5. Zwischendurch verwendete ich immer wieder auch mal Eclipse, hatte aber mit der JRE teils heftige Probleme und Ausfälle, die mich immer wieder zurück warfen. Es ging mir hauptsächlich um die vielen Features, die diese Editoren geboten hatten, wie beispielsweise Code-Coverage (Erkennung von implementierten Funktionen & Klassen), einheitliche Leerzeichen Konvertierungen und Syntax, Erkennung von PHPDoc-Formaten usw.. Zend Studio machte ein hervorragenden Eindruck und auch das im Jahre 2008 vorgestellte Zend Studio for Eclipse war sehr beeindruckend. So entschied ich mich, darauf umzusteigen, auch wenn mir eigentlich die 299,- € für die Professional Version ziemlich heftig störten.

In den Jahren der Verwendung von Zend Studio störte mich aber am meisten, dass die grundsätzlich, verbesserten Versionen (7, 8 und letztes Jahr die Version 9) immer genau in einem Zeitraum herauskamen, bei dem ich meine Upgrade-Lizenz auch immer wieder mit den teuren Preis von 299,- € erneuern musste, so dass ich eigentlich immer wieder durch die heftigen Schwierigkeiten in den letzten Wochen vor Versionsrelease gezwungen war, das neue Upgrade zu kaufen.  Im Grunde war es die Software auch immer Wert, denn allein die Zusammenarbeit mit den wichtigsten Elementen bei der Programmierung mit PHP wie ordentliche Syntax, PHPDoc-Integration, Debugging usw. machten das echt total wett, allerdings mit der neusten Version 9 hatte ich dann nur noch heftig Probleme, die mich unendlich viel Zeit kosteten. Unter anderem ist mit Zend Studio immer wieder

• während der Entwicklung an einem Projekt ohne Meldungen plötzlich abgestürzt,
• Remote Projekte waren plötzlich nicht mehr verbunden / vorhanden und mussten immer wieder neu eingerichtet werden,
• mitten in der Entwicklung bei versehentliches Drücken einer bestimmten Tastenkombination war der komplette Code der aktuellen Datei völlig unwiderruflich zerstört
• Sondertasten wie das Euro- und At – Zeichen (€ / @) bzw. eigentlich alle Sonderzeichen die mit AltGr in Verbindung stehen, funktionierten nicht mehr,
• SVN Projekte waren plötzlich voll mit Konflikten (oft völlig unbegründet) und konnten schlicht nicht mehr verwendet werden
• und viele andere Kleinigkeiten mehr

Wenn man kundenorientiert programmiert und auf einen absolut zuverlässigen Editor angewiesen ist, sind solche Dinge schlicht ein absolutes No-Go! Es spielte auch keine Rolle ob ich Zend Studio auf Windwos oder Ubuntu (mit OpenJDK oder Sun) ausführte, in allen Umgebungen gab es Probleme, denn es war naheliegend, die Schuld der Probs auf Java zu schieben. Allerdings wurden andere Editoren basierend auf Java (wie beispielsweise Netbeans oder Eclipse) teils völlig einwandfrei oder mit anderen viel kleineren, unerheblicheren Problemen ausgeführt. Hoch summiert kostete mich also diese Software jedes Jahr locker mehrere Tausend Euros, anstelle diese 299,- Lizenzgebühr. Offenbar war ich auch absolut nicht der Einzige mit diesen Problemen, denn es existieren tausende Blog- und Forenbeiträge, in denen über Probleme mit Zend Studio geschrieben wurde (und natürlich auch Lösungen, wovon einige funktionierten, andere wiederum nicht). Natürlich gibt es zahlreiche Entwickler, die offenbar mit Zend Studio überhaupt keine Probleme hatten / haben und vollkommen damit zufrieden waren / sind. Ich war und bin es aber absolut nicht mehr. Mir hat diese Software einfach schlicht weg viel zu viel Geld und Nerven gekostet.

Nach nun ein halbes Jahr unentschlossene Propiererei mit unterschiedlichster Software wie Netbeans, PHP – Eclipse und anderen entschied ich mich in den letzten 30 Tagen (Evolution-Period) für JetBrains PHPStorm. Es gibt einige Kleinigkeiten, mit denen ich dort nicht zurecht komme, die aber offenbar auch in Arbeit sind bzw. auch das Forum mit unheimlich vielen, guten Tipps gefüllt sind (ich allerdings schlicht noch nicht die Zeit hatte, mich damit besonders zu befassen). Andererseits hindert mich dieser Editor in absolut keinster Weise und arbeitet absolut hervorragend ohne irgendwelche Störungen – und das unter Windows wie auch das aktuelle Ubuntu 11.10. Meine wichtigsten Forderungen werden mit PHPStorm absolut erfüllt (PHPDoc, Code-Coverage, Debugging, Versioning) und was noch viel wichtiger ist, diese Software kostet nur ein Drittel von dem, was Zend Studio kostet. Ich möchte hier ganz klar eine Empfehlung für diese Software aussprechen und bedauere, dass ich nicht schon viel früher diesen Editor getestet habe.

Fazit
Jeder Programmierer hat seine (gewohnten) Eigenheiten und braucht deshalb einen für sich zugeschnittenen Editor. Am wichtigsten allerdings ist, dass man ungestört seine Projekte umsetzen kann, nützliche Hilfsmittel – die Zeitersparnis bedeuten – benutzen kann, damit die Konzentration voll auf die anstehende Aufgabe vorhanden bleibt. Insgesamt aber ging mir die letzten Jahre auch die Politik von Zend ziemlich auf den Senkel. Nicht nur der Editor, auch Zend Guard, Zend Server oder andere Komponenten sind meiner Ansicht nach total Buggy und wirklich alles von Zend zielt völlig auf Kommerz ab – und dass dann auch noch zu völlig überzogenen Preisen meiner Meinung nach. Es gibt zu Hauf kostenlose Tools zum Debuggen und Entwickeln; also frage ich mich doch berechtigt, wieso meint ein israelischer Verein für eine Zusammenfassung namens Zend Server über 1000,- € für so etwas zu verlangen? Nur damit das Ganze irgendwie etwas schick unterhalb einer Oberfläche zusammengefasst ist? Mal ganz zu schweigen davon, dass damit auch normale (gewohnte) Server-Umgebungen komplett ausgehoben werden (als wenn man auch nur Apache + PHP auf den Server einsetzt) und damit erst die richtig heftigen Probleme los gehen. Welcher Server-Admin zahlt dafür Geld, damit der noch mehr teils heftige Probleme hinzu bekommt, die viel Zusatzarbeit bedeuten?

Die Entscheidung, mich vollkommen gegen Zend zu stellen (und das betrifft mittlerweile auch das Zend-Framework) ist wohl durchdacht und nicht nur in den letzten 30 Tagen durch die Probleme verursacht worden. Seit dem exzessiven Einsatz von Zend-Software (mal abgesehen vom PHP-Kern) hattee ich durchweg ständig Probleme bei der Entwicklung und meine Konzentration auf den Job verlagerte sich immer häufiger auf irgendwelche Zend – eigens verursachte Schwierigkeiten (die natürlich nicht in Minuten zu lösen sind, sondern teils sogar tagelang Ausfall bedeuten) als mich auf die Arbeit zu konzentrieren. Daraus schließe ich, dass Größe eines Unternehmens fast immer auch gleich-bedeutent mit einer gewaltigen Verschlechterung der Root Leistungen einhergeht. Das Management von Zend sollte meiner Meinung nach gewaltig aufpassen, dass sich deren Finanzkurven nicht urplötzlich mal umdrehen, so wie Sie mit buggy- Software um sich schmeißen und dafür auch noch solch teure Preise auffahren.

Just my two cents

Interne Daten-Verwaltung für die Momo Net GmbH für den Import von Statistiken, Bearbeitung verschiedener Parameter, die dann statistisch ausgewertet und als CSV wiederum exportiert werden können. Das gesamte System basiert auf das eigene jcBase-Framework basierend auf Zend-Framework MVC und verarbeitet CSV Dateien.

Mein WordPress Plugin Jc-Wp Project stellt simpel die Möglichkeit zur Verfügung, einen animierten Ladebalken als Projektstatus visuell in Artikeln / Seiten darzustellen. Ein Sidebar-Widget rundet die ganze Sache ab. Im Folgenden wird hier das Plugin beschrieben. Den Download des Plugins findest Du im WordPress Plugin-Repositary.

Meine Warenwirtschaft / Fakturierung mache ich seit fast zwei Jahren nur noch mit gSales-2, welches allerdings über keine Buchhaltung verfügt. Da ich als Freelancer lediglich eine einfache Einnahme / Ausgabe Buchhaltung machen muss, machte ich dies in den letzten Jahren mittels Excel / bzw. Calc, hatte aber stets auf dem letzten Drücker am Quartalsende diese immer auf den letzten Stand gebracht. Vor ca. 6 Wochen begann ich dann mit einem Programm als OpenSource für eine einfache Einnahme / Ausgabe Buchhaltung, die sich mittels gSales-2-API die Rechnungen und Kunden holt.

Das bei Sourceforge gehostete Open Source Projekt ist bereits im mittleren Alpha-Status. Da ich das Projekt lediglich nebenher nur weiter entwickeln kann und bisher sich noch kein weiterer Entwickler für dieses Projekt gefunden hat, wird es sicherlich noch bis Jahresende dauern, bis das Projekt in die Beta-Phase einlenkt. Fortschritte des Projekts werden hier immer wieder mal veröffentlicht. Verfolgen kann man das aber hauptsächlich auf der Projektseite bei Sourceforge.

Portal mit Mobil-Frontend & Administration
Auf Basis des eigenem Frameworks jcBase (basierend auf ZendFramework) im MVC wurde dieses Anzeigenportal inkl. Administration und Mobil-Frontend nach Kundenvorgaben vollständig für die wondo GmbH & Co. KG in ca. 110 Mannstunden umgesetzt.

Screenshot des Mobil-Frontends

Das eigene Framework jcBase ist in der ersten Beta-Version erschienen. Mittels diesem Framework basierend auf das Zend-Framework 1.11 und der MVC-Architektur kann somit in fast jedem Projekt bis zu 40% des Systems mittels dieser Grundlage innerhalb weniger Stunden aufgesetzt werden. Somit ist dem Kunden mit einer geringeren Entwicklungszeit und somit weniger Kosten geholfen und der Support jedes Projekts ist um ein vielfaches geringer, da es die Produktivität, Skalierbarkeit, Sicherheit und Performance um ein Vielfaches steigert. Eine Roadmap sowie verschiedenste Dokumentationen zu dem jcBase werden folgen.

Fügt man in einer jQueryMobile Webseite dynamisch Inhalte hinzu, in der jQM-Elemente definiert sind (z.B. Buttons, etc.) werden diese nicht mit dem jQM-Markup versehen und sehen deshalb visuell nicht genauso aus, wie die zuerst dargestellten Elemente. Der Grund ist, dass standardmäßig jQM alle Seiten mittels Ajax in das aktuelle DOM lädt und die darin befindlichen Elemente mit dem passendem Markup und Theme versieht. Werden allerdings dynamisch per Ajax dem aktuellen DOM-Dokument Elemente hinzugefügt, konnten diese Elemente nicht mit dem passendem Markup versehen werden, ohne die gesamte Seite zu aktualisieren oder aber zumindest ähnlich wie bei den Form-Elementen ein refresh – Event zu feuern.

Mit der in der kommenden Woche erscheinenden Beta2 von jQueryMobile gibt es das neue Event create, welches an jedem Element gefeuert werden kann. Dazu ist es erforderlich, dass neuste Package bestenfalls direkt in den Head wie folgt einzubinden:

<link href="http://code.jquery.com/mobile/latest/jquery.mobile.min.css" rel="stylesheet" type="text/css" />
<script src="http://code.jquery.com/jquery-1.6.2.min.js"></script>
<script src="http://code.jquery.com/mobile/latest/jquery.mobile.min.js"></script>

und in dem dynamisch erzeugenden Javascript-Content dieses Event mit trigger() anzuhängen:

var link = $("<a />").attr('href','#').attr('data-role','button').attr('data-theme','a');
$(link).appendTo('.selector').trigger('create');

In den letzten 14 Tagen stieg die Anzahl der Anfragen an mobilen Websites optimiert für Smartphones (iPhone, Android-Handy’s wie Samsung, LG, etc.) massiv an, was sicherlich auch an der “Empfehlungswut” der beiden Kunden liegt, für denen ich zuletzt solche Mobilesites realisiert habe (hierfür nochmals vielen Dank). Einer der ersten Fragen der Interessenten ist immer die Gleiche: Wieso eine mobile Website und keine richtige App?

Die Antwort liegt auf der Hand:

Da zahlreiche Immobilienmakler derzeit an einer mobilen Website interessiert sind, möchte ich den letzten Punkt genau daran verdeutlichen. Wenn Sie selbst Makler sind, stellen Sie sich doch mal folgende Fragen, die Sie sicherlich weit besser beantworten können, als ich: Wird der Interessent/Kunde nur bei Ihnen wegen Immobilien schauen, oder auch bei Konkurrenzmaklern? Wie viele Interessenten / Kunden haben Sie, die regelmäßig Immobilien kaufen, ja vielleicht sogar 2 oder mehr innerhalb des kommenden Jahres? Nun mal zur Frage direkt an Sie: Wieso sollte sich also dieser Interessent / Kunde eine App herunterladen und installieren, um ein mal (möglicherweise sogar nur dieses eine mal im Leben) bei Ihnen nach Immobilien zu schauen? Glauben Sie ernsthaft, dass sich der Interessent / Kunde nun die bereits existierenden 8 Apps von den derzeitigen Maklern mit Smartphone-Apps auf Mallorca herunterlädt und installiert, weil er nun gerade über einen Immobilien – Kauf nachdenkt?

Ich denke, hier macht es durchaus Sinn, anstelle von 5-stelligen Kosten für eine Native App doch lediglich im niedrigen 4-stelligen Bereich für eine viel zweckdienlichere und vor allem weitaus Kunden-freundlichere mobile Website zu setzen. Was meinen Sie?

Lesen Sie auch hier weitere statistische Zahlen über die Nutzung von Smartphones.

Das jQuery-Plugin Validate ist ein sehr nützliches Plugin zur Javascript-Validierung von Formularen und glänzt insbesondere damit, relative einfach schnelle Validierungsregeln in Formularen zu implementieren und dabei Meldungen auch in den wichtigsten Sprachen zurückgeben zu lassen. Andererseits ist dieses Plugin auch sehr mächtig und lässt sich sehr fein über Optionen im JSON-Format bei der Initialisierung fein einstellen.

Möchte man Validate auch in jQueryMobile einsetzen, merkt man spätestens beim ersten Absendetest des Formulars, dass die herkömmliche Implementierung in $(document).ready() nicht funktioniert und das Formular offenbar ohne Validierung abgesendet wird. Der Grund ist, dass das Plugin gar nicht geladen wird, arbeitet man mit Ajax-geladenen Seiten bei jQM, da $(document).ready() lediglich bei der Startseite einmalig ausgeführt wird und nicht bei jeder geladenen weiteren Seite per Ajax. Folgend muss das Plugin auf einer anderen Art initialisiert werden:

// Innerhalb der Seite, in der sich das Formular befindet:
$('#siteSelector').live('pageshow',function(){
  $('#formSelector').validate();
});

Im Anschluss funktioniert auch Validate in Formularen in jQM Seiten.

Bei einem aktuellem Projekt füge ich via Ajax in einem Ajax-generiertem Dom-Baum Buttons hinzu, die selbstverständlich wie der Rest der Seite mit jQueryMobile ge”theme”d aussehen sollte, es aber nicht so ist.

Das Problem sieht man auf anhieb, liest man sich die Doku durch. jQueryMobile theme’d die Buttons anhand der data-role und data-theme Attribute in den HTML-Tags, die bei der Initialisierung der entsprechenden Seite mit passenden CSS-Klassen versehen werden. Lädt man mit Ajax nachträglich Inhalte hinzu, die ebenfalls solche ge”theme”te Elemente enthalten, kann jQueryMobile die so ja auch nicht nachträglich mit den passenden Klassen versehen und an das gewünschte Theme anpassen. Ein Page-refresh ist hier nicht die Lösung, da die gesamte Site dann neu geladen wird, was in der Regel nicht passieren sollte (deshalb lädt man ja mit Ajax nach).

Die Lösung ist, keinen normalen Link (<a>-Tag) zu generieren, sondern direkt einen Button mit den Attributen data-role, data-theme und die Klassen ui-btn, ui-btn-corner-all, ui-shadow und ui-btn-up-a, wie:

$('#selector').live('tap',function(){
  $.mobile.showPageLoadingMsg();
  $.getJSON('/ajax.php',{options:'blah'},function(data){
   $.each(data,function(i,item){
      var button = $('<button />').attr('href','?page=eineseite&id='+item.id).attr('data-role','button').attr('data-theme','b').addClass('ui-btn ui-btn-corner-all ui-shadow ui-btn-up-b');
      $(this).append(button);
    });
  });
  $.mobile.hidePageLoadingMsg();
});

Bleibt nun noch abzuwarten, ob dieser Umstand noch in den kommenden Beta-Releases oder bis zum finalen Release behoben wird bzw. eine gute Lösung hierzu bereit steht.

Update 31.07.2011 In dem Artikel Dynamischer Content via Ajax in jQM beschreibe ich die Lösung, die mit der aktuellen jQM-Beta2 und dem neuem Event create das Problem behebt.