Some Guy on Rails

Since my last post, I've been attempting to extrapolate features taught in the Rails Tutorial into the blog app I built through RailsGuides.

This time around, I've decided to go back and complete all the exercises put forth on the Rails Tutorial. I've had more than my fair share of trouble completing Chapter 3 Exercise 3 which has me migrate my SQLite database to PostgreSQL.

I installed PostgreSQL successfully (I think) from the link provided in the tutorial. I've updated my Gemfile appropriately (I think). I've updated my database.yml file ten ways from Tuesday, however, and am still pretty sure it's wrong.

My database.yml file for your reference:

development:

  adapter: postgresql

  encoding: utf8

  database: blog_development

  pool: 5

  username: brianscottk

  password: <my password>

test:

  adapter: postgresql

  encoding: utf8

  database: blog_test

  pool: 5

  username: brianscottk

  password: <my password>

production:

  encoding: utf8

  database: blog_production

  adapter: postgresql

  pool: 5

  username: brianscottk

  password: <my password>

Every time I try and run rake db:create:all, however, I keep getting the same dang error message that says "Couldn't create database for...<all of the above parameters>.

I've Googled a ton for an answer, but most of the posts like this one don't provide any solutions that work for me. I guess being on Windows instead of Mac is making this more difficult than it could be.

As I mentioned in my last post, I've been working on a blog application as outlined in the Rails Guides.

Upon completion of the guide, I wanted to upload my newly completed work to Github, but when I tried to do so, I received the following error message:

fatal: https://github.com refs not found: did you run git update-server-info on the server?

Googling that error led me to this post on Github, which alerted me that my version of Git was probably outdated and required an upgrade.

I downloaded and installed the latest version (1.8.0), but when I fired up my Rails terminal window, it was still saying that I was running the older version 1.7.9.

I couldn't find a Windows-based solution for this, so I posted a note on trusty, ole Stackoverflow, and determined that instead of upgrading my old version of Git, I simply installed the new version in a different directory. Rails was still detecting the original version and couldn't tell that I had even installed version 1.8.0.

You can check your version of Git by opening up your terminal window, and typing git --version

I just finished Rails Guides: Getting Started with Rails which takes you through building a simple blog application. It's super-fast, and I was able to complete the whole project in just a few hours.

What I like most about it is the sheer simplicity of the project. Unlike Rails Tutorial's "Sample App", Rails Guides's blog app is uber-basic and thus, ripe for upgrades and customization. I feel like much of what I've been learning from Ryan Bates' Railscasts can easily be applied to fleshing out this blog application.

Long story short, it seems like a great place to continue my learning.

That said, it does certainly have it's shortcomings. First and foremost, it does not follow Test-Driven Development. I did not take the initiative to implement testing on my own, but it is simple enough to retro-fit testing into it after completion.

Second, the syntax is slightly outdated, and still leverages the now deprecated "hash rocket" which I reference in my last post. By now, however, I am (and you should be, too!) far enough along in your learning to translate this into the new format.

I mentioned in my last post that Rails for Zombies (RFZ) would be one of my next steps following my completion of the Rails Tutorial.

I had originally checked out RFZ prior to really digging into the Tutorial but bailed on it for a few reasons, the main one being that it was too challenging at that point and that I felt it was preoccupying my time better spent working through the Tutorial itself.

I'm pretty sure I was right.

On this second pass at RFZ, I breezed through it. Leveraging the knowledge gained from the Tutorial, I was able to complete the entire course in about an hour.

I can't say that I completed it without pause and without the need to re-watch some of the course clips, but my overall comprehension of the concepts and general syntax was there. I actually went through the entire course twice yesterday, and with the latter run-through, made sure that I could complete each lesson without referencing any of the video clips.

Upon completion, RFZ rewards you with a $5 discount off of your first paid course or subscription from Code School, the course's creator.

I was about to purchase the $25 monthly subscription (my only option) that provides unlimited access to all of their courses, but I chose not to. My main reason for opting out was that the Rails syntax used in these courses is slightly outdated. RFZ includes heavy use of the "hash rocket" syntax that has been all but completely deprecated as of Ruby version 1.9.

