Glasfaserausbau in der Heimatgemeinde

Das Waldviertel – im speziellen der Norden – ist ja nicht gerade bekannt dafür, dass Infrastrukturprojekte des Landes NÖ oder des Bundes dort als erstes umgesetzt werden. Oft ist eher das Gegenteil der Fall, wie bei der Schließung der Gynäkologie im Landeskrankenhaus Waidhofen/Thaya. Das Waldviertel dagegen punktet dafür mit hoher Luftqualität, ruhigen Landschaften, günstigen Grundstückspreisen, wenig Straßenverkehr und bald mit einer Glasfaserinfrastruktur, die der eines Ballungszentrums wie Wien um nichts nachsteht.

2015 ging durch die lokalen Medien, dass der Zukunftsraum Thayaland eine geförderte Region bzgl. Glasfaserausbau sein soll. Als Gründer der Nordhof Service GmbH ist man für solche Nachrichten natürlich sehr empfänglich und weil ich nicht ganz einfach nur warten wollte, was passiert, habe ich mich entschlossen für die Gemeinde Gastern die Funktion des Breitbandbeauftragten zu übernehmen. Ab Juni 2016 manifestiert sich das dann auch mit einem Mandat im Gemeinderat.

Die Investitionen des Landes NÖ in den Breitbandausbau zählen grundsätzlich zu dem Bestreben, die Infrastrukturunterschiede von Stadt und Land auszugleichen. Konkret für den Glasfaserausbau wurde die nöGIG (NÖ Glasfaser Infrastruktur GmbH) gegründet. Dieses Unternehmen ist aktuell damit beauftragt den Glasfaserausbau in vier Modellregionen des Landes voranzutreiben:

  • Kleinregion StadtLand
  • Zukunftsraum Thayaland
  • Triestingtal
  • Ybbstal

Aktuell bin ich mit Bgm. Roland Datler in den Katastralgemeinden der Marktgemeinde Gastern unterwegs, um in Form von Ortgesprächen die Bürger zu informieren. Unterstützend zu diese Gesprächen, werden unter www.m-moldaschl.net/glasfaser laufende Informationen zu dem Thema veröffentlicht.

Ein Glasfaseranschluss ersetzt natürlich keines Falls eine medizinische Einrichtung wie eine gynäkologische Station, aber mit dieser Infrastruktur sind wir ganz vorne dabei was den Breitbandausbau in NÖ betrifft.

Veröffentlicht unter Glasfaser | Kommentare deaktiviert für Glasfaserausbau in der Heimatgemeinde

Event Sourcing: Gast-Blogpost bei tech.willhaben.at

Seit längerer Zeit beschäftige ich mich bei einem Kunden von mir mit dem Thema „Event Sourcing„. Darüber habe ich nun als Gastautor eine Serie von Blogposts auf http://tech.willhaben.at gestartet.

Der einführende Blogpost ist unter http://tech.willhaben.at/2016/03/event-sourcing-at-willhaben.html zu finden.

Veröffentlicht unter Applikationsdesign, Event Sourcing, Software Entwicklung | Kommentare deaktiviert für Event Sourcing: Gast-Blogpost bei tech.willhaben.at

Software Entwicklung braucht Konstanten

Als Software Entwickler kommt man nur sehr selten zu einem Projekt, das von der grünen Wiese weg gestartet wird. Meist arbeitet man an Erweiterungen von bestehenden Applikationen. Üblicherweise bekommt man vom Kunden Anforderungen präsentiert und man ist einerseits mit der Anforderung an sich beschäftigt und andererseits – das ist oft ein nicht zu unterschätzender Anteil – mit der Frage: „Wie integriere ich das Feature in den bestehenden Source Code?“.

Das Feature wird also analysiert, geschätzt und soll schließlich umgesetzt werden. Der Entwickler

  • schnappt sich also das Feature im Feature-Tracking System,
  • schreibt Code dafür in seiner IDE,
  • testet es auf seiner lokalen Maschine,
  • commited den Code ins Source Code Verwaltungssystem,
  • stößt einen Build für das Testsystem an und testet,
  • übergibt das Feature dem QA-Kollegen zum Testen,
  • steht dem Operationsteam bei der Installation es Features im Produktionssystem zur Verfügung

