Monthly Archives: November 2010

Wochenrückblick 2010-47

Posted on by
Reply

Ferien im Familienumfeld. Erholung. Auch das gehört dazu, um wieder produktiv und fokusiert zu arbeiten.

Ich konnte diese Woche noch das Buch “Focus” von Leo Babauta fertiglesen. Es ist ein äusserst inspirierendes Buch und hat mich zu einigem Nachdenken bewegt. Wie will ich arbeiten? Bin ich ein Schifflein, welches sich von den ganzen äusseren Einflüssen herumtreiben lässt, oder doch eher ein Motorboot, dass die verfügbaren Technologien zum eigenen Nutzen einsetzt. Einige Ideen sind doch ein wenig extrem, aber als Denkanstoss geradezu perfekt.

Als erste Aktion daraus habe ich die E-mail Notifikation an meinem Handy abgestellt. Eine Ablenkung weniger (nachdem ich die Twitterbenachrichtigung bereits vor Wochen deaktiviert habe).

Lessons Learned

Wie könnte es auch anders sein: Konzentration macht nicht nur glücklich sondern auch produktiv. Schön eins nach dem andern machen.

Gutes Lesematerial dieser Woche

Die folgenden Blogbeiträge fand ich diese Woche besonders lesenswert.

  • Track your Happiness: Mein Glück, wissenschaftlich vermessen: Fokus ist der Schlüssel zum Glücklich sein. E-mails, Skype, Facebook… alles lenkt ab. Wirklich Glücklich sind wir, wenn wir an einer Arbeit/Tätigkeit, welche uns Spass macht, konzentriert arbeiten und etwas erreichen. Ist eine Harvard Studie.
  • Achieving, without goals: Zielsetzen ist extrinsische Motivation. Viel besser wäre jedoch intrinsische Motivation: Ich will etwas machen, weil ich es von innen heraus will und nicht weil, es von aussen diktiert wird. Ziele helfen uns, uns zu fokusieren. Wir können jedoch nicht wissen, was in einem Monat ist… vielleicht ist das Ziel bis dahin gar nicht mehr der richtige Weg. Daher: Einfach aufgeregt sein, etwas zu machen und es dann machen. Dann braucht es auch kein Ziel mehr.
  • Burnout Busters: 10 Ways to Cope When Work Becomes Overwhelming: 10 nützliche Tipps, wenn sich die Arbeit mal wieder meterhoch stapelt und man nicht genau weiss, wo man anfangen ist.
  • Focus. Wie bereits oben erwähnt.

Drupal oder WordPress als CMS, Vergleich

Posted on by
17

WordPress ist das schlanke schnelle Drupal. Für mehr als 3 Jahre habe ich jetzt bereits aktiv mit Drupal gearbeitet. Ich habe einige sehr schlechte Sachen programmiert aber auch ein paar sehr gute. Ich würde meinen, ich kenne Drupal. Da ich mich jetzt jedoch aus der Entwicklerszene zurückgezogen habe, wollte ich ein Blogging System, welches einfach ist und einfach nur bloggt und nicht viel Wartung brauch. WordPress. Hoffentlich.

Gehostete Lösung

Einfachste Möglichkeit ein Blog zu betreiben ist, wenn man es hosten lässt. Ich habe auch einige Dienste angeschaut, darunter Blogger (von Google), Drupal Gardens (von Acquia) und WordPress. Blogger gefällt mir einfach per se nicht. Drupal Gardens ist eigentlich sehr hübsch und gefällt mir sehr gut, ist jedoch sehr langsam im Backend. Ich glaube die Jungs arbeiten dran. Es war einfach irgendwie nicht wirklich spassig damit zu arbeiten. WordPress.com hat mir ausgezeichnet gefallen, aber die haben komische Bedingungen bezüglich Werbung. So habe ich mich entschlossen WordPress selber zu hosten.

Vorteile von WordPress

  • WordPress sieht extrem hübsch aus
  • Es gibt eine enorme Auswahl an ansprechenden Themes für WordPress. Sorry, aber da kann Drupal echt nicht mithalten
  • Stellt man WordPress und Drupal auf eine Waage, dann spielt WordPress in der Fliegengewichtsklasse wären Drupal im Schwergewicht ist (WordPress hat nach der Grundinstallation 12 Tabellen in der DB, Drupal 55)
  • WordPress hat alles, was man zum Bloggen braucht einfach so eingestellt: Kategorien, Tags, Autosave, zeitgesteuertes Publizieren, hübsches Dashboard, Spam Schutz, hübsche Themes, sehr netter wysiwyg Editor. Ohne noch zusätzlich was zu installieren.
  • Es gibt sogar eine Android App für WordPress, wo man bequem Posts schreiben und bearbeiten kann

