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!

I’ve been doing a lot with REST and ROA on and off the job lately (mainly with Eric and Dray, who still does not have a blog.)

The way Rails implements resources is through Controller classes. One thing that came up yesterday, was the argument that the implementation is improper due to the inclusion of both an index and a show action in one Controller. In REST, a resource can be its own entity (ie: an apple), or a collection of of entities (ie: a fruits resource composed of apples, grapes, oranges, etc.) At first glance, the challenge to Rails Controllers seems to stand because a GET to the index action returns a collection of resources, whereas a GET to the show action just returns one resource.

Upon closer inspection though, you’ll see that the confusion comes from focusing on Controller actions. What should really be looked at is the resource (the controller), and how those two requests are addressed (the URI.) Firstly, notice what kind of resource we have… it’s a fruits resource. Next, look at the URI, it is /fruits.

Now that we’ve established that our FruitsController represents a plural resource (a collection of fruit resources), we can move on to explaining the confusion that the index and show actions introduce. A request to /fruits will return all of our fruits. But, the world has many fruits and we don’t want to request them all. Instead, we will fire a GET at /fruits?page=2?limit=10. Although most of you will recognize this as simple pagination, in ROA it is known as the concept of addressibiliy to indicate state in the URI.

Here’s where the confusion is cleared: a request to /fruits/1337 is not requesting a singular resource (in this case a cherry, the most elite of all fruits.) Instead, it is requesting a collection resource (fruits) but using addressibility to indicate state. It is okay to use the URI in REST different ways for addressiblity, because REST is a style and does not have a specification for addressing via URI’s. For example, another way of getting to /fruits/1337 might be /fruits/?page=1337?limit=1.

As a closing note, even though we used the fruits resource collection here and addressed cherry, we could have done it differently still. If you really wanted a singular cherry resource, you can do so in routes.rb by replacing map.resources :fruits with map.resource :cherry (notice that “resource” is singular.) This would map to a singular CherryController to implement the resource. You could access it with a get request to /cherry, which would map to the show action (in this case the index, or list, action does not make sense because cherry is singular.)

Jimbo Wales, founder of Wikipedia, will be speaking tonight at 8 P.M. on C-SPAN. The topic is the “Future of the Internet“, and one of the more interesting things that will be discussed is Wikia’s new wiki-based search engine being worked on.

With my recent involvement in trying to promote BarCampOrlando, seeing this kind of content on T.V. and especially in politics is a very pleasant surprise. I came across this flipping through channels and landing on C-SPAN right as the text blurb about Jimbo flashed by. They were talking about the Baghdad Embassy Contruction and mentioned a word that sounded very close to BarCamp… so I was REALLY excited for a second there =p I also recently sent out a personal email to Jimbo asking him for any involvement whatsoever in BarCampOrlando, since he lives in St. Pete, Florida and was quoted in the local Orlando Sentinel complaining about the lack of BarCamps and unconferences in the area.

I’ve recently been doing some very fun, elegant, and exciting things with Ruby at work and in my personal time. Although I have to admit that I learned Ruby because of the amount of hype Rails got on Digg back in the day, I am proud and overjoyed to consider myself a Ruby developer now.

Even though these bits of knowledge are obvious to advanced Ruby developers, I think there is value in recognizing these in context and expanding upon them. Below is my version of a summary of a presentation, courtesy Glenn Vanderburg.

• Punctuation gets in the way for short lines, but makes long lines more readable (this applies to the use of single versus multi-line blocks too.)
• The minimal syntax to open and close blocks makes their use feel natural. This naturalness is powerful, because blocks seem to allow powerful abstractions to be developed without much thought.
• Sigils are used for scope (@@, @, CAPS, $, etc) rather than typing (like in Perl.) This use of sigils helps, because the most common scopes (classes and local variables) do not have them. However, they provide an effective language feature that eliminates an annoying standard like using an underscore before instance variables (Java.)
• There are usually two (or possibly more) ways of doing something, allowing for the coded implementation to fit the context.
• Mixins/modules cannot create instance variables (because they cannot be instantiated), but they can reference them (because the instance variables spring into life inside of the object the module is mixed into.)
• The Enumerable module, along with blocks, allows Ruby to apply some functional programming techniques.
• Operator overloading.
• “Three-quals” (===) allows for beautiful case statements by defining the concept of a match.
• “Open classes” allow for nice common interfaces and DSL’s to be defined when patterns are discovered (ie: Rails’ blank? method on NilClass and String.)
• Classes being defined can execute code on themselves to define themselves further because they are objects.
• Although classes are just object instances, creating them still uses a declaration (unlike Smalltalk) and feels natural.

As a closing note, Ruby makes trade-offs in its design like any other language. These range from dynamic typing (which makes tool creation harder), to the “Principle of Least Surprise” (which make consistency harder), to many other things.

Glenn points out, and I agree, that Ruby seems to strike all the right balances (big ups to Matz.) However, this is a personal preference and we should respect the languages choices of others as a matter of taste… there’s room for everyone =)

BarCampOrlando is an opportunity for the Central Florida tech crowd to finally come together.

At BarCamp people from diverse groups, comprising of developers, designers, bloggers, and people that just plain love the web, can get together to share information, talk, and have a good time. It’s events like this that spur discussion to shape the future of the net, which makes BarCamp one of the most exciting conferences to attend. Best of all, it’s free and open discussion is encouraged, if not required!

My first BarCamp was in Jacksonville, and that’s where realized how serious blogging is thanks to presentations by Josh Hallet and Joey Marchy. I want to reiterate that this is just as much about ideas and discussion than presentations on specific technologies.

