ralfweinbrecher.de

Software Development und so'n Zeug

Firmware-Update 1.01 für Fuji X-Pro1 und Objektive

Hier ist das Firmware-Update 1.01 für die Fuji X-Pro1 und die drei bisher verfügbaren Objektive. Die Änderungen:

The firmware update Ver.1.01 incorporates the following issues:

  • 1.Reduction of chattering noise from iris of lenses in shooting mode.
  • 2.Improvement of phenomenon that parallax compensation does not work under condition of manual focus with OVF bright frame mode.
  • 3.Improvement of phenomenon that OVF quality as low visibility due to too bright OVF under the condition of power save mode during pressing the shutter button halfway.
  • 4.Improvement of phenomenon that delete function does not work after viewing continues shooting mode images.

For activate above issues completely, firmware update for XF lens is also required.

Please update the firmware of XF lens.

Milch zum Kaffee?

Erste Erfahrungen mit der Fuji Finepix X-Pro1

Endlich lieferbar

Seit ein paar Wochen ist die Fuji Finepix X-Pro 1 lieferbar. Nach langen Überlegungen habe ich meine X100 gegen die neue Kamera eingetauscht. Neben der X-Pro1 ist kein Platz mehr für eine X100. Die X100 ist eine wunderbare Kamera, aber mit ihrer Benutzung ist mir klar geworden, dass es mir vor allem auf wechselbare Optiken ankommt. Nicht für alle Motive ist die bei Kleinbild etwa 35mm entsprechende Brennweite der X100 geeignet.  Ich suche einfach ein Kamerasystem, dass sich flexibel erweitern lässt, ohne dass man zu jedem Shooting einen 10kg schweren Fotorucksach mitschleppen muss. Die X-Pro1 ist nun eine Systemkamera mit einem von Fuji neu konstruierten X-Bajonett und den zugehörigen Objektiven. Zunächst sind drei Optiken im Handel, es sollen aber in der zweiten Jahreshälfte und Anfang kommenden Jahres weitere folgen. Ich habe mir ein Set aus der X-Pro1 und dem Objektiv XF35mm F1.4 R (53 mm, äquivalent zu KB) zugelegt.

Erste Eindrücke

Als Umsteiger von der X100 muss man nicht viel hinzulernen. Der optische Sucher funktioniert perfekt. Man kann mit einem Hebel an der Vorderseite auf den elektronischen Sucher umschalten. Neu ist, dass man die Größe des Bildrahmens im optischen Sucher einstellen, so dass man bei längeren Brennweiten den Ausschnitt genau festlegen kann. Überhaupt ist der optische Sucher einer der besonderen Vorzüge der

Die Bedienelemente ähneln denen der X100. Das Zeitenwählrad rastet jetzt in der Stellung “A” (Zeitautomatik) ein, das Belichtungskorrektur-Rädchen ist leicht versenkt und kann nicht mehr so leicht versehentlich verstellt werden, wie bei der X100. Die Knöpfe auf der Rückseite sind größer gestaltet worden, so dass sie sich auch von erwachsenen Fingern gut bedienen lassen. Neu ist der Q-Button, der einen Schnellzugriff auf die wichtigsten Parameter erlaubt. Insgesamt mach das Gehäuse der Kammer einen ausgesprochen robusten Eindruck.

Fuji liefert mit den Objektiven jetzt eine Gegenlichtblende mit. Das ist toll, denn bei der X100 war dieses Zubehör anfangs gar nicht zu bekommen.

 

DIe Qualität der Aufnahmen hat mich sofort überzeugt. Ich kann nicht beurteilen, ob der Sensor der X-Pro1 tatsächlich – wie hier oder hier behauptet – gegen die Vollformat-Spiegelreflexkamers der Konkurrenten qualitativ bestehen kann. Aber für meine Maßstäbe – verglichen mit einer fast 4 Jahre alten DSLR – ist die Bildqualität exzellent.