Sind doch einige Lorbeeren für WordPress. Das ist wohl auch der Grund, warum WordPress so beliebt ist. Jeder kann Bloggen. Was leider bei Drupal out of the box nicht ganz der Fall ist. WordPress hat aber auch einige Macken:

Macken von WordPress

  • Plugin Stabilität und Konsistenz. Sorry, aber ich habe einige Plugins installiert, welche einfach eine weisse Seite produziert haben. Und dann gibt es überall in den Modulkonfigurationsseiten diese “PayPal Donate” Knöpfe… nervig.
  • Plugins und Themes sind überall verstreut. Ist irgendwie auch nicht immer sehr vertrauenserweckend, etwas von irgend einer Seite runterzuladen und zu installieren.
  • Der Code. Da erschaudere ich. Die Theme Templates erinnern mich an meine schlechten Drupal Themes. Als Designer darf man PHP Code nicht scheuen
  • Strikte Trennung von Design und Logik wird mit Füssen getreten. Mein aktuelles Theme hat einige sehr coole Funktionen, welche jedoch ans Theme gebunden sind. So gibt es Themes, welche sich um SEO kümmern, welche bestimme vorgefertige Blöcke mitbringen und sonst noch alles Mögliche im Hintergrund machen… was wiederum eine Stärke ist, weil es erlaubt, schönere Themes zu machen.

Drupal Power

Drupal ist ein extrem mächtiges Framework:

  • Super Community. Module sind fast ausschliesslich über Drupal.org erhältlich. Werbung in den Modulen ist eigentlich Tabu. Entwicklungsworkflow ist standardisiert und mit Simpletest sind auch Leitplanken für die Qualitätskontrolle gegeben.
  • Extrem flexibel. Das Hook System mag zwar einschüchternd klingen, ist aber ultra flexibel. Hacken von Code wird dadurch ausgeschlossen… fast ;) . Module wie CCK und Views verschaffen zusätzliche Flexibilität.
  • Theme Layer mit Preprocess Funktionen ist sehr transparent und ermöglicht klare und saubere Templatedateien.
  • Grosse Anzahl an qualitativ hochwertigen Modulen. Es gibt immer wieder neue innovative Ideen, welche in einem Modul resultieren

Die dunkle Seite von Drupal

  • Out of the Box gibt es nur sehr wenig und sehr hässlich, obwohl dies mit entsprechenden Profilen vermehrt auch möglich ist und hoffentlich mit Drupal 8 noch verbessert wird. Mit OpenAtrium, OpenPublish und ManagingNews gibt es einige extrem gute Produkte. Ich habe ziemlich gestaunt, als ich das erste Mal OpenAtrium installiert habe.
  • Themes. Out of the Box wird man kaum ansprechende Themes finden. Es gibt sie, aber sie sind überschaubar
  • Komplexität. Bezüglich Ressourcen ist Drupal nicht gerade ein Sparfuchs. In der DB werden ordentlich Tabellen angelegt und auch bezüglich Memoryverbrauch muss man einiges in Kauf nehmen.

Also, WordPress oder Drupal?

Es kommt drauf an. Ich habe mein Blog jetzt hier auf WordPress und bin eigentlich glücklich und habe relativ wenig Zeit investiert und falls ich mal Lust auf ein anderes Theme habe, dann ist das kein Problem, etwas passendes zu finden. Eine “richtige” Seite zu bauen, mit eigenen Ideen und Vorstellungen, wo ich mich nicht an Systemvorgaben halten muss, möchte ich jedoch lieber mit Drupal machen. Der Spassfaktor ist definitiv höher.

“Standing on the Shoulder of Giants“. Drupal ist definitiv so ein Riese (Giant). Manchmal ist es jedoch nicht angebracht, und um ein ein Wurmloch zu kriechen auch eher aufwändig, da man zuerst den Bagger auffahren muss.

Ein Blick über den Tellerrand lohnt sich

Die letzten 3.5 Jahren war ich sehr auf Drupal fokusiert. Zu einem gewissen Grad ist das auch berechtigt, denn um in die Tiefen von Drupal vorzudringen (und gewisser Module, wie CCK und Views) ist Zeit notwendig. Ein Tag hat jedoch lediglich 24 h.

Ein Blick über den Tellerrand zeigt jedoch, dass es auch andere gute Systeme gibt. Es braucht keine Schwarz/Weiss Brille. Unterschiedliche System können nebeneinander existieren. Ich habe nichts gegen WordPress. Das Gleiche auch mit Betriebssystemen. Während den letzten 1.5 Jahren fand ich, Linux war genau das richtige System als Drupalentwickler. Wenn ich jedoch in Zukunft mehr Office Sachen machen werde, denke ich, ist Windows wohl besser geeignet. Jedes (oder sicher viele) Tools haben ihre Nische.

