The Changelog: Software Development, Open Source - Cylon.js, Gobot, Artoo, IoT (Interview)

Episode Date: October 10, 2015

Ron Evans, ringleader of The Hybrid Group and creator of a fleet of open source robot libraries, joined the show to talk about open source and robotics, Cylon.js, Gobot, Artoo, teaching, KidsRuby, his programming hero, and more.

Welcome back everyone, this is the Change Log and I'm your host Adam Stachowiak. This is episode 177 and today Jared and I are joined by Ron Evans and Ron is the ringleader of the hybrid group and creator of a fleet of open source robot libraries, CylonJS, GoBot, R2, and we had a blast having Ron on the show today. We had four awesome sponsors for this show, Codeship, OpBeat, Harvest, and Imagix. Our first sponsor of the show is code ship they're your hosted continuous delivery service focusing on speed security and customizability you can easily set up continuous integration for your application in just a few steps and automatically deploy your code when your tests pass now code ship has great support for lots of languages test frameworks and

notification services and they even integrate with github Bitbucket, and you can deploy to cloud services or even your own servers. Get started today with their free plan. When you upgrade to a premium plan, use the code THECHANGELOCKPODCAST and save 20% off any plan you choose for three months. Head to codeship.com slash thechangelock to get started, and now on to thehip.com slash the change law to get started and now on to the show all right everyone we're back we have ron evans here with us ron is from the hybrid group we met jerry we met ron where where we meet him at well i met him a couple years ago at ng conf the original goes back further yeah and i remember at the time I said, we've got to get you on the changelog. That's right.

And, you know, it's only two years later. But we got you on. And then we saw him again, and you met him at GopherCon, which is kind of a running theme this fall. Yes. Because a lot of people that we met at GopherCon on the show. But, Ron, it's really nice having you. Thanks for joining us.

Hey, guys. Thanks for inviting me. At long last. It's been a long time coming. Yes, it has been. And yeah, it's funny at GopherCon, the first GopherCon, actually, I saw a lot of people I hadn't seen in a long time from various other open source communities and Go really brought them all together. And the second one most recently, same thing, but just even more magnified. So kudos to the organizers and also very interesting quality

to the Go programming world that it's attracted people that, a bunch of old hands and a bunch of cool people who are doing new things and, you know, just lots of enthusiasm. Absolutely. So you're the ringleader of the hybrid group and the creator of what I'll just call, I guess, a fleet of open source robot libraries.

Why don't you go ahead and let us know a little bit about the hybrid group, what it is and what you do there. Sure. So we're a software development consultancy based here in Los Angeles. And we've been called the software company that makes hardware companies look good. We've done software for a bunch of hardware companies such as Pebble, Sphero. We've worked on a bunch of robotic programming work for them. Particle, the wireless microcontroller company, formerly known as Spark.

Oh, yeah. And Intel and a bunch of others. So we've been fortunate to have a lot of real-world experience with programming all of the software around various physical real-world devices. And so we've taken that knowledge, you know, some people may call it mistakes, lessons learned, you know, it would be the euphemism. We've kind of solidified a lot of that into a series of open source frameworks that basically all do the exact same thing in three different programming languages, but with the same set of core design patterns. In JavaScript, it's called Cylon.js. In Ruby, we call it R2, Ruby on robots.

And then in the Go programming language, we call it GoBot. But they all have the same core set of design patterns underneath, but then implemented idiomatically in each of the different programming languages in a way that programmers in those languages would expect. So, for example, if you're programming in JavaScript, it's all callbacks and asynchronous calls. If we've really said, here's a core set of patterns for developing physical systems. How could we then implement those and provide a set of libraries that work together in the form of a framework

so that developers can much more easily program the physical world the same way as right now web developers program websites. Yeah. You know, we really see when we say think outside the box, you know, we're not just speaking metaphorically. We literally mean, you know, out here in the real world where stuff happens and it's all very analog and it's you know so there's a lot of interesting people who've been working on these sort of things as well and have been contributing um you know when when i saw you guys last at gopher con we were just holding the um hardware hack day with a bunch of really awesome hardware donated by our friends at Intel.

Intel has been really, really supportive of the work that we've been doing in open source. They actually are doing a lot of cool open source work themselves. But we had this massively successful hardware hack day with, I mean, I don't know how many people. I think there was over 100 people there. I lost count at some point just because we basically lost control of the registration. I mean, it was great. It was fantastic. But we ran out of hardware. Yeah, I mean, I remember I didn't know you had to register. So we were walking around shooting B-roll and talking to people.

And I was like, oh, hop in here and and participate and i hopped in and it was like there's no hardware left dude it's it's uh it's uh you missed the you missed the ship we got some good footage in that room too with um i'm not sure what they were doing but they were doing something with um where you can see gestures and hand motions? Yes, that was using... We've done a lot of work with Leap Motion, the gestural controller company, and so we have a whole box full of controllers that we bring with us to various hackathons

and hack sessions and workshops and kids programming things, for no apparent reason, just because they're really cool. No wires, just wave your hands around. I wave my hands all the time and nothing happens. I'm waving my hands and now something's actually happening. See, I knew it. That was exactly it.

You could see the person's hands on the screen, and they were doing different things and interacting and stuff. It was pretty interesting. Yeah, we've actually had really good support for the Leap Motion since they first shipped their 1.0 SDK and it's improved quite a lot since then. They have a bone API

that actually lets you track the different digits within your hands. So the sensitivity is quite a lot better than it ever was in the past and you can do some really really cool things I've seen some really awesome demos that were done in particular my favorite ones were actually done by Charlie Gerard she's a developer down under who's done a bunch of cool things with CylonJS and Leap Motion and Sphero and AR Drone. Her demos are always really, really fun, and she's written a couple of blog posts

about them. So I find that kind of thing really fascinating to see how other people look at the stuff that we've made and think of interesting ways to use it. It's far more interesting than the stuff that we do, at least as far as me personally. I'd much rather hear somebody play my song than to just play it again myself. We definitely want to talk to you about some of the guts and the internals and the way that these three libraries work and maybe dive into that.

But before we do that, I would like to get your take on the robotics industry at large. You mentioned Particle, and we did have Zach, is it Sopala, from Spark on back in April. I didn't even realize they had renamed. So Adam and I are kind of outside our proverbial comfort zone when it comes to some of these things. We aren't exposed into the hardware community as much as you are.

One thing that you and I discussed briefly at Go4Con, and what I'd like you to elaborate on now, is the interplay between open source and closed source amongst the robotics companies, the big players that probably our listeners have heard of and that I know of. Some of them seem to be all about open source. Some of them seem to be completely closed source.

Can you lay out the landscape for us so we can understand how robotics companies think about open source? Sure. The drone industry is one really well-known niche within robotics that has gotten a lot more attention, you know, in the last, you know, year or two in particular. So there's three companies that have been doing extremely well by selling drones to the public.

The first one is DJI. So DJI, many people have called them the Apple of drones. Their software is entirely closed source. You cannot get any information about their SDKs unless you register with their developer program. You cannot distribute any software for their platform without going through their official distribution mechanism. So it's, you know, there are a lot of parallels. And also, they're well known for having a really great consumer out-of-box experience for people. So, you know, they would be at the very closed end of the spectrum.

The opposite end of the spectrum would be 3D Robotics, which is Chris Anderson's company. 3D Robotics is completely open. Their hardware is completely open source hardware, where they publish the schematics and part listings and bill of materials. In fact, the history of the company, in brief, they were selling a different autopilot that was based on the Arduino. And another company started working on a single board Linux called the Pixhawk. And they took a look at that. It was basically, if you can make the hardware better than we can, we want to buy your company. So they basically did exactly that, adopted the Pixhawk as their official technology. Again, still all open source hardware.

