Geschichte des Softwareengeerings

N. Wirth beklagt, dass Softwareengeering keine Disziplin wurde, auch weil sich kaum jemand für dessen Geschichte interessiere. Dann schreibt er (trotzdem) seine Geschichte zu dieser Geschichte.

Er beginnt nicht irgendwo und schon gar nicht am Anfang, sondern dort, wo seiner Meinung nach wichtige Weichen gestellt wurden, ohne dass der Zug darauf gefahren wäre. Er schreibt seine eigene Geschichte als Geschichte des Softwarengineerings.

Nur nebenbei: Ich habe ein paar Jahre lang seinen Studenten an der ETH etwas Computer-Geschichte unter soziologischen Gesichtspunkten vorgelesen. Er hat mich dann mal “eingeladen”, ihm meine Geschichte zu begründen, weil ihm diese Geschichte – oder was ihm davon zu Ohren kam – nicht passte. Jedenfalls mussten seine Studenten danach meine Vorlesung nicht mehr besuchen.

In seiner Geschichte sind Computer immerhin Maschinen. “Computer systems are machines of large complexity. This complexity can be mastered intellectually by one tool only: Abstraction.” Er meint, sie seien komplex, ich würde dagegen von kompliziert sprechen. Er sieht in der Geschichte drei Phasen, weil er drei Programmiersprachen entwickelt hat.

Dijkstra hat das stukturierte Programmieren erfunden. Deshalb hat er eine strukturierte Programmiersprache, nämlich Pascal entwickelt. Dann hat Parnas die Modularisierung erfunden. Deshalb hat er eine modulare Programmiersprache, nämlich Modula entwickelt. Und schliesslich hat Dahl die Objekte erfunden. Deshalb hat er Oberon entwickelt. Das sind die historisch guten Seiten der Entwicklung, aber die Entwicklung hat leider immer den schlechten Weg genommen.

Kaum war die Hardware massenfähig, wurden anstelle der Mainframes Kleincomputer mit Unix auf den Markt gebracht und damit verbunden die Programmiersprache C, deren Konzeptlosigkeit als Freiheit der Programmierer verkauft wurde. Kurze Zeit später wurde es noch schlimmer, weil mit den Windows und der Maus die Ansprüche an die Programmierung noch erheblich grösser wurden. Hinzu kam eine nicht kontrollierbare Entwicklung von OpenSource und durch das Internet die Apps in Java, was wiederum konzeptlose Programmiersprachen zu grosser Verbreitung geholfen hat.

Ein Hauptproblem sieht N. Wirth in der vermeintlichen Lösung des Problems, die darin besteht, dass die Hardware immer schneller und billiger wird und so unsauberes Programmieren immer mehr verzeiht und mithin unterstützt.

N. Wirth hat sozusagen eine reine Lehre, die sich nicht um vordergründige Bedürfnisse von Microsoft-verseuchten Benutzern kümmert und von den Programmierern viel mehr Denkarbeit verlangt, was allenthalben anhand von “goto” diskutiert wurde. L. Torvald entgegnete, dass N. Wirth den frigging clue auch nicht gefunden habe.

Ich wundere mich auf einer anderen Ebene. Wenn ich mich nicht um kommerzielle Zusammenhänge kümmere, sondern um mit N. Wirth zu sprechen, um akademische, dann verstehe ich die Begrenzung auf Softwareengineering nicht. Dann würde ich von Technologie sprechen und mich dabei um eine Begrifflichkeit bemühen, die in welcher das Softwareengineering als solches begriffen werden kann. N. Wirth gibt dazu etliche Ansätze, wo er Computer als Maschinen begreift und das Programmieren als Handwerk (craft), das in einen Wissensprozess umschlägt, so dass in den Programmen, die zunächst nur der Steurung von Maschinen dienten, immer mehr Text sichtbar wird, der der mathematischen Vernunft unterliegt.

Ich wundere mich darüber, wieso wir uns auf mathematische Vernunft beschränken sollten, respektive darüber, warum Informatiker nicht auch in gesellschaftlichen Zusammenhängen denken sollen, wo sie im Zentrum der Produktivkraftentfaltung stehen. Kybernetik muss sich nicht auf Oberoncomputer beschränken.