We have tons of great local user groups here in Orlando, for Ruby, Java, .NET, PHP, Adobe, Linux, Ubuntu, Creatives, and probably some things I’m forgetting. Additionally, the similar Refresh06 conference was a blast. I think we have an extraordinary opportunity to create an amazing event, so show your support by blogging about it and putting badges on your sites! Without blogging and your help, events like this don’t happen.

I’ll end this with a video explaining BarCamp and its history… see you there!

Wow… RailsConf07 was absolutely amazing. The interesting thing is that I am not talking about the presentations, although they were top-notch. Instead, the Rails community is what made this conference so… heart-touching, even.

Chad Fowler directly announced that he picked the keynotes and sessions as his personal mold for what we should be thinking about. To this end, I thank him deeply for his choices.

While there, I came to recognize the Rails community in a new light. I don’t think I could have understood this unless actually being there either (as cliche as it sounds.) Our community stereotype as elitist, arrogant developers did not show its face.

I hope that the community stays like this, and that everyone has a chance to go to at least one conference like this.

All of the attendees were teeming with positive energy and friendly. The diversity of people was great, including people from different states and countries, and people in suits (maybe one or two) to people dressed like hippies and supermodels (you can guess here…). Breakfast and lunch was served in an enormous open room full of tables and seats. But, everyone there was inviting, and immediately started conversations naturally. This was true of people in the hallways too, and included speakers and even DHH himself. Chad even told us to introduce ourselves to somebody new during one of the breaks, although this was happening naturally anyway.

The ad-hoc organization of lightning talks and RejectConf led to some of the more interesting demonstrations. Similarly, post-session conversations with speakers that led to group discussions, which then led to BoFs ,fully capture the spirit of the conference. The BoFs in general stood on their own as hallmarks of open, informative discussion… not just presentation.

Each day opened with one of the hilarious Mac VS PC spoofs by Gregg and Jason. Keynotes were accompanied by accordion and ukulele (courtesy Joey deVilla and Chad Fowler, respectively), and even a spoof serenade (to the tune of ) to our beloved creator DHH.

DHH stressed the importance of plugins both as a community way to share common functionality and testing-grounds for Rails core-features.Avi Bryant (creator of Seaside) gave a jaw dropping and eye opening talk exposing similarities between Smalltalk and Ruby. He strongly recommending stealing from Smalltalk’s maturity in IDE and especially VM implementations. Specifically, a highly distributed virtually machine network by a local Portland company called Gem
Stone. Supposedly, converting this to Ruby would not be overly difficult. But, it would make Ruby run as fast as Smalltalk, which is approximately 10 times faster than Python (and 3 to 4 times slower than Java).
Besides that, Avi stressed his belief that state is good, and that like wine, “objects get better with time”. In his opinion, that is the path that Ruby should follow, effectively becoming Smalltalk =p. This was not a unique opinion though, as Chad seemed to support Smalltalk. As a bit of comic relief, Avi introduced himself as “from the future” and had a hilarious metaphor from 2001: A Space Odyssey (we are the apes…)

Dave Thomas even attacked the browser with its transition from form based requests to AJAX as a medium for the web. He compared it to a similar evolution of ideas that happened in early computers, and warned to not get stuck in a loop of repeating history. Dave went on to get the audience to come up with more examples of this “cargo cult”, evoking responses as extreme as REST, Mongrel, and Rails itself. Although, he did boldly reject the idea that conferences could ever be a cargo cult =p.

Dave Thomas had a donation-based all day tutorial that raised over $12,000 by itself. After witnessing this accomplishment, Chad Fowler (and many other speakers that followed) encouraged the audience to continue donating throughout the conference. Eventually, a challenge to make this the standard for tech conferences was put in place. It is still going on, so anyone is still encouraged to donate.

As a whole, RailsConf07 was one of the most spectacular things I’ve ever experienced. There were many other interesting things happening, such as the effort to understand how “the enterprise” will fit into Rails, and various thought provoking sessions. But, by far the Rails community showed that it is concerned, responsible, and innovative, and I am extremely proud to be a part of it. If you were there, please take the time to blog your version of the event (and encourage others to do so as well) so the rest of the community can understand what is happening and share the excitement.

I’ve blogged about my gripes with multiple blogs in the past, concluding with an informal protest to only use one.

A specific instance of the problem that I mentioned was having a personal blog in addition to blogging under a company. Well, it turns out that you can have the best of both worlds with little to no effort.

Yahoo Pipes takes advantage of the fact that so many sites and services distribute some form of feed syndication. It allows you interact with feeds from different sources in an absolutely incredible amount of ways. Through graphically playing “connect-the-dots” with various modules and/or filters, you gain an unprecedented amount of easily accessible power to create mashup feeds. Of course you can export these to RSS (or JSON), but they even offer email or mobile exports!… and publicly sharing the “source” file so others can copy your project where you left off and continue it!

Okay enough fanaticism (although it is completed warranted), and lets get back to the topic. Grabbing feeds from separate employee blogs to combine on a company blog has always been an option. However, Pipes makes this so easy that you have no excuse to not use it.

Here’s a simple proof-of-concept… totally usable though. It uses the “fetch feed” module that you pass an RSS url to. Then, the sort module is used to sort for the most recent entries by date published, and even by new blog comments. And then… nope that’s it, just connect to the “pipe output” module and you’re done!
(Note that I only included my blog here in the RSS, but you can add as many as you want to get mixed in by just hitting the “plus” icons):
http://pipes.yahoo.com/pipes/pipe.info?_id=3PcgeID42xGTQKjsy6ky6g

Another cool thing you could do is make a filter to only grab posts out of the feeds to put on the company blog that have been posted under a certain category… sweet!