In this Book Club episode, the Rogues discuss Jesse Storimer's book, Working with Unix Processes.

Special Guest: Jesse Storimer.

 

I have read one of the articles on your blog just recently. Like in that one article, I think I learned about three methods that I didn't even know existed. *laughter*

James, I thought you knew everything?

I know. So did I. Then I read the blog post and found out I was wrong. Crap.

Now my world is going to shatter. What else don’t you know?

Hey everybody and welcome to Episode 58 of the Ruby Rogues Podcast! I'm your host, Charles Max Wood. This week, on our panel we have Jesse Storimer.

Hey everyone!

I usually do the guest last, but I got ahead of myself. You wanna introduce yourself?

Sure. I'm Jesse. Currently, I'm employed at Shopify and I have been doing Ruby there for about 4 years. Before that, I was doing other web stuff. I was doing PHP and C#. The book we are talking about today, “Woking with Unix Processes” kind of grew out of my experience there in getting better in doing Rails web stuff. I got interested in the infrastructure behind the application and did my investigations there and building stuff there came the knowledge into a book.

Cool. I got to mention this is a Book Club episode for Working with UNIX Processes. We also have Avdi Grimm!

Hello from Pennsylvania!

Avdi, so you are working on a new book?

[laughs] Yeah this sort of the much awaited (by a few people anyway), “Confident Ruby” which is based on Confident Code Talk that I did at a few conferences last year. People are interested in information about that and wanna follow along as I write it. You can go to confidentRuby.com

Awesome. We also have James Edward Gray II.

I’ll be the guest Rogue this week.

*laughter*

Are you working with anything interesting?

Yes I am working on interesting things, but I'm not ready to talk about them yet.

Okay. If you want more of James, go to Rubies in the Rough.

That's retired now.

Okay don’t go to Rubies in the Rough.

*laughter*

It was a good idea, but no.

“Retired in the Rough”.

Right.