Programmieren vor dem Hintergrund von Kontingenz und Kommunikation

Dies sind einige Überlegungen zu Rolf Todescos letztem Blogpost “Programmieren und Theorie”. Insofern mein Kommentar dazu etwas zu lange geraten ist, habe ich mich entschlossen, diesen als eigenen Post zu publizieren. Ich hoffe, das kommt der besseren Lesbarkeit zugute.

1) These 1: “Programmieren als soziale Aktivität / Kommunikation”:
Unabhängig davon, wie die “soziale” Dimension nun konzeptualisiert wird (akteursbasiert, als soziale Emergenz, etc.), würde ich “Programmieren” stets auch als “soziale Aktivität”, und das heißt insbesondere als “Kommunikation”, auffassen. Denn die Codeproduktion (sei es als Umarbeitung von Altcode = Legacy Code, sei es als Neuproduktion, bei der idR mit Kunden ausgearbeitete Anforderungen = Requirements realisiert werden), erfolgt m.E. vollständig unter kommunikativen Vorzeichen: Anforderungsinterviews, Pair Programming und sonstige Entwicklerdiskussionen während des Designens, Codierens, Testens, etc., Reviews / Walk Throughs, usw.

Die Sicht “Programmierer und Computer” sollte daher nicht vom Sozialen völlig abstrahieren, weil der ganze Entwicklungsprozeß von der Anforderungserfassung bis zur Programmabgabe / -wartung durch und durch von sozialen Prozessen bestimmt wird.

Die Programm-“Lesbarkeit” ist dabei nicht nur für den einzelnen Programmierer selbst wichtig, sondern auch v.a. für diejenigen, die weiterhin mit der Codebasis arbeiten müssen (Tester, Legacy Code-Programmierer, usf). Und das bedeutet wiederum, es geht hierbei auch um “kommunikative” (= codebasierte und andere medial vermittelte) Anschlußmöglichkeiten!

2) “[…] bei dem die Programmierer im Laufe der Systementwicklung eine Theorie darüber entwickeln, wie die vorhandenen Probleme durch die Progammausführung gelöst werden können.” (Peter Naur)
* Hier wäre zu klären, was der Begriff “Theorie” bedeuten soll.
* Unabhängig von der Interpretation von “Theorie” werden bereits “vor” dem eigentlichen Programmieren eine Unzahl von idR sozial kalkulierten (!) Entscheidungen getroffen:
– Wie wird welches Software-Projekt angenommen (wer, wo, wann, mit welchem Budget, welchen Zeitvorgaben, welcher Qualität, usw.) oder verworfen?
– Neuprogrammierung oder Redeskription von Altcode?
– Welche Anforderungen sollen mit welcher Prioritität wie realisiert werden?
– Technische Vorgaben:
Zielplattform als Hard- und Softwre (Betriebssystem, etc.),
welche Tools (Programmier- und Designnotationen, Frameworks, IDEs, Test- und Debuggingwerkzeuge, usw.).
etc.
– Welche Software-Projektmanagement-Modelle werden gewählt (non-agil / agil oder irgendwie hybrid)? Das hat wiederum Auswirkungen z.B. auf die Vertragsgestaltung und Dokumentationsweise.
– Welche Designleitentscheidungen werden getroffen? Stichworte: Das zentrale Architekturdesign (Schichtenarchitektur, etc.) mit welchen Architekturdesignpatterns?
– Orientierung an welchen Programmierparadigmen mit welchen (Design- und Implementierungspatterns, Refaktorisierungs-, Test- und Debugging-Möglichkeiten, etc.)?
usf.

All das erfolgt bereits “vor” (!) dem Schreiben der ersten Programmzeile – unter der Voraussetzung, daß man nicht, ohne viel nachzudenken, sogleich wild und wirr zu codieren beginnt, was man idR höchstens im Hobbybereich tut.