After checking out the "preview clip" of RFZ 2, it seems that it too includes the outdated syntax, so I figured why spend the money on something that might reinforce incorrect knowledge. Granted there are other courses included that are newer and also seem worthwhile, but at this time I'll take a pass.

My next steps will be revisiting the Tutorial exercises that I had initially skipped, before finally trying out the Sample App extensions noted at the end of the Tutorial.

It's been quite a long road since I took my first steps towards "learning to code", but I have finally completed Michael Hartl's Ruby on Rails Tutorial!

I checked my Sample App development.log file and saw that my first app activity began on August, 7th. This means that it took me about three and a half months to work through the Sample App which makes up the bulk of the Tutorial.

As cheesy as it sounds, one of the most important things that I learned along the way is that there is so much more to learn! In many respects, I feel "dumber" now at the end of the tutorial than I did at the beginning when I was just starting out.

Along those lines, I admittedly feared reaching the end of the Tutorial. Great, I built "fake Twitter" with someone holding my hand every step of the way. So what?! Now the training wheels are off, and that scares me.

It took me 3.5 months to build something with world's best Rails cookbook. Now I've got to cook something up from scratch, and it still feels like it's going to be impossible. WTF?!

Now that I'm done freaking out, here's my plan of attack:

Before I dive right into a whole fresh app whose purpose I have yet to pluck from the ether, I'm going to work on a few intermediate steps that I hope will mentally prepare me for Rails without guidance.

Hartl's Chapter Exercises and Extensions to the Sample Application seem like a great place to start. Hartl smartly left a ton of loose ends dangling from the Sample App, which I will attempt to tie up over the next few weeks/months. Hopefully these will get me thinking the right way, without explicitly telling me what to do word for word. Plus, I assume that there must be a ton of posts on this stuff by those who have completed the Tutorial before me.

Rails for Zombies:  Hartl mentions this briefly all the way at the beginning of the Tutorial for those with no programming experience. I did a couple of lessons a few months back, but bailed for the Tutorial itself. RFZ focuses on short video lessons and accompanying code exercises. Since this requires you to actually figure the code out on your own (with a little help) instead of simply providing you with a step-by-step recipe, I feel like this is a good next step.

RailsCasts: I linked to one of these in an earlier blog post. They are awesome, and at the time of this writing there are 393 of them! My goal is to keep on watching them on my spare time, when I am unable to sit on a computer and hack away.

Hopefully as I continue along with all of these, everything will begin to coalesce, and I'll be able to start putting something together from scratch.

I've just successfully completed Rails Tutorial Chapter 10 and now have a working microposts feed in my Sample App. (Yay!)

That said, while working through section 10.3.2, I encountered the following "minor" visual bug that took me forever to resolve:

As you can see, the text box where the user is to enter in the content of their micropost is waaay taller than it's supposed to be:

I immediately assumed that this was some sort of Bootstrap or CSS issue. I attempted to troubleshoot the problem first by checking my "home.html.erb" view file and my corresponding "_micropost_form.html.erb" partial to see if I misused, mis-referenced, or mis-typed a div class or something similar... No dice.

When both of those appeared to be fine, I went back to my "custom.css.scss" file to see if I had incorrectly sized a certain class of text fields. In the /* forms */ section, I began playing around with the code:

input, textarea, select, .uneditable-input {

   border: 1px solid #bbb;

   width: 100%;

   padding: 10px;

   height: auto !important;

   margin-bottom: 15px;

   @include box_sizing;

   }

In adjusting the height: auto to things like height: 50% or height: 150px, I was able to shrink down the height of the field to something a little better, but these changes also affected the remaining text fields throughout the site in unwanted ways.

After giving up, completing the rest of the chapter, and still not having it magically fix itself, I finally reread the part of the tutorial dealing with this CSS snippet. I then noticed a wee little discrepancy between my code and the correct code.

