Geek Mama

The Voices That Matter ruby conference is a single track conference emphasizing short 30 minute presentations that give you a taste of a variety of topics.  These are my notes:

Josh Susser woke us up this morning with his talk Ruby: Fragile or Agile?  He spoke about the evolution of programming languages in particular a great deal about SmallTalk – “the best of the best”, “superior to everything that superseded it”.  Smalltalk’s greatest strength is also it’s weakness.  The language carries it’s house on its back.  It needs its own environment to run in but this causes portability issues.  Then along came C++ and sucked up all the oxygen.  C++ gave the existing C programmers and tools OO advantages.  You could ship apps you built in C++ to your customers and it gave developers just enough productivity over C that developers were not encouraged to shift paradigms.  History is entertaining but what can we take away?  Ruby needs to be careful not to be blindsided like SmallTalk.  How is Ruby positioned, where does it fit?  Folks have referred to Rails as the ruby killer app, what’s coming next?  The greatest thing about rails is the test directory, its easy to test in rails. There is a culture of agile development that comes along with the ruby community.  Building ruby’s momentum around that is the way to go.  There’s a trade off between concise, elegant code and readable, maintainable code.  There needs to be tests for every “interesting” bit of our program.  The pitfalls of ruby development is that it makes it difficult to do static analyses and refactoring.  Because of the dynamic structure of ruby and the code is more compact and DRY, perhaps analysis and refactoring is easier and perhaps unnecessary.  The problem is that refactoring happens in our brains and you have to understand what’s going on in your program.

James Golick spoke about RESTful Possibilities – REST in Rails and Beyond.  The rails community has been outspoken about REST.  As a result, a lot of people are starting to see REST as something that is only interesting as a Ruby/Rails thing.  We’d all benefit from a web which where all technologies provided restful services (unless it’s java).  In SOAP or CORBA, you can just write your regular old code and make a remote procedure call and you are protected from the complexity of it all.  But they all suffer from fatal flaws in today’s era of computing.  In order to create interoperability between java, Ruby C++, Python, etc. the complexities of the underlying technology stacks are huge.  In trying to insulate the developer from the complexities of distributed programming, these stacks create more problems than they solve.  These stacks tend to hide things you need to know from you.  Remote procedure call – FAIL.  HTTP is representational state transfer (REST).  In REST anything that can be named is a resource.  Standardization is good.  Any rails developer who has worked with rails is going to have familiarity with the restful pattern.  By exposing XML, JSON to your controller you get a cheap, clean, easy api which makes it easy to create more powerful tools.  REST apps are pleasant to integrate with.

I was really interested in hearing the data talk from Matt Bauer on Using Berkeley DB and Ruby with Large Data Sets.  They had the problem of having lots and lots of data to capture and crunch.  Much like the situation we’re in with our URL Clearinghouse.   Berkeley DB is able to handle thousands of concurrent threads and processes.  It scales to a huge database (256TB).  It also supports ACID transactions, fine grain locking, XA, etc.  Berkeley DB is embedded, runs in the same address space, written in C with many bindings, data access is very fast because its all right there.  There’s no SQL or schema and it doesn’t operate on keys or data.   It comes in two data store flavors: concurrent and transactional.   A lot of the speed comes from the fact that they don’t need to go over the wire. Berkeley DB is not easy to handle and you can hit the wall really hard.  Please read the documentation!  Well worth reading.  It’s difficult because there are so many different options.  Everything is very customizable.  There are two versions of the Ruby & Bdb bindings.  The first version was written for a much older version of ruby. It’s more ruby-esque but skip this one.  The next version is an exact match of the C implementation and is very stable.  I really wish this talk involved MySQL… Berkley DB sounds interesting but the non-relational aspects make it seem like there’s a bit of overhead before I can use it.  Twitter seems to be able to handle large volume using MySQL and I would guess most people are in the MySQL camp.  I’m a fan of SQL and entity relationships, so perhaps Berkely DB is not for me.  He mentioned ActiveWharehouse for more traditional databases, and this might be worth looking into.

Michael Hartl spoke about contributing to GitHub via his talk Case Study: Building the Insoshi Social Network.  Insoshi is an open source social networking platform.  By design it is a standard social network.  Another project on GitHub is the RoR project.  If you want to add extra features in rails, you can got to github and make a fork of rails and then clone your fork.  You can work on your own little fork of rails and you can also pull from the main rails project as updates appear.  This forking process is how you contribute to a project.  If you find something you want to change or bug you wanna fix, you can do that via a github account.  You first have to create a github acount and then you navigate to the project you want to work on.  When you click on the fork button you get “hardcore forking action”.  You get your own fork of the project.  You’ll want to clone it and push/pull which gives you a chance to make your own branches off the freshest release.  Once you have the local repositiories you are ready to code.  Commit the changes with git.  When you’re ready to push to the insoshi fork, git.push.  When you go to github, you will see a list of all the commits.  Do a diff to be sure to all worked.  When you’re sure everything looks right, go back to your main page and click the pull_request button and submit it!  The Steps are: 

1. Fork to the repository at GitHub
2. Clone and connect your local repository
3. Write a failing test
4. Get the test to pass
5. Commit your local changes
6. Push your changes to your GitHub fork
7. Make a pull request
8. It may or may not get approved by staff
9. We all profit