Daher meine These 2:
Programmierer(innen) denken und kommunizieren (!) entlang bestimmter Design- und Programmierparadigmen, die insbesondere das “Problemlösungsverhalten” orientieren. So macht es bspw. einen erheblichen Unterschied, ob man ein Problem prozedural, objektorientiert (OO) oder funktional bearbeitet.
Von Vorteil ist es hierbei, ein Problem auf “kontingente” Weise bearbeiten zu können. Man sucht dann durch eine Art “Paradigma-Switching”, die ungeeigneten / uneleganten Problemlösungsweisen zu vermeiden.
Wenn man nun Paradigmen mit Theorien gleichzusetzen gewillt ist, dann orientieren “multiple Theorien” das Problemlösungsverhalten.

* Wenn man sich im Rahmen eines (dominanten) Programmierparadigmas bewegt, dann stellen sich ganz “konkrete” Probleme, die zuerst allgemein “formuliert” werden:
– Wie baue ich eine Verbindung zum Server auf?
– Wie baue ich eine GUI entsprechend den Anforderungen?
– Wie speichere ich etwas in welcher Art von Datenbank?
M.E. handelt es sich hier um Problem-Problemlösungsrelationen, die als einzelne Aufgabenstellungen entsprechend des divide-et-impera-Prinzips (komplizierte Aufgabestellungen werden in einzelne, gut zu bewältigende Aufgabenpakete heruntergebrochen) bearbeitet werden. Beim Prozeß des “stepwise refinement” würde dann programmiersprachenunabhängiger Pseudocode solange reformuliert, bis geeignete Codezeilen entstehen. Der Pseudocode kann dann für Dokumentationszwecke im Programm stehen bleiben.
In einfachen Fällen (wie Datei xy öffnen, einlesen, etc.) kopiert man auch einfach direkt “code snippets”, ohne sich großartig mit stepwise refinement herumzuplagen.
– Eine weitere Frage wäre freilich: “Code first, test later” oder “test first”? Schon das sind zwei prinzipiell unterschiedliche Herangehensweisen ans Codieren.
– Eine andere Frage betrifft die Wahl und Implementierung welcher Algorithmen, was sich für die Programmexekution als zentral (gerade mit Blick auf die Geschwindigkeit der Programmausführung) erweisen kann.
etc.

Kommt bei diesen konkreten Problemlösungsprozessen (innerhalb einer Programmiersprachen, die sich an einem oder mehreren Programmierparadigmen orientieren kann. Bspl: “Scala” entspricht einer hybriden Sprache, die je nach Aufgabenstellung einen prozeduralen, objektorientierten oder funktionalen Programmierstil erlaubt – und das u.U. mit Blick auf ein und denselben Codeblock) “eine” Theorie zum Einsatz?
Ich würde sagen “Nein”, wenn man unter Theorie einen konsistenten Aussagenzusammenhang versteht, der dann praktisch realisiert werden soll.
So funktioniert das konkrete Problemlösungsverhalten nicht. Das heißt auch: Das upfront-Design, bei dem antizipativ und theoretisch alle relevanten Probleme gelöst und dann umgesetzt werden, ist hier idR irreführend. Man muß eher mit ständigen Re-Deskriptionsprozessen rechnen, bei denen zwischen Mini-Design, Testen/ Debuggen, Codieren und Refaktorisieren geswitcht wird. Der Prozeß ist daher eher etwas “sprunghaft” – analog zum Schreiben komplizierterer Texte!

Bei den obigen Aussagen zur “Rekonstruierbarkeit von Theorien” ist daher zu hinterfragen, ob hier nicht ganz klassisch (sensu “alteuropäisch” wg. der Orientierung an altgriechischen Leitentscheidungen!) die praktische Realisierung (up front und antizipativ) eines theoretischen Rahmens zugrunde gelegt wird.
Das wird dem Komplexitätsmanagement in Software-orientierten Design- und Programmierprozessen aber in keinster Weise gerecht – zumal hier auch nicht “eine” Theorie zugrunde gelegt werden könnte, sondern ein ebenfalls komplexer und kreativer, vorab nicht prognostizierbarer “Problemlösungsprozeß” abläuft, der nicht nur rein mental, sondern auch sozial (recherchieren, diskutieren, usf.) zu konzipieren ist (These 3).

