Permalink
Switch branches/tags
Nothing to show
Find file Copy path
Fetching contributors…
Cannot retrieve contributors at this time
341 lines (223 sloc) 14.1 KB
layout title title_full date thumb
post
Lern-Historie 2015
Lern-Historie 2015: 4 Frameworks, 3 Programmiersprachen, 3 Templatesprachen [Update #1]
2016-06-07
/files/2016/are-you-too-busy-to-improve2.jpg

Beschäftigungsfähig ist, wer seine Arbeit in der marktüblichen Geschwindigkeit erledigen kann

Aber was "marktüblich" ist, entwickelt sich vor allem für Web-Devs rasend schnell weiter. Die Anforderungen werden immer komplexer. Man selbst muss als System beweglich bleiben.

Aber was nun genau als nächstes lernen? Der Kontext entscheidet über die relevanten Learnings. Jeder hat einen anderen Arbeitsbereich, einen anderen Interessenbereich. Aber es gibt Gemeinsamkeiten. Z.B. Code-Hygiene geht alle an, da Code wesentlich öfter gelesen als geschrieben wird.

Meine Learnings bestanden aus einen Mix aus privatem Interesse für CodeForGermany-Projekte und beruflichen Entwicklungen. Hauptsächlich aber aus Dingen die ich spannend finde und Spaß am Lernen hatte.

Das sind meine Learnings in 2015 gewesen, jeweils notiert mit den Erkenntnissen und Lernaufwand. Meine Hoffnung ist, den einen oder anderen zu inspirieren, über den (zu oft bemühten) Tellerrand hinaus zu blicken und sich auszutesten. Lernen ist auch immer sich selbst zu fordern.

[Update 2.6.] aus "Pragmatisches Denken und Lernen" [Hun08]:

Ein wesentlicher Unterschied zwischen Investitionen in Wissen und Finanzinvestitionen besteht darin, dass sämtliche Investitionen in Wissen irgendeinen Wert haben. Selbst wenn Sie eine bestimmte Technik nie bei der Arbeit einsetzen, beeinflusst sie die Art und Weise, wie Sie denken und Probleme lösen. Folglich ist alles, was Sie lernen, von Wert. Nur Handelt es sich dabei möglicherweise nicht um einen direkten, kommerziellen, arbeitsbezogenen Wert. Vielleicht hilft es Ihnen dabei, Ihren R-Modus zu entwickeln, oder den fließenden Übergang vom R-Modus in den L-Modus zu unterstützen.

Für mich bedeutet das: Auch wenn ich mittelfristig nicht im Beruf eine ausschließlich funktionale Sprache wie Erlang/Elixir täglich einsetzen werde, so zeigt es mir doch, dass man a) damit tatsächlich programmieren und b) auch hervorragend und lesbar Probleme lösen kann. Auch wenn ich nicht täglich mit Golang zu tun habe, zeigt es mir doch, dass man auch mit einer reduzierten, prozenduralen Programmiersprache hervorragend und effizient arbeiten kann.

Die konkrete Timeline: (Achtung: Buzzword-Bingozettel bereithalten!)

  • Bootstrap (Herbst 2014 - März 2015)
  • Docker (Nov. 2014 - Jan. 2015)
  • Python (Dez. 2014)
  • Jade (+ Reveal.JS) (Jan. 2015)
  • Markdown (März 2015)
  • Typescript (Mai - Sept. 2015)
  • Meteor (+ Coffeescript + Spacebars + MongoDB) (Mai - Juli 2015)
  • Git (Aug. 2015)
  • Elixir (Aug. - Sept. 2015)
  • Ember (+ Handlebars) (Sept. - Okt. 2015)
  • Phoenix (Okt. 2015 - Dez. 2015)

Vorwissen

Learnings aus 2014 und früher

  • NPM: Node.JS Packetmanager
  • Bower: Frontend Paketmanager
  • Sass/Less: CSS-Präprozessor
  • Grunt: JS-Taskrunner, Build-Workflow
  • Composer: PHP-Paketmanager

