Dieser kleine Bericht ist kein Tutorial oder eine Anleitung oder sowas. Es ist eher ein Roman – die Geschichte, wie ich Magento2 kennengelernt habe. 
Installiert habe ich also erst mal:
1. xampp-win32-1.7.7-VC9-installer.exe
Quelle: http://dfn.dl.sourceforge.net/project/xampp/XAMPP Windows/1.7.7/xampp-win32-1.7.7-VC9-installer.exe
Weitere Informationen zu xampp unter: http://www.apachefriends.org/
2. Git-1.7.10-preview20120409.exe
Quelle: http://msysgit.googlecode.com/files/Git-1.7.10-preview20120409.exe
Informationen dazu unter: http://msysgit.github.com/
Dann habe ich das Magento2 Repository unter https://github.com/magento/magento2 geforkt und mit der Git-BASH ein lokal geclonnt.
git clone https://[email protected]/msoftware/magento2.git
Das gleiche habe ich mit dem Repository von netresearch gemacht. Erst ein fork und dann git clone (https://github.com/netresearch/jumpstorm). Hier ist aber dringend darauf zu achten, dass ein rekursives clone durchgeführt wird. Da aus dem jumpstore Repository heraus auch noch andere Repositorys benötigt werden. Z.B. die Dateien unter /lib/Symfony/Component. Das es sich hier um verknüpfte Repositories handelt, kann man unter github.con auch gut an dem kleinen grünen Icon erkennen (z.B. hier https://github.com/msoftware/jumpstorm/tree/master/lib/Symfony/Component).
Und weil es so einen Spaß macht, habe ich auch direkt mal das FIREGENTO GermanSetup Repository (https://github.com/firegento/firegento-germansetup) kopiert und auch geklont.
Ja, mir ist schon klar, dass der ganze Aufwand mit dem Forken eigentlich überflüssig ist, aber wer weiß wozu es mal gut ist. Ich glaube zwar nicht, dass ich über das reine “Mal reinschauen” hinauskomme, aber wer weiß …
So weit erst mal zur Vorbereitung. Jetzt, da ich alles zusammen habe, was ich für die ersten Schritte benötige, checke ich erst mal, ob der Apache läuft und muss dann mit Hilfe von jumpstorm ein Magento aufsetzen. Vor ein paar Stunden habe ich noch einen Vortrag darüber gehört und bin sehr gespannt, ob ich das nun auch hin bekomme.
Nachdem ich http://localhost/ in die Adress-Zeile meines Browsers eingegeben habe, erscheint der mir bekannte xampp Start Screen und so wie es scheint läuft der Apache (Xampp) perfekt und ich werde mir jetzt mal jumpstore ansehen. Im Hauptverzeichnis finde ich eine PDF Datei mit dem Namen README.pdf. Der Name klingt vielversprechend und ich schaue einfach mal rein. Das PDF ist in englischer Sprache verfasst und erklärt sehr anschaulich mit vielen kleinen Beispielen die Vorgehensweise.
Als erstes sehe ich mir mal die sample.jumpstorm.ini an. Da ich nicht mit sample.jumpstorm.ini arbeiten möchte, benenne ich die Datei um in “jumpstorm.ini” und editiere sie in meinem bevorzugten vim . Als erstes fällt mir auf, dass hier jemand vor dem einchecken vergessen hat das MySQL Passwort zu entfernen. Eigentlich nicht so schlimm, da es sich bei der Konfiguration ganz offensichtlich um eine lokale Entwicklungsumgebung handelt, aber es wirkt doch erst mal nicht unbedingt vertrauensbildend. Das gleiche gilt auch für das adminPass. Auch hier hätte ich mir eher einen leeren Eintrag gewünscht.
Da ich auf den ersten Blick nicht verstehe, was ich in meinem Fall unter “magento” -> “source” eintragen soll, muss ich wohl erst mal in die jumpstorm sourcen schauen. Das ist so oser so erst mal eine gute Idee, denn evtl. baut ein Blick in den Source-Code mein Vertrauen in die Entwickler wieder auf.
Nach dem öffnen der jumpstorm Datei sehe ich auf den ersten Blick das dieses Skript nicht unter Windows entwicklet wurde und daher in meinem Fall einige Anpassungen benötigt. Da es in PHP geschrieben ist, habe ich damit aber wenig Probleme und mache mich erst mal daran, jumpstorm für meine Umgebung anzupassen.
Klar, die Pfade müssen alle angepasst werden, aber ich treffe auch noch auf andere Problem.
1. In der Datei \jumpstorm\lib\Netresearch\Source gibt es eine Methode “isFilesystemPath”, die so erst mal nicht funktioniert – wenigstens unter Windows.
public static function isFilesystemPath($sourcePath)
{
return (0 === strpos($sourcePath, ‘/’)); // path is absolute filesystem path
}
Egal. Ich denke mir mal kleine Änderung – große Wirkung und ändere die Methode ein wenig ab.
public static function isFilesystemPath($sourcePath)
{
return (is_dir($sourcePath)); // path is absolute filesystem path
}
Beim nächsten Test komme ich wieder einen kleinen Schritt weiter. Als nächstes versucht das Script die Dateien per rsync zu kopieren. Das ist eine sehr gute Idee, aber unter Windows doch wieder ein Problem. Bei meiner Suche in den Sourcen finde ich 2 Stellen an denen rsync verwendet wird.
$ grep -r rsync *
lib/Netresearch/Source/Filesystem.php:
$command = sprintf(‘rsync -a -h %s %s 2>&1′, $this->source, $target);
src/Jumpstorm/Extensions.php:
$command = sprintf(
‘rsync -a -h –exclude=”doc/*” –exclude=”*.git” %s %s 2>&1′,
$source . DIRECTORY_SEPARATOR,
$this->config->getTarget()
);
Dabei denke ich natürlich direkt an Clean-Code und Refactoring und …. Aber ich kann mich bremsen und suche kurz mal bei Google nach einer geeigneten Funktion und werde unter http://aidanlister.com/2004/04/recursively-copying-directories-in-php/ fündig. Unter dem Titel Recursively copying directories in PHP hat Aidan Lister eine copyr Funktion veröffentlicht, die – so hoffe ich – auch ihren Zweck erfüllt. Zu dem Zweck habe ich ein weitere PHP Datei unter \jumpstorm\lib\AidanLister angelegt, in der ich die Datei Copyr.php mit der entsprechenden Funktion hinterlegt habe. Beim Test wird klar, warum die Kollegen von netresearch hier auf rsync gesetzt haben, denn das Kopieren der Dateien ist so ungluablich langsam, dass ich in der Zeit auch eben rsync für Windows instalieren könnte.
Nach dem Kopieren der Dateien treffe ich auf das nächste Problem. Der Nächste Schritt versucht die Anlager der MySQL Datenbank. Auch hier wir mit dem exec Kommando gearbeitet und mit Hilfe vom mysql Kommando Datenbanken gelöscht und angelegt. Da der Befehl mysql in meinem Fall nicht im Pfad ist, bekomme ich erst mal nur eine Reihe von Fehlermeldungen. Was dann dazu führt, dass die MAgento Installation mit der folgenden Exception abbricht.
[Exception]
Could not create live database
Also mysql in den Pfad aufnehmen. Bei mir liegt das Kommando mysql unter C:\xampp\mysql\bin und genau das Trage ich dann auch in meine PATH Variable ein. Während mein Test läuft und ich wieder darauf warte, dass die Dateien geladewn werden, lese ich ein wenig über das Symfony Framework. Ich selbst habe es noch nie eingesetzt und nutze die Gelegenheit, mich mal kurz damit zu beschäftigen. Unter http://symfony.com/symfony-in-five-minutes finde ich eine Zusammenfasssung des Symfony Frameworks, dass ich zwar nicht in 5 Minuten lesen kann, aber das Kopieren der Dateien lauft ja auch ein wenig länger . Na toll. Mittlerweile bin ich zum Senior Symphony Developer geworden und ich sehe wieder nur die Exception. Tja, das hat wohl nicht viel gebracht. Ich greppe noch mal durch die Sourcen nach mysql und sehe, dass es nur eine Stelle gibt, an der das Kommando mysql wirklich benötigt wird. Soll ich einfach den Pfad in der Funktion prepareMysqlCommand ergänzen. Vermutlich wird es klappen, aber so macht das einfach keinen Spaß. Ich sitze ja so oder so hier im Zug fest und erst in Hannover. D.H. ich habe noch ca. 2 Stunden vor mir und daher noch genug Zeit, es richtig zu machen. Geanu in dem Moment geht mir eine Frage durch den Kopf. Warum ist es eigentlich immer so, dass es ungleich länger dauert etwas “richtig” zu machen als es mal eben rein zu fummeln? Die Antwort kenne ich zwar, aber daran will ich mich jetzt nich hoch ziehen. Statt dessen mache ich es richtig unb baue den Pfad zu mysql in die jumpstorm.ini mit ein. Auch wenn ich mir nicht ganz klar darüber bin, ob das schon ausreicht, denn eigentlich währe es noch viel besserm ganz auf den Aufruf von mysql zu verzichten und mit den PHP Methoden mysql_connect und mysql_querry zu arbeiten. Aber das habe ich schon 100 mal gemacht und heute habe ich mal Lust auf was neues.
Nachdem ich mir nun die Arbeit mit der jumpstorm.ini gemacht habe, muss ich feststellen, dass es alles nichts bringt. Der mysql Befehl wird nun zwar ordnungsgemäß gefunden, aber die Exception bleibt. Mist!
Also weiter Suchen und nicht aufgeben. Vermutlich bin ich wieder einen kleinen Schritt weiter gekommen und darf jetzt nicht aufgeben. Das ist halt das Lehrgeld dass man zahlen muss, wenn man “mal wieder was neues probieren möchte”. OK, ich schaue mir also den Teil in der Base.php noch mal genauer an. Eigentlich kann hier nicht viel passieren und daher entscheide ich mich für eine pragmatische Herangehensweise und gebe einfach mal das erzeugte mysql Kommando aus. Beim Test sehe ich was ich nicht sehen wollte. Das Passwort aus der jumpstorm.ini steht hier im Aufruf. Ach Schei… das habe ich beim vielen Schreiben ja total vergessen. Das PAsswort muss natütrlich raus aus der php.ini, da ich gar kein Passwort für meine lokale xampp Installation nutze. So weit so gut, doch alles jamern und probieren hat keinen Zweck. Irgendwie schaffe ich es nicht, diesen Konstrukt aus mysql.exe und den benötigten Parametern zu übergeben. Ich sehe mir den Return Wert an, der immer 1 statt 0 ist und suche danach bei Google. Evtl. gibt es ja eine Besonderheit unter Windows oder irgendeinen Bug – was weiß ich? Aber nichts. Ich sehe mir das Result des Aufrufs an und bekomme immer eine mysql Hilfe als Result. Das ist sehr verwunderlich und ergibt meiner Meinung nach keinen Sinn, ist aber so. Mittlerweile bin ich fast im Hamm und folge dem was meine Oma immer zu mir gesagt hat. ” Junge, bleib doch lieber bei den bewährten alten Methoden. Das ganze moderne Zeug ist doch nicht gut für Dich”. Eigentlich stimmt es nicht so ganz, denn der aufruf mysql_connect ist jünger als das mysql commando, aber das ist mir jetzt egal und ich baue die Base.php um. In der Magento.php habe ich eine ähnliche Konstruktion entdeckt, um die ich mich jetzt aber noch nicht kümmere. Ich bin mir sicher da werde ich noch ganz von allein drauf treffen. So schaffe ich es dann auch tatsächlich, dass die Datenbank angelegt wird. Hurra! Jetz kann ich also Dateien kopieren und eine leere Datenbank anlegen. Der Nächste Schritt ist die Anlage der Magento Sample Data Tabellen und Inhalte. Auch bei diesem Schritt darf ich mich über eine Exception freuen, was aber daran liegt, dass ich den Punkt noch nicht konfiguriert habe.
[Exception]
Could not detect sample data sql file in source directory git://git.example.org/magento/sampledata.git
Also muss ich nun in der jumpstorm.ini Datei die richtige Lokation der Datei angeben und schon kann es weiter gehen. So lange der Download dauert (Leider habe ich die Zip Datei noch nicht herunter geladen und im Zug ist die UMTS Verbindung leider nicht sehr stabil) schaue ich mir schon mal die Stelle an, die zu der Exception geführt hat. Ich habe ja nun schon eine Menge über jumpstorm gelernt und evtl. hilft mir das Wissen ja weiter.
Siehe da, es ist die Stelle in der Magento.php, die ich gerade noch vor mir hergeschoben habe. Was für ein Wunder. Klar muss hier wieder ein SQL Statement ausgeführt werden und klar ist auch, dass es wieder mit prepareMysqlCommand und exec gemacht wird. Dieses mal ist es aber nicht so einfach wie noch gerade. Ein einfaches DROP DATABASE oder CREATE DATABASE ist doch etwas anderes als eine mehrere 100 MB große SQL Datei einzulesen und dann mit mysql_query auszuführen. Aber ich halte mich an das was meine Oma gesagt hat und versuche, es wieder ohne exec zu machen. Doch aktuell heißt es erst mal Geduld haben und auf den Download warten. In der Zeit google ich das Problem mal. Vermutlich hat so ein Problem schon mal jemand vor mir gehabt und warum soll ich das Rad jedes mal neu erfinden. Dabei fällt mir was ein. Ich habe doch auf der Symphonny Website gelesen, dass es bei einem guten Framework darauf ankommt, dass man das Rad nicht jedes mal neu erfinden muss. Dementsprechend ist das Internet irgendwie auch ein Framework. Man kann es nicht so ohne weiteres benutzen, aber hier findet man auch zu fast jedem Problem eine Lösung, da man so gut wie nie der erste ist, der darauf gestoßen ist … und wenn doch? Dann hat man vermutlich etwas tatal falsch gemacht und sollte lieber alles löschen und noch mal von Vorne anfangen.
So, der Download ist fertig und ich bin in Dortmund. Mist. Selbst mit Verspätung hat die Zeit nicht gereicht. Ich muss in 10 Minuten aussteigen und dann ist erst mal Sense mit Magento2. In den nächsten Tagen werde ich wohl erst mal nicht mehr dazu kommen, hier weiter zu arbeiten. Außerden sehe ich keinen Grud darain, mein Netbook in die Hand zu nehmen, wenn ich einen richtigen Rechner habe.
So wie es aussieht ist das der Punkt an dem ich erst mal aufgeben muss. Ja, ich weiß, dass Magento nicht für Windows gemacht wurde und das hat so wie es scheint auch einen Hintergrund . Ich werde das ganze wohl noch mal in Ruhe auf einem Linux Server probieren und gebe damit zurück an die anderen Webseiten.
Related posts:
]]>Die Eclipse Foundation hat diesen Monat ihren jährlichen Open Source Developer Report
“THE OPEN SOURCE DEVELOPER REPORT 2011 ECLIPSE COMMUNITY SURVEY JUNE 2011″
vorgestellt, der Aufschluss darüber geben soll, welche Richtung die Open Source Gemeinde einschlagen wird. Ich habe mir den Bericht einmal intensiv angesehen und daraus meine Schlüsse gezogen. Wie jedes Jahr, gibt es ein paar Trends, denen man folgen sollte und ein paar Hypes, die man sich ansehen kann, die aber in ein paar Jahren wieder in Vergessenheit geraten können. Die Ergebnisse der Studie basieren auf der Auswertung von 624 Befragungen, die in englischer Sprache durchgeführt wurden. In diesem Blog Beitrag möchte ich mal meinen Senf dazu geben und meine Einschätzungen für die momentane Situation und die Zukunft abgeben.
Vergleichbare Studien wurden in den Jahren 2007, 2009 und 2010 durchgeführt. Die Ergebnisse dieser Studien können unter http://www.eclipse.org/org/press-release/20071106_cbsurvey.php, http://www.eclipse.org /org/ pressrelease/20090527_survey09.php und http://www.eclipse.org/org/ pressrelease/20100604_survey2010.php gefunden werden. Die Daten der aktuellen Studie (Juni 2011) können unter http://www.eclipse.org/org/ community_survey/Summary_Data_2010.ods heruntergeladen werden. Die Auswertung der Daten steht als PDF unter [THE OPEN SOURCE DEVELOPER REPORT 2011 ECLIPSE COMMUNITY SURVEY] zum Download bereit.
Länder der Befragung
Die Ergebnisse der 624 Befragungen basieren auf Daten von Individuen, die aus sehr vielen unterschiedlichen Ländern kommen. Die Länder mit den meisten Beteiligungen waren Deutschland (18,1%), USA (16,8%), Frankreich (6,9%) und Indien (5,6%). Warum hier ein so kleines Land wie Deutschland mit einer Quote von 18,1% auf Platz 1 zu finden ist hat einen guten Grund, denn Deutschland hat eine sehr große Open Source Community und Eclipse ist nun mal die IDE Nummer 1 in Deutschland.
Personengruppen
Neben den reinen Programmierern haben auch andere IT Berufsgruppen den Fragebogen ausgefüllt. Dabei sieht die Verteilung der Top 3 Berufsgruppen hier wie folgt aus:
54.6% Programmierer
14.9% System Architekten
8.3% Entwicklungsleiter
Damit kann man mal wieder sehen, dass die große Gruppe der Open Source Entwickler zu mehr als 50% aus Programmierern besteht. Das ist auch gut so, denn IMHO braucht man System Architekten und Entwicklungsleiter nur in sehr großen Open Source Projekten.
Der Entwickler Desktop
Nachdem wir nun geklärt haben, woher und von wem die Daten der Studie kommen, können wir uns langsam an die technischen Details wagen. Zu allererst sehen wir uns mal den Entwickler Arbeitsplatz genauer an. Man kann hier sehr deutlich erkennen, dass Windows nach wie vor die Nase vorne hat. Gefolgt von Linux und Mac OSX. Im Vergleich mit den letzten 3 Jahren hat allerdings Linux als einziger von den 3 Betriebssystemen Marktanteile verloren. Fast im gleichen Verhältnis hat Windows gewonnen. Ist das ein Trend in Richtung Microsoft oder liegt das an der Verteilung der Beteiligten. Ich persönlich habe ja schon seit Jahren kein Linux System mehr installiert und habe statt dessen eine Cygwin Installation unter Windows. Ich nenne diese Kombination immer gerne “Das Beste aus beiden Welten”. Damit fahre ich sehr gut und habe eigentlich alles was ich brauche in einer Instanz.
Die am meisten verwendete Programmiersprache
Ein immer wieder heiß diskutiertes Thema ist die Programmiersprache. Hier hat Java die Nase noch immer ganz weit vorne. Mit 75,7% ist der Wert zwar für meine Begriffe noch zu hoch, aber die Nähe von Eclipse zu Java sorgt natürlich dafür, dass bei einer solchen Befragung vor allem Java Entwickler teilnehmen. Hinter der Programmiersprache Java folgen dann noch C/C++ (9,2%) und PHP (4,8%). Alle anderen Programmiersprachen, haben einen Anteil von weniger als 3% und fallen somit unter ferner liefen. Spannend ist aber die Tatsache, dass immer mehr Entwickler mehr als eine Programmiersprache beherrschen. So sind die Programmiersprachen JavaScript (36,2%), C/C++ (32,8%), PHP (21%) und Python (20%) bei den Entwicklern als weitere Programmiersprache auch sehr weit verbreitet.
Source-Code Management (SCM)
Beim Source Code Management liegt SVN mit einem Anteil von 51,3% weit vorne und hat CVS mit einem Anteil von 13,3% sehr weit hinter sich gelassen. Allerdings macht sich eine andere Versionsverwaltung auf den Weg, der Nummer 1 den Platz abzunehmen. Das hoch performante und mittlerweile stark verbreitete (relativ neue) Versionsverwaltungs-Tool Git hat hier schon einen Anteil von 12,8% und im nächsten Jahr ist noch mal ein deutliches Wachstum zu erwarten. So prophezeie ich, dass GIT im nächsten Jahr vor CVS liegt.
Change Management Systeme
Bei den Change Management Systemen gibt es keinen richtigen Marktführer, der den Markt für sich beansprucht. Vor ein paar Jahren hat hier der Bugzilla den Markt beherrscht, aber JIRA ist eine echte Alternative für Bugzilla geworden. Ich selbst setze JIRA in einem Entwickler-Team ein und bin immer wieder überrascht, wie mächtig das Tool ist. Nicht zuletzt die Integration in Eclipse über MyLyn ist sehr genial und optimiert viele tägliche Aufgaben. Bugzilla dagegen hat den großen Vorteil, dass man hiermit einfach starten kann. Man benötigt nicht die aufwendige Start-Phase, die JIRA (besonders am Anfang) etwas oversized erscheinen lässt.
Das Open Source aber nicht immer ein Change Management benötigt, zeigt z.B. die Tatsache, dass 16,5% kein Change Management System einsetzen. Auch das kann ich gut verstehen. Ich selbst führe für die meisten meiner Open Source Projekte nur eine TODO-Liste. Die Anregungen für die Weiterentwicklung kommen dann entweder von mir selbst (z.B. weil sich meine Arbeitsweise geändert hat) oder von Nutzern der Software, die über Foren, Twitter und Blogs mit mir kommunizieren. Das ist für kleinere Projekte völlig ausreichend und hat sich (wenigstens bei mir) in den letzten Jahren immer bewährt.
Build und Release Management
Das Build und Release Management ist ein Thema, auf das gerade in letzter Zeit immer mehr Open Source Projekte aufspringen. Hat man vor wenigen Jahren nur mal eben die Versionsnummer in der Konfiguration ausgetauscht, bevor man ein JAR File erzeugt hat, kommen jetzt vermehrt Tools wie Hudson/Jenkins zum Einsatz.
Trotzdem ist ant mit einem Anteil von 48,2% noch immer das am weitesten verbreitete Build Management Werkzeug. Hudson/Jenkins folgen mit einem Anteil von 32,2% und Maven mit 30,8%.
Weiter zu Teil 2 der Open Source Trends 2011
Related posts:
]]>“THE OPEN SOURCEDEVELOPER REPORT2011 ECLIPSE COMMUNITY SURVEY”
basieren. hier also mein Senf dazu .
Hier geht es zum ersten Teil der Open Source Trends 2011
Anwendungs-Typen
Die am meisten verbreiteten Anwendungs -Typen sind (wie nicht anders zu erwarten war) Server-seitige Anwendungen (28,4%), Web Applikationen (22,9%) und Desktop Programme (18,6%). Auf Platz 4 kommen dann Eclipse Plugins, aber der Wert von 11,7% erscheint mir viel zu hoch und ergibt sich wohl aus der Nähe der Befragten zu Eclipse.
Server-seitige Anwendungen
Bei den Server-seitigen Anwendungen hat Spring die Nase vorne. Kein Wunder, das Java Framework hat sehr viel Potential und im Vergleich zu J2EE hat es von Anfang an einen besseren Eindruck auf mich gemacht. Auf Platz 2 steht ExtJS. Ein sehr geniales JavaScript Framework, mit dem sich sehr gut Rich Client Anwendungen entwickeln lassen, die dann im Browser laufen können. Dabei stehen Spring und ExtJS nicht Mal in Konkurrenz zueinander. Im Idealfall kombiniert man sogar beide Frameworks mit einander und hat dann eine Anwendungsarchitektur, die von einer großen Gruppe von IT Experten verstanden wird, da sich beide Frameworks einer großen Beliebtheit erfreuen.
Schade ist es hier nur um Struts. Mit einem Anteil von weniger als 5% ist Struts auf dem absteigenden Ast. Leider hat man mit Struts 2 die von Struts 1 her bekannte Architektur so weit über den Haufen geworfen, dass kaum eine Anwendung migriert werden konnte. Aus dem, und aus anderen Gründen hat Struts sich selbst auf das Abstellgleis katapultiert. Schade.
Web und Rich Internet Anwendungen
Dieser Bereich der Anwendungsentwicklung hat lange darunter gelitten, dass er teuer war und ist. Eine gute Web Applikation ist oft deutlich teurer als eine vergleichbare Desktop Anwendung. Das liegt nicht nur daran, dass es kein rundum glücklich Paket gibt, mit dem auch der unerfahrene Programmierer mal schnell eine Anwendung schreiben kann (so wie man es dann z.B. aus den Access Zeiten noch kennt).
Aber es gibt Hoffnung. Ich persönlich finde ExtJS und jQuery sehr gut geeignet, um den Client-Teil abzudecken. Der Open Source Developer Report gibt mir hier nur teilweise recht, denn das Google Web Toolkit ist nach jQuery (30,1%) mit 8,4% auf Platz 2 bei den beliebtesten RIA Frameworks. ExtJS ist mit 4,2% schon eher eine ausgefallene Wahl.
Allerdings kann man an dem Ergebnis deutlich erkennen, dass der Stein der Weisen unter den RIA Frameworks noch nicht gefunden wurde, denn immerhin haben 18,9% der Befragten angegeben, kein RIA Framework im Einsatz zu haben.
Rich Desktop Anwendungen
Rich Desktop Anwendungen entwickelt man mit Eclipse RCP (53,4%) oder Java Swing (25,9%). Dass hier auch wieder die Nähe von Eclipse zu Eclipse RCP und Java die Studie beeinflusst haben, ist kaum zu übersehen. Sonst ist der Anteil von 2,6% für Microsoft .NET Windows wohl kaum zu erklären. Denn die Realität sieht natürlich anders aus. Desktop Anwendungen werden mit Visual Studio entwickelt. Auch wenn ich keine Zahlen dazu zur Hand habe, bin ich mir sicher, dass Java Swing und Eclipse RCP hier nur eine untergeordnete Rolle spielen.
Der Applikation Server
Immer mehr Anwendungen benötigen einen Applikation Server. Sei es, weil Daten online gespeichert werden sollen, oder sogar die ganze Anwendung im Browser läuft. So oder so, der Applikation Server spielt eine zentrale Rolle bei der Systemarchitektur sehr vieler Systeme. Kein Wunder, dass der gute alte Tomcat hier eine große Rolle spielt. Er war einer der Ersten und hat (bei mir) immer seinen Job gemacht. Mit einem Anteil von 32,1% liegt er weit vorne. Gefolgt von JBoss, der mit 9% nur noch eine untergeordnete Rolle spielt.
Mit einem Anteil von 3% liegt der Glassfish relativ weit hinten. Aber daran kann man auch erkennen, dass kaum ein Unternehmen/Open Source Projekt die J2EE Features eines Applikation Servers benötigt. Meist reduziert es sich auf JSP, JSF, JDBC, etc. alles andere kommt wohl nur sehr selten zum Einsatz.
Cloud Computing
Das Cloud Computing noch nicht im Fokus der meisten IT Fachleute angekommen ist, wird hier sehr deutlich. Nur 17,1% haben entweder Teile der IT Infrastruktur oder die gesamte Infrastruktur in die Cloud verlagert. Da ich von der Cloud auch noch nicht so ganz überzeugt bin, kann ich das verstehen, obwohl ich mich dem Cloud Thema nicht ganz entziehen kann und auch schon Cloud Computing betreibe. Das Unternehmen, dass beim Cloud Computing momentan die Nase vorne hat ist Amazon. Google und IBM haben zwar nachgelegt, konnten es aber nicht schaffen, in der Befragung über die 10% Hürde zu springen.
Das Thema Cloud Computing ist aber nicht zu unterschätzen. Cloud Computing hat das Potential, die IT Infrastruktur der Unternehmen deutlich zu verändern. Mit Vor- und Nachteilen für die Mitarbeiter und die Unternehmensleitung.
Modellierung
42,5% der Befragten gaben an, keine Modellierungstechnik einzusetzen. Sorry liebe Projektplaner und IT Architekten, aber die Wahrheit steht halt noch immer im Code . Ne, mal im Ernst. Modellierung ist toll, man kann Gedanken visualisieren und hat ein besseres Gesamtbild. Aber dann ist doch die Zeit mal wieder knapp oder das Geld ist verbraucht. Außerdem müssen Modelle auch immer auf dem laufenden gehalten werden, wenn die Architektur erweitert oder geändert wird und kaum jemand ist bereit, diesen zusätzlichen Aufwand zu tragen. Bewerten möchte ich das jetzt aber nicht, da ich zum Thema Modellierung ein gespaltenes Verhältnis habe.
Mobile Computing
Wenn man mich fragt: Das Thema Nummer 1 für die Zukunft. Aber das sage ich seit mehr als 10 Jahren und keiner will es mehr hören, also lasse ich hier einfach mal die Zahlen sprechen.
60% der Befragten haben bereits mobile Anwendungen entwickelt oder planen dies.
35% der Befragten haben bereits mobile Anwendungen entwickelt.
Die bei den Befragten am weitesten verbreitete mobile Plattform ist Android (85,1%) gefolgt von Apple iOS (66,3%). Wer schon mal in Eclipse etwas für Android entwickelt hat und dann Xcode und Objective-C sehen musste, weiß, warum Android hier die Nase vorne hat, obwohl iOS eine viel breitere Plattform bietet.
Zusammenfassung
Insgesamt war die Studie sehr Java und Eclipse-lastig eingefärbt. Aber das war auch nicht anders zu erwarten. Hätte man die Befragung auf den Webseiten des MSDN beworben, währe das Ergebnis ganz anders ausgefallen. Genau das gleiche gilt auch für den PHP Teil, der auch deutlich unterbewertet wurde. Trotzdem finde ich das Ergebnis sehr interessant und ich habe das Gefühl, die richtigen Tools zu verwenden. Denn wenn ich etwas gelernt habe, dann dass man der Masse folgen sollte. Nur weil ich ein ganz bestimmtes Feature von CVS ab und an mal benötige, ist das kein Grund, um nicht auf Git umzusteigen. Andererseits gilt auch der Satz “Never Touch a running System”. Allerdings würden wir dann vermutlich heute noch mit Host Systemen arbeiten oder Lochkarten stempeln
PS: Nur 3% der Befragten waren weiblich. Das passt perfekt zum Klischee, aber ist doch eindeutig ein Zeichen, dass hier mal etwas getan werden muss.
Zurück zum ersten Teil der Open Source Trends 2011
Related posts:
]]>