Show Notes

Transcript

 

[This episode is sponsored by Hired.com. Every week on hired they run an auction where over a thousand tech companies in San Francisco, New York, and L.A. bid on Ruby developers providing them with salary and equity upfront. The average Ruby developer gets an average of 5 to 15 introductory offers and an average salary offer of $130,000 a year. Users can either accept an offer and go right into interviewing with a company or deny them without any continuing obligations. It's totally free for users. And when you're hired, they give you a $2,000 signing bonus as a thank you for using them. But if you use the Ruby Rogues link, you'll get a $4,000 instead. Finally, if you're not looking for a job but know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept the job. Go sign up at Hired.com/RubyRogues.]

[Snap is a hosted CI and continuous delivery that is simple and intuitive. Snap's deployment pipelines deliver fast feedback and can push healthy builds to multiple environments automatically or on demand. Snap integrates deeply with GitHub and has great support for different languages, data stores, and testing frameworks. Snap deploys you application to cloud services like Heroku, DigitalOcean, AWS, and many more. Try Snap for free. Sign up at SnapCI.com/RubyRogues.]

[This episode is sponsored by DigitalOcean. DigitalOcean is the provider I use to host all of my creations. All the shows are hosted there along with any other projects I come up with. Their user interface is simple and easy to use. Their support is excellent. And their VPS's are backed on solid-state drives and are fast and responsive. Check them out at DigitalOcean.com. If you use the code RubyRogues, you'll get a $10 credit.]

CHUCK:

Hey everybody and welcome to episode 247 of the Ruby Rogues Podcast. This week on our panel we have Jessica Kerr.

JESSICA:

Good morning.

CHUCK:

Coraline Ada Ehmke.

CORALINE:

Hello.

CHUCK:

I'm Charles Max Wood from DevChat.tv. Go check out RubyRemoteConf.com. This week we have a special guest. And that's Ray Hightower.

RAY:

Good morning, everyone.

CHUCK:

So Ray, you haven't been on the show before. Do you want to introduce yourself?

RAY:

Sure. Thanks for having me. My name is Ray Hightower as you said. I run a software company called WisdomGroup. And my team and I, we run the Chicago Ruby Users Group and a couple of conferences. We run WindyCityRails now in its ninth year and a brand new conference called WindyCityThings that's all about the Internet of Things.

CHUCK:

Oh, that sounds fun. I'm actually going to be out in Chicago this summer. So, I'll have to hook up and we'll grab lunch, you and Coraline and anyone else out there.

RAY:

Absolutely. With ChicagoRuby we're doing six events every month.

CHUCK:

Oh wow.

RAY:

So certainly you could come hang out there or we could grab coffee, drinks, lunch, whatever. There are a lot of options here. Lots of activity, man.

CHUCK:

Yeah. Now that I'm talking about it, I know people are going to wonder when. It's the week after the fourth of July. I'm going to be out there for Podcast Movement. And I usually try and book a little bit of time, get in the day before, and leave in the afternoon the day after, so I have plenty of time to recuperate because I kind of go crazy at conferences and meet as many people as I can and spend a bunch of time. So yeah, so that's what I'm…

CORALINE:

I will get mad at you and take it personally if we don't hang out, Chuck.

CHUCK:

Yeah, we should.

CORALINE:

I'm just saying.

RAY:

You're a networker. You're a true networker.

CHUCK:

Oh, it wears me out but it's a lot of fun.

RAY:

Yeah.

CHUCK:

Alright. Well, we brought you on to talk about the Parallella. And I think we all looked at it. Do you want to give us a quick overview of what it is?

RAY:

Sure. I'll share a little bit about Parallella. Parallella is a single-board computer roughly the size of the other single-board computers that are out there on the market, roughly the size of a Raspberry Pi or a BeagleBone Black. Roughly the size of a credit card. And the difference between the Parallella and the other single-board computers is that it has 18 cores. So, it's a great way if you're a developer and you want to explore Parallelism and some other things, I'll talk about some other features maybe later on in the podcast, but if you especially want to explore parallelism and learn that it's a great way to do it. And it's a very inexpensive device for learning that kind of stuff.

CHUCK:

Now, you mentioned the Raspberry Pi which I think mine has two cores in it maybe.

RAY:

Yes.

CHUCK:

So, why 18 cores?

RAY:

Oh yeah, why? Because [chuckles] why overkill, right?

CORALINE:

More is obviously better. Come on.

RAY:

Yeah. [Laughs]

CHUCK:

Yeah, that's right. 18-lane highway, 2-lane high-… no, anyway.

RAY:

And sometimes there's the law of diminishing returns at some point, right? The reason we wanted a device with 18 cores, the reason my team at WisdomGroup, the reason we started exploring it is because we began working with some clients, some computer engineers, some high-end electrical engineers, computer engineers that are designing and developing and building the next generation of supercomputers. And networking with machines that have a hundred thousand cores or a million cores. And we wanted to, in the work that we do for them we're not going to be at their level. They're high-end PhD engineers doing some awesome stuff. And what we do want to do though is we want to know enough about what they do so that we can serve them better. I think about, the metaphor I like to use with this is it's as if they're medical researchers studying the latest diseases or the deadliest diseases that affect humans and then they hired WisdomGroup to build microscopes. We don't necessarily understand everything they're looking at through the microscope but the more we understand about what they want to see and what they want to examine, the better we can serve them.

CORALINE:

So Ray, you're primarily a web developer, is that right?

RAY:

Yes, yes. We do web development. We do some mobile but mostly web.

CORALINE:

So, what was it like for you to dip into the hardware world as a web developer? It's normally something like, we don't really care about bare metal very much.

RAY:

Oh yeah. That is so true, because it's all abstracted away. You've got the layers. You've got the OS and then you've got the language and all of that. A lot of my background is in hardware. One of my jobs, goodness it was over 30 years ago, I used to work in a digital lab in Colorado a long time ago where I was riding Assembly-level software for a bunch of electrical engineers who were designing hardware. And I really got into it, all the things with the gates. Boolean algebra has not changed in over a hundred years. I've always liked the hardware. I've always been interested in it. And then I also have the attention span of a two-year-old. So, I bounce around back and forth between all this stuff. But for any web developer, for us, it's one more thing to learn and one more thing to explore.
And it's always interesting to do something new and different, right?

CORALINE:

Oh, definitely, yeah.

RAY:

Oh you know, one other cool thing to get more to your point Coraline, this blew me away when I first learned in Ruby that you could do state machines. I think there was a gem called 'acts as state machine'. I don't know if that's still…

CORALINE:

Yeah, AASM still around.

RAY:

Yes, yes, yes. Still around, okay. Blew me away because when I learned about state machines we did them all in hardware. We did them all with gates. This was back in the early to mid-80s and that type of thing. So, it blows me away that now the hardware is fast enough that you can implement a state machine in software. So, they inform each other and they feed each other. And the more you learn about one the more you learn about the other. And that's kind of cool.

CHUCK:

Yeah, I remember doing state machines in college and I was an electrical engineering major. And so, it was again done in hardware. And you would wire, yeah like you said, you'd wire up the gates. And yeah, you would make it so that those gates would basically trigger the logic to get to the next stage.

RAY:

Very cool to know you have a EE degree. That is, I took some EE classes. That's a tough curriculum. So, much respect to you for that.

CHUCK:

Oh, I changed my major. I went into computer engineering. So, then we got into…

RAY:

Okay.

CHUCK:

chip design and stuff. But…

RAY:

Yeah, yeah.

CHUCK:

The initial stuff was all gates. And the way that you build out your chips is all based on that same logic. You're laying out transistors to form gates that form basically logic circuits and memory circuits.

RAY:

Yeah. You know what? Since you started talking about logic circuits and memory circuits, I should talk about one other feature of Parallella that I haven't covered in any of my presentations or any blog articles yet. I'm in the middle of writing a blog article about it. Parallella includes a fieldprogrammable gate array.

CHUCK:

Oh, wow.

RAY:

Yeah. [Chuckles] Right?

CHUCK:

That's awesome.

RAY:

And you know, this is on this device. We've spent the past several months exploring the parallel aspects of Parallella. But the FPGA, what's so exciting about that is any logic that you can implement with gates, NAND gates, OR gates, AND gates, whatever, you can implement in an FPGA, field-programmable gate array. And since it is field-programmable you write code to implement the gates. So, you can change this, the configuration of the hardware using software. And the reason why that's so cool is anything that executes on hardware is going to be faster than the equivalent task executed in software.

The challenge with software is that you got all these layers of the stack you have to go through. First you go to the hardware. Then you go to your OS, Linux, Windows, whatever. Then you go to your, maybe you go to your interpreter if you're doing Ruby. Then you go to your application code and then the libraries are called and all that. And some decision is made. And then you turn around to go back through that same stack to give the feedback through the hardware, the output in response to the input. So, all those layers you go through the stack. And so, software is slower. Hardware, what's so awesome is that your speed is only limited by the progression of the signal through the silicon. So, it's so much faster.

And then the drawback though is FPGAs are probably tougher to program. One reason we have high-level languages is because it's easier for us as humans to wrap our heads around them. But you know, trade-offs with anything. So, when you mentioned gates I said I have to mention the FPGA on the Parallella. And we're working on some articles around that. The first article around that should be out early next week. We're putting some stuff together around that.

CHUCK:

That's really exciting. Now, I really want one. [Chuckles]

RAY:

Yeah, yes. Yeah.

CHUCK:

But yeah, I remember doing homework in college and basically programming logic progression through FPGAs. And so, you'd load the program in. it would line up all the gates and then you would send your signals through it. And [chuckles] that was debugging as you send the signals in one end and you see what you get out the other. And it better be right. But…

RAY:

Yeah, yeah. And my stuff was never right the first time. [Laughs]

CHUCK:

No, no.

RAY:

And you know what was so cool, you mentioned doing that in college. There's so much… all of you have done this. We've done this professionally, but in college too. College was the first time where we really got into it where you're staying up and you're working on… and maybe you're programming your FPGA or maybe you're working with a breadboard and a bunch of discrete integrated circuits. And you're plugging them into the breadboard. And you've you your pull-up resistors and your LEDs or whatever. And there's so much camaraderie that's built up around troubleshooting. It's like the shared misery. It's the same camaraderie we have when we're writing software together, right? This shared doing this battle, this battle against the problem. And our brains come together. And it's so cool that when multiple people are working together, that it's almost like the team gets smarter when we're all working together. That's so cool.

JESSICA:

Absolutely. I think we totally learn best when we're learning together, not learning from someone who's way ahead of us but learning from someone who's right next to us.

RAY:

Yes, yes.

JESSICA:

And then you build connection and you build hardware and you build knowledge in your brain all at the same time.

RAY:

Oh, it's so cool. And you know what's so… here's something that's weird and you've probably experienced this. Sometimes you're working on a team and you're thinking through some problem. And it's almost like there's some type of telepathic connection sometimes, right? Okay, now you're looking at me like I'm crazy. Alright, okay. [Laughs]

JESSICA:

No, I agree. It is. It's because you have so much shared context that you can find the solution together. And sometimes you look at each other and it's almost like you transmitted it.

RAY:

Yes, that's… okay. Cool, I'm not nuts. Thank you. [Laughs]

CHUCK:

[Laughs]

JESSICA:

[Way to] save me, Jess. [Chuckles]

CORALINE:

I was thinking how interesting it was. It's the same way that you and Chuck getting nostalgic about hardware hacking, it's sort of taken as a given that if you're in software you have a background in hardware. And I don't think that's universally true. But I'm interested in knowing what that meant for you in your progression as an engineer. Do you think having the hardware to begin with informed the way you programmed? Or is it just like, you just had a general interest in technology? Or how would you explain that?

RAY:

You know, that's a good question. Does the hardware background inform software? I think in my case it does. At the same time there's some cool stuff happening in the software field right now that I've never seen before. I've been in and out of software development for 30+ years. I started in '82. So, I've been in and out of it. And in the old days it was like you said Coraline it was almost taken as a given that you had some background in hardware before you started doing software. But what's happening now, there are a lot of people coming to software development who have professional skills in other areas. And so, their experience as software developers is informed by that background in a way that's different from the way my hardware background is informed.

A great example. One of the organizers on the ChicagoRuby team, a guy named Doug Harman, and I’m trying to get him to give a presentation about this but he keeps telling me no, but Doug Harman spent 40 years as an investment professional selling financial instruments, financial tools to people and families who want to invest their money. And then he decided that he saw a need in his industry. So, he went and began learning Ruby on Rails. This guy is in his late 60s, early 70s, began learning Ruby on Rails and has gotten pretty good at it, has written an app that meets the needs of his colleagues in the financial services industry. And what's remarkable about Doug is he's using his background in a totally different profession, four decades of experience, to inform what he does as a software developer. And the code that he's writing is highly informed by that. And it fits very much the needs of the people that he's serving, with the app that he's writing.

So, I think bottom-line, to answer your question, I think no matter what you do it's going to inform what you do as a developer. And I never would have thought this 10 years ago, 20 years ago. But I'm seeing this and it's remarkable to me that you can come from another profession or a totally different field and come to software development with a new take and a new view. And you're adding value to the software development profession as a result. And I think that's cool.

CORALINE:

Yeah, absolutely. I wanted to point that out for a couple of reasons. First of all, coming from a nontraditional background myself I want to support other people who like you're saying have come, either switched careers, are coming from a different field, or who's interested [not to] start out being software related. The other thing I think that we kind of are in danger of doing sometimes is putting people who were hardware hackers up on a pedestal and kind of saying it's a no true Scotsman thing. Like, you're not a real geek unless you actually played with hardware. So, I didn't feel like that's where we were going with that conversation. But I did want to point out that not everyone has that background. It's really cool if you do and a lot of really important people have had that background. But not everyone does. And we should celebrate wherever we've come from and however we arrived in software development and the impact that we can make today.

CHUCK:

Yeah.

RAY:

Yeah, agree, yeah.

CHUCK:

I just want to…

JESSICA:

Right.

CHUCK:

Back that up. It does help when I run into issues with say memory and memory management or figuring out exactly how the floating point arithmetic actually happens. Sometimes it helps out there. But for the most part software is just another medium that I use to get work done. And it doesn't inform every day. So, the education that I got about how things work and how processes work and how things progress from one state to another, and those kinds of things that I learned in college, those definitely help. So, the hardware background… but that's more about thinking about problems and not necessarily about having a background in hardware. And the hardware direct knowledge really only comes in when I'm looking at, “Okay, how is this actually being executed down in the core?” Or, “How is this actually being thought about here, there, or somewhere else?” And otherwise it just, it doesn't make a huge difference for me.

JESSICA:

Right.

RAY:

Yeah.

JESSICA:

The best teams that I've been on had people from all the perspectives. You have someone who's a performance geek and someone who has a good background in the same industry the users are in. And someone who's got something else completely random. Because software is about communicating with computers and also with people. And frankly computers are the easy part.

CHUCK:

Yeah.

CORALINE:

Yes, absolutely.

JESSICA:

But on the other hand, like Chuck and Ray were saying, a little bit of familiarity with hardware can go a long way in giving you a vocabulary and sort of a perspective. And that's kind of where the Parallella comes in as a source of play and learning, right?

RAY:

Oh, yes. And I'm glad you used the word play, because I talked about why we started working with Parallella. And I talked about our clients and what we're doing. But bottom-line, I love playing with this stuff. [Laughs] I just… [Laughs] It's a lot of fun. Even when… I'll give an example. Yesterday I was experimenting with getting the whole FPGA thing going. And there are a bunch of gotchas. And I try to write in the blog articles where the gotchas… I like to say, I write about the gotchas that got me so they don't get you. And even in doing that it's like wrestling or it's like doing any kind of sport. Yeah, it's play and it's learning and all of that stuff. That's what I would say about it.

CHUCK:

So, what are you learning then? Because a lot of this play is usually, “I want to learn more about this,” or, “I want to do more with that,” or, “I want to understand these principles better.” So for you, what are you learning from playing with Parallella?

RAY:

You know remarkably, some of the things I'm learning I didn't expect. Like I'm learning a lot more about Linux that I didn't know and how Linux behaves. Even coming down to things like setting up partitions, because one of the big barriers to people getting started with Parallella is just getting the thing set up. The documentation, and I've spoken to engineers at the company at Parallella, they'll tell you in a second that when they write a lot of the documentation they skip over a bunch of steps. They're just doing stuff. They're skipping over a bunch of steps and they're skipping over prerequisites that are required. And I'm learning about a lot of things that are beyond parallelism that are different.

An example from yesterday is working with the FPGA, the official instructions tell you the steps you go through to set up the FPGA. But what they skipped over is that there are some dependencies you need to install on the Parallella first, like a library called Verilog that is a hardware description language.

CHUCK:

Oh, Verilog. [Laughs]

RAY:

Yeah, right? Okay, so you're familiar with that.

CHUCK:

Yes.

RAY:

Verilog didn't exist when I was involved in hardware. We used graph paper and pencils. [Laughs] So, I'm learning a lot about things like Verilog, hardware description languages. I'm learning about dependencies, dependency relationships in code which determines whether or not the code that you want to parallelize is in fact parallelizable.

This is something that we talked about a few days ago, the difference between concurrency and parallelism. Bluntly when I first bought Parallella, you know what I told people? I said, “Yeah, I'm buying a Parallella so I can learn about concurrency.” But those are two different things. I should share with you for the show notes, there's a video that Rob Pike, one of the creators of the Go programming language, his video. It'd titled 'Concurrency is not Parallelism' where he talks about the difference between the two. So, the biggest thing that I'm learning are things that I thought I know but really I don't know.

CHUCK:

That's interesting. I'd be really curious to hear that. Because in my head they're kind of the same thing too, right? You have parallel processes and so you can do concurrent programming because they're running at the same time.

RAY:

Yeah. That's what I thought. And I like the way Pike describes it. I've gotten to the point where I

kind of summarize it in my own way. But Pike does a much better job in the video. But if you look at concurrency versus parallelism, an example of concurrency would be if you think back to early personal computers where you had one processor and you had an operating system going through this event loop, just an infinite loop that's going through and looking at the behavior of all of the hardware attached to this [processor], looking at “Has a key been pressed on the keyboard? Has the mouse moved? Has a button been pressed on the mouse?” Looking at all the inputs. And it's looking at them one at a time over and over again through this infinite loop, through this event loop, that it's looking for all of these events. And to humans, because the computer is doing this very, very quickly, it looks like these things are happening concurrently.

But if we're writing operating systems, you take an operating systems course, this single-processor machine is only looking at these things one at a time. So, concurrency is an illusion. I'm the only person that I know that's been saying it that concurrency is an illusion. And if I'm saying it wrong, I invite the internet to correct me. Oh, boy.

[Laughter]

CORALINE:

That's a dangerous thing to ask for, Ray. [Laughter]

CHUCK:

Yeah.

CORALINE:

It's a dangerous thought.

RAY:

It is.

CHUCK:

So, I took those operating systems classes that you're talking about. And I remember writing interrupt handlers. And yeah, it works exactly as you say. The other thing is that it does feel concurrent when it does the round-robin scheduling that we're pretty used to where it stops for whatever reason or it runs the program for a certain length of time and then it says, “Okay, who needs a turn now?” and then it runs it. And so, it feels like it's doing multiple things at once where in reality on each core, it's just giving each one a time slot and making it work through it.

RAY:

Yes. It's slicing up the time. And yeah, that's exactly what it's doing. So, that's what concurrency is doing, yes.

With parallelism you actually have multiple cores that are doing things at the same time. And a good example in pretty much all of our laptops, I don't think there's a laptop sold today that doesn't have some type of video accelerator. And if you look… the laptop I use is three years old. I use a three-year-old MacBook Pro. And on this, and I didn't know this until I started researching it, you go into About This Mac and dig into what's going on with the hardware. The NVIDIA video card on this MacBook Pro has 384 cores. I'm like, “Wow!” Who would have thought, right? You think back to what a supercomputer used to be, 300 cores, that'd be like millions of dollars or whatever. So, it blows you away. But that's an example. Parallelism is happening there because you have all of these things happening at once. So, that's a distinction. Those are definitions that I didn't understand.

And in experimenting with Parallella my team and I, we're getting more to the point where we can grok that internally, right? And it's going to help us with other things that we're writing. For example one of the things we do on Parallella, getting Ruby, getting Rails up and running on that, and wouldn't it be cool if there was some type of application where it interacts with the humans via the web interface? Because the web is a wonderful place for human interaction. And on the backend you've got whatever parallel processing is going on. Say, if you need to control some sort of robot or whatever.

JESSICA:

But you said you were running Rails on the Parallella?

RAY:

Yeah, yeah, because here's what's going on. I mentioned the 18 cores. So, let me back up for a second. The Parallella has two ARM cores and then 16 of what they call Epiphany cores. And it treats the two ARM cores, the two ARM cores kind of behave like a Raspberry Pi, right? So, if you ignored these 16 Epiphany cores, they're RISC (reduced instruction set computing) cores, if you ignore those than you just have a Raspberry Pi. Just as you can run Rails and Ruby on a

Raspberry Pi, you can run Rails and Ruby on a Parallella. So yeah, and so one…

JESSICA:

Does a Raspberry Pi have one or two ARM processors?

RAY:

Yes. It depends on which model Raspberry Pi. Like Chuck has a Raspberry Pi with two ARM cores on it, yes.

CHUCK:

I have the one and the two. And I don't remember which ones have what.

RAY:

Yeah.

JESSICA:

So, how do all those other cores help you in Rails?

RAY:

Well, that is one of the things that we're experimenting with. I hope to have better answers for you on that. So far, everything that we've done with the parallel cores, with the Epiphany cores, we've done in C because that's what all the documentation is. And that's how we're wrapping our head around it and that type of thing. But one of the things that we're working toward is the idea that you've got your web interface that's facing the humans and Ruby can call C programs. Ruby can communicate with C programs. So, it makes sense to me that we can do something with the Epiphany cores. And we have to come up with a… we're coming up with some demos. We're playing with some demos about how we'll do that. I'm speaking at a conference called ConFu in a couple of weeks in Montreal where I'll share some of that. So, we have some interesting demos there. And now the challenge is figuring out which one we want to do, which one's going to appeal most to people, that people would be most interested in.

CHUCK:

That's cool. It's interesting because we perennially hear the issues with Ruby, where it has the GIL so it can't do native threads. So, it can't take advantage of multiple processors. So, how do we get around that? It's interesting that you're working around that with C. I'm wondering just if there are other better ways. We've seen stuff with the Actor model for example where maybe you could do that or do stuff with remote procedure calls or some of the other…

JESSICA:

Or JRuby.

CHUCK:

Or JRuby.

RAY:

Yeah, possibly. We tried last year. Was it last year? Maybe it was six months. Maybe about six months ago, Zach Briggs and I were, we were at a hack night, a ChicagoRuby hack night. And we were working on getting Rubinius going on the Parallella. That was longer than six months ago. This may have been a year ago. A year or a little bit longer. We were working on getting Rubinius going on Parallella. And we ran into a bunch of issues like the standard shell on Parallella is something called TC shell that I had never heard of. And I'm accustomed to bash, coming from a Mac environment. I'm accustomed to Bash. And we use Bash on Ubuntu. And so, we weren't able to get Rubinius.

But I'm wondering about JRuby there, like you said Jessica. Maybe JRuby. There are some other options that we're looking at. But the first one, you kind of go in stages. Our first stage was to do everything in C because that's where all the documentation is and that's where we can start to grok just the basic, the foundational idea of parallelism. And then I think, “Whoa, okay. It's cool if there's… maybe you have a web interface.” And maybe what's going on in the backend, that's communicating with C. And the parallel portions of your application are running in C. So, your web app is talking to this C app. The C app's running on Parallella.

An example of that, like here's one thing that we're playing with now. The examples that I've done in several presentations recently was showing how prime numbers can be calculated very rapidly when you do them in parallel, when you split the work up amongst 16 cores as opposed to just trying to do everything on one or two cores. And so, maybe we have something where there's a web application that needs prime numbers calculated or it needs some image processing done. There are image processing examples because image processing, that's an application that can be readily divided up into tasks that are parallelizable.

CORALINE:

So Ray, we shared a stage together at Madison+ Ruby last year and you gave a talk about the Parallella. And you talked in detail about the experiment you ran with generating, or with finding prime numbers. Can you talk about what that process was like for your team?

RAY:

Oh, yeah sure. It was one of the things that we wanted to run to see if this idea of parallelism would work. And it's not just… one of the things we were fortunate, we brought on board an intern last year. His name is Thomas Malthouse, a real bright young man who helped us with a lot of that, who knows C and was very instrumental in helping to get that running. And what we're doing is, the source code for that… you know in fact, everything about Parallella and really most of the singleboard computers I'm working with, everything's open source. If you want to see the source code, if you go to GitHub.com/parallella and I think the subdirectory is parallella-examples, you'll see all of the examples or a lot of the examples that we were working with. And we made some modifications just to make them work more with what we're doing. But yeah, the examples are right there.

What was remarkable, what was fun with doing the prime number example, when we first started working with that we were getting inconsistent results between the calculations done in serial versus the calculations done in parallel. We'd get one set of numbers on serial and one in… and that's not how it's supposed to be.

CORALINE:

What was going on with that? Yeah.

RAY:

Well, because what's so funny. If you have an off by one error on a single-core machine, you have an off by one error. But if you have 16 cores you have an off by 16 error.

CORALINE:

Oh, man.

CHUCK: Wow.
[Laughter]

RAY:

So, bottom-line is, so it was kind of fun wrestling with that kind of stuff. Off by one errors are multiplied by the number of cores and things like that. And then you have to look at dependencies. And one of the reasons we wanted to look at something that is basic like looking at prime numbers is because you can wrap your head around the idea of calculating prime numbers. Just put that in your brain, hold that in your brain. And we use Ruby as a way to think about the algorithm that we wanted to use, right? Just because real quick feedback loop. So, that's what we did.

So, the process… it actually took a couple of days to come up with something that worked the way we wanted it to. We based it on the examples that are, like I said in the GitHub repo for Parallella. We based it on that. And we added a few things just so that when the results are printed out you can see exactly what's going on and so that people on the stage know what's going on and which core is doing which calculations and all of that. But yeah, you asked about what the experience was like. It was [chuckles] it was troubleshooting. And I'm glad we started off doing something relatively basic like prime numbers because it's easier to grok.

CORALINE:

Sure.

RAY:

Some of the other examples that we've experimented with, like there's something called the, from physics… I guess it's astrophysics. Yeah, I guess it's astrophysics. Something called the n-body problem. And it may apply to other areas of physics but it's the idea that you've got these planets and stars in orbit around each other. And if you have thousands of them how do they behave together? Because they're in orbit around each other but not really. They're really in orbit around a common center of mass. And that common center of mass is calculated through summations. Like vector summations, vectors in three dimensions. And so, the parallel examples include an n-body example, n-body problem example, which is really cool. There's a Mandelbrot example. I'm still wrapping my head around some of the uses for Mandelbrot plots and all that stuff. But it's cool to explore those. So, that's what we do.

CORALINE:

Very cool. So, the Parallella is pretty approachable as a hobbyist. If someone was interested just in playing around with parallel computing they could… like, how much does it cost and what's the



real… what do you need to do to get started?

Okay, yeah. If you want to get started with Parallella you can buy it on Amazon. There are two versions. There's a version that's called the server version that just includes the Ethernet and power and a place for the SD card to go in, no HDMI, no USB, and that's like 99 bucks. I prefer the version that includes the HDMI, USB, reason being… you can SSH into it but I think when you're starting off with it and even after you've started off with it, I'm more comfortable with working with Parallella when I can attach a video device to it and attach a keyboard/mouse directly to it. And that's 150 bucks. And they're selling them on Amazon now. So, I'd take a look there.

And the hardest part is when you're just getting started with it, is making sure that the SD card you need with the operating system, make sure that's burned correctly. And I ran into a bunch of headaches with that. And after I got past those obstacles I put those together in an article that's called 'Parallella Quick Start Guide (with gotchas)'. And that's at my blog at RayHightower.com. And I included a bunch of pictures in there because the documentation… [Inaudible] I was going to say, the hardest part is like the documentation is written by hardware engineers who know the device intimately. And as you know, if you know something intimately it's harder to write about it when you're introducing someone to it, right? So, there are steps that we skip sometimes, right? And it's not… it's good stuff. But there are steps skipped in all of that.

And they'll rarely do that. But I tried to include some of these steps that are skipped in each of the articles and all of the… in addition to that first intro guide, the subsequent articles, I try to include some things that tell you about steps. Like even, another Parallella article that I have on my personal blog, other ones, when we talk about going through the examples, you know how in the Ruby community if you're using a gem or you're starting someone's app if you just get on a project, always in the readme file there are detailed instructions on how to get the app running on your own machine. And those instructions are always good and correct.

CORALINE:

Oh, absolutely. Never a problem. [Laughter]

CHUCK:

Yeah, every time.

CORALINE:

In fact, most people focus so much on the documentation they forget to do functionality. [Laughter]

RAY:

Right, yeah. Alright. And you know, when people miss things in documentation, it's never malicious. It's just we all get busy. And then we end up doing… Kathy Sierra said this so well. She has this acronym, COIK for Clear Only If Known. C-O-I-K, COIK.

CORALINE:

Love that. That's perfect.

RAY:

Yeah.

CHUCK:

Yeah.

And it just, it just fits. So, the hardest part of getting started with Parallella is dealing with the COIK factor. The forum is pretty good. There are other people just like me, people all over the world who are experimenting with this who when they run into gotchas they put their info in the forum. That's at Parallella… I think it's forum.parallella.org. Or if you go to Parallela.org there's a link to the forum. Sometimes links change and all that stuff. So, the hardest thing is really making sure you get the SD card burned. And I tried to, in my guide, to include a lot of that. Actually as I look at my guide, there are a few things in my guide that I know I need to update. So, it's due for an update. But I'm running around working on FPGAs now. So yeah, there you go. I'm guilty, right?

And then the other thing is you need to make sure that you either have a fan or you use the heat sink. They are now shipping the Parallella with a heat sink because it gets hot. It's the hottest of all of the single-board computers that I've worked with. I've worked with Raspberry Pi, BeagleBone, all of those. So, it gets hot. So yes, to answer your question [laughs] after that long answer, to answer your question, I would look at some of the guides that are out there with details and photos and screenshots and all that. And once you get that SD card up and running you'll find that any documentation that you find online that deals with Ubuntu Linux is helpful with the Parallella also.
So, there's a lot of documentation that may or may not be labeled exactly like that.

CORALINE:

Okay, cool.

RAY:

How about you? Are the three of you, any of you planning to start exploring this? You're all so busy. I look at all of you, I see what you're doing out in the community. You're all so busy doing all kinds, you're flying all over and speaking and doing stuff. What are your plans with single-board computers or Parallella? What do you think you'll be doing?

CORALINE:

I played a lot with Arduino years ago. I haven't played with Raspberry Pi or the Black bone or anything like that. When my daughter was little we did a lot of hardware hacking because I was trying to get her interested in programming electronics. But now she's all grown and doesn't want anything to do with any that. So, it's a little bit harder for me to be a hobbyist with that stuff now. But I'm interested. I had a lot of fun with the Arduino. And I think I could do a lot with… I've thought about Raspberry Pi's for Sonic Pi. I thought that was really fascinating. So, I don't know. There's a chance I would play with it.

RAY:

Yeah. I think all of you would be great with it. You've all got experience in other areas that would, it would make the community stronger. The Parallella community is dominated by hardware people right now, hardware people who do some software. But when I look at stuff that you're doing… you know Jessica, every time I look at you I think about a talk you did years ago about Git.

JESSICA:

[Chuckles]

RAY:

And it was like…

JESSICA:

[Inaudible] Git happens.

Yeah. Git happens, and you were doing a bunch of those. And then I was like yeah, “It's so cool.” And I think about all the areas, all three of you, all the things that you've done in software, the Parallella and the parallel computing community in general could use a lot of your insights. Because like I said, a lot of people are doing, are hardware engineers who do a little bit of software on the side.

JESSICA:

There's a point you made Ray about how the documentation was made by engineers who know the hardware intimately, which makes them the worst people to write the documentation for someone who doesn't know anything about hardware. And then you've come along and other people who've made guides that are more accessible to people with your backgrounds. And you do have some hardware background. This is an opportunity for anyone who doesn't know anything about hardware but would like to acquire the vocabulary, there's a need for people who know very little about this to write about it. The less you know, the more you can contribute to the community by learning a little bit and then making that bit accessible to more people who come from the same lack of background that you have.

CORALINE:

And that's something, I give a talk on getting started in open source. And one of the recommendations I make is that people start with writing documentation. Because not only is it a great way to familiarize yourself with someone else's source code but no one seems to like writing documentation. So, if you come in and write documentation for someone else's project, you're instantly a hero.

RAY:

Yes. [Laughs] Yeah.

JESSICA:

Yeah. And you're a hero to everybody who uses that documentation, because if you were confused by something, oh my gosh, so many other people are going to be confused by that. And you can really help.

RAY:

Yeah.

CORALINE:

Yeah, definitely. It's good citizenship.

RAY:

Yeah. The point you just made Jessica is right on. It's like it's right on. It's like if you have a background away from that, away from the device, you can become a bridge. And we need a whole lot of bridges at once. Maybe we're not individual bridges. Maybe we're individual girders or something. And together we form a bridge. I don't know. You get the metaphor. I'm still constructing the metaphor, but you know. [Chuckles] You know.

CHUCK:

You're constructing your bridge metaphor with girders?



RAY:

Yes.

[Chuckles]

CORALINE:

That's riveting, let me tell you. [Laughter]

RAY:

Oh you know, that's just what we need. More puns in computer science. [Thank you, guys].

CORALINE:

Yeah.

CHUCK:

Yeah. Now we have to convert them all to acronyms. I'm going to be busy for the rest of the week.

RAY:

[Chuckles] Right, right.

CHUCK:

So, my question is, what exactly are you doing with the Parallella? Because it seems like a lot of people are playing with it. They're figuring out what it can do. But are people actually solving realworld problems out there other than prime numbers?

RAY:

Right now the primary real-world problems that I see people are solving are they're using it as a tool to teach parallel programming to the next generation of developers. For example there's a prof at West Point, Professor Suzanne J. Matthews, who's writing some great documentation on how to get started with Parallella and how to… she's got dot product examples that you might use in physics for vectors and that kind of stuff. And I see it mostly, it's mostly the real-world uses I'm seeing are as a tool to teach parallel programming to the next generation of developers.

I think it could be useful for driving robotics. And I haven't seen anybody doing that yet. And I think it's because the people who know robotics don't know parallel programming. And the people who know parallel programming don't know robotics. But I think there's a way to bring those together.
Then it'll be [inaudible]. Yeah.

JESSICA:

Yeah. You can make like an octopus robot.

RAY:

Yeah.

JESSICA:

Because octopuses, I'm a little obsessed with octopuses, they have a very distributed nervous system. So, each tentacle can sort of think independently. So, the Parallella would make a great octopus robot.

RAY:

Oh! Yeah.

CHUCK:

Well, if any of you figure that out, I am putting on a Robots Conference in August.

RAY:

Oh, in August. Is it online?

CHUCK:

Online, yeah.

RAY:

Oh, yes. I'm kind of annoyed with the acronym IoT because you see it all over the place. But now we all know what it means. There's a lot of potential there. It feels kind of like the web in 1993, 1994.

CHUCK:

Mmhmm. Yeah, but you…

RAY:

And…

CHUCK:

You saying that it's kind of out there and people know what it is, people in the industry know what it is. Like I'd go to a Toastmasters group every morning. In fact I was there this morning. And we do a section called table topics where we just do impromptu one to two-minute talking about whatever the topics master gives you. So, when I did it I tried to explain what Internet of Things was and tried to explain to people, what would you put a computer into? And they were totally lost on it, both the concept and the term.

RAY:

What were their backgrounds? The people in the audience.

CHUCK:

Oh, they're in all kinds of stuff. Concrete or construction, a few of them are computer people, one of them is a hairdresser. But yeah, it just went over just about everybody's head.

RAY:

Yeah, okay. You know what…

CORALINE:

[It's like] explaining the web to someone in '93 and '94.

CHUCK:

Yeah.

CORALINE:

And you'd have the same phenomenon.

CHUCK:

Exactly.

RAY:

Yes, okay. Yeah, so there's plenty of time to be an early adopter, right?

CHUCK:

Mmhmm.

RAY:

Yeah, so that's one of the things, we'll talk about it in WindyCityThings this year. The people that we've got involved with that, one of our partners with that is an organization in Chicago called BLUE1647. And they're doing amazing things teaching kids about Arduinos. And they're doing Arduinos for hardware. And they're doing Java and Minecraft for software. And they're introducing this to kids, like preteens and all that. So, they're working with us on the youth program for WindyCityThings. So, that's… yeah, there's a lot to learn in that area. And there's stuff that still needs to be invented there.

CHUCK:

Alright, well one more question that I have, and this is more about Internet of Things rather than Parallella. But I guess it could be about Parallella. But mostly I'm just wondering. Where do you see Internet of Things going within the next say five years? And where does Parallella fit into that?

RAY:

I think, where would the Internet of Things go in the next five years? Hard to say exactly five years out, but I think the direction we're heading in is a direction where these devices that we still call computers, they will disappear. And what I mean by that, it's kind of like when you look at an automobile. If you ask the average person on the street, how many motors do you have in your automobile? Someone might say one. Under the hood you got a motor. But when you think about it, you've got the engine under your hood. You also have a motor for each of your powered windows. So, that's four more right there. Under the hood rarely are fans, rarely are cooling fans driven by fan belts anymore. Those are technically driven by an electric motor. So, that's six. You have a motor for your sunroof. You have a motor for the oscillating fan for your HVAC that's in there. But we don't think about those because they're so embedded in the system that all of those motors have disappeared.

CHUCK:

Mmhmm.

RAY:

And I think that with IoT, when we know IoT is really taking off, a lot of these single-board computers or their descendants will have disappeared to where we won't even think of them. And it's already starting. You look at your TVs. I've got this, the LCD TVs that are sold in stores now.
Typically they'll have a Linux computer inside of it.

CHUCK:

Oh, yeah.

RAY:

They'll have a Linux computer running the Netflix software, running the Amazon software and all that stuff. And they'll have Ethernet on there. So, I think the direction we're headed in is one, these devices, they will disappear in consumer devices. Two, I think you'll see more IoT in what they call the dull to normal industries, just basic stuff that we all need every day. An example would be what Amazon is doing in warehouses. Amazon hired a company called Kiva to do robotics in their warehouses. And they ended up buying Kiva to do robotics in their warehouses. They bought the company. And it's a very basic function. These are robots that move the different items that need to be packed around to the pick workers, the people who pick and pack. And that's Internet of Things right there. But it's not the whiz-bang stuff that we think about. It's not a flying drone. It's not a submarine, the cool jets and stuff, right? It's dull to normal.

And so, I think there are a couple of trends. One, the IoT devices themselves will start to disappear. They'll be so embedded that we don't think of them anymore. And two, we'll see more stuff happening in the dull to normal areas. So, that's what… what do you think? What do you think about it in five years? What do the three of you think five years from now, IoT?

CHUCK:

I went to CES last month. And they had computers in all kinds of stuff. Most of it isn't ready for mass market and there's so much education you have to put into it for people to really get used to it. They had pots and pans that would, you tell it, “I'm putting olive oil in,” and it would calculate how many calories you'd added to the meal. Because it could tell by the weight change how much olive oil you'd added. Or things like that. It was just, it was mind-boggling. A lot of things are moving into the home. There was a company there that had basically moving the cloud back onto your home network. And then you access it like a regular cloud. But the physical hard drive that holds your data is in your house. There are all kinds of different things that people are connecting up. There were, I think Under Armour had shirts, underwear, pants, socks. There were a zillion show companies with chips in them.

And what I think is going to happen is that it's going to get to the point where yeah we don't even, we can't even conceive of these mundane objects without having them connected some way and giving us some information about our world.

RAY:

Under Armour is putting chips into their shirts and their gear?

CHUCK:

Yeah, they had prototypes at CES.

RAY:

Wow.

CORALINE:

I'm hoping that what happens is that we will separate out things that are practical from things that are possible. Because yes, you can put a chip in anything. But do I really need to know how much olive oil I just added to my pan? Do I need my pan to be a sensor? Probably not. So, I look forward to intelligently adding intelligence and not just doing it because we can.

JESSICA:

Yeah, the hard part is figuring out whether it's useful.

RAY:

Yeah, we went through that with personal computers too, right? Early days of personal computers. What was the example they used to use? Oh, you'll be able to store your recipes on your personal computer at home. And everyone was throwing their recipes on their home computer. You know, but [laughs] that's because that's all we could think about.

CORALINE:

Store it on a $3,000 device that's as far away from your kitchen as possible.

RAY:

Yes.

CORALINE:

[Inaudible] convenience.

CHUCK:

Yeah. [Laughter]

RAY:

Right.

CHUCK:

Get a longer cord for that screen.

RAY:

[Chuckles] So, we're still in the 'put recipes on your computer' stage with IoT.

CORALINE:

I think the other thing that we have to solve is that when we have all these smart sensors all around us, how are we going to interface with them? Because I think a phone is a terrible tool for interfacing with a variety of sensors with the models that we currently have where there's an app for every sensor. That's kind of ridiculous. And our laptops aren't really well set up to handle networks or meshes of sensors either. So, there's going to be some serious UI work to make all of the sensor data centralized, controllable, and ‘manipulable’ from a single source in a way that makes some kind of sense. Because if I have to download the Under Armour app, I'm going to have to download the iron frying pan app and all these other apps, it's going to be a big mess. And no one's going to want to use it.

RAY:

Yeah.

CHUCK:

Yeah.

RAY:

So essentially, someone who has what would be the equivalent of a marketplace for all this traffic could do really well. That may be what Apple's trying to do with, what do they call it, iHome or atHome or something like that, that they're doing with IoT? Something along those lines.

CHUCK:

Yeah.

RAY:

Yeah.

CHUCK:

Well, they have iHome. Is it iHome? They also have iHealth or Apple Health.

RAY:

Yes.

CHUCK:

Or HealthKit.

RAY:

HealthKit, yes HealthKit.

CHUCK:

HealthKit and HomeKit. That's what it is.

RAY:

Yes, yes, right.

CHUCK:

And you've got other systems that also take advantage of a lot of this stuff on Android and what have you. But they also introduced another one. I don't remember. But it also had something to do with IoT. Anyway, so yeah, you've got all these different things. You've got WatchKit which connects to your Apple Watch which both has sensors and display on it. And there are so many different possibilities. And some of these capabilities really could benefit from having parallel computing. And some of them probably wouldn't. So, it's also interesting to look at it and say, “Okay, so when we can get a Parallella that's a size of a penny instead of the size of a credit card, what does that mean and where do we put that?”

RAY:

Yeah, true. True, the applications will come. I think the bottom-line is it needs to… we need to get to the point where it's easy enough for people with all kinds of backgrounds to play with this stuff.

CHUCK:

Mmhmm.

RAY:

And then we'll see it happen. Like it happened with the web. When HTML came out, that was a language that was very accessible to people from a variety of backgrounds. You didn't take a whole lot of time to learn that. And I think that's part of the reason why the web took off. If it was just, if we only had computer scientists driving the web, we wouldn't be anywhere near where we are right now.

CHUCK:

No, it's true. There were a lot of economic and business interests that funded the growth of the internet.

RAY:

Yeah.

CORALINE:

But I think fundamentally, the internet was built by amateurs.

CHUCK:

Mm, that's right.

RAY:

Yeah, true, true. And we've seen that with all technologies across the board. You look at the early automobiles. You had to be an enthusiast about gasoline-powered engines and want to fix it yourself and all of that stuff. But when they became accessible to the masses, that's when somebody figured out, “Oh, maybe we should create an interstate highway system. And maybe all cars shouldn't be the same. Maybe we should have some trucks and some motorcycles. And maybe something in between like an SUV.” And all of that comes when you start making all this accessible to the masses. But if only the enthusiasts who are doing it just for the sake of doing it are doing it, in the case of automobiles we'd still be driving model T's, right?

JESSICA:

Yeah. Because it's the many people, the amateurs, who are going to find out where it's really useful.

RAY:

True.

CHUCK:

Yeah.

RAY:

True that, true.

CHUCK:

Alright. Well, I think it's probably about time to wrap up. This has been really fun to talk about though. Let's go ahead and get to the picks. Coraline, do you want to start us off?

CORALINE:

Sure, I can start us off. Okay, so I have one pick today. It is an article by Tom Stuart who is a great speaker. And if you have not seen him talk you're missing out. The article is a transcript of a talk he gave and it's called 'Refactoring Ruby with Monads'. So, I'm a little late to the monad party. I confess that I was not really clear on what a monad was. And I'd heard some really horrible explanations of what it is involving burritos and space suits and it never made any damn sense to me. And he writes that for every person that raves about them, there's another person asking what in the world they are, and a third person writing a confusing tutorial about them.

So, they're complex and an abstract idea. And it's hard to understand how they're relevant. But his article is very pragmatic. And he basically approaches the explanation as a refactoring of some Ruby code. And he walks through this refactoring step by step by step using really straightforward design patterns. And at the end, it ends up that the refactoring was using a monad. But he never says, he never defines what the monad is. He never says that's what he's setting out to do. It's just that in the end through the refactoring process you have built a monad. And so, you get this really great intuitive understanding of exactly what it is and its benefit from a really practical perspective, which I found really handy. So, that is my pick for this week.

Oh Jessica, I should say that we were inspired at my work at healthfinch by your work's reading group, your paper reading group. So, we're picking…

JESSICA:

Cool.

CORALINE:

Blog posts and/or papers every week to do a discussion on. And 'Refactoring Ruby with Monads' was our first pick.

CHUCK:

Very cool. We had Tom Stuart on the podcast about 120 episodes ago. So, if people want to check that out, I'll put a link in the show notes.

CORALINE:

Very cool.

RAY:

Cool, very cool.

CHUCK:

And it's also somewhat germane to what we were talking about. It's his book, 'Understanding Computation'. And it goes into some of the basics of some of the concepts that we were talking about with how a computer works. So anyway…

RAY:

Excellent.

CHUCK:

Jessica what are your picks?

JESSICA:

I'm going to pick learning to play the piano. I've been working on this for about two months. I did it for a couple of years so I know how to read music back as a kid. But learning piano, it's been really fascinating. Especially in some ways that like everything in my life I find the parallels to software. For instance right now, just last week I thought I could play Brahms' lullaby, like the arrangement and the intro, 'Alfred's Level One Piano Book'. And I played it for my friend who's a master pianist. And then he showed me a couple subtleties of phrasing, like how the first not of the phrase should be the heaviest and then you gradually get lighter, and that makes the continuity and the smoothness. And how the accompaniment on a waltz should be heavy on the first note and extremely light on the other notes, which is really hard. And now there were these songs that I thought I knew how to play and I don't know how to play them at all. And I can't play them anymore, because I've learned a whole other level of what it means to play them correctly.

And that is exactly like learning how to program. And you think just because you can get the computer to do what you wanted it to do that your program is right. And then you learn about readability and then you learn about abstraction. And then you try to go back and modify that program and you're like, “Oh my god. I knew nothing about programming.” And it just gets harder and harder the more I know about it. So now…

RAY:

Your standards are raised because you're exposed to this.

CHUCK:

[Chuckles]

RAY:

Your standards are raised.

JESSICA:

Yes. And every time I learn something new I need to go back and learn the song again, just like every time I learn a new programming technique or principle or just ideas of how to make my code more clear. I feel like I need to rewrite my code again. So, at least it's not just me. It's not just software. That's why I pick learning the piano, because it's given me that perspective. Love it.

CHUCK:

Alright.

RAY:

Cool, cool.

CHUCK:

I've got a couple of pics. The first one is, this was actually mentioned I think on Ruby Rogues Parley. It's this Mogo seat. I actually have video so I can hold it up or at least the seat part of it. But it's just one pole with a seat on the top. And the reason I got it is because I typically record three podcasts on Tuesday. And then I have a regular call on Wednesday and then two more podcasts on Wednesday. And on those days by the time I get to the last episode that I'm recording that day, I am pretty worn out. And I don't really feel like standing. So, what I wind up doing is I wind up just sitting on this. Now you don't really sit on it like a regular chair. You kind of place it behind your rear end and then lean on it. And it takes some pressure off of my legs. And it allows me to get through the rest. But I feel like it's important for me to be upright at least part of the day. And since I moved my podcasting rig over to the standing desk it kind of became important for me to be able to stand at it for long periods of time. So, I'm not using it right now because this is the first podcast I'm recording today. But it's definitely something that I'm really liking.

One other thing that I just want to mention is that this episode should be coming out the same week I'm going to be in Amsterdam. So, if you're going to be in Amsterdam on Wednesday the 17th, I'm going to do a meetup that night. I haven't quite figured out where. But it'll be somewhere in town. So, watch Twitter. I'm also going to send out emails and let people know, if you're subscribed to any of the podcast mailing lists. And you can get on those on the website. It's just the mailing list to get you the episodes. I've also got the top ten episodes for Ruby Rogues that I'm going to be adding to allow people to get those via email. But I haven't quite finished that campaign yet.

So anyway, those are my picks. Ray, do you have some picks for us?

RAY:

Two picks. One was the video, one of the videos that I mentioned earlier on in the podcast was the video by Rob Pike, one of the creators of the Go language, 'Concurrency is not Parallelism'. He's a great speaker and a great explainer of the difference between the two. And he does some cools things with cartoon gophers in the video. So, you got to catch that.

My second pick is a very old paper, a paper from 1995 about building parallel programs. And it's available, the entire… I called it a paper. It's actually a book. The entire book, the entire text of the book is available online. It's called 'Designing and Building Parallel Programs' and it's by Ian Foster. Dr. Foster is at Argonne National Labs here in Chicago. And he explores what we need to know in order to write parallel programs. And what's exciting about it is that even though it's old, the mathematics that underlies all of the stuff we're doing with parallelism, it's been around forever. We may be just discovering some of it but it's been around forever.

So, those are my two picks.

CHUCK:

Alright, cool. If people want to follow up with you, find out more about you, also probably about Parallella, where do they go? What do they do?

RAY:

If you go to RayHightower.com a couple of the featured articles on my blog right there are about Parallella. There are links that will take you right there. And there's a search feature that will take you there. If you do a search on Parallella, all of the Parallella articles will come up. So, you can go to RayHightower.com and that will lead you to some other resources related to parallelism, including how to pronounce it. It will give you all kinds of resources about that. So, check out RayHightower.com and I look forward to seeing you there. And thank you for having me, Rogues.

CHUCK:

[Chuckles]

RAY:

Thank you for having me on this podcast.

JESSICA:

Thank you for coming.

CORALINE:

It's great talking with you.

CHUCK:

Yeah.

RAY:

I have mad respect for what you do. I listen to you guys a lot. And I'm honored to be here and thank you so much for having me.

CHUCK:

Well, thanks for coming.

CORALINE:

Awesome. Hope to see you at…

CHUCK:

It was an awesome conversation.

CORALINE:

Yeah. I hope to see you at a ChicagoRuby meetup sometime soon.

RAY:

Yeah, yeah, yeah. See you soon. Alright. Be well. Thanks.

CHUCK:

Alright. Let's wrap it up. We'll catch you all next week.

[Hosting and bandwidth provided by the Blue Box Group. Check them out at BlueBox.net.]

[Bandwidth for this segment is provided by CacheFly, the world's fastest CDN. Deliver your content fast with CacheFly. Visit C-A-C-H-E-F-L-Y dot com to learn more.]

[Would you like to join a conversation with the Rogues and their guests? Want to support the show? We have a forum that allows you to join the conversation and support the show at the same time. You can sign up at RubyRogues.com/Parley.]
Album Art
247 RR Parallella with Ray Hightower
0:00
1:02:24
Playback Speed: