Dissident Trainings

Delivering a node.js training

Mon, 24 Nov 2014 08:42:13 +0000

On a short notice a big training company had approached me - A trainer of them had dropped out of a planned training and they needed someone to deliver a introduction to the node platform in the context of web development for one of the bigger agencies here in hamburg.

As always: The participants already had a good idea about Javascript and knew basics of the node platform. It was all more about filling the gaps than teaching all “from the ground up”.

The content

We had a Training in 2 Parts aka days

Day 1: Introduces to node.js, npm and packages
- How node works and some look into npm
- Debugging and monitoring Node apps
Day 2: Express JS, TDD, Grunt
- Creating a CommonJS module
- Creating a ExpressJS app

The results

It was pretty nice to see the training unfold. The beginning was a bit rough, since I had to go into areas that I had rarely touched before and these were a bit bumpy at least.

I had created a simple repo for the first day, that reflects the progress of the workshop and introduces basic techniques like “git tag”, semver and such tools. All this is required later on and helps.

Surprisingly the participants wanted to code more (and even more) so that I changed the second day to just Pairprogramming/Coding-Dojo/Mob programming (I do not differ that so much).

We started with 2 repos on github (which saw one or the other commit these days):

The “Workshop” Repo - Containing the Agenda
The Examples Repo - Containing some simple steps to follow

Since most of the training was a practical introduction to something technical there was little documentation of contents (besides some ugly flipcharts - I need to patent the style). So how to solve the problem on getting a piece of documentation to the developers attending tsshe workshop? Easy thing: Just commit on a regular basis: We did Pairprogramming with a 5 minute change timer and on each of these changes of driver and navigator saw a commit to git.

This resulted in the einself App and commonJS module:

We created a webservice that uppercases any word and appends !!!!1einself to it. I did choose the inside out way of building things (I can hear the ATDD community protesting with pitchforks already): Using Mocha Unit Tests for the CommonJS module and then re-using it in our express.js app the we just built and left untested (another pitchfork protest in front of my house).

We created 2 repos there:

The CommonJS Module - A little SJ, mocha tests and
The express.js App

This forced us to really create something productive and since we committed on every driver/navigator change, there is a good documentation about what we did and when in the commit logs of the module and the app

What I learned

There is a lot of lessons learned for me here for me

Even after some years of node.js - I have still areas that I do not know very well. The new cluster module and the libraries behind node are 2 of them.
Training from back of the room can be done with straight forward technical trainings.
Pairing works quite well - Especially when participants with less knowhow learn that they get away from the keyboard all 5 minutes.
Every pair change one commit not only works at work, but creates a good piece of documentation.
Grunt and Gulp.js are topics that need to be revisited. Too big to really explain them in a workshop.
Participants value working it out on the keyboard over getting everything presented on a silver plate

Interested?

If you are interested in getting me to your place and bringing your team up to speed in all things node.js and express.js basics: contact me. Still places for 2014 available.

If you want to do it for your self: I will be adding the licenses to the repositories soonish so that the material is us able in a commercial context.

Reasons to build a pairing station

Wed, 19 Nov 2014 08:42:13 +0000

Having a dedicated computer and desk for the effort of Pair programming is a great thing. It is a little counter intuitive to those who seek for efficient use of the workplace and try to use every inch of the office all the time. Creative people (programmers) are no laying hens and should not be treated this way. So why is it good to have a computer around that is just dedicated for Pair programming?

One Button Build

You will have to set up the development environment easily and multiple times in order to develop. If that takes some hours or a day, you will be having not much productive output. So using a pairing station will force you to get something that is called “One button build”: A build that works as fast as checkout, setup some environment variables and start developing. Using docker, puppet and some other niceties make this is easily possible. A lot of other processes and tools like for example the CI benefit from this “One button build” as well.

One button setup

Same goes for your own development environment aka IDE and other tools that you require. Soon you will end up with a bunch of scripts in version control to (re-)build your IDE and configure it with the push of a button. One side effect: These re-configurations are so fast, you even can use them when you change driver and navigator.

Undisturbed working

