Where do you get hosting support?

For quite some time now, I’ve found that the options for good Rails hosting have been significantly lacking.  As a consultant/contractor on a huge range of projects, I’m often asked for advice, guidance, or help in choosing and setting up servers for a client.  Nearly every client or customer wants the same thing:

  1. Stability/reliability
  2. Flexibility/room to grow
  3. Someone to keep things running
  4. Someone to call when they need help

The first two options are met by a lot of providers.  Tier IV datacenters, hardware redundancy, and virtualization are a dime-a-dozen nowadays and building a good Rails stack is just about the same for everyone.

However, the rub is in #3 & #4.  As my colleagues, peers, and I are already work full-time writing new applications, there is precious little time for system administration and support of completed projects and old apps.  Even with extensive automation, a small 1-3 person team can write many more Rails apps than they can support long-term.

Inevitably, the client wants to know “Who is going to keep things going once development is done?” and “Who can I call when things stop working?”.  Set them up on a physical machines, VPSes, EC2, or anything else and the developer is left with little choice but to help keep that server running long-term.  Including late night phone calls when something goes wrong.  And can you honestly say you are regularly doing all the little extra things that need to be done?  General maintenance?  Security patches?  Tuning?

Want an alternative?  AWS Premium support won’t touch your software stack.  Rackspace won’t support Rails.  Slicehost: no managed option at all.  There’s really only one player: just google ‘rails cloud support’.

So my question is: If you can get easy, scalable, on-demand hosting, why can’t you get easy, scalable, on-demand support? My answer to this issue is to launch a service that lets developers keep developing while someone else takes care of the system administration long-term:  RoundHouse Support.  Please read my public release announcement and then come check us out!

Announcing RoundHouse – Managed support for your host

I’m very happy today to announce a new community service available for Rails shops: RoundHouse – Server Management and Support.

RoundHouse is a cooperative solution for getting managed servers and system administration for your Rails stack, no matter what host you use.  We’re gathering a pool of specialists that you can call upon to get the help you need.  Whether that’s emergency support when you’re having server problems, regular day-to-day duties, or assistance in configuring a particularly difficult piece of software.

This is a service that provides freelancers, development shops, and companies alike an opportunity to focus on their product instead of on their hosting.  For developers this means freeing up more time to code.  For those running a website it means reliable service from a great group of experts.  For everyone it means having someone available whenever you need it.

Obviously this is a new offering and system administration (much like your hosting provider) must be utterly reliable.  So we’re beginning to establish a base set of clients to try out our service for free.  This gives us the chance to get established, continue to develop a solid organizational structure, and to expand our brand.  For our customers, it means you’re going to excellent sysadmin support at no charge while you learn about all the great things we can offer (and then hopefully recommend us to all your friends!).  So if you’ve been needing help setting up or running your Rails app, please contact us to get started.

We’re also looking to add additional members to our team as we continue to grow.  If you have expertise in system administration, elements of the Rails stack, or are just a great DevOp, please e-mail us at jobs@roundhousesupport.com and we can talk more!

Finally, please feel free to read my expanded rationale for how this service fits into the Rails ecosystem.

Better Usability through Reality

Has anyone ever filled out an age verification form accurately?  I’m well over the minimum age for anything these days, but I pick whatever year my wild mouse-clicking finger hits on when asked for my birthdate.  If they pre-filled the month and year, all the better.  This is a very common design pattern:

How course we all know that no child, no matter the age, would accurately fill out this form just to be denied access.  So I would like to propose a new paradigm for this type of situation:

Age verification the right way

I dare you to find a more effective mechanism (legalities notwithstanding) that doesn’t negatively impact the 73% of the population that is old enough.

Scheduling with Tungle

Tungle.me is a great new service that’s making some big waves.  It is a scheduling application that integrates with your calendar (I’m using it very successfully with Google calendar).  It allows you to invite a group of people to schedule a mutually agreeable time for a meeting or appointment (while automatically handling timezones), so no more emails back and forth about “When are you available? I’m available…”.  It also allows you to mark times that you are ‘generally available’ and people can just visit your Tungle page and schedule a meeting with you (which can be a little weird, but kinda cool).  My page is: http://tungle.me/drewblas .

