Cylon.js, Gobot, Artoo, IoT

We'll go back everyone. This is the Change Log in on your host, Adam Stikoviak. This is Episode 177, and today, Jared and I joined by Ron Evans, and Ron is the ringleader of the hybrid group, and creator of a fleet of open-source robot libraries, SilentJS, GoBot, R2, and we had a blast having Ron on the show today. We had four awesome sponsors for this show, co-chip, op-eat, harvest, and images.

Our first sponsor of the show is co-chip, their 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 test pass. A co-chip has great support for lots of languages, test frameworks, and notification services, and they even integrate with GitHub and Bitbucket, and you can deploy to cloud services, or even your own servers. Get started today with a free plan when you upgrade to a premium plan, use the code, the Change Log podcast, and save 20% off any plan you choose for three months.

Head to co-chip.com slash the Change Log 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, Jared, we met Ron Ware. Where we meet him at? Well, I met him a couple of years ago at NGComps, the original NGComps. Yeah, and I remember at the time I said, we've got to get you on the Change Log, and you know, it's only two years later.

But we got you on, and then we met, we saw him again, and you met him at GopherCon, which is kind of a running theme this fall, because a lot of people that we met at GopherCon are on the show. But Ron, it's really nice having you. Thanks for joining us. Hey, guys.

Thanks for inviting me. A long last. 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 Goh really brought them all together. Yeah. And the second one, most recently, same thing, but she's even more magnified. So, you know, through those, through the organizers, and also very interesting quality to the Goh programming world, that it's attracted people that, you know, 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 it, 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 Petal, Sphero, we've worked on a bunch of robotic programming, work for them, particle, the wireless microcontroller company, formerly known as Spark, 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 silon.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 you're programming in Go, it's channels, you know, so in Go routines. So we've really said, here's a core set of patterns for developing physical systems. How can we then implement those and provide a set of libraries that work together in the form of framework so that developers can much more easily program the physical world the same way as right now, web developers, program websites, 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, you know, when I saw you guys last at Gopher Con, we were just holding the hardware hack day with a bunch of really awesome hardware donated by our friends at Intel.

Intel's 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, you know, 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, you know, we basically lost control of the registration.

It was great. You know, it was fantastic. You know, we ran out of hardware. Yeah.

I mean, I remember, I didn't know you had a register. So I was just kind of, we were walking around shooting B-roll and talking to people and I was like, I'll hop in here and participate. And I hopped in and it was like, there's no hardware left, dude. It's, it's, it's, you missed the, you missed the ship.

We got some good footage in that room too with, I'm not sure what they were doing, but they were doing something with where you can see gestures on the can motions. Yes. That was using. We've done a lot of work with Leap Motion.

Yeah. That was a gesture control 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 and just, for no current reason, just is it really cool. Yeah.

No wires. Just wave your hands around. I wave my hands all the time and nothing happens. And you know, this, I wave my hands about something is actually happening.

See, I knew it. That was exactly it. You could see the person's hands on the screen and like, 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. 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 Silent JS and Leap Motion and Sphero and AR drone. You know, her demos are always really, really fun and she's written a couple of blog posts about them. 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. You know, it's far more interesting than the stuff that we do, you know, at least as far as me personally.

I'd much rather hear some of the play-my-song than to just play it again myself. Yeah. 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 kind of get your take on the robotics industry at large.

You mentioned Particle and we did have Zach Zappala from Zappala on back in April. I didn't even realize they'd renamed. So we're 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.

So one thing that you and I discuss briefly over kind of what I'd like you to elaborate on now is the interplay between open source and closed source amongst the robotics companies, kind of 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 kind of like lay out the landscape for us so we can kind of 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 in the last 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 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 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 of those things and build 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 PIXOC. 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 PIXOC 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 the 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 and 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 and are doing fairly substantial important things as far as work in disaster recovery, bringing medications to remote villages at consistent temperatures, 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 over the happening. So that would be the completely open middle side.

