The Rogues talk about Vagrant with Michael Ries.

Special Guest: Michael Ries.

 

Has anyone actually met David Brady’s wife -- and is she real?

Yes.

That's an excellent question. Chuck claims she’s real, but that's as far as we know.

I can do one better. I have seen David Brady and his wife in a church. [laughter]

We were setting it on fire, but he did see us there. [laughter]

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

Good morning everyone!

Katrina Owen.

Hello!

David Brady.

Holy crap! Did you just say “Katrina Owen”?

And I'm Charles Max Wood from devchat.tv. We also have a special guest and that's Michael Ries.

Yup. Good morning interwebs!

So we are gonna be talking about Vagrant – but before we get started, we are going to have a Best of Parley from James.

Yeah. The cool thing about Parley this week (in my opinion) is that you can basically use it as the insider information channel on the Ruby Rogues. For example, if someday we were to bring on a new Rogue, it might just happen that we would mention it there. Another thing that's been announced there is the Ruby Nuby project winners -- which are Elise Worthy, Erin Parker, Geoff Petrie and Matt… I'm going with Ruzicka. He didn’t pronounce his last name in his video, so if I got it wrong, it’s his fault.

My money is still on that he cannot pronounce his last name and so he doesn’t.

That's a good point. We will challenge him to do so when he gets on the show.

Yup.

And then whatever he goes with, we will say he is wrong.

If he actually can’t, I'm going to feel bad.

Now I'm building a Rails app that's a random last name generator.

[chuckles] So we will have those Nubies on the show in the future time. And so, Ruby Rogues Parley is a great place to find out what we are up to when we are not recording episodes.

So if we were to announce a new Rogue on the mailing list, who would the new Rogue be?

I don’t know. You have to sign up for the mailing list to find out.

All right, that's fair. I guess somebody is paying attention to the call or the careful listener may have already figured something out. What are we talking about today, Chuck?

We are talking about Vagrance or Vagrant.

We can talk about Vagrance too. [laughter]

This is going to be the best episode—

We are experts.

Since Josh isn’t here, I felt kind of compelled to provide a definition this time. So I looked it up in the dictionary -- it’s a person without a settled home or regular work who wanders from place to place and lives by begging.

We are all contractors, right? [laughter]

So Michael, tell us what you had in mind when you brought up the topic Vagrant?

So I was listening to the Developer Environments episode and when I think it was David who was talking about switching back to Linux and you and Avdi were kind of on the pros and cons of being on a more pure Linux type environment versus Mac OS. And I think I just tweeted at Ruby Rogues and said, “Hey. How come none of you guys brought up using Mac but running Vagrant? Because that kind of gives you the best of both worlds.” And somehow that landed me here.

Oh. So I have an answer for you -- now that you are on the show -- it’s because I've done that extensively and it’s awful!

Uh-oh.

No. Actually I freakin’ love Vagrant. I'm not a huge fan of developing in virtual machines just because I can feel the speed hit when I leave native hardware and go into… what's the operative of native? Anyway, non-native hardware, virtual machine. But what I freakin' love is the push button development environment. It’s like check out the repo and you know, install Vagrant and do Vagrant up and you are done -- and it’s built everything. I love it.

Yeah I think that's a big pro. And definitely one of the other big pro is just having a development environment that's a lot more of like where your is going to end up actually running in production.

Yeah. Can you kind of describe -- for somebody who doesn’t know what Vagrant is like, this is a mind bending experience -- can you describe what it’s like just walking it off the street as a developer (as a vagrant), walking it off the street (sorry I meant to say contractor) and you've got this vanilla Macbook Pro or Linux machine. And how do you get from there to a fully set up working running development machine?

Yeah. So I think the easiest comparison you can make (that maybe a lot of developers have experienced with is) if you’ve ever come on to a new team and they assign you a development machine -- so some pretty small VM that lives in the data center and it’s running something similar to the production stack -- that's kind of your box and now you install whatever dependencies. And usually what I tell people is like, “Hey when you walk in to a project, how many days do you spend just trying to get that freakin’ thing working?”

Yeah.

Just trying to get to the point where you can see a screen that has the code running and you can actually start to write some code -- and it can be extremely frustrating. So like a typical Vagrant workflow would actually look something like you opt in the new team and they say, “Hey, we put you on a GitHub organization. Go pull down this repo.” And you install virtual box and Vagrant (which are two relatively small downloads) and then you save Vagrant up and there you are - the whole thing boots. It should take… I don’t know, for most of the machines we use to work, it’s sub five minutes -- so one to two or three minutes, something like that -- and it is running and you can immediately just open up your browser and see that app running.

