Podcast: eBay's Architecture Principles

Vorgestern wurde ein sehr guter Beitrag bei Software Engineering Radio veröffentlicht. Dieses Mal kein Model-Driven Buzzword-Bingo, sondern ein Beitrag über die Architektur von eBay. Randy Shoup, ein eBay-Architekt, stellt vier Hauptideen vor:
- Partition everything
- Asynchrony everywhere
- Automate everything
- Design the system keeping in mind that everything fails at some time

Im Grunde sind es die klassischen Ideen für Internet-Scale Systems. Ähnliche Ideen werden auch vorgestellt in "On Design and Deploying Internet-Scale Services" , ein Paper über die Erfahrungen des Windows Live Server Teams.

Eine weitere, meiner Meinung nach zentrale, Idee wurde nicht in der Zusammenfassung genannt: Der teilweise Verzicht auf die ACID-Eigenschaften und verteilte Transaktionen, weil diese die Performance und Skalierbarkeit einschränken. Diese Idee wird auch von Pat Helland (damals Amazon, heute (wieder) Microsoft) in "Life beycond Distributed Transactions: An Apostate's Opinion" ausgeführt.

Wirklich ein hörenswerter Podcast-Beitrag.

Bei InfoQ gibt es auch ein Video über das gleiche Thema.

Mac-Cluster an Virginia Tech

Da im PC^2 eh jeder Mitarbeiter einen Mac zu haben scheint, wäre es doch nur konsequent den Weg von Virginia Tech zu folgen, oder? 29 TeraFlop sind auch ein bisschen mehr als die 2,6 TeraFlops des Arminius-Clusters.

Podcast-Liste

Podcasts sind eine nette Sache auf langen Zugfahrten, im Bus, auf eine CD gebrannt auch im Auto. Vor Urzeiten (ca. 2 Jahre oder so) hab in schon mal eine Liste der Podcasts gepostet, die ich regelmäßig höre. Zum einen hat die Liste den Servercrash nicht überlebt, zum anderen dürfte sich die Liste auch total gewandelt haben.

Derzeit höre ich:

• The Java Posse: Ein richtig guter Podcasts von 4 Java-Gurus über aktuelle Java (+ Umfeld wie Andriod)-News, Diskussionen und Interviews. Es lohnt sich mal die gesamte Liste alle Folgen zu überfliegen. In den Archiven verstecken sich reichlich Schätze in Form von Interview mit z.B. Josh Bloch, Gavin King (Hibernate), Bill Pugh and Brian Goetz, Martin Odersky (Scala), (Crazy) Bob Lee (Guice), usw.
  "The Java Posse" ist (oder wird langssam) eine Größe in der Java-Welt. Immerhin veranstalten sie ihre eigene OpenSpace-Konferenz (Java Posse Roundup) und haben auch eine Diskussions-Session auf der JavaOne-Konferenz (nächste Woche).
  
  
• Semi-Coherent Computing: Ein sehr professionell gemacher Podcast von "The Register" zu Datacentern und Datacenter-Technologien.
  
  
• 
  Software Engineering Radio: Ein Podcast zu allen Themen des Software Engineering. Wirklich interessant und hat oft einen breiteren, sprachunabhängigen Blickwinkel. Manchmal etwas - naja, Buzz-Word getragen: Ich persönlich kann SOA einfach nicht mehr hören.
  

  Wirklich cool (aber nur am Rand SE bezogen) fand ich das Interview zu Microsofts Forschungsbetriebssystems Singularity, dass z.B. durch Codeanalyse sicherstellt, dass ein Objekt niemals von zwei Prozessen referenziert werden kann. Dadurch kann komplett auf Speicherschutz verzichtet werden. Eine recht typische Folge ist "Fault Tolerance with Bob Hanmer"
  

• Philosophy Bites: Von Philosophy Bites habe ich bisher erst eine Folge gehört (gestern abend auf dem Heimweg vom Grillen!): "Richard Reeves on Mill's On Liberty". Aber es war eine richtig schöne Zusammenfassung on Mills Philosphie der Freiheit. Ich hab selten ein Buch mit einem höheren "Intelligente Gedanken pro Seite" Wert gelesen: Ja, ich mag Mill, allem Utilitarismus zum Trotz. Gerade in Zeiten in denen die Politik (insbesondere die Grünen und Frau von der Leynen, aber im Grunde das gesamte Spektrum) den Menschen vorschreiben wollen wie ein gutes und richtiges Leben auszusehen hat, ist Mill IMHO kaum zu überschätzen.
  
  
• J!Cast: J!Cast ist ein Jura-Podcast zum Informations-, Telekommunikations- und Medienrecht. Auch halbwegs verständlich für den interessierten Laien wie mich.
  
  
• Chaosradio Express: Interviews zu vielen total verschiedenen meist technischen, teilweise aber auch politischen Themen von Hubschraubern. Oft sehr interessant, aber meist zu lang für meinen Geschmack (über 2 Stunden).
  

