code.talks 2014 – Review und Erfahrungsbericht

Einleitung zur Code.Talks 2014

Aus der Developer-Conference 2013 wurde die Code.Talks 2014. Die letzte Konferenz brachte bereits einige gute Infos auf den Tisch, und hatte seinen eigenen Charme, sowie gutes Essen, nicht zu vergessen.

Dieses Jahr entschloss ich mich wieder aufgrund der Erfahrungen des letzten Jahres ebenfalls wieder auf der Code.Talks 2014 mit dabei zu sein. Die Anreise plante ich dieses Jahr mit dem Auto, auf der Webseite der Code.Talks waren entsprechende Parkmöglichkeiten vermerkt, die ich mir vorgemerkt hatte und dort versucht hatte einen Parkplatz zu finden.

Feststellen musste ich letztlich doch, dass ich keinen Parkplatz innerhalb meiner 1,5 stündigen Suche nach einer Parkmöglichkeit fand. Das war mein persönlicher erster Reinfall dieses Jahr. Dementsprechend entschloss ich mich, den ersten Tag an mir vorbei ziehen zu lassen und am zweiten Tag auf die Code.Talks 2014 zu gehen.

Am zweiten Tag entschloss ich mich mit der Bahn zu fahren, und dementsprechend war ich ohne lange weitere Suche nach einer Parkmöglichkeit noch ideal zum Frühstück auf der Code.Talks 2014 anwesend. Nach Ankunft und einem leichten Frühstück wie aber auch einem Kaffee ging es dann los pünktlich um 10:00 Uhr. Im ersten Moment beim Betreten des Saals stellte ich die erste positive Veränderung an der Code.Talks 2014 zum letzten Jahr fest.

Die Säle waren beschriftet, je nach Themengebiet und somit wusste man beim Betreten des Saals bereits welche Themen dort einen Erwarten könnten.

code.talks

 NoSQL – Konzepte live und in Farbe

 Der erste Beitrag den ich mir anhörte handelte über NoSQL. Zu beginn der Präsentation wurde eine Relation zu relationalen Datenbanksystemen geknüpft um gewissermaßen einen Bezug für NoSQL Anfänger zu schaffen. Das fand ich, als jemand der sich mit NoSQL nie beschäftigt hat gut. Es wurden die Arten von NoSQL aufgezeigt:

• Graphen
• Spalten (z.B. Cassandra)
• Dokumente (z.B. MongoDB)

Explizit wurde allerdings nur auf das Thema dokumentenorientiere Technologien eingegangen, letztlich auch nachvollziehbar, wenn für einen Talk nur 45 Minuten eingeplant sind. Als Beispiel für dokumentenorientierte Technologien wurde auf MongoDB eingegangen. MongoDB ist eine KVP (Key-Value-Pair) basierte Datenbank, welche die Möglichkeit bietet verkettete KVPs in einer Collection (Tabelle) anzulegen.

Im Prinzip ist die Abfragesprache zu MongoDB recht simpel, sie beruht auf JSON kodierten Queries. Mit ein wenig Erfahrung rund um JSON, ist fällt das Verständnis rund um MongoDB recht simpel.

Im Anschluss auf die kurze Erklärung von MongoDB wurde die Thematik bzgl. der Skalierung behandelt. NoSQL-Datenbanken sollten möglichst nicht vertikal skaliert werden, sondern stattdessen eher Horizontal. Allerdings auch da stößt man auf einige Komponenten die zwingend notwendig sind. Die Skalierung in MongoDB erfolgt anhand von Sharding. Auf einer Router-Instanz (Mongos) werden die Keys konfiguriert, anhand der das Sharding erfolgt. Sobald eine Abfrage über diesen Key erfolgt, ist die Abfrage recht performant, da der Router eindeutig weiß in welchem Shard sich der Datensatz befindet. Bei einem anderen Key dagegen durchsucht der Router alle anderen Shards ebenfalls nach dem jeweiligen Datensatz.

Empfohlen wurde in dem Talk für ein Produktivsystem folgende Struktur:

• 3 Config-Server
• 4 Shards a 3 Mongod
• 4 Router-Instanzen

Was ich recht vermisst habe ist ein deutlicher Vergleich zwischen relationalen Datenbanksystemen und NoSQL. Ich muss eingestehen, dass mir nicht die Vorteile von NoSQL hervor gingen, denn letztlich merkte ich in der Fragerunde, dass trotz der hohen Flexibilität von NoSQL man in gewisser Form auf die gleichen Probleme wie mit relationalen Datenbanksystemen stößt.

 Datengetriebene Analyse und Verbesserung von Code

Im Anschluss gings für mich weiter mit der datengetriebenen Analyse und Verbesserung von Sourcecode. Die Frage die sich mir hierbei stellte im ersten Moment ist, worum handelt der Beitrag?

Diese Frage erledigte sich für mich recht schnell. Es ging um automatisierte Code-Reviews im Bezug zu sauberen Sourcecode.

Die Definition von gutem Code für den Vortrag von Herrn Drewes war folgende:

• Lesbarkeit
• Wenige Bugs
• Erweiterbarkeit / Wiederverwendbarkeit
• Effizienz

Bezugnehmend dazu ist er in seinem Vortrag auf vier Punkte von Code-Reviews eingegangen:

Automatische Code-Reviews

• Automatisch
• statisch

Unit-Testing

• Automatisch
• dynamisch

Manuelle Code-Reviews

• Statisch
• Manuell

Debugging Profiling

• Dynamisch
• manuell

Code-Reviews sind nicht nur nützlich und auch ebenfalls kosteneffektiver wie auch einfach umzusetzen,  sondern reduzieren auch den Bus-Faktor (Fehleranfälligkeit, diese lehnt sich an “vom Bus überrollt werden”).

In seinem Vortrag präsentierte Herr Drewes die von seinem Unternehmen entwickelte Lösung für Code-Reviews, welche anbei auch kostenlos nutzbar ist unter http://quantifiedcode.com. Es lassen sich anhand dieser Lösung Codereviews mittels von Mustern und Datenstrukturen tätigen, wo Beziehungen zwischen Klassen eines Moduls anhand von Graphen und Kanten in einer Graphdatenbank dargestellt werden.

Im Prinzip war der Vortrag von der Code.Talks 2014 super. Allerdings ist die Lösung für die Codereviews leider erst einmal nur für Python-Sourcecode begrenzt.

Composerphp – 10 Gebote Composer Edition

Auf der Code.Talks 2014 wurde desweiteren ein Beitrag zu Composer vorgestellt. Es wurde hauptsächlich auf das Thema Versionierung eingegangen, und in welcher Form bestenfalls die Tags für Versionen definiert werden sollten.

• Major – Breaking Change (z,B, 1.0.0)
• Minor – added backward-compatible feature (z.B. 1.1.0)
• patch – bugfix (z.B. 1.1.1)

Nach der schönen Erklärung von den Versionsnummern, wurde auf das Thema bzgl. der Konfiguration von Composer bzgl. des Updaten von Paketen erklärt, und der Zusammenhang zwischen einzelnen Abhängigkeiten von Paketen, best practises Erläutert und auf Punkte eingegangen die mit vorsicht zu genießen sind.

Ein Beispiel dazu wäre z.B., dass im Bezug zu “git rebase” vorsicht geboten ist. Ein automerge kann gerne einmal composer zerschießen, welches dann zur Folge hätte, dass bestimmte Dependencies nicht mehr updatebar sind.

Ebenfalls sollte bei der Entwicklung von Libraries die lock-Datei von Composer nicht mit in z.B. git eingecheckt werden, dies kann man gerne bei der Entwicklung von Applikationen tun, doch bei einzelnen Libraries wird dies nicht empfohlen.

Man sollte sich auch grundsätzlich bei der Konfiguration von Composer darauf beschränken, dass stable Pakete nur innerhalb der Minor-Versionen geupdated werden und mit der Konfiguration z.B. dann updates auf die nächste Major-Version vermieden werden, da Major-Versionen bekanntlicherweise nicht abwärtskompatibel sind, und damit ggf. im Produktivmodus die Anwendung zerschießen.

Es ist auch ratsam z.B. anhand von dem Tool “medusa” github repos zu mirrorn, um beim Ausfall von github o.ä. weiterhin innerhalb des Unternehmens den aktuellsten Stand der Abhängigkeiten anderer Pakete zu erhalten.

 SSL / TLS erklärt

Im ersten Moment war ich hier am abwegen, welche Session ich besuche, SSL / TLS erklärt oder doch lieber “Guerrilla software design: doing it wrong and getting it right”. Im Endeffekt entschloss ich mich für das Erste.

Der Vortrag auf der Code.Talks 2014 wurde präsentiert von einem Python-Entwickler, der sich um z.B. die openSSL Implementation innerhalb von Python kümmert, sowie bereits einige CVEs bezüglich von SSL aufgedeckt hat.

In dem Vortrag wurde die Funktionsweise von TLS 1.2 erklärt und auf entsprechende Manipulationsschutzweisen eingegangen. Der Vortrag war sehr technisch, und meiner Meinung nach exzellent, auch wenn die Zeit etwas knapp war. Ebenfalls wurde Ansatzweise auf die Konfiguration von Zertifikaten eingegangen, die vorhandenen Informationen in X.509 Zertifikaten erklärt und Verweise auf Internetseiten erläutert die dafür dienen eigene Zertifikate auf ihre Sicherheit zu prüfen. Im großen und ganzen, einer der besten Vorträge die ich gehört habe rund um SSL / TLS.

Es wurde empfohlen im Bezug auf TLS, GCM statt AES + CBC zu verwenden. Ebenfalls wurde empfohlen gerade bei der Konfiguration vom Apache oder anderen Webservern das Zwischenzertifikat mit einzubinden, das Root-Zertifikat welches auch beim CA erhältlich ist, ist dagegen relativ nutzlos.

Zend Framework 3 – Viva la evolución!

