Archive

Posts Tagged ‘Lernen’

MEAP: Wenn es einmal ganz lange dauert

29. Juni 2015 Kommentare aus

MEAP - Manning Early Access Program

MEAP - Manning Early Access Program

Seit rund 6 Jahren bin ich ein regelmässiger Kunde des Early Access Program von Manning (kurz MEAP). Mit dieses Programm kann man Bücher lesen die noch in der Entstehung sind. Was komisch tönt macht gerade bei neuen Technologien Sinn, da es dort oft an guter Dokumentation fehlt. Wie einfach man bei diesem Programm mitmachen kann hatte ich schon hier beschrieben.

Unfertige Bücher können auch einmal nicht erscheinen. Dies trat bei mir bisher nur bei einer Bestellung ein und wurde durch Manning vorbildlich gelöst.

 

Gute Dinge brauchen Zeit

Seit heute kann ich nun über ein weiteres Kapitel berichten. Es kann durchaus vorkommen, dass ein Buch erst mit einigen Jahren Verspätung erscheint. So erhielt ich heute die gedruckte Ausgabe von „Groovy in Action, Second Edition“. Dies wäre nicht der Rede wert, wenn ich mich noch an die Bestellung erinnern könnte. Ein Blick ins Mailarchiv lieferte mir als Bestelldatum den 29. Dezember 2009.

Von der Bestellung bis zur Auslieferung sind demnach ganze 5.5 Jahre vergangen. In dieser Zeit konnte ich dank der elektronischen Formate (PDF und Mobi) zahlreiche Versionen lesen. Dass der Weg zum fertigen Buch noch so lange sein wird hätte ich mir 2009 allerdings nicht vorstellen können.

 

Fazit

Solch lange Wartezeiten hatte ich bisher noch nie erlebt. Trotz dieser neuen Erfahrung finde ich MEAP noch immer eine gute Idee. Der Vorteil dieser Programme liegt allerdings klar im Bereich der elektronischen Formate und weniger bei den gedruckten Ausgaben.

Wenn neue Versionen automatisch an den eigenen Kindle übertragen werden, hat man immer die neuste Version zur Hand und kann mit dieser Arbeiten, ganz unabhängig davon wann das Buch schlussendlich gedruckt wird.

Schlagwörter:, , ,

Mein Technologieradar für 2015

22. April 2015 2 Kommentare

Seit der Veröffentlichung meines ersten Technologieradars ist schon mehr als ein Jahr vergangen. Somit ist es höchste Zeit für einen Rückblick, ein Fazit und die Erstellung der nächsten Version.

 

Was brachte mir der Technologieradar?

Der grösste Pluspunkt für mich war die erzwungene Fokussierung. Ein bewusstes Einteilen von verschiedenen Technologien in die einzelnen Ringe hat mir sehr geholfen. Ganz wesentlich war der Ring Hold, in den alles hinein geht mit dem ich mich nicht beschäftigen wollte. Dadurch konnte ich mich auf die Technologien fokussieren, die ich als wichtig erachte und hatte dennoch genügend Zeit um auch auf Neues reagieren zu können.

Ein einmal erstellter Technologieradar ist kein starres Konstrukt. Wie ein richtiges Radar soll dieser vielmehr auf die Umgebung reagieren und wichtiges hervorheben.
Strukturierte Logmeldungen sind so ein neues Thema, das aus der vagen Idee von “Log as Data” und “Business Event Tracking” entstanden ist und zu einigen Blog Posts führte.

 

Mein neuer Technologieradar

Wie im letzten Jahr habe ich wiederum das Projekt Techradar von Brett Dargan verwendet. Die Ringe sind ebenfalls unverändert und folgen der Idee von ThoughtWorks:

  • Hold (abwarten): Keine neuen Projekte mit diesen Technologien starten.
  • Assess (einschätzen): Genauer hinschauen ob sich daraus etwas entwickelt.
  • Trial (ausprobieren): In kleineren und weniger wichtigen Projekten Erfahrungen sammeln.
  • Adopt (umsetzen): Bereit um in kritischen Anwendungen verwendet zu werden.

Mit der 2. Ausgabe macht es nun auch Sinn zwischen bestehenden und sich bewegenden Themen zu unterscheiden. Die Kreise stehen dabei für unveränderte Technologien, während die Dreiecke Neuigkeiten oder grosse Veränderungen markieren.

Techradar_2015

 

Techniken, Verfahren & Methoden

Techradar_2015_Techniques
In diesem Quadranten gibt es wenige Veränderungen. Das neue Thema der strukturierten Logmeldungen sowie Exploratory Testing sind aus meiner Sicht bereit für den produktiven Einsatz und können bei der Fehlervermeidung und Eingrenzung sehr hilfreich sein. Für die konkrete Umsetzung der strukturierten Logmeldungen in .Net hat sich Serilog als äusserst hilfreich erwiesen, während BugMagnet einem beim Exploratory Testing viel Arbeit abnimmt.

Die Visualisierung von Metriken ist ein Thema zu dem ich noch zahlreiche Abklärungen machen muss. Die Ideen dahinter sind sehr spannend, allerdings führen falsch verwendete Metriken zu grossen Problemen. Daher ist hier besondere Vorsicht geboten.

 

Infrastruktur, Plattformen & Services

Techradar_2015_Infrastructure
Beim letzten Radar zögerte ich noch mit der Empfehlung von RavenDB. Mit Version 3 sind diese Bedenken nun ausgeräumt. Fall ein Projekt eine NoSQL-Datenbank benötigt und darauf mittels C# oder einer REST-API zugreifen will, ist RavenDB meine favorisierte Lösung.

Docker ist ein spannender Ansatz um ganze Systemumgebungen auf Anwendungsebene zu virtualisieren. Diese unabhängigen Container vereinfachen nicht nur den Betrieb, sondern auch die Entwicklung. Mit den Ankündigungen von Microsoft für eine Implementierung auf Basis von Windows dürfte Docker auch bald in der .Net Welt eine grosse Rolle spielen. Somit ist es Zeit für einen genaueren Blick auf Docker.

Konkretes zu SharePoint 2016 wird Anfangs Mai zu erfahren sein. Je nach neuen Funktionen und Verbesserungen könnte SharePoint 2016 ein interessantes Thema werden. Mehr dazu wird man allerdings erst nach der Ignite-Konferenz wissen.

 

Sprachen und Frameworks

Techradar_2015_Languages
Eine sehr grosse Änderung kommt mittels ASP.Net 5 (ehemals ASP.Net vNext) auf die .Net Webentwickler zu. Grundlegende Änderungen in der Projektstruktur, eine komplett auf Mono lauffähige Umgebung und ein eine neue Verteilung der Aufgaben zwischen MVC und WebAPI führen zu einem grossen Lernbedarf. Ob sich dieser lohnt wird nicht zuletzt beim Migrationspfad entschieden. Je aufwändiger es ist eine Anwendung zu migrieren, desto länger werden die alten Versionen verwendet.

AngularJS ist ein Framework mit vielen offenen Fragen. Die inkompatible Version 2 setzt auf TypeScript, den JavaScript-Aufsatz den ich immer noch sehr skeptisch betrachte. Falls AngularJS so gut wird wie manche erhoffen, muss ich meine Position zu TypeScript überdenken. Allerdings könnte AngularJS genauso gut aus meinem Technologiestack fallen…

Bezüglich neuer Programmiersprachen sehen Swift und Go sehr interessant aus, allerdings hat auch C# 6 einige Neuerungen die man nicht verpassen sollte. Daher kann ich derzeit noch nicht abschätzen mit was ich mich am Ende mehr beschäftigen werde.

 

Tools

Techradar_2015_Tools
Balsamiq Mockups und Octopus Deploy sind 2 grandiose Werkzeuge, die einem viel Arbeit abseits der Entwicklung abnehmen. Mit den Mockups in Balsamiq lassen sich Anforderungen und Ideen einfach sammeln, während Octopus das Deployment auf wenige Klicks reduziert.

Entity Framework 7 wird Microsofts nächster Anlauf für einen OR-Mapper. Da erneut grundlegende Funktionen (wie Lazy-Loading) fehlen erinnert einem dies sehr stark an die Einführung von EF 4. Ob der Ansatz eines OR-Mapperers sowohl für relationale wie auch NoSQL-Datenbanken die fehlende Abwärtskompatibilität aufwiegt? Auch hier muss sich erst noch zeigen wie gut die veröffentlichte Version wirklich ist.

Microsoft hat in diesem Bereich in den letzten Jahren sehr viel begonnen und kaum etwas langfristig unterstützt. Durch diese fehlende Kontinuität sind Micro ORMs wie Dapper für mich sehr interessant. Diese kommen ohne grosses Framework aus und liefern einen einfachen Zugang zu relationalen Datenbanken.

 

