At Work

Review: The Docker Book by James Turnbull

by

It is hard to avoid Docker. Hacker News has been abuzz with it for years, The Register ran an exhaustive feature about it a couple of months ago; indeed it seems to have taken over the DevOps world.

But why do I care? I am a developer, I live in the land of abstractions. The JVM is as low as I go my friends.

The problem is, all developers need to do releases.. And releases have a tendency to go very wrong..

Docker_Releases

So, I decided to educate myself. What is it about Docker that has got the cool kids on Hacker News all excited?

I took a look at some Youtube videos, tried out the tutorials and read a handful of blog posts and how-tos on Docker. I just couldn’t get my head around it! Finally I took the plunge and spent the last couple of weeks working through James Turnbull’s The Docker Book.

So, am I enlightened? The short answer is – yes, I have enjoyed working my way through the “Docker Book” and I have a much better idea on how to use Docker and the sort of use cases it is designed for.

The book is written in a tutorial format. We start with the basics about Docker and containers and move on to installing Docker on your favoured Linux(1) distribution.

Once we have Docker up and running, we learn about the basics of Docker. How containers can be created from images and how these images can layered. We learn about the Docker repository can be used to download standard images (for example, the image for ubuntu:14.04 can be used to build a base container that runs Ubuntu 14.04 LTS) and how to build containers from the images that we define. The author walks us through setting up and managing some simple containers.

All the Dockerfiles and any scripts and code used in the examples is readily available from the Github repository that the author has setup for the book(2).

I suspect most readers will get the most value out of chapters 6 and 7 of the book. Here the author goes through some examples including:

  • Using Docker to build a test environment
  • Building a continous integration pipeline using Jenkins and Docker
  • Building a web application that is deployed on multiple containers

These examples are quite detailed and well designed. Most of them could be used as a basis for a Docker based application stack “in the real world”.

Chapter 8 explores the eco-system(3) that is being build up around Docker focusing on service discovery with Consul and orchestration with Fig.

The book concludes with chapters on the Docker API and how Docker can be extended.

“The Docker Book” does not go into details on how containers work beyond the introductory chapters. The focus of the book is about learning what you can do with Docker and it succeeds admirably. I deducted half a star from the review simply because the author does not delve much into things like performance implications of using Docker or on how exactly the operating system may allocate resources to applications running in containers. There are plenty of resources online on these topics4.

You can’t go wrong with “The Docker Book” if you are looking for a hand-on introduction to Docker. James Turnbull is a good tutor and the resources accompanying the book are great.

Will Docker solve my release woes? Is it actually ready to be deployed in a corporate setting? Perhaps a topic for another post..

My Rating: 4.5 out of 5

Notes:

  1. Instructions for use of Docker on Windows and MacOSX are provided but are skeletal. Basically you need to use Boot2Docker
  2. I worked through almost every single example from the Kindle edition and didn’t find a buggy script or typo!
  3. The eco-system is moving fast. Kubernetes from Google is also worth checking out.
  4. The Docker blog is excellent

Review: The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim et. al

by

The Phoenix Project: A Novel About IT, DevOps, and Helping Your Business WinThe Phoenix Project: A Novel About IT, DevOps, and Helping Your Business Win by Gene Kim
My rating: 4 of 5 stars

The “Phoenix Project..” is a parable about technology, business and an introduction to the hot new buzzword of the day – “DevOps”. We follow Bill as he is promoted to be the head of IT Operations in the fictitious auto parts company “Parts Unlimited”. Bill is in for a rude shock as he leaves his comfortable middle management job behind and is thrust into the world of corporate politics, disastrous projects and a company rapidly falling behind it’s competitors and losing market share and money. The root of the problem appears to be a dysfunctional technology group and a complete breakdown in communication between the business and technology groups within the company.

The issues explored here will be familiar to anyone who has worked within technology in any sort of corporate setting. The challenges Bill faces – unclear requirements, unrealistic expectations and ever tightening budget constraints – are present everywhere. The book focuses on technology operations and we go on a journey with Bill as he tries to institute a change management procedure, keep control of production environments and tries to balance key staff who seem to spend most of their times fighting fires instead of delivering on projects.

The methods and technologies Bill and his team adapt should also be familiar to most IT folks. We have change management procedures (ITIL), Kanban boards, and continuous delivery methods. Gene Kim et. al do an excellent job of explaining how these methods work and go beyond the buzzwords in showing how these can be effectively used. The situation Bill inherits at Parts Unlimited may be extreme but its not too far off the mark.