So the config comes from the Git repo you checked out?

Yeah. So every project you just have a Vagrant -- which is just Ruby code. It’s just Ruby syntax but you can just stick it in the root of your project and then the Vagrant CLI will see that file and know what base image to use, how to provision it -- stuff like that.

So you just get… you set up a Vagrant file in your directory wherever you wanna launch Vagrant from and then you just Vagrant up and it goes. My understanding is that the Vagrant file is Puppet or based on Puppet or similar to Puppet.

I think. And I may be wrong, correct me here Michael -- but I believe you can actually choose which provisioner you want to use. And I think it supports things like Chef and Puppet, and also just straight shell if you just wanna throw some shell commands on it.

Yeah. So you can mix and match to some degree as well. So if you wanna use a few shell commands to kind of kick things off and then from there, jump in then go ahead and boot to Puppet then it will do that for you. I've even seen my sys admins at work for some reason like CFEngine.

And so I even looked into CFEngine that will let you configure it using the existing CFEngine rules. But we found out that CFEngine is terrible for provisioning, and so we ditched that and just went back to Puppet and tell sys admins to suck it up.

That is a fair point though. Vagrant supports a pretty rich plug in architecture, right? Where you can pretty much change just about anything you wanted.

And it works with virtual box off the shell, right? Does it work with any of the others like VM Ware or…

Not that I know of.

It’s just VirtualBox. Is that Oracle? Oracle’s VirtualBox?

Oracle’s VirtualBox. Yeah. The other one, my favorite (not my favorite) but the most fascinating provisioner I've seen with Vagrant is nothing. Where I've walked into a team and they said, “Check out this image file.” And it was already provisioned. And it had the database set up; it had test data in it. I think it had uncommitted files in the repo. It wasn’t great, but the point is that you can tell Vagrant, right? “I want you to go ahead and to bring up this blank machine and I want you to install PostGres or I want you to install Ruby on Rails and I want you to recompile of a custom version of Ruby.” But if that's something that you do all the freaking time and it never ever changes, you can just snapshot the image and then say, “Vagrant is going to start with this. Go.” And you are just done. I like that.

In some respects, it kind of makes me think of EC2 that way.

Mh-hmm.

You know, you have the EC2 images and you kind of take an EC2 image and then customize it to what you want it to be and re-save it as a new image.

That's really what you should re-brand Vagrant as because like EC2 that like fell out of the cloud.

Oh there you go. [laughs] I like that.

So this is kind of interesting. Why do this? We should probably have this discussion -- like what does it matter if your development environment is different from your production environment?

Ooh I’ll take that one! So, I actually first looked into Vagrant because we were running a Magento in one of our projects at work -- which I don’t recommend. We ran to this problem where half of our production boxes run CentOS 5 and half of them are CentOS 6. And it just so happen that we were releasing some new code to interact with the credit card payment process, and the default for curl changed somewhere in the various versions between CentOS 5 and 6. So, on the development machines this developer primarily deployed to some CentOS 5 machine, so his dev box was CentOS 5 and everything worked fine on his dev box, but then of course as soon as you pushed it into production, now it doesn’t follow location headers by default anymore -- which you've never bothered to test. And so it goes live and everything breaks. And so obviously, anytime you push out code and it breaks, it’s a huge hit to our morale on the team as well as kind of your reputation on the team and having good from management. And so, I'm sick of having stuff work in development and not work in production -- or work significantly differently in production than it does in development. And so, I’ve seen some conference talk about Vagrant and I thought that could be a solution -- it gives you kind of… I think in my mind, it’s sort of this 80-20 split where, if you just have git versioning for your code, but then you don’t have any versioning for the rest of your stack, you are susceptible to a lot of problems that happen in production. And something like Bosh really cures that problem, but it’s a lot of work. Vagrant is sort of like 20% of the work for 80% of the benefit in my experience; where it doesn’t take a lot of work to get it up and running, but now I really have kind of like a versioned, full-stacked copy of my application that I have a lot of guarantees about it being the same as what's actually going to run in production.

I just wanna say I love the fact that all of your development stories begin with, “And you should never do this.” [laughter]

By the way exactly how David Brady develops.

Well pretty much. Actually I generate those stories in other developers, yeah.

Just like in real life he says, “What is the worst possible thing you can say?” [laughter]

“What's the most horrible thing you can write right here.” Yeah.

But Chuck, isn’t that one of skills you gain with expertise is learning what not to do and getting some intuition about it is that might happen?

Yeah.

In the novice’s mind, there are many possibilities; in the expert’s mind, there are a few. So basically, the smarter you get, the less useful you become, I guess.