Lerne Responsives Webdesign

Bootstrap ist das populärste CSS/HTML/JS Framework für Responsive und Mobile First

  • arbeiten mit einen flexiblen Grid
  • "schwergewichtiges" Komplett-Framework
  • viele Komponenten vorgedacht

Erkenntnisse

  • Responsive ist schwierig aber beherrschbar
  • Flat Design = den ganzen Kitsch rausschmeißen
  • es gibt so viele Probleme die schon gelöst sind

Lernaufwand

  • Tutorials und Guides auf Bootstrap Projektseite lesen
  • Learning by doing (bei mir: kleinere Homepage, Umstellung eines OXID-Shops)

Lerne Virtualisierung

  • schlanke Container mit Docker
  • Virtualisierung lokaler Entwicklungsumgebung
  • Simulierung getrennter Services (MySQL, Apache)

neue Erkenntnisse

  • Definition in Dockerfile = Dokumentation
  • Mac entschlackt, weniger Seiteneffekte, weniger Wartung
  • Virtelle Maschine != 1 GB RAM pro VM
  • bessere/gezielte Abbildung des künftigen Produktivbetriebs

Aufwand

  • Onboarding in OK Labs = 1 Abend, danke @morrisjbk !
  • Artikel in PHP Magazin lesen
  • lokale Entwicklung umstellen = 1 Wochenende (optional)

Lerne Python (ein bisschen)

genutze Vorkenntnisse:

  • Programmieren können

neue Erkenntnisse

  • keine Klammern sind OK
  • weniger Syntax-Clutter = mehr effektiv tuender Quellcode
  • für schnelles Doing genau so gut geeignet wie PHP

Aufwand

  • eine Hackernacht bei mir zuhause mit dem Codefor-Leuten
  • danke @symptog !

Lerne Template-Engines

Jade ist eine Template-Engine

genutze Vorkenntnisse:

  • HTML/XML-Struktur kennen
  • Python: Dinge weglassen ist OK

neue Erkenntnisse

  • keine Tags sind OK
  • weniger Syntax-Clutter = freie Sicht auf den Inhalt
  • Probleme bei JS-Integration und Verschachtelungen
  • aber sehr gut für Inhalt (aber besser noch ist Markdown!)

Aufwand

  • Jade Referenz querlesen = ca 1h
  • ein Codefor-Abend um die Präsi umzustellen = 4h

Lerne Markdown

  • einfache Dokumenterstellung
  • Quasi-Standard mittlerweile (u.a. GitHub, dieser Blog-Post)
  • Umstellung meines Wordpress

genutze Vorkenntnisse:

  • ähnliche Syntax wie unser DokuWiki
  • Weglassen von Clutter ist gut

neue Erkenntnisse

  • viel Tooling-Unterstützung
  • einfache Transformation z.B. zu HTML, PDF, eBooks
  • Tabellen sind ein Problem

Aufwand

  • GitHub Basic Tutorial = 0,5h querlesen
  • learning by doing: bloggen, README.md schreiben (SCM zeigt diese an)

Lerne JS-Präprozessoren (Typescript)

genutze Vorkenntnisse:

  • Javascript, Build-Workflows
  • saubereres JS durch mehr Linting

neue Erkenntnisse

Aufwand

Lerne durchgehendes Fullstack (JS)

Meteor ist ein solches Framework nutzt Spacebars (Basis Handlebars) als Templatesprache und MongoDB

  • Javascript in Back- und Frontend
  • Reaktive Programmierung
  • Kommunikation per Websockets (DDP)

genutze Vorkenntnisse:

  • Coffeescript
  • Buildworkflow mit Bower, NPM, Grunt
  • Websockets