Fazit

Mit all den Neuerungen in der .Net und Microsoft Welt (Angefangen bei Windows 10 über EF 7 bis hin zu ASP.Net vNext) ist ein eigener Technologieradar aus meiner Sicht unverzichtbar.
Trotz der vielen Unsicherheiten kann man sich so auf einige Neuigkeiten fokussieren und verliert sich nicht in zu vielen Details. Daher kann ich jedem empfehlen sich selber einen Technologieradar zu erstellen. Die dafür investierte Zeit lohnt sich.

Schlagwörter:, , , ,

5 Punkte für bessere Präsentationen

30. März 2015 Kommentare aus

Präsentationen und Vorträge vorzubereiten bedeutet meist viel Arbeit. Während Tagen wenn nicht gar Wochen wird an der Vorbereitung intensiv gearbeitet und oft braucht es viel Überwindung um vor das Publikum zu treten. Ich finde es immer schade wenn diese viele Arbeit am Ende in einer Präsentation resultiert, die wegen Kleinigkeiten hinter ihren Möglichkeiten zurückbleibt.

Da mir oft die immer gleichen Punkte auffallen, möchte ich heute einige kleine Anpassungen zur Verbesserung zeigen. Weitere Ideen sind als Kommentar sehr willkommen.

 

Keine Wand aus Text

Ein Foliensatz soll die wichtigsten Punkte der Präsentation aufnehmen. Während man über die richtige Balance zwischen Hintergrundinformationen und Stichworten debattieren kann, so sollte doch niemals eine Folie komplett mit Text gefüllt sein. Noch schlimmer ist nur noch diese Folie als Ganzes vorzulesen…

Ist tatsächlich so viel Text notwendig gibt es bessere Alternativen: Sei dies ein Handout, ein eigenständiges Dokument, ein oder mehrere Blogeinträge. Welche dieser Varianten besser geeignet ist hängt stark vom Publikum ab. Alle sind aber besser als die Wand aus Text, die einem entgegen der weit verbreiteten Ansicht auch im Nachhinein nicht hilft die gewünschten Informationen aufzufinden.

 

Lesbare Schriftgrösse

Mit der Wand aus Text geht meist auch eine sehr kleine Schrift einher. Da man viel zeigen will muss halt die Schrift entsprechend klein ausfallen. Die Folge davon sind Folien, die man ab der 2. Reihe nicht mehr lesen kann. Wozu wollte man aber nochmals so viel Text einfügen? Genau, damit das Publikum die wichtigen Informationen lesen kann…

Als einfache Grundregel für Schriftgrössen gilt aus meiner Sicht: Wenn die Schrift auf dem Bildschirm nicht zu gross wirkt ist sie auf der Leinwand viel zu klein. Daher sollte man ruhig 2 Schriftgrade höher einsteigen und je nach Raumgrösse sogar eine noch grössere Schrift wählen. Ein Technikcheck vor der Präsentation kann dann für die Feinabstimmung verwendet werden um auch der hintersten Reihe eine lesbare Folie zu bieten.

 

Lesbare Diagramme und Code

Was für den Text gilt muss auch für Diagramme und Code beachtet werden. Soll anhand eines Diagramms gezeigt werden wie sich gewisse Werte entwickeln, müssen diese vom Publikum auch gesehen werden können. Zu oft wird aber weder im Kontrast noch bei der Farbwahl oder der Liniendicke ans Publikum gedacht…

Düne Linien in Diagrammen lassen sich oft sehr einfach mit einer stärkeren Linie ersetzen. In Kombination mit klar unterscheidbaren Farben ist dies meist alles was nötig wäre. Bei Quellcode geht es sogar noch einfacher: Alles was man in Visual Studio machen muss ist die den Zoomfaktor auf 200% zu stellen oder das kleine Werkzeug ZoomIt verwenden.

 

Zeitraster einhalten

Nur die wenigsten Präsentationen sind so wichtig das man den ganzen Tag danach ausrichtet. Meist ist eine Präsentation nur ein Punkt von vielen der an diesem Tag erledigt werden soll. Ein pünktlicher Start und ein rechtzeitiges Ende der Präsentation sind daher unerlässlich.
Nichts ist mühsamer als ein Präsentator der seine Zeit massiv überzieht und sich in unwichtigen Details verliert. Dies führt nicht nur zu Verspätungen der nachfolgenden Termine sondern geht auch sehr schnell ins Geld…

