Sehr geehrter Herr Stocker
Gerne bestätige ich Ihre Anmeldung zum Masterstudium an der HSR in Software and Systems.

D.h. ab Herbstsemester 2008 gehts wieder los mit Vorlesungen besuchen und auf Prüfungen lernen.

Phu, ich bin endlich durch mit Prüfungen korrigieren! Und so sieht mein armer Kugelschreiber nun aus:

Insgesamt ist die Oberfläche nicht mehr wirklich grau sondern schimmert leicht rosarot. Und nein, ich habe damit nicht zu tief in der Nase gebohrt..

habe ich ja bis jetzt noch nicht so richtig geglaubt, aber es scheint wohl doch wahr zu sein:

(Für diejenigen, die das jetzt überhaupt nicht verstehen.. wenn man hier im IFS eine Arbeit machen will hört man in der Auflistung der Vorzüge oft, dass man damit Weltruhm erlangen werde. Nicht dass ich unzufrieden wäre…)

Wieder mal ein TV-Tipp von mir: Heute, 22:10 auf SF1, Viktor Giacobbo und Mike Müller’s Late Service Public, gleich nach dem Tatort.

Eigentlich würde ich ja nie ein Buch kaufen, welches auf dem Cover einen Herrn im Anzug zeigt, aber da ich schon so viel gutes über GTD gehört habe, musste ich es einfach lesen.

Getting Things Done ist eine Selbstmanagement-Technik (ich glaube das nennt sich so..), bei der es darum geht, den Kopf frei zu bekommen und sich besser auf seine Arbeit konzentrieren zu können. Denn das Problem ist (sei), dass all die Dinge, die wir noch zu erledigen haben, ständig in unserem Kopf herumschwirren, sogenannte “open loops”, und uns in den unmöglichsten Augenblicken wieder in den Sinn kommen. Dies verbraucht unglaublich viel Ressourcen und das ist nicht gut so. Die Lösung ist es, ein verlässliches System zu schaffen, und zu lernen, diesem zu vertrauen. Wie man das erreichen soll, steht alles in diesem Buch.

Die Technik ist eigentlich recht einfach, alles was es braucht sind diverse Listen und ein System, wie man diese Listen mit allen Tasks füllt. Wie das genau funktioniert, ist auf Wikipedia viel besser beschrieben, als ich es hier könnte.

Das Buch selbst ist recht angenehm geschrieben und gut gegliedert, auch wenn manchmal etwas viel “Geschwafel” dabei ist. Das muss vielleicht bei einem Buch mit Krawattenträger auf dem Cover so sein, wer weiss.
Eher genervt haben mich die unzähligen Randnotizen auf praktisch jeder Seite (manchmal auch zwei..), da sie eigentlich immer den Lesefluss stören und extrem nerven, bzw. mit der Zeit einfach gar nicht mehr gelesen werden.

Ob ich das ganze so wie im Buch umsetzen werde bezweifle ich, aber ich bin ja auch kein Manager der in x Projekte involviert ist und nicht mehr weiss wo oben und unten ist.

Als Stefan Keller mir das erste Mal das Inserat des Dynamic Languages Shootout im Java-Spektrum gezeigt hatte, fühlte ich mich eigentlich nicht besonders davon angesprochen. Zum einen mag ich den Begriff “Dynamic Languages” nicht besonders (darüber vielleicht ein anderes Mal..) und ein Shootout, naja, war mir irgendwie alles zu reisserisch. Die Aufgabenstellung habe ich dann doch durchgelesen, und dachte mir, das ist ja eigentlich ganz einfach: Es geht grob darum, ein Programm zu erstellen, welches 5 Runden Scrabble spielt. Das Wörterbuch ist vorgegeben, pro Zug bekommt man 7 neue Buchstaben. Und schon hatte ich angefangen, mir zu überlegen, wie ich es umsetzen würde, und so nahm alles seinen Lauf…

Mein erster Ansatz bestand darin, mit dem vorhandenen Buchstaben alle möglichen Kombinationen zu bilden und diese dann im Wörterbuch nachzuschlagen. Das Problem, mit 7 Buchstaben gibt es 13699 Möglichkeiten, bei 9 Buchstaben sind es schon 986409, und mit 10 sinds 9864100 (eine elegante Formel hab ich leider nicht parat.. ). Mit etwas Pech sind es in der 5. Runde sogar 5 * 7 – (4 * 2) = 27 Buchstaben.