So it's a really classic case of a virtuous circle working. The software, likewise, all the APIs for the autopilots are all based on an open source protocol called MavLink, which is supported by a few hundred different unmanned aerial vehicles, unmanned ground vehicles, unmanned submersibles, and other things that probably defy description. So they're the opposite end of the spectrum, complete openness, and they've been doing extremely well, in particular agricultural applications that are being built. I mean, there's a whole ecosystem which has been forming around that for a long time, and now it's not just open source cool projects, but it's also commercial projects that some of them are fairly substantially funded, you know, and they're doing fairly substantial important things as far as work in, you know, disaster recovery, bringing medications to remote villages at consistent temperatures, you know, especially for antiretroviral medications, which are highly temperature sensitive and quite costly,

agricultural applications of all different kinds. So there's a lot of really exciting work that's happening, and it's not under anybody's control. It's all just already happening. So that would be the completely open middle side. So in the middle would be Parrot, I think, would be a great example. The AR drone. With the AR drone, best-selling drone ever in history. So in the middle would be Parrot, I think, would be a great example. The AR drone. With the AR drone, best-selling drone ever in history.

I've heard different stats, but it's certainly at least 250,000 AR drone 1 and AR drone 2s that have been sold. So the AR drone uses open source under the hood. So does the Bebop, and so does their other drones that they're currently selling. They're running a busy box Linux distro. But their firmware is not open source. In fact, it's all closed source. But their firmware is not open source, in fact. It's all closed source. But their APIs are all public.

They don't require any licensing. They're not stopping anybody. So we might think of them as sort of the semi-open or not closed, depending if you're like a half-empty or half-full kind of person. Yeah. You know, the point being that it's been all sorts of really awesome things that have been created despite, you know, Richard Stallman's lack of complete openness,

and yet there's a whole ecosystem of awesomely fun, cool, free and open-source projects like NodeCopter, you know, that have been created around this stuff so and they've sold a lot of hardware as well they've been very financially successful so three different strategies for how to use open source in the same sector aka drones and yet each of them completely viable in their own way so So it's really, really interesting, because, you know, sorry for the extremists out there, you know, you were expecting a simple answer.

Of course, the answer is, it depends. Reality is always a bummer for the purists out there, right? Yeah, I guess. You know, I'm a purist deep down inside somewhere. Yeah, it's the fight between the romantic purism and the pragmatism that tends to take over most of my time

as I argue with myself about which one is the right way. Somebody has to pay for something somewhere at some point or else the whole thing comes to a screeching halt, especially open source hardware. You need some actual hardware, and you burn up parts, you brick things while experimenting with them. They crash in a very literal sense, like from the air to the ground,

in a way that was faster than anticipated or in an angle that was generally you know, generally bad for the thing, you know, in a permanent way. You know, so the, you know, the need for companies to support open source and not just sort of coast off of it. And, you know, that's why it's great to see, like, I'm glad Zach from Particle, you know, they're a great example of a company that's doing a lot of things right, you know, sharing a lot of the work that they've done, writhing off of a lot of open source, and at the same time, you know, with a good solid value that they provide to other people so that, you know, they can actually make some money and still be around for a while because, you know, if they're like, oh, what happened to that awesome company? Oh, yeah, they died.

It was really sad. You know, like, oh, that's terrible. You know, I've seen a bunch of Kickstarters, not to pick on crowdsourced companies, not at all. Quite the opposite, really. I feel for a bunch of these companies that I get my weekly Kickstarter apology emails. Oh, I know. And behind each one of them is a horribly tormented person that's just feeling all this pain and disappointment. Like, no, that never went down.

I couldn't do this thing. Not to mention all these people kind of hating on them. Like, hey, I thought I pre-ordered my awesome gadget. You know, like, wait, no, you actually were betting that we might be able to successfully deliver it. And, you know, so there's a bunch of companies that they didn't survive to ship. And then there's a few companies that they survived to ship. And that effort literally killed them like okay we shipped and like i'm quitting technology and now going far away from far away from radio signals you know goodbye all you know and i i really feel sorry for these people because i think wow you know you did not realize you literally did not realize how bad things were going to be until you got into it.

Then, of course, it was so much worse than you thought and all these people were expecting. That's where perhaps a better model for a lot of companies might be on the one hand, just make some. Just a handful. Then sell them on Tindy or something. You got it off your chest and this way you

weren't on the hook for the excessive popularity that may be good and may be bad depending on whether you could actually you know shipping 50 of a thing might be enough to nearly kill you shipping 5 000 might be enough to you know you lose all your hair and you lose all your love for technology and, you know, of course you lose all your money. You know, that was sort of a given because you're like, oh yeah, we're going to be able to ship anytime. Well, you also can lose your reputation because now you're somebody who can't actually come through and you've let down a lot of people, which feels bad, but it harms your chances

next time around of having, you know, people supporting your ideas and your efforts, which feels bad, but it harms your chances next time around of having people supporting your ideas and your efforts, which is difficult, too. Yeah, and I think if it was a little bit more spelled out to the buyer. Yeah. Sorry, let me rephrase that. Sorry. It's clearly spelled out to the buyer, but if people didn't interpret it the way that they're pre-ordering a thing as opposed to their sort of

investing in the potential of a dream. They're giving somebody a chance to do an experiment. I wish people looked at it that way because if it was a little less high stakes... I think that's a two-edged sword though. I think

specific to some Kickstarters, they actually pitch it as if they're gonna get it like they show the demo they like they do hype some dreams up because they because they do have to actually you know collect some money to make it happen so they do have to sell a little bit right you know so sometimes they can be not purposefully but in a way misleading because you think well i'm gonna fund this today and in a year from now, just like they said, everything's going to go perfectly, so I'm expecting this thing. And then snag one, snag two, snag three later, it's three years out,

and you're like, well, I'm never going to get this thing. Yeah, exactly. If it all just quietly go away, as you said, that would be nice for the original people. Of it doesn't it's the internet nothing goes away ever in some cases too that gap right that in some cases when you don't ship the technology has been replaced by apple pay i'm thinking for example um this one card that was like smart i can't remember the name of it right now. Coin.

Coin, yep. So I'm a good example of that. I actually bought that thinking like, heck yeah, man, I want that. I got myself one, I got my wife one, and I was like, this is going to be awesome. And then between the time they were deep in their tech and deep in their R&D, they got sideswiped by the bigger people,

which became a much bigger play for Square, Apple, Android. They all have their payments platform. Well, the NFC chip was already in the Android phones. Literally, it was just deploying iPhones with that chip, and all of a sudden, all the software was ready. Yeah. So it's a classic case of if you only have a feature, then you probably don't have a company.

If you have a full product, you know, that's a whole other story. But there's a lot of, you know, the interesting thing is that there are companies and individuals who now have some experience with these things, and they're a lot more readily able to successfully help you navigate that space. And we work with one in particular called Highway One, which is an accelerator based in San Francisco. So Highway One, they've been responsible for some really cool companies like Navdy and Julie Bots, which is a really cool programmable jewelry for young girls. So there's some really fantastic things that come out of these,

you know, of an accelerator because they help you navigate, you know, in their particular case, they're, it's specific to hardware companies. So these companies, you know, they're able to come in to a program where they have access to mentors of different sorts, hardware, software, et cetera, helping them navigate the process of getting to a thing, only once they've gotten through that whole program, only then should they really think about doing the crowdsourcing. Premature crowdsourcing doesn't really lead to success, either just because you fail because it's so damn hard to succeed.

There's so many things that can go wrong. Or, you know, you, hey, this is, you know, the new, you know, square. I've reinvented the wheel. You know, when I was a little kid, reinventing the wheel was a pejorative. It was like, it was considered a bad thing. Like, oh, you reinvented the wheel.