Ganz lustig – für die älteren unter den Fotografen – ist die eingebaute Simulation von Fuji-Filmen. Ebenfalls eine ganz nette Spielerei sind die Doppelbelichtungen.

Positive Eigenschaften

  • Ausgezeichnete optische Leistung
  • Hervorragende Ergebnisse bei hohen ISO-Zahlen
  • Klein und leicht, verglichen mit Spiegelreflex-System
  • Gelungenes Bedienkonzept
  • Optischer Sucher in Perfektion

Was stört

  • RAW-Konvertierung derzeit nur mit SilverPix-Software möglich (mit der ich nicht zurecht komme)
  • Camera Raw von Adobe und unterstützt X-Pro1 bislang nicht
  • Die AF-Geschwindigkeit könnte höher sein
  • Bende des XF35mm F1.4 R macht Geräusche (siehe “aperture chatter”)

Fazit

Klasse Kamera!

Jetzt erst mitbekommen: Kodak Portra 160 NC gibt es nicht mehr

Wie ich mit leichtem Bedauern gestern im Fotoladen erfahren musste, hat Kodak die Filme der Portra-Serie zusammen gestrichen. Statt meiner geliebten Portra 160 NC bieten sie jetzt einen Portra 160 an, der in der Farbwiedergabe dem NC-Typen entsprechen soll. Für den 400 NC gibt es keinen Ersatz. Schade.

Kodak erklärt das so:

Warum wird der Vertrieb von 160NC und 160VC Film eingestellt?
Mit dem neuen KODAK PROFESSIONAL PORTRA 160 Film steht Fotografen, die nach einem Maximum an Qualität streben, nun ein unübertroffenes Portfolio zur Auswahl, einschließlich des kürzlich eingeführten KODAK PROFESSIONAL PORTRA 400 Film und der preisgekrönten KODAK PROFESSIONAL EKTAR 100 und KODAK PROFESSIONAL PORTRA 800 Filme. Diese Familie von Kodak Farbnegativfilmen bietet eine außergewöhnliche Palette an Farb- und Empfindlichkeitsoptionen, großen Belichtungsspielraum und unerreicht feines Korn für eine überlegene Leistung in allen Aufnahmesituationen.

Adobe, bitte …

… wie kann es sein, dass Camera Raw die Fuji X-Pro1 nicht unterstützt?

Dann fotografiere ich eben erst mal in JPEG, bis Ihr mit Eurer Software soweit seid.

Wann ist ein User Interface intuitiv

John Gruber schrieb gestern darüber, dass Apples höchster Anspruch an Benutzerschnittstellen darin besteht, dass die Bedienung offensichtlich ist. Beim Design ihrer User Interfaces geht es ihnen darum, dass der Anwender nach einem Augenblick begreift, wie es funktioniert. Die folgenden Zitate Bingen das auf den Punkt:

This of course factor is at the heart of every great design — from the iPhone to the Braun alarm radio. And it’s an important lesson that every startup and entrepreneur should remember. Whether your company is making a physical product or a web service or mobile application, it’s essential for you to think about design. (Om Malik, The of course principle of design)

Design must be functional and functionality must be translated into visual aesthetics, without any reliance on gimmicks thathave to be explained. (Ferdinand Porsche)

Leider gelingt es nur wenigen Designern, ein User Interface derartig offensichtlich zu gestalten, so auf den Punkt zubringen. Oftmals neigen Firmen dazu, durch den Einsatz von Effekten dem Benutzer ein “Wow!” zu entlocken, ohne dass das Design  ein Hilfe für den Anwender darstellt. All das wirft die Frage auf, wann ist ein User Interface Design gut? Wann lässt sich ein User Interface intuitiv bedienen?

Wann ist ein User Interface intuitiv?

Klären wir zunächst, was man unter Intuition versteht.