Yeah. One thing that I wanna talk about is somewhat related to what Michael was saying is that at the beginning of the project that Dave and I were working on, we were trying to get Chef set up so that we could manage our various servers. And, you know, it was painful but one of the tools that we did use was actually VirtualBox and Vagrant a little bit. Most of the work we were doing, we were doing out on the cloud and we were using Chef to deploy to the cloud, but you know, I was encouraged over and over again by the guy I was pairing with -- spin up a couple of boxes with Vagrant, spin up your Chef server, spin up your other servers. And you know, it makes it really easy to get that far. And then from there, then you can start tweaking around with your deployment and your set up. And so, it becomes not only is your application deployable and compatible with the remote server, but it’s, “Does my deployment work?” “Does my technology stack run properly?” And doing that on a virtual machine on your own box is a whole lot cheaper than doing it out on an actual provisioned server in the cloud or in a data center.

Interesting. That goes back to the Growing Object-Oriented Software. So they start off with that and don't have a full set of integration test for your code have an end to end test that includes checking out the code and doing a complete deploy.

That's a good point. Yeah—

Yeah. I wanna talk about multiple machine stacks, but did you ever--

I kind of wanted to hit on what Michael said too that we had one application I worked on that did not use Vagrant. And what I really see in hind sight the value it could have provided. That particular set of servers had some really involved proxy settings and like. We’d always run into scenarios where when you are developing of course on our development machines, you are basically wide open. You know, we were able to do things then when we moved up into production, we would run in to bizarre problems due to the proxy configuration. And it’s not easy to take your development machine and apply a configuration like that, right? It can be crippling, right? So kind of one of the advantages of Vagrant or Vagrant-like set up there is that you don’t mind that you are doing some strange things to your computer and changing hosts and setting proxies and stuff because that's just some virtual machine, right?

Yeah and I think that's maybe a good point to jump in on one other benefit of Vagrant -- this is maybe one of my pet peeves -- have you guys ever worked on a project where you have to install like Open Office so that you can shell out to it and have it convert something to PDF or something? Like you have some weird stupid dependency and you end up with this weird stupid dependency installed on your laptop and on your desktop and it’s like all over the place in these different computers and you hate it -- and some day you just want to delete all the themes . And I love that with Vagrant. When I done working for a little while, I just Vagrant destroy it and literally everything that is part of that project is now gone. And if it uses some random version of MySQL built from --or something stupid like that, it’s just gone. I don’t have to worry about it collaborating that other stuff on their machine anymore.

So basically, it’s like RVM gone, all the way to the logical conclusion, right? It’s just like, “You want a different Ruby? Different gem set? Get a new machine!”

Exactly.

Yeah, it’s like getting a new machine is just Vagrant add box, right?

I was about to mock you for the whole Open Office thing because, who would ever do that? And then I remembered my Mountain West talk this year where I talked about planner sheets generating them and I generate them in PDF using --- but the [chuckles] original script that I wrote that from, opened up Microsoft Visio and used the DDE to fill in all of the dates on the calendars and then tell Visio, “Send it to the printer please.” And yeah if Visio hadn’t been… if Visio was running when I started, I won’t close it down. But if I had to start Visio, shut it down now.

Remember kids, you should never do this!

That's true though. There was another app I worked on that had PDF generation scheme where if you put a .pdf on the URL, it would use this library to basically convert the page to a pdf as it got it in. That library was notoriously hard to set up and had some crazy dependencies -- and you have to have everything just so before it would work. And few of us developers got it working. In the end, I think there's only one of us left that actually have that configuration just right. So, whenever there was a bug in the PDF setup, there is that one guy who can get it to work on his machine and do that, whereas Vagrant probably would have just that working fine.

Does anybody out there have a Vagrant virtual machine that has RMagick working? Just let me know.

[laughs] Send image to dbrady@shinybit.com

No just tweet it to me. Just tweet the image to me.

Oh that's right.

So, let’s talk about multiple machines. David you wanted to bring that up.

Yeah. So I have only ever used Vagrant as a single machine -- like as a machine within a machine -- caging the tiger. I want to work on something and I wanna be able to not only wipe out my database but I want to be able to corrupt my file system or some text. And so, I run Vagrant up, brings up a machine, I’d log in to it and everything is honky dory. In some rare instances, I don't work on the Vagrant machine. I check out the image, I bring it up. it starts the server and now on my Mac or now on my Linux machine, I do my work and it hits that server. But it seems like you could do both. How hard is it -- and this is probably one of those things where, “Dave if you just read the documentation on the website, you'd know this” -- but in production we have a load balancer, we have four web servers behind it and they talk to a load balancer that has 3 database servers behind it -- can I do that with Vagrant?