Also Schluss mit “Wir Drupalianer sind die Besten, die anderen sind nichts”, lernen wir voneinander. Nehmen die guten WordPress Sachen in Drupal rein und WordPress wiederum kann sich einiges von Drupal abschauen.

Jedes Ende ist auch ein neuer Anfang

Posted on by
2

Diese Woche hatte ich meinen letzten Arbeitstag bei der Previon. Die Tage davor habe ich hauptsächlich mit Arbeitsübergabe und Aufräumen verbracht. Dazu gehörten diverse Meetings bezüglich laufenden Projekten und noch zu lösenden Problemen. Es ist definitiv ein ein angenehmes Gefühl zu wissen, dass man noch seinen Senf dazu geben kann, aber ihn dann nicht mehr ausbaden muss. Die Illusion, dass es keine Probleme mehr geben wird, habe ich definitiv nicht aber die kommen frühestens in einer Woche. Ein Leben ohne Herausforderungen wäre definitiv zu langweilig.
Jedes Ende ist ein neuer Anfang und somit die Möglichkeit, Dinge besser zu machen. Es ist immer einfach, Dinge von Anfang an korrekt zu machen, als eine falsche Gewohnheit in eine Richtige umzuändern.

Mein neuer Anfang

Ich habe mir bereits einige Dinge vorgenommen, welche ich definitiv verbessern will. Dazu gehören unter anderem:

  • Die Zeit, welche mir zur Verfügung steht optimal nützen und planen. Besonders im Planen war ich nicht besonders gut. Ich habe immer versucht sofort auf Anfragen zu reagieren, was dazu führte, dass ich die aktuelle Arbeite unterbrechen muss. Eine bessere Alternative wäre evtl. gewesen alle 2x pro Tag ein Reaktionsfenster einzubauen: E-mails und Fragen beantworten. Ich bin gerade das Buch “Focus – A simplicity manifesto in the Age of Distraction” am Lesen und habe diesbezüglich noch viel Verbesserungspotential. Ich mag den Spruch: “If you fail to plan you plan to fail.”
  • Protokoll schreiben. Wahrscheinlich gibt es niemand, der gerne Protokolle schreibt. Ich durfte jedoch gerade erst wieder die Erfahrung machen, dass man es zum Selbstschutz machen muss. Das Protokoll muss nicht wirklich lang sein, aber Be- und Entschlüsse müssen zwingend rein. Ansonsten hört man 3 Wochen später, nachdem das Projekt bachab geht: “Nein, das habe ich nicht so gesagt”. Jeder weiss, dass zu jeder Sitzung ein Protokoll gehört und doch gibt es wohl unzählige Sitzungen ohne Protokoll.
  • Kommunikation. Nicht nur Bla bla, sondern unter Benutzung des situationsgerechten Mittels und an die richtigen Leute. E-Mail (mit x Einträgen im CC) zu schreiben ist sehr einfach, aber kann auch sehr einfach falsch verstanden werden. Ein Besuch vor Ort oder ein Telefonanruf ist oftmals effizienter als 10x hin und her zu mailen. Wir sind schliesslich immer noch Menschen und schätzen auch die zwischenmenschlichen Werte.

Das oben genannte E-Book “Focus – A simplicity manifesto in the Age of Distraction” kann ich allen empfehlen. Ich habe zwar nicht immer die gleiche Meinung wie der Autor, aber gerade deshalb regt es zum denken an. Ist im Moment nur in Englisch erhältlich und kann als E-Book heruntergeladen werden. Sobald ich fertig bin, werde ich hier ein entsprechendes Review schreiben.

Good bye Drupal & Previon – Hallo Synthes & PM

Posted on by
4

Time to say good bye. Vor 3 Jahren und 28 Wochen habe ich mich auf Drupal.org registriert. Angefangen hat alles mit meiner Bachelor Arbeit an der Uni Zürich. Ich musste eine kleine YouTube App schreiben. Angefangen habe ich ohne Framework, doch als es dann an die Benutzerverwaltung ging, habe ich mich entschlossen auf Drupal zurückzugreifen. Ein sehr weiser Entscheid, wie sich später herausstellte.

Damals ist Drupal 5 gerade frisch geboren… ein riesiger Hype… alle freuten sich. Für mich war das damals noch wenig verständlich. Den Code den ich für diese Anwendung geschrieben habe war… grauenvoll. Viele Kittens mussten wohl sterben. Die Drupal API war mir ein Fremdwort, und so habe ich das meiste selber geschrieben ;)

