Punctuation

The one thing that has always made my head spin when it comes to programming is the syntax. Whenever I see something like “thing.new()” I immediately wave the white flag and go back to my safe little html world where everything is in simple tags and it all makes sense. To be honest, dots and parentheses scare me. While reading Build Your Own Ruby On Rails Web Applications (from now on… that will be known as BYORORWA) for the first time, I glossed over this information. I read it, I understood it, but I just as quickly forgot it. Only now, on my second pass through the chapter, am I truly starting to understand what it means. Below are my notes on notation:

Dot Notation – The dot (or period) is used to separate the objects from the methods… or to separate the receivers from the messages.

(I’ll fill in an example later)

Parentheses – These are used to pass arguments to methods. They are optional in cases where no arguments are being passed.

(I’ll fill in an example later)

This is a pretty bare bones attempt at explaining notation in Ruby, but since these two things have often been the bugbear of my learning experience, I thought it wise to pull them out give them their due.

A Wise Man Named Seinfeld Once Said…

I’m a big fan of online productivity tools. Over the past year, I’ve used probably half a dozen different sites (not including calendar applications) to try to keep myself in order. There are things that I’ve liked about all of them, but there was always at least one thing that just didn’t work for me. Finally I landed on Todoist and I haven’t looked back since. On a recent Todoist blog post, I noticed that they had implemented something that was inspired by the “Jerry Seinfeld’s productivity secret.” Color me intrigued. I wanted to learn more so I clicked on the link, and sure enough there was a very intelligent, easy to use system for keeping yourself motivated to continue tasks over a long period of time.

I, of course, want to implement this for my project (learning Ruby on Rails). I’m not much of a paper and pen type of person. I prefer to give and receive my info in a digital format… so imagine how excited I was when I found THIS! While I love the Todoist… for some reason, their implementation of this concept (though not radically different from the smarterfitter site) just didn’t speak to me the way this one does. It’s beauty is it’s simplicity. I hope I continue to use it… if not, I might have to get a “real” calendar. Yuck.

Back to Basics

Last week I mentioned that I might take a step back to relearn the MVC architecture. Instead I decided to take two steps back. I realized that part of my confusion was more basic than MVC—it’s that I don’t have a strong command over the concept of object oriented programming. I usually understand OOP while reading about it, but I over time I forget the terminology, and sometimes the concepts get a little fuzzy in my brain. Since I’m right at the point in the learning process where I usually start to lose it, I’m going to take my time and really try to understand OOP. I think I was a little too eager to get started on my application, and to get my hands dirty with code, that I tried to breeze through some of the more important parts. I have a tendency to do this… I don’t want to suffer through the boring stuff, I just want to get to the fun. Because I’m recognizing this in myself and because I realize that there is some important precursory stuff that I need to learn before I can really jump in, I think I might give ruby another look before jumping into the rails code again. We’ll see how comfortable I feel when that time comes. For now, however, here are my notes on some of the basic concepts of OOP (they are just notes, and therefore kind not very well fleshed out. I may choose to edit them in the future):

• OOP programs are be composed of individual entities or objects
• Objects can communicate with other objects AND each can store data
• Programming objects are often modeled after real-life objects
• Like in real life, OOP defines objects with similar characteristics as belonging to the same class

OBJECT – Single entity

CLASS – Construct for defining properties for objects that are alike and equipping them with functionality.

METHOD – Actions that have been assigned to a class.

INSTANTIATION – To create a new object, we must base it on an existing file. This process is called instantiation.

ARGUMENT – The input value that is provided to a method. Can be used to either influence how a method operates, or to influence which object a method operates on.

In the future, I’ll try to put up some examples of the previous so it makes a little more sense.

Back to Work

Look at that… it’s been exactly a month and a day since I last updated this blog. No I haven’t been slacking (well, mostly I haven’t…), I’ve been on vacation. No, not just from code… like, in the real world. True there has been about a week’s worth of padding on either end of said vacation, but it takes a little while to work your way back into the swing of things. I’m now in the process of actually writing some code (following along with my book) and I’m noticing that some of the things are coming to me pretty easy, and others are more difficult. I think I might take a quick step back to re-read about the specifics of MVC architecture. I seem to be most confused when I hear talk of inheritance and such. I feel like this is the most critical info in the whole learning-how-to-program process, so it’s worth another look. I have no new info to share with the blog today, just a note to say that I’m back and I’m ready to get to work.

Rails Basics… Finally!

