Weekly recap Week #38

This week was more about building my own things aka website.

Jekyll is still one hell (good) of a blogging and web site system. If you are hosting your own WordPress blog and you are technical capable: Look into Jekyll. It’s a complete static website generator using markdown as a file format. I love it and I am still a bit on the learning curve.

There is a yeoman generator for Jekyll and Bootstrap that makes some things easy. You might be better off with starting a plain Jekyll project and wiring everything up yourself. However it is a good if you want to see how things can be wried up and have a basic idea how bootstrap works.

I found out what copywriting is. It’s essentially writing for marketing reasons. Aha. Thank you wikipedia. One of these words that I listened to multiple times but never really questioned what they imply.

I decided on the kinds of trainings I want to provide as a “standard” to my customers. These will be: “Extreme Programming”, “Pair Programming” and “Userstories with Gherkin and BDD”. Watch out there: News will be out soon. if you want early information: Shot me a mail.

I a talk about clojure script (Clojure Script: Lisps revenge) kept me up at night and  I blame David Soria Para now for me having thoughts of trying it. It looks like the hell of a beast of a programing languages but looks like it fixed a lot of the functional fuckups that are in JS. And ITCOMPILESTOJAVASCRIPT!!!EINSELF!!!

10 tips for the XP Practice “Sit Together”

James Shore describes “Sit together” in his book as

“Sitting together fuels team communication. This has impressive results, cutting time-to-market by two thirds in one field study*. It enables simultaneous phases, eliminates waste, and allows team members to contribute insights to others’ conversations.

To sit together, create an open workspace. This takes longer than you expect. Organize your workspace around pairing stations, locating people according to conversations they should overhear. Provide plenty of whiteboard space. Make sure there’s room for personal effects and a place for private conversations.

Open workspaces are hard for some to accept. Get team members’ permission before switching, or they may rebel.”

1. Sit all the disciplines together.
I often see designers skipping this one and staying with their designer teams. Not so good. Everyone should be on the product they are working on.

2. Agree to common rules explicitly
Different people have different needs and desires. Talk about them and write them down. After a few weeks: rinse and repeat. make this explicit

3. Must not be in a room, but can be close
A glass wall often does as well. If I can see my Product owner (a role that requests own rooms very often in my experience), I can approach him.

4. Adapt your visual management
If you are doing hardcore Scrum you might dive into Kanban now. There are different disciplines and roles in the room, working on on one thing. So the normal Scrum Board most likely will not cut it. A good place to start is Kanaban.

5. Rituals! Rituals! Rituals!
I have heard of a “Disco Friday” where teams would play nice music all day long aloud on friday or seen hourly Nerf gun matches. These rituals help to firm groups and keep them in high cohesion.

6. Style it
Invest some work in styling the place. Some lights, LED ambient illumination, posters on the wall etc. will really help teams to form and stick. Make sure to provide a budget.

7. Clean it
Once a week/sprint: Clean the workplace and bring everything in order. Its a very short procedure for most places and it helps providing general order and cleanliness.

8. Have the Meetings together
Do not let the “Backend Guy” bail the Grooming when you are working on Frontend Stories. Do not let the designer bail as well. Everyone has to learn what the other disciplines do. When someone sits there and does not get it: Help him understand. Re-Arrange Groomings so that there are Stories of any Kind. You know the vertical slicing thingie? You should do it. And no .. neither the designer nor the tester will bail the Retrospective. It takes disciplined and willing teams to practice it this way. But in my experience: The seasoned crafts(wo)men will happily participate.

9. Have a extra room for “Discussions”
When different trades of craft work together, there is a lot of need to discuss things and talk about it. You will need a room for this since every discussion will be a interruption for everyone else in the room. Buy a set of high quality noise dampening head phones. I am working at a client here in Hamburg where you have small chambers for working 1on1 as well as meeting rooms that are general available for phone conferences etc.

10. Have more than enough Space
Even People with Computers need Space to work and think. Provide this. Don’t make cross-functional teams and cram them in a small room and be surprised you get a lot of complaints from the inhabitants of that room . If you cant afford space, maybe do not hire developers at all. There are regulations for how many office workers can be in a certain set of size here in Germany and I have seen several occasions where these laws where used as a common denominator of how many people fit in a room. This is not the way it works.

So this is what I came up with. What are your Ideas?

Weekly recap – Week #37

This week was code, code and code.

If you look for a way to generate a appcache.manifest and make your page more available for offline usage, grunt-appcache is your friend.

Manifesto is a anice bookmarklet to let you check HTML appcache manifests.

