Litany Against Fear

Gem Bundler is the Future

2009-10-14T00:00:00-04:00

If you haven’t checked out Yehuda Katz’s and Carl Lerche’s gem bundler yet, now is the time. This project replaces the horribly broken dependency resolution in Rails and what we all know and use as config.gem‘s. Ever seen can’t activate $gemname ($gemversion = runtime)? Or maybe my favorite, when it can’t even figure out what gem can’t be activated. If so, read on, bundler’s about to make your life a lot easier.

Yehuda has a great roundup of what can be done (and has been done with the bundler) on his blog. This is going to be a part of Rails 3, so you’re going to have to run into this sooner or later. I was getting frustrated with managing gem dependencies in Gemcutter, so now it’s bundled up and ready as a decent example of the bundler in action.

Enter the bundler

I’m using the edge gem built from their repo, and I suggest you do as well. Hopefully soon they’ll push it to that new gem hosting site I’ve heard so much about.

git clone git://github.com/wycats/bundler
cd bundler
sudo rake install

The Gemfile

Now we’re ready to make a Gemfile. This is basically a specification of what gems should be included in your app. Here’s Gemcutter’s:

clear_sources
bundle_path "vendor/bundler_gems"

source "http://gemcutter.org"
source "http://gems.github.com"

gem "rails", "2.3.4"

gem "clearance"
gem "will_paginate"
gem "sinatra"
gem "xml-simple"
gem "gchartrb", :require_as => "google_chart"
gem "ddollar-pacecar", "1.1.6", :require_as => "pacecar"
gem "net-scp"

only :test do
  gem "shoulda"
  gem "factory_girl"
  gem "webrat"
  gem "cucumber", "0.3.101"
  gem "rr"
  gem "redgreen"
  gem "fakeweb"
  gem "rack-test", :require_as => "rack/test"
end

only :production do
  gem "rack-cache",        :require_as => "rack/cache"
  gem "aws-s3",            :require_as => "aws/s3"
  gem "ambethia-smtp-tls", :require_as => "smtp-tls"
  gem "memcache-client",   :require_as => "memcache"
end

Some notes here:

By default the gem host is gems.rubyforge.org, so I’ve cleared the sources to use gemcutter.org instead.
You can easily specify gems for a given environment and multiple gems with only and pass it a symbol for the environment name. Thank goodness.
The default bundle path is vendor/gems. This won’t work for Rails since it assumes way too much about this directory, so we switch it to vendor/bundler_gems. Note: Yehuda has told me that this will work as normal once Rails 3 is closer/done.

Bundle up!

Now we’re ready to run gem bundle. This pulls down the gems from the given sources along with any dependencies. This basically creates a virtual RubyGems environment right inside of your vendor directory. (I’m cutting some out since the log is so long)

$ gem bundle
Calculating dependencies...
Updating source: http://gems.github.com
Updating source: http://gemcutter.org
Downloading actionmailer-2.3.4.gem
Downloading actionpack-2.3.4.gem
...
Downloading xml-simple-1.0.12.gem
Installing rr (0.10.4)
Installing fakeweb (1.2.6)
...
Installing nokogiri (1.3.3)
Building native extensions.  This could take a while...
Done.

So now in your vendor/bundler_gems directory, we’ve got the .gem files pulled down in cache, unpacked in the gems directory, and the gem specifications are unloaded into specifications. Bundler also makes its own environment.rb for loading the dependencies.

