Socrates Conference 2016 - My notes

Last weekend I attended the Socrates conference in Soltau/ Germany again. Here are my notes of the two days.

Day 1

Day 2

We Love Code! - Eine popkulturelle Ode an das Programmieren

Ich wohne schon wirklich gern in dieser Stadt Leipzig. Alles da was man so von einer Großstadt erwartet und trotzdem übersichtlich wie früher auf dem Dorf. Und so kam es auch, dass mir "We Love Code! - Das kleine 101 des Programmierens" in die Hände fiel. "Da hat Natalie mit geschrieben - du weißt schon, meine ehemalige Mitbewohnerin" sagte unser Schlafgast.

Macht Spaß zu Lesen (Bildquelle)

Ja, ich konnte mich erinnern. Social Media, HTML, CSS, später Ruby und viel Neugier auf den Rest. Drei Jahre später legen die Code Girls Natalie Sontopski und Julia Hoffmann einen angenehm leichtgewichtigen Einstieg in die Welt der Programmierung vor.

Die beiden Autorinnen nehmen den Leser bei der Hand und erklären mit Verve dass man (wie auch ich) eine Mathe-Niete sein kann und trotzdem ein passabler Programmierer, dass Programmiersprachen ähnlich viele Geschmacksfacetten haben wie die irdischen Variationen von Spagetti mit Tomatensoße und dass C Programmierer harte Kerle sind. Da sich mindestens 50% dieses Blogs mit mehr oder weniger obskuren C Programmiertechniken beschäftigt, fühlte ich mich zugegebener  Maßen bei letztem Punkt gebauchpinselt.

