Cloud as Quality Attributes

When I think about cloud computing, I often think about systems running elsewhere. As in, a catchall description of software that runs "in the cloud". Remote and encapsulated. This is a desirable property, a black box system, where we only have to know about, and understand, the external interface. We design components this way no matter where they run, in an attempt at good engineering. Components should be simple to use, and this is done by hiding away much of the complexity. Cloud based solutions are exactly that. The word "cloud" itself works well as a descriptor for abstract information hiding. We let our software run somewhere else, or use someone else's software, not necessarily understanding how it all works inside. It just gets the job done. Why can't we take an alternative perspective to cloud whereby we take some of the underlying principles of cloud and apply them to our software directly, as its being designed and implemented?

User Interfaces and Logging

The browser history takes on a new reputation in light of modern web application development. It seems that the browser history — the navigation capability of web browsers used to traverse web 1.0 — can either help, or just get in the way. The browser history might get in the way if you're striving for the complete desktop experience in your UI. This is where the back button is viewed as a hindrance, something antiquated that our code must be prepared to handle but offers no practical usability. On the other hand, the browser history is something that the web grew up with. It's as natural as HTTP or HTML in a web application. The web is supposed to be stateless. The URI a user visits inside an application shouldn't care about order. Regardless of what patterns your web application follows, the user interface needs to communicate and change state. With modern Javascript toolkits, the state of the user interface itself is becoming more and more detached from the state of the server-side resource.

Internet Security and Broad Daylight

Thieves operate under the cover of darkness. It shields them from what would otherwise be watchful eyes, keeping a look out in their neighborhood. Broad daylight makes criminal activity a little more difficult to execute, because the thieve is naturally exposed. This obstacle alone stands in the way — it acts as a security barrier. But the internet is not like that at all. Not only is there no such thing as broad daylight in cyberspace, but the whole idea of neighborhood doesn't really make sense. Security online amounts to every man for himself.

Letting Defects Coalesce

The quick-fix solution. An approach to bug-fixing that should be reserved for those critical problems impacting production systems. Or where you're in a high-pressure scenario where the software must ship. We all do it. Or at least, we should be hammering out these quick-fix solutions all the time. Because if we didn't, it'd mean we're waiting till we figure out what the perfect program looks like. The problem at hand takes a back seat to our own misgivings about the code we've put together. Quick-fix solutions enable us put software in the hands of users. Period. But that doesn't restrict us from thinking about defects over a longer period of time in an attempt to really understand their causes and effects. Are they just symptomatic of a deeper issue within the system's design?

Encoding Context In Links

A page in a web application shows formatted objects, menus, or things that pertain directly to the application domain. Like lists of objects from the database, or a single object, selected from the database and presented to the user. Lists of objects, or a single object, are part of the link the user has clicked, or pasted into the browser address bar. No matter actually, it's the notion uniform resource identification — the mechanism realizing this idea is secondary. The goal is that the link text identifies a resource within the application. But is that the extent of the information encoded into a single URI? Or do applications, as they become more sophisticated from a user interface perspective, need to provide context to the pages that render these URIs?

What Users Don't Know About Layout

Does it sometimes feel as though you're playing with a Rubik's cube when interacting with certain interfaces? At times, it can feel as though I can do more harm than good with the ten thousand layout-tweaking controls presented to me. Sometimes, these layout tools are in fact widgets themselves, occupying a seemingly small portion of the application space. They're not hidden away under the cover of the "advanced, break in case of emergency" section of the settings page. But I don't understand the layout of your application, so how would I even begin to go about fixing it? And does it even need fixing? Maybe it only matters if the application has gone out of its way to provide the ultimate in customization.

Decisions About Overhead

Premature optimization is all about the decisions we programmers make on overhead, before the overhead is actually witnessed in the running system. You might call it potential overhead that spins cycles on valuable resources while other code is competing for that same resource. The decisions about how to best go about minimizing overhead in software are made while its being designed. While writing code, we notice, staring at a particular function and the structures within, that this should be altered. There is no way that all this initialization work needs to happen here before the real objective of the function even starts. And so the decision to optimize, right then and there, is made. In the most straightforward cases, yes, it's worth the five or ten minutes of re-factoring and testing it takes for the obvious improvements. But even the simple ones amount to a much decision making without the relevant data.

Indexes and Keys

In any programming language, the developer typically has a choice between two collection types — a list or a dictionary. They may be called something similar, depending on the language — array and hash-map for example. The list uses an index to access a given item in the collection while the dictionary uses a key. A key could be a number, or some other primitive construct in the language, but they're usually strings. There is one interesting distinction between indexes and keys. Indexes are allocated by the list whereas keys have to be dreamed up by the programmer. This is both good and bad. Good because keys are strings based on some concept. Indexes, by contrast aren't so intuitive to the developer when they need to look something up later. Should we just stick with dictionaries in our code, or our we introducing some hidden issues?

Themes and Structure

At first glance, a theme is nothing more than aesthetics, the visual polish applied to the structural layout of a user interface. The colour combinations, the the gradients, the proximity of one thing to another. These properties are the eye-candy that make or break the whole experience. This view marks aesthetics as a blanket, coating the structural scaffolding of each widget, and collectively, the whole UI. But is it actually as clean a distinction as that? Can a theme really be thought of as no more than a collection pf appealing CSS rules? Can we detach the aesthetics from the UI, and it's constituent widgets, cleanly and without worry? It turns out, yes, we can and do. Thinking about the patterns of software reuse, the theme, or rather, the ability to theme, is crucial to user interface reuse.