[This episode is sponsored by Rackspace. Are you looking for a place to host your latest creation? Want terrific support, high performance all backed by the largest open source cloud? What if you could try it for free? Try out Rackspace at RubyRogues.com/Rackspace and get a $300 credit over six months. That’s $50 per month at RubyRogues.com/Rackspace.]
[This episode is sponsored by Codeship.io. Don’t you wish you could simply deploy your code every time your tests pass? Wouldn’t it be nice if it were tied into a nice continuous integration system? That’s Codeship. They run your code. If all your tests pass, they deploy your code automatically. For fuss-free continuous deliver, check them out at Codeship.io, continuous delivery made simple.]
[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 the company or deny them without any continuing obligations. It’s totally free for users. And when you’re hired, they also 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 bonus instead. Finally, if you’re not looking for a job and know someone who is, you can refer them to Hired and get a $1,337 bonus if they accept a job. Go sign up at Hired.com/RubyRoguesPodcast.]
[Snap is a hosted CI and continuous delivery services that goes far beyond letting you do continuous deployment. Snap’s first class support for deployment pipelines lets you push any healthy build to multiple environments automatically and on demand. This means with Snap, you can deploy your staging environment today. Verify it works and later deploy the exact same build to production. Snap deploys your application to cloud services like Heroku, Digital Ocean, AWS, and many, many more. You can also use Snap to push your gems to RubyGems. Best of all, setting up your build is simple and intuitive. Try Snap free for 30 days. Sign up at SnapCI.com/RubyRogues.]
CHUCK:
Hey everybody and welcome to episode 166 of the Ruby Rogues Podcast. This week on our panel, we have James Edward Gray.
JAMES:
I am half of this podcast.
CHUCK:
I’m Charles Max Wood from DevChat.TV. And this week it’s just us.
JAMES:
Yay. [Chuckles] I mean no, boo, where is everybody? [Chuckles]
CHUCK:
So, truth be told, we did try and record another episode earlier and it just didn’t quite work out. But it took up enough time to where Saron had to take off and yeah, the other Rogues had other things going on. So, it’s just us.
JAMES:
That’s okay. We can handle it.
CHUCK:
That’s right. So, James had the terrific idea of talking about polyglot programming and learning other languages.
JAMES:
Yeah, I’m kind of interested in that right now. So, I guess I can tell you how this started. A couple of days ago, I made a tweet. I believe it said, “Go, Elixir, Rust, or Clojure?” That was my entire tweet. And it was pretty big, actually. I got lots of response of people telling me what they thought about each one, or some people clearly picking one, or some people saying, “That’s a silly question. You can’t ask a question like that without knowing what kind of problem you’re trying to solve,” or something like that. And all of those responses were very interesting. And I actually had a reason for making the tweet, but I guess first I’ll just put the question to you, Chuck. Go, Elixir, Rust, or Clojure? Which one?
CHUCK:
Well, of all of those, I’ve tried two.
JAMES:
Which two?
CHUCK:
I have tried Elixir and Clojure. And yeah, they’re both pretty different. They are interesting in the sense that Elixir runs on the Erlang Virtual Machine and so it’s sort of functional and sort of something else. And Clojure is basically Lisp with modern data structures.
JAMES:
Right.
CHUCK:
And so, I think they’re interesting. I have to say that Clojure was a little easier for me to pick up because I’ve been playing with Scheme for the last few months.
JAMES:
Right.
CHUCK:
And so, the Lisp-ness of it was pretty familiar. But yeah, I like them. I think they’re interesting. I haven’t done anything production-like in them yet.
JAMES:
So, I’ll tell you a little bit behind my reason for doing this. First of all, I don’t really agree with the people that said, “You can’t say that, because it depends on what you’re trying to do.” What if what I
was trying to do is learn new things or think about things in new ways? That seems like a valid goal to me. When we had Dave Thomas on recently, he talked about this thing that he’s pushed since the Pragmatic Programmer, which you should learn a new language a year. And in particular, on our show, he said, “You should try to pick something that stretches and bends your mind, that pushes you in new directions. And I think that was how I was trying to go with this. And I feel like in your answer there just then, you talked about how Elixir and Clojure both did stretch your mind in new ways a little bit, wouldn’t you say?
CHUCK:
Yeah, definitely, especially and I have to admit, I haven’t done a whole lot with Elixir, but just the way that the languages are different. I have to say that my programming experience has primarily been Ruby and JavaScript. And so, Elixir was quite the departure from that. And so, things like pattern matching and stuff like that, where I played with that for a long time because I thought it was really cool. And it’s nice, because then I start looking for solutions like that in Ruby and JavaScript and seeing how I can apply that back.
JAMES:
Yeah. I think that’s exactly the reason I like to play around with different languages. And I admit that a lot of times, I will go play with a language for a while and then come back to Ruby which is obviously my favorite. I feel like I bring those new ideas back with me. And then I’m able to think about Ruby in new ways, or try to use it for things I haven’t tried to use it before or things like that, that my brain has expanded a little bit, as Dave Thomas would say.
CHUCK:
Yeah. One other thing that comes to mind with this is that I created a study group out here in Utah. So, we read ‘The Little Schemer’ which is a book about Scheme and teaches you Scheme. And the thing that was interesting was that I decided to go back one day, I spent a half hour, maybe an hour doing this. But I was like, “Alright. Well, I’m going to try and write Scheme in Ruby. And so, I was defining procs [chuckles] and naming [inaudible]
JAMES:
Everywhere?
CHUCK:
Yeah. And so, then it’s stacking them up the right way and using recursion to solve issues. And it’s not the way that I would do thing…
JAMES:
IT doesn’t work out as well in Ruby, does it? [Chuckles]
CHUCK:
No. It’s a lot more verbose as well. But it was interesting because it’s like, “Okay, I can see where this goes. And you start to understand too, how things like the enumerable module and stuff like that really work, because you can see that it really does reach into that functional paradigm and take advantage of the strengths there and also realize that there really is this functional core in Ruby. But a lot of times, we just take for granted because we just use each or some variant of it and just assume that it does what it does.
JAMES:
Yeah. I think that what you just said there is really interesting. I read ‘The Little Schemer’ too. And it’s a great book. It’s one of those great books not because it teaches you Scheme. I don’t generally run into people that are like, “Oh yeah, I do my work in Scheme.” It’s more that you learn Scheme to change how you think about computer problems and solving them and the steps that you go through. I feel it’s more valuable in that. And like you, I came back to Ruby and it’s like, “Alright. We can do this. Let’s just lambda all of the things,” right?
CHUCK:
[Chuckles] Yeah.
JAMES:
But it doesn’t work. And I love that. That’s actually one of my favorite things, is that it’s like, “Oh, you can do this.” Yeah, you can kind of do this, but you’re quickly going to hit a wall because languages like Scheme, they do things like tail recursion optimization and stuff like that so that they can do really deep recursive calls. And Ruby, because it just uses the C stack, does not have that. And it can run out of stack. And then you’re like, “Uh oh. My program doesn’t work anymore.” And there are ways around that, of course. But all of those are going to move you away from a pure functional approach and more toward a Ruby approach which, surprise, Ruby has its own way of doing things.
But like you said, Ruby inherits a lot of these heavy functional concepts, like the iterators and stuff like that, which we’re now I think starting to see in a lot of languages. I think a lot of languages have learned the value of that. And so, you have these concepts that you bring back and the different ways that you think about things. But also, trying to write any one of those languages in any of the other languages, it usually turns out to be painful for various reasons that I think can also be instructive.
CHUCK:
Yeah, definitely. Another one is just JavaScript. Central to most JavaScript programming is the run loop that it has.
JAMES:
That’s a good point.
CHUCK:
And so, dealing with the asynchronous stuff and the callbacks and all of that and then coming back to Ruby and trying something like event machine and seeing where it’s the same and where it’s different. There are so many things that you can pick up from these other languages. And it’s funny too, because you can also see where other languages borrow from Ruby. So for example, on the JavaScript Jabber Podcast, we talked to a couple of guys about the Koa framework. And I’m not sure if you’re familiar with that.
JAMES:
I don’t know it, no.
CHUCK:
But it’s a Node.js framework and it’s effectively Rack in JavaScript. And it’s based on coroutines or generators, which are sort of like Fibers, which is where it diverges a little bit. And that made me think for a while, “Gee, what if we built our Rack apps on Fibers or threads. What would be the consequences there?”
JAMES:
Yeah, is it more, I’m assuming because it’s Node, is it more reactive instead of, you know.
CHUCK:
Yeah, yeah. But it’s a lot more synchronous as well, because it effectively does yield up the middleware stack the same way Rack does.
JAMES:
Interesting. Yeah, I think there’s a lot of value in learning stuff like that. So yeah, to ruin the surprise, actually my tweet was built because a friend of mine and I, our wives get together once a month to do this activity. And so, we have some free time. And starting in August, we decided we’d like to play around with some new language that would bend our brain in different ways and see what we could learn. And so, those languages that I threw out after some initial weeding out of other options, that was the ones we were considering at that point. So yeah, so we’re doing that to learn something new.
And I’ve done that many times over the years. I’ve played with Erlang quite a bit, which is very interesting from a process, processes and actors and stuff in Erlang are just totally mind-blowing and really great to play with. Whereas on the other hand as I think I said in the Dave Thomas episode, I’m much less fond of Erlang’s syntax and I find it tedious and annoying in some ways. But it’s neat to go look through all those things, and even, I’ve spent time just learning complementary languages fairly deep like regular expressions or Bash.
CHUCK:
[Chuckles]
JAMES:
I feel like both of them have made me a much stronger programmer, figuring out regular expressions and Bash and such.
CHUCK:
Yeah, I can definitely see that. They’re tools that you’re using regularly around, inside or outside of your Ruby ecosystem.
JAMES:
Right. And they’re very different. Bash is really good at controlling processes and sending the output of this thing here or things like that. And there’s just a lot you can do. There are things I learned still to this day that I can’t live without, like being able to diff the output of two processes because you can run the processes in these subshells and just get the output and diff them. And it’s great.
CHUCK:
Yeah, there’s a lot of interesting stuff about that. So, do you find yourself doing much Bash programming then?
JAMES:
No, I don’t. That’s a good question. I don’t do a lot. I think Avdi just gave a talk at Midwest.io where he wrote a web app in Bash or something like that.
CHUCK:
[Laughs] Wow.
JAMES:
To show how far you can go in that. And I’m pretty sure he labelled that as ‘probably not a great idea’. But still, it’s interesting that you can. And we’ve definitely seen big programs written that way, like early versions of RVM, though I think they’re moving away from that some. But I don’t tend to do a lot of Bash programming. I do like to automate things, and so I will write simple functions in my dot files and stuff like that, that make simple choices for me or things like that. But I don’t tend to write a lot of just full Bash scripts that do a particular thing.
CHUCK:
So, I’m a little curious. Your list, I don’t remember the four languages. Go, Erlang, Clojure, and something else.
JAMES:
Elixir and Rust, not Erlang. Elixir.
CHUCK:
Oh, Elixir.
JAMES:
But yeah, and Rust.
CHUCK:
So, how did you narrow it down to those four?
JAMES:
Yeah, so that’s a good question. We were going for again, the brain expanding stuff and trying to find new ways to think about things. And actually, our list was bigger than that. We had Haskell on there at one point. Maybe that was it. We may have talked about a few others in passing or something. But most of them were chosen because they’re significantly different than what we do currently. So, both me and my friend, we work in Ruby doing web programming, building a big web application, that’s what we do. So, we wanted to try different stuff. So, Go and Rust, we chose primarily as options because they’re lower level languages, more like system programming languages. And I’ve played around with C various times and I don’t love it.
CHUCK:
[Laughs]
JAMES:
But it’s interesting. It is really fun to write a loop in C and watch it go crazy, crazy fast or something.
CHUCK:
It’s also fun to watch other people write C and pull their hair out when their pointers don’t go to the right place.
JAMES:
[Chuckles] Right, exactly.
CHUCK:
Or they forget to dereference them.
JAMES:
So, that’s a great thing right there. You talked about why C is so painful. There’s just no kind of checking, no safety, no anything, pointer math. Ah, it’s all terrible. Go and Rust are more modern. They’re more low level system languages, still keep the speed, but now they’re safe or at least safer, I guess I should say, have various guarantees and stuff. I read this great article the other day about Rust. I’ll try to find it to put it in the show notes. But it was about how in Ruby you can set some variable and then you can make a bunch of threads and have them try to modify that variable. And if you do it fast enough, you’re going to notice that some of them succeeded in modifying it correctly and some of them didn’t.
And that’s because if a thread does something like fetch a variable and add one to it, those are two different steps. So, if these two threads are moving fast enough and switching back and forth, then sometimes the number’s probably at 40 right now and thread A fetches it and gets 40, but then before it can increment it and put it back, thread B fetches it and still gets 40. A adds one to it and gets 41. B adds one to it and gets 41. They both assign it back and you lost a number in there. You get 41 where you should get 42. In Rust, if you try to write the exact same program, that’s a compile time error. It will actually refuse to compile your code and tell you, “Hey, you can’t modify this variable in another process. That’s not safe.” [Chuckles]
JAMES:
So, that was really cool. It’s a different way to think about things.
CHUCK:
Well, it lets you do it if you put a semaphore or something around it?
JAMES:
Yeah. You have to use some kind of synchronization, a lock, or sending messages I believe. So yeah, you can do it if it’s safe. But you can’t do it unsafely. So, that was very interesting. And then Go is maybe less safe like that, but it’s a little farther along. Rust is still very not 1.0 yet and still changing a lot. And the documentation on the internet’s in all kinds of states of may or may not match the version that exists today. Whereas Go is more mature. It’s being used by companies and stuff like that. So, we were looking at those two languages for that reason.
Elixir, like you said, I think the primary reasons would be the functional aspect of it, and the pattern matching, and the ability to play with Erlang’s processes without having to put up with Erlang syntax. So, that was the reason we were considering Elixir.
Haskell we briefly considered because it’s the pure functional language. So, it’s a good brain bender for a very different way of doing things. But I think we ruled it out because we feel like Haskell is probably a little more academic and a little less practical. We don’t see it used in a lot of places and we would like to learn something that’s even kind of a little bit practical. I’m sure we’ll get hate mail from that. I’m sorry Haskell fans. I apologize.
CHUCK:
[Chuckles]
JAMES:
And then the other …
CHUCK:
Clojure?
JAMES:
Yeah, Clojure, for being Lisp like you said. I love Lisps. I program Emacs Lisp quite a bit to customize Emacs. So, it’s a more modern Lisp. And the immutable data structures and stuff like that. And I think there are just a lot of cool things in the Clojure ecosystem, like edn I believe is their data format that is like JSON but it includes this schema and stuff with the data, which is interesting. And ClojureScript is a compiler that compiles Clojure, some Clojure, down to JavaScript.
CHUCK:
Yeah.
JAMES:
So yeah, just a neat ecosystem with lots of tools to play with. And these are just languages we thought of. I threw out some. My buddy threw out some. I’m sure if other people sat down to do this exact same exercise, they would throw out a different set of languages. For example, I think a lot of people are learning Swift right now. Have you played with it at all?
CHUCK:
I haven’t had a chance.
JAMES:
Yeah.
CHUCK:
But given that I do some iOS programming, yeah it’s definitely on my list.
JAMES:
Right, looks cool, right?
CHUCK:
Yeah.
JAMES:
So, I think a lot of people would have had that on their list. We’re more a free, open language set of guys so it’s less appealing to us. But yeah, a lot of people are playing with that and learning a lot. And I think that’s the point of polyglot programming, is that you’ll pick what’s interesting to you or what you think will expand your brain in new ways, and that there’s a lot of value to that.
CHUCK:
Yeah, definitely. And I have to say, just with my experience, in college I did Java, C++, and C. I got into Ruby after I graduated and got a job. I was also a systems administrator, so Bash was a thing that I did. And all of these things have colored what I do and how I do it and how I learn about this stuff. I am curious. When you pick a new language, how do you go about learning it? Do you pick up a book? Do you go through tutorials or watch videos? Or do you just open up a repl and just start banging on it?
JAMES:
That’s a good question, actually, because in the past I’m a traditionalist, so I will typically go and grab the Pickaxe-like equivalent in that language and just work my way through it and pick it up that way. That said, I’ve never done a language study, really, with another person before. So, that’s definitely going to change something when the two of us do this together. Would we both read the same chapters of the same book and then come back and talk about it? I think that would probably be less cool.
I’m actually envisioning maybe we would both study from a different source each week or something. Find a tutorial that he liked and find a tutorial that I liked or something like that, work on that, and then when we came together maybe walk the other person through the particular thing we were playing with. It seems to me like you could probably do better that way, because then having to internalize what you’re learning and then be able to teach it to the other person, I think would probably get you farther than just both of you reading over the same material, talking about what you liked and nodding at each other.
CHUCK:
Yeah. Yeah, I tend to take the same approach. I’ll pick up the book, whatever it is. The other thing that I like to do is work through videos. And the last thing, I always do this when I’m learning a new language is I start a new project in it and build something. I think Dave Thomas said that in his episode where he said that I build a Markdown compiler, translator, or whatever.
JAMES:
Yeah, and that’s so hardcore. [Chuckles]
CHUCK:
Yeah.
JAMES:
I just build a Markdown parser. It’s like, “Dave, Markdown’s a horrible thing to parse. What are you talking about?” No, I think that’s really cool. Yeah, and you’re so right. Playing with a language in a book or something, you may start to get the hang of it. But until you’re practically using it for something, it’s very difficult to understand the tradeoffs and how you’re thinking about things and stuff. So yeah, I agree that the practical project is very valid. I also like what you said about videos. That didn’t actually use to be a thing for me. I got really into Destroy All Software when that was going. And then Avdi’s Ruby Tapas is just sensational. If you haven’t seen both of those, you are missing some of the coolest stuff in Ruby in my opinion.
CHUCK:
I agree, totally agree.
JAMES:
Yeah, they’re great. And then in some of these other languages we’re looking at, I haven’t looked at all of them, but Elixir I know for sure has Elixir Sips, which is like Ruby Tapas. So, that would be nice to be able to use that as a learning tool.
CHUCK:
Those are the ones that I’ve been watching. And Josh Adams does a tremendous job with those.
JAMES:
Oh really? Are they good?
CHUCK:
They’re pretty good.
JAMES:
Oh, cool. SO yeah, that would be a neat thing about doing Elixir.
CHUCK:
And he starts at the beginning with Elixir.
JAMES:
Oh, good. So, you don’t have to know a lot going in?
CHUCK:
Right. So, what I usually do is I’ll watch the video and then I’ll go duplicate what he did. The first one is setting up Elixir on your machine. And that one might be a little out of date. But then the next couple, he gets into variable assignments and basic types and pattern matching and stuff like that.
And so yeah.
JAMES:
That’s awesome, yeah.
CHUCK:
Anyway, you were saying? Sorry, I keep interrupting you.
JAMES:
Oh no, no, no, no, no. Not at all. Yeah, one of the languages we’re looking at, Rust, I mentioned before the documentation’s not really there yet and it’s scary if you try to look at it. I have in the past. And you grab a tutorial or something and then you start running into problems almost immediately, because Rust is evolving so fast. I think it’s finally starting to stabilize in the core and the libraries are still changing quite a bit according to Steve Klabnik, who I asked on Twitter. So, that one would be tough if we choose that, because we won’t have as good a documentation. We can’t grab the Pickaxe-like book because it really doesn’t exist yet. But that could be part of the fun of learning it, too, which we talked about as you’d be trailblazing, and whatever we can figure out from the various stuff that’s out there. And maybe we could write a blog post or two that might actually help a few people out get started. So, there’s some appeal to that, too.
CHUCK:
Yeah, I think it’s interesting with Rust in particular. Isn’t Rust being built by Mozilla?
JAMES:
Yes, it is.
CHUCK:
And Mozilla has done a tremendous job with documentation on JavaScript. And so, I find it interesting that it, you know. But I guess it’s just that the language is so much in flux.
JAMES:
Yeah. And they are working on documentation a lot. I don’t mean to demean their project and all. By the way, I guess I should probably make this statement. I’ve said tons of things about tons of different languages here. In case it’s not obvious, I don’t really know these languages. So, take everything I said today with a huge grain of salt. [Chuckles] This is somebody from the outside looking in. So, I may have gotten many details wrong. But Mozilla is actually now spending a lot of energy trying to get Rust documentation up to speed. They hired Steve Klabnik, which is the reason I asked him, for six months to beef up their guides and their tutorials and stuff like that, documentation. So yeah, that’s exactly what he’s working on right now.
But I think it’s cool that there are a lot of things. There can be a lot of different reasons to learn a language like we just talked about. Being able to get the main book and learn lots of stuff, that’s cool. But like I said, it also can be appealing to be playing with something in its early stages, as long as you recognize that’s what you’re getting into. And there will be a fair bit of pain involved with that. I think that that can be fun, too.
CHUCK:
Well, the other thing is that with a lot of these, the approach in Elixir is different from the approach in Node.js which is different from the approach in Ruby. And even within Ruby the approach is different in Sinatra versus Rails or Padrino or whatever other framework you want to use. And to me, I look at them all as different tools. And you can actually go out and mix and match them.
A lot of companies have a polyglot setup where they use Node.js to compile their static assets or they use Node.js to handle things that make more sense to have a more asynchronous, evented system drive it as opposed to something more like Rails. Or people go over and they use Elixir because the Erlang Virtual Machine and the way that it manages processes and actors allows it to respond really, really efficiently to things. And so, the polyglot isn’t just to bend your mind. But a lot of times, there’s a really practical reason for adding part of your infrastructure in a different language or system.
JAMES:
That’s a great point. You had a great example there with the asset pipeline. It needs a JavaScript engine to do the compiling that it does in Rails, because that’s JavaScript. It’s working with JavaScript so it’s easier to do in, surprise, JavaScript. Really good point. And like you say, if you’re going to work on some low level heavy server thing, like if you’re going to have a component of your web app that’s maybe doing over, what do they call them, web sockets or something and having some interactions with those. You can have much heavier server needs than your typical http server. And probably something like Erlang is going to be a lot more smooth, if you have a significant volume of traffic, at handing something like that. So yeah, there’s no reason you can’t use multiple things every day. I’m sure even most people listening to this podcast who are Rails developers and write web applications for a living, how many technologies do you use to use that? Just Ruby, then with everything Rails adds, I assume you probably write some JavaScript, HTML, CSS.
CHUCK:
To deploy, you wind up putting Bash.
JAMES:
Right.
CHUCK:
And other things into your Capistrano.
JAMES:
Exactly. So, there are always tons of tools involved. And I’ve also heard a lot with the move toward SOA architecture, microservices, similar things like that, where you break big applications down into lots of smaller applications. Sometimes, the different components can be written in a completely different language. And that may make perfect sense from a, “Oh, well this component does this and that’s more suited to this particular language.” Not that it’s not possible in other languages, but it’s just easier, smoother in this language. And/or we just have different developers working on it and the different developers have different tastes and favorite things they like to do. So, this developer preferred to write it in Clojure or whatever. And I think that can be totally fine with caveats. Obviously, you don’t want everything put in a different language that only one person knows or something like that.
CHUCK:
Yeah, I was going to say. There are drawbacks to that, and that is if you have a team of three working on one thing in a language that nobody else in the company’s using and they all quit or get hit by a bus, then somebody’s got to come in and pick up the slack.
JAMES:
That’s a good point, yeah.
CHUCK:
And the other thing is that a lot of times in the SOAs that I’ve set up, you can cheat a little bit if they’re all in the same language, because you can hit the interfaces more directly or in a more standardized way. Whereas if they’re in different languages, you wind up, you really have to hit them by making an HTTP call over to the other service because they’re not completely alike.
JAMES:
Right.
CHUCK:
But at the same time, that’s usually a healthy thing, if you’re doing a complete acceptance test on the system.
JAMES:
Right. Or you can introduce some kind of intermediary that probably exists on both systems like RabbitMQ or something.
CHUCK:
Right.
JAMES:
You could queue your messages into RabbitMQ, which probably you’re going to have a driver on both sides.
CHUCK:
That’s true. And then you can break it apart there, because you just tested it got into the queue. And then you test when it comes out of the queue that it does the right thing.
JAMES:
Right. And maybe we should even add here that since we’re talking about this, of the capabilities of different languages. Sometimes I find it’s important to remind myself that all these programming languages that we’re discussing, they’re all Turing-complete, which means they’re all capable of doing the same things. You can write an actor model in Ruby. And it’s been done. I think Celluloid.
CHUCK:
Celluloid, yeah.
JAMES:
Yeah, that. You can do these things in Ruby. It’s probably not as smooth as it’s going to be in Erlang or Elixir where the language was thought out with that in mind. It was pushed in that direction from the get go. But you can do those things. So, there’s definitely a factor of comfort to doing something or just feel of something. Some things are better. We’ve seen and talked about in the past.
I think was it Michael Feathers who wrote the blog post that said something like he really liked functional languages for the real low level stuff in servers. And then as you got higher in the stack, he preferred to switch over to object-oriented languages, because for him that felt correct. It was easier to reason about the low level stuff in the functional languages. And it was easier to handle your higher level business logic in object stuff. And I think that’s mostly a preference. You can handle business logic in Clojure. You can write low level servers in Ruby. You can whip open Socket and handle everything manually if you want to.
CHUCK:
Yeah. Now, I do have a question for you. One of the reasons that I’ve really admired you over the years is your deep knowledge of Ruby. And so, I’m curious. If you get into a language and you really want to develop that sort of deep understanding of the language and of the available APIs in the language, or the available libraries in the language, what did you do to get to the point where you’re at?
JAMES:
That’s a good question. I don’t know any language as deeply as I know Ruby. I don’t know the others like that. But I do have a couple of tricks. One of the reasons, or I guess there are several reasons that I know Ruby at an almost encyclopedic level. One is that you should find the API reference of the standard libraries or whatever and just read it. Literally like a book, start at the top and just work your way through. That may sound like the most boring thing ever, probably it is to people that are less geeky than I am. But I actually find it really gives me a ton of ideas, because you have all these standard libraries that ship with a language. And they’re built to do a lot of things for you.
But until you’ve gone through and actually read the methods, how do you know what’s there and what it can do for you? So, just reading through them, note, I didn’t say memorize. You don’t have to memorize. But just reading through them to get familiar with them is a great thing. Like, “Oh, I didn’t know you could easily write that kind of stuff with language X, Y, Z. It turns out there’s a standard library for it. It’ll do most of the work.” And then later, when you run into a problem that’s roughly shaped like that, you’ll be like, “Ah, I saw a library for that,” and you go back and figure out the details. So, that’s one thing I think that helps.
In Ruby, it was running the Ruby Quiz for three years that made me get into such deep knowledge of it, because the people that submit to those contests, they use every trick in the book. And so, I
had to look them up every single time or I couldn’t figure out how the program worked and stuff. So, I’m sure I would recommend running the Ruby Quiz because that’s a massive amount of work. But try to find a contest like that or something and participate. And most importantly, read the other submissions that were submitted and figure out how they work, because they won’t look like yours and you’ll have to look up, “Whoa, what is this construct. I didn’t even know this is legal in the language,” or whatever. And so, those I think help a lot.
And then I was also on the Ruby Talk mailing list for years during its hay day. And that can be part of the fun of getting into a newer language. Some of the ones we’ve been discussing here I would say probably Elixir and Rust fall more into this category. But the languages that are still pretty new, the communities are much smaller and more intimate. And so, if you get on those mailing lists and stuff, you usually interact with people who know it pretty well and have a good set of knowledge to share with you. And you’d be surprised how quickly you can pick up tricks that way. So, in my time on the Ruby Talk mailing list, I was regularly interacting with people like Jim Weirich and Dave Thomas and Glenn Vanderburg and Avdi and all of that, and just all of those people had tons of knowledge and taught me so much so fast.
CHUCK:
That’s really interesting, really, really interesting. And I think those still apply. Reading the documentation, it’s still there. And getting involved like you said in doing the coding exercises or Ruby Quiz or something like it, also really applies. The last one with the community, it’s interesting because the communities are still out there. I know that the ruby-lang mailing list isn’t as it used to be and there’s not as much in there, but there are other communities. We have one with Ruby Rogues Parley and there are others out there where these sorts of discussions take place. By being involved on IRC or whatever, yeah you could definitely pick up some things there.
JAMES:
Yeah. So, the interesting thing about community mailing lists and stuff is that golden period is when the language is getting big enough to be noticed by people but isn’t yet huge. So, once Rails dropped, it just brought a massive influx of people. And then the signal to noise ratio on the mailing list turned upside down. And then all of those people that I named pretty much moved on to other places because it was too hard to keep up with. And the value of keeping up with it was much lower. So, that trick works better in earlier languages.
But like you said, once that happens, then groups fragment out and there are still strong groups if you can find them. So, like Seattle.rb happens to be one of the ones people talk about often because you’ve got Aaron Patterson, Ryan Davis, Eric Hodel, lots of people there that have a lot of knowledge and then just a fun group. And they crank out a lot of software. Join one of those groups. Even if you don’t live in Seattle, who cares? Join one of those groups and get your great community fix that way, if you’re learning a more established language.
And if they don’t have a Ruby Quiz like thing, just go take the Ruby Quiz problems and work them. The only minus there is that you won’t get to see the solutions of others. But you can cheat on that. Just work one and send it to a mailing list, one of those great mailing lists, and be like, “Yeah, I worked this problem from here to see how it was done in Clojure or whatever. What do you guys think?” And then some people will probably jump in and solve it a different way and you can see that anyway.
CHUCK:
Yeah.
JAMES:
That’s mostly what I did with Ruby Quiz actually. I stole the idea from Perl’s Quiz of the Week. And a lot of the Ruby Quiz problems, if you look back over them are some of my favorites from Perl’s Quiz of the Week where I would steal them and be like, “Let’s do them in Ruby.” [Chuckles]
CHUCK:
Nice.
JAMES:
So yeah, there’s lots of great ways to learn languages. And we’re lucky now that we have so many new avenues like the videos and stuff to get more information.
CHUCK:
Yeah. So, one other thing I want to talk about really quickly. So, Dave Thomas we’ve mentioned, he said learn a new programming language a year. I think he said it in ‘The Pragmatic Programmer’ book.
JAMES:
Right.
CHUCK:
It seems that there is a profusion of languages these days. We’ve got Rust and all the ones that you mentioned. I can probably name, if I sat down and thought about it, four or five languages that transpile into JavaScript. There are all kinds of people who are fans of the various ones. It seems like there are new languages coming out to solve different problems. Is this going to be harder or is it just going to make the ecosystem more interesting?
JAMES:
I think that’s a good question. I think we’re currently seeing a second language explosion in computers. And I think that’s because we’ve made it really, really far on what we had up to now. But at the same time, things are changing. Pretty much the existing computer world is to some degree written on C. While that was great and that got us pretty far, parts of that are horrible, like pointer arithmetic everywhere and totally unsafe and buffer overruns and stuff like that, that plague things like OpenSSL or things like that. So, I think we’re ready for a more modern low level language, which is why I think you’re seeing things like Rust and Golang and I’m pretty sure there are others that are trying to be more modern low level languages. So, I think we’re seeing that.
Also, we finally hit the wall of just doubling computer speed all the time. And it didn’t happen anymore. So now, we’re throwing in more processors. And that’s how we’re making them faster and faster, which means concurrency went from that thing operating system programmers do to that thing we all do. Concurrency is almost the same way. It’s like, well, you can do it with threads but… [Chuckles]
JAMES:
It’s really painful if you’re sharing memory and stuff. So now, we’re seeing lots of very modern takes on that. Clojure takes the idea of, “Oh, threads are fine as long as everything’s immutable.”
CHUCK:
[Chuckles] Yeah.
JAMES:
Or Elixir and Erlang use a really modern process model and stuff like that. So, I think we’re seeing this explosion of languages because modern computing is changing and the languages are catching up with what computing looks like now. And that might be pretty interesting in the future. When we had Julia Evans on she talked about fiddling around with a kernel in Rust. How cool would that be if the next major operating system isn’t written in C? That’d be kind of neat. To answer your question about how does that make things, harder or easier? I don’t know. That’s a really good question. To me, it feels like things are getting harder, because there are amazing new languages being released every month. And I’m like, “I should go learn that. I should go learn that.” But it’s already exceeded the point where I can keep up with it. And I think Avdi surprised all of us when he mentioned Idris on the show recently, and we were like, “What? Did you make that up?” and he didn’t. That’s a real thing.
CHUCK:
Yeah.
JAMES:
So, in a way it makes it harder because you’re not going to be able to visit all the major languages anymore, I don’t think. We’re passing out of that era. And you’re going to have to pick and choose the ones you actually sit down and fiddle with. But at the same time, with all this new language growth, there are lots of great learning resources, like the videos and stuff that have become popular. And since lots of people are picking up new languages, we’re getting better and better about onboarding them. So, I think that gets better. So, I think it’s a mixed bag.
CHUCK:
Yeah. I was going to ask you a question about what other languages features you wish they would steal and put into Ruby, but we did an episode on that. I am curious about, so one thing that I run into sometimes is people, they get stuck in whatever language they work, Java or, what is it, C# or Ruby or whatever. And so, a new language comes along that looks really cool and they shy away from it because they have so much tied up in the other ecosystem. And so, they worry that if they move away from Ruby or Java or whatever it is, that they’re going to lose some of that, or they’re not going to have the status, or they’re going to have to relearn the toolkits and relearn the other things. I’m not sure if I have a good answer for that other than just go try it, because it will be good for you. Do you have a better answer than I do?
JAMES:
I think I’m largely with you. I’m like, “Ah, get over it.” In a way, you’re right. I admit that I don’t know any language as well as Ruby and I admit that it’s still my favorite, to this day, with all the others I’ve played with. So far, it’s what I’ll program in, in my spare time to enjoy. But that said, it’s not the language you know, it’s what you loaded into your head while you were learning it. That’s the valuable thing. And the language is more just an outlet for that kind of knowledge. As you go to other languages, you will learn new things and you’ll learn that, you’ll load that into your head. And yeah, in some ways, you’ll be starting over. You won’t be familiar with that language’s standard libraries and stuff anymore, so you won’t be like, “Oh, I can just fire up WEBrick here and I’m serving pages,” or whatever. You won’t know that anymore.
But in some ways, that’s a good thing, because you’ll go over to the other language and you’ll ask dumb questions like, “Oh well, where’s your WEBrick?” And we’ll be like, “Yeah, we don’t throw everything on the web. That’s a Ruby thing. We build a desktop app because we have whatever.” That will be great, because it will expose you to other systems, other ways of doing things. And you also won’t be starting over, over. The hard part in learning to program is learning how to think like a computer. And you’ve already done that part, no matter which language you learned. Computers are really, really stupid and they have to context. And they only do exactly what you tell them, usually to an extremely painful degree.
CHUCK:
[Chuckles]
JAMES:
And learning how to express things through a computer that actually makes sense, that’s the tricky part. And you’ll still have that when you move to a different language. You won’t be starting at the bottom, bottom. Or maybe you are, but you’ll climb through the levels much faster. So, it’s like when you play Diablo the first time, or whatever. You go through it the first time and you’re figuring everything out. But when you’re like, “Oh, I want to start over and try this as the barbarian,” once you’ve been through the dungeon before, you know which bosses to expect where. You can prepare and go through and do it much quicker.
CHUCK:
Yeah.
JAMES:
And it’s a similar thing like that, that you know what’s going on and you can pick things up quicker. And some things will be really foreign and feel strange, and that’s good. That’s great. That’s how you know you’re doing it right, because you’re figuring out new ways of doing things. If you really are a Ruby person, going to a language like Clojure or Elixir or Haskell is going to be pretty shocking to you, because it’s functional to varying degrees. Elixir’s going to be kind of close to Ruby and Clojure a little farther still, and then Haskell really far, in my opinion. And so, as you get into that world, you’ll really start to understand what this functional programming thing is about and how do people do that. And that’s a good thing. But yeah, there’s that fear that I think you’re starting over and you’ll go backwards. But I think really, you should get over that. And it’s not like, “Oh once you write a little Haskell, oh sorry, you’re not a Rubyist anymore. You have to give us your insignia ring back” or something.
CHUCK:
[Chuckles] Wait, there are rings?
JAMES:
[Chuckles] Right. You don’t have one? Yeah, so we don’t take that away from you. You’re still allowed to write Ruby. You’re allowed to go learn new things. You’re allowed to come back and use those new things in Ruby. So, it adds to the fun.
CHUCK:
Yeah. Well, there are so many useful things written in these other languages, too. We’ve talked about several of them on this show and in other episodes. RabbitMQ for example is written in Erlang. You have Docker. It was written in Go. And you could go down the list. Emacs Lisp is written in, or Emacs is written in C but to configure it you write Emacs Lisp.
JAMES:
Yeah. And Emacs is just a little bit of C at the core that basically builds a Lisp machine.
CHUCK:
Yeah.
JAMES:
And then the rest of Emacs is written in Emacs Lisp.
CHUCK:
Yeah. So, you have all of these different things. So, if you really did truly focus on just one language and ignored everything else, you would miss all of the other richness that is still part of the ecosystem and make up great tools within the ecosystem of that language. And so, yeah, go take a chance on something else.
JAMES:
And I think that, you know you say you have this fear that you’ll be totally starting over. If you have that fear, that’s fine. I think we all have it to some extent. But you also better have the fear that staying where you are, is making you irrelevant.
CHUCK:
Yes.
JAMES:
Because that’s kind of true. Computers grow and change over time and the big languages today, they’re not going to be the big languages tomorrow. I hate to disappoint our listeners, but Ruby is probably a little past its golden age now. And it’ll have a stable period where it’s in pretty heavy use. And then some day, it will probably be on the decline, because things have moved on and people are doing things a different way. And so if you’re not playing around with this new area of languages, then when that comes you really will be starting over with no choices. It’s better to learn and grow as the industry changes.
CHUCK:
Yeah. Well, and I think a good example of this in the Ruby world, we mostly do web. There are some other areas that Ruby has found a home in, but let’s just talk web for a minute. When I was in high school, I was playing with HTML and CSS, put little snippets of JavaScript in and just copy it when I needed it. And then it went from that to you actually had to have a backend database and you were using something like PHP. And you did a little bit more with JavaScript, maybe with what was it, Prototype. And things moved along to jQuery. And so, you had a lot more DOM manipulation and things like that.
And so, the skillset changed again. You got more rapid development with things like Rails. And then now, it’s almost a prerequisite that you understand not only a backend database like MySQL, but in a lot of cases, a much more fitting thing is one of the NoSQL databases. And so, you’re probably better off understanding a relational database and a NoSQL database of some kind. And then you have your backend framework. And then you need to understand JavaScript and you need to understand jQuery DOM manipulation. But it’s getting to the point now where you actually need to know a frontend framework.
JAMES:
Like Ember or something like that.
CHUCK:
Ember, Angular, Knockout.
JAMES:
Right.
CHUCK:
And then on top of that, a lot of the things out there are being built on grid systems or actual frameworks like Bootstrap or Zurb Foundation. And this is the discussion we had on JavaScript Jabber that will also come out same time this one does. But you have all of these skills. And so, if you had just stopped at learning HTML and CSS or just stopped at learning MySQL, PHP and HTML/CSS with a little bit of JavaScript, you’d be left way behind, because at this point, things have moved ahead to the point where people expect web applications to feel like applications.
JAMES:
Right. And in the frontend, the frontend for so long has been totally JavaScript, almost any way you go. But we’re slowly seeing that starting to change. I’ve played with Dart quite a bit lately and enjoyed that. And the reason you can pretty much use Dart now if you want to is that it comes with a transpiler to JavaScript. So, it can go to JavaScript and then you can serve that. It’s big code, so it’s not something you’re going to use on just any old site, because you’re going to have much bigger assets. But if you’ve got a complicated frontend, then who cares if you have to pay that big price to set it up? The advantages are that you can write much more Ruby-like, I would say, stuff in the frontend. And I find that more enjoyable.
And then we talked about how ClojureScript gives you a way to write some Clojure in the frontend and stuff like that. So, even though JavaScript is still involved in those examples, we’re starting to see examples of ways to write frontend apps that are different. So, right now JavaScript’s reign in the frontend is totally undisputed. I have no doubts about that. But is it going to be that way in ten years? I don’t know. Maybe not.
CHUCK:
Well, the other thing is you say more Ruby-like code. And what I’m hearing is that people are using these higher level languages like Dart of CoffeeScript or whatever that abstract away some of the stuff that you don’t really want to deal with in JavaScript.
JAMES:
Yeah, that’s a good point, more higher level. When I called Dart more Ruby-like, I was actually meaning that the class system is more like Ruby.
CHUCK:
Yeah.
JAMES:
And feels more like that, yeah.
CHUCK:
Right. And really, what it is, is it compiles it to a prototypal inheritance, which JavaScript uses. But you don’t have to worry about it. And it’s interesting that in ten years, it may still be JavaScript has the browser market. Dave Thomas also said that the browser is dying and we’re just perpetuating it. And that may be true, too. So, maybe JavaScript will just fade into obsolescence on the frontend in that way, at least. And it won’t matter. And so, we’ll be using these languages to transpile other stuff. Or we may increase the complexity to the point where writing it in JavaScript is just too painful.
JAMES:
That one comment Dave made about the browser is dying, there’s been an awesome discussion on Parley about that.
CHUCK:
Yes.
JAMES:
Like, “Ah, what did he mean? Ah!” It was great. [Chuckles]
CHUCK:
Yeah. It was a good discussion. And I think it is something worth thinking about. Where are we going to be in ten years? Do you want to be maintaining the legacy systems that are still using the old technology because that’s all you know? Or do you want to have the other options to move ahead beyond the cutting edge?
JAMES:
Right. That’s why it’s good to learn things you don’t know. Go to conferences you don’t normally go to. Go to a Go conference, because you’ve been sitting down playing with Go for a little while. They’re going to talk about totally different things that you are not going to see talked about regularly at a Ruby conference. Or one of the many polyglot conferences that are so good.
CHUCK:
Yeah.
JAMES:
Like Strange Loop or things like that. Get to places. Get outside of your comfort zone in programming and learn new things. If you’ve never done any frontend programming, do that. I admit that that was me. Two years ago, I really sat down and finally started to learn JavaScript well. And until then, I had done the, “I’ll google this and figure out how to do it,” way of frontend programming. And then I finally sat down and learned how it works. And it gave me a much better appreciation for what’s going on out there.
CHUCK:
Yeah. So, I’ve been waiting to the end of the show to ask you this, but have you actually picked the language that you guys are going to study?
JAMES:
[Chuckles] We haven’t. I think we’re down to two. I think we’ve narrowed it down to Rust and Clojure at this point. Elixir, I don’t really remember why we decided not to go with that. I think it was just only one of us was familiar with that one. And so, it didn’t really appeal to the other one. Go, I
think we mostly knocked out because, and this is totally our reasoning, everybody else will have their own opinions, but I think we knocked it out because we felt like Go was more just a modern imperative language. So, it’s like C but way more modern and stuff. So, we didn’t know if it would be stretching our brain as much as some of the other choices. And we thought Rust had a little bit, to us, more exciting feature set. So, I think that is what appealed to us there. Although the downside is, we’re going to have to figure it all out with dicey documentation.
CHUCK:
So, you’re voting for the maximum brain twist?
JAMES:
Yeah right, exactly. That’s the whole point, is to figure things out. And then Clojure I think is just cool in many ways and then also has a pretty rich ecosystem that we could get into and probably learn quite a few new things along the way. So, those are the two we’re playing with now. My buddy’s on vacation right now so we haven’t talked about it too much. And who knows? Maybe we’ll flip a coin and end up picking between the two. And I assume, given enough time, we would eventually get to all of them. But who knows how it all works out? So, you have to ask me later which one we actually played with.
CHUCK:
Yeah, I’ll be curious to know that. I’m also a little curious. So, are you planning on doing this for an entire year or just until you feel like you’ve gained some proficiency and learned what you want to learn from it and then move on?
JAMES:
Yeah, that’s a good question. I think usually when I play with a language, like I said in the past I’ve always done it by myself. Erlang was probably the one I played with the longest outside of Ruby, and of course JavaScript which I pretty much have to use for my job. But I played with it for about six months or something, enough that I felt like I had a pretty good feel for it. And at that point, you end up making a decision like, “Oh, I’m going to have to build something significant in this or decide I’ve gone far enough and that’s good enough for me.” And in the case of Erlang, it was good enough for me at that point. So, I pretty much haven’t played with it since very much.
I think you got to at least give yourself, I think maybe Dave Thomas said three months or something is a good period of time. I think you definitely at least need a few months. You should build a project in it, like Chuck said. It doesn’t have to be ridiculous complexity, but also not a toy problem, but solve some significant problem in it. And then you can make the decision of whether or not you want to keep going or not.
CHUCK:
I like it. I like your answer. Alright, well should we do the picks? Or do you have anything else you want to…
JAMES:
Yeah, let’s do some picks.
CHUCK:
Alright.
JAMES:
That was a fun discussion. Thanks for letting me talk about my tweets. [Chuckles]
CHUCK:
Yeah, no problem. [Laughs] I think it was good, too. And yeah, it’s pushing me to go back and pick up a new language now that I’m done with Scheme.
JAMES:
Yeah. Yeah, I’ll be interested to know what you pick. I assume Swift or something in your future.
CHUCK:
Yeah. I’m probably leaning toward either Swift or Elixir, are two that I’ve been looking at. I’ve also been looking at going back and doing a little bit more JavaScript and deepening my knowledge there. So, it’ll probably be one of the three.
JAMES:
Very cool.
CHUCK:
Alright. Well, let’s go and do the picks. You want to go first?
JAMES:
Sure. I just have two. When this episode airs next week, it will be just before the start of the ICFP Programming Contest, the 2014 edition. This is my favorite programming contest. I’ve done it almost every year for a scary number of years now, because I’m getting old. But it’s the International Conference on Functional Programming that does this contest. I’m pretty sure I’ve picked it in the past. They do this before they have their conference. And then the results of this contest are discussed at their conference, which is really cool. Don’t let the functional programming in the name scare you away. They encourage and welcome entries using any language, platform, whatever. So, you can totally use Ruby or anything else you want.
And what they do is they release a big problem. It’s usually 10 to 15 pages printed or something. And you read through the problem spec and you have 72 hours to build a solution. And there’s usually some kind of scoring system involved to see who wins and all of that. I do terrible. I never win. But I’m like, if I get in the top 50% I feel really, really good, which I’ve only done that a couple of times. But participating makes you feel good. It’s a hard problem and if you can come up with a workable solution, then it makes you feel great. Don’t do it alone. It’s huge. Get friends, lots of friends. Get help. I totally recommend that. But it starts, when this episode comes out, it starts in the US on Friday morning. And it will be done on Monday morning, 72 hours later. So, if that sounds interesting to you, I’ll put the link to their page in the show notes. And you can go check it out.
My other pick is just this interesting thing I found for MacBook users, MacBook, MacBook Air and stuff like that. They have the SD card slot and I don’t think people use that very often. You may use it sometimes to move data back and forth from your various devices. But you probably don’t use it a ton. If you don’t, there’s this insert you can get for it that is like a mini drive. It’s got 128 gigs of space on it. And it fits flush with the computer, so you don’t have to have this thing sticking out of the side of your computer. And it’s neat looking and stuff. So, just a cool way to use what’s probably an empty hole in your computer most of the time. And I’ll put a link to that in the show notes. That’s it for me.
CHUCK:
Very nice. Alright, I’ve got a couple of picks, too. I’ve picked this on the show before, but it has really been paying off for me. I’ve been using Redbooth. Whenever I need Mandy to do something, I usually tell her on Skype but I’ve also been putting it in Redbooth. And then I get an email when she’s done, which is nice because then I don’t have to worry about, okay. She always gets done what I ask her to do, but this way I know that it’s done. And then I can just check it off in my head. I don’t have to worry about it.
So, another pick that I have, and this is something that I’ve been using lately, I picked up a contract where I am updating somebody’s copy of Instructure Canvas. And I’m not sure if I’ve talked about this on the show before, so I’ll put a link to that in there as well. But basically, it’s an open source learning management system. They use it at colleges and stuff. Anyway, I’ve been having to rebase. So, I’ve been doing a Git rebase of the current stable branch onto their custom branch where they have all their customizations. And I’ve been using Emacs and Magit mode. And it has been so nice. It’s not terrible on the command line, but it’s a lot nicer with the tool. So, I’m going to pick Magit mode.
And then I’m also going to pick Fluid app. I know we’ve picked this on the show before, but I didn’t realize that you could actually pay for it. And the paid version has a couple of features. The one that I’ve been using the most is that you can use your Fluid app to actually go full screen. And so, I’ve been putting everything full screen and it’s been really nice. So, you can do that with Chrome, but I like having it just in its own app so I can use LaunchBar to find it, because it searches my applications folder. And then I can just launch it and full screen it and then it just comes up.
Oh, I also have another pick and that is this Belkin docking station. It’s a Thunderbolt docking station. One thing I didn’t realize when I bought it is that it has two Thunderbolt ports on it. And I thought that those were two Thunderbolt ports that I could use but you actually have to use but you actually have to use one of them to hook it up. So, you have one extra Thunderbolt port. But I’ve moved everything off of my Mac Pro that’s sitting on my desk, the big cheese grater one. I don’t have one of the new, sleek, black little ones. But I’ve got that big thing sitting on my desk.
Anyway, I moved everything over to my laptop because the experience has just been a little bit nicer. And so, I just plug it into that docking station. I have to plug my second monitor into the second Thunderbolt on my laptop. But yeah, I plug two things into my laptop. It gives me wired internet. It gives me that extra Thunderbolt port so I don’t actually use a Thunderbolt port using this thing. It has three USB ports on it, a FireWire port on it, and a wired network which you don’t get on the new MacBook Pros. So, I get all of that. I’ve actually ordered another one for my standing desk. I have one of the cheap IKEA standing desk rigs. And I have two monitors on there. So, if I want to stand up, I’d just pull two cords out, take my laptop over there, plug two cords in, and I’m back up where I was.
So, those are my picks. I’ll get links to those in the show notes. And yeah, that’s it. So, thanks for chatting, James.
JAMES:
Thank you. It was a good time
CHUCK:
It was. Alright, well we’ll remind you real quickly. We have our book club book. It is ‘Refactoring: Ruby Edition’ and we’ll be reading that, or talking about it here soon. So, pick it up and read it. And we’ll catch you all next week.
[A special thanks to Honeybadger.io for sponsoring Ruby Rogues. They do exception monitoring, uptime, and performance metrics and are an active part of the Ruby community.]
[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 CacheFly.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.]