Vorsätze für 2016

Das neue Jahr ist bereits 10 Tage alt und es ist Zeit, dass ich über meine neuen Vorsätze schreibe.

Ich nutze immer die Zeit um Weihnachten herum, um komplett abzuschalten und mal wirklich rein gar nichts zu tun. So auch letztes Jahr. Mit dem einzigen Unterschied, dass ich mir Gedanken über meine Vorsätze für 2016 gemacht habe. Diese reflektieren z.T. meine Wünsche und Ziele, die ich eigentlich schon seit einer ganzen Weile hege.

Was sind überhaupt die häufigsten Vorsätze der Deutschen? Statista.com hat für das vergangene Jahr eine Umfrage dazu gestartet und die Vorsätze in folgender Infografik zusammengefasst:

Infografik: Gute Vorsätze für 2015 | Statista

Meine Vorsätze decken sich auch mit den Top 4 der Deutschen aus dem Jahr 2015.

Das sind sie:

  • Umstellung meines Arbeitstags
  • meine Bücherliste endlich mal abarbeiten
  • Ruby lernen
  • regelmäßiger/mehr Sport treiben
  • ein Android Pet-Projekt starten

Die Reihenfolge ist beliebig, denn sie liegen mir alle sehr am Herzen. Ich werde sie kurz in umgekehrter Reihenfolge vorstellen.

Pet-Projekt und Sport

Den Traum, eine eigene App zu entwicklen, verfolge ich schon relativ lange, konnte mich aber nie durchringen, die Entwicklung zu starten. Ideen habe ich viele, doch manchmal kann das einen auch erschlagen. Doch ehrlicherweise muss ich gestehen, dass es mir an Konsequenz gemangelt hat. Das möchte ich in diesem Jahr ändern. Auch ändere ich den Plan eine App zu entwicklen, die mir vielleicht neben meinem Job noch ein Taschengeld einbringt, zu einem Pet-Projekt, welches sehr übersichtlich und einfach zu implementieren ist. Ob sich daraus etwas größeres entwickelt, kann und möchte ich nicht sagen 🙂

Mein „sportliches“ Jahr 2015 war leider mehr von Arbeit, als von Sport geprägt. Dieser stetige Ausgleich zum Job hat mir sehr gefehlt und hat mich zusätzlich zum stressigen Alltag sehr müde gemacht. Das wird sich dieses Jahr (nach besten Kräften) ändern.

Ruby lernen

Diesen Vorsatz hatte ich eigentlich schon für das vergangene Jahr gefasst, bin aber nie dazu gekommen. Nach allem was ich über Ruby gelesen habe, möchte ich diese Sprache unbedingt mal ausprobieren. Da ich aus dem Java Umfeld komme, erhoffe ich mir hier eine spannende Abwechslung und ggf. neue Sichtweisen auf Problemstellungen und wie diese mit Ruby gelöst werden.

Bücherliste

In meinem vorigen Blogpost habe ich das Thema Weiterbildung behandelt. Nun kann man sich selbst über unterschiedlichste Kanäle weiterbilden und ich finde das Lesen von Büchern gehört auf jeden Fall dazu. Für dieses Jahr habe ich mir eine Bücherliste zusammengestellt, die ich bis zum Ende das Jahres durchgearbeitet haben möchte. Darunter befinden sich viele Klassiker der Entwickler-Literatur:

Ich finde, die Liste liest sich sehr sportlich. Die Spannung bleibt, wie viele Bücher ich am Ende des Jahres von dieser Liste streichen kann.

Mein neuer Arbeitstag

Zu diesem Schritt wurde ich inspiriert von Colin Ross, der in seinem Blogpost seinen Arbeitstag als Remote-Worker beschrieben hat.

Nun ist Heim- oder Remote-Arbeit bei uns in der Firma nicht möglich, aber es gibt dennoch Punkte aus seinem Tagesablauf, die ich – an meine Bedürfnisse angepasst – übernehmen möchte.

Prinzipiell möchte ich meinen Arbeitstag besser gliedern und somit fokussierter sein. Den Teil mit dem Sport am Morgen werde ich wohl weglassen und verschiebe diesen in den Abend.

