00:00:02.560
I have the honor to announce that Terence Lee will deliver the keynote. He is not only a contributor and advocate for the Ruby community but has also helped organize great events, which I appreciate greatly. So, please give him a warm welcome! We are very happy that he's here today.
00:00:30.300
Moin Moin! I think that's what I'm supposed to say, right? And I believe I'm wearing the towel properly; I was taught the proper etiquette by Yann before getting on stage so I could partake in this too. I feel like I am the least cool keynote because I'm the only one, so you're kind of stuck with what I'm going to tell you. I'm Terence; I go by hone_02 on Twitter, and I'm mostly known in the Ruby community for wearing a blue hat all the time. That's how people generally identify me in crowds. I come all the way from Austin, Texas, but luckily I was already in Europe, so I'm not super jet-lagged this weekend. We’re known in the US for having really amazing tacos as well as barbecue. If you're ever in Austin, please hit me up; I'd be happy to take you out for tacos.
00:01:23.079
I work at a platform services company called Heroku that is great for deploying Ruby apps as well as many other things. Enough about my intro. I approached the organizers last year to come talk this year at Ruby Unconf. I don't know where Aaron is; I haven't seen him this whole time, but I had dinner with some of the organizers last night. Learning that Aaron was the keynote from last year made me even more nervous about giving this keynote. Those are pretty big shoes to fill! However, during the dinner, I learned that he sang a song in German, and finding out late last night that I wouldn't have time to prepare any German singing made me feel a bit better since no one actually knew the song he sang.
00:01:54.280
So this was kind of the announcement I received earlier this month, and there was not a lot of notice ahead of time. The only response to my tweet was about how I give really good technical talks and, of course, Ruby karaoke. Even on my name badge, I think they just wrote a hashtag for Ruby karaoke. Unfortunately, this is not going to be a hardcore technical talk. I believe those types of talks tend not to be very good for kicking off conferences, at least for me personally. I want to do something a little different. So, I'm curious, how many people in the room have been part of the Ruby community for like 10 years and were here before Bundler was a thing?
00:03:13.450
It looks like about 10% to 20%, which is pretty good. I want to tell a story, and it is a bit personal because it's about my journey through open-source development and other related experiences. While preparing for this talk, I learned that Bundler is about a decade old, which makes me feel a bit older in this community. To kick it off, I started my first full-time programming job in the spring of 2009 for a small startup in Austin called Other Inbox. You know when you start your first job, you get a computer that you need to set up? We weren't even using version control that was starting to become popular at the time, as GitHub was not around yet.
00:03:48.990
I remember checking out the source code using Subversion. We were on the latest Rails 2.3 release, and this was how you managed dependencies in the dark days of Rails 2. Instead of the Gemfile, you had these config.gem lines where you listed the gems you needed to install. When you cloned it, you would then run rake gems:install, and it would go through that list, attempting to install the necessary gems into your system. However, there were always a few gems that just didn’t work right. Even after running this command, you still couldn’t get the Rails app to run. Cucumber was always one of those gems. It never worked properly with this process, so you had to manually install it. Of course, if you just ran this command, it’d give you a list, but pre-1.0 versions of Cucumber were not backwards-compatible. You had to know the exact version that they were running on their machine.
00:06:30.490
Some gems came with binaries that you had to run manually. After going through enough of these, you’d finally get a working system. Some of the things that Rails incorporated included gems unpacking, which allowed you to go through that list and unpack all the gems into a vendor folder that you could check into your repository. Then, anyone who cloned it could have the exact same versions of those gems. Of course, you could only do this for pure Ruby gems, as it didn’t handle native extensions. This made it a long process since it took an entire working day to get a functioning environment. I think it’s a stark contrast to how most people start today on their computers with Bundler. We take a lot for granted about how hard it used to be. It took a whole eight hours just to get the tests running on my first day of work, and hopefully, there was a README that described everything I had to set up.
00:07:16.510
The second thing I wanted to talk about was gem activation errors from that time. Fast forward a bit: I was working for the same company, which had a consulting arm. I moved our app off of AWS onto Heroku, and that exposed me to all sorts of new concepts. I learned to install dependencies on the Oracle Bamboo stack, which some of you might remember. There was this gems manifest file, essentially a .gems file in your repository, where you listed the version constraints and the names of the gems. It would go through and install gems in order, one by one, which sounds simple enough. However, on March 23rd, 2010, Rails 2.3.6 came out and this release became infamous for several reasons. One of the changes was the upgrade of the dependency of Rack from 1.0.1 to 1.1.0.
00:08:51.790
If you have experienced gem activation errors, you can predict what happened next. After this release, you would get an error message that would lead you to believe that setting a constant to install a specific Rails version would fix your problem, but it didn’t. This was due to how RubyGems handles activations. RubyGems allows multiple versions of gems to be installed on a system and, by default, references the latest versions first. Depending on the order your gems activate, a dependency might activate an incompatible version of Rack, causing your application to break. Sometimes, you would have to manually analyze the dependency graph to identify which gems needed to be installed to correctly resolve the errors.
00:10:04.580
If we rewind back to that pivotal local Austin Ruby conference, it was the first time I met Colin and Yehuda, who gave a lightning talk about a new project called Bundler. I had never heard of this project before. At that time, Rails was quite monolithic, and Merb was a modular framework with several dependencies. In 2008, they announced that the next version of Merb would actually be joined with Rails, transitioning to a more modular framework and an extensible API. The creation of Bundler was meant to manage these dependencies effectively, ultimately leading to a more flexible and better Ruby application.
00:10:35.200
Bundler was first introduced in version 0.8, which introduced the concept of the Gemfile and did things quite differently than RubyGems. It would look at all the dependencies and resolve them in memory before executing anything. This was a significant departure from how RubyGems managed dependencies. In the 0.9 release cycle, the Gemfile.lock feature was introduced, a pivotal development. But, the user experience during this phase was less than ideal; you often had to lock files before installing them, which added friction to the process. The release of Bundler 1.0 streamlined this experience by removing unnecessary commands and making the usage of Bundler more intuitive for developers.
00:12:41.639
Despite being a bumpy ride, by the time Bundler's 1.0 version was released, it had changed the landscape of dependency management in Ruby. However, this success did not come easily. There were many releases in a short span, and unfortunately, many of these releases were not backwards compatible. Many developers felt jaded by this experience. The introduction of the lock file was a revolutionary concept. Many didn't see the need for a lock file, prompting questions and skepticism about its purpose.
00:13:42.280
In October 2010, I remember doing some work for a project that needed Bundler 1.0 working on our platform. I became a committer to the project around this time. This was my first real involvement with an open-source project, which was both exciting and daunting. My first contribution was to help with a release, and I pretty quickly learned how the project evolved. Bundler became a success story over the years, gradually transforming how Ruby manages dependencies and helping developers feel secure in their setups.
00:16:32.630
Looking back, Bundler has become a crucial part of the Ruby ecosystem, eventually being included as a standard library in Ruby 2.6. This highlighted its integration and importance in Ruby development. Every version of Ruby now ships with Bundler, showing the progress we’ve made. What is remarkable is how the Bundler story reflects not just enhancements in coding practices but the spirit of the Ruby community. The success of Bundler has inspired many projects across numerous ecosystems, helping others understand and embrace dependency management.
00:17:44.040
The story is not unique to Bundler. Many have emerged out of the Ruby community, like Sass, which addressed existing challenges in working with CSS in Ruby applications. While Sass may not be maintained in Ruby anymore, it has transcended its origins to become widely used in other programming languages. The Ruby community consistently pushes boundaries and refuses to settle for the status quo, encouraging innovation and the development of solutions that inspire others. The rich history of Ruby demonstrates its willingness to embrace new ideas, as seen in various initiatives that advocate for inclusivity and skill development.
00:20:28.350
One notable initiative is the emergence of code schools and boot camps. One of the first, Hungry Academy, aimed to train individuals without technical backgrounds into junior developers within a few months. This approach was not widely accepted initially, yet it proved immensely successful, resulting in a significant number of proficient developers entering the field. Today, many boot camps have evolved beyond teaching Ruby, yet they owe their origins to this community's willingness to innovate and push for change in training practices and educational frameworks.
00:22:15.000
To conclude, I urge everyone here as part of the Ruby community to challenge yourself. Don’t let others impede your ability to achieve your goals. I truly believe we can all contribute to this thriving community, inspiring our friends, family, and the next generation that will ultimately continue this journey. Let your ambitions—rather than your existing skills—guide you. The path may have obstacles, but remember the history we've crafted. Know that you carry a rich legacy, and you too can make an impact. Thank you!