3) “Der Programmierer verwendet keine Theorie, sondern eine Programmiersprache. ” (Rolf Todesco)
Das würde ich als eine sehr simplizistische “Verkürzung” auffassen. Man verwendet eine Vielzahl von Problemlösungsweisen (visuell, oral, textuell, Prototypen, Designnotationen, u.U. sogar diverse Programmiersprachen und Programmierstile /-Paradigmen) in einem komplexen, immer auch sozial vermittelten Problemlösungsprozeß (s.o. These 3),  und das oft schon “vor” dem Schreiben der ersten Codezeile.
Zudem gibt es seit einiger Zeit den Approach des “visuellen Programmierens”, bei dem “Modelle” durch entsprechende Engines in exekutierbaren Code transformiert werden sollen (Stichworte: Automatisierung von Geschäftsprozessen durch entsprechende Business Process Engines).
Ziel: Das Programmieren (und damit die teuren Programmierer / -innen!) überflüssig machen, was m.E. aber letztlich nicht gelingen wird, so daß es eher um eine “Minimierung” des Codierungsaufwands geht.

4) “Er weiss dabei, was er sagen kann, aber nicht, was er sagen könnte. Er trifft eine Wahl aus dem Kontingent” (Rolf Todesco)
Bei dem obigen, relativ oberflächlich skizzierten Problemlösungsprozeß ist das “Kontingenzbewußtsein”, also: das Bewußtsein um alternative Problemlösungsweisen, recht geschärft. Und das heißt auch, es läßt sich, insbesondere bei zentralen Modellierungs-, Design- und Programmier-Entscheidungen, auch “explizieren”, z.B. in der programminternen bzw. -externen Dokumentation. Also:
* Warum wurde dieses Design (Pattern) – und zwar schon auf der Ebene der Leitunterscheidungen, z.B. der Architektur – und nicht ein anderes zugrunde gelegt? Was sind die Vor- und Nachteile?
* Warum dieser Algorithmus und nicht ein anderer? (Vor- und Nachteile?)
* Warum diese Datenstruktur und nicht eine andere? (Vor- und Nachteile?)
* Warum dieser Programmierstil für diese Aufgabe (z.B. OO und nicht funktional) und nicht ein anderer? (Vor- und Nachteile?)
* Warum diese Codeimplementierungen (und nicht eine refaktorisierte, andere Lösung), z.B. eine polymorphe Methodenlösung anstelle einer Fallunterscheidung mit switch, u.ä.? (Vor- und Nachteile?)
etc.

Da man hierbei von komplexen (nicht antizipativen) Re-Deskriptionsprozessen ausgehen muß, ist das Durchspielen von Alternativen 1A. Bref: Es wird durchgespielt, was man codieren “könnte”. Dann probiert man dies und jenes aus, sieht, daß es nichts ist, verwirft es, recherchiert neu, probiert wieder dies und jenes aus, usf. – um am Ende, hoffentlich, etwas vor sich zu haben, das funktioniert.
Das führt zu meiner These 4: Das Kontingenz- und Komplexitätsmanagement ist dem Software-Entwicklungsprozeß i.a. und dem Programmierprozeß i.b. “immanent”. 

5) “Sie ist kritisierbar – also vergleichbar – durch ein anderes Programm, also durch eine andere Wahl.” (Rolf Todesco)
Das Suchen nach Alternativen erfolgt  design-, modell- bzw. programm”intern” (!)  immer schon während” des Designens, Modellierens und Programmierens Es werden hierbei eine Vielzahl von Möglichkeiten durchgespielt und permanenten Redeskriptionprozessen unterworfen (und das sogar ganz explizit: als “Refaktorisieren” von Programmteilen).
Die “Explizierung” wichtiger Entscheidungen erfolgt mitunter sogar “im” Code selbst. Und in Code Reviews / Walkthroughs wird das ggf. nochmals durchgekaut.