Soon everyone will know that a pair working on this particular desktop is not to be disturbed. Social pressure and a special place work together. “It must be important, there are 2 persons” comes together with that special desk where a team of two is to be observed very often.

Clean desk

I personally like my mess on the table: Yesterdays coffee cup, a magazine and other things clutter up my desk and do not ask for “guests” literally. So before I start to pair the cleaning has to commence. This is not the case with the pairing station. It is just used for one purpose and multiple people work there. This makes it easy to keep it a clean place.

A big machine

Most of us use laptops these days. Machines got better and you might not feel any limitation there. But in fact, laptops are pretty limited in terms of the amount of ram that you can install and the amount of displays you can use. The paring station is limited to one place and this way you can decide for a desktop machine. With a budget comparable to a developer notebook you can get a high performance machine that is just capable of a “little” more. Want to have 64 or even 128 gig of ram? Just buy it. SSD drives setup as raid to get you as much write and read speed as the controller allows? Easy. Most of these things will be pretty close to what a modern fully setup macbook pro retina costs.

The whiteboard

A lot of problems can be solved on a whiteboard even better and before starting to bruteforce a problem on the keyboard you might want to have a little session on the whiteboard. A good pairing station has a whiteboard close and accessible with all the tools required to use it.

As soon as you got the basics of Pair programming sorted out, you should build a pairing station to make sure everyone has a perfect place to go to for a pairing session. One one hand it enforces some good behaviours (e.g. One button builds) and on the other it makes it easier to have a dedicated place to sit down and tinker over a coding problem.

Code reviews and Pair programming

Fri, 14 Nov 2014 08:42:13 +0000

Do do we still need Codereviews when we do Pairprogramming?

This is a regular question posed at trainings and when the topic Pair programming in general is coming up in discussions.

I actively advertise Pairing as a way of reducing the amount of time spent in Codereviews. However, there seems a notion to write blogposts that put these two things into a relation with a clear “vs.” apporach. A lot of them are named Codereviews vs. Pair programming. I have collected some of those that I found to be remarkable:

Coding Horror - Jeff Attwood - seems to be in favor of pairing, sees the value in both but prefers Pairing for the social factors. It is easier to critique and tak critique.

Theodore Nguyen seems to see the value of Pair programming greater than Code Reviews. I can understand that. But I would really add that it depends on the type of Codereview and applied technique.

Here is another by Paul Hinze giving a lot of detail on how to use both “correctly” and calls for pragmatic choices. I would dare you to read it when ou do one and want to move from one to the other. Maybe you can stay with Pairing and just improve the way you are doing it

Here is another one, making the point that Codereview is not Pairing (and vice versa). He seems to focus on the change of perspective that you have when you review code.

Cockburn says “Pair programming is contiuous Codereviews in his landmark paper on the topic. If you dont know it yet: Read it.

William Caputo makes the point that you can choose none, both or any. I object this, on the other hand the point he is making with “Pairing is deep, Codereviews are wide” is pretty much on the spot.

So what is my take on this? Pretty Easy!

First: The usage of vs. is just a provocation that might lead an uninformed person into the notion that one replaces the other. This is not the case.

Second: Pairing will change the way you do Codereviews and vice versa. My take is: Start with one of these things. learn how to use it and then start experimenting with the next one. These two things are closely related and one thing ís highly probable: Codereview results will be much more about the “hard things” and less about coding conventions or other smaler things and less important things that seem to fill so much of them. They might get you less results then in the Nuber of findings, but you have ore time to discuss the harder problems. And this is why you do code reviews in the first place.

A good chance to learn about this relation will be my Priprogramming Training in Munich on 03.+04.12.2014 in the Offices Mayflower. Come and see how this works together. Chance is: If you are using one og these techniques, the other can help you improve.

It is not Codereviews VS. Pair programming but CODEREVIEWS AND PAIR PROGRAMMING

Commercial thinking and action

Tue, 11 Nov 2014 08:42:13 +0000