The sitepoint book arrived early this week and it moves much more closely to my pace. There are a few basic things that I’ve picked up both from this book and the Pragmatic book that I feel it’s time to document here.

Installation

First of all, for the installation of Rails, I decided to go with Instant Rails. I prefer for the set up process to be as painless as possible and Instant Rails makes this so. It has Rails, Ruby, a web server, and a database all wrapped up in one easy-to-install bundle. If you’re a more advanced user and would prefer to pick and choose your server or database application, then knock yourself out… but Instant Rails works just fine for me.

Command Line

Once you’re up and running, you quickly learn that a lot of Rails functionality can (and I guess should?) happen at the command line. This is a new concept for me because all of the work that I’ve done up to this point as been—for the most part—command line free.

To create a new application, just navigate to the directory in which you want your app to live and type:

C:\Rails_Directory> rails nameofapplication

At this point, the console window will start spewing out all kinds of text. Just let it go… it’s creating the directory structure for your new application. The root of this structure will be whatever you chose as your “nameofapplication.”

Starting the Server

Now that we have the basic structure of the application created for us, we need to start up our web server so we can view it through a browser. Again, it’s quite simple:

C:\Rails_Directory> cd nameofapplication
C:\Rails_Directory\nameofapplication> ruby script/server

More words will fill the box. Who knows what most of them mean, but they’re doing something. And that something is starting the web server. You can view what you have so far at http://localhost:3000! Of course, we’ll need to write some code before any of this becomes usable in anyway, but it’s just cool to see something working. One note: To the best of my knowledge, starting the server seems to render this particular console window useless—at least for more typing. Just open another one and we’ll continue.

Creating a database

So now we’re going to set up the database. Since there are three environments in Rails (development, test, and production,) we’re going to create three different databases for our application. First we have to change to a mysql command prompt.

C:\Rails_Directory\nameofapplication> mysql -u root
mysql> create database nameofapplication_development;
mysql> create database nameofapplication_test;
mysql> create database nameofapplication_production;

And that’s it. Now we’ve installed rails, created the framework for a program, started a server so we can view the program, and built the database. It’s pretty amazing how fast you can get set up in rails. Oh yeah, one last thing. To get back to a usable Rails command prompt, just type:

mysql> quit
Bye

Off the Charts!

There’s a gauge on the back of the “Agile Web Development with Rails” book I’m reading that is supposed to suggest the skill range for a potential reader. The range goes from just a wee bit above beginner all the way to expert. When I was shopping for this book, that caught my eye. “I’m at least a wee bit above beginner!” I told myself. Yeah… turns out that I was wrong. In the eyes of the Pragmatic Programmers (the book publishers) I’m an idiot of unspeakable levels—barely capable looking after myself. If I had been born in the 50’s, my parents would have taken one look at me and sent me “away,” forbidding my sisters to ever speak word of me again. I would have been the deep dark family secret. Okay, that’s a little overly dramatic, but I’m clearly sub-beginner in the eyes of those who publish this book, because the damn thing moves too fast for me.

This is the problem that I always have with programming books, classes, lectures, etc. They always start out really slowly, and then all of the sudden, BAM! I’m lost. This book isn’t quite that bad, but I’m definitely getting the feeling that the author is assuming that I know something that I don’t. And he’s rolling ahead without asking me if I’m following along. I don’t want to knock the book too much. I do think it will come in handy once I have a more basic understanding of what we are doing and WHY we are doing it. That’s the part that is missing here.

I was feeling a little frustrated about this (as you may have noticed in my previous post) so I searched online to see if anyone else has had this problem. It turns out I’m not alone. Many said that the Agile book was a little too advanced for the serious n00b and that a better option for someone like me was a book called Build Your Own Ruby on Rails Web Applications by Patrick Lenz. The book is published by Sitepoint, and they even offer the first four chapters for free (pdf) on their site. I’ve gotten through three of the chapters so far and I have to say this is much more my speed. It’s more conversational and Patrick explains everything very clearly. I ordered a copy last night on Amazon (way cheaper than buying it through Sitepoint) so now I just have to wait for it’s arrival. Yay. Hopefully this will be the answer I’m looking for. My desire to learn Ruby hasn’t dampened… I just need the right materials for the way my mind works.

Am I learning?