Ergo, meine These 5:
In allem, was man bei der Softwareproduktion tut (und das geht über das eigentliche “Programmieren” im strikten Sinne von “Codieren / Implementieren” hinaus!), ist ein geschärftes Kontingenzempfinden notwendig – und das betrifft die Ebene des individuellen Bewußtseins wie der sozialen Kommunikation (Beispiele: Diskussionen mit Projekt-Stakeholders, Pair Programmierung bzw. sonstigen Diskussionen unter Entwicklern bzw. nachträgliche Reviews / Walk Throughs, etc.).

~Peter Bormann

Programmieren und Theorie

Ich arbeite gerade für die nächste MMK an einem  Moderationspapier zum Dialog-Computer und dabei bedenke ich auch wieder einmal das Programmieren.

Als “Programmieren” bezeichne ich tautologischerweise die Produktion von Programmen. Programmieren ist – wie Schreiben – “syntaxgeordnetes” Handeln, das sich durch die dabei verwendete Zeichenmenge direkt darstellen lässt, auch wenn der maschinelle Prozess ohne Kenntnis der Programmiersprache natürlich unklar bleibt. Die Programmiersprache macht das Programm sekundär lesbar. Primaär geht es um die Steuerung des Computers. Für den Computer spielt die Lesbarkeit keine Rolle, nur für den Programmierers.

Eine Kritik:
“Programmieren kann nach Peter Naur (…) nicht in erster Linie als Produktion von Programmen und zugehörigen Texten betrachtet werden, sondern als ein Prozess, bei dem die Programmierer im Laufe der Systementwicklung eine Theorie darüber entwickeln, wie die vorhandenen Probleme durch die Progammausführung gelöst werden können. Diese Theorie ist nur in den Köpfen der Entwickler vorhanden: Das Wiederherstellen der Theorie lediglich aufgrund der Dokumentation ist gänzlich unmöglich. In traditionellen Ingenieurbereichen sind aber die theoretischen Grundlagen bereits vor der Produktentwicklung erarbeitet” (Keil-Slawik, 1990 , 83).

(M)eine Kritik der Kritik:
In der Kritik wird eine Implikation der Aussage in Gegensatz zur Aussage gestellt: Die Produktion von Programmen impliziert, dass der Programmierer denkt. Dass es dabei eine Theorie verwendet, dürfte eine extreme Ausnahme sein, die “Theorie” die er zweifelslos “im Kopf” hat, ist eben gerade keine Theorie, weil sie nicht rekonstruierbar und nicht aufgeschrieben ist.

Der Programmierer verwendet keine Theorie, sondern eine Programmiersprache. Er weiss dabei, was er sagen kann, aber nicht, was er sagen könnte. Er trifft eine Wahl aus dem Kontingent. Und diese Wahl ist nicht rekonstruierbar. Sie ist kritisierbar – also vergleichbar – durch ein anderes Programm, also durch eine andere Wahl.

Steuerung und Regelung

Differenztheoretisch kann Steuerung durch die Differenz zwischen Steuerung und Regelung gesehen werden, indem auf der Seite der Regelung das, was als Steuerung ausgegrenzt wird, wiedereintritt.

Den Ausdruck Steuerung verwende ich in zwei verschiedenen Beobachterperspektiven:

1) deutender Beobachter

Als deutender Beobachter verwende ich den Ausdruck Steuerung für eine artefaktisch-konstruktiv implizite, nicht entwickelte Form der Regelung. Ich muss genau jene Geräte steuern, die konstruktiv keine Regelung enthalten. Umgangssprachlich sage ich dann etwa: Automaten steuern sich selbst, Maschinen muss ich steuern.

Regelung beruht auf Feed back(wards), Steuerung beruht auf Feed forwards. Beim Regeln korrigiere ich die Wirkung meiner vorhergehenden Massnahme (Nach-Sicht), beim Steuern muss ich voraussehen, wie meine Massnahme wirkt (Vor-Sicht).

