Rapslis Drupal World - Drupal

Drupal Freelancer verdienen mehr als Joomla Freelancer

rapsli — Mon, 08 Nov 2010 08:30:17 +0000

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.

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).

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.

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

rapsli — Thu, 04 Nov 2010 07:04:14 +0000

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:

Ein Besucher (Fritz) kommt. Drupal und die Datenbank rechnen und rendern. Die Seite wird ausgegeben und das ausgegebene Stück HTML wird zwischengespeichert.
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.
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.
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:

Die Mobileseite so auslieferen, dass Drupal für Mobile und Desktop das Gefühl hat es wäre eine andere Seite (mittels Subdomain)
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:

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).
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.

Verwandte Beiträge:

Drupalseiten einfach für Mobile aufbereiten (Tutorial)

rapsli — Wed, 03 Nov 2010 07:57:01 +0000

Mit dem IPhone ist das mobile Internet in eine neue Runde gegangen. Das WAP hat ja nicht wirklich den Durchbruch geschafft. Ich glaube ich war 1x auf einer WAP Seite mit meinem Handy und auch genauso schnell wieder weg. Fürchterlich. Zweckdienlich, aber nicht wirklich spassig.

Jetzt sieht es schon ganz anders aus. Täglich bin ich eigentlich mobile im Internet unterwegs. Zu den Websites welche ich fleissig aufrufe gehören u.a. Tagesanzeiger.ch und Twitter. Erst da merkt man, wie viel angenehmer es ist, auf einer solche Seite zu lesen anstatt eine ganz normale, welche nicht fürs Mobile optimiert ist. Auf diesen Seiten muss man dann nämlich immer blöd nach rechts scrollen. Nervig.

Noch nerviger: Das Feed wird nur als Teaser freigegeben. Das führt dann dazu, dass man auf die Seite gehen muss um den kompletten Eintrag zu lesen und die Seite ist dann meistens nicht für Mobile optimiert -> diese Einträge lese ich dann in vielen Fällen nicht.

Meine Bitte: komplettes Feed rausgeben. Alle Mobileleser werden euch dafür dankbar sein.

Also, ich habe mich immer über mein eigenes Blog genervt. Ich konnte es zwar einigermassen auf meinem Android G1 lesen, aber wirklich gut war auch das nicht. Falls jemand anderer Meinung ist, kann er das gerne im Kommentar geben

Mobile Theme Tutorial - 10 Minuten

Voraussetzungen:

Browscap installieren.
[Update] Mobile Theme installieren (danke redpanda)
Seven Theme aktivieren.

Das ist eigentlich auch schon alles. Das ganze noch konfigurieren und schon macht man alle Mobilebenutzer glücklich:

admin/settings/browscap

admin/build/themes/settings/global

Jetzt noch die Blöcke ein wenig umkonfigurieren. Das Seven Theme kennt links und rechts keine Regions. Sprich, falls man dennoch Blöcke haben möchte, dann würden die wohl ganz unten im Footer am meisten Sinn machen.

Schon fertig und das Internet hat wieder eine Seite mehr, welche auch für Handybenützer einfach lesbar ist. Natürlich lässt sich das ganze noch beliebig ausbauen und verschönern.

Einen kleinen Wehrmutstropfen gibt es allerdings: Falls der Pagecache aktiviert ist, dann funktioniert das ganze nicht. Ausweg: Eine Subdomain, z.B. http://m.rapsli.ch und dann für diese Domain das Theme wechseln.

PS: Irgendwie klappt es nicht so ganz mit Screenshots auf meinem Android. Wäre cool, wenn jemand einen Screenshot irgendwo hochladen könnte. Danke.

Verwandte Beiträge:

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

Scrum in einem Drupalprojekt Teil III

rapsli — Mon, 01 Nov 2010 06:00:41 +0000

Im Teil II dieses Artikels habe ich die allgemeinen Randbedingungen beschrieben. Hier in diesem Beitrag möchte ich ein paar Aspekte beleuchten: Wo sind Fehler aufgetreten, was ist gut gelaufen, was müssten wir besser machen, usw.

