Gefangen, nicht gefunden! #32

Softwareentwicklung

  • Letzte Woche war ich auf der Devoxx und das Essen dort war echt nicht gut. Der Rest dafür umso mehr.
  • Die Vorträge der Devoxx 2013; mal sehen, ob und wann die diesjährigen Vorträge online gehen.
  • Warum hab ich eigentlich immer noch nicht mit Java 8 rumgespielt?
  • Mitunter stößt man ja auf Webseiten mit echt gruseligem Webdesign. Man ist dann schnell dabei, zu behaupten, dass das aussähe wie in den 90ern. Tut es nicht. Wirklich nicht. Wirklich, wirklich, wirklich nicht. Das hat mir einer der Vorträge auf der Devoxx nochmal vor Augen geführt. Denn in den 90ern sahen die Webseiten so aus.
  • Gradle scheint echt einen Blick wert zu sein. Muss ich mir bei Gelegenheit mal angucken. Könnte eine echte Alternative zu Maven sein. Auf dem Devoxx-Vortrag wurde insbesondere die Mächtigkeit des Modells ins Feld geführt. Man kann damit deutlich mehr machen als mit Maven. Unterschiedliche Varianten (für x86 und ARM, als freie und als kostenpflichtige Version, etc.) und dann auch leicht Plugins schreiben, die sowas prüfen wie “sind in der freien Version auch nur Dependencies verwendet, die unter einer freien Lizenz stehen?” Das Modell gibt das ganz einfach her. Quasi das Maven Enforcer Plugin in einfach und mächtig. Nun braucht nicht jeder unterschiedliche Buildvarianten (und wenn möglich sollte man die eh vermeiden), aber es gibt einen weiteren Grund, der mir erwähnenswert erscheint. Maven Poms werden mitunter recht unübersichtlich. Die Syntax ist recht… textintensiv. Das ist bei Gradle anders. In der auf Groovy aufbauenden DSL hat man Möglichkeiten, Übersicht zu schaffen. Das allein wäre für mich schon Grund, mir das anzugucken.
  • »Ein Schüler kam zu seinem Meister. Er wartete lange, bis der Meister aus seiner tiefen Meditation aufgetaucht war und seinen Blick vom Minesweeper-Bildschirm gelöst hatte. “Meister”, fragte er dann,” kann ein Programm feststellen, ob der Computer, auf dem es läuft, mit dem Internet verbunden ist?”.« So beginnt eine lustige Erzählung von Marian Aldenhövel über Türstopper, Tischgrills, Sonnenblumen und warum man nicht rausfinden kann, ob man online ist. Die Geschichte trägt den Titel “Dojo 1″ und als ich vor anderthalb Ewigkeiten über die Geschichte gestolpert bin, hab ich mich gefragt, ob es auch eine Geschichte “Dojo 2″ gibt. Ich hätte zu gerne mehr so Zeug gelesen. Aber mehr gab es nicht. Keine Pseudo-Zen-Meister, die ihren Schülern die Erleuchtung bringen außer diese eine Geschichte “Dojo 1″. Schade. Einer der lustigsten Talks auf der Devoxx war “The Codeless Code” von Martijn Verburg. Und da war es wieder. Weise Zen-Meister, die in unterhaltsamen Geschichten ihre Schüler erleuchten. Keine sonderlich neuen Erkenntnisse und in manchen Fällen war ich auch durchaus anderer Meinung. Trotzdem: Ich hab mich prächtig unterhalten. Und das beste: Es gibt eine Website dazu: thecodelesscode.com

