EdwinStearns.com

WordPress is the right tool for this personal blogging site because it allows me to focus on content without worrying about HTML or formatting. The downside is that there is some security risk because it is dynamic. This is a trade-off to allow readers to post comments.

For the dojo website I want the advantages of quickly editing content that I get from WordPress without the security risks of a dynamic content manager. Currently I have to edit the HTML to make any changes, like up-coming events, dues changes and schedule changes. My first idea was to create makefiles that would build the website from markdown content and sync to the FTP server with a quick command, just like posting on this blog. My knowledge of HTML is low, so I quickly learned that there were many issues that I would have to resolve to get this going. Wouldn’t it be simpler to use existing static content manager software to solve this problem?

My criteria for the content manager was that it would create a static website (no logging in to the server except to transfer the files), Markdown format for content and that the site would look exactly the same as it does now (Tom Carter did a great job on the design and I don’t want to change that now). After some searching, I narrowed down to three options: nanoc, webgen and webby. All three used Markdown and Ruby for code. Ruby is my favorite scripting language (for purely aesthetic reasons), but I almost never have a need to use it in my work, so I liked the idea of using it for something practical.

I started with nanoc, but found that it didn’t handle images. This was a deal breaker because so much of the formatting depended on images; so I moved on to webgen, which never ran correctly on my Macbook Pro (probably because of Snow Leopard). When trying to build a default website, webgen would get caught in an infinite loop. These systems load with the easy to use rubygems interface, but it is time consuming to get each one going and find the problems and I was beginning to feel discouraged.

So I tried Webby. For some reason that I don’t remember, this seemed the least attractive of the options based on their web pages, but I have gotten further with this towards my goal than the others. It uses Markdown and ruby and smoothly handles images. I am still some time from replacing the dojo website with this system because of some weirdness in the formatting that webby wasn’t designed to handle (different pages uses columns differently, no biggie but it would have been easier every page was laid out the same), but I feel that I am on the right path.

When running, I like to use the Android App CardioTrainer on my G1 phone. It keeps track of the distance I’ve run and the time, but what I really find useful is the “voice prompt” feature that uses a synthesized voice every minute that tells me the current distance time and pace of my run. This feature makes it easy to follow the clock so that I can change from running and walking at the right time.

The app also has music integration so that I can listen while I run. This feature works less well, but it seems to be a shortcoming of the phone hardware rather than the app. When the app is running (querying the GPS for my position every second, playing the voice prompts etc.) the music sometimes breaks up. This state will sometimes persist for as long as 20 seconds and is very annoying. It seems that there isn’t enough CPU to do everything at once. This problem exists whether I’m using the apps built in music integration, or playing music in the background. It’s possible that they will make the app efficient with future updates, but there is a limit to what they can accomplish.

In embedded development, there is the problem that after you build the code on your host PC, you have to load onto the target. My normal solution for this is to create an NFS mount to a folder on the host that contains the binaries and the necessary auxiliary files. I was motivated to load the files via scp, but I prefer to automate my development cycle as much as possible. This means calling scp from the makefile, which means calling it without a password. I knew it was possible to set up a system that allowed this, so I turned to Google.

I searched for “scp in scripts”. The first link seemed very authoritative and gave instructions that used ssh-keygen to create a public RSA key to put in the host’s ~\.ssh\authorized_keys file. Possibly because the target is using Dropbear for ssh, these instructions didn’t work and I spent a significant amount of time trying to debug the system.

A co-worker that I had dragged into the problem gave me a different solution that did work. When I asked him where he found his solution, he said “Google”. To my frustration, his link was the first link for him on the search “scp without password”. This illustrates the principle that you should always ask Google for exactly what you want.