Learning Rails (So Far)

I've started learning how to use Ruby on Rails for development. I've touched on using Rails before, but I didn't get very far. I'm using the Ruby on Rails Tutorial book as my guide. I'm using the second edition (because I bought it a little while ago), and it is based on Rails 3. Now that Rails 4 is out, doing a gem install rails pulls down that latest version, Rails 4. I could specify a version, but from what I read, the differences between 3 and 4 are fairly minimal for the scope I am dealing with.

I ran through the first demo, which is basically installing and running Rails, both locally and on a remote host. This was fairly straightforward on the local side:

gem install rails
rails new first_app && cd first_app
rails server

The book recommends using Heroku as a remote deploy target, but I already have a web server (on a shared host) that supports Rails, so I wanted to use that again. The shared host provides a simple GUI through cPanel to create Rails instances, so I figured I'd use that, then sync down. The GUI provides an installation of Rails 3, around 3.2. OK, that's fine as it matches better with the book. I made the minor tweaks required to get it totally running, and it worked. First app (essentially) done. Yay!

The next app was a demonstration of using Rails scaffolding. I used git to track developing this, as is recommended by the book and best practice. I created the repo on the remote first, and added everything there, then cloned everything down. I did this so that there is a series of commits for the base setup, then a separate branch off for the scaffolding exercises. I did this so I could branch off of master later without having to make the changes for the host again. Then I did the scaffolding exercises. So far so good!

Then I realized I missed something in one of the commits in master. Things went downhill quickly. I tried to amend that commit, then rebase the tree on the amended commit. I lost parts of the commit and somehow the whole repo just went sideways. Apparently, by force-moving master, you can cause a branch to lose it's parent in master? Yeah, that kind of sideways. The next day, I realize I should have just done an interactive rebase and edit the commit, but that idea just didn't strike me at the time. Fortunately, that exercise was fairly simple and self-contained, so I didn't worry too much.

Now that the local and remote repos were both sideways, I decided to flush both and start over. Rather than going through that fancy GUI on the remote, I figured a simple rails new . on the remote would be sufficient. I learned two things: first, the latest Rails is installed on the server, even though the fancy GUI doesn't use it; second, in the one day between when I installed Rails on my local machine and when I tried to install it on the remote, Rails had upgraded from 4.2.1 to 4.2.2. This meant a number of the dependencies also got updated. On the remote, the web host had already handled this, but I needed to take care of this on my local machine. OK, gem update: Error. Shoot. Of course, it's one of the native extensions that can't compile. Eventually, I reached the point where I just uninstalled, then reinstalled all of the gems on the system. It worked, so done. Why didn't it work before? Umm...?

Now I have the rest of the book to go. It will be based on one example program for the remainder, an app not dissimilar from Twitter. Hopefully no more crazy git/gem shenanigans.

Comments

Post a Comment

Popular posts from this blog

The Timeline of Errors

Image
As software developers, we see errors every day. They manifest as exceptions or segfaults or error codes, telling us that our code has gotten into a state we didn't expect. Their appearance often portends bugs. Though we groan at an unexpected stack trace, we should see an error as a form of automated feedback . Feedback can be fast or slow. We can put the discovery of errors onto a timeline. Errors appear at many points over the lifetime of the code, starting at the moment it is compiled. The further to the right that an error appears, the longer it takes for the feedback to appear. Compile time Compile time is the earliest we can receive feedback about an error. The compiler automatically does a number of checks to make sure the code makes some semblance of sense. The most powerful tool for compile-time feedback is the type-checker. The type-checker makes sure that only values of the expected type are passed around to the places that expect them. This guards
Read more

Magic Numbers, Semantics, and Compiler Errors

Image
Magic numbers are considered such a scourge upon code bases that there tools out there to automatically find them and root them out. After all, who knows what setValue(6); really means? There are also many approaches to giving better names to magic numbers. Not all of them are good, though. For example, we have a callback that sets a completion percentage on a status: void callback(Status status) { status.updateProgress(0, "Starting"); // Do some stuff... status.updateProgress(25, "Some stuff done"); // Do some more stuff status.updateProgress(50, "More stuff done"); // Reticulating splines status.updateProgress(75, "Splines reticulated"); // Validate everything status.updateProgress(100, "Complete"); } Those percentages would get flagged as magic numbers by the automatic tools. The developer would need to extract those out to constants to make that tool happy. A thoughtful developer would create
Read more

The Cone of Code Uncertainty

Image
As hurricanes approach the shores of North America, we are barraged with maps of possible tracks those storms can take. Those tracks start pretty close together, but diverge widely the further into the future they predict. Simplified, those storm tracks form a cone of uncertainty . A storm in the Atlantic could slide into the Gulf of Mexico and land anywhere from the Texas-Mexico border to Panama City Beach, FL. It all depends on a myriad of tiny factors to turn the storm this way or that. As time progresses, the storm moves along, and the cone of uncertainty shrinks. Its eventual location becomes clearer to predict, and we can more effectively target resources. Cone of Uncertainty for Hurricane Ike, source Much like hurricanes, running code lives in a cone of uncertainty. A function or method call is a mysterious black box until we have a result. If something goes wrong, we must delve into this cone of code uncertainty to find the problem. We use log statements and de
Read more