The Rogues discuss Ruby trends.

 

Hey everybody, and welcome to Episode 108 of the Ruby Rogues podcast. This week on our panel, we have James Edward Gray.

I'm back from the cold, wet place.

Katrina Owen.

Hello, hello.

Josh Susser.

Hi, good morning. Apparently, I live in the cold, wet place.

Avdi Grimm.

Hello from Pennsylvania.

I’m Charles Max Wood from DevChat.tv. And this week, we’re going to be talking about some of the trends that we see in the Ruby community. James suggested this. And so, I'm going to let him kind of explain what we’re going to be talking about and then, we’ll go from there.

Yeah. So, while I was travelling, I always try to make a point of meeting the Rubyists along the way. And I did that again while I was in Great Britain, which was awesome. I had lunch with Peter Cooper. Thanks, Peter. And I had dinner with London RB -- sorry, I think it’s LRUG, London Ruby Users Group, and the London Rails Girls which is great. And while I was there, I met Tom Stuart who [inaudible] on the show later because he’s great. But he asked me a good question. He said to me, “You go these conferences, you do the Ruby Rogues, you're deep in the community, what are the trends you see happening?” And I told him what I see and he told me what he saw and we discussed that. It was a really great conversation. I enjoyed it. So, I thought we’d play that same game today. So, I'm putting the question to all of you. What do you see as trends in the community?

One of the things that I've seen sort of over the past 18 months or so is much more of an interest in functional style of programming. There was a talk by Gary Bernhardt at Ruby Conf called Boundaries where he introduced his idea of FauxOP which builds on this software screen cast called ‘Functional Core, Imperative Shell’. And I've also seen that there are a lot of other talks that are talking about functional principles for Rubyists or for object-oriented people.

So, Katrina, that was one of the trends that Tom brought up, exactly that one. Yeah, I agree. I think we’re seeing lots of it. And Jessica Kerr gave a great talk at Ruby MidWest called ‘Functional Principles for OO Development’. And it’s easily one of the most accessible functional programming talks I've ever seen. We were getting done with the core principles and how they still apply in object orientation and stuff like that. And I thought it was very good. We’re definitely going to have her on the show.

Yeah. I did like her explanation of that. I think that I've definitely been noticing that trend of digging into functional programming to see what we can learn from it in the OOP world. And I like Jessica’s talk because I think it actually made it more connected to how you do OOP which a lot of the functional talks, I think, just sort of missed the boat on that. There’s Rich Hickey’s talk last year at RailsConf which was off to a great start about functional and object-oriented. But then, I think it took a wrong turn in the middle somewhere. But we don’t need to go into that too much today.

But yeah, I think that’s definitely a big trend. Gary’s take on it, I think, is really interesting. It sort of like Michael Feathers had a similar sort of, what is it, Objects Above, Functions Below. Is that what he called it?

Yeah. I've seen a lot of people doing things where they also doc certain aspects of the functional languages like immutability or I am trying to think of some of the other principles there. But where they build it in and see where it takes them, even if it’s just an exercise. But a lot of times, it then informs their OOP code even though it’s not technically an object-oriented technique.

Do you think this is kind of happening because of the recent rise in popularity of things like Scala and Clojure and stuff like? Do you think that’s what's driving this? JOSH: My guess is that it has a lot to do with JavaScript.

Interesting.

I mean, what is it? Atwood’s Law, he says, “Any software that can be made be written in JavaScript eventually will be written in JavaScript.” [Laughter]

Yeah. I think JavaScript is kind of eating the world right now. In addition to being kind of an objectoriented language, it’s also kind of a functional language.

I like that you said ‘kind of’ twice there. [Laughter]

Well, it’s kind of in the middle, right?

Yeah.

Yes, it is.

Kind of a weird hybrid, right?

It’s not a fully functional language and it’s also not fully object-oriented unless you squint your eyes really hard. [Chuckles] But I think that there's definitely enough functional programming in JavaScript to be able to do interesting functional stuff. People have had to learn about stuff like lexical scoping and dynamic scoping and partial application, all those great things that you get in functional programming. That’s just my guess is that people are starting to get exposed to these stuff in JavaScript and then they got interested in it and they wanted to actually learn how it worked.

Language is like Haskell have been around quite a while and they have their kind of following but I don’t feel like there is big or as grandiose as like Clojure is. Even though Haskell is technically more purer and stuff, it never really seemed like sweep to mindshare or anything.

It seems like functional programming has traditionally been something that’s very academic. The only large scale language that I've seen is, I guess, Erlang is used in telecommunications.

Yeah. That’s a great example. And it too, has been around forever. I mean, it’s very robust, like you say, it’s used in telecommunications where it’s critical to be able to run forever and not die and stuff.

But really, it’s kind of a smaller side following. It hasn’t seemed to sweep like now, we’re really seeing the functional influence is present. Even in the changes in Ruby itself, it got like lazy enumeration and stuff like that where it seems currying came in Ruby 1.9 and stuff like that.

