Social Coding Diary

Abschluss und Zusatztermin

Wed, 20 Jul 2016 08:45:56 +0000

Der Abschluß des Kurses fand auf dem DevHouse Friday statt. Hier hörten wir einen Talk von Jan Kus über die Ebics::Box, eine Box die ziemlich abgefahrene Finanz-APIs irgendwie einfacher macht.
Nach dem ersten Talk verstreute sich die Gruppe zum Teil in Cocktail-Bars und zum Teil in Subway-Schnellrestaurants in Gummersbach.

Beim Zusatztermin beschäftigten wir uns noch einmal mit Testing. Neben weiteren Unit-Test befassten wir uns auch mit Acceptance-Tests.
Außerdem schauten wir uns Work-Setups an, sprechen über Dotfiles und lernten ein bisschen tmux-magic kennen. Für die Zukunft interessant finde ich vor allem Spacemacs, mit dem ich mich nach dem Urlaub auseinandersetzen möchte.

7. Termin

Wed, 08 Jun 2016 08:45:56 +0000

Thema beim 7. Termin waren Debugging und Testing. Anhand des Beispiels von Batman Ipsum verscuhten wir zunächst, Bugs in einem unbekannten Programm zu finden. Anschließend ging es noch um die richtigen Wege, eine Issue zu eröffnen oder direkt einen Pull Request zu starten.

Nachdem die Bugs gefunden und gefixed waren befassten wir uns mit dem Thema Unit-Testing und wie man vernünftige Tests schreibt. Dieses Thema wurde auch beim Zusatztermin am 20. Juli noch einmal angegangen.

Zuhause fixten wir die vorhandenen Bugs noch einmal und öffneten Pull Requests. Für mich war hier vor allem das Forken interessant, da ich das vorher noch nich gemacht habe.

6. Termin

Wed, 01 Jun 2016 08:45:56 +0000

Am 6. Termin hielten wir die Talks, die wir über die vorausgegangenen Woche vorbereitet hatten.

Mein Thema war das erstellen eine Twitter-Bots, der aus zwei alten meiner Tweets einen (möglichst sinnvollen) neuen erstellt. An sich bin ich mit dem Talk recht zufreiden, allerdings gibt es einige Kleinigkeiten, die mich stören.

Zum ersten habe ich mein Ziel nicht erreicht, durch verschiedenen technische Probleme konnte ich keinen funktionierneden Bot bauen. Der Talk beschäftigte sich daher nicht mit dem eigentlichen Thema, sondern mit den Problemen, die auf dem Weg aufgetreten sind. Obwohl das nicht die optimale Ausgangslage hatte der Talk trotzdem genug substanz.

Insgesamt war der Talk etwas zu kurz, durch den Wechsel des Inhaltes hatte ich nicht sonderlich viel Zeit, ihn vorher zu üben. Dazu kommt, dass ich beim Talk schneller gesprochen habe als bei den 2-3 Testläufen zuhause un dieser dadurch noch kürzer wurde. An sich würde ich die Erfahrung jedoch als positiv bezeichnen und ich konnte das angebrachte Feedback gut gebrauchen.

Abschließend betrieben wir einmal selbst Code-Golfing. Wir schrieben zwei Javascript-Snippets (eines in Node.js, eines in Vanilla JS), mit deren Hilfe man Platzhalter-Bilder von Lorem Flickr generieren konnte. Sowohl das Node.js Snippet als auch das Vanilla JS Snippet passten in einen Tweet. Sehr spaßig!

5. Termin

Wed, 25 May 2016 08:45:56 +0000

Der 5. Termin beschäftigte sich mit der Frage, wie man einen eigenen Talk organisiert.

Zunächst sollten ein paar Dinge geklärt werden, wie z.B. warum wird der Talk überhaupt gehlaten, also: welche Ziel hat er? Was ist die Zielgruppe des Talks? Expreten oder Anfänger? Ist das Publikum auf eine Disziplin beschränkt oder eher gemischt? Auf welcher Sprache wird der Talk gehalten? Im bezug auf die Sprache wurden auch einige Dos & Don’ts aufgezeigt.