Using input fields with an TabletPC might pose ne challenges to event handling as I found out. Dismissing the virtual keyboard might break your layout.

Instead of using backbone and wondering about the amount of boilerplate to write, I might have a look into the new apper framework for single page apps. Nice one.

Math.js just got a 1.0 and I find the new filter feature very interesting. You might wanna check your js codebase for calculations that could be done with mathjs in a simpler way. Still I heavily recommend it.

8 tips for the use of coding conventions

Coding conventions sound so easy, but get hard over the course of a longer project and with bigger team size. With a little feedback and forth with Johann Peter Hartmann, the following principles for a coding standard were up for discussion.

• understandability – The conventions should help the programmer to understand the code and should be easy to understand themselves
• learnability – It should be easy to adopt and learn a coding convention and the convention should help the developer to easily find a way into a codebase
• attractiveness – It should be attractive to adhere to a certain standard
• analyzability – The standard set itself should be machine analyzable. It’s either THIS or THAT, not MAYBE, SOMETIMES or OFTEN. 😉
• changeability – The standard should be easy to change and changes to the code, by a new standard, should be easy to do as well.

My list of tipps should help you find a standard and keep it up.

1. They apply for everyone in the team.

No developer, in no situation should be exempt of the conventions. It might sound dogmatic, but this is a rule that applies for everyone. Even for $pointyhairyboss, if he is still pushing to the codebase.

2. There is no perfect convention for every given project.

I see this discussion revolve again and again: Developers looking for “the standard”. Where do I set my braces, which kind of whitespace do I use? Please tell me. I am to smart to look for THE standard, give me any standard and I will adhere to it.

3. Automate checking

No one wants to check, what could be millions line of code, by hand ot just looking at the code. Tools can help you with that. What ever you decide, try to create an automated check for violations and make this one available to all the developers working on the software.

4. Have examples and explanations

Coding conventions may seem to be a very subjective thing. But when explained properly, in a markdown, text file or wiki page it gets easier to accept to code by standards that are not your own (yet).

5.  Your codebase must have 0 violations at all time 

With command line tools and checking before you push stuff to a repository, this should be easy. There might me exceptions, but make sure you group them into modules exempt from the checking process or make other wise sure the initial thought of a same structured codebase does not get undermined.  See 6.

6. Change if required

If the rules don’t fit, change them to better ones. Migrate the module to the new rules. Do not only change the rules. Change the code as well.

7. Everyone is responsible not only for his own conventions 

Where ever you are in a pice of code, you are encouraged to fix any violations or add a example here and there. Didn’t you find enough comments? Cool, add some.  Something is formatted wonky? Fix it! Somebody used spaces? Change it to tabs if the spec says so.  Where ever you are in the code, a OneButtonTest will be a good practice to look at.

8. Make conventions per module, not per team. 

Different modules might be written in different times and adhere to different standards. So splitting up parts of your software that follows a very different style might be reasonable. In Javascript and a browser environment you would use tools like component and bower to get things back together.  Small modules help you maintain different styles. Think about it: If you have a long running project, it’s very likely you will have more than one standard. And small modules allow for different ones in different occasions and situations. One argumentative nail in the coffin of Big ball of mud designs G*

This was my list of hints. What are yours?

Weekly recap – Week #36

This week was full of interesting stuff

• COACHING: I had to do some research on feedback types and styles. I stumbled on this document, giving a little more background on the special properties of feedback.
• TRAINING: Another research task was on the basics of lean. I am hammering together a workshop on the Lean Basics and Kanban, so I needed all in one Place on this Cheatsheet. I need to recreate this with CC.
• FUNDING: I did choose a website Theme and took a deeper look into the Onepager from http://www.rebelatheartpr.com/ which will serve as a good example for structure and approach. 😉 My theme of choice.
• CODING: If you do anything tech related to web and did not read the HTTP Status Codes RFC, I urge you to do so. It is !IMPORTANT
• NEWS: Mytaxi was sold to Daimler. I am applauding the team + Nic Mewes and Sven Külper. A german startup dream come true I guess. That is something that other big german funders never did: Building something original, as one of the first movers, not cloning anything. You better worship that ;))))
• CODING: A HTML/JS based editor. Smalleditor got my attention. I like how it is made. Definetly something to look into. https://github.com/jdkanani/smalleditor

Lots of different things. Interesting times.

 

Weekly recap – Week #35

Following the practice of Martin Wolf, I am now posting a recap of things I do over the course of a week. So you can see not only what is on my mind, but what I am actually doing

Backbone.js 