Aber ähnlich wie Colin sitze ich morgens bei einer guten Tasse Café und plane sowohl meinen Tag im Büro, als auch die Aufgaben, die außerhalb des Büros von mir zu erledigen sind.

Nachdem diese Planung abgeschlossen ist, nehme ich mir die Zeit um mich weiterzubilden oder meine Fähigkeiten in der Softwareentwickung zu verbessern. Dafür löse ich regelmäßig Codekatas, für die ich mir ein Zeitfenster von 30 Minuten gebe. Die Codekatas sehe ich als eine Art Training an und so behandele ich sie auch. Das heißt, an den Tagen, an denen ich Abends noch ins Fitnessstudio gehe, mache ich morgens mein Training am Code. So komme ich auf 3 Trainingseinheiten pro Woche.

Nach der morgendlichen Arbeit mache ich mich auf den Weg in die Firma und arbeite dort immer in 90 Minuten Intervallen, die ich für eine kurze Pause unterbreche. In der ersten Pause gönne ich mir meist einen Café. In den anderen Pausen laufe ich ein wenig herum, um den Kopf frei zu bekommen oder quatsche kurz mit Kollegen.

(realistischer) Ausblick

Meine Vorsätze konnte ich bisher schon ganz gut umsetzen. Der Teil mit dem Sport lässt leider noch ein bißchen zu wünschen übrig, aber dafür werde ich sicher noch eine Lösung finden.

Grundsätzlich versuche ich die Vorsätze nicht wie ein Pflichtprogramm, sondern vielmehr wie einen roten Faden zu sehen, an den ich mich orientieren kann. Mir geht es nich darum alle Vorsätze zu 100% zu erfüllen, sondern bei allen Punkten einen Fortschritt gegenüber dem letzten Jahr zu erzielen.

Zur Halbzeit im Sommer werde ich sicherlich ein Fazit ziehen.

Was habt ihr euch dieses Jahr vorgenommen? Es wäre schön, wenn ihr mit mir über eure oder meine Vorsätze diskutiert. Schreibt dafür einfach einen Kommentar.

Bis zum nächsten Beitrag…

Werbeanzeigen

Weiterbildung und meine Linkliste

Das stetige Lesen und Weiterbilden ist meiner Meinung nach maßgeblich, wer ein guter Softwareentwickler oder gar Software Craftsman sein möchte.

Auch wenn die Zeit dafür knapp ist, ist es äußerst wichtig, sich in gewisser Regelmäßigkeit Neuem und Anderem zu widmen.

Ich beispielsweise habe dafür immer den Sonntag Nachmittag gebucht. Hier versuche ich alle Themen, die ich unter der Woche so gesammelt habe, zu einem gewissen Teil abzuarbeiten. Ich habe mir dafür eine spezielle „Später ansehen“ Lesezeichen Liste angelegt, die ich ständig priorisiere und Sonntags dann versuche Top-Down abzuarbeiten.

Die Artikel oder Videos, welche ich besonders interessant finde, teile ich in der Regel über meinen Twitter-Account und in Zukunft auch hier auf meinem Blog. Dafür findet ihr oben in der Menü-Leiste die Rubrik „Links„, die ich stets aktualisieren möchte.

Mit meinem sonntaglichen Ritual bilde ich aber vorerst nur das Lesen und Anschauen von Blog-Posts, Fachartikeln und Fachvideos ab. Was mir noch fehlt ist eine gewisse Regelmäßigkeit zu entwickeln, sich sprachlich weiterzuentwickeln.

Gemeint sind hier natürlich nicht Deutsch oder Englisch, wobei man auch das tun kann :), sondern Programmiersprachen. Mir geht es hier vielmehr um das Vertiefen aktuell schon angewendeter Sprachen (bei mir Java) und das Erlernen neuer Sprachen. Aber auch das Erlenen von neuen Sprachfeatures, wie Lambdas in Java, stehen bei mir hoch im Kurs.

Momentan versuche ich kontinuierlich Codekatas, welche ich mir bei codewars.com raus suche, zu lösen und darüber meine Fähigkeiten zu verbessern. Damit lassen sich zwar ganz gut neue Sprachfeatures ausprobieren, aber ob ich damit eine Programmiersprache neu lernen könnte, hinterlässt bei mir noch ein wenig Skepsis.

