Skalierbarkeit und "Ruby on Rails"

Twitter ist eine stark wachsende Web 2.0-Anwendung, die mit Rails entwickelt wurde.

Ich möchte mich hier gar nicht mit dem Sinn und Unsinn von Twitter beschäftigen, sondern ich möchte mich auf ein aufschlussreiches Interview mit dem Twitter-Entwickler Alex Payne verweisen in dem es auch um die Skalierbarkeit von Rails geht.
In dem Interview heisst es:

Twitter is the biggest Rails site on the net right now. Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.

The common wisdom in the Rails community at this time is that scaling Rails is a matter of cost: just throw more CPUs at it. The problem is that more instances of Rails (running as part of a Mongrel cluster, in our case) means more requests to your database. At this point in time there’s no facility in Rails to talk to more than one database at a time.

The solutions to this are caching the hell out of everything and setting up multiple read-only slave databases, neither of which are quick fixes to implement. So it’s not just cost, it’s time, and time is that much more precious when people can[’t] reach your site.

None of these scaling approaches are as fun and easy as developing for Rails. All the convenience methods and syntactical sugar that makes Rails such a pleasure for coders ends up being absolutely punishing, performance-wise. Once you hit a certain threshold of traffic, either you need to strip out all the costly neat stuff that Rails does for you (RJS, ActiveRecord, ActiveSupport, etc.) or move the slow parts of your application out of Rails, or both.

Dies hat mit der (Grundsatz-)Entscheidung des Ruby Entwicklers David Heinemeier zu tun, sich um Skalierbarkeit und Performance wenig Gedanken zu machen. Er gibt Entwicklern den Rat "Don’t scale".

Ein (in der extremen Form wie ihn David Heinemeier gibt) riskanter Rat wie Greg Linden in diesem Posting von 2005 argumentiert.

Sopra oder Swtpra

Gestern war die 1. Präsentation der von mir betreuten Gruppe im Softwaretechnikpraktikum und sie hat auf ihren Folien das Wort "Sopra" als Abkürzung verwendet und neben viel berechtigter Kritik und einigen Dingen über die man streiten kann, kam auch die Meta-Kritik bekommen die gültige Abkürzung für das Softwaretechnikpraktikum wäre "SWTPRA" und nicht "SOPRA". "SOPRA" wäre die Abkürzung für das Softwarepraktikum der Wirtschaftsinformatik und das sei etwas ganz anderes und die Gruppe sollte in Zukunft besser SWTPRA verwenden.

Mal ne kleine Umfrage unter den Lesern: Wie nennt ihr die Veranstaltung SWTPRA oder SOPRA?
Also ich habe noch nie gesagt, ich mache jetzt SWTPRA oder ich bin dieses Semster wieder SWTPRA-Tutor. Ich verwende immer SOPRA.

Aber lassen wir einfach Google entscheiden. Auf den Webseiten der Informatik findet Google für "sopra" 179 Einträe und für "swtpra" 70 Einträe.

Offizielle Unterlagen bestätigen den Google-Vergleich da: Im Modulhandbuch heisst es:

Softwaretechnikpraktikum (SOPRA):
Das Softwaretechnikpraktikum ist ein 6-stündiges Praktikum inklusive einer Vorlesung über Projektmanagement. Eine komplexe Softwareentwicklungsaufgabe wird im Team von ca. 10 Studierenden unter Verwendung von UML und Java bearbeitet. Schwerpunkte des Praktikums liegen in der Erfahrung einer teamorientierten Softwareentwicklung unter Benutzung marktüblicher Werkzeuge und Methoden (Rational Rose, Configuration and Version Management (CVS). Zu Beginn des Praktikums arbeiten sich die Studierenden anhand eines bereits in Teilen vorliegenden Quelltexts, der im Praktikum zu erweitern ist, in die Aufgabe ein und müssen diesen re-dokumentieren. Die Erstellung von Meilensteinplänen, ein teilweise durch die Studierenden zu übernehmendes Projektmanagement sowie die Anfertigung von Kostenschätzungen und die Protokollierung des Aufwandes durch Stundenzettel sind wesentliche Bestandteile, um die Praxisnähe des Projekts sicherzustellen.

Also ich kann es weiterhin "SOPRA" nennen. SWTPRA klingt einfach auch blöd.

Die Prüfungsordnung - Das unbekannte Wesen: Seminare und Proseminare

Die Prüfungsordnung ist die rechtliche Grundlage für das Studium und regelt die Rechte und Pflichten der Studenten und der Dozenten. Doch die meisten Studenten kennen die PO nur sehr wenig. In den meisten Fällen wird das Wissen nur über Mund-zu-Mund-Propaganda weitergegeben.
Schon der Vergangenheit bin ich in einigen Beiträen auf die Prüfungsordnung eingegangen. Diesmal möchte ich mir mit den Vorschriften für Seminare und Proseminare beschäftigen.
Seminare sind eine sinnvolle Art wissenschaftliches Arbeiten zu erlernen und die wissenschaftlichen Methoden zu vertiefen. Deshalb sind Seminare elementare Bestandteile des Informatikstudiums an der Uni Paderobrn.
Doch wieviele Seminar muß man im Informatik-Studium belegen? Wieviele darf man belegen?

Bachelor-Prüfungsordnung:
Ganz einfache Regelung: Es gibt keine.
Seminare oder Proseminare werden in der Prüfungsordnung gar nicht erwähnt.

Master-Prüfungsordnung:
Im Master ist dies sehr eindeutig in Artikel 16, Abschnitt 5 regelt:

Neben dem obligatorischen Seminar im Rahmen der Projektgruppe muss in einem Modul des Vertiefungsgebietet eine der Wahlpflichtveranstaltungen ein Seminar sein. In höchsten einem Wahlpflichtmodel [...] kann eine weitere Wahlpflichtveranstaltung ein Seminar sein.

"Die Silicon Valley Story" am 20. April auf Arte

Der geniale Verfilmung des Aufstieges der Firmen Apple und Microsoft - "Die Silicon Valley Story" (Orig: Pirates of Silicon Valley) wird am 20. April auf Arte ausgestrahlt.

Arte schreibt zu dem Film:

Der Fernsehfilm spielt in den Jahren, als zunehmend Computer für private Nutzungen entwickelt wurden. Die großen Rivalen waren damals Apple-Computer-Chef Steve Jobs und Microsoft-Gründer Bill Gates. Apple hatte gerade den Macintosh-Computer herausgebracht, der weitgehend auf den Forschungsergebnissen des Palo Alto Research Center von Xerox basierte. Microsoft vermarktete das Betriebssystem MS-DOS, Büro-Software wie Multiplan und zahlreiche Implementierungen der Programmiersprache BASIC. Der weltweite Erfolg von Apple II hatte die Firma Apple reich gemacht. Für eine erfolgreiche Vermarktung benötigte ihr neuer Mac die Programme von Microsoft. Daher stellte Apple der Firma Microsoft einen Prototyp ihres Computers zur Verfügung, da Microsoft zugesichert hatte, die Software weder zu untersuchen noch zu kopieren. Doch Microsoft suchte für sein Betriebssystem MS-DOS eine grafische Benutzeroberfläche mit Fenstern und Maus. Es kam zur Konfrontation zwischen den führenden Männern der beiden Unternehmen.

Ein Muß, zumal ich ihn noch nicht auf Deutsch gesehen habe. Leider ist die RC2-DVD von dem Film noch nicht veröffentlicht worden.

Tops und Flops der Vorlesungen

Hier mal rein subjektive meine Liste der fünf Top-Vorlesungen und Flop-Vorlesungen, die ich im Laufe der letzten sieben Semester besucht habe bzw. besuchen mußte.

Tops:

1. Konzepte und Methoden der Systemsoftware
   Prof. Karl hat seinen Weierstraß-Preis voll verdient.
2. Softwaretechnikpraktikum (alte Aufgabenstellung)
   Die mit Abstand aufwändigste, aber auch sehr interessante und lehrreiche Veranstaltung an der Uni. Mal angesprochen: Die alte Aufgabenstellung (Shuttle-Simulation) war um Längen besser als die neue. Bei der alten Aufgaben waren Fähigkeiten aus allen Bereichen z.B. auch Graphenalgorithmen und Approximationsalgorithmen notwendig, bei der neuen Aufgabenstellung sind nur noch SWT-Fähigkeiten gefragt.
3. Methoden des Algorithmenentwurfes
   Ich verstehe die Freude einiger Freunde von mir, weil Ulf-Peter Schröder nun die Vorlesung "Approximationsalgorithmen" anbietet und jeder hofft, dass dies "Algodesign " wird. Ich habe (leider) für die Vorlesung keine Zeit.
4. Rechnernetze
   Nochmal Karl. Was soll man sagen, er macht um eine Größenordnung bessere Vorlesungen.
5. Mathematik für Informatiker 1
   Angeblich nicht immer mathematisch formal (sagten mir zumindest Mathenebenfachler), aber sehr motivierender Stil. Ideale Einstiegsveranstaltung ins Studium

Flops:

1. Mathematik für Informatiker 3 - Stochastik
2. Wirtschaftsinformatik 1
3. Wirtschaftsinformatik 2
4. Operations Research II

P.S. Außer Konkurrenz ein Zitat aus einer Vorlesung: "Wenn das Programm weiß, dass die Berechnung nicht enden wird, kann es die Berechnung auch abbrechen".

Python-Frameworks im Vergleich

Die Webseite "jp’s domain" vergleicht in dem Artikel "Python web development and frameworks in 2007″ die Python-Webdevelopment-Frameworks Zope, Djangeo, Pylons and TurboGears nach verschiedenen Kritierien wie der

• allgemeinen Designphilosophie
• dem System zum URL Dispatching
• dem Templatesystem
• dem OR-Mapper
• der Formularverwaltung
• den Vor- und Nachteilen des Systems
• und den Zukunftserwartungen für des Framework

Over the past year or so I have spent a whole lot of time evaluating different web frameworks, trying to find what works best for me. Like many programmers, I am a bit of a perfectionist, but I am also a pragmatist. I want my tools to work absolutely right every time, and I want my tools to help me effectively get certain tasks done. However, if you’ve programmed much at all, you know that perfection isn’t something that you are likely to find, as perfection to one person is different to what perfection for another person is. In the end you can only pick what works best for you.

Compounding this decision process is the fact that in Python web development, there are quite a few choices.

Wintersemester zu Ende!

Eben ist mit meiner Prüfung zu "Algorithmen in synchronen Rechnernetzen" das Wintersemester zu Ende gegangen. Zeit für meine letzte VKrit.

Ich fand die Vorlesung von anderer Seite "überkritisiert". Sie war nicht perfekt, aber gut.

Die Übungsaufgaben waren jederzeit fordernd. Etwas über dem Schwierigkeitsgrad der Übungsaufgaben von "Methoden des Algorithmenentwurfes". Sie haben mir viele Ah-Erlebnisse beschert (zu viele davon aber erst in der Besprechung).

Die Vorlesung ist eine Standardvorlesung und sehr ausgereift. Dies bedeutet gleichzeitig, dass nichts wirklich "Neues" behandelt wird. Die aktuellste Quelle in der Literaturangabe ist von 1997.

Der größte Kritikpunkt ist, dass leider der Veranstalter (AG Monien) gar nicht mehr so sehr in dem Bereich aktiv ist und dies eher eine Vorlesung aus der Vergangenheit der AG ist. Entsprechend war die Motivation nicht immer optimal. Dies sollte man bedenken. Von der Motivation des Dozenten mitreißen lassen kann man sich in dieser Veranstaltung nicht.