Getting Git to work properly with a package manager is pretty easy, but after having been through package version hell I only compile things now.

While compiling is normally an easy configure/make/install cycle, you do get the occasional dependency hell. Unfortunately, Git on Tiger is one such situation.

The following worked for me to get Git, Git’s man pages, and git-svn working on OSX Tiger.

First cd to wherever you keep your source files (remember to adjust this path in all the following instructions if yours is different):

cd /usr/local/src

Next lets install an XML parser dependency, Git, and it’s man pages:

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

curl -O http://kernel.org/pub/software/scm/git/git-1.5.3.7.tar.gz
tar xvzf git-1.5.3.7.tar.gz
cd git-1.5.3.7
./configure --prefix=/usr/local
make
sudo make install
cd ..

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

Add the following environment variable to whatever file your shell uses (.bash_profile for BASH):

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

Whew, you now have Git! One cool thing it comes with is git-svn, which let’s you work with existing Subversion repositories. Unfortunately this does not work immediately on Tiger, and you might get an error like Can't locate SVN/Core.pm in @INC when trying to use it. Aw shucks… brave on to use git-svn soon!

First find your existing Subversion source directory, and compile some Perl modules you probably skipped originally:

cd /usr/local/src/subversion-1.4.3
make swig-pl
make check-swig-pl
sudo make install-swig-pl

At this point you can use git-svn, except when dealing with an authenticated repository. The error will look like this Can't locate Term/ReadKey.pm in @INC, but we can fix that too. We will now connect to Perl’s CPAN (if this is your first time, just answer the questions it asks… I mostly hit enter or typed “yes” for everything) and then install something necessary to take your authentication credentials input from the command line:

perl -MCPAN -e shell
install Term::ReadKey
exit

Tada, after quite a journey you are ready to start moving away from Subversion with Git and finally achieve branching nirvana! Let me know if you have any problems in the comments.

Many thanks to Justin Reagor and Rudolf Heuser for their tips.

I was reading TopFunky’s great post on various queue’s that you can use with Ruby, and came across Rick Olson’s particularly amazing BBQ Queue service.

Being immediately inspired, I wrote a complementary version, the InlineBBQ Queue service.

Expect an MIT license on this sucker soon once it goes through at least 2 more production applications.

As mentioned in the comments, I’m in the middle of implementing the service for Rubinius, JRuby, and IronRuby too…. “rbx” and “jruby” are just proving much harder to type than “ruby”.

Note: This is a joke =p

I really like the concept of the Uniform Interface. One of my favorite things to do is spend hours on my whiteboard (and sometimes days) fiddling with ideas that express what I consider to be elegance. This ranges from macroscopic elegance (ie: the architecture level) to microscopic elegance (ie: the function/method level). Somewhere in the middle lies my fascination with sets, my favorite topic in Discrete Mathematics.

I think one of the reasons I like the Uniform Interface so much is that it groups things together into a set (all things that respond to the same method or methods), which lets you conjure up powerful abstractions at any point in the macroscopic to microscopic elegance scale.

One reason I like REST is because of its HTTP implementation’s Uniform Interface, the most common request methods being CREATE, UPDATE, PUT, DELETE, and HEAD. Programs using MapReduce also use a Common Interface for both the map and reduce functions… and there are many, many more examples.

The difference between the Uniform Interface and Interface Polymorphism is subtle. The Uniform Interface is more general (ie: applying to REST, which is a service), whereas Interface Polymorphism specifically applies to programming. Thus, Interface Polymorphism is a specific kind of Uniform Interface.

The term “Duck Typing” is mentioned in Ruby circles sometimes, and it’s mostly just another name for Interface Polymorphism. This is probably because Ruby has no such thing as an interface. Java on the other hand does, which is how I learned about the concept first. In Java, if a class implements an interface then it absolutely has to define the interfaces methods in its class definition. In Ruby, duck typed methods simply have to be defined by the time an object is called (even if they weren’t there during the objects initial class declaration, or even during the objects initialization). Notice I used the word “object”, but don’t forget that in Ruby a class represented through a constant is an object too. So, the only difference is that Duck Typing is more often used when talking about dynamically adding Interface Polymorphic methods.

Let’s sum it all up with a Ruby class definition and some inheritance.

class DuckTyping < InterfacePolymorphism < UniformInterface
end


As some of you know, when I’m not working I’m taking classes in Information Systems at UCF. One of the classes I took this semester was Web Systems II, which is essentially a server-side course that focuses on ASP.NET development.

One particular assignment was creating a “Category Code Manager”, which I had never heard of previously. I think the professor made the term up, but the concept is simple nonetheless. There are categories (ie: fruits) that each can have many codes (ie: apples, oranges). I think the purpose of the assignment was to get used to working with foreign keys, and building dynamic drop downs as a tool to display this sort of relationship. Another gotcha is that the categories can have parent categories.

The class had a participation grade that I must have overlooked… Needless to say that didn’t bode well for me, so I created this screencast as an introduction to Ruby on Rails (beginner level) using the new Rails 2.0 (final source code included.) I tried to follow best practices where possible (ie: TDD), and covered the topics of:

• Database agnosticism & environments
• Using rake to create databases, and to run
• Scaffold generator
• has_many & belongs_to relationships within ActiveRecord
• The interactive Rails console
• The new integration of the ruby debugger, and a drop of live metaprogramming
• Test Driven Development with Test::Unit
• Intro to REST’ful architecture within Rails

But, I left some things out to avoid making the screencast even longer, and avoid it being confusing for beginners. Just so you all know, some changes I would have made include:

• Create some helper methods for things like populating the select tags
• Use nested routing (I did this first, but renaming all the named routes, having to explain the routing, etc made this too complex for a beginner video)
• Use RSpec for testing (RSpec’s scaffold uses mocks and stubs, which are just a little too much to explain when already introducing all of Rails and testing)
• Use a REST’ful abstraction plugin (we developed an internal one at work, but unfortunately we haven’t been able to open source it yet… until then check out make_resourceful)
• Use the ObjectMother pattern for creating objects during tests

Enjoy the screencast!