The Changelog: Software Development, Open Source - Pow, Rails 3.1 Asset Pipeline, CoffeeScript and More (Interview)

Episode Date: July 13, 2011

Adam and Wynn caught up with Sam Stephenson from 37Signals to talk about his his many open source projects and developing Basecamp Mobile.

This week's episode is brought to you by SkyBalloon, makers of Capture. Capture is a video record button for your iPhone home screen. We've all had those moments of frustration waiting for the iPhone's default camera to initialize, only then to realize we're in the wrong mode and we need to switch and wait again. Capture solves that problem by being a dedicated video recording app. It's just 99 cents and is available on the app store. Go to skyballoonstudio.com slash capture for a download link and also a cute video promo. Don't push me away! to github.com slash explore, you'll find some trending repos, some feature repos from the blog, as well as our audio podcasts. And if you're on Twitter, follow

changelogshow. And me, Adam Stack. And I'm Penguin. P-E-N-G-W-Y-N-N. Fun episode this week. Talked to Sam Stevenson over at 37signals. He's the guy behind PAL and Prototype.js and a bunch

of other fun stuff. It helps sling the code behind the 37signals Basecamp mobile application. Talked a bit about Synco, which is the framework that they hope to extract out of that application. Everybody's wanting the deets on. And I bet you were excited to hear his thoughts on CoffeeScript. Oh, CoffeeScript and how it plays into the Rails 3.1 asset pipeline, which we had a number of questions on.

Hopefully we can save some folks some, I guess, knuckle scraping, as it were. There you go. Everybody that's been playing with Rails 3.1 has been having a time of it with the asset pipeline. It's lightly documented but very powerful. Absolutely. And next week we'll be out in Dallas at the Big D conference. Yeah, if you're out at the Big Design conference here in Big D,

I guess it's Friday and Saturday of this week, July 15th and 16th. Say hello. I'll be presenting on accelerated style sheets with a friend of the show, Nathan Smith. I hate to say the 960 guy, but that's his claim to fame, but he's a JavaScript-er in his own right. There you go. And he's a good one, too. He's got a lot of fun projects at Dapp.js, which we used

at our daily gig, too. That's true. Dapp.js is fun. He's got a lot of... Formalize.js, I guess, is the other one that's really big, too. What doesn't he have? That is true. That is true. This isn't a Nathan Smith episode. Check out a different episode for that.

Fun episode this week. Should we get to it? Let's do it. We're chatting today with Sam Stevenson from 37signals and purveyor of PAL, Prototype, JS, and some other frameworks. So Sam, why don't you introduce yourself a little bit about what you do at 37signals. Hey, so I do a little bit of everything at 37signals. Well, you're like a designer and a coder, right? No, no, no, just a programmer here.

Let's see. You did a good introduction for me. Just say what technologies you work with. All right. Yeah, so I'm a Ruby and JavaScript programmer at 37signals. I've been here since 2005. I was an early contributor to Rails, created Prototype in early 2005, and since then I've done some other stuff, including Sprockets, PAL, and a couple of smaller projects like Stitch and Exec.js.

You've got quite the lineup. We're probably going to end up splitting this into two episodes. If you're listening to this and we don't cover one of your favorite libraries that you like of Sam's, then stay tuned to either part one

or come back for part two or come back for part two or come back to part one and circle back and catch the rest of this. So plus you do some awesome show notes too. So I'm going to have a problem with that. They shouldn't have a problem that we have the best show notes in the business. That's what we heard. So Sam, the reason that you came to mind most recently was POW. Adam and I are big fans of POW. Tell us a little bit about POW and how it came about. That's awesome. So POW was, like all good open source projects, a product of frustration. At 37signals, we have something like 20 applications, and each one needs to run at its own domain name.

And most of the applications scope accounts by subdomain. So it's important to have – in the past, we would have huge host files set up so we could test things out in development. And every time you'd set up a new machine, it was a hassle to get all the apps installed and then to get the host file set up and everything. So I thought, surely there's a better way. And at the time, I was playing around with Node.js and CoffeeScript and just sort of came up with this really quick and dirty thing that spawned – it would automatically spawn Unicorn. And my coworker, Josh Peek, took a look at it and said, that's shit, and pulled that out and came up with this really awesome library called Knack, which is a Node.js adapter to RAC. And from there, we continued to build PAL out and added the cool DNS stuff to it. And it's been a big time saver for us all here at 37.

So when I'm describing PAL to newcomers, I guess I'm drawing a comparison a lot of times to Passenger. I'm not sure if that's fair. Were you using Passenger? Yeah, that's what most of us were using before. Some of us were using Nginx also. And the problem with Passenger for me was having now in this kind of hybrid mode where all of us are running multiple Rubies for the most part,

it was just a problem running multiple Ruby installations with your passenger setup, but PAL supports that, right? Definitely, and that was kind of an accident. It's a result of the way NAC works. But it's right around the time that this was coming to fruition, we started experimenting with using different versions of Ruby in our apps. And now we do have some apps on 1.9. Previously, we were all re, but yeah, it's, so it's, it's, it's great that it just works with RVM and bundler. And for the most part, everything just works.

