By Ron Evans (@deadprogram) of deadprogrammersociety.com

It was a beautiful sunny day here in Los Angeles, and I had spring already in my step, because I was headed to LARubyConf 2010. It was almost time for the main event, and there was lots of good stuff in store. The proceedings began with some brief introductions from the hardest working man in technology conference video, Coby Randquist (@kobier), then on with the show.

Oh S***: How to bring a big Rails website down (and how not to)
Tim Morgan (@riscfuture)

Tim’s presentation was named “Oh S***: How to bring a big Rails website down (and how not to)”. It was an excellent collection of real-world experiences from Tim’s work at Scribd with database problems, and their eventual solutions.

Scribd handles a lot of documents. Really, they do. In fact, they have over 50,000 new docs uploaded every day. With a site this big, it is easy to break it, and that does happen. Most problems stem from the way Ruby on Rails handles the database interactions, which can become troublesome in a number of cases. Having caused unintentional havoc, Tim was schooled by his ‘masterful DBA’ on some key rules of thumb for keeping out of trouble.

Database Rules of Thumb

1. If you add something database related to your models, make sure you look at the actual SQL that is generated when using it.
2. When you look at the generated SQL and do not understand it, use EXPLAIN
3. If what EXPLAIN reports is not clear, ask someone

There were several excellent examples presented for working with Ruby on Rails and MySQL. This included both correcting issues as well as performance optimization techniques. If you are using PostgreSQL or some other data store, then many of these specific techniques may not directly apply, but it was still an excellent exercise going thru them in detail.

Alternative Data Structures in Ruby
Tyler McMullen (@tbmcmullen)

Next up was Tyler McMullen, also from Scribd, to talk about some different ways to represent your data besides just putting it into a database-like structure. By choosing a more appropriate data representation and algorithms, you can use well known techniques to solve some problems that are very performance intensive far better than just using databases.

The four structures discussed were Bloom Filters, BK Trees, Splay Trees, and Trie. As one friend commented to me afterwards, it was like a high-compression braindump at lightning-talk speed. For audience members who were not versed in the power of algorithms, or even those who were, Tyler hit some great points by not only showing how each worked, but also illustrating a real world example for each of when it could be used.

Use a bloom filter for problems like quickly handle requests for non-existing on a file server. A BK-tree is useful when you need to find best match, like spelling correction. Splay trees are great for improving performance for caches and garbage collectors. And a Trie is useful for problem like auto-completion. In fact, Tyler showed a cool example of auto-completion implemented in Rack in 20 lines of Ruby code.

Want to see code? Check out http://github.com/tyler for some ruby extensions with these structures and algorithms.

Teaching Ruby To Kids
Sarah Mei (@sarahmei)

Now we got to hear from Sarah Mei, a developer at Pivotal Labs and an expert on teaching programming to kids. As Sarah put it very amusingly, “most programming instruction = fail”. And this, despite the fact that programming is becoming part of basic literacy.

She challenged the audience to get involved with teaching kids to program. After all, Ruby is the programming language for extroverts, and teaching is not “Rocket Science”. We all already have the tools and techniques we need to get started. She then proceeded to give a bunch of specific pointers, largely based around the same principles as Agile development.

Some great tools to teach programming to kids are Shoes, Hackety Hack, and the upcoming Small Ruby which is Sarah’s own implementation of Logo in Ruby. Other tools of interest are Alice, and Kodu.

You need to find a balance between theory and practice. A child’s aptitude for math may = computer science, but aptitude at language = programming. The youngest age to teach programming is probably middle school. Pairing the kids together works well, seems to be better than pairing a teacher/student. What is the best way to get more girls programming? Starting at an earlier age.

Sarah gave a very entertaining and important talk. Each of us has a part to play in the education of the next generation of programmers, so let’s get to work!

Everything You Ever Wanted To Ask About Threads And Fibers But Were Afraid To Ask
Joe Damato (@joedamato) & Aman Gupta (@tmm1)

For those who were confused by the double take, Joe and Aman decided to pair present in each other’s scheduled talks. This was a pretty cool way to handle the massive amount of information that they have on Ruby performance and internals.

So, what is a thread? It is just a set of execution state, with instruction and stack pointers to allow for suspending and resuming the thread as needed. There are three kinds of threads: green threads, native threads, and hybrid threads.

Ruby 1.8 users green threads, but apparently does it wrong. On the other hand, Ruby 1.9 uses native threads. Erlang uses hybrid threads.

They also talked about 3 very powerful tools for performance profiling: strace (dtrace on OSX), google pref-tools, and ltrace. Using these tools, they have identified some major performance improvements in Ruby 1.8, and have these available at http://github.com/ice799 and http://github.com/tmm1/ruby187

One reason these patches are not part of Ruby’s MRI is that they are only for Ruby 1.8 and are also x86 specific.

