Pferdesachen und Nicht-Pferdesachen

Irgendwie ist das ganz erstaunlich mit Pferden.

Ich meine, je mehr Zeit man mit Pferden verbringt, desto mehr wirken ausgesprochene Nicht-Pferdesachen unwirklicher, unsinniger und unwichtiger.

Softwareentwicklung im Team zum Beispiel, und all die damit verbundenen Probleme mit Kommunikation, Egos, unterschiedlichen Herangehensweisen, undsoweiter, undsofort.

Eine Sache kann nur schwer noch mehr Nicht-Pferdesache sein.

Oder ob iAndroid besser ist als GoogleOS. Paradebeispiel für eine ganz oberkrasse Nicht-Pferdesache.

Unmittelbar nach einem Besuch bei den Pferden heute mittag habe ich die ganzen nervigen Nicht-Pferdesachen, mit denen ich mich in den letzten Wochen immer wieder auseinandersetzen musste, beinahe vollkommen vergessen.

Ein schöner Zustand.

SKPH0401

Hoffen wir, er hält noch ein bisschen an.

Warten auf die Revolution

Sebastian C. Müller und Thomas Fritz von der Fakultät für Informatik der Universität Zürich haben, so ist meine leise Hoffnung, etwas ganz Großartiges getan.

Und zwar haben sie ein Papier geschrieben, das hoffentlich irgendwann in der Zukunft zur Revolution führen wird. In diesem Paper schlagen sie – grob zusammengefasst – vor, bei Softwareentwicklern per Biometrie (sprich, EKG, EEG & Co.) zu messen, ob sie gerade vernünftige Arbeit machen oder nicht.

Bis jetzt war der Prozess ja langsam und schleichend.

Leute, die nicht programmieren können oder wollen, suchen seit gefühlten Jahrhunderten nach immer neuen Wegen, um Leute, die programmieren können und wollen, effizienter und kostengünstiger Geld für sie verdienen zu lassen. Da gibt’s dann alle paar Jahre eine neue Methodik, die alle bitteschön ganz toll zu finden haben. Soweit, so bekannt.

Aber Softwareentwickler-Milchkühe mit Elektroden an Hirn und Händen zu verdrahten, um dann per Biometrie rauszukriegen ob sie gerade ordnungsgemäß leckere Früchte am High Performance Tree erschaffen oder eher in nem extended Biometrics-Peer-Review nochmal so richtig rangenommen werden müssen, das hat eine ganz neue Qualität.

Ich hoffe, da wird weiter geforscht. Denn irgendwann muss das zwangsweise dazu führen, dass die Leute sich erheben, ihre Fesseln abstreifen, und die Revolution ausrufen.

Na, wie wär’s?

(bin mir übrigens nicht sicher, ob ich über solche Dinge hier wirklich weiter schreiben möchte. Da hab ich am Wochenende so schöne Musik gemacht, und dann sowas…)

Into This

Wer zu den Menschen gehört, die in den Jahren 2007 und 2008 eine Live-Performance von Botany Bay besucht haben, der wird sich vielleicht erinnern, dass wir zu Beginn unserer Konzerte ein leises und fragiles Instrumental zu spielen pflegten.

Später dann, als uns klar wurde, dass man mit leisen und fragilen Stücken ab einer gewissen Publikumsgrösse kein Konzert beginnen sollte (man hört sich selbst kaum, und Aufmerksamkeit bekommt man auch nur schwer), ersetzten wir „Into This“ (so der Name des Instrumentals) durch „Moron Island“ (ein Stück von unserer 2008er EP, und so ungefähr das Allerlauteste, was wir bis dahin von uns gegeben hatten, was dann auch effizient dafür sorgte, dass die Aufmerksamkeit zu Beginn des Gigs garantiert auf unserer Seite war).

Vor ein paar Wochen hatte ich das Vergnügen, vor ausgewählten Publikum ein paar Stücke zum Besten zu geben… nur Klavier und ich, und aus irgendeiner Laune spielte ich als „Into This“ am Anfang.

Ziemlich viele Erinnerungen, die daran hängen.

Die meisten davon ziemlich schön.

Vorgestern hatte ich dann ein bisschen Zeit, mein Recording-Equipment abzustauben und eine Demo-Version von „Into This“ mal aufzunehmen, leicht erweitert und ausgebaut.