• backbone inheritance. Looks easy, but there are quite many ways to do it.
  “Backbone.js & inherticance” gives you a intro
• And if you are looking how to inherit those defaults you might wanna see this
  Stackoverflow thread
• Want to validate backbone models? I seem to come back to
  “backbone.validation” again and again
• You might wanna check the common pitfalls early on
  “avoiding common pitfalls“

Development

• I am a big fan of Grunt.js but I must admit: Gulp is awesome. I got really tired of big configuration files that seemed to be a mistery after a while. You might wanna read the
  “quick intro to gulp.js” and give it a chance. You will not regret it. Lean and Mean I say.

Blogposts

• Olaf Lewitz has a piece on happiness, money and a interview with the CEO of Krankikom GmbH
  “The most important things in life“. This was my blogpost of the week.

 

Ideas for modern coding

If starting a new web project follow some basic principles

• Start with deploy code – It must be deployable from moment 0
• Use Unit- and Functionaltests
• The deployed code is testable and thereby you can verify it
• Use Virtual machines to recreate the live environment
• All is in GIT – dev and ops code
• Use cont. integration and cont. deployment from moment 0
• Static analyze the code – it’s cheap
• Build in monitoring and logging
• Whatever you do, write some docs, build them automatically

I think I will try this. Using this one would end up with a recreatable environment, that 5 years later, everyone who wants to use the software, can recreate. It’s not ma a magic bullet, but I think it could speed up a lot of things heavily.

A day setup can save you a lot of worries. The less you depend on things made “by hand” and if you put something aside for a while, you will be able to return easily.

 

About a Bridge Thread

Reading the C2 wiki, in the context of extreme programming, a bridge thread is

The first iteration of an XP project should aim to be a BridgeThread : an end-to-end application, which does not have to contain much significant functionality, but from which the rest of the system can be hung. The BridgeThread determines the system architecture. In this XP works much like a weaving spider

Bridge Thread

The bridge thread tries to answer a question that is posed very often and I do hesitate to give an more specific answer than: “Just pick ANY, it will be a long effort to build this product and in X months, what does it matter with what we started”.

The idea of the bridge thread tries to answer the same question. Some ideas (far from complete) regarding the Bridge Thread

• Make sure it is as independent as you can from other stories. It is the beginning, so one of the primary concerns, even more than in later sprints is: Deliver something.
• Make it a core functionality for your product. If you write a app that helps you getting a cab in a city: Do not make it the login. Try to be as close to the part that delivers the value to the customer as possible. Most likely login is not your main business case. (I have advised otherwise in the past … I changed my mind)
• Don’t take any shortcuts. Use a small story, but implement it completely
• Don’t sweat it . It is sprint 1. Getting shit done is more important than getting a lot of shit one. Not producing any bullshit is even more important
• You will have to set up a lot of stuff: CI, automated tests etc. Did I vote for a small Story already?
• All layers included. use a story that needs all layers of your architecture.
• Your estimates are most likely not really good in the beginning. You could pull a story, implement it and pull the next one. Story by story. This is how a Kanban team could approach such a problem.
• Don’t commit to a sprint goal .. just try. There is no real way to commit to something you don’t know.
• Have everything extra-ready. All assets. Maybe a DB design. Architecture? You should have a good Idea of this. As much as I love emergent Architecture and Design, just don’t try always when the last responsible moment for that is. One or two extra hours invested wont hurt. Beforehand the sprint. Not 20 minutes before you start the story.
• Try to hammer a estimate in SP on the Bridge Thread anyways. And Re-Estimate in later sprints. This way you can make sure, that the learning, that took place in the first sprint lands in later sprints.

Do you have more hints what to choose for starters in bigger “Projects” or at the beginning of a new Product or Codebase? Please share them below.

Blog Posts will be moved.

I will be moving some of the posts from here to a new site that will host dissident trainings and all workshop related stuff.

If someone has ideas on the final jekyll site or a way to move posts from wordpress.com to a new blog (my seo friends): please send me ideas and hints.

The posts that will be moved get a tag: ‘dissent‘

Dissdent Trainings – Preamble

This was written a while ago. It proved valid as a guiding document in how to organize self-employed work by providing a manifesto instead of “hard rules”. So if you want to know, why I changed my Bio status to “Funder/Trainer” instead of “Looking for a Job” (No that I don’t, but I am not the kind of guy to sit tight and wait – So why not create a well crafted business here):

This might be the first post of a few that try to explain this move, it’s implications and the funny stories alongside.

Btw: The thing has a name: Dissident Trainings and a github account