Yes you can. So in a single Vagrant file, you can specify multiple machines that you wanna start up at ones and have it all be part of the same project. And you could map your local directory to each one of those individually so that maybe each one of them knows to start up this part of it or whatever. And so there's definitely ways to do that, but I actually haven’t found that useful. That's in my mind, when you get a little too far down that road, that's where maybe your pain is just to find a more complete tool something like Bosh or saving up a whole copy of your app in EC2 or something like that. I think that's maybe the outer edges of where Vagrant becomes --- in my experience.

Well it also dawns on me that I’ve only got 4 Megs of RAM in my laptop so I mean, how many machines am I going to stand up?

Yeah. So I will say though another use case with multi-VMs that we have run into at work is obviously a lot of our projects talk to each other so, I work at a company that has like six sister companies and our development group services, all these six different sister companies. And there's a lot of communication between them, but each one has separate business rules. So there is a lot of times where one is calling an API in another. And so it’s really nice actually that even though I don’t work on project x, I do know where it’s get --- so I can just check it out, stand it up, Vagrant up and without knowing anything about project works, I just leave it running on my desktop at work and then when I stand up my project, it can talk to the development copy of that project on its current master branch. And so it’s not as automated as I'd like because I have to start up each one, but it actually does give me a pretty good representation of what will be going in the production.

So in that case, the Vagrant box or VM would have the database running though RabbitMQ, ElasticSearch all of those whatever services that’s using it will have that already?

Yeah. So when we need to do this at work, each one of those VMs – the VirtualBox VM – will actually have a database and everything running locally right on the machine, anything that is a dependency of that app in production. And again, you could go further with that idea and actually have that project start up in separate VM for the database, which is what actually happens in production. But we find that going too far down that road, you can catch more possible edge cases where you kind of limiting more possible differences between development in production. But it’s sort of an area of diminishing returns in my experience, where it’s just you can keep going down that road forever and try to make it exactly the same, but it becomes so time intensive and effort intensive that the pay off is just isn’t there anymore.

Yeah. One other thing I wanna jump in here is that there were a couple of different options when you talking about standing up a server with RabbitMQ and whatever other dependencies you are at as. One thing is as we talked about before, you can use provisioners. And the provisioners are usually things like Chef or Puppet where it says, “OK we are going to start out with an Ubuntu server and then what we do is we move ahead to where we need RabbitMQ installed and we need PostgreSQL installed and we need Ruby installed.” And so it goes and it uses the package managers or Ruby gems or whatever other means it has to go and get the information that it needs to install it. So then it may install Debian packages (if you are in Ubuntu through app) or it may go download source and compile it if that's what you've told it to do. And so there are a lot of different options there that we are probably getting more in to dev ops and provisioners. The other thing that you can do is you can download or create images and the images may have test data in them as Dave implied. They usually have all of the software that you need already there. And so it’s nice because you can just literally stand it up and then turn it on and just throw stuff at it and its already preconfigured and ready to go with a possible exception of maybe needing some code updates.

Did I miss anything in that?

I’ll just say that that scenario of kind of repackaging your --- is called repackaging when you've made some adjustments to the base image and now you wanted to save a copy of it, so that other people don’t have to install that stuff in source. And that's something that doesn't work with us mainly because the sys admins that we work with in our same office, our integration between other departments and theirs is not super tight. And so when we told them like, “Hey, we don’t want you to use CFEngine anymore,” and negotiations basically ended with, “Just get me CentOS 6.3 base image box. I'll find one that works on VirtualBox,” which they use for their actual data center installs. And so we can’t really share base images directly between the two, what we just agreed upon is a known starting point that we can each replicate.

OK.

And then from there, the Vagrant file plus the provisioner takes it to where you needed it to be, right?

Exactly. And then when I go to the production, all I do is git clone my repo and just run the same Puppet rules that would have been run by Vagrant. And I just run it manually using Puppet.

So, kind of changing topic just a little bit, going back to what I said earlier about it kind of feeling like EC2 to me in the different images that you can have. One of the neat aspects of Vagrant (in my opinion) looking into it overall is that, you do end up with kind of the shared images. Like for example, I know of Vagrant Rails which is supposed to be a Rails ready box with things like RVM all installed and stuff like that to make it easy to get up and running with Rails. And then another one that I saw recently that I thought was very interesting -- if you develop for Rails there's kind of a lot of dependencies in that, right? Satisfying all the databases and stuff like that if you actually wanna work on the code base. So there is now a Vagrant box for Rails development with all the dependencies satisfied. So you could just Vagrant up that and then the Rails test should be passing and you are ready to start working on a pool request or something. It’s kind of a neat aspect of the sharing of the boxes.

