Starting Rails

So far, it’s been a pretty uneven go. Multiple times a day I’ve experienced (a) “a-ha!” moments in which something has become clear to me in a flash and after which I could no longer imagine not knowing what I came to know, and (b) moments in which I’ve felt like the whole enterprise of learning programming is simply beyond my ken.

A few days ago, for example, I think I finally came to understand routing, which is notoriously tricky and, I can only presume, an initial stumbling block for many learning Rails. This demanded of me several hours of agony, a multitude of “ConnectionNotEstablished” messages in my browser, and a few not-so-small doses of my self-respect. But overcoming this hurdle made it feel like the heavens were once again opening up and like anything is possible.

My next step will be learning how to use Rails in conjunction with databases to such an extent that I can begin actually doing more meaningful things with Rails. Linking and routing between pages that are essentially just HTML isn’t quite as exciting as it was on the first day. This already seems like orders of magnitude more difficult than routing, which is analogous to setting up a telephone operator. Connecting to a database already strikes me as a far more delicate matter, and probably far more tortuous in implementation. Wish me luck.

But in spite of really enjoying Rails so far—the aforementioned pesky roadblocks notwithstanding—I’m already confronting a temptation that I can only imagine is common to all developers: the temptation to explore or even (*gasp*) switch to other platforms without mastering the one you’re already working with. This is a temptation that has demanded a bit of self-reflection on my part.

Enter Sinatra

Last week, one of AppFog’s many ninjas-in-residence advised me to switch to Sinatra (another Ruby-based development platform) in response to a Twitter gripe of mine about my “Rails-related failure” (my words, not his!). Being the incorrigible completist and dabbler that I am, I immediately began checking out Sinatra.

The first thing that struck me about it is its simplicity. An über-simple Sinatra app could consist of one Ruby file, including views. All you have to do is type in an ominous __END__ once your routes and models are in place and begin doing layouts, be they in haml or erb or what-have-you. Here’s an example a simple but functional Sinatra app, consisting of the single Ruby file app.rb:

require 'rubygems'
require 'sinatra'
require 'haml'

get '/' do
  @title = "Main Page"
  haml :index
end

__END__

@@index
!!!
%html
  %head
    %title= @title
  %body
    %h1
      Welcome to the Main Page!

Go to the terminal, open up the directory in which app.rb is housed, and type ruby app.rb. This will get the app up and running on your local host (port 4567 is the default), and you’ll see the basic rendered index HTML file shown directly above. Now, this app isn’t exactly going to set the world on fire. But it serves to make one thing immediately clear: making a Rails app with this little functionality would necessarily involve a whole host of files and folders. 18 lines of code in one Ruby file? Forget it.

Rails is designed to allow you to hit the ground running, and it accomplishes that with aplomb (once some initial hurdles are cleared). But Sinatra has you hitting the ground practically blazing.

At the moment, I’m not sure how scalable Sinatra ultimately is, and time will tell where I ultimately stand on that. There are already a variety of deeply divergent opinions circulating out there, and I’m curious to see how the framework develops over time. But if you’re a Rubyist and wary of this or that element of Rails (such as the opinionated MVC architecture specific to it) or if you have a simple project that doesn’t require loads of complex functionality, then give Sinatra a shot. Check it out on PeepCode or via a free tutorial like this one.

My more general advice to up-and-coming developers is to do one of two things when faced with the temptation to stray from the framework you’re learning. The preferred option is make a list of things to explore at a future date when things “slow down” or you have some “free time” (whenever that is or whatever that even means). The second–and highly deprecated–option is to spend just enough time exploring something to satiate your curiosity, and then ditch it immediately.

If people you trust and respect are telling you to try something out, don’t shut out their influence. But so far, all signs nonetheless point to one conclusion: consistently giving in to the temptation to dabble will mean that you could end up spinning your wheels in perpetuity and never reaching true mastery of much of anything. This is the fate of the dilettante, and it is a well-trodden one…