Rapsli the Freelancer und Drupalianer

Während dem Studium habe ich als Freelancer gearbeitet. Dabei wurde Drupal immer mehr gefragt und so konzentrierte ich mich nach einiger Zeit ausschliesslich auf Drupal. Die Community ist super! Danke an alle, die mir jeweils via IRC, Forum und Issue Queue geholfen haben. Nach Abschluss des Studiums bin ich von einem Student und Freelancer zu einem Previonauten mutiert (habe bei der Previon angefangen zu arbeiten).

Rapsli the Previonaut

Es war eine genüssliche Zeit, voll konzentriert auf die Entwicklung und ich war froh, dass ich das CSS einfach an  Kriegel unserem Designer abschieben konnte. Es ist ein herrliches Gefühl, wenn man weiss, dass es dort in guten Händen aufgehoben ist und man sich nicht darum kümmern muss.

Bei der Previon durfte ich an einigen grösseren Projekten mitarbeiten, z.B. die Schweizer Illustrierte, Evangelisch.de, Presseportal für die AMAG und die Website für den Schweizerischen Versicherungsverband.  Und zudem einige wertvolle Erfahrungen im Bereich Performanceoptimierung, Serveradministration, Projektmanagement und agilen Entwicklungsmethoden (neben dem ganzen Drupal Know-how natürlich) sammeln. An dieser Stelle eine Dankeschön an alle Previonauten. Es war eine coole Zeit und ich wünsche allen weiterhin viel Spass.

Rapslis Zukunft?

Rapslis am MeerWie man bereits den Blogposts der vergangenen Wochen anmerkt, werde ich die Entwicklung in Richtung Projektmanagement verlassen. Ich werde ab Dezember bei der Synthes als Web Project Manager tätig sein… ob die sich dort Synthesisten nennen?