They’ve started a contest, and I love me a free t-shirt, so here’s my answers:

  1. What made you decide to start Tungling? My friend Chris had the link in his e-mail signature and I was hooked.
  2. What’s one thing we do better than any other productivity app out there?  I’d like to see a ‘buffer’ option to avoid getting things scheduled too close together.  An Android app would be awesome.  And more options/transparency for choosing a time when you have a lot of people invited.
  3. What’s one thing we could do to create a better experience for you? Keep up with lots of new features.  The invite “wizard” gets in my way too much.
  4. Do you refer Tungle.me to others?  If yes, why? Yes, the link is going in my sig soon.
  5. What would you Google to find an app like Tungle.me?  Easy meeting scheduler

Finally, their support is awesome.  I got a custom email from the founders after signing up and very quick responses to my questions.  I hope they keep the personalized service going!

My new love: Codebase-HQ

I have discovered a great new project management service called Codebasehq.com, which merges Github and Lighthouse with a pleasant and seamless integration.  It answers a lot of my wishes for the features that are needed when dealing with a “whole-project” lifecycle.  I’ll talk about the basic features and subareas of the site, but first I want to highlight what truly makes Codebase a game-changer:

Project management

When you create a project in Codebase, you are given access to a number of critical features that disjointed services like Github and Lighthouse just can’t offer.  To start with, the unified user management is terrific.  If needed, you can get into some very decent ACLs to custom each user’s interaction.  If that’s not important to you, then the standard user setup is fine and the ACLs won’t get in your way.  Each project can also have several repositories, which is great for for when you have separate repos for Rails, design files, data files, etc.  Having your wiki, repos, tickets, and more aggregated into a single unified structure is awesome and really transforms how everyone understands the state of a project.

The individual featuresets that go into creating such great project management are:

Git hosting

Git hosting on Codebase is nearly identical to Github.  And that’s a very good thing.  Repo browsing, navigation, etc is pretty much the same (if not better) and you get the important extras like deploy keys and whatnot.  You can also set a repo to constantly sync/mirror another.  It is missing some of the more flashy Github features, like the forking integration and network/commit graphs, but overall is quite polished and very capable.


Ticketing is similar to Lighthouse in its simplicity.  In some areas its a little less feature rich:  email integration is not so great right now (should get better) and you can’t customize your statuses for tickets.  In other areas it’s vastly superior, especially in the general gestalt of the interface which is much easier to use and navigate.  It is still missing the one feature that I wish all ticketing systems had: a public support interface where non-users can submit and track tickets.  But since no one else offers it either, I can’t complain much. (Tender is getting close, but they’re taking their sweet time and so far I’m not a fan).


Pretty much the same as any other milestone system.  It has one KILLER feature though: milestone/branch integration.  If you start off a git branch for your milestone, you can tie them together so you can track commits specific to that milestone. It’s incredible and stands as a great example to what can be done with true integration.


Github offers a wiki, but it’s a pain to edit and I generally don’t bother with it.  Especially because for an ‘enterprise’ project, many of the people who need to read the project’s wiki don’t even have github access (or even know what github is).  Codebase’s wiki is more traditional in its setup and works great.

Time tracking

A very nice addition that is important on many many projects.  You might not always need it, but if you do, you’ll love it.  It is simple, straightforward, and works well.  I’d like to see it integrate even more closely with tickets, but otherwise a small to medium sized team will have little to complain about.


Although both are very similar and center around git repositories, Codebase and Github do not fill the same role.  For your open-source projects, Ruby gems, and such: stick with Github.  The forking/networking features and wide community acceptance make for an unbeatable setup.  But when it’s time to get a whole dev team together on a project, Codebase definitely has the upper hand.  They have a great set of features (and are coming out with more all the time) and the overall integration and polish makes it a joy to work with.  Their pricing is also incredibly good (even if it is in Euros), so please check them out.

Big changes in Rails coming

I prefer posting brand new content and usually avoid “re-propagating” news, even in the Rails space. However, the major happenings of the last two weeks in the Rails community have prompted me to speak up. It all started with some rather unpleasant video exchanges between Rails-ists and Merb-ists about their differing theories in framework development. Out of that came a big discussion about where Rails and Merb were headed and before anyone knew it, The Merge was announced.

At first I was amazed.  I’ve always loved having both Rails AND Merb.  I felt that having two different philosophies side-by-side allowed the community to try out new ideas in a very small and agile way (in Merb), and the ones that were really good surely found their way to Rails shortly after.  Let’s face it, Rails is growing up fast and doesn’t have the luxury of breaking backward compatibility like it used to and it’s no longer able to explore the “what-ifs” like before.  But we still had that ability in Merb.  So at first I was a bit concerned.  But I still think this is a great new direction to take.  And even with the reduced flexibility, I’m really excited to have all this awesome brainpower concentrated in one place.  I can’t wait to see (and use) the end result.

