Ich liebe alternative Sichtweisen auf Alltägliches. Darum habe ich damals natürlich (wie es sich für Tecchies gehört) die Bücher von Douglas Adams verschlungen. Gerade bin ich auf einen ganz netten Artikel auf Smashing Magazine zum Thema Brand/Interface Design/User Experience gestossen: “Brand = User Experience: The Interface of a Cheeseburger“.
Obwohl sie theoretisch aufeinander aufbauen sollten, sind Brand Design, User Interface Design und die tatsächliche User Expierence in der Praxis meist nur locker verbunden. Die genannten Beispiele Mc Donalds und Google sind jedoch ganzheitlich auf ein ganz ursprüngliches Verhaltensmuster ausgerichtet. Genauso wie beim Stillen eines Babys, geht es hier darum, ein momentanes Bedürfnis, ohne groß nachzudenken sofort zu befriedigen.
Das ist natürlich keine tiefschürfende Erkenntnis, aber gut, wenn man sich so etwas hin- und wieder bewusst macht. Es hilft, den Fokus in eigenen Projekten besser setzen zu können.
Dirk Ollmetzer | Saturday, 29 August 2009 |
DevelopmentDas Schöne an Webapplikationen ist, daß man sie im Prinzip auf jedem Betriebssystem entwickeln kann. Tatsächlich nutze ich je nach Lust und Laune mal Windows (XP) oder meinen Apple Mac dazu. Die zugrundeliegende Software (Apache, PHP, MySQL) läuft auf jedem gängigen Betriebssystem. Dasselbe gilt auch für Eclipse als meiner bevorzugten IDE, Subversion als Versionsverwaltungstool und Firefox als (für die Entwicklung) wichtigster Browser. Ebenfalls sind viele sinnvolle Firefox-Plugins wie Selenium für automatisierte UI-Tests und Firebug platformübergreifend vorhanden. Alles wirklich toll, aber eines habe ich bisher sehr schmerzlich vermisst: Den genialen HTML-Validator von Marc Gueury.
Dieser läuft angeblich nicht auf Apples OS X, wenn man der Plugin-Seite von Mozilla glauben darf. Stattdessen werden dort Plugins angeboten, die entweder eine Viertelstunde zum Prüfen einer einfachen HTML-Seite benötigen, oder einfach den W3C Validator benutzen. Ersteres ist unbrauchbar und das zweite im Prinzip auch, wenn man lokal entwickelt – was man eigentlich immer tun sollte – und die Seiten daher aus dem Internet nicht erreichbar sind. Was kann man also tun?
Die Lösung ist so einfach, daß ich leider eine ganze Ewigkeit gebraucht habe, um drauf zu kommen: Mozilla sagt nicht die Wahrheit!
Das Plugin ist nämlich sehr wohl für Mac OS X erhältlich (und für Linux, FreeBSD und OpenBSD). Man muss dazu nur die Homepage vom Autor aufsuchen, auf die Downloadseite (http://users.skynet.be/mgueury/mozilla/download.html) gehen und die richtige Version aussuchen – Voilà !
Ich hoffe, ich konnte dem Einen oder der Anderen mit diesem kleinen Hinweis helfen.
Bei der Konzeption größerer Websites ist es sinnvoll, Techniken wie Prototyping, Storyboards oder Wireframes zu nutzen. Ein solches Vorgehen ist auf den ersten Blick ein aufwändiger Zwischenschritt, der von vielen Kunden als teuer, langsam und unnötig abgelehnt wird. In den 14 Jahren, die ich im Internetgeschäft tätig bin, hat sich aber gezeigt, daß häufig genau die Kunden einem vernünftigen Prototyping besonders ablehnend gegenüberstehen, die es am dringendsten gebrauchen könnten um sich der Knackpunkte ihrer meist ungenauen Anforderungen überhaupt bewusst zu werden.
Denn genau darum geht es: Einerseits die Anforderungen, die die Programmierer umsetzen müssen so weit zu konkretisieren, daß der Interpretationsspielraum möglichst gering wird, aber vor allem darum, konzeptionelle Schwachpunkte bereits vor der Realisierung zu erkennen und zu beheben, weil es in dieser Phase wesentlich einfacher und schneller ist, als mitten in der Programmierung.
Welche Technik konkret eingesetzt werden sollte, hängt dabei vom konkreten Projekt und den Beteiligten ab. Für einfachere Websites ist es häufig ausreichend, Layouts und Wireframes auf Paiper zu zeichnen und mit dem Kunden abzustimmen. Für komplexe Webanwendungen können dagegen HTML Prototypen sinnvoll sein. Meist dürfte der Aufwand dazwischen liegen.
Als ich bei I-D Media vor 10 Jahren auf großen Webprojekten als Entwickler tätig war, hatten wir häufig grafisch extrem reduzierte Storyboards, die in Powerpoint erstellt wurden, als Produktionsvorlagen. Schlicht, aber Wirkungsvoll. Iconmobile, bei denen ich 2006 meine Diplomarbeit über Mobile Communities schrieb, setzten häufig Omni-Graffle ein. Jeder hat halt seine eigenen Vorlieben. Gerade bin ich über eine Website gestolpert, die sich mit dem Thema Wireframes beschäftigt und die ich für recht gelungen halte:
Wireframes Magazine.
Unter anderem werden dort auch einige spezialisierte Tools vorgestellt, von denen ich mir demnächst wohl das Eine oder Andere genauer ansehen werde.
Neulich standen wir bei einem größeren PHP Projekt, das auf dem Zend-Framework basiert, vor der Aufgabe, die Systeme so einzurichten, daß eine flexible Releaseplanung möglich wurde. Die übliche Trennung in Live, Staging und Developmentsystem und das SVN Repository reichten nicht mehr aus, weil die Anforderungen gestiegen waren.
Die oberste Priorität bei dem Projekt ist Stabilität. Gleichzeitig hagelt es aber ununterbrochen Sonderwünsche von verschiedenen Fachabteilungen. Der einfache entwickeln-testen-livestellen Workflow genügt so nicht. Was ist also zu tun?
Wir entschieden uns, das Projekt grundsätzlich in einen Entwicklungszweig (devel) und einen stabilen Produktionszweig (stable) zu teilen. Dementsprechend gibt es für den Stable-Branch die übliche Devel-Staging-Live Umgebung. In diesem Zweig werden ausschlißelich Bugfixes gepflegt, während Funktionsänderungen und Ergänzungen ausschließlich in dem Devel-Zweig vorgenommen werden, in dem jeder Entwickler einen eigenen Arbeitsbereich hat.
Das ist zwar schon besser, löst aber noch nicht die Problematik mit den Anforderungen der Fachabteilungen, die häufig nicht auf ein neues Major Release warten wollen oder können. Also haben wir die bisherige Applikation in Fachanwendungen und gemeinsam genutzte Basisfunktionen geteilt. Nun stellte sich die Frage, wie man das bei einer Zend FW-basierten Anwendung macht und wie die Versionsverwaltung dafür aussehen kann. Schließlich liegen alle Controller in einem Verzeichnis, alle Models in einem Verzeichnis und alle Views ebenfalls in einem Verzeichnis.
Refactoring
Die Lösung ist, alle Controller einer Fachanwendung in ein eigenes Unterverzeichnis zu packen und dasselbe mit den Models und den Views zu tun. Dementsprechend ändert sich selbstverständlich die Benamung von Dateien, Klassen und URLs. Ein fiktives Beispiel:
Der Controller ‘Abrechnung‘ gehört zur Fachanwendung ‘Bestellungen’. Nun lag also bisher im Verzeichnis ‘application/controllers/‘ die Datei ‘AbrechnungController.php‘ mit der Klasse ‘AbrechnungController‘. Die URL lautete dementsprechend ‘http://servername/abrechnung/‘.
Nach dem Umbau liegt die Datei ‘AbrechnungController.php‘ in dem Verzeichnis ‘application/controllers/Bestellungen‘ und die Klasse heißt nunmehr ‘Bestellungen_AbrechnungController‘. Die URL ist daher nun ‘http://servername/bestellungen_abrechnung/‘.
Versionskontrolle
Da nun die einzelnen Applikationteile getrennt sind, können sie jeweils in separate Subversion Repositories gepflegt werden. Genauer gesagt, gibt es weiterhin nur eines, das aber wie folgt eingerichtet wird: Im Repository gibt es für jeden Applikationsteil (Basis und Fachanwendungen) ein eigenes Unterverzeichnis. Innerhalb dieses Unterverzeichnisses folgt die üblich Einteilung in ‘trunk’ (Hauptzweig), ‘branches’ (Release) und ‘tags’. Das sieht dann ungefähr so aus:
repos/
base/
branches/
tags/
trunk/
bestellungen/
branches/
tags/
trunk/
rechnungswesen/
branches/
tags/
trunk/
Ein Release ist nun ein Branch von ‘base’ in das bestimmte Releases der jeweiligen Fachaanwendungen per svn:external eingebunden wird. Es ist also bspw. möglich, eine Version 1.2 mit ‘Bestellungen 0.7’ und ‘Rechnungswesen 1.4’ zusammenzustellen.
In den nächsten Wochen wird sich zeigen, ob die Praxis hält, was wir uns in der Theorie so schön ausgedacht haben.
Dirk Ollmetzer | Wednesday, 28 January 2009 |
DevelopmentIn dieser Folge der Reihe “PHP Applikationen entwickeln” beschäftigen wir uns damit, wie das Entwicklungsystem auf unserem Rechner eingerichtet wird. Zunächst besorgen wir uns die im letzten Artikel beschriebenen Werkzeuge und installieren sie. Das XAMPP-Paket sollte hierbei in das Wurzelverzeichnis installiert werden (also c:\xampp wie vom Installer vorgeschlagen). Alle anderen Pakete gehören ganz normal in das Programme-Verzeichnis. Das beschriebene Procedere gilt für Windows Rechner, ist aber auf Apple OS X oder Linux prinzipiell ähnlich.
Den Server installieren und einrichten
Die Installation ist denkbar einfach: Das Paket mit dem Installer herunterladen und starten. Nun ist eine lauffähige Installation auf dem eigenen Rechner vorhanden. Wenn man das Controlpanel öffnet lassen sich die Server einzeln starten und stoppen. Zuvor sollte man sich noch versichern, daß Skype nicht läuft, weil sonst der Port 80 für HTTP bereits blockiert ist. Starten wir nun den Webserver und den Datenbankserver.
Das XAMPP Control Panel
Beim ersten Start erscheint ein Popup mit der Frage, ob die Firewall MySQL und Apache blockieren soll. Die Firewall soll natürlich entsprechende Anfragen niemals blockieren.
Wenn nun im Controlpanel für Apache und MySQL ‘running’ angezeigt wird, läuft unser Entwicklungsserver bereits. Davon können wir uns ganz einfach überzeugen, indem wir den Browser öffnen und in der Adresszeile http://localhost eingeben. Localhost ist immer der eigene Rechner. Der Computer fragt also sozusagen sich selbst, ob er eine Website anbietet. Der Browser sollte nun die folgende Seite anzeigen:
XAMPP Startseite
Der Webserver funktioniert. Nun müssen wir ihn noch ein wenig an unsere Bedürfnisse anpassen.
PHP Einstellungen
Die PHP Einstellungen stehen in der Datei c:\xampp\apache\bin\php.ini. Grundsätzlich sind die voreingestellten Werte für ein Entwicklungssystem bereits sehr gut geeignet. Ich möchte jedoch einige Erweiterungen aktivieren, die im Grundzustand deaktiviert sind, z.B. CURL. Dazu öffne ich die Datei und suche nach extension=php_curl.dll. Zum Aktivieren dieser Erweiterung muß das Semikolon am Zeilenanfang entfernt werden. Dasselbe mache ich mit extension=php_json.dll. Die Änderungen werden nach den Neustart des Webservers übernommen.
Projekte sauber trennen mit VHosts
Schnell kommt man an den Punkt, an dem man mehr als ein Projekt auf dem Rechner hat. Wir benötigen noch ein paar Änderungen, um verschiedene Projekte auf dem eigenen Entwicklungssystem unabhängig voneinander lauffähig zu halten – am Besten unter ihrem jeweiligen Namen. Wenn ich also am Projekt ‘Homepage’ entwickele, möchte ich das im Browser auch unter http://homepage aufrufen können. Dazu muss man dem Computer zunächst beibringen, daß er selbst gemeint ist, wenn der Browser (oder ein anderes Programm) nach dem Rechner namens ‘homepage’ fragt.
Dazu müssen wir die Datei hosts etwas erweitern, in der der Computer immer zuerst nachsieht, wenn er wissen will, welcher Rechner (besser gesagt: welche IP Adresse) sich hinter einem Namen verbirgt. Bei Unix-Systemen (also auch Linux und Mac OS X) ist diese Datei /etc/hosts. Bei Windows ist das c:\windows\system32\drivers\etc\hosts. Öffnen wir nun also diese Datei mit einem einfachen Texteditor. Vermutlich ist der einzige Eintrag, der unter den Kommentaren steht, der folgende:
127.0.0.1 localhost
Am Anfang eines Eintrags steht die IP-Adresse und dahinter der dazugehörige Hostname.
Die Zahlenfolge 127.0.0.1 ist die IP-Adresse des sogenannten loopback-devices. Jede Anfrage an diese IP-Adresse geht immer an den eigenen Rechner, egal wieviele andere Rechner noch im Netz sind. Danach folgt der Hostname ‘localhost’. Jede Anfrage an localhost wird also aufgrund dieses Eintrags an den eigenen Rechner gestellt. Wenn wir nun möchten, daß auch der Aufruf des Rechners mit den Namen ‘homepage’ an den eigenen Rechner gestellt wird, müssen wir diese Datei erweitern. Dazu fügen wir die folgende Zeile hinzu und speichern die Datei.
127.0.0.1 homepage
Wenn wir nun im Browser http://homepage eingeben, sehen wir die bereits bekannte Startseite von XAMPP.
Nun müssen wir noch dem Apache beibringen, daß ein Aufruf mit diesem Namen andere Inhalte liefern soll. Dazu müssen wir namensbasierte virtuelle Hosts einrichten. Dazu öffnen wir die Datei c:\xampp\apache\conf\extra\httpd-vhosts.conf.
Zuerst werden die Kommentarzeichen vor dem Eintrag NameVirtualHost \*:80 entfernt.
Nun wird am Ende der Datei der folgende Eintrag gemacht:
ServerAdmin webmaster@localhost
DocumentRoot /xampp/htdocs/
ServerName localhost
Dadurch bleibt der bisherige localhost auch mit weiteren Vhosts weiterhin ansprechbar. Jetzt machen wir den Eintrag für unser Projekt ‘Homepage’:
ServerAdmin webmaster@localhost
DocumentRoot /xampp/htdocs/homepage/htdocs/
ServerName homepage
ErrorLog /xampp/htdocs/homepage/logs/error.log
CustomLog /xampp/htdocs/homepage/logs/access.log common
Bevor der Webserver neu gestartet wird, müssen die Verzeichnisse für den Vhost angelegt werden, weil sonst der Neustart mit einem Fehler abgebrochen wird. Zunächst also der Projektordner c:\xampp\htdocs\homepage\ und in diesem dann die beiden Unterverzeichnisse htdocs\ und logs\.
Das Vorgehen um weitere Vhosts anzulegen ist entsprechend.
Sprechende URLs
Um das ‘verbiegen’ oder umschreiben, von URLs zu ermöglichen, wie es heutzutage viele Webanwendungen voraussetzen, öffnen wir die Datei c:\xampp\apache\conf\httpd.conf und suchen die folgende Zeile:
LoadModule rewrite_module modules/mod_rewrite.so
Die Zeile darf nicht auskommentiert sein, damit das Modul mod_rewrite geladen wird. Jetzt müssen wir noch dafür sorgen, daß die Rewrite-Regeln in einer .htaccess Datei geändert werden können. Dafür suchen wir im Abschnitt ‘Main Server Configuration’ die Default-Einstellungen, die mit beginnen. In dem Abschnitt ändern wir nun AllowOverride None in AllowOverride All.
Den Editor einrichten
Das eclipse-Archiv entpacken wir an eine sinnvolle Stelle (z.B. nach c:\Programme\eclipse\) und starten das Programm. Den Workspace legen wir nach c:\xampp\htdocs\ – also das webroot-Verzeichnis unseres lokalen Webservers. Dort werden nun die einzelnen Projekte angelegt. Jetzt legen wir ein neues PHP-Projekt mit dem Namen ‘homepage’ an. Eclipse nutzt das bereits vorhandene Verzeichnis c:\xampp\htdocs\homepage\ und legt dort einige Projektdateien an.
Feintuning
Der Übersicht halber benenne ich die Datei c:\xampp\htdocs\index.php in index_old.php um und erzeuge eine einfache index.html mit allen Links zu den lokalen Ressourcen (Projekte, Tools und Dokumentation). So habe ich mit einem einfachen http://localhost immer die aktuelle Übersicht.
Nun ist die lokale Arbeitsumgebung eingerichtet und die Projektarbeit kann beginnen.
—
Bisherige Folgen:
1. PHP Applikationen entwickeln
2. PHP Applikationen entwickeln – Werkzeuge
Dirk Ollmetzer | Wednesday, 21 January 2009 |
DevelopmentDie Frage, wie eine vernünftige Entwicklungsumgebung einzurichten ist kommt einem Religionsstreit gleich. Jeder hat da so seine eigenen Ansichten und Vorlieben. Passend zum Jahresbeginn richtete ich mir ein PHP Entwicklungssystem neu ein. Ich möchte nicht nur erläutern was ich dabei gemacht habe, sondern vor allem auch warum ich es genau so gemacht habe.
Grundsätzlich mag ich Standards – bei Vorgehensweisen, Tools und Coding. Einige meiner Leser sind ja selber gestandene Entwickler und sehen das Eine oder Andere vielleicht anders, aber möglicherweise kann der Artikel den weniger Erfahrenen Anregungen geben.
Der komplette Entwicklungsprozess
Bevor man sich eine Entwicklungsumgebung einrichtet, sollte man sich darüber im Klaren sein, wie der komplette Entwicklungsprozess der PHP Anwendungen aussehen soll. Die eigene Entwicklungsumgebung soll sich natürlich möglichst nahtlos einfügen und den Prozess optimal unterstützen. Das folgende, dreistufige Grundprinzip hat sich bewährt:
Dev -> Stage -> Live
Das Livesystem – also das eigentliche Ziel – wird genau so eingerichtet, wie es zum Betrieb notwendig ist. Das Stagingsystem für die finale Qualitätssicherung und Abnahme durch den Kunden ist nicht öffentlich zugänglich, aber ansonsten identisch eingerichtet.
Die eigentliche Entwicklung findet dezentral auf den lokalen Rechnern der Programmierer statt. So ist gewährleistet, daß sich die Entwickler nicht mit den laufenden Änderungen gegenseitig in die Quere kommen. Die Zusammenführung des Codes findet über das Versionskontrollsystem statt. Zu beachten ist, daß sich alle Programmierer auf gemeinsame Standards zu Codingstyle und Benamung von Klassen, Methoden und Variablen einigen.
Im Folgenden betrachte ich ausschließlich die lokalen Entwicklungssysteme und klammere die Frage nach Live und Stagingserver aus, um den Umfang des Artikels nicht völlig zu sprengen.
Werkzeuge
Als Betriebssystem verwende ich Windows XP. Unter Mac OS oder Linux ist das Setup aber ähnlich. In der Tat habe ich auch meinen Apple vergleichbar eingerichtet. Ich nutze ausschließlich Open-Source Werkzeuge, von denen der größte Teil auf allen wichtigen Betriebssystemen laufen. Es werden folgende Werkzeuge benötigt:
- Die Serverumgebung
Die Basis eines PHP Entwicklungssystems ist natürlich der Webserver mit PHP. Meistens gehört auch eine Datenbank dazu. Im Regelfall wird man zur Kombination aus Apache Webserver, PHP und MySQL greifen, obwohl aus besonderen Gründen natürlich auch andere Kombinationen, wie z.B. LightHTTPD, PHP und PostgreSQL sinnvoll sein können. Für ersteres spricht, daß es eine Standardkombination bei fast allen Hostern ist und es einfache, vorkonfigurierte Pakete für Windows, Mac und Linux gibt. Für mich hat sich der Einsatz von XAMPP bewährt. Es enthält so ziemlich alles, was man auf einem Webserver so alles brauchen kann. So sind z.B. in der Windows Version auch PERL, ein FTP- und ein Mailserver enthalten. Ebenso weitere Tools wie PHPMyAdmin, Webalizer und eAccelrator. Neben der einfachen Installation war für mich auch wichtig, daß sich alles ebenso einfach wieder entfernen lässt. Das Paket ist hier zu bekommen:
http://www.apachefriends.org/de/xampp.html
- Webbrowser mit Entwicklerunterstützung
Um Websites und Webanwendungen entwickeln zu können, benötigt man auf jeden Fall auch einen bunten Strauß an verschiedenen Webbrowsern. Ein absolutes Muß ist der Mozilla Firefox, weil er für alle wichtigen Betriebssysteme verfügbar ist, einen recht hohen Marktanteil hat, sich im Gegensatz zum Internet Explorer recht standardkonform verhält und einige wichtige Erweiterungen existieren, die das Entwicklerleben vereinfachen. Ich habe mindestens den HTML-Validator von Marc Gueury, die Web Developer Toolbar und Firebug installiert. Zusätzliche Browser zum Testen können natürlich auch nicht schaden. Firefox ist hier erhältlich:
http://www.mozilla.com
- Editor zu Codeeingabe
PHP-Skripte kann man prinzipiell mit jedem beliebigen Texteditor entwickeln, der reinen Text in ASCII und UTF-8 Codierung speichern kann. Für mittlere und größere Projekte nutze ich aber gerne eine IDE, die Komfortfunktionen, wie Projektverwaltung, Code-Vervollständigung, Autoformat und Weiteres bietet. Richtig toll ist es zum Beispiel, wenn man seinen Code vernünftig kommentiert und die IDE beim Schreiben eines Funktionsaufrufs automatisch die Parameter mit Erläuterung bereithält. Der einzige Nachteil ist, daß man mit einer IDE nicht ‘mal eben’ eine einzelne Datei bearbeiten kann, die nicht im Projektkontext steht. Also benötigt man einen einfachen Editor (z.B. Notepad++ oder UltraEdit) für kleine schnelle Änderungen und eine IDE für das Projekt.Mittlerweile bin ich ein richtiger Fan von Eclipse geworden. Eclipse läuft auf allen wichtigen Betriebssystemen, ist mächtig, erweiterbar und kostenlos. Es wurde zwar ursprünglich für die JAVA-Entwicklung programmiert, aber mittlerweile gibt es eine gut an PHP angepasste Version. Diese ist hier zu bekommen:
http://www.eclipse.org/pdt/
http://notepad-plus.sourceforge.net/de/site.htm
- Versionskontrolle
Als Versionskontrollsystem bietet sich Subversion an. Hier soll es nicht darum gehen, wie man sich einen Server und ein Repository anlegt. Falls man ein Open Source Projekt beginnt, kann man sich ein entsprechendes Repository z.B. bei Sourceforge oder Freshmeat anlegen. Man benötigt auf seinem Entwicklungssystem jedoch noch einen entsprechenden Client um auf das Repository zugreifen zu können. Es gibt entsprechende Plugins für Eclipse. Auf Windows-Maschinen verwende ich jedoch lieber TortoiseSVN, das sich als Erweiterung in den Dateiexplorer integriert. Somit kann ich Subversion auch ausserhalb meiner PHP Projekte verwenden. Tortoise SVN gibt es hier:
http://tortoisesvn.tigris.org
- Grafikwerkzeuge
Ein Grafikprogramm sollte man immer zur Hand haben. Sei es, um Fotos anzupassen, Hintergrundgrafiken zu bearbeiten oder Icons zu erstellen. Man muss dazu nicht unbedingt die teuren Werkzeuge Photoshop und Illustrator aus dem Hause Adobe nutzen. Ich benutze seit Jahren gerne das wesentlich günstigere PainShopPro. Es sind natürlich auch gute Open-Source-Werkzeuge, wie GIMP für Bildbearbeitung und Inkscape für Vektorgrafiken erhältlich.
http://www.gimp.org
http://www.inkscape.org
- Serverzugriff
Nun benötigen wir noch zwei kleinere Programme um unsere Projektdateien auch auf den Staging- und den Liveserver übertragen zu können und dort ggf. kleinere Anpassungen vornehmen zu können. Zur Übertragung von Dateien nutze ich WinSCP, das sowohl das normale FTP, als auch das verschlüsselte SCP beherrscht. Um den Server auf der Kommandozeile steuern zu können nutze ich das bewährte PuTTY, das sowohl telnet als auch verschlüsselte SSH-Verbindungen ermöglicht.
http://winscp.net/eng/docs/lang:de
http://www.chiark.greenend.org.uk/~sgtatham/putty/download.html
- Dokumentation
Um das eigene Entwicklungssystem zu vervollständigen, ist es sinnvoll, die Dokumentation griffbereit zu haben, falls man schnell mal etwas nachsehen will und gerade nicht online ist. Ich habe mindestens die folgende Dokumentation auf dem Rechner:
SelfHTML, nicht mehr ganz frisch, aber immer noch sehr nützlich für Fragen zu XHTML, CSS und Javascript.
http://aktuell.de.selfhtml.org/extras/download.shtml
http://www.php.net/download-docs.php
http://dev.mysql.com/doc/#refman
Die wichtigsten Werkzeuge zur Entwicklung von Webanwendungen haben wir nun zusammen. Je nach Projekt kommen natürlich noch weitere dazu, auf die ich hier aber nicht weiter eingehen möchte. In der nächsten Folge wird es darum gehen, wie man die Software einrichtet um mehrere Projekte nebeneinander bearbeiten zu können.
—
Bisherige Folgen:
1. PHP Applikationen entwickeln
Dirk Ollmetzer | Wednesday, 21 January 2009 |
DevelopmentIn letzter Zeit waren meine Artikel in diesem Blog überwiegend persönlicher, wirtschaftlicher oder politischer Natur. Ursprünglich sollte dieser Blog aber einen eher technischen Schwerpunkt haben. Daher ist es an der Zeit, wieder ein bischen aus dem Nähkästchen zu plaudern. Zur Zeit verdiene ich meine Brötchen mit der Entwicklung von Webapplikationen in PHP. Daher ist es naheliegend und durchaus sinnvoll, wenn ich mit einigen Artikeln einen kleinen Einblick in meine persönlichen Präferenzen zu diesem Thema gebe.
Man kann mit PHP genausogut kleine, nützliche Skripte, aber auch großen Dienste, wie Flickr bauen. PHP ist toll, weil man schnell Ergebnisse erzielen kann und alle Freiräume hat. Genau deshalb ist PHP aber auch ein Alptraum. Man kann auch ohne große Vorkenntnisse eben schnell mal was zusammenpfriemeln. Daher gibt es so viele unsichere und schlecht zu pflegende Software in PHP.
Weil es eine Million mögliche Wege gibt, wie man ein Problem lösen kann, hat auch jeder erfahrene PHP-Entwickler seine eigenen Methoden und Techniken entwickelt. Daher ist es mitunter recht schwierig, ein gut harmonierendes Entwicklerteam zusammenzustellen.
Dies ist der erste Artikel einer kleinen Serie an deren Ende ein eigenes Framework für eigene Webapplikationen stehen wird. Ich bin mir natürlich durchaus darüber im Klaren, daß man vieles erheblich anders bewerten und auch sehr deutlich anders machen kann. Meine Meinung ist jedoch nicht aus der Luft gegriffen, sondern basiert auf Erfahrungen, die ich mir bei verschiedensten Web-Projekten in den letzten 14 Jahren erarbeitet habe. Am besten versteht der geneigte Leser das Folgende als Anregung oder Diskussionsbeitrag.
Beginnen werde ich im nächsten Artikel mit den Grundlagen: Dem Einrichten einer PHP Entwicklungsumgebung.
Heute feiere ich ein kleines Jubiläum: meinen 500. Blogartikel. WOW! Das hätte ich mir nicht träumen lassen, als ich Mitte 2006 mit dem Bloggen angefangen habe. Eigentlich wollte ich damals nur ein paar Freunde und Komilitonen auf dem Laufenden halten, während ich meine Diplomarbeit vorbereitet habe. Es sollte “irgendwas mit Handies oder so” werden. Daher auch der Untertitel “tiny little gizmos”. Wir sind doch alle in unsere kleinen elektronischen Spielzeuge vernarrt, oder? Diesen Artikel schreibe ich ja auch gerade auf meinem Mini-Notebook während ich im Zug sitze.
Das Diplom habe ich Anfang 2007 dann auch problemlos bekommen. Da mir das Bloggen tatsächlich richtig Spass gemacht hat, wollte ich danach nicht einfach so sang- und klanglos wieder damit aufhören. Der thematische Schwerpunkt hat sich zwar ein bischen verschoben, aber es ist ein reines Hobbyprojekt geblieben. Mehrere Angebote für Werbung auf meiner Seite habe ich abgelehnt. Ich schreibe nur über Sachen, die mich bewegen und zwar genau so, wie mir der Schnabel gewachsen ist. Auf die geschätzten €2,45 pro Monat kann ich da getrost verzichten. Aber genug der Vorrede.
Freibier! Oder noch besser: freie Software!
Zur Feier des Tages gebe ich heute einen aus – und zwar einen Download ;-)
Mein Diplomthema war “mobile community” und seit Anfang 2006 entwickle ich auch an einer dementsprechenden Software: zzap. Mittlerweile ist die Software in der 4. Version angekommen und ich habe mich dazu entschlossen, zzap als Open Source unter der GPL freizugeben. Seit heute gibt es die Version 0.4.148 zum Download. Eine kurze Aufzählung der Features von zzap:
- Multichannel – Unterstützung von Web, iPhone und normalen Handies.
- Multilanguage – Deutsch und Englisch sind serienmäßig. Weitere Sprachen sind leicht hinzuzufügen.
- Connectivity – Einbindung in Blog und twitter möglich.
- Enhanced Content – Kurznachrichten plus Links plus Fotos.
- Easy Setup – Ein Installationsscript hilft beim Einrichten der Software.
- Extendable – Erweiterungsfähig durch Plug-in Architektur.
- Multitier, Schichtentrennung, MVC oder wie das jetzt gerade heisst. Bei meiner Software ist Ablaufsteuerung, Datenzugriff und Ausgabe jedenfalls ordentlich getrennt.
Würde mich freuen, wenn der Eine oder Andere die Software mal ausprobiert. Feedback ist allerherzlichst willkommen. Bei Interesse lasse ich mich auch gerne in Gespräche auf der MBC09 (Micro Blogging Conference) verwickeln.
Download: zzap V0.4.148 (376 KB)
Wie krank ist das denn? Angeregt durch den Nostalgievortrag neulich auf dem 25C3 habe ich mir mal ‘nen schönen Commodore64 Emulator (V.I.C.E.) und ‘nen Crossassembler (ACME) besorgt und schaue gerade, wieviel 6502 Maschinensprache ich noch kann. Das ist ja schon bekloppt genug, dachte ich so aber nun stosse ich auch noch auf das hier:
Einen Sinclair ZX Spectrum Emulator – in Javascript!!!
Seit einiger Zeit gibt es ja den Firefox 3 Browser bei Mozilla. Übergangsweise wird der 2er noch mit Updates versorgt. Natürlich möchte Mozilla am liebsten, daß alle den neuen Browser benutzen, damit sie nicht mehr beide weiter pflegen müssen. So weit, so verständlich.
Ich bin bisher noch nicht auf den 3er umgestiegen, weil ich so einige Neuerungen nicht mag und mit dem 2er eigentlich recht zufrieden war. Seit einiger Zeit stelle ich fest, daß der Firefox 2 extrem häufig hängen bleibt – Und zwar sowohl auf dem Mac, als auch unter Windows. Das setzte ungefähr an, nachdem der Browser damit aufgehört hat, penetrant auf den Nachfolger hinzuweisen.
Ist das jetzt blöder Zufall, habe ich meine Kisten nicht richtig im Griff oder ist das extrem ekliges Zuckerbrot-und-Peitsche-Marketing von Mozilla, wie es sich nicht mal MS oder Apple trauen?
Hat jemand ähnliche Erfahrungen gemacht, oder tritt das Problem nur bei mir auf?
« Previous Page — Next Page »