Außerdem leistet das Buch einen wichtigen Beitrag zur Idolbildung in der Geschichte bedeutender Programmier-Veteranen. Ada Lovelace, Grace Hopper (It's easier to ask forgiveness than it is to get permission) und andere bekommen extra Seiten gewidmet. Bravo. Im Pop wird fleißig zitiert und referenziert. Die dritte Generation von Joy Division T-Shirt Trägern bevölkert nun die Indie-Clubs. Höchste Zeit dass auch wir Nerds unsere Helden auf der Brust tragen, Beispiel gefällig?

Bildquelle

Und zu guter Letzt: Es handelt sich um ein schönes, aufwendig gedrucktes Buch. Wer will seinen Liebsten auch schon einen USB-Stick mit einer epub-Datei schenken? Vielleicht noch mit einem animierten GIF als Glückwunschkarte.

Es gibt Dinge die kann man nicht digitalisieren. Ein schönes Buch gehört dazu. (Bildquelle)

Fazit: Falls ihr Partner, Freunde oder Verwandte habt die die Welt in der ihr lebt faszinierend finden aber eigentlich nix davon verstehen: We Love Code! ist ein empfehlenswerter Einstieg, am Besten direkt vom Verlag gekauft.

Professional Online Whiteboarding

My job involves explaining and discussing all sorts of things to people who are almost always situated remotely. Particularly, I like sketching and drawing - that's what we software people do at the end of the day: planing, discussing and implementing boxes and arrows between them.

Shortcomings Of Builtin Tools
For a while I tried to use the builtin whiteboard tools together with the mouse as drawing device. This was inconvenient for a couple of reasons:

• drawn lines where usually quite edgy and appeared not natural
• Microsoft Lync (nowedays Skype for Business) had some lag when I tried the whiteboard there
• I never managed to freehand draw nicely with the mouse

Inspired By A Worldwide Math Trainer
At the end, I never used the builtin drawing facilities because I felt so limited. To overcome this I had a look what other people where doing. I ended up with a similar setup like the Khan Academy:

• Wacom Bamboo Tablet
• SmoothDraw (Freeware for Windows) or as a better alternative
• Autodesk Sketchbook (Free version is enough)

Note: The Wacom Bamboo series of tablet is discontinued and is succeeded by the Intuos series.

Since I wasn't sure if this whole tablet drawing thing works out for me I went for a cheap used Wacom Bamboo One tablet which I bought for 15 € off ebay.

A Cheap Wacom Bamboo Tablet Is All To Get You Started

Using The Drawing Tools
Software wise I kicked off with SmoothDraw which is not a bad choice since it is free and it doesn't require admin rights for its installation.

These days I use the free edition of Autodesk Sketchbook more often. Compared to SmoothDraw the same (limited) drawings of mine look much nicer here. Also the editing tools are way better with Sketchbook. For example, they have a Lasso selection which lets you draw the selected area and than easily move, turn or resize it.

Pressing TAB toogles between the blank canvas and the tool bars. This is nice when presenting: To get the audiences full attention I usually present inside the blank canvas. Only when I need to change a tool or setting plus I can't remember the hotkey I quickly press TAB to get all the menus and then TAB again to return to the blank canvas.

Talking about hotkeys or keyboard shortcuts: To become a fluent presenter it is advisable to know how to change between tools and colors by only using the keyboard. When I present, I draw with my right hand and use the left hand for pressing the hotkeys.

Airbrush For Visual Quick Wins
Beside the pressure sensitive pen tip I really do love the airbrush tool. Once I am done with my boxes and arrows I highlight the important parts with a subtle colored airbrush. These makes to end result much more appealing and it is so simple to do.

Post Production With Gimp
No matter what drawing tool I am using, I never use the full size of the canvas. Actually, I like to get started with a large canvas just to be sure I don't need to limit myself later on.

When I want to share the results of a drawing session I usually export the images to png and then import it into Gimp. There I cut the canvas to the actual size of the image. Also I downscale the image to a size usable for online purposes.

For this I zoom the image to a satisfying size (in percent). I then go to "Image > Scale Image". There I change the size unit from px to percent. I then enter the desired percentage I previously found out by zooming into the image.

When I am done I usually use the "Export to original image" option (can't remember the right name) to overwrite my png with a version of the right size.

Conclusion
I started my drawing experiment over a year ago. When I got the tablet I spend some evenings at home listening to good music and drawing (not only) boxes and arrows. This is also an advice for you: drawing with a tablet needs some time to get used to it. For enough self confidence for your free drawing presentation you better spend some time training which by the way is good fun anyway.

For me these 15 € together with the evenings of good music and drawing training have paid off more than once. In a world of over designed Powerpoint presentations it makes a difference when you build up a topic just with the power of a pen.

Software Craftmenship In Leipzig Is Picking Up Pace

Last September I wrote about my attempt to host a local meetup for the software craftsmen in my home town of Leipzig/ Germany. After a slow start things are recently going well.

This week we had Alex of Grossweber over how gave a very compact but at the same time well structured introduction to git and its advanced topics like interactive rebase. Up to this point my git knowledge was very basic but after this evening my understanding of this topic is much clearer. Good work Alex.

git Session with Alex @ Makerspace Leipzig, 2016/02/17

We started to publish our events on two platform. Beside our native Softwerkskammmer page we started using meetup.com as well.  I suppose being a meetup.com event helped use to constantly increase our attendees. Last week we where almost 30 people and I had to limit the subscription to the event. A couple of month back we where always below 10 people - how quickly things change...

Infrastructure As Code - Some Lessons Learned

I used the last days of 2015 to automate the installation of our C development environment. Here are some of the ingredients:

• Eclipse CDT
• Eclipse ProC - Extensions. Required to let Eclipse CDT understand ancient *.pc files
• Google Workspace mechanics plugin to offer team wide default settings in Eclipse
• some other Eclipse plugins like subclipse, Vrapper (vi keyboad layout or Eclipse)...
• Oracle Client including header files and pre-compiler
• ...

Due to this long list of required tools and plugins setting up our development environment is quite complex. After asking for some clarification on the right tool for the job I went for Vagrant.

10 days later the result was as expected. I am now able to say vagrant up and (if running for the first time) a basebox from an internal repository is downloaded and Vagrant is then running all the shell scripts I've written to install the above. This is called to provisioning step and takes place only once.

Coding the infrastructures I found my self dealing with some of the issues I only knew from ordinary coding so far.

External Dependencies

When installing software which was not provided in a nice repository (Oracle client and Eclipse ProC extension for example) I had to decide if the install scripts download some version of the software from the internet or if I should add a specific version to my Vagrant project and keep it.

I went for the latter. To reduce external dependencies (=download links at the Internet) I have the required archives and binaries locally under version control. If I want to update the software, I manually need to download the newer version and let it replace the older version.

Inside my scripts I always tried to use wildcards when it came down to file names. The goal was that a version update does not require an update of the provisioning shell scripts. A simple overwrite of the old version with the new version should do.

ECLIPSE_PURE_SDK="/vagrant/files/eclipse-SDK-*-linux-*_64.tar.gz"
...
tar xvzf ${ECLIPSE_PURE_SDK}

Feedback Loop

The general approach to codify my infrastructure setup was very similar to the way I usually go forward:

1. write new code or correct existing code
2. let it compile (optional, only required for compiled languages of course)
3. execute
4. find the error
5. start from beginning

Translated into the world of Vagrant this is:

1. write a new installation task or correct an erroneous existing one
2. let Vagrant provision (=execute) the installation tasks
3.  find the error in the installation tasks
4. start from beginning

Particularly the second step, provisioning the Vagrant box was painfully slow. It took about 5-7 minutes to finish this step. Going forward in small incremental steps this means a lot of 5-7 minutes forced breaks.

This time I accepted these waiting times. For the next bigger infrastructure coding job I will definitely try out one of the configuration management tools (Ansible, Puppet, Chef...). All of them give me something really helpful I was lacking this time - idempotence:

... operations [...], that can be applied multiple times without changing the result beyond the initial application. (Wikipedia)

My imaginary updated Vagrant cycle would then look like this:

1. write a new installation task or correct an erroneous existing one
2. execute all installation tasks, only the new or updated once run
3. find the error in the installation tasks
4. start from beginning

This should save me a lot of time since here only the differences of the configuration tasks are executed.

Thoughts On "SE-Radio Episode 242: Dave Thomas on Innovating Legacy Systems"

In episode 242 Software Engineering Radio interviewed Dave Thomas about how to deal with legacy systems. I liked the show so much that I had to do a sketchnote:

Controversial And Very Inspiring At The Same Time - SE Radio 242 with Dave Thomas

Actually I am a faithful follower of Working Effectively With Legacy Code : isolate the piece of code you want to change (dependency breaking), write tests for it and then modify the code using TDD. Over time I got quite good at it - even in C. However, it's a lot of effort - even when you're trained.

Dave sayed "Unit tests are a waste of time, focus on acceptance test" (end-to-end tests). The problem with end-to-end tests is that they are even harder to setup. Instead of mocking the objects around you, you have to provide all the external dependencies or at least good replacements:  test databases, test middleware, test clients...

Anyway, once you've managed all that and wrote your first end-to-end test, things are getting easier a lot. Covering "unhappy paths" with tests is now actually quite simple - drop a central database table, switch of the middleware, send faulty messages to your application and check what's going on.

With all this virtualization (docker as latest hype) and infrastructure as code (Puppet, Chef, ...) we now have got good tools to write end-to-end tests which are repeatable, automated and maintainable.
Surely this was not as simple in 2004 when "Working Effectively With Legacy Code" came out.

Dave's statements  reminded of the Golden Master approach which is quite similar. However, the initial end-to-end tests there is only meant to  provide the basic safety net towards a unit test coverage. The latter one is the actual goal of "Golden Master" testing.

So yes, maybe going from outside to inside is nowadays a better way of creating a safety net. I am still not convinced to ditch unit testing of old code completely but this is as always something you have to try out.

Software Craftsmanship in Leipzig

I started hosting the meeting of the Leipzig branch of the German software craftsmanship community Softwerkskammer. This is also a reason why I am short on blog posts here. Anyway, it's good fun. We try to team with the hardware nerd at Makerspace Leipzig by meeting us at there premises. We think this is a better fit than meeting in some companies (clean) office environment.

Markdown Presentations

I plan to do offer a session on modern C development called Not Your Fathers C at the Developer Open Space conference in Leipzig/ Germany. For that purpose I was looking for a way to prepare slides not in some proprietary format like Powerpoint but in pure text which is rendered to something nice.

 After one evenings search engine investigation for me the way to go forward is remark which lets you create Markdown based presentations which can also be run offline. Very neat.

Socrates 2015 - What the f**k

I'm a IT professional for over a decade now - but I've never attended something like this before:

A colleague and me took part at the Socrates 2015 conference. It's an Open Space conference which mean there is no agenda at the beginning. Just an empty flipchart which if filled with self-proposed topics of the participants at the beginning of each conference day.
No pop star like speakers but people like you and me how admit "I am not the expert but I've done something in that field and I want to share this knowledge with you." For me this is all you need - for everything more involved there are books.

While thinking about the conference I was astonished how much I've either learned or was pushed towards something. Here is my top 5:

1. Sketchnotes. This is for me "Doing something more with the whiteboard than the usual stuff without needing to be an artist." I believe in the area of Powerpoint spoilt organisations  it makes a huge difference to develop a topic just with a flipchart and a pen. It's amazing how much you can do. I love it.
2. Walking Skeleton. I never heard of this topic before. It's basically an approach to build up a system not from inside out but from outside to the inside, guided by so called end-to-end tests as well as unit tests. The book to read on that topic is Growing Object Oriented Software Guided By Tests. People refer to the approach as "London School Of TDD" (the authors of that book are based in London) in contrast to the "Chicago School Of TDD" which is TDD as we know it (Kent Beck, Uncle Bob). Really interesting.
3. Personal Kanban. I was once again pushed to think about my time management method. I attended a session about Knowledge Management but we soon found out the the key is actually Time Management. So one of the attendees offered a session about time management the next day. It all was about the guys Getting Things Done interpretation. Anyway, during the discussion I was reminded on the existence of Personal Kanban, and this is what I am trying out at the moment, all analog!. There will be a post with a nice picture somewhen later.
4. Legacy Code Retreat. I spent quite some time wadding into muddy legacy C code. I thought I am quite good at this topic but this guy who hosted a 2 hour session an how to attack lagacy code was somewhere else. Really impressive. I've done some handson training for a Golden Master Test. Also, training people to deal with legacy code can be simplified by using Adrians work.
5. I had a chat with somebody at dinner how was working for a software consultancy run as a cooperative. Basically, they have no boss and decide all together how they want the company to proceed. This was really thrilling, I was just about to hand in my CV but they are based in the wrong city ;-).

Overall the conference was much more than I expected. In my hometown Leipzig/ Germany there will be the Developer Open Space conference in some weeks, run also as an Open Space event - this time I plan to prepare something my self. Working title "Not Your Father's C".

Yes - there were also some hippies ;-)