Neben Familie, Job und ein wenig Sport bleibt dann meistens nicht mehr sehr viel Zeit übrig. Von daher denke ich, werden sich meine entwicklerischen Tätigkeiten in Zukunft massiv reduzieren. Ich hoffe jedoch, dass ich als Projektmanager auch in Zukunft auf Drupal zurückgreifen kann und so doch noch einige spannende Projekte mit Drupal umsetzen kann. Daher werde ich wohl vermehrt anstatt Drupal T-Shirt ein Hemd anziehen und am Morgen anstatt länger zu schlafen, die Zeit zum Rasieren nutzen :(

Wo die Reise hier im Blog hingeht, kann ich jetzt noch nicht sagen. Ich würde jedoch vermuten, dass es wohl in Zukunft über weniger technische Angelegenheiten bloggen werde und vor allem nicht mehr ausschliesslich Drupalorientiert. Nichtsdesto trotz hoffe ich, dass ich noch ein paar Leser behalten werde und sich Drupal weiter so positiv entwickelt… ich werde nachwievor auf die Qualitäten von Drupal zählen.

Zum Schluss: Blogpost datiert vor 1.5 Jahren.

Änderungen an Rapslis World

Posted on by
3

Meine treuen Leser werden festgestellt haben, dass ich das Blog mal wieder verändert habe: Ein neues Design und noch viel wichtiger, ich habe die darunterliegende Software ausgewechselt. Wer ein wenig genauer hinschaut, wird feststellen, dass hier nicht mehr Drupal am Werkeln ist, sondern WordPress. Skandal? Nein, ich habe meine Gründe, welche ich jedoch nicht hier erläutern möchte, bzw. noch nicht jetzt.

Die letzten paar Stunden, welche ich mit der Migration und Einrichtung verbracht haben, haben mir einen grossen Einblick in WordPress gegeben. Sehr beeindruckend muss ich sagen. Nicht schlecht, nicht schlecht.

Ich möchte an dieser Stelle nur festhalten: Falls Links ins Leere zeigen oder sonst noch Fehler sind, so freue ich mich immer über eine kleine Nachricht. Feeds sollten von der Migration hoffentlich nicht betroffen sein.

Die Scrum-Baby-Fütterung-Analogie

Posted on by
2

Jeder der schon mal einem 2 jährigen zu Essen geben musste/durfte, weiss, dass dies eine grosse Herausforderung sein kann. Ich durfte dies vor ein paar Tagen wieder mal bei meiner Tochter erfahren. Ich habe aber auch gemerkt, dass Scrumprinzipien bei der Fütterung behilflich sind. Wollen wir doch mal kurz die verschiedenen Prozesse bei der Fütterung analysieren. Continue reading →

Scrum und Getting things done (GTD)

Posted on by
4

Scrum (übersetzt Gedränge -> Chaos) und “Getting things done” (GTD, alles strukturiert und ordentlich) haben mehr miteinander zu tun als man denkt.

In der Software Entwicklung bei meinem Arbeitsgeber bin ich massgeblich an der Einführung von Scrum beteiligt. Scrum hat mich so begeistert, also habe ich versucht, die Scrum Ideen auf meine täglichen Arbeiten zu übertragen. Erst später habe ich von GTD erfahren und konnte mit Freude feststellen, dass meine Arbeitsabläufe stark denen von GTD ähneln.

Zusammenfassung Scrum

Scrum gehört zu den agilen Entwicklungsprozessen. Oberstes Ziel von agilen Entwicklungsprozessen ist ein zufriedener Kunde. Der Kunde sieht nach jedem Sprint (Iteration) ein fertiges Zwischenprodukt. Er kann spielen und testen und Feedback geben, ob sich das Projekt/Produkt in die gewünschte Richtung entwickelt. Falls Diskrepanzen zwischen seiner Vision und dem Zwischenprodukt bestehen/entstehen, kann der Produktowner Korrekturen anbringen.

Der ungefähre Scumablauf sieht wie folgt aus:

  1. Product Backlog mit Userstories füllen und diese schätzen. Eine Userstory umfasst gewünschte Features, welche wiederum aus konkreten Tasks bestehen.
  2. Wichtigste Userstories durch Productowner selektieren und in Sprintbacklog übertragen. Ein Sprint ist eine Iteration (z.B. 1 Monat oder auch nur 1 Woche). Nach 1 Monat sind die Userstories aus dem Sprint umgesetzt und getestet und die Software ist einsatzfähig.
  3. Team organisiert sich, damit die Userstories im Sprint umgesetzt werden können. Dazu trifft sich das Team täglich für max 15 Minuten zum Daily Scrum. Wenn ein Sprint definiert ist und sich das Team dazu verpflichtet hat, dann kommen keine neuen Features mehr rein (die müssen dann auf den folgenden Sprint warten).
  4. Bei Sprintende gibt es die Retrospektive: Was ist gut gelaufen, was schlecht, was wollen wir verbessern.
  5. Das Zwischen-End-Produkt wird vom Kunden begutachtet, Feedback gegeben und abgenommen. Es geht wieder zu Schritt 2.

Wer es genauer wissen will, es gibt sehr viele Ressourcen. Einfach mal bei Google oder Wikipedia anfangen oder schauen, was es hier im Blog zu Scrum gibt.

scrum prozess

Quelle: Wikipedia – Sebastian Wallroth – Der Scrumprozess schematisch dargestellt. Zentral sind die Sprints (Iterationen), welche jeweils ein lauffähiges Produkt erzeugen.

Zusammenfassung GTD

Der GDT Prozess von David Allen sieht eigentlich sehr ähnlich aus. Alle Aufgaben, die reinkommen werden aufgeschrieben. Ziel: 1 zentraler “Posteingang”. Dieser kann papierig oder Elektronisch sein, halt was einfacher ist. In regelmässigen Abständen wird dieser Kanal (diese Kanäle) durchgearbeitet und in Kontextlisten sortiert (z.B. @Telefon, @Büro, @Einkaufen usw.) und bestimmt, welche Punkte wann erledigt wird.

Die folgende Grafik zeigt es noch ein wenig ausführlicher auf. Und wer mehr wissen möchte soll einfach mal Google befragen.

Getting Things Done Prozess

Quelle: Wikipedia – René Weber – Der GTD Prozess schematisch dargestellt mit ein wenig mehr Details, als ich sie zusammengefasst habe.

Die Grafik sieht es vielleicht nicht sehr ähnlich (einfach) wie die von Scrum aus, wenn man jedoch alles mal gedanklich durchspielt, dann stellt man doch grosse Ähnlichkeiten fest.

Der Rapsli Prozess

GTD kannte ich bis vor einigen Tagen lediglich vom Namen, wusste jedoch nicht, was sich dahinter verbirgt. So habe ich mein eigenes “Framework” gebaut, welches auf Scrum basiert aber anscheinend viel Ähnlichkeit mit GTD aufweist. Dabei beachte ich folgende Grundsätze:

  1. Einfachheit. Sonst besteht die Gefahr, dass man an den Prozessen erstickt. Einfache Dinge mache ich lieber.
  2. Regelmässigkeit. Der Mensch ist ein Gewohnheitstier. Einfache Dinge sind auch einfacher regelmässig durchzuführen.

Mein Prozess sieht daher wie folgt aus:

  • Ich habe zwei Backlogs: Eine Excel Tabelle und eine Taskliste (Remember the Milk). Die Excel Tabelle ist für vage Aufgaben, Ideen, interessante aber nicht konkrete Gedanken. In dieser Liste gibt es auch eine Selektion “Ziele”. Die Taskliste umfasst explizite Tasks, welche nach der Umsetzung sofort abgehakt werden können.
  • Sprintdauer beträgt 1 Woche. Immer am Freitag nehme ich mir 15-30 Minuten Zeit (fest im Terminkalender eingeplant), um mein Backlog durchzuschauen. Unter Umständen ergibt sich aus den Gedanken (aus der Excel Liste) ein konkreter Task. Zudem führe ich eine kurze Selbstreflexion durch, wie ich an meinen längerfristigen Zielen vorankomme und schreibe in ein paar wenigen Stichworten auf, was ich gelernt habe (damit ich beim wöchentlichen Review schnell die vergangenen Lessons Learnt durchschauen kann)
  • Täglich schaue ich ganz kurz 1x auf alle Tasks (besonders die ohne Enddatum) und schaue, ob sich etwas davon am kommenden Tag einfach erledigen lässt.

Grösste Herausforderungen

Wichtigster und ebenfalls schwierigster Punk (meine Meinung) ist das konsequente Sammeln von Informationen. Schlussendlich ist es einfach ein Gewohnheitssache, Informationen nicht einfach im Kopf zu archivieren (und damit vergessen), sondern effektiv zu Papier zu bringen.

Was Bringts?

Ich habe viele (meist) kleinere Aufgaben, welche ich leicht vor mir herschieben kann (meistens wenn mich niemand dazu drängt) und hoffentlich (wahrscheinlich) bin ich nicht der Einzige mit diesem Problem. Jetzt jedoch, wenn ich einen Task auf meiner Liste habe, dann gebe ich auch mein Möglichstes, um das zu erledigen. Falls ich es nicht schaffe, dann lege ich mir gegenüber auch Rechenschafft darüber ab.

Meine Frau profitiert ebenfalls davon, denn ich habe endlich die Kartonschachtel, welche seit Wochen im Schlafzimmer steht aus- und weggeräumt.

Was für ein System setzt du ein, um möglichst viel in möglichst wenig Zeit zu erledigen (bzw. überhaupt etwas zu schaffen)?

Foto via Flickr by darkmatter’s

Schluss mit öden Corporate PowerPoint Präsentationen

Posted on by
2

Ich finde diese Corporate PowerPoint Präsentationen immer todlangweilig. Die sehen doch immer gleich aus: Irgendwo das Logo, irgend ein Header und ein Footer, wo noch ein wenig Datu, Firmenname usw. drin steht. Dann links ein bisschen Text und rechts ein Bild. Langweilig.

Ich habe mal mit Prezi ein wenig herumexperimentiert. Sehr erfrischend. Besonders um Präsentationen zu erstellen, kann man Mindmappingmässig vorgehen und dann am Schluss alles miteinander verbinden.

Aber auch mit PowerPoint lassen sich extrem cool Präsentationen machen:

Drupal Freelancer verdienen mehr als Joomla Freelancer

Posted on by
9

Ein Drupal Freelancer verdient im Durchschnitt knapp 1000$ pro Projekt, während ein Joomla Freelancer für ein Projekt knapp 500$ verdient. Das ist auf jeden Fall die Aussage einer Studie, welche von DoNanza (grösste Suchmaschine für Heimarbeit und Freelancearbeiten) durchgeführt wurde. WordPress Entwickler sind sogar noch etwas tiefer.

Ich stelle mir die Frage, was zu dieser Kluft führt. Sind Joomla Entwickler weniger talentiert, lieferen schlechtere Qualität und sind daher schlechter bezahlt? Wohl kaum. Als Grund für diese Kluft sehe ich viel eher die unterschiedliche Marktposition von Drupal und Joomla:

Drupal: Anspruchsvolle, grosse Communityprojekte, komplexe Designs, viel Individualismus.
Joomla: KMU und Vereinsseiten.Grafik

Durchschnittliches Projektbudget bei WordPress-, Joomla- und Drupalprojekten.

Sicher gibt es Ausnahmen. Ich denke jedoch, dass dies in etwa die Richtung aufzeigt. Nehmen wir einfach mal an, diese Annahme stimmt (Kommentar ist offen, falls du anderer Meinung bist), dann gibt es u.a. folgende Variablen, welche das Honorar (Projektbudget) beeinflussen: Projektdauer, Qualifikation des Entwicklers und in der heutigen Globalisierung der Projektumsetzungsort (grosser Unterschied ob in der Schweiz oder in Ungarn).

Diagram

Anzahl an Projekten in WordPress, Joomla und Drupal

Noch vorweggenommen: Es geht nicht genau hervor, ob die Zahlen auf Themer, Entwickler oder “Modulkenner und Klicker” (also derjenige, der die Seite konfiguriert) bezogen sind, sprich mit oder ohne PHP Kenntnisse. Ich gehe mal einfach davon aus, dass für die Zahlen in Joomla eher weniger PHP Kenntnisse benötigt werden als für Drupal (eine gute Drupalsite ohne PHP zu bauen ist sehr utopisch).

Drupalprojekte dauern länger

Logischerweise, je länger ein Projekt dauert, umso teurer wird es. In der Studie wäre es daher noch interessant, dies zu erfahren, was wir leider nicht können. Daher müssen wir auf unsere Annahme zurückgreifen: Drupal: grosse Communityprojekte, Joomla: KMU. Wir können somit annehmen, dass die Drupalprojekte im Durchschnitt länger dauern. Ein Drupalentwickler kann somit auch weniger Projekte pro Jahr durchführen. Kein Grund also, dass Drupal Entwickler besser verdienen.

Drupal Entwickler sind besser qualifiziert als Joomla Entwickler

Verbleibt noch die zweite Variable: Qualifikation des Freelancers. Und wie lässt sich diese messen. In der Wirtschaft ist (oftmals) der Stundensatz ein Gradmesser für Qualifikation (ob der Lohn von Gates oder Vasella lediglich von ihrer Qualifikation abhängt…???). Als ich als Drupal Freelancer während dem Studium gearbeitet habe, war mein Stundensatz noch bedeutend tiefer als er dies jetzt sein würde. Alles was sich geändert hat, ist ein Masterdiplom, welches ich besitze und 2 Jahre Erfahrung. Interessant wäre, wenn noch irgend ein Java oder .Net CMS in der Statistik wäre. Ich würde davon ausgehen, dass dort das Einkommen pro Projekt nochmals massiv höher ist, da die Einstiegshürde höher ist und höhere Ansprüche an den Entwickler gestellt werden. Vor ein paar Monaten habe ich mal ein wenig mit dem Java Springframework experimentiert (wenn Drupal ein Kinderdisney Buch ist, dann ist das Java Springframework “Krieg und Frieden” von Leo Tolstoi). Ein Javaprojekt umzusetzen erfordert daher auch ein höheres Budget, da mehr Komplexität und besser Qualifizierte Entwickler benötigt sind.

Ich gehe daher mal davon aus, dass Drupalentwickler tendenziell besser ausgebildet sind als dies ein Joomla Entwickler ist. *…ich lass mich mal wieder auf eine hitzige Diskussion ein…*. Ich denke jedoch, dass allgemein in PHP Projekten gut ausgebildete Entwickler/Architekten fehlen.

Drupal fehlen kompetente Entwickler

So. Ich habe mir wieder Feinde geschaffen. Ich denke jedoch, dass es wirklich ein Problem von Drupal/PHP ist, gute Software Entwickler/Engineere zu finden (nicht dass es die nicht gibt, aber neben den guten Entwickler gibt es auch sehr viel Ramsch). Die Art und Weise, wie ein ausgebildeter Entwickler Probleme löst ist komplett anders, als dies ein “Garagenprogrammierer” macht. Die Fähigkeiten, Probleme zu erkennen, zu verstehen und selbstständig Lösungen zu entwickeln ist anspruchsvoller als man denkt. Es ist jedoch für einen ausgewachsenen Software Engineer, welcher 4-5 Jahre studiert hat, wenig attraktiv ein paar Websites zu bauen. Ein Tiefbauengineer baut wohl auch lieber den Gotthard Tunnel als ein Sandloch. Wäre ein interessantes Thema für einen eigenen Artikel. Daher ist es wohl auch so schwierig gute PHP Leute zu finden.

Nicht zuletzt ist es auch ein Lohnproblem. Die Grafik von indeed.com zeigt dieser sehr schön auf. PHP ist verhältnismässig einfach zu erlernen und wird in eher einfacheren Projekten eingesetzt. Die Löhne sind daher auch tiefer.

Lohngrafik

Quelle: indeed.com

Fazit

Wer schlussendlich besser verdient lässt sich nicht wirklich aus den Zahlen belegen. Schade ;) . Es zeigt jedoch wieder mal, dass für alle ein Markt vorhanden ist. Joomla und WordPress wachsen schnell mit einfachen und kleineren Projekten. Drupal sucht sich die grösseren, individuelleren Projekte heraus, obwohl hier vermehrt auch Anstrengungen im Gang sind, Drupal als Produkt (z.B. OpenPublish, OpenAtrium usw) besser am extrem schnell wachsenden Joomla Markt zu platzieren.

