has_many :thoughts

We recently switched to git based capistrano deployments and I quickly found out that these weren’t working from my MacBook Pro. I noticed that my git version was a few behind my coworker’s, so I figured it was time to upgrade.

Following Justin’s original git compilation instructions, I downloaded and compiled the latest Git version, 1.6.2 like so:

curl -O http://kernel.org/pub/software/scm/git/git-1.6.2.tar.gz
tar jxvf git-1.6.2.tar.gz
cd git-1.6.2
make prefix=/usr/local all
make prefix=/usr/local test && echo $?
sudo make prefix=/usr/local install

When the compile was done, it gave me output like this:

!! You have installed git-* commands to new gitexecdir.
!! Old version git-* commands still remain in bindir.
!! Mixing two versions of Git will lead to problems.
!! Please remove old version commands in bindir now.

Thanks to this nice posting, I discovered this always happens when you upgrade to 1.6 and above. Git now only puts the main git binary and a few others in your /usr/local/bin and it tucks the rest away elsewhere. That meant that all the other zillion binaries needed to be deleted from my bin. I simply did:

cd /usr/local/bin/
ls -latr | grep git

Which gave me an ordered list of all the git binaries installed. The ones at the end all had today’s date on them, so I knew those were the new versions. The rest I could whack. The ones I could keep were git-upload-pack, git-upload-archive, git-receive-pack, git, git-shell, git-cvsserver, and gitk. The rest I removed like so:

sudo rm git-var git-update-server-info git-unpack-file git-ssh-upload git-ssh-push git-ssh-pull git-ssh-fetch git-show-index git-send-pack git-peek-remote git-patch-id git-pack-redundant git-mktree git-mktag git-merge-tree git-merge-recursive git-merge-index git-local-fetch git-index-pack git-imap-send git-http-push git-http-fetch git-hash-object git-fetch-pack git-fast-import git-daemon git-convert-objects git-bisect git-write-tree git-whatchanged git-verify-tag git-verify-pack git-update-ref git-update-index git-unpack-objects git-tar-tree git-tag git-symbolic-ref git-svnimport git-svn git-submodule git-stripspace git-status git-stash git-show-ref git-show-branch git-show git-shortlog git-sh-setup git-send-email git-runstatus git-rm git-revert git-rev-parse git-rev-list git-reset git-rerere git-request-pull git-repo-config git-repack git-remote git-relink git-reflog git-rebase--interactive git-rebase git-read-tree git-quiltimport git-push git-pull git-prune-packed git-prune git-parse-remote git-pack-refs git-pack-objects git-name-rev git-mv git-mergetool git-merge-subtree git-merge-stupid git-merge-resolve git-merge-ours git-merge-one-file git-merge-octopus git-merge-file git-merge-base git-merge git-mailsplit git-mailinfo git-ls-tree git-ls-remote git-ls-files git-lost-found git-log git-instaweb git-init-db git-init git-gui git-grep git-get-tar-commit-id git-gc git-fsck-objects git-fsck git-format-patch git-for-each-ref git-fmt-merge-msg git-filter-branch git-fetch--tool git-fetch git-diff-tree git-diff-index git-diff-files git-diff git-describe git-cvsimport git-cvsexportcommit git-count-objects git-config git-commit-tree git-commit git-clone git-clean git-citool git-cherry-pick git-cherry git-checkout-index git-checkout git-check-ref-format git-check-attr git-cat-file git-bundle git-branch git-blame git-archive git-archimport git-apply git-annotate git-am git-add--interactive git-add gitjour

Then I just had to go back and install the manpages for the new version like so:

curl -O http://kernel.org/pub/software/scm/git/git-manpages-1.6.2.tar.bz2
sudo tar xjv -C /usr/local/man -f git-manpages-1.6.2.tar.bz2

And, low and behold, I was now running git 1.6.2! What’s more, my capistrano deployments work now.

We’re still kicking the Ruby hardcore. We’ve just been massively busy locked in the Kinetic Barn HQ this winter. Anyway, here is a list of the latest things we’ve found interesting about the first stable 1.9.x release of MRI Ruby.

Note: Some of these have been in the 1.9 branch for awhile, I’m just taking the moment to get you all acquainted.

Newlines allowed before ternary colon operator (:) and method call dot operator (.)

Before this you might note that you could do this in Ruby, and it was valid.

Person.
  set_first_name('Ben').
  capitalize.
  to_a

# or...

dog = Person.first_name == 'Ben' ? 
'Cookie' : 
'pookie'

You won’t see the former very often, but you can do it if you keep to coding standards of 80-100 columns of text in your source.