Nach dem klären dieser Fragen geht es um den eigentlichen Talk: Wie ist dieser aufgebaut, was wird wann erzählt und wie schafft man es, dass die Zuhörer sich nicht zu Tode langweilen? Hier wurde uns gezeigt, wie man am schlauesten eine Outline für einen Talk schreibt.

Im letzten Teil ging es dann darum, wie die Slides visuell angenehm zu gestalten sind. Hier ging es sowohl um Bilder und Typographie, als auch um Colorschemes und Layout der Slides.

Zum Ende haben wir uns Themen ausgesucht, über die wir beim nächsten Termin einen Talk halten wollten.

4. Termin

Wed, 18 May 2016 08:45:56 +0000

Der 4. Termin fand nicht im üblichen Format statt, sondern wir besuchten eine User-Group, die Cologne.rb. Wie der name schon vermuten lässt beschäftigt sich die Cologne.rb mit Ruby. Auch wenn es mein Name nicht unbedingt vermuten lässt beschäftigte ich mihc bisher eher weniger mit Ruby. Ich wusste daher nicht so recht, was ich erwarten sollte.

Auf der Usergroup wurden drei Talks gehalten: Zum Thema Verschlüsselung, zum Thema Code Golf und ein Live-Beispiel zum Golfen.

Der Talk zur Verschlüsselung war recht mathematisch und hat mich in den rechenintensiveren Teilen öfters verloren, die generelle Logik hinter der Verschlüsselung von Daten zu verstehen war allerdings sehr interessant.

Sehr unterhaltsam war der Talk zum Code Golfing, bei dem es darum ging, ein lauffähiges Stück code in 140 Zeichen oder weniger bringen. Sowohl die Idee, als auch die Präsentation des Talks gefielen mir sehr gut.

Als letztes gab es ein Livecoding zum Code Golf, bei dem der Versuch unternommen wurde, eine Ruby on Rails App in 140 Zeichen zu verpacken. Obwohl ich weder von Ruby noch von Rails großartige Vorkenntnisse besaß war es interessant zu sehen, aus welchen Teilen eine Rails App besteht und welche von ihnen man löschen kann ohne ihre Lauffähigkeit zu beeinflussen.

Vor der Cologne.rb war ich nur auf einem Meetup (Webmontag), werde in Zukunft aber noch öfter an welchen Teilnehmen. Ich denke, Meetups sind ein gutes Format, um neue Leute und Ideen kennen zu lernen und den eigenen Horizont etwas zu erweitern (gerade, wenn man auf meetups “fremder Sprachen” teilnimmt).

3. Termin

Wed, 04 May 2016 08:45:56 +0000

