Tag Archives: dependency

Aspects of Love

Programming languages come and go at a frightening clip. Less often but still with some regularity, frameworks appear and disappear as well.

But it’s more infrequent that entire approaches to coding come along. Functional programming has been around forever. Object-oriented programming has been around nearly as long. But it’s only been a little more than a decade that the idea of <em>aspect-oriented programming</em>, or AOP, has been on the scene.

If you’re not familiar with AOP, some background might be helpful. A key idea behind AOP is that there are functions that your code needs to do which go across (or cross-cut) the entire application. In other paradigms, you then need to code bits of those functions all over the place. But in AOP, you do it only once.

One prototypical example is logging. If you’re writing an application that does anything significant, you probably write out to some kind of log when it happens. In a user-based application, for instance, you probably want to log every time you add a new user or delete a user.

Under other approaches, you need to call some kind of logging hook in your addUser and deleteUser functions (or methods). But with AOP, you can define a separate logging function, and tell it to attach to the deleteUser and addUser functions. The parts of the code that actually do the work with users aren’t touched at all.

Why is this helpful? Well, suppose you want to change how logging works or how you call the logging piece. You’d need to touch every place it’s called. With AOP, you just change the logging piece once, and you’re done.

Or suppose you decide well after the design stage that you want to add a layer of security to every user routine to make sure the person trying to make a change has permissions to do so. You could go find all of the functions and add calls to them, or you could just create a security-check routine and attach it to the relevant functions.

Compiled languages like Java and C++ have had this idea for a while now, but it has been slow to come to interpreted languages. With the Flow framework, for instance, PHP now has AOP capabilities. There’s still some roughness around the edges, but it’s a big step toward widespread adoption of this approach.

Watch this space…

Creeping Dependencies

We had a client issue the other day where a system stopped working because a necessary third-party service just stopped, with little warning. It got me thinking about the nature of dependencies.

When building networked applications, there are necessarily aspects of which you don’t have control. You don’t usually control every mile of the Internet connection that reaches the user, for instance. So, for example, if it’s a user at home on a shared cable connection and it’s 4pm on a school day when every kid in the neighborhood just got home to stream video, they’re going to have a slower connection–and there’s not much you can do.

In this case, it was a service dependency, and that’s just as potentially problematic. After all, there are times when you can’t do it all yourself–maybe you need to poll an external database for information, or there’s already a cheap commodity service that will take care of an ancillary need.

But the trick, and one that we didn’t really execute as well as we should, is to note the risk upfront and do what you can to mitigate it. In our case, we had noted the risk and thought we had some ways to manage it, but when the outage occurred, we immediately saw breakdowns in the process. Paths for escalating the outage notification were unclear, and the error message created for the users was, shall we say, less than graceful.

Fortunately the outage didn’t last all that long, and the upstream provider of the service was very gracious and quick about getting things resolved. But it was a good reminder that every time you create a dependency, whether it’s an AJAX call that relies on a decently-fast connection or a threshold service for access, it’s critical to consider how to gracefully handle the situation where it fails.

Because it will. At some point. But in our interconnected world, what’s the alternative?