So in the middle would be parrot, I think, would be a great example. With the AR drone, best selling drone ever in history. I've heard different stats, but you know, it's certainly at least 250,000 AR drone one and the AR drone twos that have been sold. So the AR drone uses open source under the hood, the, so does the bebop and so does the other drones that they're currently selling.

They're running a busy box Linux distro, so, 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, you know, you might think of them as sort of the semi open or not closed, you know, if you're like a half empty or half full kind of person. You know, the point being that it's been all sorts of really awesome things that have been created despite, you know, Richard Solomon, 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, they get eight drones and yet each of them completely viable in their own way. So, it's really, really interesting because, you know, I'm 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 have a purist, he got inside somewhere. Yes, 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. So, so that's- Some of you have 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 know, you burn out parts, you brick things while experimenting with them, you know, you they crash in a very literal sense, like from the air to the ground in a way that was faster than anticipated or at an angle that was, you know, generally bad for the thing in a permanent way. You know, so though, you know, the need for companies to support open source and not just so they're 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 at the same time, you know, with a good solid value that they provide 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 kick starters, not to pick on crowd source companies, not at all, but the opposite, really. I feel for a bunch of these companies that I get my weekly kick starter apology emails. I know. You know, and behind each one of them is like a horribly tormented person that's just feeling all this pain and disappointment to like, oh, I never went down and, you know, I couldn't do this thing and, you know, like, you know, they're, you know, not to mention, you know, all these people kind of hating on them, like, hey, I thought I preordered 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. And then, of course, it was so much worse than you thought and all these people were expecting.

You know, that's where, you know, perhaps a better model for a lot of companies might be, you know, on the one hand, just make some, you know, just a handful and then sell them on Tindy or something. Like, you got it off your chest and that's why you weren't on the hook for the excessive popularity that may be good and maybe bad, depending on whether you could actually, you know, shipping 50 of a thing might be enough to nearly kill you. Shipping 5000 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, 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 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 is difficult too. Yeah. And I think if it was a little bit more spelled out to the buyer, 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, you know, investing in the potential of a dream, you know, they're giving some of the chance to do an experiment. You know, I wish people looked at it that way because, you know, if it was a little less high stakes. Well, I mean, it's a two inch sword though. I think, you know, some people, some people start, they actually pitch it as if they're going to get it.

Like they show the demo. Like they do hype some dreams up 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.

And sometimes it can be not purposefully but in a way misleading because you think, well, I'm going to fund this today and in a year from now, just like they said, and it's like, oh, perfectly. So I'm expecting this thing. And then, you know, 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.

You know, if it all just quietly go away, as you said, you know, that would be nice for the original people. Of course it doesn't. It's the internet. Nothing goes away ever.

One case is to 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, this one card that was like smart, I can't remember the name of it right now. Coin. Yeah.

So I'm a good example 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, you know, we're deep in their tech and deep in their R&D, they got sides wide by the bigger people, which became much a bigger play for Square, Apple, Android. They're all have their payments platform, you know, so. 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 nother 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 Navdi and Julie Box, which is a really cool, programmable jewelry for young girls, excuse me. 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 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, you know, hardware or software, et cetera, helping them navigate the process of getting to a thing.

Only once they've gotten through that whole program, only eventually they really think about doing the crowdsourcing, you know, crowdsourcing, you know, 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, hey, this is, you know, the new, you know, square 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 reinvented the wheel, I want to invest, you know, how do I get in? You know. Right. But the problem is, of course, is, you know, your wheels turned out to be square and made of wood.

Yeah. There was a good reason why the industry had standardized on rubber and round and, you know, you, in 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 obvious. But, you know, 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, you know, they did as little as possible to actually get to some kind of, you know, 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 the 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? Like, oh my God, I kept like, first of all, the hackers have a field day, not that they couldn't are ready just with Metasyloit 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 tax surface. But it does significantly expose your incompetence if you fail to do it, you know, well, right?