Was sind deine Erfahrungen? Verdienen Drupalentwickler besser?

Drupalseiten einfach für Mobile aufbereiten (Tutorial) – Teil II

Posted on by
5

Mobile

Im ersten Teil ging es darum, das Theme zu wechseln, sobald ein Benutzer mit einem Mobiltelefon kommt. Das ging ja auch ganz einfach, wir verlieren dabei jedoch Cachingmöglichkeiten. Für kleinere Seiten sicher kein Problem, falls es etwas grösser wird jedoch undenkbar.

Caching wird ab einer bestimmten Popularität der Webseite unumgänglich. Daher ist es doch sehr erstrebenswert, auch für unser Problem eine Lösung zu finden. Wollen wir doch zuerst mal ganz schnell ein paar Cachingmechanismen in Drupal anschauen:

  • Einzelne Elemente cachen (z.B. Blockcache). Nehmen wir an, wir hätten einen Block der die Weltformel berechnet und das dauert 20 Sekunden. Wir wollen natürlich nicht, dass diese bei jedem Seitenaufruf neu berechnet werden wird, da das Resultat jeden Tag gleich bleibt: Wir berechnen den Block einmal und zwischenspeichern (cachen) das Resultat. Dem nächsten Besucher wird dann der bereits berechnete Block serviert.
  • Für den anonymen Besucher wird die ganze Seite gecached. Z.B. der Page Cache oder Boost. Vom Prinzip her genau gleich wie das Beispiel vorher, aber halt auf die ganze Seite bezogen.