Die Ausdrücke “Steuerung” und “Regelung” werden im unreflektierten Alltag sehr vielfälltig und beliebig verwendet. Wo die Ausdrücke bewusst verwendet werden, wiederspiegeln sie das jeweilige technologische Verständnis sehr genau: Ich unterscheide Automaten von Werkzeugen ohne Regelung. Automaten zeigen konstruktiv, was Benutzer von Werkzeugen ohne Regelung zu leisten haben. Dabei unterscheide ich zwei Fälle der Steuerung:

– unmittelbare Steuerung
Auf dem Motorrad steuere ich mit der Lenkstange die Auslenkung des Vorderrades und so die Fahrrichtung des Motorrades (dass die Sache etwas komplizierter ist, behandle ich unter Motorrad-Philosophie).

– mittelbare Steuerung
Als Polizist kann ich den Verehr auf einer Kreuzung unmittelbar – also ohne technische Hilfsmittel mit meinen Händen – steuern, oder ich kann eine Verkehrssignalanlage (Rot, Gelb, Grün) installieren. Solche Anlagen können “festzeitgesteuert” (mit festgelegten Signalzeiten) sein, also beispielsweise nachts gelb blinken und tagsüber Rot- und Grünphasen zeigen. Die Steuerung besteht dann darin, dass ich die Anlage entsprechend programmiere. Die Anlage vermittelt meine Steuerung, ich muss als Polizist nicht mehr vor Ort sein. Dafür muss ich noch weiter vorhersehen, welche Einstellungen jeweils sinnvoll sind.

Dudens Lexirom schreibt (wie üblich ohne erkennbare Terminologie), dass Verkehrssignalanlagen auch verkehrsabhängig gesteuert sein können; “dabei wird der Verkehr meist durch Induktionsschleifen in der Fahrbahndecke erfaßt und die Signalschaltung der Verkehrsdichte angepaßt. Ist die Verkehrssignalanlage eines Knotenpunktes mit der benachbarter Knoten zeitlich abgestimmt (›grüne Welle‹), so spricht man von koordinierter Signalsteuerung”.

Wenn eine Verkehrssignalanlage verkehrsabhängig reagiert, handelt es sich – in meiner Terminologie – nicht um eine Steuerung, sondern um eine Regelung.

Wenn der Feedback zur Regelung beispielsweise durch “Induktionsschleifen in der Fahrbahndecke” gespiesen wird, muss ich als Autofahrer mit dem Auto über diesen Signalgeber fahren, was quasi zwangsläufig geschieht. An Fussgängerampeln gibt es oft einen Druckknopf, mit welchem ich das Signal auslösen muss. Von der Anlage her betrachtet, sind die Fälle identisch, die Anlage wartet auf Feedback. Als Fussgänger kann ich in meiner Handlung eine explizite Steuerung sehen.

2) konstruierender Beobachter

Als konstruierender Beobachter verwende ich den Ausdruck Steuerung für einen bestimmten Teil der Regelung: Bei einer thermostatengeregelten Heizung bespielsweise wird die Heizung eingeschaltet, wenn vom Thermostaten das entsprechende Signal kommt. Wenn ich diesen Prozess isoliert betrachte, also davon absehe, warum der Thermostat das Signal liefert, wird die Heizung vom Themostaten gesteuert, wie wenn ich sie von Hand oder durch eine Festzeitsteuerung einschalten würde.

Die Vermischung der beiden Perspektiven führt zur chaotischen Verwendung der Begriffe. Ingenieure, die Anlagen wie die oben beschriebene Verkehrssignalanlage mit “Induktionsschleifen in der Fahrbahndecke” und Druckknopf-Steuerungen konstruieren, konstruieren in beiden Fällen Mechanismen, die die Ampeln “steuern”, wiewohl es sich in beiden Fällen um Regelungen handelt, weil die Anlagen situationsabhängig reagieren.

Als konstruierender Beobachter betrachte ich einen eigenständigen “Steuermechanismus” innerhalb des Automaten, der durch einen sekundären Energiekreis definiert ist. Die Steuerung eines Automaten besteht so gesehen aus einem Programm und einem Programmabtast-Mechanismus. Die Lochkarten-Mechanik von Jacquards Webstuhl ist eine Steuerung, mit welcher der Webstuhl in bestimmte (System-)Zustände versetzt wird. Die Steuerung ist der universelle Aspekt der sogenannten Turing-Maschine.

