In hopes that it gives someone else’s eyes a rest, here’s the fix.

1. Run the following commands in a terminal window:

   atsutil databases -removeUser
   atsutil server -shutdown
   atsutil server -ping
   

2. Then restart terminal, and your eyes should thank you.

Source: Restarting you Font Server in OSX

Installing a few rubys

Once you get rvm installed, you only need to run rvm install 1.9.2. That command will download and build the latest version of ruby 1.9.2 from source. If you also work with Phusion’s ruby enterprise edition, you can install it from source by running rvm install ree.

After running those two commands, you will have three versions of ruby installed on your computer, the system version, ruby 1.9.2 and ruby enterprise edition. However, if you run ruby --version you’ll notice that the system version is the one that is getting executed. Here’s what doing so looks like on my Mac running Mac OS X version 10.6.6.

cloudraker:~ mscottford$ ruby --version
ruby 1.8.7 (2009-06-12 patchlevel 174) [universal-darwin10.0]

However, if you first run rvm use 1.9.2, the running ruby --version should give you exactly what you expect. Try switching to ruby enterprise edition with rvm use ree. Again, running ruby --version should confirm that the switch took place correctly. Should you want to return to using your system’s version of ruby, just execute rvm use system.

If you ever need to check which version of rvm is active, you can run rvm current. This will output the name of the ruby that rvm has setup. We’ll discuss a better way to determine which ruby is active a little later. But first, let’s talk about how rvm helps us manage gems for each project.

Working with gemsets

Since just having different versions of ruby is not enough, rvm also gives us the ability to create different sets of gems that are completely isolated from each other. By default each version of ruby that we install gets its own gemset. We also have the ability to create named gemsets.

We create gemsets with the command rvm gemset create gemset_name. This will create a gemset for the currently selected version of ruby. One thing to keep in mind is that creating a gemset does not automatically switch you to that gemset. To do that you’ll need to use the rvm use command, for example rvm use 1.9.2@gemset_name. If you need to figure out which gemset is active, you can run the rvm currrent command. Once again, a better way to keep track of this is on it’s way.

Here’s a longer example that shows how to create and work with gemsets.

$ rvm use 1.8.6
$ rvm gemset create funkyness
'funkyness' gemset created (/Users/mscottford/.rvm/gems/ruby-1.8.6-p399@funkyness).
$ rvm current
ruby-1.8.6-p399
$ rvm use 1.8.6@funkyness
Using /Users/mscottford/.rvm/gems/ruby-1.8.6-p399 with gemset funkyness
$ rvm current
ruby-1.8.6-p399@funkyness
$ rvm use 1.8.6
Using /Users/mscottford/.rvm/gems/ruby-1.8.6-p399
$ rvm current
ruby-1.8.6-p399

Start using .rvmrc, and stop thinking

To make it impossible to forget which of your projects are using which versions of ruby and even then which gemsets, rvm will look for a .rvmrc in each directory that you switch into with the cd command.

Here’s an example.

$ rvm current
system
$ cd funkyness
$ rvm current
ruby-1.8.6-p399@funkyness

Okay. That looks like magic. What’s going on?

To answer that question, let’s take a peek inside of ~/funkyness/.rvmrc.

rvm 1.8.6@funkyness --create

With that one line, rvm will switch to ruby version 1.8.6 and gemset funkyness. It will even create it for you if it does not exist.

Since this feature could potentially be used to trick you into running malicious code on your system, rvm asks you to trust a .rvmrc file the first time that it reads it. You only have to do this once however.

What’s this post about again?

Now that I’ve explained the finer points about using rvm, I can finally start to vent a little.

I have several ruby projects that I’m working on at the moment. Some are for fun, but most are for my paying clients. I only recently started using .rvmrc files, and I’ve yet to create them for all of my projects. This means that for some projects, I don’t really need to think about which version of ruby is getting run, because it is the version that I’ve specified in the .rvmrc file. For other projects, however, I need to remember to run rvm use with the correct version of ruby for that project.

But I’d hate to run rvm use if I don’t need to. And running rvm current all them time seems a little silly. The solution that I’ve come up with is to alter the bash prompt to always let me know the current version of ruby that is in use by rvm.