This blogpost begins with a little story. I once (think years not months) worked as a coach for company and we sat in one of the meetings held in regular intervals with the Management to discuss impediments to the process and in general product development. Suddenly in a little more heated part of the discussion, one of the managers said:

In this case, the developers have to apply some commercial thinking.

I am not surprised hearing this demand by management oriented positions. I was sitting in the same boat when I had a team-lead position in another company. Two factors were contributing to the success of this other team heavily (besides the super awesome group of people, a goal and an environment to thrive): A good connection to the CFO with some mutual respect and his constant demand to apply commercial thinking (german: kaufmännisches Denken).

Back to the meeting. I was not prepared to the reactions when I posed a question to everyone attending:

Hmmm. Who in this room had some form of formal commercial education?

You would expect that some top management positions (except the CFO who was not a part of this meeting) in a company would have picked up this kind of education along the lines. Long story short: None of the managers attending had any formal and practical education and experience with accounting, amortization. This was not the first time I made this observation. Very often business and software development are different “departments” and areas of operation.

Theory and practice

These things are often not really included in the timetables of Universities as much as the demands for this kind of knowledge arise later. And then there is the practical application of this knowledge as well: A lot of this knowhow is heavily counter intuitive. You must apply it for a certain time to get a feeling for it. In my first line of work, somewhere back in the 90ies, I had the luck to start off with a not so ordinary line of work as a forwarding merchant. As hard as it was being the apprentice of a prussian merchant in its truest sense, his constant demand for high-quality and business wise reasonable the 3 years brought me to a point where I took something away that I could apply some years later when I started to develop software: commercial thinking and acting.

For a long time I did not realize how much of an advantage this is, especially when it comes to leadership and servant leadership positions. The commercial world and thus software development has some rules that apply a little bit like physics. You can try to break them, but you will not be successful.

Misinterpretations, fads and “here be dragons”

I will start a new series in this blog about basic principles that are standing behind every business and put these into the context software development and the team effort to create products. I will be putting aside trendy things like “Service Design Thinking” or “Lean Startup” as well as the latest trends “Agile Development” as first point of view. I am not implying these are bad in this context but I will try to start off with the angle of commercial thinking to get to a point where we can revisit some of the actual ideas of agile and product development and put them into context. The following topics seem to be interesting.

Economic feasabillity
Effective & efficient
Cost value ratio
Economic feasibility
Investment vs. cost
The CFO and why he is a good ally for software teams
Types of cost
Long vs. short term thinking
Economies of scale

However, this is just a rough list. I would be interested in other input as well. The agile community seems to be pretty active here as well and most methods I came across had a commercial background to it. Interpreted and applied correctly these effects kick in relatively easy and once you know what to look out for it gets pretty simple to grasp what works and what not. I am certain (product-)development teams can draw some practical knowledge from this and find out the CFO is not as a grumpy man as it may seem very often.

Book raffle - #whywepair

Mon, 10 Nov 2014 08:42:13 +0000

I want to know a little bit more about the reasoning behind Pairprogramming usage in development teams.

To get you, dear readers, tweeting a lot about it I decided to give away an edition of “Pair Programming Illuminated” by Laurie Williams and Robert Kessler. It is the defacto standard book in this field of agile development.

#whywepair

In order to win the book you need to tweet a reason for the use of Pairprogramming in your projects and development teams containing the hashtag #whywepair until Monday the 17.11.2014 (the start date of the Hamburg Pairprogramming Workshop).

Its a #winwin: The participants get some motivational tweets on why developers use Pairprogramming and the tweeting folks get a chance to win the book which provides good advice, even for very seasoned pairing setups.

Let the games begin and let the world know #whywepair so that other can draw some motivation from it.

Node.js training incoming

Mon, 03 Nov 2014 00:42:13 +0000

Out of the blue I did something I wanted to do for a very long time - creating a 2 day training for node.js.

On the one hand there is the fact I have fun with trainings and on the other hand people and companies keep asking me to give one. Then there is my constant work with the platform that goes way back when version numbers were low and JS on the server side was hip but not production ready.