Nowadays, like, you've reinvented the wheel. Nowadays, like, you reinvented the wheel? I want to invest. You know, how do I get in? But the problem is, of course, is, you know, your wheels turned out to be square and made of wood. And there was a good reason why the industry had standardized on rubber and round. And, you know know you and your amazing hubris and success of the cool video that got your crowdfunding you know everyone's like

yeah the square wheels and then you ship the first few square wheels and people are like you know these wheels suck you people are idiots and you're like oh you know i know this sounds when we're talking about square wheels it sounds like it's's obvious, but it's obviously a lot more subtle. So the fact that there are some successes and failures we can all go take a look at now and say, all right, this worked and this didn't. One of the things that's a common characteristic of successes is they did as little as possible. And what I mean by that specifically is they used open source well whether it was open source hardware platforms like the Particle whether it's open source software of different kinds they did as little as possible to actually get to

some kind of demonstrable product ideally a shippable one even if it was just a 1.0 version because if you spend all the time going off and doing all this work or starting your own hey we're going to open source it that's not a panacea either you know just saying okay we're going to slap it on github and make it a public repository does not an open source project make right in fact quite the opposite they're like wait you're running your company on this code? Oh my god, I can't, like, first of all

the hackers have a field day, not that they couldn't already just with Metasploit and other scanners, right? You know, you've already got a whole world of hurt that can come in. You know, I don't consider open sourcing your code to be significantly

exposing your attack surface. But it does significantly expose your incompetence if you fail to do it well. Yeah, that's true. And the opposite. We've seen individuals, really, really smart people, come sort of humbly doing a cool thing that quietly solves know, quietly like solves a real problem. You know, I'm talking about Mitch Hashimoto right now, actually. So Mitch, I've known Mitch for a long time. His company, HashiCorp, they're the people originally, you know,

who now have Otto most recently. So I've known Mitchell for a really long time. We worked together on a bunch of things way, way, way back in the day. So he actually was a consultant at a consultancy based here in Los Angeles called Citrus Byte. And Citrus Byte has had a lot of really interesting people who passed through there just because Los Angeles not being known for as a major tech company you know location for a long time you know so a lot of interesting people sort of have passed through similar fashion the hybrid group you know so

anyway so Mitchell you know came up with Vagrant just worked on it very humbly super smart guy solving a real problem doing this thing. Lots of people paying attention. Suddenly, all of a sudden, you know, boom, overnight success years in the making. And oh, yeah, all built on top of open source. And oh, yeah, all built on top of really good open source. That's why people used it was because they looked at the source and they said, this is actually good code that's solving a real problem. And I can improve on it and

you know so i'm not at all surprised at the success that they're experiencing right now because it was earned it was earned over a long period of time it's not just like a sudden you know boom out of nowhere nothing like that speaking of auto adam you might want to tease our upcoming show with mitch yeah we actually have an upcoming show with Mitch. So we saw Otto as well. We've been fans of Vagrant around here for a long time. So when we saw Otto, we were pretty excited about just seeing, you know, their constant chipping away at this problem.

So even if it supersedes Vagrant or not, it's still pretty interesting. Oh, that's really funny. Hey, Mitch. How you doing? Upcoming show with Mitch. I say hello to your future self from the past here. And while we're doing it, let's go ahead and take a break and pay some bills, have a sponsor come in and tell some awesome stuff.

One way you can support us is by supporting our sponsors. So have a listen. If it intrigues you, check it out. We'll be right back. Guess what, everyone? Opbeat is announcing their Node.js beta right here, right now, exclusively to our listeners. Opbeat combines performance metrics, release tracking, and error logging into a single, simple service. And with all of your data in the same place, they're able to do smart things with it and help you make wiser choices. Opbeat integrates with your code base through Git and makes monitoring and debugging your

production apps much faster. It's free for an unlimited number of users and until now has only been available for Django and Flask, but now they're launching a private beta for Node.js and sharing it with our listeners first. So go check it out and sign up for the beta. Head to opbeat.com slash changelog. That's O-P-B-E-A-T dot com slash changelog. All right, we're back with Ron Evans. Ron, the self-professed ringleader of the Hybrid Group. You guys are doing some really interesting things.

Some questions Jared and I have are the three different projects you have, they're in three different languages. You've got SilentJS, GoBot, and R2. So why three different projects and why three different languages? Well, every programming language does something really well. Or else nobody would use it at all, of course. But the adherence of that language would often proclaim its superiority in all things, as opposed to, you know, genuinely being curious about,

hmm, why is somebody using that other language, the one that I don't use myself? You know, what's so good about that? You know, and it falls into these kind of religious debates and wars much of the time, unfortunately, just because of this sort of technological tribalism. The cool thing about the early days of language communities is they're usually the polyglots, you know, the people who are, you know, genuinely curious at learning as many programming languages as possible, just to try to grok, you know, exactly what is it about this that's so cool? Because somebody must like this thing.

I mean, there's a bunch of people using it. Let me understand what that thing is, because it could be good for my brain to expand my own sort of thinking. But at the same time, each language, you know, community also has a human side to it, which is sort of the flavor of how, you know, Ruby, it's a very test-oriented type of culture. If you're talking to a bunch of Ruby programmers and you show them your Ruby code and there's, you know, no tests, they'll say in mock horror, oh my goodness, you have no tests. Let's sit down and write some tests together. We'll get your code tested.

If you're a Python programmer and you don't have any documentation that's auto-generated, they'll be like, oh my goodness, you need some documentation. Let's sit down, we'll help you write some docs. You know, that's just a characteristic. You know, the JavaScript community is a little different. It's more trailblazers. Like, let's just, you know, blaze a trail and, you know, if you could follow that trail after me, and, you know, good, that's great. But, you know, I'm sorry, I moved on to a new trail.

You know, so it's more exploratory, not necessarily worrying about keeping up with what's already been done. The Go community, on the other hand, being a very new community of very hardcore programmers from other disciplines, has a certain newness to it, we don't know what it's going to turn into eventually. But one thing is that the discipline that it enforces has brought a really interesting group of people together. So each one of our frameworks, you know, takes advantage of the strengths of the particular community, as well as the particular language and tools around it. You know, Cylon.js has a.js has more hardware support than the other frameworks because there's a lot of people doing cool hardware hacking over in the JavaScript world.

You know, from the stuff that all of the spinoffs of Node Serial Port, which was Chris Williams' project, you know, to all the stuff that's going on through Johnny Five, which is Rick Waldron's project, to all the stuff going on with NodeCopter, with the Tessel, which is a JavaScript-powered microcontroller, with all the stuff that Intel has done, with all of the stuff that Marvell's new JavaScript-powered microcontroller with Samsung, with I think it's called JimmyJS or something, Johnny, I forget. Anyway, they have a new stripped-down JavaScript runtime specifically to run on their Arctic line of microcontrollers

and single-board Linux computers. So there's a lot of people doing hardware hacking in the JavaScript world. So, of course, we have more support for more pieces of hardware there because our framework, it's all about the design patterns that we apply. And if there's already a library that talks to a particular piece of hardware, we'd much rather be using that, especially if we can be using a library that is also being used by other subcultures within the JavaScript world. Because JavaScript is very, very tribal within itself, case in point being the Node.js and IO.js schism and subsequent reunification, much to all of their credit.

Cooler heads prevailing, which I'm not a member of either one of those communities directly, per se, so I'm happy to see them getting together. I'm kind of doing my own thing, and I have been, as far as sort of pursuing the design patterns around physical computing, really it started in 2008 with something in Ruby called Ruby Arduino Development. That was a project from Greg Bornstein, who ended up going back to grad school

