Blog

  • DrupalCon SF – Workflows für Design und Entwicklung

    Review der Session "Efficient Workflwo for Design and development projects"

    Frühe Discovery Phase:

    • Einander kennenlernen. Internet brauchen, Blogs, Twitter usw. lesen.

    Deliverables. Sollen einfach sein. Dadurch sind sie verständlich und laden ein, Änderungen anzubringen.

    1. Delieverable List. Eine erste Liste, mit den Anforderungen. Dabei jedoch klar machen, dass es keine komplette Liste ist
    2. Eine Sitemap gibt einen ersten Überblick, wie die Seite ausschauen soll.
    3. Wireframe. Es müssen genau Fragen gestellt werden, ansonsten kommen Antworten wie "mir gefällt die Schrift nicht" oder "ich möchte lieber ein bisschen mehr grau haben" usw. Wenn jedoch die Fragen detailliert gestellt werden, dann kommt auch eine spezifische Antwort zurück. Ein Beispiel geben, wie ein Feedback sein könnte.
    4. Beim Design früh Feedback einholen und Tests mit Benutzern machen, da wir für Benutzer Designen
    5. Nur EIN Design machen! Sonst wird es ein Flickwert aus beiden. Nützliche Tools
      1. Templates
      2. Grid System (960)
    6. Moodboards. Damit wird die Farbpalette und Schriftarten erstellt.
    7. Basierend auf Schritt 4-6 wird ein Designkonzept erstellt
    8. Feedback vom Kunden holen. Auch hier wieder: Spezifische Fragen stellen. Den Kunden lenken!
    9. Iterieren und die Details anpassen
    10. Design wird genehmigt
    11. Umsetzung kann beginnen. Früh wie möglich Feedback einholen, aber auch hier spezifisch sein. Garland wird eingesetzt. Dem Kunden muss genau gesagt werden, was für ein Feedback man haben möchte, sprich, funktioniert Funktion xyz so wie du es gerne hättest?
    12. Kunde soll früh anfangen, Inhalt einzugeben, damit fehlende Felder frühzeitig entdeckt werden können.
    13. Start Risky, end easy!
    14. Wenn Feedback kommt, dann kommt auch Feedback über kleine Änderungen. Diese werden jedoch noch nicht umgesetzt, was dem Kunden entsprechend kommuniziert werden, sondern es wird hinten angestellt.
  • DrupalCon SF – Performance testing

    Review und Zusammenfassung der Performance Testing Session.

    Traffic muss generiert werden, wobei eine massive concurrency eingesetzt wird. Mögliche Tools um Traffic zu generieren: JMeter, LoadRunner, The Grinder.

    Economist hat sich für Grinder entschieden, da OpenSource und sehr flexibel und verständlich. Essentiell ist, dass der Benutzer sich einloggt, da ein sehr grosser Unterschied zwischen Gast und eingeloggtem User in Drupal ist. Zusätzlich läuft ein Testing Script, welches überprüft, ob auch alles immer noch gut ist.

    Gibt einiges mehr, was gesagt wurde. Vor allem viel Code.

  • DrupalCon SF – Performance Session

    Performance Optimierung

    • Server von Scratch aufsetzen. Nur das, was auch wirklich gebraucht wird.
    • Unnötige Drupal Modul entfernen (z.B. Statistik)
    • Views, welche problematisch sind entfernen
    • CCK durch eigenes Modul ersetzt -> da nur ganz wenige Felder benutzt wurden

    Hardware

    • Fast Disk 15'000 RPM
    • MySQL auf einer Disk, alles andere auf einer anderen Disk

    Software

    • Server Distroedition (z.B. Ubuntu Server)
    • Apache (MPM Worker threaded, Apache fcgid
    • PHP (FastCGI, APC via pecl)
    • Munin for monitoring
    • Awstats

    Drupal

    • Keine Kommentare
    • Voting
    • Book module
    • Nur 44 Module total
    • Normale Drupalsites 120 Module (bis 231 Module)
    • Simplicity!!! Weniger Probleme, einfacher zum Pflegen

    Möglichkeiten für Optimierungen

    • Patch für Pfadlook up
      http://drupal.org/node/106559
    • Locking Problem in Menu ist ab 6.16 gelöst
    • 404 Error Handling nicht optimal
      http://drupal.org/node/76824
    • Einige Crawlers aussperren
    • Apache Logging. Regeln aufsetzen, dass .jpg, .png, .css usw. nicht mehr geloggt werden.
    • innodb-file-per-table
    • innodb_buffer_pool_size = 256M
    • long_query_time = 2 (Weitere Konfigurationsdaten in den Unterlagen)
    • Es sind nur gewisse Tabelle in InnoDb. Die transformieren, welche viel Locking haben.

    Wie lösen? Jede Seite ist einzigartig. Zuerst sauber analysieren, wo die Probleme liegen, dann überlegen und die Probleme lösen. Dazu ist es wichtig zu messen und zu monitoren! Peaks können erkannt werden und dann danach gesucht werden.

    Problematische Module:

    • Statistics
    • QuickTabs (wenn entsprechend konfiguriert)
  • DrupalCon SF – Managing your clients expectations

    Kurze Zusammenfassung von der "You shall not pass".

    Was bedeutet "Expectations"? (Erwartungen)

    • Informale und formale Versprechen. Dabei nimmt der Kunde viele Sachen auch einfach an, dass die so sind.
    • Soziale Sachen. Kunden sind emotional mit eingebunden. Er sagt oftmals nicht, was er wirklich meint.
    • Es ist ein Mass, wie gut man ist. Wenn man die Erwartungen nicht richtig managed, dann kann man sich noch so viel Mühe geben, wenn man es nicht erreicht, dann ist der Kunde nicht zufrieden.

    Es gibt einige standardmässige Erwartungen:

    • Zeithorizont
    • Features
    • Support und Maintenance
    • Kommunikation
    • Zwischenmenschliche Beziehungen

    Das Ziel des Kunden: Möglichst viel für möglichst wenig Geld haben. Das ist ihre Aufgabe. Wenn ich etwas gebe, dann nehmen sie es auch. Kunden bezahlen uns, damit wir das umsetzen, was in ihrem Kopf ist, nicht was niedergeschrieben ist. Wenn ein Kunde einmal Erfolg hat, und mehr bekommt, dann wird er das natürlich weiter versuchen.

    Aufgabe des Projektleiters: Zurückdrücken. Wir sind die Experten, wir wissen was los ist. Projektleiter ist wie ein Regenschirm.

    Lieber intelligenter als härter arbeiten.

    Wie lassen sich Erwartungen managen?

    Versprechen managen

    • Versprechen in möglichst kleine Aufgaben aufteilen
    • Beide Seiten müssen integriert sein und etwas machen.
    • Versprechen niederschreiben
    • Beide Seiten sind verantwortlich

    "Das sollte doch einfach sein oder nicht?"

    • Klar und deutlich sagen, "nein".
    • Dringlichkeit kommunizieren, so dass es auch mal zu einem Abschluss kommt.

    Erwartungen möglichst früh managen, so dass der Kunde eine Wertschätzung für die Arbeit hat.

    Drupal

    Ein Drupalprojekt ist auch immer ein Erfolg/Misserfolg für die Community. Die Community hat daher auch ein Interesse daran.

    Als Projektmanager ist es sehr hilfreich, zu wissen wie Drupal funktioniert.

  • DrupalCon SF – IPhone Applikationen mit Drupal

    Es gibt die Möglichkeit Applikationen für Mobile zu entwickeln unter der Verwendung von JS und HTML 5 und CSS 3.

    PhoneGap. Ist ein Framework. Ist jedoch nicht ganz so gut, da nicht alles unterstützt wird.

    Titanium Mobile. Das ist gut. Titanium Mobile ist gratis. Es ist ein Compiler, welcher Javascript in Nativ Object C umschreibt.

    Pro Tag werden 60'000 Android und 100'000 IPhones verkauft. Im Jahr 2013 wird 40% des Internetverkehrs von Mobiltelefonen kommen. Eine App braucht ungefähr 6 Monate Vollzeit Entwicklungszeit, was relativ viel ist.

    Voraussetzungen von Drupalseite: Services API, damit Drupal als Webservice verwendet werden kann.

    Zum Starten:

    • iPhone SDK installieren
    • Titanium Developer installieren
    • Titanium Developer Account erstellen

    Extremstens cool!!! Das macht mich richtig heiss, auch etwas für Mobil zu entwickeln, nur brauche ich dafür zuerst auch endlich mal ein Android Phone. Applikationen lassen sich relativ rasch und mit relativ wenig Aufwand entwickeln.

  • Queue vs Batch API

    John VanDyk über die Queue und Batch API aus Drupal 7.

    Queue API

    Als, Drupal 7 bietet eine Queue API. Dabei wird zwischen persistenten und nicht persistente Queues. Scheint ein sehr gescheites System zu sein und es gibt auch einen Backport für Drupal 6. Ich bin mir gerade am Überlegen, was mögliche Anwendungsszenarien für die Queues sind: Cron Queues wäre wohl etwas cooles. Item in den Cron reinfuttern und dann werden die nach und nach abgearbeitet.

    Leider habe ich zu wenig Zeit, mir mehr Gedanken darüber zu machen im Moment…

    Batch API

    Probelem, welche dadurch gelöst werden sollen:

    1. Maximale Execution Time, welche überschritten wird
    2. Ungeduldige Benutzer

    Ist eigentlich relativ einfach zu verwenden. Werde an dieser Stelle hoffentlich mal noch ein einfaches Beispiel machen. Gibt auf jeden Fall diverse Orte, wo sich Batch API einsetzen liesse: Alles, was mit Migration zu tun hat!

    Im Examples Modul, gibt es entsprechend dokumentierte Beispiele dazu. Dieses Modul ist sowieso eine sehr wertvolle Quelle für Dokumentation!!

  • DrupalCon SF – Security

    Drupal Site security for coders and themers. Eigentlich nichts Neues. XSS das grösste Problem. Eigentlich einfach zu lösen mit den von Drupal vorgegebenen Funktionen, aber man muss dran denken.

    Besonders themes sind sehr gefährdet. Wer hat nicht schon mal einen Aufruf nach dem Prinzip:

    print $field_test['#value'];

    oder so ähnlich in einem .tpl File gemacht. Schlecht, da nicht sicher!

    Ein weiteres Problem ist Folgendes:

    Nehmen wir an, es wäre ein Pfad gegeben: user/3/delete Ein Aufruf dieser URL löscht den User mit der uid 3. Ein normaler User hat nicht das Recht diese URL aufzurufen, aber, der normale Benutzer hat das Recht ein Bild zu posten:

    Sobald der Admin auf diesen Beitrag geht (z.B. in einem Kommentarfeld, welches HTML zulässt), wird ein Request auf diese URL gemacht… schwupps ist der Benutzer weg.

    Mögliche Lösungen sind:

    1. Eine Bestätigungsseite machen. Ist leider dann nicht mehr ganz so hübsch zu bedienen, aber erfüllt seinen Zweck.
    2. Ein Token einfügen und dieses vor dem Löschen des Benutzers überprüfen.

    Es gibt einen hübschen Security Report.

    Die Frage ist natürlich immer, wie man solche Sicherheitslücken in einer laufenden Seite finden kann:

    • Formularelement durchprüfen und überall testen, ob es immun gegen XSS ist.
    • Nikto ist ein Scanner, welche eine Seite auf potentielle Lücken überprüft.
    • Nessus. Ein weiterer Scanner.

    -> Beim Entwickeln einfach daran denken!

  • Drupalcon SF – Erfolgreiche Drupalprojekte umsetzen

    Die Session von phase://technology Planning and Executing a Successful Drupal Implementation

    Die folgenden Punkte sind wichtig und ist eine kurze Zusammenfassung der Session und deckt die wichtigsten Punkte ab.

    • OpenSource. Viele Leute haben keine Ahnung, was ist OpenSource, mehr als nur "gratis Software"
    • Die Terminologie erklären, Nodes, Taxonomy, Nodetypen usw.
    • Erklären, dass Drupal keine Zaubersoftware ist, wo man einfach Module installieren kann, sondern es erfordert Arbeit.
    • Erwartungen bezüglich Zeithorizont berichtigen
    • Kommunikationsweg aufgleisen: Basecamp, OpenAtrium oder was auch immer.
    • In-person Training. Dokumentation ist gut, aber wird schnell auch alt. Ein Mix zwischen Doku und Training ist effizient.
    • Die Stakeholder früh dazu bewegen, die Seite zu betrachten und dabei besonders Wert auf Details legen. Der Stakeholder muss sich hinsetzen, und die Prozesse auch effektiv durchspielen.
    • Stakeholder muss ein Teil des Teams sein. Er hat Mitverantwortung für das Gelingen des Projekts. Stakeholder müssen mitarbeiten.
    • Das korrekte Team:
      • Projektmanager, welcher im Projekt integriert ist
      • Analyst (UX, Requirements…)
      • Designer
      • Web Producer
      • Developers (1 Hauptentwickler und 1-2 Mitentwickler)
      • Testing
    • Agiles Projetmanagement und vor allem einen grossen Wert auf den Projektumfang legen! Transparentes Backlog, so dass der Kunde jederzeit einen Blick reinwerfen kann.
    • Task management Tool effizient einsetzen (z.B. Jira)
    • Wert auf Qualität legen

    Defining Scope and Requirements

    • Sitemap. Zeigt den Ungefähren Umfang der Seite an. Ist ein Anfang, kann aber Probleme machen mit Tags und dynamischen Elementen
    • Sketch Layouts. Ein Brainstorming, alle können Teilnehmen
    • Detailiertes Wireframing. Hier wird aufgezeigt, wie die Seite im Detail funktioniert. Auch Details und Backend nicht vergessen. Falls hier kein Feedback vom Kunden kommt, dann ist das eine Warnung, dass der Kunde nicht verstanden hat!!!
    • Integration mit Umsystemen dokumentieren.
    • Spezifikationen definieren (Wiki, Jira, Word…)
    • Design entwerfen.
    • Nicht nur auf die Webseite konzentrieren, sondern alles einbeziehen, das ganze System.

    Bekannte Probleme

    • Alte Gewohnheiten in neue gute Gewohnheiten ändern. Benutzer, welche von starren Seitenbasierten CMS kommen, an Drupal heranführen.
    • Inhalt korrekt strukturieren. Herausfinden, wie die Inhaltstypen gebaut werden müssen. Zusätzlich auch die Berechtigungen korrekt einbeziehen.
    • Taxonomy effizient benutzen. Z.B. eine Themenbezogene Navigation.
    • Ein sauberes Admin Interface anbieten. Hilfetexte nicht vergessen und frühzeitig damit beginnen.
    • Es muss einfach sein für den Editor, Inhalt mit Wysiwyg Editor einzupflegen und dadurch das Arbeiten angenehmer zu machen. CSS für den Editor entsprechend anpassen, so dass die Vorschau möglichst realistisch ist. Die Toolbar so klein wie möglich halten und dann entsprechend vergrössern
    • Kreativität und Innovation für den Editor
      fördern. Dazu braucht der Editor gewisse Freiheiten.
    • Inhaltsbeziehungen korrekt abbilden: Noderelationships vs. Taxonomy. Noderelationships für Fälle, wo Inhalt eng aneinander gebunden ist. Taxonomy ist locker gebundener Inhalt, welches aber Filtering usw. erlaubt.
    • Zwischen Autor und Benutzer unterscheiden. In den seltesten Fällen ist der Benutzer auch der Autor. Einen Autor erstellen, welcher dann im Content referenziert werden kann.
    • Rollen und Berechtigungen im Auge behalten: Nicht zu viele Rollen aufsetzen, da sonst das Testen sehr umfangreich wird.
    • Migration. Bereits bei den Wireframes die alte Datenstruktur kennen und mit einbeziehen. Je früher der Inhalt migriert werden kann, desto besser
  • DrupalCon SF – Drupal Publisher’s Panel

    Einige richtige Kunden, welche Drupal auch wirklich einsetzen.

    Why did you choose Drupal?

    • Ein Enterprise CMS war ein Overkill. Neue Features kommen schneller heraus in einer Open Source Umgebung als in einer Close Source Umgebung.

    Welches ist das nützlichste Feature/Modul in Drupal

    • Wysiwyg Editor ist sehr nützlich und einfach zu verwenden.
    • Solr Such Integration sehr nützlich.
    • Schnelle Änderungen der Startseite (Layoutmässig)

    What do you wish worked better or differently?

    • Deployment von Code und Konfiguration. Wäre besser, wenn die Konfiguration im Code gespeichert werden kann. Continues Integration vs. Flexibilität dass man auf der Liveseite direkt Änderungen machen kann.
    • Usabilityverbesserungen im Admin Bereich
    • Nicht technisch versierte Leute müssen auch in der Lage sein, Module zu konfigurieren. Aussenstehende Leute müssen schneller verstehen können, worum es geht und wie sie mit Drupal arbeiten müssen.

    Can you contrast either a previous system you used or one that you compared Drupal to when looking for a news platform?

    • Sehr flexibel. Es gibt viele Ressourcen -> schafft Vertrauen.

    If you could have 5 Drupal developers working exclusively on your dream tool or module– what would that be– what would it do?

    • Dashboard. Woher kommen die Leser (Kindle, IPad usw.) Das Dashboard soll aufzeigen, wie sich die User bewegen, um daraus Rückschlüsse zu ziehen, wie mehr Geld gemacht werden kann.
    • Stakeholder management module. Ein Modul, welches die Erwartungen der Stakeholder in Drupal Standards übersetzt, so dass man Drupal nicht immer verbiegen muss.

    Talk about some of the things you have done to help with scaleability and large bursts of traffic.

    • Memcache, CDN, Pressflow, Database Master/Slave, Varnish. Module sorgfältig auswählen und dabei auf Performance achten.

    Asset Verwaltung ist nach wie vor ein Problem, welches nicht wirklich gut gelöst wird. Falls hier jemand mal mit einer schlauen Lösung kommt, dann würden sich auf jeden Fall ein paar Leute darüber freuen.

  • DrupalCon SF – CTools

    CTools ist eine Kollektion von Tools, welche für Entwickler zur Verfügung stehen. Die Session soll helfen, CTools zu verstehen.

    Die folgenden Tools werden von CTools zur Verfügung gestellt:

    • Plugins
    • Exportables
    • Form Tools
      • ctools_build_form anstatt drupal_get_form, dient als Grundlage für die Modalframework
    • AJAX Responder (Drupal 6) in Drupal 7 gibt es dafür in Drupal Core bereits entsprechende Helfer. Code Beispiel mit Erklärung.
    • Modal Dialog (aus Panels bekannt), basiert auf dem AJAX responder und den Form Tools. Code Beispiel mit Erklärungen.
    • Object Cache. Besonders für mehrstufige Formulare und sehr komplexe Objekte gut geeignet. Dadurch kann auch ein Locking durchgeführt werden. Komplexe Objekte werden dann erst beim Speichern geschrieben und dann aus dem Cache gelöscht.
    • Contexts.
    • Content.
    • Form Wizard. Multi-step Forms. Es wird nicht ein Formular gebraucht, sondern mehrere, welche über einen Pfad verbunden werden, halt eben wie ein Wizard.
    • CSS Tools. Compress, reassemble, disassemble CSS. Code Beispiel mit Erklärungen
    • Abhängige Felder. Ein bestimmtes Form Element einbinden, basierend auf dem Status eines vorherigen Form Elementes.
    • Dropdown Menulinks (wie sie in Panels verwendet werden). Dadurch können Kontextabhängige Menus gemacht werden: theme('ctools_dropdown', …)

    Einige super nützliche Sachen drin. Die muss man einfach mal ausprobieren…. uff, viel zum Ausprobieren. Meine Favoriten:

    • AJAX Responder
    • Modal Dialog
    • Dropdown Menulinks
    • Form Wizard