Software Design
iConcertCal
Feb 8th
iConcertCal is an iTunes plugin that scans your library and produces a list of upcoming concerts that you may be interested in. It attempts to detect your city from your IP address, but that can be overridden, and the calendar itself is provided as an iTunes visualiser. The iConcertCal installer has been sitting on my desktop for a few days now, awaiting a chance to be used, so it was finally time to give it a whirl.
For what it is, it’s a pretty neat implementation, though it could definitely do with some more UI niceties, such as using native text widgets so double-clicking on the city name will highlight it (I had to use the delete key to remove the default city name and replace it), and a more attractive default view. I also found the default set of dates a little disappointing, given that I know that there are more shows listed at last.fm and upcoming.org, both of which are using hCalendar and so are easy to scrape.
Indexing my small local library was quick, so there’s none of the delay that put me off after my first experience using MOG, but it still falls into the trap that system had of presuming that I’ll be getting all my music from a local library. We use one central iTunes library at home and most listening is over the network, and I know many other people whose primary listening is over an office or campus network. It is possible to feed in a list of other artists, but having to do that manually is likely to prove frustrating as tastes develop.
But what I’m really not sure about is whether iTunes is the place for this information. Personally I’d much rather have this data in my calendar software than hidden away in an itunes visualiser, particularly as I usually want access to the library browser when I have the iTunes window open. In my calendar software I can quickly see how concert dates fit with other events, and sync the data to my phone so I have the information even on those rare occasions when my laptop stays at home. Apparently calendar integration is in the works but it’s a feature I’d like to have seen in the 1.0 release.
As the plugin is lightweight I’ll be leaving it installed, but without a number of additions I can’t see myself switching to this view all that regularly.
PHP5 Objects, Patterns, and Practice
Jul 13th
Demian Turner’s review reminded me that I’ve been meaning to write a recommendation for Matt Zandstra’s “PHP 5 Objects, Patterns, and Practice” for a few weeks now.
While many of the ‘design patterns’ books I’ve read have been able to impart their core concepts, none has really worked for me in the way Matt’s did. In part that’s because it is the first one I’ve read that’s exclusively PHP-focussed. While I enjoy python more than PHP, PHP tends to be the language I default to due to its familiarity. Matt draws from the example of other languages, but clearly identifies what marks PHP out as a language and applies his techniques appropriately.
Most similar texts to “Objects, Patterns, and Practice” have a tendency to be overly theoretical. In most areas I enjoy getting to grips with theory, so I understand well the tendency to disappear into the logical details while missing the practical, but with something I use on a practical level with such regularity I don’t want to be left with too many “ok, but how do I interface that technique with my web application” questions. I often asked that question as I read this book, but usually found that the next page addressed just that question.
For those who are already regular users of PHP5′s OO facilities, the first few chapters can be skipped over quickly and this book will not come as a revelation, but it is a solid overview and I’ve found myself writing cleaner code since reading it. For those newer to OO (but already comfortable with PHP) this may well be a good introduction to that other paradigm.
Musings on Application Structure
Apr 22nd
Among other things, I’m currently working on a relatively large CMS/membership site. At the project’s initiation I decided to steer clear of off-the-shelf solutions, partly because I wanted to take myself through the learning curve that the project was sure to involve, partly because none of the CMS or framework options I looked at really appealed to me, and partly because it seemed as though the customisations required to manage this dataset would take nearly as much time as a from-scratch solution.
So far, the development has gone pretty smoothly, but for the past couple of days I’ve been revisiting a few early design decisions with the hope of making the site more flexible. Since google has yet to provide much of use when it comes to this aspect of PHP and Design Patterns, I’m going to try and document my thinking here.
This is by far the largest project I’ve undertaken since developing an awareness of MVC and other design patterns, and I’ve been trying to toe the fine-line of being informed but not defined by them. The largest challenge so far seems to have come as I try to loosen the ties between the layers.
I want to make it easier to add alternative representations of various resources. In some cases, that means atom feeds, in others it may mean FOAF or other RDF representations, and right now it means reusing View classes within the management system. I’ve spent most of the morning reworking my Dispatcher/Controller, and building some sample classes to work with it, and what I have at present is:
- Dispatcher uses switch statement to call Controller which builds a model. There are a number of generic model classes, as well as a few specific-use ones
- Dispatcher queries request to see if we’re asking for a particular representation, defaulting to XHTML
- Dispatcher calls a factory to retrieve a View object, passing the type and a reference to the model
- Factory first checks for generic model types and then for specifics, and returns an appropriate View
- Dispatcher asks View to produce the output
This is largely achieving the required result, but it’s relying on several large ‘switch’ statements. There’s one in the dispatcher to choose a Controller/Model, there’s one to check the request type, and there’s one to select the appropriate View. I’m trying to work out whether there’s a good way to combine some of that logic, and thereby make it easier to add new Views and new actions.
When it comes to location-awareness, my hunch is that I’d be best off doing some parsing of the referer and the request_uri to work out where we are, and who called us, and then allowing each View to apply its own logic to decide on a template to show and a place to return the user to. Here, I need to work out how best to do that while keeping the system as portable as possible and ensuring code-reuse.