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.

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.

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.

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.

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.

I always loved Mercurial for its clean command line interface and 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.

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.

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.

For some inexplicable reason product owners are obsessed with auto-correcting emoticons with emojis, which was somewhat manageable via app configuration before, but now that there is a tendency to simplify configuration by taking away options, a la Apple way, auto-correcting emoticons is becoming more annoying then it was ever before.

Forced auto-correction, in general, is quite stupid for a number of reasons, but automatic emoticon replacement is really getting on my nerves, not only because it changes the meaning of what is being posted, but also because it often interferes with useful Unicode features, such as searching.

I have been using Microsoft Modern Keyboard with Fingerprint ID for almost a year now and I am quite happy with how it feels in every-day use, so when I saw the weird-looking Microsoft Arc Mouse next to it on the shelf at the Microsoft Store, I thought it would be a nice replacement for my old beaten-up Microsoft Comfort Mouse 6000. However, sometimes a weird-looking thing is just that - a weird device that is hard to use.

I spent some time last week looking for a page that shows detailed per-province charts for COVID-19 cases and while there are some out there, they either combine numbers in the way that is hard to digest or they are just too small to be useful.

Being able to run server-side JavaScript predates Node.js by quite a bit. In early 2000's I was working on an application server called Tango and one of its features was the ability to run server-side JavaScript code in Mozilla's JavaScript engine, SpiderMonkey. Later on, I started using ASP with JavaScript, which worked just fine on its own for smaller tasks and for heavy workloads I interfaced ASP/JavaScript via COM with C++.

Eventually, Classic ASP got too slow and too outdated and the choice was either to move to ASP.Net or Node.js, which was picking up steam at the time. I ran a number of performance tests while trying to figure out a good path for transitioning a large application off Classic ASP and without concurrency Node ran JavaScript code incredibly fast, leaving equivalent ASP.Net tests far behind, but multiple concurrent requests made it evident that the more JavaScript is in a Node application, the slower it runs. This pretty much is still the case today.

Some time ago I noticed a bunch of disk controller error messages in Windows' Event Viewer and got alarmed that one of my disks or disk controllers might be corrupting data.

This question seems silly on the surface, to put it mildly, as both languages are compiled to produce most optimal code, often by the same compiler engine using the same optimization techniques. However, if widely-used programming practices and common libraries are factored into this mix, the result is not as straightforward as it may seem.