About 18 months ago, a few friends put together the first Shanghai on Rails event.  It all happened as innocently as you might expect: a few local programmers got together; we thought we could hold an event for about 20 people.  We had to cut off registration at 40 due to room capacity.  Since then, The Shanghai on Rails group has really taken off.  This is the 5th (?) event since we started.  And WOW!!!  Its clear Ruby is making its mark in China.  I was in the U.S. and had to miss this fantastic turnout.  Looking forward to getting back to Shanghai next week and catching up.  Congrats!!!

The key question presented by Jeff is “Shouldn’t every software developer understand English?”

I’ll start by directly answering this question: Yes, they should.  If you wait for docs on languages, tools, and libraries to be translated to you native tongue, you will be a “trailing edge” programmer.

But there is more to the issue.  One might try to stretch this simple question to imply that English should be the default language for all discussion within programmer communities.  If your goal is to create a global online community, such as StackOverflow, forcing it to be a single community only in English will leave plenty of room for other communities to emerge.  This is not a problem that needs to be fixed.  It simply needs to be understood.

My perspective is from living in Shanghai the last 9 years.  I am a “white” American.  I had no experience with China prior to my first trip there in Summer of 2000.  After all these years, now married into a Chinese family, my Mandarin is still poor.

By Fall of 2000 I had set up an R&D lab in Shanghai with a group of the best and brightest local talent.  I wasn’t there for cheap labor, I was paying more than double a good programmer’s salary.  I was there because my new customers were Chinese banks and governments which required local programers to interface with their systems.  Over the next 2 years, I grew a world class development team. They all spoke English as a hiring requirement.  Interacting with me and my team in the U.S., their language skills only got better.

During those first few years, I worked closely with bank Chairmen and senior officials in charge of IT for the Shanghai and China governments.  Whenever the issue came up of language choice for tech documentation, without exception, all officials asked me to keep docs in English only.  They wanted their programmers to be forced to learn.  They understood what it took to prepare their software community for a global market.  English was the only answer.

If language is not unified, trying to convey features and tech requirements is nearly impossible.  English has remained the choice in this regard.  But that is for requirements and final product.  Not for the process of getting there or for learning and basic knowledge exchange.

So I completely agree with Jeff Atwood, right?  Not quite.  There is more to the story.  This is a story about building community.

After a few years, I became interested in giving my time back to the local software community.  I am co-founder of the BarCamps in Shanghai and Beijing and co-founder of the Shanghai on Rails group.

The first BarCamp in Shanghai was put together by myself and friends from RainCity Studios in Vancouver.  We lucked out and the event was fantastic.  Over half the participants were local Chinese.  All the presentations were in English and mostly presented by foreigners.  We made a strong effort to encourage presentations and participation in “whatever language people were comfortable in” but it didn’t happen.  The next year’s Shanghai BarCamp was bigger and better.  This time half the presentations were by locals in Mandarin.  The presentations in Mandarin had interaction from the audience; the English presentations did not.

My experience with the Shanghai on Rails group is similar.  The first event, all presentation were in English even though we encouraged people to use “whatever language they felt comfortable with”.  Now, most presentations are in Mandarin and its the foreigner’s job to “sink or swim” in this environment.  I am very proud of this group and those that continue to build other communities such as China’s Open Source Camp.

When Chinese use their native tongue, the knowledge exchange goes faster and in more depth.  It encourages greater participation by a wider audience.

You may think these experiences only apply to offline, in person interaction.  It turns out it does not.  A site like StackOverflow ends up being more than just discrete programmer question and answer.  The discussion grows into rational behind the answers, agreement, disagreement, and derivative topics.  It grows into meeting people, online and off, and developing relationships.  An English-only website will not be adopted by the majority programmer community in China simply because they are not comfortable enough participating in English.  Will this change?  Maybe, but its changing very slowly.  My money is on Mandarin staying the language of choice for Chinese programmer communities even though their English skills continue to improve.

Jeff proclaims:
“Advocating the adoption of English as the de-facto standard language of software development is simple pragmatism, the most virtuous of all hacker traits. If that makes me an ugly American programmer, so be it”

This is not simple pragmatism.  It is the opposite of pragmatism.  Jeff seems to think he can “think” his way through this.  Pragmatism is not about “rational in your head”.  Pragmatism is about recognizing “what is”.  And what is is that Chinese programmers learn more rapidly and information exchange is more thorough when its in their native tongue.

I’m certain Jeff is a smart man.  I am certain if he spent a few years in China he would understand my position as the pragmatic one.  The only thing lacking is his experience in China.  Anyone with an English-only website that lacks this China experience and understanding will find themselves dumbfounded when their product gets cloned.