Anderes

  • Ein Schmied, ein Lastenträger und viele Schafe: In einem fernen Land lebten einmal drei Brüder. Der älteste war ein Schmied und besaß 30 Ziegen. Der mittlere war Lastträger und besaß drei Ziegen. Der jüngste schließlich sollte Hirte werden. Da dieser noch keine Ziegen hatte, bekam er von seinen Brüdern welche. Der älteste gab ihm fünf, der andere noch eine Ziege. Nach einigen Jahren starb der jüngste. In der Zwischenzeit hatten sich seine Ziegen beträchtlich vermehrt und so besaß er bei seinem Tode 132 Ziegen. Auch die Ziegen der Brüder hatten — im Gegensatz zum verstorbenen Hirten — eifrig Nachkommen gezeugt. So besaß der Schmied nun 50, der andere 10 Ziegen. Die beiden Brüder beschlossen ihr Stresslevel zu erhöhen und kamen überein, sich über das Erbe zu streiten. Wer sollte die 132 Ziegen erhalten? Da die Mutter von den ungelösten Streitereien recht bald genervt war (und sich die 132 Ziegen zwischenzeitlich in ihrem Garten stapelten), schickte sie die beiden Brüder zur Dorfversammlung, die über den Zwist beratschlagen sollten. Was ist gerecht? Wer kriegt wie viel? Alle, die das wissen wollen, dürfen sich den verlinkten Podcast anhören und dabei etwas über Gerechtigkeit, Mediation und Konfliktlösung lernen.
  • Auf der Devoxx hab ich Interstellar gesehen. Ein mutiger Film, der typisch beginnt, dann philosophisch wird, letztenendes dann aber doch den Schwanz einkneift und ein Hollywood-Ende draufpackt. Interessant sind hier neben den philosophischen Bezügen, diverse Reminiszenzen auf andere Filme. Zum einen eine optische auf Inception (ebenfalls von Christopher Nolan), zum anderen unverkennbar diverse Bezüge zu 2001: Odysse im Weltraum. Nun bin ich kein sonderlicher Fan von Kubrick-Filmen, aber 2001 ist wirklich ein Klassiker und im speziellen einer, der für Interstellar unverkennbar Pate gestanden hat. Die Wikipedia listet sogar noch mehr anklänge und Inspirationen. Trotzdem ist Interstellar nicht “Kopie” oder gar “Abklatsch” zu nennen. Er findet durchaus einen eigenen Weg und ist wirklich sehenswert.

REST ist wie Japanisch — nur anders

Von manchen Dingen gibt es einfach nur endlich viele. Von Pronomen beispielsweise. Ich, du, er, sie, es, wir, ihr, sie. Das sind die Personalpronomen. Gut, man kann diese noch deklinieren, aber dann ist auch schon Schluss. Niemand würde auf die Idee kommen, ein neues Personalpronomen zu erfinden. Es gibt einfach nur endlich viele davon. Keine Chance, das zu ändern. Anders ist es beispielsweise mit Verben. Davon entstehen ständig neue. “Simsen”, “googlen”, “chillen”, “refactoren”… Es gibt immer wieder Neologismen. Niemand würde auf die Idee kommen, zu behaupten, man hätte bereits alle Verben erfunden. Man sagt, Pronomen sind eine “Closed Word Class” und Verben sind “Open Word Class” [1]. Die Unterscheidung braucht man mitunter, um zu bestimmen, welche Wörter man in englischen Überschriften groß schreibt.

Jetzt kommt das Interessante: Dass Pronomen endlich sind und Verben nicht, ist für uns zwar einigermaßen klar und intuitiv, aber es kann auch anders sein. Ich kann zwar kein Japanisch, aber zumindest laut Wikipedia ist es dort genau umgekehrt. Dort gibt es nur endlich viele Verben, aber potenziell unendlich viele Pronomen. Beide Varianten funktionieren also offensichtlich. Zumindest gehe ich davon aus, dass sich Japaner untereinander verstehen.

Wenn ich Japanisch lernen wollte, so müsste ich also erst einmal die Denkweise der japanischen Grammatik lernen. Die romanischen und germanischen Sprachen, die wir so typischerweise kennen, funktionieren alle ähnlich. Egal ob Deutsch, Englisch, Französisch oder Italienisch: Die Vokabeln unterscheiden sich und auch die Grammatik ist anders, aber die grundlegende Denkweise: grammatische Formen, Kasus, Zeiten, Pronomen, Deklination und Konjugation… Die grundlegenden Konstruktionsbausteine der Sprachen sind sehr ähnlich. Das ist aber keine Selbstverständlichkeit. Andere Sprachen können durchaus auch anders funktionieren. Und beim Japanischen und vermutlich noch vielen anderen (asiatischen, etc.) Sprachen ist das wohl so. Unser Wissen, wie man Verben konjugiert, hilft beim Lernen von Japanisch nicht. Im Französischen konjugiert man anders als im italienischen. Aber trotzdem sind Verben immer noch von Numerus und Person abhängig. Japanisch ist hier ganz anders.