Damit man sich auf den Inhalt und die Integration des Feature konzentrieren kann, müssen obige Schritte durch Konstanten begleitet werden. Das bedeutet, dass das „Drum-herum“ verlässlich sein muss. Typische Konstanten sind

  • zuverlässige Tools (Feature-Tracking System, IDE, Source Code Verwaltungssystem)
  • zuverlässige und schnelle Hardware (lokale Maschine, Testsystem)
  • verlässliche Kollegen (QA-Kollegen, Operationsteam)
  • ein konstanter Entwicklungsprozess

Je öfter Tools, Hardware, Mitarbeiter oder gar der Prozess getauscht oder geändert werden, desto fehleranfälliger werden Software Entwickler, weil sie von der tatsächlichen Aufgabenstellung abgelenkt werden.

Es gibt aber Entwicklungsprojekte, wo sich die Infrastruktur laufend mit der Applikation ändert. Hierfür macht es Sinn einem Entwickler dafür abzustellen um Expertise aufbauen zu können. Infrastruktur ist schon alleine aufgrund der geringeren fachlichen Anforderungen etwas anderes als Anwendungsentwicklung und erfordert spezielles Wissen und Erfahrung. Dadurch wird die Weiterentwicklung der Infrastruktur wieder zur Konstante für die Anwendungsentwicklung.

In der Software Entwicklung ist man ja noch lange nicht so weit wie in der Bauindustrie. Dort kennt man die Konstanten, kennt die Eigenschaften der verwendeten Materialen und man kann sich auf die korrekte Verwendung und Kombination derer konzentrieren.

Veröffentlicht unter Software Entwicklung | Kommentare deaktiviert für Software Entwicklung braucht Konstanten

We need a foreman

A couple of days ago I shared two blog posts from Uncle Bob on twitter. He wrote about having a foreman in development teams and postet a follow up on that. My tweets lead to an interesting discussion and a blog post „We don’t need a foreman„, which I’m responding to now.

In „We don’t need a foreman“ the author argues that the foreman is somebody who

  • destroys trust, team spirit and motivation
  • is not a peer
  • will strongly stick to his position
  • may no be the best developer
  • has the responsibility for everything, so no one else will take over responsibility
  • is the bottleneck.

According to this list, the foreman is somebody who does more harm than good to a software development team. I go a little bit further and assume that the author sees a foreman as a dictator or a petty tyrant.

My view one having a foreman is completely different. I see the foreman as an „enabler“, not a „disabler“. For me a foreman is more an assistant than a boss. As such the foreman

  • cares about trust, team spirit and motivation by keeping them high
  • behaves like a peer
  • let’s other developers make decisions
  • consciously improves his skills to stay the best
  • takes over responsibility in situations where the team is not able to do so
  • cares about having co-foremen who can take over if necessary

The point is that the foreman as such acts in the background. If the results are good and customers are satisfied, there is not much actual foreman work to do. If the results are bad, the foreman helps the team to achieve better results and more satisfaction.

If you think of the famous Wiener Philharmoniker, how would the new years concert be without a conductor? You can also think of successful football teams like FC Barcelona or Bayern München. On the field there is always a foreman in the offense and also a foreman in the defense. If the team is in front there is not more to do for the foreman than every other player at his position. If the opponent is in front the foreman takes action to lead the team to a win.

It is also important to point out, that a foreman has to know the team members very well. He must know their weaknesses and their strengths better than any other in the team. People are different and that has to be considered by the foreman.

Veröffentlicht unter Software Entwicklung | Kommentare deaktiviert für We need a foreman

@TestExecutionListener pitfall

For this post I switch to english because it is supposed to help developers all over the world, not only the german speaking developers ;-).

I’m currently working on a Java web application (more on that in a future post) which uses the Spring Framework for application configuration, data access, the web layer and for integration testing. On writing my first integration test, I wanted to check out what a TestExecutionListener can do for me. As I’m using annotations to configure the application, a service test basically looks like the following:

@ContextConfiguration("classpath:application-config.xml")
@RunWith(SpringJUnit4ClassRunner.class)
public class MyServiceTest {

    @Autowired
    private MyService myService;

    @Test
    public void test() {
        assertFalse(myService == null);
    }

}

The test loads the application context definition from the classpath, uses the SpringJUnit4ClassRunner to run them and uses Springs dependency injection mechanism to get the service to be tested. The test runs fine, but after configuring a TestExecutionListener, the test will no longer be green:

@ContextConfiguration("classpath:application-config.xml")
@RunWith(SpringJUnit4ClassRunner.class)
@TestExecutionListeners(MyTestExecutionListener.class)
public class MyServiceTest {

    @Autowired
    private MyService myService;

    @Test
    public void test() {
        assertFalse(myService == null);
    }

}

The pitfall is, that if you don’t configure a TestExecutionListener with the @TestExecutionListeners annotation, the DependencyInjectionTestExecutionListener gets configured by default. So the default configuration will be replaced by your own listener, thus dependency injection will no longer work as you expect it.

The solution is to additionally configure Springs DependencyInjectionTestExecutionListener:

@TestExecutionListeners({MyTestExecutionListener.class, DependencyInjectionTestExecutionListener.class})

The documentation tells you somehow about that, but it’s very easy to read over it.

Veröffentlicht unter Software Entwicklung | Kommentare deaktiviert für @TestExecutionListener pitfall

Rückblick auf 2013

2013 war ein fleißiges Jahr. Einerseits konnte ich für meine Kunden die gesteckten Ziele erreichen, andererseits hat der Haus- und Bürobau begonnen, was mich viel mehr gefordert hat als mir lieb war.

Trotzdem, ein Jahr ohne Weiterbildung kann kein gutes Jahr für einen „Wissenshandwerker“ (zu dem Begriff ist ein weiterer Blogpost geplant) wie einen Software Entwickler sein. Hier also ein kurzer Review über meine Aktivitäten zu dem Thema im vergangenen Jahr.

Bücher

  • 97 Things a Programmer should know: Dieses Buch umfasst 97 Tipps für Software Entwickler von ca. 80 verschiedenen Autoren, die großteils selbst Software Entwickler sind. Es ist zwar durch die vielen „Geschichten“ recht kurzweilig zu lesen, bringt aber nichts neues für erfahrene Entwickler. Einsteigern ist es aber durchaus zu empfehlen.
  • Clean Code von Uncle Bob: Ein tolles Buch mit vielen Tipps, wie man Code schreiben sollte, sodass er nicht nur für einen selbst lesbar, änderbar und verständlich bleibt, sondern auch für die Nachfolger.

Seminare / Workshops

  • Git Beginners: Das Zero2hero-Team um Martin Ahrer hat Tim Berglund (Github) als Trainer für eine 2-tägiges Git-Training nach Wien geholt. Ich habe mir nur den ersten Tag geleistet und musste mir eingestehen, dass das ein Fehler war. Da ich Git schon länger im privaten Umfeld verwende, war nicht viel neues für mich dabei. 
  • Introduction to Couchbase: Michael Nitschinger ist ein in Wien lebender Couchbase Entwickler, der Couchbase Seminare veranstaltet und auch auf Konferenzen spricht. In seinem Einführungsseminar hat er Couchbase und dessen Fähigkeiten als verteiltes NoSQL System vorgestellt. In ein Kundenprojekt hat Couchbase bei mir zwar noch nicht geschafft, aber bei nächster Gelegenheit wird es definitiv in Erwägung gezogen.

Konferenzen

Programmiersprachen/Frameworks

Eine neue Sprache zu lernen habe ich nicht mehr geschafft, obwohl es mit Erlang, Dart und Scala doch einige mir noch unbekannten Sprachen gibt, die mich interessieren. Immerhin bin ich mit Grails weiter gekommen und je mehr ich mich damit beschäftige, desto größer wird meine Skepsis. Ich habe mich mit Frameworks noch nie so richtig wohl gefühlt, die versprechen einem die „ganze“ Arbeit abzunehmen. Irgendwann muss man dann doch Zeit aufwenden um zu verstehen, was da genau im Hintergrund passiert … das ist bei Hibernate auch so. Ich bin aber immer mehr davon überzeugt, dass diese Zeit besser investiert ist, wenn man die Konzepte dahinter lernt (SQL im Fall von Hibernate) und das Gelernte selbst anwendet. Meine Berufskollgen von Catalysts sind einer ähnlichen Ansicht zu dem Thema bezogen auf Software-Entwicklung mit Grails.