Instead of the code above, this part of the CSS should read:

input, textarea, select, .uneditable-input {

   border: 1px solid #bbb;

   width: 100%;

   padding: 10px;

   height: auto !important;

   margin-bottom: 15px;

   @include box_sizing;

   }

  input {

  height: auto !important;

}

In other words, I had the height specs in that initial .uneditable-input block, when it should have been in its own separate section.

A fascinating, enlightening video from Sandi Metz's GoRuCo 2011 talk on the overarching concepts behind designing your code to best prepare for the uncertainty ahead.

Sandi says that no matter how much you think you know about a project in advance of writing your code, things will undoubtedly change at some point in the future, and as a developer, you must be prepared for that.

She explains that there are two ways to write your code. In the first way, you make educated guesses about how you think that your project will ultimately turn out, which leads to a rigid, codependent program that is tough to change.

The other more elegant option, as preached by Sandi rather eloquently in this 30ish-minute clip, has you assume that you have no idea about how your program will end up, and forces you to be flexible and concise. 

WARNING: If like me, you're only 10 or so chapters into Hartl's Tutorial, much of what's discussed here is probably over your head. That said, by this point in the game, you should have enough foundational knowledge to take something tangible away from this that you can store away for later.

Heck, I'm posting this here right now, so that I can refer back to it later on down the road.

At the end of Chapter 9 of Hartl's Rails Tutorial, he has us deploy our Sample App to Heroku, reset the production database and populate it with sample users via these commands:

$ git push heroku

$ heroku pg:reset <DATABASE>

$ heroku run rake db:migrate

$ heroku run rake db:populate

<DATABASE> is to be replaced by the name of your specific Heroku database, which Hartl explains you can retrieve by running:

$ heroku config | grep POSTGRESQL

But, what Hartl doesn't explain is that the above command outputs a whole mess of crap like this:

HEROKU_POSTGRESQL_<SOME RANDOM COLOR>_URL: postgres://...etc

