Wednesday, May 28, 2008


So, I was just thinking about microscopic images, and how they're always so much blurrier than illustrations.  I was thinking about how, in videos, you can see various parts of the organism sharply, depending on the focus of the optics... it's just a razor-thin depth of field.

Then I thought: hey, wait, we have HDR photography.  ...Why can't we use this at a microscopic level to increase clarity?

I could even imagine a machine-controlled microscope that produces one image from a composite of multiple images shot at different focal lengths, helping to bring the entire image into maximal focus.

...Of course, I'm sure someone else has already thought of this.

Wednesday, May 21, 2008

Posting Ruby

So, I broke down and did some research on how to post code to blogger so that it doesn't look hideous. It wasn't nearly as simple as I wanted it to be (most notably, it was a serious pain to use cocoa to use the pasteboard for converting text)... so I hacked together a little rails project that handles things for me using web forms. It would be a long post to explain all the details, but I'll cover the basics.

First, sudo gem install syntax. Then create a new rails project and get it up and running. When you've got that, generate a controller called "Convert". The code for the controller should look like this:
class ConvertController < ApplicationController
def ruby
render :action => :ruby
def to_html
require 'syntax/convertors/html'
convertor = Syntax::Convertors::HTML.for_syntax params[:type]
@code = convertor.convert(params[:text]).gsub(/<span class="punct">([^<]*)<([^<]*)</, "<span class=\"punct\">\\1&lt\\2<")
render :action => :to_html

And then you'll need a view for 'ruby.html.erb'.:
<h1>Convert What?</h1>
<% form_tag('/convert/to_html') do %>
<table><tr><td><%= text_area_tag 'text', '', {:cols => 80, :rows => 30} %></td>
<td><%= radio_button_tag 'type', 'ruby', true%>Ruby<br/>
<%= radio_button_tag 'type', 'xml'%>HTML/XML<br/>
<%= submit_tag 'convert to HTML' ><td>tr><table>
<% end %>

...And a basic response form in 'to_html.html.erb':
<h1>The raw HTML:</h1>
<pre><%= text_area_tag('whatever', @code, {:cols => 80, :rows => 30}) %></pre>
<h1>The results:</h1>
<%= @code.gsub(/&amp;/, '&') %>

...You'll also want to set up the CSS for your site, using the CSS from the site where I stole this idea from. Polishing things is an exercise left to the reader... but that should get you started.


So, I was writing a few RSpec tests today, and required Hpricot to look at a few views. This was the code I wrote:
     links.each do |link|
this_taxa_name = nil # scope
img ="img")
if img.nil?
this_taxa_name = link.inner_text # This was the text link
has_image = true # This is the image.
this_taxa_name = img['alt']
taxa_name ||= this_taxa_name
assert_equal taxa_name, this_taxa_name, 'The names for the featured species were inconsistent (image alt/text)'
taxa_link ||= link['href']
assert_equal taxa_link, link['href'], 'The links for the featured species were inconsistent (image/text)'
assert has_image, 'There was no image for the featured species'

...This was all because I was trying NOT to assume that the image always precedes the text for the image. The test ended up being a bit longer than one page, so I asked a co-worker to look at it. His simple suggestion was "it's okay to assume the image comes before the text". By making that assumption, this block of code above becomes:
      assert !(links.nil? or links.length == 0), 'The featured species had no links'
assert_not_nil links[0].at('img'), 'There was no image for the featured species'
assert_equal links[0]['href'], links[1]['href'], 'The links for the featured species were inconsistent (image/text)'
assert_equal links[0].at('img')['alt'], links[1].inner_text, 'The names for the featured species were inconsistent (image
It's very easy to see why assumptions are the #1 problem that developers have. They make life much, MUCH easier.

I suppose that's true of life as well.

Sunday, May 18, 2008

Oh, and when adding methods to core classes...

There's this neat pattern of checking to see if it's there first. I'm not sure if this really saves any cycles (I would imagine a few), but may aid in avoiding collisions, at the very least. For example thus:

unless String.instance_methods.include? "_sp_clean"
class String
def _sp_clean
str = self.clone
str = CGI.escape(str) # Turns spaces into '+' rather than '%20'... we expect that, though
# URI.escape allows [=&], etc... which we don't want.

...Now I hope that formats nicely when this message posts. : \

Built my first gem

...And it was rather easy.  After using the "newgem" gem to create the skeleton, I just followed some bloke's instructions for editing the Rakefile.  Piece of cake.

Just thought I'd mention it.

Thursday, May 15, 2008

Text and HTML in Thunderbird

So, I'm using Thunderbird now.

One of the first pains that I've encountered is that, when replying to email, I get a warning that HTML may be unavailable to the recipient.

To turn this warning off (and select whatever you want as a default), look under Tools > Options > Composition > Send Options.  The rest should be self-explanatory.


Wow, what a blast these past three days have been!  We had a consultant in from MySQL, and I learned hoards of new tricks, tips, and techniques.  Here are a few:
  • You can store images on the filesystem based on their PK, to save having a field with the path.  For example, = 15579, image.path = images/1/5/5/7/9.png (or whatever level of separation you find appropriate).
  • EXT3--though it can be tuned--is not an ideal filesystem for databases.  XFS is much better.  (He didn't give specific reasons, and I don't particularly care to look into it.)
  • QCache_hits should be much higher than QCache_inserts.  (show with "show global status like 'qc%'")  If it's not, you need to hard-code which queries use the cache and which don't.  Global status can also tell you about the number of locks that are occurring, which you may also wish to tweak.
  • query_cache_type values are: 0 = off, 1 = on, 2 = on demand
  • QCache hits are never logged.  That would take more time.  So if you want to really see how often queries are running, you have to turn of caches.
  • 400M is a reasonable limit for query cache.
  • Stop apache from forking: this is what brings so many sites down.  Instead, figure out how many concurrent processes your box can really handle, and then set the number of connections to this limit. If this is exceeded, the OS will queue additional requests, and keep the system from dying.  100 is a reasonable place to start.
  • MyISAM tables are fine if you're read-only (or nearly so): they will be faster.  But InnoDB is much, much faster, since they store the table completely in memory.  Of course, this means you have to have enough memory to fit the damned thing.  ; )  ...And, of course, there are caveats about very large fields (like blobs, texts, and varchars with large average size).  Shrinking your data as much as possible is important with large datasets... even one unused byte becomes a Meg with a million rows!
  • "show innodb status\g" is a tool for checking InnoDB performance.
  • strace shows all the system calls used for a command (linux).  Very cool!  Not sure how I hadn't seen this one before...
  • Sharding is what massive scaling is all about... but that's a topic you'll have to look up on the web, since there's so much to it.  ; )

Tuesday, May 6, 2008

One more Annoyance with Tiger Terminal

...So, when I moved .bashrc to .bash_profile, I lost my PATH environment variable.  (Rather, it was stripped down to next to nothing.)

To fix this, I moved .bash_profile aside, re-ran terminal, ran env to get the old PATH, and pasted that into my .bash_profile where I used to say "$PATH".  Something like this:

export PATH=/sw/bin:/sw/sbin:$GEM_HOME/bin:/opt/local/bin:/usr/local/bin:/opt/local/sbin:/usr/local/mysql/bin:/Users/cpr4cpu/bin:/bin:/sbin:/usr/bin:/usr/sbin:/usr/X11R6/bin

...Pain in the arse, this.

Bash Profile, not BashRC

Another lesson learned:

In Tiger, the Terminal doesn't used .bashrc.  Why?  Couldn't say.

Just move your .bashrc file to .bash_profile

Problem solved.  Lame.  There's more discussion about this on the Mac site, but I didn't really care to dig past the workaround.


I've spent the past couple of days setting up my Mac for Rails development. I'm still running Tiger, which is problematic (to say the least)... I hear that Leopard is all set up correctly, but I'm stuck for the time being.

I finally gave up on Aptana, which was just screwing up left and right.  ...This means that I need to fall back to my old friend, Vim. 

There's a script for calling gvim from a terminal, but I also wanted to change the color scheme on load (because my terminal is dark-on-light and my .vimrc colors are customized for that).  To accomplish this, add to your .gvimrc:

colorscheme desert

(Or whatever other scheme you care for.)

This was surprisingly difficult to find (why?!?), so... I hope you stumbled on this page before too much extra work.  ; )