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.

Hobbits, Drachen und HFR

Letztens hab ich den Hobbit gesehen. Also den zweiten Teil. Zum ersten hab ich ja letztes Jahr schon was geschrieben. Hier nun aber mein Resümee zu Teil 2: Der Plot bleibt im Vergleich zu Herr der Ringe immer noch etwas zurück. Das ist sicherlich darin begründet, dass die Romanvorlage ein schmales Kinderbuch ist. Während Herr der Ringe zahlreiche Handlungsstränge aufweist und eine facettenreiche Geschichte in allen Details ausmalt, ist der Plot beim Hobbit vergleichsweise einfach und linear.

Das fiel insbesondere beim ersten Teil auf, wo es kaum Nebenhandlung gab und sich alles um die Gruppe der Zwergenabenteurer drehte. “Die Einöde von Smaug” ist hier schon deutlich besser. Insbesondere die zweite Hälfte des Filmes ist deutlich spannender. Die Gruppe wird auseinander gerissen und es tun sich drei bis vier parallele Handlungen auf. Gandalf verlässt die Gruppe um die Sache mit dem “Nekromanten” zu untersuchen, und drei der Zwerge bleiben in der Stadt zurück, während der Rest zum Erebor weiter zieht. Daneben mischen noch ein paar Elben, darunter Legolas, mit. Mehrere Handlungsstränge haben den Vorteil, dass man wunderbar zwischen ihnen hin und her wechseln kann. Insbesondere in der zweiten Hälfte wird das nun endlich genutzt, was dem Film sehr gut tut.

Insgesamt ist so die Handlung dramaturgisch da angekommen, wo man sie auch erwartet. Sonderlich viele überraschende Wendungen gibt es zwar nicht. Somit hebt der Plot den Hobbit also sicherlich nicht aus der Masse der Filme heraus. Aber dies ist auch kein negative Punkt mehr, bei sich der Film vor dem Durchschnitt verstecken müsste.

An Charakteren mangelt es aufgrund der Zwergenschar ja nicht und im Vergleich zum ersten Teil bieten sich hier auch mehr Möglichkeiten, das zu nutzen. Daneben gibt es noch ein paar Menschen und Elben, die auch ganz gut funktionieren und den Film bereichern. Viel gelobt wird auch immer die Szene, in der Bilbo dem Drachen Smaug den Arkenstein ablugsen will. Und das kann ich nur unterstreichen. Visuell ist der Film eh spitze und natürlich ist wieder Tolkiens Welt der eigentlich Star. Insgesamt ein guter Film, besser als der erste, aber immer noch nicht ganz wie Herr der Ringe. Den dritten und letzten Teil, werde ich mir sicher auch ansehen.

Während ich den Hobbit letztes Jahr in “normalem” 3D gesehen hab, war es diesmal 3D HFR. Und ich muss sagen: Das hier ist der erste Film, bei dem ich das Gefühl hatte, dass 3D auch einen echten Mehrwert bietet. Ob das an HFR liegt, weiß ich nicht, aber während in quasi allen anderen Filmen, die ich bisher in 3D gesehen hab, die dritte Dimension quasi nur einen gelegentlichen Effekt wert war, sah man hier dem gesamten Film die dritte Dimension an. Das sollte man sich echt mal ansehen.

