Wie baue ich eine Vagrant Box mit OSX Yosemite?

Vagrant ist aus dem heutigen Entwickler Alltag nicht mehr weg zu denken. Wird es hauptsächlich für Linux Distributionen verwendet, so ist es doch auch mal ganz reizvoll, eine Box mit einem OSX drin zu betreiben – sprich, Mac OSX Yosemite zu virtualisieren. Und das geht so:

Zieht euch das Repository: https://github.com/box-cutter/osx-vm

Anschließend ladet ihr euch über den App-Store den OSX Yosemite Installer herunter – aktuell ist in diesem OSX Yosemite 10.10.1 enthalten. Wenn der Download abgeschlossen ist, ruft ihr folgendes im ausgecheckten osx-vm Order auf:

mkdir dmg
prepare_iso/prepare_iso.sh /Applications/Install\ OS\ X\ Yosemite.app ./dmg

Anschließend wird das im Installer enthaltene ISO zu einem beschreibbaren DMG umgewandelt und ein paar Patches angewendet. Wenn das Script durchgelaufen ist, dann könnt ihr mittels (xcode Command Line Tools vorausgesetzt)

make virtualbox/osx1010-desktop

die Vagrant Instanz für eine Yosemite Desktop Variante in Virtual Box bauen lassen. Das “virtualbox” kann man durch “vmware” ersetzen, und wenn man das “-desktop” weg lässt, dann bekommt man eine Consolen Variante von OSX.

Ihr werdet hier einen Fehler erhalten, dass der Installer das DMG nicht finden kann. In meinem Fall sollte die Datei “OSX_InstallESD_10.10_14A389.dmg“ heißen. Also benennt ihr einfach die vorhandene DMG Datei im Ordner DMG in den euch angezeigten Namen um. Anschließen führt ihr den oberen Befehl erneut durch und wartet einfach ab. Ihr werdet zuerst ein paar mal die Shell sehen, bis sich dann irgendwann der Yosemite Installer öffnet und das System automatisch installiert.

1416523902_thumb.png

Es wird automatisch der User Vagrant erzeugt, der das Passwort “vagrant” hat. Loggt euch aber nicht direkt ein, sobald die Login Maske erscheint, sondern beobachtet eure Console. Dort werdet ihr sehen, dass Vagrant erstmal die neuesten Updates einspielt und Software installiert. Also erstmal machen lassen 😉

Und ehe man sich versieht, hat man ein OSX in der Virtual Box am laufen:

Bildschirmfoto 2014-11-21 um 00.10.37
Wichtig: brecht auf keinen Fall den Installer ab! Wenn ihr das Script vorzeitig beendet, dann wird die komplette Box gelöscht. Dass ihr die GUI seht ist erstmal etwas verwirrend – letztlich wird die Box nur vorbereit, um dann nach Abschluss aller Installationen als „echte“ Vagrant Box hinterlegt zu werden. Diese Box wiederrum könnt ihr dann als Vagrant Box verwenden, um verschiedene Instanzen davon laufen zu lassen.

Die erstellte Box wird ca. 6GB groß sein.

Der Tag der Programmierer

Passend zum heutigen Tag kann ich euch mitteilen, dass heute der inoffizielle Tag der Programmierer ist. Es handelt sich um den 256ten Tag des Jahres, welcher der 13 September, in Schaltjahren der 12. September ist.

Und da 256 der höchste Farbwert in der RGB Palette ist, bedeutet das, dass alle Programmierer heut die Farbe Weiß tragen. Ich hoffe, dass alle Programmierer dran gedacht haben 😉

In Russland ist der Tag wohl sogar ein offizieller Feiertag für Programmierer…

Weitere Informationen:
Programmers Day

Was macht einen guten Programmierer aus?

Quelle: Geek&Poke

Nach nun knapp 6 Jahren in der Programmierung und mehreren kleinen und großen Projekten, habe auch ich mir ein Bild von der Welt der Softwareentwicklung machen können. Ich konnte einige Charaktäre kennenlernen und für mich haben sich bestimmte Punkte herauskristalisiert, welche meiner Meinung nach einen guten Entwickler ausmachen.