Ok, nächster Versuch: Performanter ist es, jedes Wort im Wörterbuch durchzugehen und zu prüfen, ob man es mit den vorhandenen Buchstaben bilden kann. Das gibt zwar auch noch einen Haufen zu tun, aber immerhin ist die Zunahme linear. Als nächstes werden die Wörter nach ihrer Wertigkeit sortiert und danach einfach versucht, auf dem Spielfeld korrekt zu platzieren.

Nachdem ich nun schon zwei Abende investiert hatte, wollte ich eigentlich auch am Wettbewerb teilnehmen, allerdings fehlte mir noch eine gute Idee für die Kür. Das Inserat hat Stefan im Java-Spektrum entdeckt, was mich denn auch auf die Idee brachte: Das ganze mit JRuby zu machen und ein Swing-GUI zu implementieren, natürlich alles in Ruby. Um das ganze noch etwas cooler zu machen, habe ich alles in ein Jar verpackt und das Ganze lässt sich per Java Webstart starten. Wie gesagt, ohne eine Zeile Java-Code.

Aussehen tut es folgendermassen:

und ausprobieren kann man es von hier aus. Eine der Anforderungen war auch, dass das ganze Dokumentiert wird, also habe ich auch mal etwas rdoc geschrieben.

Ach ja, es hat dann doch für den 2. Platz gereicht. Und gegen Smalltalk zu verlieren macht mir überhaupt nichts aus.

Kurze Frage, in welcher Programmiersprache ist das wohl geschrieben:
a->Foo = b->Foo;

Read all »

Ich glaube es kaum, aber ich habe ein Buch über Software Engineering gelesen, das fast 10 Jahre vor meiner Geburt geschrieben wurde:

Das Buch stand schon recht lange auf meiner Leseliste, schliesslich ist es einer der Klassiker in seinem Bereich. Brooks schreibt von seinen Erfahrungen, die er bei der Entwicklung von OS/360 gemacht hat, einem 5000 Mannjahre / 50 Millionen $ Riesenprojekt.

Das Alter merkt man dem Buch schon an, das Lesen ist teilweise recht anstrengend, da man konstant überlegen muss, wie sich das Gelesene auf die heutigen Umstände portieren lässt. Im Buch werden beispielsweise reihenweise Betriebssysteme geschrieben, und das in nicht gerade komfortablen Sprachen. Andere Kapitel sind “zeitloser”, wie dasjenige, das dem Buch den Namen gegeben hat und welches schlussendlich zu Brooks’s law führte:

Adding manpower to a late software project makes it later

Warum? Für jeden neuen Mitarbeiter braucht es einen vorhandenen Mitarbeiter, der den Neuen einführt und wahrscheinlich auch häufig mit Fragen in seiner Arbeit unterbrochen wird. Ausserdem braucht es eine gewisse Zeit, bis der Neue richtig produktiv mitarbeiten kann. Auch steigt der Kommunikations- und Managementoverhead je mehr Leute an einem Projekt arbeiten. Eventuell muss sogar die ganze Planung angepasst werden, um die Arbeit besser auf mehr Leute zu verteilen (zumindest in einem weniger agilen Prozess). Man sollte also vorsichtig sein, einfach neue Leute in ein Projekt zu “werfen”.

No Silver Bullet

Ein weiteres, sehr spannendes und bekanntes Kapitel ist “No Silver Bullet”, welches auch heute noch zu Diskussionen führt. Um was geht es? Brooks behauptete, dass es in den nächsten Jahren keine “order of magnitude” Produktivitätssteigerung in der Software-Entwicklung mehr geben wird. Dazu muss man wissen, dass Brooks die Komplexität der Software-Entwicklung in zwei Komponenten zerlegt: die unbeabsichtigte und die essentielle. Unbeabsichtig ist alles, was man sozusagen als “Ballast” mitschleppt und tun muss, um die essentielle Komplexität einer Software zu erreichen. Essentielle Komplexität sind beispielsweise die Features, die der Kunde will, oder das Design und die Ueberlegungen, die man zum lösen des Problems anstellen muss. Mit neuen Entwicklungstools und Programmiersprachen lässt sich eigentlich nur die unbabsichtigte Komplexität reduzieren, und da dieser Teil mit der Zeit immer kleiner wurde, lässt sich die Gesamtkomplexität der Entwicklung immer schwerer reduzieren als zu der Zeit, als man noch Lochkarten stanzen oder Assemblercode schreiben musste.
Ich hoffe, ich habe das richtig verstanden und erklärt, ansonsten sollen mich Emanuel und Guido bitte korrigieren (die waren an einem OOPSLA-Workshop zu diesem Thema).

