Facebook auf Deutsch – das ist ein ganz besonderes Erlebnis. Es ist ja empfehlenswert, Facebook per https zu nutzen. Der entsprechende Einstellungs-Dialog findet sich unter den Sicherheitseinstellungen des Kontos.
Großartig ist hier die deutsche Übersetzung. Aus “Secure Browning” wird dabei “Sicheres Durchstöbern”.
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.
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.
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.
Über eine recht lange Zeit während meiner Tätigkeit als Software-Developer habe ich mit Emacs gearbeitet. Insbesondere bei der Entwicklung von Erlang-Applikationen und unter Benutzung von Distel arbeitet man sehr komfortabel. Was mich aber immer gestört hat, ist das fehlen eines Projekt-Browsers. Das hat mich dazu gebracht, alternative Editoren und IDEs auszuprobieren. Wäre Eclipse nicht so langsam und dazu noch optisch etwas ansprechender, ließe sich damit ganz angenehm arbeiten. Die Unterstützung für im Paket nicht enthaltene Programmiersprachen lässt sich per Plugin nachrüsten und die Konfiguration scheint ziemlich flexibel zu sein. Xcode ist sicherlich keine schlechte Wahl, wenn man iOS- oder Mac-Software entwickelt. Qt Creator erschein mir für meine Zwecke vollkommen unbrauchbar. Generell finde ich schnelle, schlanke Editoren besser, als die universellen und mit Features überladenen IDEs. Lange Zeit hat mir TextMate gute Dienste geleistet.
Es hat einige Zeit gedauert, bis ich auf den Emacs Code Browser gestossen bin, der genau den Zweck erfüllt, den ich bislang am Emacs vermisst habe.
(require 'semantic/analyze) (provide 'semantic-analyze) (provide 'semantic-ctxt) (provide 'semanticdb) (provide 'semanticdb-find) (provide 'semanticdb-mode) (provide 'semantic-load) (add-to-list 'load-path "~/ecb-2.40") (require 'ecb)(add-to-list 'load-path "~/Library/Application\ Support/Aquamacs\ Emacs/ecb-2.40") (require 'cedet) (require 'ecb-autoloads)
Fertig!
Nun kann man Aquamacs starten. Den Emacs Code Browser aktiviert man:
M-x ecb-activate
Kaum eine Applikation, abgesehen von ein paar Beispiel-Programmen aus den Lehrbüchern kommt im produktiven Einsatz ohne Konfigurationsdaten aus. Ob es nun darum geht, der Applikation mitzuteilen, ob sie im Testmodus starten soll oder sich mit dem Produktiv-Datenbankserver zu verbinden, ob man ihr eine Liste von Distributed Nodes übergeben will oder das Logging-Verhalten beeinflussen möchte; die Szenarien sind vielfältig. In jedem Fall gilt es, die passende Form der Übergabe der Konfigurationsparameter zu wählen.
Eine häufig verwendete Methode ist das Auslagern von Konfigurationsdaten in eine Datei. Nach den OTP-Richtlinien sollen derartige Files im Ordner “priv” abgelegt werden. Dabei legt man die Konfigurationsdatei als durch Zeilenumbrüche Menge von Property Lists an. Hier ein Beispiel:
{syslevel,production}. {address,"172.16.9.31"}. {port,80}. {name,"admin"}. {passwd,"ip6000"}.
Diese Datei wird unter dem Namen “config.cfg” im Ordner “priv” gespeichert. Es soll hier an dieser Stelle mal außer acht gelassen werden, dass es wahrscheinlich keine gute Idee ist, Zugangsdaten im Klartext abzulegen. Nun kann die Applikation auf folgende Art auf die Werte auf die Werte der Konfiguration zugreifen:
Options=case file:consult("priv/config.cfg") of {ok,L}->L; _->[] end, Value=proplists:get_value(key,Options).
Diese Art von Parameter-Übergabe funktioniert durch Festlegung der Applikations-Variablen in der .app-Datei der Erlang-Appikation. Ein Beispiel folgt, der Name der Applikation lautet “di”:
{application,di, [{description,[]}, {vsn,"0.1"}, {registered,[]}, {modules,[appman,contact,contact_param, di_app,di_sup,dlib,dnode, worker,xwrap]}, {applications,[kernel,stdlib,sasl]}, {mod,{di_app,[]}}, {env,[{systemlevel,production}, {address,"172.16.9.31"}, {port,80}, {name,"admin"}, {passwd,"ip6000"} ]}]}.
Auf diese Werte greift man aus so der Applikation zu:
Value=case application:get_env(di,key) of undefined->'default'; {ok,V}->V end.
Es ist hierbei sogar möglich, die Parameter als Kommandozeilen-Option zu setzen. So kann man zum Beispiel den Port auf 99 setzen:
erl -pa ./ebin -di port 99
Außerdem gibt es auch noch die Möglichkeit, auf Umgebungsvariablen des Systems zuzugreifen.
Path=case os:getenv("PATH") of false->undefined; P->P end.
Für eine Embedded-Linux-Hardware, die sowohl den Bootloader als auch den Kernel aus einem SPI-FLASH-Baustein lädt, musste ein Binärfile für den Bauteil-Lieferanten erzeugt werden. Mit dieser Binärdatei soll der Hersteller die Bauteile vorprogrammieren.
Zu einem Binärfile kommt man selbstverständlich sehr einfach durch direktes Auslesen des SPI-FLASH. DIe Embedded-Plattform verwendet uboot als Bootloader. Im uboot besteht die Möglichkeit, den SPI-FLASH-Inhalt an eine vorher zu setzende Adresse im RAM zu laden.
sf probe 2 sf read $(loadaddr) 0 0x200000
Anschließend kann man die Daten mit dem put-Kommano von TFTP auf einen PC laden. Allerdings unterstütz das TFTP meines Bootloaders das put-Kommando nicht.
Andererseits kann man natürlich auch auf der Linux-Konsole des Embedded-Systems direkt das entsprechende Device in eine Datei auslesen. Dazu bietet sich das dd-Kommando an.
dd if=/dev/mtd2 of=/tmp/spi.bin
Der Nachteil an dieser Methode ist, dass das SPI-FLASH in meiner Applikation segmentiert ist. Das heisst, dass der Linux-Kernel nicht unmittelbar auf den Bootloader folgt. Die Spiecheraufteilung sieht zwischen uboot und Kernel mehrere Bereiche zum Ablegen von Systemeinstellungen und Backup-Daten vor. Diese sollen selbstverständlich nicht in dem Image für den bauteil-Hersteller enthalten sein, da sie gerätespezifische Daten enthalten.
Statt der oben skizzierten Methoden schrieb ich ein Bash-Skript, dass die von der Toolchain generierten Binärdateien von uboot und Kernel verwendet. Das Skript nimmt als Parameter den Pfad zu der Binärdatei des uboot, den Pfad zum Binärfile des Kernel, den Dateinamen der Ausgabe-Binärdatei und das Offset des Kernels im SPI-FLASH entgegen. Dabei ging ich davon aus, dass das uboot bei der Adersse 0 liegt, der Kernel aber ein Offset dazu hat. Das Skript berechnet die Differenz zwischen der Dateigröße des Bootloaders und dem erforderlichen Offset. Dann erzeugt es eine temporäre Dateien mit der berechneten Länge, die es mit Nullen füllt. Anschließend fügt es die drei Teile zu einer Binärdatei zusammen und löscht das temporäre File.
#!/bin/bash #------------------------------------------------------------------------------ # Dieses Skript nimmt ein BIN-File und fuellt es am Ende mit Null # auf, bis das Offset erreicht wird # 1.Parameter Input-Filename # 2.Parameter Input-Filename # 3.Parameter Output-Filename # 4.Parameter Offset #------------------------------------------------------------------------------ usage() { echo "Concatenate two files, filling the gap with zero" echo "usage: fillbytes " echo "OFFSET must be decimal number" } if [ "$1" = "" ]; then echo "error: no input file name given!" usage exit 1 fi if [ "$2" = "" ]; then echo "error: no input file name given!" usage exit 1 fi if [ "$3" = "" ]; then echo "error: no output file name given!" usage exit 1 fi # TODO: HEX-Zahlen konvertieren if [ "$4" = "" ]; then echo "error: no offset given!" usage exit 1 fi FILESIZE=$(wc -c < $1) if [ $FILESIZE -gt $(($4)) ]; then echo "error: offset smaller than file size!" usage exit 1 fi FILLSIZE=$(($4-$FILESIZE)) echo $FILLSIZE dd if=/dev/zero of=tempfile.bin bs=1 count=$FILLSIZE cat $1 tempfile.bin $2 > $3 rm tempfile.bin
Das funktioniert soweit ganz prima. Der einzige Schönheitsfehler ist, dass man das Offset als Dezimalwert eingeben muss.
Für die Arbeit mit git hat sich für mich das Werkzeug tig als recht nützlich erwiesen. Meistens erstelle ich Patches mit git gormat-patch. Man kann aber auch auf sehr einfache Weise mit tig Patches für einzelne Commits erzeugen.
Dazu fügt man der Datei ~/.tigrc folgende Zeile an:
bind generic P !git format-patch -1 %(commit)
Nun muss man nur noch tig starten, das entsprechende Commit markieren und P drücken und schon wird ein Patch dafür erzeugt.