And the opposite, you know, we've seen individuals, really, really smart people come sort of humbly doing a cool thing that, you know, quietly like solves a real problem, you know, I'm talking about Metascha Modo right now, actually. So Mitch, I've done Mitch for a long time, his company, HashiCorp, they're the people originally, you know, who now have auto, most recently, so I've done 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 that, uh, consultancy based here in Los Angeles called Citrus Bight.

And Citrus Bight 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 to the hybrid group, you know. So anyway, so Mitchell, you know, came up with Vaygrant, just worked on it very humbly, super smart guys, 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 couldn't 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 me. Yeah. We actually have an upcoming show with Mitchell. We saw auto as well.

We've been fans of Vaygrant around here for a long time. So when we saw auto, we were pretty excited about just seeing, you know, their constant chipping away at this problem. So even if it supersedes, they're not, it's still pretty interesting. So that's really funny.

Hey, Mitch. Are you there? I'll come and say hi. I say hello to your future self on 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 No JS beta right here right now exclusively to our listeners. Opbeat combines performance metrics, release tracking and air 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 No 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 opat.com slash changelog. All right, we're back with Ron Evans, Ron, the self-profess 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 there in three different languages.

You got silent JS, Gilbod, and R2. So why are three different projects and why three different languages? Well, every programming language does something really well or else nobody would use it all of course. But the inheritance of that language would often proclaim its superiority in all things as opposed to, you know, generally being curious about why are some of the using that other language?

The one that I don't use myself. What's so good about that? 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, that the people who are generally curious at learning as many programming languages as possible just to try to grok 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, you know, get your code tested. You know, if you're a Python programmer and you don't have any documentation, that's other 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 if you can follow that trail after me, you know, 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, you know, the, you know, keeping up with what's already been done.

The Go community, on the other hand, being a very new community of much very hardcore programmers from other disciplines, you know, has a certain newness to it, you know, 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, Silent JS has a real, 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 spin-offs of node serial port, which was Chris Williams project, you know, to all the stuff that's going on through Johnny 5, which is Rick Walden's project, you know, to all the stuff going on with node copter, with the tessel, which is the 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 Jimmy JS or something, Johnny, I forget, anyway, they have a new stripped down JavaScript runtime to specifically to run on their Arctic line of microcontrollers and single board on this computer. So there's a lot of people doing hardware hacking in the JavaScript world. So of course, we have more support from more pieces of hardware there because, you know, 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, you know, we're, 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, you know, because JavaScript is very, very tribal within itself, you know, case in point being the node JS and IOJS schism and subsequent reunification much to all of their credits, you know, cooler heads prevailing, which I, you know, I'm not a member of either one of those communities directly per se, so I'm happy to see them, you know, getting together. I'm kind of doing my own thing and I have been, you know, 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 Buncy, 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, you know, 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 programming, you know, 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, you know, like we agree that, you know, we both come to the door at the same time that one of us was going to stop and let the other one go through first. But there's no rule.

There's like, there's no traffic cop. There's no camera. There's no buddy enforcing this custom, you know, so in dynamic languages, interface-based programming is something that's enforced by custom and not by rule and 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 different completely different hardware platforms, you know, could be talking to a de-go on black, could be talking to a Raspberry Pi, could be talking to an Intel Edison, you know, the 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 Node Box community and Node Copter and, you know, a bunch of some of these communities, you know, consider themselves competitive to SilentJS, 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 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, nor vice versa. You know, hey, let's have a music festival, you know, that's sort of the jamming and code attitude that, you know, I've tried to have and, you know, certainly hybrid group is also, and lots of other people too. You know, with 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, you know, to a degree, which is why we said, you know, why three different projects, three different languages, you know, essentially, we created the wheel for each camp, right?

Well, the way it's sort of played out, you know, Ruby is a great way to learn ideas and to play with ideas. You know, 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 and Python, Noir and Closure, you know, 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, you know, TJ, who wrote Express, never tried to hide that quite the opposite.