neue Erkenntnisse

  • Next-Level-Webentwicklung
  • arbeiten mit MongoDB
  • arbeiten mit {{spacebars}}
  • Fullstack-Pakete = Nutzeraccount-Verwaltung in 5 Min.
  • Prototyping gut möglich
  • Reaktive Programmierung macht Spaß
  • nahtlose Integration von Daten in App

Aufwand

  • mitgelieferte Beispiel-Apps analysieren = 1 Abend
  • Sensor-Karte für OK Labs Projekt bauen = 2 Wochenenden
  • Buch "Discover Meteor" durchlesen = 2 Wochen Abends 1h

Lerne Coffeescript

genutze Vorkenntnisse:

  • Javascript
  • keine Klammern sind OK

neue Erkenntnisse:

  • ausdrucksstarke Syntax = weniger Syntax-Clutter = mehr effektiv tuender Quellcode
  • anfangs stellt man sich die JS-Syntax noch vor, das hört auf

Aufwand:

  • Tutorial querlesen
  • learning by doing in Meteor

Lerne Versionsverwaltung

Git ist der Opensource-Standard (GitHub)

genutze Vorkenntnisse:

  • SVN und CVS

neue Erkenntnisse

  • Repo liegt lokal komplett inkl. Historie vor = Backup
  • push und pull für Kommunikation mit Repo-Server
  • git hat unfassbar umfangreiches Tooling
  • GitHub Desktop GUI ist todeinfach ("Sync" = push&pull)

Aufwand

  • tryGit 15 Min. Basis-Tutorial = ca 0,5h
  • learning by doing (git init auch wenn man es nur komplett lokal historisiert)
  • Git-Schulung durch @hwohner (Danke!)

Lerne Elixir

  • Funktionale Programmiersprache, basiert auf Erlang
  • einfache Sprach-Bibliothek mit enorm vielen Funktionen

genutze Vorkenntnisse:

  • Programmieren können
  • Offenheit gegenüber Neuem
  • Übung in lesen von englischen Texten
  • Vertrauen zu Influencern (Hallo @hisako1337 !)

neue Erkenntnisse

  • funktionale Prog. ist anders als imperative Prog.
  • Veränderung der Denkweise nötig
  • kleinere Funktionen werden erzwungen
  • Pattern Match ist der Burner! (viel Aussagekraft mit wenig Code)
  • Ruby muss syntaktisch toll sein, denn viel davon steckt in Elixir
  • z.B. !? an Funktionen: any? -> liefert Boolean, read! -> Exception bei Fehlern, read -> nur false bei Fehlern
  • programmieren nach "let it fail" Prinzip dank Supervisor
  • Logging und Testing sind "first class citizens"

Aufwand

  • Buch "Programming Elixir" von Dave Thomas lesen = ca. 3 Wochen Abends 1h lesen
  • "Your turn" Aufgaben tatsächlich machen (fast alle) = ca. 20h

Lerne Frontend-Framework Ember

  • ist komplettes MVC-Framework mit Templatesprache Handlebars

genutze Vorkenntnisse:

  • Spacebars aus Meteor
  • MVC-Struktur
  • Build-Tools

neue Erkenntnisse

  • MVC-Framework im Frontend hat eine flache Lernkurve = alles ist neu
  • Testen ist Kernkomponente
  • Mock-Server für Daten mit Mirage möglich
  • Build-Tool Broccoli funktioniert unter Windows nicht gut

Aufwand

Lerne Phoenix

  • Webdev-Framework auf Basis Elixir

genutze Vorkenntnisse:

  • Elixir
  • Grundkenntisse anderer Frameworks (Router, Controller, Templates)

neue Erkenntnisse

  • deutlich zu viele für eine Folie, u.a.
  • FP in Frontend-Webdev ist möglich
  • OOP muss nicht Eigenschaften an Klasseninstanzen sein
  • arbeiten mit ORM (Ecto) löst Probleme
  • Datenverarbeitung per Transformation
  • |> ist großartig

Aufwand

