Cry is a Ruby library that provides a nice object oriented way to create, transfer, and manipulate frozen parse trees. The idea behind the name is that you end up writing in parse tree format, in a syntax more verbose than CLOS… hence “Cry” =) In reality Cry would mainly be used in meta-programming though, and is designed to have a simple & consistent api.

Let’s say we have an instance of an “Account” class stored in the local variable “acnt”. It has a “withdraw” method that takes an “amount” parameter.

In Ruby you would normally call this method like so:

acnt.withdraw(50)

In Common Lisp’s CLOS you would do it like this:

(withdraw acnt 50)

Notice that because CLOS deals with objects, the second parameter is the instance of the class that the method will be called on. Cry copies this parameter order in its parse trees:

Cry::ParseTree.new(:withdraw, acnt, 50).evaluate

In Ruby classes are just instances of the “Class” class. Thus, the syntax for class methods remains the same:

Cry::ParseTree.new(:sqrt, Math, 16).evaluate # => 4.0

Another neat thing is that the parse tree instances are not evaluated until you call the evaluate method. This lets you pass them around, similar in concept to Procs (aka lambdas.)

parse_tree = Cry::ParseTree.new(:+, Cry::ParseTree.new(:*, 2, 3), Cry::ParseTree.new(:/, 16, 2)) # => (:+, (:*, 2, 3), (:/, 16, 2))

parse_tree.evaluate # => 14

Notice that the object and any of the parameters can each be parse trees as well (and even those can continue recursively nesting parse trees with their respective objects and parameters.)

There are also convenient getter methods for our parse tree components:

parse_tree.node_method # => :+

parse_tree.node_object # => (:*, 2, 3)

parse_tree.node_arguments # => [(:/, 16, 2)]

Similarly, there are setters that could be used like this:

parse_tree.node_object = parse_tree.node_object.evaluate # => 6

parse_tree.node_arguments = parse_tree.node_arguments.map{|p| p.evaluate } # => 8

parse_tree.evaluate # => 14

The previous example takes components of our parse tree and evaluates them separately, then sets the results back. This opens up possibilities for having a very deeply nested parse tree, and evaluating certain sections in parallel.

In traditional Ruby the above can be explicitly written like so:

2.*(3).+(16./(2)) # => 16

The big difference is that this would be evaluated immediately, whereas you can delay and manipulate the whole structure by using a parse tree.

We previously used setter methods to manually evaluate the parse trees for the object and arguments. However, we could also change something, such as the object:

parse_tree.node_object = 5

parse_tree.evaluate # => 40

Or, we could change every part of the parse tree:

parse_tree.node_method = :new

parse_tree.node_object = Array

parse_tree.node_arguments = [5, 9]

parse_tree.evaluate # => [9, 9, 9, 9, 9]

Certain methods are defined with blocks, for these simply pass in a Proc as the last argument:

# Traditional Ruby

[1, 2, 3].inject(2) {|sum, i| sum + i } # => 8

# Cry::ParseTree Ruby

parse_tree = Cry::ParseTree.new(:inject, [1, 2, 3], 2, lambda{|sum, i| sum + i })

parse_tree.evaluate # => 8

Cry::ParseTree extends from Array, and internally stores the method, object, and arguments in that order respectively. Knowing this, we could have done the following to switch out the block to be used for our parse tree:

old_block = parse_tree.pop

parse_tree.push lambda{|product, i| product * i }

parse_tree.evaluate # => 12

We have access to all methods Array does, so this would work too:

parse_tree.each {|p| puts p.inspect }

:inject

[1, 2, 3]

2

#<Proc:0x0005526c@(irb):67>

=> (:inject, [1, 2, 3], 2, #<Proc:0x0005526c@(irb):67>)

That about wraps things up. If you would like to follow development, or fork/contribute to the project, you can find Cry on github. Even if you just wonder if something will work, feel free to try out your Ruby parse tree masterpieces by adding funky ones as tests.

In case anyone is interested, I made this so I could have an easy datastructure to manipulate when dealing with Genetic Programming algorithms. I’m working on an interesting project that involves them, and will be sure to put it on github and make a post when it’s ready.

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!