Today an addendum was added to this new revolution.  It’s been announced that there will be a Rails Activist group.  The Rails Activists will champion Rails (and of course Merb) across the universe.  They will act as a voice for the community both to the Rails Core team and to the world-at-large.  There’s a UserVoice site, a Google group, and more for helping the community express their opinions.  This is a truly awesome idea and I’m even more excited to see what these guys can do for Rails.

Odd Rubyism

Today I found a little counterintuitive oddity in Ruby.  Take the following code example:

a = [0,1,2,3,4,5,6,7,8,9,10]

h = {0=>0, 1=>1, 2=>2, 3=>3, 4=>4, 5=>5,
     6=>6, 7=>7, 8=>8, 9=>9, 10=>10}

puts "Iterating & deleting array"
a.each do |i|

  puts "On #{i}"
  if i % 3 == 0

    puts "Deleting #{i}"


puts "Iterating & deleting hash"
h.each do |k,v|

  puts "On #{v}"
  if v % 3 == 0

    puts "Deleting #{v}"


With the output:

Iterating & deleting array
On 0
Deleting 0
On 2
On 3
Deleting 3
On 5
On 6
Deleting 6
On 8
On 9
Deleting 9
Iterating & deleting hash
On 5
On 0
Deleting 0
On 6
Deleting 6
On 1
On 7
On 2
On 8
On 3
Deleting 3
On 9
Deleting 9
On 4
On 10

Notice how each time the array deletes an item, it happens to skip and never evaluate the next item? Ruby internally uses an index counter (like if you were manually iterating the array with a for loop). When an item is deleted everything shifts back one.

With the Hash (it’s a little hard to see because they’re out of order) no items get skipped.

I’m not saying this is a bug or is necessarily wrong, but a Hash and an Array are very similar data structures (especially insofar as they are both enumerable) and I’m surprised that they work differently. I also spent a LONG time and a LOT of debugging to figure out that this was the error (it was buried deep in some XHR Rails calls, so reproducing it took a lot of time)

I’d love to hear from anyone who can attest to what happens in other language iterators (Java, Python, etc)!

Presenting gem_cloner

Besides being a Ruby/Rails/Merb developer, I’m also a part-time sysadmin for a number of previous clients.  Usually I’m responsible for maintaining Rails stacks, either for apps that I’ve written or just for another developer that doesn’t have as much Linux experience.

Lately, I’ve had to do a move of a number of Rails installations to completely new/clean servers.  I’ve got lots of scripts for doing initial setups of the stack as they need to be.  But one thing that comes up is that, especially with older apps, the gem dependencies can be very finicky.  Installing the latest versions will almost certainly break something.  Plus some times the system can have quite an extensive list.

Yes, I know that the gems should be packaged with the app, but there are a lot of reasons that it doesn’t always happen or doesn’t always work.  To that end, I’ve found the most effective method is just to re-install the exact same set of gems on the new box as the old one.  To automate this process, I present: gem_cloner.

gem_cloner is a very tiny but useful script that will take the text output of `gem list`from one machine and execute the `gem install` command on the new machine.  Usage is very simple:

  1. On the old machine, run `gem list > gems.txt`
  2. Copy gems.txt to the new machine.
  3. Copy the gem_cloner.rb file to the same place
  4. With sudo or as root, run `ruby gem_cloner.rb`

The script will read that file and install the exact same gem versions.  You’ll definitely want to browse and tweak the script.  Possibly by adding ‘sudo‘ in the command call or adding ‘–no-rdoc –no-ri‘ (I personally use a gemrc to eliminate the doc files on production systems).

Fork, patch, & praise ad nauseum on github and drop me a line if you like it.

RubyConf Summary Day 2

Ah, another day of RubyConf has passed.  Here’s a brief overview of the talks I attended and my thoughts on them.  The theme for today was definitely Threading and Concurrency.  And the conclusion in many (if not all) of the cases was:  Ruby sucks at it, how can we make it better?  I hope that Matz, et al takes these issues to heart and prioritizes some improvements in this area.  Native threads are a start, but the GIL kills us.  We need more!

Aristotle and the Art of Software Development – Jonathan Dahl

