http://prezi.com/xareuaotwrho/high-performance-architecture/

• Dan Kegel on the C10K problem >20 Seiten, viele interessante Links. ftp.cdrom.com auf 1 Maschine (Kegel) mit > 10K gleichzeitigen Verbindungen (1999)
• Jeff Darcy on High-Performance Architecture ~ 6 Seiten über auf was man so achten muss
• C500k in Action at Urban Airship Blogartikel über (hybrid thread/evented/queue-based, NIO) Java-Server für 500K Verbindungen. Stichwörter: Comet, Push
• Russ Cox sagt, Threads vs. Events sei eine "nonsensical" question. Tolle slides!
  • Threads sind OK, aber Locking ist boese. Vorschlag einer einfachen Architektur mit Threads und Events:
    • Message-passing moves mutable state into single-threaded loop.
    • Isolierte Worker Threads.
  • Nette Geschichts-Anekdote über die Entstehung von Pipes (~ 1972) ab Slide 23
  • Slide über related languages/Erlang: (Erlang hatte ich in meinen Slides ganz vergessen)
    • Erlang is all message-passing, completely functional.
      • Developed at Ericsson telecom starting in late 1980s.
      • No way to create shared mutable data.
      • Used in many telecommunications apps, with one thread per call!
      • Starting to get traction for other network programming.
  • Lauer and Needham, 1979: On the Duality of Operating System Structures
    • Threads und Events sind zwei Seiten einer Medallie, und welches System man nutzt, hängt nicht vom Problem, sondern von dem System (der Maschine) ab, auf der man das Problem löst
• Why Events Are A Bad Idea (for high-concurrency servers) Rob von Behren, Jeremy Condit and Eric Brewer, HotOS 2003
• Video: Advanced Topics in Programming Languages: Concurrency/message passing Newsqueak Rob Pike May 9, 2007

Während Diskussion aufgekommen:

• LLVM Blocks
• Grand Central Dispatch
• Stackless Python
• Low latency X264
• Memcached

• Exkurs Memory-Allokator
  • Java/C# vs C - GC vs Malloc
  • Same page merging
  • Cache conscious, Cache oblivious
  • Deterministic Paged Skip List - Cache Conscious
• Wir sind uns einig: Bit indices sind cool.

Scrum als Prozess, damit man halt einen hat, wenn gleichzeitig ein nicht in den Prozess eingebundener Projektleiter feste Termine vorgibt, ist schwierig. Bei langfristigen Terminschätzungen kann man Dinge wie ein Refactoring eher mal dazwischen schieben.

• Das Team gibt die Geschwindigkeit vor
• Eine wichtige Aufgabe des Scrum Masters ist, den Druck vom Team weg zu nehmen und so dafür zu sorgen, dass das Team vernünftig arbeiten kann.
• „Story Points“ statt „Stunden“ unter anderem, damit unbegabte/störrische Projektleiter einen nicht auf eine grob geschätzte Zeit festnageln – Als Tool um Druck weg zu nehmen.
• Bei sehr engen Iterationen (1-Woche-Sprints z.B.) darf trotzdem Maintenance nicht ausfallen
• Buchempfehlung von Froh: Fergus O'Connell Fast Projects.
  • Tipp zum Umgang mit Zeitdruck von oben:
    • „Es dauert bis Dezember.“ (realistische Zeiteinschätzung)
    • - „Macht's bis Oktober.“ (Vorgabe)
    • „Wir probieren's.“ (d.h. das Commitment bezieht sich auf den Versuch)
    • Jeden Tag Projektplanung mit ETA abschließen: „Wir haben das und das geschafft, d.h. wir werden realistisch im Dezember fertig.“
    • ⇒ Nach einigen Tagen/Wochen sollte beim PM ankommen, dass er entweder etwas unfertiges im Oktober oder etwas fertiges im Dezember haben kann.
    • ⇒ Man muss aufpassen, dass man sich als Dev Team Lead nicht in die Rolle drängen lässt, schlecht da zu stehen, wenn man eine externe, unrealistische Vorgabe nicht einhält. Die eigene Schätzung war OK, dass eine unrealistische nicht eingehalten werden kann ohne Abstriche, ist klar.
• Joe: Die „10:1“ Effektivitäts-Schätzung für Entwickler deckt maximal die Tagesform ab, realistisch ist eher mehr
• Frank: Oft wird unter Zeitdruck die optimistische Schätzung genommen und dann noch das Testing gekürzt / auf Unit Tests verzichtet. Man könne ja Überstunden machen zum Ausgleich. Aber selbst, wenn die bezahlt werden – Dass da keine Qualität rauskommen kann, ist klar.
  • Joe: Stimmt. In anderen Ingenieurs-Disziplinen sieht man den Produkten leichter von außen an, wenn sie nicht fertig werden; Das ist in der Informatik ein Problem.