Ähnliche Effekte lassen sich auch in der Softwareentwicklung beobachten. Sprachen wie Java, C++ oder Delphi haben im Detail große Unterschiede. Aber Konzepte sind ähnlich. Und es gibt Sprachen, die vollkommen anders sind. In Haskell beispielsweise gibt es noch nichtmal Variablen.

Aber die Analogie lässt sich noch weiter treiben: Auch in Programmiersprachen und Technologien gibt es endliche und erweiterbare Strukturen — Closed Classes und Open Classes. Typische Programmiersprachen, Technologien und Architekturen gehen einen ähnlichen Weg wie das Englische (und diverse andere, wenn nicht sogar alle europäische Sprachen): Es gibt potenziell unbegrenzt viele Verben bzw. Methoden. Aber muss das so sein? Könnte man nicht… so wie im Japanischen? Kann man. Und das tut REST. Dort gibt es auch nur endlich viele Verben. Aber gucken wir uns das einmal genauer an… weiter lesen »

Die etwas andere Einführung in REST

In den letzten Jahren ist REST zu einer beliebten Schnittstellentechnologie geworden. Das hat mehrere Gründe und einer davon ist, dass REST als einfache Technologie verstanden wird. Und das ist auch richtig. Gewissermaßen. Irgendwie. Fakt ist aber auch, dass man REST erstmal lernen und verstehen muss. Bei REST gerät man leicht in Versuchung zu meinen, etwas verstanden zu haben, obwohl das nur bedingt der Fall ist. REST wirkt erstmal einfach, aber REST ist vor allem auch anders. Es liegt eine andere Denkweise zugrunde. Ich haben schon mehrere REST-Services geschrieben und ebenso auch mehrere benutzt. Nun mache ich das seit Monaten und trotzdem komme ich immer wieder in die Situation, dass ich merke, dass ich etwas falsch oder zumindest nicht ganz vollständig verstanden habe.

Einführungen in REST gibt es wie Sand am Meer. Wenn man sich davon mal ein paar angesehen hat, wird man feststellen, dass es davon eine Handvoll Arten gibt. Unterschiedliche Herangehensweisen, unterschiedliche Schwerpunkte und unterschiedliche Nützlichkeit. Folgende Arten hab ich finden können: weiter lesen »

Gefangen, nicht gefunden! #31

Software-Entwicklung

  • … heute mal nichts …

Abartig Großes

  • Wenn ich letztens ja schon mal über abartig große Zahlen philosophiert habe, muss ich auch nochmal Borges erwähnen. Vor vier Jahren hatte ich ja schonmal auf die großartige Erzählung Die Bibliothek von Babel (w) verwiesen. 2^1024 ist ja schon unvorstellbar viel. Gegen die Bibliothek von Babel ist das aber auch wieder nur lachhaft wenig. Der Text “Die Bibliothek und Gödel” zeigt das anschaulich: “[U]nser gesamtes Universum ist fast zwei Millionen Größenordnungen kleiner als die Bibliothek. Nein, Augenblick – die Betonung muss anders lauten: unser gesamtes Universum ist fast zwei Millionen Größenordnungen kleiner als die Bibliothek.” Die Originalseite ist leider nicht mehr online. Aber archive.org hilft.
  • Das Sandbuch ist ebenso lesenswert.
  • Und wenn wir schon bei Unendlichem sind, kann ich gleich noch Hilberts Hotel erwähnen. Dort gibt es (abzählbar) unendlich viele Räume. Und selbst, wenn jeder Raum belegt ist, ist immer noch Platz.
  • Die Bibliothek von Babel ist abartig groß, aber endlich. Hilberts Hotel ist unendlich groß, aber abzählbar. Auch das Sandbuch ist vermutlich abzählbar (es gibt genauso viele natürliche wie rationale Zahlen). Aber es geht noch mehr: Die Menge der reellen Zahlen ist überabzählbar. Und geht es aber noch größer? Ja es geht. Dazu muss ich einen meiner Lieblings-Wikipedia-Artikel erwähnen: Surreale Zahl. Der Artikel ist etwas ungewöhnlich für einen Lexikon-Artikel. Liest sich aber sehr gut und ist (für jemanden, der ein bisschen was von Mathe versteht) sehr leicht zu verstehen und obendrein noch kurzweilig geschrieben. Wer sehen will wie man mit Zahlen größer unendlich rechnen kann und wissen will, wann Zahlen Geburtstag haben (kein Witz!), sollte den Artikel unbedingt lesen.