What was the inspiration, I guess, for using the dev domain? Were you guys using that prior? We were actually using the test domain, which I think some RFC recommends you use for internal things. And then when Josh went to work at GitHub, he said that they were using dev internally. And at the time, there was no way to configure it. We later added an option to configure it. But I thought dev was more intention-revealing than test because it's about your development environment, not your test environment. I'm using a gem called Powder. It's kind of a command line interface for configuring PAL.

Have you used it? I have used Powder. It's sort of the missing command line utility. Yeah, yeah. Have you used it? I have used Powder. It's sort of the missing command line utility. It's great. So Node.js under the hood, which you mentioned CoffeeScript, but is it entirely CoffeeScript, or as a JavaScript guy, do you sling any JavaScript in there? I personally love CoffeeScript

and hope to never have to write JavaScript again. So as much of it is CoffeeScript as possible. The creator of Prototype.js hopes to never write JavaScript again. Well, I mean, you know, when you're writing CoffeeScript, you are indeed writing JavaScript. But the nice part about CoffeeScript is that it's the good parts of JavaScript and you're kind of sheltered from everything else and it's just a much more pleasant environment. It's funny actually. I'm in the process of learning JavaScript and you don't want to write it anymore. Yeah.

It's – CoffeeScript just makes it so much better. So for someone who doesn't know JavaScript well or say they're a front-end developer and they want to do more snazzy stuff with their HTML and CSS, saying you want to write CoffeeScript means no JavaScript. How do you propose someone who's just learning the language in general to jump into this? Should they jump into CoffeeScript and go shorthand, or should they camp out in JavaScript and learn that first? You should learn JavaScript first. When you're writing CoffeeScript, you're still working with JavaScript. The object model is the same. It's still closures and functions and prototypes all the way through.

But the key difference to me is that when I look at a piece of JavaScript code, I see parentheses and braces and semicolons and line noise. And when I look at CoffeeScript, I can see the code that I've written. And when I'm writing CoffeeScript, I'm still sort of thinking in JavaScript, but I just have to type less. One of the digs on CoffeeScript, and I must disclose I'm a big CoffeeScript fan, but one of the digs on CoffeeScript is just the debugging overhead of matching source line with output line. Have you run into any problems or ever gotten into code where it's just hard to debug? I find it's pretty easy to map up the source lines,

especially since it doesn't mangle your variable names or anything like that. And for the most part, it's a one-to-one mapping between source lines in CoffeeScript and source lines in JavaScript. Command-F is your friend there. But just for the most part, it has not been a problem for me. This sounds disjointed in post.

We had a little hiccup with our network connection. We were chatting about debugging CoffeeScript. So what's been your experience, Sam? So a lot of people mentioned that they're skeptical about debugging compiled CoffeeScript code because the line numbers don't match up. And in my experience, this hasn't really been a problem because CoffeeScript is good about not mangling your variable names.

And for the most part, you get a one-to-one mapping between CoffeeScript's source line and JavaScript source line. So even if the numbers don't match up, it's very easy to Command-F and find where you were in the file. You know, when Jeremy came out with CoffeeScript, one of the very first things he did was, I guess, port underscore to coffee just as a one-to-one comparison. Have you played around with porting Prototype at all? No, so I don't actually, I haven't worked on Prototype in a couple of years. I passed that off to the core team a while ago. But that underscore example is a beautiful example of

what you can do when you go from JavaScript to CoffeeScript. So before we leave Prototype, there were some questions on Twitter about the future of Prototype and one user actually said in this age of jQuery. Are we in the age of jQuery? We definitely are, yeah. Is that your go-to framework these days? So we'll continue using Prototype for our existing applications at 37signals because we have quite a bit of code written on that, and it wouldn't really make a lot of sense to rewrite it all.

But for new applications, we are going to be using jQuery, yeah. What are some of the most adventurous things you've done with jQuery so far as a company, maybe even individually? I think the real win is that designers can pick it up and easily prototype stuff just by putting together a few plugins and writing just a small amount of code. So it's great for that. And then when it's time to build it out more fully, it works about the same as any other JavaScript library. So what's your take on the latest, I guess,

desktop in the JavaScript community around micro-frameworks and whether or not we need these monolithic libraries or kind of the Unix best-of-breed, off-the-shelf micro-frameworks? I like the idea. We have had experience with Zepto and Underscore and Backbone when we built our Basecamp mobile application. I think the idea of taking an API and then targeting it to a specific class of browser is great for times when you're constrained on processing speed and data transfer. And then things like underscore and backbone are great too because they're just really simple ideas distilled down to single-purpose libraries. You know, last year we went over at Texas JavaScript, and we had an interview with John Rezic, who is the creator of jQuery,

which you just talked about. And he was kind of prepping everybody with all the different browsers and all the different platforms. And in his talk, he had said the mobile web is here, and it was last year. And we were still not quite there yet, but a whole year later, are we at the mobile web? I'm not quite sure how to answer that. I think we're living in a WebKit world in mobile, and it's wonderful. And I think there's some interesting things about doing mobile development right now.