Writing Code not beneath a Gentleman Engineer

Brian Cantrill (Entwicker von DTrace) schrieb in seinem Blog:

We suffer — tremendously — from a bias from traditional engineering that writing code is like digging a ditch: that it is a mundane activity best left to day labor — and certainly beneath the Gentleman Engineer. This belief is profoundly wrong because software is not like a dam or a superhighway or a power plant: in software, the blueprints _are_ the thing; the abstraction _is_ the machine.

Ich werde in der Universität oftmals komisch angesehen, wenn ich sage, dass in 10 Jahren noch Code schreiben will. Es kommt eben darauf an z.B. welchen Code bzw. Code wofür.

Keine Festival-Karten an der FÜ

In den vergangenen Wochen hab ich mit verschiedenen Freunden und Bekannten in der Fürstenallee (FÜ / FA / F-Gebäude) darüber gesprochen, dass der Uni-Mainstream oftmals zu tut als würde die FÜ nicht existieren.

Ein Beispiel war immer die fehlende Möglichkeit Uni-Party-Karten zu kaufen, insbesondere wenn es um die "große, offizielle" Uni-Party ging: dem Asta-Sommerfestival. Karten gab es an dem Uni-Campus, aber niemals an der Fürstenallee. Obwohl es viele Studenten (viele aus der Informatik und E-Technik in den höheren Semestern) gibt, die quasi niemals am Campus sind.

Ich hab bei der letzten Wahl gehofft, dass sich dieser Misstand legt, wenn wir genug Informatiker in das StuPa wählen, aber geändert hat sich nichts. Vermutlich hängen da immer noch genug Geisteswissenschafter im 20. Semester rum, die nichmal wissen, dass die FÜ existiert.

Heute hat die Fachschaft eine Mail herumgeschickt, die ich einfach mal kommentieren möchte:

Der Verkauf der Sommerfest-Karten an der Fürstenallee wurde uns [von der "Uni"]
verboten und wir mussten mit Kasse und Karten wieder abziehen.

Dass der AStA nicht von sich aus früh genug einen Verkauf an der
Fürstenallee einplant, obwohl das offizieller Standort der Uni ist und
viele Studierende sich gar nicht am Campus aufhalten halte ich für
traurig genug, dass uns der Verkauf dann verboten ist sollte aber eine
einmalige Sache sein.

Das die AStA es nicht packt, die FÜ ordentlich in den AStA-Teil des "Stundenleben" einzubinden, ist tatsächlich traurig. Schließlich sind wir (FÜ-Bewohner) genauso Teil der verfassten Studentenschaft. Der Kartenverkauf ist da eher ein Beispiel von vielen.

Schon die jetzige Planung - dass die Fachschaft Informatik selbst den Verkauf übernimmt und organisiert - war eher eine Minimallösung. Das nun nichtmal diese Minimallösung möglich ist, ist bitter.

• Warum erlaubt die Universität den Verkauf und die Veranstaltung am Campus und verbietet den Verkauf im F-Gebäude. Kann man von Informatiker-Diskriminierung sprechen?
• Wer genau hat dies verboten? Universitätsleitung oder der AstA?
• Gibt es eine zitierfähige Begründung für diesen Unsinn?

Zum Glück habe ich mich nicht darauf verlassen und habe schon am Dienstag (als ich einmal zufällig im Campus war) meine Karte gekauft.

IBM kauft Daten-Deduplication-Firma

Wie Golem berichtet hat IBM die Daten-Deduplication-Firma Diligent gekauft. Laut dem Bericht für vermutlich 200 Millionen Dollar.

Das Thema meiner Masterarbeit ist tatsächlich sehr heiß. Auch wenn ich die damalige Bemerkung "akademisch bisher kaum behandelt" nicht mehr so stehen lassen kann. Dafür ist meine To-Read-Liste bei CiteULike langsam zu lang geworden.