Nehmen wir also an, wir schalten den Page Cache an:

  1. Ein Besucher (Fritz) kommt. Drupal und die Datenbank rechnen und rendern. Die Seite wird ausgegeben und das ausgegebene Stück HTML wird zwischengespeichert.
  2. Ein weiterer Besucher (Hans) kommt auf die selbe Seite. Bevor Drupal überhaupt irgend etwas macht, wird im Cache geschaut, ob da evtl. bereits etwas vorhanden ist: Hurra, ja: Seite servieren und schluss.
  3. Ein IPhone Jünger (Steve, natürlich via IPhone) kommt auf eine neue Seite (die weder Fritz noch Hans vorher besucht haben). Drupal schaut im Cache, findet nichts. Drupal merkt, aha, hier kommt ein IPhone daher, also Theme umstellen. Jetzt wird gearbeitet und die Seite zusammengestellt und das HTML schlussendlich ausliefern und im Cache ablegen.
  4. Hans folgt Steve. Drupal schaut wieder im Cache und findet eine Seite, weiss jedoch nicht, dass die im Cache liegende Seite eigentlich nur für Mobilgeräte gültig ist. Hans bekommt nun die Mobileseite ausgeliefert… er wird wohl nicht wirklich begeistert sein.

So. Wir haben also zwei Möglichkeiten. Beide sind in Drupalumsetzbar:

  1. Die Mobileseite so auslieferen, dass Drupal für Mobile und Desktop das Gefühl hat es wäre eine andere Seite (mittels Subdomain)
  2. Den Cachingmechanismus so anpassen, so dass er nach Theme unterscheidet.