What a way to start the morning!  Jonathan gave an overview of several great philosophers and how to apply their ideals to programming.  He likened Perl, Java, and PHP to the school of Utilitarianism, where the ends justify the (very) nasty means of getting there.  His basic theme throughout the presentation was that hard rules (from any school of thought) must be tempered with common sense.  He gave the example of DRY versus clean & understandable code in ‘database.yml’.  While the clean version has a lot of redundancy in the settings, DRYing it makes it impossible to read.  Overall, a great way to start the morning.

Ruby Arduino Development – Greg Borenstein

I caught a Ruby electronics talk last year that was pretty cool, and got an even better one this year!  Greg presented a number of cool arduino projects, including drumming with servos, a temperature reader using a big red arrow on a servo, and a drink mixer that could make screwdrivers using windshield washer pumps!  It was a terrific overview of RAD and I can’t wait to buy an Arduino when I get home.

Better Ruby through Functional Programming – Dean Wampler

Dean did a nice talk about using functional paradigms in Ruby.  He gave examples of makign sure your functions don’t modify state, pattern matching, using functions as first class objects, etc.  He gave a good comparison that showed that DSLs are very similar to functional languages because they are very declarative instead of imperative.  What I think he missed is that, under the hood, DSLs are very state-heavy in order to implement that declarative model.  It was great to delve into these ideas, but I was left feeling that if you go through the trouble of following functional programming in Ruby, you don’t really get any benefits.  Ruby isn’t optimized for concurrency like Erlang or Haskel and your code will really just be more difficult to trace.  Maybe I’m missing something, but I didn’t see the benefits (except making it easier to switch to a functional language).

What Every Rubyist Should Known About Threads – Jim Weirich

When I see Jim’s name on a talk, it is guaranteed I will attend.  I don’t care about the subject.  Jim is an amazing speaker with always interesting topics.  He gave a fairly basic overview of concurrency and why we need it (the failure of Moore’s law).  For Java programmers and the ilk, this would be concurrency 101, but probably had some new information for a lot of Ruby developers.  He provided some great code-heavy examples of race conditions and deadlock and how to work around them.  He also hammered home his message of ‘Concurrency is HARD’, but it must be done.  However, I felt there was a kind of elephant in the room with the fact that concurrency in Ruby is rather fruitless, thanks to green threads, GIL, etc.  Jim did, however, give some great examples of ways to make it easier:  Erlang & Clojure.

Using Metrics to Take a Hard Look at Your Code – Jake Scruggs

Jake gave a terrific presentation on how use metrics appropriately to help improve and maintain your code.  He talked about code coverage, testing, Flog, Saikuro, and more.  Jake also had a great example of applying these tools to target improvements with a real-life example of refactoring a Dameau-Levenshtein distance function.  He also had great example of how inject has a tendency to muddy your code significantly, increase complexity, and decrease understandability, a sentiment I whole heartedly agree with.  Best of all, Jake introduced Metric-Fu: http://github.com/jscruggs/metric_fu .  Metric-Fu combines, code coverage, flog, saikuro, and more into an easy to use interface that integrates with CC.rb.  Looks awesome and I’ll be trying it out soon!

Components are not a Dirty Word – Mike Pence & Nick Sutterer

One of the few Rails talks at the conference (as it should be).  Mike introduced us briefly to ‘Cells’, a new type of Component more similar to what Merb has now.  The Nick came up to demo Apotomo, a plugin that provides wholey-contained stateful widgets.  These widgets are persistant and handle updating their own appearance.  They also have event triggers, observers, and caching.  I will definitely be giving Apotomo a try, at least to play with, although it may not be ready for production use yet.

Ruby Kata and Sparring – Micah Martin

Micah talked about his experiences with martial arts and how it can be applied to programming.  His message was “To be a master, you must use disciplined practice outside of work”.  This is the purpose of Kata, or Forms.  He gave many reasons for a similar approach in development: peer feedback, definite goals, performance, etc.  He even performed a Kata of developing Langton’s Ant right on stage.  The best part was his introduction of a new tournament: battleship.  All Ruby developers are invited to participate by building a battleship AI.  The tourney info is available at: http://sparring.rubyforge.org/battleship/ .   Awesome indeed, you can be sure I’ll participate.

Ruby Heavy-Lifting: Lazy load it, Event it, Defer it, and then Optimize it – Ilya Grigorik