You know, TJ's biggest contribution to the Node world was he could look at Ruby jams that do the thing and rewrite them in Node really quickly. That was a huge contribution because it really accelerated, but, you know, a lot of people in the Node world had no idea where that stuff originally came from, which is, you know, 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, you know, and it's the, it's it's undoing, you know, 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, you know, you intentionally weren't using it because you're running on, you know, really small or underpowered hardware, single-board Linux computers, you know, in our case, you know, it's not really something you could take seriously, you know, you're trying to go the other way, how much can I get rid of, right?

You know, Rubenius, cool project, but splittering off of the main Ruby implementation, you know, there was a really problems with fragmentation, they looked, looked what happened with, you know, Node 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, 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's 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 IO, you know. If you're running programs for the web, your biggest problem is blocking IO because, you know, you've got requests that you go off and, you know, do something and then respond.

So if you're running applications that are talking to physical devices, your biggest problem is blocking IO. You are waiting for the servo to move to the, or stepping motor to a particular position so you can then, you know, do something with this other motor. So, I mean, you're waiting for IO. So I'm not at all surprised that a lot of people where node programmers have 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 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 and pile it so I can, you know, compile it on my computer and, you know, SCP, the file over to the drone to execute it, you know, there's a bunch of advantages to developing code using Go, which translates very directly the kinds of problems that device programmers, 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, or do we know, 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 in mass and all these different places to do all these different things. Well, the answer is I had a Virginia's 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 Linux computer, you know, whether that's a Raspberry Pi or a Beatable Black or the former 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 plants no longer has the ability to get, you know, external data. So of course it shuts down and, you know, you have a fire or something. I mean, this is, 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, you know, it's the most popular of our frameworks. But Joe Bob is coming, you know, up very quickly and popularly, it's in the 99.9th percentile of GitHub stars for go-laying projects, you know, and it's competing against Docker and CoreOS and everything.

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 that kind of leads me to my question was you got these three, you know, let's take your band analogy.

You got these three songs that you've written and if you had to take one of them and pick a single that you're going to play on the radio or whatever, would it be go-bought and it would be Cylon? Which one would you pick to be the hit? Cylon.js is the popular song right now. But go-bought 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 would say, you know, Cylon.js, this year's Grammys go-bought next year, so I don't know. Okay, now I had just uploaded from being too large, you know, 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, 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 another song. So if you like that sort of thing, you're really happy. But if you're trying to keep the troll over my music, then, you know, you don't like it one bit.

I personally have found that, you know, 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 song, 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 on another, you know, the, those different takes on it actually improving the overall, 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 he 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 your 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.

Now that we understand how much time you're tracking on your client work, you'll also be going to turn those billable hours into invoices in minutes, create a free 30 days throughout the day at getharvest.com after your trials over enter our code, change law to say 50% off your first month. All right, we're back talking about robots with Ron with the hybrid group Ron. You've got Cylon, your most popular project, you got go by the up and come or next year's Grammy winner and they support different platforms. So you mentioned that the JavaScript one supports the most, like it has 36 different platforms, go bots got about 15, maybe speak about the platforms themselves, what you know, the interesting ones and then why the discrepancy and the support from one library to the next.

So the different devices and platforms that we support are kind of in a couple of 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 that Jillian Chills, who's done a lot of really great talks about dancing drones, pointed out that most of the other things is just turning things on and off, whether it's turning on and off like Bulge or others or LEDs or whatever that was happened to be. So a lot of the devices or platforms, the Intel, Edison, beable and 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 or I2C, which stands for inter-inter-chip communication.

Very brief. Inter-chip. So when board designers, it turns out, so you think board designers are magic beings who wave their magic-sothering irons, aka wands and stuff like this mysterious spooky device that you just plug your cables into that stuff out of works. Oh man, you really nailed it there.

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 of the lecture 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? You know, similar. In fact, they have tools like Eagle, you know, CAD programs which actually enforce a bunch of these rules because it turns out that there's rules of physics that are, you know, quite well-defined and, you know, quite fixed when it comes to the board level design.

