Background

I've been scratching my head and reading more about Scrum lately. It's rather clear to me by know that Scrum needs some discipline, some interest and constant adjustment, to have an actual chance to work well for the team. What I'd like to share today is symptoms of Scrum at struggle, indicators that the agile process might not be treated as agile itself by the team. As any member of the teams involved, I am to blame for not turning the wheel around more myself, too.

I think it's important to talk about issues with Scrum, to identify causes, and to make adjustments to the process to not just "die faster" with Scrum.

So here's a few facets of a team struggling with Scrum:

Struggles

Daily Stand-Up Meetings

• Members struggle remembering what they did in general, yet few start taking and bringing notes
• Stand-Ups seems to keep catching everyone by surprise, while taking place the same time every day

Planning Meetings

• Stakeholder and/or product owner are at their phones rather than really listening
• Stakeholder wants to bypass backlog and priorities and discuss "just one small thing to be done this sprint"
• Tickets are too big to estimate well yet feel wrong or very tedious to split up further
• During Planning Poker: Estimates vary depending who would work on the ticket
• Estimating something as 2, 3, 5 or 8 does not get trivial and does not correlate to time put in well (because of things not taken into account that turn out later)

Retrospective Meetings

• No one feels like reporting anything for any of "went well", "went bad", "should be improve"; consensus is "business as usual, nothing special"
• Notes are just filed and not acted upon outside the team
• Constant struggle with telling "went bad" apart from "should be improve"

Review Meetings

• Stakeholders are not really interested to hear about see things done
• Preparing to demo during review takes a considerable amount of time (that does not seem to match value)

In General

• Tickets are often not ready-to-be-implemented
• Big topics (like architectural changes, updates of unsupported dependencies, decrease of technical depth) are procrastinated for month, rather than being addressed
• Team velocity does not stabilize for months (due to: sick leave, vacation, frequent change of members)
• Velocity is measured without taking (varying) total team hours into account
• Product owner does not help with decisions, rather mirrors questions back to developers
• Incidents produce new tickets that take priority and go into a sprint, directly
• Some team members want to improve the process (and take it seriously) while others consider that a waste of time (and take as "just a tool")
• Some team members care a lot about avoiding over-commitment while others are tending towards "we'll get done, what we'll get done"

Sounds familiar? Sounds very unfamiliar? Let me know

A Few Words of Introduction

I had a look at available static site generators not too long ago and took some notes on the go so that I wouldn't evaluate once more if I needed yet another solution later. WordPress was still powering my blog and with dynamic PHP code that felt more and more like a bug that I wanted to get rid of.

Inspecting projects took me a bit of time so maybe I can save you some by sharing my findings. For some projects, I stopped further investigation rather quickly, so please don't expect a complete evaluation of every single of these projects.

My Requirements

I was looking for a static site generator with the following requirements:

• Written in Python (so that contributing bugfixes is an actual option)
• Supports Markdown or AsciiDoc syntax for posts (not YAML, HTML, rst, JSON)
• Has one or more polished, responsive theme
• Is still maintained, e.g. has a recent latest release
• Is suited for both a blog and non-blog documentation-like content (so that I don't need another tool again for a slightly different case next time)
• Bonus: Has wordpress import
• Bonus: Has incremental builds
• Bonus: Is already packaged in major GNU/Linux distro X

Here's what I found, with projects in alphabetical order:

Candidates

Acrylamid

• Officially unmaintained
• Latest release four years ago (2014-09-11)
• 39 open issues
• Stopped at that point, next.

Cactus

• Latest release over two years ago (2016-02-21)
• 85 open issues
• Stopped at that point, next.

Complexity

• Latest release six years ago (2013-12-03)
• 19 open issues
• Uses HTML and JSON for input, next.

Grow

• Latest release just a few days ago
• Seems unnecessary complex, documentation does not get to the matter fast enough
• Stopped at that point, next.

Hyde

• Latest release three years ago (2015-11-09)
• 49 open issues
• Does not manage to get their own website fixed from loads of dead links, also check issue #12 with zero progress on that very topic
• Stopped at that point, next.

Lektor

• Latest release about two month ago (2018-09-07)
• Markdown syntax
• Seems more like build-everything-yourself rather than text-and-go
• Available themes do not look polished enough to me
• Next.

MkDocs

• Latest release about two month ago (2018-09-07)
• Markdown syntax for posts
• Some simple but clean themes
• Targetting documentation a lot more than blogging, I feel — next.

Nikola

• Latest release a bit more than a month ago (2018-09-30)
• Markdown syntax for posts, and many other options
• Rather basic themes
• Incremental builds
• Support for import from WordPress
• Ended up giving that a try at this very blog, the website of uriparser, and the website of Gentoo e.V..

Pelican

• Latest release more than a year ago (2017-10-01)
• 72 open issues
• Supports Markdown and AsciiDoc syntax (besides reStructuredText)
• Support for import from WordPress
• Quite a few themes of mixed quality, not easy to find a responsive one (like chameleon)
• Ended up giving that a try at the website of libexpat.

prosopopee

• Latest release a few months a go (2018-03-28)
• 12 open issues
• Seems focused on image-centered websites
• Stopped at that point, next.

QPage

• Latest release soon two years ago (2017-01-31)
• 0 open issues, only 1 issue filed ever
• Weird samples, weird website
• No real documentation
• Stopped at that point, next.

Sphinx

• Latest release only hours ago
• Markdown syntax possible
• Great fit for documentation, less suited for blogging on its own; might work combined with:
  • ABlog
  • Tinkerer
• I want a single thing though — next.

Statik

• Latest release a few days ago
• Seems to have a single theme, only
• Rendering the blog example ends up unthemed and with absolute, broken file:// links — next!

Tarbell

• Latest release about a year ago (2017-10-31)
• Weird tutorial using Google spreadsheets, next.

Urubu

• Latest release a few months ago (2018-08-15)
• 21 open issues
• Markdown syntax for posts
• Still used by websites listed using Urubu
• Only a single theme (if we ignore support for Bootswatch)
• Has potential, feels too small as of yet — next.

wok

• Latest release more than four years ago (2014-04-30)
• 34 open issues
• Stopped at that point, next.

If you have comments on these evaluations, please drop me a mail.

Thanks, Sebastian

Earlier today uriparser 0.9.0 has been released. Some highlights of version 0.9.0 include:

• Security fixes for issues uncovered by the Google Autofuzz team

• Support for custom memory managers for when libc calloc, free, malloc, realloc, reallocarray are not a good fit to your scenario

• New uriParseSingleUri* convenience functions to simplify user code

• Full support for strict C89 restored and enforced by CI

I cannot over-emphasize how helpful AddressSanitizer has been in making this new release. If you get stuck while writing a custom memory manager, please check out helpers uriTestMemoryManager and uriCompleteMemoryManager.

For more details please check the change log.

Last but not least: If you maintain uriparser packaging or a bundled version of uriparser somewhere, please update to 0.9.0. Thank you!

A few days ago uriparser 0.8.6 has been released. Version 0.8.6 is a bugfix release including a nasty bug that has potential to crash applications when parsing certain URIs (e.g. //:%aa@). For more details please check the change log.

If you maintain uriparser packaging or a bundled version of uriparser somewhere, please update to 0.8.6. Thank you!

Expat 2.2.6 has just been released. Besides improvements to the build system, 2.2.6 is a bugfix release. For more details, please check out the changelog.

If you maintain Expat packaging or a bundled version of Expat somewhere, please update to 2.2.6. Thank you!

Sebastian Pipping

Repology is monitoring package repositories across Linux distributions. By now, Atom feeds of per-maintainer outdated packages that I was waiting for have been implemented.

So I subscribed to my own Gentoo feed using net-mail/rss2email and now Repology notifies me via e-mail of new upstream releases that other Linux distros have packaged that I still need to bump in Gentoo. In my case, it brought an update of dev-vcs/svn2git to my attention that I would have missed (or heard about later), otherwise.

Based on this comment, Repology may soon do release detection upstream similar to what euscan does, as well.

I've been wanting to get away from Wordpress for a while now. To get rid of dynamic code execution, of MySQL, of PHP, and Wordpress in particular. I finally completed that move.

The conversion to Static Site Generator Nikola took me a while, maybe I'll make time for another post with a few more details. There may still be a few rough edges, e.g. with the URL rewrite mapping. Please let me know if you notice anything broken.

I would like to apologize if any Blog Planet gets spammed by the change in feed entry IDs.

For the record, this is what the blog looked like for the past years:

Good bye, Wordpress.

EDIT 2018-05-29: Missing favicon restored

We had a case at work were multi-line output of a command should be turned into an array of lines. Here's one way to do it. Two Bash features take part with this approach:

• $'....' syntax (a dollar right in front of a single-tick literal) activates interpolation of C-like escape sequences (see below)
• Bash variable IFS — the internal field separator affecting the way Bash applies word splitting — is temporarily changed from default spaces-tabs-and-newlines to just newlines so that we get one array entry per line

Let me demo that:

# f() { echo $'one\ntwo  spaces' ; }

# f
one
two  spaces

# IFS=$'\n' lines=( $(f) )

# echo ${#lines[@]}
2

# echo "${lines[0]}"
one

# echo "${lines[1]}"
two  spaces

I wanted to write this post for a while now. It's about how different IT companies are, in Berlin. I find that interesting. The examples include what I have witnessed myself, at jobs but also interviews, and also tales from friends. I will leave the implications that this diversity has to you. I expect to revise this post a few times in the future. Also, splitting things into disjoint categories turned out to be difficult, so it's somewhat arbitrary. Order does not necessarily reflect importance. With that being said, these are some examples for ways in which Berlin IT companies differ :

People

• Diverse mix —vs— 95% locals
• Daily English —vs— German all day long
• Cheap junior labor —vs— mostly seniors
• Non-IT people and IT mostly lunch together —vs— hardly ever

Development

• Git —vs— Mercurial
• CI on master branch —vs— on all branches —vs— zero CI
• master branch always green —vs— in constant need of repair
• master branch has a single gatekeeper —vs— it has not
• Code review is waving through —vs— code review is collaboration, exchange, learning —vs— code review is not done
• Paid IDE —vs— using free edition of commercial product

Responsibilities

• Dedicated Ops people —vs— devs doing ops work as well
• Getting informed —vs— constant need to hunt information yourself
• Lots of freedom —vs— work drone with roadmap shoved down your throat without ever asking input
• Growing software —vs— getting tickets done any way

Working hours

• 32h per week welcome/tolerated —vs— 40h per week enforced
• Official core hours from 10:00 to 15:00 (5h) —vs— 10:00 to 17:00 (7h!) —vs— 9:00 to 17:00 (8h!) —vs— …
• Core hours enforced/complained —vs— come in at 11:00, we're good
• Sleep at night —vs— be called by Ops for help at 1am
• Home office by choice —vs— home office by explicit approval

Compensation

• Salary negotiated to the ground —vs— accepting what you asked
• Salary raised every 12 months by contract —vs— no plans to raise before you bring it up
• Vacation days negotiable —vs— 25/26/28 vacation days across the company
• Overtime compensated —vs— overtime not compensated

Contract itself

• Can be adjusted —vs— refusing to change anything "for administration reasons" (to then find out …)
• Is explained when you have questions about details —vs— is not explained
• Is German and English side by side —vs— German only
• Is mostly okay —vs— raising eyebrows a lot

Rooms

• Sales people have calls right next to you —vs— on the hallway —vs— nowhere near
• 2 people per room —vs— 4 to 6 people per room —vs— 20+ people per room
• Headphones, coming early, staying later to get work done —vs— healthy amount of distractions

Office

• No plants —vs— externally managed alibi plants —vs— 800 Euro budget to go buy some as a team next week
• Rather dark —vs— lots of light
• Windows to open —vs— no window that would open in the building

Surroundings

• Variety of tasty lunch options nearby —vs— hardly any

Equipment

• Freely chosen —vs— presets —vs— same reflecting Apple box for everyone
• Healthy chair granted —vs— on demand —vs— they'd rather have you quit
• Motor-lift table —vs— screw-lift table —vs— fixed height (of unfit/unhealthy height)

Drinks / Food

• Machine-made sparkling tap water —vs— three types bottled mineral that are hardly ever run out
• Water, wide variety of soft drinks, juices and beer —vs— two boring options
• pay-yourself sweets —vs— free sweets —vs— no sweets
• Barely drinkable coffee from press to a single button —vs— "Siebträger" espresso machine for handmade gourmet coffee (i.e. the "Gentoo way")

Your mileage varies? Interesting differences missing? Surprised? Drop me a mail!

Version 2018-05-04

I recently dockerized a small Django application. I build the Dockerfile in a way that the resulting image would allow running the container as if it was plain manage.py, e.g. that besides docker-compose up I could also do:

# For a psql session into the database:
docker-compose run <image_name> dbshell

# Or, to run the test suite:
docker-compose run <image_name> test

To make that work, I made this Docker entrypoint script:

#! /bin/bash
# Copyright (C) 2018 Sebastian Pipping <sebastian@pipping.org>
# Licensed under CC0 1.0 Public Domain Dedication.
# https://creativecommons.org/publicdomain/zero/1.0/

set -e
set -u

RUN() {
    ( PS4='# ' && set -x && "$@" )
}

RUN wait-for-it "${POSTGRES_HOST}:${POSTGRES_PORT}" -t 30

cd /app

if [[ $# -gt 0 ]]; then
    RUN ./manage.py "$@"
else
    RUN ./manage.py makemigrations
    RUN ./manage.py migrate
    RUN ./manage.py createcustomsuperuser  # self-made

    RUN ./manage.py runserver 0.0.0.0:${APP_PORT}
fi

Management command createcustomsuperuser is something simple that I built myself for this very purpose: Create a super user, support scripting, accept a passwords as bad as "password" or "demo" without complaints, and be okay if the user exists with the same credentials already (idempotency). I uploaded createcustomsuperuser.py as a Gist to GitHub as it's a few lines more. Back to the entrypoint script. For the RUN ./manage.py "$@" part to work, in the Dockerfile both ENTRYPOINT and CMD need to use the [..] syntax, e.g.:

ENTRYPOINT ["/app/docker-entrypoint.sh"]
CMD []

For more details on ENTRYPOINT quirks like that I recommend John Zaccone's well-written article "ENTRYPOINT vs CMD: Back to Basics".