Anderes

  • Die Ig-Nobel-Preise sind wieder vergeben worden
  • Längst überfälliger Fernsehtipp: Die Anstalt. Herrliche Politsatiere. Als sich Ende letzten Jahres Urban Priol und Erwin Pelzig aus dem Format verabschiedeten und Max Uthoff und Claus von Wagner übernahmen, war ich zuerst skeptisch, ob die Anstalt weiterhin so gut bleiben würde. Wie sich herausstellt, waren meine Befürchtungen absolut unbegründet. Gut wie eh und je. Absolute Empfehlung! Die September-Folge wird am nächsten Sonntag auf 3sat wiederholt und findet sich auch in der Mediathek.

2^4096

Zahlen sind abartig. Einen Forenthread nehm ich mal zum Anlass und versuch bildhaft dar zu stellen, wie groß die Zahl 2^{4096} ist. Ich kann gleich schon vorweg nehmen, dass mir das nicht wirklich gelingen wird. Aber sehen wir und das mal an:

2^{4096} das ist eine Zahl mit 1235 Dezimalstellen. Das kann sich kein Mensch vorstellen. OK, angenommen wir wollen bis dahin zählen. Wie lange würde es dauern? Natürlich machen wir das nicht selbst. Wir nehmen einen Computer dafür. Der aktuell schnellste Supercomputer ist der Tianhe-2 mit einer theoretischen Maximalleistung von 55 Petaflops, also 55 \cdot 10^{15} Rechenoperationen pro Sekunde. Da wir für das Rechenbeispiel ja keine Kostenbegrenzung haben, nehmen wir doch gleich diesen Supercomputer. Wobei. Wir sollten nicht zu geizig sein. Wir kaufen jedem der 7 Milliarden Erdenbürger einen solchen Supercomputer und lassen die alle zählen. Kostet ja nur ca. 2,7 Trillionen Dollar (das sind knapp dreißig mal so viel wie die Gesamtmenge der Schulden). Wie lange würde das dauern?

2^{4096} / (55 \cdot 10^{15}) / (7 \cdot 10^9) / 60/60/24/365 \approx 8,6 \cdot 10^{1198} Jahre

Hm… hat irgendwie nicht sonderlich geholfen. Kann sich auch noch niemand vorstellen. Wir müssen da schon größere Geschütze auffahren. Die Planck-Zeit ist die physikalisch kleinste Zeiteinheit. Kürzere Zeitabschnitte gibt es nach aktuellem Stand der Physik nicht. Das sind ca. 5,3 \cdot 10^{-44} Sekunden. Angenommen wir hätten einen Supercomputer, der innerhalb dieser Zeit einen Zählschritt machen kann. Angenommen wir hätten nicht 7 Milliarden also pro Mensch einen, sondern einen pro Stern im Universum. Oder nee, angenommen wir hätten einen dieser unvorstellbar schnellen Supercomputer pro Atom im Universum. Davon gibts ca. 10^{85} und das Universum ist ca. 13 Milliarden Jahre alt. Wie viele Universen mit je einem unmöglichen Supercomputern pro Atom bräuchte man, für die Zählerei?

2^{4096} / (5,3 \cdot 10^{44}) / 10^{85} / 60/60/24/365 / (13 \cdot 10^9) \approx 4,8 \cdot 10^{1085} Universen

Auch nicht viel besser. Jetzt muss ich mich schon echt anstrengen: Unser Universum ist ja echt leer. Das meiste da drin ist Vakuum. Langweilig. Angenommen, wir würden nun unser Universum lückenlos mit den unvorstellbar schnellen Supercomputern vollpacken. Die kleinste Längeneinheit, die unser Universum nach aktuellem Stand der Physik so kennt, ist die Planck-Länge. Das sind ca. 1,6 \cdot 10^{-35} Meter. Das sind quasi die Pixel unseres Universums. Kleiner geht nicht. Angenommen wir könnten unseren unvorstellbar schnellen Supercomputer unvorstellbar klein machen, sodass er innerhalb einer Kubik-Planck-Länge Platz hätte.

