There are two ways to add a module to a class, include and extend. The include keyword will bring the module methods into the class as instance methods, allowing instances of the class to use the methods. The extend keyword will bring the module methods into the class as class methods, allowing the class itself to call those methods.

It’s important to understand which of these two are appropriate to use on the module and to design and structure your module so that it can be used correctly. If you use the wrong keyword to bring the module into a class you will not end up with the expected functionality. Additionally, modules should be designed and structured with this in mind, separating methods that are intended to be instance methods from those that are intended to be class methods.

Write out what you want your tests to do without worrying about the actual syntax for the tests first. Statements like “it ‘should do whatever this test should do’” do can be followed with pending on the next line. This allows you to write out all of the ideas with what you would like your code to do without having to worry about any syntax yet. You can then impliment tests as you’re comfortable and write the corresponding code to pass them when the tests are ready.

Sometimes it’s helpful to write out skeleton tests, to describe what features a given unit of work should DEFINITELY have without worrying too much about potential features or tasks that it may need further down the line. Once you get the basics built out on your files when you come across new functionality that is needed you can go back and add tests and then add the code to get those to pass. This approach can save some time as you won’t need to try and brainstorm every feature you might come across and can instead focus on making sure your tests are good and that your code passes them. You can always add more tests later

With the level of complexity of our current projects, writing tests often feels very frustrating. It feels like spending a lot of time writing out very basic things about the code when we could be actually writing the program. Intellectually I’m aware that this work will pay off down the line as projects become more complex, so in the meantime I need to keep reminding myself that it’s not slowing us down, it’s preparing us for things to come.

The SQL side of the program exists to keep a unique record of articles off of Hacker News that meet certain criteria. The scrape can be run multiple times over multiple days, weeks, etc. so it was important that the SQL side of the program not continuously re-enter the same article over multiple scrapes. Here’s what the code looks like…

1
2
3
4
5
6
7
8
9
10
11
12
13

class Database

  @@db = SQLite3::Database.new('articles.db')
  @@db.execute("CREATE TABLE if NOT EXISTS articles(id INTEGER PRIMARY KEY ASC, title TEXT UNIQUE, url TEXT, parent_url TEXT, points INTEGER);")

  def self.insert(array)
    array.each do |article|
      sql = "REPLACE INTO articles(title, url, parent_url, points) VALUES (?,?,?,?)"
      @@db.execute(sql, article.title, article.url, article.parent_url, article.points)
    end
  end

end

There are a few bits of this code I would like to highlight.

“CREATE TABLE if NOT EXISTS” – This one should be familiar to most Flatiron students already, but since some of our projects and examples have assumed the existance of a table I thought it would be worth mentioning. The ‘if NOT EXISTS’ part is important to make sure that you are not creating a new table every time the code runs, this code will only execute the first time the program runs, unless the ‘articles’ table is deleted from the database (this would have to be done manually by the user).

“title TEXT UNIQUE” – This is one that I had to look up what I wanted SQL to do before I could figure out how to do it. This tells the database that while the ‘title’ column is not the primary key, that it is unique and that SQL should raise an error if something attempts to add an item with the same title as something else to the table.

“REPLACE INTO” – The work-horse piece of code, normally we would use ‘INSERT INTO’ but in this case, I chose to use ‘REPLACE’ for two reasons. First, it resolves any conflicting titles by replacing the old entry with the newer one, which makes sure that we only have unique entries in the table. Second since it replaces the old version with the new one, it will update any other data about the article that has changed since the last time the scrape was run (for instance, if the number of points were to change).

These three peices that were previously unfamiliar to me do a lot of work in very little space. Because I don’t need to write methods to check for some of the things these take care of automatically, we save a lot of space and the code is easy to read. Thanks for reading, I hope if you’re working with SQL these little bits are helpful!

Today I wanted to talk about a couple ways I think the .tap method in Ruby is useful. The first time a lot of us at Flatiron saw this method, it was used in an RSpec test and threw many of us for a loop trying to figure out exactly what the test was doing. After using the method for a bit, it’s become clearer what the tap method is, a shortcut.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