So, you know, if you're going to build a drone, for example, you don't start completely from scratch. You say, okay, whether 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-interchip communication or I2C is how you see it written.

The old-timers call it I2C, so, 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 are kind of the same sort 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, you know, physical part of the communication, you know, the transport, if you will.

Devices are the behaviors. LEDs know how the blink, buttons can be pushed and can be either on or off, digital compasses have a heading, et cetera. So we can combine these two patterns together, basically double adapter pattern. So the same digital compass will work regardless of whether it's on an Intel Edison or a Beagle One 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, you know, number one turned on because the button's being pushed or turned on, digital pin six, 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 particles 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 iSworsy 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 the database programming in web development has for a long time. You know, you switch between, you know, Mongo and, you know, CouchDB or something, just 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 iSworsy interfaces, but also for other interfaces. So there's other devices, which are themselves complete autonomous robotic units. Thanks for your own. Right.

Sphero. 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.

I can't talk about it. The one thing I can say, the one thing I can 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 that's, you know, but if it just all happened to work, that'd be really cool. Anyways, but the Sphero is that you have today that we have official support for, you know, 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 OLLI 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 talk 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 plug and 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 a head, do something, you know, programmatically as opposed to how do I build my own robot from the ground up or whatever?

Yeah, the software wing of the heart tracker movement, if you will, you know, the fun part. Is that really called Sphero with a head? Yes. That's 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, you know, kind of a rover style interface, you know, forward back left and right.

So you can 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, knows it has a takeoff command and has a land command, you know, 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 lead function, and our drones could be using, you know, a 3D robotics iris could be using an AR drone, could be using a pair of bebop, you know, we're applying these same sorts of principles that, you know, I know web developers are going, yeah, no big deal, right? You know, everyone else is going, wait, you're saying you can use the same code and change two lines of code and be running out on a completely different piece of hardware?

Yes, that's exactly what I'm saying. So that thought is pretty avant-garde 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've boxed ourselves in, we wrote a framework in 2008, 2009, specifically for unmanned aerial vehicles using Ruby and, you know, it'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 like sick languages, it's amazing, but, um, but it was really too early and also it was very limited, it only worked with Arduino's 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, 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, you know, 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 in small groups, you know, that's really where innovation comes from, that doesn't mean that can't happen to big companies, but it happens within those companies and it's not the company as a whole. And we need to encourage also non-commercial types of development, solving problems that maybe aren't, you know, highly remunerative, but they're important for the world, you know, 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 disinheartened of saying, oh, wow, I'm trying to boil the ocean, saying, no, no, no, just boil this one pile of water, it's all you need to do, you know, and somebody else will do their part and so on, you know, 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, you know, right now, there's a lot of companies throwing their hats in the ring of saying, we want to build the back in for your internet of things, you know, 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, and 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, what's the coolest thing you've seen somebody make with one of your libraries, either Sylon, Gobot, or R2, you know, you mentioned you can mix and match all these things and come up with something amazing, does anybody really wow you with something they've done with these frameworks?

Well, some of the stuff that I've seen in particular in education, you know, that's the stuff that excites me personally, I know there's, you know, important or highly profitable or, you know, big money investments in some, but the ones that excite me personally are the ones that I've seen where it's, you know, 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, you know, control their spheroes and their Lego nine storms robots, you know, to navigate this lunar landscape and 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 condom drum, right? It looks really easy to actually try to do it and you're like, oh man, that's really hard, you know?