I wonder if anybody uses it to teach programming classes. Because I know that one of the biggest getting people set up is you spend several hours the first day or the night before getting everything installed and making sure that everything runs, but Vagrant would solve that pretty quickly.

That's a great question. I've used EC2 in similar scenarios. But the crappy part about EC2 is that I had to bring up a bunch of servers and pay for them over the weekend the while I talk the class or whatever, whereas Vagrant would be just couple of simple downloads. So, yeah I totally agree.

So for the record, Katrina Owen = 2, My mind = 0. Wow. [laughter]

Does Vagrant work on Windows?

Yup.

What?!

Anywhere that VirtualBox will run, you can run Vagrant. So it’s just fine.

So if you have an acceptable Ruby and an acceptable virtual box, it would just happen for you?

Yeah, I mean at work, we have some guys using Windows box and some guys using some Mac’s and it hasn’t caused any problems so far.

With Vagrant you mean, right?

For the record, Michael Ries = 1; My mind = 0. [laughter] Wow.

That hasn’t caused any problem with Vagrant, right? That's good. What about so that the on the one project, I did have like used it heavily. I did have some issues. And back then, I'll admit the main culprit was Textmate. We used a shared folder and worked on the source that way and that was how with kept it in sync with what was on the Vagrant box. And Textmate I guess just by the way it works in rechecking the files in the directory for changes or something like that, it was very painful when I would switch in and out of it. And to be clear, I believe that was Textmate 1 and I'm pretty sure that problem is gone in Textmate 2. But there can be (and Dave mentioned earlier) there can be some performance hits for using Vagrant and some idiosyncrasies to work around.

What kinds of things have you guys seen?

Yes. I think this is a good time just to talk about Vagrant gotchas. So I definitely say anytime you are working on a machine other than your native machine (whether it’s a remote server or a local virtual machine) there is always the hassle that I used --- and have it like pop up notifications every time I have a test that fails. I love that functionality. And you can’t really get that to work pretty well using Vagrant just because the test run inside the virtual and how is it going to tell my desktop to pop up a notification etc. So there's sort of this, “I have two consoles and I have to remember which is which,” that is slightly annoying. And that's just the case anytime you are working on machine other than the machine you are actually siting at. And so that's a little bit of the pain point. And then the major performance penalty that I've seen is actually doing SSH. And so like WEBrick out of the box, unless you patch it, will do a reverse DNS lookup on every request it gets which when you are running at a local machine, doesn’t cost anything because its local host, but inside of the VM, it tries to reverse look up the DNS of your desktop making request to virtual machine on every request and like every request of every CSS file. And that can make your response times extremely slow. And so we just switched over to using Unicorn 3000 to give us the same thing without the reverse DNS look up. Since we are using it in production anyway, that was kind of a no brainer. But there's just inherent performance loses in terms of running any virtual machine. And in production, you use very powerful hypervisors which are highly optimized to reduce that overhead, but the Oracle VirtualBox desktop version is not super optimized for those kinds of use cases and so you definitely, in my experience its about 20% slower than running on my native machine.

So, do you do most of your work outside the box reaching into it? Because running guard to me was trivially easy because I would Vagrant up and then I would just minimize that and I would go into the virtual machine and I would just stay there, work from in there. Now granted, I'm a die-hard Emacs user and so I'm in a text-only environment. I don't work with like RedMine or with NetBeans or Textmate or any of those.

I think you mean RubyMine not RedMine.

Sorry, RubyMine. Anyways I guess I'm asking two questions; one is do you typically work outside the box? And the second question is if you do use RubyMine or Textmate, do you install a VM with a GUI? Do you just go ahead and put on install GNOME? That's seems like it would be devastating to your resources. So I'd be tempted to not do that.

Yeah. At work we definitely… almost everyone uses IDEs. I'm right now learning Vim specifically so that I don’t have to keep using a text editor outside of my virtual box and also because when I log in to production, it will be really nice to be as effective in that production box of debugging and looking for problems as I am on my local machine. So I'm actually learning Vim specific for that reason. But using Textmate, that's even not really an option, right? Because I never deploy to a Mac box and so I just can’t run Textmate inside my virtual---. I can get it at home but I can’t go and snuggle with it. [laughter]