I’m not sure what to think about my current progress. The book I’m working with attempts to teach the reader Ruby on Rails by walking them through the steps to building a web application. Once you reach the end of the book, you’ll have built a working shopping cart (of course). I’ve just completed the first chapter of actual coding and I do have a nifty little admin page that allows me to add products to the database, display them, etc. The problem is that while I’m following the steps directly, I don’t feel like each step is being explained thoroughly. I often don’t understand why I’m doing something or why it’s working the way it does. Part of me thinks that I just need to get used to the syntax and the general structure of the program and then it will all make sense. But the other part of me worries that I’m not actually learning, that I’m just following instructions. I wish I knew somebody who was interested in learning this with me… that way we could bounce questions and ideas off each other.

Or maybe I need to stop worrying and just keep following what the book tells me to do. Sometimes you just need to do things a couple of times before it truly makes sense.

Ruby on Rails 101: Understanding MVC… or Not

For this portion of the learning experience, I will rely mostly on the book “Agile Web Development with Rails” (unless I don’t like it, in which case I’ll switch to something else). This book has been highly praised across the board as THE text to read if you want to learn Rails… and I want to learn Rails… so, there you go.

This week I’ve been studying the architecture that Rails is based on. It’s called MVC, which is an acronym for models, views, and controllers. I have to be honest and say that I’m not sure I understand it completely. I feel like I get about 80% of it, but there’s that last 20% that’s just not clear. My problem is mostly with how it relates to RoR and the directory structure Rails generates. I think that I really just need to code something to fully grasp how it works and what it all means. I’m more of a hands-on kind of guy, so I actually need to do it myself before I truly understand it—just reading it in a book doesn’t always cut it for me.

I’m tempted to skip all of this background info (about MVC and such) but I don’t think that would be wise. I’m eager to jump right in and start coding but RoR is a very rigid system, so if I don’t understand the framework, that’s going to be a major problem for me in the future. It won’t be that long before I can get my hands dirty.

Moving on…

Okay, so now I feel like I’m grasping the basics of Ruby as a language. I’m far from understanding it completely or even being able to write my own Ruby programs, but I do feel like I’m getting the basics down. My education on the subject is not complete, but for the purpose of this blog, I think I want to move away from the Ruby aspect and start to focus on the Ruby on Rails part.

I’m moving on for two reasons. First, while I find Ruby fun to play with, the truth is that I’m not interested in becoming a programmer. I started this journey to learn Rails. That doesn’t mean that I’m going to stop learning Ruby altogether—actually, it’s quite the opposite. I’m still following Why’s (poignant) guide and I’m also using Chris Pine’s Learn to Program book to continue my education. The thing is, I want to learn Ruby to support my Rails development and make me better at Rails, not to make me a Ruby programmer. Second, it’s becoming increasingly difficult to express what I’m learning in Ruby on this blog. I’m not sure how to convey this information in a concise manner and still make it comprehensive enough to mean anything. My last post took quite a long time to format, only to show a snippet of code that’s only marginally useful.

Don’t worry, it’s not that I’m breaking up with Ruby… It’s just that we’ve decided to see other people.

Conditionals!

Okay. So, yesterday I spent my time reading how to code conditional statements in Ruby. Because I do have a limited exposure to programming, this isn’t actually as bad as it sounds (or as it could be).

Basically, a common interaction for a program involves the computer stating that IF some condition is met, this happens—ELSE (the condition is not met) this other things happens. While I hate to take examples directly from Why’s (poignant) guide to Ruby (haven’t I already linked to this site enough?), the below code snippet does a great job of explaining several parts of a conditional statement way better than I ever could… besides, I’m the student, not the teacher, right?

print( if at_hotel.nil?
        “No clue if he’s in the hotel.“
             elsif at_hotel == true
        “Definitely in.“
             elsif at_hotel == false
        “He’s out.“
             else
        “The system is on the freee-itz.“
             end )

So, in this example, if at_hotel is empty (nil) then “No clue if he’s in the hotel.” will be printed to the screen. This means that the program doesn’t have enough info to answer the question. If at_hotel is TRUE, then it will print “Definitely in.” If at_hotel is FALSE, then “He’s out.” gets printed. Since this covers all the possibilities, the only other option is that system must be on the fritz.

Conditional statments aren’t so bad, right? In fact, everything has been pretty manageable up to this point. I have to admit that I’m getting worried, because in my past experience, this is around the time that the hammer usually drops. Usually at this point in the training, the next bit of code we see is so complicated and unrelated to anything we’ve learned, that it causes my eyes to cross and my brain to shut down. Hopefully that won’t be the case this time…