Der Steuermechanismus eines Automaten ist eine Interpretation der Benutzerintention: Das durchgedrückte Bemspedal wird durch ein ABS-System im Auto als Wunsch für effizientes Halten genommen, dh. die Räder blockieren nicht, sondern werden so gesteuert, dass sie bis zum Stillstand immer drehen.

Kostenlose infotechnische Weiterbildungsangebote

Wer sich in Sachen Softwareentwicklung, Internetkommunikation, usf. online und gratis weiterbilden möchte,dem seien folgende Angebote empfohlen:

OpenHPI (eine Online-Lernplattform vom Hasso-Plattner-Institut in Potsdam). URL:  https://openhpi.de/
Im Jahr 2014 werden die folgenden kostenlosen Kurse angeboten:

1. Internetworking with TCP/IP
   Beginn: 31. März 2014
   Dauer: 6 Wochen
   Arbeitsaufwand pro Woche: 5-7 h
   Tätigkeiten: Videos, Lektüre, Quizzes, wöchentliche Hausaufgaben, die relevant sind für die Zulassung zur Endprüfung
   Zertifikat (kostenlos): möglich (je nach Abschneiden in der Endprüfung)
   Sprache: Englisch
   Zielpublikum: m.E. ein IT-affines Laienpublikum (Informatiker mit Hochschulabschluß, u.ä. dürften dagegen das meiste schon kennen)
   Dozent: Prof. Dr. Christoph Meinel
   Kursbetreuung mit Diskussionsforen: vorhanden
   Kursgebühren: keine
2. Weitere Kurse im Jahr 2014
   Semantic Web Technologies (ab Mai 2014), Dr. Harald Sack
   In-Memory Data Management (ab September 2014) von einem der SAP-Gründerväter, Prof. Hasso Plattner, himself
   Einführung in die Internetsicherheit (ab Oktober 2014), Prof. Dr. Christoph Meinel

   Bewertung: Nach meiner Erfahrung (mit früheren Kursen im Jahr 2013) sind das absolut professionelle Kursangebote, die sich freilich eher an ein IT-Publikum (Studierende / Praktiker aus den Bereichen Informatik / Wirtschaftsinformatik) richten. Aber einige Kurse, wie bspw. der obige Kurs zu “Internetworking with TCP/IP”, dürfte auch ein IT-affines Laienpublikum ansprechen.
   Bislang sind diese Kurse noch kostenlos, aber das dürfte sich in naher Zukunft ändern (zumindest eine Zertifizierung könnte dann kostenpflichtig werden).
   Kurzum: “Sehr empfehlenswert” gerade für IT’ler, um sich über neuere Entwicklungen profunder zu informieren.

Coursera. URL:https://www.coursera.org/
Allgemein: Eine Online-Lernplattform, die (idR) kostenlose Uni-Kurse, u.a. von Top-Universitäten wie Princeton, Stanford, Duke, etc.,  anbietet, wobei bestimmte Zertifizierungsleistungen kostenpflichtig sind. Mit über 600 Kursen in mehreren Sprachen (wobei derzeit insbesondere englischsprachige Kurse dominieren) hat man fast schon die Qual der Wahl.
Obwohl es hier für ITler viele interessante Kurse gibt (ein Kurs zur Einführung in Scala von Martin Odersky, Kurse zum Erlernen der Android-Programmierung, etc.), dominieren die Angebote aus dem Bereich “Humanities”, so daß auch Nicht-Techies den einen oder anderen interessanten Kurs finden dürften.

Bewertung: Nach Absolvieren von englischsprachigen Scala- und Androidkursen muß ich sagen, daß mir diese Angebote sehr gefallen. Insbesondere um sich schnell in ein neues (IT-)Thema einzuarbeiten, eignen sich solche Kurse sehr gut. Wer dabei auf Zertifizierungen verzichten kann, muß (idR) auch kein Geld zahlen.
Kurzum: Top (nicht nur für ITler)!

~Valonqua