I strongly recommend the Phoenix Project to anyone who works in technology in any domain. As a developer, I don’t have much insight or indeed interest in how IT operations work and the sort of challenges they face. This book forced me to think more about why we have change management procedures and how operating and maintaining an IT infrastructure is as (and probably more) challenging than building the applications that run on that infrastructure.

I have deducted a star simply because the writing can be clunky in parts and I feel the book would have benefited from more editing. The characters are caricatures of the type of personalities you find in most corporate settings. It can be a bit much at times (like the binder carrying manic depressive CISO), but it didn’t detract from an informative and engaging book

View all my reviews

The WhatsApp acquisition

by

The water-cooler was abuzz this morning with news of Facebook’s $19 billion acquisition of WhatsApp, a tiny company. With the claimed 400 million users that WhatsApp brings to Facebook, the numbers involve value each user at $40. That is an astonishing amount of money for a service that is monetised through application sales, not via advertisement. There have been a number of articles and blog posts online analysing this deal. This is not one of them..

My colleagues are a quiet and taciturn lot. Office banter is limited to a “Good Morning” and a “See you later..” outside of the lunch hour. For the first time, in my admittedly short stint here, we had a bonafide conversation that was not even tangentially related to trading systems and market data feeds. We got talking about what it means to be a programmer working outside of the startup / silicon valley scene. One of my colleagues remarked that he spent half a decade in further education and a lot longer learning the ropes until he got to the point now where he is comfortable and financially secure. He wondered if that time would have been better spent writing a new chat or social network. Perhaps a new way of optimising the transmission and sharing of ribald jokes, or for improving the sexting workflow.

We carried on in a similar vein for a while when the most introverted of our lot spoke up. He said: “I was just never interested. The thought of building the next Facebook or Twitter just doesn’t excite me. It was never something that was on my radar.”

I spend way too much time on Hacker News. The Silicon Valley culture and eco-system fascinates me, but it does not inspire me. I marvel at the numbers that are thrown around. A few billion here, a few billion there, but I also wonder about the utility of it all. It is now fashionable to talk about how much of a talent drain banking has become. How so many people left promising careers in academia and engineering to cut code and make money on Wall Street and the City. In a few years I can see people talking in similar terms about Silicon Valley. “He was a promising scientist, but he joined Google to help them optimise the placement of adverts on search results.”

I find the earnest tone of discussions on Hacker News and of the job postings for these start ups deeply ironic. They talk about changing the world, wanting rockstars and working on cool new technologies. Yet, the end goal is a big payout via IPO or acquisition having built a better way of sharing food selfies. I think these headline acquisitions are a honey trap for programmers. Somebody, like my colleague, who wouldn’t really even think about working for a startup building a “trivial” app might realise that the App may be a gateway to that long dreamt of retirement on the beach.. You might get a lot more people ready to work for peanuts with the hope of striking it rich one day. Perhaps it is not a colossal waste of money after all..

Working Effectively In Multi-Cultural Teams: Email and Teleconferences

by

I was born in India but moved to The Netherlands to finish high school. I went to University in England and have worked in London and Tokyo since then. I have spent probably more time than most in a state of cultural confusion. Since starting my career, I have worked with teams in India, The USA, England and now in Tokyo.

I have noticed over and over again that communication can fall apart at the boundaries of different cultures. A team that is very productive locally may not scale across different regions and cultures.

In 2010, I was transferred to Tokyo from the London. When I first moved to Tokyo, I assumed my role would be strictly technical. I did not expect my work to be much different to what I did in London. I was wrong. Over the last couple of years, my role has turned into that of a translator, a mediator and a cultural interpreter (for want of a better word).

I want to share some of the things I have learnt in my time here. This entry focuses on Email and Teleconferences.

Email

Our world runs on email. From scheduling meetings, to status updates or to “sharing information”. Email is easy to use and easier to abuse. Poorly written emails can result in anxiety, confusion and misunderstanding.

When writing an email most people err on the side of verbosity. My Japanese colleagues often are perplexed when faced with an email that is a large block of unformatted text. I believe there is the strong correlation between the length of an email and the likelihood that people will read and respond to it.

There are ways to make email more effective:

  • Structure the email for clarity. Use paragraphs, bullet points and clear section headers to make the email look less dense
  • Focus on the intended recipients and those who need to take action based on the contents of your email
  • Do not use a single email to cover multiple topics. Send an email per topic and only send the email to the relevant people
  • Address recipients (people or teams) directly in the email. It is much more effective to say: “Hi Alice, Bob, Charlie” or “Hi Source Control Team” instead of starting the email with a “Hi all”

Finally, if you find yourself writing a long email it may be easier just to put the contents of your email in an appropriately formatted document and send the document. If action is required, arrange a meeting or a teleconference to go through the document with your colleagues.