Unser Universum hat einen Durchmesser von ca. 78 Milliarden Lichtjahren. Das sind

(78 \cdot 10^9) \cdot (9,4 \cdot 10^{15}) / (1.6 \cdot 10^{-35}) \approx 1,1 \cdot 10^{62} Planck-Längen

Vereinfachend nehmen wir an, das Universum sei kugelförmig, dann ergibt sich ein Volumen von

\frac{1}{6} \pi (1,1 \cdot 10^{62})^3 \approx 6.9 \cdot 10^{185} Kubik-Planck-Längen

Wir lassen jetzt mal außen vor, dass das Universum früher kleiner war.

Wie viele Universen, bei denen jeder noch so kleine Teil einen Supercomputer enthält, der so schnell ist, wie es die Physik auch nur im entferntesten maximal zulassen würde, bräuchten wir um bis 2^{4096} zu zählen?

2^{4096} / (5,3 \cdot 10^{44}) / (6,9 \cdot 10^{185}) / 60/60/24/365 / (13 \cdot 10^9) \\ \approx 6,9 \cdot 10^{984} \text{ Supercomputer-Universen}

Ich fürchte, das ist immer noch nicht ganz vorstellbar. Nur leider gehen mir jetzt die Vergleichsgrößen aus. Was bitte hat mehr Rechenkraft als ein Universum, das ausschließlich aus Supercomputern besteht?

Das einzige, was mir noch bleibt, ist die Aufgabe kleiner zu machen. Angenommen, wir wollten “nur” bis 2^{2048} zählen. Dann wären es nur 1.4 \cdot 10^{300} Supercomputer-Universen. Bei 2^{1024} wären wir bei 1,1 \cdot 10^{60} Supercomputer-Universen. Erst wenn wir auf 830 Bit runter gehen, wären wir bei 47 Supercomputer-Universen und das können wir uns nun endlich wirklich vorstellen. Oder so.

Was lernen wir daraus? Niemand wird jemals in der Lage sein, RSA durch einen naiven Brute-Force zu knacken. Absolut. Keine. Chance. Niemals.

Ist RSA deshalb für alle Zeiten sicher? Nein. Das Problem ist, dass niemand ausschließen kann, dass nicht irgendwann ein findiger Mathematiker eine zündende Idee hat, mit der man so abartig große Zahlen effizient faktorisieren kann. Es sagt ja niemand, dass man das einzeln durchprobieren muss. Wir können ja schließlich auch mit so großen Zahlen rechnen. Nichts anderes tut unser Computer, wenn wir eine HTTPS-Seite ansurfen.

Die vielleicht interessantere Aussage: Es gibt Dinge, die können wir uns einfach nicht vorstellen, weil sie einfach so dermaßen abartig unvorstellbar sind, dass unser Geist hier kapituliert. Aber es ist ganz lustig, das fest zu stellen. ;-)

Wenn die OOP knifflig wird