Besser machen kann man dies in dem man seine Präsentation mit 5 Minuten weniger Zeit plant. So kann man auch auf einige Fragen eingehen und ist nicht bereits am überziehen. Eine Uhr oder ein Wecker hilft ebenfalls dabei die Zeit im Auge zu behalten, falls das gewählte Präsentationsprogramm dies nicht selber anbietet.

 

Live-Coding vermeiden

Auch wenn es einige Leute gibt die ohne weiteres vor Publikum fehlerfreien Code schreiben können, so trifft dies für die meisten Präsentatoren nicht zu. Es gibt wesentlich spannendere Möglichkeiten um eine Präsentation zu gestalten als mit einem vollen Saal Fehler zu suchen…

Code soll ruhig gezeigt werden. Gerade wenn es um Details geht sind Code-Beispiele sehr hilfreich. Allerdings genügt es meistens diese zu zeigen, ohne dafür den Code vor Publikum einzutippen. Will man schrittweise den Code für eine Anwendung ergänzen empfiehlt es sich Git zu verwenden und von einem Commit zum nächsten zu springen.

 

Fazit

Obwohl diese 5 Punkte sehr subjektiv sind können diese doch zu besseren Präsentationen führen. Damit ist zwar noch keine erfolgreiche Präsentation garantiert, doch kommt man so leicht in die Gruppe der angenehmeren Präsentationen.

Schlagwörter:,

5 Jahre und 100‘000 Besucher später…

2. September 2014 Kommentare aus

Vor 5 Jahren startete dieses Blog mit dem Artikel “SVN: Commits auf Tags?“. Bis heute folgten 170 weitere Blogeinträge mit einer breiten Themenvielfalt die von grossen Reisen über das Entsperren von Assemblies bis zu .Net Zertifizierungen reicht. Dieser Mix stösst noch immer auf ein reges Interesse und brachte vor einigen Tagen den 100‘000. Besucher auf dieses Seite – sofern die Statistik von WordPress halbwegs korrekt zählen kann.

Grund genug also um diese Jahresmarke mit einem eigenen Eintrag zu würdigen. Zudem ist es eine gute Gelegenheit um einmal auf das erreichte zurückzublicken. In diesen 5 Jahren konnte ich unglaublich viel lernen und mein Blog hat mir geholfen dieses Wissen so aufzubereiten, dass es nicht in kurzer Zeit wieder verloren geht. Und gehen die Details nach all der Zeit doch ein wenig vergessen hilft mir dieses Blog als Nachschlagewerk. Gemäss den Rückmeldungen die ich regelmässig erhalte geht dies nicht nur mir so. Es freut mich wenn auch andere vom hier gesammelten Wissen profitieren können. Denn Wissen ist ja bekanntlich das einzige Gut das sich vermehrt wenn man es teilt.

 

Die 10 beliebtesten Blogeinträge

Auch wenn ich immer versuche etwas Hilfreiches aufzuschreiben, so kann ich kaum je abschätzen welche Einträge ihr Publikum finden. Je nach Jahreszeit verschiebt sich die Nachfrage nach gewissen Themen, doch meistens ist die kleine Erklärung zum einlesen eines Strings über die Kommandozeile ganz weit vorne dabei. Dieser Ausflug ins Java-Land erschien im Januar 2011 und ist auch heute noch sehr beliebt.

Die Top-10 Beiträge gemessen an den Einblendungen sind:

  1. Java: String von der Kommandozeile lesen (mit java.util.Scanner)
  2. Kurz-Tipp: Strecken messen in OpenStreetMap
  3. Kopieren eines Subversion Repository
  4. Stolperfallen bei der Installation von SharePoint 2013
  5. Erste Schritte mit AngularJS
  6. svn export – oder wie man die .svn Verzeichnisse los wird
  7. CSS leicht gemacht mit Bootstrap
  8. Von Subversion zu Git migrieren
  9. SWT: GUI bei langen Aktionen nicht einfrieren lassen
  10. RavenDB: Eine Einführung

 

Englischsprachiger Ableger

Seit einem Jahr schreibe ich zudem in meinem englischsprachige Blog Improve & Repeat. Die zahlreichen Kontakte der letztjährigen NDC haben mich motiviert mein Englisch zu verbessern und regelmässig ein wenig tiefgreifender über Technologien und Konzepte zu schreiben. Die 26 Blogbeiträge die dort im ersten Jahr erschienen sind haben knapp 18‘000 Leser auf die Seite gebracht. Damit ist der Start mehr als geglückt und motiviert mich dort auch weiterhin sehr aktiv fortzufahren.

 