You're like, oh no, no, no, but to me, that was the most personally exciting is seeing the looks on the kids faces as they grock the concepts of programming, you know, because kids are much smarter than adults ever give them credit for it, right? They don't necessarily have this ability to express themselves in the same ways, they don't necessarily have the same fine mother skills, but they don't need 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 foreign language, you've probably experienced that directly, right? 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, you know, hold a full intellectual conversation where you don't just understand, but you're able to respond and, you know, initiate concepts in the conversation. So watching these kids grab these ideas and turn them into variations of these ideas, they're in real time and the amount of work that they actually get to that, but that 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 know, you can't control it. All you can really do is sort of inspire it and then, you know, 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. You've seen robotics and teaching in these sustained ways out there, as far as things that just, you know, continue to teach as opposed to just get excited and then kind of move on. Oh, yeah, so I was lucky that, I guess the virtue of having, of being a little ahead of people because of life experiences, like I happen to have, you know, my oldest son's a teenager.

You know, if I start 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 Pepper 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 with Cicero complaining about, you know, the youth of the ancient Roman times, you know, it's like, oh, yeah, okay, so, so, like, I'm sorry, I'm going to vote with the delinquents on this one, you know, if nothing else, they're more fun.

But, you know, the idea is that we are unleashing through teaching programming, you know, coming to town and saying, hey, kids, you know, here's this one time thing, we did this kid's code camp was what we called it, you know, we were doing them in 2011, you know, it was literally like a programming circus comes to town, you know, we 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. So Corey Haines, I'm sure you know, Corey, um, so Corey was supposed to come and teach the scratch class. Well, he flaked, no, he couldn't make it because of 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 them to do it. I wanted to scratch and so we were introduced to the 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, God, I'm like, we can't, we can't come to 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. Okay, 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 is like, Oh, this is much better. And he adopted their curriculum and started using it as part of the scratch stuff he was doing. Wow. Okay.

Like that was, that was a magical moment because that was sort of, you know, that's the holy grail of education, the mixed age, peer learning, you know, Montessori style, you know, re learning by teaching and the fact that we were actually able to hit that, but then the programming circuits rolled away. So I know, luckily for us, collectively, when they 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. Uh, code 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 code.org. Where, 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 the program 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 the programmers run the world and they make mistakes, do their 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 who had the same name, but obviously they was a very different gender and, you know, height and age, like, we were looking for an 87 year old woman and this is a 16 year old guy, pretty sure that like, this is a computer error, you know, sort of common sense thinking that does not necessarily occur when people accept, you know, the DAX 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, it's something that all of us would like to know exists in the world. And so, you know, it's, 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 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, you know, the self-driving car error, you know, most of the problems to do the people, well, most of the problems in the world to do the people in programming areas the same. So, it's not about creating a generation of entrepreneurial programmers, I think that's very much of a great hearing. I think it's more about how we create the 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, let's stop here for another quick break here from another one of our awesome sponsors. When we get back, we're on, 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. Outputs of PNG, JPEG, GIF, JPEG 2000 and several other formats. And if you're like me, you've ever argued with your boss or a teammate about serving red and images to non-red devices, you'll appreciate their open-source, dependency-free JavaScript library that allows you to easily use the ImageX API to make your image responsive to any device.

Now, all this takes a platform and the ImageX platform is built on three core values. Flexibility quality, performance and affordability. When it comes to flexibility and quality, ImageX has over 90 URL parameters that you can mix and match to provide an unlimited amount of transformation 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-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 ImageX and what they're all about, head to imgix.com slash changelog. Once again, imgix.com slash changelog and tell them Adam, 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 let's do this.

What do I do? How do I get started? Well, first of all, you're going to 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. If you shouldn't hide these types of addiction, there's gonna be a cash investment probably into some hardware, I guess. Oh, yeah. But the beauty of this, there's a lot of really great kits that combine together some 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 a Grove connectors are a little plug-in type connectors. Those are the one the kits that we used, the GopherCon hackathon.

That way you can assemble some basic circuits without actually having to solder anything just by plugging in the connectors. You know, that makes it a lot easier to get started 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 pure electronics project as opposed to the programming soldering together the whole robot and then programming it, you know, could take quite a long time. And that 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, if you, what you're really more interested in is how can I have some type of programmable device to then, you know, make it do things. The sphero robots are really excellent.

