The long way through Software Craftsmanship

Brown-bag session: docker

Jun 16, 2015 - 1 minute read - Comments - dockertooltrainingbrown-bag-sessionclient

Today we have done a brown bag session about Docker. One of the team members explained to us the latest news, topics and how tos, including:

  • the difference between a container and an image
  • diffing image contents
  • AUFS (Another Union FS)
  • persistent vs non-persistent (volatile) filesystems
  • running CMD and other commands on the instance
  • problems of running with permission = root (or its group)
  • downsides of it
  • how to compare it with a virtual machine

Types of defects

Jun 14, 2015 - 2 minute read - Comments - ethostyposwritosthinkostypes-of-defectscategorizationslashdotquoteleprechaun

Some time ago, while researching types of defects and the cost of fixing them1, I stumbled upon this:

Years ago I worked with a bunch of economists in the US Federal Government - they categorized ‘bugs’ in their memos into three types:

  • Typos: Simple misspellings of words. Infrequent, easy to detect, easy to fix.

  • Writos: Incoherent sentences. More frequent, hard to detect, harder to fix.

  • Thinkos: Conceptually bonkers. Very frequent, subtle and hard to detect; almost impossible to fix.

Most ‘late’ bugs that I’ve seen in software projects belong in the last category - a lack of design or the failure to make a working mock-up leads to ‘thinkos’ which are only obvious when the application is nearly completed. These are expensive to fix.

Source: http://developers.slashdot.org/story/03/10/21/0141215/software-defects---do-late-bugs-really-cost-more

I would also add a new category to this:

  • Ethos: Morally wrong, although possibly legal. These may take different forms: vary from a company to the next one, from society to society, etc. Even harder to fix than ‘thinkos’, as there is a reason (mainly economic) to keep them in place.

On a technical note, these are not usually well-known artifacts in the company, therefore not everyone should know about them. Only a few developers know the correct reasons behind them and the rest might be sold a fake reason, so the latter cannot fix these ‘ethos’, as they assume they are present for a good reason


  1. This is also a chapter in the book The Leprechauns of Software Engineering by Laurent Bossavit: ‘Chapter 10: The cost of defects: an illustrated history’ [return]

Brown-bag session: Refactoring

Jun 11, 2015 - 1 minute read - Comments - brown-bag-sessionrefactoring

At a client, today we’ve done a brown-bag session on refactoring: we’ve gone through and a live demo, including refactoring a core piece of our code.

We’ve done some mob programming to help identify some smells and how to fix them.

Self-study in June 2015

Jun 3, 2015 - 5 minute read - Comments - self-study-aggregationjune2015monitoringcqrsby-examplearticlemicroservicearchitecturebalanceremote-worknino-martincevicrobert-c-martinjulien-kirchcedrick-lunvenmichael-erasmusgregory-brownabdelmonaim-remanibazaarlearningperilseducationlearningdavid-bonillabonilistarui-figueredoscientific-methodtddbddmetaprogrammingjavaapprenticeshipronny-ancorinipeter-bellrefactoringlegacy-codeantipatternsbig-ball-of-mudpatternsbrian-footejoseph-yoderrüdiger-möllerconcurrencyparallelismjvmjmmjava-memory-modeldeadlockactorcspdisruptorakkaabstraktoralberto-bacchellichristian-birdwikipedia5-whysjessica-kerrqualitybeautiful-codejeremy-ashkenasdavid-deSandrotranspilerphysicsmobile-devicecode-geniusjenn-schifferbresenhamline-algorithmalgorithmjohn-crepezzijavascriptminifiedminifyuglifycompressdebugdev-toolchromerebecca-wirfs-brockcarlos-bleantirezgitcommit-messagecommitgarbage-collectiong1-algorithmcms-algorithmpythonswitch-casedaniel-roy-greenfeldmax-ogdenjoseph-monizclojurecarin-meierchemical-computingabstract-computinghaskelllenslensesgabriel-gonzalezgarann-meansprofessionalismculturejeff-atwoodreadingself-study

Update: I’ve grouped all small posts related to the self-study from June 2015 into a single post

Le monitoring de flux par l’exemple

I’ve read this article about monitoring, in the way of “by example”, by Cédrick Lunven and Julien Kirch (French)

The First Micro-service Architecture

I’ve read this article about microservices and how they were implemented many years ago by Robert C. Martin

How I Learned to Balance My Life With Remote Work

I’ve read this article about balancing life and work, either physical or remote by Michael Erasmus

Demystified CQRS

I’ve read this article about CQRS by Nino Martincevic

The perils of programmer education in the bazaar

I’ve read this article by Gregory Brown

6 useful and lesser-known git commands