One of the best things about learning Rails has been the community. It’s amazing to see how many great tutorials and guides and forms of documentation have been created out there for beginners, even absolute beginners (as I very, very recently was).

The guides section of the Ruby on Rails website itself was, of course, very helpful in walking me step by step through installing rails and walking me through the various files and folders associated with the directory of any Rails app. I highly recommend it. And this video from Jeffrey Way is the best resource I’ve found so far for making the jump from just feeling your way around Rails into actually doing something with it (a chasm that I’m hoping to cross very soon).

But the very best thing that I’ve found so far, which will be useful for both beginners and those entering a more intermediate phase, is Michael Hartl’s tutorial on railstutorial.org. What makes this tutorial stand out for me is its thoroughness. Plenty of tutorials walk you through step by step, but Hartl’s tutorial deals with a variety of crucial issues from the very get-go, including writing your own tests and specs to a discussion of which elements of Ruby are most important to learn to using the Rails console.

An issue like testing is indeed dealt with on the official Ruby on Rails page, to give one example, but Hartl’s tutorial has you writing tests from the very start, and doesn’t let you proceed until you can write proper tests that actually pass. This strikes me as an essential skill and a habit that might save you hours of consternation and late-night keyboard-bashing down the road.

There are many others and I encourage you to do some exploring on your own. There are even detailed lists of Rails resources. As I said before: when you work with Rails, you never walk alone.

Now, raphael.js seems like something that many of us could live without. But it also strikes me as perfect if you’re working on a project that needs just a tiny bit of extra aesthetic pizzazz beyond what’s available in CSS, jQuery,et al. Even better, it’s an absolute breeze if you feel even remotely comfortable in JavaScript. To give one very basic example: you can use just one instance of JavaScript’s “for” function (typically used for iteration) to produce 30 circles with circumferences varying according to an equation (for example, making concentric circles separated by 5 pixels). The following code will get you 30 such circles emanating out from the center of a 500×500 pixel canvas:

for ( i = 0; i < 30; i++) {
var x = 0;
var circle = ( 250, 250, 0+5x );
};

That’s it. Four lines. But this tool isn’t just about pizzazz. Things like this strike me as downright useful. And there are plenty of tutorials like this one to help ease you into using it and expand your capabilities.

Though I haven’t yet delved too deeply into JavaScript’s many uses (as I’ve been focusing on Ruby), I’ve been impressed by its versatility. In the coming weeks, I’ll be talking about other .js libraries as I discover them. Recommendations welcome!

This is an agonizing decision because it will also dictate what language you end up focusing on, what platform-associated things you end up learning to use (such as editing programs or databases), and even what programming community you end up (tacitly) joining! Obviously, your decision is never final. You can always abandon a platform and get started doing something else. But that would be, to put it mildly, an inefficient use of your time. Better to give the initial decision its proper weight.

I’ve decided to begin my life as a developer using Ruby on Rails. I have to say, I feel good about this decision.

I’ve been criticized by some (even friends!) for choosing Rails. They somehow think that I’m choosing it because it’s “trendy,” presumably due to its currently strong standing amongst start-ups and its widely touted ease of entry. Even worse, Rails developers have been described in some quarters as smug (or worse). But let’s be honest here. It’s now 2012, and if Rails is indeed still somewhere on the Trend-o-Meter, it certainly occupies a place below node.js and perhaps even a few others in the web-dev world.

Second of all, major sites like hulu and Groupon were built in Rails, which shows that it’s widely used beyond the context of tiny start-ups (here are some others). And so if you’re an up-and-coming developer interested in learning Rails, or even a seasoned one thinking about switching or exploring, I say ignore the very unhelpful trendiness issue and judge for yourself. Here are some of the things that drove my decision:

1. For many, it’s a factum inconcussum that Ruby on Rails is “easy” and “user-friendly” and even “fun.” Let me assure you: as an absolute beginner, it has so far been none of these things. It is easy to use only against the backdrop of the other platforms out there (for example Java-based platforms). It may be easier, but there’s still a pretty steep learning curve, meaning that I won’t be making it overly easy on myself.

2. What drew me to Ruby as a language was actually not the so-called “philosophy of Ruby” espoused by its founder, the eminently likable Matz. I’m a bit too much of a masochist and perfectionist to be drawn to something simply because it’s pleasant. Nor did this sway my decision, although I do find it quite entertaining. Instead, I’m drawn to Ruby (and Rails by extension) largely because of the community surrounding it. The Python community, to give one poignant example, is also wonderful. Maybe as great as or even better than the Ruby community. But the world of Ruby has settled on Rails as a platform in large numbers while an analogous consensus doesn’t seem to exist in the Python community, which is split between users of Django, Pylons, Tornado, Flask, and others. For a beginning developer, that profusion of options can make your head spin. Time will tell if I continue to find it beneficial to have the vast bulk of the Ruby community rallying behind Rails.

3. The beginner-oriented documentation on the Ruby on Rails official page is excellent. The guides section of the page is actually helpful and really does walk you through step-by-step, telling you where to look for things, what specific files and lines of code actually do, things to look out for, etc. I’ll post more about Rails guides soon, as there are many highly useful ones.

4. I’m surrounded by Ruby people. Essentially all of the developers sitting in the next room have Ruby backgrounds that extend from “strong” to “face-melting.” Furthermore, a lot of PHP Fog and AppFog architecture is actually written in Ruby (although in the Sinatra platform, which I’ll discuss soon, rather than Rails). To top it all off, our CEO Lucas Carlson wrote a popular book on Ruby and has contributed to the Ruby gem library pretty extensively. In the past week, he’s already given me some sage advice on how to hit the ground running.

My impressions thus far: after a few days of initial orientation, what I’ve found with Ruby on Rails is that it’s not “easy” the way that Adobe Photoshop or Skype or Excel are easy. There’s no point-and-click interface that’s going to magically and inexplicably do it all for you. But it is indeed “easy” in the sense that you always have the sense that somebody somewhere has got your back and has done a lot of thinking for you and gone out of their way to help eliminate the hassles and frustrations that you will invariably face.

That’s a kind of easy that I’ll take any day.

One of the wonderful things that I’ve discovered while learning programming is that there are so many people out there who (a) are just like you, and (b) have been in your position and love programming so much that they want to extend their knowledge to you. Case in point: the vast, ever-expanding world of programming tutorials.

What’s cool about this world we live in is that there are lots of really good free tutorials. Recently, I’ve given shout-outs to hyper-polyglot Bucky from The New Boston in particular, but there are others like him. What’s not quite as cool about the world of tutorials is that there are piles of mounds of pantloads of really mediocre tutorials that turn out to be a waste of time. I won’t name any names.

And then there are tutorials that are so well produced and so helpful that they strike me as being well worth paying for. PeepCode is the best example of this that I’ve found thus far. The tutorials on Rails and jQuery have been both incredibly helpful and quite aesthetically pleasing, to name only two of the dozens of tutorials available. This is in addition to absolute gems like this video, which gives you an inside look at things from the user interface perspective.

If you’re a beginning developer like me, or even more advanced and looking for a well-structured introduction to something new to you (maybe node or Clojure or CoffeeScript or backbone.js), I would strongly urge you to watch some of the sample videos on the site and consider signing up.

Oh… I’ve also heard good things about treehouse but have yet to try them out.

Free tutorials are great, but all too often they come with the hidden cost of the many hours that are eaten up either finding them or sitting through them only to realize that they weren’t all that helpful. Believe me, I’ve spent countless hours trolling around the internet looking for good tutorials, and PeepCode is really the cream of the crop. If there is something that’s just as good (or better), please let me know in the comments, Dear Reader.

