Mac OS X Remote Install via Disc Target Mode

Problem: Leider ist das Superdrive von meinem MacBook Pro scheinbar schon etwas mitgenommen.. denn die Leopard-CD (normal, kein OEM) wollte er nicht mehr lesen – der iMac aber schon. 😐 DafĂŒr aber die mitgelieferte DVD, nur war das noch Tiger (10.4). Was tun?

Die Problemlösung ist die gleiche, wenn man ein ganz kaputtes Superdrive hat.

Idee 1: Remote Install oder in deutsch: Entfernte Installation

Dieses Feature wurde mit der EinfĂŒhrung des Macbook Airs in Leopard integriert – okay, fein, den Host könnte der iMac spielen. Leider scheint das entweder nicht funktionieren oder aber es funktioniert tatsĂ€chlich nur mit dem Macbook Air 🙁 Geht nicht. Schade

Idee 2: Die Leopard-DVD vom iMac

Ja, geniale Idee.. nur (leider) sind die mitgelieferten DVDs allesamt OEM-Versionen, die jeweils nur fĂŒr die Produktreihe funktionieren. Also mit anderen Worten: Einen anderen iMac kann ich Leopard installieren, fĂŒr ein anderes Macbook hĂ€tt ich ein(en) Tiger im Angebot.. ach menno 🙁

Idee 2.5: Disc Target Mode

Nachdem die Installation der iMac-Leopard-DVD auf dem Macbook Pro die Installation verweigerte, kam mir eine Blitzidee: Targetmode. Damit startet man das Target (also das Macbook) in einen besonderen Bootstatus; zeitgleich verbindet man den Target mit dem Hostrechner (Mac) und kann von dort auf die Platten zugreifen (vgl. externe Platten). Da man bei einem Mac auf externe Platten wie die eigene zugreifen kann, kann man auch installieren. Und wenn man fĂŒr den Host auch eine gĂŒltige Installations-CD hat (oder ein funktionierendes Laufwerk)… *freu*

Tatsache, man nehme also die Boot-DVD des Hosts (hier iMac), mit der man „booten & installieren darf“. Als Zielmedium wĂ€hlt man aber die Platte aus, die auf dem Target liegt – sehr einfach an dem Symbol eines externen DatentrĂ€gers zu erkennen. Nicht vergessen, vor dem nĂ€chsten Neustart die Rechner alle auszumachen, Kabel raus.. neu starten.. und voila. 🙂

Java-Swing-Komponenten als Bild / Snapshot

FĂŒr unsere Anwendung (Ă€hm, halt Diplomarbeit ftw!) wollte ich eine Export-als-Bild-Funktion fĂŒr die Anzeige des aktuellen Graphen einbauen. Dabei handelt es sich um eine JComponent, die ĂŒber das JUNG-Framework dargestellt wird.

WĂ€hrend jetzt Apple-Benutzer leichtfertig ĂŒber dieses Feature lachen können, ist dies fĂŒr Hauptzielgruppe der Anwendung (also Windowsbenutzer) eine sinnvolle Funktion. Es hat sicherlich wenig Sinn, umstĂ€ndlich einen Komplett-Screenshot anfertigen zu mĂŒssen.. viel einfacher kann das Programm das ja selbst machen.
Es gibt eine Reihe von Suchtreffern in Google, die durchaus lesenswert sind.

Die Grundidee ist, dass man sich selbst ein Graphics-Objekt erstellt und dann die JComponent darauf arbeiten lĂ€sst. Im Falle von Swing ist dies idR vom Framework vorgegeben (nĂ€mlich fĂŒr den Bildschirm), hier aber wollen wir ja ein eigenes Bild haben. Die Höhe und Breite ist in den meisten FĂ€llen von der Komponente zu erfragen.
BufferedImage bi = new BufferedImage(width, height, BufferedImage.TYPE_INT_ARGB);

Anschließend brauchen wir das zugehörige Graphics-Objekt, denn damit arbeiten die Paint-Methoden. Clue Nummer 1: Man könnte in Versuchung kommen, und einfach getGraphics() zu nehmen – ist ja auch naheliegend. TatsĂ€chlich erstellt das aber auch nur ein Graphics-Objekt, wĂ€hrend createGraphics() ein Graphics2D-Objekt erstellt. Und in den meisten FĂ€llen braucht man das auch.
Graphics2D g = bi.createGraphics();