Und da es höchste Zeit wird, die „Schall“-Kategorie hier mal einzuweihen… was läge näher, als eben jenes Stück, mit dem wir einst unsere Konzerte begannen?

Hier ist es.

Stephans Hypothese der mehrfachen Unvollständigkeit

Hat ein System X den gleichermaßen offensichtlichen wie immanenten Fehler Y, so finden sich innerhalb einer Zeit t garantiert n Menschen, die vollkommen überzeugt verkünden: „Blödsinn! Das hat mit X überhaupt nix zu tun! Wer X so verwendet, dass Y auftritt, der macht es einfach falsch“.

Wobei n umso größer wird, desto offensichtlicher und nerviger Y ist, und t sich mit der Marktdurchdringung von X asymptotisch verkürzt.

Wollt ich nur mal gesagt haben.

 

In memoriam Michael Reichmann

Michael Reichmann, † 18.5.2016

Ich habe Michael Reichmann nur einmal kurz in Person gesehen, das muss auf der Photokina 2008 gewesen sein.

Virtuell allerdings begleitete er mich, seitdem ich mich mit (Digital-)fotografie beschäftige, über seine Veröffentlichungen auf seiner Webseite, Luminous Landscape.

Seine intelligente, gewitzte und leidenschaftliche Art und Weise, über Fotografie, Techniken und Equipment zu schreiben, werden mir fehlen.

Wo andere es zur Tugend erheben, möglichst viele Amazon-Affiliate-Links in vermeintlichen Produkttests unterzubringen, schaffte er es, selbst in Equipment-Besprechungen sowohl mit als auch über Sehen, Seele und Gefühl zu schreiben. Die Welt ist leerer ohne ihn.

Mach es gut, Michael.

Der lange Weg zu LuaHack

Ich bin mir ja immer noch nicht sicher, ob und wie ich Programmier-Topics auf diesem Blog behandeln soll.

Bislang habe ich diese Seite von mir in der Öffentlichkeit eher nicht so gezeigt¹, die Musik war (und ist btw immer noch) wesentlich wichtiger, und über das Programmieren muss ich dank Scrum & Co. eh schon mehr reden als mir eigentlich lieb ist.

Und selbst, wenn ich dazu übergehen sollte, hier über Programmierthemen zu fabulieren… in welcher Tiefe soll ich es tun? Eher generell, so dass es jeder versteht? Oder bis zur Zeitkomplexitäts-Analyse eines Shadow-Casting-Algorithmus? Wer liest hier überhaupt mit? Wer ist interessiert daran?

Trotzdem ist es natürlich eine wichtige Seite von mir, und ich programmiere durchaus nicht ’nur‘, um das Geld zum Musik machen zu verdienen, sondern auch zum Spaß. Gerade (bzw. seit längerer Zeit schon) bastle ich beispielsweise an einem Spiel, das in gleich zweifacher Hinsicht ein Novum sein dürfte.

Denn erstens handelt es sich um das meines Wissens erste rogue-like, das nativ für RISC OS entwickelt wird.

Und zweitens ist das Teil vollständig in Lua implementiert.

Wie es zu alledem – RISC OS, Lua und Roguelikes – kam, das ist eine recht interessante, lange und komplexe Geschichte, für die ich etwas weiter ausholen muss… tja, und ich denke, das mache ich einfach mal, und schaue, was die Reaktionen so sind, und dann schauen wir wie es weiter geht.

Thanks For The Memories

Den besten Brotjob² meines Lebens hatte ich nämlich 2012-2013.

Und zwar war ich zu dieser Zeit CTO bei einer feinen, kleinen Mobile-Spiele-Schmiede. Und weil wir sehr wenige Leute (sprich: sieben) waren, hatte ich gleichzeitig eine sehr aktive Rolle in der Entwicklung (sprich: sicher 80% unseres Codes kamen von mir, trotz des hochtrabenden Titels³).

Was daran so toll war?

Nun, zum einen durfte ich mir meine Zeit frei einteilen und von zuhause aus arbeiten. Und, ja, tatsächlich, das funktionierte, und zwar sehr gut.