Einziger Wermutstropfen: In einigen wenigen Szenen hat man das Gefühl, dass etwas nicht stimmt. Beispielsweise sieht man das am Anfang im Gasthaus “Zum tänzelnden Pony”. Dort gibt es eine Dialogszene mit Thorin und Gandalf. In normalen 2D-Filmen stellt man Dialoge häufig so dar, dass man den Hinterkopf oder die Schulter eines Gesprächspartners an der linken Seite sieht, während das Gegenüber im Zentrum des Bildes (und im Fokus) steht. So erhält man quasi die Perspektive eines Gesprächspartners und je nachdem, wer gerade spricht, wird zwischen den beiden Sprechenden hin und her geschnitten. Das ist ganz typisch für Filmdialoge, weil es sehr gut die Gesprächssituation abbildet. Ein zweites Beispiel aus dem Gasthaus: Eine Gasthausszene wird lebendiger, wenn einfach mal jemand kurz durchs Bild huscht. Es gibt einem das Gefühl, dass man mitten drin steht. In 2D funktioniert das ganz gut, weil es einen Näher an die Handlung bringt. Hier funktioniert es aber nicht so gut, weil der ganze Film optisch schon recht realistisch wirkt. Durch die fehlende Tiefenschärfe führen einem solche Szenen im wahrsten Sinne vor Augen, dass man doch in einem Kino sitzt und eben nicht auf einer groben Holzbank in Bree. Technisch ist Tiefenschärfe bisher nicht zu erzeugen. Deshalb müssen Filmemacher hier, meiner Meinung nach, Mittel und Wege finden, wie man Dialoge vielleicht filmisch anders darstellt. Wie? Ich weiß nicht. Ich bin Softwareentwickler, kein Regisseur. Dennoch: Der Hobbit (oder HFR?) markiert für mich einen Meilenstein, was 3D-Kino anbelangt.

Clean Code und das Modellprinzip

Drei Monate nach meinem letzten Post zu Clean Code hier nun wieder einer. Und wieder grab ich in den Krümeln und tu so als könnt ich alles besser. Heute behaupte ich mal, ich könnte einen besseren Parser für Kommandozeilenargumente schreiben.

In Kapitel 14 “Successive Refinement” zeigt Bob Martin sehr detailliert (auf über 50 Seiten) wie man Code schrittweise refactort. Das Kapitel ist wirklich, wirklich lesenswert, weil es die einzelnen Schritte beschreibt und zeigt, wie sich der Code verändert. Das Schwere oder eher: das, was man beim Refactoring nämlich üben muss, ist, wie man alles so kleinschrittig macht, dass die Tests immer durchlaufen. Schnell passiert es, dass man sein System an diversen Stellen ändert und es dann erstmal für Stunden nicht funktioniert, vielleicht nichtmal durch den Compiler geht. Die Kunst ist es nun, die Schritte so zu wählen, dass eben genau das nicht passiert. Mir passiert es immer noch, dass ich Code kaputtändere und ihn dann erst wieder zusammenflicken muss. Dieses Kapitel hat mir geholfen, dass das nun seltener passiert, wenngleich noch ein wenig mehr üben muss.

Aber ich wollte ja mal wieder ein wenig besserwisserisch auftreten und an Uncle Bobs Code rumkritteln. Wenngleich ich bewundere, wie der Mann refactort; das Endergebnis gefällt mir nicht so. Gucken wir uns erstmal an, wie seine Musterlösung denn aussieht: weiter lesen »

Gefangen, nicht gefunden! #28

Informatik

  • Tolle Präsentation zum Thema OO: Ein Name ein name und ist kein String
  • Die wohl beste Definition für verteilte Systeme ist die folgende: “A distributed system is one in which the failure of a computer you didn’t even know existed can render your own computer unusable.” So wahr! Diese Definition ist bekannt als Leslie Lamports Definition des Begriffs. Per Zufall bin ich auf den Ursprung der Definition gestoßen: distribution.
  • Wie man Versionsnummern aufbauen sollte.
  • Technical Debt ist ja schon weithin bekannt. Letztens hab ich noch von einer anderen Art der “Schulden” in der Softwareentwicklung gelesen: Competence Debt. Sehr gutes Konzept!
  • Some thoughts on build tools and application builds. Interessanter Artikel. Die Kernthese des Artikels ist sicherlich diskussionswürdig. Aber das Bemerkenswerteste daran ist eigentlich etwas anderes. Nämlich die folgende Überlegung: “[T]he natural evolution of mastering programming skills: 1. Can I do this? 2. Can I do this more easily? 3. Can I do this more elegantly? 4. Can I not do this?”
  • Lustige Info: Theoretisch darf der Localpart einer E-Mail-Adresse Sonderzeichen enthalten. Selbst ein @-Zeichen. So etwas muss dann excapet werden.
  • Gute Beispiele sind viel Arbeit. Sehr viel Arbeit. Wer mal ein wirklich gut ausgearbeitetes Beispiel sehen will, sollte sich den Vortrag Practical Refactoring ansehen. Und alle anderen am besten auch. Denn genau das, was der Titel ausdrückt, wird in knapp zwei Stunden gezeigt. Refactoring an einem praktischen Beispiel. Keine Spielzeug-Beispiele. Kein Trivialkram. Und trotzdem durchweg verständlich und nachvollziehbar.