Learning Tests - Something you Shouldn't Smile About

I admit - at university I was one of the guys who would rarely attent a non-technical course. Just because I thought that this is the easy stuff - I don't need to waste my time with that.

Well, this aditute has changed.  Over the years I've learned the benefits of reflecting your work style, your personal progress and so on. Attempting to follow the principles of the agile manifesto is one of these findings.

The topic of this post are Learning tests, something a collegue of mine introduced to me and which I problably would have smiled about in university since it is not technical in itself - but it is a nice and easy way to invest your (usually limited) coding time carefully.

So what is it all about?Learning tests is about using your existing unit test framework to have a play with some new library function or class you haven't used before (or a long time ago). You are writing tests not against your own implementation but against the currently not so well understood new library function/ class you are planing to use in your own implementation later.

Learning tests are a kind of a step in between - the unit tests for a new feature you are planning to implement are there but you feel that you should examine the internal mechanics you will utilize for the implementation a little bit further (e.g. some complicated external library).
At this stage you slide in one ore more Learning tests which are writting using your every day unit testing frame work and hence live on with all the other unit tests. In your Learning tests you have a play with the unknown library until you understand how to employ it in your own work. You then move on to your actual implementation.

That's all about it. Nice, simple and definitly helpful.

Second Status - Studying "Structure And Interpretation Of Computer Programs"