Okay. Do we think this is a useful trend?

Yes.

Yeah, I think so.

In what ways? What's the benefit of learning more about functional programming as you do objectoriented programming in Ruby?

I think, first of all, just expanding your skills and your capabilities is always going to be a useful thing. And because functional programming paradigms are very, very useful in certain types of problems, solving certain types of problems, I think that it will expand people’s ability to solve other types of problems creatively.

The other thing is that I see is we talked about currying and we have lazy evaluation and things like that that have come into the Ruby programming language itself. And those things can be useful as well. And so, just the tools will have to get better because people are exploring these other areas of programming languages.

Not to mention, it’s easier to test.

I think the other thing that’s interesting is that the genesis of object-oriented programming comes from functional programming. That sort has its roots. I think Simula and Smalltalk-72 and the very earliest of object-oriented languages were very much like functional languages that had a mutable state stuck on objects. One of my favorite tricks in Lisp is to build objects using closures, which is probably worth a blog post one of these days. But it’s a fun pattern.

Yeah. That’s a very common pattern in JavaScript as you build your objects. That’s the only way you can actually get “private attributes” or private methods or functions.

Yeah, hide them in the Clojure.

Yeah. One other thing that’s related to this that I found interesting is that I've gone to several talks where they're not adopting necessarily features or functionality from other languages. But they're actually hooking into it. And so, one that I remember from a few years ago was -- I'm trying to remember who gave the talk. But basically, it was a messaging system that sent messages across networks and stuff and it used Erlang to do it. I've seen other systems that they kind of hybridize things with JavaScript and use Node.js for some things and Rails or Ruby for something else either as different endpoints on the same web application or using JavaScript to handle the eventing for things that work better in an evented system versus things that work well in things that are more procedural like Ruby.

I think that’s a good point. And maybe, actually a separate trend altogether is I would seemly seem to be moving to a more Polyglot-type structure. I mean, it’s common for us to use Node.js to run our servers or things like that. It seems like we’re branching out more. Do you think?

I was talking to Anthony Eden of DNSimple a couple of weeks ago. He was telling me about the different languages that he uses and it’s at least, Ruby, that’s kind of where he started off, and then Erlang and also Go. And it’s not a big company. It’s not GitHub. I mean, there are like what? Two people working there?

Yeah. Isn't 37Signals server for…

Campfire?

No. Is it PAO? That’s Node, right?

It’s written in Node, yup. I think it uses Nack.

Yeah. It seems like we’re seeing more and more of that, that it’s accepted that we’ll just use lots of different tools for whatever seems to be a good fit here.

Okay. So, there's the good fit argument but there's also the laziness argument. If you look at something like the asset pipeline in Rails, that actually requires a JavaScript Runtime to do some of the work. And it actually doesn’t need to be based on a JavaScript Runtime. It’s just that when the feature was done, that was the simplest way for them to get it implemented. My opinion is that they made a bad choice about that in introducing that dependency because it made the Rails core team a little bit easier, they made the work on the feature a little bit easier and made it way harder for everybody else in the world who’s using Rails.

That’s an interesting point. What you're saying is and Matz has talked about this. He’s talked about how Ruby is very English-like. And sometimes, that makes the internals of Ruby very complicated because different things mean different things and certain context in Ruby seems to just kind of almost know the difference of whether or not you're dividing by something or defining a Regular Expression. He says that if that makes his job harder, that’s okay because he just has to develop the language once and get it all working but then, we use it all the time.

Yeah. That’s the point that I was making.

It’s an interesting thing, though, like I mean, in defense of the asset pipeline, how ubiquitous is JavaScript these days. It seems like it’s almost everywhere. I mean, most modern computers do include a JavaScript Runtime except maybe servers where you're typically deploying to, then you have to go out and grab it if you want it. But Postgres ships with the JavaScript Runtime now, right?

That’s true.

Yeah. Like I said, JavaScript is eating the world. I'm not the first person to say that. But I think that some languages, because of the history of the evolution of the language, they're just what it gets used for commonly. Some languages have a better tool set for solving particular kinds of problems.

Erlang is great for messaging and Ruby is great for doing things together.

Correct me if I'm wrong. But in the asset pipeline, it’s actually used to parse JavaScript because they do like a minimization of JavaScript. Is that right?

Hmmm.

Yeah. But I believe that what they're doing there is not something that actually requires a JavaScript Runtime. It’s really just string manipulation kind of stuff.

The CoffeeScript compiler is written in CoffeeScript and compiled to JavaScript. So, you need a Runtime if you're using CoffeeScript especially if you need it, just hook it in.

Right. But if yours assets in the asset pipeline don’t include any JavaScript, you don’t even have CoffeeScript, I guess, then you still need the JavaScript Runtime, I believe.

