Phew, day nine is over and in the rear view mirror and day ten kicked off with a few hours of self-directed work. It really seemed to come at just the right time for a lot of us, myself included. I got caught up on a lot of the things that were giving me trouble and by the end of the day was really feeling like I was back in the driver’s seat with my learning.

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!

Week two day two was a rough one for me. I’m finally starting to feel really stressed by the material. I’m spending a lot more time fighting my way through producing what I feel is sub-par code than I’d like. I’m really hoping that I’m reaching the end of a plateau in my learning and will take a jump forward soon. I’m having trouble breaking problems down into smaller pieces and still keeping track of everything. I’m also having some issues figuring out how to refactor my code from the ‘works’ stage to the ‘right’ stage. Week 2 day 3 we get a big chunk of time to catch up on stuff though, so I’m hoping that my not feeling confident about my code from the last day or two isn’t uncommon and that I come out of Wednesday feeling a bit better.

I came out of the weekend feeling like I really knew what I was doing, then Monday happened. At the beginning of the day I was feeling good about my competence level but once we really dug into nested hashes and how to access data inside of them the wheels really came off the rails for a while.

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.

I’m going to wrap Friday-Sunday into one big post.

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.

On day four we really got into Ruby. Most of the day was spent in lectures with a few labs mixed in and was punctuated by most of us being at the campus pretty late working on our homework.

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.

Day Three was the easiest day for me thus far with comprehension. It was mostly a review of and practice with GIT, HTML and CSS with some Ruby at towards the end of the day. I think they’re trying to get us a lot of repetition with the basics so that when they really hit the harder stuff full force we’ll be less-lost on the basics.

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.

I’m catching up by posting my day two post on the morning of Day 3. Yesterday we spent a ton of time on Git and Github, as well as setting up our environment and getting plenty of practice with BASH. Most of this came fairly easily, though with Git it took me a while to even start to understand the differences between merging and rebasing.

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.

It’s been one day and I can already tell this is going to be a period of weeks that defines my future. The first day of class 003 and the first day in the new Flatiron campus was an amazing experience. A giant space filled with like-minded nerds and geeks from all different backgrounds coming together to code for an intense amount of time.

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.