Skip to content

Bericht von der OOP 2014 (Teil 2)

Donnerstag, 06.02.2014

Impact Maps und Story Maps

Am nächsten Morgen ging es mit dem Vortrag „Impact Maps und Story Maps: liefern was wirklich zählt“ von Christian Hassa weiter.

Er stellte eine Möglichkeit vor, dass das Backlog eines Projekts nicht überquillt. Hier nannte Impact Maps, die sichtbar machen sollen, welche Auswirkung ein bestimmtes Feature hat und was man dafür liefern muss. Daneben stellte er noch Story Maps vor, die auch irgendwas können.

Mir war der Vortrag leider viel zu hoch. Wer noch nicht mit User Stories im agilen Umfeld arbeitet, konnte mit dem Vortrag leider nichts anfangen.

Continuous Documentation statt Endless Specification

Der zweite Vortrag „Continuous Documentation statt Endless Specification - den Fokus auf nachhaltige Artefakte legen“ von Susanne Mühlbauer war da schon etwas besser, aber auf ähnlichem Niveau.

Die Referentin stellte zur Diskussion, ob es sinnvoll sei, dass man an vielen Stellen im Projekt mehrfach das Gleiche auf andere Art und Weise dokumentiert. Sie hält Prozess- und Projektdaten (Besprechungsprotokolle, Zwischenergebnisse etc.) für weniger wert als den entstandenen Code oder Designbeschreibung. Dieser Output könnte dann bei einem iterativen Verfahren wie Scrum wieder in die Anforderungsdokumentation wandern, um die Spezifikation zu verbessern.

Als Beispiele für solchen nachhaltigen Artefakte, die man aufheben sollte, zählt Mühlbauer Motivationen und Entscheidungen sowie der grobe Überblick über das Thema. Ebenso ist oft ein Benutzerhandbuch notwendig. Auch beschrieben werden sollten die Schnittstellen und nicht-funktionale Anforderungen, ebenso wie die Testfälle.

Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr

Siemens-Mitarbeiter Michael Stal sprach dann aus, was alle Software-Architekten denken: „Architekt zu werden scheint nicht schwer, Architekt zu sein dagegen sehr“.

Die Architektur ist das Rückgrat des Systems und so sind auch die Architekten wichtig, die dieses pflegen. Oft sind Architekten aber „nur“ normale Entwickler, die dazu ernannt wurden, aber keinerlei sonstigen Erfahrungen dafür mitbringen. Ein Problem ist dabei sicher auch, dass Architekten in manchen Prozessen einfach kein Platz zugeordnet wird.

Am Beispiel der Siemens AG stellte Stal dann die verschiedenen Architekten-Anforderungen und dessen Verantwortungen vor. Neben Design Skills benötigen sie Erfahrung im Requirement Engineering und Teststrategien. Vor allem die Soft Skills sah Stal als extrem wichtig an. Ebenso sollten auch Architekten noch implementieren – etwas, was sehr oft nicht mehr der Fall ist.

Zusätzlich sollte man als Architekt (und in meinen Augen auch allgemein) nicht alles bis ins kleinste Detail vorab spezifizieren, designen und berechnen, sondern lieber einfach etwas ausprobieren und dann nachjustieren, wenn es nicht stimmt. Das erfordert aber Mut.

Gut fand ich auch den Hinweis, dass man als Architekt auf ein guten Ausgleich zwischen Arbeits- und Privatleben achten sollte. Mehr als 40 Stunden kann ein Mensch auf die Dauer in einer Woche nicht sinnvoll arbeiten ohne sich kaputt zu machen bzw. ohne dass die Qualität leidet.

Keynote: An Agile Challenge

Die Keynote „An Agile Challenge: Munich Germany Takes On The Columbus Ohio USA Agile Benchmark Study“ war in meinen Augen dann eher wenig erwähnenswert.

Es wurden nur Ergebnisse von ein paar europäischen Firmen vorrgestellt, die an einer Agile-Benchmark-Studie teilgenommen hatten.

Über Freud und Leid der Entwickler beim Schätzen ihrer Aufgaben

Der Vortrag „'Och, nicht schon wieder ...!'; - Über Freud und Leid der Entwickler beim Schätzen ihrer Aufgaben...“ war eigentlich weniger Vortrag als Erfahrungsaustausch.