I was approached by a company that sells a lot of trainings in order to be the replacement for a trainer who did not have time to attend his date. I want to use this chance to contribute a little bit back and want to create the training, exercises and code as creative commons and MIT licensed material.

What will the training be like?

The training aims at people with basic Javascript skills, preferably web developers and want to dive a bit more into node.js, learn about the pattform and get some useful information on good practices with the platform.

It is straight forward pairprogramming or dojo style for everything the group does and all in a very technical fashion. I will provide around 10 little example “challenges” that will be easily solved by the attendees when attending the training. All with the goal to get over the basics and be able to productively start with server side Javascript.

The contents are going from zero to developing versioned commonjs modules and express.js apps.

How node works & why javascript on the server side
Building and executing a basic node.js code
Networking and async code
Data Access with REDIS
Debugging a node application
Managing multiple instances of node.js
Monitoring node apps
Coding Dojos
Node.js build tools - Gulp and Grunt
Git(hub) development workflow
TDD with node.js
Creating own modules
Web development
Connect

This is all the stuff I would have loved to know when I started out with the platform and covers a fair deal of the node.js “standards”

The result

This should set up everyone with enough skills to start out seriously into node. You could learn all that from tutorials that are out there. But having it all in a intense 2-day training should be very valuable for teams and companies venturing out into the world of node and serverside Javascript.

Interested?

If you are interested in receiving the training or the contents of it: Hit me up with any of the ways to get in touch with me on this website or twitter.

Weekly recap - Week #43

Sun, 02 Nov 2014 09:42:13 +0000

This was a week full of preparations.

The talk for the Berlin PHP Usergroup is finished. It features: bower, gulp, grunt, docker, chef, puppet, analytics, new relic, a lot of js frameworks and more. This is about how to avoid a re-write of your code in a year or two. I guess we all know the web will stay and we should code software for it like it stays. The slides are on Slideshare

My “Playpplication” Video for play4agile 2015 is out there. There was a formal process for everyone who wants to attend to make a video and put it online in order to avoid the normal “who clicks fastest gets a ticket” process. I liked it and it looks there is a reasonable amount of applications out there. Mine is here on youtube.

Still we are spreading the word about the Pairprogramming workshops in Hamburg and Munich. You can book both locations now.

Hamburg (17+18.11.2014)
Munich (03+04.12.2014) there.

I still hate cucumber.js a bit and I actively look for a user who can help me with the very long stack traces. That is not helpful and in the first run Dominik Jungowskis cucumber-assert did not help as well (yet). I might have a special configuration. Next week it will be back to the drawing board.

There is a new site about my workshops so that there is more visbility on trainings.

I added a new workshop about node.js on github. This is a classic 2 day training for small teams in need of an introduction to the node.js plattform.

Weekly recap - Week #43

Sun, 02 Nov 2014 09:42:13 +0000

Oh my #gwad. What a week.

Bad news is bad. I had to cancel the Pairing workshop in Munich due to a lack of registrations. It looks like people and companies want more of these On-Site trainings. I might re-approach the idea of open workshops again, but for now (2014) the idea is done.

Luckily for me, a company in Hamburg wanted to have a Pairing workshop on-site. So what the heck. Bad news (cancelled workshop) is good news (time for a iknhouse workshop).

For a reason I am starting to dive into golang and start to acquire new knowhow. This is a awesome language and for a long time one with a type system. I am deeply amazed about the traits of the language and “hacky” feel it has. It feels a bit more complete comparing to my new beginnings in node.js some years ago.

There was a node.js training since the last #recap and it has been a load of fun.

A load of Javascript libs have found their way to my harddisk:

InteractJS does everything from drag and drop to gestures in plain vanilla JS. I like this approach to the problem and thus the lib gets a mention here.
The Taunus client/serverside framework catched my eye and for a reason I liked working with it. I might reisit this soon.

Survive your front-end

Wed, 29 Oct 2014 21:00:00 +0000

I am building a talk on how to approach big/long running front end projects that will be initially presented at the Berlin PHP User-group on Tuesday. I started to prepare it and want to nail down my thoughts.

Where I am coming from