Anderes

  • Kurzresümee zu den Doctor Who Specials:
    • The Night of the Doctor: Eine Mini-Episode, die mit der Regeneration vom 8. in den “War Doctor”, eine Lücke füllt. Durchaus sehenswert. Insbesondere Paul McGann ist toll in seiner Rolle. Aber: Inhaltlich bringt die Episode die Verbitterung des Doctors nicht rüber. Er hat viele Menschen sterben sehen. Und aufgrund des Todes einer einzelnen Person, die er kaum gekannt hat, entscheidet er sich, ein Krieger zu werden und seine komplette Lebensweise übern Haufen zu werfen? Das nehm ich ihm nicht ab. Besser man hätte den Doctor in den Wirren des Krieges gezeigt anstatt auf einem einsamen, kargen Planeten. Schade. BTW: Bester Satz: “Will it hurt?”” in Anspielung auf John Hurt. Klasse!
    • The Day of the Doctor: Gut aber nicht überragend. Verschiedene Zeitlinien. So etwas finde ich immer spannend. Und hier ist es ganz gut umgesetzt. Diverse Referenzen auf die vergangen 50 Jahre Doctor Who. Wie zu erwarten prima. Optisch hat mir insbesondere die Hütte auf dem Wüstenplaneten gefallen. Sehr schön. Auf der anderen Seite gab es diverse Szenen, die offensichtlich nur für die Schauwerte da waren. Beispielsweise die Szene zu Beginn mit der Tardis am Hubschrauber. Man hätte darauf verzichten und Zeit und Budget besser für den Plot nutzen können. Insbesondere wird nur behauptet, dass die Time Lords so schlimm wie die Daleks geworden waren. Es wird nie gezeigt und die Folgen des Time Wars sind kaum zu erahnen. Wovon ich leider auch etwas enttäuscht war, ist der “War Doctor”. Vielleicht auch, weil ich falsche Vorstellungen hatte. Aber ich hätte mir einen vom Krieg, vom “Time War”, gezeichneten, verbitterten, müden, vielleicht mürrischen Doctor gewünscht. Das hätte ein toller Kontrast zu den anderen beiden beiden Inkarnationen gegeben. Leider sind die meisten Dialoge mit dem War Doctor lustige Szenen geworden. Da wurde meines Erachtens viel Potenzial verschenkt. Leider. Insgesamt natürlich trotzdem eine tolle Folge. Aber lange nicht so gut, wie sie hätte sein können.
    • The Time of the Doctor: Auch diese Folge hat mich nicht ganz überzeugt. Richtig toll fand ich “Handles” den Cyberman-Kopf. Hier hätte ich mir eine Mini-Episode als Prequel gewünscht, die dessen Vorgeschichte beleuchtet. Die Nacktheits-Geschichte ist albern, aber verglichen mit Strax aus dem vorangegangenen Weihnachts-Special echt lahm. Stattdessen hätte die Sache mit Handles weiter ausgebaut werden können. Da wäre Potenzial gewesen. zwischendurch gibt es einzelne Szenen, die mit einer Erzählerstimme als Voice Over realisiert wurden. Hier wirkt die Geschichte fast wie ein Märchen und das ist auch gut gelungen. Passt zu einer Weihnachts-Folge. Das hätte man weiter ausbauen können. Ansonsten ist der Plot insgesamt etwas zu “gewollt” und insbesondere die Silence sind nur Beiwerk und nicht richtig genutzt. Obwohl diese ja eigentlich zentraler Teil der Story waren. Oder hätten sein sollen. Auf der anderen Seite sind die Weeping Angles total unnötig gewesen. Verschenkte Zeit. Also nicht die gesamte Episode. Die Angles-Szene. Insgesamt mittelmäßig. Schade.

