Paul Dix Explains Nothing

Scotland On Rails Wrapup

This isn't a full wrapup, but I wanted to at least post code and slides from my talk. Here are the slides. If you're going to be at goruco at the end of this month, no peeking! In part of my talk I presented a Twitter friend recommender. It comes in two files:

twitter-friend-getter.rb and twitter-recommender.rb

If you run it against someone that has more than 69 friends, you'll have problems because of Twitter's API request limitations. Keep in mind that it's just a one off script that I used as an example for this talk. Feel free to do with it whatever you'd like.

The conference was a lot of fun. I wish I had a little more time to check out Scotland and also to hang out with the other speakers. I was busy beating my slides and code examples into shape until Saturday morning. I did get a chance to meet a bunch of smart people and put faces to some online names.

Alan, Paul, Abdel, and Graeme, thanks for organizing the event. Alan, no worries on the confusion Saturday night. You were super busy and I didn't make a point of trying to introduce myself and hang out earlier in the conference (something I regret). I think everything went very smoothly. My only issue was that I would prefer lunch a little earlier in the day (12 instead of 1).

The talks and overall quality of the conference were great. I always like to pick one thing as a primary take away from the technical content of a conference. From SoR I would say it's jRuby. By the looks of it, it's an immediate replacement for MRI. I'll be spending some time with it over the next few weeks, but if it's as good as it looks it will be what powers Tahiti.

Technorati tags: scotlandonrails, twitter, collectiveintelligence

Speaking at Scotland on Rails

I'll be giving a talk titled "Collective Intelligence: Leveraging User Data to Create Intelligent Rails Applications" at Scotland on Rails! The title is a bit of a mouthful. It translates roughly into a talk about recommendation systems (like Amazon). Recommendation systems are sometimes a subset of machine learning, so it's a topic that I'm really excited about. I can't wait to help show that Ruby and Rails can be used for solving hard problems too.

Scotland on Rails is a two day conference in Edinburgh on April 4th and 5th. My friend and colleague Bryan Helmkamp will also be there presenting on Story First Development. It's the perfect excuse to make a trip to Scotland! If you need more motivation, take a look at the list of talks.

Introduction to Rails @ Columbia

Earlier this week I gave an introductory Rails talk to fellow computer science students at Columbia. It was a student organized event with a pretty decent turnout of 30+ people.

Thanks to everyone who attended. Here are a few pointers if you're interested in digging into Ruby and Rails:

Links
A decent Rails 2.0 compatible walk through by Fabio Akita

Books
The Rails Way by Obie Fernandez (a Rails 2.0 must)
Programming Ruby "the Pickaxe book" by Dave Thomas (required reading for any ruby coder. Make sure to get the 2nd edition and NOT the 3rd.)
The Ruby Way by Hal Fulton (a classic with a cookbook approach. Great reference)

I've taken Agile Web Development with Rails off my list of recommended beginner reading until it gets an update for 2.0. I think that the walk through as an introduction with a little bit of reading through Pickaxe should be enough to dive into The Rails Way. There are a ton of other Rails books out there about how to build a social network or some other thing. I haven't read any of those so I can't comment on their quality, but I have thumbed through and read a little bit of Obie's book and can say that it's pretty comprehensive. It's also probably the most up to date book on the market.

Screencasts
Defintely check out Geoffrey Grosenbach's Peepcode screencasts. I watched the Rspec and Git screencasts and thought they were great. The beginner should check out Rails From Scratch part 1 and Rails From Scratch part 2, both of which have Rails 2.0 updates. Those actually may be the best way to start before digging into Obie's tome.

Also check out the free Rails screencasts put together by Ryan Bates.

At the beginning of my talk I listed a bunch of NYC companies that wanted to be listed as interested in recruiting Columbia students that want to get into Rails. Here is that list:

1. Mint Digital
2. EastMedia Group
3. Motionbox
4. StreetEasy
5. LimeWire
6. Indaba Music
7. Bear Stearns
8. thoughtbot
9. curbed.com
10. www.mirRoRplacement.com
11. Agile Partners
12. Medidata Systems
13. Arvato Systems
14. TechSmart Solutions Group
15. www.4elbows.com
16. www.recyclebank.com
17. myJambi.com
18. www.chalq.com
19. Climate Culture

 

Hopefully I did my little part to help spread the Ruby and Rails gospel into the ivory tower.

ActiveDocument: More than just a document store

Last week I met up with Sebastian, Jake, and others to talk about ActiveDocument and Thrudb. Rick Olson (aka technoweenie) and Ross McFarland (a Thrudb contributor) were also in attendance in #activedocument on freenode. Before I talk about that, I'd like to give out some informational pointers. We've all decided to focus in on Rick's ActiveDocument implementation to bring our efforts together. Sebastian also set up a Google Group for ActiveDocument.

We spent our time asking Jake a bunch of questions about the future of Thrudb and trying to figure out how ActiveDocument could become an alternative data layer for Rails apps (replacing ActiveRecord). There are many pieces to the project, but they reach well beyond being a simple document store. The major parts include Thrucene for indexing, Thrudb as the document store, Thruqueue as a message queue, and Throxy to proxy requests and provide load balancing between Thrudb and Thrucene instances. If AD is going to replace AR and an RDBMS, we'll have to take advantage of most of these pieces.

