01:44 - Ruby Best Practice Patterns Project is Cancelled

02:47 - Sarah Allen Introduction

• twitter
• github
• blog
• Bridge Foundry
• RailsBridge
• Presidential Innovation Fellows

04:16 - Sarah Allen: Why no ruby in gov? (Slideshare)

08:25 - Government, Ruby, and Agile Development

14:04 - The Smithsonian Environment, Coding Processes, & CMS

• Drupal
• PHP
• transcription.si.edu
• WordPress
• Joomla!
• Radiant CMS
• The Ruby Toolbox

41:43 - Working with Government

• 18F Digital Services Delivery
• Open Data within Government

56:34 - Day to Day Experience Working at the Smithsonian & Smithsonian History

01:03:17 - Getting Involved

• Presidential Innovation Fellows
• Sarah Allen: Why no ruby in gov? (Slideshare)

Book Club

Object Design: Roles, Responsibilities, and Collaborations by Rebecca Wirfs-Brock and Alan McKean

Next Week

The Debugging Mindset with Danielle Sucher

Transcript

JAMES:  Alright, are we ready? Are we buckled up? JOSH:  Oh, wait. Yes. [Chuckles] JOSH:  I will not fall out of my chair this morning. JAMES:  Good. I would hate to have that happen on the air. JOSH:  Again. JAMES:  Again, right. JOSH:  [Laughs] JAMES:  It had happened before. I’m just saying. It was Josh, just to be clear.[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.] **[This podcast is sponsored by New Relic. To track and optimize your application performance, go to RubyRogues.com/NewRelic.]**[Does your application need to send emails? Did you know that 20% of all email doesn’t even get delivered to the inbox? SendGrid can help you get your message delivered every time. Go to RubyRogues.com/SendGrid, sign up for free and tell them thanks.]**[Bandwidth for this segment is provided by CacheFly, the world’s fastest CDN. Deliver your content fast with CacheFly. Visit CacheFly.com to learn more.] **JAMES:  Hello everyone and welcome to episode 149 of the Ruby Rogues Podcast. I’m James Gray and I’ll be your host since Chuck is out today. With me as always is Avdi Grimm. AVDI:  Good morning, afternoon, something. JAMES:  Josh Susser. JOSH:  Good day from sunny San Francisco. JAMES:  And today, we also have a special guest, Sarah Allen. SARAH:  Hello, also from sunny San Francisco. JOSH:  Hey, neighbor! SARAH:  Hi. JAMES:  Usually, we have multiple people from Utah. Today, it’s multiple people from California, I guess. JOSH:  Yeah, yeah. So hey, thanks for joining us on the show, Sarah. JAMES:  Yes. SARAH:  It’s really great to be here. JAMES:  Absolutely. I’m going to have you introduce yourself in just a second Sarah, because we’ll get into what you do and stuff as we start to talk. Before we do that though, we do have an announcement. We’ve covered this on Parley, but we haven’t mentioned it on the air before. We talked in the past about doing a Ruby Best Practice Patterns Project. And we’ve actually been working on that for a while and trying to get a contract settled with the publisher and things like that. Unfortunately that project has not worked out. And we’ve decided to abandon it, because it was chewing time and resources trying to set it up and we were not finding something that everyone was comfortable with. But that’s okay. We’re doing other projects and interesting things. I just did the first Ruby quiz study group on a Google Hangout. And we recorded that and did all that. We have more experiments coming. So, it’s a little sad that the project’s ending. But we’re redirecting that energy to other places. And we just thought we wanted to let everybody know that. And with the business out of the way, let’s get to the show. Sarah, now tell us who you are. SARAH:  I have been a software developer for a little over 20 years. Before I entered the Ruby community, I was most famous for having developed After Effects, Shockwave, and Flash video. However, in the open source world those technologies aren’t so favored. But it is delightful that we can now do multimedia in the browser. So, we can apply all of this open source goodness to what used to be called multimedia and is now just called application development. About six years ago, I started programming in Ruby and probably most well-known in this community by doing Test-First Teaching and founding RailsBridge, which in the last year we’ve done a refactoring. So, the non-Rails-specific part of RailsBridge is now called Bridge Foundry and has a 501(c)(3) status via a fiscal sponsor School Factory. And so, Bridge Foundry creates bridges that are each unique instances of bridging the technical divide and creating a culture in technology that is open and welcoming to anybody in our population, our wider social population, not just the tech community population. So, I’m pretty excited about that. JOSH:  That sounds like you extracted a gem from Rails Bridge. SARAH:  [Laughs] I think we did. JOSH:  Good job. SARAH:  So, I like the refactoring analogies. And then for the last six months I took a leave of absence from everything I was doing and was a Presidential Innovation Fellow halftime in D.C. JAMES:  And that’s what we had you on to talk about today. You gave a talk recently that Josh made me aware of about Ruby in Government, or the lack thereof. So, maybe Ruby isn’t in government very much. SARAH:  Yeah. I called it, at the talk, why no Ruby in Government. There actually is some Ruby in government. And I mentioned a couple of projects where I’ve seen Ruby used fruitfully. However I wasn’t able to use Ruby. And it wasn’t because they say, “No, no, Sarah. Don’t use Ruby.” But I agreed when I walked into it that I would recommend the best technology for the job. And my biased assumption was that, “Well, that might likely be Ruby.” But I would get my feet on the ground and figure that out. And much to my dismay, I didn’t feel that the problem that I was faced with despite having some technical challenges and requiring some programming, I didn’t feel that Ruby was the right solution. And so, I talked about that at our local Ruby meetup. JAMES:  That makes us all sad. [Chuckles] AVDI:  Does it? [Chuckles] JAMES:  Does it? Yeah, that’s a good question, actually. JOSH:  [Laughs] So, maybe you can dig into that a bit, Sarah. So, why would we assume Ruby would be great for government anyway? JAMES:  Because it’s great for everybody, Josh. JOSH:  Okay. [Chuckles] JOSH:  Ruby does have a lot of things going for it. Why aren’t those things great for the government? JAMES:  That’s a good question. SARAH:  Well, I think one of my assumptions going into it is part of the Presidential Innovation Fellows program is that we’re trying to bring Agile practices into government. As you all know, there are a lot of government projects where we the people pay hundreds of millions of dollars for software that at first blush doesn’t look like it ought to cost that much money. JAMES:  Are we talking about healthcare.gov now or? SARAH:  That is sadly not unique to our government in that everything seems to cost in the multimillion dollars, even small projects. And there are some good reasons for things being expensive, when your initial deployment has to go out to the entire population. There does have to be some degree of let’s make sure we go through some hoops and there’s PII, personally identifiable information, concerns. Having a bit of process around that makes a lot of sense. However, Todd Park, the CTO of the United States, had this inspiration that maybe we could take some of these relatively new practices. And when I say new, I’m saying in the last 10 to 20 years, because government moves slowly and I think, as it should. If we’re going to be enacting laws and policy that affect our whole population and you don’t want to revisit those every six months, you ought to be building things that if the software itself doesn’t last 20 years, the concept ought to. So, things ought to change slowly when they have such a massive impact. However, he had the inspiration that maybe we could develop prototypes and iterate. And our methodologies could learn something from what we’re doing commonly in industry these days so that we can come up with the right solution more quickly get feedback from citizens more quickly and produce better results for our country. And I thought that this was a good idea and signed up to head into government for six months. I have to admit, I was a little skeptical. But I was very inspired by Todd Park. I was very impressed by what the Round One fellows had done the previous year. And I thought, “Heck. If anybody can do this, I think Todd Park has the power to influence getting stuff done, and why not me?” So, if we’re doing Agile and we’re doing rapid prototyping, Ruby is a really great language for doing software that’s malleable enough to be responsive to the needs of its users. So, that’s one of the reasons that I was biased that Ruby’s a good solution. JAMES:  This is a process of government? Make something like Agile more complicated, just because there are several entities involved and the need to do so much validation and stuff. Or is that not a big issue? SARAH:  I think laws are the alternate waterfall. You work for months if not years to pass a law. And then it’s what you got. And then if the outcome’s not what you want, you have to revisit it in a slow process. And so, I’m not sure that we should change that. I would love to have a little more validation of our laws that there we’re getting to the right outcome. But that wasn’t my department. But given the way that our democracy works, you are implementing something where a lot of the decisions have already been made. And a well-written law will frame what needs to happen without going into a lot of detail about how. And I think those kinds of laws are the best place. When we have policy that’s just like, “Okay, veterans should have benefits,” then I think that’s fertile ground for, “Okay, let’s create some software that’s going to get them the benefits that they deserve in an Agile method where they can sign up and say what they need and get it. And we have hospitals for them to get to and so forth, for at least the majority of veterans that are online and connected.” So, there’s the whole law policy issue. And then there’s what you spoke about, which is having multiple stakeholders that are not necessarily beholden to each other. So, that is a challenge. When it comes to Agile it’s much easier working with a small team where you’re looking at a representative sample of your customers. And a lot of Agile in industry, you totally are free to say, “Okay, here’s a setup, customers we’re just going to not include, because that’s going to let us move quickly. We’re going to focus,” so forth and so on. In government we can’t be like, “Oh, these citizens we’re not going to serve.” So, it’s a little more complex. But I think that we can still apply these methodologies to the problem. It’s just that much more challenging to get there. JOSH:  Okay. I think you said something that was interesting that is worth digging into a little bit. You talked about Ruby as being, it sounded like it was a natural choice for doing Agile development. And you said that software written in Ruby is malleable. So, it’s easy to change and adapt. Is there anything else about Ruby that you think makes it particularly well-suited for Agile development? SARAH:  Well, I think that it’s suitable for development in general. I think I’m contrasting this with my experience. I had done a little PHP before in my life. I think everybody’s exposed to it at some point or another. You need to throw up a simple web form, add on to a WordPress site, you write a little PHP. But you get into actually doing development and it helps. There was a reason that the industry created object-oriented programming 20 years ago, because it does help structure your code. And packaging up your data with your methods I find to be helpful. And that actually in modern PHP, you can write object-oriented PHP. However, the way that Drupal and WordPress work, they’re heritage. Even though you can use the latest version of PHP, you can’t easily, at least in my experience, use those features. You’re typically writing code with these hooks where you’re naming functions. So, your functions have certain names and then they’re called at specific times. It looks a lot like object-oriented programming. But it requires a lot of discipline. If you name something wrong, it just doesn’t work. You just don’t have all of these helpers that you have when you have a modern programming language. And that’s unfortunate because if you have to do something even moderately interesting, then I felt like I was coding in the 80s, in the midst of this modern cloud deployment kind of world. JAMES:  That’s a good point there, just the design naturally lead to a certain structure of code. So, it’s not to say that you can’t make these nice complicated object systems in PHP and then just use that little hook to tie it in. But it’s just that it’s not as natural to do that as it is. When you’re programming in that you think, “Ah, I just need this one other function so I’ll throw it in here and name it something different,” and then it doesn’t naturally lead to that structure. Whereas the way we build Ruby sites and stuff, making objects everywhere, does more naturally [inaudible]. AVDI:  PHP, [inaudible] things in government. JOSH:  Sorry, [chuckles]. SARAH:  The way that you typically structure code in Ruby, whereas if you’re doing a PHP add-on to a content management system, over time your code gets worse, unless you have an enormous amount of discipline. And you really have, at the beginning before you start coding, a real concept of how this thing is going to be created. And so, I think that that is challenging. And plus, there’s the whole testing thing. Ruby has great, fabulous support for automated testing and test-first development. And that is slower – it’s less adopted in the PHP world. And it’s harder to integrate into those systems, at least from my experience. JOSH:  Yeah. So, one of the points that Jeff Atwood, Coding Horror, made when he was on the show last year talking about Discourse and that project, was one of their goals was to make Ruby as straightforward to deploy as PHP. And his thought was that that’s one of the biggest barriers in the way of adoption of Ruby. And it sounds like that’s the kind of thing that could potentially help building a lot of government sites too. You used the name Drupal a lot. It sounds like Drupal is something that gets used in government software. SARAH:  Well, maybe I should just talk about my project a little bit. JOSH:  Yes, do that. SARAH:  So, I was at the Smithsonian Institution, which is an amazing place that has 19 museums. It has archive and libraries. It has our national zoo, research institutions. The Smithsonian has just a very small percentage of its collections on exhibit at the museums. Most of those collections, most Americans don’t actually know that most of the collections are actually there for research and it’s not just waiting in the warehouse until we feel like displaying them. They’re there for us to understand our history and our natural world. So, we were brought into the Smithsonian to look at this from an open data perspective and from a digital asset perspective. They’ve been doing a lot of work. They’ve been actually working since the 60s to digitize their collections, to create digital records as well as in some cases digital images of the collection objects. And so, they’d come up with this idea which it turns out a lot of different organizations who have archival material and specimen records are working on, which is let’s use the power of the crowd to create these digital records. Once we have an image of something that has writing on it, we can include volunteers who would help annotate this information and provide access to it. Does that make sense? JOSH:  That makes total sense. That sounds pretty cool. I’m curious. How did that work out? Was that successful? SARAH:  So, this was a great project. They had started it before we got there, where they had connected their digital asset management system to a Drupal frontend. And they had a services-oriented architecture. So, they had an API to access these digital assets. And basically, they were flipping on its head the normal process. So, normally what happens is there are these physical objects that an archivist or a scientist will use to take in by hand and write notes on card catalogues, cards and so forth, and now are typing in metadata about. And then later, they would get around to, “Okay, we’re going to take a photograph of the object or scan the object.” So, this process inverts that, where the first thing is just creating a stub record for this thing. Who’s the person who created it or collected it? And that’s just a placeholder digital record that has some metadata and basically where to find it in its physical location. And then, let’s take a photograph of it, because there are all of these mass scanning technologies where you can photograph things very quickly, with very little human labor relative to typing up stuff, and then put those photographs in front of people. And then anybody can type in what they see. So, that was a lot of what we did. I worked with Jason Shen who was another Presidential Innovation Fellow whose specialty was really communications and outreach. And what we did was most of our effort was about activating that community and really creating an engaged community and discovering what it was that excited people about doing this activity. So, most of our work was in that kind of what in the industry we might call customer development these days, or user research. And when we came onboard, I don’t know if you guys know this, but the Smithsonian has as many volunteers as it has employees and contractors. There are 6,000 who are paid staff at the Smithsonian and 6,000 volunteers. And almost all of those people walk into the buildings in Washington, D.C. or New York or Panama or whatever. And they have a badge and they often work side-by-side with the employees. They’re sometimes retired scientists or they’ll start out as docents and then become curators. And these people are doing the work of fairly senior staff sometimes. And sometimes, they’re just giving tours to museum visitors, and helping out the kids, or answering the phone. So, they do a range of jobs. And for that, they have some of the privileges of an employee. They get to go to the events in Washington for free. They get to get discounts at the gift store. And so, when we got there, there were a lot of people involved in the project who were the folks from the museums and archives and libraries who said, “Well, people are doing work for us. We should be at least giving them discount at the gift store. Are we disrespecting them if we’re not giving? It’s not that much. But should we go through that effort?” And unfortunately, that’s a little complicated, because they don’t have gift certificates at the online gift store. And you know, that’s its own project, right? So we said, “Well let’s find out.” Find out what motivates them. Would they be more motivated? Would they feel excited to have a discount? And unsurprising to me but surprising to some of my Smithsonian colleagues, people just love the work, the opportunity of being a part of our nation’s history, that people were just so feeling privileged, because they were “touching documents that had been in the back warehouse.” Often, they hadn’t been really viewed carefully since they were accessioned is what they call it, brought in and stored and labeled. And so, that discovery where people were like, “Wow, I’m reading somebody’s field notebook of when they were in the 60s in South America collecting frogs,” and, “Isn’t this interesting? We had this woman scientist with another woman scientist, traveled in South America and they wrote about their birthday trip to this island.”  And it just gives you a feeling of how scientists did actually live and work in 1960. And people found that to be very precious. So, then we were able to create things that would be very rewarding to these people. Jason put together a webinar where the folks who’d been transcribing a particular set of field notebooks got to meet with the archivist who knew that much more about the related material. JOSH:  Yeah. I love hearing stories about academic research type organizations. And just listening to you talk about the research process and environment there, it sounds like everybody’s so excited about what they’re doing. SARAH:  That’s really true. And I think that this technology has the opportunity to help us redefine what a museum, archive, and library is about. And that’s what’s really exciting about taking this Agile methodology and user-centric design and applying it to these different governmental activities that are typically this, “Well, there are the citizens, and then there’s this very tiny keyhole through which they talk to the government, and then there’s all of the people behind the government wall.” It needed to be that way in the 1800s when you had to go by horseback just to deliver a letter to the government. It doesn’t need to be that way anymore. JAMES:  Right. JOSH:  Now you have to drive by car to deliver the letter. [Laughter] SARAH:  So, that’s all just context, for the work we’re doing is really about citizen engagement. And the software is facilitating that. So, I arrive in D.C. And it’s a six-month long civic lesson for me to understand how it is, and why it is that our government works that way, and what things I need to do so that I don’t break the law, because that’s another thing, just a little side note. [Chuckles] In industry, it’s relatively easy to get fired and relatively hard to break the law, because there are lawyers who figured out all that legal stuff. And pretty much, you just do your job. The bounds of the law are way outside your job. In government, the reason you have a job is because somebody passed the law. And so, it’s really hard to get fired, which is maybe something we should fix someday. But there are things that you are doing because the law says you need to do them. There’s a whole bunch of stuff you have to learn like, “Don’t do this. There’s actually a law against that.” [Chuckles] Or, “You have to do this, because the law says you have to do it.” So, there’s a lot of the big learning curve there. So, in the midst of all this, I also discovered that my project is on Drupal, which implies PHP. And in the interview I said I would have an open mind, and so I’m like, “Okay. I’m going to spend the next three weeks while I’m learning about government also learning PHP.” JAMES:  So, let’s just clarify there. Is that handled through the law? How was that decision made? SARAH:  Right, so PHP is not mandated by law. Thank you for that clarification. [Chuckles] JOSH:  Okay. So, this is not like a legislature passing the law that pi = 3 and web programming = PHP? SARAH:  Exactly. We totally have the flexibility to choose our technology stack according to our legal patterns. But the team, most of the software at the Smithsonian, at least the core software that’s leveraged across the whole institution is written in the Office of the CIO. And that’s typical in government, is that you have a CIO, Chief Information Officer that will sometimes have a team of engineers who write core services. Sometimes they don’t. Sometimes, they just have a CIO who then has different departments working for them, or sometimes they outsource all of their tech. And there is some debate amongst some people. And we had some of these discussions. Should our government be writing software? And I’m of the opinion that we just need people inside government, more people inside government who really understand software, so that we could write good software. But we can’t outsource all of the technical decisions or we won’t get the right decisions at the end. That’s my opinion. JAMES:  Interesting. SARAH:  So back to, how was this made to use Drupal? So, you could go to the site now, which is transcription.si.edu. And at its heart, it’s a very simple site. Users sign up. There’s a bunch of information that they can see about the various projects, about the activity in general. And then the core of it there’s an image that’s displayed. There’s a web form. And they can go and see the next page. So, the very first iteration of this is 95% what you find in any CMS, and 5% or not even 5% of the functionality, if you were to write all of this from scratch, is custom software that says, “Okay, we’re going to pull this image from our asset management system. Whatever somebody types in this form, we’re going to save off to our collections database.” So, very, very little code is actually unique and special to this thing. And so, on the face of it, starting with the content management system, it makes a lot of sense. So, let’s think about what content management system we would choose. The top two content management systems in the world are WordPress and Drupal. Joomla’s a close third. Sometimes, that’s second depending on who you read. But most people would say that Drupal’s number two. So, then the question is WordPress or Drupal? In this particular example, Drupal has more extensions and more of a community around writing custom code, because you’re thinking that, “Okay, in a few months, maybe six months, maybe three years, we’re going to be making things that are more sophisticated. So, we want to have something that’s a little more extensible. It has more plugins that are really functional, that do things that are maybe a little more unique than WordPress.” And so, that’s how they arrived at Drupal. That make sense? JAMES:  Yeah, absolutely. JOSH:  Yup. So, are we still talking about the arc of what you’re doing at the Smithsonian? SARAH:  Yeah, I’ll finish up that arc. So, that’s a really rational first decision. And once I learned about how they came to it that seems to make sense. And so, I’m like, “Okay. So, let me just code in PHP and do the extensions that I think are merited here.” And so, I went down that path. And what I found is that as you develop more and more code then you get deep in this Drupal world. And then you have this fragility that comes from, okay you’re developing with hooks instead of object-oriented programming. And the testing infrastructure is a little harder to wire in there. Plus, there isn’t a culture of testing. So, that’s yet another sell. And then often the extensions, I find that when I add a Ruby gem to a project, often the Ruby gems work and play with a bunch of other Ruby gems pretty easily, and I can use it in a bunch, like more general-purpose libraries than the stuff I found in Drupal. We know that there are PHP libraries. It’s all doable. At the 10,000-foot view, these are all interchangeable. But basically, you can paint yourself into a corner much easier, because these things are I think rigidly formalized. Although maybe my PHP skill is not what somebody else would have had, so I give it that. The key thing that I wanted to talk to the Ruby community about is because there isn’t a good choice that competes from a functionality perspective, if not from a community perspective, although I think the community is part of the functionality really, with Drupal and WordPress, once that decision is made, it’s hard to change. You might later end up with 95% of your site is custom code and 5% of it is a CMS. But at that point, are you going to switch programming languages? JAMES:  Right. That’s a really good point, actually. SARAH:  So, I wanted to ask, why don’t we have an excellent CMS that’s been around for a couple for years, more than a few years? So, whenever I ask, “Why isn’t there an excellent CMS?” there is always a great answer. [Chuckles] SARAH:  But it is a different answer every two or three [inaudible]. AVDI:  [Chuckles] JOSH:  So Sarah, when I was at Pivotal, we had a lot of client projects that were basically, “Oh we want a CMS with some extra, with some custom functionality.” And whenever we looked at it, when we really unpacked it, what they really wanted was an application with a little CMS embedded in it. So, it ended up being that latter case that you were talking about. And in Ruby and Rails, it was just so straightforward to put together those CMS capabilities within the Rails app we were building, that using something like a CMS library or engine or package or whatever form it was delivered in was actually more work to figure out how to use that thing and then to figure out how to customize it in a way that was compatible with the rest of your application’s requirements. It was just easier to write it ourselves in Rails. So, that’s what we ended up doing. And it was, I think the right choice in all those cases, because we got what we wanted and we didn’t have to deal with all the overhead of this project that wasn’t really designed to serve exactly what we were doing anyway. JAMES:  So, that’s a good theory. I don’t know if I totally agree with it. And obviously, we’re all guessing. But what I was thinking is I wonder if the types of communities around, say PHP and Ruby lead to different outcomes. So, I hear what you’re saying, that it easy to put some minor CMS capabilities in a Rails app, and I agree with that. But those capabilities are going to be no polish, simple things, unless you devote a significant amount of energy to it. JOSH:  That is true. And the other big downside is that if you’re building a lot of web applications that are going to be used by the same population of users, you want the CMS stuff to operate the same in all of them. JAMES:  Right. JOSH:  So, building a custom CMS for each application at that point is, you’re not getting the benefits of uniformity there. JAMES:  Right. And I think one of the advantages of things like Drupal and WordPress is that you have this large list ecosystem, like Sarah was talking about, of these plugins that do a lot of, that solve a lot of common needs. And so, you can get really far with just cherry picking some stuff that applies to your particular project. And you can stand something on its feet really fast, which in the case of the project Sarah was describing, I think was one of the great initial goals. Let’s stand this up and let people start editing data, and then see where it goes. The downside of that is what Sarah has said, is that as you begin to say, “Wouldn’t it be great if,” and you start adding in that more and more custom stuff, then you’re going to reach a point where it flips upside-down on the benefits ratio. SARAH:  Yeah, and wouldn’t it be nice if we didn’t have to have, because we want to have CMS functionality out of the box, that dictates our choice of language. Setting aside whether Ruby or PHP is better or worse, if you want to be programming in Ruby, why must you build all of the CMS functionality from scratch all the time? JAMES:  So, I will point out, just because I’ve worked with it a fair bit, that we do have Radiant. And it’s not as new as you might think. It’s not this year’s answer. I just looked on the page to try to figure out the date. The copyright starts in 2006. And it was used on the Ruby’s home page for a while. And we’ve since moved on. So, it’s been around long enough to serve that purpose and move on. I would argue that Radiant is not like Drupal in that it describes itself as a no-fluff CMS. And I would say the PHP solutions are the opposite, lots of fluff, in that you get to flesh things out very quickly, whereas Radiant’s more developer-focused, maybe is the way I think I would say it. SARAH:  Yeah, and I did use Radiant on a project a few years ago. And I think that it is the mature CMS in the Ruby world. But one of the questions with Radiant and CMS’s that come after it is it doesn’t have… that we have this dichotomy. I think part of it is DHH said we could build a blog in five minutes. So, why would we respect any blogging functionality? We as a community, I think that we don’t respect the challenge of creating user interface objects that can be reused. AVDI:  Yeah. SARAH:  We want to always recreate the interface from scratch and have that be custom. But we don’t feel that way about our ORM. JAMES:  [Chuckles] SARAH:  Our ORM, we want to use out of the box and rely on. But our UI controls, we want to make from scratch all the time. What’s up with that? JAMES:  That’s a really good point. And again I think, and I admit that I’m totally guessing, but I think it’s probably a little to do with the cultures around PHP and the cultures around Ruby. Whereas Ruby, you tend to have, I don’t know, I want to say more backend developer kind of stuff, that… AVDI:  Well, there are a lot more hobbyist developers in PHP. There are a lot of people that came in from fiddling a little bit with HTML and then gradually, I think, started fiddling with the PHP. SARAH:  But is there a cause and effect there? Because they have WordPress, they start with a WordPress site and then they become PHP developers. JAMES:  That’s [inaudible]. AVDI:  Yeah. SARAH:  Whereas we have a lot of hobbyist developers. I talk to a lot of people where Ruby’s not their day job. They’re professional developers. They’re hobbyist Ruby developers. JAMES:  Right. AVDI:  Yeah. SARAH:   So, I think culture’s eminently malleable. Is it a good thing? Do we not care? Are we cool with the fact that we write all our UI from scratch and we want that to be the way it is? AVDI:  I’m looking at the list of CMS systems that are listed in The Ruby Toolbox. The top four are Refinery, BrowserCMS, Locomotive, and Radiant. And they’re all Rails plugins, and I think that’s interesting. Rails engines, I guess, they’re all built of Rails. And I wonder if that has any effect on this too, just the fact that pretty much the only game in town, if you want to do something CMS-y is to use something that plugs into Rails, that sits on top of Rails. Whereas things like WordPress and Drupal, as far as I know, they’re the framework. They are the framework and then you plug stuff into them. And I’m just thinking about some of the differences in how that shows up in using the app. So, I still use WordPress for all my blogging and I have for years. And if I want to try out a new WordPress plugin, the way you do that normally is you either upload the zip file with the plugin into WordPress and then bang, it’s installed, or even more simply, you’ve got basically an app marketplace almost, like a plugin marketplace built into it these days. And you just find the plugin that you’re looking for and you say install this. And you do that as a user, basically, not necessarily as a developer. And bang, that plugin is installed. And we would never even imagine having the framework-managed plugins. We would tend to think of a plugin as being like a gem that a developer adds to the Gemfile and then pushes out a new release. So, it’s a different way of looking at things. JAMES:  Yeah. I think that’s what I was trying to say, is that I think the kind of people that get started with PHP, maybe taking a webpage, throwing some PHP code in that page, and then fleshing it out from there, have a less developer-centric approach. And I don’t mean that in a derogatory way. I mean that in a positive way, like Avdi just said. There, putting a plugin in WordPress is stupid simple, whereas in Ruby we’d be like, “Okay, go into Bundler.” AVDI:  Well, and it’s a user concern too. JAMES:  Yeah, yeah, right. It’s at a different level. SARAH:  Well, yeah. Why, if what I want to do is make it so that my textboxes have a different set of UI controls for rich text, why do I have to have my developer do that with a redeploy of my software? Whereas within certain bounds, the Drupal developers are advising about which plugins they’d choose. But you just pop in a little different UI decoration without redeploying your software, which seems like a nice thing, whether you’re a developer or not. JAMES:  Yeah. I think I hear you. SARAH:  But I think it’s really interesting what Avdi said, is that Rails sets you into a certain dev deploy situation that is different from the way that the PHP CMS is at. And there’s no reason that you couldn’t create in Ruby a piece of software where you add something dynamically via user interaction. JAMES:  Yeah, Radiant lets you put in snippets and chunks of CSS and stuff. But even in Radiant, I would say from my experience using it which is not extensive and was a while ago, it’s still more developer-focused I think than PHP’s. SARAH:  Yeah, that was my experience as well. JAMES:  Question. Why doesn’t one of these solutions come out of the Ruby world and get built up? I took Amy Hoy’s 30x500 class a long time ago. And actually, she had this one lesson where she was teaching how to vet ideas, basically. And she had these certain ideas that she said are non-starters. The idea itself is flawed, and that you should never try to use it as a basis for a business, I should clarify, not that there’s something wrong with these ideas, but that these ideas are bad ideas for a business. And I remember on that list is a CMS. [Chuckles] JAMES:  So, that’s interesting. SARAH:  Yeah. And I think that CMS’s are predominantly, they’re not businesses, just like a lot of open source software. We, as communities of developers, we create open source software largely so that we don’t have to keep rewriting the same code and we can focus on stuff that’s more interesting. JOSH:  Right. SARAH:  And it’s great when there are open source options and you can be like, “Okay, I can focus on inventing something or doing something that is actually intellectually challenging. And I can just snap in something. I don’t need to write it one more time.” JAMES:  I like what you said earlier about the value of being able to reuse user interface components. Why do we feel the need to develop those every time? That is a very Ruby thing, I think, the need to that. And I like what you said about how if you can write a blog in five minutes, well then, that’s not hard. But that’s also so misleading. I have been rewriting my blog lately. And I’ve been tracking my progress. And I’ve spent about ten weeks of free time on it, so not massive amounts of time, but free time. And it is a big project, do things like let users log in through Twitter, GitHub, or do Atom feeds or do spam detection, or all that. SARAH:  Yeah, and I would love to see an ecosystem of Ruby things that extend the UI rather than having… what I think we have is this huge divide between this stuff you do in Ruby and then everything else is in the JavaScript world. And there aren’t as widely accepted patterns for Ruby stuff that goes toward the UI. I don’t know, maybe you guys, maybe I’m missing something. AVDI:  [Chuckles] JOSH:  There’s no clear winner there. SARAH:  Yeah. JOSH:  Sarah, I’m going to change the direction just a little bit, because I want to ask about the non-technical part of the job more. SARAH:  Okay. JOSH:  And the process. And working with government I think can be really shocking to developers who are not used to it, or anyone who’s not used to it. And the whole mindset of people who work in the bureaucracy or administration is just so foreign to a lot of us who are in business. The way private businesses and public businesses get run is really different, because we have different kinds of goals and objectives and metrics that make us successful. And just the whole way the government gets run is different. And the one thing that I learned really early on is that most of the way that government is set up to work internally is to protect individual people from being accountable for their actions. JAMES:  [Laughs] JOSH:  That’s the purpose of the bureaucracy is that people can sit down and do their job and not worry about having to deal with somebody angry that they did something wrong in a particular job. But then that’s expanded to be nobody has to be accountable for anything in particular. It’s just the process that is accountable. SARAH:  I think that’s a really good point. Accountability I think is a very big concern in government. And I think it actually stems from a desire to be accountable. Its origins are that we need to be accountable to the American people and we need to make sure that we’re not breaking the law. So, we will have in government, for example, every organization, every agency has an inspector general that is a watchdog on the whole organization. And then you’ll have people in your organization who are the ones who know the details. You’ll have a broad outline. I should do this. I shouldn’t do that. But then if you’re in this new area, you’ll go to one of these people and you’ll be like, “Okay, what should I do in this case?” And they will tell you. And then sometimes people get into these habits where those people, you have things that… One of the things that the Innovation Fellows program is doing is challenging some of the accepted practices, because people, they do some patterns and be like, “Okay,” people will say, “Oh, that’s a policy.” And then our administrative folks would go, “Okay well, can you show us the law that says we can’t do this?” And, “No, there’s no law. It’s a policy.” “Okay, go show us the policy document.” “Oh actually, there’s no policy document. That’s just the standard practice.” “Oh, is that written down anywhere?” And then you just keep poking at it. And sometimes you do bump into a law. And then people go and they read the law and they’re like, “Okay well, actually here’s a way that we can accomplish the goal while still being within the law.” And that’s a little tiny innovation in process. And sometimes, it’s just talking to people and being like, “No actually, we’ve done our homework. We talked to the legal folks. And we can do this process without breaking the law.” But that’s what happens, is you get these entrenched people patterns because you can’t have software developers who also know all of the laws. We just have to have a separation of concerns there. And ultimately, you have to have people who have a background in legal who are reading the text of the laws and interpreting them. So, because we need the separation concerns, you have these different roles. And so, you’ll have these people who are in various places in the hierarchy responsible for interpreting the law and the policies that are documented and we have to follow them. And then you have your manager that tells you what to do. And then you’ll have cross-agency initiatives where your manager’s not the only one telling you what to do. And this gets fairly complicated, because there are these different rules and people that you have to pay attention to and do what they say. And that can box you in to just, “Okay, I’m going to just keep my head down and do what I’ve always done, because then I can be the most productive.” So, from the outside, after it runs for many, many years, it gets really broken. And part of that, I think is because it’s not only a lack of accountability. There’s also a lack of reward system for taking any risks. There’s only a negative consequence to taking risk. There’s no positive consequence to taking risk in government. And that’s one of the things that I think the administration’s really looking at. And the office of management and budget, how can we actually incent our government employees that, “Okay, if you stick your neck out and you really try to do the best thing for the American people, there’s some upside.” JOSH:  So, I had an interesting experience. Sarah, I know you’ve heard about this because it was mentioned in one of the talks at the first GoGaRuCo about doing open source voting. And I got to work on a little project at Pivotal related to that where we were building a prototype for some voter registration system that was being submitted to a government commission that was looking into online voting technology. Pivotal Labs got involved in working with the Open Source Digital Voting Foundation and just knocked together a prototype that was actually very functional in what it did. It was cheating in the back, but the software worked and showed the user experience of how you would do an online voter registration system. And this came out of this meeting where a whole bunch of Secretaries of State were talking about this stuff with members of Congress. And they said, “Oh, here’s just the kind of proposal we want to see for building one of these systems. We want to get a ballpark estimate for how much it would take to build this.” So, Pivotal and OSDV went off and we spent two months knocking together a prototype in spare time that we had in the office, for probably a billable rate of $30,000 worth of work total. And the big consulting companies came back and said, the Accentures of the world, one of those, came back and said, “Oh, here’s our quote for a $500,000 six-month study that we will take to put together the requirements for the prototype that we will build that will inform us as to how much the budget for the whole project would be.” And the OSDV guys showed up and said, “Oh, here’s the actual functioning thing. You can see how it works. And yeah, there’s tons of work to do to actually hook it up as a scalable web app. But hey, take a look.” And the politicians in the room got completely confused by what happened, because they’re like, “Oh, this very big reputable consulting organization just told us that it’s going to cost us many millions of dollars to develop just the first part of this, not even something that works and is deployable. And you’re telling us that you could build this kind of stuff and have already built it?” And it’s like, “Why are you lying to us?” It’s like, “We’re not lying to you.” [Laughs] “Here’s the software. It works.” SARAH:  Well, that’s exactly the kind of shakeup that we’re trying to create, that it's always challenging to define what does it mean to work? So, if you’re bidding on a government contract, so you have to account for meeting requirements, and that whole RFP process where you have to figure out how much time it would take. You’re not billing by the hour, like in two months we’re going to have something that’s demonstrable and we can put it in front of users, but maybe doesn’t have all the functionality they need. That’s never in an RFP. And that’s some things we’re trying to look at, is can we change the way these RFPs are written and change the process so that we can start with something like, “Let’s have users use a subset of the functionality.” But think about it. If you’re a lawmaker and you’re going to authorize the government to say, “Okay. Yeah, you can just hire somebody who won’t guarantee you that it will support all your functionality and will just deliver a piece of software in two months that they can put in front of users.” How do you word that? JAMES:  It’s a tricky question, right? I understand what you’re saying. We have to have these ten things. And then it might be like, “Well, seven of those are something we can throw together in a weekend.” [Chuckles] Or part of some subset of those is the blog you can build in 15 minutes. [Chuckles] SARAH:  Yeah. And then I think that it’s also that this is where those ridiculously long specs come from, because somebody’s like, you want it to say okay, we’ve got these goals of what we want citizens to be able to do. But if you know that during the time that you’re building, during those two months, you’re not going to be left alone, you’re going to be having to talk to 37 people who each work for a different department, who will tell you what they think the citizens need, and then at the end of that each of those 37 people have to approve your work, in addition to the citizens being happy, that’s where we get the $500,000 price tag, because it’s all of that overhead. And that’s what we have to turn inside out. And one of the exciting things is, it’s just announced, this new group called 18F, which is inside of government having a small team that can deliver on just those prototypes. So, you don’t have to put it out to an RFP bid. You can just go to this internal government group and be like, “Okay, make me a prototype that does something like this so that I can evaluate how hard this thing is that I’m going to want to put out to RFP. And I think that’s pretty exciting. JAMES:  So, how does that work with concepts like Agile, where we just try to say, “Okay, it would be great if we could do these ten million things, but the problem with that is you’re talking years and we want to do something faster. So what we need to do is turn this down to an MVP, pick the stories that are absolutely required, do that, then we’ll talk, then pick the next set of stories”? It seems like you say. If you have 37 people doing oversight on a particular project, how do you even handle something like a customer in an Agile “definition” of the term? SARAH:  I think the key thing is getting all of those 37 people to buy into this user-centric design, that it’s not their… well, listen to them. But they’re not setting the requirements, the citizens are. That we have some kind of goal where we’re trying to say, “Okay, somebody can submit an application for a government job. And within two weeks, we can know whether they’ve gone on to the next phase and let them know that they haven’t met the minimum requirements.” As opposed to what usually happens where it’s maybe a couple of months later and they’re still going through the process. So, that’s an example where you can think that a lot of people in government might have an opinion on that. But if you could turn it inside out and just say, “No, our goal in developing software is to meet some citizen need,” and we can all as government employees inform that, but the only way we’re going to ultimately know whether we met that citizen need is to usability. You test it with a bunch of citizens. And everything else is just all of our opinions that are not requirements, their opinions. And I think that’s the way we turn it inside out, is we get everybody to agree that the need we’re meeting is not a bunch of well-meaning government employees who are super experienced, but that those “requirements” aren’t actually requirements. They’re ideas. JAMES:  It seems like this is an area where open government has some advantages. If we make the data available and open to the citizens, then they’ll use it in whatever ways they’ll use it. And the marketplace will naturally filter what’s valuable and not valuable in that. And then those projects become big and small. And it’s the fact that that data got moved outside of the government process that allowed that to happen. SARAH:  Yeah, absolutely. I’m so excited about the executive order from last year which makes our data that’s paid for by our federal tax dollars by default open. And this movement towards open data and open APIs means that, “Hey, you don’t like how this and such government application works? Great.” We can make an open source app that does that, or some private industry can make an app. And I’ll pay a premium to have a great app that integrates a bunch of government open data. Because I’m fine with paying some private citizen a little bit extra in some cases, for that service. You know, that we can just open it up, and give different agencies the opportunity to work with each other’s data. That’s one of the things that is, I wouldn’t have guessed but not surprising once I heard it, is that open data within government has incredible accelerating effects on work within the agency that owns the data. That often, we see situations. These agencies, sometimes they have hundreds and thousands of people. And you may have the right to see the data that somebody in another department has, but you don’t even… When you want something, government employees go to Google just like everybody else. And our internet search systems inside government agencies are not as good as the public search systems that are available out in the world. So, why not leverage that stuff? JOSH:  Interesting idea. [Chuckles] JOSH:  Yeah. SARAH:  Yeah, a lot of this stuff, one of the fellows said when we were talking about some of the challenges of you get into this government job and you’re like, “Oh my gosh. Something I could do in a week or a few days at a startup I can just tell it’s going to take me a few weeks or a month and a half.“ And that’s hard. But then at the same time, he said, “There’s such a low bar.” [Laughter] SARAH:  We don’t have to… Just getting close to what we think is a great app is so much better than what government employees and our citizens have to deal with when it comes to government services. That we can just make it something that we think is just the beginning of what we’d like to see, is still far and above what people are used to seeing. And that’s pretty exciting. JOSH:  Awesome. JAMES:  Alright. Any other questions or should we do some picks? JOSH:  I just got a question about the day-to-day experience of being a Fellow at the Smithsonian. Where did you go to work? Did you walk into a giant gallery full of prehistoric animals? JAMES:  [Chuckles] SARAH:  That’s a great question. JOSH:  Yeah. I want to know. [Chuckles] SARAH:  So, I was working in the capital gallery, which is right off the Washington Mall. So, it is an office building. It’s right near the Department of Ed, and Health and Human Services, and the Department of Transportation, and Department of Agriculture, are all in this, some corridor. But it’s also right next to Air and Space. It’s three blocks away from what they call the Smithsonian castle, which is right next to the African Art Museum and the Freer Sackler which is Asian art. And then I walk a little bit across the wall to natural history, which is where all the dinosaurs are. And we did a project with the Botany Department, which is in the Natural History Museum. And so, for a while, I would have almost weekly meetings. And I would always say, “Oh, I’ll come to your office.” [Laughter] JAMES:  Right. SARAH:  And I loved, I ended up getting my badge so that I could go in the back offices. And you could go look at the dinosaur bones that are on shelves and stuff. And then American History is just fabulous. And that’s just the next museum over from Natural History. And then whenever I could, we would also have meetings at the castle which was the very first Smithsonian building. It’s the Smithsonian Institution building. And when the Smithsonian was founded, does anybody know the story of how the Smithsonian was founded? Do we have time? JAMES:  Go for it. SARAH:  So, this guy James Smithsonian who was an Englishman, he left his estate to the United States of America. He had never visited the United States of America. But he said if his heir had no kids, he wanted his whole estate to go to the United States of America, to found the Smithsonian Institution to increase and diffuse knowledge amongst men. So, that was his idea. And he left this in his will. And the British government sent it over to the American President, which I forgot. Who was the president in 1848? But the president felt at the time that this was not within the executive powers to accept a bequest. And this was the equivalent, it was like, I don’t know, 40 million dollars, which is 400 million dollars today. It was a lot of money. But he tossed it over to Congress. Congress debated it for six years. “I think we should build an art museum.” “No, we should build a Natural History Museum.” “What we should really do is build a telescope to look at the planets, because we really need to understand our universe.” It was debated back and forth. And finally, this congressman took every single proposal and put it together and said, “We’re going to do all of it.” [Laughter] JOSH:  Yes. JAMES:  Awesome. JOSH:  Nice menu. Give me one of everything. SARAH:  Exactly. And then that guy sailed across the ocean to collect this money in gold. AVDI:  [Chuckles] Oh, geez. SARAH:  And sailed back to America. JOSH:  [Laughs] Wow. The whole ship handcuffed to his wrist, right? SARAH:  Yeah. Can you guys believe? That ship could have gone down in a storm. And then we wouldn’t have had the Smithsonian. JOSH:  Wow. SARAH:  That stuff happened. JAMES:  I’m taking notes for my next contract. I expect to collect my payment in gold. JOSH:  [Laughs] Yeah, talk about identifying project risk factors. JAMES:  Right. SARAH:  [Laughs] JOSH:  The funding could be lost at sea. AVDI:  [Laughs] SARAH:  So yeah, so they gave the Smithsonian some land on the mall, which was then almost an island, because what is now a filled-in road was a canal. And so, it was just this big field. And they built what’s now the Smithsonian Institution building and it had two wings. And one was for science and one was for art. And they collected paintings and they did science experiments. [Chuckles] And that was what they did. And then I remember being in a meeting with the Undersecretary of Art and Culture, Richard Kurin, and he said, was with Diego Mayer-Cantu and Jason Shen, my fellow Fellows, and he said, “Do you know that Abraham Lincoln used to have meetings in this room with the Smithsonian secretary during the civil war?” And people would mail him letters about stuff, things, ideas for how to win the war. And some of them were scientific in nature and he didn’t know how to evaluate them. So, he would keep them in a stack. And then once a week, he would walk down the mall and meet with the secretary and a few science advisors. And then Abraham Lincoln would pull out these things and they would talk about them. And they’d put them in the crazy idea pile or maybe this is a… AVDI:  [Laughs] SARAH:  …good idea. And out of this, what they called the crazy idea committee, they actually… This was also, the war was happening right there in Washington. You could go to the top of the Smithsonian building and see the other side of the conflict. And what they ended up doing was flying one of the first hot air balloons, hot air balloons were new [inaudible], over the Smithsonian castle, and they had it tethered. So, somebody would use a telegraph machine from the balloon and they would go to the land and somebody would listen to the taps from the telegraph machine. And they would say where the enemy troops were and then somebody would etch it. [Chuckles] And they would make prints and send them all out. [Chuckles] SARAH:  And this was innovation in technology. JOSH:  It’s like first-generation drones. JAMES:  Yeah. SARAH:  Exactly. JOSH:  [Chuckles] But with people. SARAH:  I like that. So, everybody, every time you had a meeting at the Smithsonian, it’s almost like there’s this oral history of, “Did you know what happened in this place hundreds of years ago?” At one point, when we were first there, there were these events that would happen when we were first there. The whole network was slow because the baby panda escaped from the zoo. And the webcam was the big deal there. And so, that’s a big traffic moment. And yeah, another big traffic moment, we were going to actually have the press release go out about our fellowship. And then it was delayed because they discovered a new mammal. This doesn’t happen very often. So, that was pretty exciting.  And you find out, learn these things. JOSH:  So, this sounds like an amazing opportunity. How did you get this opportunity? And can other people get this opportunity? SARAH:  Great question. Right this minute, you can go to whitehouse.gov/innovationfellows and apply. So, I heard Todd Park speak in December 2012, and before that, didn’t think that you could say innovation and government in the same breath without being sarcastic. And he told all these great stories from what the Round One fellows did. And he actually said at the end of his talk, if you have any ideas about innovation in government email me. So, I emailed him with my ideas about education, government, and ended up actually being on the phone with him and talking about it. And he said, “You know, you should apply to this fellowship.” And it took me a little bit to get over the fact to even consider doing it. But the more I heard stories about change happening and the more I thought this is something that really needs to happen. And it is our hope that this program will continue indefinitely. However, I think we have a unique opportunity with this administration, that it’s less about the politics of the administration, but more that Obama, President Obama is the first president that has really embraced technical solutions to problems. He is fairly savvy about using technology himself and also hiring technical leaders like Todd Park, and authorizing. This is called the Presidential Innovation Fellows program. President Obama thinks that this is a good way that we can do better with technology in government than what we’re doing right now. And we certainly hope that this program will outlast this administration. But I think that there is a pretty big opportunity right now that may not come again. And we shouldn’t take for granted that we can just apply next year. And so, last year that’s how I felt. I was like, “There’s a round two. There may not be a round three.” And if I want change to happen, maybe I just need to do it. Maybe I need to step up here. And it was a pretty big deal. You may remember I was CEO of Blazing Cloud, a mobile development company. Being CEO of a company is not a small thing to walk away from and figure out how you’re going to get your team to operate without you. Luckily, I had an awesome COO, Stacia Carr, who stepped up and stepped into that role. I was CTO of a startup and I told my partners, I am taking six months away from this. It’s hard. It’s a big deal in the life of a startup to put it on pause for six months. The site was running and so forth, and I got agreement that if we had any disasters, I would step in on a weekend and help out. But this is a very, very big des-… And I have a family in San Francisco. So, I spent a significant amount of time in D.C. away from my family. My husband said, “Okay, I’ll support you in this.” You know, he said, “I think this is important for the country.” So, this is a non-trivial decision but it is an important one. And if we don’t have people like the people on this phone call, our listeners, stepping into government, then we can’t complain. At a certain point, if you’re not willing to help solve the problem, then you just should live with the shitty tech that somebody else makes. JOSH:  [Chuckles] Yeah. Yeah. I’m inspired. [Chuckles] JAMES:  Absolutely. JOSH:  I wish that this year didn’t have a mind of its own for me. [Chuckles] JOSH:  If I could take some time to go do this, this sounds like this would be an awesome thing to do, at least not in the winter. SARAH:  [Chuckles] Yes. JAMES:  Right. SARAH:  Well, we are, there is support for remote work. I think it is important, though D.C. is a very much face-to-face place. And that’s part of what we’re trying to fix, to really… we embrace remote work. And to get that with open source, and there is a lot of it. Data.gov is a fabulous open source project. If anybody has any interest in participating in an open source project that is making our government better, Data.gov, it’s on GitHub. It was created from the beginning as an open source project. And I think that has helped with its resilience and really meeting the needs of the open data community. And it’s not done yet. So, there are a lot of improvements that need to be made. So, even if you can’t or aren’t ready to make the decision to become an Innovation Fellow or you’re early in your career, get involved with open source and open data. Thank you for letting me rant. JAMES:  Yeah, no it’s awesome. I want to say, when Sarah talks about the shelves in the Smithsonian, I don’t think I had a good image in my head of that until I looked through her slides. So, we’ll put a link to the slides in the show notes, and in particular go to slide 28 where you can see this long, long stretch of shelves. It’s quite impressive. SARAH:  Yeah, it was pretty special to be involved in that. And I think everybody had, the [inherited] history of the Smithsonian is pretty unique. But I think in every agency there’s a heritage of that, you’re just in touch with these things or these buildings and these institutions that were created in order to support our democracy. It’s pretty awesome. JAMES:  Alright. We’ve talked about this for a while and we should move on to do some picks. Avdi, what do you have for us this time? AVDI:  I don’t have much this time. I did mention last time that I’d switched cellphone providers. And as part of that process, I decided to just buy myself a new GSM phone so that it would be my phone rather than something that I got through the cellphone company. And I wound up going with a Moto X from Motorola. And I have to say, I think this is probably the perfect Android phone right now. I switched to it from a Galaxy S4. And it’s just really good. It’s small. I say phone because it is a phone. It’s not a miniature tablet. It’s rounded and feels good in the hand. It’s got excellent battery life. It’s got some cool stuff going on with how it leverages Google voice control. So, you can pretty much just talk to it and tell it to do things without even picking it up. And yeah, it’s just a really well-balanced phone-sized phone. Moto X. So I think that’s really about it for me. JAMES:  Josh? JOSH:  Let’s see. I’ve been kind of distracted by working lately. [Chuckles] I don’t have picks except I’m going to pick the Ruby Hero Awards, because that season. And I think people should go and nominate people who they think deserve some recognition for their awesome contributions to the world of Ruby. So, that is my pick. And that’s it for me this week. JAMES:  Okay. So, I’ve been reading this cool series of articles, I guess you would call it. It’s just one article that’s growing on Martin Fowler’s blog called Microservices. And it’s a more modern term than SOA, I guess you would describe it as. And Martin and James Lewis are co-authors on this, breaking down what they are, how big are they, what are they designed around? I found it all very fascinating reads. It’s been a little bit controversial on Twitter. I’ve seen some Tweets about attacking certain parts of it as being misrepresentative of what SOA is and stuff like that. But I really enjoyed it. so, I would encourage you to check it out. Maybe we’ll get Martin back on to talk about it at some point. And that’s my only pick this time. So, Sarah, what do you have? SARAH:  I have a few picks. For people who listen to Ruby Rogues, if they still want to listen to more podcasts, I started in late December a podcast with the fellow, Jason Shen, that I collaborated with at the Smithsonian, called Tectonic Podcast. So, we talk about innovation in business software and life, following our innovation fellowship to keep that fellowship going while he’s in New York and I’m in San Francisco. Also, one of the things that we didn’t talk about that I want to mention, which has a great set of videos, is we did a great hackathon, the first ever Smithsonian hackathon, where people wrote code for the American Art Museum. So, AmericanArt.si.edu/luce/hack. There, the outcome of what a group of citizens did with some experimental open data APIs that the Smithsonian had. And I think that’s such a neat example of what we can do when you can get government and citizens together. And then lastly, on the technical side, this may have been mentioned before on Ruby Rouges. But I’ve really been enjoying Screenhero for remote pairing. JAMES:  Alright, well thank you very much Sarah for coming and talking to us. It was very interesting. SARAH:  Well, I really appreciated the conversation. I learned some stuff. JOSH:  I have one last question and that’s your opportunity for shameless self-promotion, are you speaking or appearing anywhere in the near future? SARAH:  No, nothing that’s been scheduled. JOSH:  Okay. So, we’ll just keep our ears open then. SARAH:  Alright. JOSH:  Okay. Thanks again. JAMES:  Yeah. SARAH:  Thank you. JAMES:  Thanks everyone. We will see you next week. Bye. JOSH:  Bye. SARAH:  Bye. AVDI:  Bye.[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics that are an active part of the Ruby community.]**[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]**