class Dog
attr_accessor :name, :favorite_food, :breed
end

# The Three code samples below all are based on the above class.

clifford = Dog.new.tap{|x| x.name = "Clifford"; x.favorite_food = "Children"; x.breed = "Big Red Dog"}

# The code above and below this comment are equivalent.

clifford = Dog.new

clifford.name = "Clifford"; clifford.favorite_food = "Children"; clifford.breed = "Big Red Dog"; clifford

# This code is also equal to the code below, in case semi-colons make you uncomfortable...

clifford = Dog.new
clifford.name = "Clifford"
clifford.favorite_food = "Children"
clifford.breed = "Big Red Dog."
clifford

So the three pieces of code above all return the same value with different ways of getting there. The tap method offers a few advantages over the others.

First, you get the same return out of a single line of code. This advantage should be obvious from looking at the code (you can paste the samples into IRB to confirm equality)

Second, you don’t need to call the variable to get the return value, which also means…

Third, you don’t have to store the object in a variable at all. This looks like…

1
2
3
4
5
6
7

#Original code from above

clifford = Dog.new.tap{|x| x.name = "Clifford"; x.favorite_food = "Children"; x.breed = "Big Red Dog"}

#Same return value without having to store the object in a variable

Dog.new.tap{|x| x.name = "Clifford"; x.favorite_food = "Children"; x.breed = "Big Red Dog"}

This allows you if you are creating a large number of objects and passing them into a larger data structure (hash, database, array) to not have to first store the object in a variable before passing the variable into your data structure, saving steps along the way. With the other ways of making clifford ‘real’, you would need to store the object in a variable to be able to manipulate it after it was made, with .tap you can make clifford exist and have traits without ever having to tell the computer to remember him.

The big thing I wanted to focus on is that provided you’re not living in an alternate dimension where there is no Git, you can feel free to burn your working code to the ground and swim in its ashes. You still have that working code in version control, there is nothing intimidating about altering it to where it starts failing tests or stops functioning. Even if you never find a better solution on a given project, you never will if you don’t start smashing your code and trying to rebuild them.

In Office Space they took the printer out into a field after one too many “pc load letter” errors and smashed it to pieces. Unfortunately with hardware, its pretty difficult to put back together. Count yourself lucky that with code that is not the case, you can destroy your project over and over again and roll it back if you aren’t making useful progress.

Get over the fear of the red results and break your code, it’s liberating.

Take the following situation…

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

class Dog

  attr_accessor :name, :color, :breed, :number_of_legs

end

fido = Dog.new
fido.name = "Fido"
fido.color = "Red"
fido.breed = "Direwolf"
fido.number_of_legs = 4

other_fido = Dog.new
other_fido.name = "Not Fido"
other_fido.color = "Green"
other_fido.breed = "Regular Wolf"
other_fido.number_of_legs = 3

So we have the class Dog with a few attributes, and we’ve created two dogs. Now we’re going to create two methods, one to make an individual dog bark and one to make the Dog class bark.

1
2
3
4
5
6
7
8
9
10
11

class Dog

  def barkley
    puts "I AM TOTALLY BARKING YOU GUYS"
  end

  def self.bark
    puts "THE CONCEPT OF A DOG IS BARKING, RUN FOR YOUR LIVES!"
  end

end

Now, if we put fido.barkley we will see “I AM TOTALLY BARKING YOU GUYS”

If you put fido.bark though, you will get a NoMethodError, because the bark method is defined for the class it was in because we defined it as self.bark, with self referring to the current object its contained within.

So… If we put Dog.bark we will see “THE CONCEPT OF A DOG IS BARKING, RUN FOR YOUR LIVES!”

Similarly, if we were to call Dog.barkley we would again get a NoMethodError because the method is defined without the self demarcation, telling ruby that it is to be used by individual dogs, not by the class as a whole.

So bringing things back around, if you want your overall class to respond to a method, name it as self.method, if you want a specific instance of that class to respond to it, do not have the self in there.