I think that’s kind of a failing of Ruby’s dependencies. I've ran into that issue before with HighLine where we would prefer to work with termios because everything is easier and better that way. But if I had put a termios dependency on there, then I run into trouble when people try to install it on Windows where that’s not easily available and stuff like that.

Okay. So, the point that I was trying to make though, is that the polyglot approach to things, I think is often great. We had a great talk on this two years ago at GoGaRuCo. Blake Mizerany who wrote Sinatra did a talk about being polyglot and all the different languages that they use at Heroku. So, that’s a great example of using the right tool for the job. My point was that there is this other side of that which is people reach for the familiar tool, the one that they know well or they have experience with. And I think a lot of times, that’s a great way to make a choice about which technology to use.

But if you're doing that just because you don’t want to bother learning something else that may be a better fit for the problem you're solving, then that gets you in trouble.

Hmmm.

That’s a good point.

That’s just my old commonage speaking.

What other trends have we seen?

I can point one out that I've been seeing and that is NoSQL.

Yeah. It’s a favorite.

A lot of people talking about NoSQL.

It’s very true.

Yeah. I'm really excited about MagLev. That’s my favorite NoSQL. [Laughter]

Katrina, what were you going to say?

I was going to say rather than NoSQL, can we just say non-relational datastores?

Yeah.

Yeah. Is that the politically correct term for NoSQL?

I don’t know. It seems odd to me to call it NoSQL when there are a lot more ways of storing and retrieving data than using SQL. I don’t know. It seems like an inverse definition.

Yes. It’s not like SQL even came first, right?

Yeah. [Chuckles] It shows you how much relational databases own the web development world or even just the development world in general. There's SQL and then there's everything else. It’s obviously one.

We’ve been seeing relational databases hopping on this trend. Look at Postgres, with all the different things it includes, it can do inverted indexes for searching [inaudible] or HSTORE is almost kind of the built-in mini document database or its XML parsing, to me, is in a similar way or now it includes a JavaScript Runtime engine it we can store JSON and stuff.

Yeah. It is really interesting. The other thing that’s interesting about Postgres is it actually includes a pass through capability so that you can pass through requests to the other systems like MongoDB or whatever you're using. Another thing that’s really interesting to me is that I've seen a lot of people moving off of Memcached which has been around forever and on the Redis for their caching.

I've seen this as well and one of the things that I'm curious about, I haven't used Redis very much. But I accidentally discovered in the worst way possible that there's no like, keys don’t automatically expire like if you fill up your Redis, it doesn’t seem like the oldest keys just kind of fall out which was not my expectation.

This is actually a trend that I've heard of from several people is misusing Redis.

Misusing Redis is a trend. I like it.

Yes.

Yeah, it’s correct. I actually am pretty familiar with Memcached/Redis scenario. So, Redis is great and I love Redis and it does lots of different names. But using it as a cache like Memcached is, is really dumb in my opinion because like Katrina says, it’s not as easy to just set a boundary. And what's way worse is Redis’ expiration of keys. It’s not near as intelligent as Memcached’s expiration of keys. Memcache will favor the stuff that hasn’t been hit in a long time, whereas in Redis, if I recall correctly, a read has no effect on the time to whatever or things like that. In my opinion, Memcached is still, by far, the better caching system. But Redis has other features that may get valuable, in my opinion.

Yeah. But I've also heard people swearing up and down that MongoDB is the best thing ever for anything ever, ever. My thing is I look at them and I've played with some of them. I found that if you have different types of data, then you can play to the different strengths of some of these systems.

But MongoDB doesn’t answer everything just like relational databases don’t answer everything.

Oh, come on! There's no silver bullet technology that answers everything?

I'm going to write a database system and I'm going to call it ‘Silver Bullet’.

The problem with silver bullets is maybe you're the werewolf. [Laughter]

I am not a werewolf.

That’s what all the werewolves say.

I'm just an ordinary villager, really.

This kind of seems to go with the polyglot trend. The polyglot trend seems to apply to tools, languages, databases, everything. I mean, we have books about that. There are some languages and [inaudible], some databases, and [inaudible], stuff like that. And I think it’s kind of this overall trend of picking all of the [inaudible]. I'm inclined to agree with Katrina about how we’re learning new techniques because it just makes us better able to solve problems and I think that’s generally a good thing.

The other obvious trend that has been going on for a couple of years is Rich Applications in JavaScript in the Browser.

Yes.

That’s the one that makes me think I need to retire. [Laughter]

Now, we have Backbone and Ember and…

Angular.

Yeah, Angular.

Knockout.

Yeah, all of these.

And then we’ve got some that have been around for quite a bit longer like dojo. There's a ton of stuff out there.

Yeah. Well, Ember came from -- what was it, SproutCore, which has been around for years. Yeah. And I think that the community is still kind of figuring out what's a really effective way to build this kind of applications and know this one approach that there seems to be a ton of energy around exploring how to build these applications using Node on the backend and JavaScript something on the front-end.