at NYU's Interactive Technology Program, which is where Massimo Pansi, the creator of the Arduino, is one of the professors. Really amazing place. So the work that we've done, you know, first it started with R2, just because it was natural in Ruby. It was really about creating frameworks that supported multiple different hardware platforms, even all at the same time. It was about using the adapter patterns in order to communicate with all sorts of different categories of devices. And it was really about identifying interfaces to talking to whole categories of devices.

And how can we do interface-based programming in Ruby? Well, there is nothing in the language that enforces interfaces. And in JavaScript, well, there's nothing in the language that enforces interfaces. It doesn't mean you can't do it. You can absolutely do it. But you do it through customs. We agree that when we both come to the door at the same time, that one of us is going to stop and let the other one go through first.

But there's no rule. There's no traffic cop. There's no camera. There's no buddy enforcing this custom. So in dynamic languages, interface-based programming is something that's enforced by custom and not by rule. In GoBot, on the other hand, because GoBot is able to utilize Go, Go is all about interface-based programming. And by defining certain categories of interfaces, the implementations of which could talk to completely different hardware platforms. It could be talking to a BeagleBone Black, it could be talking to a Raspberry Pi, it could be talking to an Intel Edison.

With a minimum of changing of code, this is a really, really powerful paradigm for programming of the physical world. And so, you know, each one of the frameworks takes advantage of each of the language's capabilities and also the community behind it. You know, Go has a really, you know, rapidly growing and really active community, and they're really interested in hardware hacking. JavaScript people, they've been interested in hardware hacking for a long time, and, you know, the NodeBots community and NodeCopter and, you know, a bunch of some of these communities, you know, consider themselves competitive to Cylon.js.

You know, we don't consider ourselves competitive. We're more just sort of like, hey, we have our band, and we're playing our music. You know, we hope you like it. You know, you have a band too? That's really cool. We'd like to hear it. You know, your band's music doesn't mean anything towards our band's music, We hope you like it. You have a band too? That's really cool. We'd like to hear it.

Your band's music doesn't mean anything towards our band's music, nor vice versa. Hey, let's have a music festival. That's sort of the jamming and code attitude that I've tried to have, and certainly Hybrid Group is also, and lots of other people too. That's an interesting perspective to take it from like, hey, you've got your band, I've got my band, we play our songs, you play your songs, kind of approach towards what you said earlier, much earlier, which was reinventing the wheel to a degree,

which is why we said why three different projects, three different languages, essentially you recreated the wheel for each camp, right? Well, the way it sort of played out, Ruby is a great way to learn ideas and to play with ideas. We've seen a lot of interesting new concepts come from the Ruby world. A really good example would be Sinatra. You know, the Sinatra pattern for, you know, developing web mini applications has been adopted widely, you know, Express.js, Flask in Python, Noir, Enclosure, Martini, and a couple of other ones in Go.

I mean, there's a lot of people who use Express.js who have no idea that Express took every one of its ideas in whole cloth from Sinatra. And TJ, who wrote Express, never tried to hide that. Quite the opposite. TJ's biggest contribution to the Node world was he could look at Ruby jams that did the thing and rewrite them in Node really quickly. That was a huge contribution because it really accelerated. But a lot of people in the Node world had no idea where that stuff originally came from, which is funny. But the

reason why they didn't use Ruby was because Ruby was great for ideas, but ultimately, Ruby's virtual machine is its weak spot. It's its undoing. The kinds of applications that people want to write increasingly involve some ways to deal with concurrency. And, you know, JRuby is a great project, fantastic project. Amazing what those guys have done. You know, its strength is the JVM and its weakness is the JVM. Like if you're committed to the JVM, then JRuby is for you. It's absolutely fantastic. But if you weren't thinking of using the JVM or, youM or you intentionally weren't using it because you're running on really small or underpowered hardware, single board Linux computers in our case, it's not really something you could take seriously. You're trying to go the other way. How much can I get rid of? You know, Rubinius, cool project, but splintering off of the main Ruby implementation, you know, there was already problems with fragmentation.

I mean, look what happened with Node and IOJS, which finally pragmatists there said, you know, we better get back together before something bad happens and we lose all of our collective momentum around this thing. You know, Java's Node is a hack, all right? It's a hack. Language purists, concurrency purists can, you know, get into the details about, you know, but ultimately it's a hack that we all need it because it solved the biggest problem that most programmers have these days, which is not the general case of concurrency, but it's really just about blocking I.O. You know, if you're writing programs for the web, your biggest problem is blocking I.O. because, you know, you've got requests,

you have to go off and, you know, do something and then respond. So if you're writing applications that are talking to physical devices, your biggest problem is blocking I.O. You are waiting for the servo to move to the stepping motor to a particular position so you can then do something with this other motor. So, I mean, you're waiting for I.O. that a lot of people who are Node programmers found out, hey, Node is actually really cool for device programming only because the hack that they put in is the hack that we needed. You know, it doesn't solve the general concurrency case.

Go, on the other hand, was designed by very serious people who had spent a long time not succeeding, you know, and figuring out, okay, this is going to work and this is not. And over that long period of time, really synthesizing down some more fundamental solutions to the concurrency problem at large. And so we could take advantage of that in GoBot to do device programming. You know, that's something that most people in Go hadn't really thought about. But once they start to think about it, wow, this is a great way to do the kind of

concurrent programming that you need if you're going to program robotics or internet-connected devices or drones or these other things. In fact, wow, it's a multi-architecture, so I can cross-compile it, so I can compile it on my computer and SCP the file over to the drone to execute it. There's a bunch of advantages to developing code using Go, which translate very directly to the kinds of problems that device programmers, now not necessarily the ones who are programming on microcontrollers, but that's, you know, again, that's a false argument. Oh, well, Go doesn't run on Arduino, so you can't use it. Well, that is sort of saying

you're going to develop all of your complete internet-connected application using nothing but microcontrollers? There's just no way. They're too underpowered. On the other hand, you can't do it all with single-board Linux computers either because they're too expensive. You know, for these small, cheap sensors that need to be deployed en masse to all these different places to do all these different things. Well, the answer is a heterogeneous architecture you know you've got microcontrollers which are connected possibly through wi-fi possibly through bluetooth or bluetooth low energy you know particle has got a great option there and you're talking to some type

of hub you know some type of single board lin computer, you know, whether that's a Raspberry Pi or a BeagleBone Black or the far more powerful Intel Edison, you know. So now you've got a complete suite of different possible solutions to bring to bear to the problem so you can push as much intelligence to the edge as possible. That way, if the internet goes down, you know, your home security system doesn't lose all capabilities or what have you. You know, your home agricultural system no longer works. And so, you know, your crop dies or, you know, your industrial processing plant no longer has the ability to get, you know, external data. So, of course, it shuts down and, you know and you have a fire or something. I mean, the Internet of Things needs to be about the Internet of Things and not the AOL of Things. And that's

where open standards and open source are so important. So each one of these communities, you know, the Ruby world is more about learning how robotics work. I don't see a large adoption in Ruby as far as getting excited about device-level programming for various reasons. The JavaScript world is very excited about it and is pursuing all sorts of different avenues, and that's the most popular of our frameworks. But GoBot is coming up very quickly in popularity um it's in one it's in the 99.9 percentile of github stars uh for go lang projects you know and that's competing against you know docker and core os and everything i mean we're at the bottom of the top okay make no mistake the very bottom like last

one's in you know last lot but um well that kind of leads me into my question was you got these three you know let's take your band analogy you've got these three songs that you've written and if you had to take one of them and and you had to pick a single that you're going to play on the radio or whatever would it be gobot and would it be cylon which one would you uh pick to be the the hit cylon js is the popular song right now but gobot is a whole new genre of music that once people realize what it is they're going to get even more excited about it because a lot of insiders already are so i was gonna i would say you know silent js this year's grammys go about next year's.

