 Thank you for that lovely introduction. So today, after a brief introduction, a little more about myself and about this project I did last year, I will share three reasons why I felt that I could not recommend Ruby for the project that I was doing. Nonetheless, I still believe that Ruby, the Ruby language, was well suited to these types of challenges. So I'm also going to tell you about three observations that I will hope, I hope will spark some ideas in the community or at least some conversation. So first off, I love Ruby. I learned Ruby on Rails six years ago, working on Mightyverse. Through changing features and database models and multiple versions of Rails, Ruby's flexibility and resilience has served me well. As Sarah said, I co-founded Rails Bridge and later Bridge Foundry with Sarah May and many, many others. I've taught Ruby to a few hundred, maybe even a thousand people. Ruby was the first language where I learned to practice test-first development. First I learned that after learning that it was great for testing, I learned that it was really a design methodology and then I applied it to teaching, publishing open source curriculum at test-first.org. Now I work for 18F, working to transform the U.S. government from the inside out. I started working for the government in June 2013 as a presidential innovation fellow. A couple of years ago I might have told you that I thought government innovation was an oxymoron. But I felt if I didn't try to help, then I couldn't complain. I applied for this fellowship which matches industry experts with government innovators on national priority initiatives. Last year was a huge year for open data. In May, President Obama signed an executive order making all government data, data paid for by our tax dollars, by default open. And 14 of us of the 43 presidential innovation fellows were focused on open data. My work was at the Smithsonian Institution. When I arrived, I had no idea how vast the Smithsonian is. There are 19 museums, 15 archives, 23 libraries, and nine research centers all over the world. The Smithsonian in its collections has over 137 million specimens, artworks, and other treasures, and over 136,000 cubic feet of archival material. So these are giant dinosaur bones, birds and drawers, dried plant specimens and cabinets and things in jars, cultural icons. Political campaign history going all the way back to George Washington. There's giant airplanes and paintings and sculptures and lots and lots of paper. Our challenge was to turn pictures of things into data, leveraging the power of the crowd, what they called digital volunteers. When we arrived, they had just built this application. The idea was it's just a simple website that puts a picture of a document, usually written in a very hard to read cursive. In front of anybody who wants to join in, and there's an open text field, and you type what you see, and then that creates a machine readable message that you can search on and future researchers or the public can more easily read than deciphering cursive. Our challenge was to apply that framework to the creation of new digital records for natural history specimens. At the Museum of Natural History is our U.S. herbarium. So this is five million dried plant specimens, each pressed on acid-free paper, and these have been collected since the 1800s. 3.7 million of these specimens have no digital record at all. This is actually the record. It's a label on the piece of paper, and these things are in this vast climate-controlled room. So the idea was, well, let's take this application and let's add a simple web form, and so that the volunteer is typing in structured data that goes into the database with a little peer-review process, and then we have data that we can expect, we can learn about which species were in different places without going through this massive, massive research project, which is so challenging that it almost never happens. So this application, I arrived, it had been created in the last month or so in PHP, in the Drupal content management system, and I must admit that I thought perhaps I was a little more enlightened than my new government colleagues. I thought I could sort of analyze what was going on and inform them that there were better alternatives. So why did I think that Ruby was better? I've spoken to this a little bit, but I feel that Ruby's flexibility is fabulous for an early application. We just started this project. It's going to go on for years, and it's going to have to evolve. That flexibility, combined with our awesome test frameworks, means that we can build these robust applications where the implementation and the behavior change over time so that we have software that evolves, and I had experience with this and I was excited at that opportunity to explain this to my new colleagues. Well, as you know from the title of this talk, I found that I wasn't able to quite frame this the way that I had hoped. So why not, Ruby? First of all, at the core of this application was a content management system. So this is really common. Your application starts and you just have a lot of pages of text and information about your project, content management system, offers, drafts, publishing, all these nuances that take a while to code, but are really straightforward and well understood. If we look across the web, the top one million sites, just a little over half of them are in WordPress. That's like the most popular CMS in the world. Drupal is that little green wedge, and that's quite popular, too. But we have CMSs in Rubyland. So if we look at the Ruby CMSs, I thought I'd just start out by looking at popularity. If we just look at the downloads of the Ruby CMSs and add up all the popular ones from Ruby Toolbox, you'll see that the active installs of Drupal are significantly higher than all of the Ruby CMSs that have ever been downloaded. So in reality, it looks like this, where there's this vast amount of Drupal and this tiny little bit of Ruby out there in the world. But popularity isn't everything, old tools, although I don't think Drupal is actually younger than some of the Ruby CMSs, but that's neither here nor there. Popularity shouldn't drive our decisions. If we look through the actual frameworks, and one of my very first Rails projects when I started my consultancy Blazing Cloud some time ago was a radiant site. So I had some experience with Ruby CMSs, and I kind of kept an eye on this, and I found that the Ruby community always has an awesome CMS. In almost every year, it's a different one. So I was a little reluctant to go down this route to represent to, I'm here from the White House and I've got these fancy titles, and I was like, okay, we have to look a little more further than just swapping out tool sets. So number two is related to number one, but I think it's a different point, which is about a high level of components. So a mature CMS like Drupal, like WordPress, offers a component ecosystem. So these are different components that you can just install, sometimes with just a UI, and it gets downloaded from the web, and you turn it on and off, and with permissions, and it's just really easy to just snap in there. And this covers not only just blogs and comments and things, but social sharing and third party widgets and features that do all sorts of lovely things. This guy says that we can build a blog in five minutes, and I'm sure most of us could do that. But if you look at modern blogging systems, they're not just posts, has many comments. They have archives, categories, calendar widgets, spam controls. I think it's worth looking at how these content management systems create this environment that allows these kinds of components to thrive. So these components are typically broken down into one bit, which is some UI that would show up for the end user going to your website or using your web applications. Sometimes it's just visual, sometimes it's interactivity. Usually it can be skinned, sometimes it offers a few different themes. Then there's a different UI that's the admin interface that you can use as a developer, but it's typically used by non-developers to just tweak a couple of parameters. And then there's, of course, some code that you install into your system. So the third reason that I was reluctant and in fact did not recommend moving to Ruby is that the biggest challenge for this project and in fact for many projects when they start out, it's not actually code. We were solving the interoperability of different systems, both computer and IT systems and people systems. And there was very little code that needed to be written. So if I couldn't put forth, well, this is just going to change your world to be adopting this new language, well, you know, heck, I can write PHP. In fact, one of the components I ended up prototyping in Ruby and I spent several weeks iterating on it, you know, probably all told a few days of writing code but over a period of time and then, you know, I spent four hours and I rewrote in PHP. So, you know, language isn't everything. So what did I learn from this? What are my takeaways? Something that is, you know, obvious but I think interesting to reflect on is that framework choice leads to language choice. I learned Ruby because I was doing Rails and later grew to love Ruby. People will make these choices about a content management system based on the features that they need when they're starting their project. And a lot of people will say, well, you know, just stand up a WordPress instance next to your Rails app or, like, so what, you know, let's figure out the requirements and then sort it out later. And this is what happens. At the beginning of your project, you have, like, mostly sort of CMS types of things, you know, and if you follow, like, the whole lean startup thing, you know, you'll start with, like, a landing page that isn't even an app. It's on, like, one of these services, right? So there's all these ways that you can validate that you're headed in the right direction with very little code, right? It's messaging, it's framing, it's, you know, understanding your business. And then as time goes on and the thing that's frustrating about this process is you just have to add a little, a little more code until suddenly you have this massive code that kind of overwhelms your content management system and maybe you need a different technology choice. So you end up three months or three years later with a big rewrite and then you have majority code, tiny bit of CMS features. So I think this is unappetizing. I'd like to start in a situation where I've made some technology choices that are going to let me grow my application, change the features over time in the way that I know Ruby does well. But I don't want to give up that quick start. And frankly, I don't want to have to rewrite all of these things that there are fairly good mundane solutions for. The second thing is that frameworks are patterns of how we work. They set down the rules that we live by. And for the most part, those choices give us tremendous acceleration. Now I love Ruby and I like Rails. I think when I'm living in a Rails world, I'm happy to just go forth and go by certain rules that I find maybe a little distasteful. Maybe I wouldn't have implemented it that way, but who cares? Because what I'm doing is innovating on top of that. And it was interesting. I was honored to be invited to talk on the Ruby rogues earlier this year and I talked about this question because I was kind of frustrated with what I felt were the lack of choices that I had last year. And I was talking about the different CMS options we had in the Ruby community and Abdi Grimm pointed out that all of those top CMSs are actually Rails CMSs. And maybe the problem isn't Ruby, but some of the constraints or perceived constraints that we have in Rails. That perhaps this developed test deploy cycle, which is so valuable when you're doing something new and innovative and scary in order to make sure that your code is awesome. Maybe that cycle doesn't fit when you're adding in something that's effectively a solved problem. Like if I want to swap out my calendar widget or pick a new rich text editor, like really must I do that? Can't I just tell my colleague who is creating all the content here, pick one of these three text editors you like? I don't care. But we don't have those options in a Rails app. We have a conversation, we get their needs, we build in these things. And I'm spending a few hours doing something that is wrote, something that is straightforward. So for a while I thought that this was one of the problems. And then I learned about this project that 18F actually did before I joined this group. And I think that it introduces a different model that I think is interesting. It doesn't solve the problem, but it's an idea. There's a new government website that was released, I think, in April called NotAlone.gov. So this addresses a very important issue of campus sexual assault. So there was a government task force, it was a 90-day task force led by the vice president in looking into how is it that we have so many assaults on campus and so many of these women and other young people who get assaulted feel like they have no recourse, feel like they don't have services. And they found that, in fact, there's an enormous number of services, but because of history and the way that things were set up, some of them are college obligations, some of them are state obligations, they're really in lots of different places. And it's really hard to navigate that system. So they came up with this, like, two months into this three-month task force, they came up with this idea that maybe we just need to have a central place where people can go and discover these services. And so they came to 18F and a couple of the presidential innovation fellows signed up and they thought it was a really important issue, so worth the challenge of creating a website from concept to completion in 27 days. So technically standing up a website, they say that in government standing up a website, in 27 days is not a big deal in the private sector. In the government, launching a new website after you've finished all the code typically takes three to six months. So that in itself was a challenge. Also with this particular set of information, even in the private sector, this would be hard to execute on in 27 days. You ought to be careful that the information is correct, there's legal implications to what you say, there's all sorts of review process that has to go into just purely writing the words. So this team got together and they used some components that they had already validated and gotten approvals to deploy. So this is mostly a content site. It has some code, it pulls in other websites and has an elastic search backend that's served over some services. What they did was they creatively thought, well, if we just keep all of the text in simple markdown files and some structural stuff in YAML, we can teach our non-technical collaborators to just edit those text files. We use GitHub pages and then they can do previews, all themselves, and then the developers deploy it to the final site. And so GitHub serves as the admin of this CMS and as a staging site. And under the hood, we have a Ruby CMS that I never thought of as a CMS, which is Jekyll. So I think that that's an interesting model that's worth some exploration. So my third observation is that the ecosystem of components is as important as the language itself. When you think about the component ecosystem of Ruby, our habits are our tool set is that we have these separate pieces that are assembled by a developer. And it's kind of like if I say I want a table, I might go to the store and pick out all these tables, but if I'm living in the Ruby community, this is what I get. So to just make this concrete, like maybe this is Omnioth, right? So in the back end, I've got some table legs and then I add in some bootstrap, right? Like so I can assemble my table top and then I need a Facebook button to connect and I have to go find that myself. Who's done this? Few of you? No. So in summary, what we do not automate, we are doomed to repeat. When you choose a language and a framework, you choose your superpowers. And each of us can also choose to build tools that shape our world. We can invent new superpowers for ourselves and for the next generation of makers. I think we can look across the world and see how other people are solving problems, but they're not completely solved. There are drawbacks to the current offerings, to Drupal, to WordPress, that maybe we could leapfrog and solve in a different way. And maybe it's not a monolithic CMS. Maybe there are other options. So I hope this conversation, or I hope this talk will become a conversation. And I'll leave you with the question about what will you make happen? Thank you.