It turns out after looking at my ‘to do’ list for Flatiron that the only things I have unfinished stand about 80% done. Some are a little further along, some less; but the overwhelming majority of my unfinished work falls right around ‘almost done.’ It always seems to be that one method I can’t get to function correctly, or the one or two tests I just can’t seem to get to pass that are holding up some of my work from being completed.

So I’ve decided I’m going to stop caring about pace. I’m not going to find it odd or frustrating anymore when I rush through 80% of a project only to find myself stuck in the mud at the end. I’m just going to push through it, knowing that it’s completely normal and not something that’s going to change.

I’m going to try and break down structs into three parts. Concept, Code and Uses…

Concept: A struct is a miniture class, created quickly and at its core it is a class that only has basic getter and setter methods.

Code: There are a few ways to create a struct. I think the easiest to do and understand is as follows…

1

Location = Struct.new(:name, :lattitude, :longitude)

That’s all there is to it, this quickly creates a Struct Class called Location that keeps track of a locations name, lattitude and longitude coordinates. Which brings us to…

Uses: Structs seem like they are best used for set values for things that don’t need to have any class methods. Things like GPS locations seem like a great reason to use a struct instead of another structure. Any time where you know there is a fixed amount of information you need a struct can be a quick and easy way of storing information about those things, I’m going to try and use structs more and see if I can’t find even more useful ways to implement them!

Namely Nokogiri, this ruby gem for scraping web pages was the big learning focus of my weekend. Our project was to use Nokogiri to scrape the Flatiron student webpage for information on each student and export that data into an SQL database. It took a lot of trial and error playing around with Nokogiri before we figured things out, but by the end my whole group was pretty comfortable navigating the trees of data that is HTML.

We also had to redo the quiz from week one but make it object oriented, having to have classes in each of the previous tests. I thought the difficulty on that assignment was pretty easy but that it was useful in providing repetition in looking at grouping things as a class.

Lastly we were given an assignment called playlister, which was a multi-file, multi-class assignment that had a suite of rspec tests that needed to be passed. I sure hope this was the stretch assignment for the weekend as I spent a lot of time struggling with it.

I’m really looking forward to week three. After two weeks I’m already amazed at the tools we’re beginning to scratch the surface of using. I can’t imagine after 10 more weeks how many cool things we’ll be able to build. I feel like a child who just learned what a car can do but whose feet can’t yet reach the pedals. Once they can it’s going to be a fun time!

Something I like about Flatiron is that we learn everything from the ground up. The magic of a lot of things like Rails and Active Record will be understood by us as we will have learned to do everything without them. That is exactly how I want to learn to program. That said, it’s also a pain in the butt. Writing SQL queries isn’t conceptually difficult, though the new syntax creates some conflicts, but writing it in sublime as a .sql file and smashing it into a DB in BASH is a more tedious process than I think is probably necessary. I’m about ready for Active Record!

Most of the classes issues seemed to stem from Queries and Joins. Most of the organizing of the databases came pretty naturally to most people I talked to, but there is a lot of syntax with queries/joins that can be pretty confusing. I’m going to post a snippit of my code and try and explain it…

1
2
3
4
5
6
7
8
9

SELECT project.title, SUM(pledge.amount) AS 'total_pledge_amount'
FROM
project
INNER JOIN
pledge
ON
project.id = pledge.project_id
GROUP BY
project.title;

So, this query has several parts which I will try and explain correctly one at a time.

The first is SELECT. This is the specific data we want this query to look at. In this case its the ‘title’ column from the ‘project’ table and the sum of the ‘amount’ column from the ‘pledge’ table. The AS key just renames the result of the SUM function to ‘total_pledge_amount’ and could be removed and the query would still function. Next is FROM, we are joining from the project table, using an INNER JOIN with the pledge table. I reversed the places of project and pledge and got the same results, so I’m not yet sure where it would be important to specify one table in front of another. After that is ON, which is where the JOIN will link the two tables based on a mutual key. In this case its the primary key of project (project.id) and the foreign key in pledge that corresponds with the project primary key (pledge.project_id). Lastly is GROUP BY for which i put ‘project.title’ this orders the query results alphabetically by the ‘title’ column in the ‘project’ table. The result is a list of each project.title and the total amount of pledges that match each projects key.