You can, for the most part, if you're targeting a smartphone, there's a high chance it's running a WebKit browser, and there's a high chance that it has relatively recent hardware, probably more recent than you can assume for people with desktop machines because of the way mobile contracts work. So I think it's great that we're seeing the hardware get faster and faster, WebKit get more and more features, bringing it closer to parity with desktop browsers, and it's

really exciting to work on on mobile apps mobile web apps the reason why i asked that question that kind of sense is because i know that i'm probably an edge case in this scenario but uh i'm on twitter a lot i'm on some sort of application uh on my iphone or a mobile device and the links i click they tend to go to websites in general so those websites are either designed for or planned for mobile experiences and the most often case is they're not. And the times they are, I'm really happy as a user, but as a developer I just wanted that as more and more people on the mobile platforms,

I mean you guys did the HTML5 version of Basecamp, so that's got to at least say something for mobile web. Yeah, definitely. I think the experience can be good whether or not you do a specific mobile version. There are a few things you can tweak to just make things more readable. But I use an iPhone, and I'm really happy with the way mobile Safari works. So John Gruber recently called out the Basecamp mobile app, saying that if you're going to do a mobile web app, then don't try to mimic native applications. Just build something altogether web.

Is that what you guys set out to do? We definitely wanted it to feel like a web app, and I think that's important because when you choose not to do that, you end up having to replicate native functionality or you end up trying to replicate native functionality with tools that can be slow or primitive. And this is what we've seen in the past with libraries that try to emulate native scrolling behavior, for example. So one thing we did in Basecamp Mobile was we just decided that the content is going to be on the page and the page is going to be what scrolls. And I think that worked out really nicely for us because the end result was the app felt very fluid. It felt like a web page still, and we missed not being able to have that fixed header at

the top or the bottom, but in the end, it didn't really matter. So in the latest iOS beta, leaks have shown that position fix now works as expected. You can dock those toolbars at the top or bottom, just like you would expect them to behave instead of to the dock them to the viewport rather than to the document. What other gaps do you see that need to be filled before you can really get a true immersive web experience versus what you would have to go to a native app to get? I'm super excited about the over scroll excited about the overflow scroll changes in iOS. One thing that I would like to see is support for uploading files.

So on iOS, you cannot actually trigger, you know, there's no file system, user visible file system, so you can't really open a file dialog. And so they just disable the input file elements. But it would be really nice if you could just choose a picture from your photo library, for example. I do quite a bit of mobile development myself, and on iOS you've got the screen density differences between the older iPhones and the iPads and then the iPhone 4 and the Retina display. Recently jumped into Android development and was just

shocked at the matrix of screen sizes and screen resolutions. It's almost like a Microsoft product matrix. So what does that leave us from a front-end developer perspective of making sense of all that? Is this something we're going to deal with, or are we going to have tools around that to make loading different resolutions easier? So what we did in Basecamp Mobile was we used double-size assets for everything, and they just scaled down automatically. And that seemed to work pretty well. So we went with the iPhone for resolution on all images. You know, which is kind of counterintuitive. We have been, I think, led down this track of WAP and older mobile technologies where you had to keep it as lean as you could because the bandwidth and processor was the problem.

And as you mentioned earlier, you earlier, these are computers in our pockets that would have taken up rooms 20 years ago, right? So is there anything that maybe conventional wisdom that you debunked as you developed this app? Let me think about that for a minute. Well, let me put that another way. Is there gains that you thought, you know, weren't that important that turned out to be big? I mean, what, what are the bottlenecks? Is it number

of assets and network calls? Is it size of assets? Um, we, I think, I think it was memory for us, really a number of Dom elements on the page, and especially when you get into things like turning on hardware acceleration for certain elements, they use up more memory, and they take longer to render. But the best part of all this is, you know, it just reinforces the idea that progressive enhancement is alive and well on the mobile web.

Because we built this app, again, all using our iPhones, and we tested routinely against Android and webOS and BlackBerry devices. And in the end, when it came to time to polish everything up and make sure we had a good experience on all the browsers. It was mostly just a matter of turning certain things off on the older browsers. Was the mobile app a complete 37signals team effort or just a couple of you working on this? Yeah, it was me, Josh Peek, who no longer works with us, and Jason Zimdars as the designer. No, Jason in Oklahoma City?

Yeah, that's right. So how does a project like that, I guess, get in the pipeline at 37signals? What's your workflow? Do you prototype a couple of things and then go to Jason and DHH and say, hey, look what we have? Or is this something that you plan for it out in the future? It can work that way, but the way this particular project worked is that we all knew that we wanted a mobile version of Basecamp and our customers were asking for it. And so it was just a matter of balancing that with all the other things that we can do on all of our other projects with our limited team size.

And eventually it became a priority and And we put some time aside to, we thought that we might be building more than just, you know, more mobile apps than just Basecamp. So we took a little bit of time to do a tech investigation and just play around and see what we could build without really building anything. And we were happy with how that turned out. And so then we went full in on the Basecamp mobile project. There's another

