Friday, July 16, 2010

Lone Star Ruby Conf Speaker Interview: Jesse Wolgamott


Today's a twofer for the Lone Star Ruby Conference.  My third interview (second today) is with Jesse Wolgamott (@jwo) who's presenting "Battle of NoSQL stars: Amazon's SDB vs Mongoid vs CouchDB vs RavenDB ".  Jesse shares some thoughts about NoSQL and the conference.



NoSQL looks like it's gaining momentum.  Why should Rubyists be interested in the topic?

Jesse Once you reach the point in transaction system where the database is the scalability cause of your scalability problems, there's no going back. You've taken the red pill. Table-based transaction databases are constrained by memory and there's a hard maximum until your app crawls to a halt. The dream of true replication and easy sharding is built in.

Also: migrations just suck, even in Rails.

There are a lot of NoSQL players, what made you zero in on these four?

Jesse CouchDB was my first experience with NoSQL -- the built-in map-reduce is so unique. MongoDB is a newer kid on the block, and is easier to get running in Rails, so that's a plus. I like to mention Amazon's SDB because it's frequently overlooked; You use Amazon's servers so in that respect it's the easiest to setup. RavenDB is new and shiny. Cassandra is also really cool, but not as ruby/rails friendly.

What's your current involvement in the NoSQL world?

Jesse I've used CouchDB, MongoDB, and SDB in the real world, but I'm just a lowly programmer.

What made you want to present at LSRC this year?

Jesse I got jealous looking at all the ruby conferences across the country, and heard about LSRC through the local Houston ruby group. Austin rules, Ruby rules, so win win win.

Other than your own talk, what are you most looking forward to at LSRC 2010?

Jesse The "Vim for the modern Rubyist" talk -- Vim is so hot right now! (but really, it should be cool and I love the AntiIDE thinking).

Lone Star Ruby Conf Speaker Interview: Nephi Johnson


Okay, time for a second interview with a Lone Star Ruby Conference speaker.  This time, Nephi Johnson (@d0c_s4vage) talks a bit about his presentation — "Less-Dumb Fuzzing and Ruby Metaprogramming".



Fuzzing isn't always well understood.  Can you describe fuzzing, and tell us what situations it's a good fit for?

Nephi Fuzzing is a term used to describe the process of feeding an application unexpected inputs in order to find flaws in the code.  During development, it's pretty much impossible to write code that will handle all possible inputs correctly.  Fuzzing helps to uncover some of the more subtle and unforeseeable flaws that haven't been found through code reviews and normal testing.  Fuzzing is typically very automated and usually involves feeding a program thousands or millions of sets of malformed input.  The program being fuzzed is then monitored for crashes, exceptions, and/or performance.

The last person to really talk about fuzzing in the Ruby Space was Zed Shaw.  That's kind of a tough act to follow.  Why is this an important topic for Rubyists, and why are you the right person to talk about it?

Nephi I think fuzzing is an important topic for every developer (or anyone who wants to find bugs in an application).  If you have the time to fuzz a product, you will almost certainly uncover flaws in it.  One bug fixed during development is one less bug that customers have to experience with a release product.  Not finding flaws in the code after extensive fuzzing is also a big confidence booster.  I think this is especially applicable to Rubyists because of the flexibility (and fun) that comes with using Ruby.  I think anyone could make their own fuzzer/data-generator with Ruby in a short amount of time.  Also, if someone wanted to use the library I've written, it just so happens that I've written it in Ruby [*sarcasm*].

Why am I the right person to talk about fuzzing?  Fuzzing is something that I spend most of my free time doing or working on.  I put a lot of thought into coming up with ways to more efficiently fuzz programs.  As a security researcher, I have different goals in fuzzing than developers.  I want to find the really interesting bugs, bugs that might allow one to run their own code or do something entirely unexpected with the program.  I think my perspective on fuzzing might provide different insights for those who use fuzzing outside of the security field.

What prompted you to speak at LSRC this year?

Nephi Someone had mentioned to me that it might be interesting to hear from somebody in the security field and suggested I submit a talk.  I liked the idea, chose to talk about a project I've been working on using Ruby, and here I am.

Other than your own talk, what are you most looking forward to?

Nephi I'm looking most forward to the talks "Vim for the modern Rubyist", "What every Ruby programmer should know about threads", and "Getting Started With C++ Extensions."  Why these talks?  I love using vim - it was the first text editor I used when I started using Linux and now it's all I use, threads give me trouble sometimes (ruby threads, that is), and I've been wanting to write my own ruby extensions for a while now.

Thursday, July 15, 2010

LSRC Speaker Interview with David Copeland


With the Lone Star Ruby Conference just over a month away, I thought it would be a good idea to talk to some of the presenters.  David Copeland (@davetron5000) is giving a talk about a topic that resonated with me, so I sent off an email to find out more about what he thought would make his presentation and the conference worthwhile.



I've never been a big 'web app' kind of guy, so I was excited to see "Why And How You Should Make Awesome Command Line Apps with Ruby" as a presentation.  Why do you think Ruby works well in this space?

