all-IT

Als Entwicklungs-Hardware sind Macs momentan ziemlich beliebt, läuft doch auf diesen Alu Beauties ein Betriebssystem, das auf Unix basiert.

Ein weiterer Grund dafür dürfte auch sein, dass die Entwicklungsumgebung Eclipse auf MacOs gut unterstützt wird. Dies gilt vor allem für Java (mit dem Java Development Tool – JDT). Aber auch PHP Webanwendungen lassen sich gut mit Eclipse und dem PHP Development Tool – PDT programmieren.

Das PDT bringt keinen eigenen PHP Interpreter mit. D.h., man muss selbst für einen Webserver mit PHP Modul sorgen. Auf dem Mac bekommt man das Rundum Sorglos Paket mit MAMP.

Möchte man auch PHP Scripts unter Eclipse ausführen, muss man die beiden miteinander bekannt machen. Doch zuvor verlangt Eclipse PDT nach einem Debugger. Zur Auswahl stehen der Zend Debugger, der leider nicht mit MAMP mitgeliefert wird und XDebug, dessen Modul zwar in MAMP integriert ist, bei mir aber nicht funktionierte.

Eine aktuelle Version von XDebug kann man sich über brew installieren.

brew install xdebug

Brew setzt zwar Xcode voraus, sollte aber auf keinem Entwickler-Mac fehlen. Eine Installationsanleitung gibt es auf github.

Doch zurück zu XDebug. Während der Installation wird man auf die nächsten Schritte hingewiesen:

To use this software:
  * Add the following line to php.ini:
    zend_extension="/usr/local/Cellar/xdebug/2.1.1/xdebug.so"
  * Restart your webserver.
  * Write a PHP page that calls "phpinfo();"
  * Load it in a browser and look for the info on the xdebug module.
  * If you see it, you have been successful!

Die php.ini, die MAMP mitbringt, lässt sich nicht mit normalen User Rechten editieren. Mit sudo geht es aber schon.

sudo vi /Applications/MAMP/bin/php/php5.3.6/conf/php.ini

Im Bereich [xdebug] dann die Direkive für das xdebug Modul hinzufügen:

[xdebug]
zend_extension="/usr/local/Cellar/xdebug/2.1.1/xdebug.so"

den Webserver durchstarten und den Erfolg wie oben beschrieben kontrollieren.

Funktioniert alles, muss man in Eclipse nur noch in den Einstellungen ein PHP Executeable konfigurieren um von dort aus PHP Scripts starten zu können.

Als Entwicklungs-Hardware sind Macs momentan ziemlich beliebt, läuft doch auf diesen Alu Beauties ein Betriebssystem, das auf Unix basiert. Ein weiterer Grund dafür dürfte auch sein, dass die Entwicklungsumgebung Eclipse auf MacOs gut unterstützt wird. Dies gilt vor allem für Java (mit dem Java Development Tool - JDT). Aber auch PHP Webanwendungen lassen sich gut mit Eclipse und dem PHP Development Tool - PDT programmieren. Das PDT bringt keinen eigenen PHP Interpreter mit. D.h., man muss selbst für einen Webserver mit PHP Modul sorgen. Auf dem Mac bekommt man das Rundum Sorglos Paket mit MAMP. Möchte man auch PHP Scripts unter Eclipse ausführen, muss man die beiden miteinander bekannt machen. Doch zuvor verlangt Eclipse PDT nach einem Debugger. Zur Auswahl stehen der Zend Debugger, der leider nicht mit MAMP mitgeliefert wird und XDebug, dessen Modul zwar in MAMP integriert ist, bei mir aber nicht funktionierte. Eine aktuelle Version von XDebug kann man sich über brew installieren. brew install xdebug Brew setzt zwar Xcode voraus, sollte aber auf keinem Entwickler-Mac fehlen. Eine Installationsanleitung gibt es auf github. Doch zurück zu XDebug. Während der Installation wird man auf die nächsten Schritte hingewiesen: To use this software: * Add the following line to php.ini: zend_extension="/usr/local/Cellar/xdebug/2.1.1/xdebug.so" * Restart your webserver. * Write a PHP page that calls "phpinfo();" * Load it in a browser and look for the info on the xdebug module. * If you see it, you have been successful! Die php.ini, die MAMP mitbringt, lässt sich nicht mit normalen User Rechten editieren. Mit sudo geht es aber schon. sudo vi /Applications/MAMP/bin/php/php5.3.6/conf/php.ini Im Bereich [xdebug] dann die Direkive für das xdebug Modul hinzufügen: [xdebug] zend_extension="/usr/local/Cellar/xdebug/2.1.1/xdebug.so" den Webserver durchstarten und den Erfolg wie oben beschrieben kontrollieren. Funktioniert alles, muss man in Eclipse nur noch in den Einstellungen ein PHP Executeable konfigurieren um von dort aus PHP Scripts starten zu können.