The problem? I had never become even remotely comfortable operating in shell environments. I was never forced to operate in these environments because I was (un?)fortunate enough to come of age after the point-and-click-GUI revolution of the 1980s. It also doesn’t help that the white-text-on-black-background aesthetic of command line interfaces (CLIs) always made them seem like a kind of curious relic from a primitive, benighted, and thoroughly superseded era of computing.

But it turns out that I was incredibly misguided in my neglect of the shell environment for two reasons. First, because familiarity with shell environments is absolutely indispensable in carrying out a wide range of tasks as a developer. In just my first week as a would-be developer, I was forced to work in the shell in doing all of the following: interacting directly with MySQL databases, working with the SASS-to-CSS converter (a very nifty tool), using my first package manager (the highly recommended Homebrew), and also installing and working with Ruby on Rails (as well as toying with Django, though making little progress with it).

The documentation for all of the above, even when aimed at “beginners,” simply assumed that I would know what to do when given a piece of text saying “sudo something-something” or “gem install such-and-such.” I must admit with no small amount of sheepishness that I at first had no idea where I was even supposed to do this. In my browser? In my Windows command prompt? In DOS, of all places? What on Earth is this dollar sign that keeps popping up? And what is bash, beyond an English verb that is weirdly satisfying to say?

This became perhaps the very first pet peeve that I developed while learning web development. Even the most basic tutorials (well, okay, a little more advanced than the oppressively omnipresent “Hello world” tutorials that glut the web to the brim) never actually explained what this CLI business is. I learned very quickly that I needed to have at the very least a rudimentary understanding of the shadowy world of the CLI, in spite of there being little that was less comfortable to me. Even after days of concentrated effort, the blinking cursor against a dark background occasionally made my mouse start looking something like this.**

Fortunately, it turns out that functioning in the shell environment need not be so intimidating at all. It just requires proper introduction and a small bit of devotion. Within a few hours thumbing through a few books and websites, I managed to acquire enough of an understanding of the shell to feel a bit less overwhelmed and perhaps even slightly comfortable in this environment.

I started by cheating and asking some colleagues for pointers. They recommended to me Cameron Newham and Bill Rosenblatt’s Learning the bash Shell (book and PDF), which I found to be highly readable and instantly helpful. After just a few pages, I found myself able to perform some of the basic tasks that we associated with CLIs, like creating and removing directories, wildcards, “touching” files, and piping commands together, like this line that I ran in bash, which enabled me to put the current date and time into a new file called “now” and then place that same information in a separate file called “then:”

$ date < now $$ cat < now > then

Sad as it may sound to more experienced programmers, this constituted a legitimate “a-ha!” moment for me. It made me feel like I could finally begin to play God on my own machine, like I had torn back the veil that had kept me from genuinely interacting with my system. In a future post, I’d even like to tackle writing some of my very own shell scripts. For now, I’d like to offer a bit of advice.

For those of you to whom this post was entirely opaque, I absolutely implore you: sit down and spend a few hours experimenting with shell environments. You will absolutely not regret it, as it will drastically ease your entry into whole worlds of programming and development (particularly if you end up using things like GitHub or cloud platforms like PHPFog and AppFog, which rely heavily on CLIs). I would even advise more advanced programmers and developers to brush up on their knowledge and to check out some of the many shell interfaces available out there, like Zsh, iTerm, and iTerm2 for Mac users, and GNUStep for Windows. Ultimately, it might not be the best use of your time to become an absolute ninja in the shell. But an overall programming ninja afraid of the blinking cursor strikes me as a contradiction in terms.

**I have since overcome this.