Der dritte Termin beschäftigte sich mit deployment also der Frage, wie ich meine änderungen im Code in eine Live-Umgebung schiebe. Hierfür haben wir uns mit einem Beispiel das Tool Heroku angesehen.
Mit Heroku ist es sehr simpel, einen laufenden Serve für gar kein bis wenig Geld aufzusetzen. Wir haben uns angesehen, wie man eine App mit Heroku verknüpft und die änderungen pushed. Aus Spaß haben wir uns auch angesehen, was man machen müsste, wenn man den Server komplett selbst aufsetzen würde (mit Hilfe von Digital Ocesn Droplets.

Außerdem haben wir uns mit Virtuals Machines beschäftigt und wie diese in Development und Deployment zum Einsatz kommen. Generell besteht der Vorteil bei ihrem Einsatz darin, dass man eine garantiert laufende Development-Umgebung bereit stellen kann die jeder sofot nutzen kann. Es müssen also keine dependencies mehr installiert werden. Das einzige, was (bei Vagrant) nach dem Clonen noch gemacht werden muss, ist das Ausführen von Vagrant Up.

2. Termin

Wed, 27 Apr 2016 08:45:56 +0000

Der 2. Termin stand unter dem Motto “Start Hacking”. Zu Beginn gabe es einen kurzen Input: Was genau bedeutet Social Coding eigentlich? Welche Wege gibt es, um einem Projekt oder einer Community zu helfen, eben sozial zu coden?
Auch wenn hier sofort Github ins Gedächtnis kommt, ist das nicht alles. Genauso hilft es, Dokumentationen zu schreiben oder Blogpost zu veröffentlichen.

Außerdem beschäƒtigte sich der Input mit der Frage, wie man ein Projekt findet, an dem man in irgendeiner Weise mitarbeiten möchten. Hier sind vor allem solche Projekte sinvoll, mit denen man persönlich, ob privat oder im Arbeitsalltag, zu tun hat.

Im zweiten Teil des Termins sollten wir dann selber an etwas mitwirken. Für mich persönlich bot es sich an, Bug Tracking im Node-Modul Node Sass zu betreiben. Hier hatte ich seit längerem das Problem, dass die binaries des Moduls nicht automatisch gebuildet wurden, sondern ich diese manuell (über node-sass/scripts/install.js) erzeugen musste.
Ich versuchte also nachzuvollziehen, wie das Modul aufgebaut ist und an welcher Stelle die binaries gebuildet werden sollten. Aufgrund der mäßig guten Internet-Verbindung stellte sich das als langwierige Aufgabe heraus, da ich den installationsprozess häufig durchlaufen lassen musste.

Wirklichen Erfolg hatte ich damit leider nicht, der Bug besteht bis heute. Da ich allerding aus der einzige Mensch zu sein scheine, bei dem dieser Bug auftritt würde ich die Ursache dafür außerhalb von Nodes-Sass vermuten. Insgesamt hat mir dieser Termin aber dabei geholfen, mich in fremden Code einzulesen und diesen auch zu Debuggen.

1. Termin

Wed, 20 Apr 2016 08:45:56 +0000

Der erste Termin beschäftigte sich mit den Basics von Git und GitHub. Da mir diese grundlegenden Basics weitestgehend bekannt waren werde ich diese hier nicht noch einmal explizit aufführen. Dieser Eintrag wird sich daher eher mit den Dingen beschäftigen, die mir noch nicht bekannt waren und diese ggf. weiter vertiefen. Dies betrifft vor allem die standard git befehle, die jederzeit mit git --help über die command line eingesehen werden.

Generelle Funktionsweise von Git

Initialisiert man einen Ordner durch den Befehl git init als Git Repository wird in diesem Ordner ein Unterodner mit dem Namen .git angelegt. Git identifiziert einzelne Zustände des Rpository über einen SHA1-Hash, der übern den Content gebildet wird und (in der Regel) eindeutig ist. Im .git Ordner sind alle Versionen des Rpositories gespeichert und über den SHA1-Hash identifizierbar.
Objekte in git unterteilen sich in die Folgenden:

blob - ein file
commit - Zeigt auf einen einzelnen tree
tree
tag - Markiert einen Commit als einen besonderen (i.d.R. ein release)

Der Typ eines Objects kann mittels git cat-file -t eingesehen werden. Um den Inhalt des Objects zu sehen, wird git cat-file -p verwendet.

Stashing

Mein einziger Kontakt mit Stashing war bisher ein Fix, um schon geaddte Dateien wieder aus dem Staging-Bereich zu entfernen. Die Lösung hier war es, diese änderungen in einen stash zu schieben und diesen anschließend zu löschen.
Übersetzt man “stash” mit “Lager” bekommt man eine recht genaue Vorstellung von der Funktionsweise des Commands. git stash dient also dafür, aktuelle änderungen an einem anderen Ort zu speichern. Die Dokumentation führt ein gutes Beispiel auf:

Often, when you’ve been working on part of your project, things are in a messy state and you want to switch branches for a bit to work on something else. The problem is, you don’t want to do a commit of half-done work just so you can get back to this point later.

Die Anwendung von git stash ist recht simpel: solange git status nicht committete oder geaddete changes ausgibt ruft man git stash auf und die änderungen werden in einen neuen Stash geschreiben. Git nummeriert die stashes dabei (angefangen bei 0) automatisch durch, wobei der neuste stash immer an der ersten Stelle (0) liegt. Mit git stash list lassen sich die einzelnen stashes anzeigen, mit git stash apply [stash@x] lassen sich stashes wieder in das working directory einfügen. Werden Stashes nicht mehr benötigt können diese mit git stash drop wieder gelöscht werden.

Merging

Normales Merging vie git merge war mir bereits vor dem Termin ein Begriff, neu war für mich aber die option --squash. Mit dieser Option werden die Commits des zu mergenden bracnhes nicht mit in die hsitory geschrfeiben, sondern als ein einzuger Commit auf den Head geschrieben.