Irgendwie komme ich kaum zu posten. Unter anderen wartet ein Artikel zu REST (wobei das vermutlich mehrere werden) in der Pipeline. Jetzt sind aber erstmal die Delphi-Tage dran. Und bevor sich das hier gar nicht mehr mache, kurz und bündig:

  • Die diesjährigen Delphi-Tage in Bonn haben mir wieder gut gefallen.
  • Mit Delphi hab ich mittlerweile eigentlich kaum noch etwas zu tun. Aber es war 10-jähriges Jubiläum der Delphi-Tage und ich hab Martin ein wenig vertreten dürfen. Es waren meine siebten Delphi-Tage und vielleicht meine letzten. Aber man soll ja nie nie sagen…
  • Die Begrüßung verlief ungeplanterweise etwas improvisierter als von mir angedacht. Aber ich denke, es haben sich trotzdem alle begrüßt gefühlt.
  • Mein Vortrag war insgesamt ganz gut besucht und ich bin im Großen und Ganzen auch zufrieden. Das ein oder andere hätte ich besser machen können, aber ich fands in Ordnung.
  • Ich hab vermutlich etwas zu oft Fragen ins Publikum gegeben. Ich sollte lernen, das gezielter einzusetzen.
  • Vermutlich hat man gemerkt, dass ich deutlich weniger Zeit in Folien und Vortragsvorbereitung gesteckt habe, als in den letzten Jahren. Die Folien waren sehr codelastig und an der ein oder anderen Stelle gabs kleine Fehler. Und er Vortrag lief nicht überall ganz rund: “Hab ich hierzu ne Folie? Äh ne hab ich nicht”.
  • Danke an die aufmerksamen Zuhörer, die mich auf das ein oder andere Problem hingewiesen haben. Ich soweit ich mich daran erinnern konnte, hab ich die Folien entsprechend korrigiert.
  • Ich hab das Gefühl, mein Problem mit dem “äh” ist besser geworden. Ob dem so ist?
  • Die Beispiele kamen, nach dem, was ich so gehört habe, nicht ganz so gut rüber, wie erhofft. Ich von meiner Seite aus, war mit ihnen eigentlich sogar recht zufrieden. Trotz der kurzen Vorbereitungszeit hab ich nur an einer Stelle auf ein Foobar-Beispiel ausweichen müssen (Dafür war das auch besonders schlecht ;-) ). Woran die anderen Beispiele gekrankt haben, weiß ich noch nicht so genau.
  • Feedback ist wie immer jederzeit herzlich willkommen.

Gefangen, nicht gefunden! #30

Informatik

Anderes — Heute: Lustiges

  • Vor einiger Zeit ist es mir mal passiert, dass ich auf meiner Fernbedienung die falschen Tasten gedrückt hab. Und dann war da so Zeug. An der Aufmachung konnte man erkennen, dass es sich wohl um Sketche handeln sollte. Offensichtlich hatten die Macher aber vergessen, sie lustig zu machen. Mir ist dann eingefallen, dass mir sowas schonmal aufgefallen ist. Ich muss es aber verdrängt haben. Und auch jetzt kann ich mich nicht mehr erinnern, was es war, das sich da auf meinen Schirm verirrt hat. Ist wohl auch besser so. Nicht, dass ich etwas gegen Nonsens hätte. Aber wenn, dann bitte richtig. Einer, der Nonsens kann, ist Jan Philipp Zymny. Beispiele:

    Achtung! Kann Lachkrämpfe auslösen.

Was Bud Spencer nicht kann

Bud Spencer ist ein dicker, bärtiger Haudrauf, der viele Prügelfilme gemacht hat und jetzt über 80 ist. Ja. Aber er war auch Olympionik. Seine Schwimmerkarriere ist ja hinlänglich bekannt, aber in der Wikipedia kann man nachlesen, dass Carlo Pedersoli, wie der Kerl gebürtig heißt, noch viel mehr kann. So ist er wohl auch Komponist, hat Jura studiert und mehrere Erfindungen patentiert. Erstaunlich. Was kann der Kerl eigentlich nicht?

*

Vor anderthalb Ewigkeiten hab ich mal ein Interview mit ihm gesehen. Dort hat er behauptet, er könne eigentlich nicht schauspielern. Die ganzen Rollen, die er verkörperte, seien alle so ähnlich, weil es jeweils nur er selbst sei, der da zu sehen ist. Das sei nicht geschauspielert. Ich mag die Bud-Spencer-Filme. Zumindest einige davon. Aber es stimmt natürlich: Bud Spencer ist immer der selbe.

Konstruieren wir aber mal etwas, das Bud Spencer niemals könnte. Etwas, das einen echten Schauspieler erfordert. Wir brauchen also etwas, bei dem ein Schauspieler viele Rollen übernehmen muss. Beispielsweise etwas über Klone weiter lesen »

Gefangen, nicht gefunden! #29