Leider befindet sich Deutschland im Bereich Home Office noch immer im finstersten Mittelalter, und vielerorts herrscht mit gespenstischer Selbstverständlichkeit die Idee vor, wenn man nur genug Leute zusammen in ein lärmiges Büro sperrt und sie von morgens bis abends mit Meetings und Spielchen malträtiert, dann werden sie sich schon irgendwann ganz arg dolle zusammengehörig fühlen und mehr und bessere Arbeit machen als wenn man ihnen die individuelle Freiheit und Ruhe ließe, die sie als Geistesarbeiter eventuell benötigen könnten.

Mein damaliger Chef, dem ich bis in alle Ewigkeit dankbar sein werde, hatte die Weitsicht, das anders anzugehen, und das zahlte sich aus.

Obwohl 2012 ein Jahr der derben Schicksalsschläge war (mein Vater erlitt im August einen Schlaganfall und starb schließlich drei Monate später an den Folgen, während meine Mutter alles unternahm, um ihm schnell nachfolgen zu können), entstanden in dieser Zeit drei neue Spiele – zwei davon mit einer von Grund auf neu & selbst entwickelten Sprite-Engine, ein anderes unter einem mir bis dahin nicht bekannten Framework (Corona) mit einer mir bis dahin nicht bekannten Programmiersprache (Lua) –, sowie zwei Prototypen für ein weiteres Spiel und eine sehr hübsche Audio-App, ausserdem koordinierte ich unsere externen Mitarbeiter, unsere Praktikanten und alles was sonst noch so alles daran hing. Und das alles ohne Probleme, und ohne, dass jemals Dinge unerledigt liegen blieben.

Tja, und zum anderen entwickle ich eh gerne Spiele, einfach so, zum Spaß, und zur Entspannung. Tatsächlich hatte ich schon während meines vorherigen Brotjobs damit begonnen, nach Feierabend wild drauf los zu entwickeln, als Ausgleich für alles, was bei meinem damaligen Brötchengeber falsch lief (s.o.)

Als mir also die Gelegenheit geboten wurde, das vollends zu meinem Beruf zu machen, griff ich ohne zu zögern zu.

Wolken am Horizont

Ich schreibe das alles in der Vergangenheit, weil es leider nicht hielt. Wir hatten uns und den Spielemarkt überschätzt… zwar hatten wir ein bis zwei kleine Hits gelandet, aber das reichte auf Dauer nicht, um uns über Wasser zu halten. Die Werbeeinnahmen brachen links und rechts ein, und als Gegenmaßnahme begingen wir den (auch heute noch überaus beliebten) Fehler, unsere Apps so derartig brutal mit Werbebannern und Interstitials zuzuscheißen, dass unsere User verärgert gingen und nie wieder kamen.

Herbst 2012 sah es schon relativ finster aus, und wir mussten uns überlegen, was wir tun konnten, um Kosten einzusparen und vielleicht doch noch das Ruder rumzureissen (was ein schöner Wortwitz ist, denn bis dahin hatten wir rundenbasierte Spiele mit Piraten-Thema entwickelt).

Die erste Stelle (und letzten Endes die einzige), an der wir den Rotstift ansetzten, war die native App-Entwicklung. Bis dahin hatte ich nativ für iOS entwickelt. Wir wollten aber den Android-Markt mitnehmen und wir mussten uns schnell bewegen… Wir könnten viel schneller und kostengünstiger sein, so unsere damalige Überlegung, wenn wir unsere Apps fortan mit einem hybriden Framework entwickeln würden.

Wir entschieden uns für Corona, ein Crossplatform-Framework für Android und iOS, um unsere bestehenden Spiele zu portieren und unser nächstes (und letztes) Spiel anzugehen.

Unglücklicherweise war uns da eine  ganz große und wichtige Wahrheit noch nicht bewusst, nämlich:

Crossplatform-Anwendungsentwicklung ist Unfug.

Bevor jetzt alle auf mich losgehen: Klar, man muss das einschränken. Es spricht überhaupt nichts dagegen, ein Spiel, das keinerlei speziellen Features und Eigenheiten der Zielplattform prominent verwendet, beispielsweise in Unity3D zu entwickeln.