I don't know. Okay, now my head just exploded from being too large. Let me remind our listeners that all of these projects have a lot of contributors, both direct contributors that you see in the commit logs, indirect contributors who paired with those people, indirect contributors who just pointed stuff out through Twitter, email, hey you at the conference, you know, these are very much the product of a lot of people thinking about them. And really, that's the great thing about open source is, you know, you play the song once and it turned into a whole nother song. So if you like that sort of thing, you're really happy. But if you're trying to keep control over my music, then you don't like it one bit.

I personally have found that the song that people thought they heard me play and then they played back to me was way better than the original song I played, which I can't even remember what it was right now, because your version of my song was so much better than mine. Yeah, that's why I like when you said it's like a jam band, because it really is as far as, you know, there's people riffing off one another, and

those different takes on it actually improving the overall thing. So, I want to ask you about the different platforms supported. Maybe Cylon's the most popular because of the JavaScript community, maybe because it supports the most platforms. But before we get into that, let's take a quick break here from a sponsor and we'll be right back. All right, listeners out there who are working solo or on a team tracking time for your projects and billing for invoices.

Imagine this scenario you thought you were wrapping up a project and the client asked for a new feature at the last minute and they got questions about time spent on the project well do you know how much time you're spending on every feature tweak or bug fix to give them that feedback well harvest is a time tracking tool built just for that for understanding where time is going and billing for that time. They even have built-in reporting that lets you know how much time your projects took so you can use that information to make better estimates in the future. Not only will you understand how much time you're tracking on your client work, you'll also be able to turn those billable hours into invoices in minutes. Create a free 30-day trial today at GetHarvest.com.

After your trial's over, enter our code CHANGELOG to save 50% off your first month. All right, we're back talking about robots with Ron, with a hybrid group. Ron, you've got Cylon, your most popular project. You've got GoBot, the up-and-comer, next year's Grammy winner. And they support different platforms. So you mentioned that the JavaScript one supports the most. It has 36 different platforms. GoBot's got about 15.

Maybe speak about the platforms themselves, the interesting ones, and then why the discrepancy in the support from one library to the next. So the different devices and platforms that we support are kind of in a couple different categories. One of them are things like single board Linux computers where we're actually talking directly to the pins to turn on and off the digital signals to turn on and off LEDs or motors. My friend Julian Cheels, who's done a lot of really great talks about dancing drones, he pointed out that most of the internet of things is just turning things on and off.

You know, whether it's turning on and off light bulbs or motors or LEDs Edison, you know, the BeagleBone Black, we actually are able to take advantage of the built-in Linux operating system for the general purpose input-output or GPIO interfaces, as well as the I2C, which stands for inter-interchip communication. A very brief... Inter-interchip. Yeah, so when board designers, it turns out... So you think board designers are magic beings who wave their magic soldering irons, a.k.a. wands,

and somehow this mysterious, spooky device that you just plug your cables in and it somehow works. Oh, man, you really nailed it there. That's exactly right. Turns out they're just as lazy as software programmers, perhaps even more so. It's just they do it with circuits instead of with modules and libraries. Most electrical engineers never actually get to design a circuit. They take various circuits that do well-known things and combine them together.

And that's how they – I mean, it's very hard work. Don't get me wrong. Is that like copy-paste kind of? Yeah, it's similar. In fact, they have tools like Eagle and other CAD programs, which actually enforce a bunch of these rules because it turns out that there's rules of physics that are quite well defined and quite fixed when it comes to the board level design. So if you're going to build a drone, for example, you don't start completely from scratch. You say, okay, what do I need? I need some accelerometer. I need a barometer. So I know my altitude. I know a magnetometer so I can figure out which way the thing is pointed. So you get chips that do each

one of these things and you put them onto your board. The way that they communicate with each other is so-called inter-inter-chip communication or I2C is how you see it written. The old timers call it I2C. So if you know which, you can go either way depending on how much gray hair is in the room at the time. But, excuse me. So we have support for these different devices. So all of our frameworks have kind of the same set of design patterns. You have connections.

Connections are how you physically are going, the protocol physically to communicate with a particular piece of hardware. It could be a serial port. It could be Bluetooth low energy. It could be Linux GPIO. And then you have devices. Devices are things like LEDs or buttons. So where the connections are the physical part of the communication, the transport, if you will,

devices are the behaviors. LEDs know how to blink. Buttons can be pushed and can be either on or off. Digital compasses have a heading, etc. So we can combine these two patterns together, basically a double adapter pattern. So the same digital compass will work regardless of whether it's on an Intel Edison or a BeagleBone Black, or an Arduino. So in the case of the Arduino, we communicate with a C program that's running on the Arduino's firmware itself that supports a serial protocol called Fermata. Fermata is basically a descendant of the MIDI protocol, which is used for musical instruments. And it is a way for a computer to talk to an Arduino and say,

is your digital pin number one turned on because the button's being pushed? Or turn on digital pin six to flash, or 13 to flash an LED. So it's a way of communicating with the microcontroller from an external computer. That's how we communicate with the particle. The particle is essentially a microcontroller that has an API on it. So you can call this API through Particle's cloud servers, wherever the thing is, as long as it's connected to the local Wi-Fi network. So our frameworks use these different interfaces, whether it's a GPIO interface or an I2C interface,

to communicate with all the different hardware platforms that support that interface, whether it's a Particle or an Intel Edison. So it's a great way to apply the same sort of patterns that database programming in web development has for a long time. You switch between Mongo and CouchDB or something, you switch between MySQL and Postgres, you don't really think that much about it

just because you've got some plumbing under the hood which is handling this. So we're applying those same exact principles but to physical systems development. And we're doing it not just for the GPIO and I2C interfaces, but also for other interfaces. So there's other devices which are themselves complete autonomous robotic units. Spheros. Right, Sphero.

Really great example. So the Sphero is the robot toy from Sphero of Boulder, Colorado. From Star Wars. Can't talk about the Star Wars thing. They already announced it. They can talk about it, but I can't talk about it. The one thing I could say is there may be very soon open source support for a Sphero that happens to have a head. That's all I'm allowed to say. Can't name names.

But if it just so happened to work, that would be really cool. But the Spheros that you have today that we have official support for, it's really the minimum viable robot. It has output in that you can send it Bluetooth. So it's a Bluetooth device, or in the case of the Oli and the Sphero with a head, it's a Bluetooth low-energy device. But they use the same protocol as far as the same packets that send it commands to roll around. And it also has input.

It has a built-in accelerometer, so it's able to detect collisions, for example. So it's the simplest possible input and output. You know, we joke around, we call it the minimum viable robot. And it's great for people who want to learn about robotics, but they don't want to get into the whole soldering or plugging things in. You know, that's, they're more interested in making their robotic device do something. That's the part that interests them as opposed to the, you know, how do I actually build

it up from nuts and bolts? You know, and you really need both, and a lot of other people, too. Yeah, I mean, admittedly, that'd be the camp that I would be more in, is like, how do I make this Sphero with the head do something, you know,

programmatically, as opposed to how do I build my own robot from the ground up? Yeah, the software wing of the hardware hacker movement, if you will. Yeah, you know, the fun part. Is it really called Sphere with a Head? Yes. That is not the official name. That's the operative term for avoiding imperial entanglements, let's just say.

Imperial entanglements, good use of the word. But we have really, really good support for some of these complete robotic devices through, again, interfaces, kind of a rover-style interface, forward, back, interfaces, you know, kind of a rover-style interface, you know, forward, back, left, and right, so you could apply that same concept of coding. So if you're using a Sphero or you're using the Sphero's little brother, the Ollie, you know, you're still using the same style of interface.