Wie geht es weiter?

Auch wenn ich mich in den nächsten Monaten vermehrt auf Improve & Repeat konzentrieren werde, so bedeutet dies nicht das Ende meines deutschsprachigen Blogs. Ich habe noch zahlreiche Ideen die hier besser aufgehoben sind. Allerdings könnten die Abstände zwischen den einzelnen Einträgen hier grösser werden. Wer nichts verpassen will sollte daher unbedingt den RSS-Feed abonnieren.

Schlagwörter:,

5 Podcasts für Software-Entwickler

17. Juni 2014 4 Kommentare

Podcasts sind für mich ein sehr angenehmes Format um mich auf dem Laufenden zu halten. Alles was es braucht ist eine Mobiltelefon und eine vernünftige App die Podcasts verwalten kann. Und natürlich die passenden Podcasts. Heute möchte ich 5 Podcasts vorstellen die ich regelmässig höre und ich für Software-Entwickler empfehlen kann.

Mir gefällt an diesen Podcasts vor allem der regelmässige Blick über den Tellerrand. Sich nicht nur auf ein spezifisches Thema oder eine Technologie zu limitieren macht angesichts der kurzen Halbwertszeit von Frameworks und Toolkits Sinn. So bleiben viele der besprochenen Themen auch dann noch relevant wenn wir schon den nächsten Hype vor uns haben.

 

Ruby Rogues

Ruby Rogues ist eine wöchentliche Diskussionsrunde die sich vorwiegend um Ruby dreht. Hat man sich einmal an das wilde Durcheinander gewöhnt schätzt man sehr bald den grossen Themenmix und das fundierte Wissen der Moderatoren.

Neben dem Book Club gefallen mir besonders die Episoden bei denen es um allgemeine Themen wie dem Lernen oder Software-Qualität geht. Hier kommen aus meiner Sicht die unterschiedlichen Erfahrungen der Rogues besonders gut hervor und ermöglichen sehr spannende Diskussionen.

Ein grosses Plus für diesen Podcast sind die Abschriften die es für jede Folge gibt. Damit kann man auch später einzelne Themen oder Links einfach finden ohne sich die genaue Folge merken zu müssen.

 

Hanselminutes

Scott Hanselman dürfte den meisten .Net Entwicklern durch seine Präsentationen rund um ASP.net bekannt sein. Sein Podcast Hanselminutes ist glücklicherweise keine Microsoft-Werbeveranstaltung sondern behandelt die Themen die ihn persönlich interessieren.

Jede Woche bespricht Scott mit einem Gast in rund 30 Minuten ein Thema aus dem IT-Bereich. Dabei ist es immer wieder erstaunlich mit wie viel Hintergrundwissen seine Gäste aufwarten können.

Besonders lustig wird es wenn Richard Campbell ein bis zwei Mal pro Jahr für eine Hanselminutiae Folge zu besuch kommt. Diese Gespräche über alles was die beiden gerade so machen sind sehr spannend und die Liste von Gadgets meist endlos.

 

This Developer’s Life

Leider nur sehr unregelmässig und mit grossen Pausen erscheint This Developer’s Life. Die Gemeinschaftsproduktion von Scott Hanselman und Rob Conery nimmt sich in rund einer Stunde grösseren Themen an, die einem meist sehr lange im Gedächtnis haften bleiben. Space, Typo, Cancer und Getting Fired sind nur eine kleine Auswahl der Themenvielfalt.

 

.Net Rocks!

Carl Franklin und Richard Campbell machen zusammen seit einer gefühlten Ewigkeit .Net Rocks. Thematisch sind die beiden in der .Net Welt beheimatet und kennen dort alles was Rang und Namen hat.

Mit 2 Folgen a 60 Minuten pro Woche ist es kaum möglich alle Folgen zu hören. Bei der Menge kann man aber problemlos einen “eigenen” Kanal mit ausgewählten Episoden zusammenstellen und hat immer noch genug Material.

 

Herding Code

