1. On Railcar: an isolated Rails environment

    Ever since launching Railcar, I’ve been getting a lot of questions about why I’m building it, how I’m approaching things, how people can help, and so on, so I thought I’d take a few minutes and share some things with you.

    Why?

    The main reason is that the Kickstarter pointed to a real need that I didn’t realize still existed. I’ve become so separated from what it means to be “new to Rails” that I didn’t realize it was still a problem to get a Rails setup going on your machine, but thinking back on it, it was and still is a bit of a nutty process. It’s not just the installation of stuff, but the whole environment around the application. How do you start it up? Why can’t I just stick it in my Apache root and let it go? Why do I have to configure a database file? Migrations? What is all this? I forgot how much cognitive friction really exists there that things like Locomotive removed when I was first starting out. I had some spare time, experience building desktop apps, and some ideas about how it should work, so why not hack on something?

    Now, as I’ve learned more about Tokaido’s approach, I’m really glad that I started building something else. Statically linking everything is good for the tools to get started (for example, we’re going to make it such that you don’t have to compile anything to get started with Rails and SQLite), but offering everything statically linked is just going make things difficult. There’s a reason that Apple doesn’t like you to statically link things on OS X (go ahead, try it; there’s no crt0.o for a reason). You can find their reasoning through a quick Googling (unfortunately, the original page explaining it appears to be gone now), but essentially they force you to dynamically link to the system libraries and kernel (even in static mode). Their position is that purely static linking is a Bad Thing because things can change and break under your code (e.g., moving a piece of functionality from the Mach kernel to userland). Plus, if part of the reason you don’t want people to have to compile things is the file size of the GCC package, you’re not going to help that with statically linking everything. Locomotive was about 100MB, and I think that’s probably the absolute minimum file size you’ll be able to pull off if you go that route. Why not have them download ~150MB and be able to install anything they want?

    Which leads to my second issue: discouraging people from using the tools they will be using in the “Real World” is a bad thing. Yes, it’s great to have a one click thing that you can develop in and really learn with, but your team will not work that way. No matter how good you make it, I seriously doubt that experienced developers will use a GUI tool for something that can live and work better with a CLI. Rails developers use homebrew. Rails developers use compilers. Rails developers encounter problems with installing gems sometimes. After a certain point (i.e., once they move beyond their first few learning apps), attempting to hide these details from people learning isn’t helping them learn. This issue is especially controlled thanks to homebrew and their extensive list of patches and OS X-specific fixes for many libraries. And these are not problems you will solve, unless you think you’re more talented than the thousands of developers from the past 20+ years who have attempted to solve it in every programming language ever used in a *nix environment.

    Look, I don’t think what Yehuda’s doing is wrong or that Yehuda is wrong. That’s not what this is about. I see this as the exact same situation as bundler/isolate, Merb/Rails, Sinatra/Ramaze, whatever/whatever else. There are alternative ways to approach the same problem. My philosophy is that I want people to use Railcar until it doesn’t work for them anymore, at which point they can click the forthcoming “install to system” button and go about their merry way. His approach is probably different.We appear to be taking two valid approaches, and I’m sure different people will gravitate to one or the other. That’s fine.

    What?

    So, what am I doing exactly? Currently, I have a usable isolated app environment living in the repository. It’s written in MacRuby using XCode and Interface Builder (I don’t have any interest in using HotCocoa because I like pretty interfaces and it’s incredibly hard to build those in HotCocoa). On the first run, it will install Homebrew, RbEnv (Why RbEnv? I could quickly figure out how it worked and its flexibility will make it easier to drop binary installs in. I’m not opposed to using RVM at all, but RbEnv was just easier to figure out and easier to hook with my code. Patches accepted :)), Ruby, and some default packages.

    Railcar

    Once it’s bootstrapped, you can install popular packages in Homebrew, install various Ruby versions, generate (or drag in existing) applications and launch them with various options. It’s a little rough, some things aren’t quite wired up, but it’s definitely a good MVP build right now I think.

    Railcar

    Currently everything builds from source, but I’m working on a setup for binary installations for Ruby and SQLite. I’m also setting up (later today, hopefully) a repository for a very, very small collection of statically compiled gems for SQLite, RMagick, and a few others. Basically, I want to put the most popular gems in there so that in their initial learning, there won’t be a ton of issues. I’m also going to invest some time (or invest some money in having someone else) in converting a few gems to rake-compiler to make a lot of things with respect to compilation that much easier.

    Railcar

    Once the binary installs are in place, I want to polish up the whole UI, put some nice icons in (those are in the works!), and get it really released as a product unto its own. Then, I want to get to work on an educational piece that will either be part of the Railcar app itself or a separate application. Basically, I want to make the documentation accessible, provide a number good on boarding tutorials, help with common errors, offer a “help search” that will search the mailing list, Stack Overflow, etc. to help find the best answer, and so on. I haven’t decided the best place for that; I’m gravitating towards a second app so that you don’t have to use Railcar, but we’ll see.

    How can I get involved?

    You can contribute code, for sure! I’m going to work on adding some tickets to Github today for some things that need to be done, but you’ll find a few TODO: type things sprinkled throughout the code. There are also a few rough areas that I’d like to smooth out that don’t really conform 100% to the Cocoa way of doing things (e.g., I should be binding the per-application settings using Core Data probably), but those issues are minor. Feel free to refactor/add/improve anything that you see. I know MacRuby pretty well, but I’m not the most expertest expert. I know some people were saying things like ARC were creating issues for them, so if I have a weird build setting in XCode, please feel free to correct it and send me a pull request. Oh, and tests. We need some of those.

    Secondly, if you’d like (and don’t feel compelled at all), you can contribute monetarily. While everyone likes money (and it would be amazing to get a little boost around tax season), I don’t really care about it, I’m not “seeking” it, I don’t need it to keep working on the project, but I’ve gotten a number of requests for a PayPal button or whatever, so here you go:

    Depending on the amount I gather, I plan on investing part of the money back into paying others to improve things like rake-compiler, Rails documentation, and so on. I’ll send you a sticker for contributing if you don’t mind providing your address on the page after you finish with PayPal. Please pardon the payment going to my business’s PayPal account. My wife uses my “main” PayPal account extensively for her business, and I don’t want to risk PayPal freaking out and locking it up. If you’d prefer not to use PayPal, I can figure out something else if you’ll e-mail me.

    Where do we go from here?

    Well, I’m going to keep hacking. Getting people to help finish up a few loose ends would be great so we can get it into the hands of people to use. Anything you can do to contribute to that (even filing a Github ticket with a great idea), would be really helpful. I’m available via e-mail or Twitter if you wan to chat about any ideas/issues you can foresee.

    Comments

Powered by Tumblr; designed by Adam Lloyd.