I'm hoping that everyone’s going to figure out how this whole works and then, I can jump in and work around it properly. [Laughter]

Well, speaking of trends, let me see if I can find this post really quickly. It’s on my mind. Actually, this was the last useful thing I put on my blog a year ago which is talking about trends. So you say, okay, great. There's this trend about server computation versus client computation. And I guess the trend is it goes back and forth. It’s like, first we had mainframes where everything happened in the centralized computing resource and your terminals were dumb. And then, over the decades, it switched to Sun workstations and the network is the computer. There's no mainframe. It’s just workstations. And then, it switched back to the servers do all the work with web servers and now, it’s switching back to rich applications or where most of the application is implemented. It goes back and forth and I think we’re deep into the swing, to the client right now. And we probably have several more years of learning about how to build these things well. And then, eventually, somebody’s going to figure out something that runs better centralized on a server and things will start shifting back the other way.

Yeah. The one thing that I think is interesting about this particular trend is that a lot of folks, they get all excited about the hype of a single-page app. And in reality, it would take them twice as long and the code would be infinitely more reasonable if they would actually break it up. I mean, you can serve the rich frontend but you don’t have to put everything in one big giant mess of JavaScript.

We’re seeing some interesting hybrids like Basecamp Next, I guess it’s called. It uses primarily server side stuff with the famous [inaudible] all caching, how they got everything working well there. But then, there's an exception. Like the calendar or something is Backbone. And they're trying to use it where it makes sense, I guess.

Yeah. And that’s the approach that I favor is use where it makes sense.

It is an interesting concept, right? I mean, that one of the things we’re always concerned with is how fast can we build. Not how fast can we build, how fast can we surf pages? I just got done listening to the Discourse episode. Jeff is really concerned about how many milliseconds it takes to get those answers. And by awfully doing a lot of those process into the client, that’s an easy way to get to those at times.

Oh yeah, absolutely. I've been thinking that that’s probably the best advantage economically in the long run. If you just look at a company like Google, by far, their biggest expense is their power bill for the data center is running all of their servers.

Google is kind of an interesting example because in recent years, I was just reading an article the other day about how they're dropping XMPP for Google Talk in favor of Hangouts, basically. So, they're going for [inaudible], talk to anything kind of approach to the more proprietary stuff.

Okay, that’s a totally different kind of trend. But I think that that’s orthogonal to where the processing is happening if it’s on the server side or the client side. If you look at Gmail, they took the traditional web mail and moved all of the business logic or all the application logic and interaction to the client into the browser. And that saves them a ton of -- basically what it comes down to is the economics of how many watts do they have to pay for to serve up the Gmail pages.

So, I'm paying their power bill now?

[Chuckles] That’s right.

Well, their advertisers are.

Ah, okay.

[Chuckles] So, indirectly, you are. But yeah, just the economics of it, every time you click on the page, that cost will be a certain amount in the power bills to run the server to render that page. If you can move that into the browser and reduce their expense, that makes their business more profitable. So, I think just the economic realities of things when you operate at that scale are going to push people to more and more [inaudible] on the client side. But James’s point about Basecamp Next and all of the optimization that 37Signals has done to make the server side economical, that’s a reasonable approach too. There's not only one way to skin that cat.

Is this client side thing being driven perhaps a lot by the proliferation of the mobile device? Now, we have lots of scenarios where you're online, then you're offline, then you’re online, then you're offline. So being able to do things client side and then save up that communication for the server is maybe more advantageous now.

There's definitely some of that. But I think a lot of it also ties into the fact that our browsers are becoming more capable. With HTML5, there are a lot of different things that you can do with JavaScript in the browser that you really can't do on the server. And I think there's some of that too.

I think it’s a good mix of that.

Good gaming is like huge all of a sudden in the browser, right? Thanks to HTML5 and stuff.

Right. And you can either manipulate it through SVG or you can actually get a Canvas element on there and manipulate it that way. Canvas element is just a bitmap that you manipulate through JavaScript. But yeah, it really comes down to a lot of the sub-browsers are much more capable now and so, we can do a lot of these awesome stuff in it.

Alright. Would you like to talk about anymore trends?

Yup. In the past two years or so, there has been a proliferation of very short developer training programs like from the six-week to the eight-week to the 12-week to the six-month. And they're churning out junior developers of varying ability.

I know nothing of such things. [Laughter]

That’s a great one. I didn’t get it though. So, how does it work, Katrina, since you have first hand experience. How well does it work?

I only have experience from the longer program type, I guess. I work at JumpstartLab. And we do a six-month developer training program. And since we are able to spend six months with these students, we can take people who have virtually no programming background, whatsoever. And it works really well. The students have been working for four months now and they have some really interesting basic skills kind of across the board. We focused on Ruby first, and then on Rails. Now, they're going into more API integrations and performance and scaling and security, and sort of SOA-type applications. And so, they're able to at least touch on a lot of subjects. In the shorter programs, I think that people need to have more of a programming background. You have to have at least played with some type of programming so that you have a basic understanding of control structures and assignment and scope and things like that to actually make it through the program successfully.