If you're programming a couple of different kinds of drones, you know, same idea, you know, it has a takeoff command, it has a land command, you know, it has an interface, which is well understood. Now we can mix and match our controllers. You know, you could be using a joystick, you could be using a leap motion, and our drones could be using, you know, a 3D robotics iris, could be using an AR drone, could be using a paired bebop. We're applying these same sorts of principles that I know. Web developers are going, yeah, no big deal, right? Everyone else is going, wait, you're saying you can use the same code and change two lines of code and be running on a completely different piece of hardware?

Yes, that's exactly what I'm saying. So that thought is pretty avant-garde in the in the hardware space yeah that's our contribution that's the reason why we have our own frameworks as opposed to just jumping in on somebody else's frameworks because there's a lot of cool work that's been going on you know but you know but we've been doing we boxed ourselves in we wrote a framework in 2008 2009 specifically for unmanned aerial vehicles using ruby and you know there's a bunch of youtube videos and my little brother damon and i you know flew around the world you know carrying tanks of helium on our shoulders through exotic cities you know we could say we could ask for a tank of helium in like six languages it's amazing but um but it was really too early and also it was very limited it only worked with arduinos

and at the time that seemed like it was you know really big and open-ended well now we realize there's so much more there's a bunch of different ecosystems based around different hardware platforms unique capabilities some of which are shared so if we can apply these same set of design patterns, we can really do something important as far as making it easier for people to program their physical world. So it's not just, you know, the professional priesthood of programming as it's been. But it's really for every human giving this sort of ability to do more, you know, because eventually this is where everything's going, right? The same way mobile is today, physical computing, you know, Internet of Things and robotics will be in, you know, five years.

You know, you'll have app stores, you'll have big IPOs, some gigantic successes, some massive failures, you know, in short, all the same sort of stuff that we see today in mobile. So, you know, we have invested really heavily in terms of our time and also paying people to work on open source, to say, look, let's start doing this now, everybody, so that we can have the renaissance that we hope that it can become. And it's not just a few big companies dominating the landscape because the innovation really comes from individuals and small groups. That's really where innovation comes from. That doesn't mean that can't happen at big companies,

but it happens within those companies and it's not the company as a whole. We need to encourage also non-commercial types of development, solving problems that maybe aren't highly remunerative, but they're important for the world. Those are the kind of problems we also need to be able to work on, and if we can make it easier and cheaper for people to actually do that, then instead of getting disheartened of saying, oh, wow, I'm trying to boil the ocean,

say, no, no, no, just boil this one pot of water. That's all you need to do, and somebody else will do their part and so on. That's how we got to where we are now as opposed to living in a closed source world. So ultimately this can win, but it requires a collective commitment to it. And right now there's a lot of companies

throwing their hats in the ring of saying, we want to build the backend for your internet of things. I just don't want it to be the AOL of things. I want it to be the internet of things. And it's the openness and the interoperability. It may seem scary. Like, wow, you're saying we can make it possible for our competitors to get right into our systems? Like, yes, that's right. And that's going to keep you honest. That's going to keep you on edge and actually doing something useful, or you won't be relevant anymore another question for you here what's the coolest thing you've seen somebody make with one of your libraries either Cylon, GoBot or R2 you know you mentioned you can mix and match all these things

and come up with something amazing has anybody really wowed you with something they've done with these frameworks? Well, some of the stuff that I've seen, in particular in education, that's the stuff that excites me personally. I know there's important or highly profitable or big money investments, but the ones that excite me personally are the ones that I've seen where it's little kids.

We did a bunch of work with some visual programming tools in participation with Sphero and Google for Youth.io. Youth.io is a kids' programming event that takes place the last day of the Google.io event. This was the second year a couple of months ago. And so it was a visual programming environment that ran on Chromebooks specific for a lunar mission where the kids would do visual programming

to control the Spheros and their Lego Mindstorms robots to navigate this lunar landscape. And they had to get through this tunnel. And I just thought, this is such an incredible application of so much technology like the amount of engineering that to do this deceptively simple thing you know it's the technological equivalent of playing a conga drum right it looks really easy to you actually try to do it and you're like oh man that's really hard you know i thought it was easy like no no no that to me that was the most personally exciting is seeing the looks on the kids faces as they

grok the concepts of programming you know because kids are much smarter than adults ever give them credit for right they don't necessarily have this ability to express themselves in the same ways. They don't necessarily have the same fine motor skills, but their ability to comprehend, you know, researchers are consistently learning that babies long before they're actually able to vocalize or able to understand a lot more speech than was ever previously thought, you know, and that's very consistently true through the entire developmental cycle. If you've ever learned to speak a foreign language, you've probably experienced that directly. It's much easier to learn to understand

than to initiate the things you want to say outside of a few canned phrases, but to actually hold a full intellectual conversation where you don't just understand, but you're able to respond and initiate concepts in the conversation. So watching these kids grab these ideas and turn them into variations of these ideas there in real time and the amount of work that it took to actually get to that, but that it was unlocking their creativity and that some of these kids are going to go on themselves and build all these amazing things, you know, not necessarily using these tools, but that doesn't really matter.

You know, you have to ask yourself at some point, is what you care about the fact that this mission is being accomplished or do I care about that my name's on the mission? You know, when it comes to kids and teaching programming, you know, you got to take yourself out of the equation to the maximum extent possible while still at the same time recognizing, you know, you have a leadership role to play by what you choose to do. But ultimately, it's not about you. It's about them. They're going to take these ideas and do something with them and you can't control it

all you can really do is sort of inspire it and then it's up to their parents I have my own kids so I got my own problems so that's a great one time opportunity for kids have you seen robotics and teaching in any sustained ways uh out there as far as things that just you know and continue to teach as opposed to like just get kids excited and then kind of

move on oh yeah um so i was lucky that um i guess guess the virtue of having of being a little ahead of people because of life experiences. Like I happen to have my oldest son is a teenager. So, you know, if I started caring a little bit earlier about kids programming than some younger people, it's because I had a kid. So, you know. Sure. Wow. Amazing. But I was just the latest of the new generation. I mean, it goes back to Alan Kay,

and it goes back to Papert, and it goes back to before them, you know, of, you know, how do we teach critical thinking to the next generation? And I think it was, you know, if we go back, I believe it was Cicero complaining about, you know about the youth of the ancient Roman times. Yes. It's like, oh, yeah, okay. I'm sorry. I'm going to vote with the delinquents on this one. If nothing else, they're more fun.

But the ideas that we are unleashing through teaching programming, coming to town and saying, hey, kids, here's this one-time thing. We did this Kids Code Camp, was what we called it. We were doing them in 2011. And it was literally like a programming circus comes to town. We would do a one-day thing. We brought in experts. The first one, actually, was we sort of hit the home run out of

the park um so cory haynes who i'm sure you know cory um so cory was supposed to come and teach the scratch class um but he flaked no he couldn't make it because of some no he he literally could not make it and he was super bummed because he some, no, he literally could not make it. And he was super bummed because he really wanted to do it. And I was really bummed, too, because I really needed him to do it. I wanted Scratch. And so we were introduced to one of the teachers at the Liberal Arts and Science Academy of Austin, Texas, which is a high school. And one of the teachers there said, oh, yeah, I'd love to come and teach the class. Then he got back to us the next day saying,

oh, I got really bad news. I can't make it either. And we're like, oh, we can't cut a break. Then the very next day, he contacts back and he says, listen, some of my students here at the high school said they would really like to teach this class. And I'm like, my jaw is on the ground. Literally, there's tears in my eyes. I'm like, you know. So they put together a curriculum themselves. They came in and taught the elementary age students, these high school kids, and their curriculum was so good that when I showed it to Corey, Corey's like, oh, this is much better,