Unser nächstes Spiel aber sollte eine rundenbasierte Foto-Rate-App werden, in der man ein Teil eines Gegenstandes mit der Handykamera aufnahm und zurechtschnitt und ein zufällig ausgewählter Mitspieler raten musste, worum es sich handelte. Eine Art Mischung aus Kreuzworträtsel, Instagram, Memory und Chatroulette… und als solches eine sehr nette Idee. Gleichzeitig konnte man noch mit seinen Mitspielern chatten und Extras kaufen und so weiter und so fort.

Nun haben sowohl Android-User als auch (vermutlich noch in stärkerem Maße) iOS-User gewisse Erwartungen daran, wie sich eine Software anzufühlen hat. Insbesondere wenn es um Dinge geht wie Fotos aufzunehmen und zurechtzuschneiden, zwischen verschiedenen Views hin- und her zu navigieren und mit andren Usern zu chatten, dann erwartet der Benutzer eine schon gelernte Art der Bedienung, und er erwartet (mit Fug und Recht, wie ich betonen möchte), ebendiese Bedienung in einer flüssigen und robusten UI tätigen zu können.

Und damit nahm das Unglück nahm seinen Lauf, denn bei Corona fühlte sich nichts flüssig und robust an, weder auf Anwender- noch auf Entwicklerseite. Um vernünftig mit großen Fotos hantieren zu können musste ich eine native Erweiterung schreiben, ebenso für alles an Client-Server-Kommunikation, was über das simple Senden von JSON-Daten hinausging (und der Google Blobstore erwartet nunmal multipart binaries, was ebenfalls sein gutes Recht ist). Im Endeffekt schrieb ich so viele native Erweiterungen von Corona, dass man die gesamte Sache auch gleich hätte nativ implementieren können.

Selbst wenn ich nicht nativ programmieren musste, dann war Corona auch für die einfachsten Dinge unglaublich unhandlich und gewöhnungsbedürftig. Ganz simples Beispiel: Pinch- und Rotate-Gesten sind unter iOS sehr beliebt, um Bilder zu rotieren und zu zoomen, oft und gerne wird auch beides zusammen verwendet. Um diese Gesten in einer nativen UIView zu erkennen und das Bild dementsprechend transformiert darzustellen, benötigt es im nativen UIKit ungefähr 5 Minuten Zeit und 10 Zeilen Programmcode. Unter Corona hingegen waren es zum Schluss 247 Zeilen, und zwar nach zwei Tagen Entwicklungsarbeit und etlichen grauen Haaren mehr auf meinem Haupte.

Und ganz von alledem abgesehen fühlte sich die App weder wie eine Android-App noch wie eine iOS-App an. Die Views ruckelten in  der Navigation unbeholfen herum (während nativ alles hardwarebeschleunigt und flüssig funktioniert hätte), es gab Blackouts und Blitzer wenn die Library mal wieder versuchte, irgendetwas nachzubilden, was nativ ganz anders aussah und normalerweise problemlos funktionierte, und ständig hing drohend über alledem der Memory Warning Crash, weil zig unnötige Megabytes an Code im Speicher gehalten wurden, die das Framework beherrbergten.

Damit wir uns nicht falsch verstehen: Corona ist vermutlich schon ganz ok, um ein einfaches 2D-Spiel zu schreiben, das nichts besonderes können muss. Für unseren Anwendungsfall (und tatsächlich war das Spiel in vielen seiner Funktionen näher an einer „Anwendung“ als an einem „Spiel“) jedoch war es falsch, falsch und nochmal falsch.

Doch auch wenn unser Crossplatform-Ausflug letzten Endes einer der fetteren Nägel in unserem Sarg war, so bin ich dennoch dankbar dafür, dass wir ihn unternommen haben. Denn erstens habe ich dabei viele Fehler gemacht, die ich in dieser Form garantiert nicht noch einmal machen werde (mein Crossplatform-Abwehrreflex ist gesund und jederzeit bereit zum Angriff).

Und zweitens lernte ich dabei Lua kennen.

Lua

Lua ist eine Programmiersprache, die 1993 von der Computer Graphics Technology Group der Päpstlichen Katholischen Universität von Rio de Janeiro in Brasilien entwickelt wurde.