Pre-VKrit: Parallel Programming in Java

Ein Mitarbeiter der AG Kastens hat mich heute von meinem angestammten Arbeitsplatz (F1-Freifläche) verjagt. So richtig begeistert war ich nicht davon. Aber es ist das Zeichen, dass die Vorlesung "Parallel Programming in Java" gestartet ist ("Funktionale Programmierung" ist ja leider doch abgesagt worden).

Vor knapp einem halben Jahr hab ich in einer kleinen Artikelserie geschildert, warum ich von der Behandlung von paralleler Programmierung in "Grundlagen der Programmierung 2"(GP2) nicht richtig begeistert gewesen bin. Programme, mit denen Studenten parallele Programmierung beigebracht werden soll, sollten zumindest thread-safe sein und möglichst den empfohlenen Wegen entsprechen. Zum Beispiel wurde java.util.concurrent komplett ignoriert. Diese Artikel sind aber leider bei dem Server-Crash verloren gegangen.

Aber der "Rauswurf" hat mich auf die Idee gebracht Kastens-Material mal anzusehen. Ich nenne es mal "Pre-VKrit", aber im Grunde ist es nur ein Durchsehen der Vorlesungsfolien. Aufgefallen ist mir folgendes:

• Es geht mit bei dem bekannten DigiClock-Beispiel los, dass in GP2 daneben gegangen ist. Hier wurde aber die running-Variable als "volatile" deklariert. Damit ist das Programm dann auch thread-sicher. Es gibt immer noch Varianten, die für den Zweck einen Block in bestimmten Zeitintervallen auszuführen, die vielleicht besser sind (z.B. ScheduledThreadPoolExecutor), aber immerhin ist es thread-sicher es auf diese Weise zu machen.
• Auf Folie 25 wird java.util.concurrent vorgestellt und das locks-Unterpackage näher besprochen. Insbesondere wird fett markiert, dass die dort zu findenden Lock-Implementierungen die gleichen Speichersemantik haben wie die normale Synchronisation. Leider wird die Semantik des Speichermodells im Rest der Vorlesung mit keinem Wort erwähnt. Keine Ahnung, wieso man fett hervorhebt, dass zwei Konstrukte, die gleiche Speichersemantik haben, wenn man diese Speichersemantik nicht vorstellt.
• Die InterruptedException wird immer noch durchgängig sinnlos verwendet (catch (InterruptedException e) {}). Brian Goetz sagt in "Java Concurrency in Pratice", dass man mit einer InterrupedException vieles machen kann, aber man sollte sie niemals fangen und nur ignorieren.

Aber ansonsten fand ich die Folien jetzt recht gut. Ich würde sie hören, wenn nicht mein Softwaretechnikteil schon lange "voll" wäre. Die Vorlesung relativ stark ausgerichtet auf Datenparallelismus, wie sie im High-Performance-Computing wichtig ist, (Loop Transformation, etc) und weniger auf andere Muster wie parallele Programme strukturiert werden könnten (Active Object, Reactor, Fork-Join, etc.). Eine eher "Doug Lea"-orienterte Vorlesung hätte ich es spannender gefunden, aber auf Grund des PC^2 "in der Nähe" ist es wohl auch eine nachvollziehbare Schwerpunktsetzung.

Wer sich für das Thema interessiert und einen vielleicht etwas anderen Blickwinkel wünscht, sollte sich "Doug Lea: Concurrent Programming in Java" und "Java Concurrency in Practice" von Brian Goetz, Doug Lea, Josh Bloch und anderen aus der Bibliothek besorgen. Doug Leas Buch ist ist älter (2000, insbesondere pre-1.5), sehr muster-orientiert (aber kein Muster-Buch wie POSA2) und wirklich gut. Brian Goetz fügt insbesondere eine ausführliche Behandlung des "neuen" Java 1.5-Speichermodells hinzu und bespricht unter starker Berücksichtigung des java.util.concurrent-Paketes wie moderne, parallele Java-Programme strukturiert werden könnten. Das "JCiP"-Buch fand ich einfacher zu lesen.

Sopra: Softwarequalität bewusst niedrig gehalten

Ich schreibe gerade an einen Artikel über das "Softwaretechnikpraktikum" an der Universität Paderborn und wollte eigentlich begründen warum ich die alte Aufgabenstellung ("Shuttle-Simulation") trotz all der Probleme besser finde als die neue Aufgabenstellung ("dSpace Systemdesk").