I’m Luc Perkins, the newest addition to AppFog. Please let me briefly introduce myself. I was born in Soldotna, Alaska but have called the Portland area my home since I was a kid. I studied political philosophy at Reed College and went on to get a Ph.D in it from Duke, finishing this past December. Toward the end of my studies, I began to feel inexorably drawn to the world of web development in general and to the start-up community in my home city in particular. Two months ago, I bit the bullet and dove head-long into programming, hitting every YouTube tutorial that seemed useful (shout out to Bucky from The New Boston in particular), slowly inching through the JavaScript tutorials on CodeAcademy, and even doing it the old-fashioned way and checking out books on PHP and Python from my old alma mater’s library. So far, I’ve mostly accumulated smatterings of knowledge about lots of things (especially acronyms…do you ever stop learning acronyms?!). But suffice it to say that I’m hooked, on the unbelievably broad and active peer communities associated with every language and platform, on the pace of change in the world of development, and on the incredibly inspiring creativity and camaraderie that I see on display everywhere, from start-ups to blogs to the Ruby gem library to the brilliant programmers sitting right across from me.

For all these reasons, I’m absolutely thrilled to be brought on board to occupy the position of Developer Evangelist at AppFog. True, my background in computing is, in a word, limited. While I consider myself generally tech-savvy and have never encountered any serious difficulty doing many of the things that citizens of the 21st century do online, from social media to basic web design, I come to the world of programming and development with both a mountain of curiosity and a limited skill and knowledge set driving me. This space will be devoted to—pardon the kitsch—telling my story, the story of my evolution from a beginner struggling to understand things as simple as the ins and outs of PHP, MySQL, and other languages, to someone who will eventually be able to put AppFog to fruitful use and worthy of the title “Developer.”

Along the way, I will share my impressions of and experiences with existing programs, languages, and platforms, offer advice to up-and-coming developers on the many pitfalls that may confront them in the course of their own development, and attempt to contend with the steady flow of subtle and sometimes not-so-subtle transformations constantly going on within the brave new world of cloud computing. It’s going to be an uneven but exhilarating ride, and I look forward to sharing the journey with you, Dear Reader.

We’re incredibly flattered by the nomination – especially given the amazing bunch of companies that we’re nominated with. From partners of ours like MongoLab and Iron.io to fellow PDX startups like Puppet Labs – the list is extraordinary and we are honored to be part of it.

We’re especially excited to see how many of the startups are Cloud Tech and PaaS. It’s awesome to be part of the new hotness.

All that said… we’re here to win this thing. And we want you to vote for us.