It is much easier to ignore a long email than to ignore a meeting. Sending the document as part of the agenda of the meeting will ensure that your colleagues will have the document in front of them while you talk them through it.

Teleconferences

I do not know of a single person who enjoys teleconferences. They can be boring and can be a most effective time and productivity disposal system. Things become more complicated when not everyone can speak English (or the dominant / common language of your workplace).

I try and avoid teleconferences as much as possible, but there are ways to make them work:

  • Have a clear agenda, focused and realistic agenda. Having an unfocused agenda is the death knell for productivity! Enforcing a strict time limit to the meeting will also help focus minds on the agenda.
  • Send any materials, documents, diagrams ahead of the meeting. If possible, attach them to the meeting invite. It gives time to invitees to read and prepare any questions ahead of the meeting.
  • Do not read through documents or presentation in the meeting. Use the meeting to discuss the material, not to read it out loud.
  • Prepare actionable items for those people who you have invited to the meeting. If you cannot think of one, the person should be strictly an “optional attendee”.
  • Avoid slang, cultural references, and inside jokes. It can be very disconcerting for a team member not to know what everybody else is laughing about. Stick to the agenda, and use basic and direct language.

I have found that having a video meeting can be more effective than having a teleconference. It makes it difficult for the attendees to tune out the teleconference and check their email. As the facilitator, you get immediate feedback if your message is getting through.

Finally, treat meetings or teleconferences as matters of last resort. They are expensive and are an inconvenience especially if your team works in different timezones.

Code of conduct for Professional Programmers

by

Robert Martin’s book Clean Code (Amazon Link here ) is one of the most important books I have read on the craft of software development. It is a language / platform agnostic book on how to write good, maintainable, and readable (i.e. the “Clean”) code.  But, when deadlines start slipping and things start falling apart, it is all too easy to cut a few corners and accrue some technical debt which will come due later.  It looks like Robert Martin has written a follow-up to Clean Code. The title is The Clean Coder: A Code of Conduct for Professional Programmers (Amazon Link here ).  It is on my “to-read” list, but Christoffer has written an excellent summary here.  He lists 9 points that he took away from the book. For me the most important point was this:

A Professional Programmer Takes Responsibility

It is very easy to blame the BA (Business Analyst) for not writing a clear specification or a clear test plan. It is easy to blame the user for not doing a thorough UAT, and it is easy to blame the QA team for not doing integration testing properly. If there is a bug in the code, it is the programmer’s responsibility. Once a system reaches a certain complexity, there will always be bugs or edge cases that somehow slipped through into production. Once a bug has been identified, it is the programmers responsibility to explain it, to fix it and to ensure that similar mistakes don’t happen again.

I have been (and routinely am) in positions where a bug in code I have written has lead to a significant outage or a measurable, significant, monetary loss. The first instinct is to always look for problems somewhere else. Maybe something went wrong in the operating system, maybe the deployment team did not release the packages correctly.. It may be the case, but as a Professional my first responsibility is to check my own code. What did I change? What could have gone wrong? How can I reproduce this error in the test environment? How do I fix it? And finally.. how do I make sure this does not happen again?

In my experience, a policy of complete transparency is the best policy for a Professional Programmer. If the management team knows they can trust you, they will generally be more understanding when things fall apart in production!

Meetings

by

I wonder if there is a simple and straightforward formula which determines the value proposition of having a meeting at work.  Corporations love looking at the bottom line.  Cost saving measures abound in these economically straightened times.  Travel budgets are slashed, weary executives travel coach class and nights out on the company expense accounts usually stretch no further than a burger at TGI Fridays, if you are lucky.

It is depressing when you attend a meeting knowing fully that it is pointless.  It is doubly depressing when you know your fellow attendees probably feel the same way,  but nobody else wants to cancel the meeting.  I guess it depends on the corporate culture.  Here in Tokyo, decision making is basically building consensus, and meetings are all about sharing information.  What ends up happening is you have ten people sitting in a room and one person talking.  Out of the ten, maybe three would have some idea on what is going on.  Two will be asleep, and the rest would be nodding but with a glazed over look in their eyes.

So, is there a solution?  Maybe have Outlook or Notes or your meeting organizer somehow hookup to the HR database and come up with how much the meeting is costing the company?  If you have ten people, each costing say $50 an hour to employ, an hour long meeting is going to cost $500.  Is it worth the expense?  Would it be better to get everybody out of the office and to a bar or a restaurant for a meal (probably costing around $500 – TGIFridays!).  Maybe people can have a bit of fun, and relax and get something done as opposed to just sitting around slowly sinking into a dazed sort of stupor.