Wie geht ihr damit um? Hinterlasst doch dafür einfach einen Kommentar oder schreibt mich auf Twitter an 🙂

Der Wendepunkt

Wie entscheiden wir, wie weit wir gehen müssen, um eine bestimmte Anforderung an unsere Software zu erfüllen und wie wir diese implementieren?

Ist der einfachste Weg hier der richtige oder wäre der simpelste besser? Was genau macht den Unterschied aus?

Mit diesen Fragen beschäftigt sich Sandro Mancuso in einem Blogbeitrag, den ich gerne zusammenfassen möchte.

Es gibt immer einen Punkt, an dem wir uns entscheiden, wo in unserem System wir Änderungen implementieren, die dann zum gewünschten, neuen Verhalten führen. Manche würden dafür exakt nur genauso viel Code schreiben, um der Anforderung/Verhalten zu genügen. Dieser Ansatz wird stark durch TDD getrieben und unterstützt. Andere schreiben deutlich mehr Code als gefordert, um vielleicht zukünftige Anforderungen mit abzudecken. Auch hier wird man prima durch TDD unterstützt, nur ist die Frage, wie weit sollte man sich von der Anforderung (in die Zukunft) entfernen? Kann man diese überhaupt vorhersagen? Wird dadurch unter Umständen die Anwendung nicht unnötig komplexer?

„Der Anspruch, eine Anwendung so flexibel für ihren Gesamten Lebenszyklus zu schreiben, dass Änderungen am Verhalten oder den Anforderungen an die Software leicht zu implementieren wären, ist schlicht unmöglich. Man wird es immer falsch machen, egal was man unternimmt“.

Dieser These kann ich mich nur anschließen.

Sandro beschreibt das Problem mit dem Begriff „Inflection Point“, welchen er wie folgt definiert:

„Der Inflection Point definiert den maximalen Aufwand, den wir mit Gutem Gewissen aufbringen können (um dem neuen Verhalten zu genügen), um den gewünschten Grad an Flexibilität zu erreichen, den wir zum aktuellem Moment benötigen. Alles was hinter diesem Inflection Point liegt, ist den Aufwand nicht wert.“

Wie aber nähert man sich diesem Punkt? Entweder von rechts nach links, oder von links nach rechts.

Wenn wir uns von Rechts dem Inflection Point nähern, dann betrachten wir die Features unserer Software, die wir in näherer Zukunft umsetzen wollen. Wir denken also darüber nach, wie die ideale Lösung für unsere Features aussehen würden. Von diesem Punkt aus wandern wir weiter Richtung links und überlegen uns, wie wir die Lösung günstiger bzw. schneller implementieren könnten, ohne dabei die Flexibilität für die zukünftigen Features aus dem Auge zu verlieren. Irgendwann werden wir unsere Lösung aber immer so weit vereinfacht haben (um sie auch schneller umsetzen zu können), dass wir zu viel Flexibilität verlieren würden, um noch unserer idealen Lösung für das Feature (und zukünftige) zu genügen. Änderungen würden hier einfach wieder zu „teuer“ werden. Sobald man an diesem Punkt angekommen ist, hat man den Inflection Point von der rechten Seite aus erreicht.

Von der linken Seite aus ist man bestrebt, eine Lösung so schnell und einfach wie möglich umzusetzen, um den Anforderungen eines neue Features/Verhalten zu genügen. Wobei hier ausdrücklich nicht Quick-and-Dirty gemeint ist. Erst dann würden wir anfangen über direkt im Anschluss anstehende Features und über die potenziellen Möglichkeiten unserer Software in der näheren Zukunft nachzudenken. Dadurch sind wir in der Lage zu entscheiden, wie flexibel unser aktueller Code gegenüber der Zukunft überhaupt sein muss. Stellen wir Fest, dass wir unseren Code so weit flexibel halten wollen, dass er zu aufwändig zu Implementieren wäre, dann haben wir den Inflection Point von der linken Seite aus erreicht.

Für mich hat der erste Ansatz (von rechts nach links) einen starken Character von Over-engineering. Dies führt zu erheblichen Kosten im Bereich der Wartung der Software und letztendlich leidet darunter auch die Flexibilität, die man sich zu erst noch auf die Fahnen geschrieben hat.