Da ich mir selbst bereits seit langem vorgenommen habe mich mit dem Zend Framework 2 außereinander zu setzen, war ich auch auf die Idee gekommen den Vortrag von Ralf Eggert mir ebenfalls auf der Code.Talks 2014 anzuhören. Zwar habe ich mir im Vorfeld bereits vor einigen Monaten ein Buch zum ZF2 gekauft, auch ebenfalls von Ralf Eggert, dem Buchautor und dem jenigen der das Zend Framework 3 präsentierte, aber nie so wirklich Zeit dafür gefunden es komplett zu lesen.

In erster Linie wurde in dem Vortrag mehr über ZF1 und ZF2 gesprochen als eigentlich rund um ZF3. Es wurde der Wachstum von ZF beschrieben und erläutert, die Probleme die beim Einlernen in ZF bestehen wurden geschildert. Dass ZF mächtig ist, ist nicht abstreitbar, dass das Lernen des Frameworks nicht all zu einfach ist, resultierte mir bereits vorher beim Lesen des Buches zu ZF2. Meine Vermutung, dass der Einstieg für andere auch ebenfalls hart ist, hat sich auf dieser Session für mich bestätigt.

In Version 3 vom Zend Framework, soll dieses um einiges performanter werden als das ZF2, sowie die Router-Konfiguration soll vereinfacht werden.

Auch wurden in diesem Vortrag gerade beim Laden von Views beschrieben, wie das Laden von Views bestenfalls nicht realisiert werden sollte, um das Caching weiterhin zu gewährleisten. Auch dies war ein Beitrag zur Code.Talks 2014.

Eine kurze Geschichte der Testpraktiken

 In diesem Vortrag wurde auf die Geschichte von Bugs eingegangen, sowie die Arten des Testens von Software. Der Vortrag von der Code.Talks 2014 wurde präsentiert vom Gründer und Entwickler von phpunit.

Insgesamt war der Vortrag hervorragend.Es wurde explizit auf die Testverfahren

• Acceptance Test-Driven
• Behavior-Driven Development
• Test-Driven Development

eingegangen. Wobei das Test-Driven Development im ersten Moment recht verstörend klang, bringt es Vorteile mit. Test-Driven Development heißt so viel wie, dass die Tests vor der eigentlichen Anwendung implementiert werden. Der Vorteil der sich daraus ergibt ist, dass tatsächlich nur das implementiert wird, was benötigt wird, und eben auch so dass die jeweiligen Methoden oder gar Klassen auch getestet werden können. Die Definition von Sebastian Bergmann ist folgende: “Wenn Sourcecode nicht getestet werden kann, ist es kein guter Coding-Stil”.

Der komplette Vortrag richtete sich um die Art des testens, nicht um Tools zum testen von Sourcecode.

Ab in die Horizontale – Parallelisierung mit Queues

Dieser Beitrag richtete sich um die Parallelisierung mit Queues, welcher ebenfalls auf der Code.Talks 2014 vorgestellt wurde. Explizit wurde in diesem Zusammenhang auf RabbitMQ eingegangen, in welcher Form es ideal ist Worker aufzubauen um das Abarbeiten von Queues zu optimieren.

Ich persönlich empfand diesen Vortrag als nicht all zu spannend, gerade da die Technik nicht mitspielte die für diese Präsentation von Daniel Seif vorbereitet wurde. Die Vorteile des Konzeptes konnten damit nicht in einer Live Demo vorgestellt werden. Ebenfalls handelte es sich beim präsentierten Sourcecode um einen recht schlecht debuggten Code, wie ich vermute.

Fazit

Trotz einiger Pannen auf der Code.Talks 2014 wie z.B. dem WLAN-Zugang bin ich doch recht zufrieden mit der Code.Talks 2014. Letztes Jahr empfand ich die Vorträge um einiges spannender, aber dafür war die Code.Talks 2014 dieses mal um einiges besser organisiert. Beim WLAN-Problem gab es wohl entweder ein Problem mit dem DHCP, oder die Subnetzgröße wurde zu klein gewählt, vom WLAN-Dienstleister. Was ich dagegen doch gut feststellte, ohne hier heimlich Schleichwerbung einzubetten, war dass die DSL-Leitung der Firma für die ich tätig bin einwandfrei lief, welche für diese Veranstaltung geschaltet wurde. Das Essen war wie letztes Jahr auch wieder super. Die Organisierung der Säle war ideal. Der einzige Punkt den ich neben den bereits erwähnten bemängeln muss, mir fehlte auch dieses Jahr etwas mehr Bezug auf IT-Sicherheit auf der Code.Talks 2014.

Code.Talks 2014

7.4

Organisation

8.0/10

Qualität der Vorträge

8.0/10

Hotspot

3.0/10

Location

8.0/10

Athmosphäre vor Ort

10.0/10

Pros

• Bessere Organisation zum Vorjahr
• Freies Internet
• Freie Verpflegung
• Möglichkeiten zum Austausch gegeben
• Thematisch bezogene Räumlichkeiten

Cons

• Kaum Parkplätze vorort
• Wenige bis keine Vorträge zu Web-Security

Code.Talks