Die beiden Referenten Paul Herwarth von Bittenfeld und Joachim Seibert teilten den Raum in zwei Gruppen auf, die wiederum in drei Teilgruppen geteilt wurden. Diese drei Teilgruppen sammelten sich dann um drei Fragen an drei Tischen. Jeder sollte sich mit den anderen austauschen und aufschreiben, was 1. die Motivation für Schätzungen ist, 2. welche Störungen es gibt, die Schätzungen zunichte machen können, und 3. welche gute Erfahrungen mit Schätzen gemacht wurde. Die Teilgruppen wanderten dann zum nächsten Tisch weiter und am Ende wurden die erarbeiteten Ergebnisse vorgestellt.

Das ganze bezog sich natürlich auf das Abschätzen in Scrum-Projekten, sodass ich nicht direkt mitreden konnte, dennoch kam Einiges zusammen. Vor allem aus dem Scrum-Umfeld konnte ich so ein paar Begriffe wie „Planning Poker“ oder „Magic Estimation“ aufgreifen (hier grob erklärt).

Mir hat die Veranstaltung sehr gut gefallen, weil man so einmal mit seinen Tischnachbarn ins Gespräch kam und sich austauschen konnte. Dazu im Fazit mehr …

Keynote: Software Design in the 21st Century

Danach trat Martin Fowler mit seiner Keynote „Software Design in the 21st Century“ an. Martin Fowler ist kein Unbekannter in der Software-Welt und hatte/hat einen großen Einfluss auf die Entwicklung im Bereich Software-Architektur, Refactoring und Extreme Programming.

Dementsprechend habe ich mich auch auf seinen Vortrag gefreut, der zweigeteilt war. Der erste Teil beschäftigte sich mit den verschiedenen Arten des Refactorings. Neben Test-Driven-Development-Refactoring nannte er auch noch Little-Pickup-Refactoring, Comprehension-Refactoring, Preparatory-Refactoring, Planned Refactoring (im Backlog) und Long-Term-Refactoring.

Martin Fowler zum Thema Refactoring.

Martin Fowler zum Thema Refactoring.

Die guten Gründe, die für Refactoring sprechen, sind: Qualität, sauberer Code, Professionalität und dass es einfach das Richtige ist. Diese Gründe sollte man aber gegenüber den Geldgebern/Projektleitern nie nennen. Besser wäre es, wenn man „Okönomie“ als Grund angibt: Man kann nach dem Refactoring mehr und schneller liefern.

Der zweite Teil befasste sich weniger mit normalen Software-Themen, sondern griff die Nachricht der Keynote von Constanze Kurz vom Vortag mit auf. Fowler betonte, dass wir Entwickler nicht bloß „Code monkeys“ seien, sondern unser Gehirn einschalten sollten. Wir sollten das Richtige und Moralische während unser Arbeit tun. Dazu zählt auch die Privatsphäre der Nutzer zu schützen.

Er verwies dabei auch auf den kommenden Dienstag. Am 11. Februar 2014 ist der Tag, an dem wir zurückschlagen: The Day We Fight Back – Against Mass Surveillance. Martin Fowler rief jeden dazu auf, teilzunehmen, was ich nur unterstützen kann.

Ich hätte nicht mit so einem kritischen Thema auf der OOP gerechnet, bin deswegen aber umso mehr begeistert gewesen. Auch heise hat darüber berichtet.

Agile Softwarearchitektur - 5 Dinge die vom Hype bleiben

Im vorletzten Vortrag ging es um das Thema „Agile Softwarearchitektur - 5 Dinge die vom Hype bleiben“. Stefan Toth erzählte, wie Softwarearchitektur in die agile Welt passt.

Es sind dabei vor allem fünf Dinge, die bleiben: Schlanke Vorarbeit (d.h. nicht totdesignen, bevor man anfängt zu kodieren), gemeinsame Architekturarbeit aller Beteiligten/Entwickler, Architekturanforderungen müssen festgehalten sein, Architektur und Entwicklung verzahnen (iterativ mit Metriken und Tests verifizieren und korrigieren) und Reflexion der Architektur.

Insgesamt war es ein guter und interessanter Vortrag, der dabei half, das Thema Softwarearchitektur im agilen Umfeld korrekt einzuordnen.

