Reading:

• https://blog.stevecoast.com/what-the-hell-is-happening-to-rails
• https://yehudakatz.com/2011/06/14/what-the-hell-is-happening-to-rails/ Thoughts on Rails 3.x:
• Resource routing changed - Good and Bad
• Performance problems - Explained
• Code is more accessible - Reading the source is easier Rails Wishlist:
• Background processing
• Better multi-database support
• Fixture loaded database caching The long fixtures tangent:
• Fixtures
• Foxy Fixtures
• Factories Considerations for Rails’ Future
• Mobile Web
• Javascript front end
• Persistent sockets/connections
• realtime rails
• API versioning

Transcript

CHUCK: Hey everybody and welcome back to the Ruby Rogues Podcast. This week we are going to be talking about the direction of Rails; where it’s going, where it’s come from. But before we get started, lets introduce our panel. We have James Edward Gray from Gray Productions, he's worked on things like Scout and a few other handy tools like FasterCSV. Welcome to the podcast, James. JAMES: Thank you. CHUCK: We also have Aaron Paterson from the Rails Core Team. He works for AT&T Interactive; he's contributed a few little known libraries like [00:39], and we'll welcome him as well. AARON: Thanks. CHUCK: We have David Brady from ADD Cast, from Shiny Systems and he's contributed a few things including an interesting library called tourbus, that you can use to do load testing and stuff in your application. DAVID: Yup. CHUCK: And finally, we have Peter Cooper from the Ruby Show, the JavaScript Show, Ruby Inside, Ruby Weekly, JavaScript weekly and probably a few other things that I've forgotten. PETER: And I've submitted one patch to Rails once. How awesome is that? One patch, baby! CHUCK: Nice. And I'm Charles Max Wood from teachmetocode.com. I'm also the host on the Rails Coach Podcast, teachmetocode.com has screencast and podcast, and I am getting ready to launch a Rails summer camp that you can sign up for at teachmetocodeacademy.com. Yeah, you heard it here first. [Chuckles] AARON: Wow. PETER: Is that the future of Rails? CHUCK: [Chuckles] I don’t know about that. Rails moves kind of fast. So, there's been a bit of discussion out there. I don’t know if you guys have been following some of it. There was a guy named Steve that wrote, “What the hell is happening to Rails?” And kind of went on to rant and then Yehuda Katz replied to some of the discussion. I'm kind of interested in you guys’ take on some of the changes we've seen in Rails lately. PETER: There’s a what now? AARON: I guess, I don’t know if I can summarize it really. Some guy was like, “Oh, no Rails is getting forked.” What was the summary of his article? Like it’s not for new people anymore or something like that. CHUCK: That was the general gist was… well there were a couple of things; one was that it moves too fast that nobody can get good documentation around it. And the other argument was yeah, the Rails core team is adding their pet technologies to it and it’s becoming  harder to learn. So everybody go back to Rails 2, learn Rails 2 and then learn Rails 3. AARON: I don’t know about that. JAMES: It’s an interesting point. I think I'm skeptical of it too. Although, I can sympathize with it in some areas. So like for example, let’s just take resource routing; if we look at resource routing in Rails, that’s usually to step up to that, you are going to learn a few things, you are going to learn how to declare the route. You are going to learn which routes it defines by default, which ones you are supposed to send where, what if you need to do special routes, things like that. Whereas if you go back to Rails when it did basically what was it… the action ID controller action ID/// that was pretty darn easy to learn; you pass the hash to all the URL methods and stuff like that. Now I'm not arguing the old was better; I think the new way does have plenty of advantages for it, but it probably does that a bit to the learning curve that’s going on. I think that just one example. I think there are others, where Rails for being a framework that’s famous for being very easy to get into, probably has grown up a little in some areas and maybe that is requiring a bit more to get under your belt. If it’s worth it, it’s probably okay and I don’t know that that is necessarily a bad thing. And if it requires more to learn about how web applications work and stuff like that, I assume that’s also a good thing, but I'm very interested to hear that other stuff too, though. AARON: As soon as you start adding any new pieces of tech that's something new for people to learn, I mean we can't just stay with the old stuff forever. And also the other thing I wanna say about it is you don’t have to use it, right? You can go ahead and use Rails 3.1 without ever learning anything about CoffeeScript if you like. JAMES: Hold on a second, I got to put another on this phone or it’s going to cut me off. CHUCK: [Chuckles] I was actually going to say there's a little bit of noise in the background there. AARON: Oh, I'm sorry. CHUCK: That’s okay. My take on this is a little bit interesting. And it really just brings out more questions because Steve kind of says, well its harder for new people. My take is which new people? Because we have people who are converting from things like PHP or some of these other frameworks that are out there from Python or Django or this or that. And then you have the people who are new to programing and new to web development, and they are just picking these stuff up. And I'm thinking okay, well, if you are just coming over from another web development framework or language, then yeah there's a little bit more to know about, as far as CoffeeScript and Sass, and the routing and things like that. But that’s all part of the framework. But if you’re new to web development anyway, then things like Sass and CoffeeScript actually make it a lot easier because it abstracts the way some of the ugly parts of those technologies like JavaScript and Sass or CSS that  have their words that are a little harder to deal with. JAMES: I think that Sass especially, I assume one of the main complaints in the article was targeted at the asset pipeline, just because it does change how several things are done. Sass seems pretty simple to me just because it’s pretty much you can use it and still have normal CSS right in there. So not really a big deal there. CoffeeScript is maybe a little bit more debatable in that if you are really going to use CoffeeScript, then you probably do need to spend a little bit more time learning yet another language and it kind of gets annoying of how many languages do we need to display one freaking webpage. But I think there's a little bit of that syndrome. What about with the asset pipeline, I think that an interesting choice for additions to Rails just because it really does, as far as like structure stuff. Aaron, can you tell us what you think about the asset pipeline? Is really going to be as great as it looked or is it really trying to do too much? AARON: Well, I think some of the technology in it is actually important. It’s very important. Much of the technology is important but like the stuff that I think is immediately useful is for example, the compression stuff and putting assets together. That stuff that we actually do in production, with all of our websites, but it’s not built in to Rails. We had to use third party stuff to deal with it. So I'm actually pretty excited about those particular things in the asset pipeline. How it will play out, like moving our apps to it, I'm not 100% sure. I'm not going to know until I actually do the work. CHUCK: Interesting. I'm going to give you a low pitch because you’ve done a lot of work on like bug fixes and performance in Rails 3, when Rails 3 first came out, there was a really big performance hit that people took upgrading from Rails 2 to Rails 3, and it seems like you’ve worked some of that out. I'm a little curious as to where those problems were and why they were willing to release a Rails 3.0 that was actually slower than Rails 2. AARON: [Chuckles] Well, it depends. So the thing is, one of the major performance issues I've dealt was in active record, and the problem is the actual performance degradation was like basically n squared graph. The problem is like if you are running very small iterations, like your end values is very small, you don’t actually notice, right? So, that’s a thing is like, it’s not that we are willing to release a slower one, it’s just that we didn’t know it was slower. PETER: That told you. AARON: Yeah. CHUCK: [Chuckles] Until somebody really use it. AARON: Exactly, yes. One of the things that somebody else has pointed out a speed regression in 3.1 and we are not going to release 3.1 without this particular regression taken care of. One of the things I wanna do in the future is like we need to start having benchmarks, and benchmarking them overtime. We have some benchmarks in Rails itself, like benchmark this and that. We don’t actually run them on like regular basis and then track the values overtime. Because really, I think that's the only way you can detect these sorts of performance degradations. So, yeah I don’t if that answers the question very well, but that’s my thoughts on it. CHUCK: I think it does give us a good idea just because, yeah you didn’t know. But at the same time, I guess it does bring up the point you are making that hopefully you are testing the benchmarks in the future, so that at least if we are going to take some kind of performance hit, we are aware of it. AARON: If we are going to take a performance hit, we should at least know what it is and why. JAMES: While people are complaining that Rails is getting worse in some areas, as far as for a newbie to get in, I do think its getting better in some areas. And the one that I would name is just the code I think is more accessible these days. There are some parts where it’s gotten worse; like the stack is definitely gotten deeper and that’s makes it a bit better to track, but when they switched away from heavy meta programing to breaking everything out into modules and just including those in the right places and letting Ruby’s method call system work like it’s supposed to work, I think Rails gotten much easier to understand at that point. So I'm hoping that that makes contributing and stuff more popular, easier to get into. AARON: Readability has definitely gotten better in 3.0, in my opinion. Some of the asset pipeline I'm not super excited about, but we'll fix that overtime, I guess. CHUCK: I think that’s one thing that we see with our development processes too is that I never write pretty code the first time. [Chuckles] I usually wind up writing ugly code and then fixing it. AARON: That’s the thing is like as long as we have tests… we have tests for it and it works, so now that we've gotten working, then we start moving on to the refactor stuff. I mean that will be the refactor stuff of our red/green cycle. It’s not the prettiest to read, but you can get through it if you have dedicated a few minutes. CHUCK: I really want to see what speculations people have as far as things that maybe we would like to see in Rails 3.2, that isn’t coming in Rails 3.1. Does anyone have any thoughts on that? AARON: Oh, boy. I did, but I think that somebody else should go first. [Chuckles] PETER: No cowbell. CHUCK: No cowbell? PETER: More cowbell. JAMES: More cowbell, that’s right. I don’t know what we are going to see in Rails 3.2 obviously, I don’t have errands inside. I was trying to think of what I want to see in Rails 3.2, and I don’t find myself coming up with like 50 immediate things that I wanna throw out there. So, I think that is kind of a good sign. I think maybe the one thing I would like to see Rails get into a bit, there's lots of systems like this but Heroku's new setup were to use the park file I think that through forming where you set it various processes. I think that’s pretty much a requirement of any non-trivial Rails application, that you are going to have at least a background working process or something like that. And I would love to see Rails get a little bit into just making it easier to set something like that up, or maybe giving different ways to load Rails environment; like in a background worker, you generally don’t need the entire stack, just the database side would be enough. Or giving us way to even load on slimmer environments and stuff like that for API or setup like that. And I know that you do have those tools like through metal and the router, which is definitely improved, but I think seeing Rails get in to that and make it something nice  like form does with its prog file is a feature I wouldn’t mind seeing in the future. But I'm totally just a pie in the sky wishing now, I don’t have any idea if they would ever do something like that. AARON: Background processes seem pretty important to me. That's another thing that we do in all of our applications at work. I would kind of like to see that too, but I think my goals for 3.2 are not so lofty. [Chuckles] CHUCK: [Chuckles] Yeah, I think one thing that I would like to see as well is I've dealt with applications that need to connect to more than one database at a time, and that whole process seems a little bit clunky to me. You can still put it in the database.yaml and you can still tell it what connections to use, but you know, it just seems like it kind of exposes the trick behind some of the Rails magic that I wish I just didn’t have to think about. AARON: I think one of the things I wanna do for 3.2 is like right now, in Rails, our base class test case, like if you go all the way down to the base class, it’s actually a Test::Unit test case and what I wanna do is I wanna change that to be Minitest on the base class. And the reason I wanna do that is because, I mean we’ve talked about the benefits of Minitest, but you will get the Minitest spec’ing stuff for free basically, so people can have a spec’ing library built in and not have to do anything. CHUCK: Right. JAMES: Hurray for that idea. CHUCK: [Chuckles] AARON: Well, and you also get faster test runs and etcetera, etcetera. I actually have an awesome idea that I wanna put in. So do you guys use Fixtures in your Rails apps? CHUCK: No. DAVID: Yes. JAMES: No. AARON: No? All right, I do. DAVID: I'm with you, Aaron. AARON: All right, we can argue about this later. I'm happy to argue about Fixtures versus Factories, but we use a lot of Fixtures, and one thing that sucks is its slow to load those Fixtures into a database, right? That’s actually the main startup cost of your test run is loading all those Fixtures into the database. So what I wanna do is I wanna see if I can get those to load into a SQLite database, and then cache that loaded database. Your first, you pay the same cost, but on subsequent runs, it will just copy that previously used SQLite database, so we can get basically instantaneous startup time to our test runs. JAMES: That’s a pretty interesting idea, but the downside to that would be the test would have to run under SQLite, right? So if you use PostgreSQL-specific queries or something, you'd have a problem with that, right? AARON: I think we can do something with other databases. JAMES: There's actually plugin, I believe for the Postgres adapter, where it throws all the Fixtures in the database and then I believe that sets a save point, and at the end of each tests, it rolls back to the save point after Fixtures have been loaded. And my understanding is that’s quite a bit faster. AARON: If we could do that between the test runs, I'm pretty sure there’s a way to do it for all databases between test runs, we just have to figure out how to do that, but it should reduce start up time on your test suite like a lot. DAVID: There's a trick that we started doing at Public Engines that we actually ran into a snag, where we were trying to move a bunch of our test data, our production data but ideally, the idea would be to move all your production data to use MySQL’s in memory tables, so that’s all in RAM, and just there's no disc access, there's just no wait time on that. And we immediately ran into a problem because for crimereports.com and of course we're doing geo coding and we're doing geographic searching, and the archery indexes can't be stored… you can only store them in a --- or in odb table; those are the only two engines; it doesn’t support the in memory engine. And that kind of highlights Jame’s issue is that if we're developing MySQL and there's this clever plugin that runs on SQLite, that’s okay right up until we have spec that actually checks database constraint enforcement, that kind of thing; if they are not equivalent between engines, then you run into trouble. But I think that would be really brilliant if you could find some ways to optionally turn on some performance enhancement and say, yeah for this subset of the test, it’s safe so you can do it, so you can just turn it on and run. AARON: So one of the places I worked, we got all of our tests to run… so what we will do is test on SQLite and then deploy to the MySQL, and we got all the test to run in an in memory SQLite database but it turns out that didn’t actually buy us much time at all. DAVID: Really? AARON: Yeah. Our main overhead was loading all the Fixtures into the in memory database and then from then on, we weren’t IO bound at all, we were CPU bound on all of our tests, so putting it in memory didn’t do much. DAVID: Interesting. I wonder if that is universal or that’s just where your bottleneck happened to be next. AARON: Yeah, that the thing; I don’t know. JAMES: I've definitely done some work with the SQLite database, where I was switching to an in memory database bought me a lot. It may be because the way Rails runs tests or something. I've never done it in Rails test suite, so it may be that it’s just not effective there, but I can say that SQLite’s in memory database can be lightning quick. AARON: If you are IO bound, absolutely. It’s insanely fast. But I mean, we were CPU bound, so didn’t help. DAVID: We had a sys admin Nazi from hell and everything was on VMs; and the VMs were on the same hardware, but they were firewalled from each other through external hardware. So literally, two machines on the same Zen physical machine, 100 kpbs. I mean, just insane IO binding. Just absolutely insane. And that’s a separate bottleneck. That’s a “go attack your IT” bottleneck. AARON: [Chuckles] CHUCK: All right, I'm going to bring us back to Rails. We've kind of gone off on this tangent here. DAVID: No, we want all these in 3.2. [Laughter] JAMES: That’s awesome. Can we go around the horn on the Fixture question? It’s a hot topic. CHUCK: Sure. Go around the horn and say whether or not you use them or… JAMES: Yeah, Aaron why should we be using Fixtures? AARON: So, I use Fixtures for a few reasons; one is it will be faster than using Factories simply because the fact that all of your generated data is cached. And the other reason I use it is… I don’t know. [laughs] How's that? I like them. CHUCK: [Chuckles] How about you, Peter? PETER: Even when I've used them, I've always found them a little bit verbose to kind of define and work with. But if there were a defense for using them, it would be because DHH likes them. That seems to be a common defense now. Like, “Oh, I use CoffeeScript. DHH uses it, it must be good.” CHUCK: [Chuckles] PETER: This was a common thing that was brought up during the whole adding CoffeeScript in Sass thing. It’s like DHH likes this framework, let’s go with it. So yeah, I have Fixtures on some old projects but I don’t use them on new projects, so that probably pretty much builds up my entire opinion of them. But I'm not against them, and I still maintain them on older projects. They are just not for me now. DAVID: So I weighed in and said yes on Fixtures. I'm going to qualify that and say that you should use Fixtures when they are appropriate. And when should they be appropriate, let me start by saying when they are not appropriate and that is whenever possible, you should be doing all your unit tests should be testing the model. They shouldn’t be testing Fixture data etc. but a real obvious place where it’s obvious to me that you need to be using Fixtures is when your database is actually an interface, that some other process like a message queue or a data warehouse is pumping data out and you actually received data in the database from some other process. It didn’t get created and validated by Rails; Rails doesn’t own the universe anymore, it’s now just one member of a functioning ecosystem. And the data at rest in the database is kind of the API that you have the code against, that’s a really good argument to be using Fixtures data. I will then say that you should only use your Fixture data to test the interface of getting data in and out from your database. And then as soon as possible, you should close up that spec bundle, open another one that doesn’t use Fixtures and do everything with your models and with factories. JAMES: I used to use Fixtures a ton, and I just found I kept getting bit by --- I would try to test some pages paginated, so I would look for x number of entries and then I’d end up making new Fixtures somewhere for whatever reason, and then that broke other tests further away and maybe that’s not even a very good example, but you get the idea. I found that as I had to modify Fixtures to do something in one place, then I was breaking things in other places and it really just got me down. So then I switched to using factories to build them. I do agree that Fixtures are faster than Factories. However, when I switch to factories, I had this like enlightening moment, that actually I think it ended up making them faster for me, and that was that I don’t always need to put it in the database to make the test work. Especially in unit tests, a lot of times I have a method that just manipulates some data in the model in some way and shows it to me in a different way, perhaps it pulls out an inner field and calls to io or something like that. Vut the point is I find that in a lot of cases, I could just do model.new, past the field to set it at whatever I wanted and then just call the method after that, and I don’t need to save it to the database. So I actually now, whenever I can, I do my testing without involving the database at all. And then when I really do need to involve the database, I go ahead and use factory to build the object and put it in there. And so because I'm only using factories like half the time or so, then it turns out that that actually turns into a win. The thing I really do like about factories and the reason that I could never go back is wiring up associations in Fixtures is -- to put it nicely –a nightmare. And with factories, it’s great; if I have a user factory and then I have an article factory, and that article has an author, then I can just say association, user and then boom; when I create the article I get the user and everything else I need, so that then I can pull an email address out or whatever. So that’s how I do my tests these days. DAVID: I need to jump in again just because I need to go twice, because James just showed me that I'm an idiot that doesn’t speak English. I used factories exclusively. And when I'm saying Fixtures, I'm actually talking about factories that write up the database. Because James is right; managing associations is just a nightmare. Also, Fixtures, especially like Fixtures files on disc, it’s very, they make it very easy to write yourself into a code smell, where your test framework suddenly depends on the global state of the entire database, like the entire number of records in a table. And that’s a code smell that I've become really, really sensitive to. And if you’re doing that, you need to see if you can back away from Fixtures a little bit and try to do more factories. CHUCK: Yeah and my experience is the same with James’ where you have this Fixture set and then you changed it just a little bit. And you know, what I did initially when I ran into this problem was I actually ran into a case where I was trying to program around it, so instead of saying there should be three records in the database, I would say get the number of records in the database; and then when I create something, check that there's one more. But the problem is then what you get into is your test become so complicated, that they are not specifying necessarily one state or one path. And so it can get to the point where your tests need to be tested and… DAVID: And you are still depending on the global state of the database, right? Because you do that insert— CHUCK: That’s the whole problem. DAVID: You are depending on them not having a collision of unique key. CHUCK: Yeah, exactly. So anyway, yeah it does; it gets painful really quickly. AARON: Have you guys used Fixtures since Foxy Fixtures came around? Because like people complain about hooking them up like hooking up associations and I really don’t see that. JAMES: No, I probably haven’t. Can you explain to us how Foxy Fixtures hooks them up? That would probably be good for people to know. DAVID: I have used Foxy and had trouble, but go ahead. AARON: Basically all it does is that it looks at the associations on your models and generates ids from that. So basically we used to have the Fixtures used to be like this model belongs  to whatever, so you'd have to put in in your Fixtures file like whatever underscore id and then assign it some number. And then when you are trying to figure out this web of models, you have to keep all these numbers in your head which is basically impossible. But all the Fixtures have names, right? We give the record a name, so what you can do is say like well, this is the association, here is the name of the record that it is associated to. So you just provide that name and then Rails calculates  an id for you and inserts it to the database with that ID, so all you have to do is remember, ah, these are the list of the books for this author and you just put the list of the books names -- and it’s totally fine for me. DAVID: Foxy with a good set of ERB, like if you are actually leveraging ERB in your Fixture files and you are using Foxy Fixtures, you are really close to a factory at that point because you’ve got dynamic code, you’ve got interpretation, that sort of thing. It’s more of a data driven code model instead of a code driven model. One problem I've had with Foxy is the when your database is the interface and somebody else is specifying the ids of records, so here's ids 1000-1100, here's 100 records in this table that came from this data export; Foxy wants to dictate what the ids are, and so that can run you into a headache. AARON: Oh yeah, I agree. Honestly, I think the real answer is like we don’t I’d say I’d champ in Fixtures but the truth is we used a mixture of Fixtures and Factories where it makes sense to use one or the other. JAMES: Yeah, I think I can see that. I didn’t know about being able to refer to objects by name, so I guess that shows you how long ago I've moved away from Fixtures, but it definitely does sound better. I just really love what the Factory is being able to set things. And like I love how I can only specify the fields I care about this time. AARON: James, are you testing your factories? JAMES: I do not. AARON: [Laughs] I see. JAMES: I´ll just sit in the corner now. Thanks. CHUCK: I'm going to break in here and I really wanna get us back on topic. [Chuckles] DAVID: The future of Rails is the database. AARON: Let me tell you the direction of Rails; it is north. CHUCK: Oh, great. JAMES: Not maybe north by northeast. CHUCK: [Chuckles] AARON: I don’t know. Maybe. PETER: The direction is CoffeeScript. CHUCK: CoffeeScript, there we go. We'll wind up writing everything in CoffeeScript. PETER: I wanna know more about this DHH thing. This library that apparently, he talked about it at a keynote recently, and he was introducing the CoffeeScript stuff in that and he's like, oh yeah, “37 Signals are putting this framework, that like heavily uses JavaScript and everything,” and then he didn’t mention it again. So I'm intrigued on what that is all about. I never dug into it more after that. He didn’t cover it in any depth but they’re building some JavaScript framework at 37 Signals and they didn’t say much else on that. AARON: I know it’s called, Cinco. PETER: That's the one. CHUCK: Yeah, it’s supposed to be a mobile aware or something. I guess it’s the JavaScript framework that they are using in their Rails app, so that when you access the 37 Signals apps like Base Camp from your mobile phone, that the touch interface and stuff works and things like that. That was my understanding but I could be totally off on that. DAVID: What would that buy you over say using jQuery touch? CHUCK: Good question. I don’t know. I don’t know that they’ve released a lot of details about Cinco, to be honest. But I think that is one thing that is relevant to where Rails is headed is the mobile arena. We've been building our apps for web browsers for so long, and then we have these mobile web browsers that have this teeny tiny screens, and not the traditional mouse interface; touch or if you tap it twice or if you touch it long or hold it or whatever, you know? It does different things. And so, the interface that people are using to  access our Rails app isn’t as well defined as it would be for a traditional browser app. I'm a little curious too as to if there are specific features in the upcoming Rails versions that handle that? Does anyone know anything about that? AARON: I think what's going to happen is we are going to get better… I think Rails is going to become more… like much better at providing APIs. I'm speaking very vaguely here because I don’t really… it’s kind of a foggy idea in my mind, but I think like the future of web is it is going to become more and more client side JavaScript based, I think. And that means that Rails applications is going to have to be really good at serving up that JavaScript, but then providing APIs for that JavaScript too. So I'm not sure exactly like specifically how that’s going to affect the framework, but it’s absolutely something that we have to think about going forward. DAVID: I have a question along the same lines… and boy, I really hope the answer isn’t, “Duh, David it’s already in Rails.” Anyway, learn the libraries, right? One direction that I'm seeing applications moving is they are moving away from rest, from the representational state model to persistent connection, live streaming, long duration sockets -- that sort of thing. My understanding in Rails right now is that’s a bad idea because the processes are big and cumbersome and which you really wanna do is proxy them out something lightweight that can maintain a persistent socket. Is that the case in Rails? And if it is the case in Rails, where will we go in the future? Will we see an easy plugin ability like with rack to roll it out to something? Will we something in Rails itself like, active thingy that will let you persist that? JAMES: “Active thingy.” CHUCK: [Chuckles] DAVID: Yeah. Do you know what I'm talking about? I'm talking about like you connect to a mapping  application and you get real time locations of like everybody near you, and you are constantly sending AJAX, updating your geocode location and so is everyone else. And you are getting those things and it doesn’t make sense to do that with rest in a full constantly reloading the webpage. You just want a socket that is going to stream you token four has moved to this location. AARON: RIGHT, you are taking about web sockets. JAMES: right, basically and that’s kind of where I'm going with my earlier “pie in the sky” request that I probably didn’t explain very well. Basically what I was saying is I think nowadays, we always have those extra things; whether it’s for background processing which was just the first thing that popped in my head or your more current example of web sockets or whatever. We always need that extra environment running, feeding us constant information. And yeah, I think you are right that that is definitely where the web is going and so hopefully where Rails is going too. CHUCK: Now, doesn’t Rails come with a streaming API? Is that not something that you could use in a similar way? I know it’s not a socket but its… AARON: It’s not exactly the same as doing web sockets, if I remember correctly -- which I don’t. I probably don’t remember. Basically the way the streaming works is you do have a socket open to the Rails process, well actually, that’s not even true. You have a socket opened to the proxy, so for example, our set up is engine  x in front of unicorn. And on the backend, unicorn always uses closed connections back to the engine x proxy, but the web browser keeps a persistent connection open with engine x, so what happens is you keep the socket open and then you send a request over the socket, and then engine x decides who to delegate that to and request it from unicorn; which is okay because hopefully your connection between engine x and unicorn should be very fast, so you don’t need to worry about latency there, but engine x and unicorn don’t keep the socket open, but the client and engine x keeps the socket open and do multiple requests per socket. But this doesn't handle doing a push data back to the user like say web sockets would do. CHUCK: Right. JAMES: So kind of a long lines at the local OKRb meeting, one of our members has been working on this library and I don’t remember the name, I´ll look it up, but maybe its Real Time Rails, but he's been working on his library where when you render a bunch of objects in a page like you know, you render a collection of objects, but then it tracks those ids and as it renders them, it sets up a web socket to keep track of them and changes on them. And then these changes happen back on Rails in callbacks, it triggers via the web socket and that data on the page gets updated via the web socket. So it’s pretty neat stuff. And that you can render some things around the page and then it basically live updates as that information becomes available for Rails. I just kind of seen it in action. It might be cool for Rails to look at something like that in the future. AARON: It looks like web sockets are HTTP, so it’s possible. CHUCK: I guess the other question is we are increasingly getting into a world where everything connects to everything and so, Aaron brought this up with the APIs, better handling of APIs. What ideas do you have as far as what Rails can do better with providing APIs for external resources and accessing external APIs for its resources? AARON: Honestly, it’s difficult for me to imagine it right now because it’s pretty easy today for providing like JSON APIs and what not. I just think we need to push the boundary of how easy it is to setup APIs and get good APIs up and running. I'm just not sure how yet. CHUCK: Anyone else have thoughts on that? JAMES: Yeah, you know when I'm designing, and maybe this is backwards, but I always start with the URL, and then I work it out from that how I wanted it to work and function. The URLs that I'm going to hit is part of the API and I almost kind of wish there was a way to make Rails router work like that, like I can sketch out URL scheme and have it do certain things based on what I sketched out. But I'm not exactly sure that would look like and stuff. It’s kind of the on paper stuff I have to do beforehand to get ready for it. It would be kind of cool if it was rolled in as part of the router or something. CHUCK: They don’t frequently change that routing API. JAMES: Right. AARON: Probably one thing I think would be good is if there was a standard easy way in Rails to do API versioning. CHUCK: Oh, yeah. JAMES: That’s a great point, yeah. And maybe that can be generalized too. For example, you could have a component in your URL in your routing, basically where that component represents different versions in. And because of that, you could do something, set it to a different controller that you know, do something based on that action. Maybe even as simple as setting a variable or something somewhere that you can check against which one you are supposed to be handling or something. But that’s kind of interesting point and very good point that something people always end up doing manually. CHUCK: All right, we are almost out of time. I wanna ask one more question and I really just want a quick answer. You can take as long as you want to answer, I guess but is Rails harder to use now than it was when you learned to program in Rails? PETER: Yes. DAVID: No. JAMES: [Chuckles] We covered it. AARON: No. CHUCK: Okay, so we heard one yes and two no’s. Peter, why do you think it’s harder to learn? PETER: I guess I just focus on the why. And just the fact that when I've been teaching people, I've just noticed a lot more kind of friction with people that I've been trying to teach in recent times then a long time ago. And I don’t know whether that’s because I'm now further away from that having been through the learning experience myself or not, but there are just a lot more things that people need to juggle mentally to get a grip on it. And I think James probably touched on it earlier when he said about the move to like the restful URLs for example. There was a time when it was all a lot more kind of Sinatra-esque in the way that you just define every…  you can even have that pattern or you could just go into the routes file and define every single route separately if you wanted to even though that’s obviously not a great idea, we know that now. To people who are coming into it new, they kind of like, things like that. They like to get up and running and then they'll start to learn the best practices, which I think is probably a lot of us learn. That’s how I learned.  My initial Rails code was absolutely abysmal; it wasn’t following best practices at all and it’s got better all the time. So yeah, I think perhaps there is this emphasis now on doing things in a quite structured proper way of doing things. And it’s a lot harder to fall off the rails as it were. CHUCK: Okay. DAVID: Peter, I'm also going to suggest that part of your problem, just a hypothesis might be market fatigue. I think you’ve taught all the smart people, and so this is to be expected. CHUCK: [Chuckles] Those dummies. JAMES: Ouch. CHUCK: So Dave and Aaron, is it then easier to learn or is it the same? DAVID: I´ll give mine real quick and then Aaron can give the definitive one. I think there's more stack to learn, but I think it’s easier to come to. Like Rails has kind of lowered the entry point of there's a lot more magic, which means there's a lot more opinions but that means there's also a lot more convention. So you can sit down and you can start and now you can build your blog in 12 minutes instead of in 15. But there is a lot more stack to learn and so fair point that if you really wanna master Rails from top to bottom, I think there's going to be more to do, but just to pick it up and run with it I think is simpler. AARON: Yeah, basically that’s what I was going to say is I think we have stuff like Bundler which get your dependencies all installed and ready to go for you, like this seems much easier than it used to be in the old days. But I think it’s easier to get up and running, I just think it’s harder to master. CHUCK: Right, okay. JAMES: I will say that while I mostly agree with Peter said, he basically echoed my thoughts perfectly. But I do agree at some of what Aaron said too in like for example, when Bundler came out at first, I think I really didn’t know what to think about it. And the more I use it, the more I'm convinced that it’s the best thing that ever happened to Rails applications, because you put it on the server, you bundle install and just forget about it. And I'm currently in my job right now moving old Rails application up to Rails 3 and just the dependency management to get that old application running on my computer was amazing. I can't believe we used to do that regularly. CHUCK: All right, well thank you very much everybody. Let’s go ahead and jump in to the picks. Let’s go alphabetical this time, let’s start with Aaron. AARON: Amazon Prime. Get it. [Chuckles] So one of my hobbies is sausage making. [Chuckles] CHUCK: [Chuckles] You got to do something with those mushrooms, huh? AARON: Yes, exactly. And I wanted a smoker, so that I could smoke my sausages and I bought it on Amazon with Amazon Prime and it will show up tomorrow, so I am extremely happy with the service. So yeah. CHUCK: Okay. JAMES: I have to agree with that. That’s like one of my best company write ups ever. CHUCK: [Chuckles] What do you get for it? I know you get two day shipping. Is there anything else to it that you like? JAMES: 2 day shipping for free is the thing that can't be beat. AARON: Yeah and I think like two day shipping for free is just so good and for the price like it will pay for itself when Christmas rolls around. CHUCK: Right. That’s very true. All right, was there anything else? We all kind of chimed in on you. AARON: No, that’s it. CHUCK: Okay. I think I'm next. ive had a few people asked me what I use for my podcast recording and so I'm just going to throw a few things out there for that. The first one I use is I do all my hosting at  Libsyn.com. And it’s a paid service, but basically it takes away all my worries about bandwidth and  it gets the downloads done pretty fast. Another thing that I'm doing is the recording that I'm doing goes into a digital audio recorder. And I'm doing a Skype mix over an iMic, and it goes into the digital audio recorder which is an  Edirol R-09 or whatever. It’s the HD version of Edirol, which they don’t make anymore. Now you have to get the 05 or something. Anyway, the Edirol is really nice because it actually has a microphone on the top, so I can actually just walk outside, hold it up by my face and just talk into it. It records it all to an SD card that I can either put in to my computer or I just plug the USB cable more often than not and it takes care of that for me. And then on my iPad, I'm using an app called Resounder, to queue up the music and stuff. And that’s pretty much it. The only other piece of hardware I've got is my microphone, which I'm not super fond of so I'm not going to tell you what it is. And I'm using the Behringer XENYX 802 Mixer -- and its awesome. So I´ll put links to all of that equipment in the show notes. And if you’re thinking about starting a podcast, all you really need is a microphone and some software to record. But if you wanna get all fancy, then that’s what I'm using. I guess Dave’s next. DAVID: Okay, yeah. So I was definitely ill last week and I've actually been sick for about the past three weeks. And so, if you are listening to this podcast through the wonders of modern technology, you probably have access to my pick -- which is first world medicine. The past three weeks, I have been absolutely wonderful and grateful for expectorants, anti-histamine, decongestants, and antibiotics. And specifically, I wanna give a big shout out to my good friend amoxicillin 500 mg, two tablets twice a day until the infection in my lungs goes away. CHUCK: Oh, man. DAVID: So yeah, shout out for doctors everywhere. Thank you. JAMES: And that was a public service announcement: Vaccinate Your Children. DAVID: Don’t even start with me. Vaccinate your freaking kids. Get over your freaking superstitions and vaccinate… AARON: What are you talking about? That’s how the government controls us. You didn’t notice?  [Chuckles] CHUCK: Yeah, it causes autism. Oh man, now we are really going to get blamed. JAMES: If we don’t get hate mail over that, Vaccines do not cause autism. Go vaccinate your kid. CHUCK: Really, go read the science. James? JAMES: So a couple of years ago, I declared war on Photoshop and I think I'm losing because I've replaced it with about 5 programs instead of the one that I used to use, but I'm much happier now. So that’s how I tell myself it’s okay. But anyways, I've learned some cool things along the way as I do it. And I'm going to have to recommend at least two of the programs that I used to replace it. I used Pixel Maker  for a while and it has kind of a nice interface and stuff but there are always things that are lacking so I always had to go to the Acorn to do the other things that I couldn’t do in Pixel Maker. And then as time goes on, I've learned that I'm just doing everything I need in Acorn, so it’s finally come up and taking care of those things. It’s not as sexy pixel maker, but it’s definitely functional; it’s got great filters and stuff in it now, so if you want a graphics program that’s not like insanely draconian, I recommend Acorn. And then the other graphics program. I've actually just used since like the Mac OS9 days and can't get over is the Graphic Converter. And that program is just absolutely I swear, I've thrown images at that, but I have no idea… if I see a file I don’t even know what is, I usually just try to open in a Graphic Converter first because even if its bob’s image format, graphic converter opens it. It’s like they have a time machine and they went into the future and predicted all possible image formats, and all of them are already in Graphic Converter. And they were like 15 years ago, so it’s amazing, you can open anything with it, I swear. So Graphic Converter and Acorn are two of the tools I've used to avoid ever supporting Photoshop again. CHUCK: So I have to chime in here and let you know James that I have a James picks tally going, it’s currently at $30. If I hadn’t already upgraded Acorn, it will probably be $80 now. JAMES: That’s awesome. CHUCK: Yeah, I went and bought one of your games last week, so. JAMES: Which game? CHUCK: I bought Lost Cities. JAMES: Awesome game. Great choice. CHUCK: Yeah, it should be on the mail today or tomorrow so we'll see. I told my wife it was for her, but it’s not. JAMES: So I'm costing people money now? Now I'm going to feel pressured to find cheap recommendations. That awesome. CHUCK: No, good recommendations. I'm enjoying them. All right Peter, what are your picks? PETER: You guys are way down in the alphabet. I just noticed, James like J, you are not even halfway, I'm like way up there on my own. Yeah I just want to second the Amazon Prime one that Aaron mentioned. Although just to make you grin, here in the UK, what you get for your money is next day guaranteed delivery, just because it’s a tiny little island which  means I spent so much money on Prime. I actually kind of hate it in a  way. I like it of course, but the fact that I'm just going to click and bang it’s going to be here by mid-day tomorrow. So I think 11pm actually, they will do that. So yeah, small country. Some of the benefits. 20% tax, not so good. Things that are  my actually proper picks, CoffeeScript, you might I mentioned this a couple of times. I actually got to play with it last weekend. I literally spent the whole weekend in a hack event putting some stuff together and I've kind of fallen in love with it, so I'm probably going to be talking about it more in the future and I've been enjoying that so far. And in terms of an actual project to just point out, I wanted to point out Foreman, because it ties into something that was being mentioned earlier about having managed multiple processes from a Rails app. What you can do with Foremen is you create a file, a proc file which I believe is a little bit similar to what you  can do on the new Heroku stack, although I have not played with that yet, but you can create this proc file where you define all of the different processes that kind of backup your Rails process; so things like rescue workers, schedulers and things like that. And then you can run that locally, where foreman start all of those processes and lets you see all of the logs of those in sort of a single stream. And then you can actually export it to production, which will export it to Ubuntu’s up start system or to a normal system. They are rolling it out to production. So this might be something that might be very interesting to see perhaps become a bit more mature, get more development and maybe integrate with Rails at some point down the line. So yeah, that’s pretty much it. CHUCK: All right. JAMES: I think that is what Heroku is using. I may be wrong, but I believe it is what they are using and it is definitely what I was trying to refer to earlier. CHUCK: All right. Thanks guys for another great podcast. I know our audience really appreciate you taking the time to come on and talk. We had a major tangent there with the Fixtures, but I think there's a lot of content there. And I think really did go into some of the things that we are going to see Rails have to deal with one way or the other. Our panelists again today are Aaron Patterson, David Brady, Peter Cooper, James Edward Gray and I'm Charles Max Wood. You can get the show notes at rubyrogues.com, and you can find us in iTunes. And again, just like to ask you to leave us a review and let us know what you think. JAMES: Also vote for our show topics. We took this topic out of the votes. CHUCK: Yeah, absolutely. This was the top topic, so yeah go to rubyrogues.com, click ‘request a topic’ and then vote something up or add your own in. And that will do it, we'll catch you all next week.