Dazu lese ich gerade auch den Artikel "Ein verbessertes Softwaretechnikpraktikum: Zwischen grüner Wiese und Legacy-Systemen" in dem Björn Axenath und Stefan Henkler ihre Neukonzeption beschreiben. Vielleicht muß ich mir das nochmal überlegen.
Geschockt war ich als ich laß (Hervorhebung von mir):

In den letzten Jahren wurde den Studenten der undokumentierte Code eines komplexen, verteilten Systems [die Shuttle-Simulation] gegeben. [...]
Für einen Großteil der Studenten war dies die erste Begegnung mit einem großen Softwaresystem. Da es sich um ein Legacy-System handelte, war die Qualität bewußt niedrig gehalten.

Was? Bewusst?
Das ein System mit den Jahren verkümmert, kann ich ja noch irgendwie verstehen. Die bekannte Liste "realer" Architekturtypen von Brian Foote und Joseph Yoder (Big Ball of Mud) sind gleichzeitig Zeugniss und Warnung davor. Ich bin immer davon ausgegangen, dass dies eben unabsichtlich passiert ist, weil sich niemand um die Qualität gekümmert hat. Mein Eindruck war damals, dass es am Anfang durchaus als gutes System entwickelt wurde (z.B. konnte man die Überreste eines State-Pattern finden, wenn man genau hingeguckt hat) und die Qualität aber den späteren Entwicklern stumpf egal war.

Aber ein bewußt meises System zu entwickeln und frischen Studenten vorzusetzen, ist doch so ziemlich das Schlimmste was man machen kann: Das ist Anti-Code-Reading. Und wir wundern uns über die meise Softwarekonstruktionsfähigkeiten von Absolventen. Wo sollen sie es den gelernt haben, wenn selbst im berühmten Elfenbeinturm kein "Vorbild" vorgesetzt wird?

Sopra: Softwarequalität bewusst niedrig gehalten

Ich schreibe gerade an einen Artikel über das "Softwaretechnikpraktikum" an der Universität Paderborn und wollte eigentlich begründen warum ich die alte Aufgabenstellung ("Shuttle-Simulation") trotz all der Probleme besser finde als die neue Aufgabenstellung ("dSpace Systemdesk").

Dazu lese ich gerade auch den Artikel "Ein verbessertes Softwaretechnikpraktikum: Zwischen grüner Wiese und Legacy-Systemen" in dem Björn Axenath und Stefan Henkler ihre Neukonzeption beschreiben. Vielleicht muß ich mir das nochmal überlegen.
Geschockt war ich als ich laß (Hervorhebung von mir):

In den letzten Jahren wurde den Studenten der undokumentierte Code eines komplexen, verteilten Systems [die Shuttle-Simulation] gegeben. [...]
Für einen Großteil der Studenten war dies die erste Begegnung mit einem großen Softwaresystem. Da es sich um ein Legacy-System handelte, war die Qualität bewußt niedrig gehalten.

Was? Bewusst?
Das ein System mit den Jahren verkümmert, kann ich ja noch irgendwie verstehen. Die bekannte Liste "realer" Architekturtypen von Brian Foote und Joseph Yoder (Big Ball of Mud) sind gleichzeitig Zeugniss und Warnung davor. Ich bin immer davon ausgegangen, dass dies eben unabsichtlich passiert ist, weil sich niemand um die Qualität gekümmert hat. Mein Eindruck war damals, dass es am Anfang durchaus als gutes System entwickelt wurde (z.B. konnte man die Überreste eines State-Pattern finden, wenn man genau hingeguckt hat) und die Qualität aber den späteren Entwicklern stumpf egal war.

Aber ein bewußt meises System zu entwickeln und frischen Studenten vorzusetzen, ist doch so ziemlich das Schlimmste was man machen kann: Das ist Anti-Code-Reading. Und wir wundern uns über die meise Softwarekonstruktionsfähigkeiten von Absolventen. Wo sollen sie es den gelernt haben, wenn selbst im berühmten Elfenbeinturm kein "Vorbild" vorgesetzt wird?

Die Prüfungsordnung: Vertiefungsprüfung

Wie ich schon am 1. April geschrieben habe, ist am 9. April meine Vertiefungsprüfung im Masterstudiengang.