In Brasilien gab es damals ein mehr oder weniger strenges Embargo für ausländische Hard- und Software. Das führte dazu, dass man das Rad öfter mal neu erfinden musste… und in einigen Fällen führte es dazu, dass man das Rad vor allen anderen erfand, und obendrein noch ein besseres und schöneres Rad als die anderen.

Denn TCL, die einzige vergleichbare damals schon existierende Skriptsprache, war im Vergleich zu Lua undurchsichtig, kompliziert, unflexibel und ganz allgemein eine ziemlich ekelerregende Angelegenheit.

PHP und JavaScript erschienen erst drei Jahre hinterher auf der Bildfläche und sind auch heute, 20 Jahre später, noch immer kein ausgesprochenes Paradebeispiel für Schönheit und Klarheit.

Als die Corona-Leute eben jene Crossplattform-Lösung ersannen, die uns schließlich (unter anderem) das Genick brach, da wählten sie Lua als Frontend-Programmiersprache. Aus relativ einleuchtenden Gründen, denn Lua ist leicht erlernbar, sehr effizient, lässt sich sehr gut in andere Programmiersprachen einbetten, und steht unter der MIT Lizenz, sprich, es ist für jedermann frei verfügbar und in eigene Projekte integrierbar.

Und so kam es, dass ich eines Tages vor der Aufgabe stand, Lua zu lernen. Und, oh Wunder, so sehr Corona selbst ein Krampf im Allerwertesten war, so sehr lernte ich Lua schätzen.

Denn erstens ist Lua konzeptionell wirklich sehr klar und einleuchtend. Zwar ist Lua selbst erstmal nicht objektorientiert, aber die vorhandenen Sprachkonstrukte wie metatables und Funktionen als First-Class-Objekte lassen Konzepte wie Objektorientierung und Vererbung sehr leicht verwirklichen.

Zweitens ist Lua für eine interpretierte Skriptsprache sehr schnell⁴. Ich hab keine Geschwindigkeitsvergleiche mit anderen Sprachen gemacht, aber andere Leute haben das getan, und das bestätigt meine Eindrücke.

Drittens ist Lua schlank und unauffällig. Ein ausgewachsener Lua-Interpreter kommt in ca. 180kb ARM-Code unter.

Und viertens mag ich Lua einfach. Das ist bei Programmiersprachen so ein persönliches Ding, das sich schwer begründen lässt. Manche mag man, andere nicht so sehr. Als ich beispielsweise anno 1998 Objective-C kennenlernte, da war quasi sofort klar, dass das eine große Liebe werden würde. Swift hingegen (was viel bessererer weil moderner ist) reisst mich nicht im geringsten vom Hocker… und das liegt nicht daran, dass ich nicht gerne neue Dinge lerne (siehe: Lua).

Auf jeden Fall: Das alles führte dazu, dass ich auch noch lange nach dem Niedergang unserer Spiele-Company gerne den Lua-Interpreter auspackte und das eine oder andere Stück Spiel programmierte… was auch mit dem Auftauchen einer wirklich sehr genialen neuen Hardwareplattform zusammenhing, und der damit verbundenen Wiederauferstehung eines schlanken und schnellen Betriebssystems aus den späten 80er Jahren.

Aber das ist dann das Thema des nächsten Postings in dieser Reihe.


¹ Das gilt natürlich nicht für die Brotjob-Kollegen. Vor denen bleiben meine Musiker- und Fotografen-Personae ebenso gut versteckt, wie ich bisher meine Eigenschaft als Programmierer vor meinem Musik- und Fotopublikum versteckt habe. Komisch, ich mache das andersrum garantiert nicht freiwillig, aber es scheint mir ein ungeschriebenes Gesetz zu sein, dass diese Welten getrennt sein müssen.

² Danke, sleeksorrow, für das Wort

³ Wobei es mir jetzt auf dieses ‚CTO‘ gar nicht so sehr ankommt… ich frage mich eh immer wieder, warum Softwareentwickler nicht einfach Softwareentwickler bleiben dürfen, sondern mit der Zeit zu irgendwas hochtrabendem anderen mutieren müssen. Was ist so schlimm daran, ein Entwickler zu sein? Es gibt doch ein Leben lang etwas zu lernen und sich weiterzuentwickeln…

