Lately, there has been a rush of activity around building native applications for the various mobile devices.  The latest explosion of activity started in 2008 with two events: Apple opened-up the iPhone to 3rd party development by releasing the iPhone SDK,  and Google released Android as open-source software.  In 2010, of course, Apple fanned the flames with the release of the iPad, and Microsoft Windows Phone 7 looks like it will be a strong platform for mobile device custom development.  But even before these events, there had been waves of popularity of mobile development coinciding with the rise of Blackberry and before that, Palm devices.  It even used to be the case that something didn't have to be a phone to be a mobile device.  But now that most mobile devices are network-capable and the bandwidth available to them has expanded dramatically, the question becomes, "Do we need discreet native mobile applications, or can a single web a

From all the time I’ve spent learning design, there are a handful of things I’d hope to remember or re-read if I were to ever get amnesia and have to start all over again.  For new comers and experts alike, I’d like to share a few ideas about design worth thinking about through musings and links to other material that has helped form my opinions (some more relevant than others).

I've been reading up on design patterns lately, particularly those in Core J2EE Patterns. Design patterns are great - they help software architects rely on the collective knowledge and experience gathered from past projects; they also allow designers, developers, and analysts to use a common language.

It occurred to me while flipping through the Core J2EE Patterns that several of them are either outdated or at least their utility has been diminished by advances in JavaEE. (Not to mention that this may mean some of the Core J2EE 'patterns' are too implementation specific and may be better labeled as strategy than pattern).

After seeing a pretty funny blog entry last week on Dart-board Driven Design, I thought I'd finish off a blog post I started on deciding when to use design patterns.

My argument is that the cost of the additional layer of 'pattern' code should be outweighed by the  value the pattern delivers; further, you must evaluate the value when implementing any pattern.