Herding Code erscheint rund alle zwei Wochen und wird von K. Scott Allen, Kevin Dente, Scott Koon und Jon Galloway moderiert. Thematisch ist dieser Podcast noch mehr auf .Net fokussiert als .Net Rocks, was einem durch die unterschiedlichen Meinungen ein recht genaues Bild über das .Net Ökosystem liefert.

 
Soweit meine Liste mit Podcasts. Da auch ich gerne neue Podcasts kennen lernen sind weitere Empfehlungen sehr willkommen.

Schlagwörter:, ,

Mittels Technologieradar die Übersicht behalten

12. Februar 2014 1 Kommentar

Bei all den vielen neuen Werkzeugen, Techniken und (JavaScript-) Frameworks die wie Pilze aus dem Boden schiessen ist es äusserst schwer den Überblick zu behalten. Überall sieht man neue Dinge und vieles davon sieht so spannend aus dass man dies gleich ausprobieren will. Nur ist die Menge mittlerweile viel zu gross um dies auch zu tun.

Was man bräuchte ist eine Art Filter mit dem man sich gezielt auf einige ausgewählte Themen und Werkzeugen konzentrieren kann. Man müsste wichtigeres von unwichtigem trennen können ohne dabei zu viel Zeit mit dem Kategorisieren zu verlieren. Was ich bräuchte wäre etwas wie der Technology Radar von ThoughtWorks, nur halt für mich und meine Interessen.

 

Von ThoughtWorks zum eigenen Technologieradar

ThoughtWorks veröffentlicht in etwa alle 6 Monate eine Aktualisierung ihres Technologieradars. Die Grafik ist dabei eine Zusammenfassung der internen Diskussionen und zeigt auf in welche Richtung sich die IT-Branche aus ihrer Sicht bewegt. Statt grosser Dokumente hilft einem eine einzige Grafik abzuschätzen ob man Zeit in die entsprechende Technologie investieren soll oder besser gleich eine Migration plant. Dazu dienen diese 4 Ringen:

  • Hold (abwarten): Keine neuen Projekte mit diesen Technologien starten.
  • Assess (einschätzen): Genauer hinschauen ob sich daraus etwas entwickelt.
  • Trial (ausprobieren): In kleineren und weniger wichtigen Projekten Erfahrungen sammeln.
  • Adopt (umsetzen): Bereit um in kritischen Anwendungen verwendet zu werden.

Neal Ford ist nicht nur beim Radar von ThoughtWorks involviert, sondern spricht auch an Konferenzen über den Nutzen eines persönlichen Technologieradars. In diesem Blogpost erklärt Ford wie man damit auch einen Realitätsabgleich machen kann. Fixiert man sich zu sehr auf einen Hersteller bekommt man nicht mehr mit wie sich die Welt um einen herum verändert – bis es zu spät ist und man keinen neuen Arbeitgeber findet.

Das Festlegen auf die einzelnen Technologien und wo man diese sieht ist der aufwändigste Teil um selber einen Technologieradar zu erstellen. Hier kommt es ganz auf die eigene Einschätzung an, da angesichts der schnellen Veränderungen objektive Kriterien kaum weiterhelfen.
Sobald man alles beisammen hat geht es mit der grafischen Darstellung recht schnell. Dank der grossen Vorarbeit von Brett Dargan uns seinem Projekt Techradar braucht man nur noch eine JSON-Datei anzupassen und schon hat man seine Grafik.

 

Mein Technologieradar

Für meine Grafik bin ich recht schnell von ThoughtWorks abgewichen. Wenn auch etliche Technologien gleich sind so hat mir die Vorlage nicht ganz entsprochen. Der Quadrant “Techniques” ist bei mir weiter gefasst und beinhaltet neben technischen Lösungsansätzen auch Verfahren und Methoden. Gleiches gilt für den Quadranten “Infrastructure” der bei mir auch Plattformen und Services umschliesst.

Techradar_201401

 
 
Techniken, Verfahren & Methoden
Tech201401_Techniques
In diesem Quadranten gibt es bei mir die meisten Einträge in den Ringen “Adopt” und “Trial”. Dies war nicht so geplant, zeigt aber einen interessanten Nebeneffekt des Technologieradars: Durch die grafische Darstellung kann man eine thematische Häufung von Einträgen erkennen die einem so vorher nicht bewusst war.