Ein bisschen Selbstreflektion zum Schluss

Wie fühle ich mich nun in Vergleich vor einen Jahr? Weniger festgefahren im Denken. Gerade die vielen Programmiersprachen habe mir als PHP-Entwickler gezeigt, dass es mehr gibt im sehr pragrmatisch orientierten Scripting-Kosmos. Zudem hat jede Sprache und Tech ihr Für und Wider. Wenn man viel kennt, kann man bei den täglichen Anforderungen aus mehr Möglichkeiten schöpfen. Die Herausforderung besteht darin a) die Anforderungen wirklich zu verstehen, b) nicht falsch zu liegen und c) die richtigen Worte zu finden die Entscheidungsträger konstruktiv mitzunehmen.

Worin habe ich mich verbessert? Im etablieren der Best-Practises aus anderen Sprachen in meine tägliche Arbeit, hauptsächlich in und mit PHP und JS. Z.B. vermeide ich mixed returns wie @``return bool|array sondern @``return array($data, $err) welches super mit list($data, $err) auf Variablen gemappt werden kann. Auch nutze ich viel mehr funktionale Konzepte wie array_map und array_reduce. Wobei manchmal ein simples zweifach geschachteltes foreach schlicht besser zu lesen ist. (Hallo Golang 😄)

Gehe ich Probleme anders an? Das können wohl nur die Leute beurteilen die mit mir täglich zu tun haben. Ich kann zumindest in Tech-Entscheidungsfindung mehr Aspekte einbeziehen und argumentativ mehr mitwirken. All die Tech und Libs helfen prinzipiell ja auch nicht, Probleme anders zu durchdenken. Dabei helfen eher Bücher wie "Der Pragmatische Programmierer" von Dave Thomas (ja, der der das Elixir-Buch geschrieben hat) und "Pragmatisches Denken und Lernen. Refactor your Wetware!" von Andrew Hunt.

Kann ich Probleme einfach(er)/schneller lösen? Libs und Tooling machen in einen komplexen Softwareprojekt nicht mal 50% aus bzgl. des Zeitaufwandes, tendenziell eher Richtung 20%. Klar, sie sollen ja auch Arbeit abnehmen, sodass man sich auf die harte Businesslogik konzentrieren kann. Ich denke, das Ziel ist mit dem ganzen Tooling definitiv erreicht. Was alleine das JS-Linting durch Typescript für Schmerzen erspart..

Wie ist die Halbwertszeit des Wissens? Libs und Tooling sind wichtig und nehmen viel Arbeit ab, verändern sich aber genauso rasend schnell wie der Rest vom Internet-Dev-Space. Sprachen und Libs sind damit einer gewissen Mode unterworfen. Die Karavane zieht auch schnell mal weiter wenn es etwas besseres gibt. Zudem findet auch bei Libs Konsolidierungen statt, wobei die verwaisen/vernachlässigt werden, die nicht auf den nunmehr De-facto-Standard gesetzt haben.

Beispiel Taskrunner: Grunt war das erste JS-Build-Tool. Mittlerweile gibt es noch zig weitere, u.a. Gulp, Broccoli, Brunch. Grunt stellt insbesondere für Umgebungen die starke Individualisierung der Build-Chain erfordern immernoch die beste Wahl dar. Aber ob in ein, zwei Jahren noch irgendwer dafür neue Module baut oder bestehende pflegt steht in den Sternen.

Beispiel Chart-Grafiken: Vor Jahren war Flot supertoll, mitterlweile wird es praktisch nicht mehr gepflegt (letztes Release April 2014), dafür gibt es einen Sack voll D3-basierenden Grafik-Libs (C3, NVD3, Graphene und andere).

Bei all dem Stress

Never forget how to do nothing

Mal schauen was 2016 so bringt ..

Danke für die zahlreiche Inspiration, Erklärungen und Challenges @hisako1337, @morrisjbk, @symptog und phibos.