Thrudb is still very much in development. There isn't an official release and Jake has stated that it will probably just be in the subversion repo for a while. I believe that Throxy still has some work before it's ready, but it's high on the list. That being the case, it will probably be a little while before ActiveDocument has a release.

However, we still came up with some design and implementation things we're thinking/concerned about.

• Support for multiple serialization formats. Thrudb exmaples use Thrift as the serialization format, AD includes that and JSON.
• How to deal with concurrency, locking and counters. Thrudb uses atomic writes where the last write wins. If a group is a document and the membership is stored, how do we deal with two processes updating the group membership at the same time?
• Ability to support other document stores or indexes. Jake is separating Thrudb out into its constituent parts so it's conceivable that you could use SimpleDB as the document store and use the rest.
• Thinking outside the RDBMS box. AR provides great built in finders and relationship functionality. How much of this should we try to replicate and what other things can we include that just wouldn't have been possible in an RDBMS?
• Speed for writes and updates. Rick posted some metrics on ActiveDocument vs. ActiveRecord. The write speed is slow due to an update to the index each time a record is created or updated. Jake tells me that this problem only gets worse as the index grows in size. He's actively working on this and has recently improved it quite a bit. However, it still highlights that index design is important when thinking about how an AD schema will be set up.

I haven't had a chance to actually do more development on this. Right now I'm still hacking on Tahiti, but I'm pretty sure that it will use AD and Thrudb in some capacity. I'll post more details as these things develop.

Technorati Tags: activedocument, thrudb

Deployed Rails Stack on Slicehost

I picked up a Slicehost account a few months ago with the intention of launching a site some time this summer. I've been super busy with Google and trying to gemify my machine learning code so I haven't had a chance to start using it yet. Well the gem is mostly done and I'm awaiting a little code review from Trotter so I finally had a little time to get things set up.

It turned out to be easy as hell thanks to capistrano and deprec. Capistrano is the handy ruby library for automating deployment tasks and deprec is just a bunch of Capistrano recipes to install the full server stack. I won't cover the details since they're documented quite well in this deprec post by Craig Ambrose and this PeepCode screencast by Top Funky and this post specific to deprec on slicehost.

Thanks guys, anybody who makes installing a full server stack that painless is on my list of heroes.


Technorati Tags: deprec, capistrano, rubyonrails

RailsConf: Day 2: Ajax, Deployment, DSLs, and other miscellany

I'm well into day 2 of RailsConf.  I would like to keep live posting about each session, but I'm getting a bit overloaded.  Here is some info from the sessions I've gone to so far.

First was Ajax on Rails by Justin Gehtland.  This session covered the ActionView ajax helpers and some RJS.  Justin's presentational skills were great and his talk was well polished.  The information wasn't new to me, but he did show off a couple of cool things.  He's working on a replacement for scaffolding that is very ajaxy.  I was very impressed and can't wait to play around with it.  At a glance it seems like it has a lot more to offer than AjaxScaffold.  Justin said that it would be released at OSCON next month and you can watch the streamlined site for details.

Next was Domain Specific Languages by Steven Hammond.  He covered what a DSL is, and some examples.  Rails examples are the framework itself, migrations, RJS, acts_as_state_machine, and game_dsl (the last two being plugins).

Bill Katz then dug deeper into DSLs, and other topics, with his presentation on Metaprogramming Writeopia.  The talk centered around how he designed and implemented a DSL for his authorization plugin.  Bill's DSL is interesting because it wasn't based on Ruby at all. There would be something like a call to see if someone has a permission:

permit "admin of :meeting or admin"

As you can see the DSL is contained within the string passed to permit.  Bill caught some flack for using a string instead of tweaking ruby syntax.  He said a string was better suited for the exact syntax he was aiming for, and I think the result is very readable.

I then went to Rails Deployment presented by Ezra Zygmuntowicz.  Ezra started with a case study of his work on The Yakima Herald.  Some things that I heard about in this session:  use a VPS (virtual private server) instead of a shared host.  Make sure your VPS provider is using Xen.  Xen is fast and the provider won't be able to oversell the server so you can get guaranteed resources.  Mongrel cluster + Apache 2.2 == the new hotness.  I actually knew this already from talking to Zed Shaw at the nyc.rb meetings, but I'll put it out there for everyone else.  BackgroundDRb is a project that Ezra has been working on for running background worker tasks in Rails applications.  I'll definitely be checking this out.  Ezra is working on a new hosting company called EngineYard.  It's all based on VPS and it looks like they're aiming for pushbutton deployment of Rails clusters for serving up highly available, fault tolerant, high traffic rails applications.  Cool stuff.

Hopefully I'll have time next week to go through and actually process all of this information I'm pulling in.

Technorati Tags:  RailsConf

RailsConf: More Sutff!

The adventures at RailsConf continue!  I went to a few other sessions and watched Martin Fowler's keynote.  I'll have to put some thoughts together on those.  Maybe I'll have time at the end of the weekend. 