Sich im Voraus Gedanken über die zukünftigen Features einer Software zu machen ist selbstverständlich nicht falsch, nur bin ich der Meinung, dass diese nicht das Design direkt beeinflussen sollten. Natürlich kann man an manchen Stellen versuchen, die Software für anstehende Features flexibel zu halten, aber man sollte dies stets mit dem zu erbringenden Aufwand abwägen. Daher würde ich dem Ansatz, sich von links dem Inflection Point zu nähern, häufiger den Vorzug geben. In einem Entwicklungsteam bietet dieser Ansatz auch verstärkt die Möglichkeit, nach jedem Schritt zu reflektieren und den Plan für das weitere Vorgehen neu festzulegen.

Mein wechsel zu ownCloud

In diesem kurzen Beitrag möchte ich gerne meinen Wechsel weg von Dropbox und Google Contacts/Calendar hin zu meiner eigenen ownCloud beschreiben.

Was genau waren meine Beweggründe?

Die Dienste von Dropbox und Google sind so ausgereift und einfach in der Handhabung, dass es eigentlich keinen Grund gibt, diese nicht zu nutzen. Sie funktionieren einfach. Sie machen mein Leben leichter, in dem ich von überall aus auf meine Dateien, Kontakte, Kalendereinträge und vieles mehr zugreifen kann.

Nur leider gibt es da einen kleinen, aber faden Beigeschmack. Ich kann zwar meine Daten über wirklich intuitive Benutzeroberflächen – sei es jetzt ein Client auf dem Smartphone/PC oder die (mobile) Website – verwalten, aber wirkliche Kontrolle darüber wo und wie meine Daten gespeichert werden, habe ich nicht. Ich weiß auch nicht genau, inwiefern diese Daten sicher sind, bzw. diese nicht sogar weiter gegeben werden.

Grundsätzlich sollte man sich immer im klaren sein, dass Daten, die meine häusliche Festplatte verlasen, potenziell angreifbar sind und diese, ohne mein Wissen, missbraucht werden können. Daher stellt sich nun die Frage, wie sensibel dürfen meine Daten sein.

Bei mir handelt es sich nicht um wirklich sensible Daten. Dennoch möchte ich nicht, dass diese auf ausländischen Servern gespeichert sind.

Ich habe mich daher vor einiger Zeit dazu entschlossen, meine Daten in meiner eigenen Cloud zu speichern. Als Cloud-Service nutze ich dafür ownCloud. Was ownCloud ist werde ich hier nicht beschreiben, sondern verweise auf die Website des Anbieters und Wikipedia (die meisten Leser werden ohnehin über ownCloud ein Stück weit informiert sein).

Was habe ich für konkrete Anforderungen?

Meine eigene Cloud soll für mich ein Ort sein, wo ich meine Dateien ablegen und diese auch teilen kann. Außerdem ich möchte ich meinen Kalender und meine Kontakte mit der Cloud synchronisieren. ownCloud bietet all diese Funktionen und noch vieles mehr. Für’s erste reicht das aber.

Die Installation

Die Installation von ownCloud auf einem Webserver ist kinderleicht. Man läd sich von der ownCloud Website das entsprechende Installations-Skript runter und läd dieses in das html-Verzeichnis des Webservers hoch. Über die Adresse http://beispieladresse.de/setup-owncloud.php kann die Installation gestartet werden. Voraussetzung für die Installation ist, ein Webserver mit php in der Version >= 5.3 und magicquotes sollten deaktiviert sein.

(.de ist natürlich auch nur ein Beispiel)

Der Wizard führt einen in schnellen Schritten durch die Installation, welche wirklich selbsterklärend ist.

Die ownCloud ist dann nach der Installation unter http://beispieladresse.de/cloudname erreichbar.

ownCloud als Speicher für Dateien

Das Ablegen von Dateien gestaltet sich in ownCloud genauso einfach, wie mit Dropbox. Zur Verfügung steht einem die Website zur eigenen Cloud und natürlich, wie bei Dropbox auch, der ownCloud Client. Dieser ist erhältnich für Windows, Linux, Mac OSX, iOS und Android.

Auf meinem PC habe ich Ubuntu 12.04 installiert. Zur Installation des Clients habe ich das ownCloud Repository eingebunden und den CLient mittels sudo apt-get install owncloud-client installiert.