I can speak to that a little bit because I've been doing the Rails Ramp Up course which is me teaching people Rails. And there's definitely that element to what I tell people that it helps if they're familiar with HTML and CSS. They don’t have to know Ruby but it really makes a difference in understanding what's going on. And I don’t go into a lot of the Ruby idioms and things when I teach the course because it is only eight weeks. And so, I focus mainly on giving them what they need to know to write a basic Rails app and then offer to do any level of coaching that they need during those eight weeks. But yeah, it does help if they have some programming background even though I'm willing to help them during that eight weeks, sometimes, it takes a little bit more experience to do that.

Is this being driven by an overall demand for more and more programmers?

It seems like it. It seems like there is a need for people who can shovel code like basic websites. Not the really difficult problems that GitHub and Amazon and Rackspace. All these are solving. But the day to day small business or internal tools, there's just such a huge need for people who can write code effectively and quickly. And people are searching for Ruby developers all over the place and not necessarily finding them. So, they're hiring people who write Java and C++ and C# and Python who end up, of course, learning Ruby quite quickly. Within three months, you don’t even realize that they haven't been writing Ruby all their life. But there is definitely a demand for more and more Ruby programmers.

I think another angle on that is that people are seeing the opportunity there because obviously, the market for these courses to some extent, are the companies that want to hire Ruby people and can't find them so they train them. But there's also the people out there who are looking to find a position or better their situation and figure out that there is opportunity there. And so, they actually go and they sign up for these classes and pick them that way.

I think that that’s dead-on. But there's like a small related trend, I think. I'm not quite sure what they call them. I guess, diversity expansion groups that have been forming around Ruby and Rails training. RailsBridge is the first of them and now we have Rails Girls and Black Girls Code.

There's also CODE2040, I think, in San Francisco.

Don’t know that one. [Chuckles]

When Tom asked me the question about the trends I've been seeing, my first response was that I think we’re getting more diverse. And in saying that, I didn’t just mean like getting women and other minorities into programming. Actually, I meant that at conferences, I'm seeing keynotes from names I don’t know and stuff like that. And I really love that trend overall. I always find it so great to hear from -- I mean, I love the people that I know and stuff like that. But also, sometimes, I feel like I could probably get their keynote at this point. You know what I mean? I've heard their thoughts enough and I like hearing from a more broad group and new ideas. Even in my own talks, when I'm giving speeches now. At Scottish Ruby Conf, I was sitting up on stage, getting ready to talk. And I was just looking around the room thinking, “Don’t all of you people know, there's some other great talks going on right now?” Like, “Why are you in here?” [Chuckles] And I think I like that, that there's lots of new voices spreading lost of new ideas. I love that.

One other trend that I want to talk about just for a minute is the trend toward remote workers. It seems like that’s becoming more and more common. I've talked to several people that don’t live in the same State or even in the same country as the company they're working for. I find that fascinating, as well.

That’s a great point.

I've been definitely picking up a trend of just more people doing it and becoming more normalized in my interviews for The Wide Teams Podcast. It’s funny, I've kind of started to get a lot more interviews with people that start out with, “Well, I used to have a two-hour commute,” or something like that. “And I listened to a podcast for a while and I got myself a remote job.”

And then, they don’t have time to listen to the podcast anymore. [Laughter]

Well, yeah. That’s what they say. The implication is always that they don’t have time to listen to the podcast anymore. But yeah, I'm getting kind of a -- I don’t know what to call it, like a second generation or something of interviews and there definitely seems to be a more appreciation by a lot of companies that remote work really works.

I think it ties back to what we were talking about before with more companies wanting to adopt Ruby but not being able to find developers. And the ones that I see struggle the most are the ones that will not hire people who are working remotely.

Yeah.

What do you think the next version of remote work is going to be? I think that remote work is, in a couple of years, going to be so accepted that it’s going to be pretty much the same thing.

Working from space. [Laughter]

I don’t know! It could be something like that. It used to be that you were much more tied to the office schedule and then we got flex time and different commute hours. I just wonder what it’s going to be in 20 years or 50 years or whatever when telepresence and virtual reality and all that is just so integrated that sitting down at a table or a desk and pairing with someone doesn’t really feel any different.

Yeah, that’s what I was going to say is that there are still some communication roadblocks. For the most part, I think people figure out how to get around one way or the other. But they're still there and there are still issues that you have to deal with, being a remote worker. But at the same time, I think those are the next steps are lowering that barrier. I think you hit it dead-on. In 50 years, it’s not going to make any difference.

Technology-wise, I would love to see the day when we have wireless technologies that let me do my remote work in the middle of a park, somewhere with my Google glass on, to see my pairing partner’s screen. I can be that crazy guy in a park bench that’s talking to nobody.