Anschließend muss man sich entscheiden, welche Zeichenroutine man anstoßen will. Es gibt prinzipiell folgende Möglichkeiten: paint(Graphics), paintComponent(Graphics) und paintAll(Graphics). Sofern paintComponent() ausreicht, diese nutzen. Im Falle des JUNG-Graphen mit verschiedenen Subelementen und eigenem Renderer funktioniert jedoch nur paintAll(Graphics) auf allen System zuverlĂ€ssig. WĂ€hrend paint(Graphics) unter MacOS und Linux noch funktioniert, produziert es unter Windows unschöne Ergebnisse.

Anschließend kann man mit dem statischen Aufruf ImageIO.write(bi, "png", file); das gesamte Bild als — hier PNG — speichern. Achtung: Dies ist eine JavaSE6-Klasse, in den VorgĂ€ngern benötigt man dann den Umweg ĂŒber FileStream & Co.

[1] jung.sourceforge.net
[2] java.sun.com

Code-Coverage, Eclipse, jUnit

eclemma-1

Joa, es ist wieder Zeit fĂŒr einen Artikel in der Java/DA-Reihe.

Als erstes und sehr einfach zu testendes Kriterium gilt beim Testen die Code Coverage. Eigentlich sehr simpel, denn es quantifiziert nur die Code-Coverage, also von wie vielen Zeilen Code (Instructions) tatsĂ€chlich wie viele (bzw. welche) auch ausgefĂŒhrt werden. Da man dies natĂŒrlich gerne automatisiert machen möchte, sind Tests wie mit jUnit ideal. Aber, auch normale Anwendungen sind mitzutracen und den Codecoverage ist zu ermitteln.

eclemma-2

FĂŒr Eclipse gibt es dazu ein prima Plugin namens EclEmma. Und auch schnell ĂŒber die Update-URL im Manager installiert. EclEmma dient dabei als eine Art Wrapper fĂŒr verschiedene Launchtypen – also beispielsweise als normale Applikation oder einen jUnit-Test bzw eine ganze Suite (Plugins). Das Ergebnis wird nach Beendigung des Programms/Tests innerhalb von Eclipse in einer Baumstruktur dargestellt; sehr schön ist auch die grafische Hervorhebung direkt im Sourcecode. Alternativ kann man sich das Ergebnis auch als HTML exportieren lassen.

Yaml, Yuml, ja was denn?

FĂŒr große Datenbanklayouts braucht man irgendwann Diagramme; die werden entweder mittels „ER-Syntax“ oder im „modernen“ UML entwickelt. Bei kleineren Projekten oder Veranschaulichungen kann so ein UML-Editor aber schnell zum exponentiellen Overhead werden, weil es sich einfach weder lohnt noch in der „Projektlage“ jeder damit genug auskennt. In diese Richtung stoßt yuml.me, die mit Hilfe einer wirklich einfachen Syntax wunderschöne UML-Diagramme zaubern. Die sind zwar ggf. nicht 100% UML2-tauglich (bzw. haben nicht alle Funktionen des Standards), aber das Ergebnis ist durchaus sehenswert und fĂŒr die meisten kleinen Dinge mehr als ausreichend.

Auf Seite der Konfiguration ist es natĂŒrlich blöd, dauernd mit diesen URLs zu hantieren. Aber, es gibt fĂŒr alles eine Lösung: MMan nehme YAML. Sehr hĂŒbscher Syntax, fast ohne Overhead und damit viel Platz fĂŒr das eigentlich Wesentliche: Informationen und Daten. Das Doctine Project, ein PHP Object Relational Mapper, nutzt zur Definition von Datenbankschemata auch eine YAML-Struktur (Beispiel).

Da ich weder Lust auf PHP coden noch das Aufsetzen eines Java-Servers hatte, habe ich eine kleine, feine Java-Anwendung geschrieben. Sie konvertiert ein DB-Schema in YAML in ein Bild (zeigt dieses an) und lÀsst auf Wunsch dieses Speichern.

Downloads (benötigt Java 1.6):

  1. AusfĂŒhrbare Jar kAml.jar
  2. Dmg Imagefile alsAnwendung fĂŒr Mac OS X