Content tagged Clojure

Benutzt du Clojure in der Arbeit?

posted on

Wenn ich auf ein Meetup gehe, lautet die erste Frage immer „was machst du so?“. Beginnt das typische Gespräch hingegen mit „benutzt du Clojure in der Arbeit?”, bin ich auf der :clojureD in Berlin gelandet.

Am 24. Februar war ich auf meiner ersten Clojure-Konferenz. Nach einem Treffen der Munich Clojurians war das erst mein zweites Zusammentreffen mit anderen, die der Begeisterung dieser Programmiersprache erlegen sind.

Es war ein tolles Erlebnis. Auf keiner Konferenz bisher hatte ich so den Eindruck, dass alle einfach ein rießen Interesse an Softwareentwicklung haben und alle dafür brennen neue Gedankenanstöße aufzunehmen. Keiner der einfach nur seine Arbeit erledigt bekommen will. Ich hatte das Gefühl wirklich unter den Besten zu sein, die es in meinem Beruf gibt.

Wie schade, dass anscheinend trotzdem das Potential der Sprache so oft noch nicht genutzt wird. Obwohl ich im Cognicast oft genug auch schon die andere Seite gehört habe: Firmen, die darüber klagen zu wenige Clojure-Entwickler zu finden. Die Antwort auf der :clojureD war leider öfters: „nein, in der Arbeit nutze ich kein Clojure“.

Worin ich mich 2016 verbessere: Clojure und Softwaretests

posted on

Mein einer Vorsatz für dieses Jahr ist es die Philosophie von Clojure zu denken. Seit 2011 spiele ich mit Lisp und 2014 hatte ich meinen ersten Kontakt zu Clojure, einem der Dialekte von Lisp. Der andere ist, ich möchte meine Erfahrungen mit Softwaretests ausbauen. Bisher hatte ich vor allem an meinen Fähigkeiten mit Unit-Tests gearbeitet und hierfür meinen Stil gefunden. Jetzt will ich automatische Integrationstests in mein Standardrepertoire von Entwicklungstechniken aufnehmen.

Jetzt im Mai?

Du kennst es bestimmt: an Silvester hast du gute Vorsätze für das neue Jahr und ab Neujahr ist es schwer diese einzuhalten. Die letzten Jahre bin ich gut damit gefahren mir nichts konkretes vorzunehmen, stattdessen ist mein Ziel etwas neues zu erreichen. Das heißt Anfang des Jahres bin ich noch auf der Suche was in diesem Moment das richtige für mich ist. Ich probiere verschiedene Dinge und experimentiere damit. Merke ich, dass es nicht das richtige ist, so muss ich nicht mit meinem Vorsatz brechen, sondern mache mich auf die Suche nach etwas anderem.

Für dieses Jahr bin mir inzwischen sicher, dass ein großes Thema für mich ist, dass ich in den beiden genannten Gebieten mehr Erfahrung sammeln will.

Lisp/Clojure

Web Deelopment with Clojure

Funktionale Programmierung fasziniert mich seitdem ich im ersten Semester an der TUM davon gehört habe. Auch wenn mein täglicher Berufsalltag objektorientiert ist, schreibe ich in diesem Rahmen funktional: Seiteneffekte wo nicht nötig vermeiden, bevorzugt verwende ich unveränderliche Value-Objekte und genieße wie ich in Java8 mit Streams ausdrücken kann was ich mit Daten machen möchte und nicht sagen muss, wie das geschehen soll.

Zu kämpfen habe ich noch damit herauszufinden wie ich ohne Klassen meine Programme auf höherer Ebene möglichst sauber strukturiere. Ich merke den Vorsprung, den die objektorientierte Denkweise in meinem Kopf hat: was ich in Java schreibe hat einfach noch die schönere Globalstruktur, es gelingt mir besser zusammen zu halten was zusammen gehört („high cohesion“) und getrennte Konzepte getrennt zu halten („loose coupling“). Ich denke, es liegt daran, dass ich schon deutlich mehr gute Beispiele für OOP als für funktionale Programme gesehen habe.

Clojure Applied

Vorwärts gebracht haben mich hier dieses Jahr bisher vorallem die Bücher Web Development with Clojure von Dmitri Sotnikov und Michael Swaine am Beispiel von Webanwendungen und Clojure Applied von Alex Miller und Ben Vandgrift für allgemeine Clojure-Programme. Nun muss ich in der Praxis probieren was ich gelesen habe. Hierzu schreibe ich ein Tool das ich brauche gerade als Clojure-Webanwendung. Mal schauen wie ich mit dem Ergebnis zufrieden sein werde …

Service- und Akzeptanztests

Nachdem ich meine Muster für Unittests mit jUnit, Hamcrest und Mockito gefunden habe arbeite ich jetzt daran die richtigen Werkzeuge und Muster für Tests auf höherer Ebene zu finden. Schon vor einiger Zeit hatte ich mit Fit einige Versuche unternommen. Inzwischen ist dieses Werkzeug Teil von FitNesse geworden. Tests werden hierbei in HTML-Dateien geschrieben. Diese können wahlweise zum Beispiel auch in Word oder einem Wiki erstellt werden. „Richtig“ fühlt sich das für mich bisher aber nicht an. Seit ein paar Monaten experimentiere ich stattdessen mit Cucumber. Die Tests werden dabei in (einigermaßen) natürlicher Sprache geschrieben und in einem Textdokument abgelegt. Für mich als Entwickler fühlt sich das sehr viel besser an.

In Fit wird damit argumentiert, dass ein Kunde/Auftraggeber besser in der Lage sei eine Spezifikation zu editieren, wenn er dies in seiner gewohnten Textverarbeitung tun kann. Ich denke aber, dass es immer ein Wunsch bleiben wird, dass man als Entwicklungsteam eine fertige Spezifikation erhält. Es ist wichtiger ein Tool in der Hand zu haben, das es mir ermöglicht mit dem Kunden/Auftraggeber zusammen dies zu erarbeiten. Das ist aber genauso in einem Texteditor möglich. Wichtig ist vielmehr, dass der Kunde ein Verständnis dafür hat, was niedergeschrieben wird. Hierfür eigent sich Gherkin, die Sprache von Cucumber, ausgezeichnet: die Spezifikation kann er als normalen Text lesen.


Unless otherwise credited all material Creative Commons License by Matthias Wimmer