Ich habe mich für die erste Möglichkeit entschieden, da diese viel einfacher umsetzbar ist:

  1. Einen Domainalias http://m.rapsli.ch anlegen (die Domain zeigt auf den gleichen Server wie rapsli.ch), ein sog. Domain Alias. Leider wird diese Möglichkeit nicht von allen Hostern angeboten (besonders nicht von den günstigen).
  2. Jetzt geht es nur noch darum, mobile Geräte auf diese Domain weiterzuleiten. Dazu dient ein einfacher Eintrag in der Datei .htaccess
1. RewriteCond %{SERVER_NAME} !^m.rapsli.ch$ [NC]
# a bunch of user agent tests
2. RewriteCond %{HTTP_USER_AGENT} (nokia|symbian|iphone|blackberry|android) [NC]
3. RewriteRule ^(.*)$ http://m.rapsli.ch [L,R=301]

Kurze Erklärung dazu:

Zeile 1: Da es es lediglich um einen Domain Alias handelt, verwenden beide Domains das gleiche .htaccess. Um zu vermeiden, dass ein Mobilgerät immer wieder weitergeleitet, machen wir auf der Subdomain nichts.
Zeile 2: Wir stellen die Bediengung, dass es nokia, symbian, iphone,…. ist
Zeile 3: Falls das alles zutrifft, dann machen wir die Weiterleitung auf m.rapsli.ch

Das war es dann eigentlich auch schon. Jetzt können wir den Cache auch wieder einschalten.