buzzword that kind of jumps in the playing field these days, coined by I think it was Paul Irish, wasn't it, Wynn? Responsive Web Design? That will be in the show notes. There you go. And Wynn and I, not long ago, we started this new gig together called Pure Charity.

And we kind of took the mobile form factor approach first. So design for mobile first and then went up to the desktop. And we actually ended up using Adapt.js for it. And it was kind of sweet how it worked out. But in general, like yourself, first and then went up to the desktop and we actually ended up using adapt.js for it and it was kind of sweet how it worked out but um in general like yourself what is the approach that you guys take do you take a mobile approach first or in general with your side projects do you take a mobile approach first and then design the desktop version and do you have this uh the same markup what are what are some of the different trends you go down towards actually designing

an interface for it we are right now desktop first. That may change in the future. But we focus on the desktop browser. And then we try to do things to make it work as nicely as possible and as many devices as possible. And then in some cases where we have a lot of people who need to use, for example, Basecamp on the go, need to check in on their to-do lists, their projects via email and stuff like that. Then we make the decision to go through and do a full mobile version. But we have played around with the responsive design for an internal application and we really liked

that as well i think that's it that's a great um sort of a judo way to to make a mobile app and being that you guys are the kings of frameworks do you plan to use an existing framework say like less um i think what was it called when less it's not less js because or less uh like the sas less kind of thing it's um the less web framework less css no no no um the less framework is actually what it's called less framework for less framework.com do you actually plan to use a framework that's out there do you think or is this something that you guys would take a look at and say, okay, we can probably do this a little bit better and actually create a usable framework to attack responsive web design?

I'm not actually sure. I haven't personally worked on that. I've just seen the way it works on the phone and in the browser in this particular application. I'm not familiar with the LESS framework. I think the approach is simple enough. It's adaptive, more or less. It starts off with some sort of framework where desktop version has 12 columns,

mobile version has three, and they're using some sort of media queries or JavaScript to make that adjustment on the fly. I think in general we would probably keep that in-house and just use the stuff that CSS gives us, so the viewport queries. So several folks on the Twitter were asking about your various frameworks, and one of them was Synco. What is Synco? Synco is what we came up with when we built Basecamp Mobile.

And it exists right now only inside Basecamp Mobile, so it has not been fully extracted yet. And we sort of made the mistake of talking about it before it was ready to be released. And so now lots of people are sort of tapping their fingers and asking, when is it going to be done? I think ThinkVitamin fueled that buzz a little while back. Yeah. So right now it doesn't exist in a form outside of Basecamp Mobile. It's something that I hope to get to this year. But right now I've got a couple other projects that I'm working on wrapping

up. So can you talk about the internals at all? Yeah, it's, septo, and we use JSDOM for testing. So by way of Stitch, you can actually load the application inside a node process, hook it up to JSDOM, and write your tests that way.

And that was really great for us. So Stitch for the uninitiated is a common JS stitcher together for the browser? Right. It basically works like nodes require a function. You give it a set of paths and it pulls in all the source code in those paths and puts them together in a single JavaScript file.

And each of your source files becomes a CommonJS module. Maybe a nice segue to Sprockets. Right. So it's new in Rails 3.1, so I guess the Rails 3.1 asset pipeline is based on Sprockets, is that right? That's correct. So one of the questions off of Twitter this afternoon was how does the Sprockets approach differ from, say, Jamit? So Sprockets was originally

created in, I think, 2008, 2009 maybe, and we needed it internally at 37. We were starting, we have all these applications and we needed to share common plugins across them, JavaScript plugins. And there was no really good way to do that. So I came up with Sprockets, which was a JavaScript packager that basically let you put code, it gave you a load path. You could have code live in vendor, for example. So we could have JavaScript plugins in their own separate Git repositories and then have them versioned specifically for each app,

but in general all share the same code. And we've been using that internally for, well, ever since then. I think it didn't really catch on. I probably didn't do a good job of explaining exactly why it's useful. And then Jamit came out a little bit later and took a more straightforward approach. You could enumerate your files and it also handled CSS as well as JavaScript.

And it's a really nice app. Sorry, a really nice plugin. So the new version of Sprockets came from our desire to want to bring this load path idea to Rails assets. And Josh Peek and I have been working on it for a while. But it's a rewrite of the original version of Sprockets that extends the load path idea to all types of assets. So JavaScript, CSS, images, Flash movies, MP3 files, whatever you want to serve.

You can keep these files in, for example, a Ruby gem, which you can then keep under version management with Bundler in your application and then pull them right into your app. So I think that's the biggest advantage of Sprockets. Other things that it does that JAMA does not do, it will automatically compile CoffeeScript code to JavaScript. It also automatically compiles SAS or SCSS or less to CSS. And I'm not sure if Jamit does anything with images or not,

but with Sprockets you can read those in as a data URI. Sprockets lets you add ERB interpolation to source files. So you can pull any image asset from anywhere in your load path and get it as a data URI string.

