Finally, a good day! Well, a good day based on my new definition. I used to rank my days at DBC based on how well I did on the challenges that day. If I was able to complete all of them and feel confident in my work, it was a very good day. If I struggled through every challenge and felt stuck at every corner, it was a decidedly shitty day. Now, I try to think about how much I learned on a particular day. And that makes today a decidedly good day, although there’s still a lot to figure out.

Like every Monday morning, we got together with the entire school and chatted about the previous week’s feedback. Some people have been complaining about certain aspects of the program, wanting to pair less and have more teacher hands on learning instead of learning from fellow students. While DBC is always changing and adapting based on student feedback, they tried to explain that the pairing and peer learning are what makes the program stand out when compared to a traditional school setting. I can definitely agree with this, and I wouldn’t want to spend more time than necessary with a lecture, only to go and work on the challenges by myself. I can do that at home.

The morning lecture on SQL was absolutely necessary for getting comfortable with the day’s challenges. We were marrying SQL into Ruby, similar to last week when we introduced CSV into Ruby. The syntax is completely different, but by using special operators, we can access whole databases, tables, columns, or specific values inside SQL through Ruby methods. Here’s a few examples: 

$db = SQLite3::Database.new "students.db"
$db.results_as_hash = true


def self.where(column_name, name)
    $db.execute("Select * FROM students WHERE #{column_name}",name).map {|student_hash| Student.new(student_hash)}
  end


def save
  if(@id)
    $db.execute(
    <<-SQL
      UPDATE students
      SET first_name = "#{@first_name}", last_name = "#{@last_name}", gender = "#{@gender}", birthday = "#{@birthday}", email = "#{@email}", phone = "#{@phone}", updated_at = DATETIME('now')
      WHERE id = "#{@id}"
    SQL
  end


Okay, so lots of new stuff going on here that took us a little bit to figure out. Don’t pay attention to the top bit, that’s just the code required to create a new database in Ruby using the SQLite3 gem. Notice that $db is a global variable, accessible across the entirety of Ruby on any linked file. The other two snippets of code, while performing different actions, are just two of the different ways we can access the same data. In the first snippet, we create a method called ‘where’, which takes two arguments. Just like in SQL, we need to know the column name and then search for a particular value inside that column. In this case, we provide those two arguments and then use $db.execute(a method created in another file that creates a clean database) to search through the database using SQL commands. Since everything inside the parentheses is a string, we have to interpolate certain commands like column_name.

In the second snippet, we use something called a ‘heredoc’. Instead of using quotes to create the SQL string, it uses those «- marks. We can put whatever we want next to them, but this is an opportunity to type the specific information that we’re creating, so it’s easier to understand later. Instead of SQL, I might have put «-UPDATE or something similar. These tags act as the SQL string quotes, so everything inside essentially does the same thing, though there’s a little difference with the interpolation. Since SQL only recognizes it as a string, we have to put extra quotes around the interpolated bits. The @ symbols are just referencing instance methods that have the required information for creating a new database object. At the bottom, we close off the heredoc with the same tag we started with.

Lunch, then afternoon lecture. This one was on getting a better understanding of ORM, object relational mapping. Our afternoon challenges would be on manipulating data using ActiveRecord Jr., which is a pre-built program that allows us to mock the behaviors of the real ActiveRecord. The ORM lecture helped us get a better understanding of what is happening inside of the Ruby code as it relates to the SQL database.

Off to more challenges. These were actually a lot easier, though I’m beginning to realize that both challenges, while nearly identical, had a different learning competency in mind than what we thought. I originally thought we would be asked to take this ActiveRecord clone and manipulate the data in it, making sure we knew how to use every facet. Instead, we were told to go through all three classes (one of which was a parent class of the other two) and simplify the code. We moved nearly every method over to the parent class, only modifying code slightly when there was an overlap. It turned out to be a little too easy, but that’s because we didn’t write the rSpec tests that were part of the challenges. I was more focused on learning the actual code of ActiveRecord and not so much on creating the tests for making it run. However, now I realize that the whole point of creating tests was to actually dig into each method and see what it did. By writing a test for what a particular method should do and making it pass, we guarantee that we know what’s happening on every line of code.

Tonight, I decided to focus on understanding every test that others had created. I made my own tests as differently as I could and attempted to get those to work. There was a lot of confusion, and it was very slow going. I managed to create a few tests and make them pass, and was satisfied with my understanding of the syntax. I knew what data I wanted to access, it just took me longer than I wanted to get at it.

Tomorrow is optional solo day, but I think I’m going to try to pair with someone. Even though I enjoy working by myself, I’m usually able to get more accomplished when my pair and I put our heads together.

Until tomorrow, I’m Edwin Unger and I’m a web developer in training.