Archive for the ‘Programming’ Category

Static content managers

Monday, January 25th, 2010

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.

Macbook Pro

Wednesday, November 25th, 2009

I started a new job and with it I have bought a 15″ Macbook Pro. This is my first Mac and there have been some difficulties getting going with it. The main problem is that there is a lot of muscle memory that is unusable with the keyboard. Many things that I used to do with the control key are mapped to the command key, but not all. The control and alt (or option) keys are not where I’m used to which causes considerable problems in emacs, my favorite programming tool. My solution is to follow the advice I have read many times and change the key mapping so that caps lock is control and control is caps lock. This never made sense to me before because I used the right control key when typing a letter with my left hand and vice versa, the way I was taught to use the shift key. On my Macbook, there is only the left control key, so pressing C-x (a common combination for emacs) felt awkward. Using the caps lock as the control key makes this much easier. The problem now is that I have to think when doing common actions in emacs. This reminds me of the experience start to use emacs for all my programming work. It took about 2 weeks before I felt comfortable. This is better than my experience with vi where I never felt comfortable.

CardioTrainer

Saturday, August 22nd, 2009

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.

SCP without passwords

Wednesday, June 10th, 2009

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.