Nach der Installation kann der Client gestartet werden. Man gibt nur noch den lokalen Speicherort für Dateien an und zusätzlich die URL+Passwort zur eigenen ownCloud. Der Client synchronisiert dann automatisch alle Dateien zwischen PC und der Cloud.

Auf meinem Motorola Razr I nutze ich den ownCloud-Client for Android. Die Installation ist, denke ich, selbsterklärend.

ownCloud als Speicher für Kontakte und Kalender

Die ownCloud bietet neben der Funktion Dateien im Netz abzulegen auch die Möglichkeit, seine Kontakte und Kalender mit dem Dienst zu synchronisieren. Das Ganze spielt seine Stärke erst so richtig aus, wenn die Daten auch mit einem mobilen Gerät und einer PIM-Suite (wie Outlook, Evolution oder Thunderbird mit Lightning) abgeglichen werden können.

Die Kontakt-Daten importiert man ganz einfach über die Website der Cloud im Bereich Kontakte. Dafür klickt im unteren, linken Teil der Anwendung auf das kleine Zahnrad und klickt im Bereich Importieren auf den „Select file…“ Button.

Die Kalender-Daten werden auf ganz ähnliche Weise importiert. In der Regel existiert bereits ein Default-Kalender, der nur noch mit den importieren Daten versorgt werden muss.

Synchronisation mit mobilen Geräten

Da ich selbst nur ein Android-Mobiltelefon besitze, beschränkt sich der nachfolgende Text auch nur auf die Synchronisation mit einem Android-Gerät.

Für die Synchronisation werden zusätzlich folgende Apps benötigt:

– CardDAV free (für die Kontaktdaten)
– CalDAV (für Kalender – kostenpflichtig, 2,59 €)

Die Installation der beiden Apps sollte wie gewohnt über den Google PlayStore erfolgen.

Einrichtung der Kontakt-Daten

Nachdem die CardDAV App installiert und gestartet wurde, verlangt die App nach der Anlage eines neuen Kontos. Hierzu wählt man CardDav als Kontotyp aus. Auf der nächsten Seite wird die URL zum Kontakt-Speicher (in diesem Fall unsere ownCloud angegeben). Die URL folgt dabei dem Muster:

http://beispieladresse.de/cloudname/remote.php/carddav/addressbooks/username/contacts

Eine SSL Verbindung kann wahlweise eingerichtet werden. Die App benötigt nur noch den Usernamen und das Passwort und versucht sich anschließend sofort mit der ownCloud zu verbinden. Ist der Versuch erfolgreich, können noch weitere Einstellungen getroffen werden. Ich persönlich nutze die Zwei-Wege-Synchronisation mit der Einstellung, dass das mobile Gerät immer gewinnt, sollte es zu einem Konflikt kommen. Diese Art der Synchronisation befindet sich derzeit noch im BETA-Status und sollte mit Bedacht gewählt werden. Ein initiales Backup der Kontakte empfiehlt sich. Ich persönlich habe aber noch keine Problem damit gehabt.

Die Kontakte werden anschließend mit der ownCloud synchron gehalten und in Android-Kontakte-App angezeigt. Die Synchronisation mit den Google-Kontakten kann dann deaktiviert werden.

Einrichtung der Kalender-Daten

Die Einrichtung folgt dem gleichen Beispiel, wie die der Kontakt-Daten. Auch nach dem Start der CalDAV App wird zunächst wieder nach der Anlage eines neuen Kontos gefragt. Wählen Sie diesmal CalDAV als Typ aus und folgen Sie dem Wizard, wie schon bei der Einrichtung der CardDAV App. Die Zwei-Wege-Synchronisation ist auch hier noch im BETA-Status.

Ist die App eingerichtet, muss in der Kalender-App von Android noch der ownCloud Kalender als anzuzeigender Kalender hinzugefügt werden. Es kann jetzt auch der Google Calendar deaktiviert werden.

Coming soon…

Mein Blog befindet sich derzeit noch im Aufbau. Von daher noch ein bißchen Geduld 🙂
Erste Themen werden sein:

  • Wechsel von Dropbox/Google Services zu ownCloud
  • Codekata Tagebuch
  • uvm.

Gruß marstusch