Navigate/Search

Archive for April, 2007

Web Apps Offline

Friday, April 27th, 2007

A colleague sent me a link to a O’Reilly Radar article in which the author links to a presentation for, and briefly discusses, a framework, Dojo Offline, for allowing web-applications to work, you guessed it, offline. Pretty slick. They gloss over the 800 pound gorilla of sync conflicts more than I would like (as that’s the real difficulty with on/offline apps), but I think that the presentation does a good job of demonstrating the sensible approach Dojo seems to take. Off-line capability for web apps is coming, and we need to ready.

Now this isn’t a new idea, to be sure, and there have been plenty previous attempts at transparently handling content, with an internet connection or without (see an interview with the author of Dojo Offline for some current offerings). But with at least the presentation made available over at the article, it’s becoming clear that this is something of which to take note. With applications like Google Apps and GMail becoming not only more popular, but also more fundamentally necessary for users’ business processes, the expectation that one does not need to be “tethered*” to the internet in order to function. If Dojo Offline and Dojo Storage (or one of the competing frameworks) were integrated with such applications, the pricepoint of Google Apps would become so much more appealing.

I’ve been delving into WordPress plugin development, recently, for some projects at work, and I keep thinking that I would like very much to have this sort of functionality available for WordPress. I know the need exists. It’s somewhat addressed with the email blogging capability of WP. But that just side-steps the issue – it places the work of the proxying into the hands of the user: they need to install or access an email system to create their posts. It’s something of a disjointed solution. Back in my Blogger days, I made use of a Blogger for MS Word plugin, which let me work with Word to create and upload posts. This was nice because I could work offline (and use a better editor, in my opinion, than the editor that was available then).

I have to wonder if there is another alternative to using JavaScript, though, since it’s not too uncommon for users to disable JS entirely, or to use browsers that don’t support it (though I have no numbers to back this up, though). It seems that the offline capabilities of a browser app (as opposed to web app) could be one more point of abuse for developers, breaking Graceful Degradation or Progressive Enhancement. Of course, I suppose that those that will break those ideologies will break ‘em anyway, if we’ve got this extra tool or not. :)

-sean

* Yes, yes, “tethered” was much more appropriate when we were all literally tied to the internet via phone and Ethernet cables, but it still applies. :)

A Stitch in Time…

Saturday, April 21st, 2007

Pre-investment in order to do less later is always worth it.

Several times I’ve had colleagues who have stated to me that, while they would like to spend the time working on these “schoolwork tasks”, but those were “from the classroom, and this is the ‘real world’.” I couldn’t disagree more. “A stitch in time…”, “An ounce of prevention…” and such truisms are all true, especially with regards to software development.

I’ve stated before that I am of the opinion that successful projects take the path of least resistance, as long as it a long-term “least resistance”. Short term solutions are a treacherous road, and should be avoided if possible. (Hmm… Perhaps a better term would be “path of least overall cost”, but that just doesn’t flow as well.) :)

Regarding software development, so many headaches are solved by doing the up front legwork that we learned that we’re supposed to do when writing code. In-code commenting, pre-designing architecture, legible code, and (gasp!) documentation are not just “good ideas” to me; they are requirements of successful software. Remember, not only do we need to deliver applications, we (read, “Developers as a whole”) need to maintain them as well. It is just as important, if not more so, to have maintainable code as it is to have “correct” code. Please, think of the childre– er, the next developers that will maintain your code.

This is true of non-software projects as well – how often have people looked back on what was started, and said “What in the world were we thinking?” when trying to fix something? It’s always worth that time to make sure one can look back and know why a decision was made, so one can always reconsider it with new knowledge.

Similarly, having fail-safes in place to make sure that changes to a project do not break other aspects of its goals are essential. Generally, a project of any appreciable size takes on a living, changing nature, with many of the small details or requirements never being fully documented or considered. Making sure that later changes don’t have far-reaching consequences on inter-linked aspects of a project will save much wailing and gnashing of teeth. In software development (for you coders), I’m sure you recognize that I’m talking about testing, especially automated testing. The fail-safes in place are so essential because they will help you continue to forge ahead with the project in question without needing to look over your shoulder all the time.

But when you do need to look back, knowing how or why things exist they way they are will make diagnosis infinitely easier. When repairing anything, it is always easier to read the manual before diagnosis, as it were, then to reverse-engineer the object (possibly erroneously!). This is where all that up-front work you spent documenting (or at least noting) will pay off.

And when you get to go home at 5 o’clock with minimal hair-pulling or teeth-gnashing, you’ll quite the happier person.