vendor
|-- bundler_gems
|   |-- cache
|   |   |-- actionmailer-2.3.4.gem
|   |   |-- actionpack-2.3.4.gem
|   |   |-- ...
|   |   `-- xml-simple-1.0.12.gem
|   |-- doc
|   |-- environment.rb
|   |-- gems
|   |   |-- actionmailer-2.3.4
|   |   |-- actionpack-2.3.4
|   |   |-- ...
|   |   `-- xml-simple-1.0.12
|   `-- specifications
|       |-- actionmailer-2.3.4.gemspec
|       |-- actionpack-2.3.4.gemspec
|       |-- ...
|       `-- xml-simple-1.0.12.gemspec
`-- plugins

Bundler will also dump gem executables in your Rails.root/bin directory. This means you can then use bin/rake, for example. Running rake as normal should still work though. As for your version control, it’s recommended to check in the .gem’s only, then run gem bundle to unpack/install them. This goes both for new developers and getting code deployed.

Loading the Environment

Now the issue is to load up the bundled environment instead of the system installed one. Start by creating a config/preinitializer.rb, which is loaded first before config/environment.rb:

require "#{File.dirname(__FILE__)}/../vendor/bundler_gems/environment"

Then, in each config/environments/*.rb file:

Bundler.require_env RAILS_ENV

This basically does a require for every gem listed in your Gemfile and their associated dependencies. That should be it! Your app should (hopefully) boot and now you should run your tests to ensure your application is still working right.

If you want to see this all in action clone Gemcutter and follow the contribution guidelines for getting up and running.

Issues

So, I had a few roadblocks with the bundler, and I don’t think it would be fair to not mention them.

The documentation sucks. I’m hoping this will improve before Rails 3 is ready (whenever that is). Maybe a Rails guide would be appropriate, and I’ll definitely help start it.
Gemcutter’s on Heroku, so it’s necessary to check in a lot of the vendored code (in fact, all of the development/production dependencies). New contributors just have to run gem bundle -u to get the test dependencies.
In my staging environment I had to use Bundler.require_env "production". Pretty self-explanatory but I missed it at first.
Shoulda macros just stopped working, since it assumes the location of gems in vendor/gems or vendor/plugins. I had to include this in test/test_helper.rb to make it happy:

Shoulda.autoload_macros(Rails.root, "vendor/bundler_gems/gems/*")

Wrapup

This guide went over how to use Bundler today, with a Rails 2.3.4 app. According to Yehuda, this eventually will be packaged in Rails 3, so the commands will be baked into Rails…so something like script/bundle. The nice thing is that you can use the bundler with any Ruby project, so this is good to know in general.

The bundler is really the future of gem dependency management. If you’re sick of fighting with config.gem‘s or are starting a new app it would be well worth your time to start looking at it. If you’re having trouble with the bundler (or success stories!) feel free to comment here or hop in #carlhuda on irc.freenode.net. Check it out on GitHub if you haven’t yet.

On Gem Forking

2009-10-09T00:00:00-04:00

So, GitHub has recommended Gemcutter as an alternative to hosting gems on GitHub. Of course, there seems to be an outcry, for three main reasons that I can see:

1) Effort must be made to move documentation and install instructions
2) Gem forking is not possible with the new site
3) GitHub gave no warning on this

As for #1, you’ve got a year to update your user base and get gems off GitHub. I’d assume that any actively maintained project has figured Gemcutter out by then. And for #3, at least we’ve got a new service that works and can meet the same needs.

Regarding RubyGem forking, I’d like to state that this statement is false. Gemcutter accepts built gems, so you simply need to mimic the actions that GitHub’s gem builder did: Open your .gemspec up, append your username to the gem name, and save. gem build, gem push, and done.

I think an important distinction must be made here: gem forking != scm forking. GitHub made it easy for anyone to automatically push modifications to gems, but there’s a bigger picture to think of here. Hopefully at some point, the changes you made will be brought back into the mainline gem. As David Dollar so eloquently puts it:

I think the general idea is that gem forks should be a huge special case. I’m somewhat of the mind personally that making gem forks too ‘easy’ causes a great deal of unnecessary fragmentation in the community. It seems reasonable to me, that if your project is going to depend on a gem fork, that the dependency resolution not be automatic, and your installation instructions can tell the user how to get the forked dependency.

If a fork is going to be long-term, or a true alternative, it should probably be reregistered under a new name as a different project.

Like I stated above, ‘gem forking’ is still supported just because of the nature of how Gemcutter works. I felt there needed to be a longer term solution for this in general, since now the community has grown used to it. This lively discussion ensued, and after some deliberation we’re going to use subdomains in order to solve the problem.

The idea is this: you’ll be able to register your own subdomain on gemcutter.org, such as qrush.gemcutter.org, and we’ll give you a completely blank index to push to. Hopefully you’ll be able to add others like the gem owner system works now. I feel this feature needs to be used in the following ways:

1) Subdomain use should be infrequent. It’s for trial/forked gems that shouldn’t be relied on for production.
2) Use prerelease versions for development snapshots (version numbers like 1.0.0pre, gem install yourgem --prerelease)
3) Don’t add someone’s subdomain as a source, unless you can completely trust anything they toss there. (like, your own for example)
4) Consider gemcutter.org/rubygems.org as the main, canonical repo that you can trust.
5) Start looking into gem signing/cert since it’s the way we can really trust gems

Of course, none of this subdomains stuff works yet, but it seems like the best way forward. It’s also spawning new, awesome ideas like password protected, private subdomains. If you’re interested in contributing to the project, please fork away or hop in #gemcutter on Freenode to see what’s happening.

This is our gem host now, let’s make it awesome.

RailsCamp NE Adventures

2009-07-20T00:00:00-04:00

The concept is simple: Get a bunch of developers together for a weekend away from the internet and most of civilization to have fun and relax. To be honest, I didn’t get to relax much, but it was made up in spades just by how awesome the event was.

The venue was the Maine MountainView House in Bryant Pond, ME I’m sure others will post better pictures soon, but the pond itself was beautiful. A dock, fire pit, and plenty of chairs made for some fun smore-making and werewolf games. The house was huge and definitely stood up to nearly 30 developers’ antics throughout the weekend.

The event itself was slightly organized, which was just perfect: catered lunch and dinner, and plenty of social hacking. Each day had a few talks showing off fun projects and interesting problems. Topics included covered internationalization with gettext, CouchDB, the Rails Rumble, rdoc.info, RadiantCMS, and plenty more I’m probably missing. I showed off Gemcutter and got plenty of awesome feedback and ideas for the site.

As for hacking, it was an interesting mix of people and skill levels. Quite a few developers were there mostly to observe what others were using for tools and to understand how they work. I loved showing off Cucumber and I definitely heard the good word of TATFT being preached. I wish I could have watched a little more, but I was having too much fun coding away.

My adventure went something like this: The start of Saturday got a few people talking about ideas to hack on, and perhaps a project the group could work on together. Nick Plante mentioned games via Twitter, and that eventually lead to implementing DopeWars. From there, some went outside on the porch to sketch out how the app would work, and we then wrote some basic user stories. It ended up that Jason and I banged out a quick prototype in Sinatra and got something decently working. On Sunday, amongst recovering from some late night Urban Terror, I hacked with some others on searching gems via Gemcutter’s web interface.

If there’s a RailsCamp going on even remotely close to you, do everything you can to get there. It was more hands on than RailsConf, and the amount of networking and fun being had was multiplied. I’d just like to say thanks to the organizers, Pat Allan and Brian Cardarella, for working hard to put on a great time for all. I’d love to help organize a RailsCamp in the future, perhaps since I’m returning to Rochester soon it could include the Great Lakes region and bring in hackers from NY, PA, OH, MI, and more. (If you’re interested too, leave a comment!)

RailsConf 2009 Webrat Rails Testing Evolved

2009-05-07T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Bryan Helmkamp.

Webrat = Ruby Acceptance Testing for Web Applications. Let’s say you’re creating a form: you want to know the code works as expected, and you want to ensure it still works when you make changes. The solution: writing tests.

Integration testing is built into Rails, and it does plenty of stuff already: creating requests, checking responses, determining what is on the page, and submitting the form on the page as well. It definitely works, but it’s verbose and requires way too much work. This is why Webrat was started: to make this process easier so people actually use it and want to write it.

Webrat has a very conversational tone, it’s like walking someone through the website. The basics:

visit [path]: Pretty much the same as the traditional Rails way of loading the page.
click_link "name": Uses Nokogiri to search through all of anchor tags and finds the link with that text. It then finds the href and it will follow whatever path is given. It’s a “browser simulator”.
fill_in: Finds the input you’re referring to and simulates actually entering information in, but without a browser.
click_button: Submitting form, which infers what URL to post to by looking up the form element it’s scoped to.

Getting started: Hook up the gem, some inital setup for your environment and you’re set. The core API is pretty small, and it’s all you really need to work with most web forms on a daily basis. It’s also test framework agnostic, and can even be used in IRB. It’s mostly used with Cucumber now, but what’s important is that the two are separate. There’s adapters for the big web frameworks: Rails, Merb, and Sinatra.

Some of the magic with Webrat happens due to the locator strategies. Usually it’ll just work, and especially with forms it can work off of a label tag with a for attribute. There’s also other ways to get elements if you need a less…magical way.

Webrat is meant for testing web apps, and checks all of the following:

Verify HTTP status codes
Verify form fields exist
Verify HTML content

Plenty of awesome matchers/assertions baked in:

contain: Checking text in the response body.
have_selector: Ensuring elements are on the page with the given CSS selector and some attributes/content if specified
have_xpath: Pretty obvious, a bit more powerful. Neat fact: Nokogiri actually converts CSS selectors to XPath.

Debug with save_and_open_page, which opens a temporary file of what Webrat is looking at.

There’s also adapters for Selenium and Mechanize adapters. It can be used outside of the verification context. The Mechanize session object can be used for screen scraping for example. This is being used by some to test existing web apps in other languages that want to convert to Ruby slowly, and the tests still work just the same during the process.

Selenium is now fully supported with Webrat. The library handles booting up both a Selenium and Rails server for you. It’s pretty easy to use the standard Webrat API and drop into Selenium when you need to. The main problem here: it’s SLOW. Get around this by writing only what’s necessary in Selenium, since Webrat itself is way faster.

Rack is going to help a lot with cleaning up Webrat, since they don’t want to maintain adapters for every Ruby web framework out there. This is what Rack::Test was created for, and it will hopefully be integrated in for Rails 3.

RailsConf 2009 Automated Code Quality Checking in Ruby and Rails

2009-05-07T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Marty Andrews.

Plenty of ways to lower your WTFs/minute when looking at code. Static analysis = just looking at the code without running it. Why do this though? There’s plenty of practices that already enforce quality: testing, pair programming, etc…but there’s much more that you can do on your own.

Code smells are important, you need to really follow your nose. Plenty of tools are available to help with this:

Rails stats, which comes packaged with the framework: rake stats. It gives plenty of metrics, but what is most important is the Code to Test Ratio. This is most useful for human review and communicating with your team that you need to test more.

Reek: searches for code smells. There’s plenty of things this gem searches for, such as dupliation, long methods, uncommunicative names, control coupling, and the list goes on and on. Showing off how to use the command and what it prints out. Reek is best for regular human review and checking your own code.

Flog: complexity checking of Ruby code. It checks your methods for how complex they are, and warns you when they’re getting out of hand through a scoring system. Methods with high scores should probably be refactored. You can use flog to enforce code quality at the level of continuous integration: builds don’t pass if the flog scores are too high.

Flay: is a pretty complex tool that finds duplicate or similarly structured code. This gem can find potential candidates for refactoring. This can also be used in automation, since it has a score as well. Same concept: if the score is over a threshold, fail the build.

Roodi: checks for design problems, which involves checking plenty of different code qualities. Basically prints out different problems with your code. One big thing it checks is cyclomatic complexity, which goes higher for the number of branches and loops in a method. It’s the minimum amount of tests you need for a piece of code, so refactoring it so it’s lower is better. Another neat thing is that it looks for = in conditionals. Using Roodi in automation is great since it allows you to tweak the settings that are appropriate for your project, for example the level of cyclomatic complexity that is acceptable.

Metric-fu: reports on all of the above in one neat package with rake metrics:all. It also includes some other great reports, such as Churn. Churn will show you what files have changed the most often in your source code repo, which means that you might want to split it up. This is best for regular human review.

In your CI: flog, flay, roodi.
For yourself and your team: metric_fu, rails stats, reek (and more!)

RailsConf 2009 And the Greatest of these is Rack Support

2009-05-07T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Ben Scofield.

Lots of awesome stuff is being brought into core: templates, nested attribute assignment, AR::Base#touch, and finally…Rack.

Rack is the Ruby version of Python’s WSGI (Web Server Gateway Interface). Rack apps require a call method that returns a very standardized array with a HTTP status, headers, and the response body. The normal flow of web apps is request, application, and response. Rack allows you to insert middleware between these parts.

Plenty of existing pieces of middleware:

Rack::Profiler: like rubyprof.
Rack::MailExceptions: replacement for exception notifier
Rack::Cache: pretty obvious
Rack::Cascade: enables different Rack apps to serve one whole app. For example, you can have a middleware to do just file uploads.

Going through how Rack is integrated into Rails. You can see the middleware that is loaded by default with rake middleware. Firing up script/server is now done through Rack, and Ben went through the code of how this works.

Metal! Basically a way to load Rack apps inside of Rails easily. The main problem with this: it’s hard to test. You’re forced to mostly use integration tests.

Rack::Bug has debugging info that’s pretty much dropped in, including SQL queries and so on. One gotcha, with middleware it requires a closing body tag.

Caching. Using Metal for progressive caching can really help, and if you can avoid ActionController you can shave a lot of time off the request.

Rack::Embiggener is a simple example of a piece of Metal that lengthens tiny urls. Showing off some code about how this works. Another awesome example: rewriting the hoptoad_notifier in Rack.

RailsConf 2009 Working Effectively with Legacy Rails

2009-05-06T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Pat Maddox and BJ Clark.

Why? Rails is almost 5 years old, plenty of value to be made and everyone writes it. What is legacy code? Code that’s a few months old maybe? Plenty of defintions: “Code without tests” “accumulated technical debt” “code that is difficult to change”

Technical debt is not necessarily bad…it’s deferring necessary work. Plenty of examples abound: Rails, MediaWiki, ActiveScaffold, all of the code you write on a daily basis. How to figure out where debt exists: easy upfront gains, bad migration paths, difficult to extend. There’s ways to deal with this though: big design up front, or agile.

TATFT. The cycle is of upmost importance. People seem to forget about the refactoring part once tests are passing…don’t miss it!

Testing is the best way to minimize debt that someone else didn’t pay down. Must maintain the existing value along with adding new value. Start testing NOW. Unit tests are extremely important, and Cucumber is awesome for testing the entire stack. When should you test though? Don’t do it all at once…do it just in time when you actually need it. Isolation is really helpful for injecting testing in applications. The more split up parts are, the easier it is to test individual sections.

Let Rails do its job. Plenty of places where code is rewritten: caching, validations, serialization, memoization, and so on. One way to deal with this is make everything a framework, use metaprogramming and DSLs to your advantage. Some pros: it’s easy to read and the behavior is free. On the flip side: it’s not as accessible to brand new Ruby programmers. Write your own little framework or use someone else’s like resource_controller.

Rails also has plenty of extension points that you should be using: filters, observers, callbacks. Callbacks are great for cleaning up controllers and pushing logic into the model. The main problem here is the indirection when trying to debug, and also testing is a bit harder. However, it’s practically like using a transaction and it keeps with the skinny controller/fat model standard.

Ruby seams: alias_method_chain, method_missing, send / eval. Plenty of places where you can modify code without modifying the actual text you’ve written. A good idiom to use is default arguments, which is great since classes can be used here as well. Mocking can help out as well with faking out parts of legacy code bases that won’t help with testing what you need.

What’s really essential is to understand Ruby as much as possible. Learn to make Rails work for you. Another awesome reference is “Working Effectively with Legacy Code” by Michael Feathers.

RailsConf 2009 What Makes Ruby Go An Implementation Primer

2009-05-06T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk was presented by Charles Nutter and Evan Phoenix.

Method Calls. What happens? Evaluate receiver and arguments, look up method named ‘foo’ (walking up the class heirarchy), and call it. Lookup is the most expensive part. There has to be some sort of method cache because walking through the different classes is really expensive. This involves checking for a cached method and ensuring the class hasn’t changed since the cache was saved. Huge deal for performance with dynamic method invocation. 80% faster typically with a method cache.

Tons of things can affect the cache: def / undef, Module#define_method, etc. Object#extend is the huge problem. Used for mixins with modules and adding methods all the time in Ruby. How does extend affect the cache? In 1.8/1.9 the entire cache is cleared, but with JRuby (and somewhat with Rubinius) it’s localized. Extending a module has some massive performance implications. A little increase in syntatic sugar can lead to pretty huge slowdowns. It’s still definitely useful, but it has to be used with caution or in a different manner.

Constant lookup! Same deal, lots of searching through the heirarchy. Cached at lookup site, and they are globally cached across all Ruby implementations. So basically, don’t redefine constants at runtime or frequently.

Options Argument: Basically passing a hash at the end of an argument. Forcing Ruby to create the hash for you, or passing no arguments at all hurts performance.

obj.run rescue nil: eating exceptions in one line. Happens for two reasons: dirty way to fix a problem at 1am, and possibly by design though extremely rare. The big problem: StandardError has 101 subclasses, and you probably want to know about what happened. Best thing to do: throw it into a logger.

autoload: Delay code loading until some later point. Lots of problems though…for one, it’s completely thread unsafe. Inherently broken with threads in all implementations. It doesn’t actually call #require, so you can’t autoload gems. Plenty of alternatives though: pretend to go single-threaded, pay the cost upfront

super: lots of different ways to use this keyword. One really strange behavior: blocks tacked onto a super call will be passed up implicitly to the superclass. Parens work really strangely, if you don’t specify them on super call it will use local variables that may have changed in lines before.

To wrap up: simpler code is the better code. Think twice about the fancy features of Ruby and how it might affect your app.

RailsConf 2009 Starting up Fast Lessons from the Rails Rumble

2009-05-06T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

A panel on the Rails Rumble moderated by Nick Plante. The panelists: Joe Fiorini, Chris Saylor, James Golick, and Ben Scofield.

1) How is competing in the Rumble like working on a normal web project?

Ben: The goal is different…you want to WIN.
Joe: Not really a flexible budget or time to reconsider options. The limitations make it more feasible.
Chris: They did a lot of upfront work and simply executed it.
James: More focus on the value, since that’s all the time you have for.

2) Is it possible to build a real product this way? Have you continued to develop your web apps?

Chris: They definitely didn’t intend it to stick…but they got a call from someone who wanted to acquire them. After actually registering the company, they’ve built it into a decent business and are actually talking to the Food Network about possibly acquiring it.
Joe: The real challenge is physical for their team, getting together is rough.
Ben: Since he’s the only one working on his project it’s a lot harder to continue work on it.
James: Getting feedback is essential, and a 48 hour window forces you to get that as soon as possible.

3) What sort of up-front planning and design work did you do?

Chris: Complete wireframes, DB schema, and tasks for people to do.
Joe: None? Mostly good ideas, and that’s it.
James: Some doodling, and using Pivotal Tracker a bit.
Ben: Some research and finding inspiration for the designs online.

4) How did you plan for the 80/20 rule in building web apps within a 48 hr time period?

James: Need to have something ready to deploy. New ideas had to be squashed too and forced into the Tracker.
Ben: Time limits help out…do the most difficult stuff first.
Joe: Their first production deploy was on Friday at 11:30, and it’s easier once you do the first one. They used a bastardizd scrum process and tried to keep it as simple as possible.
Chris: The 80/20 rule is crap most of the time! They tried to figure out what was going to take the most time and do that first. They also had to make sure someone was reviewing code.

5) What are some lessons from the Rumble you can apply to teaching someone new to Rails?

James: They had at least one pair programming session going on, and that helped out immensely.
Chris: During the Rumble they taught a designer how to use SVN.
…and hijacked!

6) Did you use automated testing?

Joe: No. Sort of hard without a good background of testing and not a good place to learn.
Ben: Not good to learn completely new things, for example a World of Warcraft addon…which is written in Lua. And he used some automated testing.
James: Plenty, that’s just how they write code. Great way to catch regressions and they definitely noticed some teams that had pretty broken apps that didn’t do any testing.
Nick: Work with technologies you’re comfortable with.

7) What processes/tools were the most helpful?

Joe: resource_controller was awesome. Also, NewRelic RPM helped when their site got hit from Lifehacker. Basecamp was great for communication too.
James: Starter apps were really helpful, like bort or blank. Pivotal Tracker is super simple and gets out of your way.
Chris: Going to be interesting to see how Rails templates will be used. Campfire was awesome too, especially for the history and inline images.
Ben: Lots of testing gems: factory_girl, shoulda, mocha, etc.

8) How did you find good people to work with? How similar is this to finding cofounders?

Joe: Mostly coworkers and friends of them.
James: He ended up hiring his cohorts since he enjoyed working with them so much.
Chris: Local user groups are a great way to find people.
Ben: Teams are for the weak.

9) What was the most rewarding part?

James: A lot of great hacking and tons of fun.
Joe: Good opportunity to learn and nice to see a finished app in one weekend.
Chris: The belt.
Ben: Definitely a reminder of why this profession is awesome.

Next up: August 22/23rd! More info here.

RailsConf 2009 Robert Martin Keynote

2009-05-06T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

What killed Smalltalk and could it kill Ruby?

Is Smalltalk dead yet? It was the language that only a few dabbled with in the 70s and also quite a few huge projects written. Why did Smalltalk just keel over? Squeak has become an academic language mostly, no one is doing anything serious in it.

Smalltalk really was the pinnacle of what object-oriented design was all about. There were some good languages around though…C++ is man’s language, Java is more of an estrogen language. Objective-C was really influenced from Smalltalk though. Smalltalk had a huge advantage over C/C++ in productivity. Smalltalk also had a lot of powerful IDE tools, especially for refactoring. But, it still died. It was mostly…non-hormonal. It makes stuff happen.

Ward Cunningham is pretty much a badass. He’s come up with or kickstarted tons of great ideas: design patterns, FIT, the wiki, the list goes on and on and on. According to Ward: clean code is when you look at a routine, and it’s pretty much what you expected. Clean code has a metric of zero WTFs/minute.

According to Ward: what killed Smalltalk was that it was just too easy to make a mess. This didn’t happen in C++ because it punished you for creating a mess. Smalltalk didn’t complain much about this, and messes could pile up fast and without consequence.

Ruby has this same problem. Happens with many projects: it’s just a tangled mess eventually and you have to dive into the framework to see what’s going on. Apply the Boy Scout Rule to code: random acts of kindness for every checkout. This doesn’t happen though…cleaning code is risky. The messes are easy to make, but hard to clean…it becomes your mess if you break it!

There’s a way out of this: TDD! Ruby has this built in, but he’s afraid that the discipline won’t grow with the community. The rules of TDD:

Don’t write a line of code without writing a failing unit test
Not allowed to write more of a unit test when they’re failing. (Make it green!)
No writing of production code without writing another failing test.

The cycle might seem pointless to those outside…but it really prevents the horrible timesink that is debugging. Having a test suite really helps with refactoring. Tests eliminate fear! A suite of tests removes fear when trying to change things.

TDD never became part of the culture in Smalltalk…it has become part of the Ruby culture, but is it enough? Without tests, you are not in control of your codebase. There was a certain air of arrogance in the Smalltalk community that seemed to keep people away from it. They felt their tools and languages were just better, and they ended up building a wall around themselves.

Dynamic languages won the language wars, even the static languages have adopted some dynamic principles. There was a certain lack of professionalism that the community just lacked. Smalltalk died since it just refused to address the general problems of the enterprise: parochialism.

What might save Ruby and Rails, etc from this demise? It’s not headed in this direction yet. The following must happen to prevent the downfall:

Discipline. TDD. It’s HARD.
Humility. There are good laughs to be had, but don’t build the wall (or force them to!)
Solving the dirty problems. Bad database schemas, for example. Someone’s got to deal with it.

Don’t ignore the enterprise.

RailsConf 2009 Rails 3 Step off of the Golden Path

2009-05-06T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from Matt Aimonetti. There’s a lot of talk about “the merge” but not many know why or what happened. Going through the history, starting from the principles behind Ruby, and the process of how Rails came about. The big principles behind Rails: Convention over Configuration, Don’t Repeat Yourself.

At some point there was a schism from Rails, and this was Merb. Merb was focused on performance and agnosticism. Lots of drama as time went on and plenty of tension. They finally sat down and talked, and they had the same goals but just had different perspectives.

What’s in store for Rails 3:

Improved performance. Merb was a speed demon, it’s time to bring that into Rails.
Increased modularity. Bringing this to the next level.
Agnosticism in general throughout the framework.
Public API, ensure that plugins won’t break.
Mountable apps with Rack

The Rails 3 default stack: ActiveRecord, Prototype, ERB, Test::Unit. No huge changes for end users. Instead of one “Rails Way” there’s going to be many “Rails Ways”. A big difference is that Rails 3 will be less opinionated. Not all apps are going to be the same, and this just recognizes it.

When should you step off the default stack? According to Matt, he believes that it’s a question of taste along with the requirements given to you.

Will be able to pick and choose the JavaScript engine you want. For templating engines, it’s not that big of a change since there’s really only 2 choices. The more difficult choice will be the ORM. It will be possible to seamlessly swap between the various ORMs available. One of these is DataMapper, which has a lot of great benefits that ActiveRecord doesn’t. It’s uses lazy loading along with a smarter way of dealing with potential N+1 select problems that plagues ActiveRecord. Some other neat features: ways to move/migrate from older column names, and a really nice way to define complex queries with Query::Path. Tons of adapters too.

Other adapters such as Sequel or Hibernate will work. Plenty of non-RDBMS systems being considered as well. CouchDB, Redis, Tokyo Cabinet, etc will hopefully be easy to build adapters for.

Create your own Rails: define your own file structure, your own router DSL, and even your own ways to deal with requests. The goal is that the audience for Rails will expand even further, and perhaps grow into places that we can’t even see now.

RailsConf 2009 Getting to know Ruby 1.9

2009-05-06T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is from David A. Black. No slides for this presentation: all examples of some live code. Going to go over what’s needed to know to upgrade existing 1.8 code and then dive into what’s new.

In 1.8: Object#to_a works pretty well, but warns you that it will be obsoleted. In 1.9 it’s gone. One way to get around this: use Array() to create arrays. There’s also Integer() and Float() which are a little stricter than to_s and to_f.

No more comma delineated hashes. a = {1,2,3,4,5,6} just doesn’t work.

In 1.9, String does not have Enumerable mixed in. This caused a lot of confusion with 1.8 since String#each and String#map behave differently with line breaks. There’s now a few methods: String#each_line, String#each_char, String#each_byte, and also String#each_codepoint. Codepoints are used for multibyte/UTF8 strings.

Finally, String#[] returns a character and not a number.

New Hash shortcut with symbols: h = { one: 1, two: 2, three: 3 } They’re also ordered too. When walking through the Hash, it’s done by the order that key/value pairs were inserted into it.

Plenty of new Enumerable magic: #each_slice splits arrays into parts, #each_cons does a sliding door of the given size. It’s now possible to use Enumerable#cycle to get a sort of manual iterator that you can stop and start.

Block scoping with variables works the way people expect. If a variable inside a block has the same name as a local variable, it will use the block scoped variable.

RailsConf 2009 Chris Wansrath Keynote

2009-05-06T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

Chris is going to talk about how to become a Rails rockstar/ninja/etc. Here’s what you need to do: Get a blog. Have an attitude of some sort. Don’t go for the default blog design. Customize it. Choose a tone: just two random adjectives.

Now for content: just write…anything. Start some controversy, bitch at other bloggers’ code, copy content from your older blogs. Lots of this and you’ll become a famous Rails developer. But…famous != good.

Code is what brings developers together: not what people are blogging or known for. Chris went through a story of how he created a YAML library for PHP that helped him get a job. Code…it talks! This is definitely how they found everyone who’s working for GitHub now.

Ruby/SourceForge is not about the code, even with the new redesigns. The process to create a new project on SourceForge is ridiculous: huge description, have to pick a license and even a category. Ridiculous, and unnecessary. No approval process on GitHub. All of this is just ceremony, and they don’t add value.

Get out of the way: reduce friction! Friction wastes energy and is expensive, need to avoid it. A big deal of creating a business: finding those who can help you.

We need more of this…people who contribute more to the community instead of just pushing their own agenda. We don’t want rockstars, they’re just unreliable.

RailsConf 2009 The Future of Deployment

2009-05-05T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This panel is from the guys behind Heroku. Going through the russian doll architecture of Heroku: Thin, Rack, Rack::Cache, and Sinatra. The guys who wrote this stuff are here, and they have some interesting opinions to share.

Marc-Andre Cournoyer started Thin as a port of Mongrel that was not threaded. He plugged it into EventMachine, and magic happened.

Christian Neukirchen started Rack. He didn’t want to go with Rails for writing his own CMS, so he started it as a Mongrel plugin. He created a port of the Mongrel API to FCGI, brought it to Zed, and he pretty much shot it down. From there he started looking around and found Python’s WSGI and decided to start on a Ruby version of it. Now at the point where pretty much every Ruby web framework runs on Rack.

Ryan Tomayko started Rack::Cache since he wanted a much simpler way to deal with HTTP caching, since it’s usually so complicated it’s easy to lose people when trying to explain it. He also wanted to show a great example of some Rack middleware.

Blake Mizerany started Sinatra because he had some smaller apps that he didn’t need to use Rails for. He started messing around with Mongrel handlers but soon switched over to using Rack.

Adam Wiggins is one of the founders of Heroku. He thinks the meaning of deployment is changing. It’s not a slow cycle that requires a lot of hardware and time, and they’re enabling people to change rapidly and allow developers to focus on writing their application code and not their servers.

Discussing the terminology behind deployment. Some talk that Mongrel has become a noun, but most people seem to use just “app server”. Moving onto middleware and how it can be used. Most people seem to know about it but not actually use it. The real benefit seems to be that you can have small pieces that are easier to test and can be brought together in a simple way. Lots of discussion about queueing systems as well. Plenty of people in the audience are using them, and there also seems to be a decent chunk of people that have rolled their own system.

(Note: I missed a decent chunk of this panel, the dry Vegas air finally got to me)

RailsConf 2009 Smacking Git Around

2009-05-05T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is definitely for those who use Git daily. Going through a whirlwind introduction to Git in under a minute.

Learning about Revision Selection first. It’s an alternate way to referring to ranges of commits. There’s tons of ways to refer to objects in Git:

SHA1
Partial SHA1 (at least 4 chars and unique in the git datastore)
Branch, remote, tag names
Caret Parent (master^2)
Numbered Parent (master~2)
Blob Spec (master:path/to/file)
Relative Specs
Ranges [old]..[new] that are reachable. Really useful to see what hasn’t been pushed yet or what’s upstream.

What am I going to push? git log origin/master .. Lots of visual examples that would be way to difficult to show in text only. To see what’s in a branch and not in another: git log master --not origin/master or git log master ^origin/master

Showing off how Git doesn’t really treat git diff correctly. Using the ... syntax allows you to check differences when you want to merge. So usually: git diff HEAD...topic

Changing previous commits with git commit --amend: first off: you can modify commit messages, and any staged files will get added in.

Doesn’t seem like many people understand how git rebase works. Going through how the rebase process actually does its magic. Showing off a great example of using git rebase --onto. It’s used to transplant entire sections of commits cleanly. You can use branches as a lightweight way to refer to commits during a rebase.

Running through a git rebase -i. It actually loads a script that’s executed in reverse order. Lots of fun stuff here: squshing, picking, reordering, and so on.

Showing off git filter-branch for rewriting the entire history.

There’s an alternative to submodules: sub-tree merging. This involves adding a remote for a project that isn’t a direct clone. You can also use git read-tree to pull out specific trees from other remotes and merge them in. git merge has a ton of crazy options: -s subtree --no-commit --squash whoa.

It’s possible to stage changes interactively with git add -p. There’s also git blame, and it’s -C option. This option allows you to see code blocks that were moved in from other files so you can see when they were originally modified.

Going through git bisect and how you can use it to find bugs.

The git config is full of awesome options (enable with git config --global)

help.autocorrect 1: Git will autocomplete commands that you mistype or didn’t finish.
color.ui auto: Turn on colors when in the terminal only
Custom merge tools: plenty of ways to configure your own. Check the cheatsheet.

Lots of stuff that can be done with .gitattributes. Diffing binary files is one option, which Git usually barfs with. You can tell Git how to diff a binary file. Showing how to set this up. The end result is awesome, exiftool can show you how resolutions changed, etc. This also works on Word Documents!

Filters are pretty crazy too. The process is basically this: a smudge script processes files during checkout, and a clean filter runs on files when committed. This can be done to implement a $Date$ RCS style variable.

Scott also uploaded the slides and a cheatsheet so you can see everything that was covered.

RailsConf 2009 Rails is from Mars Ruby is From Venus

2009-05-05T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

Learning Ruby will make you a better programmer! Why you should you learn Ruby? It’ll help out with using Rails as well. There’s tons of great references for learning about Ruby: the poignant guide from _why, the Pickaxe, and tons of real books too.

It’s your responsibility to listen to your code and figure out what it needs. You need to write Ruby code that is expressive and simple, but also works within the Rails conventions.

Some of the things that you do that makes Ruby crazy:

Iteration. Don’t do it on your own. Ruby has powerful ones, use them! for..in calls each internally.
Not taking advantage of the sugar that Ruby has. Don’t use ternary operators, use ||=. There’s also a |= operator that can help cut code down drastically.
Don’t use checks against nil or false. Use Ruby’s sense of truthiness to your advantage!
Making code shorter when it doesn’t help understanding it. Brevity is not the goal, readability is the goal.
Not using rescue on methods.
Don’t don’t don’t use !!. Ruby does not not like clarity.
Base is a lame class name. Naming is really important.
Keep Ruby idiomatic. Named scope are a great example of doing this.

Going over some bad code that generates a URL…it revolves around checking the class of an object and doing some actions with that object. Instead of using a case statement for that, it’s better to push that into the respective classes. This is definitely better since it’s a decent separation of concerns and just cleaner Ruby.

Jumping into Rails performance. Don’t prematurely optimize without knowing what will be slow, but at the same time, don’t write code that will never be fast. There’s some ways that Rails helps out with this, like counter_cache.

Ruby is fun! (and easy!) The more Ruby you know, the better you’ll get at Rails.

RailsConf 2009 Notes

2009-05-05T00:00:00-04:00

I’ll be doing liveblogging of the conference talks that I attend this year. This page will be updated throughout the week with links to the notes. Stay tuned!

Day One

Day Two

Day Three

RailsConf 2009 Guitar Hero Behind The Music

2009-05-05T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

This talk is about bringing the data from the game into the web. They’re going to go over the process, the programming, and the infrastructure behind the Guitar Hero titles. They’ve built a pretty huge Rails app that collects stats from the game across all of the currently available titles.

They use feature driven development. This causes plenty of issues: with deployment, with getting customers to use it, and even more. A big part of this is managing expectations of the client. Lots of different stakeholders behind the game, and it’s the project manager’s job to deal with them and the developers.

One huge difference with developing the website is that it’s never actually complete, unlike the game. They use a modified scrum process for iterations. They had plenty of issues with traditional scrum, though:

Lots of unnecessary overhead
Sprints were way too long

They changed it so sprints were much shorter, usually a week, and daily standups to help out with communication.

Lots of maintenance they have to deal with: managing refactors and upgrades along with making sure people can still use the game. A huge saving grace for this was using continous integration.

Going over the architecture of their system. The Wii system talks directly to a Rails stack, but the Xbox 360 and PS3 do not, but the data eventually shows up on their network.

They’ve made some serious modifications to Rails. STI was not a good solution, it doesn’t handle millions of rows in a good way. They created the GHConfigurator, which has a lot of crazy features:

Title specific associations (for example: high scores across different games)
DB sharding, and making sure that connections aren’t opened everywhere

They used Array#pack and String#unpack to cram a lot of data for sending stats to the GH servers. The Wii and Xbox/PS ways of dealing with the stats are drastically different and required ways to work with this.

They created an event manager to deal with processing stats coming in, but there were a lot of problems. There were too many GH titles, lots of load, the deploys had to wait until the queues were empty, and so on and so forth. It was bad.

Don’t redesign the solution, solve the problem! They had to fix this monster by splitting it into separate parts:

Reaper: Get events from the DBs and toss them into the queue, using Sparrow. Backed by sqlite3.
Dispatcher: Check the queues every so often, create consumers. They had to deal with problems that the game developers send them here as well.
Consumer: Parse the xml, actually create the high scores and other magic.

Huge success, lots of great feedback from the community about how well it’s working. Since it’s separated out it’s a lot easier to test, deploy, and manage overall.

The configurator broke fixtures completely. FactoryGirl saved them from this. Transactions also broke pretty seriously, but it was fixed by patching ActiveRecord. Caching was also hosed. They use fragment caching mostly, and they have to manage expiring them on their own. Caching on pretty much every single query.

They use capistrano along with branches in SVN for deployment. Three environments: development, staging/QA, and production. Pretty standard set of tools for serving: Thin, Monit, HAProxy, NGINX, Memcache, MySQL.

RailsConf 2009 DHH Keynote

2009-05-05T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

Rails 3! This year marks the fifth year of working with Rails (six really for him). We’re largely doing the same things from 5 years ago. Stop fretting so much if you’re up to date with the most up to date practices. It’s possible to enjoy Rails without knowing everything new that’s going on, and definitely not necessary to rewrite apps as a whole that are using the ‘old’ practicies.

We were supposed to be killed a long time ago. Going through some memories of why Rails isn’t supposed to make it. First off: it wasn’t ‘enterprise-ready’. There was this notion that it was a group of consultants more interested in getting more billable hours and selling their books. This is obviously not the case. It takes time for these arguments to settle.

The next step was copying Rails: Grails, Sails, Monorail, etc. By bringing a few parts that makes Rails awesome into a different language, it can help to make that language not suck. Well, maybe not. If you can boil down what makes Rails coders more efficient, then you don’t need to learn about Ruby or Rails.

Switching back to old systems: the first big one was ‘7 Reasons I Switched back ot PHP after 2 years on Rails’. For some reason since Rails didn’t meet his needs, people saw it as a reason to ignore Rails. News sites like Slashdot and Reddit seem to intensify the arguments behind these posts, but it only lasts for a really short amount of time.

The failwhale! The core argument behind this: Rails doesn’t scale. It’s hard to fight a meme like this, and it’s better just to accept them. Rails has the both good and the bad with this situation, and it doesn’t really matter in the long run.

One of the big ‘storms’ was the Array#second and so on methods, which only lasted for a few days like the other ones. Merb was one of these too, but it’s stuck around. The arguments at face value may seem very heated, but once you dive in, people are trying to solve the same problems.

Chill out. We’re still here despite all of what’s been going on and it’s not going anywhere.

The Philosophy of Rails 3:

Lock up the unicorns: Not going to solve all of the problems or be a huge rewrite.
No holy cows: Question what’s going on, get away from things that can’t or shouldn’t be changed. Huge example: alias_method_chain. Nothing is sacred in Rails. Definitely up for improvements that break existing Rails apps, if the arguments are good.
Have it your way: the real merge! It allows you to choose whatever you want, there’s an accepted way to do things, but you can modify it as you want. Keeping people in the community because of this is most important.

The progress of Rails 3:

No new gems or huge release today. Going over some nice parts of Rails 3 that’s already in the repo.

New router: Rewriting it again. Routing based on subdomains and user agents as well. Bake Rack into the router so you can mount multiple Rack apps at the same time. Going through some new ways that the router could be designed, both for old style declarations and new REST routing.
XSS protection: For a long time, it’s been a holy cow and left to the developers to determine when to use the h function to escape HTML. Flipping the convention: all default views will be escaped. You have to use the raw helper to unescape. Mark a string as being safe HTML with String#html_safe!. Thiswill probably cause the most pain for upgrades.
JavaScript: Unobstrusive means that no javascript in your HTML. Rails needs to do this too, but it’s skipped over this for a long time. Rails is going to adopt HTML5 standards of custom attributes in order to get around this. Showing an example of data-remote: true for link_to_remote, data-method: delete for link_to :method => :delete, :confirm => true.
Lots of more agnosticism: ActionORM, more flexible generators.
The great refactoring: Lots of ideas from Merb being brought over. AbstractController + ActionDispatch for making the controllers better and cleaner. ActionRelation will help out with some of the relational math going on under the hood of ActiveRecord.

DHH’s secret to productivity: renegotiating requirements. Most programmers don’t seem to be able to do this and push back. The real lesson here seems to be reflecting on what the customers really need, and trying not to sink tons of time into fruitless efforts. We want to be the hero and do everything the client wants. This is bad, obviously. You need to balance motivation along with what the clients want. The definition of programmer is bad: consider them partners instead.

RailsConf 2009 A Morning with GitHub

2009-05-05T00:00:00-04:00

This is part of my series of notes on RailsConf 2009. Check them all out here.

Introducing the guys behind GitHub, and then going through some QA’s.

1) Does github use any special techniques for storing so many repos?

Storing repos uses alternates, which shares objects between different repos. They use Grit for a pure Ruby interface to Git. They use RedHat GFS as a shared filesystem. Lots of caching. No distributed hash table for objects…yet. Architecture is pretty standard so far.

2) How do you monitor the whole system?

Twitter. No, seriously: NewRelic. There’s also a job queue that they’ve written custom stuff to look into what’s going on. Engine Yard monitors the overall health of the system. They use Tom’s god gem for lots of monitoring. They have to make sure that some processes don’t kill the servers, such as syntax highlighting or upload-pack running wild.

3) Do you shard git repos or do you use one big GFS?

They split up repositories because having thousands of repos in one directory is just…bad. They use a pretty simple hashing algorithm to split it up.

4) How long does it take the test suite to run?

A few minutes? No one seems to know. They use integrity to let them know when the build breaks.

5) Are they going to open source github?

Cost of running the open source project is really high, they’re in this to make money. Parts of it are open source: Jekyll, Grit, the services.

6) How many servers do you run GH on?

Hosted at EngineYard. 4 front-end slices, 1 job slice, 1 machine for solr, 1 for gem building. Memcache runs on the front-end slices too.

7) Is the GitHub source on GH?

Yes.

8) Is GitHub profitable?

Yes.

9) Why an Octocat?

Tom was looking for a mascot when GitHub was starting, and he was looking for octopus style images since Git has an octopus merge. He found some artist that made him

10) How do you manage authentication of so many SSH public keys on one user account?

Someone from EY patched sshd for them. Patching authorized_keys doesn’t work well with thousands of keys. So now, it looks up the keys via MySQL, which scales pretty well.

11) When will you offer GH tshirts featuring the Octocat?

Soon, hopefully.

12) Naming gems username-gemname sort of works. How can it be made better?

They’re not very happy with the setup. They had to deal with some people creating accounts like ‘net’ and having an ‘ssh’ repo. It’s been an incredible amount of work and a huge hassle so far for them.

13) What can we expect in terms of new features on the upcoming months?

Make sure the site scales. GFS isn’t going to scale for much longer. They need to make Git scale, not Rails scale. Git wasn’t really built to do what they need, and it’s a big problem that they need to tackle. Better documentation for the API along with better integration for third party apps.

14) Why not use passenger?

EY manages it. No big reasons to change it yet.

Git Started with Git

2009-05-01T00:00:00-04:00

One of the best parts about my internship at Thoughtbot is that I’m able to participate in the awesome Ruby user group meetings nearby. For the month of April I talked about learning Git and how it can be integrated into your daily life at three different venues: Boston.rb, BarCampBoston 4, and NHRuby. Here’s the slides from the talk:

What I definitely enjoyed the most was getting questions and feedback from the audience. I was half afraid that I was leaving them far behind with some of the advanced topics (especially with rebasing) but from what I gathered most seemed pretty solid after the talk. I don’t think I could ask for more than responses like this (thanks!):

One aspect that really bit me was dealing with amount of material and questions, especially since the time requirements were different for all three. I cut plenty of slides out to fit it under an hour by the end, since my original timeslot was roughly double that. You can get all three versions if you’re extra curious here.

BarCamp Boston 4 Roundup

2009-04-26T00:00:00-04:00

BarCamp Boston 4 has been a lot of fun. This post is just a roundup of the talks I went to on Sunday. I gave a talk about getting started with git, which seems to have went well.

I’ve never been to MIT before, and I need to come back and explore the campus more. It was held in the MIT Strata center, which is absolutely ridiculous. The architecture is really just unreal. Also, I can’t believe how much pizza a few hundred nerds can down in a manner of minutes.

One of the neatest things was that a project was being run in the hallway with a Wiffiti stream of the tweets, pictures, and more that was going on:

Here’s the talks I went to and what I got out of them. You can see the full schedule here.

how to be a freelancer

The person giving this talk wanted to hit like 8 points, but I think he only got to 3. What ensued was plenty of discussion on how to deal with clients, how to ditch them, and problems that come up with freelancing in general. The general gist I got from it: I’m glad I don’t have to deal with that.

Code secrets

This was a great idea: people in the audience write down horrible, deep, dark secrets about code they’ve written, and then they’re read off. Hilarity ensued.

Starting a Boston startup space

Sadly I didn’t pay too much attention to this one, but my basic gist was that it’s a community service, and it’s tough to decide a business model that works for the people you’re serving. I’ll definitely be utilizing the local coworking if I end up on the lam as a freelancer or mobile worker after school is over.

Fun with QR Codes

QR codes are really neat, and can do some ridiculous stuff. They’re really awesome for embedding URLs into the real life, like putting a QR code near a bus stop that can open a schedule for you. I just wish my phone didn’t suck so I could actually read them. I do wonder how this concept would catch on with the general public. What is really funny is to watch people try to read the QR code on their phones from the screen.

JavaScript Testing Discussion

Lots of gripes about the current state of testing JS in the browser. There’s plenty of ways to DO testing in the browser, but there doesn’t seem to be a be-all, end-all solution. Listing out various testing frameworks, but there doesn’t seem to be many familiar with most of them. Complaints, bitching and moaning about how difficult this situation is. It all boils down to not being able to remove the human element from testing it correctly.

Ruby Testing Panel

Seems to be a general discussion of what’s going on in the Ruby testing world and reactions that people have. Starting off with a rant or reasons why to Test First. Diving into some differences between RSpec and Shoulda and their syntax differences. Some talk about mocking and stubbing and the different libraries. This discussion went for an hour but I skipped out early to make the next talk.

Introduction to the Arduino

Should be easy to translate software development experience into the microcontroller world. Throwing some around the room so we can get a look at what they are. Huge advantage: the bootloader. All you need is a USB cable and you can load code on it. There’s ways to get around it or write your own too. Ridiculously neat demo: the arduino spins a platter with a thin slot that has LEDs beneath it. There’s a lens at the top of the platter that the arduino can hook into, and control the speed of how fast the platter will go. Lots of C code and magic registers that you need data sheets for. I wonder if the Ruby library abstracts any of this away. Data sheets just seem scary, but useful.

LOLCODE 101

This isn’t 100% serious, but for some reason somebody made a programming language around this meme. I would post some code but pygments doesn’t support the language. Best part of the language: DIAF is exiting with a status code.

Checkout tracked remote branch with Git

2009-01-07T00:00:00-05:00

I frequently need to do this when setting up or syncing my various machines, and I seem to forget the command all the time. So let’s say you’ve got more than one branch on your remote, and you want to bring it down into your local repository as well:

Viewing information on the remote should look something like this:

$ git remote show origin
  * remote origin
    URL: *************
    Remote branch merged with 'git pull' 
      while on branch master
        master
      Tracked remote branches
        haml master

Luckily, the command syntax for this is quite simple:

git checkout --track -b <local branch> <remote>/<tracked branch>

So in my case, I used this command:

git checkout --track -b haml origin/haml

You can also use a simpler version:

git checkout -t origin/haml

If you only could follow 10 people on Twitter...

2008-12-11T00:00:00-05:00

…who would they be? I’m following a staggering number of people (1,337 to be exact), and the signal vs. noise ratio is just getting out of control. I’m not sure how I got into this situation: I just started following everyone that followed me, and it spun out of control. I see a few options from here:

Remove everyone and start again.
Set up groups in TweetDeck and continue to follow a ton of people.
Slowly whittle away until my following/follower ratio is down to 1:1.

This got me thinking…what if you could only follow 10 people? Who would I follow and why? I present my list, and I encourage you to think of your own.

ablissfulgal: My girlfriend. I don’t need to explain this one.
mittense: Former coworker from Stardock who plays way too many video games.
GarrettAtreides: Classmate at RIT, MS lover, and all around goofy dude.
AmazingSyco: Classmate at RIT, Cocoa hacker, and all around funny dude.
chorn: Local Ruby fan that’s a riot. Supposedly he’s a CTO too.
BreakingNewsOn: For those who prefer their news in ALL CAPS.
defunkt: One of the GitHubbers and an awesome Rubyist.
faithfulgeek: Convert to the Ruby/OSX world from Microsoft. I’m going through the same transition.
nakajima: Ruby ninja who’s a code machine. And he’s hilarious.
guykawasaki: Entrepreneur extraordinaire. I’m listed on his site as a Twitterati too.

To those who didn’t make the cut, don’t feel bad! It’s not that I don’t want to communicate with you, just most likely I can communicate easier through a different channel (IRC, IM, what have you).

Who would you follow? Let me know in the comments or make your own blog post!

Open Source Collaboration with Git and GitHub

2008-12-05T00:00:00-05:00

I just gave a talk at the Society of Software Engineers’ Tech Talk Thursdays about Git and GitHub. The talk was a mashup of Scott Chacon’s various resources on Git along with Michael Hartl’s presentation on contributing to Insoshi with GitHub. I think it went pretty well and it was followed by some good discussion.

The talk is an introduction to Git from the perspective of a student who has used version control before (and hopefully has learned a bit of graph theory). I went over the little history that Git has, why Git rocks, and how helpful and easy it is to use GitHub. Check out the slides: (yes, there’s puppies)

Open Source Collaboration With Git And Git Hub

View SlideShare presentation or Upload your own. (tags: oss collaboration)

It was definitely a lot of fun. (I almost wish someone was taking notes!) Someone was taking a video, so hopefully it’ll be up soon. Next time I give the talk I want to show how easy it is to convert from svn/cvs as well as create and browse repositories since I got a lot of suprised looks about git init and git instaweb during Q&A.

GitHub Rebase #6

2008-12-01T00:00:00-05:00

The sixth edition of my column is live: http://github.com/blog/246-github-rebase-6

I’m slowly improving the parsing process. For the last edition I broke out all of the work the app does into rake tasks, and then the Rails site is just for viewing the data. Basically there’s a few steps:

Download ATOM feeds (This week, 1400. Last week, 1200).
Check that all of the downloads went ok. (Bad gateway errors happen to good people)
Parse the files, making sure that events are unique and users forkers are logged.

Surprisingly I’m relying less and less on my app to get the column together, which is good. Huge kudos to the GitHubbers for creating the Recently Created page for each language. This helps me diversify the column while avoiding a lot of data crunching on my end.

Next week I definitely want to parse the entire month’s worth of events to really see the trends come out. Luckily their atom feed goes back 4000-5000 pages (of 30 events each) or this wouldn’t be able to happen. What this will mean is that I’ll actually have to optimize the download and parsing as much as possible. Stay tuned!

Using Berkeley DB and Ruby for Large Data Sets Notes

2008-11-20T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk by Matt Bauer from Pedal Brain.

Large amount of data in their system with cycling. Tires, speed, wind, etc. 46 data points. 29 collected every 5 seconds. 1.7 TRILLION data points (50 GB!) with over 5000 concurrent requests. Everything from GPS location, power, etc. Devices are peridocially connected so data much be captured quickly and latency must be low. Realtime reporting of where cyclists are at with this system. Ability to do reports on many different levels. Typical report is 40k-220k rows.

They settled with lighttpd, merb, and sleepycat software’s stuff with BerkeleyDB. It’s fantastic: open source and highly concurrent. Can scale to 256 terabytes! Fully featured DB too…ACID, locking, and more. What’s special: it’s embedded, written in C with many bindings. No SQL or schema, doesn’t operate on keys or data. Like sqlite, but way more battle tested.

Two data stores. Concurrent data store: no recoverability or transaction capabilities. Transactional data store: fully recoverable and complete ACID feature set. So it’s very powerful…but is it good through Ruby? YES! Showing off quite a few tests about how blazingly fast it is. No marshalling data over the wire or through a socket so it’s very fast.

Very difficult to handle though. All sorts of special constraints that can be customizable. Two bindings that let Ruby talk to Berkeley. Guy Decoux wrote the original, which is pretty slow and built for a much older Ruby version. The newer once with Dan Janowski is an exact implementation of the C API, quite stable. Only three test cases though.

Guy’s bindings let you feel like the data is literally an object in Ruby. Dan’s way is a lot like C. A bit messy and uses bit flags, but it’s a direct translation from C anyway. There’s only one table with BerkeleyDB, but different types of access:

BTree: sorted, balanced tree. Ordered insertion results in full pages.

Hash: extended linear hashing

Queue: fixed length records

Recno: stable record numbers

Variable length key and data means 4 gigs of data. Damn. Transactions and cursors are in there too and can be done completely through Ruby code. Indexes are in too, but requires two separate database connections.

The future: combine the Ruby feel of Guy’s code with Dan’s C codebase, improve tests, more marshaling options. Support for newer version of the DB and moving to GitHub soon.

Databasess != SQL or Entity/Relationship. Just be happy and use Ruby! Use the right tool for the job too, if it’s BerkeleyDB, sqlite, MySQL, or whatever.

Ruby: Fragile or Agile? Notes

2008-11-20T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is by Josh Susser from Pivotal Labs.

Tons of wonders in the world. What the heck happened to Smalltalk though? Spawned many languages, but it was still superior. Yeah, there’s Lisp too. Why aren’t we all programming in Smalltalk? C++ mostly.

Why is it a bad idea to go with C++ (At Apple!) Alan Kay said that 3 things make up OO: encapsulation, polymorphism, inheritance. For C++: WEAK encapsulation, WEAK polymorphism, WTF inheritance. At Xerox he programmed a smalltalk interpreter (or something) in Microcode. C++ is not a high level language. Just a thin layer on top of C, which is just portable assembly. Smalltalk had a lot of great things…IDE, garbage collection, and a huge blind spot.

Josh likes looking at things like their greatest strength is their greatest weakness. Comparing to Superman’s strength and willingness to do good, which Lex Luthor can manipulate.

“An operating system is everything that can’t fit in a language” Very meta: Most of smalltalk implemented in smalltalk. Made of a kernel, which made up the fundamental pieces of the language: primitives, datatypes, IO, fundamentals. Virtual image had everything else: compiler, graphics, network stack. VM can be ported from platform to platform, and the image runs the same.

Virtual image is really cool, but it’s not without cost. Made applications almost impossible to deliver. He was one of the first at Xerox to deliver commerical Smalltalk apps. Very hard since the code was integrated with the user’s data. No concept for namespaces, so screwed if vendors use them together.

So, it’s a bit of a monolith. You’re not using Linux, Windows, etc windowing system, you’re using Smalltalk’s. It’s getting old. C++ sucked up all of the oxygen and steam that Smalltalk had built up in a very short period of time.

Why did that happen? C++ was not better than Smalltalk, but it was just enough better than C. Didn’t require a big conceptual leap, plenty of tools, easy to implement, tons of tools already available for C. Most important things: Could actually ship applications with C++ to customers. Just enough more productivity! Sometimes, good enough is good enough.

That brings us to Ruby. It would really suck if we were all programming in the modern equivalent of C++. It’s not in immediate danger of facing Smalltalk’s demise, but it couldn’t hurt to think about ways to strengthen Ruby. Not going to fix the language, but fix the language.

Rails. Most people came through it, and web development is the center of what’s being done with Ruby. However, in the long run it’s a niche….like PostScript. The next Ruby ‘killer app’ will be outside of the web development domain. Not sure what yet though.

Proposing that the reasons why people like Ruby is also because of agile development. There’s a higher percentage of Rubyists that actually do use agile development techniques. It brought joy back to his programming experience because of that. Best thing about Rails is the test directory and how it encourages TDD. RubyGems too since most ship with tests. There’s a culture of agile development around Ruby and it’s essential to its future. Performance issued may be solved by Maglev, Rubinius, YARV, etc.

The amount of metaprogramming in the language helps with the TDD movement. The problem is in development tools: we don’t have a good IDE! It’s a joy to program in it, but it makes it hell on an IDE to understand what’s going on with the language. Smalltalk made decisions to limit the language so good development tools could be created. Simple refactoring methods like extract method, renaming are easy in Smalltalk. Not so much in Ruby because of its dynamic nature.

Going through how update_attributes works…it uses send to dynamically set attributes. It’s incredibly powerful and expressive, but it makes refactoring difficult. This may be preventing people who are working with Java and used to refactoring tools to move over. No way to fully statically analyze a Ruby program…you’d need to solve the halting problem: Run the program to see what the program does. Why don’t we just do that? Run tests to see what’s interesting about the program.

Showing off a little example to see what methods have been called on what classes. Can easily hook into Ruby metaprogramming to figure it out, but the main problem with this is that it can be very slow and you need to run the whole program.

RESTful Possibilities - REST in Rails and Beyond Notes

2008-11-20T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is by James Golick from giraffesoft.

The Rails community has been outspoken about REST, but it’s starting to get a stigma where it’s associated with only Ruby/Rails/Java. However, that shouldn’t be the case. There’s plenty of other uses outside though.

Classic problem in computer science: two computers talking to each other over the network. Typically this has been done with Remote Procedure Call. The idea that you’re invoking a method on some service. Make the programmer feel like they’re writing regular old code, especially with SOAP and CORBA. Stack takes care of plumbing and isolates you from the complexities of distributed programming.

They have some big problems though, especially in today’s era of computer. Nearly 42,000 lines of code in the SOAP stack for Ruby. It’s huge. They create way more problems than they solve. Fail.

The web came around soon after these technologies, especially HTTP. Fielding described REST originally: representational state transfer. Absolutely anything can be resource. Used all the time: GET, POST. Don’t verb the noun though and complicate things.

Rails sought to standardize on REST. Based around the map.resources and routing system, which helps out a lot. Standardization is GOOD. New hires can be much more productive because of this. Cheap and clean API. Since there’s a standardization at a higher level, powerful tooling is available. Easy and refreshing integration. Ridiculously easy to use it, only a few lines of code to even integrate with Twitter. Even more, this makes happy developers, which can lead to a more profitable business.

Beyond Rails. Building on REST gets you a free server since there’s tons out there already, and a cheap client since they’re already implemented and easy to use. Looking at Starling as an example of this. 24% queue, 76% other shit LOC-wise with REST. Going through implementing a queue in Sinatra, which is really quite easy. Building apps on REST is good since there’s plenty of servers and clients out there that can easy consume and use the services without a lot of code.

Professional Ruby Conference Wrapup

2008-11-20T00:00:00-05:00

If you’re looking for the copious amount of notes I took for the conference, check out this post.

Speakers, if you have slides up, blog posts, or other stuff you want me to link to, let me know and I’ll make sure to add it.

I had a ton of fun at this conference. I was really honored to meet some of the smartest people in the business and really get a feel for the community at large. I think the most interesting part of the conference was the mix of people involved…it felt more like a big usergroup meeting than anything. Some people were very experienced, yet others were just starting to look into Ruby and what it has to offer them. Getting perspectives from both sides of the coin was very enlightening.

The boston.rb pub night/crawl was a great time too. (At least for most people) I definitely want to see the rochester.rb group start up again with focused presentations and I’m going to work towards making that happen. So, what I learned in a much simpler format:

Test all the fucking time. There’s no excuses. Pick a testing framework and go with it.

Ruby is slowly moving into the enterprise, and we have to fight hard to keep it fun and exciting.

Agile development principles are at the core of the Ruby community.

Pair programming helps a lot but is a skill to be learned.

Have fun and be passionate about your work.

Contributing to Insoshi with Git and GitHub Notes

2008-11-20T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk by Michael Hartl who runs Insoshi.

Michael wrote Railspace and was part of Y Combinator and built insoshi out of those experiences. It’s a developer run social network. They got onto GitHub during their beta and it’s really helped them out.

Another huge project on GitHub is Rails. Explaining the basics of Git and collaboration. Pushing to repositories, and most importantly: pulling down changes from cloned copies of the source.

Going over a few features of Insoshi. One such feature is common contacts, which should be as simple as Person.common_contacts_with(@other_person). Contributors submit code constantly that isn’t tested and somewhat messy, so it helps to clean it up. We’re going to go through the process of cleaning it up since there’s various problems from functionality to database vendor problems.

Showing off GitHub and forking a repository. Forking a repo…it’s absolutely the same! They have 2 branches: master (stable) and edge (slightly less stable). Forks can maintain separate branches too. They have a custom script that pulls down changes and creating a separate branch for your own changes.

Now that we have a forked repo and it’s updated. So let’s change the code write a test for our new functionality FIRST. Wrote a failing test and going to fix it in the code. Used the & operator to find the intersect between two arrays: person’s contacts and other person’s contacts.

Showing the git commit and push commands and the diff up on GitHub. The pull request feature on GitHub lets you make the project maintainers aware that you’ve made changes and lets them bring in your work. From there it’s out of your hands, but they will be notified.

Testing as Communication: Real-World Techniques Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Jon Larkowski from Hashrocket.

Subset of Obie’s The Hashrocket Way talk. No mismatch between what the customer says and what the tests give. Hashrocket values agility & transparency. Communicate all the f***ing time, but only if the overhead is low. Two lines of communication:

Client to developer
Developer to developer

Tools they use:

Pivotal Tracker: Awesome tool. They don’t write a line of code unless if a story in the application supports. Seriously, just check out http://pivotaltracker.com Tells you when features will be done with velocity. Again, just go to the site. This helps them out with communication because it lets them know who’s working on what. Also a huge scheduling tool. Helps developers talk to developers with estimation efforts.

Stories: All work is driven on stories. Only code what’s on the card. Stories are tokens of a conversation. Writing stories at a developer level where they can start implementing it is important. They used to use index cards but now they just use the Tracker. They slowly train customers to write their own stories. Standard forms:

As a / I want to / So That
Given / When / Then

They want to understand development efforts in a larger context, so this helps out to see the bigger picture.

Pair programming: Keeps developers honest, focused, and leads to higher quality code. There’s two wheels on the axle since there’s more than one person that knows the code. Laptops on either side of the computer. Ping Pong: one dev writes a failing test, other writes code to pass the test, rinse and repeat. Daily standups for the entire company.

Testing: Express client stories as tests with Cucumber and normal MVC tests. RSpec specdoc format creates documentation. Durable system specification since it’s in English. Tons of techniques used: RSpec, MVC, Factory Girl, Cucumber, Selenium, RSpactor (instead of autotest), Continuous Integration (CruiseControl), even clicking on stuff too.

Delivery: All the f**cking time. Delivered multiple times a day! Very tight feedback loop with client. Smoke test together to demo features. Deployment with Capistrano to EY or EC2. Some Passenger use.

Client Acceptance: Developer-assisted! Hold their hands for a while. Video chats, use the Tracker (automatic updates too). Daily standup with client to touch base.

Impedance Matching: Clients, developers, testers…all speak different language. The goal is maximum power transfer! Need to be able to talk to clients in their language, and not in geek speak. Bridging that gap requires a geek-to-english filter. Code however is a different answer. Getting the code to a geek speak standard is easy with regular code and MVC tests. With integration tests, it can bring that up to a level where both developers and clients can understand it: ENGLISH.

Surviving as a Windows Based Rails Developer Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is by David Berube.

Rails on Windows happens because sometimes it’s a MS shop that isn’t fully converted to Ruby. Fundamentally, Windows is not a good operating system. It just isn’t POSIX. Most Rails devs are using OSX and are deploying on some version of Linux. Windows definitely isn’t suitable for a server environment.

Easy way to get started is the One Click Ruby Installer (http://rubyinstaller.rubyforge.org) Many intrinsic pitfalls.

Automatic binary conversion: LF => CRLF. Sucks since you need a special flag to tell Windows not to touch it.

No Kernel#fork. Can’t do anything about it.

No GNU (commands).

No Compiler.

Running the actual development environment takes a lot of work. Visual Studio does have Ruby in Steel (but that costs money). NetBeans is clunky. He recommends using gvim, despite the obvious learning curve, since it can easily translate on UNIX systems. Emacs? E-text editor too has bundles, but don’t work all the time.

POSIXing your Windows box will never happen 100%. Cygwin is a good way to emulate the environment, but it sort of sucks. There are a few ways to emulate linux utilities too: unxutils, gnuwin32. Plenty of other tools too: PuTTY, Filezilla/SmartFTP, Litestep for Virtual Desktops and more.

Why switch? Go for Ubuntu! (If you can) It’s awesome. There are some bright sides…FXRuby and shoes for GUI stuff, and OLE isn’t too bad within Ruby either.

Sinful Ruby Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk from Will Koffel from Sermo.

Sermo is in the health industry and builds a social network for licensed physicians in the US. They have roughly a quarter of all professionals in the field signed up in the country. (100,000!) Creates a unique model for other businesses to come and get opinions from hundreds of doctors. Built with traditional Java setup. J2EE. JBoss. Moving to Ruby now.

Lust. Why would you bring Ruby into your business? Don’t jump in blind to it. Keep it professional! Top-down adoption in the organization: CEO latched on first by polling VCs. Choose it for the right reasons.
Gluttony. Teach it who’s boss. Is Rails too opinionated for your business? They have some interesting decisions that they didn’t want to change: No production SVN, sprocs/funcs. Make conscious choices about what to use.
Greed. Don’t need to take the plunge and go 100% Ruby if you don’t need to. Slowly brought Rails in through some ugly iframe hacking and session cookie reading. They use Thrift from Facebook in house to let Java and Rails talk to each other. Uses the Thrift server front-end to talk to the Rails app sitting in the background.
Sloth. Rewriting your front-end in Ruby just isn’t enough. Architecture, services, and data are still critical. Plenty of new constraints since they’re using two languages.
Wrath. Leads a trail of technological tears for the former stuff in use. JSP is being phased out, but destruction is sure to happen.
Envy. Change is hard. Ruby training offered for all developers. Some of the code has an ‘accent’. Build inclusive systems first. Lots of differences between Java developers that are stuck in a inheritance/package paradigm instead of Ruby mixins.
Pride. The deadliest sin! Don’t let the love morph into hate of other languages! Be PROUD though! Find the right ways to introduce Ruby into your organizations. Give back to your Ruby community! Start or join a usergroup! Help the language mature, it’s going to have the same problems.

Rock Solid Ruby Deployments Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Philippe Hanrigou (http://ph7spot.com)

Usually deployment is a bit issue/doubt with management and many others when choosing to go with Ruby. As Rubyists we may not be 100% familiar with all of the other tools that help web developers out, like lsof, strace, and gdb.

The secret to troubleshooting is knowing your stack! You just need to know the basic, fundamental principles that are operating in your stack. You also should know the tools to help out with poking around the stack. There’s some ways to look at the current Ruby interpreter thread: Kernel#caller, Kernel#raise. Thread#raise too, but not so much.

The next layer: Mongrel. When mongrel starts, there’s one thread (or cog, visually). The first thing Mongrel does when a request comes in is handle the request and spin off a new thread. There’s a Rails handler to marshal the request and attempt to get a hold of the Rails lock. From there, Rails takes over and talks to the database, etc…but that might take a long time. Other requests are going to spin new threads in Mongrel and sleep until they can obtain the lock on Rails. Phillippe created caller_for_all_threads, which gets a hash of all traces from all threads in Mongrel. You can send a signal to Mongrel and get a dump of where all of the Mongrels are. This will be in the next version of Ruby Enterprise Edition too.

DTrace! A dynamic tracing tool that can trace the entire fucking stack. All of the other tools like GDB and strace live in the user space, not the kernel space. DTrace runs within the kernel and it can see everything: application, interpreter, and system. Using one tool, you can get information from your DB, memcache, Rails, Apache. It’s not a static view tool: it can view multiple parts of your system through probes that can be tracked. Since probes are off by default, adding in probes is very cheap.

The main problem is that dtrace isn’t ready yet for Linux. Paul Fox (http://www.crisp.demon.co.uk) is working on it, but it’s not production-ready.

DTrace is really good at inspecting garbage collection. Can see when it starts, stops, when exceptions are thrown, and even more. The tool lets you drill down and find the problem easier. It helps you pinpoint the actual performance bottleneck in your infrastructure. You can even see which ruby methods are slowing a particular group of Rails actions. Obviously, database methods will be slow. Can also figure out your memcache hit ratio, slow db queries, network i/o, and more. There are plenty of ways to hook into DTrace from Ruby: tracer, ruby-dtrace. Can allow you to hook into Rails very easily. Once again, know your stack!

Rails AntiPatterns Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Chad Pytel and Tammer Saleh from Thoughtbot.

They’re gonna talk about things that they’ve seen that have gone wrong in the Rails world. It’s not gonna teach you to do TDD. It’s gonna show you how to fix code better.

Move code from controller to the model. 14 lines is TOO long for the create action. Might be crazy but you need to keep your guard up. Some crazy stuff is going on in this method. Transaction, catching an exception too. Refactored so it’s a bit smaller, but not ideal yet. Refactor by identifying parts of code that are identical. Try to weed out unnecessary code too. Use AR callbacks when you can, a LOT easier. DO WHAT YOU MEAN. Have expressive callback names. Constantly check for code that isn’t needed. Don’t violate the Law of Demeter…keep things DRY and look into the rule when you can. Use conditional callbacks in Rails 2.1 to remove even MORE code. Once again, push actions down into callbacks when possible. Get rid of transactions if you can. Only rescue exceptions if they are truly exceptional!

Putting too much domain knowledge in the controllers is BAD. They move state checking out of the controller and into the model by defining a hash and dynamically creating methods to check the state. Tackle large refactoring iteratively! Shove business logic into the model. DRY DRY DRY. Use named scopes instead of having complex finders in your controllers.

User Roles. See them all the time in apps. Ugly, messy, thoughtless code. Instead of having a role model, use boolean fields if you only have a small number of roles. If more than that, use has_many and not HABTM. Don’t build beyond the requirements and don’t jump to models prematurely.

Bad code happens to good people. This was all production code that they definitely wrote, but looked like crap 3-6 months down the line. The real lesson is to always be refactoring.

Payment Processing with ActiveMerchant Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk by Cody Fauser from Shopify.

Why use it? Need money from customers to survive. Started very small and eventually morphed into Shopify. Shopify had to deal with tons of little idiosyncraies with how different clients wanted to interact with different payment gateways, so they extracted out this logic to make it easier.

All they wanted to do was charge money and not worry about the payment gateways. Just send the order form and ActiveMerchant handles the rest. Roughly 50% of Shopify’s gateways use PayPal Website Payments Pro. All of the gateways just WORK. Very easy to tell when it’s the provider’s problem because they have a lot of clients and can tell when they break.

The goal: A simple, uniform API. Another important thing is interpreting the results that come back from the gateways. AM takes care of abstracting all of the messy handling away for you. AM is essentially a universal translator. The alien languages = payment gateway’s APIs. Our language = Ruby.

Terminology:

Cardholder: person you want $ from
Authorization: Verifies & reserves funds on card
Capture: Makes authorization for settlement
Settlement: transfers authorized amount to your bank
Sale/Purchase: authorization/capture combined
Address Verification Service: Fraud protection mostly.
Card Security Code: 3/4 digit code on the back of a credit card. More fraud protection since sites are forbidden from saving it
Payment velocity: Keeps transaction history to keep track of scammers. They keep a hash of the credit card info and check it if the card is submitted again

Authorization process takes a long time (4 seconds) and you need to be able to have enough Mongrels to handle. For the other end of the process, settlement takes a few days for the banks to deposit the money. Showing off some code now about how AR works. They use integers for cents instead of worrying about floats and rounding errors. Very simple, clean code. The difference between choosing merchants is as simple as picking the right gateway class for the merchant. The rest of the code to interact with the gateway is the same.

So, the benefits: it’s pretty damn simple overall. Rich credit card object that has plenty of validation and helpful methods that do pretty much anything and everything you need. (card.display_number => XXXX-XXXX-XXXX-1337 for example) AM takes the response from card security code checks and puts it in a form where you don’t have to think about it. The community has grown substantially…it’s open source! Most of the gateways have been implemented outside of Shopify. The project is very extensible and the development time for new gateways it quite low. It’s production ready code. Well tested, high quality code.

Mobile Developments Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Matt Pelletier from Eastmedia.

Going to talk about the mobile world. ~280 million PC sales worldwide. Around 1.2 billion mobile handsets too. The technologies that are in play:

Voice
SMS
MMS
Mobile Data Services

Voice: How all of the telcoms started, obviously. Normal calls. Robots too. Tons of VoIP technologies too: Voice XML, Asterisk/Adhersion

SMS: Just recently started to surpass the number of voice calls in the States. SMS has long been used in South Korea/Japan. More SMS than email there! Mobile Terminated: you send a text message, Mobile Originated: you recieve a text message. SMS works even during emergencies and when phones are normally down since it wasn’t originally a consumer service. There’s no metadata associated with an SMS though…just time and 160 characters. Can’t reply even.

MMS: “A total shit show”. Even Apple ditched it and used email. It’s very carrier specific and abritrary. Hard problem to solve though.

Mobile Data Services: Most sharply rising area that’s important to businesses. WAP 1.0 was a disaster. WAP 2.0 is a trimmed down Web. Trimmed down version of XHTML. Matt used this for their New York Jets project, which got 2 million hits within 4 hours when Brett Favre got signed. Crazy. The “REAL” internet. is involved here too, sans Flash. Browser War v2.0: MobileSafari, Opera, Android Browser, Skyfire. Tons of apps now too. These used to be controlled by carriers in the US, but it’s changing. This is being slowly eroded by the App Store and Android’s Marketplace. App development process is MUCH better than it used to be, but it really isn’t the Web. MANY MANY operating systems on each phone. The best approach to creating these seems to be hybrid: SaaS, iPhone app consuming a Rails app.

Smartphones are becoming more and more common. What exactly do people want? Twitter/Facebook: talk to each other, find places, search. Americans use the mobile web as an extension of the desktop. Location Based Services aren’t quite there yet. GPS is still slow. Not able to figure out exactly where you are yet.

Spot.io: Post online strange stuff you see that’s location based. Entry points: Twitter, IM, Email, API with OAuth, iPhone client. They’re also parsing english to extract the most knowledge. Using a hand written parser since people don’t write the same on Twitter as they do on the Wall Strett Journal.

iPhone Development: Feels like Rails community 3-4 years ago. Sparse domain knowledge and poorly organized. Apple’s SDK has code examples but has a lot of holes and problems. Not many good code conventions, but not that bad given it’s been out for a year. Apple and Google have squeezed down the multiple layers of complexity to a point where you just have to worry about the APIs.

Messaging with Ruby on Rails Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk from Blaine Cook, formerly of Twitter. Now he’s in Ireland!

Building messaging systems is simple. Talking. Mail. Telephones. Messaging helps out a lot with AJAX. Parallel processing too, especially with technologies like MapReduce. Also important to decrease latency. Definitely important because latency determines context.

HTTP really isnt messaging. There’s a requester, and a response. Not ideal…ends up with a system that constantly asks “are we there yet?” Also need a specific address for it, and low latency. You want online messaging to be like fedex: deliver straight to your door, not to a mailbox where you have to go pick it up. Definitely needs to be asynchronous!

There are many options to do this online: RabbitMQ is Erlang, but a bit odd. ActiveMQ is more enterprisey and Java-based. Starling/beanstalkd are very lightweight, simple, but not a lot of features. Gearman/TheSchwartz is more of a distributing processing framework than a queue server. cron could be used, but it’s not designed to handle large numbers of messages. TONS of protocols too that each use.

The queue server/broker needs to be durable: There needs to be a guarantee if the broker dies that the messages are going to get delivered. Beanstalkd doesn’t have any durability, Spread not so much in some situations. Obviously durability is very important, especially for some domains (financial stuff). Reliability is important too! Starling works a lot like Mongrel: can scale very easily, works well with multiple brokers acting together.

Another important idea: Safety! If the queue server can’t finish a job, the job will get picked up by another broker. Starling doesn’t have this…results in dropped messages because workers crashed. Very application specific, but basically you need to be able to ensure that the message isn’t sent twice while recovering.

Blaine recently built and released ActiveQueue. There’s many different ways to tackle this problem: Workling, Nanite. Probably 15 different queue servers released in the past 2 years…which is fantastic since it shows that people are using it and it’s growing. Doing it yourself is possible too. Clients talk to a queue, and workers pull jobs off the queue. Workers talk to the queue, and don’t forget to throw in some monitoring of the workers & clients.

The future: XMPP and cross-site messaging. Moving towards a low-latency, addressable internet! Right now, it’s like checking to see if everyone you know has sent YOU mail. We can do better than that! Servers need message-oriented backends to deliver message-oriented frontends.

Battle Royale: Merb's Role in the MVC Holy Wars Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Foy Savas. He’s a Ruby Application Developer and a contributor to Merb and DataMapper Just for Foy:

Dan, you better pay up.

The list of web frameworks goes on and on! It’s important to keep an open mind. Merb has influnces from Django/Pylons from Python. It’s meant to do what Rails is bad at: quick responses. What is it now? High performance, quick to deployment, fully scalable.

We can make analogies between the frameworks.

Application performance: Looking a graph of how the frameworks stack up for requests per second. Fastest is merb routing, faster is merb controller, merb itself handles rendering pages. Rails and Merb eat cake for breakfast…but merb blazes ahead! How? Uses Ruby, Picks the best, tests for speed. No Symbol#to_proc, considered evil. Merb saves big with design decisions. Merb inline templates into controller as methods! No copying like Rails does. Merb is committed to performance: future releases can’t be slower.

Abstract controller: exception, mail controllers. No double renders. Merb uses case statements instead of responds_to. Merb has a worker queue baked in with run_later! Pushes it out of the request, response cyce. Merb is Rack-enabled. Super easy. Magical stuff is possible with Rack middleware and multiple versions of Merb. ActiveSupport is a kitchen sink. Extlib isn’t. Only what you need, nothing you don’t. Matz loves the Merb too.

DataMapper kicks AR’s ass. Auto-migrations, identity map, lazy loading data sets. Rails loves alias_method_chain. Merb hates it and would rather just refactor. The Merb API public method interfaces doesn’t change without timed deprecation. Private methods aren’t supposed to be used so they can factor. Plugins are gems!

Merb Slices: Rails engines and an official part of the app. Extract code from your app and use it on others. Merb Auth: RESTful authentication that uses the cascading strategy pattern. And more. So much more.

Tons of Rails production examples. Not so much Merb. But they should be counted as Ruby apps.

Marketability! They’re looking to get real with Rails. Looking for smart people no matter what. Gotta respect the leaders of the community.

What’s the Merb Advantage? Gems. Modularity. Performance. Stack agnosticism. Open-Endedness.

5 Great Talks Notes

2008-11-19T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is a talk about talks from Matt Knox (filling in for Giles Bowkett, who didn’t show)

Matt had a bit of a different start with Ruby…he learned Rails for a job. Head down coding, didn’t get involved with the community at all. Eventually he got burned out on it, and he started to get involved and going to conferences.

1) Avi Bryant: Smalltalk is awesome, Maglev is gonna rock. The language itself is strange, but is veyr powerful. Maglev is crazy, alien technology. Been working on it forever.

2) Luke Francl: Testing is overrated. Huge norm violation. Amazing that someone has the courage to do this. He was showing that there are many other ways to increase code quality: proofs, reviews, and more. Unit testing works well though.

3) Damien Katz: Hugely inspirational talk. He sold his house, moved down to NC to write software he was passionate about. He’s now writing CouchDB and it’s part of the Apache project.

4) DHH: Talked about how RailsConf moved from 30 people meeting after RubyConf to a huge conference. He talked about how Ruby isn’t on the fringe anymore. This is the “great surplus” speech, and it will end at some point. The mainstream will copy Rails, something new will come along, or Rails will become the mainstream. What should we do about this? Do OTHER stuff than programming. Read paper (books!). Program less. Get a hobby. Work 4 days/week.

5) Giles Bowkett: Utterly ridiculous. It was about patronage in Renaissance Europe and how it draws parallels to VC now. What happened was that the artists were worn as fashion accessories that were funded by the rich. As you make money you can go from being a pet monkey to being your own monkey owner! Since it’s cheap to develop apps now, VCs aren’t necessary.

The many facets of Ruby at AT&T Interactive Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Coby Randquist from AT&T Interactive (and a partner at Confreaks!)

They’re already TOO BIG. They handle this by breaking these things down into smaller teams. Everyone does TDD! Mobile development teams too: iPhone, Blackberry, Android. Project managers, plenty of designers. Huge team.

The site (YellowPages.com) is one of the highest traffic sites on the net. 27 million monthly uniques, 165+ million page views. WOW. Basically, they replaced a legacy Java legacy application with a Rails app and service tier with a small team in a manner of months. It’s been live since July 2007, currently running on Rails 2.1.1.

How did they scale Rails? Load balancer gets requests that figures out which datacenter to hit it. Load Balancer there => Web Tier => Load Balancer => Service Tier => Load Balancer => Oracle Cluster.

Web tier: 8.4k LOC, 20 servers/data center, 16 mongrels/server. Minimal AR. Communicates with service tier primarily. These process ERB and HAML. CDN servers for images, js.

Service tier: 10k LOC. 8 servers/data center, 30 mongrels/server, memcached. Talks to search engine and oracle DBs.

Their production environment runs a custom compilation of Ruby. Plenty of other little tweaks for speed boosts. They’re rewriting their service layer in Merb! Why? Rails footprint: 60MB/mongrel. Merb footprint: 25MB/mongrel. Huge difference because of their traffic. Hopefully will deploy by the end of the year.

They’re huge into Open Source. Plenty of open source projects on GitHub: waves, functors, kablame, crufty, hoshi, live-console. Lots of fun little apps that their R&D is playing with: ‘Speak 4 it’, ‘Need 2 Pee’. Research being done with search, natural language recognition, speech recognition and more. Their site is a huge force in hyperlocal searching.

Content from other presentations: Their interview process is quite interesting…they send ruby code first and give candidates and hour to complete a unit test with a class. They use SVN for version control and most developers use git-svn.

Riding Rails at the New York Times Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Ben Koski from the NYT’s Interactive News Technology team. The team is a recent addition to the company…6 backend, 3 frontend people. They’re a part of the newsroom…directly working with reporters! Journalistic instead of business.

Big difference between journalism on the web vs. of the web. On: copy paste from the newspaper. Of: connected multimedia, assets, and more.

Plenty of Rails apps living at the Times. Big ones like the election tracker to smaller ones like a Guantanamo detainee library. Each application should tell a story…not just a data dump on the web. Showing off the other various apps that they’ve done. Dynamic backends, internal research apps, and even more static include generators.

Going over the election results from the AP feed and the architecture they used to tackle Election night this year. Feed had live results, county-by-county. They had to figure out how to split up 153 different files every 3-5 minutes that were comma-delineated. They used this for the primaries…but it wasn’t going to cut it for the general election.

AP schema feed just wasn’t rails friendly. (Duh.) FTP is slow, long updates, long rollbacks because of massive amounts of data. Interesting way how they handled updating the production tables from the AP feed by adding in staging tables to ‘buffer’ changes. Some awesome stats about how their architecture handled the lode.

Ben is now going over some what they used to speed up the app. Second highest day of traffic ever in Times history. How did they scale Rails? They didn’t! Well, wait a minute. They used Rails to generate the HTML and uploaded that up to /www. Works well for high traffic since there’s no need for dynamic content/interaction on the site.

More scaling static content techniques: Used memcache and load-balancer caching. Pulled AJAX requests from a CDN, reduced how big the page was, and grouped flash content into one file.

Strengths:

Rapid start, raw data to app in hours
Tweak-friendly. Can easily change stuff because of Capistrano.
Ability to drop down to SQL in AR is essential.
Web code works well on command line. (In other words, PHP can’t do that.)

Weaknesses:

NYTimes is mostly a Sun shop. They use EC2 for most stuff.
Deployment. What? I missed this.
Admin interface isn’t there out of the box like Django.

Refactoring Complex Domains in Ruby on Rails Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Shane Harvie.

Inheritance vs. Delegation. Need to make sure that you’re using the right technique. Going over a simple example with a bike that has various properties. We want to be able to change the type of bike it is at runtime. State pattern would work well, but let’s use them with module extension.

However, Ruby doesn’t natively provide a way to unmix a module. However, there’s a new gem called mixology that allows you to do just that.

Domain evolution. Fat controller are bad. Service layers are good, but can get fat too. Behavior should be defined within models.

So we’re modelling a network with various nodes, in building. They can be physically connected or wirelessly at a certain frequency. Nodes can’t have more than one physical connection. Obviously a decently complex example. Getting a little lost with this example, sorry folks. Creating a service layer helped out a lot. Extracted functionality out to a separate module that handled the complex logic of building nodes.

However, changing requirements completely mucked up that model. Rewiring multiple AR models is tough! The main problem is that the logic that decides how to do the change gets mixed up with the logic that actually makes the change. The query is mixed with the modifier! There needs to be a way to figure out what the new network would look like if two nodes were connected. This goes on and on until what’s being returned gets ridiculously complicated. It’s much better to refactor out into a results object. Way more examples…I need to pick up Shane’s book.

Professional Ruby Conference Notes

2008-11-18T00:00:00-05:00

I’m going to attempt to live blog and take notes about the talks at the Professional Ruby Conference today and tomorrow. Stay tuned! :) (By the way, huge thanks to Antonio Cangiano)

I’ll keep this post updated with links to the other conference notes posts as the day goes on.

The slides are going to be posted here. I’ll link the slides to my notes once the conference is over.

Tuesday

Wednesday

Thursday

Professional Ruby Conference Keynote Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This is the keynote of the conference from Obie Fernandez. He’s going over the Hashrocket Way, or how he runs his company. Explaining the origins of the hashrocket logo…80s rock. Pretty metal. Going to explain how they work…based on Agile: Extreme programming, scrum, their own experience. Four principles in the manifesto for agile software development:

Individuals & interactions over processes and tools

Pair-programming. They use 2 people in front of one computer, 2 keyboards, 2 mice. Both people that way can code and can be contributors. More productive despite only one workflow. Why? Less interruptions (Twitter, questions, bosses, etc) A lot easier to continue when two people are working on the same thing if one person needs to take a break. Pair programming is a SKILL to be learned! Benefits come out over time, not immediately. Need to work at it. Continous code reviews => produces high quality code => less defects and problems. LEVELING UP of knowledge because of working closely with skilled people.
No interviews. What? No, wait. Phone interviews first. But beyond that, no. Can’t figure out how they work until you actually WORK with them. Obviously a bit of a problem…but they should be able to make it if they want the job.
Don’t get too big. He doesn’t want the company to get bigger than it is. Rails is productive and the team size can stay small because of it.
Small teams. 2-4 people. Roles can rotate…generally a designer + a senior person who’s overseeing + client = sweet spot of 5-7 people for a team. Very self-organizing.
Everybody together. No one works remotely at Hashrocket. Ever. They have a Guest Star program to bring in people for fresh ideas. They bring in people on short-term engagements. Just bring them in for a week, brings in new blood, excitement, new thinking.

Working software over comprehensive documentation

TATFT. Test all the fucking time. Showing a snippet from Brian Liles’ talk.
RSpec. Think in terms of specifications. Protection against regression, documentation generated for them in the output.
Minimum viable product. What’s the least you can do to get a working site up. Rails Rumble 2007…powerful constraints, powerful deadlines. Hashrocket builds sites for clients in 3 days flat. How do you do this? If distributed, bring people together in one place.
Small Releases. Very short release cycles. 2-3 weeks sometimes, but multiple deploys a day for some clients.
#Customer colloboration over contract negotiation
Onsite customer. Talk to them face to face and get them to answer the questions. Find a way to make your environment desirable. (You can see the beach from their office!)
Visual Design FIRST. They require design documents first. Not exactly an XP practice. They focus on programming not design. Awesome hybrid process graphic…combines steps from classic waterfall with modern, iterative agile methods.
User stories are used to define requirements. Narratives about features, with acceptance criteria and relative effort required. Provides a backlog of how long tasks take and leads to better estimation. They use ‘storycarding’ to figure out how long features/tasks will take.
Master Services Agreement. Way more about this on Obie’s blog. Defines the relationship and business partnership. Legalese. Keeps IP property separate. Keep these documents simple…(Doesn’t look that way to me).

Responding to change over following a plan

Pivotal Tracker. Cornerstone of his business, and it’s free to try! Shows current features and a backlog of current ones. (I wonder how this compares to Lighthouse!)
Standup meetings. Literally stand up to keep it short. Phone call every day with clients too. Traditional scrum style standup…what are you doing, what did you do.

One more thing…HAVE FUN! Should be fun since Ruby is awesome.

Nature Network Stays Agile in the Enterprise Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Matt Jankowski from Thoughtbot.

Showing some hilarious images when you google ‘enterprise’, ‘agile’, and ‘agile management’. All ridiculously complicated. Agile is Thoughtbot. The enterprise is a old, huge publishing group in London. The site itself is social networking for scientists. Provides a forum for online communication and allows them to share research data, etc. Had over 28 people in total working on the project for at least a month.

What is Agile? Obie explained a lot…but they do “lowercase agile”. Not 100% to all conventions. TDD + BDD / TATFT ^ XP. No pair programming. Elements taken from ‘Getting Real’ by 37signals too. Lightweight, goal-driven development.

What is enterprise? Meetings. Spec documents. Layers of management. Constant re-organization. Bureaucracy. Internal politics. People who “just” want a job. Frowning on people like that just isn’t cool.

Goals between agile companies and enterprise companies are very different. REAL goals are different. Are the cultures at odds with each other? Can they work together efficiently?

Getting to the case study! They had some crazy routes that the client wanted, and didn’t have leverage to say no. Having someone with no check on their power that makes crazy decisions is bad, mmkay? They used JIRA for issue tracker. Ridiculously complicated and not a communication tool like Basecamp is. They also used Perforce, centralized SCM, which emphasized control, not trust.

Plenty of stakeholders in the project that had conflicting and related requirements. Ad sales, editors, IT Group (Keep this crazy ruby stuff away from our Java app servers!), Developers (keep crazy ruby code away from us!), product/branding team, system architects with tons of experience, QA team, analytics, design team.

Developers were obsessed with test coverage, not product quality. Obsessed with semantic/valid markup, not site usability. Elegance & refactoring over how the site feels/looks. Developers aren’t just coders! Devs must have constant access to product team, but the product team can’t interrupt devs.

Production site was still very high-quality. Hire excellent people. Enterprise is about avoiding risk and managing change.

JRuby: Who What Now? Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

Talk from Tom Enebo from Sun Microsystems. He’s the co-lead of JRuby.

You don’t have to be a Java programmer to use it. It’s just Ruby! Compatible with Ruby 1.8.6. Proving compatability…passing against tons of Ruby/Rails tests. On target to put our 6 releases a year, 15000 bug fixes, ~3100 changesets. Performance is great and improving.

They’re working on Ruby 1.9 support and Java interop. They just released 1.1.5 two weeks ago. Added some caches, supposedly 5-20% faster.

Some issues:

Native-threaded. Not a big deal.

No native C-extensions. Ported over some libraries that use it, work to do them

No Continuations. (What the heck are they?)

Foreign Function Interface: call C functions directly form Ruby. Joint API, started with Rubinius. It’s now a gem. (This reminds me of dropping down to interop/pinvoke in Windowsland). Going over an example use of the FFI gem.

1.9 support done by christmas, hopefully. They want to put 1.8.6 and 1.9.1 support in the same binary. JRuby makes Java fun again! Tom is starting to go over a neat 3D pong game that he rewrote in JRuby. It’s Ruby code, not Java.

Why Java? Fantastic VM…500 man-years total on it. (Jebus.) Other typical pro-Java arguments. Going over how JRuby optimizes loops. Garbage collector is better, native threads, more tools (debuggers, IDE, profilers), more libraries.

Why use JRuby on the web? Once again, it’s EVERYWHERE. Less political resistance too. Other options: Warbler, Glassfish. JRuby lets you put in parts of Java where you need it.

Why people are using JRuby: No new software to install, Java libraries fill a void in Ruby (like Swing), works on Windows. Code obfuscation works well since JRuby generates Java bytecode in a way that no decompiler can understand it yet.

Introduction to Mongrel Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Matt Pelletier from Eastmedia.

It’s a HTTP server written in pure Ruby. History…other solutions were SLOW! FCGI, WEBrick, mod_ruby sucked. Translation into CGI just slowed everything down. Zed Shaw decides to just write a full HTTP server. Fast, light, plays well with other servers, very configurable and flexible.

Huge design goal was SECURITY. Most security holes were the fault of human oversight, crappy hand-written parsers, HTTP spec doesn’t limit sizes. He decided to implement security by putting caps on a lot of the request parameters.

Production environments: Rails isn’t thread-safe, but processes are cheap. Use mongrel_cluster to configure. DON’T use it for SSL. (There were some other no’s too, but it went too fast) How many mongrels? Depends on your app. There’s simple ways to calculate and forecast how many your app will need depending on load and other factors.

Mongrel is thread-safe and is faster than Rails itself! There are plenty of other web servers available to…Swiftiply, Thin, Passenger.

Four Years of Ruby Development Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Ezra Zygmuntowicz from Engine Yard.

He’s going to go over his history working and deploying with Rails.

Started with WEBrick, which rocked for development but obviously not for production. He first tried out Apache with FastCGI. Didn’t work that well either. Had to write scripts to kill zombies.� Lighttpd + FastCGI was bad. Lighttpd + SCGI was bad. Another Apache combination that sucked too.

Then…MONGREL! Pure text, can hit individual mongrels, great platform for sure and still in use. Lighttpd’s proxy module failed. Lightspeed was next and it was nice, but their license sucks. Mongrel + Nginx was next! This combination works really well and is battle-tested. Ebb is actually faster than Mongrel since it’s single threaded and event-driven. Mongrel though is still the best general purpose server.

Passenger has done an awesome job, but it’s geared mostly towards development and shared hosting/small VPS. Nginx + Mongrel or Thin for high volume deployments. Passenger might be there someday, but not yet. Ruby Enterprise Edition helps with memory, but Apache is a hog so it doesn’t matter.

Rack: the great equalizer! Boils down any web server down to an object with a ‘call’ method on it. Makes it a lot easier to write handlers that are server agnostic. Rack is fast becoming a standard and it future-proofs your code/app.

Nanite: builds scalable backends for Ruby apps. Nanite ‘agents’ report back to a broker, which then fan out reports to various Nanite ‘mappers’ on the front end. It’s built around RabbitMQ, which is written in erlang. This means it’s fast, clusterable, and very scalable. Apps just need to appear fast, not actually be fast. This system is crazy useful for building apps on scalable cloud sites like EC2. Basically, it makes it easy to build scalable backends.

Engine Yard As a Service! Going to open it up for other hosting platforms to use their infrastructure with. Other services are very low level, but they want to make it easy and approachable. They’re going to attempt to apply the convention over configuration that Rails provides to deployment. Instead of logging into your server to make changes, you log into their application and describe what your app runs on. It’s the genetic information of your app and allows for greater portability. Allows you to build an entire server from scratch and deploy your app with one click. This is a much different way of thinking about deployment! No manual changes, all done through site’s interface. Ridiculous.

Demystifying Rails Plugin Development Notes

2008-11-18T00:00:00-05:00

Part of my series of notes from the Professional Ruby Conference. See them all here.

This talk is from Nick Plante.

Work more on the ‘special sauce’ of Rails. Plugins can save you a LOT of time! Generalized, reusable code libraries. Lets us mold the Rails framework into what we want it to be and make it more powerful. It’s a lot easier than you think! Some examples: User authentication, Pagination, Asychronous Processing, View Helpers.

Why develop them? Internal reuse, opportunity to refactor & clean up. Also contributes to the Ruby OSS ecosystem! Most plugins don’t start as plugins. They really shouldn’t…they’re extracted/generalized.

Nick is going over an example of making a plugin for validating ISBN numbers. Lots of messy code lives in the model…it can hit a limit. Extract it! Use encapsulation and information hiding…Extract into /lib, or better yet, make a plugin!

When designing the interface for a plugin, KISS. Extend the Rails DSL in a natural way…many pre-existing examples to guide us (ActiveRecord::Validations in this case). Showing some examples of plugins, from Paperclip, acts_as_list, some for ActionController and ActionView too.

Make people learn as LITTLE new stuff as possible to use your plugin. Showing off an example module for the ISBN validation. Some methods I haven’t seen before: extract_options! validates_each

Why is it a module and not a class? A module is a degenerate abstract class and can be mixed into a class. Include for instance methods, extend for class methods.

Plugin hooks! Install.rb: Auto-run when the plugin is installed with script/plugin install. Used to show the readme and copy any assets over. (Uninstall.rb for the opposite). Init.rb is used to inject plugin code into the framework, runs when the application is started. Common idiom is to use self.included to extend modules as well.

NEED TESTS. (TATFT!) If you’ve extracted it, you should have the tests. Right? Some strategies: mock/stub out the environment if possible. Rake tasks are generated for helping out with testing plugins too. RSpec also has a plugin generator.

Distributing plugins is super easy. Any old SVN/Git repo, RubyForge, GitHub. They can also be packaged as Gems and use the various rake tasks for gem installing/unpacking. Why use Gems? They have proper versioning and dependency management. GitHub makes creating gems super easy.

Don’t be afraid! Read the Rails source too.

GitHub Rebase #4

2008-11-17T00:00:00-05:00

The latest edition is now up! http://github.com/blog/224-github-rebase-4

I really need to get some of this process sped up and automated. Currently I have to manually look up all of the repositories, and creating the table was a bitch. I also need to figure out how to make my Rails site that processes GitHub’s RSS feed to be multithreaded so it doesn’t take an hour or two…or three…to figure out what’s going on with it.

GitHub Rebase #3

2008-11-09T00:00:00-05:00

Geez, it’s been 3 weeks already? The third installment is up at:

http://github.com/blog/208-github-rebase-3

GitHub Rebase #2

2008-11-03T00:00:00-05:00

The second edition of my weekly installment is now hosted at GitHub!

Next week I’m going to release it on late Saturday, or perhaps early Sunday. It’s a bit late this week, but I don’t think anyone will notice.

GitHub Rebase #1

2008-10-26T00:00:00-04:00

This is the start of a new weekly column that going to recap some of the action that’s been happening on GitHub during the past week. My goals with this column include:

Prove that Git is a great choice for version control!
See how active the community at GitHub really is and what they’re working on.
Show how Open Source development is truly open.
Using the magic of feed-normalizer, hpricot, and gchartrb, I’ve created a little Rails app (dubbed Rebase, of course) that I can use to rip all of the events that are going on at GitHub. I’m going to try to keep the format of the column consistent, but I definitely need your feedback to make it better.

Stats Breakdown

And, just for fun:

Notably New Projects

Each week I’m going to look over some interesting new projects that have just showed up on GitHub and explain what they’re about. If you have a project you think I should showcase, let me know and I’ll see about featuring it!

Wysihat: A minimalist’s approach to WYSIWYG/Rich Text Editor. Right now it’s very, very beta, but it has the support of 37Signals so I definitely hope it’s destined for greatness. Once some decent themes are created for it, I’d definitely consider integrating it in some of my sites. This project definitely is growing and needs help, so fork away.

Android: Google announced that their Android framework was going open source and was hosted on Git, so it was clearly only a matter of time before their code landed on GitHub too. They have a ton of projects in their codebase, but it doesn’t seem like all of them have pushed yet. Definitely looks promising though, and I really would like to see how their system works.

acts_as_passive_aggressive: Just in case you ever needed a way to vent on your users, this plugin provides the perfect opportunity. I love the project’s readme.

VoteReport: This is a new Rails site to track the election next week through Twitter. They’ve got quite a lot of documentation on their PBWiki, and I really hope that this site turns out to be a little more useful and fun than watching tweets fly by on Twitter’s election page. If you want to help them get the project up and running before the 4th, go for it!

javascript-xhtml-purifier: A new, robust JS script to sanitize HTML. I can guarantee that at some point most web developers will need to do this, so bookmark or clone away.
Next week I’d love to break down the stats a little more and figure out what commits were the most commented on, and maybe which projects had the most activity. Let me know what you’d like to see in the future!

Pumpkin Carving 2008

2008-10-20T00:00:00-04:00

In 2006 I created a stormtrooper. Last year was HomestarRunner. This year however, I paid homage to the one and the only, Octocat:

This of course is the logo of one of my favorite sites, GitHub. We’re having our Halloween party this weekend so I made this guy a little early this year.

If you’re curious, you can see the creation process on my new Flickr account (their upload and photo managing interface is kickass!). If you’d like the stencil I used, just leave a comment or email me. Happy Halloween!

Where do you get Ruby news from?

2008-10-19T00:00:00-04:00

I’m wondering where other fellow Ruby and Rails hackers get their Ruby-related news fix from. For some reason I just feel continually disconnected from the community at large and I just want to make sure I’m taking advantage of the resources out there. So here’s my news sources:

Ruby.Reddit (http://reddit.com/r/ruby): This seems to be one of the most active sources, and usually the commentors are fantastic. It’s community-driven news at its best, but sometimes it’s a little slow compared to the other subreddits. What I like most about it is that the community is relatively small, so if you post a story it usually sticks on the page for a few days.
RubyFlow (http://rubyflow.com): I just got into RubyFlow recently, and it seems more like the community well than anything. You can throw a coin in and wish for some visitors to your blog, but you’re usually lost in the mix. It’s a very interesting concept though, and it’s definitely fun to see big names in the Ruby community on the list.
Ruby.Alltop (http://ruby.alltop.com): Alltop is awesome for getting an overall sense of where the community is right now. It’s Guy Kawasaki’s ‘magazine rack’ of latest Ruby stories…essentially a RSS aggregator. I’ve discovered quite a few blogs I didn’t know about and now keep track of through it. One of my goals with this blog is to get on there someday! :)

I suppose my secondary news sources would be Freenode’s various Ruby channels (mostly #rubyonrails) and the Rails mailing list, but I don’t check those as often. I’ve also heard about a secret channel, but who knows if I’ll ever get in there. Those also don’t have a handy RSS feed, so I tend not to check them as often. So, where do you get news about the Ruby community from?

Calculating Age in Rails

2008-10-13T00:00:00-04:00

You’d think that this would be easy, but for some reason it wasn’t, at least for me. Let’s say you keep track of a User’s birthday with a date field. Great! Let’s show the user’s age.

def age
  Date.today.year - birthday.year
end

Done! Right? WRONG. Worked fine for some users, until one of my coworkers asked me…hey, you’re not 21 yet…how’d you magically gain a year on your profile? Crap. Obviously this will work for everyone’s whose birthday is BEFORE Date.today, but not after.

So, we need a more exact method of calculating the age:

def age
  ((Date.today - birthday) / 365).floor
end
def age

  ((Date.today - birthday) / 365).floor

end



So what this method does instead is use the Rational value given by subtracting two Dates, and divides it by the number of days in a year. Since that number is still a Rational, calling floor on it will round it down to the nearest Fixnum, giving us a (slightly more) precise account of this user’s age. EDIT: But this is still inaccurate!
Yeah, I thought it was easy too. Perhaps this shows that I need to test my app a little more thoroughly! It also would be nice to save the age in an instance level variable, but right now I don’t use the age more than once on a page so it doesn’t matter.
EDIT: It looks like my method is still not sufficient for leap years! The comments have posted MANY great solutions. My method is fine for a general estimation, but the comments have many solutions for that deal with greater accuracy. I’m honestly not sure which is best, so choose carefully when you’re developing your app.

Loading custom code in Rails

2008-09-22T00:00:00-04:00

This is a question I’ve seen asked (including by myself) in #rubyonrails on Freenode quite a few times, and I figured I’d settle it once and for all. There’s a few different ways to get custom code loaded into your Rails app. The first solution to this is understanding how code gets loaded with Ruby in the first place, which I usually get confused with. Let’s do a little recap about your different options that Ruby and Rails provides:

load: Loads and executes the Ruby program in the file filename.
require: Ruby tries to load the library, returning true if successful.
require_dependency: Reloads source files on each request when in development mode, so changes are reflected on the next request.
require_or_load: There doesn’t seem to be much documentation on this, but it doesn’t seem as safe and it may result in your code being loaded twice. Review the code here before you use it.

So, the most ideal keyword to use is require_dependency, since it will reload code during development mode when you make changes. Otherwise, you’ll have to constantly restart your development server/console, and that just sucks. Plus, it’ll work perfectly in production mode and only load the files once.

So, where’s the best place to put the files with your custom code? Well, there’s a few folders that are on the Rails load path in the first place: app, lib, vendor and mock paths (source) you need to add different folders to the load path, that’s more than possible. In your config/environment.rb, add whatever folder you want in the config.load_paths variable. For instance,

config.load_paths += %W( custom )

This will load the custom directory (RAILS_ROOT/custom) to the load path so you can use those files. The problem with files you put in these directories is that they may be in the load path, but you’ll have to require the custom files you want in each class that you’ll want to use them. The solution to this is to get the file required for the entire Rails environment, which is a lot easier than you’d think.

Let’s say we want to load some extensions to String for your app. Being a forward thinking developer, you’ve created a new folder in lib, called core_ext, where you can put other ruby files in the future if you need to. So in lib/core_ext/string.rb you’ve dumped for example:

class String
  def slugify
    self.gsub(/[^a-z0-9]+/i, '-').chomp('-')
  end
end

The folder config/initializers contains files that run once when your Rails environment is getting set up. Create a new file in that folder and this will run through your custom folder and make sure that the files are required properly.

module CoreExtensions
  def require_core_ext
    Dir["#{RAILS_ROOT}/lib/core_ext/*.rb"].each do |f|
      require_dependency f
    end
  end
end
Object.instance_eval { include CoreExtensions }

So now, you can call require_core_ext in whatever class you want, and it will reload all of your custom code if you’re in development mode or if you’re in production, it will only load your custom classes when the file is first loaded. Now you can call String#slugify all you want, and if you make changes to the method in lib/core_ext it will be reflected when you refresh the page.

If you’ve got any other examples of how you bring in custom code, let me know, as I’d love to find out.

Switching to Rails

2008-09-18T00:00:00-04:00

For a while now I’ve been obsessed working with Ruby on Rails. Rails has caused me to switch from doing .NET/ASP.NET development on my desktop PC using Windows XP to owning a Mac Mini and putting Ubuntu on Dell laptop. Obviously, this is a huge change, and I’m going to explain why I’ve switched.

Rails is a combination of software engineering principles and web programming best practices.

In this respect Rails is a dream: Active Record. RESTful architecture. Built-in xml/json/etc web services. TDD/BDD practices. I could go on and on, but all that matters is writing Rails applications is an enjoyable and fun process. You’re not writing scripts for pages, not having to worry about the nuts and bolts of creating a site, or dealing with painful XML files. Convention over configuration is a real path to productivity, and it’s going to take the other competing systems a long time to catch up to the headway that Rails is making on a daily basis. Rails isn’t the solution to everything, and it certainly has had it share of growing pains, but it’s being proven again and again as the most efficient way to create data-driven web applications that are very reliable and follow web standards.

Tools on *nix based systems are a lot better for Rails development.

DHH puts it best:

The stigma of being a Web programmer still using Windows will increase.

For me, it’s not that much of a stigma, but more of a practical issue. The power of the Unix command line combined with tools like Textmate makes development on OSX and Linux machines for Rails a LOT easier. The tools on the Windows side are there, but they’re usually not as powerful and not as easy to set up. Cygwin is piss slow. Most of the non-Visual Studio text editors suck. The command line sucks, and I tried really hard to make it not suck. Even Ruby is slower! All of this pain goes away on OSX/Ubuntu. Rails would be a lot different if it started on Windows, and I wonder if it would really be the same platform. For now though, I’m loving the productivity boost that I’m experencing and trying out different operating systems, and it serves my needs well.

Bleak future of .NET development.

This one will probably get me flamed the most. It’s not that I don’t like .NET, it’s just that I couldn’t see myself using it any more professionally. I’m really not a fan of VB.NET, especially compared to Ruby. It’s a cruft filled language that makes me feel like Mort when writing it. Great things are possible with the language, but the result is so unreadable and ugly that I don’t feel it’s worth it anymore to use, especially if I can choose not to. C# on the other hand I love and always will, especially over Java.

What scares me more about .NET is where’s it’s going: Silverlight and WPF. WPF is supposed to be an awesome new platform that makes it easier for both programmers and designers to collaborate and create great applications. Seriously though, where are the great WPF applications? Why haven’t we heard as much about them, as say, the newest iPhone apps? I could say the same for Silverlight. Oh wait, the Olympics. ooh, Yahoo Messenger! Whatever. Nothing is going to kill Flash’s market share.

I’m sure that things have changed since I was heavy into (bleeding edge) .NET development 6-9 months ago, but still there seems to be no killer app for WPF or Silverlight yet. Until that happens they’ll just suck like everything else. I’d love to be proven wrong on this point, so if you know of one please show me.

If you’ve switched away from Windows or even if you’ve become a Rubyist/Pythonista in recent times, let me know what your experiences have been. For now on my blog posts will hopefully be a bit more frequent, and will chronicle various quirks and fun things I’ve found during my Rails journeys.

Raytracers, snowflakes, and Pac-Man, oh my!

2008-05-23T00:00:00-04:00

So yeah, this is pretty much what I’ve been up to for the past, oh, 3 months/1 quarter of school. These are a few of the projects I’ve done for my Computer Graphics 2 class (which I just got an A in, booyah!)

First up, the classic CG application, a ray tracer complete with phongphongphong shading, procedural shading on the floor, reflection, transmission, and even some tone reproduction.

Secondly, my quarter long personal project, a simple particle system/b-spline curve generator in XNA, dubbed Q-Blizzard. Turned out to be quite pretty, not exactly configurable though.

And finally, an image that won me a $25 Barnes and Noble gift certificate in the Pixar Renderman Shader contest. I won third place out of around 30 images! My roommate noted that I should have added an OM NOM NOM caption in for kicks.

Hopefully this will mark my return to regular blogging (going to try monday, wednesday, friday) for the summer and onward. Hell, if mittens can keep up his Daily GameDev.net postings for 2 months, I can do it too. Right? …Right? (I seem to tell myself every few months or so…)

Rock Band Rocks.

2008-03-27T00:00:00-04:00

It simply does. That is all.

Oh, you wanted to know why! Well, if you’re still reading and not playing it, there’s three reasons why Rock Band is an awesome investment (it’s still $169.99) for your Xbox 360, PS3, or (soonly) your Wii. First off, the UI is a lot cleaner than Guitar Hero 3’s.

Now, do remember that 1-4 people are watching the TV at a time for Rock Band instead of only 1-2 for Guitar Hero 3. However, the Rock Band interface is extremely simple. No complex images on the fretboard, a scoreboard that is easy to see, and the Overdrive meter is so much easier to understand than the star power gauges. All you want to know when you’re playing either of these games is what your multiplier is and if you can use your star power/overdrive or not. With Guitar Hero 3, they’re on complete opposite sides of the screen! Also, the star power gauge is made of lights that fill up, and it’s even harder to see when playing with two players. For Rock Band, all of that information is in one place, at the very bottom of the fretboard, beneath where you’re looking at most of the time to play notes. Obviously, the team behind Rock Band really looked at how people play Guitar Hero and what’s essential to see when you’re playing, and turned that into a brilliant design that’s easy and fun to play.

Secondly, the downloadable content rules. Grant it, I haven’t looked that much into GH3’s available songs, but Rock Band’s library continues to grow. My most recent downloads have been Limelight and Working Man from Rush, Crushcrushcrush from Paramore, and the huge Boston song pack. These new songs bring so much replay value to the game it’s not even funny. Obviously they have all 4 playable parts in the songs, but you can opt to play the downloaded songs in the World Tour mode. So now, I can earn money for new looks and instruments by pretending I’m Geddy Lee.

Finally, the drums just rule. It’s a completely different experience than the lead/bass guitars, and there’s something truly enjoyable about banging pretend drums with real drumsticks. It’s also a huge challenge for me, even on Medium the songs are pretty difficult, especially since the bass pedal is a central component to most songs. It’s a game controller like no other, one you can beat senselessy and not feel bad about it.

If you’re not able to get it yourself, at least visit someone’s house that has it, I assure you that you’ll definitely feel like a rock star, at least for a few minutes. Heck, if they get the new lights and smoke set, all you’ll need are some serious clothes to match.

Why I love Twitter

2008-03-25T00:00:00-04:00

I’ve become quite a twitterholic the past few days. In fact, let’s check the stats. Yeah, I’ve been pretty much addicted the past few days. Why? Well, there’s a few things I love about Twitter:

Twitter is short, sweet, and easy to use.

The concept is simple: 140 characters to tell the world what you’re doing. I don’t think you can get more simple than that. No complex forms, no huge commitments, just a simple request, and your simple answer. It has a wonderful web interface, and the settings allow you completely customize your page’s background along with colors for fonts. It’s just a breeze to use and easy to look at, which is a welcome change compared to Facebook or MySpace.

It’s an awesome way to network with highly connected bloggers.

I think Scoble puts it best:

You’re communicating to the world that you’d like to be listened to (golden rule: treat people how you’d like to be treated).

Twitter is becoming the heart of the Interblag. It’s what bloggers are doing when they’re NOT blogging. Obviously yes, we all have our jobs and commitments, but Twitter is a way to connect with those people between their blog, vlogs, or however they communicate with the internet at large. It’s a way for those who are connected to quickly poll, grow, and comment with their audience. The value to bloggers to be active on Twitter is absolutely critical: these are the people who you WANT to be reading your blog. They’re the people that will link your blog to others, they know where to share it and who to share it with. They’re all here folks. Come and find them.

It’s a great way to keep in touch with friends.

I think Twitter in Plain English hits the nail on head: Twitter is a way to converse with friends in a way that isn’t that important to email them, but doesn’t necessarily demands their instant attention. Of course now, you can use Jabber/XMPP to interface with Twitter. Anyway, I find it to be a neat way to keeping in touch with people I know in the real world online that isn’t exactly bugging them over AIM or Facebook. Also, if you’re concerned about random people like me following your every move, you can make your page private and only allow those you approve to watch your updates.

It’s just fun to use!

What really gets me with this are the fantastic clients that seem to be populating the net. The Twitter API is readily accessible and easy to implement, and that’s extremely important as it seems that most people use twitter through outside clients or through text messaging rather than their web interface. My personal favorite at the moment is Twhirl, which is an Adobe AIR client. It’s got a neat, clean interface and colors are customizable, so I’m having fun with it. I rarely have to go to the website anymore, the API is so open that the majority of the functionality is accessible through outside clients.

So, why haven’t you created a Twitter account yet? I guarantee you that it’ll do nothing but help you get your blog known, and connect with others who are on the same quest. Feel free to follow me as well, I’ll make sure to follow you.

Pimping the Windows Command Line

2008-03-20T00:00:00-04:00

Lately I’ve noticed that a few of my friends have been able to understand or even be aware of the Windows command line. I have a hard time myself pulling myself away from Explorer, but sometimes the command line is just quicker. However, it’s a bit drab by default. Today I’m going to show you just how you can pimp yours out a bit.

First up is a wonderful tool called Console2, which is an open source tabbed command line utility. It allows easy configuration of fonts, colors, the background colors, and even lets you do some really crazy things if you wanted such as adding a background image. The best feature by far though are its tabs, which I’m sure if you’ve ever used IE7+ or Firefox you know how useful they can be for multitasking. Another great feature is that you can set up plenty of keyboard shortcuts if you’re into that sort of thing. Check it out here: http://sourceforge.net/projects/console/

Console is great if you want to fire up a specific program all the time, but I’m used to slamming WinKey + R and typing cmd so much that it’s basically embedded into my muscle memory. So, I was looking for configuring the default prompt instead of running another program. Pimping out my command prompt has taken me quite a while to find the perfect configuration that suits my needs, and it’s constantly changing as I find new things to add. Here’s what I’ve done to trick mine out:

I’m using Consolas as my font. I absolutely love Consolas and I find it much easier to read than Courier New or the default font that the command window has. Consolas is not available by default and requires a simple registry hack along with a reboot in order to work. I haven’t had any issues with it thus far, and I highly recommend following Scott Hanselman’s wonderful tutorial.

I’m not a Windows command line user at heart, I was raised during my Computer Science classes to poke around Linux machines. Sadly, certain commands like ls -la come much more naturally to me than dir /a. My solution to this is installing the CoreUtils for Windows package, which adds most of the core GNU utilities into the command line. This hack requires installing a package from SourceForge and adding to the PATH environment variable, which are covered in this blog post over at AskStudent.com.

Finally, I’m a huge fan of using the pushd/popd commands: push directory and pop directory. Basically it’s a way to return to directories instead of having to overuse cd or even remember where you were. Luckily, there’s an easy way to keep track of the amount of directories that have been pushed onto the stack by changing the PROMPT environment variable to:

$p$_$+$g

Check out the AskStudent tutorial to see how to do get to the environment variables window if you don’t know how. What this does is add + symbols to the command line window as shown in the screenshot. It’s ridiculously useful, and now I just wish I could figure out how to automagically pushd and cd at the same time.

If you’ve got any questions regarding pimping out your command line or other great hacks I’m missing out on, let me know!

Defraggle Rock

2008-03-18T00:00:00-04:00

As always, I’m late to jump on the ~~fail~~boat, and this time I’ve decided to do some serious maintenance on my computer. I’ve had enough of having to rely on System Restore and worrying that I’ve lost all of my data, or that my computer is on the brink of death. So, I’m going to start maintaining my system more, and that’s starting with keeping my hard drive as tidy and speedy as possible.

My buddy Island Dog pointed me towards a great tool called Defraggler, and this started my journey. Essentially, it allows you to really control the defrag process from a drive and individual file level. It also includes the color graph that sadly, Vista removed. Obviously, this tool is pretty much only for power users, as I’m sure grandma doesn’t even know the slightest about what a hard drive even is. Partly I’m glad that Vista streamlined the process of defragmentation, but I have a feeling normal users won’t be doing it regularly until Windows does it for them or it’s watered down to one huge button called “Drive Maintenence” that does Disk Cleanup, a defrag, and whatever else fun stuff Microsoft decides that your drive needs. For users like me however, I like having a bit of control. Not too much though, I’m not a supervillian.

Anyway, Defraggler is a very neat app. It clearly presents the process, what files need to be moved around, and shows your data being moved around. It also allows you to switch the process priority from normal to background so I can actually use my computer during the process. This is nice for XP, while the visualization helps on Vista. I find the color graph absolutely fascinating since I’m scared to death of low level stuff like this, but my mind does wonder how defragmentation works under the hood. Maybe someday I will be a supervillian after all…just definitely not using Linux to control my orbiting brain lasers.

Turning off the Firehose

2008-03-16T00:00:00-04:00

I recently came across this post about a user who decided he had enough of the user-generated news community, Reddit. I’ve been a Reddit user for a quite some time now, and I’ve done my share of down voting Ron Paul stories as well submitting silly pictures that have made it onto the front page. Lately though, it’s become more than a habit to check this site. I have a very compulsive personality, and I tend to find some sort of deep and intensive joy in small, minute improvements and changes. I know this is the reason why over 70 days of my life were wasted on World of Warcraft, and I’m pretty sure it’s the reason why I find programming so fun. Most people would be frustrated by missing a semi-colon and be absolutely stumped by the quest for perfection that compilers demand, but to me it’s another challenge, another hurdle I know I can overcome. It’s also the reason why some days I’d refresh Reddit every 5 to 10 minutes to see if my karma had changed.

Reddit has been sucking up way too much of my time during the day, and I’ve decided to put an end to it. All I did was block it through my hosts file to redirect to 127.0.0.1, which works out well since during my work time it directs me to the website that I’m developing.

So, I’m turning off the firehose. I will probably end up blocking Digg and Slashdot as well, and I need to set up Google Reader for my favorite blogs. Yeah, this means I’ll sacrifice that information intake that my brain is used to, but I feel that time could be used to read the several books I have lying around my room, be it Code Complete or the Mythical Man-Month. My guitar is also gathering plenty of dust, and I have a few side projects that I could be working on as well. Here’s to less distractions! Do you have distractions that you could probably do without?

5 Things That Video Games Do That Really Make Me Angry

2008-03-13T00:00:00-04:00

I’m sure that this list could be a lot longer, but I’m going to focus on six issues that really piss me off when I’m playing video games. If games happen to have more than 2 or 3 of these traits they tend to collect dust in my game cases very quickly, or they will do the same at your local game store. So, without further adieu:

Not being able to skip cut scenes

Sometimes, gamers just want to jump into the action. Yes, I know that designers have spent grueling hours working in their wonderful plot into the game, and skipping cut scenes may mean that the gamer will miss out on crucial story elements and possibly even essential game hints. Well, that’s just too bad, and sometimes I don’t mind taking that kind of chance. Perhaps I just need to vent a bit by blowing up some aliens or lighting a few people on fire. Another gripe I have with this is that some games don’t make the option apparent if it is available at all during a cut scene. Please make them optional. I beg you. One game I played recently that either I couldn’t skip or couldn’t figure out how to skip was Metroid Prime 3: Corruption. It’s now collecting dust in my cd case.

Bad artificial intelligence

This one is probably hated by most gamers, and we’ve all seen it. The AI runs enemy monsters or units into a wall, they can’t figure out how to path correctly to follow you, or perhaps the designer of the game just didn’t test the AI in the way that you think it should work. Well, it pretty much sucks when this happens. Rarely though is it a reason to stop playing a game, but when the AI is good it’s easy to tell, and in some cases it’s actually frightening.

Hard to use menus

This is a killer when you’re trying to get things done fast. One might think that this kind of behavior is a no brainer and should be somewhat of an industry standard by now, but sometimes game designers absolutely fail at the 2D portions of the UI. One example I love is simple and definitely proven are any of Valve’s game menus. They are somewhat of a convention in Valve’s games and they present easy options first for beginner users while also allowing more experienced users to easily whip through menu choices. Crappy menus and other UI options are very easy to spot. One of the worse things you can do is slow down a user as they’re going through the menus. Warcraft 3 does this with the stupid chain menu system, which I’ve grown to loathe. Sometimes games can fail completely in both usability and readability, the biggest example of this I can think of is Dead Rising. I couldn’t even read the menus since the text was horrible and it was laid out poorly. Ugh.

Collect-a-thons

When I was 10, I used be able to stand running around various platformer worlds gathering every last bit that games could offer me. Hell, I even got 101% in Donkey Kong 64, but I wasn’t hardcore enough to get all the stars in Super Mario 64 or all of the golden skulltulas in Ocarina of Time. Now however, I absolutely can’t stand it. Games can get by without them just fine, but for some reason developers continue to inject these endless quests. World of Warcraft could even be considered one giant collect-a-thon. I guess that this mentality appeals to some gamers, but I’m over it. And yes, I did beat Super Mario Galaxy, just with the minimum amount of stars.

Voice chat

Ah, the bane and boon of online gaming. I’ve become somewhat jaded to this miracle of modern technology, and now I’m absolutely sick of it. If I’m playing an FPS, I’m there to snipe someone’s head off or lay a trap to waste them with, and not to listen how their day went or who in pop culture is ridiculously hot and said nerd doesn’t have a chance with. I don’t want to hear about how someone is cheating, hacking, or just being a bag of douche in the game. Get over yourself, and shut up. One of the first things I’ll do with games that have voice chat embedded is turn it off immediately. I’d rather leave voice chat to external programs that can be dedicated to the sole purpose of transmitting voice instead of having to build all of that extra functionality into the game.

What things tick you off about video games? I’m sure there’s irksome moments that occur on a daily basis for any gamer, and here’s your chance to rant about it.

Flash and WPF: A pain in the ass.

2008-03-09T00:00:00-05:00

I could say this about WPF as a whole, but when things actually work with WPF it’s so damn smooth I can’t help but feel somewhat accomplished. Nevertheless, I had a real pain trying to get an embedded flash player into my WPF app. Why Flash? Why not…dare I say, Silverlight? Well, I’m building a small app that plays YouTube videos, so obviously Flash makes sense. First, here’s some lessons I learned while on this wonderfully frustrating journey:

For this instance, the WebBrowser control blows.: My first attempt was to add an embed tag into a WebBrowser control, which is put inside of a WindowsFormsHost control, which is how .NET encapsulates pre-3.0 controls. This did not work in the long run because first of all, IE throws script errors when you try to play YouTube’s .SWF files, and also when resizing the background flashes and looks like utter garbage. Don’t get me wrong, it has its uses. Just not here.
Pre-packaged solutions also suck.: There’s a few flash solutions out there that I tried, either got working and had to pay ridiculous amounts for (oh look, $1000 off this month!), or plainly didn’t work at all. Just don’t use them.
Google is your only hope.: Basically any problem I’d come across I’d have to google immediately, and answers were sparse. The solution I finally ended up with was embedded ActiveX objects, which I also had a lot of trouble with, hence this blog post.

So, here’s an overview of what I did, and how you can get it working. A small note, I’m targeting .NET 3.0.

Reference Interop.ShockwaveFlashObjects and AxInterop.ShockwaveFlashObjects in your project. The latter assembly may only be the necessary one, but back in the 2.0 world the forms designer added both. These DLLs will be included in the download project, but you can usually find them in the COM tab of the Add Reference dialog.
For whatever UserControl or Window you want to show this on, set up a WindowsFormsHost object as well as a AxShockwaveFlash object. (Make sure to include a using AxShockwaveFlashObjects; as well)
In the Loaded event for your UserControl/Window, NOT the constructor, set up these objects and set the Child property of the WindowsFormsHost to the AxShockwaveFlash object you made. If you don’t do it in this order, or do this in the constructor, ActiveX gets quite angry at you.
Make sure to add the WindowsFormsHost to the UserControl/Window…this is one of those gotchas that can save you some time.
Now you can set the Movie property of the flash player, and call Play() and it should work fine. If not, leave a comment and I’ll help you out.

Here’s an example project for you to get started with:

I’m afraid of low level programming.

2007-11-27T00:00:00-05:00

It’s running right now. Beneath those fancy windows. Under the hood. Shifting bits. Moving words in memory. And its scares the crap out of me.

Why? It’s a facet of human nature: what you don’t understand, you’re afraid of. But what can a novice programmer do about it? One of the main reasons I chose software engineering as a major is because I don’t want to have to think about the lowest level of computing power if I didn’t need to. I want to solve problems, help the company I’m at succeed, and enhance my knowledge of the craft.

However, I’m starting to learn that I may need to return to the ‘roots’ of programming. I’m taking a computer graphics course this semester, and it will be the most C/C++ programming that I’ve done in a while. Now grant it, I have had other classes where we did assembly and C, but not the entire course. It just seems to me that in order to really solve a problem efficiently, you should understand some of the underpinnings and inner workings of what you are programming.

So, what’s my solution to this? Well, for now, tinker around with C++ and maybe even poke around the Managed C++ Quake port. Being in the Kingdom of Nouns ruled by Java and .NET is nice though, and it really does let you focus on the problem at hand. Sometimes though, I wonder if escaping from those magical places allows the programmer to really dive into the task at hand and nail it down. I don’t even want to get into some of those esoteric languages that I happen to see way too much about.

One day I’ll get around to reading K & R or CIL Under the Hood, but until then…Are there any other ways to dispel this fear? Let me know what you’ve done to get over it.

Digg Labs: Flash doesn’t suck all the time.

2007-10-31T00:00:00-04:00

Don’t get me wrong. I’m not an expert on Flash. I haven’t even made anything special in flash. Yeah, I can tween a circle and bounce it around the stage, and that’s the extent of my Flash knowledge. One thing I do know about it: if you want to drive traffic from Google searches, you’re better off not using it. Some bloggers even claim its use to be evil. Now I’m sure there’s a lot of Adobe fans are ready and willing to tear me a new one by now with arguments about how Flex and AIR will change the face of the interweb, but it’s my opinion and always will be that your website’s MAIN content should NEVER be in Flash. Let’s look at the letters you type into that address bar of your browser at least once every day: HTTP. Hyper. Text. Not animations, or effects, but text. Until that protocol changes I doubt Flash will ever be used as a serious web design platform.

Once again, don’t get me wrong. Flash has its uses. In fact, it’s completely changed how we use the web. Newgrounds and YouTube immediately spring to mind, as they spawned entire communities and one could say even industries. Flash even has practical uses within sites, such as SWFUpload or various visualization tools that are used even inside of Google’s own pages.

The real magic of Flash is combining its content together with publicly available APIs and doing what Flash does best, even better than Java in some respects: being platform independent. Digg Labs is a perfect example of this, and their contests are a testament to the real future of Flash and its real use on the internet. Digg Labs is the perfect mash-up: content generated by users and displayed in a (semi) useful, interactive, and fun way. Now, you can even get them to be your screensaver on Windows or OSX. I tried for a long while to turn some of the Digg Labs .swf files into screensavers before, but it’s quite a nightmare without the right tools, and all the right data from the Digg servers.

What’s so special about Digg Labs creations is that unlike other visualizations of just raw data, be it traffic to your website or your network speed shown to you on a speedometer, you can actually interact with it. You can see the user who just dugg that story, and you can go check it out for yourself. Yes, it may be flooded with an overwhelming amount of Ron Paul stories at the moment, but at least it’s not the HD-DVD encryption key, or even worse.

Other websites out there really need to look into Flash for this purpose. This is a unique and fun way to engage your community while providing an actual useful way to access your site’s data. Be it Reddit, which I would literally love to see an exact clone of Digg Labs for (or even both together in one app…Blasphemy!), or Facebook, or any Web 2.0 site, they could really use some Flash visualization/interaction apps that can run on your desktop via a screensaver, Flash executable, or AIR. Imagine pictures from your friends on Facebook showing up in real time on your desktop or Del.icio.us links pouring in under a certain tag in a nice animated fashion. All of the buzz about Google’s Open Social and bringing out more APIs into the public for use makes this the perfect environment for more Flash goodness like Digg Labs to happen.

So yeah, Flash doesn’t suck all the time. Its niche on the internet continues to expand, but some part of me hopes I’ll never have to learn more than how to move that red circle around the stage.

Why every programmer should play NetHack

2007-10-29T00:00:00-04:00

I have a place in my heart for an obscure text based game called NetHack. This game is an archetype roguelike game, and I’ve been playing it for over a year now. Not a year in actual game time (yes, I used to play WoW, a lot), but I’ve been into NetHack seriously for the past 6 months or so, and it still kicks my ass. However, I’ve managed to ascend (beat the game) twice, and I can even play it on my Motorola Q.

How has such a game captured my attention for so long and directly apply towards my career as a software developer? Let me enlighten you as to why I think you should play it, and why it still matters so much.

NetHack is HARD.

No, this isn’t really a reason to play the game. However, it is a testament to how NOT to make your software. The amount of frustration I’ve had to go through in order to ascend has been utterly ridiculous. Hell, when I first started playing the game, I didn’t even know there was an ending. I just played because I like to explore. A classic idiom in web development is “Don’t Make Me Think!” I had to do completely the opposite in order to get anywhere in NetHack. One has to remember what monsters do, not to put on that piece of armor because it might be cursed, not to drink from that fountain because snakes might pour out and kill me, and so on and so forth. Well, perhaps under the thousands of lines of C that compose NetHack, someone didn’t think about that, but I for damn well sure am not going to make sure whoever uses my program won’t have to think twice about performing actions.

After 20+ years of development, it still has a vibrant community of users.

This really should be the goal of any community online going forward, be it you’re creating a forum for users of your software to request features, or you’re making a wiki-based community, or any of the above. Where will your community be in 20 years? Will it have vibrant fan-made sites? Will it have a fleshed out wiki? How about a newsgroup? Or will it fizzle and be forgotten? The lesson here is that in order to make your community bloom you need to first plant the seeds. Dig in a bit and you’ll find that behind this game of ASCII characters and telnet terminals there lies a deep and invested group of users passionate about the game and willing to help others how to play. If it wasn’t for the community and the “spoilers” it offers, I’d probably still be wandering around the Dungeons of Doom aimlessly.

“The DevTeam thinks of everything.”

This is a classic motto of NetHack’s development team within the community. The level of complexity of the game is ridiculous. Allow me to elaborate on one specific monster, the cockatrice. This monster is one of the most feared in the game because it can turn you to stone. Ah, but here’s the rub: once slain, you can wield its corpse and stone foes. And this is where the DevTeam starts thinking. You picked it up with no gloves on? You turn to stone. Oops, you tripped down some stairs because you were carrying too much? Stoned. Hit the wrong key and now you’re eating it? Bam, stoned. The list goes on, and on and on. However, the point is clear: the people behind NetHack have really thought of every possible case, every possible scenario in the game, and there’s a consequence or action for it.

I tend to strive for this goal now when I’m coding. I’d be proud if my program was so robust, so tested, and so mature that it could be said that I thought of everything. And even then, that’s still a long shot, perhaps even impossible. In the short term, I find myself trying to think of every possible case that I can while I’m programming, and I hope someday I’ll be known to be able to really “think of everything.”

Not convinced yet? Check out these old articles from GameSpy about NetHack. And if you’ve played NetHack (and/or if you’re a coder), leave a comment and let me know what you think about how NetHack relates to your other 9 to 5 job. And for those of you concerned, there are several GUI versions of the game in the case that you’d rather look at pretty pictures instead of characters.