Die Vertiefungsprüfung im Masterstudiengang, oder "Abschlussprüfung" wie sie offiziell heißt, ist ausführlich festgelegt in §14 (4) Satz 1 und 2 festgelegt Master-Prüfungsordnung:

1. drei studienbegleitenden Modulprüfungen im Vertiefungsgebiet; eins dieser Module ist in
der Regel das Modul Projektgruppe mit einer dem Vertiefungsgebiet zugeordneten
Veranstaltung (26 Leistungspunkte), die beiden anderen bzw. gegebenenfalls alle drei
Module sind Wahlpflichtmodule mit einem Umfang von 8 Leistungspunkten,
2. einer mündlichen Abschlussprüfung über die Zusammenhänge der Inhalte aus den drei
Modulen unter Nr. 1

und §19 (2)

Die Gesamtnote errechnet sich aus dem gewichteten Durchschnitt der Noten aus [cut, siehe auch]. Dabei wird abweichend von den in § 16 Abs. 4 festgelegten Leistungspunkten die Projektgruppe mit 8 Punkten, die Abschlussprüfung mit 16 Punkten und die Masterarbeit mit 50 Punkten gewichtet.

Ende! Das wars. Mehr Festlegungen gibt es nicht bzw. mehr offizielles und öffentlich festgelegtes konnte ich nicht finden. Ich bin ja durchaus gegen diese "Hochschule als Verwaltungsorgan des Landes"-artige Überreglementierung, aber dies ist schon etwas arg wenig. Für 16 ECTS-Punkte also soviel wie 4 Master-Vorlesungen ist dies sehr viel Unklarheit!

Nur wenig mehr Klarheit besteht bei dem Begriff "Vertiefung" also den Veranstaltungen deren Zusammenhang Thema der Vertiefungsprüfung ist. Wie oben zitiert wurde, besteht die Vertiefung "in der Regel" aus
- der Projektgruppe
- zwei Modulen mit insgesamt vier Veranstaltungen davon mindestens einem Seminar (§16(7)).
All diese Veranstaltungen und die Projektgruppe müssen aus dem gleichen Informatikgebiet (SWT, ESS, MUA, MMWW) kommen (§16(2)).
Diese Variante ist wohl der Standardfall. Bei mir ist dies die Projektgruppe "ORCOS", das Seminar "Rechnernetze" bei Prof. Karl, "Betriebssysteme" bei Prof. Rammig, "Architektur paralleler Rechnersysteme" bei Jens Simon und "Speichersysteme" bei Andre Brinkmann.

Wenig bekannt ist die Alternative mit drei "normalen" Modulen aus dem Vertiefungsgebiet. Das "in der Regel" kann man dann getrost vergessen. Die Projektgruppe gilt dann als normales Modul in einem der anderen Bereiche und ersetzt das normale Module dort. Wichtig, die Projektgruppe muss dann dort eingebracht werden. Der Gesamt-"Workload" bleibt der Gleiche. Zum Beispiel könnte man eine Projektgruppe im Bereich "Modele und Algorithmen" machen, nichts anderen in dem Bereich und dann "Mensch-Maschine-Wechselwirkung" als Vertiefungsgebiet wählen und dort 6 Veranstaltungen absolvieren. Das Beispiel ist arg theoretisch, denn es gibt bekanntlich (in diesem Semester) keine Projektgruppe bei den "Theoretikern".

Laut Auskunft des Prüfungssekretariats muss man selbstständig einen Termin mit zwei Prüfern aus der Gruppe der Veranstalter der Vorlesungen im Vertiefungsgebietes vereinbaren und eine gewisse Frist vorher beim PrüfSek schriftlich anmelden. Dabei soll mindestens ein Prüfer auch Professor sein.
Die Rechtsgrundlage für diese Festlegungen sind mir nicht klar. Wie ist es geregelt, wenn kein Termin organisiert werden kann? Was passiert, wenn ich in meinen Vertiefungsveranstaltungen keinen Professor gehabt habe (schwierig, aber theoretisch denkbar?). Diese Fragen sind unklar.

Die wichtigste Unklarheit bleibt der Inhalt der Prüfungen:
Zur Erinnerung: "Abschlussprüfung über die Zusammenhänge der Inhalte" ist alles wir haben. Dies ist aber auch der entscheidende Unterschied zur DPO4-Vertiefungsprüfung. Es geht (mehr) um die Zusammenhänge zwischen den Inhalten der Veranstaltungen.