Fangen wir doch mal mit den Positiven Sachen an

Kunde war alle zwei Wochen für einen Nachmittag bei uns, um das Projekt anzuschauen und offene Fragen zu besprechen, sowie die Planung der nächsten Aufgaben. Das ganze Team war jeweils während des Eröffnungsteils anwesend. Dadurch hatte auch das ganze Team ein "Gespür" für den Kunden.
Projektstart war extrem positiv. Das Team war voll drin, wurde nicht durch andere Projekte/Arbeiten abgelenkt. Es herrschte super Stimmung. Jeder fühlte sich als Teil des Teams und Projekts. So macht es auch gleich mehr Spass. Die positive Stimmung ist auch immer gut für die Kommunikation. Dailys Scrums waren in dieser Zeit sehr aufgestellt, unterhaltsam und zugleich informativ.
Drupal ist hervorragend für Scrum geeignet. Bereits nach einigen Tagen gibt es eine funktionierende Anwendung, die zwar noch Ecken und Kanten hat, aber immerhin läuft.
Unser Scrumboard war zwar sehr einfach, aber sehr effektiv. Wir konnten uns voll und ganz auf den Scrumprozess konzentrieren, ohne dass wir uns noch mit irgendwelchen Tools hätten plagen müssen. Von daher für den Einstieg ein super gute Lösung: Jeder sieht auf einen Blick, wer gerade woran arbeitet und wer evtl. noch Hilfe braucht.

Es gibt aber auch einige Mängel

Das Projekte verwässerte gegen Projektabschluss: Mitarbeiter wurden aus dem Team gezogen (Todsünde) und viele Ablenkungen durch andere Projekte/Arbeiten waren hier die Hauptkomponenten. Wenn man den Projektverlauf ein wenig genauer anschaut, dann waren die ersten Sprints sehr effektiv: Es gab viel Arbeit, jeder war beschäftigt. Gegen Ende des Projekts gab es dann keine grossen Baustellen mehr, sondern noch schleifen und feilen an den Ecken. Irgendwie gab es hier noch einen Koordinationsmangel im Kleinen.
Leider mussten wir feststellen, dass der Kunde seinen Pflichten nicht nachkam und so extrem viel Inhalt fehlte. Das führte dazu, dass: Migrationen nicht gemacht werden konnten, ein Gesamtbild der Seite sehr spät möglich war und eben User Stories als (theoretisch) abgeschlossen waren, aber halt noch nicht getestet werden konnten, weil noch Inhalte/Daten Fehlten. Beispiel: Paymentschnittstelle Postfinance. Eingekauftes Modul, installiert. Task abgeschlossen. Es fehlten Zugangsdaten, um das ganze auch richtig zu testen. 1 Monat später kamen die dann: 1/2 Tag Aufwand, um es einzurichten und daraus resultierende Fehler noch zu beheben.

Was würde/werde ich im nächsten Projekt anders machen

Den Kunden noch besser mit einplanen und einbeziehen. Dazu gehört meiner Meinung:

Dem Kunden bei Projektbeginn klip und klar machen, dass sein Mitarbeiten unbedingt notwendig ist. Auch der Kunde hat Pflichten! Er muss verstehen, dass wenn er seine Sachen nicht tut, die logische Folge ist, dass sich das Projekt verspätet.
Bessere Definition von fertig. Solange man Userstories abschliessen kann, welche nur die Aufmerksamkeit des Entwicklers brauchen, ist es wohl relativ klar. Sehr oft ist man jedoch auf irgendwelche Daten angewiesen: Zugangsdaten zu Schnittstellen, Musterdaten usw. Fertig ist ein Task erst, wenn diese Sachen mit drin sind ... der Kunde muss das auch verstehen.

Verwandte Beiträge:

Scrum in einem Drupalprojekt

Scrum in einem Drupalprojekt Teil II

Umstieg von Typo3 auf Drupal

rapsli — Fri, 29 Oct 2010 06:29:57 +0000