⁴ Zumindest war das damals so. Inzwischen läuft Javascript vermutlich nativ auf irgendwelchen GPU-Kernen, die nebenbei alle 10 Sekunden einen komprimierten Framebuffer-Dump an die NSA schicken. It’s a brave new world.

Der Tag ist gerettet

Aufgrund irgendeiner seltsamen schrägen Abzweigung in unserem Gesprächsverlauf sind meine Kollegen (Abbildung: unten) und ich heute bei der Mittagspause zu der Überzeugung gelangt, dass mein Tag vollständig verloren und sinnlos ist, wenn es mir in eben dieser Mittagspause nicht gelingt, ein Bild zu machen, das ich SOOC einfach so veröffentlichen kann (Abbildung: oben).

Uff. Gerade noch mal Glück gehabt. 🙂

SKPH9874

Ansonsten… bin ich immer noch dabei, meinen ersten (naja, ok, zweiten, wenn man die Komfortzonen dazu zählt) Artikel über ein Programmier-Thema zu schreiben, und tu mich leider ziemlich schwer damit. Aber es wird, es wird…

 

Ein Wochenende mit der X-Pro2

Am Wochenende hatte ich endlich mal Zeit, meine neue Kamera, eine Fujifilm X-Pro2, einem etwas intensiveren Test zu unterziehen.

Meinen ursprünglichen Plan, meine Komfortzone (haha) zu verlassen und die entlegenen Ausläufer des Siebengebirges zu erkunden, musste ich leider zurückstellen – denn zum einen wurde ich erstmals in meinem Leben von einer Allergie heimgesucht und bekam zeitweise kaum Luft, und zweitens wurde das Siebengebirge von Heerscharen von Wanderern heimgesucht, was meinem Bedürfnis nach Ruhe und Abgeschiedenheit nicht gerade entgegen kam.

Also beschränkte ich meine fotografischen Aktivitäten zumindest vorläufig auf die eigenen vier Wände, respektive den eigenen Garten, respektive die nähere Umgebung der K-Burg.

Zwei Erkenntnisse habe ich dabei mitgenommen.

SKPH9013
Der Unterstand
X-Pro2, Fujinon XF 35mm f1.4 @ f8.0, Classic Chrome

Erstens, es gibt hier immer wieder neue Dinge zu entdecken.

Wie zum Beispiel die Textur dieses ausgeblichenen Holzbalkens, in Kombination mit dem Grün des jungen Efeus, das sich hier einen Weg aus der Dunkelheit des alten Unterstands im Garten ins helle Frühlingssonnenlicht bahnt.

SKPH8258
Buba wacht
X-Pro2, Carl Zeiss Super-Dynarex 135mm, f4.0, Velvia

Zweitens, ich mag die X-Pro2 wirklich sehr, und das nicht nur, weil sie neu ist.

Die Bedienung fühlt sich sehr natürlich, sehr camera-like an, alles ist intuitiv genau dort, wo man es als Mensch, der seit 30 Jahren mit Kameras hantiert, erwartet. Kein AppStore, kein SoftSkinPortrait, kein Auto-HDR, kein Babyportrait-Im-Sonnenuntergang-Modus, keine komplizierte Bedienung über Menüs und Untermenüs… man merkt deutlich, dass Fujifilm bei der Kameraentwicklung Fotografen mit ins Boot holt.

Und das ist gut so.

SKPH8653
Die letzte ihrer Art
X-Pro2, Carl Zeiss Super-Dynarex 135mm f4.0, Velvia

Tatsächlich kommen alle Bilder in diesem Artikel quasi direkt aus der Kamera. Sie wurden nur verkleinert und mit einem Wasserzeichen versehen, ansonsten fand keine nachträgliche Bildbearbeitung statt.

Sehr entgegen kamen mir dabei die integrierten Filmsimulationen, die bei der X-Pro2 sehr viel mehr darstellen als nur ein nettes Gimmick.

Fujifilm hat eine lange und traditionsreiche Vergangenheit als Filmhersteller, und das ist deutlich zu merken. „Velvia“ beispielsweise steht eben nicht nur für „mehr Kontrast und mehr Sättigung“, und „Acros“ ist weit entfernt von „alles schwarzweiss und ein bisschen Kontrast in die Tonkurve“.