SOLID Deconstruction

Den Abschluss – und mein Highlight – bildete der Vortrag SOLID Deconstruction von Kevlin Henney. Ich habe Henney bereits auf der OOP 2012 gehört und freute mich daher auf ihn. Grund war und ist, dass man in seinen Vorträgen Tränen lacht und trotzdem etwas lernt.

Henney nahm die SOLID-Prinzipien auseinander und erklärte zu jedem Prinzip, wo es herkam und was es ursprünglich bedeutete und wieso wir es in der heutigen Zeit manchmal falsch anwenden bzw. falsch verstehen.

Interessant war auch sein Verweis auf das Dreyfus-Modell zum Erwerb von Fähigkeiten, was den Menschen in fünf Typen unterteilt, wie er etwas lernt und aufnimmt. Dementsprechend sollte man auch mit den SOLID-Prinzipien umgehen.

Der Vortrag war wie erwartet sehr erheiternd. Kleinere Anekdoten und ein sehr lockerer Vortragsstil reißen einen einfach mit. Zusätzlich habe ich einiges über SOLID gelernt und kann die Prinzipien (bzw. Henney nennt es lieber Pattern) besser anwenden.

Fazit

Die OOP war wieder sehr gut und ich kann es eigentlich nur jedem empfehlen, der die Möglichkeit hat, dort hinzugehen, es mindestens einmal zu versuchen. Das Programm ist so riesig, dass für jeden etwas dabei ist. Daneben kann man auch viele Kontakte knüpfen …

… wenn die Raumgröße nicht wäre. In jedem Vortrag gab es das gleiche Bild: Zwischen je zwei Zuhörern war ein Platz frei. Immer! Ausnahme: Zwei Entwickler kamen gemeinsam durch die Tür herein und gehörten zusammen. Auch während der Pausen blieben die meisten (wenn sie nicht Teil einer Gruppe waren) für sich. Ich bin unsicher, wieso das so war, aber es fanden so nur wenige Gespräche statt. Einzig bei den Gruppenarbeiten in den Vorträgen (was bei mir nur zwei waren), wurde das Eis gebrochen und die Gespräche fingen an.

Interessant waren auch die Ausstellungen im unteren Bereich der Halle. Siemens stellte beispielsweise ein 1:2-Modell des Mars Rover aus. Und beim Carl-Hanser-Verlag konnte ich mit den Leuten reden, deren Bücher ich ab und zu lese.

Das Mars-Rover-Modell am Siemens-Stand.

Das Mars-Rover-Modell am Siemens-Stand.

Bilder gibt es im Übrigen beim Veranstalter, wer ein paar Impressionen sehen will.

Bericht von der OOP 2014 (Teil 1)

Jedes Jahr findet in München die OOP statt, eine Messe, auf der viel über Software-Architektur, Agilität und Management gesprochen wird. Dieses Jahr waren mehr als 150 Referenten vor Ort und haben über 1800 Konferenz-Teilnehmer unterhalten. Mich am Mittwoch und Donnerstag ebenfalls.

Eingang zur Messe.

Eingang zur Messe.

Mittwoch, 05.02.2014

OOA, IOC, ROI, SQL - Was passt nicht?

Der erste Vortrag war „OOA, IOC, ROI, SQL - Was passt nicht? Eine Erzählung von Betriebswirtschaft und Software-Entwicklung“. Hier ging es speziell um den Return of Invest (ROI), für den sich das Management in einer Firma meist interessiert.

Anhand eines Beispiel, bei dem es darum ging, ob man ein Stück Code mit einer Factory und DIP refaktorisiert, wollte Michael Mahlberg zeigen, ob es sich lohnt, dies so umzusetzen. Wichtig für ihn war, nicht die absoluten Zahlen zu sehen, sondern immer die Investierung betrachtet über die Zeit (also inkl. Zinssatz). Ich gebe zu, dass ich das nicht alles verstanden habe.

In kleinen Gruppenarbeiten sollten dann andere Fälle wie „Make or Buy“, „Serviceaustausch“ oder „Flat-File vs. Datenbank” besprochen werden. Da wir viel zu viele Teilnehmer waren (ca. 50) teilten sich diese also auf drei Gruppen auf, in der aber nur wenige etwas zum Ergebnis beitrugen. Heraus kam auf alle Fälle, dass es wesentlich leichter ist, die Kostenseite für eine Software-Änderung aufzuschreiben als die Nutzenseite.