Informatik

  • Hab mir letztens Bootstrap angesehen. Und jQuery. Und ich muss sagen: Ich hab selten Frameworks gesehen, die so leicht zu lernen sind und so wenige Ecken haben. Echt hübsch.
  • Ich weiß wieder, warum ich PHP nicht mag. 1, 2
  • Es gibt Sprachen die sind weit verbreitet. Das heißt aber nicht, dass diese immer toll sind. Im Gegenteil. Ich hab eher den Eindruck, dass die am weitesten verbreiteten Sprachen maximal Durchschnittsniveau erreichen. Und dann entstehen Sprachen, die von diesen Sprachen dann die Ecken ausbügeln wollen. Groovy ist so ein Beispiel. Oder LESS. Letztens hab ich mir CoffeeScript angesehen. Auch ganz interessant.
  • JEE ohne Container: Dropwizard
  • Hübsche Doku für REST-Services: Swagger Sehr empfehlenswert obwohl es im Detail noch ein paar Ecken hat.
  • Wenn wir grad bei REST sind: HTTP-Entscheidungs-Diagramm. Etwas unübersichtlich, aber trotzdem hilfreich.
  • Und noch was zu REST: restapitutorial.com
  • Kontroverse Position: Delete All Unit Tests. Meine Meinung dazu: Nein. Konkreter: So mit das wichtigste, was ich in letzter Zeit über Unit Tests gelernt hab, ist, dass eine “Unit” nicht notwendigerweise eine Klasse ist. Meistens eher nicht. Und wenn man das beherzigt, ist es auch gar nicht mehr so aufwendig die Tests zu pflegen.
  • Bisher noch nicht so extrem erlebt, aber trotzdem interessant: Why your previous developer was terrible
    And why your current one seems so amazing
  • It Is Possible to Do Object-Oriented Programming in Java: Schon wieder ein Vortrag über OOP? *gähn* Gähn? Wirklich?
    • Die drei Prinzipien der OOP: Ignoranz, Gleichgültigkeit und Egoismus.
    • Sprachen und Technologien, die sich besser für OOP eignen als Java: C, COM und JavaScript
    • Was Barbara Liskov wirklich sagen wollte
    • ==> Ein provokanter Titel, ein bisschen Bekanntes, einiges Lohnenswertes und ein paar gute Denkanstöße.
  • Defensive API Evolution With Java Interfaces: Unterm Strich sowas wie “API Evolution Patterns”.

Anderes

  • Eine hübsche junge Frau, Vollwaise, überfordert, zwielichtig, steht am Bahnhof. Eine andere hübsche junge Frau, wortlos, benebelt, äußerlich identisch zur ersten, wirft sich vor den Zug. Die erstgenannte schlüpft in die Rolle der nun toten. Und ab da wird die Sache kompliziert. Aktenkoffer, durchwühlte Hotelzimmer, die dubiosen Kollegen von der Polizei, die eigene Vergangenheit, die neue eigene Vergangenheit… Ach ja: Und da sind noch ein paar andere mit ebenfalls identischem Äußeren, aber nicht minder rätselhaften Motiven. Orphan Black hat etwas Besonderes. Eine intelligente Thrillerserie, die einem im Kopf bleibt.

Kurz mal was übers Testen