So that's pretty handy. So basically it pulls assets out of the public folder and makes them first class citizens of the application I guess. Exactly. In development mode, it enumerates all of them in the head, but in production mode, it concatenates them into one package? So by default, it concatenates everything all the time. There is a debug mode, which you can use in development if you want everything split out. So for CoffeeScript, what are you depending on to concatenate those files, the low-level Coffee compiler to stitch those together?

We actually – Josh Peek and I have a project called Exec.js, which lets you bridge various JavaScript runtimes to Ruby. And since the CoffeeScript compiler is written in JavaScript, we basically just pull in the browser version of the CoffeeScript compiler, which lives in the CoffeeScript gem, and then invoke it with exec.js. And exec.js is cool because it will automatically pick the best runtime that you have installed. And by default, if you're on Windows or OS X,

you have a JavaScript runtime available, and it'll shell out to that. You can also install Node, and it'll use that. And there's a great project called the RubyRacer, which embeds V8 into Ruby. From Charles Lowell? That's correct, and it's an excellent project. And it will prefer that if you have it installed.

So this CoffeeScript support, I guess, was the shot heard around the world back in April with Josh's famous commit on Rails 3 that included CoffeeScript and unfurled that massive comment thread on GitHub. Who got dibs on, I guess, checking that in? Did you guys discuss it or it was just his turn to make that commit? Oh, yeah. It was, I think, a long time coming, but Josh just finally did it and it was fun to see the reaction to that. It's a very polarizing reaction.

People either love CoffeeScript or hate it. It's great because it's just a line in a gem file, really. But it's a default, and I guess it's what the defaults that Rails encourages tend to catch on. Yeah, they're blessings. Although they don't always win out in the ends. I guess the also prototype via jQuery, right? Yep, yep. But opinions change over time.

And I think that's what makes a great framework. It's malleable and can change as our aesthetics change. What other types of assets can we serve out of the assets folder? You mentioned JavaScript and CSS, of course, also images, but what about something

could we serve pretty much anything out of this with the tilt gem to be able to take markdown files and have HTML come out the other end? So that's a good question. Sprockets does use tilt internally, but it doesn't expose all of the built-in handlers. But you could certainly – it's extendable. So you could certainly write your own engine to use if you wanted to serve markdown files from sprockets.

I actually saw an interesting project. I'll try to get the link for you guys. Someone was working on this project that compiled a certain type of source file to JavaScript processing commands, which would then in turn render an image. So he was writing processing source as sprockets source files, which when you request result in like a ping image being generated. So I thought that was really cool. I guess the boundaries are really limitless here.

You could do the same thing with CSS sprites, right? Yeah. There's no good solution for CSS sprites in sprockets yet. You can do data URIs in line, but hopefully somebody will figure that out.

I'm using it I guess I should say we use it with Compass on the edge with SAS. I'm using it, I guess I should say we use it with Compass on the edge, with SAS. I'm not using the application CSS manifest as much, just using Compass's built-in packaging because we're big SAS and Compass fans. But Compass also has its own spriting built in with Lemonade. I'm anxious to see how that shakes out. Yeah, maybe we can get that to play together. That would be nice.

Absolutely. I know Chris Epstein's been working hard on that. Definitely. He's a great guy. He's a Rails comp. Talking about that. So the learning curve for Sprockets, I guess for the Rails 3 asset pipeline, has been a steep one for me, and I've been in Rails since 2006.

Is it a lack of documentation? Is it just a totally new way of looking at how we do our assets? Or what seems to be the stumbling block for Rails devs? I'm working on the manual this week, and it's been a real challenge for me to explain sprockets. It seems like something that should be simple to explain. But I think the difficulty is that it does three main things. It gives you the load path.

It gives you the processing, so turning CoffeeScript or less files into the correct compiled output. And it also does dependency management. So it does hook in also to the Rails image tag helpers as well and serves those as assets instead of public? Right. So the way that works is Sprockets is actually, you create a Sprockets environment for your application. And that's actually a rack app. So it gets mounted at slash assets. And so you can just request any asset in the load path after slash assets, and it's served on the fly. And if that asset has dependencies,

those dependencies come in for it. So it implicitly creates bundles. So if we wanted to serve those, I guess, statically on a read-only file system such as Heroku and take those out of public assets instead of dynamically hitting Rails, what are options for setups like that? When you go to deploy, there's a deploy task that will actually copy everything in your load path over to public. You can also put it behind a caching proxy, and everything should just work.

Sprocket sets all the right headers. One of my favorite parts about this conversation is just thinking about the, I guess what I bumped into recently was the asset pipeline, and I was calling things from Compass, and things just weren't working out well. And I think it's just probably in that middle ground where maybe it's not all fleshed out. In Rails 3.1, is this asset pipeline and some of the stuff you're talking about, is it all kind of finalized yet? I think the overall design is finalized, yeah. We need a bunch of people banging on it and filing bug reports. And how do they do that?

Because, I mean, we've hit some bugs. I know that Chris, we mentioned before, Chris Epstein on Compass is, you know, a big cheerleader for us and the leader for us and doing good work on compass and helping us with um you know a number of sass things in general but also compass and css frameworking of all sorts and this is uh this is something to win and i use and that was a bug that we recently kind of i don't know if it's a bug or not but basically in uh in compass you have this variable that they call so the image path um that you can set and i wasn. And I wasn't sure where to put stuff, basically. Static assets like images and whatnot.

