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.

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 »

powered by WordPress | QuickLaTeX | WordPress Themes