Vor 2 Wochen habe ich bei ein paar Entwicklern eine kleine Drupaleinführung für Entwickler gemacht. Dabei waren ca. 7 Entwickler anwesend. Einige kamen aus der Joomla Welt (bzw. haben dort Erfahrungen gesammelt) und andere von Typo3. Einen Drupal vs. Joomla Beitrag habe ich ja bereits geschrieben... und der scheint die Gemüter hochzutreiben. Daher ein paar Zeilen zu Drupal vs. Typo3.

Ich muss fairerweise sagen, dass ich keine tiefen Typo3 Kenntnisse habe. Ich habe es vor langer Zeit mal lokal installiert und musste an der Uni einmal ein paar Inhalt ändern. Mag durchaus sein, dass sich seither einiges geändert hat... ich bin schon mal gespannt auf Kommentare

Wie dem auch sei. Aus dem Gespräch mit den Typo3 Kennern kommt immer das eine oder andere heraus. Typo3 scheint auf jeden Fall ein sehr mächtiges Werkzeug zu sein. Respekt. Der grosse Unterschied zwischen Drupal ist jedoch sehr grundlegend:

Inhalte (sog. Nodes) in Drupal landen alle in einem riesigen Topf. Alle sind gleich. Es gibt keine Struktur und es gibt keine eigentlich Seiten, sondern nur lose Inhalte. Es liegt nun am Bauer einer Seite, diese Strukturen herzustellen, dazu gibt es diverse Möglichkeiten: Taxonomy, Inhaltstypen, CCK.

Typo3, so wie ich das sehe, hat Seiten. Sprich: Ich lege eine Startseite, eine About us und eine Kontaktseite an. Dann kann ich natürlich auch Hierarchien anlegen, welche dann in einem schönen Menubaum dargestellt werden. Ich bearbeite jedoch die Seite als ganzes. Möchte ich also einen Inhalt von A nach B verschieben, dann mache ich das wirklich physikalisch... kopieren (wahrscheinlich kann man auch irgendwelche Verküpfungen machen, sollte ein Inhalt doppelt vorhanden sein).

In Drupal ist wie gesagt der Grundgedanke anders und viel weniger auf solche starren Seiten ausgelegt, sondern Inhalt erstellen und dann über Ansichten an den entsprechenden Orten erscheinen lassen.

So, ich lasse mich sehr gerne belehren... Für alle Drupal Fans: Hier kann man mal ein wenig mit Typo3 spielen.

Hier ein paar Screenshots aus dem Backend, wenn eine Seite erstellt wird:

Scrum in einem Drupalprojekt Teil II

rapsli — Wed, 27 Oct 2010 21:07:50 +0000

Vor zwei Monaten habe ich einen ersten Scrum Erfahrungsbericht geschrieben. Damals standen wir noch am Anfang des Projektes. Jetzt zwei Monate später stehen wir mehr oder weniger am Ende. Ein guter Zeitpunkt, um ein kleines (oder grösseres) Fazit zu ziehen.

Wer nicht weiss, was Scrum ist, soll doch am Besten mal bei Wikipedia vorbeischauen. Dort gibt es eine ausführliche Erklärung

Zuerst einige Randbedingungen:

Als Backlog dient Jira. Eine ältere Version ohne Agile/Scrum Unterstützung
Sprintdauer sind zwei Wochen.
Teamgrösse: 4 Entwickler und 1 Designer
Das Projekt basiert auf Drupal. Es ist eine Tageszeitung mit diversen Schnittstellen an Redaktionssysteme und SDA.

Der Prozess sah ungefähr wie folgt aus:

Retrospektive. Dazu musste jedes Teammitglied zu den folgenden 4 Punkten Auskunft geben:
1. Teamgeist
2. Zufriedenheit mit den Tasks
3. Ablenkung von Aussen
4. Kommunikation im Team
Backlog schätzen. Wir haben es mit sog. Scrum-Pokerkarten gemacht. Ich persönlich fand diese Methode extrem nützlich.
Sprint erstmals grob zusammenstellen
Dem Kunden als ganzes Team zeigen, was wir gemacht haben
Sprint definitiv festlegen
Fragen und Details im kleinen Rahmen mit dem Kunden diskutieren
... sprinten... daily scrum ... sprinten ... daily scrum... und dann fängts wieder von vorne an