It's been, I guess, hard finding the right cocktail of edge gems any time something's pre-release. Finding the right version of SAS and Compass, and then as well Rails 3 itself. It's been a shaky road. So when you say people need to file bugs and tickets and help you hit and bang on Rails 3.1, where can they feed back to you guys? The best place is the Rails bug tracker,

and if it's not really a Rails issue, then we can redirect it to the right place. I guess one of the most exciting aspects of the asset pipeline is that now plug-ins and gems and bundles of application can hook into the Rails asset pipeline and provide assets without the need to run a rake task and copy those over to your public folder in some sort of generator, right? Yeah, and I think that's going to be huge. We already have been making good use of the Rails Pjax plugin, which does just this. And it's actually written in CoffeeScript, which is cool. I came across this feature with the Formtastic Form Builder plugin.

In Rails, prior to Rails 3.1, you had to run a rake task to copy their assets, their baseline assets, their style sheets into the public folder. But now they can just take it into the asset pipeline and serve those. There's no need to do that, which is really cool. But it also begs the question, as more and more code is coming from gems, are we losing anything to, I guess, obscurity or magic in gain of this convenience? I don't know about that. It does seem a little weird to me that we're packaging assets or non-Ruby code in Gems. But it's the tool that we have right now.

I guess the takeaway is to always look at the Gem source. I think in the early days of Rails, before we even moved to Gems for our plug-in management, everything was script plug-in install. I was pulling from Subversion, right? And unfurling these things down in the plugin folder. And it was right there in the project. And still people didn't open those folders and see exactly what this plugin was doing. They read or read me and said, hey, it does exactly what I want it to do.

But even more so when we moved to gem files or gem packages to manage these dependencies. It became even more of a black hole, and I'm just surprised how many Ruby devs don't go to the source and check it out. Yeah, it can be. The great thing is that you don't have to use a gem. It's a convenient way to distribute stuff, but you can also just check something out into the vendor directory. Sprockets will automatically look there for, it'll look for assets, subdirectories inside that. There's also a vendor assets, JavaScript directory too, which is where,

you know, it's a great place to put, for example, all your jQuery plugins. So what's the benefit? Last week's episode, or I guess last episode, has been a couple of weeks ago. We talked to the guys over at CDNJS and talked about more and more JavaScript frameworks moving up to the content delivery networks. And so it's kind of a lateral move than bundling all your frameworks together.

Have you noticed any gains in serving jQuery off of a CDN and just bundling all your frameworks together. Have you noticed any gains in serving jQuery off of a CDN and just bundling your application assets versus bundling that version of jQuery in with your assets? There's some contention about this, but I feel like bundling everything in a single asset is the way to go. And you can also break that down a level further by grouping all your framework libraries together in one bundle and then all your application code in another bundle, which Sprockets lets you do pretty easily since everything is a bundle. But I don't really know if CDNs are worth it for most people. Maybe if you have a public site where you serve a lot of traffic on the front page. But for most applications, the bundle is requested once and then it's cached. So if you're not a regular on the show or a listener of the show, you probably don't know that we have a running drinking game with the words Hamill and Sass on the show, or listener of the show, you probably don't know that we have a running drinking game

with the words Hamill and SAS on the show. I want to put these guys on SAS so far. I haven't mentioned Hamill yet. Maybe we'll later in the episode. Cheers. Cheers. I wanted to know how important was SAS's embracing of this new SCSS syntax? how critical of a factor was that in getting SAS support in Rails 3.1?

I'm not sure. I can say that the big thing that excites me about SAS is support for nesting. And I know a lot of people use the advanced features like mixins and things like that, but just having nesting is such a huge improvement. And the fact that it's backwards compatible with your existing CSS really helps, I think. So it's going to be good to just spread this to as many people as possible. You know, we use gems to kind to package up our patterns and share them across applications with Compass. You mentioned doing that with

now your JavaScript assets and even your CSS assets and have those being served out of gems. I think what excites me about that is we've had this dual world set up between client-side code and server-side code. Every time there's an advancement on the client-side, then those static assets have to

migrate their way over and be versioned separately than the server-side code. But now, if I want to take Adapt.js and turn it into an asset pipeline component, now I can say, well, I'm just using Adapt.js version XYZ, and I know I'm getting the static asset that came from that without having to really worry about going back to the source, copying the static asset over, and always maintaining that versioning myself. Yeah, I think it's going to be a big win. I'm excited to see what kind of stuff people are going to package up to. I think there's some interesting opportunities for Rails plugins that also provide maybe just a small JavaScript asset, a small CSS file, or a couple of images. I'm going to circle back to PAL just for a moment and about a couple of aspects of PAL that I found intriguing.