Architectural Refactoring

Der zweite Vortrag war „Architectural Refactoring - agile Umsetzung von Modernisierungsentscheidungen“. Unter Architectural Refactoring versteht Referent Olaf Zimmermann, dass man eine zuvor getroffene architekturelle Entscheidung ändert.

In der Regel ist dies nicht einfach, da es mit einer Strukturänderung im Design, Neuimplementierung und Dokumentation verbunden ist. Oftmals liegen vorher getroffenen Entscheidungen nicht einmal vor, was die Sache noch mehr erschwert.

Als Beispiel hat er ein Y-Template vorgestellt, mit dem man festhalten kann, welcher Anwendungsfall unter bestimmten nicht-funktionalen Anforderungen zu einer Entscheidung führt und andere Entscheidungen weglässt, sodass ein bestimmtes Ziel erreicht wird unter Beachtung ggf. negativer Konsequenzen. Festgehalten werden soll das Ganz durch das „ARC Metamodel“, was aber derzeit noch entwickelt wird.

Keynote: Agile Skalierung – Prinzipien statt Blaupause

Die Keynote „Agile Skalierung – Prinzipien statt Blaupause“ von Stefan Roock und Hennig Wolf war sehr interessant.

Die beiden Trainer von it-agile zeigten als Beispiel, dass ein agiles Pilotprojekt auf eine ganze Firma ausgewälzt werden soll. Hier hilft dann keine generische Blaupause, nach der alles umgestellt wird. Ein Überstülpen eines neuen agilen Entwicklungsprozesses von oben bringt nichts, sondern der Kulturwandel muss von unten, von den Mitarbeitern kommen. Verschiedene Prinzipien wie direkte Kommunikation, kein Zielzustand vorgeben sowie beobachten und anpassen sind dabei ganz wichtig, damit so eine Änderung ein Erfolg wird.

Imposing Rule-Based Architecture on Legacy Systems

Der Vortrag „Imposing Rule-Based Architecture on Legacy Systems“ von Michael Feathers sollte den Umgang mit Legacy-Systemen zeigen.

Neben der Darstellung einer einfachen Struktur stellte er einige Mittel vor, wie man Verletzungen der Architekturregeln darstellen kann. Zusätzlich war es wichtig, den Fortschritt wie auch immer zu messen.

Ein schönes Zitat von Kent Beck im Vortrag war: „Wenn du dein System nicht mit vier Objekten oder weniger beschreiben kannst, hast Du keine Architektur.” Das kann man als übertrieben ansehen, aber es soll klar machen, dass jede Art von Architektur zumindest als grobes Konzept leicht verständlich sein muss. (Als Beispiel hat Michael Feathers im Übrigen das Testframework JUnit mit nur zwei Klassen beschrieben.)

Die Vortragsfolien sind leider nicht so gut, da diese oft nur die Überschrift enthalten und der Rest auf der Tonspur kam, was die Zusammenfassung auch etwas erschwert.

Keynote: Mastering the Internet

Überrascht hat mich die Keynote „Mastering the Internet“ von Constanze Kurz. Die Sprecherin des Chaos Computer Club ist vielen sicher bekannt, man würde sie aber nicht auf OOP erwarten.

Das Thema ihres Vortrags war recht aktuell, da es um die Enthüllung von Edward Snowden ging, vor allem eben Prism und die anderen Überwachungsaktivitäten des us-amerikanischen und britischen Geheimdienstes.

Als Open-Source-Aktivist (und Mitglied bei der EFF und FSFE) bin ich dem Thema sehr verbunden und habe mich gefreut, dass Constanze Kurz das den OOP-Teilnehmern noch einmal klar gemacht hat. Interessanterweise blieb sie nicht die einzige …

CCC-Sprecherin Constanze Kurz.

CCC-Sprecherin Constanze Kurz.

Modernisierung von zentralen Frameworks

Anatole Tresch von der Schweizer Bank Credit Suisse zeigte im Vortrag „Modernisierung von zentralen Frameworks - ein Erfahrungsbereicht“, wie einen Java-Framework, was in der Bank benutzt wird, in mehreren Jahren modernisiert wurde.