Or you could be that person in a bar who I think I'm having a nice intimate conversation with, but you're actually trying to solve The Halting Problem. [Laughter]

Yeah, but who knows? We may have ocular implants or something and so, when you're pairing with somebody, you just switch modes in your head and then, you see their screen. Nobody else can see what you're looking at. But you have that level of ability to see what they're seeing and communicate with them without necessarily even disturbing anyone else or anyone else even knowing that you're doing it.

I'm sorry. I just love how we’ve gone off into science fiction here. [Laughter]

Yey!

Bringing back, I met this programmer at Scottish Ruby Conf named Jake. For now, I'm [inaudible] to me because he brought me over and said, “This guy is from Oklahoma.” And so, we started talking but he actually hasn’t been in Oklahoma for a long time. He’s been travelling all over Europe and the UK and stuff. And he brought this up. He basically just went into his employer and said, “Does it matter to you where I am when I do my job?” And the employer said, “No.” So, he left. But yeah, I think that’s the trend, even the bigger guys. Twitter, when they were first formed. I know I had some discussions with them. And when they were first expanding and getting big, they did not take remote workers. At that time when the trend was changing, it was a little lurky. But nowadays, I think for the right people, at least they do.

Yeah.

Thoughtbot also had a no-remote-work policy. And then, they lost too many people. And then, when one of their other best guys was going to move to Sweden, I think, he was like, “Okay. I'm quitting because I'm moving to Sweden.” And they were like, “Maybe we should rethink this.” [Chuckles]

Yeah, right. I mean, there’s lots of programmers out there. And I realize there's an especially large number of them in San Francisco. But there's also an especially large number of companies hiring programmers in San Francisco. So, if you want to have a larger pool, you're going to have to take remote workers.

In the scenario that Katrina brought up is the situation that I've seen most often bringing companies into this is they have somebody that they deem is indispensable that, “My mom has some critical illness and I have to be there to take care of her. And she lives across the country. So, I have to move, I don’t have any other choice.” And so, the company is faced with losing this person or giving them some other option. And so, they wind up allowing them to work remotely. And then, once they figure out that it can actually work, then they start saying, “What other brilliant people can we bring in this way?”

And these decisions, if they're made well, all come down to economics because people are running businesses, they need to be able to be profitable. So, if they can get the value out of somebody more cheaply, if they can get more value from a programmer who’s sitting three time zones away than they can from somebody who’s coming into the office, then sure, that’s a great decision for them to make.

To me, it’s so much more valuable to be like here, in my house, in my comfortable office, choosing to work whenever I want to work and it’s convenient for me. I do a lot more work and have higher quality here than I would in some office.

Yeah. I think that’s true for a lot of people. Okay, here’s a related trend. And I think that maybe even David Hansson was talking about this a couple of years ago, about the Reversal of Outsourcing. Ten years ago, everybody was outsourcing their development projects to India or The Ukraine or some place like that.

That’s a good point.

And that’s driven by economics, like I was just saying. If you can create the same value for less cost, then that’s a real win for your business. But if you look at tools like Rails or even just Ruby that make programmers more productive, then you can get that same sort of economic advantage by having a team that’s good at those tools and that is more productive than dealing with all of the overhead of communicating with the team that’s halfway around the world. Is this a trend people have been seeing? I don’t think I've been on a project in over five years that’s wanted to outsource development work to India.

I have.

Okay.

Well, to The Ukraine. It turned out to be too difficult to communicate. So, after six months, we stopped doing it and did everything in-house again. The communication itself became too expensive even though the development work itself was far, far cheaper.

Right. So, that’s a more succinct way of saying what I was saying before. There's all this overhead in dealing with a remote team like that. And if you can save money by just having a more efficient process locally, then that makes up for them.

Yeah. And it’s interesting because usually, those outsourcing decisions are made because they look at your per-hour in the US and your per-hour over there. And they miss those trade offs that we’re talking about here whether it’s language barrier or skill level or something else. And I'm not saying that folks in Ukraine or India are poor developers but you do have to deal with some of these things that dissociate the important parts that you need to get across.

Can I throw out one more trend before we call this quits?

Sure.

Tom brought up a really interesting one to me. This was more of his. But he said that he sees a trend overall toward us learning more about object orientation or better ways to build software or things like that. And he believes that Ruby was almost kind of this rebel culture where we were running away from all these things like Java and not having practices and stuff like that. In the beginning, that allowed us to build software quickly and move faster and stuff. And now, we’re reaching the point where we have ten-year-old Rails applications and stuff like that, that have been around for a while. And we have to start weighing, how do we maintain these things, how do we keep them growing, how do we handle them in the future? And now, maybe we’re looking back and saying, “Some of these ideas aren’t bad.” We should bring them forward with this because they help us in certain ways. He thinks that a trend of kind of bigger interest and those things. What do you think?