and he adopted their curriculum and started using it as part of the Scratch stuff that he was doing. Wow. Okay, like, that was a magical moment, because that was sort of, you know, that's the holy grail of education, the mixed-age peer learning, Montessori-style relearning by teaching. And the fact that we were actually able to hit that, but then the programming circus rolled away. So what now? Us, collectively, when I say us, all of us, humanity, a bunch of other people started thinking about this problem and started caring about it enough to do something. Coder Dojo, fantastic work that they've done, you know, sort of bringing back the computer club of your, you know, weekly, you know, place to go hang out and just sort of play around with stuff. You know, fantastic place to go hang out and just sort of play around with stuff. You know, fantastic. Code.org.

Code.org, where our team was sort of like, hey, let's write some software, and we wrote Kids Ruby. Code.org, you know, they were video producers. Like, let's get the word out. That was really important to do that because the more support that the broader community, not just, I mean, we programmers know that programming is important already. We do it every day all the time, right? It's the rest of the people, you know, helping, you know, share and make it easier for them to, if nothing else,

understand how a technological world works. You know, not necessarily from the, everyone become a programmer, but to everyone understand that programmers run the world and they make mistakes due to the program errors. And so, you know, maybe you shouldn't push the red button, you know, because that might be an error. Like, are you sure, sure, sure. You know, you want to launch the first strike you know so just having a well-educated well i mean you know it could be law enforcement realizing oh there was an error with this person had the same name but obviously they was a very different gender and you know height and age like we're we were looking for an 87 year old woman and this is a 16-year-old guy. I'm pretty sure that

this is a computer error. It's sort of common sense thinking that does not necessarily occur when people accept the dea ex mechanica. What the computer says is absolutely always infallibly correct when that's absolutely not the case, right? And so knowing a little bit of common sense of like, well, let's just hold up for a minute and verify that that was indeed the first strike launch order, you know, is something that all of us would like to know exists in the world. And so, you know, those are extreme examples, but they happen in very minor ways all the time through minor decisions that are increasingly made by machine. We need the general populace to understand the implications of that so that they can be informed, not just how to make good policy on that, you know, at the governmental level, but also just how do you deal with it on a day in, day out, like what to do if the garbage robot malfunctions kind of thing. Well, first of

all, stay away from it, you know, kind of idea, you know, I mean, these are common sense. I, you know, the self-driving car error, you know, most of those problems are due to the people. Well, most of the problems in the world are due to the people. Well, most of the problems in the world are due to the people and programming error is the same. So it's not about creating a generation of entrepreneurial programmers. I think that's very much of a red herring. I think it's more about how do we create a better world by acknowledging the place that technology has taken of importance the same way that we expect our doctors and our lawyers to have certain professional and ethical standards, software and hardware people

eventually are going to have to grow up and recognize we also are going to have to recognize our place in the broader world and what part that we have in that and how can we be making things better and not worse. Well said. Let's stop here for another quick break. Here from another one of our awesome sponsors. When we get back, Ron, I want to ask you about getting started with some of these libraries and with programming robotics.

And then, of course, our awesome closing questions. So after the break, we'll do that and we'll be right back. ImageX is a real-time image processing proxy in CDN. And let me tell you, this is way more than image magic running on EC2. This is way better. It's everything your friend and developers have dreamt of. This is way more than ImageMagick running on EC2. This is way better. It's everything your friend and developers have dreamt of. Output to PNG, JPEG, GIF, JPEG 2000, and several other formats.

And if you're like me, and you've ever argued with your boss or a teammate about serving retina images to non-retina devices, you'll appreciate their open-source dependency-free JavaScript library that allows you to easily use the ImageX API to make your images responsive to any device. Now, all of this takes a platform, and the ImageX platform is built on three core values. Flexibility and quality, performance, and affordability. When it comes to flexibility and quality, Imagix has over 90 URL parameters that you can mix and match to provide an unlimited amount of transformations that you need for your images. And they take quality very seriously. And because of their commitment to quality, several top 1000 websites in the world trust

them to serve their images. Now when it comes to performance, ImageX operates out of data centers filled with top-of-the-line Mac Pros and Mac Minis, and they're set up for a completely streaming solution. This means your images never hit the disk. Images are served by the best SSD-based CDN for delivery around the world anywhere extremely fast. And while we're talking about speed, almost all the image processing happens on GPUs. This means transformations are super fast when compared to competing virtualized environments. And lastly, it's all about affordability.

Everyone wants to save a buck. That's how the world works. Because ImageX processes close to a billion with a b images per day they're able to make certain optimizations at scale and pass those savings on to you to learn more about imagix and what they're all about head to imgix.com slash changelog once again imgix.com slash changelog and tell them adam from the changelog sent you we're back with ron evans ready to find out ron how do you get started i'm sure there's plenty of developers out there now excited about the not the aol of things, but the Internet of Things, and specifically how they can use Cylon or R2 or GoBot

to program some hardware. What would you say to somebody who's just like, okay, let's do this. What do I do? How do I get started? Well, first of all, you better get buy-in from your significant other. He or she is going to have to deal with your new electronic habits. So that's important that you shouldn't hide these types of addictions. Is there going to be a cash investment probably into some hardware, I guess? Oh, yeah. But the beauty of it is there's a lot of really great kits that combine together sort of the minimum necessary pieces.

Seed Studio, SparkFun, and Adafruit are three online retailers that have put together various kits that work with, you know, the Arduino is sort of the gold standard of microcontrollers, the minimum viable microcontroller. Of course, that's better for people who want to actually assemble some pieces. If you buy something called the Grove starter kits, then Grove connectors are little plug-in type connectors. Those are the kits that we used at the GopherCon hackathon. That way you can assemble some basic circuits without actually having to solder anything just by plugging in the connectors.

That makes it a lot easier to get started, you know, before you, you know, not that many people have soldering experience. It's great to learn how to solder, but you might want to do that with a separate project, just a pure electronics project, as opposed to the, you know, programming. Soldering together the whole robot and then programming it, you know, could take quite a long time. And this way you can get started a lot more quickly. The Intel Edison has a couple of different starter kits that we have really good support for with our frameworks. They have the base starter kit,

the same sort of starter kit, which is also available for the Raspberry Pi and the Arduino with a few basic sensors. Then from there, what you're really more interested in is how can I have some type of programmable device to then make it do things? The Sphero robots are really excellent. You can get them typically. Sphero now has a program called Spark, S-P-R-K, where they have a special educational program with heavily discounted.

So that's a great way to get a hold of a Sphero robot. We have support for if drones, making things fly is what's getting you excited. The Parrot, it's really hard to go wrong. To a large extent, just because you can get replacement parts as well. When you're flying things around, you're probably going to crash a bunch of times. So the new Parrot Rolling Spider for $99 is a great option for if you want to just

have a programmatic control over a flying device. So those are some of the, and then there's lots of really great peripherals of different kinds, you know, whether that's the Leap Motion, Gestural Controller. There's a couple of brain-computer interfaces that we have support for, the NeuroSky MindWave and also the Muse, which are both Bluetooth electroencephalograms or EEGs, which are able to read your brainwaves. So practice meditation or have the drone fly off when you get really agitated.

Or maybe you should do the opposite. Maybe it should land if you get really agitated. You know, that might be better. Yeah. You know, so there's a lot of different toys. You know, you might consider them toys. In fact, a lot of them come from toy stores. You know, we call it IoT to us means Internet of Toys. And, you know, any sufficiently advanced technology starts out in the form of a toy. Right?