Dave Having used PERL and bash in the past, Ruby is just a FAR more pleasant environment; it's just really easy to make a well-designed system, the code is clearer and easier to write, and there's a lot of great libraries that are easy to install and set up.   My talk doesn't go TOO heavily into this, but I think everything that makes Ruby great for web apps makes it great for command line apps.

As a Sys Admin, CLI stuff is my bread and butter.  Do you see Ruby as a good language for Sys Admins?  Why or why not?

Dave Nothing's going to be "as close to the system" as shell scripts, but Ruby has some great libraries that let you write cross-platform scripts, and that's a good thing.  Ruby also has a culture of terse-but-readable syntax, code-as-configuration and overall UNIXness that I think a sysadmin would find familiar and comforting.  Ruby really embodies the "motivated laziness" that is the hallmark of a good sysadmin (by which I mean automating painful tasks away into something simpler).  Further, there's some great management tools built with Ruby, like chef and capistrano.

What prompted you to present at the Lone Star Ruby Conference this year?

Dave I've spoken at a few conferences and user groups and really liked it, and I liked the idea of a Ruby-focused conference; Java-based conferences always feel a bit behind the bleeding edge to me, and the Ruby world is always pushing the boundaries.  I also thought my talk would be interesting to share, specifically for the reasons you note above; Ruby and Rails go hand in hand, but Ruby is an awesome language all on its own.  Plus, the last time I was in Austin, I was there for one night on a cross-country drive, so I didn't get to see much :)

Besides your own talk, what are you most looking forward to while you're there?

Dave There's a ton of really interesting looking talks scheduled; The ActiveModel/Active Relation talk looks good, as well as the NoSQL stuff and deployment talks.  And, I'm sure Tom Preston-Warner from github will give a good talk!

Ruby|Web Interview

Mike Moore, one of the big movers behind MountainWest RubyConf and the UtahValley.rb is getting the ball moving for another Ruby-centric conference —Ruby|Web. He was kind enough to sit down with me and share his thoughts about Regional Ruby Conferences and how Ruby|Web fits into that space.

SLC already has MWRC, why another Ruby (ok, Ruby+) conference?

Mike Moore  There are so many great regional Ruby conferences that are happening in the west this fall. GoGaRuCo, SunnyConf, mountain.rb are all very close both in distance and time. And then there is Lone Star, Ruby Hoedown, WindyCityRails, Ruby DCamp, and eRubyCon/JRubyConf all this fall as well. All of these are great events and deserve to be attended. So if you are near one of them you owe it to yourself to attend! I guess a broader question might be with so many regional conferences, why another? This is something I've struggling with, because I didn't want to take away from any of the other awesome conferences. But the thing I've realized after doing MountainWest RubyConf/MWRC for the last four years is that the Ruby community is much larger than we think, and there are many, many local folks who just won't ever make it to another conference. And many in the local community has been asking for both a second local conference and more Rails/web content for years now. So I guess a short answer is that there is demand for it. That said, I've really been humbled by some of the interest we've gotten from Rubyists outside of our local area. I really think this is going to be an awesome event and will inspire everyone who attends to become better at what they do.

MWRC has a reputation for being tech heavy, geek friendly, and a great value; but you're changing the location, the timeframe, and the general 'theme' for Ruby|Web. Why play with a good thing? What makes you think you're going to make people happy with a different conference? 

Mike  Every year we've experimented with small tweaks to the format of MWRC, but it has largely remained the same. I love MWRC and I think it does many things really well. I love that it is downtown SLC and you get to walk around and explore the city. We hold it in the SLC Library's auditorium and its a beautiful venue with comfy seats and a nice big screen. And Engine Yard's annual Hackfest has been a great time to learn and hack with some of the brightest Rubyists around. The only real complaints we get each year is the short breaks and lack of space to lounge around and talk to each other. There are lots of couches and tables, but you have to go upstairs to get to them, so its proven to be inconvenient. And I have a hard time saying no to the many wonderful proposals we get each year, so we tend to pack the schedule pretty tight with little break time. I personally prefer to have so much great content that my brain feels tired after the conference, but some want more time and space for interacting with the other attendees. So for Ruby|Web I figured we had an opportunity to try something new and see if we can improve the experience with some more radical changes. The first thing is the venue; Snowbird provides a location where we don't have to walk four blocks to find some food or a comfy couch to hack on. The entire resort is awesome and we get to keep the exploring aspect while acquiring some conveniences like having a lot of room for lounging. Secondly we're planning a relaxed schedule that will allow attendees more time to talk with each other or pair on some code or even ride the tram up the mountain. Basically we want to make it easier to be with each other and learn and hack, since that is kinda the point, right?

What is the biggest impetus behind Ruby|Web? Why should people plan on coming? 

Mike I, like a lot of Rubyists, do web programming for a living. I was a web guy long before I found Ruby or Rails. I think the Ruby community has done a really good job of showing that Ruby is so much more than Rails, and I am fully on board with that. But with this event I wanted to give us permission to focus on the web stack as much as we wanted. So I guess you could think of this as a regional RailsConf, without the risk of getting a cease and desist letter from O'Reilly's lawyers for naming it that. :) But this will be more than just Rails; there is Rack and Sinatra and Sammy and Scripty2 and HTML5 and CSS3 and OAuth2 and so much more. I want to be a better web developer, and I want this Ruby|Web to help me do that.