1. Installing Ruby Version Manager (RVM)

Ruby Version Manager is a great tool for isolating your development environment to each individual project.  This allows you to have specific ruby versions with specific gemsets isolated from the rest of your development environment, virtually eliminating any potential conflicts.  Although not absolutely required to use Rails or Ruby, RVM will greatly reduce headaches with managing ruby.  To learn more about RVM, visit the RVM homepage.

Luckily, RVM provides an install script that we can download and execute with a single command.  This command will download the latest code from the github repository, so you need to have git and curl installed on the system.  If you are using a recent linux distro like Ubuntu 11.10, then you might already have git and curl installed. If not, execute the following command:

$ sudo apt-get install git curl 

Start the RVM installation by running this command:

$ bash -s stable < <(curl -s https://raw.github.com/wayneeseguin/rvm/master/binscripts/rvm-installer)

Now that the installation completed, we need to add the loader for RVM to our .bash_profile. Open the file in your favorite editor:

$ gedit .bash_profile 

Next, past the following command into the text file:

[[ -s "/home/artem/.rvm/scripts/rvm" ]] && source "/home/artem/.rvm/scripts/rvm"

For the .bash_profile to take effect, we need to restart the bash shell.  Once the bash shell restarts, let’s verify that RVM is properly installed by running the following command:

$ type rvm | head -1

rvm is a function

Next, let’s check what dependencies we need to install on our platform by running:

$ rvm requirements

This returns a number of requirements you will need for different ruby compilers. We will use MRI (official) ruby interpreter, so copy and paste the command under that and run it:

$ sudo apt-get install build-essential openssl libreadline6 libreadline6-dev curl git-core zlib1g zlib1g-dev libssl-dev libyaml-dev libsqlite3-0 libsqlite3-dev sqlite3 libxml2-dev libxslt-dev autoconf libc6-dev ncurses-dev automake libtool bison subversion

2. Installing Ruby

Now that we got RVM all ready to go, let’s jump right into installing Ruby.  First, let’s see what version of ruby are available to us through RVM:

$ rvm list known

We can see there are quite a few different ruby installations available:

# MRI Rubies
[ruby-]1.8.6[-p420]
[ruby-]1.8.6-head
[ruby-]1.8.7[-p352]
[ruby-]1.8.7-head
[ruby-]1.9.1-p378
[ruby-]1.9.1[-p431]
[ruby-]1.9.1-head
[ruby-]1.9.2-p180
[ruby-]1.9.2[-p290]
[ruby-]1.9.2-head
[ruby-]1.9.3-preview1
[ruby-]1.9.3-rc1
[ruby-]1.9.3[-p0]
[ruby-]1.9.3-head
ruby-head

# GoRuby
goruby

# JRuby
jruby-1.2.0
...

# Rubinius
rbx-1.0.1
...

# Ruby Enterprise Edition
ree-1.8.6

...

# Kiji
kiji

# MagLev
maglev[-head]
..

# Mac OS X Snow Leopard Only
macruby[-0.10]
...

# IronRuby -- Not implemented yet.
ironruby-0.9.3
...

Let’s start by installing Ruby 1.8.7:

$ rvm install 1.8.7

This will download and install Ruby 1.8.7.  After installation is complete let’s set RVM to use this Ruby installation:

$ rvm use 1.8.7@defaultgems --create
Using /home/artem/.rvm/gems/ruby-1.8.7-p352 with gemset defaultgems

You can also set this to be the default version, overriding the system installation of Ruby, by running the following command:

$ rvm use 1.8.7@defaultgems --default
Using /home/artem/.rvm/gems/ruby-1.8.7-p352 with gemset defaultgems

You can always switch back to the system ruby by running:

$ rvm use system

3. Installing RubyGems and Rails

Ruby is fully functional now, but we are not done yet.  We want to get Rails set up on this installation, so let’s start by installing RubyGems (ruby package manager).  Start by downloading the setup file from RubyForge, then extract the archive and execute the setup.rb file:

$ sudo ruby setup.rb

Once the installation finishes, simply execute the following command to install Rails:

$ gem install rails

4. Starting the first project and configuring the basics

We are finally ready to get to the good part of actually setting up a new project.  Start by navigating to the directory where you want to store rails project and create a new rails project:

$ rails new Project -T
$ cd Project

Note the ‘-T’ option; it tells rails not to use Test::Unit.  Instead, we will use RSpec that we will install shortly.

Remember we installed Ruby 1.8.7?  Let’s say for this project we want to use version 1.9.2 instead (because that’s what our server uses), but we only want 1.9.2 to execute for this project AND we want it to that automatically.  Additionally, we want to isolate the gems for this project so that we don’t have any hard to trace conflicts between unused gems.  It’s a tough order, but that’s exactly what RVM is made to do.  We can customize the RVM behavior by placing .rvmrc file inside the root directory of our project:

$ gedit .rvmrc

Now we need to put one line to load the ruby we want with a gemset that’s specific to the project.  Recall that we wanted to use Ruby 1.9.2, so paste the following:

rvm 1.9.2@project_name

Save the file and exit the directory and enter it again:

$ cd ..
$ cd Project

RVM will ask you if you trust this .rvmrc file (and you should! you made it).  Click yes, and it should prompt you with an error that we didn’t install this version of Ruby yet.  Copy and paste the instructions given by the error:

$ rvm install 1.9.2
$ rvm gemset create 'project_name'

At this point, we need to reinstall rails for this specific gemset, so run:

$ gem install rails

5. Installing RSpec and Guard

Now that we got our project set up, we should add a testing environment since we removed Unit::Test. Let’s start by opening the Gemfile and adding the following:

group :test, :development do
  gem 'rspec-rails'
  gem 'capybara'
  gem 'guard-rspec'
end

Next run the bundle command from the bash shell, and initialize RSpec and Guard:

$ bundle
$ rails g rspec:install
mkdir spec/support spec/models spec/routing
guard init rspec

And, now we are all set to start programming the first application. Fortunately, starting a new project will take a lot less time, now that we got everything installed, so don’t be afraid to experiment

Let me know how this works out for you. If you have any question, be sure to leave comments below and share this if you liked it!

I’ve also been drafting several articles on the extended airplane rides, but they aren’t quite ready to publish.

Stay tuned!

Backend

• Optimize database access
• Refactor code for faster execution

Frontend

• Added ability to view added words
• Added ability to remove words from list
• Added support for multi-line dictionary entry display
• Fixed some CSS/Browser issues

See it here:

http://duzhe.aaginskiy.com

The first step is to decide the purpose for learning the language. Having a clear understanding of what you want to gain from the language will help you develop realistic goals and expectation as you make progress.

Set Realistic Goals

As with any other skill, there exist two types of goals, long-term and short-term. For long-term goals, you need to decide what you want to do with a language and how far you’d like to pursue it. For example, if you are traveling for business in 10-weeks, you probably aren’t interested in acquiring full fluency in the language. Instead, you may prefer to gain basic knowledge of key situations you might encounter during travel. On the other hand, if you want to gain full fluency in the language equal to your native language, you should keep that in mind as you develop your daily approach to learning the language.

Long-term goals are very important, but long-term goals alone tend to be detrimental to your progress. It happens because with long-term goals only, you will quickly become discouraged without reaching those goals for a long time. In this respect, the short-term goals complement the long-term goals to help you make solid progress and stay motivated.

Learning languages is a two-step forward, one-step back process, so set short-term goals that will keep you excited about making progress.  Without short-term goals, learning a language often feels like a moving backwards.  A good example of setting short-term goals is choosing a topic goal for the week, such as learning the words and grammatic structures to introduce yourself. You can then develop a plan to reach the goal that fits your personal schedule. You could spend the first two days learning the vocabulary and the grammatical structures, then you could spend the next three days practicing. On the 6^th day, you may consider writing a short 7-8 sentence journal entry introducing yourself. Finally, on the 7^th day, you can practice it on someone who speaks the language (of course, if you have access to a native speaker, you can practice it every day for 7 days).

Choose Interesting and Relevant Material

If you are taking classes, you will be required to follow a textbook and the choice of words and material that it provides. Often, you will find that this material is not interesting or pertinent to what you want to learn. For this reason, it’s very important that you supplement that textbook material with what you actually enjoy. For example, if you enjoy music of the language you are studying, then you may want to learn vocabulary in your favorite song.

By choosing material you enjoy, you will also select real-world usage of the language. While classes can be very helpful for developing understanding of the language and how the grammar functions, but learning how to conjugate every single verb will not be so helpful because you will easily forget some of the obscure conjugations that you don’t practice. Learning relevant real-world material that interests you will help you remember the more complex topics you learn in class

Develop a Daily Routine

Developing a daily routine depends on your personal schedule and other time commitments. I find the best way is to develop a daily minimum and maximum. For example, let’s say you would like to learn 35 new words every week; you could decide to learn 5 words per day, but what if you skip one day? This can become quickly discouraging when you are not meeting your goal of 35 words per week. Instead, I recommend you set a daily minimum and a maximum. Let’s say every day you learn at least 2 words and no more than 8 words. This way, if you are busy one day, you can still reasonable learn a couple of words and then get caught up when you have more time without forcing yourself to study too much. Being flexible is important when learning a language.

Also, I highly recommend carrying with you a small notebook (maybe something pocket-sized?) where you can record any new words you hear or words you’d like to learn. For example, let’s say you are at a store buying a pack of gum and it hits you that you’d like to know how to say a pack of gum in the language you are learning. You tell yourself that you will look it up when you get home, but very likely you will forget you even had the thought within the next 20 minutes. For this, I recommend keeping a list of words you’d like to learn. This will keep you motivated because you will see progress relevant to your daily life. If you buy coffee every morning before work, you’ll be delighted to know that you could do the same thing when you travel.

Most of all, remember to spend at least some time reviewing every single day no matter how busy you are. You can play an audio CD on the way to work, review your words from last night during your coffee break, or maybe practice your new words on co-workers who speak the language. Every bit of review puts you that much closer to reaching your short-term goals, which in turn help you reach the long-term goals.

The next big step will be refactoring my Rails code.  In an effort to get all my ideas down quickly, I’ve turned the code into a lot of mess.  The next alpha (2) release will bring no visible improvements to the user, but it will streamline the code for future updates.

The following, and final, alpha (3) will bring user registration and management.  This will not necessarily come with any benefits to registration at that point, but it paves the way for future updates.

The beta release will come with a full word editor to submit updates to the dictionary, as well as many other features.

For now check out the alpha (1) release:

http://duzhe.aaginskiy.com

While evaluating the different dictionaries to use with the reader, I came across the need to parse CC-CEDICT entries from their text form.  After an initial quick google, I didn’t see any articles with a quick RegEx solution for doing just that, so I jotted down my RegEx for parsing CC-CEDICT.  Hopefully this will help other people who might google for the same purpose.

The RegEx:

^\s*(.+)\s+(.+)\s+\[(.+)\]\s+\/(.+)\/\s*$

This RegEx will take care of any trailing spaces before or after the actual dictionary entry.  It assumes that each line follows the standard CC-CEDICT formatting, and will spit out four matches (1: Simplified 2: Traditional 3:Pinyin 4:English).  Each individual English entry is still separated by ‘/’, but the trailing ‘/’ are removed.

http://duzhe.aaginskiy.com/

[UPDATE] I selected the dictionary, so the flashcards now include the definitions.  The definitions are provided by the excellent ADSOtrans.

Finally, to run the Rails 3 app, I’m using Passenger (mod_rails) to execute the ruby code.  I’ve chosen Passenger because it is the fastest option for executing Ruby apps offered by my web hosting provider.

Getting all 3 components to work together, unfortunately, was not trivial.  It took a while to get it all to work because primarily there is not much documentation on generating a recipe for Capistrano that works with Rails 3.

Here is a step by step on how to get Ruby on Rails 3 deployed on Passenger-enabled servers with git and Capistrano.

1. Set Up Git Repository

I will not go into how to install git on the server and locally; that is for another tutorial.  I recommend to make sure the git locally and remotely are of the same version or some unexpected bugs may arise.

First, make a copy of your project, just to be safe, then change directory to the project directory:

[localuser ~]$ cd projectdir

Now that we are in the right folder, let’s set up the project as a local git project.  First, let’s look at all the steps and analyze them one by one:

[localuser projectdir]$ git init
[localuser projectdir]$ touch .gitignore
[localuser projectdir]$ git add .
[localuser projectdir]$ git commit

The first line tells git to initialize this folder as a repository.  After it is done, we create an empty .gitignore file.  This is where you can write what files to include from the repository.  I’m leaving it blank for now.  Next I let git know to add all the files in the directory to the local repository (note the “.” at the end; it can be replaced for specific files).  Finally, I let git know to commit any changes (which in this case would be everything).

Now we need to switch over to the remote server and and set up a remote repository:

[localuser projectdir]$ ssh [remoteuser@]host
[remoteuser ~]$ mkdir projectdir.git
[remoteuser ~]$ cd projectdir.git
[remoteuser projectdir.git]$ git init --bare
[remoteuser projectdir]$ exit

First, we SSH into the remote server and create a new directory where we want the remote files to be stored.  We initialize the directory as a barebones git repository, since there are no files there yet.  Finally we return back to the local machine.

Next we are going to push our local repository to the remote host and set up some short cuts to make it easier in the future:

[localuser projectdir]$ git remote add origin ssh://[user@]host/~/projectdir.git
[localuser projectdir]$ git push origin master
[localuser projectdir]$ git branch --set-upstream master origin/master

In the first line we set up a short cut to push the repository to keyword: origin, rather than typing the address every single push.  Next we push the previous commitment to the “origin” server under master branch.  Finally, we set up our branch is the primary upstream branch, so we can just issue “git push” command without specifying a branch or remote host.

2. Set Up Capistrano

Capistrano is a wonderful program for deploying Rails 3 apps; it allows for great customization and is very simple to use.  Best of all, it is very flexible and will work with almost any version control system out there.  Of course, we will be using it with git, so we will develop the right recipe for that.

The first step is to install Capistrano with the following command:

[localuser projectdir]$ gem install capistrano

After the installation is done, open up your Gemfile and add:

gem 'capistrano'

Finally, we initialize Capistrano by running:

[localuser projectdir]$ capify .

This creates two files Capfile and config/deploy.rb.  The Capfile is like a a make file and can be left alone.  The second file, config/deploy.rb, is the one that we will customize.  Fill in all the necessary information that is representative of your connection:

require 'bundler/capistrano'
set :user, 'username'
set :domain, 'web.host.com'
set :applicationdir, "appdir"

set :scm, 'git'
set :repository,  "ssh://[user@]host/~/projectdir.git"
set :git_enable_submodules, 1 # if you have vendored rails
set :branch, 'master'
set :git_shallow_clone, 1
set :scm_verbose, true

# roles (servers)
role :web, domain
role :app, domain
role :db,  domain, :primary => true

# deploy config
set :deploy_to, applicationdir
set :deploy_via, :export

# additional settings
default_run_options[:pty] = true  # Forgo errors when deploying from windows
#ssh_options[:keys] = %w(/home/user/.ssh/id_rsa)            # If you are using ssh_keysset :chmod755, "app config db lib public vendor script script/* public/disp*"set :use_sudo, false

# Passenger
namespace :deploy do
  task :start do ; end
  task :stop do ; end
  task :restart, :roles => :app, :except => { :no_release => true } do
    run "#{try_sudo} touch #{File.join(current_path,'tmp','restart.txt')}"
  end
end

The first line is very important for making Capistrano work with Ruby on Rails 3.  Without it, Capistrano will throw a bunch of errors when running the bundler on the remote host.  Line 2-4 are relevant to your server configuration and should be filled in accordingly.  Lines 6-11 set up git as the version control system; you should adjust line 7 for where you set up the remote repository in the previous section.  Lines 14-16 set up the addresses of the different services (all the same in this case), and line 19-20 set up the deployment location.  Finally, lines 27-33 let Capistrano know that we need to create a file tmp/restart.txt to reboot Passenger after any deployment.

This pretty much all you need to do to get it deployed:

[localuser projectdir]$ cap deploy

That’s all it takes to get the app deployed.  Leave a comment and let me know if this worked for you

At the moment, I’m only rolling out the Pre-Alpha version.  In this version, 读者 (DuZhe) Text Analyzer segments and analyzes the text for difficulty.

It generates three (3) different scores.  The first score is the overall Difficulty Score, which represents how the piece of text ranks on the scale of 1 to 10.  The algorithm for predicting the difficulty is still being tweaked, so I won’t be disclosing it yet.  However, I will discuss the algorithm in a later post.

The second score is the Old HSK difficulty score; it ranks the frequency distribution of the words in the text as compared to the typical HSK test passages.  The scale is from 0 to 4, representative of the HSK levels.

The third score is similar to the Old HSK score, but it is designed for the New HSK.  This score also is derived by comparing the word frequency distribution to a typical New HSK test passage.  The scale is from 0 to 6.

You can experiment with the Pre-Alpha version here.

读者 (DuZhe) Text Analyzer: http://duzhe.aaginskiy.com