Month: <span>April 2012</span>

There are a million to-do list applications out there, both rich client and web-based. I never found one that did everything I wanted it to, which led me to consider writing my own. But then I discovered Todoist and now life is so very good.

Todoist is a web app that gives you a standard list of projects and tasks. Projects can be color-coded, and tasks can have a priority, labels, notes, a due date, etc. Both can be reordered manually or in the case of tasks by priority. You can further query by label or due date, and move tasks easily between projects. The killer feature for me was you can create subtasks below a main task, which show as indented and can be marked as completed individually while keeping the main task active.

They decided to use very a Gmail-like approach to the user interface. Clicking on one of the gear icons next to each project and task activates a context menu similar to the ones in Gmail. It’s fairly minimalist in the overall layout of the page, making it feel very snappy. Plus it has a bunch of keyboard shortcuts and there is not only an iOS app but a Firefox extension for it as well.

They offer a base set of features for free, or you can get the premium version for $3 a month or $24 for a year, which gives you the advanced query capabilities and some other stuff. It was well worth it.

Recently I was trolling through my collection of lesser-read developer blogs when I came across a September, 2010 blog post from James Senior on jQuery templates, and from there to this one by Stephen Walther. The big news at the time was that Microsoft was going to start contributing code to the jQuery project.

One their first projects was a templating plugin. The idea is you can embed a chunk of markup in a page that contains placeholders for data. Then you call the plugin, pass it some data, and it merges everything into the template, producing markup that is ready for rendering. It looked like just the kind of thing I’d want to start using in production, today. Turns out that would have been a bad idea.

After I downloaded the code and some samples, I surfed around a bit more on the subject and learned that they are no longer actively maintaining the jQuery template plugin. They have decided to go in a new direction. Which is fine, but woe are the people who decided to invest heavily in the plugin during those first few months and are now stuck with a dead-end tool.

The rate of change of web technologies and tools is getting scary fast, and it makes me subconsciously shy away from the latest new stuff because it could all be replaced in 6 months. That might not be the best approach for a professional developer to take, but neither is having such instability in the LOB applications you have to write and maintain.

Over the last couple of years there’s been a lot of debate over how web authentication should work. On the one hand you have traditional web sites where you have to register before you can use them, which involve selecting a user name and password, and then you have recent open standards for authentication like OpenID that allow you to authenticate using a common, predefined set of credentials.

The OpenID approach never really excited me like some others. I have never had a problem with multiple web site accounts, since I have a scheme for selecting user names and passwords that seems to work fairly well. The problem is for some sites it’s not feasible to outsource the authentication to a third party provider. Things like the site for managing your retirement account, or your bank’s web site. Unfortunately the biggest issue I keep seeing with these types of sites is most of them have very strange, very bad password requirements.

Case in point: forcing you to select a password that is no more than 8 characters, or cannot contain non-alphanumerics. That’s just insane. The best way to create a strong password is to make it long and include a variety of characters types (letters, numbers, symbols, etc). I find it hard to believe these institutions are so strapped for space on their database server/mainframe that they can’t afford a few more characters per password. Likewise, what modern RDBMS doesn’t support the standard non-alphas that people tend to use?

It boggles the mind.