Vorausgesetzt man hat eine ungefähre Vorstellung davon, wie die Einstellung das Ergebnis beeinflusst, kann man diese Filmsimulationen tatsächlich verwenden, um sich damit viel nachträgliche Bildbearbeitung zu sparen.

SKPH8655
Buche + Bokeh
X-Pro2, Carl Zeiss Super-Dynarex 135mm, f4.0, Velvia
SKPH8652
Lieblingsaussicht
X-Pro2, Carl Zeiss Super-Dynarex 135mm f4.0 @ f8, Velvia
SKPH8623
Abend in den Weinbergen
X-Pro2, Sigma 24mm F2.8 AF Super Wide II @ f4.0, Velvia

Insbesondere Acros hat mich beeindruckt. Ich habe keine Ahnung, welche Soße Fujifilm da genau in die Bilder rührt, aber es kommt meiner Vorstellung von Schwarzweiß-Fotografie schon ziemlich nahe:

SKPH8418
Tulpe
X-Pro2 + Fujinon XF 27mm f2.8, Acros+R
SKPH8398
Rhababerkuchen machen
X-Pro2 + Fujinon 27mm f2.8, Acros+R
SKPH8995
Frau K.
X-Pro2 + Minolta AF85mm f1.4G, Acros+R
SKPH8579
Buba wacht (II)
X-Pro2, Sigma 24mm F2.8 AF Super Wide II @ f2.8, Acros+R

Aber genug der technischen Fachsimpelei. Dies soll kein Kamera-Testbericht werden*, und es ist auch wirklich nicht so, dass ich mit diesem Artikel jedem Fotograf den Kauf einer X-Pro2 ans Herz legen möchte. Ich habe nur die Erkenntnis gewonnen, dass sie bislang sehr gut zu mir und zu meiner Art zu fotografieren passt. Ha, wer weiss, vielleicht grabe ich auch irgendwann doch nochmal die Menschenfotografie aus.

Zurück zum Wochenende: Es war, von meiner neu entdeckten Allergie und den Heerscharen im Wald hinter unserem Haus mal abgesehen, wirklich eine sehr schöne Zeit. Hier noch ein paar Impressionen:

Zu guter Letzt besuchte uns auch noch die Nachbarskatze… ein wahrhaft betörend schönes Wesen mit dem Namen Fritzi, das ich schon letztes Jahr in mein Herz geschlossen habe (tatsächlich tauchte sie zu meinem letzjährigen Geburtstag zum ersten Mal bei uns auf)… sehr zu Bubas zeitweisem Unmut.

Tja, und da das hier schließlich immer noch das Internet ist, möchte ich euch als Abschluss dieses Artikels ein paar Bilder von Fritzi nicht vorenthalten (allesamt mit dem Fujinon XF18mm f2.0; wie sich herausstellt, ein ideales Objektiv für Fritzi, denn sie hat die Eigenheit, auf die Kamera zuzurennen, um sich sodann nur wenige Zentimeter davon entfernt in Szene zu setzen):


* von denen gibt es schon genug im Netz… auf der anderen Seite bin ich a immer noch am Herauskriegen, was ich in diesem Blog eigentlich schreiben möchte, und für welches Publikum. Wer sich also einen erweiterten X-Pro2-Erfahrungsbericht wünscht, der darf mir das gerne in den Kommentaren kund tun, eventuell könnte ich zu sowas Lust bekommen…

Dog Cam

Als Ausgleich zu gestern: Ein Buba-Bild ohne Text über Softwareentwicklung darunter. So eine schnöde Instrumentalisierung hat sie nämlich nicht verdient 🙂

Das hier war heute morgen auf unsere Terrasse, als das frühe Sonnenlicht den herrlichen Tag heute schon ankündigte. Aufgenommen mit meiner X-Pro2 und einem Takumar 135mm f2.5, das ich von meinem Vater geerbt habe, und das ca. so alt sein dürfte wie ich selbst; JPG out of the box, nicht bearbeitet, nicht beschnitten, nicht begarnixt.

Von Komfortzonen

Es ist an der Zeit, hier mal ein paar Takte über Softwareentwicklung zu reden.