Das mit dem Testen ist eine merkwürdige Sache. Meine Beobachtungen zu dem Thema sehen in Etwa folgendermaßen aus:

  • Testen die ungeliebte Tätigkeit. Häufig ist das Testen eine ungeliebte Tätigkeit. Sie wird als langweilig, eintönig und unproduktiv empfunden. Viele schreiben lieber Produktivcode als Testcode. Als ich in der Uni das Softwareentwicklungsprojekt betreut hatte, musst ich meine Studenten fast schon dazu zwingen, JUnit-tests zu schreiben (und das war explizit Teil der Aufgabenstellung). Die besten Gruppen hatten eine gefühlte Testabdeckung knapp über “kaum nennenswert”.
  • Testen an der Uni. An der Uni wird auch das Testen thematisiert. Aber wie… Was lernt man da? Hauptsächlich Begriffe. Blackbox, Whitebox, Testtreiber, Dummy, Unittests, Integrationstest, … Man lernt einzelne Details über Testabdeckung, Path Coverage, Statement Coverage, Branch Coverade, MCDC Coverage, … Man lernt was über statistische Testverfahren, Äquivalenzklassen und Grenzwertanalyse. Was aber lernt man nicht? Testen. Aber Zeug wie Mocking-Frameworks und TDD wurden gar nicht behandelt. Und was schon gar nicht Teil des Studium war, ist explizit mal zu lernen, wie man Code testbar macht. Testen muss man lernen wie ein Handwerk. Und wenn man mal ein gewissen Gefühl dafür bekommen hat, verliert es auch ganz schnell seinen Schrecken. Denn Testen ist eigentlich alles andere als langweilig und unproduktiv.
  • Testen als Spezialqualifikation. Es gibt die einen Tests, die man selbst schreibt. Manchmal hat man aber auch den Luxus separate Tester zu haben. Das sind Leute, die die abartigsten Fehlerfälle finden und ein Gespür dafür haben, was noch alles schiefgehen könnte. Wenn man so jemanden hat, ist das ein echter Mehrwert. Automatisierte Unit-Tests sind zwar immer noch unersetzbar, aber durchaus sinnvoll ergänzbar.
  • Testen und Dokumentation. Wasserfall-Tester müssen Berge von Doku schreiben. Das ist auch das, was man so in der Uni gelehrt bekommt. Testkonzepte, Statusreports, Testspezifikationen, Testergebnisse… Alles wird dokumentiert. Das passt schön in die Wasserfall-Denkweise und mag in Fällen, in denen es um sicherheitskritische Software (Autos, Flugzeuge, Computertomographen, …) geht, aus rechtlichen Gründen angebracht sein. Allerdings frag ich mich manchmal: Welchen zusätzlichen Mehrwert könnten unsere Tester liefern, wenn sie nicht die Hälfte ihrer Zeit mit Papierkram verplempern würden?
  • Tests haben. Einer meiner Profs stellte immer den wissenschaftlich nachgewiesenen Effektivitätsvorteil von Inspektionen gegenüber Tests heraus. Was aber meist untern Tisch fällt, ist die Feststellung, dass das Punkt bei automatisierten Tests ein ganz anderer ist. Es kommt nicht darauf an, Tests zu schreiben. Das Tolle ist, sie zu haben. Wenn man sie einmal geschrieben hat, kann man sie regelmäßig fast ohne Aufwand neu ausführen. Und das ist wirklich ein *riesiger* Vorteil. Man kann so viel entspannter refactorn. Bestehende Funktionalität geht nicht so einfach kaputt, weil man Tests hat, die das prüfen. Nötige Verbesserungen werden nicht aus Angst, etwas kaputt zu machen, verschlafen… Viele Effekte, die ungemein positiv für die Qualität sind.
  • Testen als Handwerk. Wie gesagt: Testen ist ein Handwerk, das man erlernen muss. Eines, das man in der Uni nicht lernt. Auch, wenn ich schon seit über zwölf Jahren programmiere, richtig testen hab ich erst in den letzten Monaten gelernt. Und ich hab das Gefühl, dass ich noch mehr zu lernen habe und noch mehr lernen werde.

Letztens hab ich zwei Artikel gelesen, die meinem Verständnis für Tests wieder einen Schub nach vorne verpasst haben. Und das sind die beiden:

Da steht viel Interessantes drin, aber ich will mal eines hervorheben, was ich besonders wichtig finde: Einer der Fehler bzw. ein Missverständnis, dem auch ich aufgesessen bin, ist dass es zu jeder Klasse eine Test-Klasse geben müsse. Ich hab sogar mal nen Test geschrieben, der geprüft hat, ob zu jeder Klasse ne Testklasse und zu jeder Methode ne Testmethode existiert. Und das ist Blödsinn. Der Effekt der dann auftritt, ist, dass jegliches Refactoring ein analoges Refactoring der Tests nach sich zieht. Benenne ich eine Methode um, muss ich auch alle zugehörigen Testmethoden umbenennen. Teile ich eine Klasse, muss ich auch den eine neue Testklasse schreiben, etc. Das ist ein Hemmschuh, der eigentlich nicht da sein sollte. Vielmehr sollten Tests orthogonal zum Produktivcode sein. Tests sollten sich an der Fachlichkeit orientieren, nicht an der technischen Struktur des realisierenden Codes. Es gibt also quasi pro fachlicher Anforderung eine Testklasse.

Ich hab das mal bei meinem ArgumentsParser ausprobiert und das ist tatsächlich ein enormer Fortschritt.

powered by WordPress | QuickLaTeX | WordPress Themes