So I think one of the things that struck me when I came across the project, other than the great domain name pal.cx, was how well-designed the website was. So give a shout-out to the artist behind this design. Jamie DeHansen at 37signals did an amazing job of explaining PAL visually. I had been talking to him for a while about, you know, I'd like to do a website, but I'm not sure how to make it interesting. And he had the great idea of making it about superheroes. So he did some really great drawings and then made the website sort of look like a newsprint piece of paper.

Were you surprised by how quickly the adoption rate took off for PAL? Absolutely, yeah. It felt good. It felt like we really struck a chord with people. So I noticed the annotated source code, this seems to be a trend. I guess you used Docco for this? We used Docco, which is a wonderful tool. So it strikes me as just the right level of documentation for source.

Absolutely, yeah. But you can, in languages that are maybe a little bit twisted up, like, are not languages but environments, like Node, where everything is asynchronous, you can very clearly explain your intent alongside the code. And I found it interesting. I didn't start out, Pal started out without any documentation. And then I went through and added the docco stuff later. And I thought it was fascinating the way that it actually changed the code. As I would go through and document things, I would run into cases where they're too hard to explain. Something was too hard to explain or looked too awkward. And so I'd refactor it to be more linear, more narrative,

and it matched up with the documentation and in the end seemed so much nicer. And I think that's half of the benefit of Daco and the other half is that it makes it so much easier for anyone to come into the project and understand what's going on and contribute a change. You know, that's so right. I do a lot of titanium development in CoffeeScript. And when folks are coming to the project, I feel like there are certain aspects of the project that I want to document, but I want to make it part of the source code. But a lot of times the Java doc format

or those other formats are just so verbose and using at tags and at params and just especially a dynamic language like JavaScript or Ruby just feels weird putting a lot of structure to your documentation. It's sometimes more structured to your docs than you do your actual code. What makes this such a great project is it just reads it out of the comments, puts it over on the left-hand side in the left margin,

and then you see the code on the right. But the other cool thing is it uses Markdown, so you can use Markdown inside of your comments, and you get a nice formatted set of docs. So this is actually the first time I'm hearing of this, though. So where did Daco come from? Or do I not spend enough time in source code and reading comments? It's a Jeremy Ashkenaz joint.

It's inspired by Rocco or Shaco, or is it the other way around? No, Daco came first, and then the others followed. So Rocco is the Ruby version, and Shaco is the... Shaco is for shell scripts, I believe. Gotcha. Yeah. And so this is exclusive to Ruby or is this just... So Rocco is for Ruby.

I believe Daco is for JavaScript and CoffeeScript only, right? Or is it just you get CoffeeScript for free because it comes with JavaScript, right? Right, it's written in CoffeeScript. I've only used it with CoffeeScript. I believe it comes with JavaScript, right? Right. It's written in CoffeeScript. I've only used it with CoffeeScript. I believe it works with JavaScript as well. It's just such a beautifully simple idea. I think the implementation is under 100 lines of code too.

So what's up for PAL? Anything on the roadmap that are bugs you'd like to squash or features you'd like to add? I'm pretty happy with it right now. One thing I would like to do when I have the time, or if anyone is motivated, I'd really like to see it running other languages. The RAC protocol is so similar to Python's WSGI and Perl's PSGI. It seems like a no-brainer to support those languages as well.

Rupak G., fan of the show, asked me on Twitter today, why no support for PHP? He wants to put PHP in PAL. No, actually, you can install the Rack Legacy gem. I love the name of that gem. It's pretty opinionated. But it actually will shell out to the PHP CGI binary to run PHP files and then serve them up as Rack responses. So you can use that if you want to access PHP through PAL. That's your dream, Adam.

You can get your WordPress and your Rails out. There you go. I like playing with WordPress too. It's open source, right? It's good stuff. That's true. I can't knock those, but it's a good one. We actually have one more question.

Actually, this is something that's come up to me quite a bit too, which is LuckyDev, at LuckyDev says, will JavaScript become the mainstream server-side language like Ruby on Rails? I mean, we're going on a trend where Node.js is used far more often. There's a lot more happening in the JS world since it's on all platforms, basically. What do you think? There's no question it's going to become more and more popular. I don't have a crystal ball though.

But you do by prototype, so. I certainly enjoy writing things, writing server-side things in Node. And I think the dream is to have an end-to-end JavaScript application, right? Like you have your front-end in JavaScript and your back-end in JavaScript, and you're sharing models between them. I don't know if we'll ever get there, but as with all things in the web world, it's a slow march, and it'll be interesting to see how it plays out. You know, I guess Node, if it did anything,

was call home the JavaScript diaspora from around the world, right? All of these JavaScript coders were kind of embedded in the other server frameworks and now they have rallied around this server framework. But as someone who writes JavaScript and JavaScript well and CoffeeScript inevitably well and Ruby extremely well, if you were sitting down and you could pick any language to write a particular project,

which one would you choose on syntax alone? It really depends on the project. But gosh, there are a lot of things that I prefer now about CoffeeScript than Ruby. Comprehensions? Not so much comprehensions. I actually like the significant white space. I like not having to write end.