Bei all den Dingen die ich anschauen oder umsetzen will gibt es eine grosse Ausnahme: Es muss aufhören aus reiner Bequemlichkeit in einer API 1:1 die Limitierungen der darunterliegenden Systemen weiterzureichen. Nur weil SQL Server Null-Werte als 1.1.1753 maskiert braucht ja nicht jeder Konsument der API in seiner Anwendung die Null-Konvertierung selber durchzuführen. Auch wenn ich dies bisher vor allem im Bereich von Datenbanken angetroffen habe gibt es keinen Grund dies nicht auch bei anderen Systemen zu beachten.

 
Infrastruktur, Plattformen & Services
Tech201401_Infrastructure
Das grosse Thema in diesem Quadranten ist die Cloud. Trotz all der NSA Enthüllungen gibt es hier Chancen die zu gut sind um sie zu ignorieren. Angefangen bei GitHub über Code Climate bis hin zu Amazon und Azure gibt es unzählige Einsatzgebiete die auf eine Erkundung warten.

Bei RavenDB habe ich am längsten um die Einteilung gerungen. Da mir noch einige wichtige Informationen für den Produktiveinsatz fehlen blieb es schlussendlich beim Einsatz in kleineren Projekten. Die Wissenslücken für den Einsatz in geschäftskritischen Anwendungen sollte ich aber bald schliessen können.

 
Tools
Tech201401_Tools
Viel Auszuprobieren gibt es für mich bei den Tools. Rund um Ruby gibt es eine Vielzahl von Helfern fürs Testing und den Aufbau von Entwicklungsumgebungen. Bei .Net vermisse ich bisher so ausgereifte Werkzeuge. Daher wird es Zeit genau zu prüfen wie weit SpecFlow und MSpec, respektive Puppet und Chef gekommen sind.

Ein weiteres spannendes Thema sind für mich Micro ORMs. Realistisch betrachtet wechselt man kaum je die Datenbank bei einem Projekt aus. Daher sind OR-Mapper wie Entity Framework oder NHibernate mit ihren Abstraktionsschichten oft ein grosser Overhead der einem den Zugriff auf datenbankspezifischen Funktionen nur über Umwege erlaubt. Micro ORMs könnten da eine Alternative sein die eine vertiefte Abklärung verdienen.

 
Sprachen und Frameworks
Tech201401_Lang
Sowohl für C# wie für Ruby Entwickler dürften die meisten Einträge in diesem Quadranten nachvollziehbar sein. Wo es wohl einige Erklärung braucht ist der “Hold” Ring.

Bei den Desktop-Frameworks wie WPF aber auch WinForms halte ich mich derzeit zurück. Angesichts verteilter Standorte, Home Office und der Verbreitung von Tablets setze ich viel eher auf die Webentwicklung. Diese allerdings abseits von WebForms und Silverlight. Da Silverlight selbst von Microsoft nicht mehr in allen IE-Varianten unterstützt wird ist diese Technologie definitiv gestorben – auch wenn die Supportseite einem eine andere Geschichte erzählen will.

Sehr skeptisch bin ich auch bei TypeScript. Hier handelt es sich aus meiner Sicht um eine Lösung auf der Suche nach einem Problem. Die Probleme vieler Entwickler mit JavaScript lassen sich nicht durch ein aufgepfropftes Typensystem lösen – viel eher muss man JavaScript als eigenständige Sprache akzeptieren und die Eigenheiten lernen. Und sollte TypeScript tatsächlich länger bleiben kann man später immer noch auf diesen Zug aufsteigen.

 

Fazit

Beim Zusammenstellen des Technologieradars muss man sich plötzlich festlegen. Es genügt nicht mehr nur eine vage Liste mit interessanten Technologien zu haben – nun wird auch eine Einteilung in die Kreise und Quadranten benötigt. Es bleibt einem nichts anderes übrig als die einzelnen Technologien zu ordnen und zu klassifizieren.

Der grosse Nutzen dieser Übung liegt für mich im bewussten Auseinandersetzen mit den einzelnen Technologien und der Entscheidung, ob diese nun einen Platz im Radar finden oder nicht. Dabei spielt es keine grosse Rolle wo genau sich diese auf der Grafik befinden. Viel wichtiger ist welche Technologien es überhaupt hinein schaffen.

Wieviel mir die ganze Übung am Ende bringen wird muss sich noch zeigen. Die ersten Erfahrungen waren allerdings so hilfreich dass ich die Erstellung eines eigenen Technologieradars sehr empfehlen kann.

Schlagwörter:, , ,

5 Bücher die jeder Software-Entwickler kennen sollte

30. Juli 2012 3 Kommentare