Für die Sprintplanung haben wir ein einfaches Flipchart verwendet, das ungefähr so aussah:

Die blauen Zettel stellen User Stories dar. Die gelben Zettel die daraus resultierenden Tasks. Die Tafel stand in unserem Büro und so hatte jeder stets im Blick, was noch offen ist.

Von der technischen Umsetzung gingen wir grob gesagt wie folgt vor:

Design kam geliefert als Photoshop Datei
Drupal Grundinstallation, diverse Grundinhaltstypen
Zentrale Elemente für die Zugriffsberechtigung auf Artikel
Implementation der diversen Schnittstellen
Erstellung der Übersichtsseiten
Aufräumarbeiten und der ganze Rest

Die ganzen Entwicklungen haben wir in Features gepackt und dann via SVN regelmässig (1x pro Stunde) auf den Entwicklungsserver gestellt. Dadurch hat jeder Entwickler laufend die Änderungen von den anderen Teammitgliedern auch bei sich gehabt und ist zu jederzeit aufgefordert, Bugs in Jira als solches festzuhalten. Kleinere Bugs haben wir daher nicht immer gleich sofort gesammelt, sondern sog. "Bugdays" geplant, an denen sich das Team ausschliesslich Bugs widmet. In diesem Projekt hielt sich die Anzahl an Bugs massiv in Grenzen (oder kommen noch ;) daher hatten wir auch keine wirklichen "Bugdays".

Damit sind jetzt auch die Randbedingungen klar. Um diesen Eintrag nicht noch weiter in die Länge zu ziehen, werde ich die daraus gezogenen Erfahrungen in einem nächsten Blogpost schildern, denn es gibt doch die eine oder andere Lehre.

Verwandte Beiträge:

Scrum in einem Drupalprojekt

Scrum in einem Drupalprojekt Teil III

Aufwandschätzungen sind doch kein Zufall

rapsli — Tue, 26 Oct 2010 06:21:14 +0000

Letzte Woche hat mich ein Arbeitskollege gefragt, ob ich kurz ein kleines Teilprojekt schätzen könnte. Hintergrund: Der Kunde wollte ein paar funktionale Erweiterungen für die bestehende Webseite. Mein Arbeitskollege hatte bereits eine Aufwandschätzung gemacht, welche jedoch aus Kundensicht viel zu hoch schien. Also bat er mich, auch einen Blick darauf zu werfen.

Ich kannte das Projekt ein wenig aus der Entwicklungsphase, da ich dort in einigen konzeptionellen Fragen involviert war. Ich hatte jedoch absolut keine Ahnung von den neuen Kundenwünsche und schon gar nicht, was mein Arbeitskollege geschätzt hat.

So machte ich mich an die Arbeit, ich hatte eine Liste mit ca. 10 Punkten aus der Offerte. Ich ging die Liste Punkt für Punkt durch und mir die folgenden Fragen:

Wie lässt sich der Punkt umsetzen?
Sind externe System mit involviert?
Ist Entwicklung notwendig oder lässt sich alles mit bestehenden Modulen umsetzen?
Gibt es Risiken bzw. Dinge, welche unklar sind?

Je nach dem, wie die Antwort auf die Frage war, wurde der Aufwand ein wenig höher, bzw. ein wenig tiefer. 10x wiederholte ich das Spiel.

Resultat: ca. 20 Personentage Aufwand. Ehrlich gesagt, ich war nervös bzw. aufgeregt, als ich ins Büro nebenan ging. Wieviel würde er wohl geschätzt haben?!

Auch er hat die Punkte, welche offeriert wurden, einzeln geschätzt. So konnten wir diese Schrittweise durchgehen. Erstaunlich: In den ersten 4 Punkten 100% Übereinstimmung. Es gab 2-3 Punkte, wo es eine ganze kleine Abweichung gab, aber alles in allem doch ein extrem grosse Übereinstimmung.