I’ve seen and used the latter numerous times, however I usually don’t put a newline after the colon. Eithercase, Ruby makes things a bit more clearer in 1.9 (though these are bad examples of their use cases).

Person
  .set_first_name('Ben')
  .capitalize
  .to_a

# or...

dog = Person.first_name == 'Ben' ? 
'Cookie'
: 'pookie'

Kernel#methods and #singleton_methods used to return an array of strings but now they return an array of symbols.

I use this daily within Irb to see what methods are in my objects. You used to receive an Array of Strings, of all the methods on the object you ran this against. Now you will get this.

>> String.methods.sort
=> [:, :, :=>, :, :, :, :, :, :__id__, :__send__, :allocate, :ancestors, :autoload,
 :autoload?, :class, :class_eval, :class_variable_defined?, :class_variables, :clone, 
:const_defined?, :const_get, :const_missing, :const_set, :constants, :display, 
:dup, :eql?, :equal?, :extend, :freeze, :frozen?, :hash, :id, :include?, 
:included_modules, :inspect, :instance_eval, :instance_method, 
:instance_methods, :instance_of?, :instance_variable_defined?, 
:instance_variable_get, :instance_variable_set, :instance_variables, :is_a?, 
:kind_of?, :method, :method_defined?, :methods, :module_eval, :name, :new, 
:nil?, :object_id, :po, :poc, :pretty_inspect, :pretty_print, :pretty_print_cycle, 
...]

If you know anything about Ruby low level you might guess someone got smart and decided it was better to utilize the Symbol table instead of building these lists of anonymous String instances.

Hash; preserving item insertion order

Yes, Hashes are now ordered… which is pretty odd if you’ve been writing Ruby for awhile now. We all used to utilize Arrays, and I hope we still do. But Hashes are now ordered by the pattern in which you insert keys/values into them.

[1,2,3,4,5].inject({}) { |hash, value| hash["name_#{value}"] = value; hash }

# Ruby 1.8
=> {"name_4"=>4, "name_5"=>5, "name_1"=>1, "name_2"=>2, "name_3"=>3}

# Ruby 1.9
=> {"name_1"=>1, "name_2"=>2, "name_3"=>3, "name_4"=>4, "name_5"=>5}

As a community, let’s not go nuts and start replacing our usage of Array’s with Hashes when we needed to persist order. I’m fairly certain the speed of an Array will always trump a Hash.

Named/Coroutine style Regexp

Dave Thomas can give you a better description than I can…

sentence = %r{ 
    (?<subject>   cat   | dog   | gerbil    ){0} 
    (?<verb>      eats  | drinks| generates ){0} 
    (?<object>    water | bones | PDFs      ){0} 
    (?<adjective> big   | small | smelly    ){0} 

    (?<opt_adj>   (\g<adjective>\s)?     ){0} 

    The\s\g<opt_adj>\g<subject>\s\g<verb>\s\g<opt_adj>\g<object> 
}x

md = sentence.match("The cat drinks water") 
puts "The subject is #{md[:subject]} and the verb is #{md[:verb]}"

Dir.exists?/.exist?

This one annoyed quite a few people, because before you had to do File.exists?(”/tmp”) to test the existance of a directory. Odd, but fixed.

Negative operators such as ”!”, ”!=” and ”!~” are now overloadable

OOOHHH… more fun for the DSL writers out there! dm-core, I’m looking at you! :)

Rake and RubyGems Made Core

Both Rake and Rubygems are now included in the core library. Hopefully it’s still as easy to upgrade them both!

Thats Not All

Of course this isn’t it, and the entire list is a great read. If anyone else has anything feel free to post… like the difference between proc and lambda now, new Hash key syntax {apple: 1, pear: 2} or anything else… feel free to comment.

I haven’t been around in awhile, frankly because I’ve had my own things to attend to… but I’ve felt somewhat ashamed that I’ve left my kind Kinetic audience a float. So here is another “Up and Running” treat. Cloning Merb-core and -more, from Git[hub] to dummy project.

BTW, it should be any day now for the official 0.9 release. Rumors have it that Ezra will be releasing it at ActsAsConference.

Preperation

Your going to want to remove any old gems in the following list, as you will be installing trunk versions in this tutorial.

merb (< 0.9)
merb_datamapper (< 0.9)
merb_helpers (< 0.9)
datamapper (< 0.3.0)

You can go ahead and gem install the following. I’ve listed the version numbers I use currently.

sqlite3-ruby (1.2.1)
data_objects (0.2.0)
do_sqlite3 (0.2.3)
do_mysql(0.2.2)
rack (0.2.0)

Along with the regular Merb dependencies listed in the API.

# gem install mongrel json json_pure erubis mime-types rspec hpricot mocha rubigen haml markaby mailfactory Ruby2Ruby -y