#SaveTheDay

Was trennt John F. Kennedy von zeitreisenden Aliens? Ein Tag.

Stellt euch folgende Situation vor: Ihr habt eine tolle Idee. Aber ihr habt kein Geld. Stellt euch vor, es geht darum, eine Science-Fiction-Fernsehserie zu erschaffen. Aber Raumschiffe dürfen nicht vorkommen. Zu teuer. Aussichtslos, möchte man meinen. Aber Not macht erfinderisch. Das Geld reicht zwar nicht für ein Raumschiff, aber irgendwo kann man eine blaue Polizeitelefonzelle auftreiben. Kurzerhand spendiert man dem nicht realisierbaren Zeitreiseraumschiff einen kaputten Tarnmechanismus, der dafür sorgt, dass es immer aussieht wie eine britische Polizeitelefonzelle. Am 23. November 1963, genau einen Tag nach der Ermordung John F. Kennedys, geht die neue Serie im britischen Fernsehen auf Sendung: Doctor Who war geboren.

Seit dem bereist also ein zeitreisender Außerirdischer mit zwei Herzen, der immer nur “Doctor” genannt wird und niemals seinen Namen verrät, die Weltgeschichte, das Universum, fremde Welten… Begleitet wird er dabei von wechselnden “Companions”, also Freunden oder “Begleitern”.

Ein paar Jahre später hat man mit der Serie das nächste Problem. weiter lesen »

Principle Languages—How to Make and Communicate Design Decisions

Remember remember the fifth of November… I certainly do remember the fifth of November—which was last Tuesday. I don’t remember it because of the Gunpowder Plot, certainly not because of the nursery rhyme and at least not today because of V for Vendetta. Rather I once more gave my talk on principle languages. This time as a webcast to Sydney, Australia.

This is also a premiere. This is not the first time for me to present the topic. Neither it is my first webcast or my first presentation in English. But this time I have a recording. And here it is: weiter lesen »

Gefangen, nicht gefunden! #27

Informatik

  • Tolles Eclipse-Plugin: Infinitest: Bei jeder Änderung werden im Hintergrund automatisch die betroffenen (und eben nur die) UnitTests ausgeführt. Man bekommt sofort Feedback. Manche mögen befürchten, dass das zur Performancebremse wird. Aber: Man kann konfigurieren, dass Integrationstests (und das sind ja die, die dauern) nicht ausgeführt werden. Wenn man seine UnitTests richtig schreibt, sind die i.d.R. performancetechnisch problemlos, zumal ja eh oft nur eine Test-Klasse betroffen ist.
  • Mockito ist im übrigen auch toll. Da kommt kein anderes Mocking-Framework ran, das ich bisher gesehen hab.