Oder vielmehr: Über Entwicklung und Fortschritt im Allgemeinen, denn selbstverständlich lässt sich das, was sich Softwareentwickler den lieben langen Tag anhören dürfen, auch mühelos auf andere Berufe übertragen.

Beispielsweise finde ich, so ein Gas-Wasser-Installateur sollte ruhig mal was neues ausprobieren und seine Komfortzone verlassen. Insbesondere einer, der seinen Job schon sehr lange Zeit sehr gut macht. Es geht nämlich immer noch besser, der Prozess hört nie auf.

Das Sicherheits-Druckventil in der Heizung einfach mal weglassen. Den Mut haben, alte Zöpfe abzuschneiden.

Oder, noch besser, das Ding durch den allerneuesten heissen Scheiss aus den USA ersetzen, vom dem niemand so richtig weiss, ob und wie er funktioniert, den aber irgendwelche eigens dafür gezüchteten Evangelisten auf Konferenzen ganz toll finden.

(und überhaupt, pfffff, Sicherheitsventil, das ist so funktional, so von gestern. Heutzutage macht man sowas reaktiv. Sieht zwar erstmal viel komplizierter aus, mit dem dadurch bedingten Grossbrand nebst zugehörigem Feuerwehr- und Notarzteinsatz… aber wenn der Groschen erstmal gefallen ist, dann ist es die wahre Lehre)

Und da nicht aufhören. Überkommene Arbeitsweisen aktiv hinterfragen und offensiv angehen.

Einfach mal ein Lagerfeuer neben der Gasleitung entfachen und gemütlich ne Kippe schmauchen während man schaut ob auch alles schön dicht ist.

Das Klo einfach mal in einem 32°-Winkel installieren und den Kunden dann in die Richtung erziehen, dass das vollkommen schnafte so ist.

Und auch in der Elektrotechnik könnte man sicher so viel anders und besser machen, wenn die Leute endlich mal aus ihrer Komfortzone rauskommen und sich neuen Ideen gegenüber öffnen würden.

Beispielsweise arbeiten zwei mit Handschellen aneinander gefesselte Elektrotechniker sicher sehr viel schneller und effizienter an einem Problem als nur einer allein. Was? Warum wehrt ihr euch denn dagegen? Ihr habt es ja noch gar nicht ausprobiert. Wer sich nicht weiter entwickeln will, der ist irgendwann weg vom Fenster.  Also hopp, hier, Handschelle, Fesseln.

Und dann, beispielsweise so ein Trafo. Muss der unbedingt sein? Wozu ist der überhaupt gut? Da kann man sicher was anderes neues hippes einbauen, oder einen kleineren, oder irgendwas, was nicht so viel kostet und nicht so viel Zeit braucht, oder? Und die LEDs ruhig mal ohne Vorwiderstände betreiben. Dinge anders machen. Traut euch!

(und kommt mir nicht mit ihr habt das so gerlernt oder gar studiert, oder mit physikalischen Gesetzen. Das hier ist die richtige Welt, Baby! Ihr müsst auch mal was anders machen! Und das sage ich bewusst als Fachfremder!)

Mut haben, mal ein paar Paradigmen zu verschieben!

Auch bei der Gärtnerei. Müssen Pflanzen denn wirklich unbedingt in Erde wachsen? Könnte man da nicht mal was neues ausprobieren, z.B. stinkenden synthetischen Nährschleim oder sonst ein Wundermittel, mit dessen Anpreisen sich ein Haufen Leute, die noch nie im Leben einen richtigen Garten gesehen haben, auf eigens dafür eingerichteten Tagungen eine goldene Nase verdienen?

Und dieses Ding, mit dem ihr die Löcher in die Erde gräbt, ihr nennt es „Schaufel“. Voll archaisch. Voll oldthink. Gibt’s da nicht irgendwas anderes? Am besten irgendwas verteiltes, verteilen ist immer gut, am besten was, das für viel Geld von mehreren Leuten tagtäglich gewartet werden muss, damit es halbwegs funktioniert. Ihr werdet sehen, das ist dann Fortschritt.

Traut euch, die Dinge mal mit frischen Augen und einem frischen Blick auf das Wesentliche anzuschauen.

Verlasst eure Komfortzonen. Dann wird nämlich alles besser.