New Computer Users

I can't remember when, or why exactly, I started using a desktop computer. The fact that it was a clunky desktop system running Windows 93 says something all on its own. Clearly, I didn't have any idea how irrelevant that system would become in short order. New computer users don't understand how quickly technology development moves — if I had known that, I probably wouldn't have bothered. The fact of the matter is that when I first started using a computer, I wasn't a developer, I wasn't using the thing as a tool to do any meaningful work. The real driving force was simple curiosity. That curiosity, I'm sure, was partly driven by the surrounding hype at the time. Computers, and their interconnected fabric were the future. If you didn't understand them and tightly integrate them into every aspect of your daily life, you'd left behind. Back then, I don't think the surrounding hype got the best of me. Hype hasn't slowed down, its simply moved on — mobile computing for instance. I was too busy doing kid stuff to really appreciate the ramifications, and so I was considered a casual user. Probably like a lot of people around the globe who use computers, but don't depend on them for critical tasks. Then there are other types of users. There are developers, there are non-humans. We can classify users based on why they're currently using a computer, not why they first started.

Cloud Application Support

Consumers of the cloud are of only a few variety. Maybe even two. There are those who really enjoy configuring the low-level platform aspects of what they're deploying. To these consumers, CPU topology matters, as do the network card specifics, and whether or not ACPI features are available. Platform level concerns are of the utmost importance in any environment — cloud or no cloud. But if we treat the supporting platform as the only critical piece of the system, we wouldn't succeed in our mission. Which brings me to my second class of cloud consumer — the application developer. The easy solution, and one that I think we're relying on a little too much today, is don't treat the application as an actor in the cloud landscape. Instead, the established approach is to treat the applications that actually fulfil business requirements as something that gets put into a platform container. The container is a cloud-friendly wrapper that encapsulates the application to a point where it doesn't know it is virtual.

CSS3 Transitions in jQuery UI Themes

You can add CSS3 transitions to your jQuery UI theme without much effort. You can use a single selector to apply the same transitions to multiple jQuery UI widget components. As a simple example, the following code illustrates how we can apply CSS3 transitions to the hover state for buttons, accordion headers, and tab navigation.

Lean Tornado

Tornado is a lean web framework. Vague, yes. Allow me to explain. Tornado doesn't get in the way of the developer trying to build an application by imposing too many conventional constraints. Each web framework that gets put out there in the community, be it Python or otherwise, adopts its own conventions. Usually from inception onward. Conventions establish a standard set of practices, patterns — call them what you will — they're essentially rules that explain how to best utilize the framework because some other developer had done it that way before. By and large, this approach works. Develop a toolkit that has a vast collection of reusable components and an instruction manual on how to use them in isolation as well as building new, larger components from smaller ones. By following these conventions on how to get the most reuse out of these parts, the developer really only needs to tap their previous project experience with similar code and the rest should just fall into place — assuming they've read all the documentation and learn how to follow the patterns of the framework very quickly.

Privacy In The Cloud

Not much thought goes into privacy control with regard to the pieces of information our virtual machines expose when running on a cloud provider's infrastructure. I'm not talking about the internal data that only the guest operating system has privileged access to. That's a security concern. I'm of course referring to the mountain of data that we're generating as a bi-product of operating a virtual infrastructure. The meta-data. This infrastructure is offered out to customers as a service, and just like any other web service, the provider is going to collect data on all their tenants. What does this data look like? What information can be derived from this data, and do we as tenants have any say in the matter?

Rewriting and Forgetting

I once rewrote an entire program in another language. Why, you ask? At the time, I thought the software would improve by virtue of be written in what I considered to be the better language choice. Perhaps my naive assumption stemmed from the hope that customers actually care about such decisions when interacting with my software. I never had the opportunity to become that customer before realizing that hardly anyone using a system ever stops to think about the design decisions that have made their way in. The only ones who truly pause and think "hey, wouldn't this be spectacular if we could just rewrite this in a language that runs on many platforms instead of maintaining many code paths" are us — the ones who write the software to begin with.

No Fixed Address

All content out there on the web has a fixed address. But the objects that reside in the implementation of these web resources do not. At least not in a URL-sense. These are objects that live in the database, in cache, or in the web server's memory, as part of an intermediary step toward the finished product that is ultimately delivered to the client. What these objects do have that strikes a similarity with URL-thinking is a unique identifier. These identifiers tell us that this object has it's own state, unique to itself in some context. The context in which these objects are unique is usually constrained to the application. For instance, the primary key that identifies a row in a database table is a common object identifier. The context in which we're assigning identifiers to objects is growing more important, as time moves on, because there is a growing need that the applications we develop integrate seamlessly with one another.

Designing For Big Data

Information is all around us. We're producing more data on a daily basis than ever before, and there is no sign of this phenomenon slowing down. Most likely, this is due to the increasing number of network-connected devices. Everyone has a laptop, a tablet, and two phones it seems — each generating data in their own unique ways. Going beyond personal computing devices that we control for the most part, there is a growing number of unmanned devices that are pushing data across networks. These autonomous agents are usually sensing data about their surrounding environment, and publishing the raw data for either some centralized software that knows how to make sense of that data, or in a more distributed fashion where other agents might want to know what's going on. These autonomous agents have a profound impact on the global measurement of available information because they never sleep. There is an endless stream of data about the current state of the world. We're measuring just a portion of our existence through these autonomous tools, a tiny fraction of what we could potentially measure. Imagine what the automated information stream will look like 5, 10, 20 years from now...