Was mir am Buch auch noch sehr gefallen hat sind die Zusatzkapitel, die in der Neuauflage hinzugekommen sind und sich mit den Reaktionen zum Buch auseinandersetzen, die einzelnen Bereiche nochmals analysieren um zu verstehen, was sich bewahrheitet oder wo sich Brooks geirrt hatte.

Die beiden erwähnten Kapitel sollte eigentlich jeder mal gelesen haben, die restlichen Themen lohnen sich wohl nicht so, bzw. gibt es bessere zeitgemässe Bücher.

Ich hab schon lange nichts mehr hierüber geschrieben, die “einfachen” Themen sind ja auch schon durch. Eines der wohl nützlichsten Tools neben den coreutils ist für mich ssh, da man damit extrem flexibel ist. Von überall her ist man ohne grossen Aufwand auf einem beliebigen Rechner und arbeitet damit genau gleich, als wäre man lokal am Gerät. Ok, das wissen die meisten wohl bereits. Es gibt aber noch ein paar Dinge, die einem das Leben mit ssh noch einfacher machen, davon soll dieser Beitrag handeln.

Authentifizerung mit Public-Key (in 2 Schritten)

Als erstes braucht man natürlich ein Schlüsselpaar, dies erstellt man mit ssh-keygen Wer mutig ist kann das Passwort auch einfach leer lassen. Für jeden Rechner, an dem man sich nun damit anmelden will, ist nur noch folgendes zu tun: ssh $host "mkdir -p .ssh; cat >> .ssh/authorized_keys" < .ssh/id_rsa.pubDabei wird auf dem Server das entsprechende Verzeichnis erstellt, falls es noch nicht existiert und danach unseren Public-Key angehängt. Das wars schon! Wenn man das Passwort (für den Schlüssel) nicht jedes Mal eintippen will, dann lohnt es sich, den "ssh agent" einzusetzen. Da dessen Konfiguration jedoch Distributionsabhängig ist, verzichte ich auf eine Erläuterung.

Konfiguration pro Host

Leider kann man sich den Usernamen, den man auf einem Rechner hat, nicht immer aussuchen. Natürlich könnte man sich immer mit user@host verbinden, aber das ist eigentlich unnötig, viel eleganter ist es, die Host-Spezifische Konfiguration in .ssh/config einzutragen. Bei mir sieht die Beispielsweise so aus:
Host dnd
HostName dnd.ch
User mstocker

Host r2
HostName r2.ifs.hsr.ch

Sollte eigentlich selbsterklärend sein. Für die Verbindung reicht nun ein 'ssh dnd' oder 'ssh r2'.

Tunnels

Wenn man einen mühsamen Admin hat, der einem alle möglichen Ports zumacht, kann man dies ziemlich einfach umgehen, und zwar mit local port forwarding.

Nehmen wir an, wir haben einen Laptop im HSR-Netz und würden gerne auf server1:8080 verbinden. Zuhause haben wir einen Rechner stehen, den wir per ssh erreichen können, und welcher auch server1:8080 errreicht. Mit folgendem Befehl wird nun ein Tunnel über den Server zu Hause nach server1:8080 erstellt: ssh -L 80:server1:8080 server_zu_hauseIm Browser über localhost:80 ist server1 nun erreichbar. Ist doch eigentlich ganz einfach!

Mit ssh kann man noch viel wildere Dinge tun, wie z.B. Reverse-Tunnels, mit denen man beispielsweise von zu Hause aus auf den PC im Büro zugreifen kann. Und seit OpenSSH 4.3 sind sogar ganze VPNs möglich...

Ich suche jemanden, der an die OOP 2008 geht und mir einen kleinen Gefallen tun könnte.. bitte schnell melden!