If you want to know what the next big thing is, go to a really, really good toy store and look around. Right? Look around in the so-called science section. You know, scientific toys. So you go over there and you're like, let's see, hydrogen cell fuel kit, home DNA test kit. How about the Rock'em Sock'em robots?

And of course, a pile of robots. Pile of robots, yeah, but these are Rock'em Sock'em robots and they're fully Bluetooth, low energy interface, API available. There's a real world human human-size or even larger rock-em-sock-em robot thing. Do you see that, where they're trying to fight Japan?

Yeah, well, on that, listen, Team USA, you guys are looking great, but you should be in contact with Limor Freed. She should be the captain of the team. If we put her in charge, I think the possibility of our success is significantly higher. Really? Just saying. Just saying. I don't think, they may or may not hear this, but you could send them an email. It might be more effective. Yeah, well, you know, she's got the

street cred, and, you know, being a New Yorker, I think she can think she's got the right pit fighter attitude. But when I was in Tokyo speaking at Ruby Kaigi, a very, very nice man was introduced to me by Tenderlove, Aaron Patterson. And this guy turned out to be one of the heads of the Japanese National Institute of Science and Technology, who told me about his permanent installation at the museum that was right down the street from where the Ruby Kaiji conference was. And I was like, oh, wow, I really want to go see that. So I went over there. It turned out that's the museum where the ASIMO is. Wow. So they're very far ahead as far as developing robotic technology and also adoption of it culturally.

But we've seen a lot, particularly with drones, what we would have called unmanned aerial vehicles a few years ago. But now anything that flies under robotic control is a drone. Yeah, what's the definition of drone? Is that it right there? Anything that flies under robotic control is a drone yeah what's the definition of drone is that it right there anything that flies on a robotic control well you know like the mainstream definition of drone is similar to the mainstream definition of hacker yeah just in other words they took our word from us and they ran with it and whatever we wanted to do something bad do with that word then we we tried to take it back, and we failed. Drones originally, actually, the first drones were airplanes that flew themselves through mechanical means during World War II.

During World War II, the average survival rate for fighter pilots was only a few minutes of air combat before they got shot down and killed. So it turned out this was a real problem in the air war. And they developed these airplanes that they would literally take off by themselves and fly a pre-determined flight pattern. And then the human pilot would take off in another airplane and shoot down this other airplane. That was what a drone was in circa World War II. And so, you know, drone aircraft meant, you know, eventually they were remote controlled and, you know, it meant any vehicle that was remotely piloted, you know, became a drone. And, you know, hence the Predator drones, which are not, you know, technically really flying robots, but they're actually, you know, telepresence see for example in the DARPA challenge or in the SparkFun autonomous vehicle challenge which is you know slightly more friendly version

you know these are devices where the intelligence to make all the decisions is entirely in the device itself of course that's a little bit of a false dichotomy, right? Human beings, we have the problem of our brain and our body have to be attached or else bad things happen, right? You know, robotic devices, no such requirement. You know, that's where swarms or, you know, the brain is safely on Earth while the body rolls around the planet Mars. You know, out of curiosity, you know, and a bunch of those systems, you know, so, you know, there needs to be intelligence in the devices themselves, but also, you know, there's a distinctly human component, whether that's the decision-making process, you know,

fire or do not fire the missiles or, you know, you know, conduct this experiment. But I mean, it's really, really hard. A neighbor of mine actually works at the Jet Propulsion Laboratory in Pasadena on some Curiosity-related work. And the latency of communicating with a robotic device on another planet, you know, you think you got problems flying your drone around your backyard.

Have fun with that, right? Yeah. Well, it's definitely been a blast having you on the call, Ron. I know that it was great meeting you at GopherCon. Loved having you at Hack Week. It was a lot of fun seeing a lot of the people in your class and in your room there just kind of doing some really interesting things. And what y'all are doing at the hybrid group for it as well

on the open source side is really interesting. So we appreciate your love of everything. The one closing question we think we have to ask you, though, is who your hero is. So we ask those who come on the show, who's your programming hero? So who's that for you? Wow, I have a bunch of programming heroes, actually. I have to only pick one. Well, I'm going to give a shout out to the late great Jim Wyrick. Jim was the creator of the Rake programming language and innumerable other open source projects.

He was the only guy who was a chief scientist who I didn't laugh at that title by asking them if they had peer-reviewed papers and where the last one was. Jim was an amazing contributor to a lot of other projects as well. Very humble guy. A lot of people felt like he was their best friend at programming.

And he definitely is missed in the Ruby community. And so I would have to say, of all my programming heroes, I miss him the most. Yeah. We echo those same thoughts. Who was that recently, Jared, who a their hero was uh was jim the karen meyer karen meyer yeah oh karen's amazing okay well you know karen um she the work that she did with closure drone um which you know i don't know if she's i saw her at oscon

um fairly recently and it was really great because we'd never actually met up in real life, although we had worked together on some stuff. So it's really funny. Oh, the internet is crazy. But but the stuff that she's doing with autonomous drones and the closure language is absolutely fascinating. Amazing work. And, you know, Jim is really missed by both of us because he was one of the few people who understood, you know, of the people in the Ruby world, I felt like Jim was one of the few people who really understood what I was trying to do and how much more it was just than Ruby.

And so he's missed even more for that vision of seeing, you know, and contributing really actively, you know, he just got really excited about a lot of projects and, you know, and contributing really actively. He just got really excited about a lot of projects, and he'd done some really cool stuff with drones, and I was really excited to make him excited and happy when I showed R2 for the first time at the Los Angeles Ruby Conference and it was using the Argus gem that he had worked on with a bunch of patches that I didn't submit as a pull request because I wanted to surprise him. So he was in the front row and

he saw the box for the AR drone and then I pulled the whole thing out and, you know, did the talk. It was just the fact that I was able to make him happy for a minute, that really made me happy. Like to give back because he was a really humble guy who did a lot of things for a lot of people and you know everyone who ever used rake still uses it today not realizing you know and just doing this thing and playing this ukulele yeah I showed him how to play blues music on the ukulele true story actually the same day that I showed him that you could use Ruby for unmanned aerial vehicles, the fact that I could bring something

to a brilliant guy like him, like, I don't mean like, oh, I'm so great. I mean, like, I felt genuinely grateful that I could offer him something back in return because he did so much for so many people and never thought of himself, really. He was just doing it. So the fact that i could even bring him anything at all ever as sort of uh you know hey

thanks you know because we're all very hungry for new information and i think that includes everybody and you know some people they're you know humble enough to acknowledge it and other people they just sort of like sneak around and quietly look at what everybody else is doing because we're all really hungry for new information. And so Jim, you know, he was overt about it. He was like, if he didn't know something, he would instantly ask you, what's that? He didn't pretend like he knew things

that he didn't already know. That's how he learned so quickly and he was able to come up with so much. Very curious. Just a curious mind and so you know let's let's all be like that let's all be curious absolutely stay curious my friends stay curious well ronald was definitely a pleasure to have you on the show i know that uh i'm sure our listeners have appreciated your passion for hardware open source internet of, creating the software behind some of the best hardware out there, as you mentioned

earlier in the show, and the passion you have for not only Ruby, but Go, and also JavaScript, and how it can affect the future of the directions we've talked about today. But I want to thank our awesome listeners who listen to the show each week. Without you,

it wouldn't be possible possible because who would listen? We also have awesome sponsors that make this show possible. Codeship, Opbeat, Harvest, and Imagix. And Ron, I know this has been a long time in the making, this show here with you. But it was great meeting you at GopherCon. Look forward to seeing you further out there in the open source world, my friend. But for now, let's all say goodbye. Jared, Adam,

thanks so much. To all of you listeners out there in internet lands, I just want to say thanks for taking the time and go program something right now. Boom. Bye, guys. That's the way to do it. We'll see you next time.