I’m finally starting to instinctively break things down into smaller chunks. I was expecting this sort of progress to come with a light bulb over my head, fireworks or some other sort of stark realization that I had made progress. Instead it came from solving a problem and looking at my solution and realizing that I solved it differently than I would have a couple days ago without even noticing I was doing it.

I’m also starting to get a little bit of a handle on refactoring. I managed to get our pigeon hash problem working and then condensed some of my code that was running in different parts of the program into a single method at the end to execute all the sub-methods at once. I’m happy that I spotted this and was able to make my code better without breaking its functionality. After looking at some of the solutions my classmates came up with however, I still know that I have a lot of work to do with refactoring as some of their solutions were brilliant!

The first few hash projects I was able to get through cobbling together nested do blocks based on .each and the key varient but it was really messy. I felt like I was trying to break a problem down into simpler ones like Avi told us, but coming up with even more complicated answers that usually didn’t work.

Then came Hashketball. A giant monstrosity of nested hashes that we had to find a bunch of ways of iterating through to get to the particular piece of data we wanted. At times we also had to compare various types of data that could be found throughout the nested hash jungle, all while trying to avoid the local predators (read: errors, fatigue, frustration). After what seemed like a day and a half but was really probably only a couple hours of fruitlessly banging on my keyboard trying to break the problem down into smaller problems, or try and get elaborate nested blocks to do what I wanted I finally found the heartbreakingly simple answer of how to access the hash how I wanted.

It was so simple I couldn’t believe it. Or at least I couldn’t believe it until the thought occured to me that rubyists likely have to do this sort of thing and since its ruby there has to be an easy way to do it, that’s just the way ruby works.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

hash =
{
  :hash1 =>
  {
    :hash2 => 1,
    :hash3 =>
    {
      :hash4 => 2,
      :hash5 => 3
    },

  },
  :hash6 => 4
}

#so to access the number 3.

hash[:hash1][:hash3][:hash5]

#this looks at the 'hash' created, then accesses deeper levels of the hash by 
#calling on keys in [].


#you can also iterate through pieces of a hash.

hash[:hash1][:hash3].each_key do |key|
  hash[:hash1][:hash3][key]
end

#This looks through the has to the key :hash3 then looks at each key within and 
#returns the value it's associated with.

Friday began my love affair with case statements. They are beautiful creatures that really can save you a lot of code over if/else statements and also read a bit more clearly.

EXAMPLES…

1
2
3
4
5
6
7
8
9
10
11
12
13

def temperature_bot(temp)
  result = ""
  case temp
    when 0..16
      result = "cold"
    when 17..21
      result = "comfortable"
    when 22..100
      result = "hot"
    else
      result = "you're probably dead"
  end
end

1
2
3
4
5
6
7
8
9
10
11
12

def temperature_bot(temp)
  result = ""
  if temp > 0 && temp < 17
    result = "cold"
  elsif temp > 16 && temp < 22
    result = "comfortable"
  elsif temp > 21 && temp < 100
    result = "hot"
  else
    result = "you're probably dead"
  end
end

The difference doesn’t seem to be a huge deal when you’re scanning over the different code, but the clarity and ease of the case statement makes debugging easier when you’re dealing with a larger set of code.

Over the weekend I managed to stay out of Manhattan. I don’t know in the long run if this is a good or a bad thing, but I spent the weekend in Brooklyn coding, climbing with some Flatiron folks and managed to have enough time to watch a little football on Sunday.

I was really happy with the assessment we were given over the weekend. I think everybody at Flatiron goes through points in a day when they feel like the ‘dumbest kid in class’ because they don’t get something yet or are having trouble. Somehow, despite this happening to virtually everyone we don’t seem to be able to shake that feeling just yet.

Having a solo assessment that goes over the material we’ve covered so far went a long way to helping me confirm that I knew what I was doing so far. Not everything came to me right away but I managed to make my way through everything with a little help from google and my new best friend Rubular.