Die Intuition (v. lat.: intueri = (deponens) betrachten, erwägen, eigentlich: angeschaut werden, daher auch passiver Sinn von Eingebung, ahnendes Erfassen; intuitum) ist die Fähigkeit, Einsichten in Sachverhalte, Sichtweisen, Gesetzmäßigkeiten oder die subjektive Stämmigkeit von Entscheidungen zu erlangen, ohne diskursiven Gebrauch des Verstandes, also etwa ohne bewusste Schlussfolgerungen. (Wikipedia: Intuition). Das zugehörige Adjektiv heißt intuitiv. Aus der Wortbedeutung heraus wird klar, dass es sich hierbei um eine menschliche Eigenschaft des Verhaltens handelt. Wenn also jemand von einem intuitiven User Interface spricht, dann meint er ein User Interface, das sich intuitiv bedienen lässt. “Ich möchte, dass wir ein intuitives User Interface schaffen.” heißt also in Wahrheit “Wir sollten ein User Interface entwerfen, dass ich intuitiv bedienen kann.”

Um zu erklären, wann sich ein User Interface intuitiv bediene lässt, ist etwas Theorie erforderlich.

Die Diskrepanz zwischen dem aktuellen und dem erforderlichen Wissen des Benutzers

Die Anwender eines Design bringen unterschiedliche Vorkenntnisse mit. Im Bereich der Telekommunikation hat man es mit Anwendern zu tun, die noch nie zuvor einen Kommunikations-Server eingerichtet haben, einen Desktop-VoIP-Client in Betrieb genommen haben oder überhaupt über nennenswerte PC-Kenntnisse verfügen, so dass ihnen selbst die Bedienung per Maus fremd ist. Auf der anderen Seite gibt es Personen, die jede Einzelheit des Designs kennen, da sie möglicherweise an Schaffungsprozess selbst beteiligt waren. Man kann sich die verschiedenen Wissensstufen verdeutlichen, indem man sie sich als Punkte auf einem fiktiven Zahlenstrahl vorstellt. Die Verteilung der Punkte gibt Auskunft über die Vorkenntnisse der Benutzergruppen. Von besonderem Interesse ist aber ein weiterer Punkt: der Normal-Kenntnisstand. Dieser markiert die notwendigen Vorkenntnisse, um mit einem User Interface die geforderte Aufgabe lösen zu können. Jeder Benutzer hat einen unterschiedlichen Kenntnisstand und dieser ändert sich mit der Zeit, da mit der Benutzung des Interface die Erfahrung zunimmt.

Die Wissenslücke

Der Normal-Kenntnisstand und der aktuelle Wissensstand des Benutzers liegen häufig weit auseinander. Hier entsteht eine Wissenslücke. Genau an diesem Punkt kommt das User Interface Design ins Spiel. Wenn momentaner Kenntnisstand und Normal-Kenntnisstand zusammentreffen, kann der Nutzer die an ihn gestellten Aufgaben lösen. Um diesen Punkt zu erreichen, kann man den User trainieren und ihm somit zusätzliches Wissen vermitteln. Man kann aber auch über das Design des User Interface den Punkt des Normal-Kenntnisstandes senken.

Intuitives User Interface Design

Von einem sich intuitiv anfühlenden User Interface spricht man, wenn

  • der Kenntnisstand des Nutzers dem Normal-Kenntnisstand für das User Interface entspricht oder
  • das Design des User Interface den Anwender nicht spüren lässt, dass sein aktuelle Kenntnisstand unter dem Normal-Kenntnisstand liegt

Die Schwierigkeit liegt darin, zu erkennen, was die avisierten Kunden bereits an Wissen mitbringen und was sie wissen müssen.

Drobo FS: Festplatten inkompatibel mit Firmwareversion?

Die Inbetriebnahme des Drobo FS gestaltete sich schwierig. Nachdem Stromversorgung und Netzwerk-Verbindung hergestellt und zwei Laufwerke in den zwei der dafür vorgesehenen Slots installiert waren, blieben alle fünf  Zustands-LEDs rot. Das Dashboard konnte den Drobo FS im Netzwerk finden. Als Statusmeldung zu diesem Gerät wurde angezeigt

… dass die installierten Festplatten mit der Firmaware-Version des Drobo FS inkompatibel wären …