I have had the chance to get my hands on a lot of Javascript projects and most of the were not small projects per se. It is not only the raw lines of code that let me speak of “big” projects but longevity and complexity that you find in a modern front-end to a web applicationmaking it “big”.

A regular observation is that front-ends do not get the same level of love that a backend gets. Some examples I came across this year alone:

Specifications are very roughly prepared for front-ends
The crafty side of development, modularization and testing is neglected
Standards are not set and/or followed
The fact that a javascript front-end is the client to a server application is often overlooked
Front-end code is often thought as throw away.

Seriously guys. It would be good business to go on and on and on like this for years. It is already going on. You think your back-end code rots from greenfield to brownfield fast? Look at your front-end code. It always rots faster.

“Code this fast. We can rewrite this next year.” and next year we are sitting on the same type of code for the same website, thinking about other things we could do, but re-write a bunch of front-end legacy crap. Yeah, just implement another slider. You like to work in one checkout with 20k lines of code? You want to implement just another self made inline validation for address data? Go for it, but just do not expect me to like this and help you failing.

Sorry, I am too old for this. Been there, done that - 10 Years ago.

Where to start?

When working out all the specific little hints and tipps for the talk I had to group them in order to create a flow for the presentation. All the little things and tricks go into 3 groups.

Tools - We have 2014 and there are a lot of new toys. Lets use them.
Craft - We must use the tools. This means pure development
Process - Development is just a part of a larger process.

It is just the first order I brought into the first set of ideas. It all might be subject to change.

Tools

There is a bunch of new tools to help with front-end development. A little sneak peak of the things I have used in the last weeks and months.

Bower, Component.js or NPM - for modularization and re-use
Gulp and Grunt for Builds
Docker, Chef or Puppet to build a machine where it runs on
Mock and Stub Servers
GIT(hub), do you speak it?
…..(more in the talk)

You can still right click and download Jquery if you want to, but there is no need for it and if you’ve checked it into your version control I do think of this as a anti-pattern. We moved way beyond this.

I do not mind using Jquery plugins as a basis for a project or React components, but please, can have consistency? I do not mind doing coffeescript for you (and learning another language while you pay me doing this) but please, can we have all the code consistent in like one langugae then?

Craft

The pure coding is the thing that I call craft. This has not changed much. But using tools alone will not help you.

I mean we can go on for the next ten years like this in our code ….

function validForm(formName) {
    switch (formName) {

        case "request_showing":
            // Validate the first name
            if (request_showing.first_name.value == "") {
                alert("Please enter your first name.");
                request_showing.first_name.value = "*** FIRST NAME";
                request_showing.first_name.focus();
                problem = true;
            };
            break;

        case "email_friend":
        // ....... 

    }
}

or we can grow up and use patterns and a little thinking to find some slick implementations that follow old concepts like coupling) and cohesion). It is not new and just because you have visited jsconf last week and took away the concepts from es5, rxJS or any other reactive variant these “rules” are not bollocks.

Really, I have seen this pattern over and over. The Jquery guys told us all the stuff we did before was crap in 2004 with all the same arguments used today by the rxJS community. And seriously the language that we actually use has not really changed. It is still javascript and the browsers we target still ask for a pretty old ECMA Standard. IE8 anyone? ;)

It is not that I do not care for the niceties of es5, but some old patterns do not get out of fashion and a DOM tree, the main target of any JS front-end project, is still a evented thing so event driven programming will get you very far.

Process

The “best” thing I have seen in the last year was a code review tool giving a automated +1 for any checkin based on executing the tests of the codebase I was assigned to. So far so good. But the tests executed in this case were the ones for the backend codebase. Front-end tests did not get executed at all (they were broken at the time). This is how you subvert the basically pretty cool code review process (no I wont argue pairing vs. code reviews here - although I am a big proponent of paired code as you all know). A lot of the investments done (tests for the frontend code), but all the money invested thrown out of the window.

