Paul Dix Explains Nothing

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

RailsDay 2006 Thoughts

I participated in RailsDay 2006 over the weekend.  It was a lot of fun and a real learning experience.  Here are the details and some of my thoughts on how everything went.

Trotter Cashion and I worked on an app for doing search across multiple engines with features like history tracking, alerts for when results change, differences between engines on the same search term, and search within only urls that you've visited over a certain time frame (at least that's everything we wanted the app to do).  We submitted under Matt Pelletier since Trotter and I were both too disorganized to get registered in time.  Matt was originally going to join and lead us on our effort, but work got in the way so Trotter and I forged ahead without him.

First, some information about the application idea.  We had trouble coming up with something to write.  The time limit, the fact that it's open source, and trying to do something other than yet another todo list or blog made it real difficult to think of something interesting.  I came up with the idea a few days before the competition and discussed it with Trotter.  We both thought it was interesting enough to pursue and might turn out to be a fun little project.  We wanted to make something that had some lasting utility beyond the competition.  Even if it were only a small chunk of code from the project we wanted to contribute to the community.  Our thought was that we could provide a unified api for doing search across multiple services.  Something that would be designed to run in Rails, yet not dependent on it.  Alas, I think we fell short of that goal. 

Our initial goals were to write the api to include connectors to Google and Yahoo with the hopes that we could include Technorati as a bonus.  We didn't really research things before the actual competition so we weren't sure what libraries were out there, if any.  It turns out that there is already a Yahoo API in Ruby written by Robot Co-op.  We used it to make things easy and found that the SOAP interface for Google was pretty straight forward.  Because of the time constraints we didn't get to trying to connect to Technorati or any other more standard search engines.

We ended up implementing only a simple search feature that grabs the top 10 results from Yahoo and Google.  It shows which ones show up in both and the others that are unique.  We implemented the history tracking of what links you followed and search histories, but we didn't have time to include any useful features around the stored data.  The alerts piece of the application was dropped entirely.  We used acts_as_authenticated for the login system.

For next year I would definitely do some things differently.  First would be the logistics.  Trotter and I didn't really have a place to work from.  We met up at a coffee shop in the morning, but they wouldn't allow us to plug in and the wifi was very spotty.  We ended up working out of his apartment, but not before we wasted a number of hours.  Next time I would scout out a place that is open most hours that is comfortable enough to work in and will allow us to plug in our systems.  Second would be the planning of the application.  We wrote absolutely nothing down before we starting working on the app in the morning.  It would have been a good idea to have everything well planned out and designed on paper.  That way we could jump right into the work of coding when the competition begins

All in all it was a fun competition and a great learning experience.  Trying to write a fully functional application in a 24 hour period really shows you where your weak spots are.  Other than my general newbie status to ruby and rails, I desperately need to work on my design skills.  The campfire chat that was going for the competition was surprisingly active.  I took my standard role of lurking in the shadows, but I did see some familiar names having intelligent Rails related conversation.

If you're interested, here is the source code to RailsDay 2006 Search.  Do whatever you want with it just don't judge us too harshly.  If you're actually motivated enough to see it run you just need to install the yahoo-search gem like so:

    gem install 'yahoo-search' --include-dependencies

You need to be running 0.8.11 or better of the gem package.  Trotter had a problem with 0.8.10 where it kept looping on a dependency and failing to install properly.  Once you've created the database just run rake migrate, start your local web server and you're ready to rock.

Technorati Tags: RailsDay, ruby on rails

Code for Nine Men's Morris

This is very late, but here's the info on my Nine Men's Morris algorithm.  I ended up writing it in C++.  I'm still new to the language and I was working with it at the time for another class.  Ultimately the decision  to use C++ was based on getting more experience with the language while benefiting my studies with the other class.  Here is the code to Morris.  It's a Visual Studio project, but I didn't write anything Microsoft specific (I'm just too lazy to write a makefile and test building it).

While I did well on the project as a graded piece of work, my showing at the tournament was quite poor.  I attribute this to running out of time, which is my own fault.  I didn't spend nearly enough time tuning my eval function to determine the 'goodness' of a board.  I actually wrote the program to be able to play against itself using different eval weights and/or different eval functions.  I had grand plans to have it play hundreds of games against itself testing different weights.  Unfortunately, I ran out of time and had to submit the project.  Thus the most import part of the program received very little attention.  I also wanted to implement some form of killer heuristic so the program could get further down the game tree.  The current version gets anywhere from 4 to 8 moves down the tree given a 10 second window.  Deeper game tree = better moves.  Suprisingly it still managed to beat me every time I played it.  I guess this just shows how poor of a player I am.

Some observations from this project:

1. Visual Studio is a kick ass IDE.  I knew this from my .NET dev days, but all my C++ projects up to this one were written in vim.  I forgot how much I love the integrated debugger and intellisense (code completion).  If you can use Visual Studio for a C++ project I don't know why you'd use anything else (other than a fanatical hatred for anything Microsoft).
2. I probably could have written this in any language.  My guess is that the algorithm would have been able to get the same distance down the game tree in Ruby, Lisp, C#, Java, C++, Python or whatever.  The choke points were when the branching factor got out of hand and there were just too many game nodes to evaluate.  Differences in execution time probably wouldn't have mattered with this kind of exponential expansion.
3. Writing code in C++ makes me really miss dynamic languages like Ruby.  This program could probably be written in 500 lines in a much shorter amount of time using a dynamic language.
4. Writing the program in Ruby probably would have resulted in a better performing (better move decisions) algorithm.  This is becasue I would have had more time to focus on improving the eval function and adding in some killer heuristics instead of wrestling with the language.  All this despite the fact that I'm still a ruby newbie.

Here are some notes about the code.  There are six classes and the main driver representing around 1500 lines.  Some of it is ugly as all hell, but I tried to put in comments where I thought things might not make sense.  Most of this is the result of a marathon weekend coding session.  There is a known bug in the GameController class.  I know what it is and how to fix it, but I ran out of time at the end and didn't have a chance.  It's not fatal and I'm leaving out the details just to see if anyone is curious enough to poke around and find it.  The meaty interesting sections are the eval functions and the ab mini-max implementation.  There are six eval functions: three test and three production for each stage of the game.  These can be found in the Board class.  The ab mini-max implementation can be found in the GameController class.