Vision Mobile hat seinen Enterprise App Developer Atlas online gestellt. Ganz nett um sich einen Überblick über verfügbare Tools und Frameworks zu verschaffen.
Im folgenden Artikel zeige ich ein einfaches Idiom das dem C#-Compiler ermöglicht auch Erweiterungen auf anonymen Lambdas zu verstehen. So lassen sich UnitTests kompakter und verständlicher schreiben.
Bernd Krehoff hat einen Erlebnisbericht zur vergangenen Manage Agile 2013 im bor!s gloger Blog veröffentlicht und nennt dabei die aus seiner Sicht interessantesten Vorträge.
Ich finde insbesondere den Keynote-Vortrag Beyond IT - Beyond Agile? von Ulf Brandes sehr inspirierend.
SonarQube ermittelt die im Projekt angehäuften technischen Schulden (Technical Debt) anhand des SQALE Models (Whitepaper, pdf). Doch was genau sind eigentlich technische Schulden? Und wann werden diese fällig?
Ist normalerweise nicht meine Baustelle, aber vielleicht ist das was für unsere C++/Linux-Ritter: Laut Ankündigung ist mit KDevelop 4.6 die Debugger-Unterstützung für den GDB verbessert worden (Stichwort Breakpoints). Außerdem wird jetzt neben make und CMake auch Ninja als Buildsystem unterstützt. Ninja soll extrem schnelle Builds ermöglichen was sich insbesondere für größere Projekte bezahlt macht. Das motivierende Projekt für Ninja ist der Chrome Browser dessen Build
Docker is an open-source engine that automates the deployment of any application as a lightweight, portable, self-sufficient container that will run virtually anywhere.
Der Gedanke Container anstelle isolierter VMs zu nutzen hat was.
In Reactive Programming – vom Hype zum Praxiseinsatz gibt Joachim Hofer ein Beispiel wie man um "reactive" zu werden in Scala eine synchrone API schrittweise in eine asynchrone API umstrukturieren kann; und das ohne Abstieg in die sog. "Callback-Hölle".
Der Bezug auf das Reactive Manifesto kommt dabei etwas kurz, wie ich finde.
Auch kommt mir die Schachtelung der Futures/Monaden in Scala (und später vielleicht Java) vergleichsweise umständlich vor. Die Verwendung von async/await und der TPL ab C# 5 ist dagegen purer Zucker was Les- und Nachvollzieh-barkeit betrifft. Ab VS2013 sollen diese Einflüsse sich auch auf den Debugger ausgewirkt haben. Der von Microsoft diesbezüglich getriebene Aufwand ist zugegebenermaßen schwer zu erreichen, geschweige denn zu toppen!
Der Blogpost No Experience Required! stellt die Ergebnisse von empirischen Studien zusammen die insgesamt über 30 Jahre abdecken. Erstaunliches Ergebnis: Es konnte absolut gar keine Korrelation zwischen der Erfahrenheit eines Programmierers (in Jahren) und der von ihm produzierten Codequalität festgestellt werden. Das stimmt nachdenklich, oder?
Im Blog Accelerated Development gibt Dalip Mahal mit Inspections are not Optional eine sehr schöne Motivation um Anforderungsdefiziten mit Code Inspection zu begegnen. Fazit: Je später die Inspektion desto teurer, d.h. es ist ratsam diese so früh wie möglich im Entwicklungsprozess einzuplanen. Ja genau: Idealerweise ganz an den Anfang.
Die stattfindende zunehmende Hinwendung zur Praxis der Buildautomatisierung ist sehr zu bergüßen. Ein diesbzgl. Kernaspekt ist dass bei Änderungen am produktiven Code-Repository sehr schnelles Feedback über den Zustand des Gesamtsystems möglicht ist; angefangen bei der grundlegenden Frage: "lässt sich der Code noch kompilieren?".
Die zunehmende Verwendung freier, moderner, web-basierte Services ist insgesamt zu begrüßen. Beispiele hierfür sind: DokuWiki, Bug Tracking, vSphere Web Client (VMWare im Browser), WordPress (Blog), RedMine (Project Management), Jenkins (Build Server), GitBlit (SCM), Sonar (Code Quality) und ggf. noch einige Andere die mir gerade nicht einfallen oder die ich nicht kenne.
Über eine Meldung auf Heise DeveloperHeute bin ich auf Klocwork Insight aufmerksam geworden. Dabei handelt es sich um ein Werkzeug zur automatischen Analyse und Refactoring von C++ Code. Das Demo-Video welches typische Handgriffe in der Visual Studio Integration zeigt erinnert stark an Jetbrains ReSharper (für .NET). Kein anderes Tool hat mein Arbeiten so stark verändert. Daher könnte ich mir gut vorstellen dass das Insight vielleicht was für unsere C++ Ritter ist. Was meint ihr?
Hosted on Martin Fowlers own Thoughtworks Advisory Board. Worum gehts?
The ThoughtWorks Technology Advisory Board is a group of senior technology leaders within ThoughtWorks. They produce the ThoughtWorks Technology Radar to help decision makers understand emerging technologies and trends that affect the market today. This group meets regularly to discuss the global technology strategy for ThoughtWorks and the technology trends that significantly impact our industry.
Die parallel 2014 ruft nach Beiträgen. Eine gute Gelegenheit seine eigene Fachkompetenz auf den Prüfstand zu stellen. Welche Techniken zur Parallelprogrammierung verwendet ihr? Und wie verhalten sich diese zu aktuellen Techniken?
Der Heise Developer Artikel Persistenz mit Event Sourcing beschreibt das Konzept welchem u.a. doppelte Buchhaltung, SCMs und Oracle Streams zugrunde liegt. Anwendungsmöglichkeiten sehe ich da viele.
Scrum und das Aber beschreibt die typisch verhaltenen Reaktionen auf den Scrum-Erstkontakt: Durch Scrum wird auf einmal viel aufgedeckt was vorher kaschiert wurde. Das wirkt in der Regel verunsichernd wenn nicht gleichzeitig für mehr Vertrauen im Team gesorgt wird. Das deckt sich mit Sebastians und meinen Erfahrungen. Bernd Krehoff resümiert:
Allerdings ist es dann blauäugig, das Rahmenwerk (Scrum) für das Scheitern verantwortlich zu machen und zu behaupten: Scrum passt hier einfach nicht zu uns. Ehrlicherweise müsste die Antwort lauten: Wir möchten uns nicht so oft ins Gesicht schauen müssen.
Caching ist prinzipiell cool. Allerdings kann ein Cache auch Probleme "kaschieren". Benötigt ein Projekt-Build ein Package schaut NuGet erst in seinen lokalen Package Cache und lädt es erst vom Server herunter wenn es dort nicht zu finden ist. Super Sache. Für Entwicklungs-Builds will man die Version nicht immer hochdrehen sondern verwendet stattdessen gemäß Semantic Versioning die sog. pre-release Syntax. Lokal ist das kein Problem, man weiss ja dass der lokale Package Cache nutzerspezifisch unter %LocalAppData%\NuGet\Cache zu finden ist. Also einfach Package-Datei aus dem Cache-Verzeichnis löschen und weiter geht's! Aber wo ist der Package Cache auf einem Build-Server?
With New Programming Jargon Jeff Atwood added all the modern programming metaphors to the Jargon File. With Reptile Codei would like to propose one myself.
In "The Science of Discworld (1)" [1], chapter Mammals on the Make, biologist Jack Cohen elaborates on of one of science's remarkable misjudgments. At this time, the concept of DNA was often referred to as Blueprint of life. And it still is today:
It seemed to be a natural conclusion to approximate a species' level of evolution or its complexity by the length of its DNA strand, i.e. the longer the DNA code the more sophisticated the species.
This intuitively made sense. By analogy, the engineering blueprint of Jumbo Jet is a lot longer than that of a simple paraglider.
The embarassing result: Empirically, the DNA of a frog is much longer than the human DNA. Confusion took hold. Could it be that God considered simple reptiles higher than his flagship creation, man?
Later, it was found that human DNA is so much shorter because it is organized better[2].
Put simply, frog DNA contains a variety of contingency plans for environmental changes that accumulated in the course of evolution as lots of code patchwork. For instance,
if temperature between -14° und -7° do this, else if between -7° and 0° do that, else if ... etc.
Warmbloods like man escape this complexity through the elegant statement
set internal temperature to 36°.
Especially for developers, i find this view very accessible, because they very well know about metrics like Lines of Code (LoC) oder Cyclomatic Complexity (McCabe) from their own experience [3].
Hitting such code, you could probably say in Mr.Spock voice:
Fascinating! This component is likely to be hard to maintain: The average cyclomatic complexity of their methods differ with 57.63 significantly from that of the World Code Health Organization (WCHO) which recommended a maximum 20.
Compared to Mr. Spock just stating
Woah! Reptile Code!
really hits home and feels more natural.
Footnotes:
As a teenager i loved reading Terry Prattchet Discworld-novels, especially the series Science of Discworld which were written together with co-authors Ian Stewart und Jack Cohen and which uniquely prescribes the wonderful cosmology of Roundworld and is amongst the best introductory works on evolution after Richard Dawkins.
Later, it turned out that DNA-Code at times can "reorganize" and shift to a whole new organizational level of abstraction. It seems, evolution knows the concept of "refactoring" but she is a lot more cautious on eliminating "dead code" (perhaps of the deep coupling of SCM and the code itself).
In general, long codes with a high McCabe-Complexity are a lot harder to maintaint, cf.:
Ein Teilaspekt des neuen Build Server ist dass er sich im Von Neumannschen Sinne selbst reproduzieren kann. Nun ja, nicht ganz alleine - Man muss noch den Knopf "Jetzt bauen" auf dem entsprechenden Job: Neuer Jenkins oder einen Post-Commit-Hook auf dem scripts-Repository aufsetzen.
In On Writing Interfaces Well gibt Jonas Downey Tips zum Schreiben guter Fragen und Antwort-Optionen in Oberflächen. In seinem Team gibt es eigene Commits nur für das Feilen and den Formulierungen mit dem Tag Wordsmithing.
Asynchronen Code zu testen ist schwierig. Umso leichter haben es Bugs sich dort einzurichten wo man schlecht mit dem Besen hinkommt. Ein kurzer Bericht aus dem Projektalltag.
Im Rahmen eines Projektes hatten wir für einen REST-Adapter die Verwendung des auf Groovy basierenden Web-MVC-Framework Grails erwogen, dies aber dann verworfen. Der vorgeschobene Grund war Zeit und Budget im Griff zu behalten. Der ehrliche Grund ist wohl eher das Eingeständnis von Grails keine Ahnung zu haben und daher nicht vergleichend einschätzen zu können wie aufwendig eine Grails-Implementierung gegenüber Groovy ist.
Im dritten Teil seiner Online-Kolumne Source Reflection #3: Über spekulierende Softwareentwickler reflektiert Jörg Friedrich über den spekulativen Charakter von Entwurfs- und Programmier-Entscheidungen in der Softwareentwicklung. Er stellt fest, dass
[Prognosen] umso unsicherer [werden], desto mehr es auf die Handlungen von Menschen ankommt. "Woher soll ich wissen, welche Anforderungen ich an die Software haben werde, bevor ich ausprobiert habe, was ich mit ihr machen kann?" – so könnte man eine alte Psychologenweisheit auf den Softwareentwicklungsprozess anwenden.
Fazit: Wir brauchen weniger Anforderungs- und dafür mehr Unsicherheits-Management. Könnte er da Recht haben?
Gerade gestern hat mich ein Artikel unseres alten Scrum-Trainers Markus Gärtner erneut auf die Cyclomatic Complexity-Metrik aufmerksam gemacht. Diese ist besonders praktisch weil sie zu einer Methode direkt sagt wie viele Unit Tests man dafür haben sollte.
Auch in aktuellen Sprints haben wir viele Fehler erst wieder sehr spät beim manuellen Testen bemerkt, sodass wir Schwierigkeiten hatten die angedachten Szenarios bis zum Termin überhaupt einmal durchzuspielen. Die meisten der dazugehörigen Bugs waren schwer zu finden da sie sich gut in teils sehr langen Methoden mit vielen if-else-Verschachtelungen versteckten (d.h. hohe Cyclomatic Complexity). Die entsprechenden Code-Pfade waren vom Entwickler wohl kaum - wenn überhaupt - durchlaufen worden.
Grund genug für mich den Dachboden meiner grauen Zellen zu durchforsten.
Nach einer Meldung von heise Developer ist die BPM-Notation jetzt als ISO-Standard akezeptiert. Grund genug sich einmal damit auseinanderzusetzen, oder?
Beispiel eines Geschäftsprozessdiagramms, erstellt mit der BPMN. Eigentlich ganz einfach, oder?
Mehr zufällig als beabsichtigt bin ich beim Update meiner Paint.NET-Version auf das Multicore JIT-Feature in .NET 4.5 aufmerksam geworden. Rick Brewster, seines Zeichens Autor von Paint.Net, hat auf seinem Blog erklärt warum Paint.Net so schnell startet. Schließlich sind managed-Applikationen auch unter .NET dafür bekannt sich beim Startup gegenüber nativen Anwendungen etwas Zeit zu lassen.
Jenkins unterstützt den Master/Slave-Betrieb sodass die Arbeitslast auf verschiedene Rechner (Slaves) verteilt werden kann.
Für einen Windows-basierten Slave ist es am komfortabelsten den Jenkins Slave vom Master als Dienst starten zu lassen. Technisch verwendet Jenkins da WMI + DCOM (sic!) was auf Anhieb meist nicht direkt klappt.
Als Server für geographische haben wir gute Erfahrungen mit dem Open Source Projekt GeoServer gemacht. Hier zwei praxisnahe Referenzen für Integration, Wartung und Tuning des Servers:
What's in a good commit? & What's in a good commit? - Timo Mihaljov and Jaco Pretorius discuss best practices for what should go in a commit when developing, with Timo giving the initial list of 5 best practices and Jaco responding to these sharing his opinions.
Lesenswert.
There's only one rule when it comes to committing commented-out code ;-)
Die Scrum Alliance hat einen neuen Bericht The State of Scrum: Benchmarks & Guidelines veröffentlicht, der zeigt wo und warum Scrum praktiziert wird. Dazu wurden knapp 500 Fachleute in mehr als 70 Ländern befragt. Vertretene Branchen sind neben IT auch Bildung, Finanzen, Regierung, Gesundheitswesen, Telekommunikation und einige andere.
Mittlerweile gibt es mehr Alternativen eigene http-basierte NuGet-Repositories zu realisieren als durch die Kombination Windows-Server + IIS + ASP.NET. Scott Hanselman nennt Einige davon in seinem Blog. Das sind u.a:
MyGet - NuGet as a service in der Cloud (kostenpflichtig)
Der Einsatz von Memen in Vorträgen ist in den letzten Jahren so populär geworden, dass es mittlerweile entsprechende Websites für Mem-Generatoren gibt.
Dabei handelt es sich um Bilder mit ggf. kurzem Text die den Kern einer Idee (das Mem) besonder klar und prägnant transportieren. Ein gutes Beispiel für einen Vortrag der Meme einsetzt ist z.B. Managing Modular Software for your NuGet, C++ and Java Development von Baruch Sadogursky, bzw. Fred Simon, Chief Architect von JFrog, der Firma die den populären Maven-Repository-Server Artifactory entwickelt haben.
Die im obigen Vortrag verwendeten Meme-Generatoren sind u.a:
Crosspost Heise Developer: Collab.Net hat die kostenlose Desktop-Anwendung GitEye veröffentlicht. Sie soll einfach zu bedienen sein und basiert ihrem Aussehen nach auf dem Eclipse-Framework. Wer vom Mergen mit egit genervt ist und Eclipse gewohnt ist, für den könnte GitEye etwas sein.
Git-Repositories sind leichtgewichtig, d.h. sie lassen sich einfach und schnell anlegen, leicht kopieren und erzeugen insgesamt einfach wenig Overhead. Wichtig dabei: Halte deine Git-Repos klein, unabhängig und handhabbar, dann hast du mehr davon.
Ging letzte Woche schon rum: jQuery-menu-aim ist ein jQuery-Plugin für mega snappy dropdown menu items. Die Idee ist einfach: Statt eines Delays testet man ob sich der MouseCursor-Pfad innerhalb eines Dreiecks zu den child items befindet. Die Idee ist wahrscheinlich uralt und schon mehrere Male neu erfunden worden, zuletzt von Amazon. Es fühlt sich einfach mega responsive an und ich finde es einfach cool. Aber da bin ich wohl nicht der Einzige.
The future of work is already here. Customers are adopting disruptive technologies faster than your company can adapt. When your customers are delighted, they can amplify your message in ways that were never before possible. But when your company's performance runs short of what you've promised, customers can seize control of your brand message, spreading their disappointment and frustration faster than you can keep up.
Durch eine einfache Erweiterung des Thrift-HTTP-Servers um CORS können nun JavaScript-Callbacks zu lokalen Desktopanwendungen gelangen. Das entsprechende MetaThrift-Beispiel kann jetzt mithilfe der folgenden Links einfach nachvollzogen werden:
Während der Ausstattung eines Demo-Client mit diversen unserer Software-Anteile bin ich auf das Problem gestossen, dass das aktuelle Visual Studio (VS2012) keine Visual Studio Setup Projects (.vdproj) mehr unterstützt. Tatsächlich hat Microsoft den Support dafür eingestellt, VS2010 ist die letzte unterstützende Version.
Daher meine Bitte an alle Kollegen: Neue Installer auf Basis des WiX Toolset bauen und alte Installer auf WiX migrieren.
Achtung für diejenigen die mit Jenkins und Git arbeiten: Mit der aktuellen Version (git-client.1.0.4) wurde vom Command Line Interface (CLI) auf JGit umgestellt. Eigentlich eine gute Idee, leider gibt es jedoch noch Probleme (Workarounds finden sich auch dort).
In Backend-lastigen Projekten hat die Anwendung des von Michael Nygard geprägten Circuit Breaker Pattern (Blitzableiter) viel zur Stabilität beigetragen.
Dabei handelt es sich um ein relativ neues Pattern mit der folgenden Kernidee:
The essence of the pattern is that when one of your dependencies stops responding, you need to stop calling it for a little while. A file system that has exhausted its operation queue is not going to recover while you keep hammering it with new requests. A remote web service is not going to come back any faster if you keep opening new TCP connections and mindlessly waiting for the 30 second timeout. Worse yet, if your application normally expects that web service to respond in 100ms, suddenly starting to block for 30s is likely to deteriorate the performance of your own application and trigger a cascading failure.
Für .NET habe ich das sehr leichtgewichtige NuGet-Package Reliability Patterns von Nygard selbst verwendet.
In Java gibt es mehrere Implementierungen, eine davon z.B. in der JRugged library. Diese waren jedoch für unseren Geschmack so schwergewichtig und überladen, dass wir das einfache Pattern gerade selbst implementiert haben.
Die typische Nutzung verwendet einen Decorator mit CircuitBreaker als Proxy für die Real-Implementierung.
Ich habe zum ersten Mal vom CircuitBreaker-Pattern aus dem Buch Dependency Injection with .NET von Mark Seemann gehört. Lesen bildet also nicht nur.
Im Rahmen eines Kundenprojekts habe ich Erfahrungen mit der Datenzugriffsbibliothek Simple.Data gesammelt. What's the deal? Tadaa: der Ansatz von Simple.Data setzt auf Konventionen sowie dynamic und kommt dadurch ohne boilerplate code oder vorgenerierte ORM-Modellen aus. Mein Eindruck: It just works! Genial einfach in der Benutzung und sauber programmiert.
Für Entwickler die hauptsächlich mit statisch typisierten Sprachen wie Java oder C# arbeiten, ist der Umgang mit einer voll dynamischen API allerdings ungewohnt, bricht dann doch die gewohnt komfortable Begleitung durch Intellisense, Resharper und den Compiler weg.
Die meisten (ich auch) tendieren dann dazu, ein Repository als Abstraktionsebene einzuschieben.
Mark Rendle, Autor von Simple.Data, hat sich dazu seine eigenen Gedanken gemacht und beschreibt in seinem Post HOWTO: Dial up the static on Simple.Data einen zu TypeScript ähnlichen Ansatz mithilfe der Duck Casting-Bibliothek ImpromptuInterface. Stark!
In Java ist u.a. Hibernate (JBoss) oder die Java Persistence API recht bekannt. In .NET gibt es unter vielen anderen das Entity Framework (Microsoft) oder NHibernate. In Ruby ist ActiveRecord (Ruby on Rails) verbreitet. In Python verwenden viele das OR-Mapping von Django (Web-Entwickler natürlich) und auch PHP kennt einige Mapper. In JavaScript greift man nicht direkt auf die Datenbank zu (Ausnahme vielleicht node.js, da server-seitig), sondern typischerweise über Ajax und bildet das zurückgelieferte JSON meist auf die Oberfläche ab (z.B. mit Knockout).
In anderen Sprachen wie Flex, Perl oder C++ war OR-Mapping dagegen bislang kein sehr verbreitetes Konzept. Mit der Veröffentlichung von ODB (Code Synthesis) als Open Source ändert sich das jetzt. Das Mapping von Klassen und Feldern auf Tabellen, Spalten geschieht analog zu anderen Sprachen (Annotations, Attributes) über #pragma db. Generische Query-Klassen sorgen für gewohnt komfortable Abfragemöglichkeiten. Abhängigkeiten zu anderen Frameworks gibt es nicht (Qt und boost support gibt es). Unterstützt werden die wichtigsten Datenbanken (z.Zt. Oracle, MSSql, PostgreSQL, MySql und SQLite). Neben GPL gibt es noch andere Lizenzmodelle. Meiner Meinung ein wertvoller Zuwachs für die C++ Welt.
Brian Harry, TFS product manager, hat in seinem Blog angekündigt, dass TFS bald Git repositories hosten kann. Der Team Foundation Service kann das schon jetzt (30.01.2013). Außerdem wird VS2012 SP2 native Git-Unterstützung haben.