Meine Empfehlung ist mit den Prüfern vorher zu sprechen. Dies ist üblich und wirklich ratsam. Mit viel Glück schränken sie den Stoffumgang auch noch etwas ein.

Eine wichtige Frage ist der Umgang mit Seminaren. Muss man "fit" in allen Seminarthemen sein, oder reicht es wenn man sein eigenes Thema kennt. Dies handhaben die Prüfer wohl jeweils anders. Auch ist nicht in dem Fall sichergestellt, dass auch jeder Teilnehmer Zugang zu allen Ausarbeitungen hat.

Wichtig ist, auch die Prüfer daran zu erinnern, dass es sich um Prüfungen im Master handelt. Prof. Karl hat mir zwar mal gesagt, dass es mittlerweile jedem Prüfer glasklar sein sollte worin der Unterschied besteht. Aber ich bin zu lange an der Uni Paderborn, um daran nicht hin und wieder meine Zweifel zu haben.

Am 9.4 um 15:30 bis 15:45 kann ich mehr berichten.

Disclaimer: Bitte in Zweifelsfällen immer nochmals bei den verantwortlichen Stellen nachfragen. Ehrlich!

Google: Search tomorrow's web, today! (SPOILER)

Google Österreich hat ein neues Feature auf die Hauptseite der Suchmaschine eingebaut - gDay - Die Suchergebnisse von morgen:

The core technology that powers gDayâ„¢ is MATEâ„¢ (Machine Automated Temporal Extrapolation).

Using MATE’s™ machine learning and artificial intelligence techniques developed in Google’s Sydney offices, we can construct elements of the future.

Google spiders crawl publicly available web information and our index of historic, cached web content. Using a mashup of numerous factors such as recurrence plots, fuzzy measure analysis, online betting odds and the weather forecast from the iGoogle weather gadget, we can create a sophisticated model of what the internet will look like 24 hours from now.

We can use this technique to predict almost anything on the web – tomorrow’s share price movements, sports results or news events. Plus, using language regression analysis, Google can even predict the actual wording of blogs and newspaper columns, 24 hours before they’re written!

Das hat mich sofort an diesen H. Maurer erinnert, ein österreichischer Informatik-Professor, der schon sehr skurrile Thesen vertritt, die zu diskutieren dies aber das falsche Blog ist (und ich vielleicht der falsche Autor). Nur als Kostprobe: Er hält, laut einem GI-Artikel von letztem August, Google in unredlicher Zusammenarbeit mit Wikipedia für die mächtigste Organisation aller Zeit(!). Mächtiger als die Kirche im Mittelalter, Mächtiger als <da fällt mir noch eine ganze Menge ein>, Wow!

--- SPOILER WARNUNG---

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".

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?

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

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.

Buchtipp: Programming Collective Intelligence

Meine neueste Buchanschaffung und Buchtipp ist
"Programming Collective Intelligence" von Toby Segaran.

Was der Titel elegant verschweigt (vielleicht um potenzielle Käufer nicht abzuschrecken): Das Buch ist Machine-Learning angewendet auf moderne Web-Anwendungen. Das Inhaltsverzeichnis offenbart dies sehr deutlich. In dem Buch werden behandelt:

• Clustering (Item-based und Hierachisches)
• Künstliche Neurale Netzwerke
• Stochastische Optimierung (Hill-Climbing, Simulated Anneling, etc)
• Support Vector Machines
• Naive Bayesian Classifier
• Decision Tree Learning
• Genetic Programming
• Nicht-negative Matrix Faktorisierung

Dies ist schon eine ziemlich beeindruckende Liste von Verfahren. Viel mehr steht im "Mitchell" auch nicht.

Eine Besonderheit des Buches ist die absolute Abwesenheit von Pseudocode. Jeder Algorithmus wird in lauffähigen Python-Code dargestellt. Bei einigen komplexeren Ansätzen finde ich Pseudocode immer noch lesbarer, aber so sinkt die Hürde mit den Algorithmen direkt "zu spielen" ungemein.

Hinzu kommt, dass für jeden Ansatz auch immer praktische Beispiele für das Web angegeben werden. Es werden u.a. Empfehlungen auf Basis von del.icio.us-Daten gegeben, Personen auf Facebook gematcht und Preise auf eBay geschätzt. Alles extrem aktuelle Anwendungen inkl. Input (meist: HTTP-Request and Rest-Webservice und XML parsen) und Output z.B. ein Entscheidungsbaum als Image exportieren) der Ansätze, die in Python-Code dargestellt werden.

