While I was zipping a drink at the pool in Spain and visiting friends and family in Switzerland, the team at Gatelys.com was busy designing and configuring two new ecommerce stores using the Rails eCommerce platform I worked on while a Gatelys. And they have many more ecommerce sites to come.
Rails is open for some serious business.
Note that most of the logos, graphics and layouts are done by Lomax which is the best graphic designer I know. Now if only I could find a way to hire him away 🙂
This complements www.nationaltabletennis.com that was launched a couple of months ago:
Since Daniel came back from Europe, I figured I’d finally pick up his slack and write an entry. 🙂
Last night I went to the Boulder-Denver Ruby Group where Chad Fowler spoke about all things RubyGems. It was a laid back talk with a recap of gems past, present and future. Pre-RubyConf 2003 the ruby-talk list would get peppered with questions like
“Where is Ruby’s CPAN?”
At RubyConf 2003, when put on the spot by David A. Black about the topic, Matz basically said
"if you build it, it will be included in ruby core. That led Jim Weirich, Rich Kilmer, Black, and Fowler to spend the next night coding what would become the RubyGems. They even demo-ed it at the conference. It has grown quite a bit since then and now could be called the de facto standard for library distribution in Ruby.
The latest version of RubyGems is 0.9.0, which has some not so minor scalability improvements. To get the latest version simple run
gem update --system. Since RubyGems isn’t in core yet, you still need to
require 'rubygems' or set your
RUBYOPT environment variable to
rubygems. There is another way when starting ruby you can pass it the
“But you said it wasn’t in core… if it’s not in core, why does it have it’s own argument for the ruby interpreter?”"
It’s true, it’s not in core. This is actually just a little trick by Chad et al to make it look it is part of ruby. The
-r argument tell ruby to require whatever parameter follows, so the gem crowd made an
ubygems.rb file that only has one line of code in it …
require ‘rubygems’ … and from that comes
Bundled with gems is its own
gem_server. Firing this up starts up a WebBrick server on port 8808 by default. Going to http://localhost:8808 will then display all of the gems you have installed and even link to the rdoc installed locally if it exists and to the docs on the web. It also can serve gems if you wish. This means other machines could point to your gem_server and install any of the gems that you have installed. You do this with the
--source argument. Others could search what gems you have by running
gem search -r --source http://your_machine:8808 search_string. There is even a tool
index_gem_repository.rb that will create a directory that can be served by apache as a gem server, in case you want something a little beefier than webrick.
One interesting idea that Chad mentioned was making a meta-gem for your projects. All the gem would declare is its dependencies on the other gems that your project needs. That way when setting up a new machine you can just install your meta-gem from your gem_server and then it will automatically install all the necessary gems. Pretty cool.
Chad did a good job of describing how gems came to be and guiding us through some of the code with some nice anecdotes along the way.
P.S. The coolest part of the night was I’m going to be a volunteer at RubyConf `06! Chad was quick to warn me that there is no glamour involved. Oh well, I’m excited anyway.