Curiously, I find myself being driven to devise common ways to abstract context in my infrastructures. Initially it was an afterthough, but now it's become a metathought, becoming an approach rather than an artifact. I'm wondering now if it has more to do with the problems I'm working on or the way I'm going about coding their solutions. How far can abstracting context go? From a practical perspective, I've been busy lately building infrastructural facilities to support other efforts. At night, when I work on my own stuff, I'm metaprogramming at subterranean levels while juggling multiple contextual onions. I contrast that with the day job where the focus is always on end-product - add a feature here, a page there, connect to a database and do choreographed crud. The day job is satisfying, but the depth, issues and complexity of the night work is entirely different. Perhaps what I'm seeing now is just a sort of transcendence of style. Instead of writing context-free code in a specific domain, I'm writing context-abstracted code for use in multiple domains. Pushing away from specific problems, I find context can be wrapped up in a small packages and examined or re-established as needed. It's like I'm stepping outside, standing away and looking in. But it's more than a simple inversion. I really am thinking of context as an abstraction, as though from the point of view of an infrastructural component. And I'm finding that this perspective has tremendous simplifying power. It's still fuzzy. I haven't yet stood far enough away. I think I've only glimpsed at what a generalized context object needs to contain and do. But I really want it.