Paul Graham just finished his keynote, which consisted of him reading his new essay.  I liked this one much more than the last few he has put out.  This one reminded me of his earlier stuff about startups, nerds, and outsiders.  I'll leave the details of his essay to when he releases it into the wild.

I can say that this essay (or talk), like his earlier work, left me inspired.  Inspired to do new things, take risks, and enjoy the work I do.  It was a great keynote!  Maybe I'll write more about this later, but right now I should really be paying attention to Why the Lucky Stiff and the Thirsty Cups.

Tehcnorati Tags: RailsConf

RailsConf - Intro to Capistrano

The first session I attended was Intro to Capistrano presented by Mike Clark.  Capistrano, formerly known as SwitchTower, is a ruby gem that makes deploying web applications dead simple.  It was written by Jamis Buck who, unfortunately, wasn't there today.  Capistrano works great with Rails, but its usefulness isn't limited to just Rails.  Mike's presentation was great and covered the steps for setting up "cap" from the install to configuration to first time deployment to revision deployments to custom tasks for doing other things.  I haven't had a chance to use cap yet, but after hearing Mike's presentation it's on my list of "things I have to use".  Here are my unedited notes from the session:

Install Cap:
  gem install capistrano
Setup with your App:
  cap --apply-to /path/to/my/app MyAppName

Recipe file holds the information
  Names of serves and Roles.  app, web, and db are predefined roles.
  There is a concept of a primary server.

  where the deployed code goes:
    set :deploy_to "/library/rails/#{application}"

Now you need a deploy target.  This sets up every server you have configured in the recipe.
  cap setup

First time to deploy:
  cap update_code symlink
That will do a svn co (if you're using svn) on every machine with a role.
Now when there is a new release read:
  cap deploy
To revert a deployment:
  cap rollback
You can rollback multiple times to previous versions.

Other commands:
  cap disable_web
  cap enable_web
This puts up a maintenance screen.  If you're running multiple web servers and you need to update the database with migrations or something.
  cap diff_from_last_deploy

You can set up your own tasks.  You can set them to run only on machines with a certain role.
You can chain multiple tasks together.
Set up channels and streams.  This is good because you can use it to tail the log files on the servers.
Task hooks.  Run something before or after another task runs (like deployment).
Use it for multiple configurations like development, production, and test.
A great example of this are libraries for cap.
  gem install capistrano-ext
This particular one outputs load information.  This library is good to look at to learn how to write capistrano extensions.

Capistrano Assumes:
remote servers talk POSIX
same deploy directory structure and password on each machine
web app uses FastCGI with Apache or LightTPD
  *it's easy to make this work with mongrel

Technorati Tags:  RailsConf, Capistrano, Ruby on Rails

RailsConf is Go!

We're into the first day of RailsConf!  I've met a bunch of cool people and I'm again amazed  at how vibrant the rails and ruby community are.  This morning Dave Thomas gave a keynote.  He started with some stats about the adoption of Rails and highlighted how amazing the rise of the platform is.  Dave then issued a challenge to improve rails.  He aimed this not the core team, but the community at large.  He listed three primary issues that he would like to see addressed: Data Integration, Real world CRUD, and Deployment.  Here are my unedited notes from the talk about Dave's three issues:

* Data Integration
better use of schema.  use schema constraints.
  add validation based on the table schema. 
  work with database foreign keys.
    add belongs_to if fk exists
    make it easy to define in migrations
  primary keys
    better support for non-integer pk's (in migrations)
    support for composite pk
  support for distributed transactions
  standard attribute based finders
  better support for non-database models

* Real-world CRUD
scaffolding needs to be updated
  supports table relationships
  ability to configure scaffolding
  in-browser validation
  AJAX
  cross application skinning
  bring simplicity of AR to views and controllers

* Deployment
capistrano (DT loves it)
  but it doesn't follow the model in the real world.  in the real world developers know what to deploy and the server administrators know how to deploy it.  cap assumes that the developers are responsible for everything.  DT wants a more cooperative deployment model.
  server config
    nominate server roles
    where files go on each server
    user names/permissions/security
  deployment
    set up server once
    set up individual applications as needed
    send application config to server
      server checks dependencies, etc
    stages application to server
    installs (or not)

    ISP set up standard environment
    developers and users deploy.  that way the deployment steps are the same across ISPs as long as they support the cap config.

Technorati Tags: RailsConf, Ruby on Rails

RailsConf Approaches!

I'm headed to RailsConf later this week!  I lucked out and picked up a ticket at the end of last week.  I'll be headed over with the East Media crew, which includes among others: Lee Nussbaum, Trotter Cashion, Matt Pelletier, and Zed A. Shaw.  Zed is the author of Mongrel (a kick ass ruby web server), Matt is giving a talk at the conference on Sunday, and Lee and Trotter just kick general coding ass.  So I'll be in great company!  I know a number of other NYC Rubyists will be going.  It should be a great time and I hope to meet a bunch of people there!  If you're going, drop me a line or just look for me at the event.  I like to talk about all things nerd.  Here's me in the RailsConf Facebook.

Tehcnorati Tags:  ruby on rails, RailsConf