Die Online-Überprüfung der installierten Firmware ergab, dass bereits die neueste Version Laut Handbuch wird bei der Inbetriebnahme des Drobo der Inhalt der installierten Festplatten gelöscht. Dennoch war der normale Betrieb auch durch mehrmaliges Neustarten oder Zurücksetzen in den Auslieferungszustand nicht herzustellen. Formatieren der Festplatten an einem anderen PC und anschließendes Einsetzen in den Drobo nützte ebenfalls nicht. Der Drobo-Support hatte nur die Idee, die Festplatten in einem anderen Slot zu probieren.

Dann kam mir die Idee, den Drobo über sein Dashboard-Menü zurückzusetzen. Hinter diesem Menüeintrag verbarg sich dann überraschenderweise eine Funktion zum Löschen des Drobo bzw. seiner Laufwerke.

Die sich drauf hin öffnende Dialogbox verlang nach der Eingabe der Zeichenkette “löschen” in Kleinbuchstaben. Dann darf man das Löschen aller Daten bestätigen.

Ein erneuter Neustart des Drobo führte dann zu der Erkennung der Festplatten und grünen Status-LEDs.

Insgesamt war die Erfahrung mit der Inbetriebnahme des Drobo FS alles andere als gut. Ein System, dem man Backups wichtiger Daten anvertrauen möchte, muss zuverlässiger sein. Ich werde dieses Gerät nur mit grossem Misstrauen benutzen.

Statement

Kirschen pflücken (Wann man git cherry-pick benötigt)

Mit git cherry-pick ist es möglich, kleine Code-Patches über Branches hinweg zu bewegen. Ich vertrete die Meinung, dass man dieses Kommando nur in seltenen Fällen verwenden sollte, wenn es wirklich notwendig ist. Ein Anwendungsbeispiel ist ein kleiner Hotfix direkt im Stable Branch (master). Anschließend merkt man, dass es sinnvoll wäre, diese kleine Änderung auch in einen Release-Branch zu übernehmen. Dann bietet es sich an, cherry-pick zu verwenden.

Der Haken an der Nutzung von cherry-pick ist, dass aus der Sicht von Git damit ein neues Changeset erzeugt wird. Der mit cherry-pick kopierte Commit bekommt eine neue SHA-1-Summe. (Auch rebase hat diese Eigenschaft, dass es die SHA-1-Summe des erzeugten Commits ändert, aber immerhin ist das rebase-Kommando in der Lage, Patch-IDs zu analysieren.) Beim cherry-pick wird also ein Changeset zwischen Branches kopiert und mit einer neuen SHA-1-Summe versehen. Beschränkt man das auf die notwendigen Anwendungsfälle, kann nicht viel schief gehen. Allerdings ist cherry-pick zwischen Branches die man mergen muss ein sicherer Weg, um Konflikte zu erzeugen.

Die Regel lautet daher: Benutze cherry-pick nur in seltenen Fällen, wenn es notwendig ist und vermeide es zwischen Branches, die Du mergen musst.

Falls Deine tägliche Arbeit mit Git eine Menge cherry-pick enthält oder anders ausgedrückt es nicht äußerst selten angewendet wird, dann stimmt wahrscheinlich etwas mit Deinem Workflow nicht.

Der Zusammenhang zwischen Komplexität und Arbeitsaufwand in Software-Projekten

Angeregt durch die Lektüre des Werks “Software Estimation: Demystifying the Black Art” von Steve McConnell will ich mich hier mal mit den Schlussfolgerungen aus seinen Gedanken zum Thema “Disecononmies of Scale” beschäftigen. Steve McConnell ist auch der Autor des für jeden Software-Entwickler zur Pflicht-Lektüre gehörenden “Code Complete”. Im hier besprochenen Kapitel beschäftigt er sich mit der Effektivität von Software-Teams in Abhängigkeit der Größe des jeweiligen Projekts.

 

 

Steve McConnell schreibt:

Project size is easily the most significant determinant of effort, cost, and schedule.

