Sunday, March 30, 2008

Quellcodeverwaltung Mercurial 1.0 freigegeben

Wie Golem die Woche berichtet hat, wurde die Version 1.0 von Mercurial freigegeben. Mercurial ist eine freie, verteilte Quellcodeverwaltung. Schon vor 1.0 wurde sie für zahlreiche Projekte verwendet. Die größten Projekte sind wohl die Sun-nahen Projekte wie NetBeans - by the way - Super RoR-Support - und OpenJDK.

Der größte Unterschied von einem verteilten Quellcodeverwaltungsystemen zu konventionellen wie Subversion ist (meinem Verständnis nach), dass ein Checkout (bei Mercurial Clone genannt) nicht fest mit einem Repository verbunden ist. Änderungen können kurzfristig im Repository A gesichert werden. Aber ein späterer Versionstand kann in eiem anderem Repository B gespeichert werden. Außerdem ist dort das erzeugen einer neuen Version durch Commit von dem Veröffentlichen dieser Änderung entkoppelt. Man kann lokal häufig committen, aber nur fertige Versionen können dann veröffentlich ("pull") werden. Im Mercurial-Wiki ist eine Beschreibung vorhanden.

Warum kann dies nützlich sein?
Zum Beispiel bei Uni-Projekten könnte (mit Mercurial) jeder Student mit seiner Bachelor- oder Diplomarbeit oder jede Gruppe von Studenten ein eigenes (privates) Repository erhalten mit dem er tälich oder stündlich Commits erzeugt. Aber nur funktionierende Versionsstände werden dann in das zentrale Hauptrepository geschoben.

Man könnte so etwas mit Subversion-Branches machen, aber selbst da ist jede "interne" Sicherung auf dem zentralen System sichtbar. Nicht so schön. Faktisch commiten Studenten tälich Zwischenstände ins zentrale Repository, was häufig zu Unannehmlichkeiten führt.* Oder sie arbeiten ohne Sicherung (Commit) bis zum einem Meilenstein, aber viel des Komforts einer Quellcodeverwaltung geht damit verloren. Und bei HD-Crashes verliert man nicht nur dem "Komfort".

In gewisser Weise sind verteilten Quellcodeverwaltungsysteme die dritte Stufe - nach zentralisierten, Sperr-basierten Systemen und zentralisierten, Merge-basierten Verfahren wie Subversion. Ein anderes verteiltes Quellcodeverwaltungssystem ist GIT, dass z.B. für den Linux-Kernel eingesetzt wird.

Ich selbst habe noch nicht mit veteilten Quellcodeverwaltungen gearbeitet, aber ich glaube, dass es z.B. in dem Uni-Kontext wirklich sinnvoll wäre. **

---

* Man kann eine Strategie fahren, dass man nur ein zentrales Repository mit häufigen Commits ohne Branches hat. In enggekoppelten Teams wie in Firmen ist dies wohl auch die Standardvariante. Aber bei lose-gekoppelten Teams wie bei Uni-Projekten ist dies wohl nicht die optimale Idee.

** Ebenfalls für den Einsatz für Studentenprojekten gedacht ist DrProject, eine Trac-Variante für "classroom usage".

Saturday, March 22, 2008

VKrit: Philosphie der Technik

Nachdem ich vor zwei Jahren die gute, interessante Vorlesung zur Sozialphilosphie gehört habe und ich noch Punkte für das Studium Generale brauchte, hab ich im letzten Semester die Vorlesung "Philosphie der Technik" von Prof. Peckhaus gehört. Da Prof. Peckhaus auch im Vorstand des "Heinz Nixdorf Institutes" sitzt, klang auch erstmal nicht schlecht.

Ich nehme die Verantwortung des Ingenieurs durchaus ernst und auch deshalb habe ich gedacht, es könnte interessant werden. Und wurde bitter enttäuscht.

Der absolute Fokus der Vorlesung lag auf extrem technik-kritischen Kräften wie Martin Heidegger und Hans Jonas. Zum Beispiel geht es bei Jonas laut der Vorlesung nicht mehr um eine Risikoabschätzung und Bewertung alleine. Wenn eine Technologie, Erfindung oder Tat größere negative Folgen haben könnte - egal mit welcher Wahrscheinlichkeit oder welchen Umständen, nur die Möglichkeit zählt - dann sollte man die Erfindung nicht tätigen, nicht in die Richtung forschen oder etwas nicht tun. Ich glaube nicht, dass ich das so falsch sehen wenn ich sage, dass man mit dieser Leitlinie kann man Forschung und Technikanwendung einfach komplett einstellen kann.