I think it’s absolutely right. Just look at all of the talks that have been done over the past year, maybe 18 months, about more object orientation in Rails like putting Rails on top of your app instead of having your app be Rails.

The other thing that I was going to point out was just look at how wildly popular the practical objectoriented development in Ruby was. And then, how much feedback we got on our episode on it where we went two hours talking about it because we were interested in it.

Right. I think it is a trend that we’re seeing. People were trying to find better ways to build software and I've said this at Ruby MidWest but even our drama, the fights we get into on the Internet. Two people really arguing about the best way to build software. That’s not necessarily a bad thing.

Yeah. So, this trend I've bee thinking of is Rails+. I think Katrina was saying something about that just a moment ago. It’s like service-oriented architectures on Rails.

Right.

When do we get to Rails++? [Laughter]

That’s the next one.

[Chuckles] Rails, the Next Generation.

[Chuckles] Yeah. So, one of the things that I realized when we were doing the episode on Martin Fowler’s book on Patterns of Enterprise Application Architecture, is that I think that a lot of those patterns, we’ve seen them get reinvented over and over. So, ActiveRecord in Rails, a lot of people, that was the only object relational mapping technology they knew of. And then, they started running into the limitations of the ActiveRecord pattern and wanting to decouple the persistence representation on the database from the runtime objects behavior. You end up with people trying to build data mappers and other sorts of persistence patterns. And a lot of times, they didn’t have the benefit of experience like Martin does, or they haven't looked at his books. So, they stumble across these other solutions. I think that maybe a trend is sort of rediscovering all of the old stuff. [Chuckles] So much of these stuff has been done before and known about for a long time and we have the population of, I think, Ruby developers especially web developers are significantly selfeducated and don’t necessarily have formal education Computer Science and know all of these. And even a good form of education in Computer Science misses a lot of this stuff anyway because it’s more like Engineering than Computer Science. It’s seems like there's a lot of rediscovery of old stuff going on.

I agree.

I guess that’s just the nature of the field as it evolves.

Yeah. And it’s all related back to what we were talking about before with better ways of making software, better ways of doing object orientation, better ways of doing all these things. We’re going back to the kind of the canonical code stuff.

[Laughs] I don’t know. But some days I look at the progress of computer software and think that the only real innovation that has come along in the last several decades is ways to more effectively use

RAM.

I look at this iMac. I have like 12 freaking gigabytes of RAM in this thing. And yeah, it does a lot of really cool stuff. But I used to do a lot of really cool stuff in like a couple of dozen K of RAM.

So, by more effective ways to use RAM, it’s more effective ways to use more RAM?

Yeah, basically. [Laughter]

Now, if you hit the minimize buttons, see the window bends and twists. It’s really cool stuff.

[Laughs] I know. But I wonder about my personal effectiveness measured in the amount of RAM that I use. [Laughter]

I don’t think it really increased. [Chuckles] I think the software has gotten really good at using a lot of RAM.

Yeah. David was telling me about the last PC he bought which is pretty recent and it has like 32 Gig of RAM in it.

[Expression] It’s like, oh my God! [Laughter]

And it’s gotten so inexpensive that you can just do it.

Good thing. [Chuckles]

Yeah. [Laughs]

We’re drifting. Can we…

[Laughs] Yeah. Anyway, shall we get to the picks?

Sure.

Katrina, what are your picks?

Alright. On the topic of polyglot-ism, if that’s a word, I am picking GopherCon. The first ever Go Conference which is going to be held here in Denver in April of 2014 and I have my ticket and it’s going to be awesome. You should be there.

That is cool.

Wow!

I thought it was a conference about an old part of the Internet that nobody ever uses anymore.

I thought it was a conference for rodents.

Avdi, what are your picks?

I saw a really good talk video on Prolog by Aja Hammerly. I don’t know if I'm pronouncing it right. But one of the best short intro to a language talks I've seen. And that’s a neat trick with Prolog because it’s so far outside of the way we usually think about programming. So, I highly recommend it. And for not-so-programming pick, I was looking over the list of picks recently and was very surprised to see that I've never actually picked my favorite beer. So, my go-to beer that I like to keep around all the time is Troegs HopBack Amber Ale. If you can find it, get it. It’s just a great allaround everyday beer.

Awesome. James, what are your picks?

I have got a few. First of all, Avdi was just showing me this new library before the show called naught that he wrote. And it’s about the null object pattern which I just got done speaking about at Scottish Ruby Conf that I like the null object pattern. And this thing is like the null object pattern on steroids. So, it’s really cool because you can make all kinds of null objects with the special behavior, conversions, and all kinds of neat things. A really neat library that everyone should check out, if you're into patterns. And then the other one kind of tech, kind of fun. I mentioned before that I went and saw all the Rubyists on my trip. I really enjoyed that. I even had two Rubyists, Chris and Shawn from the BBC Email me while I was there and I went and saw, they gave me kind of a behind-the-scenes tour of the BBC while I was there and told me what kinds of things they're working on with Ruby which is really great. So, I just have to stress, this is a travel tip. If you're going to some cool place, reach out to the Rubyists in any area, they're generally great people and you can just have dinner with them and learn about cool things. I find it very enjoyable to add to my vacations. And then for one totally fun pick, while I was in Great Britain, I spent two weeks with my brother who was the music guru extraordinaire. And so, he always tells me why everything I'm listening to is terrible and what I really should be listening to. I have to admit, he got me hooked on a few things. And one of the artists he has me hooked on is the band, it’s called The Civil Wars.