Grund für die Modernisierung (Refactoring) waren die üblichen Probleme wie erhöhte Wartungszeit und eine zu komplexe API. Das mittelgroße System mit 17.000 Codezeilen hatte Zyklen, eine hohe Kopplung und zahlreiche große Klassen. Als Ziele gab man sich vor robust zu sein, die Wartbarkeit und Laufzeit sollte verbessert werden, daneben wollte man aber auch kompatibel bleiben.

Hier sollte jedem klar sein, dass das eigentlich nicht alles machbar ist. Angeblich wurde aber eine Performancesteigerung von Faktor 100 herausgeholt. Gleichzeitig wurde das System entkoppelt und vereinfacht, was ich mir nicht so richtig vorstellen kann. Kompatibel ist man aber nicht geblieben, was aber kein Problem war, da die Kunden ja wiederum in der Bank saßen und man so direkten Kontakt zu ihnen halten konnte.

What If? - An Exploration of What's Possible, What's Not and Why?

In der Abendschule von 18:30 Uhr bis 20 Uhr gab es dann den letzten Vortrag „What If? - An Exploration of What's Possible, What's Not and Why?“ von David Hussmann. Einige Vorträge gibt es auch auf seiner Firmen-Webseite Devjam.

Sehr unterhaltsam hat David Hussmann erklärt, dass die Leitsprüche „certification over education“ und „process over product“ eher schaden als nützen. Die Änderungen müssen aus dem Team heraus kommen und von ihm angenommen werden. Zusätzlich muss Platz für Anpassungen und Veränderungen sein.

Das heißt, wenn der Prozess nicht passt, egal ob Scrum, Kanban oder was anderes, dann muss man ihn anpassen. Und wenn man dann eben eben nicht mehr nach Lehrbuch arbeitet, dann ist das einfach so. Wenn es dem Team und dem Projekt hilft, ist das in Ordnung.

Mir hat an dem Vortrag gefallen, dass eben nicht so sehr auf Regeln gepocht wird. An vielen Stellen hört man immer wieder: „Was, ihr macht Scrum und habt kein ordentliches Backlog? Wie könnt ihr nur?“ Ich hoffe, dass sich dieses Denken der Freiheit und Anpassbarkeit noch weiter herumspricht.

Etwas enttäuscht war ich nur von dem Begriff Abendschule (Night school). Ich hatte mir darunter eine lockerere Atmosphäre und Gespräche vorgestellt. Effektiv war es aber wie die normalen Vorträge – nur eben spät abends … und recht teuer.

Buch: Software-Architekturen dokumentieren und kommunizieren

Titel

Software-Architekturen dokumentieren und kommunizieren

Autor

Stefan Zörner

Sprache

Deutsch

Genre

Fachbuch

Herausgeber

Carl Hanser Verlag, 2012

Seitenanzahl

277 Seiten

In jedem größeren Software-Projekt besitzt die Software eine bestimmte Architektur. In der Regel sollte diese strukturiert und gut dokumentiert sein. Da Dokumentation aber nicht gerade zu der Lieblingsbeschäftigung von Entwicklern zählt, krankt es des Öfteren daran. Das Buch „Software-Architekturen dokumentieren und kommunizieren“ von Stefan Zörner soll zeigen, wie man die Software-Architektur festhalten kann.

Inhalt

Inhaltlich orientiert sich das Buch „Software-Architekturen dokumentieren und kommunizieren“ teilweise an der Dokumentationsvorlage arc42. Diese Vorlage, entwickelt von Gernot Starke (der auch das Geleitwort zum Buch verfasst hat) und Peter Hruschka, ist unter einer Creative-Commons-Lizenz frei verfügbar und für jeden nutzbar.

Stefan Zörner beschreibt in seinem Buch aber viel mehr als die Dokumentation mit arc42, dies nimmt im Vergleich sogar nur einen kleinen Teil ein. Wichtig sind ihm vor allem Fragen wie „Was dokumentiere ich? Für wen dokumentiere ich? Und wie ich finde das Dokumentierte wieder?“ Auch wenn diese Fragen nicht generell und erst recht nicht leicht zu beantworten sind, gibt sich der Autor sichtlich Mühe, dem Leser Denkanstöße in diese Richtung zu geben.