With a non-modularized codebase, in the same repository like your backend you are pretty much set up to fail. It starts with the big codebase, goes on with a one size fits all test and release process where you are pretty much forced to check all the functionality all the time. Besides TDD and some integration testing you are pretty much bound to do most of your real testing in a explorative way. It is a very important way of testing but should be used as a an extra to show your blind spots, discover new areas to test and not be the most important source for bugs.

This is what you do when you specify requirements. The checkouts address form does need a inline validation is not a requirement in my world. I am sorry. But starting coding will just get you into a long loop of trial and error that is inherently costly and as I started out: you will repeat this next year. To be constructive here, why not go down the road of specification by example. Yeah I know, that sounds like a big hassle. If you calculate the cost of bugs in specific steps of the development process, you might change your thinking here.

My point!

I think we now can stop repeating the fails of the last ten years (and more) over and over. We have evolved the tools, craft and process over the last 10 years in a way that really helps with this.

Tools - Use the tools at hand. They are not toys and they are a pretty good investment. Use them with care, but use them.
Craft - Front-end is hardcore software development. Accept it and learn it.
Process - Process wise we learned a lot on how we can improve development and find errors and bugs early in development. CI, CD, Feedback and all this is not a joke. This is the new imperative.

I am looking forward to the talk and as always I am looking for feedback in the comments section here.

The BDD project - Second steps

Wed, 22 Oct 2014 21:00:00 +0000

More progress (Version 0.0.1) is made and we are a little further down the road towards a first deploy.

Frameworks & Tools

I sided with the Silex framework that allows for easy development with PHP and Symfony2 components. I spent the last 3 years with Express.js which follows the same doctrine as its Ruby variant Sinatra. If stuff will become a little chaotic and the project gets bigger the switch to Symfony 2 will not hurt to much since a lot of the infrastructure is the same.

The built in PHP webserver will do nicely for development purposes. It is an awesome tool.

For the Scenario and BDD side of things I went with Cucumber.js and webdriver. It seems the thing that works right now.

Another decision I had to make was the one of the build tool, which is in this case gulp.js. I started to like the non-verbosity of the tool.

A first scenario

In order to keep scanarios and stories separated the decisionw as to keep stories in the github bugtracker and the scenarios go as feature files.

However, there is a point where I have to start and stuff needs to be shipped. In order to wire up everything I decided to add a scenario, setup cucumber with webdriver (not only installing it, but writing the code that actually uses the webdriver api).

The Scenario

This should force me to implement a lot of basic stuff right away. and relates to Story #2

Feature: View Practice
  As a workshop participant and website user
  I want to read about specific practices
  so that I know what it is about
  and I can decide if I want to have it in the workshop

  Scenario: View Pairprogrammig
    Given I surf to '/practices/pairprogramming.html'
    Then I should see a level 1 heading 'Pairprogramming'
    And a paragraph of text
    And a unordered list of links to external websites

  Scenario: Link to allies
    Given I surf to '/practices/pairprogramming.html'
    When I should see a list of allies
    Then the list of allies should contain 'Test Driven Development'

I will see how this works out in the next steps. ;)

Next steps

Some things come into mind

Automating the inclusion of the original markdown files about the practices
Deploy it
Implement Story #1 and #2
Find a way to test and validate that it works

Things I wont do (yet)

Heavy TDDing - I am not yet writing an big chun of APIs right now
CI - Given the “advice” I took away from the guys of Unruly I will delay that for a later time and dont focus so much on it.

Dissident Trainings

Delivering a node.js training

The content

The results

What I learned

Interested?

Reasons to build a pairing station

One Button Build

One button setup

Undisturbed working

Clean desk

A big machine

The whiteboard

Code reviews and Pair programming

So what is my take on this? Pretty Easy!

Commercial thinking and action

Theory and practice

Misinterpretations, fads and “here be dragons”

Book raffle - #whywepair

#whywepair

Node.js training incoming

What will the training be like?

Contents

The result

Interested?

Weekly recap - Week #43

Weekly recap - Week #43

Survive your front-end

Where I am coming from

Where to start?

Tools

Craft

Process

My point!

The BDD project - Second steps

Frameworks & Tools

A first scenario

Next steps