Dev::Blog

I spent far too much of this morning futzing about trying to get Typo working in a DreamHost account (no, it’s not public yet). This post turned out to be the key to getting everyting going.

While Typo is pretty sweet, I’m not sure if I’ll be able to actually use it with DH on a shared plan - I already get regular messages saying I blew the CPU limit, and right now I’ve got 5 instances of dispatch.fcgi that’ve sucked back 3 seconds of power each. Unfortunately, while DH has been great, and I still heartily recommend them for smaller sites (no, this blog isn’t the “problem”), they won’t have any dedicated servers available until they migrate their data centre.

Of course, I do have a static IP at home… While I wouldn’t want to run anything mission critical¹ on it, a home server might be just the ticket for lower-traffic sites and experiments. Now if I could just get FastCGI working on Tiger…

I’m visiting family this week, which has a real stop-and-go rhythm for getting anything done, which means it’s a good time to do “shallow” tasks like surveying a lot of tech from 10,000 feet.

I got Ruby installed on the ThinkPad¹ - the one-click 1.82 was a lot easier than the many-click 1.84 version, and now it’s got me thinking about how I can use it online (more on that later, I’m sure). Dreamhost has Rails support now, but it’s pretty simple to do straight CGI stuff too:


#!/usr/bin/env ruby
puts "Content-Type: text/html\r\n\r\n"
puts "hello world"


The trick is to name the file with a .cgi extension - DH’s Apache doesn’t have support built in for .rb files

1. (and technically on Ubuntu, but that was installed as a Virtual PC and really really really doesn’t seem to like when the box goes to sleep)

OK, WordPress has been updated, which will hopefully fix ecto’s problems with the WP RPC responses - the last post gave an “invalid XML response” error, but later showed up online… Testing again…

Don’t mind me, just testing out ecto before I write something meaningful and then lose it to a config error…

As part of my ongoing “stop coding like it’s 1999″ regime, I managed to think my way out of some code in the following scenario:

My business object returns a phone number, but it happens to be a raw number, i.e. there’s no formatting: (416) 967-1111 comes back as 4169671111. I’ve got a repeater control in ASP.NET, and I want to pretty it up.

In the past, I’d:

1. Code a new property into the business object to give me a formatted string.
2. Add an ItemDataBound event handler to the repeater, which calls FindControl and fills in the value all pretty-like.
3. Ignore the issue and hope nobody notices.

The new and improved Luke does this in his <ItemTemplate> node:

<%# String.Format(
   ”{0:(###) ###-####},
   Convert.ToInt64(
      DataBinder.Eval(Container.DataItem, “PhoneNumber”)))
%>

Not the prettiest thing in the world, but (after some thinking) the easiest, and it actually puts the presentation details at the right layer.

If I’m not careful, I might actually become productive.

Pop quiz: is there a cleaner way to do this?

Converting string to enumeration value:

MyEnum bar = (MyEnum)Enum.Parse(typeof(MyEnum), foobar);

It’s one of those things that makes sense, and you should have just tried it from the start, but for some reason you thought making converter functions would be the way to go. Much time saved now. Yum.