UI blunderz

travis is a great service that provides CI (Continuous Integration) build platform suitable for github based projects. For Open-Source projects, there is a free tier.  - but there was a wee booboo if the end-time of a build is not yet set: This could be case of defaulting to the start of Unix time or 'epoch'. Unix time is measured from the beginning of the year 1970, measured in seconds. An alternative implementation would be to use a null to indicate unknown time - however even the inventor of null considers it to be a mistake. This being a website, the client side code must be JavaScript, in which there is another option undefined, although normally that is used to indicate a bug for example if attempting to access part of the program that does not exist. (for example, a typo attempting to use a function that does not exist). This is possible, because JavaScript is a dynamically 'duck typed' language, where objects and data are accessed by convention rather than by c

For frontend web developers, there is a handy Chrome plugin, to inspect the state of the ReactJS website. However, a disadvantage is of course that just about any other ReactJS dev can also inspect your public website. If you happen to have deployed using a *dev* (internal, not really optimized for production) build, then this can be detected by your users. Unfortunately Yahoo Mail! had this issue for a while (but it seems OK now)... Word to the wise: sanity check your production software now and then!

Windows has been around for quite a bit, and been thru several revisions. The Vista edition, like the Concord, looked impressive, but at times had difficulty flying. Here Vista is trying to show some volume controls (with a pretty basic hardware setup), and running into some difficulties: What causes this bug - who knows, and I suppose, who cares. Some kind of erroneous while condition, which can cause any imperative program to enter an inefficient, repetitive  state. Given the complexity of a piece of software such as Windows Vista (50 million lines of source code!). To put this in perspective, and at risk of comparing the art of C++ programming to that of 16th century literature (though at least in terms of age and fragility, there may be parallels), the entire works of the Great Bard (he of Hamlet) number 0.88 million lines. So we may reason that Windows Vista could have been composed by 56.81 Shakespeares.