geschrieben von gklinkmann \\ tags: eclipse, macos, php

Das Versionskontrollsystem git wird immer populärer, so dass sich jetzt auch Google entschlossen hat git auf Google Code neben svn und mercurial zu unterstützen. Doch leider ist es mit einem einzigen Knopfdruck im Admin-Bereich von Google Code nicht getan.

Vor der Umstellung sollte man sein Projekt in einem separaten Verzeichnis sichern.

Nachdem man von svn auf git umgestellt hat, sollte man als erstes einen Reset des Repositories mit folgender Option durchführen:

HTTPS ist das einzige Protokoll, das Google für git unterstützt. Zur Authentifizierung sollte man sich ein Passwort generieren und die Zugangsdaten (auf Linux oder MacOs) in einer .netrc Datei im home Verzeichnis abspeichern.

Nun kann man das Git Repository von Google Code in ein neues Verzeichnis clonen. Danach die alten Projektdaten in das neue Verzeichnis kopieren, zu Git hinzufügen und lokal festschreiben (commit).

 > git clone https://code.google.com/p/<projectname>/ <projectname>
 > cd <projektname>
 > cp -R <pathToOldProject>/* .
 > git add .
 > git commit -m"inital import"

Was jetzt noch fehlt, ist der erste Upload zu Google Code.

 > git push origin master

Bei nachfolgenden Uploads ist die Angabe des Branches nicht mehr notwendig.

 > git push

Links:
Tutorial – Erste Schritte mit Git

Das Versionskontrollsystem git wird immer populärer, so dass sich jetzt auch Google entschlossen hat git auf Google Code neben svn und mercurial zu unterstützen. Doch leider ist es mit einem einzigen Knopfdruck im Admin-Bereich von Google Code nicht getan. Vor der Umstellung sollte man sein Projekt in einem separaten Verzeichnis sichern. Nachdem man von svn auf git umgestellt hat, sollte man als erstes einen Reset des Repositories mit folgender Option durchführen: HTTPS ist das einzige Protokoll, das Google für git unterstützt. Zur Authentifizierung sollte man sich ein Passwort generieren und die Zugangsdaten (auf Linux oder MacOs) in einer .netrc Datei im home Verzeichnis abspeichern. Nun kann man das Git Repository von Google Code in ein neues Verzeichnis clonen. Danach die alten Projektdaten in das neue Verzeichnis kopieren, zu Git hinzufügen und lokal festschreiben (commit). > git clone https://code.google.com/p// > cd > cp -R /* . > git add . > git commit -m"inital import" Was jetzt noch fehlt, ist der erste Upload zu Google Code. > git push origin master Bei nachfolgenden Uploads ist die Angabe des Branches nicht mehr notwendig. > git push Links: Tutorial - Erste Schritte mit Git

geschrieben von gklinkmann \\ tags: git, kubuntu, macos, tools, tutorial

Ich habe in der letzten Zeit das Thema Grails in diesen Blog etwas vernachlässigt. So ist es nun nach dieser Durststrecke an der Zeit, wieder einen Blog Eintrag zu diesem Thema zu schreiben (weitere könnten folgen).
Einer meiner ersten Artikel zu Grails zeigte, wie man Grails und Eclipse zueinander bringt. Dieser Eintrag war so erfolgreich, dass ich ihn auch als feste Seite im Rahmen eines kleinen Tutorials in den Blog integriert habe.

Dies ist ein paar Monate her und die Unterstützung der Erstellung von Grails Anwendungen durch Eclipse ist stetig besser geworden.
War es zum Anfang so, dass die mit Abstand beste IDE für Grails IDEA war, so holt das freie Eclipse immer mehr auf. Spätestens mit dem Wechsel der Grails Entwickler zu Springsource und der damit verbundenen Einbettung in die Eclipse basierte Springsource Tool Suite (STS) hat sich eine Menge getan.

Mal abgesehen von dem Hauptspeicher – Hunger von STS fühle ich mich als alter Eclipse Nutzer gut aufgehoben. Mit Netbeans und IDEA konnte ich mich nie so richtig anfreunden.

Um den Grails Support zu aktivieren müssen die Grails und Groovy Extensions über den Reiter Extensions des STS Dashboards installiert werden (s. Screenshot). Danach gibt es für Grails Projekte eine eigene Perspektive mit Syntax Highlighting, Code Vervollständigung und einer übersichtlichen Navigation im Project Explorer.
In der Toolbar gibt es in der Grails Perspektive einen Button zur Ausführung von Grails Befehlen (wie z.B. run-app).

Bei der Installation der Grails Extensions wird im Installationsverzeichnis des STS die aktuelle Grails Version abgelegt.

~ > ls springsource/
   grails-1.3.5
   grails-1.3.6				
   grails-1.3.7
   maven-2.2.1.RELEASE				
   roo-1.1.0.RELEASE			
   tc-server-developer-2.0.4.RELEASE
   sts-2.5.0.RELEASE

Gibt es bei den Updates (Help -> check for Updates) eine neue Grails Version wird diese dort hinzugefügt. In den Preferences (Groovy -> Grails) muss man dann die neue Version für den Workspace übernehmen. Im Grails Projekt ist dann noch der upgrade Befehl notwendig.

Fazit:
Die Grails Integration in Eclipse hat einen großen Schritt nach vorn getan. Vom Funktionsumfang dürfte IDEA immer noch führen. Grails Projekte werden dort allerdings nur in der kostenpflichtigen ULTIMATE Variante unterstützt.
Die kostenfreien Entwicklungsumgebungen Netbeans und die Eclipse basierte STS unterscheiden sich kaum in der Grails Unterstützung. Hier entscheidet die persönliche Vorliebe über die IDE.

Links:
Diskussion zu diesem Thema auf stackoverflow.com

Ich habe in der letzten Zeit das Thema Grails in diesen Blog etwas vernachlässigt. So ist es nun nach dieser Durststrecke an der Zeit, wieder einen Blog Eintrag zu diesem Thema zu schreiben (weitere könnten folgen). Einer meiner ersten Artikel zu Grails zeigte, wie man Grails und Eclipse zueinander bringt. Dieser Eintrag war so erfolgreich, dass ich ihn auch als feste Seite im Rahmen eines kleinen Tutorials in den Blog integriert habe. Dies ist ein paar Monate her und die Unterstützung der Erstellung von Grails Anwendungen durch Eclipse ist stetig besser geworden. War es zum Anfang so, dass die mit Abstand beste IDE für Grails IDEA war, so holt das freie Eclipse immer mehr auf. Spätestens mit dem Wechsel der Grails Entwickler zu Springsource und der damit verbundenen Einbettung in die Eclipse basierte Springsource Tool Suite (STS) hat sich eine Menge getan. Mal abgesehen von dem Hauptspeicher - Hunger von STS fühle ich mich als alter Eclipse Nutzer gut aufgehoben. Mit Netbeans und IDEA konnte ich mich nie so richtig anfreunden. Um den Grails Support zu aktivieren müssen die Grails und Groovy Extensions über den Reiter Extensions des STS Dashboards installiert werden (s. Screenshot). Danach gibt es für Grails Projekte eine eigene Perspektive mit Syntax Highlighting, Code Vervollständigung und einer übersichtlichen Navigation im Project Explorer. In der Toolbar gibt es in der Grails Perspektive einen Button zur Ausführung von Grails Befehlen (wie z.B. run-app). Bei der Installation der Grails Extensions wird im Installationsverzeichnis des STS die aktuelle Grails Version abgelegt. ~ > ls springsource/ grails-1.3.5 grails-1.3.6 grails-1.3.7 maven-2.2.1.RELEASE roo-1.1.0.RELEASE tc-server-developer-2.0.4.RELEASE sts-2.5.0.RELEASE Gibt es bei den Updates (Help -> check for Updates) eine neue Grails Version wird diese dort hinzugefügt. In den Preferences (Groovy -> Grails) muss man dann die neue Version für den Workspace übernehmen. Im Grails Projekt ist dann noch der upgrade Befehl notwendig. Fazit: Die Grails Integration in Eclipse hat einen großen Schritt nach vorn getan. Vom Funktionsumfang dürfte IDEA immer noch führen. Grails Projekte werden dort allerdings nur in der kostenpflichtigen ULTIMATE Variante unterstützt. Die kostenfreien Entwicklungsumgebungen Netbeans und die Eclipse basierte STS unterscheiden sich kaum in der Grails Unterstützung. Hier entscheidet die persönliche Vorliebe über die IDE. Links: Diskussion zu diesem Thema auf stackoverflow.com

geschrieben von gklinkmann \\ tags: eclipse, Entwicklungsumgebung, Grails, groovy, Java

Alle großen Linux Distributtionen bringen heutzutage Pakete für das Open Source Monitoring Werkzeug Nagios mit. Doch Nagios hat sich erst durch seine Erweiterungen (und natürlich aufgrund der geringen Kosten) in vielen Firmen durchgesetzt.

Die Integration der Erweiterungen (wie z.B. nsca oder MK Livestatus) ist mit etwas Handarbeit verbunden. Dies ist den Programmierern dieser Tools auch aufgefallen und so haben sie sich kurzerhand zusammengeschlossen und ihr Wissen und ihre Software in der Open Monitoring Distribution (OMD) zusammengeführt.

OMD (Version 0.42) beherbergt in seinen Paketen (für SLES 11, Debian 5.0, Ubuntu 10.04 and RedHat/CentOS 5.4 and 5.5) Nagios selbst und zusätzlich diese Erweiterungen:

• nagvis
• pnp4nagios
• rrdtool/rrdcached
• nagios-plugins
• Check_MK
• MK Livestatus
• Multisite
• dokuwiki
• nsca
• check_nrpe

Ein weiterer Vorteil von OMD ist dessen Instanz Fähigkeit. So kann man mehrere autarke Nagios Umgebungen auf einem Server betreiben, die unter unterschiedlichen BS Benutzern laufen können. Eine Instanz erstellt und startet man mit:

omd create foo
omd start foo

OMD installiert sich immer unterhalb von /opt/omd und ist damit unabhängig von den Installationspfaden der unterschiedlichen Linux Distributionen.
Bei der Integration der verschiedenen Werkzeuge wurde auch auf Performance geachtet. So wurde bewusst auf das I/O lastige NDO verzichtet und stattdessen auf MK Livestatus gesetzt, das direkt auf die Nagios Daten im Hauptspeicher zugreift.

Wer sein Nagios lieber von Hand kompiliert, muss trotzdem nicht auf die anderen Vorteile von OMD verzichten. Entsprechende tar balls sind neben den Paketen im Download Bereich vorhanden.

Alle großen Linux Distributtionen bringen heutzutage Pakete für das Open Source Monitoring Werkzeug Nagios mit. Doch Nagios hat sich erst durch seine Erweiterungen (und natürlich aufgrund der geringen Kosten) in vielen Firmen durchgesetzt. Die Integration der Erweiterungen (wie z.B. nsca oder MK Livestatus) ist mit etwas Handarbeit verbunden. Dies ist den Programmierern dieser Tools auch aufgefallen und so haben sie sich kurzerhand zusammengeschlossen und ihr Wissen und ihre Software in der Open Monitoring Distribution (OMD) zusammengeführt. OMD (Version 0.42) beherbergt in seinen Paketen (für SLES 11, Debian 5.0, Ubuntu 10.04 and RedHat/CentOS 5.4 and 5.5) Nagios selbst und zusätzlich diese Erweiterungen: nagvis pnp4nagios rrdtool/rrdcached nagios-plugins Check_MK MK Livestatus Multisite dokuwiki nsca check_nrpe Ein weiterer Vorteil von OMD ist dessen Instanz Fähigkeit. So kann man mehrere autarke Nagios Umgebungen auf einem Server betreiben, die unter unterschiedlichen BS Benutzern laufen können. Eine Instanz erstellt und startet man mit: omd create foo omd start foo OMD installiert sich immer unterhalb von /opt/omd und ist damit unabhängig von den Installationspfaden der unterschiedlichen Linux Distributionen. Bei der Integration der verschiedenen Werkzeuge wurde auch auf Performance geachtet. So wurde bewusst auf das I/O lastige NDO verzichtet und stattdessen auf MK Livestatus gesetzt, das direkt auf die Nagios Daten im Hauptspeicher zugreift. Wer sein Nagios lieber von Hand kompiliert, muss trotzdem nicht auf die anderen Vorteile von OMD verzichten. Entsprechende tar balls sind neben den Paketen im Download Bereich vorhanden.

geschrieben von gklinkmann \\ tags: monitoring, Open Source

Wenn sich ein Entwurfsmuster in der Web Entwicklung bewährt hat, dann ist es das Model View Controller Pattern oder kurz MVC. Ich bin schon seit längerem auf der Suche nach einem PHP Framework, dass MVC konsequent umsetzt, aber nicht gleich mit Kanonen auf Spatzen schießt. Leichtfüßig (oder in “Neu-Deutsch” light weight) und objekt orientiert sollte es sein. PHP Fameworks, wie z.B. Zend, CakePHP und Symphony gehören da eher zu den Boliden. MVC setzen sie zwar perfekt um, objekt orientiert sind sie auch, aber leichtfüßig ist anders.

So bin ich auf CodeIgniter gestoßen, was von sich behauptet mit einem “schmalen Fuß” (small footprint) daher zu kommen.

Die Installation ist schon einmal denkbar einfach. Das Zip im “DocumentRoot” des Webservers auspacken, das Verzeichnis umbenennen und die vollständige URL für den Webauftritt in der Konfigurationsdatei system/application/config/config.php angeben.

$config['base_url'] = "http://localhost/allMedia/";

Und schon kann man seinen ersten Controller schreiben.

class Books extends Controller {
   ... some logic ...
 
   // build view
   $this->load->view('common/header',$headerdata);
   $this->load->view('book/list',$data);
   $this->load->view('common/menu',$menudata);
   $this->load->view('common/footer');
}

CodeIgniter ist in der Lage Teile einer View vor dem Ausliefern zusammenzusetzen. Templates werden unterstützt sind aber nicht zwingend notwendig.

Für mich bringt dieses Framework alles mit, was ich brauche:

• das MVC Entwurfsmuster
• durchgängige Objektorientierung
• Performance
• schöne URL’s
• Helper Klassen (z.B. für Paging)
• gute Einbindung von doctrine als OR Mapper
• und nicht zu vergessen eine gute Dokumentation

“Das Feuer ist bei mir entzündet” und ein kleines Projekt bereits mit CodeIgniter implementiert. Wem also Zend und Co. zu komplex sind, der sollte sich CodeIgniter einmal etwas genauer anschauen. Es lohnt sich.

Wenn sich ein Entwurfsmuster in der Web Entwicklung bewährt hat, dann ist es das Model View Controller Pattern oder kurz MVC. Ich bin schon seit längerem auf der Suche nach einem PHP Framework, dass MVC konsequent umsetzt, aber nicht gleich mit Kanonen auf Spatzen schießt. Leichtfüßig (oder in "Neu-Deutsch" light weight) und objekt orientiert sollte es sein. PHP Fameworks, wie z.B. Zend, CakePHP und Symphony gehören da eher zu den Boliden. MVC setzen sie zwar perfekt um, objekt orientiert sind sie auch, aber leichtfüßig ist anders. So bin ich auf CodeIgniter gestoßen, was von sich behauptet mit einem "schmalen Fuß" (small footprint) daher zu kommen. Die Installation ist schon einmal denkbar einfach. Das Zip im "DocumentRoot" des Webservers auspacken, das Verzeichnis umbenennen und die vollständige URL für den Webauftritt in der Konfigurationsdatei system/application/config/config.php angeben. $config['base_url'] = "http://localhost/allMedia/"; Und schon kann man seinen ersten Controller schreiben. class Books extends Controller { ... some logic ... // build view $this->load->view('common/header',$headerdata); $this->load->view('book/list',$data); $this->load->view('common/menu',$menudata); $this->load->view('common/footer'); } CodeIgniter ist in der Lage Teile einer View vor dem Ausliefern zusammenzusetzen. Templates werden unterstützt sind aber nicht zwingend notwendig. Für mich bringt dieses Framework alles mit, was ich brauche: das MVC Entwurfsmuster durchgängige Objektorientierung Performance schöne URL's Helper Klassen (z.B. für Paging) gute Einbindung von doctrine als OR Mapper und nicht zu vergessen eine gute Dokumentation "Das Feuer ist bei mir entzündet" und ein kleines Projekt bereits mit CodeIgniter implementiert. Wem also Zend und Co. zu komplex sind, der sollte sich CodeIgniter einmal etwas genauer anschauen. Es lohnt sich.

geschrieben von gklinkmann \\ tags: frameworks, Open Source, php