… und 2014?

Das Thema Complex Event Processing wird die nächsten Monate dominieren und ein paar Bücher warten schon darauf gelesen zu werden, u.a. Practical API Design von Jaroslav Tulach (sauteuer, hoffentlich wirkt’s ;-)). Mit Seminaren und Konferenzen sieht es momentan nicht so gut aus. Da bin ich für Tipps dankbar. Der Haus- und Bürobau geht natürlich weiter, langweilig wird mir also nicht.

Veröffentlicht unter Software Entwicklung | Kommentare deaktiviert für Rückblick auf 2013

Keine Ausreden

„Mein Vorgänger hat so schlecht gearbeitet“, „Der Code ist nicht verständlich“, „Das Design ist schlecht“, „Es gibt keine Dokumentation“, „Der Code ist nicht dokumentiert“, „Das Framework ist veraltet“, „Mit dem Framework XY wäre es schon lang fertig“, etc … es ist schon sehr einfach für Entwickler, die ein historisch gewachsenes Stück Software (welches ist das nicht?) weiterentwickeln, Ausreden zu finden, wenn etwas nicht rechtzeitig oder vielleicht gar nicht fertig wird oder mit vielen Bugs geliefert wird.

Es darf aber niemals dazu kommen, dass man solche Ausreden verwenden muss, denn

  • bevor man ein Feature implementiert, macht man eine Analyse
  • basierend auf der Analyse überlegt man eine Lösung
  • basierend auf der Lösung macht man eine Schätzung
  • basierend auf der Schätzung stimmt der Auftraggeber zu oder – falls das Ergebnis der Schätzung zu lange ist – wird man sich gemeinsam eine „billigere“ Lösung überlegen

Hat man sich verschätzt, sollte man aus den eigenen Fehlern lernen und die nächste Analyse genauer machen. Bekommt man zu wenig oder gar keine Zeit für eine Analyse sollte man hinterfragen, ob eine weitere Zusammenarbeit mit dem Auftraggeber Sinn macht.

Interessant ist auch immer wieder der Versuch einen Neubau zu argumentieren. Dabei muss man aufpassen, wer einen Neubau argumentiert: Ist es ein Entwickler, der schon ein paar Jahre mit der Software arbeitet und immer wieder – zwar mühsam aber doch – die vereinbarten Ziele erreicht, oder ist es jemand, der nie wirklich versucht oder es nicht geschafft hat, das Bestehende zu lernen und zu verstehen? In so einem Fall, stellt sich dann nämlich die Frage, ob von der gleichen Person ein Neubau überhaupt geschafft werden kann. Aber, man kann ja wieder auf den ersten Absatz dieses Artikels zurückgreifen ;-).

Es geht halt bei der Entwicklung von Software schon noch darum etwas zu schaffen, etwas fertig zu stellen, etwas zu Ende zu bringen, den Auftraggeber zufrieden zu stellen … und die kompetenten Entwickler sind jene, bei denen das gesagte und das getane zusammenpasst.

Veröffentlicht unter Software Entwicklung | Kommentare deaktiviert für Keine Ausreden

Broken Windows

Mit der Broken Windows Theorie bin ich das erste Mal in Berührung gekommen, als ich The Pragmatic Programmer gelesen habe. Diese Metapher begleitet mich seither in meinen Projekten und sie fasziniert mich. Ich finde sie faszinierend, weil man sie nahezu überall anwenden kann.

Die Broken Windows Theorie hat ihren Ursprung im Kriminalwesen und beschreibt, wie ein zerbrochenes Fenster in einem leerstehenden Haus zu völliger Verwahrlosung führen kann. Ein zerbrochenes, nicht repariertes Fenster in einem Gebäude lässt erkennen, dass das Gebäude leer steht. Ein zweites Fenster bricht, Graffiti werden aufgesprüht und das Gebäude wird „übernommen“. In weiterer Folge steigt die Zerstörung und Kriminalität zieht ein.