Down through the years, it is unfortunate but true that any diehard Windows user will have experienced a serious disk failure. While it is true that like any mechanical device, disks are prone to occasional error, and like everything in this universe, eventual decline unless work is done, there are fundamental reasons why the Windows Operating System is more prone to disk issues that Linux based systems. Given the same hardware, and allowing for different flavours of Linux and file systems, generally Linux disk systems tend to be better performant and more reliable: - Linux filesystem avoids fragmentation, where the free space of a disk becomes broken up over time into smaller parts, and then newer large files must be broken apart in order to fit into the free space. Fragmented drives tend to perform more slowly, and defragmenting is a slow process. - Linux seems to make better use of caching, where file contents is read and written in memory (the very fast, volatile storage of a compu

Team Explorer is/was a part of Visual Studio IDE (a tool used by Windows-based application developers). This part involved retrieving and committing source code to remote source control systems, mainly Microsoft's Team Foundation Server (TFS). TFS is not a new acronym, and one of its older, colonial-days meanings was Tropical Fatigue Syndrome, the effects of which would be familiar to any unfortunate developer as they struggled with various Team Server errors: Why these errors are displayed at all to the user, is basically to halt the dumb imperative program in its tracks , before it can do more damage. Why would damage be done to the user's precious data? The dumb, command-following program has hit an unexpected, not-designed-for problem, and were it to continue, its behavior is, like a beautiful Porsche stolen by an insane criminal mastermind,  actually completely undefined. Not even the coders who originally built the software would know what exactly would happen next!

Visual Studio, that erstwhile desktop development tool used by millions of Windows based developers since the late '90s, has been through many a revision. Unfortunately, like any complex piece of software, some of these interesting and progressive revisions also involved the odd regressive bug, where the tool hit an unexpected state that it cannot handle. Words fail to describe     Catastrophic failure! Catastrophic indeed! In classic application developed software, handling 'undefined' situations that are not expected, leads to undefined behavior, where no one really knows how the system will continue to behave. Such situations pose a danger to any data involved, such as documents that the user is editing, since at the very least, the user may lost their current unsaved changes. Worse, if the program continues its imperative path (where the computer is blindly following instructions given by the original authors of the software), then the data may actually become corr

Tenrox in a former incarnation was a rather primitive website with a decidedly built-by-desktop-coders feel. It did work, but was difficult to use, and so like many a functionally correct product, did not gain the enthusiasm of its users that any product supplier would desire. The title of the software - Tenrox - made this situation additionally uncomfortable for its long suffering users... Unfortunately, the user issues were not confined to usability: there were also occasions of unexpected errors: Although this dialog is ugly, in case of un-handled errors it can actually be catastrophic failure may be the best thing to do. This is to avoid data loss, data leakage, unauthorized access and other unexpected behavior. Today, Tenrox . com is marketed "a cloud based project management software that helps you plan and schedule your projects track time and expenses" - already sounds better!

Even the mighty Stackoverlow site has had its share of downtime over the years. site down: an extreme case of preventative catastrophic failure?  In this case, the cause is not known, but could be a sudden maintenance for security reasons, OR a decision to take the site offline when a critical bug was found. The second reason could be an planned example of catastrophic failure - a decision to terminate the program (the web site) in order to prevent entering undefined states that could lead to much more serious consequences such as data corruption, data leakage or security issues. Typically, catastrophic failure is a kind of automatic throwing mechanism, where a program raises an exception to interrupt the current flow of code. However, in extreme cases, a site down state like this could be a manual intervention...

Programming is hard! The classic imperative programming model, where the computer performs the exact instructions as given by the programmer, places a huge burden on the shoulders of the all-too-fallible human coder. The problem is one of managing complexity , and one of communication to and from the computer and the human being. The human works by attempting to create an internal mental model that is as accurate and complete as possible, of what is actually going on inside the computer. So, some coders are far more productive than others, making less mistakes and able to make more accurate and complexity-managed software.  However, with today's complex and multi-vendor hardware, even the simplest smartphone or laptop is never fully understood by one single human coder. Worse, the human coder is relying upon a wobbly stack of existing code created by previously similarly limited human coders. In some respects, it is amazing that any software works most of the time! Here is an ex

GEP Launcher is/was some old x86 program, which was in an unfortunate manner, revealed to be written in Perl. Perl is a much maligned language, something like JavaScript, without the good parts. There is no compiler which in itself has the advantage to shorter iteration times during development, but then all checks and validations are performed only when the program is actually running. Originating in a lax kind of West Coast environment, Perl kind of "sits by the poolside" and lets you do what you want, no matter the consequences. A running joke is that almost anything can be interpreted by Perl: so, something like Regular Expressions, the code can be easy to write, but hard to read. And it's generally agreed that developers spend far more time reading than writing code.  Unfortunately for fans of particular programming languages, it is difficult to objectively measure the prevalence of bugs with a particular language. Reports abound of how buggy C++ projects tend to be,

Microsoft software, despite unfortunate products such as the CMD line envrionent (no-one who has switched to Unix or bash-on-Windows has ever complained!) - generally have high quality, considering the sheer range of hardware supported, the different product lines and their generations, and the millions of users, it is somewhat impressive that it mostly works. However, there is the odd slip-up which we helpfully point out in these pages: Timeless messages from classic code Like any engineering endeavor, there are trade-offs between cost and value, and so quality can at times suffer...

  Notepad++ is a great and free text editor with many practical features, such as line-sorting, multi-file and directory find-and-replace, and excellent encoding support. However, programming is hard, and even the noble Notepad++ has been caught off guard in the war on bugs:  To NULL or not to NULL... A display full of NULLs is not that desirable, but on the other hand is better than random, uninitialized data, or worse, reading beyond assigned buffers into memory regions containing data this user is not supposed to see.  The history of NULL is a controversial one: it was, somewhat like JavaScript, cheap to implement at the time and seemed a good idea. However, notoriously, even the inventor of NULL considers the invention to be a mistake . At first glance, and when used in a very limited scope, NULL seems a sensible construct: a global kind of default 'this is not set' value, that is reliably detectable, as opposed to some random memory garbage. Issues arise when the NULL val

Windows aficionados will recall the blue screen of death - and it's not fun like the one they use in the movies. To the credit of the inventiveness of Microsoft engineers - the screens of death are not limited in their colors to the blue section of the visible electromagnetic spectrum. Should you be unlucky enough, and perhaps there is some Irish-American connection here, but you may also share the joy of experiencing not only the blue screen of death - but also the green:   Software innovation at its finest Oh to be a fly on the wall, when the UX, software devs and PMs were discussing this fine feature! The exact count of shades of green that Windows sports is a topic for more in-depth analysis, and may even be considered a trade secret... EU officials are investigating...

A rather unfortunate, and thankfully unusual errors is when the dotnet platform runs out of memory (most likely, in fairness to the large and so easy target that is Microsoft, not at all the fault of the behemoth, but that of the incumbent application...). Admittedly, this is an extreme case, given Windows paging mechanism, where the short-term volatile RAM of the computer can be artificially (how else?) extended by writing less-used data to disk - this extreme case, where even the paging-extensions are failing to acquire enough memory... User intervention required... Perhaps this is a case of catastrophic failure - although it seems less preventative, than already too late... So, would it have been simpler to close the offending process and show the user a suitable error message? The choice presented to the user seems enviable indeed... So, this seems less a case of preventative catastrophic failure, than lazy coding, where responsibility for a technical decision is dumped onto the u

Not all issues are bugs, and not all issues take a long time to fix. Consider this example from Microsoft Lync (the posh Skype): Be right back... Unlike many other application boo-boos exemplified in this series, this one is a bit hard to explain. The message does admit there is a problem, and this is a modal dialog (absorbing all user input and so blocking any other part of the application from processing any new user actions). So, on the face of it, this appears an example of catastrophic failure . However, reading further through the message, we see that the user has a rather specific task to perform: restart and leave it running for 15 minutes . Restart does seem a little unfortunate and casual: we don't quite know what the problem is, but in fact we DO know the software is, like your aunt Wilma's old car, a bit unreliable, and just needs a bit of a kick and another try every now and then. Admitting to unreliability is unfortunate, yet the honesty is to be commended - hop

A kind of California style, cool and casual way to tell the user that something truly bad has happened to the Google Chrome browser.   why ask? Although this is a "mere browser" and not the OS (there is still a difference, right?) - this does not seem so much different or better than Microsoft's prompting the user when the dotnet platform exhausts memory . Such an error seems unrecoverable - like a catastrophic failure, there is no choice to be made - so why ask? The user really does not have much choice - so why prompt? and why should the user need to decide what to do with your bug?