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

Assuming the Bugs

Writing code is all about making assumptions. Sometimes those assumptions are explicit, but more often we make those assumptions implicitly. We make assumptions about what kinds of parameters we will receive. We make assumptions about what kinds of values methods and functions will return. We make assumptions about the global state. The correctness of our code relies on the correctness of these assumptions. Bad assumptions can wreck our applicatons. We assumed that method never returns null, but turns out it does. Now we have an unexpected NullPointerException crashing through our stack. We assume that we will always average at least one element. Turns out someone wants to average zero elements. Boom, division by zero, ArithmeticException . We make so many assumptions through our codebases, at least a few are going to be wrong. Really, there are many, many assumptions that are wrong. These are bugs. These bad assumptions are all of our bugs. Usually, our assumptions are i...
Read more

Assuming Debugging

Bugs are bad assumptions . Debugging is the process of testing our assumptions until we discover the invalid one(s). Once found, we can then correct those bad assumptions. The following code generates blog post author statistics for a popular blog site. The statistics show which days of the week authors are making posts. Most of the authors post every day, and extra on Fridays and Saturdays to capture the weekend audience. It has at least one bug. @GET @Path("/authors/{email}/weekly-stats") public UserWeeklyStats calculateWeeklyStats(@PathParam("email") final String email) { final User user = this.userService.byEmail(email); final Map<LocalDate, List<Post>> postsByDate = this.postService.thisWeekGroupedByDateFor(user.id()); if (postsByDate.isEmpty()) { return null; } final Map<DayOfWeek, List<Post>> postsByDayOfWeek = new HashMap<>(); postsByDate.forEach((date, post) -> post...
Read more