Und er fügt hinzu:

People naturally assume that a system that is 10 times as large as another system will require something like 10 times as much effort to build. But the effort for a 1,000,000-LOC system is more than 10 times as large as the effort for a 100,000- LOC system, as is the effort for a 100,000-LOC system compared to the effort for a 10,000-LOC system.

Und schließlich folgert er:

[Using common productivity average values], the 10,000-LOC system would require 13.5 staff months. If effort increased linearly, a 100,000-LOC system would require 135 staff months, but it actually requires 170 staff months.

Obwohl laut McConnell neben der Größe des Projekts auch die Art der Software, die entwickelt wird, als auch persönliche Faktoren eine Rolle spielen, kann man doch erkennen, dass sie den größten Einfluss auf den Erfolg hat. Wenn Du also möchtest, dass Dein Software-Projekt nicht scheitert, hast Du nur eine Wahl:

Halte Dein Projekt klein!

Laut Untersuchungen steigt der Aufwand in Software-Projekten in größerem Maße, als die Zahl der Code-Zeilen wächst. Anders ausgedrückt:

Mit der Zahl der Codezeilen steigt der Aufwand exponentiell an. Die Effektivität des Teams sinkt dementsprechend.

McConnell führt dazu in seinem Buch eine Tabelle an. Die Daten der zugrunde liegenden Untersuchungen sind “Measures for Excellence” (Putnam and Meyers 1992), “Industrial Strength Software” (Putnam and Meyers 1997), “Software Cost Estimation with Cocomo II” (Boehm et al. 2000), und “Software Devel- opment Worldwide: The State of the Practice” (Cusumano et al. 2003). Die in der Tabelle dargestellten Untersuchungsergebnisse zeigen, dass mit jeder Verzehnfachung der Code-Basis eines Software-Projekts die durchschnittliche Produktivität eines einzelnen Entwicklers (ausgedrückt in Lines-Of-Code) sinkt.

Projekt-Größe (in Lines Of Code) Lines Of Code per Staff (Cocomo II Nominal in Parantheses)
10k 2,000 – 25,000 (3,200)
100k 1,000 – 20,000 (2,600)
1M 700 – 10,000 (2,0000)
10M 300 – 5,000 (1,600)

Sicherlich hat diese Betrachtungsweise auch einen Haken. Wie messe ich denn die Größe eines Projekts? Hier angeführt wurde immer das Maß der “Lines Of Code”. Das Bestimmen eines neutralen Werts ist hierbei nicht so einfach. Einerseits wird die verwendete Programmiersprache eine Rolle spielen. So können 100 Zeilen Erlang bis zu viermal soviel Code-Zeilen in C++ entsprechen. Ähnlich wird es sich mit dem Vergleich von Scala zu Java verhalten. Außerdem gibt es eine Grauzone: WIe misst man Kommentarzeilen? Wie geht man mit verschiedenen Code-Formatierungen um? (Vergleiche: Wikipedia LOC und LLOC). Mir geht es aber hier nicht um das Messverfahren. Bei Interesse sollte man sich das Kapitel “Role of Lines of Code in Size Estimation” in Steve McConnells Buch durchlesen. Dort kommt er zu der Schlussfolgerung:

My personal conclusion about using lines of code for software estimation is similar to Winston’s Churchill’s conclusion about democracy: The LOC measure is a terrible way to measure software size, except that all the other ways to measure size are worse. For most organizations, despite its problems, the LOC measure is the workhorse technique for measuring size of past projects and for creating early-in-the-project estimates of new projects. The LOC measure is the lingua franca of software estimation, and it is nor- mally a good place to start, as long as you keep its limitations in mind.

Man muss sich beim Start eines neuen Projekts oder immer dann, wenn Entscheidungen bezüglich Architektur und Design eines Software-Projekts anstehen, bewusst machen, dass das Wachstum der Codebasis die Effektivität verringern wird. Für den erfolgreichen Abschluss eines Projekts ist es eine Bedingung, dass man die Größe gering hält.