Andrew Hunt und David Thomas gehen in dem Kapitel „Software Entropy“ auf  die Broken Windows Theorie ein indem sie analysieren, in wie weit Projekt- bzw. Teamkultur Einfluss auf ein erfolgreiches Projekt haben. In der Software Entwicklung versteht man unter Broken Windows, schlechtes Design, schlampige Implementierung und falsche Entscheidungen. In diesem Sinn führen Broken Windows in Software Projekten genauso zu völliger Verwahrlosung. Dies ist daran erkennbar, dass ein gut funktionierendes Team nach langer Entwicklungszeit Ergebnisse mit vielen Fehlern liefert.

Verantwortlich für das Verhindern von Broken Windows sind aus meiner Sicht

  1. die Software Entwickler: Klar, sie schreiben Code und der muss sauber sein/bleiben/werden.
  2. Produktmanagement/Produktdesign: Eine Anwendung muss per Definition sauber sein, dh. Produktdefinitionen dürfen genauso keine Broken Windows enthalten
  3. Management/Kunden: Entwickler und Produktdesigner brauchen Zeit, Zeit für Reviews. Zu straffe Fertigstellungstermine führen dazu, dass Entwickler und Designer bei der Qualität als erstes Abstriche machen.

Aus eigener Erfahrung weiß ich, dass man jeden Tag dazu verleitet wird, schnell mal ein @Ignore über einen nicht funktionierenden Unit Test zu schreiben oder schnell mal unDRY zu sein, weil es „ja eh nur“ einen Kleinigkeit ist. Trotzdem, Broken Windows dürfen in einem Software Projekt nicht akzeptiert werden, weil es langfristig zu schlechter Qualität und Frustration führt.

Veröffentlicht unter Applikationsdesign, Software Entwicklung | Kommentare deaktiviert für Broken Windows

Erstes Kundenprojekt mit WordPress umgesetzt

Gestern ist der Relaunch von www.moldaschl.at in Betrieb gegangen. Die Webseite gehört meinem Fahrradhändler und -mechaniker Radsport Moldaschl aus Heidenreichstein. Die alte und statische Webseite wurde von mir durch eine Lösung auf Basis von WordPress abgelöst.

Mit dieser Lösung kann der Kunde selbst und ohne Programmierkenntnisse

  • Seiten erstellen und verwalten
  • Beiträge auf der Startseite erstellen und verwalten
  • Bilder hochladen und verwalten
  • das Menü verwalten
  • Grundeinstellungen am Layout verändern
  • das Layout komplett verändern (mit WordPress Themes)
  • und alles was sonst noch mit WordPress Plugins möglich ist

… und das Alles in weniger als 20 Stunden Entwicklungsaufwand. Gehostet wird die Seite von der Telekom. Mit der Administrationsanwendung des Business Webspace kann man WordPress mit wenigen Klicks installieren.

Der Kunde hat sich das initiale Layout selbst ausgesucht und hat auch den Inhalt schon selbst erstellt.

moldaschl.at

Was noch fehlt bzw. was man noch machen kann, ist eine SEO (Search Engine Optimization) Optimierung der Seite und „Social Icons“, damit Inhalte von www.moldaschl.at leichter über Plattformen wie Facebook und Twitter geteilt werden können.

Veröffentlicht unter Wordpress | Kommentare deaktiviert für Erstes Kundenprojekt mit WordPress umgesetzt

Rückblick auf 2012

Als Software Entwickler ist es nicht nur wichtig, dass man Software, sondern auch seine technischen Fertigkeiten entwickelt. Als Angestellter hat man – wenn man Glück hat – einen Arbeitgeber, der lernwillige Programmierer fördert, als Selbständiger muss man sich schon selbst Gedanken drüber machen, wie man sich selbst weiter bringt.

