Over the weekend, I re-created the theme for this blog. My goal was to jettison the old base theme that I’d used to create the previous theme, because it was never quite complete, and the underlying theme code was buggy. You may have seen some errors here from time to time.

I wanted to go super-modern when I did this, so I selected two candidates, AdaptiveTheme, and Zentropy. I was drawn to Adaptive because they prominently display HTML5 compatability, and I was interested in Zentropy because it incorporates HTML5 Boilerplate.

I love the idea of HTML5 Boilerplate, and I’m going to incorporate it into my alternative health management application, Inner Light Tools.

I ended up selecting AdaptiveTheme because it’s built for easy sub-themeing. I prefer building as a subtheme simply because my code and their code is separated, and I can update the base theme as needed for bug fixes.

Deploying the new theme turned out to be a pin in the ass, on Drupal 6, because it had built it using the D7 that I have installed locally. So I bit the bullet and upgraded this installation to Drupal 7 Friday night. It was pretty smooth for an upgrade that big. I’m still learning my way around D7, so some things are still a bit wonky. But it’s a massive improvement, so I’m glad it’s done now.

Bugger, WYSIWYG editing is still broken for me, it just posts empty content. I had to go back and disable it, then repost this

I like to think I’m fairly security conscious. I have a different password for most of the sites I use. I track them all using Passpack.com. I use it to auto-generate complex passwords whenever I create a new login.

I also use CreditKeeper, which gives me a monthly look at my credit score from all three angencies. Yesterday, I decided to improve the security of my password there. I discovered the following requirements on their password field: length 6-10, only letters and numbers.

That’s unbelievably crappy. Kinda as bad as you can get. They recommend not using dictionary words, but I’ll bet you $100 they don’t check that when you submit.

So, I wrote them the following message:

The extra password that you’ve added to the login system is a fine security improvement. However, as the one site on the internet which contains THE MOST concentrated collection of my financial data, I find it galling that you limit my main password to 10 letters and numbers. That’s a pitiful level of security. I would really like to use a password like this: R

But no, your system is actively preventing me from using a secure password. Thanks.

As expected, I go a non-answer back from them, basically blowing me off.

Time to go looking for another tri-bureau credit report that
a) doesn’t suck
b) is marginally readable
c) doesn’t cost a colossal amount
d) doesn’t run on a VAX in the basement
e) understands how to handle a password

I fear the chance of that is about 0.01%, Just wading through the spam when I do the search is going to be an nightmare.

I’m done.

I’ve made good improvements in the look of the ‘day view’ calendar stuff, though it still needs work before I’ll show it to you. I learned a bit about ruby’s date handling and rails’ i18n in the process.

I also finished the mailchimp templates, which look decent now, though they could use a polish at some point.

Overall, I can call this codeathon a success. I’ve made a significant improvement in the functionality of the app. I’ve now got a few roads I can travel to really fill out the features that I’ve build this weekend. I like having starting places, it makes deciding what to do next easier.

One of the techniques I’ve used to fight through this weekend is to focus on the list I’ve prepared, and not get pulled off into coding cul-de-sacs. While all of the work in said cul-de-sac needs to be done, it doesn’t need to be done now.

The other thing I’ve had to do is give up on nuanced implementations – there are a few places where I wished to build modules that handled all the special cases and ambiguities that I know are there. But I had to keep telling myself that working code is what I’m after, and that it’s easier to build future code on a working base than to try and get the complex case right the first time. So I build the näive case and live to fight another day.

• appointment model
• appointment controller
• appointment view for user, with basic CSS
• expand user registration to handle business name
• seed data for a few users/appointments/events
• subdomain handling in dev, and on server
• appointment view for anonymous patient
• appointment list for next two days on Center page
• super-simple mailchimp template
• mailchimp setup for confirmation email

I just realized that adding Patient login is going to be a very complex change, because now both Practitioners and Patients can be logged in, and I’ll need to heavily differentiate between their experiences.

So, I’m canceling those two items on my list and moving on to the mailchimp changes.

I thought there was a bug in Clearance, because I didn’t see the password change in the DB. Of course it wasn’t changing because I was setting it to the same thing every time. Ug. I spent some quality time with the Clearence code in the debugger though.

I’m calling it a night though, my neck is killing me.

For tomorrow:

• patient registration
• logged in patient appointment scheduling
• super-simple mailchimp template
• mailchimp setup for confirmation email