Lukas’ Weblog

Just another fanstuff project: brainrules

It provides a cheatsheet for John Medina’s twelve brain rules, because I was not happy about the official one. Done using GIMP, OpenOffice Presentation and gedit.

1. Damn you, OOo.
2. Damn you, missing directory listing.
3. Damn you, non-SVG graphics in PDF.
4. Love you, Free TrueType Fonts.

Awesome lecture about motivation… I believe it. It’s just my own experience.

Youtube: RSA Animate – The surprising truth about what motivates us

Heute ist sie endlich online. Im Stile von “FCE – Mein Erlebnis“, beschreibe ich meine Situation zu dieser Zeit (die 9 Monate) und wie es für mich war. In der Tat habe ich so viele interne und rechtliche Dinge erwähnt, dass ich die Datei (noch?) nicht von Suchmaschinen indizieren lassen möchte. 4 Tage Arbeit und jede Menge Paragraphen. Das 32-Seiten-lange Dokument beinhaltet (Inhaltsverzeichnis zitiert):

• Der Zivildienst
  • Die Fakten
  • Der Zivildienst
  • Die Gewissensklausel
  • Zivildienst-Gehalt
  • Urlaub, Arbeitszeit und Arbeitsrecht
• Die Situation
  • Stellung
  • Der Formularkram
  • Der große Tag
  • Meine Bezirkstelle
  • ”GWDs und Zivis” oder ”die Gewissensklausel in der Praxis”
  • ”A&W” oder ”Cap Wörth”
  • Die Hospitantenzeit
  • Das Autochecken
• Die Erlebnisse
  • Best SaniQuote
  • Zitat zur Situation eines Zivi
  • Der Einstieg ins Sanileben
  • RTW mit Hospitant
  • Der erste Tote
  • Die erste Reanimation
  • Typische Standard-Fälle
  • Die Routine
  • Problem 1: ”Stunden pro Monat” oder ”Zuvieldienst”
  • Problem 2: Das Recht
  • Problem 3: Status qualificum
  • Problem 4: Ortsrettungsstelle Ferlach
  • Problem 5: Zivildienstserviceagentur
  • Problem 6: Theologie
  • Problem 7: Zusatzaufgaben
  • Problem 8: Nachtschichten
  • Problem 9: Verlängerung
  • Kritik in Kurz
  • Zeitleiste
• Konklusion
  • War das Tätigkeitsfeld für dich in Ordnung?
  • Hast du was gelernt / fürs Leben mitgetragen?
  • Sollte der Präsenzdienst abgeschafft werden?
  • Bist zu zufrieden mit deiner Leistung?
  • Statistiken

In der Gegend vom 8. April wollte Wordpress (trotz gegenteiliger Einstellung) seine Datenbank selbstständig updaten. Ausgelöst wurde dieses Update automatisch als ich mich als Administrator einloggte. Im Zuge dieses Updates crashte mysql und Wordpress hinterließ eine halb durcharbeitete Datenbank. In der Realität wirkte sich dieses “halb” mit den Symptomen eines addslashes() auf alle Bloginhalte und Titel aus. Die Metadaten der Pages (ich habe nur eine: “About”) wurden komplett zerstört.

Jetzt am 29.04 konnte ich ein Skript schreiben, welches die Datenbank wieder auf den alten Stand brachte. Danke an meinen Sysadmin. Bei eventuellen Problemen bitte einen Kommentar hinterlassen.

Letztes Jahr ging es um Armut. Dieses Jahr um den Klimawandel.

Manche behaupten es werde wärmer. Manche behaupten es werde kälter. Eines ist klar: das Klima verändert sich und damit ist der Begriff “Klimawandel” auf jeden Fall zielführender als Begriffe wie “Klimaerwärmung”. Einige argumentieren das Klima wäre über all die Jahr schon dynamisch gewesen und ein temporäres Tief ändere an dieser Tatsache nichts. Wissenschaftler halten dagegen, dass die Veränderung in einer kürzeren Zeitspanne stattfindet als je zuvor.

Für mich hat die Argumentationslinie recht wenig Relevanz. Wenn ich an alte Tage zurückdenke, wo ich draußen im Schnee gebaut habe und heute mit dem Rad bei eisiger Kälte ohne Schnee in den Dienst fahre, merke ich die Veränderung, die in das Leben von Menschen einschneidet. Früher hat man sich im Dezember beim Skifahren getroffen; heute beim Bergwandern zur Weihnachtszeit. Die kalten Zeiten (mit Hoffnung auf Schnee) haben sich nach hinten verschoben. Während früher die Winterferien (Dezember) zum Schnellschaufeln genutzt wurden, sind die schnee-intensiven Monate jetzt der Februar und März. Manchmal wird man trotzdem schon im November vom Wetter überrascht Auch die Strahlung der Sonne kommt mir heutzutage extremer vor als früher.

