I always favored pen and paper for initial technical designs and when first devices that enabled handwriting recognition emerged, I enthusiastically tried them out. Some of those original applications were quite good, but worked only on one device, like the Samsung's SNote, and some worked on several platforms, but captured only pixel images instead of pen strokes.
Eventually, I ended up using OneNote, which works on many devices and has all the features I need, but many of those features are implemented inconsistently across various devices and I can't help but wonder if OneNote is being developed by multiple independent teams with limited communication channels between them.
Last month I ended up copying thousands upon thousands of files, while recovering my data from ReFS volumes turned RAW, because Microsoft quietly dropped support for ReFS v1.2 on Windows 10. During file recovery, I was trying to be careful and flushed the volume cache after every significant copy operation, but a couple of times Windows just restarted on its own and I faced a bit of uncertainty on whether data in all files safely reached the drive platters or not.
I used a couple of file integrity verification tools in the past and thought it would take some time to read all files, but otherwise would be a fairly simple exercise. However, it turns out that everyday file tools don't work quite as well against a couple of hundred thousand of files.
I have been a big proponent of Storage Spaces in Windows 10 for many years and while redundant storage provided by Storage Spaces is not a replacement for a proper backup, it does provide good protection against individual drive failures and some forms of enclosure failures.
When Windows 10 was just released, in addition to drive redundancy, it also allowed formatting Storage Space volumes as ReFS (Resilient File System), which added a layer of protection against bit rot and sudden power loss because of the way it performs disk writes. Later on, Microsoft removed the ability to format new volumes as ReFS from Windows 10, but existing ReFS volumes remained usable and I assumed that Microsoft will be respectful of terabytes of data and will warn me that ReFS will no longer be maintained on Windows 10 when the time comes.
That turned out to be a bad assumption and what followed felt like a gut punch.
When I wrote the first version of this blogs application in 2008, I initially used TinyMCE for posts and comments, but within a couple of weeks I switched to CKeditor because it handled HTML better and provided server-side support for image uploads. Years have passed since then and the last version of CKeditor I integrated into this application was v2.6, which was written so extraordinarily well, that it continued working for me without any problems for over 10 years.
In the last couple of years, when I started noticing little problems, like Ctrl-B switching back to plain text on its own in Chrome, I decided it was time to upgrade the editor to the latest version. CKeditor worked so well for me over the years that the thought of checking out alternatives didn't even enter my mind.
Last week, after a large Windows update, my laptop popped up an offer to upgrade to Windows 11 before even getting to the sign-in screen. There was only upgrade and decline buttons and while I didn't want to update right at that moment, I didn't want to decline either. I pressed Esc and it continued. No idea if it was the same as decline, but checking Settings > Windows Update confirmed that the offer is still there.
I looked around for Windows 11 upgrade stories and couldn't find anything useful - all articles and posts described the new Windows 11 look and feel and had very little to say about features and general behavior. So, I decided to upgrade on the weekend and check it out for myself.
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.
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.