Of that mess of crap above (which I've truncated for brevity), the name of the database is everything before "_URL".

So for example, your database name might be something like HEROKU_POSTGRESQL_PURPLE.

In that instance you would run the command heroku pg:reset HEROKU_POSTGRESQL_PURPLE to reset your production database.

Upon executing the above command, Heroku will alert you with "! WARNING: Destructive Action..." and will have you confirm that you do, in fact, want to reset the database by manually entering in the name of your app.

It had been far too long smooth-sailing through Hartl's Rails Tutorial without an error or problem. Something was bound to pop up sooner or later. Fortunately the error described below was a cinch to correct.

In section 9.3.2 Hartl has us use the Faker gem to populate our SQLite3 database with sample data for us to mess around with.

To begin, we are instructed to "reset", "populate" and "prepare" the database in that order. The first command we run is bundle exec rake db:reset.

In running that first command, I received the following error in my console:

couldn't drop db/development.sqlite3 : #<Errno::EACCES: Permission denied - c:/sample_app/db/development.sqlite3> db/development.sqlite3 already exists...

Fortunately, the solution really couldn't have been any easier. As per this post on Stackoverflow, all you need to do is completely shutdown your Rails Console and restart it. I actually fully closed out of my two console windows, opened one back up, and it worked perfectly. No need to even reconnect to the Rails Server.

According to the post above on Stackoverflow, this is a Windows-only problem, and shouldn't be an issue if you've been following along with the tutorial on a Mac.

It's been a little while since my last post, and I just finished Chapter 8 of Hartl's Rails Tutorial, so I figured that I'd share a bit.

I decided at the start of this blog that I'd only post things that I discovered outside the scope of the Tutorial. If Hartl explains it well in the Rails Tutorial, there's no real point in me repurposing it here, unless I've got some worthwhile commentary of my own.

If you're just beginning with Rails and you haven't been working through Hartl's Rails Tutorial, stop reading this blog right now, put down your iPhones, and pick up the fcking book. Read it!

My posts here to date have encompassed two main types of posts, and will continue to follow suit until I've completed the Tutorial.

Explanations/Opinions/Advice/Clarifications on those parts of the Tutorial that I've had problems with. I figure that odds are, if I've found a particular part challenging, someone else has as well. Many of my posts are dedicated to tips, tricks and trouble-shooting that I've learned while working through the Tutorial.

Supplemental Learning - I've noted on multiple occasion that my personal strategy for learning Rails, and programming in general, is to bombard myself with as much knowledge as I can from as many angles as possible throughout the learning process. These types of posts are dedicated to some helpful resources that I've discovered along the way.

As I continue on with the remaining chapters of the Tutorial, I'd be happy to dedicate posts to answering any questions that I get from readers, so please don't hesitate to email me with any issues that you're having.

Once I've wrapped up the Tutorial, I'll begin trying to construct my own basic apps. At that time, I'm sure I'll have a bazillion questions and problems of my own, so I will surely be posting more frequently.

I just began Chapter 8 of Hartl's Rails Tutorial which starts off by having you generate a "Sessions" controller using the script rails generate controller Sessions --no-test-framework.

This got me thinking about what would have happened if I had accidentially typed "Session" or "Sesions" instead of "Sessions". Would I have been stuck? Would I have been SOL and forced to roll back to my last saved version on Git? (assuming I even knew how to do that, which I don't :)

Well, fear not. Google and StackOverflow have yielded the answer. If the linked post is a little confusing, allow me to simplify it with one simple command: Run rails destroy controller Sesions --no-test-framework to undo the accidental creation of a misspelled "Sesions" controller.

In other words, swapping the word "generate" with the new word "destroy" undoes the creation of the files and associated code adjustments that resulted.

I'm going to assume that the same type of command swap can be done with other rails generate commands (beyond just those associated with the controller), but I don't know for sure, and have yet to test it out.

Has my above tip worked for any of you? Has anyone successfully destroyed anything other than controllers?

If you are following along with Hartl's Rails Tutorial, you'll come across the "%w" symbol in Chapter 6.2.4 "Format Validation".

In case you were wondering (as I was), what the hell this "somewhat" familiar-looking symbol meant, here's your answer according to The RoR Notebook:

Just wrapped up Chapter 5 of Hartl's Rails Tutorial, and my "Sample App" is well underway.

That aside, throughout the process, I've obviously already begun to encounter bugs in my code. It amazes me how replacing a seemingly benign "," with a "." can cause your whole application to fail. Crazy!

Sometimes, of course, it's tough to know where to start trying to find the "." needle in your code haystack.

I've been watching some of Ryan Bates' Railscasts screencasts and stumbled upon this one which has already helped point me in the right direction.

If you haven't checked out Railscasts, you probably should as they are praised by everyone in the industry. While many of the topics are likely to be slightly above your head at this point, others like the one here apply even this early on the Rails learning path. Even the complex ones are explained in such a simplistic way, that I didn't even feel all that lost taking them in.

Rob K. has also been following along with Hartl's Rails Tutorial and wrote in with some issues that he had been having opening files in Sublime Text 2 from the command line.

I'm glad that he had this problem, because I had been meaning to address this when I came across this point myself, but forgot.

Rob and I have both setup our Rails development environments on Windows and have been working primarily with Windows for the Tutorial.

If you, too, are on Windows, this video by Pressed Web will get you setup opening files with Sublime Text 2 from the command line in just a couple of minutes.

NOTE: The video has you use "ST2" as the command line code, while Hartl uses "SUBL". I reccommend Hartl's way, if you're following along with the Tutorial to help avoid confusion. Both options work the same.

If you're on a Mac, I can't say for sure, but Hartl addresses the issue here. I am under the impression, that you just need to follow these basic steps:

Type echo $PATH  from your command line to see if you already have a /bin directory in your path.

If yes, run the line ln -s "/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl" ~/bin/subl

If no, run the line sudo ln -s "/Applications/Sublime Text 2.app/Contents/SharedSupport/bin/subl" /usr/bin/subl from your command prompt.