Die Menschheit hat die Angewohnheit in solchen Fällen nach einem Grund zu forschen und ihre Neugier zu befriedigen. Der Treibhauseffekt bedingt durch stärkeren CO₂-Ausstoß gilt als Quasi-Standard zur Erklärung des Phänomens. Wie kann man dem entgegenwirken? Für den Normalbürger gilt die Anweisung den Straßenverkehr zu reduzieren, alternative Energien zu verwenden und Ressourcen zu sparen.

Ich persönlich nehme mir das Radfahren sehr zu Herzen. Wenn jemand wegen einer einmaligen, weiteren Fahrt den Weg mit einem Kraftfahrzeug zurücklegt, so sei es ihm zu verzeihen. Doch in dem Bereich, der regelmäßig stattfindet (zB der Weg zur Arbeit), sollte die Optimierung von Vorgängen stattfinden auch wenn man manche Gewohnheit dadurch ablegen muss und Opfer bringt. So sollte man den Weg zur Arbeit möglichst mit Fahrrad zurücklegen. Öffentliche Verkehrsmittel sehe ich nur als halbfunktionstüchtige Alternative an. Sehr nett finde ich auch Peters Mut zum Kauf eines Elektromopeds. Ich denke mir solche Innovationen werden unsere Zukunft bestimmen und das Bestehen der Natur sichern. Auch wenn die Innovationen langsamer Einzug in unser Leben erhalten als der Winter schwindet…

Beginnend mit proj stadtchor begann ich kommerziell zu arbeiten (= Erwartungshaltung auf finanziellen Gegenanspruch). Damit verbunden waren die Überlegungen um Preise und Projektmanagement. Nie zuvor hielt ich mich an XP oder andere Konzepte, verwendete hg/git, plante Aufwand/Zeitinvestition oder dachte mir vorab einen Preis aus. Ich muss sagen: jetzt auch noch nicht professionell, aber ansatzweise musste ich mir Gedanken machen und beginne mich an gute Tipps zu halten.

An einer Webseite ist es wohl am einfachsten erklärt: Wenn jemand eine Webseite haben möchte, dann gehe ich einmal her und schreibe eine Textdatei TODO in das Projektverzeichnis. Ist ein Hoster schon vorhanden? Domain bereits fixiert? Stehen Logos und favicons zur Verfügung? Haben wir genug Inhalt? Welche Technologien sollen es sein? Welche existente Software verwende ich? Gibt es Ähnlichkeiten zu anderen Projekten? Und zu guter Letzt: Wann ist das Projekt abgeschlossen und was erwarte ich vom Kunden am Ende?

Dies war die Basis. proj steph wurde genau auf diese Art und Weise geboren. Hierfür benötige ich keine großartige Planung, Software und mache mir keine tiefen Gedanken. Eine simple Textdatei mit Notizen, die mir gerade einfallen. Genau mit dieser Datei komme ich dann zum “Kunden” und bespreche mit ihm Punkt für Punkt durch. Ist alles geklärt, kann das Projekt beginnen. HTML & CSS stand am Anfang, danach kam PHP. Vier wesentliche Elemente mit denen ich mich gerade im Moment beschäftige, sind Roadmaps (setzt Ziele für die nächsten Releases fest), der Sinn von Meetings (Treffen mit Kunden zur Projektplanung), unittests (automatisiertes Testen von Software) und SCM (Source Code Management Systems).

SCM: (ich bevorzuge übrigens hg aus reiner Gewohnheit) wenn man jeder Änderung am Quelltext eine Nachricht zuweisen “muss”, dann beginnt man genauer zu überlegen, was man genau macht und konzentriert sich darauf in den nächsten 2 Minuten nur diesen 1 Bug zu fixen und beginnt nicht wild am Quelltext irgendwas zu verändern, was gerade im Moment nicht zu scheinen passt. Möchte man größere Änderungen machen und weiß nicht, ob die Änderung in Zukunft bestehen bleibt, so “forkt”/”branch”t man das Projekt. Mithilfe des SCM kann man diese Änderungen wieder verwerfen bzw. in den Hauptzweig wieder einfließen lassen. Ganz allgemein möchte ich damit nur sagen, dass Aktionen am Quelltext bewusster wahrgenommen werden, wenn man sie dokumentiert und mit kurzen Stellungnahmen versieht.

