 Okay, absolutely. If not, I have more jokes. Yeah, I have a Windows version of U.S. 8.1? Okay. I've been using this stuff. Yeah. Okay, so I have been writing a few things over the years, and previously I was doing desktop application development, so I actually had a machine with every single version of Windows since forever. I would have to test my application every platform. Okay, never mind. Alright, that's that. Okay, so the first thing I wanted to ask for this whole thing starts because I'm just curious. So who does their primary development work on Mac? Mac. Okay, that's like two-thirds of you all. Linux? Linux? That's like a third. And I'm guessing no one else here uses Windows. Okay, well done. Okay, so that's kind of tangential. So I'm Joel. I've been writing software for a while. I like tools. I like languages. I like, you know, basically finding ways to make engineers productive. I'm that kind of person. So my five random movie tips today are sort of one actually more Rails tips on how to get your stuff done quicker. Okay, so let's jump straight into it. First, it's actually possible for you to actually run Ruby code in your browser. There's this project out there that's called nscripten. It basically takes all of your existing language runtime. So Python, Ruby, I can't remember what it was, the other one. Basically, they take the reference implementation. So in this case, MRI. They compile the using LVM and basically generated it into JavaScript. So you can actually run it in your browser. It would be useful if you are on a computer without Ruby installed and you need to do something. I don't know how useful, but give it a shot. It's useful. Somehow. Okay. You could do that too. You could use Nitrous. I had some reservations with Nitrous. Okay, anyway. Okay, the next one is now the rest of these are all our Rails tips. First one is you are given database. You get a schema. How do you know what you want to index? So you can use this gem, a lot of DBA, supposed to basically run through all your models and generate the list of indices that should be in the schema. It could be useful. I put this here because I told myself I'm supposed to try it out, but I actually had not yet. So, well, yeah. Okay, the next one is similar. It's called Bullet. Bullet is a gem that helps you eliminate your n plus one queries. What are n plus one queries? Basically, you load something and for each item you find some associated information. So what happens is you have to run n SQL queries, like one for every item in your first data set. Rails gets around this problem by this thing called eager loading. So then how do you know what you have to eager load and whatnot? So then Bullet also will run through, as you basically run your pages, looks at your queries, looks at and try to guess when you probably should be using eager loading and when you have not. And it will tell you when that happens and you should do something about it. Once again, this is one thing I told myself I should be using. I have not used it yet. I will. I will. Okay, the next two is I think probably a bit much closer to my own beliefs. Okay, so the cool story or the strange story, the real story, whatever you're going to call it, was that before I had windows on this I was actually running Ubuntu and I was like doing a Rails app in Ubuntu because why? On Unisys you have this thing called Spring. And Spring is supposed to basically preload Rails in your memory. So remember you run a Rails task or some Rails thing. Instead of taking like 10 seconds to start up and then run that command for like half a second and be done. So if everything sends a command off and basically then half a second. That was good. But I still found that my development experience was really, really bad. So I narrowed down to these three things. The first thing is when I requested for a page from my application, it took quite a while before I saw anything being stacked up from whatever web server I was running to spit my page out. And I found that it spent a lot of time and crashing my disk along with it. Running through all of my assets and trying to like figure out whether these are fresh or not. And that took quite a while. So Debug Asset Pipeline, this particular gem only refreshes your assets only when they are changed. Okay? First thing. Second thing, if you have your Rails server running in a console or you have your assets out in Debug mode that you have one HTTP request for every single asset. So if you bring in like 10 files, like 10 JavaScript files for example, then you're going to see like 10 requests in your console. That's really nasty. It clouds your actual output which you're probably more concerned about. It's probably your SQL queries for example. And so what Rails DevTweets does is it actually blocks all these asset requests so you can still have Debug on and you don't get all your assets in one huge file. And yet not have your console flooded with text. All right? The final one was the one that actually improved my development time by a lot. Okay? So what happens is if you run Rails in Debug mode what happens is every time you change something you reload a page. Rails are basically scaring the entire directory like every single file open and unchecked to see whether it's changed. In my case it was particularly slow because you have to like, opening files are not exactly the fastest thing on Earth. So that also took some time to, you know, get up and running and decides that, you know, you should reload everything over again. So what Rails DevBoost does is the moment you change file it reloads it in the background and so that you don't have to wait until you request for the page and so by the time you request for the page it should be loaded, right? Okay? So that was the first bunch of things that I did to improve my development speed. The final one comes for Spring. I was talking about Spring just now about how Spring preloads everything but the other thing that Spring does as well is that Spring also will check all your files in your application directory or the entire source directory for changes and I was paying attention to Htalk for a while and I was wondering why. And I found that, you know, Spring was loaded in background and it was using like 15% of a CPU and I was like, why? So looking around, it showed that Spring has this loop that basically iterates over every single file in your Rails application and it decides, it's just that the site value needs to be re-linked application. So in a typical setup you have these two things looking at your directories for changes to your Rails application which is not exactly the most efficient thing to do. So Spring allows you to do this little thing you can put in your Spring content file. Basically it says instead of iterating over every single file, you'll use your native OS method for getting notified that a file is changed so Spring instead of needing to run that busy loop, it just waits for changes. Okay, so that's it. Any questions? Otherwise I will be hanging around for a while. Right? Thank you. So like I promised, we have a bit of time for folks if you have any hot picks or things that you want to share with the group.