I’ve read this article about git commands (log, checkout, stash, cherry-pick, annotate) by Jon Cairns

Is Your Scrum Standup Slowing You Down?

I’ve read this article by M. David Green

Me duele Indra

I’ve read this Bonilista (Spanish) by David Bonilla

TDD, BDD, [add every other method that promises software quality here] and the tea tasting lady

I’ve read this article by Rui Figueiredo about the scientific method, TDD / BDD and how to scientifically detect if the ‘how’ affects the result. In this case, exemplified by how to prepare your tea

The Art of Metaprogramming in Java

I’ve read these slides by Abdelmonaim Remani

When TDD does not work

I’ve read this article by Uncle Bob on situations where TDD might not be appropiate, especially around the borders

Mi primera semana como aprendiz

I’ve read Ronny Ancorini’s experiences in his first week as apprentince with Carlos Blé & Associates (Spanish)

Refactoring without good tests

I’ve read this article by Peter Bell on how to deal with a legacy codebase, what are the effects of not having tests and how to deal with. How to add tests to a codebase that is not ready for it.

Big Ball of Mud

I’ve read this paper, containing a collection of patterns and antipatterns (disguised as notes) by Brian Foote and Joseph Yoder

Comparision of different concurrency models: Actors, CSP, Disruptor and Threads [sic]

I’ve read this comparison of concurrency models by Rüdiger Möller

5 Whys

I’ve read this wikipedia article on the technique called “5 Whys”

Expectations, Outcomes, and Challenges of Modern Code Review

I’ve read this paper, direct link, by Alberto Bacchelli and Christian Bird on code review at Microsoft.

They explain how they do it, the exact methodology they are using and why they do it.

The main reasons to code review are:

  • finding defects
  • code improvement
  • alternative solutions
  • knowledge transfer
  • team awareness and transparency
  • also:
    • improve development process
    • avoid build breaks
    • share code ownership
    • track rationale
    • team assessment

The quality wheel

I’ve read this article by Jessica Kerr about the qualities of beautiful code

5 Minute Physics

I’ve watched this video on interactions with the mobile devices and related to physics by David DeSandro

Rise of the Transpilers

I’ve watched this video on the rise of the transpilers and coffeescript by Jeremy Ashkenas

Drawing Lines with Bresenham’s Line Algorithm

I’ve watched this video about how to apply the Bresenham’s algorithm to draw lines (implemented in pseudo-code and javascript) by Jenn Schiffer

Working with Minified JavaScript

I’ve watched this video by John Crepezzi on how to mix javascript files (clients and yours), how to decompile javascript in chrome, dev & debug tools

How we ran our Legacy Code Retreat

I’ve read this article by Andreas Leidig, looking for inspiration on running a legacy code retreat / brown-bag session. The experience report is here

Shift Left: Testing Earlier in Development

I’ve read this article by Rebecca Wirfs-Brock

Polymorphic Equality

I’ve read this article on implementing polymorphic equality on C#, by Carlos Blé

Commit messages are not titles

I’ve read this article on git commit messages and how to use them, by antirez

Oracle Considers G1 Garbage Collector for Java 9

I’ve read this press article on the G1 and CMS collector, by John K. Waters

What Tech Newbies Need

I’ve read this set of tweets, grouped by Jessica Rose about the most helpful things beginners can do to improve their programming skills.

JavaScript For Cats

I’ve read this introductory guide to javascript by Max Ogden

Why Doesn’t Python Have Switch/Case?

I’ve read this article on the switch case in the python language by Daniel Roy Greenfeld

[Joseph Moniz’s] Notes on Clojure

I’ve read Joseph Moniz’s Notes on Clojure.

Chemical Computing with Clojure

I’ve read an article on performing abstract computations with chemicals, written in Clojure by Carin Meier

Lenses

I’ve read this tutorial on writing lenses for haskell, a way of importing imperative getters / setters to a Data. Written by Gabriel Gonzalez.

On another note, the first part, about writing getters and setters in the naive way, is also explained in Learn you a Haskell > Chapter 8 Making Our Own Types and Typeclasses > Record syntax

Microservices in Haskell

I’ve read these notes on implementing a microservice in haskell, by AlexanderAA

Overcoming Resistance to Change - Isn’t It Obvious?

I’ve watched this video in the channel of The World with Theory of Constraints

Bacon is bad for you

I’ve read these slides on professionalism and the programmer culture, by Garann Means

Code is a job

I’ve read these slides, that are the continuation of “Bacon is bad for you”, by the same author, Garann Means

The Great Newline Schism

I’ve read this article by Jeff Atwood on the difference in newline character(s)

Top ten reasons why I won’t use your open source project

I’ve read this article on what’s necessary for an open-source project to be usable by others. Written by Adam Stacoviak