Ruby Newbie

Today I worked on Assessment #4, in preparation for retaking it tomorrow morning. Although there exists a nonzero chance that I'll get 100% in two hours, odds are much better that I'll fail. According to an email I received at noon, that will mean the end of my time at App Academy.

There are benefits and drawbacks to leaving, but I'd stay if it were up to me. I plan to continue the curriculum on my own (redoing what we've done so far, even) or with other AA rejects. Maybe I'll go to Burning Man, or maybe I'll accept some co-traveling invitations; I'll have time for that sort of thing now. I don't have a clear picture of what my life will look like a few months from now.

All I do is program. Here's a real conversation from today:

me: "Wow, I can't believe it's 10:00 already!"

other student: "We have got to get an earlier start tomorrow."

me: "What do you mean? We started immediately after class, except for getting takeout."

other student (begrudgingly) "I guess we do have to eat."

There's a lot of material I wish were covered in lectures or readings, and I've been really grateful lately to be learning important stuff from my classmates. And here I'll describe one such thing, as a brief reprieve from my talking about my feelings.

In MVC, there's a hierarchy of abstraction layers (probably there's a real term for this). Here's what it looks like:

Views Controllers (& Helpers) Models Database

Assessment 04 was today, and it was very ambitious in scope. I am aware of multiple scores in the 10-15% range. Afterwards, the collective mood felt intense, strained, and frustrated. I had been pretty despondent all day, and after the assessment I continued to be pretty despondent.

But the day wasn't all bad. For one, I got significant solo app-building time in, which was extremely beneficial.

After the evening lecture I got a chance to talk with Ned about the program and my experience of it, and I found him gracious and sympathetic, even if he couldn't tell me what I wanted to hear.

Others and I spent two hours this evening wrestling with the assessment, this time with the benefit of each other's insights (and the internet). The average score on this second trial was 25%.

There were at least two fewer students in class today; word on the street is a few people were asked to leave. No announcement was made.

I feel for the missing students, and I wish I knew a surefire plan to avoid their fate. I can only resolve to do my best to "not look down" and shoulder on, even while knowing in the back of my mind that I might be next.

Yesterday (Friday) we made another rails app (!!). We made it farther along in the process, partly with the increased speed that comes from repetition, and partly because we skipped some some less interesting requirements.

Much of our time was spent making forms, which are kind of a giant pain in the ass. If I want to make a single text entry box for "band name: ", I must write "band name" four--sometimes five--different times, in three different permutations, in the HTML that generates that field. Here's an example:

<label for="band_name">Band name</label> <input type="text" name="band[name]" id="band_name" value "<%=value(band, :name)%>" >'

Don't miss any quotations marks or curly braces! The server will get mad if you do.

Let me dissect the above code:

<label --Okay, we're making a label for a field.

for= --Which field? The functionality of this portion seems not strictly necessary, but we've been instructed to always do it for two great reasons. The first is for accessibility: content readers for the blind rely on fields being labeled in this way. The second is that apparently if the user clicks on the label name, their cursor will be placed in the input field for that label. This is especially important in mobile environments, or, only works in mobile environments (I wasn't clear from the lecture).

"band_name"> --this is what the label's for. Must exactly match what comes after id= in the input type= section below. The angle bracket indicates that it's part of

Band name --this is what the user will see as the label for the input field. Notice it's not a string. If it had quotation mark, the user would see those too.

</label> closes out the label element.

<input type="text" --We're making a text input field. This is a single-line field for the user to enter text into (if we wanted a multi-line box, we'd use <textarea name= ).

name="band[name]" -- this tells rails where to store the string that the user submits. In this case, params[band][name]. params is a magical multi-layered hash, and band is a key within it. The band key points to a hash, and name is a key in it.

id="band_name" -- Remember that for="band_name" from the label earlier? This is the part of the field that's matched up with the that part of the label. The two are associated now.

In order to understand the value part of the HTML, I must first do more reading. Back in a bit.

Okay, I'm back. And I'm ready to collect a prize as the first person on the internet to return to a post as promised. I know you're on the edge of your seat, so without further ado, here's the value section, explained:

Today, we pushed farther into the rails app pipeline by developing our first views. To this end, we've learned a touch of HTML and ERB. ERB is a rails component that allows you to embed ruby into HTML--pretty neat. Except it doesn't look neat at all! Here's an example:

Sex: <%@sexes.each do |sex|%> <%=sex%> <%end%>

That's honest-to-goodness some of today's code. Being a web developer might be more exciting than I thought.

We are zooming through our rails projects, and the going is very fast. I'm seeing now how Rails enables streamlined web app production: it ties together SQL, Ruby, and HTML. All that abstraction is implemented in syntax and file relationships that are new and often confusing, but if the past is any indicator I'll be feeling pretty comfortable with it come next week.