You can get them typically, sphero now has a program called Spark SBRK, where they have a special educational program with heavily discounted. So that's a great way to get a hold of a sphero robot. The, 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 our 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 lead motion, gestural controller, there's a couple of brain-computer interfaces that we have support for the neuro-sky mindwave, and also the muse, which are both Bluetooth electroencephalograms, or EEGs, which are able to read your brain waves.

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. 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 TOS 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, you know, so you go over there and you're like, let's see, hydrogen cell fuel kits, ooh, you know, whole DNA test kits, and of course, pile of robots, pile of robots. Yeah, but these are rock-o-sock-o-robots and they're fully, you know, Bluetooth, low-energy interface, you know, there's a real world, you know, human size or even larger rock-o-sock-o-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 Leemor 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 him an email might be more effective.

Yeah, well, you know, she's got the street cred and, you know, being a New Yorker, I think, she's got the right pit fighter attitude to, you know. But when I was in Tokyo, speaking at Ruby-Kai-D, and 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-Kai-D conference was. I was like, oh, wow, I really want to go see that.

So, went over there, turned out that's the museum where the ASMO is, and, you know, so they're very far ahead as far as developing robotic technology and also adoption of it culturally. But, you know, we've seen a lot, you know, particularly with drones, what, you know, we would call them their own vehicles a few years ago, but not, you know, anything that flies under robotic controls of drone. Yeah, what's the definition of drones at 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. They took our word from us and they ran with it and whatever you wanted to be, right? It's like bad deal with that word, and 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, you know, 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 the 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, flying telepresence with weapons, you know, as opposed to an autonomous robot, you know, the things that you see, for example, in the DARPA challenge, or in the spark fun 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, if it's where swarms or, you know, the brain is safely on earth while the body rolls around the planet Mars, you know, all the curiosity, you know, in 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, the 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 in your drone around your backyard, right? Yeah, well, it's definitely been a blast having you on the call run, I know that it was a great meeting you at Go for Con, loved having you at Hat Week, it was a lot of fun seeing a lot of people in your class, and then you're in your room there, just kind of doing some really interesting things, and what you are doing at the hybrid group for it as well, 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 gonna give a shout out to the late-grade Jim Wierick, 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 review papers and where the last one was, you know, 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 programming, and he was 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 have those same thoughts, we've uh, who was that recently, Jared, who had their hero, was Jim? The Karen Meyer? Karen Meyer?

Oh, Karen's amazing. Okay, well, you know, Karen, 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 fairly recently, and it was really great, because we never actually met up in real life, although we had worked together on some stuff, so it's really funny. All the internet is crazy, but the stuff that she's doing with autonomous drones and the closure language is actually 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, all 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 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, he'd done some really cool stuff with drones, and I was really excited to, um, to make him excited and happy when I showed R2 for the first time at the Los Angeles Ruby conference that was using the Argus Jam that he had worked on, you know, with a bunch of patches, and 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 with 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 him in it, 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, 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 ukulele, true story, um, actually, the same day that I showed him that you could use Ruby for on dandereal 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 a, 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 sneak around and quietly look at what everybody else is doing, because we're all really hungry for new information, 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 really know, that's how he learned so quickly, and he was able to come up with so much, that he meant just a curious mind, and so, you know, let's all be like that, let's all be curious, stay curious, my friends, stay curious, what was definitely a pleasure to have you on the show, I know that I'm sure our listeners have appreciated your passion for hardware, open source, internet, things, creating this software behind some of the best hardware out there, as you mentioned earlier in the show, and the passion you have, you know, for not only Ruby, but go and also JavaScript, and how it can affect the future of these, 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, because you wouldn't listen, we also have awesome sponsors that make this show possible, Code Ship, Op-eat, Harvest, and Imageix, and Ron, I know this has been a long time in the making this show here with you, it was great meeting you, go for Khan, look forward to seeing you further out there in the open source for 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.

Well, bye guys, that's the way I do it.