And this male-female duo that just does great harmonizing and really great music. If you haven't listened to The Civil Wars, I recommend it. Those are my picks.

So, the BBC, is it bigger on the inside?

[Laughs] No. It is huge. I mean, just the amount of buildings they own. I only saw one, their newer broadcasting headquarters. But it was really cool just going there and see them making the news and recording radio shows and stuff like that. It’s really great especially if you're kind of a British nut like I am.

Is watching them record radio is as interesting as watching people record podcasts?

[Laughs] It was more interesting than you might imagine just because they told us about things like, “This is the studio they use when they bring in live bands and stuff.” And as I said, I had my brother, the music geek tagging along. He’s currently in college for production of these kinds of stuff. So, that was really cool.

Nice. Josh, what are your picks?

I would really remiss if I didn’t mention that the Golden Gate Ruby Conference CFP is open and should be open for another week when this podcast is posted. It’s running through midnight, June 13th, Pacific Time. So please, send us proposals for speaking. Yey! GoGaRuCo.com. And then, my other pick is in honor of Mike Moore. Mike Moore is the biggest Bronie that I know.

So, I was bored one night recently and I decided to go and watch an episode of My Little Pony because Mike does such a good job of talking about it. [Laughs] It actually was kind of amusing. There's a lot more subtle grownup humor in the cartoon than I was expecting and it’s sort of like the new Bugs Bunny. Bugs Bunny was the cartoon for grownups when [inaudible]. So, My Little Pony: Friendship is Magic. [Laughs] And it’s on Netflix streaming so you just watch it there. It’s actually pretty funny.

Yeah.

“You guys are my friends and you make everything magical.” Okay, that’s it for me this week.

Alright. So, I’ve got a couple of picks. The first one is it’s a JavaScript library that I've been playing with. I've had trouble in the past finding a good calendar UI for the web that I liked. And I found one and it’s called fullcalendar. And it looks really good, it’s very interactive. It’s sort of like Google Calendar but not entirely. Anyway, I really like it so I'm going to pick it. Another one that I'm going to pick and I know this has been picked in the past. But I've been watching all of the Star Trek Next Generation shows on Netflix. And it’s kind of fun to go back and watch it and, “Oh, I remember that now!”

Chuck, if you're watching Star Trek Next Generation, are you playing along on the Star Trek Next Generation Fashion blog?

No. I should be, huh?

You should be. Their commentary on the episodes is relevant.

[Chuckles] Okay, I’ll check it out.

Can I sneak in one pick related to yours? [Chuckles]

[Chuckles] Go ahead.

I'm actually reading right now, The Physics of Star Trek by Lawrence Krauss. It’s really kind of a neat book because it goes through all the different things you see a lot in Next Generation but it does touch on the other series as well about what’s an inertial dampener, how does it claim to work, does that work, could we make an inertial dampener. All that kind of stuff. And why do tractor beam work? So, it’s kind of a fun way to learn some physics if you're enjoying Star Trek.

Nice. So, my last pick is actually a Rails app that I am using to manage some of my git projects. And that is GitLab. It’s kind of a GitHub clone. It’s not nearly as fully-featured, obviously. But it’s self-hosted and it’s very nice.

Kind of?! It’s almost exactly GitHub, right? Doesn’t it look like GitHub?

It does. It looks a lot like GitHub. GitHub has a lot more features to it but for a lot of the features that I use most commonly, GitLab has them.

When I'm using it, I always wonder, “Are these two people still friends?”

It’s funny because GitLab, all of the instructions and everything for you to get it are in the Read Me in the GitLab project on GitHub. [Laughter]

Anyway…

That’s like the textbook definition of irony.

Yes, I guess. But the main thing for me is that I have clients that want private repos and things like that. I've got projects that I don’t necessarily need to have on GitHub that I don’t want to pay for a private repo for. So, I'm posting it myself.

This is, I guess, taking the place of Gitorious as the roll your own git server?

Gitorious and Gitosis. This is just nice because it has a nice graphical interface on it.

It has the GitHub interface. [Laughs]

Yeah, it has a nice GitHub graphical interface on it.

Are you trying to tell us something, James?

[Chuckles] I'm just saying seriously, when you use it, it’s a little shocking.

Yeah, it does. It looks a ton like GitHub. Anyway, those are my picks. We’ll wrap this all up. We’ll catch you all next week.