It was inspiring to meet Matz, the creator of the Ruby language, and other Japanese Rubyists at last month’s RubyConf. Matz kindly recorded various phrases about Ruby in Japanese . Since then I’ve been working on learning katakana as an easy intro (perhaps) to the Japanese language.

For those who are unfamiliar with Japanese, katakana is one of two phonetic scripts used in Japanese writing, along with Kanji which is the pictographic script used for the majority of Japanese words. Katakana is used mostly for words which have their roots in foreign languages, so it is naturally used for many words having to do with software development. I asked a Japanese Rubyist why is the word for “Ruby” (the programming language) not a Japanese word — even when speaking and writing Japanese the word for Ruby is “Ruby.” She replied that if they used the Japanese word, it would be indistinguishable from the word for the jewel. They can easily google for “Ruby” and find Ruby language references in Japanese text. The Japanese effectively extend their language by adopting foreign-language words for new concepts and inventions, and end up making the language more expressive by creating a larger vocabulary.

Despite the fact that many things that I might want to say as a software developer find their origins in English words, without hearing them first in isolation I would probably not understand them if I heard them. So, in addition to learning from the excellent book All About Katakana, I am also developing a list of geek words that are written in Katakana.

I’ve noticed that most of the tweets I see from Japanese Rubyists are in katakana and I wonder if I learn to read this phonetic text whether I might actually understand them now and then or perhaps the twitter stream is yet another dialect.

Below is my short list of geek vocabulary words that I am learning now (with some mightyverse links if you want to hear them). Once I get a little farther along in my studies, I hope to get my Japanese friend Iku to record more words for me, so please comment with your favorite katakana words (or ones you would like to know if you are an English speaker and I’ll add them to my translate wish list).

テスト
te su to
test

フレーム
fu rei mu
frame-

ワーク
wa ku
work

オブジェクト　　
o bu je ku to

ドット
do tsu to
(dotto)

メソッド
me so tsu do
(mesoddo)

object.method

ハッシュ
ha shu

ロケット
ro ke tto

hashrocket

テレビ
te re bi
television
(it’s for television)

There’s a nice Railscast introduction to rake for Rails, which goes into a number of other important details that aren’t covered in this post. Below is a little tutorial of creating a Rails rake task and getting it to run remotely on heroku.

Introduction to Rake

In lib/tasks, create a file called greet.rake

task :greet do
   puts "Hello world"
end

By naming the task .rake and putting it in this special place rails will automatically pick it up and make it available to you. You can see it listed if you type: rake -T on the command line. To run it:

rake greet

which will print “Hello world”

to run one task before another, specify a dependency like this (multiple tasks may be specified in the same file):

task :ask => :greet do
   puts "How are you?"
end

Writing a Practical Rake Task

Now for the task at hand, I’m going to create a rake task which creates a bunch of fake data for me to test with. First I’ll create a little experimental app:

rails rake_example
cd rake example
script/generate scaffold person first_name:string last_name:string
rake db:migrate
rails generate admin fake_people

Here’s the rake task (lib/tasks/fake_people.rake):

require 'faker'

namespace :admin  do
  desc "create some fake data"
  task :fake_people => :environment do
    print "How many fake people do you want?"
    num_people = $stdin.gets.to_i
    num_people.times do
      Person.create(:first_name => Faker::Name.first_name,
                    :last_name => Faker::Name.last_name)
    end
    print "#{num_people} created.n"
  end
end

Note that I’m using the faker gem (docs here) and I created a task dependency on loading the rails environment so I could access my Person model.

Now I can run

rake admin:fake_people

and it will prompt me to ask how many I want and then it will create them. Cool goodness, yes?

Running Remotely on Heroku

We’re not done yet. I want to deploy this on heroku and be able to run the task remotely. For this, there are two gotchas, first I can’t run an interactive script remotely; also I need to tell heroku that I am using the fake gem and make sure it is installed.

1) removing interactivity

Instead of an interactive script, we can set an environment variable or command line argument (thanks to a tip by Adam Wiggins).

My modified task looks like this:

require 'faker'

namespace :admin  do
  desc "create some fake data"
  task :fake_people => :environment do
    num_people = ENV['NUM_RECORDS'].to_i
    num_people.times do
      Person.create(:first_name => Faker::Name.first_name,
                    :last_name => Faker::Name.last_name)
    end
    print "#{num_people} created.n"
  end
end

which I can call locally from the command line like this:

rake admin:fake_people NUM_RECORDS=1

2) adding gem to heroku

I need to create a gems manifest, which sounds fancy, but is simply creating a .gems file at the root of my app with contents similar to what I would put in my config environment.rb to specify that my app requires a gem:

faker --version ">=0.3.1"

3) Deploy and Run

So I can deploy my app to heroku with the usual steps

git init
git add .
git commit -m "example app for rake script testing"
heroku create
git push heroku master
heroku rake db:migrate

and run the task remotely:

heroku run rake admin:fake_people NUM_RECORDS=1

I attended the EngineYard Road Show a couple of weeks ago. I had low expectations for a mid-week corporate-sponsored event, but I found it to be unexpectedly good. I took a few notes on some of the presentations, which I’ve collected below:

Why Performance Matters

Tom Mornini of EngineYard told us about a Google search latency experiment which measured drop-off rates when response time was slow. It is awesome that Google also measured that the effects persisted even when the previous fast response time was restored. As humans, our behavior often reflects our expectations, rather than our immediate experience.

I also enjoyed the four stages of performance which he defined as Delight, Satisfaction, Frustration and Abandonment. It is really easy to get bogged down in the wrong places and optimize things that don’t matter when working on performance. It was nice to see a clear presentation on how to prioritize (and why to prioritize) work on performance and scalability. (Slides)

Agile Deployment

Bill Lapcevic (@blap) from New Relic challenged the audience to do “agile deployment.” AboutUs often releases several times per day — averaging 10 per week. “Smaller deployments more often allow you to back out small pieces of code” says Ward Cunnigham of AboutUs. Instead of stress and load testing before you deploy, make it part of the culture of your development team to watch the performance effects of the live site right after deployment and make it easy to roll back and roll forward.

Engine Yard Cloud

Abheek Anand @abheek presented Engine Yard’s new Cloud product, which has a complete web UI for set up. There’s no command-line interface to it, which is weird, since it offers a deeply geeky array of options for you to tweak exactly how your stack is configured. This is the other end of the spectrum from Heroku. You even get ssh access!

Abheek notes that Engine Yard sets everything up to be performant by default — 20% perf improvement out of the box, e.g. gzip’d content, correct load balance settings. He also adds this generally useful tip: measure everything, identify top ten, pick #1 and optimize.

More about Agile

Ian McFarland (@imf) talked about agile, rails and the cloud:

specialization breeds efficiency: cloud allows you to focus on your key business value (not ops)
increase your bus number: the number of people who would need to get hit by a bus before it would jeopardize your project
shift from a technical decision about whether we can release to a business decision of whether you want to
business driven is sadly, kind of a novelty in software

Also there was an interesting talk on cloud testing by soasta.com — wish I had that the last time I had to build a load test lab!

the evolving ultrasaurus

Sarah Allen's reflections on internet software and other topics

Monthly Archives: December 2009

Japanese geek speak

creating a custom rake task