Anderes

  • Continuum: Eine low-budget SciFi-Serie. Vollständig zu sehen auf YouTube. Bisher 2 Staffeln à 9 Episoden zu je ca. 5 Minuten (ja, das ist kurz; low-budget eben). Das Ganze hat gute und weniger gute Stellen, aber es taugt ganz gut um sich die Zeit zu vertreiben. Da hat es schon viel schlechteres ins Fernsehen und Kino geschafft.
  • Eine Serie, die aus einer gänzlich anderen Richtung kommt, ist Under the Dome. Romanvorlage von Steven King, tonnenweise Spezialeffekte, etc. Eigentlich nicht so 100%ig mein Genre, aber die Serie ist wirklich gut. Worum geht es? Über der Kleinstadt Chester’s Mill erscheint urplötzlich eine unsichtbare, unüberwindliche, unzerstörbare Kuppel. Alle Einwohner sind eingeschlossen und niemand weiß, warum. Was unter der Kuppel in den folgenden Wochen und Monaten geschieht, wird wird aus Sicht von mehr oder weniger acht Personen erzählt. Das erzeugt einen dichten, abwechslungsreichen und spannenden Plot. Bei genauerer Überlegung wird man aber feststellen, dass die Idee eigentlich noch viel mehr Potenzial liefert. Dieses Potenzial bleibt ungenutzt, da die Handlung dann noch viel komplizierter würde. Es gibt eine Menge Charaktere, auch abseits der 8 (+-) Hautpersonen. Und eine Kleinstadt kann innerhalb von Wochen oder gar Monaten der Isolation auf *sehr* viele Dumme Gedanken kommen. Eigentlich würde ich für so ein Szenario mit viel mehr Chaos rechnen. Laut Wikipedia spielt im Roman die Handlung auch innerhalb von kaum mehr als einer Woche. Erst die Serie dehnt hier die Zeit. Außerdem ist in der Wikipedia zu lesen, dass wohl eine zweite Staffel geplant ist, die über das Buch hinaus gehen soll. Ob das eine gute Idee ist? Ich weiß nicht. Mal sehen. Ich bin gespannt.
  • Wenn wir gerade bei Serien sind: Doctor Who wird jetzt am 23. November 50 Jahre alt. Von der BBC geplant sind: Eine 75min-Jubiläumsfolge und eine 90min-Dokumentation.
  • Jessica Hische über Design, Lettering und Arbeit neben der Arbeit: Unterhaltsam, aufschlussreich und den Block übern Tellerrand wert.
  • Wie konjugiert sich eigentlich refactorn? In der Softwareentwicklung benutzen wir naturgemäß viele englische Fachbegriffe. Die Frage ist hier, wie man damit umgeht und das ist nicht ganz einfach. Das ist mit ein Grund, warum ich meine Masterarbeit auf Englisch geschrieben habe. Da stellt sich die Frage nach dem “Denglisch” nicht. Man könnte jetzt einfach gnadenlos alles übersetzen. Man könnte also “umgestalten” sagen. Mit dem Effekt, dass niemand weiß, wovon man redet. Manche deutsche Begriffe haben nicht eingebürgert und sind verständlich. “Bindung” beispielsweise für “cohesion”. Oft ist das aber nicht der Fall. Wenn man den Begriff beibehalten will, muss man ihn dann aber mit deutscher Grammatik konjugieren, weil englische nicht funktioniert. “Wir sollten das refactor” ist Müll. “Alice refactors den Code” auch. Also konjugieren wir deutsch: Ich refactor(e), du refactorst, er/sie/es refactort, wir refactor(e)n, ihr refactort, sie refactor(e)n. Was man häufig liest ist sowas wie “Sie refactored den Code”. Und ich muss zugeben, dass ich sowas auch schon gemacht habe. Es erscheint intuitiv, da wir die Form “refactored” kennen und etwas schreiben wollen, das sich genauso anhört. Grammatikalisch ist das aber unsinnig. Sobald man darüber nachdenkt (was ich gerade mal getan habe), merkt man, dass es “refactort” heißen muss. So werde ich das in Zukunft also schreiben.
  • Die Ig-Nobelpreise sind wieder verliehen worden. Unter den diesjährigen Preisträgern: “Alberto Minetti, Yuri Ivanenko, Germana Cappellini, Nadia Dominici, and Francesco Lacquaniti, for discovering that some people would be physically capable of running across the surface of a pond — if those people and that pond were on the moon.”

powered by WordPress | QuickLaTeX | WordPress Themes