Especially now that we’ve got a little side bet running with our buddies at Cloudability. As a fellow PDX startup and a partner of ours – we’re big fans of Cloudability. But we still want to kick their butts – especially because we want to win the bet (and get the case of Terminal Gravity IPA that’s at the end of this particular rainbow.

So please… if not for us do it for the hops (and the kittehs)… vote for us!

We believe our inclusion in this report is largely based on AppFog making a difference in the developer community by making things easier for you, and we pledge to continue to keep working to provide the highest quality products for you, our customers, and evolve to meet your changing needs.

So please keep telling us what you think about us, the products and the company. Because we do this for developers like you. But at the same time… thanks Gartner! We think you’re pretty cool too.

As we build up a library of these cool hacks and the like, we’ll keep sharing – so consider this the first in a series.

We need you! Want to become an AppFog Fellow? If you have any helpful ideas that have made your life easier – please let us know and we’ll add them to the library! What do you get in return? Free service! Credit will be applied to your account as an AppFog Fellow. AppFog Senior Fellows have been an AppFog Fellow for over a year. They get even more goodies and swag!

Sandbox distractions.

AppFog Senior Fellow Matthew Lyon:

I check email from the computer once a day — before I start coding. Delete / Archive / Respond to things as necessary but get them out of email. Then quit the email client. I’ll check it during the day but only from my iOS devices, and then if I need to respond right away from the computer fire it up again. Twitter, Facebook, Reddit etc have been relegated to my iOS devices, even from my personal computer. Hacker News has been “blackholed” in /etc/hosts. I’d suggest considering doing that with Facebook etc as well if you have a hard time being disciplined. If I see something I want to “read later” on twitter I star it, and the revisit those later when I’m in “reading stuff” mode.

Manage SSH credentials intelligently.

AppFog Fellow Steve Ho:

When working with GitHub and AWS and the like, add credentials to keychains with ssh-add /path/to/key. Do this the same way every time to avoid errors and issues and to be efficient.

Express ideas concretely whenever possible.

AppFog Senior Fellow Matthew Lyon:

I use whiteboards, notebooks, mockups, flowcharts, lists and state diagrams to figure out what I’m supposed to build before I start, and I encourage and help others do the same. Expressing requirements concretely as something you can look like makes it easier to talk about the particulars and the end goals rather than expressing it verbally where you have to hold everything in your head and it’s easier to talk about theoretical what-ifs.

Become a keyboard shortcuts ninja.

AppFog Fellow Tim Rosenblatt:

One of the more obvious ways to become more productive (or more efficient + effective) at work is to not have your hands leave the keyboard. The most common reason for taking your hands off the keyboard is usually “to use the mouse.” So stop touching your mouse!! Learn, live and love your keyboard shortcuts. You’ll be faster, less easily distracted and as a bonus you’ll be less likely to need to wear wrist braces in the future.

Use paper lists.

AppFog Fellow Larry Hitchon:

Paper lists are good. I use Dropbox for virtually every document I have. I use Github for nearly all my code. I will hardly buy a book anymore if it isn’t available in Kindle format, or at least a PDF. I have access to nearly everything, nearly all of the time. But making a to do list on paper at the start of a day and checking things off is uniquely satisfying. And effective.

Learn to love the Google Chrome Developer Tools.

AppFog Fellow Steve Ho:

While the Firefox and Safari tools are useful and good – Developer Tools in Chrome is not only better but far faster and less of a time-waster.

http://code.google.com/chrome/devtools/docs/overview.html

Also make sure to check out the Chrome extensions

https://chrome.google.com/webstore/category/home?hl=en-US

Work in places where you can safely ignore the surrounding environment.

AppFog Senior Fellow Matthew Lyon:

The lizard brain is constantly looking for things happening around you that may be relevant. In an office that means listening in on co-workers conversations, paying attention to who’s coming in and out, who’s talking behind closed doors, etc. None of that is good for concentration. In a cafe you’ve only got other people you don’t care about, perhaps some screaming kids or angry beatnik. Unless it presents a threat to your safety (as a deranged-looking man in a long coat who walked in and started crying once could have) you can safely ignore it because it has nothing to do with you.

IRC is magic.

AppFog Fellow Todd Sampson:

While there are projects and products and technologies out there where the smart kids behind them do not use IRC, they are rare. If you run into real technical issues that need real-time resolution, IRC is where you should go. Odds are that in the time it takes you to filter through all the linkbait sites that you get from your Google search you’ll have your answer on IRC.

Use Google Public DNS.

AppFog Fellow Joe Chung:

While it might seem like a small price to pay, that slow name resolution from your crappy ISP does start to add up. And then there are propagation worries, and security concerns. You get the idea. It’s free, it’s fast, it’s no bullshit. Get it.

The Google Public DNS IP addresses (IPv4) are as follows:

• 8.8.8.8

• 8.8.4.4

The Google Public DNS IPv6 addresses are as follows:

• 2001:4860:4860::8888

• 2001:4860:4860::8844

GitHub GitHub GitHub.

AppFog Fellow Todd Sampson:

Really… it’s 2012 people. Get on-board. GitHub rocks. The learning curve is quick and easy, and the payback is massive and increases over time. Also use GitHub for project management – even if you don’t have a repo the project management and wiki are great for running any project. Honestly, there is no argument against using this.

Bonus Tip (for entrepreneurs).

AppFog Senior Fellow Lucas Carlson:

In talking with VCs, when you want money – ask them for advice. When you want advice – ask for money.

If you don’t know VCs but still have questions, ask people who have done it before. I’ve raised $10M from VCs for AppFog, feel free to ask me anything you want – lucas@appfog.com