Thats a lotta gems right? Well, taking a closer look you should have most of these already… and if you don’t you should.

Installing Git

You installed it already, otherwise… EPIC FAIL!

You DO have a Github account

If you have a Github account, you’ll most likely want to fork merb-core and merb-more so you have your own fork’s to mess about with. If you find anything interesting you can always submit a bug/patch and help the wonderful Merb team out! Or start building some new framework forked from Merb. Either way…

To do this, login to Github and…

http://github.com/wycats/merb-core/fork
http://github.com/wycats/merb-more/fork
http://github.com/wycats/merb-plugins/fork

You’ll then want to clone these like the next section…

You DON’T have a Github account

If you don’t have an account yet for Github you’ll still need Git installed like I noted above. From within a fresh directory in Terminal run the following commands.

# git clone git://github.com/wycats/merb-core.git
# git clone git://github.com/wycats/merb-more.git
# git clone git://github.com/wycats/merb-plugins.git

Installing these Git forks/clones

Simply enter the directories “merb-core” and “merb-more” and run…

# sudo rake install

You’ll also want to do this under “merb-plugins/merb_datamapper” and “merb-plugins/merb_helpers”. Including any others in “merb-plugins” you would like installed.

Installing Datamapper Trunk

Currently, Datamapper is still under SVN. I’m positive this will change in the near future. But for now…

# svn co http://datamapper.rubyforge.org/svn/trunk/ data_mapper

Then simply go into the data_mapper/ directory created and do…

# sudo rake install

Merb-gen is your Friend?

I’ve just recently discovered that they’ve changed, yet again, the default way of creating a new Merb project. I guess because “merb -g” or “merb” was getting annoying, so “merb-gen [projectname]” is some how much simpler. You also use this to generate models/controllers/resources/etc… :/

I’m going to take another guess and say this is somehow based on the project directory no longer needing to conform to a certain structure like Rails. I’ve heard this, but I haven’t tested it out for fact… so let me know your experiences.

Either way…

# merb-gen lovely-app

Going into Toshi Station to pick up some power converters

This is where it starts to get exciting. The fruit of our labors dance in unison to form a euphoric aura called “0.9”... not so fast though.

1. If your not already, make sure your in the “lovely-app/” project directory.

2. Open up “config/init.rb” and uncomment…

use_orm :datamapper

Rspec should be your testing framework by default.

3. Back in your shell, run…

# rake --tasks

4. This should auto-generate “config/database.sample.yml“

5. Overwrite the entire thing with the following, and save as “config/database.yml”...

---
:development: &build
  :adapter: sqlite3
  :database: db/dev.db

:test:
  <<: *build
  :database: db/test.db

:production:
  :adapter: mysql
  :database: lovely_app
  :username: root
  :password: ""

6. Your going to now want to create those sqlite databases. If not both just db/dev.db.

# mkdir db/
# sqlite3 db/dev.db
SQLite version 3.5.1
Enter ".help" for instructions
sqlite> .databases
seq  name             file                                                      
---  ---------------  ----------------------------------------------------------
0    main             /Users/bionicebonics/lovely-app/db/dev.db                     
sqlite> .quit

You should be able to run a successful “rake—tasks” if you did everything correctly. You may also want to test and see if you can run the daemon, and pull up a browser window. Run “merb” by itself from Merb.root or project root directory.

In short, just start hacking! Reference the API for help, not me.

The Sugar

You should now have a base process for exploring Merb 0.9 development.

The Salt

If for some weird reason your getting errors running “merb”, make sure you removed any old versions of Merb <= 0.5.x.

Also try uninstalling merb-core and reinstalling it from a new Git clone of the main repo. I had to do this for some odd reason whilst running through this tutorial.

Shameless Kinetic/PhillyOnRails

Colin will be giving a talk on Merb at our local PhillyOnRails Users Group, so stay tuned for info on that.

Update

Gotta love Merb integrating Rack/WSGI!

Following a few discussions on the Thin webserver mailing list, I just tried Merb on Thin… this is working out excellent! I’ve also heard that Ezra just got 2200 req/sec using Thin.

If you would like to explore the possibilities of this incredibly fast setup, simply do…

# sudo gem install thin
# cd lovely-app
# merb -a thin

This will load Merb on Thin. If you don’t know about Thin, I’m not going to sit here and explain it. I’m just not like that. You’ll have to FOFY, find-out-for-yourself.

The following is the exact compilation steps I took for compiling Git onto the new retail version of Leopard. Definitely a big change since my previous article on installing in Tiger (next to pre-installed SVN, bye bye CVS!)...

