Mini Upgrade

image by 'smee' at Apple InsiderThanks to this tutorial, I was able to upgrade my Mac Mini media server to 3GB of RAM. That allowed me to upgrade it to Mac OS X Lion as well (it only had 1GB before, and Lion requires 2GB). That’s made quite an improvement in file sharing responsiveness. If you recall, even on Snow Leopard, it could take 30 seconds to connect to a server. Initially, I had tried to use the DIMMs left over form my MacBook Pro upgrade (to 8GB), but they were too advanced. Luckily, I had an old white MacBook in the closet with a bad motherboard which happened to have matching DIMMs, so I was able to complete the upgrade.

Pow and WordPress on the same machine

While developing the InnerLightTools application on my local machine, I’m using the Pow web/rack server. It’s a great way to run rails apps locally. At the same time I’m working on WordPress development locally as well, and for that I need Apache. By default Pow runs on port 80, just like Apache, so I couldn’t do both at the same time. Initially I set Apache to run on a different port, but discovered the WordPress Multisite won’t run on ports other than 80 and 443. So, I found the Pow configuration page contained information about setting Pow to run on an alternate port. It’s pretty simple, just add

export POW_DST_PORT=<any port num>

to your ~/.powconfig file and restart. My Pow is finicky, so I often have to reinstall it to get things to work properly. Fortunatley that’s trivial with the Powder gem.

Lion, Rails 3.1 and WordPress Clients

I haven’t gotten much done on Inner Light Tools on the last few months. My day job had taken over all of my free time, at the same time, I was waiting for Rails 3.1 to finish up. I’d begun converting the code over with one of the early Release Candidates, but when I updated my MacBook to Lion, things broke. At the same time I’d tried renaming the Xcode directory, and then make and gcc stopped working. Even when I moved the folder back they wouldn’t work.

Because I couldn’t compile any native code, the upgrade to rails 3.1 final would’t work. I couldn’t get Xcode to reinstall from the App Store either. So I reinstalled it on another machine, and made a copy of the installer before it was finished (when it gets deleted). With that I was able to reinstall, and everything started working again, thankfully.

Now that I had a final version of Rails. I could get on with the code. Over the weekend I spent some time deleting parts of the app. Originally I’d planned to allow users to build customized intake forms, but dealing with all the complexity that brought was driving me nuts, and taking forever to code. So I’ve cut it out, and it’s not just a simple model.

I may go back to that idea in the future, if my users actually want that kind of thing. I’ll ask them first.

Also, I’m trying out WordPress clients, trying to decide between MarsEdit and MacJournal. I’ll let you know which one wins.


I’m disappointed in Drupal. It looked like they were doing great things with the 7.0 upgrade, and I was looking forward to it. I have 7 different sites running Drupal 6 right now. As soon as 7 was release I upgraded this site to it. That process was not as seamless as I would have hoped.

for the 8 months prior to 7.0, it seemed like every plugin author has added a compatibility pledge to their listing, saying that they’d have a working version on the day 7.0 was released. This made me even more eager to jump in. Unfortunately not everyone was onboard.

Prior to the upgrade there was no easy way to test whether your plugin has a 7.0 compatible version available. I could have visited the nodes for ever one of my plugins, but there is no easy way to find links to those pages, even with the module installed. So would have had to go to the drupal site and do a search for every one of the 20 or so modules. And the names are fairly generic, so sometimes it’s hard to find the right plugin, or nodes discussing the plugin flood the results and you have to spend a while digging through to find the right node.

So I just went for it and upgraded, and what a mess it was. half my plugins broke, so I had to install alpha or beta versions of those. If they were available, many times there wasn’t even that. So, I lost a lot of functionality including core things like MetaWeblog API support. For months I’d check on the nodes for those modules, hoping for an update. Few came.

I have a lot of time and knowledge invested in Drupal, but things were handled so poorly that I’ve given up. Usability even went downhill in 7.0, with some setting taking me months to find. This site is now running wordpress.

What a difference! Whereas the Drupal experience is clunky, disorganized and rough, WordPress is a joy to use and install. the UI polish is an order of magnitude greater, and really makes it feel like the developers care about your experience. Plugins actually have ratings, so you can compare them easily. Installation is trivial, and the number of classy professional themes available is staggering.

In short, I’m pissed that I waited so long.

First landing page

My first landing page for Inner Light Tools is up: reiki software. It’s pretty rough, but I want the search engines to get something in there for those keywords. It’s not a very competitive phrase, so I hope I can get to the top ten as easily as I did for ‘alternative health practice management’. Then I’ll rank for two phrases that nobody searches for 🙂

Massage software is next.

Intake forms

I’m building a system whereby each practitioner can customize their intake form. I’ll provide a wide range of sections that can be added/removed and re-ordered. This is obviously a bit of a challenge. I still haven’t figured out how I’ll handle validation, I’ll probably have to write something custom.

Today was a big push in that direction. I build a nice UI with jQuery drag and drop to re-order the modules. I still have to build the adding modules part, and saving the new order to the DB. I’ve laid the groundwork there though, by changing the model relationships. Initially Users had :has_and_belongs_to_many relationships with FormSections. But that didn’t let me save the order in which the FormSections were saved. So I fleshed out the FormSectionsUsers model to be fully fledged with id and order columns, and some indices. Then I changed the relationshop to :has_many, :through.

One thing that’s so easy to miss in the Guide is that you need :has_many definitions for both the target of the association, and for the association model itself. Don’t forget the asterisked lines below (from the Association Guide):

[ruby] class Physician
***has_many :appointments***
has_many :patients, :through =&gt; :appointments

class Appointment
belongs_to :physician
belongs_to :patient

class Patient
***has_many :appointments***
has_many :physicians, :through =&gt; :appointments

New Theme

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

…On Long Passwords

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 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.

In the End

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