JAMES:
Hey everyone! We just wanted to say our own special Ruby Rogues happy birthday to Steve Klabnik’s dad, also, named Steve Klabnik. Steve, your son has come on our show before and taught us a whole bunch of things we didn’t know. So we know you are probably as proud of him as we are and he told us about your 54th birthday which is coming up on April 1st though it’s not a joke. So we wanted to dedicate this episode to you and happy birthday from the Ruby Rogues. Everybody?
(EVERYBODY): Happy Birthday!
[This podcast is sponsored by New Relic. To track and optimize your application performance, go to rubyrogues.com/newrelic]
CHUCK:
Hey everybody and welcome to episode 48 of the Ruby Rogues podcast. This week on our panel, we have Avdi Grimm.
AVDI:
Moo! Sorry, I was still piping my output through CowSay.
CHUCK:
We also have David Brady.
DAVID:
Hey! This is David Brady, Chief Metaphor Officer at SlideRule Labs.
CHUCK:
We also have James Edward Gray.
JAMES:
Hey everybody! It's James and I can't think of anything funny to say.
CHUCK:
We also have Josh Susser.
JOSH:
Okay, guess what I’m drawing here.
DAVID:
A penis! Aaahh!!
CHUCK:
And I'm Charles Max Wood from teachmetocode.com. We also have a special guest this week and that's José Valim.
JOSÉ: Hello! I’m José Valim from Plataforma.
CHUCK:
Do you want to do a quick introduction? Let people know who you are and what you're about.
JOSÉ: Okay, so I'm José Valim from Plataforma. I am Brazilian, but I currently live in Poland. I am the author of ‘Crafting Rails Applications’, that we are going to discuss today and part of the Rails Core Team member. And lately, I'm having fun writing a programming language called Elixir. I guess that sums it up well.
CHUCK:
Alright. Well, thanks for coming. So, as some people know we've been reading your book, ‘Crafting Rails Applications’. And so we invited you on, so that we could do our book club and talk about what we learned from the book.
DAVID:
Wait! Today’s that book? Hang on. I got to read something. I'll be right back.
JAMES:
Nice.
AVDI:
Okay, I'm back.
CHUCK:
We just cut like 4 hours out of…
DAVID:
No. I just read really, really fast. There are a lot of words in there.
JAMES:
Actually, it is a pretty short book. I was surprised that how quick I went through it for it being real high level and stuff like that. So I appreciated that it wasn't, a long slog. 02:48
JOSÉ: Yeah. Thanks. That's one of the first feedback I got from my editor, Brian, is that everything was very concise. And it’s basically, because I cannot write or express myself any other way. ‘Cause it is not my native language, right? So I just write everything as concise as I can, probably to finish sooner than later.
AVDI:
I wish more authors were like you.
JAMES:
Yeah. I wish more authors wrote with their non-native tongue, definitely.
JOSH:
Well, was it Pascal with that wonderful little quote? I apologize for the length of this letter. I have not time to make this shorter.
CHUCK:
Yes.
JOSH:
It takes work to be concise.
JOSH:
Or just learn a whole other language. That'll do it.
JAMES:
Yeah, that's right.
CHUCK:
Yeah. But we have been in that place, where we've been reading a book or I have any way when reading a book then, you know, you kind of tune out and then all of a sudden they come around to the point and I’m like, "Oh! Okay. I get it now." You know, it's like 10 pages of set up that half of it you didn't need.
DAVID:
The thing that I love about Crafting Rails Applications is that, while the chapters are short, each one is like; this is a really important thing at a very high level that you might not have known about. I’m going through this and I was going, “Wow! There’s a whole bunch of stuff in Rails 3 that I didn't know about". I was stealing a phrase from Avdi. He said this on the pre-show. I’ve just been cargoculting all of my Rails 2 stuff into Rails 3. And this book, you need this book. You absolutely need this book.
JAMES:
I wanted to ask José. What made you want to write an advanced Rails book? Was it the desire to level up the users of Rails? Or to get more people involved in contributing to Rails? Or what was your motivation?
CHUCK:
James, it’s because you're doing it wrong.
06:
02
DAVID:
Did you actually change any features in Rails? Because that would be too hard to write about them in the book?
JOSÉ: Yeah.
DAVID:
You did?
details:
What is the format? What is the location? Okay, we need some object that is going to hold this information for us because; it’s just insane if I continue showing everyone like all those information passing from one method to another. It was like too verbose, right? So I decide, let's create this new thing. This new thing at the end, I have changed a feature. I changed a behavior. But you know I inserted new classes. I re-factored some code for sure.
CHUCK:
So is that Authorship During Development?
JOSÉ: Yeah.
DAVID:
Book Driven Development.
JAMES:
Actually, José joked about Book Driven Development but one of the things I do love about the book is actually, he does test drive his way through every single example.
JOSH:
Oh Yeah!
JAMES:
And some of the most natural. Like usually when authors try to test drive the section of the book, they seem to fall under like common traps, like over testing or something like that. You know getting so many tests and there it gets crazy complicated and stuff. But the test driven development in Crafting Rails Applications to me feels like insanely natural and it really comes off great in some examples, where we’re sure like to know how to implement active model and so you just throw in active model test. And you start with failing tests and work from there and I thought it was a really great way to show the examples. What made you decide to do it test driven?
JOSÉ: That’s a good question. I have no idea. I think, I don't know. I think it is just I’m usually doing test driven development myself, right? Even when I am working more like with frameworks, with Rails, I like to do a lot of test driven development. I usually don't do test driven development when I am, for example, people like to do Cucumber outside. I don't know this kind of stuff but I like to do unit test driven development. I think that's like mainly the reason, right? I just want to reflect the way I view the application and right code.
CHUCK:
Well, no one else in the community does TDD.
JOSÉ: At some point, I was like, I wasn't sure exactly if I should do TDD at some points, it feel like, because it’s tricky, right? Because, at some point for it to write the test, you need to somehow know a little bit how the system behaves or how Rails behave, right? So, sometimes it can come off like I’m writing the test but just I, the author, can write that test because at that point I’m the only person who knows exactly what I need to access to gather information. You know what I mean?
Does it make sense?
DAVID:
Totally makes sense and I love the fact that I've read a lot of programming books for past couple of years by people who ostensibly do TDD and their books have no tests in them. And their defense is that, the tests would be too verbose or make the chapters unnatural. And I’m like, that’s kind of like weak sauce excuse especially now that I’m looking at your book and reading with the tests just makes it really, really clean. And the beauty of it is that I’m looking through your tests and I’m going “Dang!” Now I know if I want to start an active model, the first thing I need to do is include the Lint Test for it. It’s freaking brilliant. I’m going to stop kissing your butt in this call. I promise, but not yet.
CHUCK:
So, on that same topic, not the butt kissing, the TDD, one thing that I did notice was you kind of explained things “this is what we're going to do or this is why we need this feature to work this way” and you give us the test example and the nice thing about it was sometimes they didn’t completely follow what you were explaining that you wanted to do, but as soon as I saw the, and probably I’m getting told that getting a lot of static, I probably have my volume level set too high or something. Anyway, so what I’ve seen it, what I noticed was that basically, I’ll fix the static issue in a minute.
Basically, what I...
JOSH:
Chuck, you need to stop talking and you need to fix the static now.
AVDI:
You're Megatron. I’ve heard drive-thru burger joints that were more legible, audible.
JAMES:
Did you just use the word legible with regard to audio. Is that allowed?
DAVID:
You are if you have Synesthesia like I do. Chuck’s audio feed tastes like poo.
AVDI : I don’t know how you’re going to sneak it in there but you always sneak it in there. [laughter]
CHUCK:
Is that any better?
JAMES:
It’s not. No. You’re still very badly caught up.
CHUCK:
That’s weird. It’s not coming through on the recording so it’s got to be the sound card going into my computer.
JOSH:
Ouch!
DAVID:
Yeah, it just barely started. Do you have a battery powered system in the mix somewhere that might have a dying battery?
CHUCK:
Ah… No. I don’t.
JAMES:
Restart the call real quick?
CHUCK:
Alright, I’ll hang up and restart the call. ------
CHUCK:
Sound check.
DAVID:
Sound check from David.
JAMES:
You’re better Chuck.
JOSH:
Chuck! Chuck! Chuck! Chuck! Chuck! Chuck!
CHUCK:
Okay, it must have been Skype.
JAMES:
Okay Chuck, you were asking a question. Go for it.
CHUCK:
Well, what I wanted to point out was that in a lot of cases the test examples really clarified things for me. So if I wanted to know exactly what was going on which is part of the purpose of the test and you know test exactly the code is suppose to be doing. I could just look at it and say, “Okay.” So for example, what I was reading when you create the mark up in ERB mix; which I thought incidentally was kind of funny that it had a --- extension. Anyway, you know that really just communicated well. “Okay look. You need to be able to get a text format out of this and an HTML format out of this and it needs to work in this way”. And for me, it was just so clear. It’s like, “Look these are the important parts and this is what we’re shooting for”. It really did clear things up. And you know, I see that as one of the benefits of TDD, but it also really helped I think in getting your point across in the book.
JOSÉ: Nice. Thanks.
JAMES:
I thought the examples you chose were another strong point of the book, like I just found a lot of the examples really cool, like really practical. How do you do a form where it just emails all the fields to you? Stuff like that. But in that one when you included the nice honey pot twist, so that you know if Spambot came in there and just fill out the fields, it would just actually throw it away, because there was the honey pot field in there. You had another example where you used marked down for, you know, both the email text and HTML body if you run it through a converter, which is great. Cause that exactly what mark down is for. And lets you write both sides of the email with just one pass. I just, I thought your examples were pretty inspired. Where did you come up with those?
JOSÉ: Some of them there where really existing Gems. The mail form was an idea I had while I was still working Rails 2 and Rails 3 just made it like extremely easy and I thought was a good subject; the same with for responders. But ideally, at the beginning, what I did is that I chosen some parts of Rails I wanted to talk about, right? First I came like, “Oh! I want to talk about active model. I want to talk about engines. I want to talk about ORM stuff.” And then I was trying to come up with ideas of how to show those features but not in a total academic way that we just say, “Hey! This is how you could do but by the way I don’t have any practical example. In fact, you can do whatever you try.”, because it would make no sense. With time, I was able to get some ideas and match them and put them in the book. There was for example we have AbstractController controller in Rails which what we use as foundation for both ActionController and ActionMailer. And it was one of the things I wanted to cover but I didn’t. For example in this case, it didn’t come up with anything particularly interesting I could talk about using or I could build with AbstractController. It was just left out of the book. It didn’t cover with more detail. I had one idea that I could make potentially a jabber client that so you would send commands to the jabber and it would map the commands to an action and execute the action or something like that. But it didn’t felt as natural, I would end up spending a lot of time doing the jabber set up and it was hard and I didn’t write the chapter after all.
JOSH:
I liked the way that you built the chapters like that. But it was like the cool stuff in the chapter often snuck up on me. For example, when you were talking about sending the multipart emails using template handlers and you get down into that chapter and all of a sudden, BOOM! You’re talking about customizing generators and using Railties. It was sort of the benevolent version of leading someone down the garden path but instead of hugging them, you give them a toy surprise.
AVDI:
One of my very favorite things about this book is like your kind of very casually using some very, very powerful stuff. But not in a way that’s like, “you already know how to use this incredibly obscure thing” but you’re actually showing that a lot of relatively obscure and very powerful extension points are really easy to use. And what’s fascinating me is that, you chose some actually some really ambitious examples. Like, “let’s store all the views in the database instead of on disc”. And then you stepped through and it was actually a really straightforward process if you know the extension points. I’m not sure if that’s really a question but well I guess. Do you feel like a lot of developers are under using the framework?
JOSÉ: That’s a hard question. I have no idea because when I usually like reached for consultancy, it’s exactly because people are using those parts. Maybe because of the book or because of something else and they want some validation if what they are doing is correct and how they can improve. In my perspective, there are a lot of people actually using those things but it’s because that’s how this information got to me in the first place. So it’s hard.
AVDI:
I know that I’m going to change how I write things based on what I learned from this book. And I feel like there are a bunch of things where I’ve been trying to work around the framework. Or now, I
feel like I can work with the framework. And I see so much code; it seems that it’s building huge piles of code around the framework. I’m more and more understanding that a lot of those are just not necessary.
JOSÉ: Nice. Actually, I have a better answer. I think that people a bit lies in the framework because with the book, I think I was able to reach a lot of plug-in developers. At the end of the day, most of the people, they are using plug-ins, right? And the plug-ins they are built on this foundation. I guess people utilize it well because they are doing that via Rails.
CHUCK:
That’s something, now that you say it, it seems obvious to me is that, plug-ins are going the way of engines. And if you use Engines and Railties in particular, you really do get the ability to extend all of these different things into a plug-in. This is really a handbook for how to extend Rails.
JOSÉ: The Engine part was, at first, Yehuda like they were going like to cut off of Rails 3 because they were, we’ve all timed. I already had Devices and Engines. It was all of the things I decided to work for Rails 3 and I put a lot of it before, I think, Railties, Engine stuff with the help of both Yehuda and Carl because I need it badly. I think it’s great because today, I’m working in a big project and it would be like a total mess if I could not split my project into Engines and split the concerns this way.
CHUCK:
And that’s another thing that’s really handy with Engines is that, it occurs to me in a lot of cases that, a lot of people go to the SOA, the Service Oriented Applications, simply because, they need that kind of separation of concerns within their application to avoid unnecessary coupling and things and Engines is a good way of managing that as well if you can stick it in the same application.
JAMES:
José there’s been a movement in Rails recently, I think about doing better Object-Oriented design in Rails and it was your book that made me realize that Rails kind of beat us to the punch. That Rails was already doing better Object-Oriented development and your examples were like, “Hey! Let’s write a new responder.” Luckily, Rails plans for this. We can just write this object and boom! We’re good. And over and over again, I thought in your book you were just using good ObjectOriented design, was that a conscious effort on your part? Or was that a natural result of the way Rails has changed recently?
JOSÉ: Both, because most of the work was already done by Yehuda. So, Yehuda did the resolver part and he had exactly those used case in mind. He figured like maybe someone wants to…and by the way, when I say Yehuda, please include automatically Carl. He said maybe someone wants to customize the classic cases, liquid templates because there usually is a database. And in Rails 2 time, you wanted to use liquid or say all you should get a template from the database and you want to compile it. And probably, put in on main cache. At this point, you are like duplicating a lot of the parts that Rails already does, because Rails finds the template for you. Rails cache the template and Rails checks if the template is PDA or not. So Yehuda came with this idea and then, at the beginning and just when I was writing the book, there were a lot of things that were complicated. And they were complicated because high coupling and Object was doing too many things and I was just trimming it down. Part of the work actually continued in Rails 3.1. It might talk for RailsConf last year, I give like, it’s actually for people who’ve read the book. It’s actually nice to see it because I kind of updated the part of the book there. Because with Rails 3.1, I’ve explained a little bit more of its possibilities. Actually now, it is very easy for you to have Sinatra-like controllers. You can say that the context where I actually rendering your views, is the controller and not actual anymore. You can do Sinatra-style that they were able that instance variable are not copying them anymore. You can call protective methods and stuff like that.
JAMES:
I thought kind of talking about the examples you just mentioned that, you really showed like some kind of new age Rails I think in the book. Like there’s been a lot of talk and I know you’ve been involved showing counter examples about how in Rails you always getting all of this plumbing, whenever you’re make a controller whatever. Even in the book, you show like, ”Here’s how you strip a controller down there pretty much nothing.” Bare bones, parts and add it what you want or another example was threading. Recently, Rails became thread-safe and you kind have of a cool example of which probably doesn’t even require thread-safe Rails to be honest. But it is still kind of cool like that you have an example of “look what we could do with threads and a simple cue”. I thought that examples were leading the way.
JOSH:
Another comment about engines and testing. You had your Enginex, sort of test framework that you put together, which I found really interesting. I built something a lot like that a year or so ago for an internal thing. It was cool to see that guy out there; I never had the chance to score what I did. I
think your approach was pretty similar that I did. It’s like that’s the kind of obvious thing to do. But it’s nice to have it to be out there. It would be great to have that be more publicized or higher profiles. I guess that’s open source because it’s part of the book. Have you seen some people taking that up and using that as their? Has there been feedback on that? Is there buzz around it?
JOSÉ: So right now, Enginex is dead because it was kind of merged into Rails 3.1. So in Rails 3.1, when you do Rails plug-in it’s going to generate like basically a similar structure as you have in the books. It’s going to generate the lead folder and the test directory is going to have a Rails application there.
AVDI:
(That answers my question).
JOSÉ: And it was, part of the, not part but all of the work was done by Piotr Sarnacki. He did Ruby Summer of Code in mountable Engines. Rails 3.1 proven a lot how we can handle engines. So if you go to Rails and check the options you have. You have options like mountable. So today, you can mount an Engine. For Rails 3.1, we make that Engines, there are actually Rack applications as well. So you can say go to a route and say, “Hey, I want to mount my Engine at this point.” If you’ll say that the Engine is isolated, it isolates everything. It isolates the helpers. It isolates the models. Because with the falling Rails, for example is that you have had helpers, and that the falling Rails that’s going to include all the app helpers across all engines and that kind of stuff. So, when you isolate, you don’t have this kind of stuff in the anymore. You have down like completely separate components. And when you mount it, it’s like another component and then you don’t have universal router anymore. Because into Rails 2-3.1 before Rails 3.1, there are alter, even if you have an engine, what the engine was doing was that it was adding routes to your application, to the application router. But in Rails 3.1, engines has its own routers so you have different route sets and different ways. It’s like a really amazing work that Piotr did to make building engines easier. This is nice because it’s a lot more flexible than the interior was. It was a nice progression because in Rails 2.3, we had engines already but basically, what was happening there is that, there was a lot of code duplication. Basically, this high initializing application, they copy that code and then they paste it in the engine class and you had a duplicated initialization code. And then for Rails 3, we improve that to actually make an application inherit from engines. So the booting process, the loading locales and views is similar. It’s the same. And then 3.1 took the step, it was nice. And also, answering your question, I don’t remember exactly the name of the Gem. I think it is Combustion but I have to check it out. One of the people said that, “Oh! I don’t want to necessarily have a whole Rails Application in my test directory”. What you can do is that you can have form as a single file or a Gem that mimics a Rails application and that’s what this Gem does. And it’s very simple. It’s based on the same idea of a gist that shoots some time ago that you can put a whole Rails application into one file. This is another approach for the same thing which is actually very distinct.
JOSH:
I have a slightly different approach. What I did was that, as part of the spinning up the test suite, I generated a whole new Rails application fresh every time; which actually only takes a moment. It didn’t officially add to the time of running the test suite. Because what I was doing, I was building a frame, a suite of engines that worked together as a component framework. It made a lot of sense to me trying each one out new with a fresh application every time and it worked fine. That is another possible approach. Anyway, that is a whole like…
DAVID:
That is some seriously nerd baler stuff right there Josh.
JOSH:
Anyway, back to the book. There’s some really cool stuff in the book. Let’s start ragging on things now. One of the things that I found frustrating in Rails 3 is that, on the good side, there’s half of cool stuff you can do Railties and engines and configuration but I don’t know if the documentation has improved a lot in the last year, but a year ago, it was pretty hard to understand how to work with things like that paths and have a set of the configuration in the Railties. And a good example of that was when you were showing set up of engine and changing all the path names. When you were saying, you don’t have to load the controller from app controllers; you can load to liv controllers. The syntax for setting up this path names always drives me baddy. Instead of using normal hash syntax, somebody decided that, “Oh! We’ll create our own DSL for describing path names.”
JOSÉ: I have good news. It’s that we changed the syntax in Rails 3.1 and duplicated the old one because I agree it was just horrible. the DSL. It’s just the hash.
DAVID:
Holy freaking crap! Guys, I think I’ve discovered a pattern here. We complain to something about José and then he tells us it’s already fixed. Quick! Find something else.
JAMES:
It’s kind of an interesting point though. We’ve actually hindered that earlier comment parroted by David Brady but, if you came into Rails a long time ago like most of us did. Then you’ll learn to how to write Rails, how Rails was then. Rails has grown up overtime and changed, right? And sometimes we just keep writing things the way we know how to write them and that still works in Rails. But in reading this book, as you casually introduced me to the architecture at every turn, here’s the middleware stack. Here’s how models work now and stuff like that. All I kept thinking is, “Oh! I’ve definitely been screwing that up. Oh! I really should have been using this.” Or things like that. It’s interesting. We need some pack like this book for people that have been in Rails. You used to write it like this now, you should be writing it like this.
DAVID:
James keeps reading things and going, “Ah! I’ve been screwing that up.” I keep reading things and going, “Hah! That’s a thing?”
CHUCK:
You weren’t getting it wrong. You just weren’t doing it at all.
DAVID:
I just want to, getting it at all.
CHUCK:
I have a real quick question and this is something that seems to come up every few months. I’m interested to get your take on it especially since we’re kind of digging in to; we’re going further down the rabbit hole with Rails. And that is that a lot of people are saying, Rails back in Version 1.2 was much easier to pick up that it is now. And it seems that with all the modularity and all this other features, there’s more to know. Do you feel like it’s easier or harder to learn to use? And how do this new feature kind of fit in with the way you think about that?
JOSÉ: I think that it’s more, you guys can agree or disagree with me. I would love the discretions that it’s more of the whole ecosystem thing. Because at some point where we started, we just had like Ruby on the 8.6, that’s what, everyone was using. That was fine. We had very few Gems. The ecosystem started to grow as a whole, and then we have like different Ruby implementations and people need to worry about RVM. Everyone is using a bunch of Gems, which is great. And now you need to have something like, Bundler. Those are the kind of stuff that makes it more complicated for you to set up. We try to abstract it away through the maximum but we could not do everything. So I agree in the sense it gets harder. I prefer the way it is right now than the alternative which is every time I want to run, rspec. I realized that it’s causing conflict because something was already activated or stuff like that. But I think we can get better. It would be great if one day we can get rid of bundle and this kind of stuff. The ecosystem is changing and we are adapting to it. Sometimes you need to catch up with new things. Sometimes the new things, somehow needs to catch up with us. For example, people are complaining for quite some time that booting Rails Application is much slower but it’s because we have like Gem dependencies now. Probably, we have more files that we had in Rails 2 and we have to require and possess this stuff. The built in system per se is more of boost so you can do more kind of stuff and is probably slower. And now, everything is catching up with those new things that came so we have on Ruby on 9.3 with the falcon paths. They say it is fast. I think someone is doing a benchmark of booting Rails 2.3 application and 3.0 application with the falcolm pads is like the same. There is no difference in time anymore. Things are changing but I guess they are still changing all the time and sometimes they are going to get worse temporarily so they can get good and bad after.
JOSH:
Right. I think this is a good segue into that. I think if you look at some of the features in Rails and how the APIs are built. Some of them, I think, they’re very well done. Others, I think, the functionality is there but the longevity, I worry about the longevity of the API. An example is the Rack Middleware and the responders that you talked about. They both use this very generic call API, which is just basically a functional paradigm. So I’m just going to hand you this function, you’re going to call up with some arguments and then we’ll do something. Sure that works, but you’ve now taken all the expressiveness of your object oriented language and shove it to, “Oh! Here’s a function. Call it.” If I look at Rack, here’s this thing; it’s a piece of middleware or whatever they’re going to turn the name into in Rack 2 and you’re just going do call and what you get back is an array of 3 things and it’s positionally determined. I can understand if you’re programming and see how that kind of thing makes sense but we’re in a very high level language and there is very low overhead involved with having an object that has a status code method or message and a body, just all the things in that matter. How do these things actual messages that you sent to an object to get the results back? Seems like there is zero overhead of doing that, and it’s actually a lot simpler to think about that than I have an array and I have to remember that it’s the second item in the array that I need to grab the thing out of. The same thing got done with responder’s where, “Oh! I have a responder and all I’m doing is… I’m doing call and I’m going to pass him this very complicated set of arguments.” That I have to remember how these things are ordered and what the options mean. Why isn’t that just an object with ease?
AVDI:
It is. Racks provide that object if you want to use it.
JAMES:
Yeah. I know what you’re saying Avdi. I think though, to add to Josh’s example and kind of where he’s going, Aaron Patterson has talked in several talks about how, it’s kind of like, because the Rack middleware, all you get is call, call, call. But the truth is that like Rails for example, uses that for 3 different things; one is managing some kind of global state like ActiveRecords connection pool. One is a set of filters on content that, you know, contents coming back out and replaces key tidbits for Asset pipeline and whatever. A third one, I honestly can’t even remember at the moment. But because Rails is doing that, you’re growing this call stack every time. One of the main reasons Rails has gotten slower overtime, now it’s like the middleware stack so it’s like 68-bit. They have to pass down the call chain whereas, it might made sense if you had a set of more like what Josh is talking about, you could register filters. And those could all really be handled at one level instead of each needing to be at a separate point in line. They could just run through and do the filtering of content as needed and that’s stack strain. Those could be tuned specifically to that purpose and you could have the generic wrapper if you needed that. I think I see both sides like I do appreciate the mail. I love it that I could just grab a and throw again in to super simple case. If there seems to be a real object TPI that would give us some things that we don’t have now and that would make certain aspects easier. That seems more like a problem with Rack than Rails.
JOSH:
So Rack was one example and I think that it’s a different thing than the responder in API.
JOSÉ: I don’t know if the responder example actually apply but the way I like to look at it is that sometimes we need to take a step which in the future, where we look back, it may seem that I stepped back, which there are like Rack API being that simple out of the object. But if you go at that time when you had Rack and Rack came out, it makes extremely sense. Sometimes you need to do something extremely simple, that you are not going to assume anything and see how people are going to react to that and use that, so, they can take the Step forward and say, “Oh! I know what people want to do with this.” This is my response. I have Rack and then I realize how people are using, how Rails are using and how frameworks are using. Okay, now I think we can go to this more optimal setter. Maybe we’re using this structure just like to say that I have no clue what I’m doing here. Please, just use it and let’s come up with the used cases and have that obstructions for it in the future.
JOSH:
No. That’s great. I think there’s nothing wrong with that. You got to figure out what you’re doing and if all give way into a better solution, that’s great. I know there’s some work being done on Rack in that regard. The stuff like the responders though is, I think, it’s worth taking a look at why is it setup in that very functional way where it’s just an anonymous function and all it does is take stuff and calls and initialize on an object internally. Why is that hidden behind in this really genericized interface that doesn’t seem to add much to me? Is that a direction being pursued internally in Rails to clean that stuff up?
JOSÉ: I don’t think so. I just think it was, when designed, it was like, I think I wrote that cold like the idea I had in my mind at the time. I was probably a, Rack-hipster. I was just going to use Carl. That’s how things came out in the end. Probably you can re-factor it now because I agree with you in practice in what everyone is doing, is it that they are actually inheriting from action home controller responder. I haven’t seen anyone actually writing their responder from scratch because, unfortunately, there is a lot of logic in set up, in the initialize method as he said. We can either move the set up away or pass an object that already has this set up to along with that, or, we can go for an object-oriented.
JAMES:
On a plus side just having this simple method wrapping, I think sometimes does pay dividends like I really want to have the middleware stack is being used in Rails now in every level. I can just add something above this controller or above this action just by getting something in there. I think it’s actually the fact that it’s just that one method that makes that trivial in my opinion.
AVDI:
That’s very fractal.
JAMES:
Yeah. That’s interesting where they explain it.
AVDI:
I have a question. I wonder if you can sort of briefly lay down some rules for when do I add, mount a Sinatra app? For what purposes just I mount a Sinatra app? For what purposes do I write a Railtie? For what purposes do I write an Engine?
JOSÉ: Right. The Sinatra App, like I’m saying personally, is if you have already some existing functionality that you want to mount into Rails. For example, if they ask you if you have a server API that is Sinatra, you do build that in your application and that’s great. But if I am going to do something specifically for Rails that does not have the intention of being used it separatedly I would or do a Railtie or an Engine or actually none, depending on what you are doing. The first chapter, I think is where we build the renderer and we don’t even need a Railtie at this point. Because we just want to hook into an action controller and that’s it. The Railtie you need when you want to add like customize at some point Rails booting process. You want to provide configuration. So I suppose you have a Gem named, I don’t know, fubar and you want to add, configure that fubar so people can customize stuff and you need a Railtie for that. And the engines, is when you want to kind of have a main application. You want to have your own models that are going to be loaded in the development, your own views, your own helpers. Maybe you want to mount something. That’s like the rough guidelines.
CHUCK:
Okay. So I’m a little curious. You mentioned that things like Enginex have made their way into the Rails Core or the Rails Repository. Do you have any intention of going back and updating this to kind of like reflect some of these changes that have gone in?
JOSÉ: By this, you mean the book or the engine?
CHUCK:
Yes, the book.
JOSÉ: I think somehow updating the book maybe even adding extra chapters. So the whole Rails 3.1 will probably be worth a new chapter to talk about what you can do now with engines, which, I tell you, you can mount the engines, right? But besides that, I can’t think of huge things because I
cannot think that I could write other chapters besides those one that would feel similar to the chapters I have now in the book. I don’t have something conceptually as big or we can work in that way. One other idea I had that could fit the book was that we could do controllers, Sinatra style while rendering the context or render the views of the controller. But that would be like some things more. I wrote a blog post some time ago, My 5 Favorite Hidden Rails 3.2 Features and one of the features I talk now is how you can customize the exception rendering. That could also be part of the book but it’s something very small. I would be able to go over it completely in one page, two pages maximum. I think I want to update it eventually when Rails 4 comes out or something like this. But I don’t feel like there is a rush or a lot of new content I could add.
JAMES:
What about the Asset pipeline? I mean it’s a big new piece but is it not really customize, in the way the pieces you talk about in the book are. What makes it not a good choice?
JOSÉ: There are few things we can do about the Asset Pipeline that we’re always discussing it. For example, the Asset Pipeline use Tilt for template rendering and we could somehow make it use or somehow we could change Rails to use Tilt as well. Or we could just make the Asset Pipeline use the Rails rendering and then if we integrate the Asset Pipeline closer to Rails, we would somehow remove most of the customization. We could do because they are just the same thing. They are the same appendices, right? I don’t know. Maybe we could do something about with the Asset Pipeline. I think what I’m trying to say that we could do something with the Asset pipeline but the fact that for example, if I write a chapter, it says, “Hey! In the Chapter 3, I’ve taught you how to write template engine for Rails. Now I’m going to teach you how to write a template for Asset Pipeline.”, or something like that. That’s weird for me. They should be the same thing. Maybe one of the areas that could have a little bit more of BDD, the Book Driven development, so I could change things a little bit and make them make sense under my eyes. It’s one of the things I have to study more and see how I could change it before I write a chapter on it. One of the things I wanted to eventually write a chapter as well, it’s one of the initial ideas I had for the book, we maybe change ActiveRelation to query how add service. You could write the same queries and then at the end you’re querying to observe this maybe ActiveResource but that will require a lot of effort. I don’t think I would make it easy or even possible. There are those other things but they would require a huge amount of work before I could write something that would be nice and easy to customize I guess.
CHUCK:
Alright. Well if there’s nothing else that people have that they want to jump in within, then, we’ll go ahead and get to the picks.
DAVID:
I just wish there was more to complain about, about the book. So, we could just keep hammering on José.
JOSH:
I have a non-book topic. Just quick. José, could you say something about the Open Source Vacation that you’re taking right now because the tweeting that you did about it was clear that something was happening but it wasn’t like very clear what your involvement in Rails Core is right now and just what you are up to.
JOSÉ: I have like, this kind of ritual that at the first thing I do every morning is that, I go through Rails pool request for example. And I reply to everyone like, I try to say like, “Hey! This pool request is great. Here’s what you can improve.” And merge what the story is good and it really takes to communicate with people, but from time to time it was, obviously, I don’t have the responsibility. Just something I did for pleasure, for fun. But lately, it starts to become stressful. I was not feeling that much pleasure to do it. It was kind of self-imposed responsibility than something for fun. Everything was happening out of time, a lot of criticism. I, personally, there are people who react differently to these kinds of things. I wish someday I’m going to be like a master like DHH like he simply doesn’t care what people are talking about. He doesn’t let that take him. I am the person, that I am reading and that I want to talk to people. I want to understand what is happening. I want to understand how to make it better for them. And this whole interaction was becoming so stressful that I said like, “Okay. I need to stop. I need to take a break. I need to stop doing this public thing.” It doesn’t change my relationship like in terms to Rails Core member. I am talking with Yehuda plus Pastorino, Aaron, Xavier, everyday including Rails latest stuff. I am just going away from this public relation, just taking a break. Maybe I would go to some point where I
can actually care less in the good way if someone like, try to throw stones at me. I would like not care. I would say, ”Okay. Fine. My life goes on.”, or something like that.
CHUCK:
Just use the force and throw them back.
JOSÉ: Yeah.
JOSH:
I think it’s kind of like understandable that the currency of open source is not money, it’s something having to do with personal interactions and Avdi knows the term for that thing, without a name. Respect, is that it? It’s understandable, but you’re still part of the Rails Core and contributing and work around stuff?
JOSÉ: I’m just focusing on other stuff. It doesn’t mean, for example that I am stopping contributing to things in general. If I am building a Rails application and it say that something that Rails is broken, benchmarking, production map, and I say something that slow, I am going to obviously go there and fix it. I’m just going away from merging pool request, those things that I described.
JOSH:
Yeah. That seems to be the natural progression for a lot of people doing open source maintenance; that they have a period of where they doing a lot of serving, public requests and a period that they don’t. People leave Rails Core now and then and people join Rails Core. That’s life. Don’t think it’s anything to get too dramatic about. But it’s good to know what’s up with you and where that came from.
AVDI:
Do you have any other open source projects that you’re working on?
JOSÉ: Yes. The company open source projects form committees with them last and last because the guys there are simply doing a great work, which are devise in simple form. I am also working on my language, which is Elixir which is a language for Erlang Virtual Machine. It’s doing great. I’m putting a lot of work on it lately because the company agreed they would pay for me to work on it as well. I’m putting a lot of effort in that and trying to get a version that I can tell to people go, start and use it because we are good at this point to try stuff out.
AVDI:
Once you get to that point, what would the use case be, where you would say, “Yeah! This is a good thing to try to use Elixir for.”
JOSÉ: Basically, I do add stuff. I’m thinking about web. For example, if you have to think in scenarios where you need to handle a bunch of concurrent request where people use in that machine today. I would like to say maybe you can try Elixir out. Because it is an Erlang Virtual Machine and a Erlang Virtual Machine was built with exactly that in mind. They were built by Ericsson and they have in mind telephone switches, so you have a lot of concurrent connections opening there at the same time. If you go the Erlang mailing list, you get reports before doing all this kind of crazy great stuff. You know WhatsApp? An application for iPhone, Androids, that kind of stuff. Does any of you guys know it, or not really?
JAMES:
Yeah. I think I’ve seen a video about it.
JOSÉ: It’s basically iMessage but it work between devices and across devices. They have a node. Each node in their system is Erlang Machine and it handles 2 million concurrent connections. That’s like, “Wow! What the f*ck? What is happening there?” and you have this case in Facebook also using Erlang for chat and this kind of stuff. Elixir is basically trying to make Erlang development nicer. I’m trying to provide a better syntax, better abstractions like protocols and this kind of stuff. I would use it mainly for web development I guess. If I had something that needs to handle auto concurrent connections or maybe an API back-end, but I hope that people they are planning to do this something in Erlang, they can also just go and use Elixir because the idea is that it simply works. You can just use the other language and extract everything and it’s going to work fine.
CHUCK:
Cool. Alright. We really do need to get with the picks, so, go check out Elixir. That sounds really, really cool.
JAMES:
I’d say Josh will be happy to know it’s homoiconic.
JOSH:
Highly overrated.
CHUCK:
Avdi, what are your picks?
AVDI:
I think I just have one. I just published a little tiny fun app called Cowsays.com, that’s not my pick but I just wanted to say, in my own personal work, putting little apps together, I started using a view plug-in called Erector for the last couple little apps I’ve started working on and I really enjoyed…
JAMES:
Apparently, you may think about it David.
DAVID:
I thought about it but I was muted.
AVDI:
it’s a different kind of view on Rails. It starts out with something like Markaby where you’re writing your views in Ruby which I really like because I really, really hate mixing languages. I hate having to switch to cementing modes and if I’m not working actually with the designer, then I’m perfectly happy to write my HTML in Ruby instead of in HTML or in some mix or in some third language like Hamel. But the really interesting about is it takes that and it builds another level on it where, every view is a class with a content method which actually outputs the text into view. And the neat there is if you want to say a layout, you can have a layout class and then have the parts of the layout that change for different pages can be factored out as different methods. And then you just derive a class from that layout, if you want an individual page, a view, you just derive a page from your layout and by overriding method; you customize the parts of the page that you want to change. Basically, everything that you know about object-oriented programming just sort of carries over into making specific views for specific uses. At least for my little apps, it’s been a pleasure to work with.
DAVID:
So, it doesn’t make it hard to get something stood up quickly?
AVDI:
That’s correct.
JOSH:
Go sit in the corner. And stop doing that while you’re in the corner.
CHUCK:
Okay. I’m going to go ahead and go next. One of my picks was something that James brought up in the pre-show. We actually recorded very deliberate opening for that and that is Steve Klabnik’s dad. He has a blog post, where he basically explains what’s going on with his dad and why he’s trying to get birthday cards for his dad, which is going to be on April 1st. I’ve actually talked to my VA in advance to make sure that this episode will go out in time for you to send out a birthday card. Go ahead and click on the link in the show notes then you can get Steve’s physical address where you can send the birthday card. I’d really love to basically have Steve like on Saturday Tweeting something like, “Holy crap! The mailman just dropped off a whole bag of cards.” And then I think we as a community, can really do that. Really just go and take the opportunity to thank somebody who gives a lot to our community. It sounds like he’s going through some difficult stuff so; I think this would be really something nice we could for him. Also, my other two picks: one, I was upgraded to the latest version of Skype, until like a couple of days ago. I finally got tired of the interface. The new Skype after version 5.0 is bad enough but every time I’ve upgraded I wound up hating it more and more. I actually downgraded back to Skype 5.0 and I’ve been getting complaints from people on my Skype call namely this one that my audio isn’t great coming through Skype. It sounds fine on the recording but I’m probably going to upgrade to 5.1 and see how it goes. Anyway, my pick is old versions of Skype that actually has an interface that you can deal with. And finally my last pick is UserVoice. I double and triple checked to make sure that it hadn’t been picked. UserVoice actually is what we use for to request a topic. I really, really like it. It makes it really easy to manage kind of the ideas and requests and features and stuff. I’ve seen other clients use it for things like support. So, if you have a question or a comment or a feature request, then you can put it in through UserVoice. So, those are my picks and I think they are great. Did we have James go?
JAMES:
Not yet.
CHUCK:
Alright James. What are your picks?
JAMES:
I’ve got a bunch of picks this time. I’ve been consuming all kinds of cool content lately and it’s awesome. The first is I found this great e-book bootstrapping design. This is a book for basically developers who end up meeting to do some design for their startup or whatever. It’s just a really great book. It’s absolutely great. If you have some design skills, this is probably not a good book for you. But if you’re like me and you can’t design you’re way out of a wet paper bag, this is a great book for you because it goes through and it’s just like ruthlessly practical. This is how designers choose color. That’s complicated and hard. Here’s some rules you can follow that’ll get you pretty good results easily. It has nice graphics that are really geared toward developer-types like a picture of mistakes you can make with bonds with an X over it and they have picture of using those in a good way with a check mark and that’s great. It’s just really like a great book for, if you’re a developer and you want to just, this won’t make you a design expert but it might actually make you able to look in two websites and judge which is one is probably superior.
CHUCK:
They should have called it “Crafting Pretty Applications”.
DAVID:
It actually puts like the two things next to each other with a check box or a check mark and an X.
JAMES:
Yeah. I’m not kidding.
DAVID:
It’s like this is an alternation. It’s a design book for people who are bad at design and reading books.
JAMES:
Right, which would be another way to say that exact same thing were short, is developers.
CHUCK:
It is it like eat this, not that.
JAMES:
So anyways, that was my first pick. Second pick, I’ll do this quick because we’ve definitely mentioned the Rails software on the show multiple times. I hate to pick it again but he just did an 8episode series called “Sucks Rocks” where he re-implements this old Sucks Rocks application. Shut up David. Rails, it’s awesome. In fact, we’ve been talking on the show and pretty much everywhere in the community about how would I build an application that just uses Rails to liberate mechanism. He basically does that. I don’t even think if he introduces Rails until like episode 5 or something like that. He just happily builds this thing and there’s some things in here I don’t like that he does but I would love things because it may get me thinking. But the thing you should watch that’s really awesome is you watch the series as watch as the model interface turns out. He just develops this application the way he wants it and he’s like, “I’m going to need a method that does this.” And those methods end up being his model interface and it uses absolutely nothing from ActiveRecord like ‘create’ or anything like that. If you want to know how to design by just treating Rails is like delivering mechanism, this is a great thing to look at. One more thing, (I told you I found lots of good stuff). There is just this awesome slide deck from Matz about how Emacs changed his life and it’s really interesting, really fast, you’ll shoot right through it and those slides would have a few words on them. But it’s really interesting, it actually turns out that Emacs was a major design influence on the Ruby programming language.
JOSH:
That explains so much.
CHUCK:
That’s it. I give up. JAMES: He’s upset right now but you know…
JAMES:
But no, seriously.
AVDI:
Vindication.
JAMES:
That’s right. I guess this interested me because I’ve been playing a lot with Emacs lately and learning a lot about it. But it’s really interesting about Matz’s design, goals, and stuff but the other thing I loved about this slide deck is it’s also what hacking looks like in my opinion. This process that Matz goes to and if you need the slide deck, I think you’ll see what I mean. Those are all ontopic stuff. One off-topic one, what I’ve been watching on TV lately is Downton Abbey which is kind of a high society show. It’s a masterpiece classic theater series and it takes place the day after the Titanic is when the series starts. First season goes up to the start of the World War. It shows that high society but it also shows like their servants and how they’re living and stuff. And usually I don’t give in into this kind of suitor, I usually call this, suitor stories, where the girls are always trying to attract suitors. Really this was pretty interesting and the characters are cool and well-rounded. They’re not black and white and stuff like that and I have enjoyed watching it. And I have enjoyed watching it with my wife so it’s a great thing. You can probably watch with your significant other.
Okay, those are my picks. I’ll shut up.
CHUCK:
Alright. David, what are your picks?
DAVID:
So I will lead by saying, I guess I can’t unpick somebody else’s pick but I just could not get to Downton Abbey. I basically, I turn it off after I view the first episode and said this is an entire miniseries about British people being nasty to each other a hundred years ago. It really is an…
DAVID:
It’s true. If it’s a feature for you, it’s A++ with by, wouldn’t it.
CHUCK:
My wife loves the period pieces. So if they’re dressed up in olden ways, it doesn’t matter. I mean I could be like, “Yo brother. Yo.” And you know dressed up as olden people, she’d be into it.
DAVID:
Ye oldie thug life eh? So I just have one pick today and that is…
CHUCK:
That is going to be my next podcast, “Ye Oldie Thug Life”.
DAVID:
Ye Oldie Thug Life. So I just have one pick today and that is Draw Something for iPad and iPhone. Basically, it’s Pictionary on crack. You draw pictures. I’m actually burring out. I met about 23 games running simultaneously and you can tell like people that play PSP they either get a very quick sketch done in like 30 seconds or they get like a 5 minute long movie with multiple frames, updates and reactions. The cool thing about is, you get to watch the other person answer drawing but you can’t talk to them so you can’t influence the drawing. It’s a really interesting dynamic. And it’s interesting because the people that I play with are kind of divided into 2 groups. You can just start a game and the game, their server will find a stranger for you to play with. If you do that, or if I do that, then I’m playing against the stranger and so I tend to be very family friendly and very PG. And they just broke my heart because I was playing against a teenage girl that I did not know and I got the 3 words that I was allowed to pick from were stool, poop, and triplets and like, “Crap! I have to draw triplets.”, because I don’t want to sent to jail for something offensive to a teenage girl. I’m going to be the next guy up “To Catch a Predator”.
JAMES:
Could I just point something out here? David Brady dissed my pick for being British people being nasty to each other and David picked that allows him to be nasty to the rest of teenage girls in the modern world.
DAVID:
I’m not being nasty. I’m not being nasty. I’m being gross. There’s a difference. [laughter]
CHUCK:
David, you know that stool is something that you can sit on, right?
DAVID:
That’s disgusting!
JOSH:
I was so waiting for that.
DAVID:
So, yeah, my username is ratgeyser and if you connect to me and you just write me a note that saya, “I’m from Ruby Rogues.”, so I know you from Twitter then you go on the other list and like I sent Josh a drawing. The drawing was pong and I drew the screen for pong. Sorry, Avdi just said that he wants a 3-legged stool at the back jam and that broke my brain.
DAVID:
Did you have to have it surgically removed? That’ all I want to know.
DAVID:
But yes, so I drew Josh the classic pong video game screen and he typed P-O-N-G and hit send and that skipped through the end of the drawing so he didn’t see that I had been peeled off a new page and drew a gigantic dong and then a Ruby code next to it wrote, “.sub d/p”, so I mean, you get basically penises with Ruby code attached to them.
JOSH:
Which is we all look for.
DAVID:
Well, if it’s your cup of tea, hit me up with Draw Something.
CHUCK:
Josh, what are your picks?
JOSH:
Yeah, sure. Make me follow it.
CHUCK:
Hey! You said not me first.
JOSH:
I did. It’s fine. It’s fine. One of the reason is I’ve been playing Draw Something up is that I have this great little iPad stylus that I picked up ‘cause swagging a conference. It makes me about a 10 times the artist that I am with my finger. I don’t have an endorsement of a particular brand of iPad stylus but their incredibly easy to Google. It’s just basically a patent with felt tip and no ink and mine has is little quicker button in the end and retract the felt tip and it doesn’t get dirty in your bag. So, go that one, they’re great. And then my next pick is for apologypro.com. This is thanks to Avdi. Avdi put up some very concise guidelines for how to deliver an effective apology when you’ve done something that you probably shouldn’t have done. Even if you don’t understand what you did wrong. Go check that up.
CHUCK:
All the married men or what? Even if it’s something you hadn’t know.
JOSH:
I love apologies. Apologies are really easy to deliver. They’re even easy to deliver a sincere apology. You just really have to want to re-establish communication with someone. And if that’s your priority, it’s not big a deal. One of the best words of relationship that if I say I’ve got that anybody was. It was probably even on a movie or reading a book or something. But it was like; you know I’m having a fight with my wife, what should I do? Well you should apologize. Well what if I’m right? Oh! Then you should definitely apologize.
CHUCK:
It’s so true.
AVDI:
I want to say something real quick. I got a ton of pushback on that people basically saying so you’re saying that people just insincerely apologize to make people happy? And I’m definitely not saying that. But here’s the thing about like human communication, and I’m not going to claim that I am an expert. But even if you deliver an apology which is not completely sincere, if it is a real apology, it will change the dynamic so much, between you and whoever you’re having an altercation with, it will change the dynamic so much and so quickly, in most cases, that you will discover that soon you actually are sincerely apologizing. Because they will come, once you come out and meet them a little bit more than halfway, they will meet you more than halfway. It’s all about taking that first step.
JOSH:
Communication is a dynamic.
CHUCK:
The other thing that I’ve noticed is basically that a lot of times I’ll be apologizing and I’m not apologizing for the point I was trying to make. Usually, “I’m sorry I put in a way that made you upset.” You’re communicating the intent not to have offended or whatever as oppose to actually saying, “Clearly I was wrong about everything in my life.”
JOSH:
Just go read apologypro.com. It’s all you need to get started. So, thank you Avdi for putting that stuff up there. I think you’ve given how contentious things could get on the internet and people inadvertently offending other people or saying stuff to break down communication. I think it’s great to have helpful tips for people how to unstuck communication.
CHUCK:
Wait. Somebody’s angry on the internet?
DAVID:
Yeah. It’s an amazing fact.
AVDI:
They’re wrong.
JAMES:
Our next episode will be a 1-hour apology for the fact that we have David Brady on the show.
JOSH:
It might take several shows.
CHUCK:
We’re not wrong and we’re not sorry.
DAVID:
It’s all in good fun.
JOSH:
So moving along. Sorry about that, this is a re-pick of an old pick but it’s been updated so I think it’s worth mentioning and that’s the Hub command line utility for making working with GitHub much easier. And it’s been growing and improving and it’s really nice for if you’re doing anything with Github especially if you’re dealing with pool requests or any of the GitHub’s specific things. It’s really great so check that out. And then, I mentioned a couple weeks ago that I’m at the rack health accelerator and my start update and I mentioned that they have cool stuff so resources for startups. And they finally got the video series all packaged up. That’s called start up elements and it’s on the rock health.com website and they have a bunch of great videos up there of people telling start up founders, how to make good decision about running their business. You going to fear not in the health IT field. It’s really worth checking out. And then just little word for Heroku, I haven’t been through the initial development/requirement process on Heroku in a while. It’s just gotten so much better than it was a couple of years ago. I know a lot of people are really using Heroku but if you haven’t been using Heroku in like a year, come back and take a look at it. It’s really gotten so much easier to do pretty much everything that you want to do to complete in an application. Yesterday I wanted to install SSL-certs and do HTTPS so that everything on my application would be secure. It took me a very short amount of time to just find where everything was on their site to hook that up and to make it work and they have really great instructions for doing all the tool chain stuff for creating the SSL and getting the thing approved and registered. So, it’s turned into an exceptionally good experience. If anyone’s considering whether using Heroku, it’s definitely worth checking out.
And they’re not our sponsor. I’m saying that just because.
CHUCK:
But they should be.
JAMES:
That’s right. We’ll talk to them.
CHUCK:
Alright. José, what are your picks?
JOSÉ: Okay. So, I would first like to show a link to Piotr Sarnacki twitter profile because we talked about him in the show and he’s working Rails 3.1 engines so we’ll follow him, you’ll probably going to pick something interesting. The second one is for my company, Plataforma. Most of the work I do in Rails and in the personal in general, they are the guys concern so if you just want to give a
shout to them and thank them for the opportunity and everything. Third one is the link to Elixir which I think it was already mentioned at some point. We have a very nice getting started guide, so we’re committed to go ahead, try it out. And the last one, my last pick is a Gem called Jimson. Simply it was working and the application that you had to communicate through an external service. And the only way for me to communicate to this external service was by Gem Ruby. So I had this Ruby 1.9 communicated to do Ruby and I could use Resque for this kind of stuff and expose via Sinatra but that would be an over queue because I just want a raw access to the methods and API. So I basically needed an RPC, Remote Procedure Call, and there is just jimson Gem that implements Jason RPC. It’s very simple. It’s very elegant and it helped me a lot so if someone ever feels like need something in this scenario, I would recommend this Gem and that’s it.
CHUCK:
Alright. Once again, I just want to remind everybody. First off, go spend a few bucks, send a birthday card over to Steve Klabnik. That’s Steve Klabnik’s dad, Steve Klabnik. I also want to thank José for coming on the podcast again and for writing such an awesome book.
JOSÉ: Thank you guys.
JAMES:
Thank you very much.
JOSH:
Can you remind people about RailsConf or I’ll do it? We’re going to be at RailsConf. Come to RailsConf, we’re going to be doing a live session.
CHUCK:
Yup. And that is the 23rd to the 25th, and I don’t know yet when our session is. Just come for the whole thing.
CHUCK:
Is it on the site now? Do they have the schedule up?
JAMES:
Yup.
CHUCK:
Alright, we also are in iTunes so you can go and find us there. Just do a search on Ruby or Ruby Rogues. I’ve also found that we are in the What’s Hot section under Technology, which is between that and new and note worthy. Both of those are pretty hard to get into so thank you guys so much for all your support. Really, really appreciate it. And if you’re listening on the Android device or something, I had somebody recommend on one of my podcast to use DoggCatcher to get your podcast. So if you have an Android device and you’re looking for a good way to get them, apparently that’s one that works really, really well. We’ll catch you all next week!