Textmate 2 to be clear has a command built in called rmate I think. And you put this little script on the server and then from there, you can use rmate to connect back to your Mac and open that file there. So you can sort of get some of this with Textmate 2. It’s still not (I have to say as a recent Emacs user), Emacs is kind of rocks in this kind of thing because opening a file locally or opening a file over SSH is basically all the same with Emacs. So there's no problem having like the dichotomy of two worlds.

So as another Emacs user, Michael I just wanna say welcome and we love you -- nothing wrong with Vim.

Its I use a lot of Vim myself. So yeah, I just wanna make sure the editor war doesn't even catch fire here. So alternate option has anybody figured out how to set up like a fused file system on the Mac and then mount it from inside the virtual machine so that it’s shared?

I haven't seen that. The page itself -- Vagrant docs -- recommend setting up an NFS share and say that that's faster than just using like virtual box shared folders. They have some times and stuff on their page but yeah I think some people do things like that.

Yeah. I've heard of people using Dropbox as a way to share a git repo. And I've heard stories that basically once you get more than one person using that Dropbox git repo at the same time, that the git index gets corrected.

That doesn’t surprise me.

That sounds like another one of those long string of bad ideas to start with. [laughter]

Well what it is, is a long string of bad ideas trying to solve… right? It’s like I get this pain and it hurts right here, so I'm going to stay up all night trying to figure out how to get out a 5 minutes’ worth of work. And as developers, we all do this right? And this is where bad ideas come from. [laughter]

Yeah. But occasionally good ideas comes out of it too.

Yeah.

Where basically somebody does spend all night solving that ten minutes of pain, but it’s then 10 minutes that you save over and over and over again.

To be fair, all of Michael’s story start off with, “Oh my gosh!” but then the all end with, “Vagrant! Yay!”

Doesn’t Vagrant started like that?

Probably.

Yeah sure. Somebody else spent that pain.

Yeah we'll its interesting too that the people who wrote the virtual box were willing to open up an API so that you can manipulate your VMs that way.

Yes.

Yeah it’s awesome. It’s cool stuff. All right. So do we have anything else about Vagrant?

I have one more question for Michael. Michael, you are based in Utah aren’t you?

Yeah, I'm---

What?!

So when are Dave and I going to have lunch with you?

I think all of us have actually already had lunch together.

I'm sure we have.

Wait, what?!

We met at the JCW's in Lehi once. I know Chuck… I know you were there Charles and then DBrady I met you once at a URUG meeting.

Holy freakin crap. OK.

Did I not get the memo? So Utah is only---

Apparently.

Another [inaudible] in Utah. [laughter]

Yeah, I was pretty sure I’d met you. I saw your picture. And I'm like, “I know that guy from somewhere!” So yeah.

So, Katrina you are calling in from Utah as well?

Yes.

Oslo, Utah. [laughter]

Actually, a huge portion of Central Utah was, well I guess the Danish settled by the Dutch and so yeah, there's a lot of very much Northern European style. You wouldn’t expect it but it’s totally there in Central Utah -- believe it or not.

I'm not very surprised.

Yeah. My ancestors come from down there and yeah I got some Danish and Scandinavian blood in me. Anyway, so yeah I have to say have you worked on Vagrant at all Michael or do you just use it in your work?

No. I tried my best to be explicitly honest with James when he invited me to come on the show and saying, “I'm not an expert. I have never committed to Vagrant. I don’t really know what I'm talking about other than as someone who uses it all the time.”

Wait, Ruby Rogues can’t get people on anymore that actually did stuff?

[laughs] He was a fan boy. You know, I felt sorry for him. You know.

All right. All right. Just because he knows everything about it does not… oh wait. No that's sort of does exactly mean he's the person we wanna have on the show. Never mind.

Yeah. But yeah, definitely a big thank you for coming on the show. It’s one of those tools that I use every so often and ignore, and this is kind of a reminder now I really need to go and learn a little bit more about it.

Yeah I really wanna use it more too, especially I've got a class coming up early next year and I really wanna do like --- see if I can figure out a good way to use that to bootstrap people’s environments you know.

Yeah it could be a very interesting thing because virtual box is just easy to install, so just tell them to install virtual box and go use the Ruby installer and Rails installer to Windows and do it the same way if they are on something else.

My mind is still just blown that Vagrant works on Windows, just out of the box. (No pun intended.)

I'm curious how it stands up on Windows 8 if they’ve solved the… if they’ve made virtual box work on Windows 8. I'm sure it’s just a matter of time if it’s not there yet.

Yeah.

All right. Well, let’s go ahead and do the picks. We pretty much wound down.

Did we really run out of things to talk… we… OK, we are down two Rogues today and--