To get started I used my favorite search engine to see if someone had already tackled this problem. I found one really good example that even introduced some color, however it was also using some git magic to include the current branch on the prompt. A few modifications later, I came up with my own version that just displays the ruby that is in use by rvm, and it does so while looking like it was copied and pasted out of Textmate.

Here’s what it looks like.

:rvm => 'system'
~ $ cd funkyness

:rvm => 'ruby-1.8.6@funkyness'
funkyness $ cd ..

:rvm => 'system'
~ $

I’ve read some recent discussions where the question of CSS unit testing has been raised. Many of these discussions devolved into a debate about whether or not CSS was “code”. A lot of these commentators complained about CSS not being a Turing complete language. I’d like to claim that this debate, with respect to unit testing, is a giant waste of time. Whether or not CSS is Turing complete has nothing to do with the reasons why one would like to write tests against CSS.

But to avoid that debate, I’ll avoid describing CSS as code. Instead I’d to propose that CSS is actually a domain specific language that is used to control the the way a browser works. For simplicity, let’s think of CSS as a configuration syntax.

CSS is a language that affects the way that HTML documents are displayed by web browsers. As the use of CSS has increased as the primary method for altering the way information is displayed, HTML documents have become more and more semantic. The additional tags that have been added to HTML 5 have made the documents even more semantic.

This means that HTML is basically just data that is displayed by a web browser. Web browsers have a default way of presenting this information. CSS is used to alter this default presentation, which means that CSS is simply a method for configuring the workings of a browser. Since CSS has an effect on the execution of a program, the web browser in this case, that is used for displaying information, it is important to ensure that the configuration is accurate for the task at hand.

This is where testing comes in. Testing should be employed any time that we want to ensure the correct operation of an application.

So can we stop the bitching and get started on a decent method for testing CSS already? I’ve got some ideas, but I’ll have to write about them later, once I’ve had a chance to work up some experiments.

1. Keep words and sentences short.
Big words do not make you sound smart. (I actually had to re-write that sentence. Originally it said, “Big words make you sound pretentious.” I have to keep even myself in check.) Long sentences make you seem boring. Readers, especially savvy web-oriented ones, don’t actually read — they scan. Short sentences keep these scanners more engaged, which leads to more sales. I try to keep most of my sentences to one thought, or clause. Sometimes two. More that that, and I try to break it up into separate sentences. Another way to put this idea is, “write like you talk.”

2. Use contractions.
When we’re talking casually, we use contractions — those “shortcut” words like can’t, won’t, shouldn’t, etc. We say – “I’d love to join you, but I can’t. Maybe next time, when I don’t have a conflict.”  In conversation, we’ll use the non-contracted form when we need to clarify or make a point. For example, “Joe, for the last time, I will not go on a date with you. Please, do not ask me again.” Using contractions instantly lightens the tone of your communications, and (you guessed it) makes your readers feel more engaged with your content.

3. Choose the “sparkle” word.
Which has more personality? “We’re happy to announce…” or “We’re thrilled to announce…” They essentially mean the same thing, but “thrilled” jumps out just a little more because it’s more exact. Happy is generic. It’s probably the first word you’ll reach for. Stretching just a little bit for that vibrant word can make your copy sing.

4. Write in the present tense, active voice, second person.
In non-academic terms, this means – avoid the words “have” or “been” and use the word “you”. Writing in this style is one of the most powerful ways to connect with your reader. It puts them in the here and now. It makes it feel like you’re having a conversation with them through the screen. Compare, for example, these two sentences: “We have enjoyed working with wonderful clients like you.” Versus, “You are a wonderful client. Thank you for your business. It makes ours more fun.” See the difference?

5. Know which (few) grammar rules you can break.
On occasion, I’ll start a sentence with “and”. I sometimes end with a preposition, too. That’s because these grammar rules help facilitate the conversational style. But there are some rules that when broken, make you look silly, or stupid, or ignorant. Here’s just a small sampling.