Ilya gave a great talk on how to break down a task into something where you can use multiple processes.  This is the good stuff.  Forget threads and concurrency problems.  If you truly isolate the tasks (share-nothing? hello?), you begin to produce a system that can massively scale very easily.  He demonstrated using his real-world example of scaling AideRSS.com.  They split off the different tasks: network-bound, IO-bound, CPU-bound.  The different processes communicate with message and job queues (he mentioned starling, beanstalked, and SQS) and they used EventMachine to prevent blocking-IO.  In the end, they could load each EC2 instance with basically one task of each: saturating network, IO, and CPU simultaneously to get the best bang for the dollar.  Overall, the talk was great, but I may be biased since I feel it basically validated all my experience and convictions about the RIGHT way to scale.

Keynote – Dave Thomas

To round out the evening was Dave with a literally breathtaking talk.  He gave an example of Ruby’s biggest problem (at least I think so): slow development.  Ruby had 48 months between 1.6 and 1.8 and it’s already been 52 months waiting for 1.9.  (I guess Matz has really taken to heart his goal of being ‘enterprisey’)  This causes INCREDIBLE problems for migrating to a new version, not to mention learning or using the new features.  It also leads to slower adoption, wheich means less usage of the new version, which makes even LONGER releases.  Dave’s solution is to Fork Ruby.  He proposed four forks, all VERY good ideas.

RubyLite – A version of Ruby where we strip out a lot of the unnessessary stuff.  Dave projects Ruby’s codebase to be 100MB when 2.0 is finally release (in 2011!).  Pulling out a ton of unneeded syntax, libraries, and redundant methods could significantly improve size and performance.  I’m all in!!

Parallel Ruby – Dave proposes a ruby that will automatically parallelize certain operations.  A new operator: //= would perform something similiar to:  a,b=b,a using passed procs simultaneously.  Basically distributed map automatically.  Awesome idea.  Have no clue where to begin with this one though.

Typed Ruby – Ruby with typing.  Charles Nutter has been workign on something very very similar to this with Duby.  Cool idea, but I love duck-typing too much.

Closure-based Ruby – Dave offers a new syntax for hashes that will free up braces (not a bad idea, if there’s an =>, you already know it’s a hash, the braces aren’t really needed, just like with implicit arrays right now).  The braces can be used to element all the Lambda, proc, Proc.new, block madness.  Make ONE first-class proc object, that can be passed and used all over the place.  A GREAT idea!!!  I think he took it a little far when he suggests making class and method definitions using it.  The code at the very end looked like Lisp with braces all over the place, you couldn’t tell what was what.  But otherwise, I whole-heartedly support a simplified proc system in Ruby.

Dave closed by saying that he hopes that he inspired us to go out and impliment these ideas, or any others we may come up with.  Try out new things and maybe they’ll get merged into MRI.  I sure hope RubyLite and the closure system Dave proposed eventually get taken into MRI.  I may even take a crack at implementing them myself!

RubyConf Day 1

During RailsConf this spring, I provided thrice daily (or more) posts on the talks and events.  While they were very popular, I didn’t really get to enjoy the conference much.  This time, I’m limiting myself to shorter notes once per day.  Here is a brief recap of Thursday, Day 1 at RubyConf.

The theme for RubyConfat RubyConf so far is DSLs.  While DSLs are always a promenant topic, so far every talk has included a pretty extensive coverage of them (or how they are used in a project).  This isn’t at all a bad thing, as I believe DSLs are very powerful, produce clean code, and are of great benefit to Rubyists.  That said, I don’t get to write many of them, so I’m a bit rusty and looking forward to beefing up my skills at Neal Ford’s ‘Advanced DSLs’ tomorrow.

Matz’s Keynote
Matz was his usual comedic self.  The talk was quite good and very sentimental.  As he notes, he doesn’t like a lot of technical content in his keynote.  Instead, this was more about how great the community is and he provided a lot of encouragement to keep that up, no matter how much we grow.  He asked for raised hands on “Who started with Ruby because of Rails”.  I’d say about 30% of the room raised their hands.  Then he asked about “Who stuck around because of Ruby” and it was clear that Ruby is why everyone stays.
A oft repeated quote from the keynote:  “Rubinius, yea – Good try”

Scaling Ruby (Without Rails) by Gregg Pollack
Gregg (of RailsEnvy) did a nice talk about what you should keep an eye on when developing in Ruby and trying to maintain decent speed.  He noted that Design Patterns in Ruby has many great examples, but they are necessarily slow.  Matter of fact, in general, making method calls are much slower than the alternatives.  I think this was great to hear as it reinforces my coding style of avoiding things like ‘.nil?’ or ‘.zero?’ that are expounded by other Rubyists.  I believe the more traditional routes are just as understandable without being so expensive.

