One of the more persistent challenges we’ve faced at my day job in recent years has been adapting our “plug-in” web apps to the design constraints of our resellers’ website products. Think, for example, of a camera store widget that can be added to an existing page on an existing website. The user should be able to select from a library of different designs and color schemes to try to make the integration with the site as seamless as possible. When we first built the infrastructure for handling different internal designs, we also came up with some baseline widths (500px, 750px, 950px, etc) that we thought would be able to accommodate the needs of any website designer. Then we wrote separate CSS style sheets for each design, color, and width combination. This seemed like a reasonable approach at the time, but in practice it’s become a real headache as we’re constantly having to adapt to the specific width requirements of each new vendor. And our recent forays into WordPress themes and Facebook frames have only exacerbated the issue.
A few months ago, we started researching new platforms, frameworks, and tools for the next generation of our flagship product at my day job. OSGi was one of several Java technologies that came up during our initial discussions. I had heard of OSGi in its context as the underlying runtime for the Eclipse IDE plugin architecture, but otherwise I knew very little about it. A quick Google search revealed that it’s been rather ubiquitous in the embedded software world for quite some time now as a way to implement service gateways. More recently, forward-looking developers have also started to consider it as a platform for increased modularity in enterprise web applications. This idea piqued my interest, and I decided to do a little research. While we ultimately chose not to use OSGi for reasons which I’ll outline below, I still had a lot of fun putting together a presentation for my colleagues and building a small prototype. I’m definitely going to keep an eye on progress in the OSGi world over the coming months in the hope that someday it will become a standard in the web world too.
Early last year when I decided that I just couldn’t put off redesigning the very dated-looking Orbi Software site any longer, the first skill that I knew I needed to get up to speed on was CSS. Like many programmers, I had learned the basics of CSS in a very informal way, mostly by looking at a few online examples and then studying the stylesheets of designers that I collaborated with as a coder. This limited exposure gave me enough knowledge to get by, but I always felt like I was coding by coincidence when I had to write my own classes. And some of the CSS files that I was maintaining became rather large and unweildy over time, with lots of unnecessary duplication of similar styles. As the promise of CSS3 slowly started to become a reality with the release of many cool new vendor-specific CSS3 extensions, I finally decided that I just didn’t want to hack my way through creating stylesheets any longer.
In this series of posts, I thought it might be useful to step back and take a look at my current development environments. Environments is plural here because I have more than one: the first on a PC running Windows 7 Professional at my day job, and the second on a MacBook Pro running Snow […]
2009 UPDATE: ColdFusion MX 9 has been released since this article was originally published, and it now has Hibernate baked right in. Why do I want to use JBoss instead of sticking with Macromedia’s own JRun J2EE Application Server? Well, it’s a little bit of a long story. Most of the application development I’ve done […]