Spätestens durch GitHub hat Static-Site Generation für die breite Masse an Bekanntheit gewonnen. Das Prinzip ist relativ einfach: statt auf einem Server die Seite von PHP oder ASP.NET “zusammenrechnen” zu lassen, macht man es auf dem Entwicklerrechner und spielt die einzelnen HTML Dateien anschließend auf dem Server. Die Vorteile die ich dadurch sehe:
Der Webserver kann sehr einfach sein. Dadurch verringert sich die Komplexität in Wartung und Sicherheit. Migration auf andere Server sehr einfach.
We are Developers Ich hatte die “Ehre”, vor einem Monat die We are Developers Konferenz zu besuchen. Während der Konferenz gab es schon einige Unstimmigkeiten, welche Javascript Frameworks wohl die Besten sind. Viele Speaker sprachen sich gegen Framework X aus und verfechten das ultimative Framework Y. So ging es die ganze Zeit. Als eine Speakerin ein Framework (ich glaub es ging um das Framework von Xamarin) nicht kannte, ging ein Raunzen und Unverständnis durchs Publikum.
In der Firma beschäftige ich mich momentan mit Business Analyse. Das Buch Business Analysis For Dummies [1] definiert Business Analyse wie folgt:
set of tasks and techniques used to work as a liaison among stakeholders in order to understand the structure, policies, and operations of an organization, and to recommend solutions that enable the organization to achieve its goals.
Es geht bei Business Analyse also darum, Unternehmensabläufe zu verstehen, um sie verbessern zu können.
Die meisten Informationen habe ich aus dem Netz und aus dem Buch Kryptografie: Verfahren, Protokolle, Infrastrukturen (iX Edition).
Wie man Wikipedia entnehmen kann, ist Kryptografie heute mehr als nur die Lehre der Verschlüsselung:
… war ursprünglich die Wissenschaft der Verschlüsselung von Informationen. Heute befasst sie sich allgemein mit dem Thema Informationssicherheit …
Das Thema hat eine lange Historie vorzuweisen. Heute ist es ein Hilfsmittel im Alltag geworden - ein Auszug:
REST ist in vielerlei Munde. Oft sind sich die Nutzer über die Bedeutung dieses Buzzwords aber nicht einig. Grund genug, sich einmal die orginal Arbeit anzuschauen.
Das erste Interessante an der Arbeit ist einmal der Betreuer: Richard N. Taylor. Wenn man sich mit Software Architekturen auseinandersetzt (vorallem im akademischen Bereich), kommt man kaum um ihn herum. Auch sein Buch ist recht interessant.
Das erste Wort, welches einer Definition bedarf, ist der Architecture Sytle:
Ziel des letzten DOJOs war die Implementierung von Game Of Life. Auch wenn immer versucht wurde bis Ende des DOJOs eine lauffähige Version zu bekommen, so stand das Software Design und die korrekte Methodik (e.g. TDD) im Vordergrund. Es ist für einen Entwickler oft schwer sich zu bremsen und auf die korrekte Ausführung zu achten – daher empfinde ich es als gute Übung.
Die Implementierung erfolgte in 10 Minuten Pair Programming Sessions auf einem Laptop, sodass jeder Teilnehmer mit “Entscheidungen” anderer Teilnehmer arbeiten musste.
Übung macht den Meister – nicht nur im Sport. Coding Dojo erlaubt es, sich mit anderen Entwicklern auszutauschen und Ideen fließen zu lassen.
Die Softwerkskammer ist jene Plattform, an denen diverse Treffen angekündigt werden. Was passiert bei den Treffen? Teilnehmer bekommen Aufgaben gestellt und lösen diese meistens zu zweit. Zeit, um Denkweisen anderer Entwickler kennen zu lernen, Zeit um eventuell seine IDE besser kennen zu lernen oder womöglich bietet sich sogar eine Möglichkeit an, eine neue Programmiersprache zu lernen.
Ich habe mich im letzten Sommer ein wenig mit den Grundlagen der Kryptografie beschäftigt. Inzwischen ist Kryptografie nicht nur mehr die Lehre des Verschlüsselns, sondern weit mehr [1][2]. Neben der Kryptografie hab ich auch noch ein anderes Schlagwort gefunden: Security Engineering [3]. Vorweg: die Ganze Thematik ist extremst komplex aus meiner Sicht. Betrachten wir nur Mal die Kryptografie. Ein paar Schlagworte (jemand, der von Kryptografie Ahnung hat, wird an dieser Stelle lachen – für einen Newcomer doch sehr viel Information zum Verarbeiten):
Vom Sonnenschein zum Schlechtwetter - Fault Tolerance Wie im ersten Teil festgestellt, gibt es viel zu oft nur Schönwetter-Tests. Damit nicht genug – das System ist auch oft nur für Schönwetter gebaut. Wer kennt das nicht?
try { ... } catch(Exception ex) { ... } // Catch-Log-Forget In manchen Situationen ist diese Technik unvermeidbar - oft ist sie aber ein Zeichen für schlechtes Design. Einen passenden Einstiegspunkt für dieses Thema zu finden, finde ich persönlich kompliziert.
Wo alles anfing Agile Softwareentwicklung ist in aller Munde. Die meisten Teams haben diesen Softwareentwicklungsprozess adaptiert - oder zumindest die angenehmsten “Dinge” davon. Den ersten Kontakt mit agilen Methoden hatte ich bei einem Seminar auf der TU - u.a. mit “User Storys”. Ein guter Einstieg für mich war damals das Buch von Mike Cohn [1]. Ein sehr interessantes Zitat, welches bis heute in meinem Hinterkopf hängen geblieben ist:
Words, especially when written, are a very thin medium through which to express requirements for something as complex as software.