Gregg also talked about threading (also a popular topic at RubyConf this year), Neverblock, Mongrel vs. Evented Mongrel, Deferred requests, Rind, DBSlayer, Halcyon, and Ruby-prof.  Overall, not bad, but a little light on content, examples and details.

Using Git in Ruby Applications – Scott Chacon
Scott gave a nice talk that included a brief overview of git itself followed by explaining some unusual things that git could be used for, including a ticketing system, wiki backend, and more.  His major goal was to introduce Grit, a Ruby library that allows you to interact with a git repo through Ruby.  It was pretty neat, but also quite complicated, even for git veterans.  There were quite a few code examples, but I didn’t really see any ‘start-to-finish here is how you do this’, and I think it was just a bit too much for the talk.  Overall though, it looks like a nice library and I hope to try it out more later (possibly for some interesting Rails/Capistrano tasks)

Recovering from Enterprise – Jamis Buck
I actually debated whether to attend this talk or go to another because it looked to be a bit beginner.  Boy, am I glad I stayed.  Jamis gave a terrific talk about his experiences writing and re-writing dependency injection libraries Copland & Needle.  After a nice, fairly technical walkthrough, we get to the meat of the conclusion:  Ruby-style dependency injection doesn’t require a dependency injection library at all:  Pass the class name or overwrite a helper method and go!  He left us all with some great quotes and nuggets of knowledge:

“I was riding the Dependency Injection horse for all it was worth”
“If you were turning every ten lines into a component, then you just wind up with component soup.  And I hope you’re hungry”
“Just in time.  Not just-in-case”

Unfactoring From Patterns: Job Security Through Code Obscurity – Rein Henrichs

Rein gave a pretty funny talk that went through the procedure for turning good code into bad.  It was funny with a lot of audience suggestions.  I attended hoping for some ‘glimmer of divine knowledge’ from the advertised ‘1% of truth’ to be presented, but there was none.  It was just a good time laughing at poor coding practices.

Peer Aware Desktop Application Development – Preston Lee
Preston presented on a library called ‘Journeta’ that provides a server-less broadcast-based peer-to-peer discovery and communication platform for clients on a LAN.  It’s a pretty fun and interesting topic, although I can’t think of any application of it right now.  Once again, the subject of the inadequecy of Ruby’s green threads came to the forefront.  It provides a severe bottleneck for the kind of asynchronous communication that Journeta does.  As we know (and was pointed out by Gregg earlier), the Global Interpreter Lock in Ruby 1.9 means that we still don’t have an appropriate solution.  I pray that a real solution comes to light soon because Ruby is severely suffering because of it.

Preston noted that Journeta didn’t work for Windows (mostly because he hadn’t tried).  I took that as a bit of a challenge and hacked on it during his talk.  After delving into some interesting internals of the Windows UDP Socket handling, Multicast, etc, I managed to get Journeta working on my Windows machine.  A fun chellenge for sure.  This is definitely what RubyConf is about.

Testing Herasies – Francis Hwang
Another talk I was considering missing, but I’m glad I didn’t.  I would say Francis gave probably the best talk of day.  It was chock full of technical content, examples, and a rather controversial topic: the right way to test.  Francis started with an overview of Mocks, Stubs, Dummies, Fakes, etc.  Then he started in with a great list of testing ‘dogma’ that people are told is the ‘One-Right-Way’.  He provided some excellent examples for why these bits of dogma aren’t necessarily true.  For example, he argued very effectively against Mocks (and the general ideal of seperating your testing from side-effects of external applications).  I hope he posts his slides for later reference, and if I find them, I will be sure to add a link here.

To end out the day, I attended the evening’s lightning talks.  There were a lot, but I’ll note a few:

Ryan Davis (ZenSpider) – Provided an overview of his new gem: Flay.  It’s a tool to find duplicate code, even if the code uses different variable names.
Yossef Mendel – Talked about what is and is not true (Truthiness) in Ruby.  A good reminder that only ‘false’ and ‘nil’ are evaluate to false in Ruby.  Everything else is true.  Yossef provides a funny little tool to see the truthiness of something (but hopefully after his talk, you don’t need it): http://github.com/ymendel/truthy
Bruce Williams was quite popular at RubyConf today as he was selected on Monday by the Obama campaign to attend the acceptance speak in IL as ‘Front Row to History’.  Bruce built a neat site prior to leaving (in one day) that provided updates on his tweets and snaptweets: http://obamaftw.org/ Way to go Bruce, I’m jealous!