Beginnen wir erstmal mit dem handwerklichem Teil, den wohl jeder Entwickler drauf haben sollte. Neben Syntax und Semantik gehören auch Kenntnisse der Wirkungsweise von Programmiersprachen, Netzwerktechnik, Computertechnik im Allgemeinen, Design Patterns, Datenbanken, Betriebssystemeigenheiten usw. zum Erfahrungsschatz. Erst wenn man das komplexe Zusammenspiel dieser Komponenten versteht, so kann man auch alle Probleme, die da so kommen mögen, lösen.

Ein anderer Punkt, und den finde ich besonders wichtig, ist die Erfahrung. Entwickler, die eine Programmiersprache beherschen, können zwar schnell neue Sprachen erlernen, weil sie sich fast alle ähneln oder zumindest die gleichen Prinzipien verfolgen (hier gibt es natürlich Ausnahmen). Aber auch wenn der Entwickler die neue Sprache erlernt hat, so kennt er bestimmte Eigenheiten eben erst, wenn er auch eine gewisse Praxis hat (min. 0,5 – 1 Jahr). Das hat Auswirkungen auf die Geschwindigkeit des entwickelten Codes und natürlich auch auf die Produktivität des Entwicklers. Meiner Meinung nach ein häufig nicht bedachtes Problem.

Ein wichtiges Kriterium für einen guten Entwickler ist seine Arbeitsweise. Man kann streng nach Lehrbuch programmieren, man kann aber auch lösungsorientiert an ein Problem herangehen. Obwohl ich mich möglichst an die Konventionen halte, so bin ich doch auch öfter mal der lösungsorientierte Typ. Ich denke einfach, das man immer eine gute Balance zwischen Lesbarkeit des Codes und aber auch dessen Performance halten sollte. Natürlich macht es Sinn, streng objektorientiert zu entwickeln, an manchen Stellen kann dies aber sowohl in der Lesbarkeit als auch in der Geschwindigkeit des Codes negative Auswirkungen haben. Es ist aber von Fall zu Fall unterschiedlich – und die Grenze zum Gefrickel ist hauchdünn.

Quelle: Geek&Poke

Neben der Art und Weise, wie man seinen Code strickt, hat natürlich auch die Verwendung von Kommentaren und geeigneten Funktions/Variablennamen einen sehr großen Einfluss auf die Lesbarkeit. Meine Devise: lieber eine Funktion “getLoggedInUserData()” nennen als “getData()” – sagt beides das gleiche aus, jedoch gibt erste Funktion deutlich mehr Randinformationen und beschleunigt so sehr schnell das Verständnis für den Code. Wie lang eine Funktionsbezeichnung oder ein Variablenname ist, hat keinerlei Auswirkung auf die Ausführungsgeschwindigkeit – denn beim Kompilieren werden die Namen sowieso verworfen. Also warum geizen, wenn man diese Fähigkeit gut ausreizen kann. Natürlich sollte man es auch nicht übertreiben und zum Schluss Funktionen wie “todayIsAGoodDaySoGiveMeTheUserData()” nehmen 😉

Dokumentation des Codes ist natürlich immer ein leidiges Thema. Ich persönlich bin eigentlich immer ganz froh, wenn wie oben beschrieben Variablen und Funktionen selbsterklärend sind und sich doch ab und zu eine Kommentarzeile im Code verläuft. Wenn ich dann noch eine zusätzliche Dokumentation erhalte, die mir grob einen Gesamtüberblick über das System verschafft, bin ich schon glücklich. Als Entwickler kann man sich, mit etwas Erfahrung, sehr schnell in Systeme “reindenken” – gibt es dann dazu eine automatisiert generierte 1000-Seiten Doku, wird zumindest bei mir der gegenteilige Effekt erziehlt.

Sätze wie “Kommentare schreibe ich dann später rein” kennen wir wohl zuhauf – und seien wir mal ehrlich: in diesem Fall wird es nie einen Kommentar geben. Ein guter Ansatz ist daher, zuerst den Klassen- oder Methodenrumpf zu bauen, grob zu dokumentieren und erst dann mit der Implementierung zu beginnen.
Optimalerweise kann man abschließend noch ein paar erläuternde Kommentarzeilen verpacken und schon hat man wieder deutlich zur Verständlichkeit beigetragen.

Fazit
Ein nettes Zitat, welches ich kürzlich gelesen hatte, sagt folgendes: “Entwickle immer so, als ob der Typ, der den Code später warten muss, ein Psychopat ist, der deine Adresse hat.”. Besser kann man es wohl nicht formulieren 😉

Links:
Geek&Poke (Bildquelle)