humandoing software

I needed to do some magical AJAXy previewing (inline) for an email templating system I’m building that generates both text and HTML versions of an email. For displaying the HTML version of the email inline I was using an iFrame. Using jQuery to do an AJAX post of the template, I then needed to render the response inline, and essentially wanted to just replace the HTML contents of an iFrame with the HTML response I received back from my AJAX jQuery post.

I found this tidbit from Twig’s Tech Tips, which did exactly what I wanted. Using an iFrame like this (no src attribute):

<iframe id="preview-iframe" width="320" height="240"></iframe>

You can use this jQuery call to replace the contents of the iFrame:

$('#preview-iframe').contents().find('html').html(data);

Just a quick thought on the latest from Gruber regarding doing it first, vs. doing it right.

For a bit of context, he states:

Do you include the half-baked stuff, or hold it until it’s fully-baked? Apple wasn’t going to include a front-facing camera until they had software that made it useful in an iPhone-caliber way. HTC is happy to include a front-facing camera and leave its utility (and user experience) in the hands of third-party developers.

And from here – he carries on to state the following:

Android and iPhone fans will read the preceding paragraph very differently. Android fans will read it and say, “Exactly — give us the hardware and let developers figure out what to do with it.” iPhone fans will read it and say, “I can’t wait to get an iPhone 4.”

My first thought, reading the above paragraph wasn’t “I can’t wait to get an iPhone 4″, but rather “Thank you for saving me from having to deal with mediocre implementations of video calling that will no doubt increase my blood pressure and shorten my life. Thank you that I don’t have to give a flying crap what Qik or Fring are. I can’t wait to get an iPhone 4.”

Planning is not just guessing, it’s harmful guessing… 37 Signals has been around for 10 years, you know how long we usually worry about? Two weeks. Sometimes, when it really gets crazy, we worry about two months. We absolutely do not worry about what next year is going to look like.

I’m not always the hugest DHH fan (although, I am a Rails fan ) – but watch the lecture.

1. That can’t happen.
2. That doesn’t happen on my machine.
3. That shouldn’t happen.
4. Why does that happen?
5. Oh, I see.
6. How did that ever work?

This needs to be re-posted on the Interwebs every now and again, especially when you just finish having one of “those” moments.

Here is a handy web tool for checking the validity of JSON. I’ve been generating a lot of funny custom JSON lately, and every now and again I get it wrong.

When jQuery gets ahold of invalid JSON data on a $.getJSON call, it fails silently, which can leave you with a head-scratcher, until you fix your broken JSON data.

The 2010 year has started off with a bang as Kareem and myself begin working on an awesome web booking calendar.

Debugging problems with logrotate (as in, logs not rotating) – this was plenty helpful:

logrotate -d -f /etc/logrotate.conf

After sitting on the code for JarIndexer for about 5 years, I finally got around to throwing it out to the world on GitHub.

I’m hoping a few people who use it decide to take it and run with it – or at least enjoy the open sourced version.

There might be an easier way to do this without escaping the regex to grep, but for my small brain to remember later on – I wanted to grep the output of rake routes and search for two strings (logical OR):

rake routes | grep “\(give\|gift\)”

…then the DNS has propagated, and all is good with the world. Well, maybe not the whole ‘good with the world’ thing, but definitely the DNS has propagated, which means you’re viewing the site on it’s shiny new Linode  VPS running on mod_rails (AKA: Phusion Passenger).

Media Temple was a great host, but something changed over the past several months, and my Capistrano deployments were no longer working. It was less of a headache to get a better host than it was to figure out what actually went wrong, and it’s about time I started bumbling around in happy server deployment land again. It doesn’t hurt that mod_rails drastically reduces the Ibuprofen required in the deployment of Rails apps.

As an aside, it’s been so long since I’ve looked at Apache configs in any depth, that it took me a few minutes to figure out how to use the same VirtualHost config for both humandoing.net and www.humandoing.net. The answer (at least the one I used) was ServerAlias. I’m surprised that this didn’t appear anywhere in the mod_rails docs, but I guess it’s more of an Apache thing than a mod_rails thing.

See my config below:

<VirtualHost ip_goes_here:80>
  ServerName humandoing.net
  ServerAlias www.humandoing.net 
  DocumentRoot /var/www/apps/humandoing/current/public
</VirtualHost>

I’m doing deployment using Vlad instead of Capistrano, but man, the documentation sucks. I think that the problem is almost that it’s too easy to use, but that aside – the documentation still seems uber-lacking.