Meetings: Faszinierend… manche Kunden stellen überhaupt keine Ansprüche, manche Kunden erwarten eher, dass alles von alleine geht und manche Kunden möchte am liebsten jeden Tag die Fortschritte sehen. Ich bin etwas vorsichtig. Wenn jemand sich treffen will und den Projektstatus besprechen möchte, dann kommen viele Faktoren zusammen und werden gegeneinander abgewägt. Ist für mich alles klar, ich bin mitten in der Arbeit und soll die Arbeit am Projekt für das Projekt unterbrechen, ist das Meeting eher zu vermeiden. Entweder ein Meeting dient dazu Unklarheiten zu beseitigen oder um Motivation für das Projekt zu finden. Mir ist durchaus klar, dass auch der Kunde Unklarheiten haben könnte, aber in dem Fall bemerkt man dies bereits beim Gespräch vorher am Telefon oder im ICQ/Skype. Ein anderer zielführender Faktor um die Sinnhaftigkeit von einem Meeting abzuwägen sind die Kosten. Um es hoch zu rechnen: Ich schätze die Zeit ohne Anfahrtszeit oder sonst was ab (zB 2-3 Stunden), verrechne 10 Euro pro Stunde und wenn ich wegen Punkt 1 ein Meeting unangebracht halte und jetzt auch noch die 2*10 Euro ungefähr/mehr als 20% des erwarteten Preises für das Produkt liegt, dann lehne ich das Meeting auf jeden Fall ab. Letztendlich geht das Projekt bei einem Meeting nicht voran und es wird bloß die Richtung für die Zukunft definiert. 2 Stunden Programmierzeit bringen das Projekt wesentlich weiter als 2 Stunden Meeting, wenn das Ziel ganz definiert ist (PS: Programmieren beim Kunden geht IMHO wegen der Konzentration gar nicht).

Roadmap: Mithilfe einer Roadmap teilt man sich die Zeit genauer ein. Man stellt klare Ziele und versucht einen Zeitplan einzuhalten. Langfristiges Planen. Man überlegt bei jedem Punkt ob dieser essenziell für ein Projekt ist und wenn er nachrangig ist, so verwirft man ihn leichter. So kommt man nicht auf spontane Ideen.

unittests: Software soll stabil sein. Mit unittests ist Software bei mir grundlegend wesentlich stabiler geworden. unittests verlangen aber auch, dass die Problemlösung bereits vorher ganz klar definiert ist. Schreibt man eine Methode um, so ist die Zeit des unittest-Schreibens verlorene Zeit. unittests sollte man vorwiegend vor der Implementierung schreiben. Manchmal ist es auch nachher sinnvoll.

proj jaun: diejauntaler.at

Wie angekündigt, ist jetzt proj jaun auch fertig und basiert technisch auf proj steph. Aber es gab doch einige Anpassungen und der Aufwand war letztendlich mindestens gleich groß wie bei proj steph. Gerade bei Graphiken (siehe proj gimp_tut) gab es einiges zu machen. Aber die Arbeitsweise war wieder gleich: Gesagt, getan. In Sachen Design und Gestaltung habe ich nicht viel zu sagen gehabt. Aber zum Programmieren war ja doch ein recht großer Haufen und deshalb bin ich jetzt froh, dass es fertig ist. Sobald auch proj therapy (endlich) fertig ist, wird es Zeit für die neuen Projekte und wieder ein verbessertes Projektmanagement.

Sehr bedauerlich bei solchen Projekten finde ich immer, dass sich Web 2.0 bei vielen noch nicht durchgesetzt hat und die wenigsten Nicht-Techies bereit sind regelmäßig zu schreiben/bloggen und klare Vorstellung von solchen Elementen haben. Sehr viele Durchschnittsmenschen sehen noch die einzelnen statischen Seiten, die verlinkt werden. Im Web 2.0 ist mehr drin. TODO: Kunden Web-2.0-Philosophie näher bringen.

Für proj jaun benötigte ich einen kleinen Effekt rund um die Konturen von Personen. Mit jQuery habe ich die Vorgangsweise dokumentiert, damit ich mir sie in Zukunft auch noch merke. Ursprünglich wollte ich es zu einem kleinen Framework ausbauen, damit jeder Programmierer selbst die Datei anpassen kann und selbst einfach Präsentationen machen kann, aber in der Tat fehlt mir gerade ein bisschen die Zeit / Motivation. Bevor die Datei verstaubt, release ich sie mitsamt der ToDo-Liste.