Joe and Aman delivered when it came down to a very detailed discussion of how Ruby handles threads, as well. But their afternoon talk would be even more hardcore.

New Relic With The Best Sponsored Message Ever – Really!
Paul McCready (@kingofslugs) from New Relic gave the coolest and most fun sponsored demo I have ever seen. He showed some awesome pictures of human-powered flight (Go, Gossamer Albatross!) and in an incredibly entertaining way tied it into his brief pitch as to the benefits of New Relic’s application profiling service. Furthermore, he really knew what he was talking about. Good job, Paul! Someone give that man a raise.

After a long lunch filled with fun conversations between all the amazing Rubyists assembled, it was time for the second half.

Civic Hacking
LuigiMontanez (@LuigiMontanez)

Luigi Montanez works at the Sunlight Foundation, a non-profit organization dedicated to government transparency via open source software and APIs. They have done some really excellent things, and have started getting more developers in the community involved. Of course, they need you to get involved, which was the immediate gauntlet throw by Luigi in his talk.

So what is civic hacking? It is when the government releases data, and citizens then develop peaceful application using that public data.

He discussed the Obama iPhone app, which was a key tool in organizing people during the run-up to the last presidential election. Interestingly, the app was not created by Obama’s campaign. Instead, it was built entirely by volunteers, and was only show to the Obama staff after it has been created and was about to be released. This is a excellent example of civic hacking in action.

The concept is simply this: Open Source + Open Data = Better Government. Right now, Federal, State, and local government has not done a very good job of publishing data online, let alone providing APIs with which to access this data.

Apps For America was a contest sponsored by the Sunlight Foundation, and was very effective as getting many developers to create cool and use applications that mashup or present government data in a useful way. Fillibusted, and This We Know are just a few of the great things created by open source civic hackers as part of Apps For America, and they are planning Apps For America 2 right now.

Luigi also discussed the Aaron Swartz incident. Aaron Swartz, of Reddit fame, brought the attention of the Man on himself, when he helped out to make publicly availble information about U.S. federal court cases actually public, from a system called PACER. He was vindicated, but it points out even more strongly the need for making public data accessible to the public. Now there is a Firefox plugin called RECAP that grabs data from PACER and uploads to archive for free access, helps bypass the paywall, and makes new data available.

There are many ways to get started civic hacking. The main thing is to get involved. Because today in the internet age, we do not need large bureaucracy to support our engagement with government. Power to the people, right on!

Garbage Collection and the Ruby Heap
Aman Gupta (@tmm1) & Joe Damato (@joedamato)

The second part of Aman & Joe’s detailed retrospective of the internals of Ruby, covered two things you would know nothing about if you had never programmed in any other language than Ruby. Lucky for all Ruby programmers, all aspects of memory management are hidden from view.

After a detailed description of stacks vs. heaps, and descriptions of how Ruby handles the many internal references, they discussed Ruby memory leaks. Since you do not handle memory directly in Ruby, they are not classic memory leaks. Instead, they are reference leaks. If an object has any objects that contains a reference to it, it can never be freed. Examples are assignment of an object to instance variable, or adding an object to a hash or array.

One very interesting technique they mentioned was loading profile data into MongoDB so you can do queries on it using memprof, a new profiling tool that Aman & Joe have created. Memprof actually outputs JSON, which is MongoDB’s data storage format, which is what makes this so very easy to do.