For a while, I've been hearing the term API thrown around, and today was the big reveal. API's are a backdoor way to interact with a web app. This means you can basically patch your own desired functionality onto many powerful services available online.

Today was our second solo day, woohoo! Unfortunately, I struggled with the project. But if the measure of a day's success is how much you learn, I did alright.

One thing I learned the "self" in self.method_name (inside a class method) refers to the "self" in the scope where the method is called, rather than the scope where the method is defined. So if you make a parent class, the child class that inherited from the parent will be the "self". It can get more subtle and tricky, as you can see in the following:

def self.attributes @attributes end

def initialize(params = {}) params.each do |attr, val| if self.class.attributes.include?(attr) self.send("#{attr}=", val) else raise "mass assignment to unregistered attribute #{attr}" end end end

These methods are defined inside a parent class definition. The "self" inside initialize refers to the instance of the child object, thus the need for self.class.attributes to refer to the self.attributes method defined above it.

I've just spent the last six hours redoing SQLzoo--much easier the second time through, but I'm still far from flawless. Regardless, I'm entering the seventeenth hour of my day, so it's time to go to sleep.

Tonight I was told by an AA alum that so long as I understand the abstract concepts and take the work seriously, that I will do fine. Nonetheless.

Today we started using ActiveRecod, which is the rails ORM (Object-Relational Mapping) between ruby and SQL. This saves us from writing sopping wet SQL queries and byzantine join statements, but it adds a thick layer of magic that I very uncomfortable.

The night of w3d1, I got nearly eight hours of sleep. It was the first time that had occurred on a night before a schoolday. . . since App Academy started. I now have a new personal policy, because that extra time sleeping, at the expense of reading or working through a project, was time well spent.

Throughout the day, there was a very noticeable difference in my ability to pick up on ideas. Even though I hadn't completed the reading, I absorbed a lot of the reading content over the course of the day, instead of feeling stuck. And I never, not once, got into a state where I couldn't think at all because my brain was shutting down.

Today began with Assessment 02, which tested our OO skills with a game of Crazy eights. Afterwards, we began working on SQL with SQL Zoo.

Writing SQL is very different than writing ruby. One the one hand, we haven't used anything approaching complex algorithms. On the other, I find the syntax used in writing SQL to be less clear. If the query is complex, the series of JOINs and WHEREs and GROUP BYs can quickly become convoluted.

Prior to now I'd seen RSpec, a ruby TDD gem, only in the context of our assessments. Today, we wrote plenty RSpec tests of our own.

The idea behind TDD (Test-Driven-Development) is that before you write your code, you specify its behavior in a variety of states. RSpec is a way to specify that behavior in code that also checks the code's actual outputs against the expected outputs.

Although RSpec is written in ruby, its syntax looks pretty unfamiliar. This is because it's a superset of the language; in other words, it has all the functionality of ruby plus additional methods. Here's a typical example:

require "rspec" require "my_filename"

describe "my_class#my_method" do it "behaves as expected" do expect(my_method(given_input)).to eq "expected output" end end

Today was our first solo programming day, and I loved it. It was such a relief to have uninterrupted thought. Pair programming has definite advantages, but so does solo work; I'd prefer it if our class split its time 50/50 between the two.

I made checkers today (all by myself!). It's functionally complete, and I'm stunned by that outcome because it's a first for one of the big projects. And about a third of the people I talked to didn't finish theirs. Maybe I won't get kicked out of App Academy after all.

Today, Katarina and I fleshed out the chess game we started building yesterday. It's funny how things so commonly seem nearly finished. Yesterday, I thought we'd finish today for sure, maybe even with time to refactor thoroughly and spiff it up. Let's just say the reality feels more like Zeno's paradox. The next bug fix always feel like the last, and while it's true that squashing those bugs takes us closer to our goals, the fact remains that we never reach them.

Every day, I learn a staggering amount. So much that by the end of the day, I can't remember it all and the morning seems like a week ago.

Now, you may be saying to yourself, "Naomi, if you can't remember it all, in what sense have you learned it?" A reasonable concern. Never worry, gentle reader, because there's a workaround. You see, every day I am doing some programming-related activity--programming or watching a lecture or reading code--for about fourteen hours. If learning is reinforced through repetition, and I hope it is, my frequent encounters with the recently forgotten will cause me to remember them more readily in the future.

Today my pair and I wrote about 3/4ths of a minesweeper game. It had a Board class, a Tile class, and a third class to manage gameplay. The partner I paired with today had a very different style from me, and it cemented for me how much I benefit from writing the skeleton of complex behaviors out in pseudocode ahead of time. I'll push for that in the future.