proj gimp_tut beta “presenter”

GIMP-Aufgabenstellung
Füge einen weißen Rand rund um Personen hinzu, der an den Personenkonturen ganz weiß ist und nach außen hin transparent wird.

TODO

• next / previous buttons
• switch between “small” and “big” mode
• better font-size-handling
• reduce number of confusing css-classes
• Support fullscreen-like presentation

TODO die negativen Smilies im Gästebuch entfernen

kein Kommentar.

Nach 8 Debugging-Updates ist die Webseite endgültig abgeschlossen. Wieder lief einiges schief. Das größte Problem war es wohl dem Webseitenbesitzer die Möglichkeit zu geben den Inhalt selbstständig zu modifizieren. Unter PHP gibt es keine schönen Lösungen dafür. Letztendlich gibt es nur die Alternativen TinyMCE oder selbst etwas zu stricken. Die erste Entscheidung war es selbst einen Interpreter zu entwickeln. Dank meiner wachsenden Regex-Kenntnisse war alles kein Problem. [URL], [BOLD], [HTML] und viele weitere arbeiteten zuverlässig. Aber letztendlich scheiterte ich an einer schönen HTML-Formatierung mit gutem Paragraphen-Handling. Weil bereits 80% der Entwicklungszeit für diesen Teil der Webseite drauf ging, entschied ich mich zu alternativen, schnellen Lösungen und baute ein, was bei proj stadtchor zu finden ist: ein Wikisyntax-Interpreter. Der große Nachteil: Der Wiki-Interpreter wird nicht mehr weiterentwickelt und er hat seine Fehler, wenn nicht die ganze Seite ein Wiki ist (zB URL-Handling). Soweit zu diesem Thema… mit ein paar Workarounds von mir sind die Basics alle zu lösen.

Wie besagt war der Interpreter das Zentrum. Gästebuch und Co. waren 1-Tages-Geschichten. Bezüglich Design war ich recht eingeschränkt. Während andere Kunden eher die Philosophie hatten “biete mir was an”, setzte sich Stefan in stundenlangen Skype-Sessions dazu und bittete mich um dies und das. Ich hielt ihn nur von bösen Ideen ab (zB text-decoration:blink) Es wird auch noch ein Nachfolge-Projekt geben. proj jauntaler wird auf der selben Software basieren, aber ein anderes Design besitzen. Und hier ist der Link: stefanwrana.at (proj steph)

Was ich so richtig eklig finde, wenn ich heute eine Webseite entwickle: Ich habe das proj cms fallen lassen. Das bedeutet ich habe kein Framework auf das ich zurückgreife, wenn ich eine Webseite neu entwickle. Sämtlicher Quelltext von proj steph wurde in den letzten Wochen neu geschrieben. Das erzeugt unlesbaren Quelltext mit konzeptionellen Fehlern. Das ist der Grund, wieso ich nicht mit repositories arbeitete und den Quelltext online stelle. Er sollte nicht Verbreitung finden. Manche Webdesigner greifen auf Frameworks wie Wordpress zurück. *würg* finde ich grausam sowas für kleine Webseiten zu verwenden. Gute Alternativen habe ich einmal erfolglos ausprobiert. PHP bietet auch keine richtigen Parser an. Weil die Hoster oft alt sind und die Kunden nicht ihren Hoster auswendig kennen, muss ich oft davon ausgehen keine Datenbank zur Verfügung zu haben. Die Arbeit mit Dateien ist teilweise schwieriger. Und das waren so meine Grundprobleme.

Ich kündige an, dass ich jetzt mehr in den Bereich python schauen werde. In python weiß ich, dass es eine schöne stdlib gibt und Textverarbeitung allgemein wesentlicher leichter ist. [:] ist schneller geschrieben als substr() und arbeitet logischer. python kommt mir persönlich wohl eher entgegen. Ich glaube aber das Verständnis für die Web-Funktionsweise (wsgi/cgi/Co.) muss bei python höher sein. Encodings und anderes werden wesentlich sauberer behandelt und verlangen daher ein besseres Verständnis. Hin oder her… ich bin motiviert das zu lernen und werde es mir jetzt einmal anschauen. Mit PHP möchte ich immer weniger zu tun haben.