curl -O http://surfnet.dl.sourceforge.net/sourceforge/expat/expat-2.0.1.tar.gz
tar zxvf expat-2.0.1.tar.gz 
cd expat-2.0.1
./configure --prefix=/usr/local
make
make check
sudo make install
cd ..

curl -O http://kernel.org/pub/software/scm/git/git-1.5.3.4.tar.bz2
tar jxvf git-1.5.3.4.tar.bz2
cd git-1.5.3.4
make prefix=/usr/local all
make prefix=/usr/local test && echo $?
sudo make prefix=/usr/local install
cd ..

curl -O http://www.kernel.org/pub/software/scm/git/git-manpages-1.5.3.4.tar.bz2
sudo tar xjv -C /usr/local/man -f git-manpages-1.5.3.4.tar.bz2

Notes

You may need to adjust your default MANPATH environment variable. You can either apply something along the lines of…

export MANPATH="/usr/local/man:$MANPATH"

...to your .bash_login, profile or what have you. Or you can look into editing /private/etc/man.conf (or un-tar the manpages into a directory in your MANPATH already).

Also, no need to fiddle around with SVN bindings for Perl, or whatever the problem was with git-svn before.

You may also wish to surf our past articles hear on this blog for upgrading Git. The upgrading should be identical on Leopard.

Next Time

My next article will cover developing outside of a traditional distributed Git environment. Using Git to manage personal branching/merging/local copies, then committing to a main SVN repo. Happy hacking.

Note: This article is still on using Git under Tiger (10.4.10, respectively)... Until I have time to run down to the Apple store tomorrow and do a nice clean install of Leopard onto my Macbook, I will not have the appropriate means of writing a proper article on Git use under 10.5.

This is for anyone that reads this blog, and used my previous article on compiling Git. I left the proper Git tutorials to the behmouth of external articles out there, on using Git as Rails project/deployment SCM. I’m also a firm believer in DIY, and the same applies to learning new things. Nobody ever taught me a damn subject (completely) in person on anything I use day-to-day… so DIY and…

Welcome to the wonderful world of Git folks!

Since my last article, actually a day ago, Geoffrey Grosenbach over at Peepcode Screencasts released Video 015, on Git. This should really, visually, help out those that are really having problems crasping the simple things in Git. There are other numerous advances in using Git with your Rails applications. So I’ll keep things DRY here…

One thing I will update you with though, a quick and simple way to update your source compiled installation of Git, by using Git’s repository itself.

# git clone git://git.kernel.org/pub/scm/git/git.git
# cd git
# make configure
# ./configure --prefix=/usr/local
# make all doc
# sudo make install install-doc

You will now have a completely refreshed version of Git on your system.

Take note, Grosenbach mentions the benefits of having a compiled version of Git on your system. He does not, however, give more than a quick mention that it may be slightly difficult gathering up the proper dependency chain onto your system. That was what my previous article was for.

Enjoy, and let me know how things go for you… justin_at_kineticweb.com.

X-posted from another blog (forget which, maybe Ruby Inside)... here is a lil script that will check your Rails apps for compatibility issues against Rails 2.0.

http://pastie.caboo.se/99900.txt?key=krcevozww61drdeza13e3a

That is the pastie text link, in case you would like to wget/curl the file down to your local machine. Comment in the script also notes that you can run it using wget/curl, and gives the relevant commands. Wouldn’t it be nice to include an alias for that? ;)

Also, below is an example of some output it gave me on an app I’m currently working on with Rails 1.2.3…

Your application doesn't seem ready to upgrade to Rails 2.0. Please take a
moment to review the following:

-- breakpoint server -----------------------------------------------------------

  The configuration option has been removed in favor of the better ruby-debug
  library.  (changeset 6627)

    gem install ruby-debug

  Remove the line(s) from configuration since the setting has no effect anymore.
  Instead, start `script/server` with the "-u" or "--debugger" option (or "-h"
  to see all the options).

  files:
  config/environments/development.rb:12:  config.breakpoint_server = true

-- pagination ------------------------------------------------------------------

  Pagination has been extracted from Rails core.  (changeset 6992)

    script/plugin install svn://errtheblog.com/svn/plugins/classic_pagination

  Alternative: you can replace your pagination calls with will_paginate (find it
  on http://rock.errtheblog.com/).

  files:
  app/controllers/admin/categories_controller.rb:14:  @category_pages, @categories = paginate :categories, :per_page => 10

From the example above its clear that this script gives you at the very least some where to start. I can’t imagine it will find everything. :) Now for that script that will convert all my Rails apps to Merb! ;)

Author Notes: “NOTE: this script does simple, regular expression searches. It might not be right at all times. Consider this script just for informative purposes.”