Published 14 May 2008
I had a brief encounter with aspects at the Colorado Software Summit a couple years back. I was glad to finally get a bit oriented to AOP, to which I had been blissfully ignorant, and decided that I had incredibly limited interest in the topic. Of all things, I kept wondering why AOP did not appear to be widely applied to the presentation layer, which was the first place I would think it to be.
Along comes Matt talking about extensionless URLs (a pet interest of mine) and dropping lines like this:
In an ideal world, it’d be possible to modify the <a> tag at the very core of the view framework you’re using to automatically encode the URL of any “href” attributes.
There you go – a cross-cutting concern if there ever was one. Where is our AOP for the presentation layer?
Published 22 February 2007
Following Cote’s del.icio.us links, I found that there is a JSR proposed for a RESTful Web Services API. It would be ludicrous for this JSR to not be voted in, so let’s assume it will go forward and become a massively committee-driven document someday, perhaps even accompanied by a reference implementation. The burning question on my mind is: will it actually be simple enough to use?
Hopefully, the JCP learned it’s lesson from the community fallout on WS-* Java APIs. And hopefully it has learned from the RoR community that developer productivity rather than infinite pluggability is actually a key requirement. Think Spring and DI, not commercial black box components and SPIs.
So let’s see if they can actually pull off an API that lacks the following:
- Factory classes for roundabout instantiation
- Manager classes for implementation abstraction
- Engine classes for what should be behind the scenes servicing
- Interface/Implementation pairing ad nauseum (I’m so done with the Bridge pattern)
- Pluggable runtime providers – how about just provide a good one OOTB and be done with it?
Can they possibly do it without the same old, tired patterns?
Technorati tags: java, jcp, jsr, REST, webservices, simplicity, econo, patterns
Published 4 January 2007
Anne Zelenka caught my attention with her recent posts about Ajax start pages – be sure to check these out.
Tim Peter’s right that ad-supported widgets are micropayments on a couple of levels – content providers are paying distributors micropayments for impressions and clickthroughs, and then I’m paying as a consumer with a drain on my attention. I guess what I am fearing is a world where each widget provider offers free and paid versions, so as a consumer I’m not signed up for a paid version of a single start page (a la NetVibes) that’s ad free, but rather I’m stuck making micropayments to multiple widgeteers if I want ad-free versions of their widgets on whatever start page. Yikes!
Until there are standards or semi-standards for how to produce Ajax widgets that will work on a variety of start pages, this could be the grim future.
Rich Campoamor is right on about the JSR 168 portlet spec. In the original spec (I don’t know where it ended up), all of the meaty UI specs (such as standard CSS style names that would let you add a measure of coherence to an aggregated portlet start page) were an appendix and an afterthought to the spec. I’m not optimistic about Ajax widget interop… but like I said I’m too cynical.
Technorati tags: ajax, startpages, micropayments
Published 11 December 2006
Not just applications and data… so said Jon Udell to wrap up his announcement about his new gig. Jon couldn’t have phrased that better, and I couldn’t agree more. Jon was making a larger point about language and platform dogmatism versus solution-oriented pragmatism. Being well-known for his transparency and openness, he is turning heads for going somewhere that most people have associated with being opaque and closed. But he gets the fact that Ozzie is changing the direction of that ship, and perhaps he will do so too.
I myself have been down various roads of being a technology dogmatist. At various times I have ruthlessly and arrogantly defended technologies that I was comfortable with. But more and more I see them as just so many mineral deposits that all clog the same faucet. Sometimes there is a right tool for a job. More often there are various tools that could adequately do the job, but always there is contextualization of tools. I want my value to be as a conduit for delivering, and less of being a lofty wonk or a one-size-fits-all punisher.
Sidenote: I want a job with a title of Evangelist someday! I currently work for an extremely cool employer and believe in the work that I do, but who doesn’t think ahead to their next move. I have long thought that my next stop would be as an industry analyst, but maybe evangelist is a better fit. I’m an evangelist today here, but no one is paying me and the focus is nebulous. And too many evangelists come off as being gilded sales reps. Maybe Jon will change that persona, and recast the coolness surrounding tech evangelism… we’ll see and I’ll be watching.
Technorati tags: jonudell, evangelist, industry analysts, mashup
Published 24 October 2006
conferences , development
That phrase dawned on me at some point yesterday during CSS presentations – it seems like the entire world is being configured in XML. Just about any enterprise software and many development frameworks have their configs in XML, I have even started to see benchmarks on apps that included lines of code together with lines of XML – it’s been elevated to a first class citizen in code metrics! But the fact is that it’s becoming less and less runtime config and more and more business logic codification.
So I think that any enterprise developer worth their salt will build and maintain skills in XSLT, XPath, and XQuery. These are not the hot technical skills that will raise your bill rate or necessarily float your resume to the top of the pile. But I think they are going to be seen as core skills before too long. And you just might be the superhero who rescues your team someday when migrating away from a mountain of proprietary XML configs.
Technorati tags: xslt, xpath, xquery, xml, roachmotel, coloradosoftwaresummit, css2006
Published 9 February 2006
architecture , development
I have been wanting to follow up on various very good blogs posts I’ve been reading lately around architecture concerns with Saas/mashups. A lot of people bring up concerns on security, etc. when talking about Ajax and the new mashup technology – but old schoolers will say the song remains the same. Sure, there are some new exposure points and those need to be protected, but you primarily need to practice the same good core architecture when dealing in this area.
I fully agree with Robert’s comments on reliability and other -ility management for SaaS/mashups as core architecture principles. I think his experience is an interesting case study from a couple of standpoints – one is that presentation tier/mashup developers obviously need to think about graceful error handling in the UI layer in a new way (not sure if that’s being done generally), as well as logging and outage reporting (highly doubt that’s being done fromt clients as it’s not as easy as server-side). What is the common Saas model for this? Does a mashup developer need to setup his/her own monitors for consumed services? Subscribe to an announcement list? Somehow report from the affected clients?