Selecting Real-Time UI Messages

Displaying notifications in the user interface is an essential feedback mechanism. They inform the user that something of interest has happened. A virtual machine that belongs to them, and one of the disks is no longer accessible. The user might want to know about something like this as it could pose a serious threat to their business. Imagine this type of thing happening and we get notified by the guest operating system when we try to write to the missing disk. Better to let the user know as soon as something like this happens, using appropriate messages, perhaps even guiding their next course of action. The problem with this type of notification is that the user didn't trigger it. It was triggered triggered by the autonomous background behavior of the system. And so, displaying these types of notifications indiscriminately could pose a problem. The UI needs to select which messages to display.

The Web Shaped By Applications

The web used to be composed of simple pages. It still is, to a degree, but less and less so. For example, Wikipedia is the active giant still spewing forth pages rich with information. There are plenty of news sites, and blogs just like this one that I wouldn't consider applications. But less and less so. Instead, we're craving the interactivity brought about by applications. The information is still there, just arranged, and curated differently. Instead of a monolithic blob, such as this post, the pieces of information are fragmentary. Not necessarily incomplete, but defined by a work-flow different from what we're used to. Will there be a need for pages in the future when the web is composed of powerful applications that allow us to better carve out the chunks we need at that moment?

The Plugin Ecosystem

The idea of monolithic software is a rarity for most folks. Even an operating system, which is itself a big monolithic beast as far as most users and developers are concerned, has it's own plugin ecosystem. The operating system does a lot of work, but the vast majority of that work is in support of plugins, or applications, that run on top of it. Like it or not, its these plugins that make the software on which they run useful. They support the idea of an ecosystem, new plugins evolving from old ones, old and stable plugins becoming dependencies of other plugins — once the plugin development community forms, it seems there is no stopping it. The ecosystem that plugin development sets forth opens up the door to an interesting development culture, one that seems to have a strong experimental, and thus, strong educational feel to it.

Permissions and Capabilities

Users are a central concept to any software system. Even single-user systems have users, maybe even multiple users, just never at the same time. Looking at the user concept through the eyes of a developer, however, roles are a better concept. The reason is simple — roles are abstract where a user is an instance of one role or another. This is how we think about most other things in the system, so why not the actors that we're interacting with too? We're not interested in the user who is currently interacting with the system, because that's not how the UI components are designed. They're designed around roles. The role describes for the developer, what this user instance is capable of doing. Roles are about permissions and the underlying capabilities of system. The two are interrelated, but when separated, as they so often are, cause major headaches in the code.

Developing Error Opportunities

I'm never able to catch myself making a coding mistake before it happens.  The funny part, for me anyway, is after the fact when I discover what the issue really was — it was a trivial error.  And the pattern I followed leading up to the error was avoidable.  How could I not have seen this coming, I sometimes question.  Is the answer that only in hindsight are these types of things obvious in an activity as complex as writing software?  That may be the answer.  But even still, I think it is both interesting and worthwhile to think about this type of software development pattern.  What makes us predictably and repeatedly successful, and what makes us unpredictably and repeatedly error-prone?

Complexity and Scale

What's the relationship between complexity and scale? Is there no relation between the two concepts when it comes to software architecture — your software either scales up or it doesn't? I think the opposite is true. There is no technology that encases our existing software systems and presents the owners with a scale button. That doesn't stop us from trying, and the results are mixed. That's not surprising, however. The successful software scaling operations typically involve a simpler business domain. That's not to say it's impossible to scale up complex software systems — Facebook has an incredibly complex business domain and I think it's safe to say they know how to scale up their systems. They're also a good example of how the two ideas are bound together. Facebook has a lot of knowledge about, and spends a lot of effort on, large-scale software.

Organizational Features

Depending on the software, the information captured needs to be organized in one way or another. Users don't just supply input only to be dumped in a large holding bin. The user doesn't want to sift through their information when they actually need to find something. Another reason users want their information organized, probably according to a schema of their own creation, is for when they don't know what they're looking for exactly. There will come a time, when you have a flash, a sudden recollection, or partial memory of something more complete. You know it exists, you just need to come across it to bring it to the forefront of your memory. In these situations of "I don't know what I'm looking for", we browse our stored information. How we browse, depends on how we organize. But organizing isn't just some trivial activity. Depending on the organizational facilities we've provided to the user, they just might overwhelm themselves.

Geo Everywhere

Precise geographic data is invaluable when it comes to software that has to know either where the hardware its running on is, or where something else is. And it seems that this particular type of data is found in software everywhere. And if it isn't, you could probably find a valid use case after browsing the code for ten minutes. Phenomenons hit software development culture, some stay while some disappear. The ones that stay, generally never stop evolving in an effort to standardize their meaning. Everyone must be on the same page, otherwise, you might as well create your own ad-hoc formulation. Geo is different. The way we store, manipulate, and use the data is constantly in flux. But the data itself — longitude and latitude — unchanging, and unambiguous.