Ich werde immer mal wieder nach Buchempfehlungen gefragt. Passende Tipps zu geben ist nicht einfach, da je nach Arbeitsgebiet und Vorwissen ganz unterschiedliche Themen im Blickpunkt stehen. Es gibt aber einige Bücher die ich immer wieder empfehlen kann. Die darin behandelten Themen sind nicht technologiespezifisch sondern behandeln wichtige Konzepte und Techniken. Die 5 Bücher die ich hier nenne ergänzen sich, bieten aber auch für sich alleine einen Mehrwert.

Hinweis: Seit Januar 2014 gibt es hier eine aktualisierte Liste mit noch besseren Büchern.

 

Refactoring

Trotz seines Alters ist Refactoring nach wie vor das Standardwerk zur Restrukturierung von Code. Der ausführliche Katalog mit Strategien zur Verbesserung der Codebasis ist aus meinem täglichen Entwicklerleben nicht wegzudenken.

Dies bedeutet keinesfalls dass ich alle darin vorgestellten Methoden auswendig kenne. Aber Refactorings wie das umbenennen von Variablen oder das Extrahieren von Methoden sind Dinge die jeder beherrschen sollte. Diese sind sehr einfachen und verbessern den Code doch enorm.
(ISBN: 978-0-201-48567-7 | detaillierte Rezension)

 
 

The Art of Unit Testing

The Art of Unit TestingRoy Osherove liefert das aus meiner Sicht bisher beste Buch über Unit Testing. Es gibt viele Bücher die gut sind, seine Erklärung von komplexeren Themen wie dem Mocken von Abhängigkeiten ist aber immer noch unerreicht.

Das Buch bietet viele praxisrelevante Beispiele die zeigen wie man auch komplexere Bereiche testen kann. Gerade diese Teile sind in der Praxis meist der Grund weshalb man den Vorsatz Unit Tests zu schreiben aufgibt. Wie bei allem gilt aber auch hier, dass man selber denken muss und Tipps auch kritisch hinterfragen soll.
(ISBN: 978-1-933988-27-6 | detaillierte Rezension)

 

Dependency Injection in .Net

Wendet man Unit Tests konsequent an wird der Code oft modularer. Um diese schön getrennten Teile zu einer Anwendung kombinieren zu können fallen schnell einmal die Begriffe Dependency Injection und Inversion of Control. Das Buch von Mark Seemann liefert einem eine sehr gute Einführung und auch das nötige Hintergrundwissen um eine praxistaugliche Anwendung aufzubauen.

Mir gefällt daran das nicht nur gezeigt wird worauf man achten muss sondern auch wie man merkt dass man auf dem falschen Weg ist.
(ISBN: 978-1-935182-50-4 | detaillierte Rezension)

 
 

Clean Code

Unit Tests, Refactorings und Dependency Injection sind Techniken die den Code sauberer machen. Wenn einem diese Richtung gefällt ist Clean Code von Robert C. Martin der nächste Schritt.

Sein Buch geht den Weg weiter und verbindet verschiedenste Erkenntnisse in der Software-Entwicklung der letzten Jahre zu einem Ganzen. Bei Clean Code ist es aus meiner Sicht aber besonders wichtig das man das Ziel bei all den Regeln nicht aus den Augen verliert. Verständlicher Code sollte immer vor einer in Stein gemeisselten maximalen Anzahl Zeilen für eine Methode gehen.
(ISBN: 978-0-13-235088-4 | detaillierte Rezension)

 
 

Debug It

Trotz Unit Tests wird man immer mal wieder vor einem Bug stehen. Wer gerne alternativen zu mehrstündigen Einsätzen des Debuggers hätte sollte sich dieses Buch anschauen. Paul Butcher liefert mit seinem Buch viele Tipps und Tricks damit man bei der Bugbeseitigung nicht nur im Dunkeln herum stochert.

Das Buch zeigt was die wesentlichen Schritte der Fehlerbehebung sind und worauf man nicht verzichten darf. Ein beherzigen dieser Vorschläge kann einem Stunden bei der Fehlersuche ersparen.
(ISBN: 978-1-9343-5628-9 | detaillierte Rezension)

 
 

Soweit meine Liste von Büchern die ich als „Must-Read“ bezeichne. Ich würde mich freuen zu erfahren was andere Entwickler als unverzichtbare Bücher auflisten.

 

Folgen

Erhalte jeden neuen Beitrag in deinen Posteingang.

Schließe dich 329 Followern an