We are more business than usual -- except for the Utah part. [laughter]

Holy crap. Well, the good news is I have five picks. So for the next half hour…

CHUCK: it’s only going to take you a half hour to get through five picks?

No, I'm just going to pick my top two so…

All right. Go ahead then Dave.

Actually, so we have talked in the past about switching to Linux and I had made the switch. I mentioned my pick a couple of weeks ago was the ASUS ZENBOOK™. I'm still loving it. It’s still making me very happy. The MacBook Air definitely has some real competition now. I had a lot of hassles with it. Everyone told me stuff would just work and it just didn’t and--

What's wrong with you Dave?

Well what's wrong with me is I installed Kubuntu (which is the KDE version of Ubuntu) because way back in the day when I was...

Yeah. So back in the day when I was a Linux user, back when you had to compile everything and fiddle with everything and you had to check your laptop out in advanced to make sure that it would actually work. There was Ubuntu which was known and Kubuntu which was KDE and I hated GNOME. And four or five years have gone by since then and this whole notion of checking out your laptop to make sure it will run Linux before you get Linux -- you don’t do that anymore. You just get Linux, put it on it and it just works. What they didn’t tell me is that GNOME is now kind of history. It’s now this thing called Unity and KDE is also history. It’s now this thing called the Plasma Desktop. And the KDE guys, I love you but you guys have really gone off on a weird rat hole and the canonical guys supporting Ubuntu have basically… they’ve given up on the whole Linux rebellion. They’ve basically said, “Look, we were built against Windows and then Apple came and defeated them for us, so the war is over. Why don’t we go into the business of developing an operating system as though that were our primary job?” And so, when somebody told me Kubuntu often put Ubuntu on, all my pains went away. And so my pick is Ubuntu -- especially if you are thinking of switching from a Mac to Unity desktop. Apparently it drives hard core Linux users crazy just write up a tree, but if you are coming from OS X, it feels… it doesn’t look like OS X, but a lot of the things that you would think of like the Alfred app or the Quicksilver and the search bar and that stuff, they are just kind of there and they work and they are really, really nice and I like them. My other pick is actually relevant to Vagrant and that is The Twelve-Factor App. I can’t believe nobody’s picked it yet but its www.12factor.net and this is just a rant or a screed -- it’s a free eBook that you can read online or download. And its twelve factors about making the difference between development environment and or what developers do and what production does getting rid of those impedance mismatches. And point number 10 is the development for production parity. And they basically say you wanna keep development staging in production as similar as possible so that you don’t run into these, “I'm developing on CentOS 5 and I'm shipping on CentOS 6 and that kind of thing.” And 12factor.net it’s a great read. It’s a short read. It’s not a huge eBook. And I highly recommend it. And those are my picks.

All right. James, what are your picks?

I've got just two. We were pretty hard or I guess I should say *I* was pretty hard on rdoc and ri kind of stuff on our documentation episode recently. So I did wanna point out I do actually use them – I use them a lot -- all the time. And if you wanna know why, there's a great article by Jesse Storimer on 5 reasons you should using ri. He basically lays out the reason I use them. I know a lot of people that tend to just do all for the documentation. It’s a little bit substandard and he kind of lays it out here. And so it’s a great post to read. And then for fun, I think you guys know that I always enjoyed stuff for dads and kids. There was this great TED talk recently about game designer and his little girl and how they made a game. And it’s really good thinking outside the box kind of stuff and how he get her just to draw pictures and use those as a background or recorded her with those mic and it’s story and stuff. It’s a great message overall and good stuff. Parents should check it out. Those are my picks.

Awesome. Katrina, what are your picks?

I'm all business today. My first pick is YAML::Store. So, YAML::Store is like key store except you can open up your database and your editor and then fix typos. If you don’t know about key store then that's a bonus pick. It’s a simple file-based menu database thing that is included in the standard library. It’s got transactions, it’s got locks. It’s really good.

Can you run SQL on it?

It’s for when you don’t need SQL.

It’s no SQL. That's even better.

There you go.

It’s a key store. OK. Got it.

Yeah it’s a key store. The second pick is Pygments, which is a Python library for syntax highlighting. It’s what used on the refactoring talk to get all of that code in to the slides with as little pain as possible. So it’s got a bunch of lexers, bunch of styles, lots of formats. I use the RTF one. And yeah, it’s got a command line interface. It’s really nice. The third pick is for people who are time zone challenged (like myself), who need to meet up with people in Utah to have a podcast, it’s called the meeting planner – it’s timeanddate.com. And it just lets you pick 6 cities around the world and it shows you a schedule -- all the hours and when to meet up. It’s really useful.

