 So I'm Ben Schofield, and I'm here to talk to you about crimes against development, stealing ideas and tools and applications from other frameworks and communities and languages, and bringing them into your own community. And obviously, the title of my talk is a reference to a very famous Picasso quote, which is, the hard part is, no one can actually find where Picasso said it, and so it comes out in a bunch of different ways. And I think I really like this one, if I can, well, I'm standing right here so quick. All right, so I love this, right? The Bad Artist, I'm going to tell you, the Great Artist of Steel, I've also heard good artists copy Great Artist of Steel, and it's by, well, I guess it's by Banksy and not Picasso after all, right? So it, this is a really weird quote, particularly the first time you hear it, because we were, so accustomed to think of stealing as bad, and copying is not nearly as bad as stealing. But what happens is, when you start to unpack it, they mean something very specific about stealing, and it's the art of taking something from someone else and making it your own, right? And so we can look at this in art, particularly, right? This is where the quote originated, and if you look at a bunch of different artists, we see influences and, you know, the same, same subject paintings and sculptures all the time, and even with things like street art, right? Street art is very, very prevalent. This is The Obeyed Giant, do you guys know The Obeyed Giant by Shepard Ferry? Right? Shepard Ferry is a street artist who got to start by taking a picture of Andre the Giant, right? Wrestler from the 70s and 80s, stylizing his face to an unrecognizable degree, and slapping the word obey underneath it, and then plastering it all over the buildings in Los Angeles, and then around the world. And The Obeyed Giant became this thing, it would just pop up everywhere. And it was actually stealing, right? This is the face of Andre the Giant, but Shepard Ferry has, you know, stylized it so far that he's made it his own, and it's now this new thing, this Obeyed Giant, that has greater meaning and much greater prevalence. I'm sure there are people all around the world who have seen The Obeyed Giant, who know nothing about Andre the Giant, or the Princess Bride, or, you know, a really, really drunk Frenchman. So, Shepard Ferry is also interesting, because in the 2008 US presidential campaign, he created an iconic poster of Obama, that, you know, it's the red, white, and blue, very stylized, and it has hope underneath it. He was the subject of a lawsuit from the Associated Press in the US, because he had taken a photograph of Obama as the base of that. And it got into, you know, things about fair use, and all sorts of other copyright issues, because he didn't credit the original artist or the AP. But what he had done, he made something that was wholly distinct from the original subject matter. He stole that photograph, and he modified it, and owned it in a way that made it something much more iconic, and much more meaningful to a huge swath of people, right? I don't think it's exaggeration to say that that image codified a lot of what the Obama movement represented, and, you know, that's part of the reason why we had a change of administration in the dramatic way that we did. Of course, I'm not a historian, so I'm not going to talk about fine art anymore. I don't want to talk about literature and stories, though. If you look at mythology, stories are stolen time and again, and modified, right? So you look at Greek mythology, and you look at Roman mythology, which they took whole from Greek mythology, and just changed the names, and had the same stories. I think that that is sort of bad copying or bad stealing, because they didn't really make it their own, you know, the Emperor is still Zeus, Venus is still Aphrodite. But if you look sort of broader in mythology, you see elements stolen from one pantheon and one tradition all over the place. And some of that could be attributable to almost like patterns, right? So every culture has love and sex, and so every culture that has a pantheon has a god or goddess of love and sex, right? So you have Ishtar in the Near East, and then you have Aphrodite and Venus, and you have, what, Frey, I guess, in Norse mythology, or Frig, I'm not sure. But they pop up again and again, so you have to sort of decide between what is direct influence, right? So the Norse mythology probably doesn't draw much from Egyptian, because there wasn't a whole lot of interaction, and what comes from patterns, which is more like what that is, and we'll get more into that when we get to software development. If you look at the Lord of the Rings, right, Tolkien took a lot of existing material and incorporated it into his work. He also invented a lot of stuff, whole cloth, like the Elvish language. What I find interesting about the Lord of the Rings is not so much what he took beforehand, but how he's been used since. In middle school, in lower grades, I read just a metric ton of awful, awful fantasy, as I'm sure many of you did. And I read across this one author, his name is Dennis McCironan, and I don't fear to name him, but he is probably the most blatant Tolkien rip-off I've ever seen. He changed the name of the dwarves to something like the Dwarves, and basically the rest of it was the same. It was awful. But there have been numerous works in the, what, 60 years since Tolkien was writing, actually longer than that, that have used the same themes and told the same sort of stories, but in their own way, so they've stolen sort of the essence of Tolkien's work and made it their own, so it's something entirely new and entirely valuable. So in the US, there's a bit of a joke around Star Trek, where there are only, I don't know, 12 plots across the entire corpus of Star Trek, right? And so you can actually sort of see this. This is the top of a Star Trek plot generator flowchart. So to make up, if there had been another episode of the original series or another season, you could create the plot for any one of those episodes by starting at the top, so whilst investigating a form of energy never previously encountered, Bones falls in love when the Enterprise encounters an apparent duplicate of Abraham Lincoln, maybe, I don't know, which is in fact not what it seems, and you just continue reading down, and it ends up being a plot of Star Trek, and that probably should have happened, right? The idea is that there are only so many stories in the world, and this obviously is very popular in literature more broadly, there are, you know, Boy Meets Girl, Boy Liz's Girl, Boy Fine's Girl, and there are very distinct set of plots in the world that are just recycled over and over again. And recycling is a nice way of saying stealing, in this particular case. No, I love the new Doctor Who, but I kind of feel like the same thing is true. There are only so many Doctor Who plots. I mean, how many times can the Deluxe be resurrected? Its companion gets into Harry's situation in historical period. Yeah, that's like a third of the Doctor Who stories. So really recycling and stealing of pieces of literature is extremely prominent. And do you guys know, obviously you know Don Quixote. Do you know Pierre Menard? Anybody? So Jorge Luis Borges wrote a story, a short story, about it's called, I believe, The Life and Times of Pierre Menard, and it is about a man who wrote Don Quixote. It's actually word for word, Don Quixote, but it's a totally different story. So it's actually, it's this weird meta-stealing of Don Quixote to say something very meta-textual, as Borges often did with his stories. But it's as direct a lifting of the original source material as you can possibly get, and saying something completely different. So it's not like he's plagiarizing Cervantes. It's actually a new story that just because the framework around it has changed a little bit. OK, so that's enough literature. That's enough fine art. What I really want to talk about is software development, but first we're going to talk about music. So music, I think, is a really interesting case to look at because it gives us a framework for understanding stealing and software development. So I think there are three main ways you can steal things in music. The first is sampling. So you're actually directly lifting pieces of music and incorporating it into a new piece. And I think the current master is probably Girl Talk. This is an infographic of his song, What It's All About. There are 35 samples across four minutes of music, and it shows you where they start and begin. You can see the time signatures, right? And how they overlap. And what he's done is he's taken Queens We Will Rock You and later Bohemian Rhapsody, and he's laid them with DJ Funk and Phil Collins and Beyonce and Boogie Down Productions and all kinds of stuff, and he's made a unique piece of art entirely by stealing other people's work. And nobody cares because it's awesome. And it's clearly not copyright infringement because none of these appear by themselves except the very, very tail end of Bohemian Rhapsody. So that's the first way. You can actually lift something wholesale and use it. In software development, I think the most obvious version of this is when you use somebody else's library. You just take it in and you use it. Maybe you pay for it or whatever, or you're shelling out to a Python script from your Ruby application or whatever. You're clearly just taking there and using it as part of a larger application. And this might be a little controversial that I'm calling the stealing, but I think of influence. So Jimmy Hendrix is one of the most influential rock musicians of all time. The way he played music affected generations of musicians after him. And people aren't really stealing what he played. Nobody is stealing his lick to the Star Spangled Banner not to actually produce it, but they're taking the essence of what Hendrix's music was about and they're reapplying it to their own work. And we'll look more at stealing influence in a little bit as well. And then this is a statue of Eleanor Rigby in Liverpool. Eleanor Rigby is apparently the most covered song in history. There are somewhere between 60 and 200 covers of it. I got conflicting accounts. And I haven't listened to all of them. That would probably drive you insane. But what I can guarantee you is that a large number of them sound nothing like the original Beatles Eleanor Rigby. And probably a large number of them sound a lot like the Beatles original Eleanor Rigby. And I want to distinguish those into good covers and bad covers. Good covers are where you take the source material and you play it in your own style. Bad covers are those where you take the source material and you try to replicate the original style. When I was in high school, I worked in a movie theater. And one of my best friends at the time was into the punk scene. And he brought into work a double disc CD set of punk covers of Frank Sinatra, which was awesome. About 90% of it was awesome because it was like flying me to the moon with punk and things crashing and stuff. And then there was about 10% of it that was just awful because it was punk bands trying to sing Frank Crune like Frank Sinatra. So clearly there's a very important difference between doing something in your own style, covering it in a way that's true to you, stealing it and making it your own, versus just copying it. And with that, we can talk about software development. Hey, look, blinking lights. They're gone, which means I can go on to the next slide. OK, so I want to talk about patterns. And I want to talk about specific applications. I want to talk about specific tools. We'll start with X unit. We all know X unit. We're all familiar with test unit. X unit, and there might be people in this room who actually know the story. I'm sure there are people in this room who know the story way better than I do. But X unit started with Kent Beck, who on every small talk project, he would have the team write their own unit testing framework, and he kind of called it S unit. J unit was written by Kent Beck and Eric Gamma from the gang of four book, pair programming on a flight to somewhere. And they came out and J unit was fully formed as if Athena had sprung from their heads. And J unit is the thing that really caught the imagination of the testing community. It was ported to CPP unit for C++ by Michael Feathers, who's here, so find him and say thank you for CPP unit. It was also ported to N unit for .NET. Lapidary, did anybody here use Lapidary, Jim? I don't know. No. So Lapidary was the original test framework included in the Ruby Standard Library. It was superseded by Nathaniel Talbot's test unit. But they were both test unit, obviously, but Lapidary also was X unit influenced. And so what you've got here are several different ways of if we look at it in the music model of stealing, right? So S unit influenced J unit. S unit actually didn't have a single code base that was then ported or anything. It was just an influence. J unit to N unit, particularly version one, was a bad cover. If you look at N unit 1.0, there are methods in there that are only applicable to Java programs. They were ported. It's like they went through line by line and said, Java, C sharp, Java, C sharp, Java, C sharp. So you get things that are bad. N unit 2.0 actually was a complete rewrite, as I understand it, and had really good features that then made it back in. But you want to put a bad cover. CPP unit, I would argue, test unit, they're good covers in that they took the ideas of the X unit pattern and applied them more broadly to the relevant communities. And sampling, I doubt, happened because these are all across different languages. Though Lapidary might have gotten code in a test unit, I don't know, I'd have to ask Nathaniel, to give equal time to our behavior-driven friends. Look at BDD. BDD started as musings by Dan North. And then he started writing JBehave, which was a BDD framework for Java, obviously. Around the same time he started writing JBehave, Dave Astel started writing RBehave and Ruby, which eventually evolved into RSpec, which we all know and love. JBehave was ported to .NET for NBehave. PHP spec was written in response to RSpec. So you've actually got, if you draw out the genealogical tree, they sort of fork in different things, influenced different things. And then Jasmine breaks with the naming scheme, obviously. But it's behavior-driven development for JavaScript. But they all flow from their least influenced, if not ported, or covered from earlier behavior-driven development ideas. Near and dear to heart rails. CAKE PHP, when CAKE PHP came out, I thought it was a joke. Because it was essentially rails in PHP. And as soon as a new release of Rails would come out, three months later, CAKE PHP would have a new release. It was like clockwork. You could set your watch to it if you had a three month long watch. Since then, they have branched out, and I believe they're doing innovation on their own. They're no longer just following the Rails community. But that was the first of the Rails clones that I saw. Grails is a groovy on Grails, and Ruby on Rails are clearly very close. That's intentional. Rhino on Rails was written by Steve Yega at Google. It's a port of Rails to JavaScript. And then ASP.NET, I talked to a friend of mine who does .NET development. And I told him the title of my talking. He's like, oh, .NET steals everything from everyone. And ASP.NET, MVC is another example that they took. Because MVC, as launched by Rails, penetrated so many different web frameworks, ASP.NET brought some of those ideas back in for ASP.NET MVC, which is the dominant .NET framework at this point, as far as I know. Along the lines of .NET steals everything, the most popular ORM in .NET, as I understand, is in Hibernate, which is clearly just an N in front of Hibernate. And then they also have their own Active Record Port, which is called Subsonic. Both of these are very popular. And as far as I know, no native .NET ORM has become nearly as popular as any of these. So a lot of these so far have been what I would call covers. They're pretty direct ports of functionality. This is almost all influence. So the ModStar modules for Apache, we had ModPerl, ModPython, ModPHP. And for a long time, deployment was awful in Ruby because there was no equivalent. Who here deployed stuff before passenger in ModRails? Who here sent thank you emails to the Fusion guys when ModRails came out? Yeah, yeah. Or should have. Everybody. So what happened here is people complained loudly but never did anything to get a ModRails. And then the Fusion guys actually did it. They saw how, and I hesitate to say they saw it because it was really obvious how valuable it would be. They actually just had the time and the brainpower to build it. But they ported the idea of an Apache module that would make deployment so much easier, glossing over all the technical details, and built ModRails which eventually became faster, which is now a fundamental aspect of many people's deployment strategies. Now let's, with these next two examples of copying, I'm actually gonna show you code so you can see how they're similar and how they're different and some other interesting characteristics. We all know Whiskey, right? Yes, no? Maybe? Okay, there's a bright light over there. So if you're nodding over there, I can't see you. But I'll say this side says yes. Whiskey actually came from the servlet API. If you read PEP333 in Python, it's not written in Python, thankfully. But if you read PEP333, the author explicitly calls out, I like the servlet API because Java apps have a really clear way for application frameworks and servers to talk to each other. And in Python, we have nothing like that. So I propose this. I will call it Whiskey and see that it was good. And the Whiskey spec is actually a really neat read. I highly recommend. You'll see the URL to it in the slides later. But Whiskey was just a spec. It wasn't code, it wasn't executable. So in Python, they built paste, which is an implementation of Whiskey. Now, Rack, obviously we all know, was didn't come from paste, it came from Whiskey directly, right? So Christian, I guess, read the PEP and said, hey, that's a really good idea. Let's build that in Ruby. And so he built it and it's Rack. And then Rack got ported to JavaScript with Jack and then to Perl with Plack, which is an only Perl. We don't have our equivalent of Whiskey. We don't have a Whiskey or anything. But Plack does have a Piskey. So I guess they rewrote the spec first and then they implemented a Plack to it. And then Haskell has Hack and I'm sure there are many other Acqu words that are taken by other languages. I don't know if there's a NAC. I kind of hope there's not. But we've seen ports, right? So this is a code sample from the Whiskey spec. Can everybody see that in the back? Is it big enough? I can't make it bigger, so if not, then I'm sorry, but, yeah, right, so. Okay, so this looks a lot like, we're all familiar with Rack and we're gonna see an example of that in just a second. But it's very familiar, right? You define a method that takes environment, and in this case a start response, which is a little different than we're used to. And we're gonna return, we're gonna start response with the status and the headers, which we're used to. And we're gonna turn a string, right? And this is an innumerable string. An innumerable string. Hey, check out JetLag. All right, this is the implementation of Whiskey and Python. It's paced and it looks almost identical to that last slide, right? It just doesn't have the comment and it's collapsed some stuff. So instead of having variables for headers and status, it put them directly in. This is Rack, right? This is the simplest possible Rack. It takes environment and gives you back the status headers and string. This is plaque, which should look really familiar, right? So it doesn't have a named parameter, right? But it's shifting off the first argument into end and then returns status, headers, string. This is gonna get boring, because they're all the same. This one takes end and it returns status, headers, string. And hack, which looks different, but only because it's Haskell. So we've got the end. I can't actually read Haskell, so I'm gonna make my best guess because I know what this is doing, right? So end is the environment hash coming in and then we return, hey, it responds 200 headers and a packed string in this case. And I deleted some stuff like imports and whatnot around this just so you could get the very, clearly very, very similar. Now I do wanna jump back really quickly. If you look at paste and whiskey, right? They both have two arguments to the method. Start, response is the second one. But none of the others do, right? They all have just end. And that's because all of the others came from rack, not from whiskey, right? So whiskey was a good cover, rack was a good cover of whiskey. It changed it so that it better suited its community Ruby. But all of these others, I don't know if they're bad covers or not, but they're clearly following on from rack's example, not from whiskey's. And you can tell that by the name. We're gonna see more about naming in a minute, but you've got, okay, whiskey and paste. Those are unique. Rack, the first one that's kind, name that. And then everything else is named hack. Black, Jack, hack, whatever else. Sinatra, right? So Sinatra is near and dear to my heart. I love Sinatra. It's a great micro web framework. Code for that, right? So this is a very simple application. It responds to three, well, an infinite number of routes, but three routes, infinite number URLs, right? Homepage gives you a template, homepage. Names with a variable in the path gives you hello, whatever that name was, and then post login, processes login. So in JavaScript, this is express.js. It's JavaScript written specifically for Node.js. So this is a framework when you're using Node, you run this. And we're gonna use a middleware called BodyParser, which I probably should have deleted because it's kind of noise at this point, but it gives you something further down that I'll tell you. When you get the homepage, then you render out a template for the response.render, EJS template. Names, again, you have an in route variable with name, and we can get it out by request.param name. And then post login, and down here, data is in request.body, and that's what BodyParser gives you. It takes form encoded bodies and gives you access to them as parameters. So very similar. Ratpack is the groovy version, and I should never say the single version. This is groovy, a groovy version of Sinatra. There are actually others. Sinatra is one of the most copied frameworks as far as I can see. Everybody wants to write it because it's so simple and useful. So in groovy, you get homepage, you render out the template. Again, in route variable is orparams.name, and then prams.username or prams.password for the login. Ooh, PHP. Didn't think you'd see that here, I hope. I didn't think I'd see it here. But slim is a PHP version of Sinatra. Obviously, there's a lot more crap in here because it's PHP. You have to init an object, right? And then you're going down slim render. It has its own template viewer for homepage.php. Same in route variables for name. I should have come up with a catchy slogan for that, so I don't have to think about it every step of the way. And then login, and this is my favorite part. I'm gonna go over here in point because it's so much fun. So if you ever programmed PHP, then you know that PHP gives you a global post array, but slim has hidden that from you with slim, request, post, then the name, right? Which is awesome. But wait, it gets better. Nancy is Sinatra in .NET. So here we're using, for the homepage view, we're using the spark view template. We can return a concatenate string for your hello name and then data prams field. And I had to delete a lot of extra cruft in this file just to get it on the page, but the .Nancy has a lot of extra stuff going on, just so you know. And then this one's really interesting. It's sammy.js, so it's another JavaScript version, but it's different than Express. This is meant to be run client-side and it's actually built on top of jQuery to make it a little more concise. What this thing is, we wanna start in the same app and it's gonna point at the element on the page with id main. And when we get, it's using Ajax to fill in main with different things, right? So when we get the equivalent on homepage, we're gonna take a partial that is this file and stick it into main. And when we post to slash login, we're gonna take whatever form variables, we're gonna submit them out and then we're gonna validate and do whatever we need to. I didn't include the name example here because I'm not sure you can do in-route variables with sammy. If anybody knows, you can? Okay, well I could not find an example of that, so. It's experiment, ooh, exciting. Apparently it's experimental and therefore exciting. So it uses the new Ajax history stuff. Cool. So, now we've seen a lot of Sinatra clones. I wanna take a quick brief in-route to talk about naming. So we saw this with rack, right? They weren't all named versions of paste or whiskey, they were all named versions of rack, the ones that descended from it. Now, if you look at the Sinatra clones, we had, what do we have? We had rat pack, sammy.js, slim. We had, there's one called Fitzgerald, which is another PHP one. There's another one called limonade, but whatever. That doesn't really fit my model, so I'm gonna ignore it. Clearly, all of these programming communities are full of people who are inspired by music and really know the history of music and they're naming Sinatra clones after famous singers. And then you get to Scala. Does anyone know what the Scala clone of Sinatra is called? Scalatra. Scalatra, yes. So I don't wanna say that Scala programmers aren't as musical as the rest of them, but I think this speaks for itself, and I apologize to the person who knew that. So anyway, here's the example in Scala, and it's also very cut down from what the actual example is. There's a lot of ceremony cut out, but clearly another template engine, just a string, and then data's in prams field. Pretty simple. So now we've seen examples. You might be saying to yourself, hey, software thievery sounds like a good idea. Lots of people are doing it, why don't I steal something? So let's look at how to do it. I'm gonna teach you how to steal things. That's really, next outside there'll be a primer on breaking into cars. So I think there are two ways to go about stealing software. There's the knee-driven way, which we're gonna talk about first, where you're coding along in Ruby, and you run up against a brick wall, and you Google for a solution, you're like, I can't parse this parameter or whatever. I don't know. I never run into problems, so I don't have to steal things, but maybe you do, I don't know. You run into a problem, and after asking around and Googling, you can't find a good solution in Ruby. So you say, I bet other people have run into this problem. So maybe I'll look at Python to see what they did. So you say, I'm gonna look at Python, and you start Googling for Python, and you effectively case the joint. You work your way through the Python community until you find the solution, and then you investigate a solution, and then you steal it, which is the next part we're gonna get to after I show you the other way to go about it. The way I actually prefer is opportunity-driven. So this is where you say to yourself, I've heard a lot of stuff about Haskell. I bet it's a really cool language. I think I'm gonna learn it. So you go in and you start working with Haskell, and that's actually casing the joint at this point. So you picked your target, now you're casing it, and you're doing Hello World Haskell, right? Using hack, whatever. And then you wait for your chance. And by wait for your chance, I mean you watch it to say, when you say, holy shit, that's awesome, why doesn't Ruby have that? So the idea is that you involve yourself in a language, and you find the cool things they have, and then you steal them for yourself, and for the good of your larger community that we're all sitting with. So casing the joint appears in both of those, and it's probably the one that, hey, it's got a clever name, or not clever name. It's got a name that's not immediately descriptive, so let's look at that. Where do you look when you go to case the joint of Python? There are a couple ways. For almost any language, you can go to GitHub for Python specifically. You go to Bitbucket, and a couple of languages hanging on Bitbucket. SourceForge, if you're looking for old stuff, and Google Code, if you're looking for Python and Java and other languages that Google cares about, unlike Ruby, sadly. So these are great. The way I found all of the Sinatra examples, I typed Sinatra into GitHub, and then I filtered out all the Ruby examples. And wow, look, there's like 128 different results that I could pick from to show examples of. And it's remarkable. But you search for your problem in the other language, and you can see code on these places. Different languages also have specific places you can go to look. If you're stealing from Ruby, which stealing internally is fine, I guess that maybe not fine, but in Ruby it's fine. So you go to RubyGems, you can see what else people have written. For Python, I actually, I never was a fan of peps before I read the whiskey pep, and I'm like, holy crap, this is pretty cool. Maybe I should go read some other peps, maybe. PyPy is their equivalent of RubyGems. Obviously, if you wanna steal from Pearl, Cpan is the one and only place to go. And other languages generally will have similar repositories of solutions that you can go and look at and then later steal. But it's not always easy to tell what's a good thing to steal, right? So if you go to RubyGems and you search for something random, like I don't know, full text search, right? You're gonna get Sphinx back, which is awesome. You're gonna get, I don't know, solar back, which is pretty cool. You're gonna get index tank back, which is, you know, a service back search. You're gonna get ferret back, which maybe is not the best thing to be implementing in your Ruby app at this point. So how do you tell what are the good ones, right? And I've got a list of good flags in rough order from best to worst signals that this is gonna be a good thing to steal, right? So if you're looking at GitHub or Bitbucket and you see it has a ton of forks and watchers, it's a really active community and people care about it a lot. It's probably a good solution versus one that has no watchers and forks, particularly if it's been around for a while. If the repository's active versus nobody's committed to it for three years, maybe that's a single you want the active one. Edge case tests are interesting. Obviously you want a good test suite. Test suites are important. Edge cases only show up when people are using the software though. So if you have a lot of edge case tests, then you know a lot of people are using it because they're submitting bug reports. Same thing with issues, right? If the issue tracker is active and things are being closed, not just opened and ignored, then that's a really good sign that it's a good project to try to think about stealing. Citations is a relic from my days in academia. If the project is used in lots of other projects, that's another good sign, right? As opposed to if it just sits out there and nobody uses it for anything. Documentation isn't so much of a good flag that it's an important project to steal, but it will make it a lot easier to steal when you get around to actually perpetrating the client. So Python is great for this. Python has excellent documentation. And so it's much easier when you decide you wanna take like PIP, right? PIP and virtual and were stolen by the GitHub guys into WIP, right? And part of the reason that's so easy is because the documentation around is really good. If you can find a history of the thing you're thinking about stealing, that can also be really valuable, right? Cause you can follow it back up and say, okay, I found hack in my, I'm like in some, I'm in OCaml, right? And I found hack and I wanna implement hack in OCaml from Haskell. But then I follow this history back up and I can get all the way back to Whiskey and say, all right, I'm gonna steal from there instead of from hack directly, right? And then this one, do you guys know, okay, Cupid, the dating site? Talk about a change of gears, right? Okay, Cupid is a dating site, I guess it's mainly in the US. Okay, Cupid is mostly famous for having a crap ton of data about profiles and matches and dates and success and failure. And they do blog posts analyzing that data that are fascinating reading. And one of the things they found is you get way more dates. If you take two profile pictures, one's rated an average of a four and most of their ratings are around four. So pretty hot versus a profile picture that has a lot of fives and a lot of ones and twos. Also, and the average is still decently high, the profile picture where people disagree strongly gets way more dates than the one that is uniformly rated highly. So what happens is if people are having strong opinions around a particular tool, that's actually a really good reason to look more deeply into it. And I think we can look at this with RSpec, right? Or Hamel, right? Some people love Hamel, I hate Hamel, and maybe it's worthwhile looking for someone other than me, right? Okay, so those are the flags you should look at. Now let's actually perpetrate the crime, steal something, right? And first you need to be aware of trouble spots, right? So location, where is the code actually living? Is it in GitHub, is it in SVN, is it in SourceSafe, is it on SourceForge? Is in, you know, that can actually make it much harder to steal if you just can't get to the code. If it's in a completely different coding paradigm, if it's functional programming and you're trying to do it in logo, right? That's gonna be tricky. Actually, no, functional would go really well with logo. If it's object-oriented and you're trying to do it in logo, that would be hard. The idiom, different languages have different idioms. So if you're trying to steal from Perl, you need to get really good at reading one-liners, right? And same way for style, right? You can be thrown off by stylistic characteristics of the code you're trying to steal and port if you're not careful. So you need to be aware of all that. The more important thing, though, is how deeply you need to understand the code you're stealing from, right? And that depends on how you're trying to steal from it. So for inspiration, I don't think you need to have a very deep understanding of the original code at all, right? So J-behaved R-spec, R-spec wouldn't need to actually look at the original code base of J-behaved at all. It could just take, it's all actually whizgy to rack would be a better exemplary. You could read the spec and sort of understand the high level of what it's doing without caring about implementation at all to implement rack, right? If you're gonna sample, so Sinatra, Padrina was a framework that's written on top of Sinatra. It actually uses Sinatra as part of it. You need to understand more, but still not into the deepest depths because you're sort of living on the inputs and outputs of the underlying code. So you need to know it in sort of a black box way, but you don't need to delve into the depths. Now if you're doing a bad cover, like J-Unit to In Unit, clearly you're understanding the code at a line level because you're copying it and changing, you know, pluses to plus equals or something, whatever your language grammar is, differences. But you're not really understanding the spirit of the code. And that's where a good cover comes in. Because a good cover, when you understand what the code is actually trying to do, you can figure out how to best express it in your home community, where you're bringing it to, right? So, and that's sort of the high level and I wanna leave on a good note, right? So, as Rubyists, we can steal from everybody, right? Yes, we are the master thieves of the software development world. It's because our language is multi-paradigm, right? We can steal procedural code, we can steal object-oriented code, we can steal functional code, maybe not as well as any purely one of these languages could steal it, but we can do it. And with metaprogramming, right, we're more powerful than almost any other language, particularly one in high rotation and usage. So we can write DSLs to steal other kinds of code if we need to. But I think the most important piece of why we can steal from everyone is because we're so test focused. And really, I've sort of hinted at it, but when you're stealing code, the important thing is to understand how it works and tests give us an excellent way to do that, right? So if you have acceptance tests for WISGI, then you can write RAC to meet those acceptance tests, right? The acceptance tests don't care about the underlying framework. To a lesser extent, you can do that with integration tests or Selenium or anything. If you have that high level test suite, then you can make sure that your stolen goods are matching the spirit of the original code while still you can look at it and make sure that it matches the spirit of your community as well. So that's actually it, and we've got a good bit of time for questions. That's me, Bergl, I love the word Bergl. I don't know if it's an actual word, right? Is it, is Bergl, yes, it is, thank you. Yeah, I should know that. I'm gonna use it in Scrabble. Okay, so questions about stealing, that are not about stealing physical goods. So I swear I have no knowledge of that, yes? What's the best piece of software theft that I've seen? Being in the Ruby community, I'm gonna say it's RAC because it's the one that we own, right? So if you look at WISGI, WISGI clearly came first and the Surflit API came before WISGI and they did the same thing. But RAC dominated the Ruby community in such a way that it then spreads out and it affects everyone else, right? So clearly Python, and Python still has problems with the implementation of WISGI because the Jango framework doesn't support it fully in the way that all the others do, right? So it's a little different, whereas Rails and Merb and Ramaze and Camping Air Rails embraced RAC wholeheartedly, which made us, actually that single theft made us a markedly stronger community as a whole. And I don't think there's anything more you could ask for software than to bring the community as a whole together. Wow, that's like kumbaya, right? Yeah, yes. So Rails and Merb in the context of the student, wow, can you steal something when you're the owner of it and you go work on somebody else's project? I mean, that's a philosophical question, I guess. So certainly I would classify the Merb and Rails merger as mutual influence because Rails 3 was basically a rewrite and it encompassed concepts from both Rails and Merb. All right, so they're sort of overarching patterns of modularity and interchangeability from Merb, but the framework and the look of it remained very Rails-like, does that make sense? Yeah. Actually, I think design patterns are a really good example of theft as well, right? Because they're sort of theft at the highest level, right? I'm gonna go as abstract as I can and MVC is my pattern. And this is kind of what I was getting at with mythology, right? It's at a certain point it becomes unclear where something is stolen from something else or descended from or it's just implementing the same underlying idea independently. So it's like convergent versus divergent evolution. So sharks and dolphins look the same mostly but they evolve through separate paths and they just converge on the same form factor. Other quick, yes. Okay, so are there times where it's not worth stealing where you should just use the original and so basically shell out to the Python script that does what you want? Yeah, for instance, right? Yes, absolutely. Stealing is not a no cost affair, right? There's always gonna be time lost to the porting and to understanding the original code and if it's just a utility that does what you need it to, go ahead and use it. If it's a core part of your business, I would recommend that you actually internalize it at that point, right? So image magic would be a really good example. Image magic is not written in Ruby. There are actually really good reasons image magic is not written in Ruby. One could debate that there are really good reasons image magic not to be written in its current form but that's another issue entirely, right? Different languages are good for different things. You can do anything in one trying to complete language that you can do in another but that doesn't mean you should, right? So it's always gonna be a cost-benefit analysis. Anyone else? Yes, profitable? Okay, so the question is burglaring from open source versus burglaring from closed source or businesses or people who are standing to make a buck. Right, so that I actually don't have a problem with, right? For a brief time in my career I worked with .NET and .NET had this practice that I imagine they still do of selling software components, right? So you need your cool data control for your webpage and you buy it for $500 for a license. I'm like, that's ridiculous, right? I can just build that and maybe it takes a long time to build but yeah. At that point you're relying solely on sort of the acceptance level testing knowing the inputs and outputs and you don't care about what's in the middle, right? So I'm a huge fan of that. Okay, so patent infringement, yeah, that would be a... Yeah, and patents have gotten weird as people start patenting processes. So like Amazon's one quick purchase patent. Yeah, I could build that really easy but I can't because it's illegal and at that point you have to ask the lawyers. Yeah, I mean there's, I think that those sorts of patents are bad but I have no power, so yeah. Sure, right. Yeah, so clearly the patent system is arcane and not conducive to finding out what's already been patented. Particularly when the language around patents is so impenetrable, right? You look at the one quick patent, it doesn't say one quick patent, it says something ridiculous like all of Apple's patents do. I don't know. I don't know how you find out what's patented until you get sued but if you're succeeding so wildly that you're getting sued then hopefully you have money to pay the lawyers or to rearchitect that piece of your system. Actually, this leads me to another really related point though. You hear a lot in business and startups about ideas versus execution and copying of ideas. I think as developers we don't care so much about the copy and you feel free to copy my idea, it's the execution that matters, right? And I think that's generally true for everything I talked about here as well as in the startup role, right? So you can have a billion clones of Groupon or Amazon or Etsy or anything, it's the execution that matters, right? Anyone else? Then let's go eat or burgle something but mostly eat.