There is vast evidence to this effect.  There are hundreds if not thousands of Chinese IT knowledge exchange sites and blogs.  The local Chinese did not create these sites to simply be different or to “own it themselves and get rich off ad revenue”.  If you knew how hard it is in China to make money off an ad supported site, you would understand how laughable this is.

StackOverflow is a great site.  I hope it continues to see success.   If the folks at StackOverflow wanted to address the China market, the only way they could have successfully done so is to have cloned their own product and run it on a server inside China.  They would have to fragment their own start-up.

You can pretend the world is flat all you want.  Those that understand it is not will pick up where you have left off.

Here is my recipe, tested under OS X 10.5.5 with postgres 8.3.4:

Find an unused Group and User IDs. My system has two “login users”.  I want to add another user and need to find a number not in use.  The trick is to create a new user that does not show up on the OS X login dialog.   I found tips from here: http://macosx.com/forums/mac-os-x-system-mac-software/297377-add-user-can-not-seen.html

> sudo dscl . -list /Groups PrimaryGroupID
> sudo dscl . -list /Users UniqueID

On my system, ID 503 is not in use, I’ll use this for my postgres Group and User IDs. Note: OS X should give you an error on the following commands if you screw up and pick an ID already in use.

Create OS X Group and User for postgres using ID 503 (substitute a different ID if this is taken):

> sudo dscl . create /Groups/postgres
> sudo dscl . create /Groups/postgres PrimaryGroupID 503
> sudo dscl . create /Groups/postgres RealName 'Postgres Admin Group'
> sudo dscl . create /Users/postgres
> sudo dscl . create /Users/postgres UniqueID 503
> sudo dscl . create /Users/postgres PrimaryGroupID 503
# not sure if this next command is necessary.
> sudo dscl . create /Users/postgres NFSHomeDirectory /usr/local/pgsql
> sudo dscl . create /Users/postgres Password '*'
> sudo dscl . create /Users/postgres UserShell /bin/bash
> sudo dscl . create /Users/postgres RealName 'Postgres Admin User'

Install postgres.  Download latest source from http://www.postgresql.org/ftp/source/ We’ll assume postgresql-8.3.4.tar.gz for this example.

> tar zxf postgresql-8.3.4.tar.gz
# check your umask. 0002 or 0022 is good.
> umask
> cd postgresql-8.3.4
> ./configure
> make
> sudo make install
> sudo mkdir /usr/local/pgsql/data
> sudo chown postgres:postgres /usr/local/pgsql/data
# switch to postgres user to initialize the database
> sudo su postgres
> /usr/local/pgsql/bin/initdb -D /usr/local/pgsql/data
> exit
# setup the logs directory
> sudo mkdir /usr/local/pgsql/data/logs
> sudo chown postgres:postgres /usr/local/pgsql/data/logs
> sudo chmod 700 /usr/local/pgsql/data/logs
# setup OS X launch script
# paths assume you are still in the postgresql-8.3.4 source root
> cd contrib/start-scripts/osx
> sudo /bin/sh ./install.sh
# to keep postgres from starting at OS X system start, edit /etc/hostconfig file:
# change POSTGRESQL=-YES- => POSTGRESQL=-NO-
# to manually stop postgres
> sudo /Library/StartupItems/PostgreSQL/PostgreSQL stop
# to manually start postgres
> sudo /Library/StartupItems/PostgreSQL/PostgreSQL start
# add /usr/local/pgsql/bin to your PATH
# in my ~/.bash_profile I have a line near the top which I changed to
# PATH=$HOME/bin:/usr/local/pgsql/bin:$PATH:
# after PATH change, exit shell and reopen or re-source .bash_profile
# test if you can connect
> psql -Upostgres
# type \q to quit

Install pgcrypto. Basic digest and crypto functions are not in the default compile. You must install them separately. Its best to do this now as the install requires the config options created from the core install above.

# from postgresql-8.3.4/contrib/pgcrypto
> make
> sudo make install
# The above install creates /usr/local/pgsql/share/contrib/pgcrypto.sql which must be imported to each schema (YOUR_DB_NAME) where the functions are used.
> psql -Upostgres -d YOUR_DB_NAME -f /usr/local/pgsql/share/contrib/pgcrypto.sql

The first thing I have encountered is a key difference in defining unique indexes.

In 0.2.5 ( or 0.3) you would write something like this:

class User < DataMapper::Base
property :email, String, :index => :unique
property :display_name, String, :index => :unique

which would produce SQL indexes (for postgres) as:

Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"users_display_name_key" UNIQUE, btree (display_name)
"users_email_key" UNIQUE, btree (email)
"users_display_name_index" btree (display_name)
"users_email_index" btree (email)


doing a fairly straightforward conversion to datamapper 0.9 yields the following:

class User
include DataMapper::Resource
property :id, Integer, :serial => true
property :email, String, :index => :unique
property :display_name, String, :index => :unique

which generate these SQL indexes (postgres):

Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"index_users_unique" btree (email, display_name)


This creates a single unique index on the combined fields email and display_name; not what I want. I assume this is quite possibly an intended effect as this is how combined key fields gets handled in the new dm 0.9. After a few minutes looking through the very clean datamapper 0.9 source, I find there a constraint type called unique_index. When I use this as follows:

class User
include DataMapper::Resource
property :id, Integer, :serial => true
property :email, String, :unique_index => true
property :display_name, String, :unique_index => true

I get indexes generated as:

Indexes:
"users_pkey" PRIMARY KEY, btree (id)
"unique_index_users_display_name" UNIQUE, btree (display_name)
"unique_index_users_email" UNIQUE, btree (email)


much better!!!

One of things you will encounter when using the coolest and latest technologies is that they might contain bugs . It is what we encountered in using datamapper 0.2.5 and do_postgres 0.2.3 in our merb 0.9.2 development stack for ShellShadow.

Here’s a quick look at how we add our patches into our merb app.

One of nasty bugs existing in datamapper 0.2.5 or 0.3.0 is that it will interpret NULL integer fields from a table as 0. It was a huge issue for us and had to be patched.

Turns out the culprit is not datamapper but in do_postgres. Many thanks to Adam French for pointing this out on #datamapper irc channel.

The buggy code was in [GEM_PATH]/gems/do_postgres-0.2.3/lib/do_postgres.rb in class Reader < DataObject::Reader method typecast(val, field_type).

The code in questions was:

when "INT2", "INT4", "OID", "TID", "XID", "CID", "INT8"
val.to_i


This should read:

when "INT2", "INT4", "OID", "TID", "XID", "CID", "INT8"
val == "" ? nil : val.to_i


The fix was a one liner but we needed to replace the entire method it was in.

This is how you apply your monkeypatch:

1. Add your patch file under <your_merb_project>/lib. Lets call it do_postgres_patch.rb. We put our modified copy of typecast in this file.
2. In <your_merb_project>/config/init.rb, you’ll see at the very bottom


Merb::BootLoader.after_app_loads do
### Add dependencies here that must load after the application loads:
# dependency "magic_admin" # this gem uses the app's model classes
end

In this block, add:
require 'core_extensions'

That’s it. Easy and all patched up!!!

Last October, I tried every ruby debugger I could find (except the windows-only Sapphire Steele). At that time, only NetBeans 6 beta had any form of working debugger and for the most part, the command line ruby-debug was a better choice.

We were re-writing ShellShadow in merb (the old site was Rails).
Now that I’m exploring merb and datamapper and sequel, I find I need a GUI debugger. Unless you have an internalized mental model of the framework (e.g. you’re the creator), you won’t get far fast enough with command line debugging.
Aptana’s latest release on what was RadRails does the job.

Here are a few things to get you going:

1. Download and install Aptana. This is a multi-step process where you need to install Aptana and then from the intro page, install the RadRails plugin. There may be updates to Aptana. Just let eclipse work its magic and update to the latest patches.
2. install ruby-debug-ide.
   gem install ruby-debug-ide. You will want to run this as “sudo gem install ruby-debug-ide” if you are installing to your global gems setup.
3. On OS X 10.5, I needed to create a link (the following is a one line command)
   sudo ln -s /usr/bin/rdebug-ide /System/Library/Frameworks/Ruby.framework/Versions/Current/usr/bin/rdebug-ide
4. Config the ruby debugger in Aptana. Open the eclipse/aptana preferences dialog from “Windows->Preferences…”. In the section “Ruby>Debugger”, turn on the checkbox “Use ruby-debug library.
5. Setup your app. I didn’t create a Rails project. I create a ruby project (its for merb). I have my aptana/eclipse workspace outside of my ruby project and simply point the working directory of my project to the right place. You’ll want to set your debug setting for this project to run /usr/bin/merb or whatever your app is. This approach litters my merb project directory with two files: .loadpath and .project. You’ll probably want to tell your version control system of choice to ignore these files.

Its not perfect, but this seems to be as good as it gets at the moment for a GUI ruby debugger. Here are a few things of interest:

1. Breakpoint removal is flaky. We found that sometimes when you turn off a breakpoint, it doesn’t go away. We had to edit the code to force aptana/eclipse to refresh itself.
2. Interactive console isn’t great. IRB has a cleaner expereince but the apatana console does work.
3. Missing ability to eval expressions in the debugger. This would be a great feature and hopefully it gets added someday.

Many thanks to the Aptana RadRails team!!