Irgendwie konnte ich mich nie dem Gedanken verwehren es geht doch mehr darum, dass "kapitalistsche (-technische)" System an sich zu kritisieren als mir als Ingenieur sinnvolles Handwerkszeug in die Hände zu geben.

Die Unterlagen waren ziemlich schlecht und können von der Qualität nicht ansatzweise mit den Unterlagen wie sie in der Informatik üblich sind mithalten. Dass die Klausur trotz (mit etwas Abstand gesehen) sehr einfachen Fragen gar nicht so gut ausgefallen ist, lag weder an der Komplexität des Stoffes oder den Studenten sondern an den Unterlagen. Ein roter Faden fehlte meiner Meinung nach zum Beispiel komplett.

Zumindest im letzten Monat wurde sehr oft mit Videobeiträen gearbeitet, wo zum Beispiel gezeigt wurde das für ein tolles, vorbildliches, weil untechnisiertes Leben Heidegger in den Alpen führte. Ist dass richtig in einer Universtätsvorlesung? Man braucht sich dann auch nicht mehr zu wundern, wenn die Lehramtsstudenten (die meisten waren aus der Schiene) diese "Technik" in den späteren Unterricht übernehmen.

Mein Fazit ist nie wieder, aber mein Studium Generalle ist seit Mittwoch auch "voll". Es gab nur einen Grund weiter zu der Vorlesung zu gehen und der hatte mit Kaffee zu tun.

Tuesday, March 18, 2008

Plagiate

In guter Regelmäßigkeit wird durch Hochschulen bemängelt, dass Studenten Teile von Seminararbeiten oder sogar Diplomarbeiten aus dem Internet abschreiben: Ein Plagiat.

Und ich sehe keinen Grund so etwas zu verteidigen. Es missachtet die Arbeit des originalen Autors, stellt dem Prüfer in Abrede dies zu entdecken zu können und unfair gegenüber Mitstudenten, die ehrlich ihre Leistung erbracht haben.

Aber ohne Zweifel gibt es dies auch in der anderen Richtung. Spiegel online berichtet von einem Fall bei der ein Professor die Arbeit einer Studenten unter eigenem Namen veröffentlicht hat.

Vielleicht kann mir da mal jemand erklären. Wie kommen Wissenschafter darauf geistige Schöpfung von anderen zu nehmen und unter eigenen Namen in die Welt zu tragen? Wo ist die wissenschaftlich Ethik geblieben?

Saturday, March 15, 2008

Seminararbeit Rechnernetze

In diesem Semester habe ich bei Professor Karl am Seminar "Rechnernetze" teilgenommen.

Meine Arbeit hat sich mit verteilten Hashtablen mit direkten Routing (One-Hop Distributed Hashtables) beschäftigt.

Abstract:

Distributed Hash Tables (DHT) are an important substrate of several peer-to- peer (P2P) applications. Most existing approaches favor a small memory and net- work overhead over lookup latency. New approaches question this tradeoff and allow a lookup with using only one hop, but they store the routing information for all nodes on each node in the system and so require higher background traffic to maintain the routing tables up-to-date. In this paper the design of three one-hop DHT approaches is described and compared in detail. This comparison shows that different assumptions are used to analyze the approaches. Therefore, several parameters are inspected and an uni- fied parameter setting is extract. Using the unified parameter setting, a fair and meaningful comparison of the approaches is possible. In particular, the bandwidth consumption, fault tolerance properties, the usage of heterogeneity in the P2P net- work, and the scalability are compared. The comparison shows that the unified parameter setting lead to different relative results as originally stated by the approach designers.

Download: PDF 1,2 MB

Tuesday, March 11, 2008

Jolt Award: Beautiful Code and Guice

Gerade bei der Java Posse gehört:

Das Buch Beautiful Code, dass ich vor ein paar Wochen empfohlen habe, hat einen Jolt Award 2008 gewonnen. Cool.

Wunderbar und höchst verdient: Das Dependency Injection Tool Guice hat ebenfalls einen Jolt Award gewonnen.

Durch Guice hatte ich die Idee für das neue Konfigurationssystem (das alte war im Grunde unbrauchbar) von Shox. Zuerst wollte ich Guice direkt verwenden, aber weil der Fokus doch stärker auf Konfiguration von Attributen lag, Dependency Injection dabei nur ein angenehmer Nebeneffekt war und ein paar Überlegungen mehr ist es dann doch zu dem @ShoxParameter System gekommen. Guice ist richtig, richtig cool.