Some month ago I decided to self study the online material of the Spring 2014 course of "Structure And Interpretation Of Computer Programs" of the Berkley University.  I was actually planning to regularly post my learning status - however, I forgot to post my half time status. This might be due to a minor football (soccer) event this summer ;-)

Anyway, here is where I am:

I'm slowly creeping forward, working full time doesn't help, too. How can people organize to work on a part time Ph.D. when they have a full time job and a family?!

As the pictures above shows, the next thing is to kick off the last project which is writing a Scheme interpreter in Python. I've done some Scheme recently, I don't hate it - I feel more like in this comic which was on one of the first lecture slides introducing the Scheme topic:

Source: http://inst.cs.berkeley.edu/~cs61a/sp14/slides/24_1pp.pdf

I've never had to deal with something complex like writing an own language interpreter so I'm really looking forward to spend some time with this (last) project.

Looking at my other obligations I suppose it will be October when I'm done with the whole course. We'll see.

Becoming a Wizard - Studying "Structure And Interpretation Of Computer Programs"

A while ago I was listening to some interview on software engineering radio. The person interviewed said that he is shocked about so many programmers nowadays haven't heard about what he believes is one of the most influential programing books ever written: "Structure And Interpretation Of Computer Programs" (SICP) - also called the wizard book:

Well - he would have been shocked by me as well. SICP is apparently one of those books which one should have read in programmers life - or better worked through. SICP is teaching not a particular programing language but how to program. It is more about the bigger picture.

The book seams to be popular in the US since many universities are using it as the basis for their own lectures. Here in Germany SICP is rather unknown.

After I got my own copy of the book I started reading. After a while I felt that I should not read but properly study this book. An Internet search brought me then to UC Berkley and their variant of the course. It is based on SICP but is using Python as teaching language (instead of Scheme in the original version).

For each term, UC Berkley is providing all study material online, including a complete set of screencasts of the lectures. For me, sitting in Germany and working full time, this is a fantastic way of participating at the lectures to a convenient time, learning at my own pace.

My personal project for the next couple of months is to finish this course, doing most of the homework and also trying to do some project work - being a proper nerd.

Since I'm not enrolled I won't earn a certificate or something similar - but my intend is to gain a broader understanding of programing - not an other piece of paper.

This will be fun :-)

Why pressing buttons

This is the personal blog of me, a software developer who his enthusiastically digging all kinds of subjects related to software engineering. The posts are supposed to be my public memory since so many things are popping up every day - nobody can't seriously memorize that. At least not my average brain. Instead of scribbling my thoughts into some moleskin I share them here with you. Not as fancy but hey! - we're digital people, aren't we?

Since I'm native German the posts will be German and sometimes in English, depending on my mood and the topic.

The blog is named after the very recommendable album of a band called "Radio Burroughs". Check their bandcamp page.