Fazit: Aufwandschätzungen sind also doch nicht nur Zufall! Besonders das Aufteilen in kleinere Teilaufgaben war extrem hilfreich. Wenn man dann noch ein bisschen was fürs Projektmanagement hinzufügt, sowie eine gesunde Reserve ist man sicher auf der richtigen Spur.

Problem ist dann halt meistens nur, dass das Marketing den Preis drückt, um Konkurrenzfähig zu bleiben... danach fragt man sich, warum es mit dem Budget nicht aufgegangen ist... aber das ist dann nicht mehr ein Entwicklerproblem.

Besonders für Drupalprojekte habe ich die Erfahrung gemacht, dass es einige Punkte gibt, welche den Aufwand fast ausnahmslos steigen lassen:

Migration von bestehendem Inhalt. Wird immer unterschätzt, da von einer idealisierten Umwelt ausgegangen wird. In der Realität sind oftmals die Daten schlecht, müssen noch umgewandelt werden usw.
Jegliche Interaktion mit unbekannten Drittsystemen. Auch wenn es noch so trivial ausschauen mag... irgend eine Tücke ist noch drin.
Mehrsprachigkeit. In Drupal grundsätzlich kein Problem, aber im Detail, gibt es immer wieder ein Modul, welches (noch) nicht mehrsprachig ist oder irgendwo Zeichenketten, welche sich nicht übersetzen lassen.

Dies sind besonders in der Medienbranche immer wieder auftauchende Anforderungen und oftmals auch immer wieder Risikotreiber.

1. Beta Version für Drupal 7

rapsli — Thu, 07 Oct 2010 06:50:58 +0000

Habe soeben gerade gesehen, dass die 1. Beta Version für Drupal 7 bereit zum Download ist :)

Muss ich doch mal schauen, ob die benötigten Module auch bereits eine Alpha oder Dev Version haben, dann könnte ich schon mal das Blog migrieren. Auch sollte ich mich mal wieder an die Arbeit für Fast Gallery machen, damit die D7 Version wieder richtig funktioniert.

Fast Gallery - Quickstart

rapsli — Wed, 06 Oct 2010 06:06:12 +0000

This is a quick start for setting up a Fast Gallery. I did this with Fast Gallery 5.5 and Drupal 6.17.

First a quick introduction on how Fast Gallery works. Basically Fast Gallery displays a pictures from a folder, just like you know it from Windows Explorer. So lets say you uploaded 50 pictures to your site via FTP, you point your gallery to the folder, then user is presented those 50 pictures. If there are subfolders, the user can just click on the folder and will see the pictures from this subfolder (just like in Windows Explorer).

Copy the latest version of Fast Gallery into your modules folder
Install Fast Gallery
Install Imagecache and setup two presets: "thumbs" and "full" (for example)
Go to admin/settings/fast_gallery/general. Here we are going to setup a gallery
On the top we got three text fields: "Path to Gallery", "Path Alias" and "Title of Gallery". Path to gallery would the folder where the images are located relative to the Drupal index.php, so for example sites/default/files/galerie. Path Alias, would be any alias, so for example: my_gallery, and the "Title fo Gallery" could be something like "My first Fast Gallery"
There are two dropdowns for selecting imagecache presets. Since you created two imagecache presets previously you can select them now here
On the same page we we have other options, which we can leave as they are
Hit the submit button
That's it, you are done! Go to http://mysite.com/my_gallery and you should see some images

German Version

Verwandte Beiträge:

Fast Gallery - Step by Step

Twitter API geändert

rapsli — Mon, 13 Sep 2010 08:28:15 +0000

Es scheint, als hätte die Twitter API geändert. Alle die, welche das Twitter Module im Einsatz haben, werden somit ein kleineres Problem haben, da das Posten nicht mehr funktioniert. Schade, dass das Twitter Modul nicht sehr aktiv ist, denn sonst wäre bereits eine aktuelle Version vorhanden. Ist eigentlich sehr erstaunlich, da es immerhin 15000 Installationen des Moduls gibt. Mal schauen, dass ich hier eine Lösung finde.