Bei der Dokumentation geht er dann auch verstärkt auf wichtige, zu beschreibende Aspekte einer Software ein. Darunter z. B. die Randbedingungen, Qualitätsmerkmale („non-functional requirements“) oder Architekturentscheidungen. All dies sollte festgehalten werden, damit man auch später noch klar nachvollziehen kann, wieso die Software so strukturiert ist, wie sie vorliegt.

Zielgruppe

Auch wenn man meinen könnte, dass das Buch nur eine kleine Zielgruppe hat, so sollte doch eigentlich jeder Software-Entwickler wissen, wie er die Struktur seiner Software dokumentieren und anderen vermitteln kann. Sicherlich ist es in einem Ein-Mann-Projekt übertrieben, mit arc42 an die Dokumentation zu gehen, aber die meisten Programmierer können bestätigen, dass sie ohne Dokumentation (und sei es nur in Form von Kommentaren) den eigenen Quellcode nach einem halben Jahr nicht mehr komplett verstehen. Demnach richtet sich das Buch an eine große Gruppe, sowohl im Business- als auch im Privat-Bereich.

Für seine Vorträge und das Buch hat er sogar eine eigene Schach-Engine DokChess geschrieben, die unter Open-Source-Lizenz verfügbar ist. Dieser Software widmet er anschaulich im Buch auf 34 Seiten eine komplette Beispieldokumentation, sodass jeder Leser ein echtes und anschauliches Beispiel für gute Dokumentation vorliegen hat.

Durch Übungsaufgaben versucht Stefan Zörner auch gleich zum Mitmachen anzuregen. Dies ist sehr fordernd, weil man die Architektur des real existierenden Squeezebox Medienservers dokumentieren soll. Hier sollte man also schon etwas Zeit mitbringen. Auch wenn die ersten Übungsaufgaben noch recht einfach zu handhaben sind, wird es zum Ende immer anspruchsvoller. Gut ist, dass man dem Autor seine Lösungen per E-Mail zuschicken kann und er dazu Rückmeldung gibt und seine Musterlösung zuschickt.

Fazit

Das Wichtigste, was Stefan Zörner wohl als geeigneten Autor für so ein Thema ausmacht, ist sein Erfahrungsschatz. Als ehemaliger Trainer und Berater bei oose und nun bei embarc hat er regen Kundenkontakt. Privat arbeitet er beim Apache-Projekt mit und hat so auch einen Einblick in andere Organisationsformen.

Das Buch liest sich daher aufgrund kleiner Anekdoten und Zitate sehr locker und flüssig. Darüber hinaus bauen die Kapitel nicht aufeinander auf, sondern können auch je nach aktuellem Wunsch gezielt bei einem Problem gelesen werden. Sinnvoll ist es aber, wenn man jedes Kapitel zumindest überfliegt.

Sehr gut haben mir vor allem die Kapitel 8 „Lightfäden für das Vorgehen zur Dokumentation“ und Kapitel 10 „Stolpersteine der Architekturdokumentation“ gefallen. In Kapitel 8 geht es darum, wie man sinnvoll dokumentiert. Vor allem die Aussage, dass ein Bild (UML-Diagramm) manchmal nicht mehr als tausend Worte sagt, ist bei mir hängengeblieben. In Kapitel 10 geht es um fiese Dokumentationsfallen, etwas, was Stefan Zörner schon auf der OOP 2012 vorgetragen hat, wo ich ihn auch kennenlernte.

PS: Ich weiß nicht, wieso ich die Rezension nicht eher hier veröffentlicht habe. Das Buch hatte ich bereits im März 2013 fertig gelesen.

freiesMagazin 02/2014 erschienen

freiesMagazin 02/2014 Titelseite

Heute ist die Februarausgabe von freiesMagazin erschienen und bringt viele spannende Artikel aus den Bereichen Linux und Open Source mit.

Inhalt der Ausgabe 02/2014

  • Fedora 20
  • Creative Commons 4.0 vorgestellt
  • Der Januar im Kernelrückblick
  • Explizite Positionierung in LaTeX
  • Shell-Skripte – Kleine Helfer selbst gemacht
  • Sozi – Eine kurze Einführung in das Inkscape-Plug-in
  • Gone Home
  • Äquivalente Windows-Programme unter Linux – Teil 4: Bildbearbeitung (2)
  • Rezension: Android – kurz & gut
  • Rezension: Apps mit HTML5 und CSS3 für iPad, iPhone und Android
  • Rezension: Debian GNU/Linux – Das umfassende Handbuch
  • Leserbriefe und Veranstaltungen