Joe and Aman are amazingly knowledgeable about the hardcore internals of Ruby performance, and have posted their slides online, so if you want to get down and dirty with Ruby’s memory management implementation, I highly recommend checking it out. They are also getting ready to offer their memprof as a web-based service (http://memprof.com) to make the process of analyzing the massive quantities of data easier.

A New Look at Software Development: What will the next 10 years bring?
Dave Astels (@dastels)

Dave Astels is a true software genius, having been instrumental in creation of the canonical Ruby testing framework RSpec. Now working with Ruby thinktank and hosting gurus Engine Yard, he has been thinking about a few interesting ideas regarding the next generation of software development. Or, as he put it quite humorously “the alternate title for this talk is ‘Programming: You’re Doing It Completely Wrong’”

What Dave was talking about, was that the difficulty in creating software is only getting worse. Software is more complex, bigger, more distributed, parallel, and even more life critical. We cannot continue building software over the next 10 years in the same way that we have for the last 50 years.

That’s right, 50 years. The theoretical basis for all the languages that we use today were mostly determined in the 1950′s. Actually, Smalltalk (’71) is one of the conceptual new kids on the block. Think you are modern with your functional languages like Erlang? Sorry, based on ML (’73).

As far as programming tools, Dave cannot understand why we are still using file system based tools like Emacs and Vim. Not that he likes any current IDE’s better. But clearly there are other ways to work with code, other than editing text files on disk.

We need languages and tools that have parallelism & distributed processing baked in and that actively prevent bugs. The programming idioms that have become second nature to us as everyday tools don’t work.

Dave wants to see intelligent tools, that are more cooperative with the user, and do more for the developer. Perhaps even written using Rubinius. AHe says we need a new way of programming, that incorporates parallel strategies, problem decomposition, data structure design, and algorithmic organization.

It was a very thought provoking talk, and I am hoping that some of the concepts take root and grow.

Mobile Ruby
Sarah Allen (@ultrasaurus)

Sarah Allen is CTO of software consultancy Blazing Cloud, where she has been doing mobile development, and is the creator of the “Ruby Conf 1.0″ app on the iTunes app store. That app was written using the Rhodes mobile framework, which was the main topic of Sarah’s talk.

“Writing mobile apps are like getting tattoos. some people like the pain, but most people just want the effect”, Sarah told the amused audience. “And Brand Transcends Platform,” she explained as she was juggling 3 handsets for the live portion of her demo. As the only presenter to show actual running code, I salute her!

Content is what really matters when developing a mobile app. Not so much the specifics of UI experience. It is key to remember that “Mobile != Pocket Desktop.” Also the promise of “Write Once, Run Anywhere” does not really exist for mobile development, but at least we can achieve “Run Anywhere.”

The rest of her presentation consisted of looking through the source code for the Ruby Conf 1.0 app. Since Rhodes is loosely based on Ruby on Rails, and the code you write is Ruby, most Rails developers will be able to recognize a lot of similarities. There are important differences, however. One interesting thing about Rhodes, is that there is actually a very small Ruby VM running on the mobile device when you compile your app togther. Apparently the most recent version also supports the popular Net:HTTP lib, so it is possible to create some pretty interesting applications that talk to remote services without using the RhoSync server to do so.

There have been a number of apps approved on the iTunes app store that were developed using Rhodes, including the Wikipedia mobile app. Rhodes is definitely worth taking a look, if you a Rubyist who wants to get into mobile development without learning Objective-C.

The Big Rewrite – Doing It Right
Rich Kilmer (@rich_kilmer)

The conference keynote was given by RubyCentral founder and longtime Rubyist (10 years!) Rich Kilmer. Rich runs a consultancy called InfoEther, and a few months back his colleague Chad Fowler (@chadfowler), also a RubyCentral founder and member of InfoEther, wrote a blog post against the so-called “Big Rewrite”. Rich’s entire presentation was effectively a rebuttal against Chad’s post. Did I mention that Bob Martin (@unclebobmartin) was a speaker at RailsConf 2007, and the topic of his talk was speaking vehemently against the “Big Rewrite”? Oh, we Rubyists are a wild and crazy bunch!

Rich’s presentation was quite excellent. His really knows not only Ruby, but has a fantastic grasp of how to build scalable, loosely coupled systems, based on a lot of real-world experience. So his plan for success is based on an actual big rewrite being done for a client by his consultancy, which is actually underway at the time of his presentation. And this is no mere incremental change, this is a total bottom to top rewrite.

Actually doing the “Big Rewrite” consists of understanding the drivers for the rewrite, preparing for the rewrite, executing the rewrite, then flipping.

The drivers, or reasons for doing the rewrite, are that it must be business driven, it must NOT be technology driven, you don’t call it a rewrite, and you must complete it in a major business cycle.

When preparing for the rewrite, you must drop a major release just before the rewrite, you must understand your problem domain, and you must break down the current system into logical sets of functionality.

Executing the rewrite requires implementing pieces as REST services, using central authentication, and implementing shared behaviors and using them. Furthermore,
you must automate system administration tasks (Puppet or Chef), use a standard worker framework (minion or resque), and dedicate resources to repeatable data migrations. Lastly, keep service code consistent & models clean, and make sure to use the right tool for the right job.

When ready to actually do the flip, you need to perform incremental migrations of historic data, prepare business users for possible disruption, and do practice runs of the flip scenario several times. Finally, enable “read only” of the old system during final client flip, do the flip, and provide a way to fall back if flip fails.

A few final points: use polyglot programming to handle needs with best language for certain tasks. if you need 20 lines of Lua or Perl, no big deal. Do it. You may need to add functionality to the existing system if the flip fails, or if you need to add functions during the big rewrite itself. And if two things should be named the same, but have different behavior, you probably actually have two different systems. You can do a big rewrite, but you need to stay within business cycle.

Wrap Up
It was a rewarding day of serious Ruby awesome here in Los Angeles. When it comes to enthusiasm, and vibrancy of the Los Angeles Ruby community, we are really coming into our own. That is certainly one reason that we had so many cool out of town presenters and attendees. Thank you to all of the presenters, attendees, and organizers who helped make LARubyConf a great conference. See you next year!

This guest blog post was written by Ron Evans (@deadprogram) from The Hybrid Group, a team of Los Angeles Ruby on Rails software developers. Ron is a contributor to several open source projects, occasional author and speaker, and iconoclast. Check out his blog Dead Programmer Society for many more posts about Ruby.