Andrew Hunt und David Thomas schreiben in „The Pragmatic Programmer“, dass man als Software Entwickler pro Jahr mindestens eine neue Sprachen lernen und pro Quartal ein Buch lesen soll. Diesen Ansatz verfolge ich in etwa. Mir sind folgende Dinge wichtig, wenn es um die Entwicklung meines Wissens geht:

  1. Bücher: Bücher sind eine hervorragende Quelle für Wissen. Ich versuche pro Jahr ein paar zu lesen, wobei ich immer mehr Bücher pro Jahr kaufe als lese.
  2. Blogs/Artikel/Magazine: Das ist Teil der täglichen Arbeit. Damit versuche ich am neuesten Stand zu bleiben.
  3. Neue Sprache(n): Eine neue Sprache zu lernen bedeutet für mich mehr als nur ein Hello-World zu schreiben. Um sagen zu können, dass ich eine Sprache gelernt habe, muss ich schon eine kleine Anwendung (zBsp: Zeiterfassungssystem) damit geschrieben haben. Deswegen ist es – wenn man mit Projekten voll ausgelastet ist –  relativ schwierig für mich pro Jahr mehr als eine Sprache zu lernen.
  4. Konferenzen/Vorträge: Veranstaltungen dieser Art sind für mich als Ideenimpuls sehr wichtig. Vorträge dauern oft nicht länger als eine Stunde und sind deswegen immer (aus einer technischen Perspektive) sehr oberflächlich gehalten. Trotzdem oder vielleicht gerade deswegen dienen sie mir als perfekte Ideengeber. Ein anderer wichtiger Aspekt dabei ist das Networking. Konferenzen sind eine perfekte Gelegenheit für Erfahrungsaustausch mit Gleichgesinnten.

Was hat sich also bei mir zu den obigen Punkten im Jahr 2012 getan?

Bücher:

  • ActiveMQ in Action: Bei einem Kundenprojekt haben wir uns entschieden JMS mit ActiveMQ zu implementieren und deswegen habe ich mich mit diesem Buch schlau gemacht
  • Java Message Service: Mit diesem Buch habe ich mich bei dem gleichen Kundenprojekt mit den Details von JMS beschäftigt und es dient mir auch als Grundlage für eine JMS Einführung an die Kollegen.
  • Version Control with Git: Git interessiert mich schon länger und ich verwende es schon seit einigen Monaten mit Bitbucket. Was mir aber immer noch fehlt sind „Best Practices“ mit Git. Aktuell verwende ich es eher noch wie Subversion.

Neue Sprache(n): Ich habe 2012 begonnen mich mit alternativen Sprachen auf der JVM zu beschäftigen. Ich bin gerade dabei mit Grails und Groovy eine kleine Anwendung zu schreiben, kann aber noch nicht behaupten, dass ich es „gelernt“ habe.

Konferenzen/Vorträge: Im Jahr 2011 waren die Konferenz- und Seminarbesuche eher enttäuschend, deswegen habe ich mir für 2012 vorgenommen gehabt, dass ich nur wenige, dafür gut ausgewählte Vorträge besuche.

  • WKO E-Day: Der E-Day ist eine Gratis-Veranstaltung der WKO zu den aktuellen Themen in der IT. Ich wollte mir das ganz einfach mal ansehen, war mir aber schon zu Mittag sicher, dass das nichts für Software Entwickler ist.
  • Treffen des Vienna Agile Requirements Circle: Ich war bei einem Treffen des V-ARC und habe den Diskussionen rund um das Thema „Product Owner(ship)“ gelauscht. Es war ganz interessant, aber da war trotzdem nichts Neues dabei.
  • EJug Seminar zum Thema Groovy und Kotlin: Vor allem der Vortrag über Groovy von Dierk König war sehr interessant und hat mich auf gute Ideen gebracht.
  • Agile Tour 2012 Wien: Interessante Vorträge zum Thema Agilität in der Software Entwicklung waren es definitiv wert, einen Samstag dafür zu investieren.

Alles in Allem kann ich mit 2012 zufrieden sein. Für 2013 freue ich mich schon auf die Software Quality Days und auf Confess 2013.

Veröffentlicht unter Software Entwicklung | Kommentare deaktiviert für Rückblick auf 2012