I like that every line of code is significant. And I just like the simplicity of the language. I'm kind of the same way. If you write something, you want it to mean something, right? A curly brace or a semicolon. It's the same thing with SCSS and SAS. And I think that's probably where Wynn and I probably – Wynn writes CoffeeScript, though, and I don't. But, you know, it's kind of where I can meet with you on there and say that I agree that writing code that doesn't actually do something sucks.

I feel the same way. I love the terseness, and don't get me wrong, it's one of my favorite features, but CoffeeScript adds a lot to JavaScript. It's not hard stuff, it just removes a lot of tedium, and one of those things is the existential operator, right? Being able to put a chain of dot notation method calls or property calls with a question mark in front of the dot and know that in a safe way you're going to go down five levels deep is just awesome. The existential operator is beautiful,

and it's definitely one of those things that I wish I had in Ruby. Still trying to figure out why I love white space so much and I still don't sling Python. You know, the thing that bothers me about Python is that it has seemingly arbitrary restrictions on what you can do independent of white space. So, like, you can't have more than one expression inside a closure, I believe.

That may not be accurate anymore, but I know at one time that was the case. And CoffeeScript has no such restrictions. So you can break out of the whitespace model if you need to using semicolons. There's also something really handy called the then keyword, which lets you join two white space sensitive lines on a single line. It basically is the exact, it parses the same way as a new line plus an indent. So anytime you write a new line plus an indent, you can also just write then. So it's really that flexibility, I think,

that's powerful about CoffeeScript. Yeah, I was asking earlier about JavaScript and CoffeeScript, but is there anywhere that somebody can learn JavaScript and CoffeeScript kind of in parallel? Is there any good recipe for learning those two in parallel? Just kind of being sure of what JavaScript does obviously is a good thing as a programmer, but at the same time, you don't want to just learn JavaScript blindly and not know where it maps to CoffeeScript or vice versa.

That's hard for me to answer. I don't know. Trevor Burnham's CoffeeScript book from the Pragmatic Programmers is excellent. It's not really, it assumes you know JavaScript, but it also takes you through using the language on the server side and in the browser. So I think it gives you a good overview of everything you can do with it. It's a great read. I highly recommend that book. So as a company, obviously, I think everyone would be safe to say that 37 Signals wasn't exactly founded on open source, but it's certainly a big piece of the company and the culture. Why do you think beyond, I guess, the obvious answer, which is what Rails has done for the company, why do you think open source is so important to the company?

I think that's exactly it. We can put out code that is useful to us, that raises the bar, and get people using it, and we get our bug fixes for free and our R&D. It's just a powerful thing to do. I think that should be the primary motivator for anyone who wants to get into open source too. Well, this is the part of the show that we normally ask a couple of closing questions. And since you admit that you haven't caught an episode, we'll catch you blind here. So what is on your open source radar if you have a Saturday afternoon and you're just hacking for the pure joy of it,

although it sounds like you do a lot of that at your day job? What's got you excited that you just can't wait to play with? Oh, man. I'm going to sound like an idiot if I, if I answer this honestly, because I, I've pretty much just been focused on my own stuff. And that's perfectly fine. A lot of folks have said that. Yeah. Um, which of your projects are you looking to, um, show the most love? I definitely want to get Sprockets out. The 2.0

final release. And then I would like to give PAL a little bit of love and then hopefully start on Synco. If you had to, I guess, look back at your – how old are you, by the way? Just curious. I'm 27. 27. Okay.

So you're almost when I was aged. I'm 32. When you're what? 41? 45. If you had to look back on your history of being a programmer or working at 37 Signals, Who do you look to as a hero in your world? Who do you look up to? Who do you aspire to be more like?

Who would you even like to pair a program with? So David Heinemeyer Hansen was extremely influential in getting me interested in actually contributing to open source projects. So I have him to thank for that in the early days of Rails. I've done a lot of work with Josh Peek, who is an amazing programmer, and I feel like we think the same way about a lot of problems. He's been very fun to work with.

And Jeremy Ashkenaz is who I consider to be the model open source programmer. He's been very influential for me lately. If you follow any of his projects and you read the bug tracker, you can see how clearly and concisely and definitively he makes decisions. And it's something you don't always see in the open source world, but it's very refreshing. And I hope to one day manage my projects as well as he does. So DHH, who was the second one? Josh Peek. Josh Peek.

So the two of your heroes are fellow co-workers. That's correct. I don't work with Josh anymore, but we worked together for a time. That's got to be kind of fun. I mean, it's not a dream, though, to work with whom or have worked with whom you look up to. And I mean, that's the whole point anyway, is success breeds success. Absolutely. You mentioned Jeremy. I'm convinced that he's a Cylon. Absolutely. assume, pardon me, you just assume that he's going to be holed up in a cave somewhere to turn up as much software, much less, you know, open source software. But, you know, he's very approachable. And you ask him a question in IRC and he's instantaneous. I feel like he may be operating at a higher plane of existence.

That's true. Well, thanks, Sam, so much. A little technical hiccups. Hopefully they'll come through editing okay. But so glad you joined us to talk about POW and prototype and sprockets and rails three, one and the whole lineup. Well, thank you guys so much for having me.