Nice. Michael what are your picks?

I'm glad we are business doing the episode because now I don’t have any business picks. So my first pick is gomtv.net. So for any nerds who never understood why people would ever like to watch sports, this is sports TV about StarCraft and it is awesome. I actually have a favorite team for sports now to do things like that. [laughter]

Is there a fantasy league?

Not that I know of.

Like my fantasy league will be like all Zerglings.

Do you listen to the JavaScript Jabber podcast?

No. I haven’t.

You should go make friends with Jamison and Joe from that show.

All right. So for anyone that likes StarCraft, it’s a good place to go watch and it actually is somewhat educational as well in terms of strategy. My second pick is to pick someone at work that is maybe hard to live with and go do something nice with them. So this kind of came out of the Angel Harms episode actually, but it definitely reminded me that everyone is worth getting to know and learning something from. And that people who I thought were hard to work with, if you just get to know them better and doing something nice for them is a great way to do that. All of a sudden you realize there is lots of good qualities there and lots of ways to really learn from that person. So, on to pick number three. DAVID: I just wanna interrupt and say, “Best pick ever.”

That was awesome.

Pick number three kind of goes a long with that -- it’s a Confreaks presentation by Michael Feathers called Code Blindness. It was at 2011. So it’s a little bit old, but still amazingly important. And it’s basically he's talking about businesses not treating development like a black box. And my pick is actually to watch and that and then replace every time he talks about developers, with managers. And every time he says managers, replace it with developers. So think about it the other way around and what can you do as a developer to really learn about what your manager is and marketing people are doing so that you can really understand the business not as a black box that generates money to pay for your development, but as something that you are trying to --- that’s been extremely helpful in my experience. And my last pick is another fun one. And if you guys do hardware hacking, there's this awesome product called The IOIO – it’s spelled I-O-I-O. It’s basically a little board that you plug in, you USB plug it into your Android device and it gives you ---. So it’s sort of like you can write like Arduino type projects with it except that you get to write it in like JRuby running on Android. And at Ruby Conf there's that awesome presentation about Arduino and they came up with some really good ways of abstracting hardware concepts into a Ruby API that makes sense. And so I'm practically planning on doing the same thing but for the IOIO. And if anyone is interested in that, please hit me up on Twitter.

Sweet.

OK for the record, Michael Ries = 2, David Brady’s mind = 0.

Wow. I’ll be right back guys I'm going to go buy some IOIOs.

[laughs] All right. So I guess that leaves me with my picks. My first pick is something that I got the other day (or if not the other day probably one week ago, two weeks ago) and its already pretty well integrated to my life -- It’s my iPhone 5. I got it because I wanted to try the iPhone end of things. I've had an iPod touch for a long time, but I wanted to just see how it was to have the iPhone. And so far it’s been pretty cool. Siri is really nice and the retina screen is amazing. A few things that I wanna pick for it, the first one is actually something that I've picked in the past but I'm going to tell you why it’s cool. The Omnifocus app for iPhone is awesome. It’s more or less what you would expect, but it has this feature and this feature is that if you create a reminder with Siri on your iPhone, there's an option in Omnifocus for it to go and suck that in to Omnifocus and create a todo for you which -- made my day. So, I mean I’ll be driving down the road and remember something I have to do and I'll pick up my iPhone, hold the button in and then tell it, “Remind me to go over the Ruby Nuby winners again,” or whatever and it puts it in my todos, it sets the due date for whatever time I told it to. And then my phone when it’s time to get it done, it does a little beep and reminds me that I got stuff that I had to get done. So it’s really, really, nice you can add stuff in your calendar and a whole bunch of other things. I also found out, I listen to my podcast now on my iPhone and so I can tell Siri, “Play whatever, whatever podcast,” and it just finds it and plays it.

You listen to whatever, whatever too?!

I like that show.

That's awesome.

Whatever.

Whatever, whatever.

Yeah. So my other pick is the service that I'm going to get into the Ruby Rogues site, it’s called SpeakPipe -- it allows people to leave voicemails. So if you wanna leave us a voicemail then that would be available to you. If they are relevant to something we are talking about, we might actually play them on the show. But ultimately, you know, if you wanna just give us a message let us know something you thought of or anything like that, feel free. I don’t wanna replace comments on the show notes because I think it’s important to have those conversations there, but you know, we do appreciate feedback and that's just another way to open it up so that you guys can do that if you have a microphone on your machine. Anyway, I don’t think I have any other announcements, so we'll wrap this up. Thanks for coming again Michael!

Yeah thanks for having me!