Alright I'm Charles Max Wood from teachmetocode.com and I'm actually going to be putting up a webinar in mid-July about JSON API. So if you are interested in that, stay tuned. I’ll put a link in the show notes. Let’s go ahead and jump in and talk about the book. (I'm going to find my Kindle over here).

(I'm going to go and read the book real quick.)

[Laughs] Yeah I’ll be back in five minutes.

You know it is actually an interesting place to start though. The book doesn’t take that long to read, like just maybe 2-3 hours if you are working through and play with the code a little bit afterwards. It’s really not a long thing to get through. Did you do that in purpose Jesse or is that how much you fit in it?

it was definitely in purpose. I was saying that in the pre-show that I originally planned to write a larger book about system programming in general, covering processes and networking and threads and all kinds of interesting stuff. And what I was looking to do was processes and Forking processes and all those kind of things. So once I had written down what I wanted to do about that, then I realized how much I have written already I said, “Wow. Before I continue, wanna show this to people and see if it resonates with people and helps people” and so I showed it around to some co-workers and some friends and they really liked it. So I decided just like package it up as its own book and put that out there. So that's why it’s that long.

What made you decide about… I mean, at its core you are pretty much writing about Fork and it’s kind of an obscure, low level concept. What made you think this is important enough to be a book?

I wrote a book that I have wanted to read about two years earlier. So I got interested in Fork was like an introduction to processes basically. I was playing around with the rescue source code and reading it. Right in the middle of the main worker loop, there is a call for Fork, which I have never seen before. So I looked in the documentation. It said it was something about creating a process and I open up a console and Fork in the process right there. And all of a sudden, the console becomes unusable. It doesn’t know how to read input anymore, the output is all messed up. So, I was super intrigued and I dug around and learned a bit more but it’s really hard to find Ruby specific resources with this. At the time, (and still) I have a very poor C programming skills, which is the typical language you use if you are doing like low level stuff like that. But I hear from people that you can do all the same stuff in Ruby if you know how.

So, I picked up a larger book Michael Kerrisk’s book called “Linux Programming Interface”. It’s a great book, but it is about 1500 pages long and the thing was I didn't even know when to start. I didn't know what questions to ask. I didn't know what I wanted to know, just that I was interested. So books like that, it was hard for me to dig in and just read the whole thing. So I mostly, looking through a few instructions in the book, looking on the Ruby documentation, looking at open source projects that I found, I kind of figured out what I wanted to know about processes.

And the thing that I think is important about the book is that, it is written for someone who has read about Forking, knows a bit more about processes but they don’t know where to go next. So the book very intentionally starts with like the most basic stuff. It starts with showing that your code is already running in the process and builds up through forkingand through different things that you can do with creating processes.

Yeah I was pretty impressed just kind of the breath of things and it was very approachable the way that you explained things, so it was very easy to pick things up and go, okay I can see how it works and I can see why you want it to working that way. I think one of my favorite things was when you went into Fork and exec where you effectively Fork to get all of the context from the other process and then you execute something and within that context. I thought that you really kind of interesting and then once you explained it, it seems pretty intuitive and I don’t know if I would have come up with something like that on my own.

What's really cool about that particular example Fork & exec is that is basically, how Unix works. Unix was designed around that concept; that when you Fork, you inherit all these things, the process so you can assess things up and Fork to make sure your child gets those and then exec to turn it into a totally different process which is what you intended it to be but with that new environment right. Understanding some of the concepts on this book actually explain some of the low level concepts of Unix.

I think once you understand Fork and exec, you understand the whole system is like Fork and exec all the way down from like if you are on OSX and using launchd for instance, launchd is going to launch a bunch of processes when your system boots and it does that with Fork and exec. All the way down if you on your shell and if you start up IRB and Fork and exec and IRB process and even one of the most common feedback I had with the book is people saying, “Oh, didn’t know that kernel system method does a Fork underneath”. But of course, that is Fork and exec too just like everything else.

Yeah Fork and exec is what I do in a restaurant; I get my Fork and exec on my meal. *laughter*

Okay.

Hey you all laughed.

That just means we have incredibly poor taste.

You almost be as tired as I am.

So Jesse you talked about the documentation and looking into it and stuff. I actually have to admit you actually thought me on your book that I didn't know and I've always known how to look at man pages and I usually know which number a particular page I'm interested as under (which level). But, this is the first time I have actually had the levels explained to me. Oh you find system functions here and programs and stuff like that. I thought that was really awesome how you just like and you did that in a couple of points in the book actually. Like, man pages are one example I can think of and then session groups. Every now and then we are going to introduce some new concepts, you just kind of stop and explain the underlying mechanism and I really like that.

Thanks.

yeah I really like the process group too where you kind of have the master process and the way that you explained all that stuff.

Yeah definitely. I think that was my biggest take away book is I’d never taken he time to properly understand process groups and session groups. And you did a really great job of just really succinctly laying that out.

After you get the hang of something like that, it’s really neat to play with like tmux or screen because that's what they are doing, using those process groups, session groups. Splitting themselves offso they can keep that session running. That is pretty neat.

Yeah the thing that really build the understanding for me was the playing with shells and job controls in shell specifically, so you know when you run a command in a shell and you put the ampersand at the end, backgrounds that process. Ultimately, it’s making use of process groups and sessions groups to put that process in a new session that is not attached to the terminal and they put you back in the terminal. Similarly, like when you have a couple of processes running at the shell, like when it’s piping in another for instance, they are in that case, they will be on the same session groups so when you send a signal on the command line, it sends it to all process and get the expected behavior.

Yeah about the stuff about how signals are treated with regards to session and process groups I do not know.

Yeah and the whole list of signals and the way that they all interact and understanding, “Okay when you are waiting on a thread, you are actually effectively waiting for this signal to come back and if it get this kind of signal then it does this kind of thing, this kind of signal if this is other thing. If its waiting on it this way then it reacts one way, if its waiting this way, it reacts another way.” I mean just the explanations, it really kind of “okay, I get what I'm doing now when I fire up my program or when I fire off a thread and tell it to go do something like this” or just different things like that. It was really fascinating to me to look at it and go “Okay, that's how they are talking to each other and that is what all these stuff means” because I have seen it before, but I never had it explained to me.

So I'm curious what your go to references are. Do you have a stack of W.R. Stevens or what?

Well, I have a couple different sources. I see the main ones are probably man pages because there is so much documentation that we all have on our computer right? It’s pretty…

People read that?

*laughter*

Man pages aren’t always relevant for Ruby programmers maybe but they always at least a jumping off point if you aren’t familiar with something. And then if you fall off W.R. Stevens book or I tend to go for a Michael Kerrisk’s book first. I wanted more high level and the explanations are a little bit better.

What is the title of that book?

The Linux Programming Interface.

What is the W.R. Stevens book you guys keep bringing up?

It’s really a whole series of books. He wrote the.. I think.. I guess what a lot of people think of as definitive books on Unix processes and IPC and networking. I think it’s TCP/IP illustrated. James, what are the main Unix books? I'm having trouble remembering their names.

Good question. I don’t know.. Uhm..

W.R. Stevens I think his first big one is one called “Unix Network Programming” and one called “Advanced Programming in Unix Environment”.

That's the one I'm thinking of!

Right. Advanced Programming in the Unix Environment … and are there are actually, I think, 3 volumes of UNIX network programming getting sort of progressively more obscure.

And there are actually 3 volumes of TCP/IP Illustrator as well.

Yes there are. [laughs]

I think collectively, he has about 3,000 published pages on network programming and Unix programming.

Yeah, but I actually do have a copy of Kerrisk’s book and I've heard the same thing, I heard that from you and I heard from other people that he is really distilled a lot of the stuff that you find in a Steven’s book and updated it as well.

An interesting titbit about Kerrisk’s book is that I'm not sure to what extent he is involved, but he is apparently the maintainer of the man pages project.

Jesse what was your goal in doing this? I mean like, when you thought about this book, I know you said that this is what you wanted to read. But what do you hope people read this and like come away with?

I think the main thing that I wanted to instil with people was, kind of like showing them what is possible for a couple of reasons; like first one is just that its super interesting and super fun to know that you have these things at your fingertips like in the Ruby language and you probably never used them. And probably the code that you are using is already relying on them. So it’s fun to get to look at that layer of your stack and to start and start utilizing it. I guess that to the point there where I hope that people take the concepts and build stuff with it, because there is certain kinds of applications and certain kinds of problems that lends themselves really well to the techniques that I showed on the book. I've talked to some people who read the book and said like,” you gave me the confidence to write this crazy Forking demon process code” and so I'm always really happy to hear that someone took the concepts and apply them .

Can I ask what you book writing process is like?

Sure.

No, you can’t Avdi.

[laughs] Yeah. What's it to you?

Are you curious about the tools or the actual how I focus and how I edit and stuff like that?

He just wants to tell you if you are doing it wrong if you’re not using ---.

I'm really interested in all of the above; both the tools and the personal process and the process of how you get it out to people. Do you start with a beta? That kind of stuff. So really, all of the above.

I’ll try and tell this in a story in short form. About summer of last year. I really thought I had good understanding of these concepts and I was building stuff with it and when I talk to people about it, we always had interesting conversations and lots of questions. So I really feel like I want to share this. I knew that nothing existed that is quite like it. So I originally started screening my ideas down into what I want to be a screencast and quickly I realize that it I'm much better off writing than screen casting so, I started the writing.

In terms of tools, I wrote all my text in Markdown from the beginning, not sure where I was going to put it. And I have known about this little framework called “Kitaboo”. It’s a little Ruby Gem that takes Markdown and Textile files and compiles them into an HTML that is suitable to use with Prince XML, which is a tool for generating PDF from HTML. So I knew that I had it in my disposal and it gave me the ability to style my book with HTML and CSS, which I was really comfortable with. So I try to immediately and started using that all the way through the process.

While I was reading the book, I had noticed that it was probably pretty home grown. Like there was a couple of places (at least in the early version) where the code kind of flowed outside of the box a little and stuff like that. I noticed that you are definitely using it as just kind of a scripted system. But, the cool part of that you still got a pretty heavy level of control, like you formatted the PDF so that it’s really nice bidding on a screen. I love that. Like when the PDF is not meant to be printed and then read (which kind of defeats the whole point).

Yeah I agree.

I thought that was cool. I just wanted to say that. (Keep going though).

For the writing process, there was definitely no beta version. I was barely told anybody that I was working on it. I still had my day job at Shopify and worked on this kind of in the evenings after my daughter go to bed and sometimes late into the evening. I was really never sure I would share with anybody which I was putting my ideas down and then I was learning new things along the way so it was worthwhile for me. And I really enjoyed the process of editing more than writing, but eventually I got to something I was happy with.

I’ll just share a little bit of editing process which is that, I don’t think I write well but I edit pretty well. I like to think of it like I put all text in a box and then the editing process is just like taking text outside of the box and staking it up into a nice structure. So I spend a lot more time to editing than writing and that's where it really comes together. Towards the end I had something that I thought is pretty good and I showed it to a couple of people.

One of the first people I showed it to was Marc Andre Cournoyer and he gave me great feedback and that was encouraging. I showed it to a few co-workers and they were encouraging too. So I just in terms of actually getting it to people, since I work on Shopify in the ecommerce platform, I used the platform to sell the book. There is nothing really scientific or really planned about the whole process. I just said, “we’ll they seem to like it, I’ll put it out there and see how it goes.” So one day I announced on Twitter that I had this book and it went really well and I was really surprised.

It’s cool. Do you like the small publishing that seems to be kind of taken off in the Ruby community and these books like these and Avdi’s books, do u think that is a good way for community to go?

I do, absolutely. I think it’s for some writing styles I should say. I don’t think the place of a real publisher who is going to give you editor and lay out editor and all that stuff, I don’t think that its obsolete but I know that I have never would have completed a writing process that took twelve months and it had somebody else in there with me giving me real intense feedback in the beginning because for me, at least the process is very personal. And I wouldn’t have been able to finish the project if it wasn’t just me I think.

I just wanna finish the other aspect that I liked is that I knew I had a much closer relationship with readers of the book. Like everybody who buys the book gets and email from me with the download links and I get all of the replying back with questions or feedback. It would act like a tied relationship with readers that way even if my book is going out through Amazon and through other channels exclusively.

Yeah and you get random readers that want to read your book and then talk about it on some show.

[laughs] I thought that was nice.

[laughs] Stalkers.

[laughs] I know. I wish they’d just shut up.

What I thought you said was cool too though, you talked about the difference about the small time self-publishing and the bigger publishers, but it doesn’t actually have to be either or, or right? I mean you both recently got picked up by Pragmatic Programmers, right?

Absolutely.

So it’s kind of cool. I have to confess when I first read this book, which Is a while back now. I read it back around when you announced it and I got mad because I was like, “Where is the section on ICP?!” and it wasn’t in there and I was on that. So I was prepared but do you when we got here on the show for not having section on ICP and while I was waiting for the show to happen…

James you are such a ----.

I know.

When I was waiting for this show to happen, I got an email at one point and it’s like; hey I read a bunch of stuff in the book made me all about ICP. Like I can run all those sections and that was really cool and what I was going to say is I kind of like how this is like almost a “living thing” and its evolving over time.

Yeah I completely agree. A book is definitely a living thing and on that note I have a chapter coming out on later this week.

Can you tell us what it’s on?

Sure it’s about resource limits. Someone was asking on about how many open files can I have in one process at one time and I didn’t realize that you could change those kinds of limits within a Ruby process. So I learned something new in trying to answer that question and I wrote a chapter about it.

Is that how you decide what to where to go next? I mean like where the feedback did you have people tell you how do I do ICP or IPC?

Yeah, that was definitely a point of feedback. I had originally planned to give IPC more attention like I didn't think that I can give it justice in a chapter or two. And I got people saying, “the book is great but where is the IPC?” that I decided that I could put an intro and cover at least enough to get people excited about it and to introduce the concept. And that seems to have made everyone happy. I'm glad I dodged the bullet of you coming after me. *laughter*

It’s one of those things you really need to know later. I mean as soon as you make a little process I mean there's that fun part where you write a few Forks and you start to figure out how it is all working and then the next thought how do I these guys talking to each other right.

Right I you want the new chapters, you can go download the book again?

Yeah you can always just reuse the link and I usually send around an update email too when these stuff comes out.

So you’re working on a new book right?

That's right. It’s in progress.

All right. Can you give us the short… why this book is going to be awesome too?

Sure. At the end of the processes book, I wanted to talk about networking but we talked about so much that I’ll save it for later. So this is kind of me living up to that. And the networking book, I don’t know if I said yet the new book is called “Working with TCP Sockets”, it’s going to be all about networking programming in Ruby. I think it’s as relevant the processes book because we are all doing web stuff, we are all connecting to database servers, we are all doing so much that relies on networking and so this book will intend to give you (in a similar approach as the processes book) like look at the basics of networking and start at really simple stuff and start about creating servers and non-blocking I/O and building events and system and different server architecture and stuff like that.

Is there a link to that where that people can come and say, “Are we there yet?”, “Are we there yet?”, “Are we there yet?”.

[laughs] Yeah if you go to “workingwithtcpsockets.com” you can leave an email address and that is the best way to stay in touch right now.

How do you come up with these domains?

[laughs] Well, “The working with” and “working with” is the common parts of the title right? So I used that in the next book.

You should get “workingwith.com”

I think I tried, and that one is taken.

That figures.

I’ll put up a link on the show the notes, but there is a cool write on Jesse’s blog not too long ago about passing I/O objects across sockets and I was like “Oh, this is interesting.” And I started reading and silly little bumpers so I went about three methods I didn't know existed in Ruby from one blog post. To me that is kind of cool for the upcoming socket. So you guys should definitely check it out.

I have a question about your blog actually. You know picture of yourself that appears you are hiking while wearing a life preserver vest thingy. Were you expecting a flash flood? *laughter*

I love where this show go sometimes.

No that's actually very relevant about the writing of book we are talking about. So I wrote a blog post not too long ago. giving a background about how the book to cam to be. One of the things I said was I had an idea for the book and I wrote down a few things, I wasn’t sure how it’s going to work and I went on this which wilderness trip which is where that picture is from. So the trip was two and a half weeks in the forest in Wisconsin. We had no technology and no electronics of any kind. The particular picture that you are looking, I had a life jacket doing some canoeing. An it was there when I was away from technology and gave away distractions that I was really able to like get on my notebook and write down how to structure the book and do a lot brain storming. So that when I came back from the trip, I was really excited to work on the project and I was really good idea of where I want to go and what I want to say. So that's the story of the picture.

That makes me feel a little better because now I'm not the only person that can be in the middle of the staggering glory of the outdoors in the middle of the wilderness somewhere and be thinking, “I wonder if I can pass the socket over a pipe somehow.” *laughter*

Wait, you guys go outside?

*laughter*

Yeah there are things out there like the sun and dirt earth. I love how you are talking about, “yeah so I went out. I got away from technology and I sat down brain storm without technology”.

I really wasn’t intentional. I went there and I didn't have the intention of going there but I couldn’t stop thinking about it. So I put my thoughts to a paper and I was able to get back to the experience. I assure you guys if you are taking time away from the distractions of technology, you would really be productive.

I don’t believe it.

A book I love called “Pragmatic Thinking and Learning” talks a lot about that, because you basically give your brain that chance to rest. It’s there doing what it does best, in the background which is this pattern matching; it’s sitting there thinking, “what about this?”, “what about that?” and so it turns out to be such inspiring time.

Yeah but have you guys been away from Twitter? Do you know what these withdrawal symptoms feel like?

*laughter*

Yeah that's the other problem. You start twitching after a while.

And you start clipping at 140 characters when you speak.

Anyway I also wanna get in and talk a little bit about kind of the first chapter of the book. If you have dealt with Linux after master scale, I mean, most of the stuff is really trying to pull up table contents with…

JESSE: it starts with talking about PIDs and --- and stuff like that.

Yeah. These stuff are pretty basic but at the same time I mean, you have to have that understanding. To understand how all these stuff works and it’s also just understanding they have IDs that you can send them kill signals and things like that. I mean just some basic, basic stuff and the things that you went over that they have parents, they have file descriptors, they have an environment, they have names and exit codes. I mean, all of that stuff it’s right there. I t really empowers you to gather a lot of information about what your system, what your program is doing outside of the normal “it ran and then it ended”, “it ran and threw exception” and that there are a lot more there. And knowing that, and knowing how to interact with your processes kind of from the outside and seeing your programs that way, I thought that that was pretty handy. I have been a system admin and I knew some of it, but at the same time it really clarified a lot of stuff that I think I knew, but didn't really complete get I guess.

I found that when I first started learning this type of stuff, I used to be like when I have to set up a server (for example) to run a Rails application, I would just Google around and find the steps and follow the steps exactly. When something went wrong, I have no clue what to do. Then, after I

started learning how process is, what Fork is, how does exec work, like that, then I found that I can understand more what was happening. Like this process can’t do this or whatever.

In think with the first few chapters, I also wanted to get people just taking really simple codes and running it in consoles and seeing something meaningful and in some cases, it was something you didn't know before just to kind of get the momentum going, to continue it in the chapters where things got harder and more complicated.

One other thing I really liked about the book would be the appendices in the end. There were examples from Rescue and Unicorn, you have Spyglass (I don’t remember exactly what that was) I think it was the project you built for the book as an example

That's right.

Yeah some code that you can go through. It’s kind of cool because it was some basic process code but it was also pretty simple. I actually had some fun browsing through it because you can pretty easily follow everything that was going on, whereas, a lot of times Unicorn if you are really looking at Unicorn, I mean it’s not too bad. But I mean it’s definitely a step up to complexities scale whereas following that through can be complicated.

I had to read the examples from Rescue and Unicorn a couple of times before I really… Because I wanted to understand back to front, top to bottom exactly what was going on about there. It was nice to see something that is in action that people out there are using and kind of have that mental challenge of going, “Okay, I really need to get these different pieces and okay, I didn't quite understand that so I go back and reread that section and really understand what is going on there.” Yeah it’s pretty foundational to a lot of stuff that we use and we just don’t think about it.

Yeah, for sure.

There is kind of a neat blog post follow up on the book you talked about all the standard stream standard out, standard in, in Unix. It was kind of neat Ruby on Eric Hodel’s blog that explains like why when Ruby starts up there is actually multiple copies of standard in and standard out and things like that and how you can basically change some out, but you still have that reference of what they were in the beginning. So, that was like, swap one and swap it back to what it was and that is kind of neat. When I saw that blog post, I thought that was unique add on to what the book that we are reading here. So I thought I just throw that out there. I’ll put the link to the show notes.

Well, is there anything else that we need to talk about before we can get in to the picks?

Just one thing that I’ll mention that I think is interesting which that is, I have been writing a series of post in my blog. It’s been a few weeks since I have added to it and it’s a series where I am doing a Unix shell in Ruby code. So something like you can replace bash with for instance. I think it’s really interesting to look at these techniques for working with processes because, when you look at building a shell, you will realize how many of these techniques were created specifically for a shell program. You think about what the first versions of a fork and exec and various system calls were being written like 40 years ago. The terminal was the only interface to the computer and so the system will be built around the interface and today, we do so many interfaces to work with but still, these primitives are suited to building shells and working with shells. So I’ll put a link to that in the show notes. It’s an interesting read.

Cool. Is there a GitHub that people can look at?

Yeah I’ll put that in eh show notes too.

Alright, cool. Yeah that's sounds something that I would be really interested in seeing and digging into. Let’s go ahead and get into the picks. Did we warn you about the picks Jesse? I know that you listen to the show so you probably know anyway.

Yeah I'm a frequent listener. I know the picks.

We’ll start with Avdi. Avdi what are your picks?

So I cannot believe that this is not in the pick list already, Greg Brown’s “Practicing Ruby” series. I would just read the tag line off because I'm not sure how to describe it, “An eclectic journal for a dedicated hacker, lovingly curated by Gregory Brown”. Basically you can sign up for those. It’s not free service so you can sign up for this and you get really longer well written article is like better, really sort of a higher standard than you find in a typical blog post about various topics and particularly good for anybody who is still in withdrawal for the cancellation of Jame’s wonderful and missed series of Rubies in the Rough.

+1 on Practicing Ruby is cool stuff.

*laughter*

James I totally get where that is too much time because I found myself in the same boat very often but man, I miss that stuff because I learn something with every single issue. But anyway, Practicing Ruby is awesome and this is also a tiny bit of self-promotion because the very last latest article is a guest article that I wrote and would basically give you a preview of some of the content that you will see on the Confident Ruby book.

My other pick is an android program called “Montano Reader”. I tried a bunch of book reader programs and like eBook reader program and this is the best one that I found. And recently I hooked it up with their new cloud offering which syncs it up between devices, so that like my phone knows where I left off reading on my tablet and you are probably already used to this on stuff like the Kindle reader but this is for those DRM free books that you download from PragProg or O’reilly or whatever its not part of a service. It’s just a file that you downloaded; you can have them synced up across the devices using that, which is kind of cool.

Alright, cool. James what are your picks?

I've got a few. First of all, just in some cool libraries that I think everybody should play with, first of all I am kind of surprised that I never mentioned this one before but I wrote it and I haven’t and that is Typhoeus.

Woo!

Yeah I know. Isn’t that awesome? If you have to do HTTP stuff, Typhoeus is my absolute favorite Ruby library for that these days. HTTP is great in like comes with Ruby but it also has a terrible interface and we just have to face that. It’s absolutely terrible.

I love how you put that. It’s great, in that it comes with Ruby. It’s only redeeming quality is that you don’t have to install it

It’s pure Ruby whereas Typhoeus needs curl so it’s not so that there are advantages to things like but if you can use Typhoeus, it’s all the robustness and richness of Curl. And what makes it really awesome it binds to Curl multi, so you queue up a bunch of request and fire them all off and just trigger blocks as they come in, allowing you to do things effectively in parallel when you need to make a bunch of requests. And I use that when dealing with APIs all the time, especially if it’s a DOM API where I have to fetch some words and I have to fetch like 10 items on a list. You just fire all that up in Typhoeus parallel and it’s just awesome. That library absolutely rocks. I think it’s the best HTTP library in Ruby.

Curl uses Fork for that

[laughs] I'm not sure exactly how it does them that's an interesting question.

It’s possible.

Yeah it gets the request fired up and then it blocks waiting for the answer which is why that allows it to switch to do other things. So it may be flawed right now. That is a good question though.

Other library that I have just become aware of a couple of days ago and didn't know about at all is Drip. And if you are a node SQL guy and you enjoy looking at those kinds of things, check out Drip it’s pretty cool. It’s from a guy named Seki, I think and he did lots of things you already know and love like DRB, all that kind of stuff. He also did this library called Drip which he said is the library he made after years of making applications with drb and then from the lessons he learned from that and is basically a way to show streams between processes, streams of data.

And then you can keep a curse under the stream and just walk forward in the stream and process data as you want and as I was learning how to use this, it really reminded me of the episode we did with the square guys where we talked about how they’ve found it so much more effective rather than to push events to like pull from their feeds off their different service list and keep their own cursor. That is almost exactly what this thing does. So, it really made me think of that. If you enjoyed so you will probably enjoy this. It doesn’t have very documentation, but probably due to language barrier, but there is a sample directory in the project and you can look through there to get some ideas or you can go get the amazing drb book, which includes two different chapters on it. So, that kind of serves as a documentation.

Finally, for a fun pick, I have no idea how this maybe gone past me, I finally watched RED the other day and that is just a hilarious action romp that is totally corny and fun kind of along the lines of like “Demolition Man”, “True Lies” kind of fun. It never takes itself too seriously and it’s just a great time so if you like movies like that, you should definitely see RED which I think , I didn’t see a lot about it when it came through I guess when it struck pass my radar but it’s a really cool movie. I enjoyed it.

Those are my picks.

Awesome. Alright I’ll go ahead and drive my picks and then we will let Jesse go last. So my first pick, I have gotten to know a fella by the name Cliff Ravenscraft. He does Podcast Answer Man and a bunch of other shows that I really enjoy. He is an expert on podcasting and has quite brand of business built around that. I know I picked Podcast Answer Man on the show before, but he is opening up a “Podcasting A to Z Course” so if you are interested in learning how to do podcasting, how to set up a word press site to run it or if you wanna set up something else, he will give you a lot of pointers. He goes over equipment, software all kinds of stuff like that. So it’s pretty much a to z course on how to do podcasting, how to get it into iTunes and all that stuff. And so if you are interested, the course is regularly $999 and it’s a four week course, but he sent me a promo code (because we are friends now) and the promo code is WOOD it’s my last name.

Wait, you are friends?

Don’t talk to me.

*laughter*

Just kidding.

anyway, so yeah if you use the promo code, you get $100 off and I also get a little bit of a kickback but you know, cliff is definitely the expert on podcasting. So, if you are serious about putting the other podcast for your business or anything, then definitely go check it out. It starts July 9th and I think it goes through August 4 but yeah, it’s totally worth it. Anyway I’ll go and put a link up for that.

Another thing that I have been doing lately is I have been reading the “Getting Things Done” book by David Allen. I finally got to the point where it’s now you understand that the principles behind this, now we are actually going to get in and start implementing the system to organise all of you stuff so you can get stuff done. So Monday I spent all day cleaning my office and you basically create this huge in pile and you organize the in pile and you start the process to get to stuff done. I have to tell you that it’s been really nice to get everything together and put it where I need it so I

can find it.

One of the things that he has you buy is a labeller.

Yes.

I have to say I had my labeller for two days and I already love it.

*laughter*

I'm addicted. I don’t know how I lived without one before.

I did the exact same thing when I read that book and it’s been one of my favorite thing ever since now do you find yourself like labelling the cat and… *laughter*

Small children…

*laughter*

Alright. I have been tempted, I have surprised the urge, but I'm definitely labelling a lot of stuff in and around my office (some stuff that definitely doesn’t need to be labelled). Anyway it’s just like, yeah I know what that is. But I have to put the label on it anyway. But yeah it’s been really nice. I have been using it to label all of my files and to organize a lot of other things. It’s just been super, super nice. So anyway, I'm going to put the labeller in the show notes and the link to the book. I

haven’t quite finished the book because I'm still organizing. I just ran out of time on Monday and I had a rush job for a client yesterday. I don’t know what to say, I loved this thing. Jesse, what are your picks?

Okay so my first pick USP Ruby mailing list. It’s a mailing list specifically learning about system programming in Ruby so it’s totally on point with the topic today. The guy who writes the posts is Eric Wong, who is the author of Unicorn and I manages to find his profile on Ruby Gems.org. He’s also the author of a whole bunch of other Ruby libraries.

The mailing list is kind of like maybe I can read you couple of post titles. It’s basically talks about doing I/O , talks about system calls its talks about working with Unix time concepts and all kinds of things about processes and so if you doing the topic on the book, you should use this for sure I’ll put a link to that in the show notes.

The other one is a mac app called Shush. I'm actually using it right now on this call. Basically, what it does is it mutes our microphone all the time unless you hold down a key and then lets you talk. So if you do a lot of Skype meetings or stuff like that, it’s really useful not to be quite as intense as clicking the Skype mute button. It’s a little bit more intuitive lets you block a background noise and you can mutter to yourself on the call and not bother everyone else.

So it’s kind of like a talk button but not a walkie talkie.

Yeah exactly.

As opposed to a mute button which works the other way.

Yeah.

That's cool. I should check that out.

That is really awesome. That should be required for all of future Rogues guests. *laughter*

Yeah maybe we will install it on David’s machine when he is not looking or not telling. *laughter*

What Dave? I can’t hear you. I can’t hear you. What?

Well, let’s go ahead and wrap this up. As you know, we finished our Book Club book so we have to pick another one. The other one that we picked is “Growing Object Oriented Software Guided by Tests”. I’ll have an Amazon link in the show notes.

I also encourage you if you like the show and you wanna support the show, to go to Rubyrogues.com and in the sidebar on the right, there is a place where you can sign up for Ruby Rogues Parlay. We have about 30 people in there besides the Rogue and we’ve had pretty good discussions about testing. We had quite a discussion about books and got a lot of feedback on some of the other books that we are probably going to read on book clubs in the future.

Yeah, so they get to influence us in a way as we go so that's actually cool. They have talked a lot about the book we are about to read, Growing Object Oriented Software Guided by Tests. Also, some other books and why they think they are important and we have added those to the list.

Yeah we had quite a discussion. I think somebody had been asking questions about doing service oriented architecture and that informed the book decisions a little bit, but we had some good discussions about some of the processes in building those up and things like that. I mean just great conversations going on over there. So if you wanna get in, the basic level is $10/year. You can’t get much cheaper than that and we love to have you on the list.

Anyway, other than that, who are we talking to next week?

It’s ourselves. We are talking to ourselves.

That's right. We scheduled the DDD discussion so.

Right, so somebody needs to tell me what that is before the next episode.

I was going to say its triple D, so it’s bigger than double D. *laughter*

That's terrible.

I know. Alright we will wrap this up and we will talk to you all next week!