Ein weiteres Highlight des Buches z.B. im Vergleich zur Vorlesung "Maschinelles Lernen" ist in meinen Augen die Diskussion über die Auswahl und Parametrisierung der Ansätze. Es wird dargelegt, wann welcher Ansatz möglicherweise bessere Ergebnisse liefert, aber auch welche Auswirkungen Parameter haben und z.B. auch die tendenziellen Unterschiede zwischen Gini-Koeffizienten und Entropy beim Entscheidungsbaum-Lernen. In der Vorlesungen werden die Verfahren zwar skizziert, aber es gibt keine Beispiele realistischer Größe oder andere Hilfestellungen. Dies ist in der Form auch nicht unbedingt Aufgabe der Vorlesung. Ich sehe das Buch deshalb komplementär zur Vorlesung.

Diesen Zweck erfüllt das Buch meiner Meinung nach hervorragend und es macht Lust die Beispiele sofort zu nehmen, auszuführen und weiterzuentwickeln.

Allerdings sind einige Ansätze schon ziemlich abgefahren - Wird genetische Programmierung tatsächlich irgendwo eingesetzt? Auch habe ich teilweise das Gefühl, dass mehr Hintergründe/Theorie notwendig sind, um einige Ansätze auf neue Probleme anwenden zu können. Ob für Entwickler ohne Informatik-Background eine 2-seitige Einführung in Lineare Algebra ausreicht, um nicht-negative Matrixfaktorisierung auf andere Problemen anwenden zu können, bezweifele ich.

TR: A Pattern Language for Overlay Networks

Durch Zufall bin ich auf ein interessantes Paper zum Softwareentwurf von Peer-to-Peer-Systemen gestoßen: "A Pattern language for Overlay Networks - Design Patterns in Peer-to-Peer Systems " von Dominik Grolimund, ETH Zurück und heute Entwickler des P2P-Storagesystems Wua.la.

Durch eine Untersuchung des Quellcodes von zahlreichen Open-Source-P2P-Systemen aus dem praktischen und dem akademischem Umfeld (von LimeWire über Bamboo to FreePastry) hat der Autor des technisches Berichtes erfolgreich verwendete Lösungen für häufige Entwurfsprobleme (Pattern) extrahiert. Die Pattern gliedern sich in die Abschnitte "Application Interaction", "Messages", "Message Handling", "Routing", "Local Node", "Protocol", "Remote Node" und "Network Interaction".

Ich finde den Artikel schon deshalb interessant, weil er sich mit dem Softwaredesign von P2P beschäftigt. Normalerweise liegt der Fokus in dem Bereich quasi ausschließlich auf dem Systementwurf. Aber reale Systeme mit der hohen Komplexität brauchen auch ein angemessenes Softwaredesign.

Da Algorithmen für Sensornetzwerke aus der Softwaredesignperspektive eine hohe Ähnlichkeit mit Peer-to-Peer-Systemen (aus Systemdesignsicht ist dies so nicht der Fall, aber auch dort existieren Gemeinsamkeiten) ausweisen, wäre der technische Bericht auch in der Projektgruppe hilfreich gewesen. Wir müssen zwar nichts "real" implementieren (Pattern wie "Abstract Node Handle" sind dann nicht notwendig), aber viele der Pattern wären auch in den simulierten Algorithmen und den verwendeten Simulator sinnvoll einsetzbar gewesen. Zu spät.

P.S. In der Sidebar dieses Blogs werden nun auch neben meinen öffentlichen del.icio.us Bookmarks (RSS) auch die öffentlichen CiteULike-Bookmarks (RSS) aufgelistet. Die automatisch generierten del.icio.us-Artikel wird es nicht mehr geben.

HNF-Ausstellung: Fahren ohne Fahrer

Am Sonntag startet die neue HNF-Sonderaustellung "Fahren ohne Fahrer".

Es ist schon ein paar Jahre her, dass ich in dem Museum gewesen bin, obwohl ich quasi jeden Tag vor dessen Tür her gehe. Aber diese Austellung muß ich sehen!

Schon alleine wegen "Stanley", dem Gewinnerauto des "Grand Challenge"-Wettbewerbes. Auf der Webseite heisst es dazu:

Das Heinz Nixdorf MuseumsForum zeigt vom 9. Dezember bis 24. Januar zwei Modelle, die ohne Fahrer hinter dem Lenkrad auskommen. Der VW Touareg „Stanley" hat Technikgeschichte geschrieben und als erstes Auto vor zwei Jahren die „Grand Challenge" gewonnen. 23 Fahrzeuge waren für das Rennen zugelassen worden, weniger als ein Viertel erreichten nach 220 Kilometern durch die Mojave-Wüste das Ziel. Als zweites Auto präsentiert das HNF den Golf GTI 53+1, dessen Name auf den berühmten Filmkäfer verweist. Er ist in der Lage, einen Hütchenparcours ohne Fahrer schneller zu fahren als mit.

Zur Einstimmung nochmal das "Winning The DARPA Grand Challenge"-Video: Coole Fahrszenen und einige Skizzen der dahinter liegenden Machine Learning-Algorithmen.

Wer kommt mit?

ACM Studie: Universität Paderborn in Software Engineering weltweit auf Platz 16

Pressemitteilung der Universität:

Die Universität Paderborn ist die Nummer 1 der Software-Institute in Deutschland und nimmt auch international eine Spitzenposition ein", so Prorektor Prof. Dr. Wilhelm Schäfer vom Institut für Informatik. Dies belege ein aktuelles Forschungs-Ranking, das gerade von der renommierten Association for Computing Machinery (ACM) veröffentlicht wurde.

In der aktuellen Ausgabe der Zeitschrift Communications of the ACM (Juni 2007) werden die Top 50 Institute im Bereich Software Engineering weltweit bewertet. Die Universität Paderborn belegt dabei einen hervorragenden 16. Platz und ist so mit Abstand das beste deutsche Institut. Lediglich die Universität Karlsruhe (Platz 29) und das Fraunhofer-Institut für experimentelles Software-Engineering (IESE) in Kaiserslautern (Platz 32) finden sich als weitere deutsche Einrichtungen in den Top 50. Im internationalen Vergleich liegt Paderborn z.B. noch vor der Stanford University. Auch in Europa zählt Paderborn zu den besten vier Instituten neben der Polytechnischen Universität Mailand und den beiden Londoner Universitäten Imperial College und University College.

Eine schöne Nachricht für die Universität.
Auch gerade jetzt kurz vor der Entscheidung über die Exzellenz-Cluster.
Bei aller Freude sollte man aber anmerken, dass der Artikel der ACM nicht (primär) ein Ranking ist, sondern eine Vorstellung einer neuen automatischen Methode zum Ranking. Ohne den Spaß verderben zu wollen, aber das ist ein Unterschied.

Unabhängig von diesem Makel ist es natürlich schön zu sehen, wenn die eigene Universität in der Forschung international mitspielen kann (oder zumindest so bewertet wird). Es liest sich schon beeindruckend:

1 Massachusetts Institute of Technology
2 Carnegie Mellon University
3 Georgia Institute of Technology
4 University of Maryland, College Park
5 Oregon State University
[...]
16 University of Paderborn
[...]
18 Stanford University
[...]
32 Fraunhofer-IESE, Germany

ZFS

Das ZFS-Dateisystem von Sun Microsofts wird im Solaris 10 Betriebssystem eingesetzt und wurde vor einiger Zeit auch als Open Source veröffentlicht.

Interessant (besonders wenn man diese Vorlesung gerade hört) ist ZFS vor allem deshalb, weil es alte Annahmen, die vor 15 Jahren ihre Berechtigung hatten, über Bord wirft.

Die Liste der Features wäre zu lang um sie hier aufzuzählen, aber u.a. bietet ZFS

• Ende-zu-Ende-Datenintegrität durch Transaktionen und Checksums
• Pooled Storage, dass Ende der festen Größenteilung von Dateisystemen (Dateisystem wächst und schrumpft je nach Bedarf)

Mehr Informationen zu ZFS allgemein gibt es in dieser Präsentation von Sun", die ganz unbescheiden ZFS als "The Last Word in File Systems" bezeichnet.
Einen kleinen Einblick in die Entwicklungsarbeiten an ZFS bietet dieser Bericht auf den Forschungsseiten von SUN.
Eine Anleitung wie man ZFS als "Filesystem in Userspace" betreibt findet sich im node-0-Blog.