My ‘take away’ from the weekend is the power of regular expressions. I think all of the code in my weekend homework that I am most proud of used regular expressions to accomplish a lot with very little code. They don’t read as easily as normal ruby syntax but you can do some really powerful stuff with regular expressions and it makes them a lot of fun to use.

My goal for this week is to use yield and code blocks better. I was reviewing the Treehouse ruby material to brush up for week two and they showed some very cool ways to organize a chunk of code where the main method organizes and runs the sub-methods and yields to them to do the ‘work’ to get the goals they want. This reminds me of the Jukebox assignment we worked on last week and makes me think that the program would have been a lot ‘cleaner’ if I was more comfortable yielding to other methods.

A few takeaways that I need to make sure get ingrained in my head…

A method always returns the return of the last command it executes. This means if you write a method to manipulate an array and want to call that method later and have it return the manipulated array that you need to call the name of the array at the end of the method in order for the method itself to return that array.

Puts ALWAYS returns nil. So try really hard not to actually put it in a method. Definitely make sure that its not the last thing in an array unless I want the array to return nil.

I also saw syntax I like for short if statements to keep them more compact.

if x == 1 puts “x is 1!” end

is equivalent to

puts “x is 1!” if x == 1

I think the second iteration of code looks much cleaner and would like to start thinking of short if statements that way before I put them in a block.

I am the most responsible student I have ever been, albiet through three days. I pay attention in class, work as hard as I can on my projects and do my homework thouroughly right away. Yesterday I woke up feeling like I was starting to get a cold, so I made sure to get plenty of vitamin C and went to bed at 9:30 when I was finished with my work to get a little extra sleep to help combat this cold.

I’m not yet sure if this is the sign of maturity, or the complete devotion to a singular focus. I’m assuming more of the latter, I am so focused on this program that there is nothing else to be concerned about other than working hard at coding and taking care of distractions that might lead to my inability to focus or work as hard as I want to.

One thing that I did learn today was how to use a splat (*) in method arguments in Ruby. With the little Ruby I know, I really enjoy using arrays to solve problems when I can. Normally I would have the array set up ahead of time and use a method to manipulate the array or the data within to solve a given problem. splat gives you some other options on manipulating similar sets of data however.

You can set up a simple splat method as follows to see how it works:

def splat(*inputs)
puts inputs
end

splat(1,2,4,5,6)

This will output the following:

1
2
4
5
6

This allows you to take a variable quanitity of inputs (it will also take strings) and manipulate them one at a time before deciding what to do with them. An example of when this might be useful would be if you were pulling a bunch of variable types of data from a database and wanted to sort that data, you could have the pieces get input through a splat method and have the method sort them by type (string, float, integer) into arrays before manipulating or looking at the data in the arrays with further functions.

My understanding is that when you create a new branch to work on a feature, other things can happen to the master branch while that feature is still being worked on (like other features or fixes being merged in). If you were to merge a feature in after many changes have happened to the master branch you can run into some conflicts when you try and merge the new branch in. These situations can sometimes be mitigated by rebasing the branch instead, removing it from the branch continuity and placing it back on top of the master branch. My understanding of exactly how this works is still a little incomplete, but I believe it does something like catch the base code up to current for the branch and then add the new feature changes rather than attempting to merge two complete sets.

I’ve also decided that I want to do some (completely unqualified) self expirimentation and research into some of the non-computer related aspects of coding. Yesterday after about hour 9 or 10 of coding I started to hit a wall where it was ‘hard’ to think and I was having to look up simple commands that I know off the top of my head normally. I was also becoming more frustrated more quickly when I ran into issues. I think of this as ‘brain fatigue’ and would like to see how different factors like sleep, diet and exercise affect this over my time at Flatiron. Hopefully I’ll find some ways to combat this issue that I imagine is being run into by more folks than myself.

The best part? At the end of a long-day it hadn’t become a grind. I was laughing just as much when we wrapped up as when we started and wished the staff had let us go a little further as I was really digging into cleaning up the CSS in our project.

I can’t wait to see what the next 12 weeks hold.