• Your (you own it) vs. You’re (you are)
• There (not here) vs. Their (it belongs to them) vs. They’re (they are)
• Assure (give support) vs. Insure (to buy or sell insurance)
• Affect (verb) vs. Effect (noun – can you put “the” in front of it?)
• “A lot” is two words.

There are plenty more, and feel free to vent in the comments below. To keep your writing neat and tidy, try typing your opposing words in a search engine with “vs” between them. You can also check out The Grammar Girl.

6. Accessorize with styles.
Not to sound like your high-school English teacher, but rhetorical styles such as alliteration, metaphor, similes, rhyme, and repetition are marks of great writing. So use them. A word of caution though; too much of any of these styles, and you can easily swing to the other side of the personality pendulum (the one where you sound like an amateur and we don’t want that). It’s best to think of these styles like an accessory — add enough to accentuate your content, but not too much where you overwhelm the message.

7. Read out loud before you publish.
And by “out loud”, I don’t mean “really loud and slow but still in my head”. It means with your voice, at a natural volume. In addition to catching typos, this form of editing is perfect for making sure your content is conversational. Does it sound natural? If there’s a sentence that just doesn’t flow, work with it until it sounds right. Then, give your content to someone who hasn’t read it yet. Ask them to read it out loud. Then, massage any phrases that tripped them up.

With these simple tweaks, you can transform writing that’s bland and impersonal, into content that brings your readers closer to your brand. These are great tips for all sorts of business communications in both print and web. Have a question about how to implement these styles? Have a story about how you turned your copy around? Want to vent about your grammar pet peeves? Put it in the comment below.

Thanks, and happy writing!

Through the Rackspace Apps control panel, I can change all of the DNS entries for any of the domains that they are hosting. To create a subdomain, all I have to do is create an A record entry for “example” that points to my home ip address. I used whatismyip.org to look that up. Clicked “save”, and then the address started resolving right away. Perfect. Well, at least until my ISP hands out a different ip address.

What I needed was a programmatic way to detect that my ip address has changed and then update the A record entry for example.vaderpi.com with the new ip address.

I dug through the Rackspace Apps API documentation looking for a published way to do this, but I was unable to find one. Then I realized that I could just treat the control panel website as an API by driving it with a headless browser, like HtmlUnit.

There are several ruby gems that provide the ability to drive headless browsers. I took a quick look at celerity, mechanize, steam, and webdriver. I settled in on using steam, because it seemed like it had the fewest number of layers between it and the headless browser. I had also never used it before, and wanted to get a feel for how well it worked.

I have posted the resulting script as a github gist. Take a peek. Comments and forks are welcome. Note that all domain names, user names, and passwords have been replaced with made up examples.

As for running the script, I set up an @hourly entry in cron. The script only contacts the Rackspace Apps control panel if it detects an ip address change, so the risk of accidentally hammering their web server with this, should be low. (I point that out in case any of my old coworkers stumbles across this. )

The current implementation can only update an existing DNS entry, but it should not be too hard to extend it to support creating additional DNS entries. Anyone that goes to implement this should make sure to correctly handle clicking the add link if there are not any empty rows in the entry table.

In addition to supporting creating new entries, there are a few improvements that I would like to make to this script. (1) I’d like to have an external service resolve the domain. This is going to become critical, because I want my the domain to resolve to the private ip address for devices that are on the private network. (2) I’d like to not rely on whatismyip.org.

I’m thinking of writing a small web service that I can install on my server that will address both of these. The service will be able to do DNS resolution, and it will be able to detect the public ip address of the caller.

Monkey patch Pathname for Windows paths

Since I am using the Pathname class to build paths in my examples, I need to give you the monkey patch that I use to make Pathname correctly display win32 paths.