Downloads

Unter der Adresse http://freiesmagazin.de/mobil/ findet man immer die aktuelle und alle bisher erschienenen HTML- und EPUB-Ausgaben. Auf der Magazin-Seite können die letzten drei Ausgaben von freiesMagazin abgerufen werden, ältere Ausgaben findet man im Archiv.

Kontakt

Wer jeden Monat an die neue Ausgabe erinnert werden will, kann auch den RSS-Feed abonnieren. Leserbriefe mit Lob, Kritik, Anregungen oder Fragen und neue Artikelvorschläge können an die Redaktion geschickt werden.

Wochenrückblick 05/2014

Der Wochenrückblick lässt das Geschehen der vergangenen Woche rund um Ubuntu, Linux und Open Source Revue passieren.

Rund um Ubuntu

Supportende für Ubuntu 13.04 „Raring Ringtail“

Am 27. Januar 2014 lief die Unterstützung für Ubuntu 13.04 „Raring Ringtail“ aus. Alle Benutzer, die noch Ubuntu 13.04 einsetzen, sollte baldmöglichst auf eine noch unterstützte Ubuntu-Version wechseln. Das kann entweder ein Upgrade auf Ubuntu 13.10 „Saucy Salamander“ sein oder eine Neuinstallation von Ubuntu 12.04 LTS „Precise Pangolin“ mit Langzeitunterstützung.

Mehr Informationen gibt es im Ikhaya-Artikel.

Weitere Quellen: Ubuntu Fridge, Linux-Magazin

Gewinner des Xubuntu-Hintergrundbild-Wettbewerbs

Im Xubuntu-Blog wurden die Gewinner des Xubuntu-Hintergrundbild-Wettbewerbs bekannt gegeben. Von den 81 Einsendungen wurden 6 besondere ausgewählt, die mit Xubuntu 14.04 im April ausgeliefert werden.

Neues rund um Linux

LinuxTag startet Call for Papers

Der LinuxTag in Berlin zählt jedes Jahr zu den größeren Veranstaltungen, wo sich Linux-Anhänger aus Deutschland und weltweit zum gemeinsamen Austausch treffen. Für die vom 8. bis 10. Mai 2014 stattfindende Messe werden wieder zahlreiche Vorträge und Workshops gesucht.

Quellen: Pro-Linux, heise open, Linux-Magazin

US-Schule wechselt auf Linux-Laptops

Die US-amerikanische Penn Manor High School in Pennsylvania hat über 1700 Schüler mit einem auf Acer-Laptops vorinstallierten Ubuntu-Derivat namens Ubermix ausgestattet. Die Entscheidung für ein Open-Source-Betriebssystem soll der Schule ca. 345,000 US-Dollar an Lizenzkosten sparen.

Quelle: Linux-Magazin

Kostenloser Online-Kurs zur Parallelprogrammierung

Wer schon immer mal die Grundprinzipien der Parallelprogrammierung lernen wollte, hat dazu in einem kostenlosen Online-Kurs des Hasso-Plattner-Instituts die Möglichkeit. Der Kurs startet am 3. Februar 2014 und geht über sechs Wochen. Die Kurssprache ist Englisch.

Quelle: Linux-Magazin

Hardware und Mobiles

Geeksphone stellt Revolution vor

Nachdem das Geeksphone Peak+ abgesagt wurde, wollte sich die spanische Firma Geeksphone auf ihr neues Gerät namens „Revolution“ konzentrieren, was diese Woche vorgestellt wurde. Das Smartphone wird mit Android ausgeliefert, unterstützt aber auch Firefox OS als Betriebssystem.

Quelle: heise open

Pyra wird Open-Pandora-Nachfolger

OpenPandora: war ein Spielekonsole-Handheld von 2010/11, die Linux als Betriebssystem benutzt und sonst auch nur auf Freie Software setzt. Der Nachfolger namens Pyra befindet sich aktuell in der Entwicklung. Genau Details sind noch nicht bekannt, da noch an der Platine gelötet wird.

Quelle: Golem