Andre's Blog
Perfection is when there is nothing left to take away
Version? What's that?

Traditional applications rely on the application version to communicate to application users the set of features included in a package and the impact of upgrading from one version to another for applications with carefully maintained versions.

Website applications, on the other hand, are often upgraded by the website operator in their own environments and website users usually have no idea what version of the application is running behind the website UI, even if there is one.

Website applications are centered around user-visible features, which are being continuously developed and deployed to production environments, so grouping features into version levels for such deployments makes very little sense.

Looking for thoughts on HTML reports

HTML reports generated by Stone Steps Webalizer didn't change much structurally since I forked the original project back in 2004. Current HTML reports use CSS styles wherever possible and have some JavaScript niceties, such as rendering charts in JavaScript and, less-known, jumping between reports with Ctrl-Alt-Up/Down, but otherwise they remain the same monthly one-page reports with pre-formatted all-items sub-reports and a single collective index report.

Bitbucket fishing

A few months ago Bitbucket dropped the Stone Steps Webalizer project repository because Mercurial was no longer supported. Along with the source repository Bitbucket also dropped Wiki, issues, downloads and some configuration, like components and milestones, even though these didn't have anything to do with Mercurial.

I moved the project to another hosting service, but about a week ago I needed to follow up on one of the past Bitbucket issues and noticed that some images from the supposedly deleted repository Wiki were still accessible in Bitbucket cloud, which made me think that my repository was just disabled, but not deleted.

Five days till release

One cannot spend a week in software development without hearing how many days are left before some milestone, be that a release or just a sprint demo. Yet, I cannot remember ever hearing that there is only 120 hours left until the upcoming release. Sometimes 24 or 48 hours are being tossed around to deliver the same message, but that's just saying that the release is in 1 or 2 days and that the team is expected to work around the clock to get there.

Most issue tracking systems, on the other hand, tracks work in hours and one cannot help but wonder how work hours translate into days until that milestone. The simple answer is that they don't, even though most teams keep trying to have that cake and eat it too.

What is build metadata good for?

Build metadata in Semantic Versioning is a quite commonly misunderstood concept, which often sparks passionate online discussions on whether build metadata should be allowed in package repositories or not, and some of the confusion around this topic even seeps through into prominent online services and applications.

CSS font size - it's not what it seems

Ever since I started using a 4K monitor, I noticed that I have to adjust browser zoom almost for every site where I wanted to read content and not just glance at some excerpt. Looking closer at CSS styles on some of those sites I found that most of them used pixel unit sizes for pretty much everything, including fonts. I was puzzled at first by the widespread use of a technique that cannot compute sizes in a predictable way across various displays and devices, but further investigation confirmed that it was done on the advice of the CSS specification.

Stomp that Squash

Squashing commits is not a particularly new concept - one could always get a diff between two non-adjacent commits or dates, before multi-file commits came about, and produce a combined patch of changes, similar to how squash commits work, which was useful for submitting patches to another project and other similar uses, when recipients were not interested in development details and wanted just the patch.

In recent years squash commits started gaining popularity, but far too often are used as a new fashionable way of doing things, rather than for a specific purpose, which yields oversized and poorly structured commits that are harder to review, graft and trace in a bug tracking system.

Switching from Mercurial to Git

I always loved Mercurial for its clean command line interface and its powerful revision query language, which are very well structured, compared to Git's adhoc command line approach that combines unrelated concepts in various command line elements, such as allowing commit message search in a revision specification (e.g. git log ":/^ABC" --), which backfires by reporting a bad revision, depending on whether the text was found or not. However, support for Mercurial services and tools has been declining for quite a while now and the time has come to switch to Git.

Kicking the Bitbucket

A while back now Bitbucket informed me that Mercurial repositories are no longer supported and will be disabled as of Summer of 2020. In my mind of a software developer a repository is just where the source code is kept, so given that Stone Steps Webalizer is now mostly in maintenance mode, I decided to let the Mercurial repository be disabled at Bitbucket and use it just for issue tracking, Wiki and downloads. Soon I learned that Bitbucket and I have different definitions of what a repository means.

Point of Story Points

How many times you heard in agile planning meetings that a similar user story has been done before, so the user story in question can benefit from that experience and can be assigned a fraction of the original story point value? If the answer is more than once, chances are, your planning meeting are long and contentious and past velocity rarely comes up when you are filling up the next sprint.