require 'pathname'
class Pathname
  alias_method  riginal_to_s, :to_s
  def to_s
    original_to_s.gsub('/', '\')
  end
end

Visual Studio command line environment

Running command line Visual Studio tools requires having certain environment variables loaded. This can be done by running vsvars32.bat directly or by launching a Visual Studio command prompt from the start menu. This is something that I always forget to do; my terminal windows spring into life by typing cmd in the run box. So, I wanted to write a task to ensure that the environment was properly set up.

I am working with Visual Studio 2005. If you want to use the Visual Studio 2008 tools then you will need to adjust the vsvars32_bat variable accordingly.

vsvars32_bat = Pathname.new(
  "c:\program files\") +
  "microsoft visual studio 8" +
  "common7\tools\vsvars32.bat"
task :vsvars do
  if ENV["VSINSTALLDIR"].nil?
    `"#{vsvars32_bat}" && set`.each do |line|
      if line =~ /(w+)=(.+)/
        ENV[$1] = $2
      end
    end
  end
  raise "Eek!" if ENV["VSINSTALLDIR"].nil?
end

This code is the product of about 30 minutes of googling. I eventually found this trick in the shoes rakefile[1].

Now any task that needs to call a Visual Studio command line tool just needs to declare vsvars as a prerequisite, like so.

task :csc => [:vsvars] do
  sh "csc test.cs"
end

Building with msbuild

This is actually pretty easy once we have the environment set up correctly. Just create a task that calls msbuild from a sh call.

namespace :build do
  desc "Build the core project"
  task :core => [:vsvars] do
    sh "msbuild #{core_solution_path}"
  end
end

Controlling Cassini (or webdev.webserver)

There is a lot going on here, so let me first overwhelm you with the code, and then explain what it is doing.

def wait_until_site_loaded
  puts "Please be patient. Waiting for site to respond...."
  site_loaded = false
  until site_loaded
    site_loaded = system
      "curl -L -I -f http://localhost:2088/Default.aspx > NUL 2>&1"
  end
  puts "done."
end

namespace :web do
  desc "Start the local web server"
  task :start => [:vsvars] do
    Thread.new do
      sh "webdev.webserver /path:#{web_root_path} /port:2088 /vpath:/"
    end    

    wait_until_site_loaded
  end

  desc "Stop the local web server"
  task :stop => [:vsvars] do
    `taskkill /im webdev.webserver.exe > NUL 2>&1`
  end

  desc "Restart the local web server"
  task :restart => [:vsvars, :stop, :start]
end

Before the code block above will work, you will need to create a web_root_path variable that points to the absolute path of your website. Relative paths will not work.

The web:start task will start the web server. If an instance is already running at the specified port, then you will get an error message in the form of a dialog box. I wish I knew how to make it fail silently. (I also wish I knew how to prevent it from displaying an annoying balloon notification.)

After starting the web server, the web:start calls out to curl to make sure that the site is responding to get requests. I have curl installed as a result of installing cygwin. There are other ways to get curl, but you will need to make sure your path points at it’s location to use the code above without modifications. curl is pretty chatty, so I have silenced it by routing its standard out and standard error streams to NUL.

The web:stop task will kill all instances of Cassini. This might be annoying if you have more than one instance running. If that is the case, then you will need to write in some form of accounting for the process id of the web server process, or develop a way to figure out which process id owns the port you want. Once you know the specific pid, you can call taskkill /pid and pass it the pid of the process you want to kill.

The web:restart task will call web:stop task followed by web:start task.

One more thing: display available tasks from default task

Note: This recipe does not apply to just Windows development. It will work on any platform.

You can get a list of documented tasks by calling rake -T, but I always forget to do that. I usually just call rake when I want to know what it does. So I created a :default task that displays the same task list that you get when you call rake -T.

task :default do |task|
  puts "You must specifiy a task. Available tasks are listed below:"
  task.application.options.show_task_pattern = /.*/
  task.application.display_tasks_and_comments
end

That’s it. I hope you found these recipes helpful. Happy coding!

[1]: This is way off topic, so I stuck it in a footnote. I know it’s old news, but the way _why, the creator of shoes, committed Internet suicide really irritates me. There were a lot of people benefiting from his contributions to the ruby world, and then one day he just decides to take his toys and go home. He could have bowed out graciously, explaining that he had moved on, but he instead chose identity death. His works remain in archived form, but I am not sure if there is still any energy behind them.

Benifit-driven conversational copy gets you noticed.

10 Reasons why it works:

1. The first word. You. Not me, I, we or any other form of the first person. You. It grabs the reader’s attention and makes your message relevant.
2. Conversational tone. “Here’s the deal” is a great opening line. It closes the gap between the writer and reader. It makes your reader feel like they’re face-to-face, and opens an emotional bond. And in advertising, that’s a powerful thing.
3. Clear benefits. Your reader wants to know, “What’s in it for me”. Give them clear and meaningful examples. Andy does a great job here with, “You will become a rock star with badass contacts. We will find you a job when you graduate.”
4. Name dropping. Works every time. If you have the clout and the contacts, make it known.
5. Edgy. Yes, this ad uses words like “shitwork” and “badass”. But it works here because of the audience. It makes your ad stand out amid a sea of corporate babble. Just make sure that you have the corporate culture to pull it off.
6. Authentic. There’s no guessing that this job will require a lot of effort and work. In fact, they come out and say “You will be exhausted.” But transparency and honesty about the job (especially early in the process) just make you more credible.
7. Keywords instead of tasks. “Blogging, Youtube, Social Media, Viral, Word of Mouth…” describe what the job is about without saying what the employee will be doing on a day-to-day basis. This helps ensure that qualified candidates won’t self-select out because they perceive they’re under qualified.
8. Short & Simple. At just over 100 words, this ad packs punch. In just a glance and a quick scan, you clearly understand what Andy’s looking for and whether or not it’s a good fit for you. No need to drone on and on. We’re all too busy to read useless information.
9. Written for the audience. This ad might not be the best fit if you were trying to find a more senior position, but for an intern, the edgy and conversational tone is perfect. This is how 19 year olds speak. Write how you (and your audience) speak.
10. Clear call to action. “How to apply: blow my mind” (love this!) followed by three websites where you can learn more. Clear next steps are critical for increased response.

What are your thoughts? Is this an effective Wanted Ad? Or did it cross the line? Would you apply? Would you pass it on?

To your success,

Andrea

The application that I am working with performs a lot of client-side DOM manipulation. This can create instances where my script was asking Watir to perform operations on DOM objects that didn’t exist. To defend against that, every time that I called click or set or select on various DOM objects, I wrote two additional statements. One to make sure the browser had finished whatever it was working on, and one to make sure that the element I was about to interact with actually existed.

The code looked something like this.

  @browser = Watir::Browser.new
  @browser.goto("http://localhost")

  @browser.wait
  Watir::Waiter.wait_until { @browser.text_field(:name, /UserName/).exists? }
  @browser.text_field(:name, /UserName/).set("Admin")

  @browser.wait
  Watir::Waiter.wait_until { @browser.text_field(:name, /Password/).exists? }
  @browser.text_field(:name, /Password/).set("Password")

  @browser.wait
  Watir::Waiter.wait_until { @browser.button(:name, /Submit/).exists? }
  @browser.button(:name, /Submit/).click

While that works, I got really sick of having to re-type the selector for the DOM element that I wanted to muck with. What I wanted to do was write code that looked something like this.

  @browser = Watir::Browser.new
  @browser.goto("http://localhost")

  @browser.text_field(:name, /UserName/).wait_to_set("Admin")
  @browser.text_field(:name, /Password/).wait_to_set("Password")
  @browser.button(:name, /Submit/).wait_to_click

Wow. That is much more concise and easier to understand. Even a non-programmer can understand what is happening now.

To make this code actually work, I decided to write a quick monkey patch that adds a “wait_to_” alternative for every method that can be called on input elements and links. These methods call @browser.wait, ask Watir::Waiter to wait for the element to exist, and then call the requested method.

I called my monkey patch Watir Wait. (Get it? I crack myself up! ) Take a peek and let me know what you think. If I get enough positive feedback, I’ll rework this into a proper patch and submit it to the Watir team for inclusion.

Enjoy!

This version only works with Oracle databases, but it should not be too difficult to rework this to talk to database management system that you are mucking with.

Requirements: ruby 1.8.7 or later, ruby-oci8 version 2.0 (if on Windows, make sure you download the binary gem from rubyforge instead of trying to do gem install ruby-oci8)

Enjoy!