Quest to Program

Test Writing is an absolute necessity in programming and I know in order to write great code I need to write automated tests to check that code. I have been having lots of challenges wrapping my head around tests and the relationships they have to the code I’ve written. 3 days ago I decided to buy a course that would help me understand writing them better. I ended up purchasing a course called Ruby Programming from the Team at Pragmatic Studio and I’m super happy I did.

Prior to Pragmatic Studio I had been attempting to write tests in MiniTest and so the syntax looked something like this:

test “capitalizes the project” do assert_equal “Seinfeld”, @fundrequest.project end

as opposed to the new RSpec syntax I am learning through Pragmatic Studio:

it "captializes the project" do @fundrequest.project.should == "Seinfeld" end

I prefer the reading and writing of RSpec because I find it easier to write and understand tests when written in this manner. 

Aside from the tests I’ve been spending lots of time practicing at iterators and blocks. I’m in the process of writing a few very simple gems, one that will be a very simple game and another that will be a fundraising type gem. I’ve gotten to a point where I understand how to write them (for the most part), the biggest challenge now is deciding when and which iterator to use. (In my example below I am using case as the iterator.)

module GameTurn def self.take_turn(player)    die = Die.new    case die.roll      when 1..2      player.blam      when 3..4      puts "Nothing happened to #{player.name}"      else      player.w00t    end end

This week I did not reach my goal of 40 hours of learning Ruby/Ruby on Rails. I came in at 22.34 hours, but not included in that time are the hours I spent working on a website design for a new brand called Power Of My People. While I didn’t reach that goal in pure Ruby and Ruby on Rails development I did spent lots of time on HTML, CSS and Liquid which pushed me closer to that 40 hour goal.

The time I did spend on learning, I spent most of it working on TimeStation. I made stylistic changes, wrote tests, added Users and set up a home page. When I wasn’t working on TimeStation I had a chance to finishRuby Koans and worked through more of the book ‘The Well Grounded Rubyist’.

Today, I spent my morning getting TimeStation deployed on Heroku (which means it now live online!). I learned that Heroku doesn’t like SQlite and that I needed to setup a PostgreSQL database for production. The reason for that is SQlite is not intended to be a production grade database. It is more commonly used for small amounts of data because it can be run in the memory and thus commonly used in development instances of small Rails applications.

I’m finding writing tests to be very challenging, because I still have so much to learn about how the elements of code interact with one another. Typically with TDD you will want to develop tests as you write the code whether that is before, or immediately after. This guy says 20% before 80% after works for him (and he created Rails).

I’m using Devise for my user generation but I am having trouble running tests where a 'fake' user accomplishes a task when logged in. I’m close to getting this to work, but I still have some more fiddling to do.

The first test I wrote is so simple, but it feels fantastic to get it up:

test "index, user not signed in" do  get :home assert_response :success assert_select "h1", "Log Your Hours." end

Since building the TimeStation application last week, I've been logging my hours on a regular basis. Over the last 7 days (Wednesday - Wednesday), I’ve logged 41.77 hours and have been splitting my time between books, koans, meet-ups, codewars, and  TimeStation.

Last night I went to my second Ruby meet-up. My goal for this meet-up was to build a few new features on TimeStation, including a re-design of the layout. Prior to the meet-up I’ve been trying to come up with a solution that allows me get the number for the Total Aggregate Time I've spent, and render it in the view. I was trying all sorts of things from adding a new column to my database for total_time, to creating a map in my view, to creating methods in my controller. None of those worked for me (possibly because I was implementing them poorly), however the solution for my problem was incredibly simple. Create a class method using Self. 

Up until that point, I didn’t quite understand why the total_time methods I had never allowed me to call on the entire Clock. I had assumed what I wanted to do needed to be achieved through another approach, so I tried other ways (such as adding a column to the database). Turns out - when I tried to run loops, they never worked because I was only going through a single instance.

For example, my old code looked something like this: 

Class Clock     def total_time # function      end end  a = Clock.new  a.total_time 

This never worked because I was only ever creating a method for a single instance of Clock rather than the entire Clock model. After some guidance at the Ruby Meet-Up my new code looked like this: 

Class Clock     def self.total_time # function      end end Clock.total_time 

All of my books have finally arrived - they are; 

 “The Well-Grounded Rubyist” David A. Black  “Eloquent Ruby” Russ Olsen  “Agile Web Development With Rails” Dave Thoma, David Heinemeier Hansson  “The Rails 4 Way” Obie Fernandez 

In addition to those books, yesterday I discovered a few cool things that are going to help improve and test my Ruby knowledge.

The first is Ruby Koans, which is basically a bunch of tests that iterate through many different Ruby Principles. I’ve made it through about 1/3rd of Ruby Koans so far, and it has already exposed me to so many more use cases for Strings, Arrays, Symbols and more. I haven't known how to answer most of the questions without first testing them in irb, but it has been great at exposing me to new use cases and giving me a better idea of how tests operate. 

Codewars is this place where other people create these things called a “kata”, which is essentially a user generated question that other people have the opportunity to answer. The more you answer, the more Honor you earn! 

Last week, I attempted to make a TimeStation application where I could log my hours spent on learning how to program. Pretty quickly I realized I had no idea how to start it and instead decided to spend my week learning more about the fundamentals of Ruby. 

Over the last week I've learned a lot, and with my reformed knowledge and understanding of more programming principles and fundamentals of Ruby, I decided to attempt building TimeStation again. I’m excited to say that I finished it early this Tuesday morning! 

My goal for the TimeStation app was to be able to input a date, start time and end time. For every session that I created, I wanted to know how much time I spent on programming by saving that log to a database. 

I started off by taking the Time.now code which returns the current Local Time and I assigned it to a @time instance variable. I then created an initial class, with methods that I tested in my console. The resulting code was the following; 

class Timer    def start_time       @time = Time.now        return(@time)    end   def end_time      if Time.now - @time < 60.to_f      return(Time.now - @time).to_f    elsif ((Time.now - @time) / 60 ).to_f > 60      return((Time.now - @time) / 3600).to_f   else     return((Time.now - @time) / 60).to_f   end   end end

When I took that chunk of code put it into my console to test, everything worked. 

2.1.4 :056 > TimeStation.new => #<TimeStation:0x007f892bdd7b40>  2.1.4 :057 > a = TimeStation.new  => #<TimeStation:0x007f892bdcfc38>  2.1.4 :058 > a.start_time  => 2015-01-13 18:07:12 -0800  2.1.4 :059 > a.end_time  => 3.622796 

Hooray! This is the first real chunk of code I have written myself, as simple as it is - it worked! After getting this first initial chunk of code to work, my next task was to create a web app that allowed me to create and save multiple time chunks. 

Rails makes things very easy. I ran the following command in my console to give me a head start on the structure of the application:

Rails generate scaffold Timer Day:Date start_time:time end_time:time

Now that I had the ability to create, destroy, edit etc.., there were a few things that I needed to change. 

1) The Time.now was rendering in the default UTC timezone and after some testing and reading I was able to change the default timezone in my config/Application.rb file. It required me adding the following code:

config.time_zone = 'Pacific Time (US & Canada)' config.active_record.default_timezone = :local

2) I took that initial chunk of code I wrote earlier and adapted it for the index.html.erb file. 

  <tbody> <% @clocks.each do |clock| %>    <tr>  <td><%= clock.day %></td>    <td><% if (clock.time_end - clock.time_start) < 60 %>           <%= (clock.time_end - clock.time_start).round(2) %>             <% if  clock.present? %>                <%= "Seconds" %>            <% end %>        <% elsif ((clock.time_end - clock.time_start) / 60) > 60 %>             <%= ((clock.time_end - clock.time_start) / 3600).round(2) %>             <% if  clock.present? %>               <%= "Hours" %>             <% end %>        <% else %>           <%= ((clock.time_end - clock.time_start) / 60).round(2) %>               <% if  clock.present? %>               <%= "Minutes" %>             <% end %>        <% end %>       <td><%= link_to 'Show', clock %></td>       <td><%= link_to 'Edit', edit_clock_path(clock) %></td>        <td><%= link_to 'Destroy', clock, :method => :delete, :data => { :confirm => "Are you sure?" } %>    <% end %></td>  </tr> </tbody>

I went to my first Ruby meetup a few days ago. It was great to be part of a community of very smart people all working towards a common goal of learning. My question to one of the programmers there was, "When would you need to use a class variable or a global variable when programming?" their answer confused me. It confused me because I had no idea how Object Oriented Programming (OOP) actually worked. 

Over the last few days I’ve been working towards developing a fuller understanding of OOP. My goal today is to describe and illustrate that in the simplest terms I can.

What is Object Oriented Programming? 

The definition as described in the Well-Grounded Rubyist is as follows; 

“Everything you handle in Ruby is either an object or a construct that evaluates to an object, and every object is an instance of some class.” If you’re anything like me, that statement will probably just confuse you.

Almost everything in Ruby is an instance of the Object class. If you’ve ever watched StarTrek, the ultimate enemies are The Borg. Essentially all of their minds are shared from a common place - the Queen Borg. In this case, the object class is the Queen Borg. Whatever thing can interact with the Queen Borg will also be able to interact with the sub-class of Borg. That’s how OOP works. Object sits at the highest point and every class created beneath the Object class (which is everything) inherits all of the methods that can interact with the Object class. Let’s take a look at how this works. 

Imagine you are a chef with many, many recipes. As a chef, you like to keep track of your recipes in an online application. In order to save recipes, you are going to need to be able to create and generate a new recipe. Therefore, we can say “Recipes” are our class. When we create a new recipe like “Dill Salmon” we need to make sure it is an instance or exists from the Recipe class. 

Here’s how we would create the necessary code to create that recipe 

class Recipe     def initialize(cuisine, protein, *ingredients)     return [cuisine, protein, *ingredients]     end end

dill_salmon = Recipe.new()

dill_salmon = the object or instance that was created from the class recipe Recipe = The class that we created. new = a method that we are able to use that interacts with the Recipe class. This ‘new’ method is actually inherited from the Master “Object Class”. There are many of these methods that are inherited from Object Class, ‘new’ is just one of them. 

Now that we’ve created a new instance of Recipe called dill_salmon, we can add some content to this by using our method called ‘food’. ‘Food’ interacts with the Recipe instance of dill_salmon. 

dill_salmon.(“American”, “Salmon”, “Dill”, “Olive Oil”, “Red Wine Vinegar”, “Salt”, “Pepper”).  >>  ["American", "Salmon", "Dill", “Olive Oil", “Red Wine Vinegar”, “Salt”, “Pepper] 

We now have the dill_salmon recipe created.  Now if we ever wanted to search by ingredients, cuisine or protein we would need to define new methods that would interact with the objects. By doing this we first need to make a few changes to the food method by creating instance variables of the attributes we passed for cuisine, protein & ingredients. 

class Recipe < Object   def initialize(cuisine, protein, *ingredients)      @cuisine = cuisine      @protein = protein      @ingredients = *ingredients      return [ @cuisine, @protein, @ingredients ]   end   def cuisine      return(@cuisine)    end   def protein     @protein   end   def ingredients       @ingredients   end   def everything      return [@cuisine, protein, @ingredients]   end end

We can now call our new methods on our instance object of Recipes. 

dill_salmon.cuisine  => “American” 

dill_salmon.protein => “Salmon”

dill_salmon.ingredients => [["Dill", "Oil", "Vinegar"]] fdill_salmon.ingredients

=> ["American", "Salmon", ["Dill", "Oil", "Vinegar"]] 

Lets talk about variables. Variables in programming are like legs are to a chair, absolutely necessary! Variables make clean and sexy programming possible. Instead of having someone write something like “All Pies are Delicious” (forget about the validity of that statement), you might want to assign a variable to that phrase. For example; 

Pie = “All pies are delicious”   => “All pies are delicious” Pie + “ , especially blueberry”   => “All pies are delicious, especially blueberry”. 

That is a variable. Now you can imagine when you have to use the same code over and over again, by assigning a variable to it you are saving space and making much cleaner code. 

Now there are several types of variables: local, instance, class and global variables. For the purposes of this post I am just going to focus on local and instance variables. 

A local variable is a variable that works only within the defined area. For example, lets say that you have a recipe that you use at home, and that recipe requires a mixture of salt, sugar and thyme. You create a jar of the perfect mixture of ingredients and you call it Thymer, that is your generated variable. If you go to create another recipe that requires salt, sugar and thyme - you are not able to use Thymer because it does not have the right ratio of ingredients. It won’t work and will ruin your new recipe.  In code, our recipe might look something like. 

def recipe1   thymer = 'sugar, salt, thyme’   ingredients = thymer + ‘ meat, flour' end

puts recipe1    => sugar, salt, thyme, meat, flour

And we can see that the local variable will work when it is defined within this recipe method. However, if we try and use the ‘thymer’ variable in another method it will ruin the recipe and in the case of programming, it causes an error. 

def recipe2  ingredients = thymer + ‘ blueberries, pie crust’  end 

puts recipe2 causes an error because “thymer" has never been defined within the recipe2 method, and therefore will not work with local variables. An instance variable will allow this example to work. The difference is small, but it will make a big impact in the way the code works. The small change is that we are changing the variable ‘thymer’ to ‘@thymer’. 

def recipe1   @thymer = 'sugar, salt, thyme’   ingredients = thymer + ‘ meat, flour' end

puts recipe1  => sugar, salt thyme meat, flour

In recipe2 thymer will work and when we call the method the full recipe will be returned. 

def recipe2   ingredients = @thymer + ‘ blueberries, pie crust’  end 

Just finished the fantastic and free Rails tutorial over at https://www.railstutorial.org. My finished application can be viewed here. 

What I liked about Michael’s tutorial is that he focuses in great depth on making sure you are getting exposed to the best practices of developing from the start. As an absolute newbie that is going through the programming of the application and the learning of new concepts - it is a lot of stuff to take in. I made mistakes on virtually every chapter and I had the opportunity to spend time troubleshooting my code and to figure out what was broken. Without the tests, it would be incredibly difficult because I might never realize it is broken until it is too late. So can I competently build an application now? - No. Do I have a better idea of how the elements of an MVC framework interact with each other or why developing tests are so important? Absolutely.

REST  - It stands for Representational State Transfer, and it’s an architecture or set of rules that can be used wherever HTTP is being used. It argues for which ways GET, POST, PUT and DELETE’s should be used. 

HTTP - Hypertext Transfer Protocol is the basis of the World Wide Web. It allows for the sending of documents back forth on the web between two different roles: server and client. For example, a webpage that you visit all of time is the client. The server is the computer running the application in the background. HTTP has some very important verbs associated with it: GET, PUT, DELETE, and POST. 

GET is the simplest request method. Every time you click a link on the inter webs, a GET request is sent to the server that says something like “Hey, I need that information about how many users to display on this page. ” That information is sent to back to the client (the webpage). GET requests are read-only and will not affect the server side information. 

PUT requests are used to create or update a resource at the exact URL given. Most commonly this is used in a RESTful development. PUT’s will be used to update the resource. For example, when you edit your account information on a forum, this would be a PUT request if the web application is adhering to RESTful development. 

DELETE will terminate all data associated with the resource. 

POST is much more robust and will typically be used to create new information for the resource. For example, if you are adding a new book to a web application you might use the POST action. Creating a new book could store the information for that request in the same URL identified or a different URL, or triggers a different action whereas a PUT has to be at the exact URL.

DRY - Don't Repeat Yourself. When developing applications and given the opportunity to remove any repeats - take it. In Michael Hartl tutorial I have been working on, the login and signup pages used very similar embedded ruby fields that I took out and have turned into a new partial that I can then refactor and render on 1 line of code. 

In Chapter 6 of Michael Hartl's tutorial I just finished building user authentication for my application. In the past, through the OneMonth Rails tutorial I used the Devise gem and thought it was the coolest thing in the world. It seemed like magic because I had no idea how it worked and thought I would need to be coding for years before I could build something like that. Well, I was wrong. 

Michael unearthed the mystery of devise, and walked me through the steps needed to setup my own authentication system, including tests. The most complicated aspect of this process was the code needed for the email authentication. For example, I wanted to accept [email protected] as a valid email but reject foobar.test@gmail..,com.

I’ve just gone through Chapter 4 of Michael Hartl’s Rails Tutorial. This chapter focused primarily on Ruby: Strings, Arrays and Hashes. 

I’m starting to get a grasp on what can be achieved through using these, but I have so far to go before I have a comprehensive understanding of the concepts.

On the highest level and most basic levels - here are my explanations.

Strings.

Michael argues that strings are the most important data structure for web applications. In other words, I need to learn what a string is capable of inside and out. 

For now, I’m just going to touch on literal strings. Literal strings are sort of like throwing a ball back and forth with a friend, if that friend always threw the ball back at the same velocity, arc and spin that you threw it at. In Ruby a literal string is when you take a double or single quotation and you input values into it. Ruby will return back the string as exactly what you input into it. For example, when inputting “Turkeys” as the string, it will print “Turkeys” out. 

Arrays

Arrays are a list of things in a particular order. You're in a line? That line you're in is an array, or would be if we lived in the matrix. Take the red pill Neo! An example of a very simplified array is: giant = [1, “giant”, “fee”, “fy”, “fo”, “fum”]. Next time I call the array “giant” it will display the array as it was inputted. By applying a little bit of Ruby we can type giant.reverse and it will send us back [“fum”, “fo”, “fy”, “fee”, 1]. 

Hash

Hash’s are complicated. They seem to be quite similar to arrays but here goes my explanation. Unlike Arrays, hashes are assigned a key and a value. You might use a hash when there is a great depth of information and you want to decrease the time it takes to search through one very long array. 

An Array will be indexed. Eg..,

Food = Array.new  Food = %w[Indian, Chinese, Thai, German]. Because each of these are in order ie.., Indian[1], Chinese[2]. We can type that array to return a value. Food[2] will return us “Chinese”.

A hash on the other hand is something that has a key and a value. For example if we wanted to break down each cuisine into more detail and know what dishes are my favourite - we might turn them into hashes. 

Food = Hash.new Food = { indian: “samosa, butter chicken”, thai: “cashew chicken, pad thai”, chinese: “fried rice, hot and sour soup” }

As of today, I have worked my way through the OneMonth rails course from Mattan Griffel and the first Rails for Zombies Tutorial created by the team at Envy Labs. 

OneMonth by Mattan gave me a great introduction to the Ruby on Rails framework. I got to set up a local environment, develop my own application (of course Mattan held my hand through the whole process) and unleash my app live into the world in under a month. The best thing about Mattan's course is that he took so much of the mystery out of programming for me. Mattan doesn't go into a wealth of detail on subjects but he did a fantastic job at introducing me to the world of programming and rapid development. 

Over the last few days, I was able to go through the Rails for Zombies Tutorial created by the team at Envy Labs. While I'm totally grateful they made their first course available for free - I wasn't crazy about it. I really wish their tutorial was about working within my local environment instead of working within their small development window. The production value at Rails for Zombies is top notch and they did introduce me to some new concepts that weren't covered in OneMonth. They further helped me reinforce some of the concepts I learned or read about through Mattan and Stack Overflow. At this time I will not be pursuing the Rails for Zombies advanced courses but I may revisit them in the future. 

I am now throwing myself full fledged into the rails tutorial written by Michael Hartl. So far this book is fantastic, it's well written and covers the latest version of Ruby on Rails. As someone who is new to programming I am extremely happy that I went through the previous tutorials before jumping into this book. I already had my local environment setup, I had some general working knowledge and so far  I have been able to trouble-shoot problems with relative ease. 

The most important thing I have learned today?  Setting up your test environment. Through Michael's tutorial you download a gem called "Guard" and guard will constantly monitor the tests you have in place. For example, if you save a file you are working within and there is a test in place that is related to that file, Guard will immediately check that it passes your test. As Michael puts it "Guard will run the right tests when the integration tests and views are updated 

What the hell am I doing? I have been pondering this for a while. When will I take the plunge and learn to program. If I don't it may be a decision that I regret for a very long time. I've recently graduated from University at 26, and until now I've been working within Software Sales.

My goal is to learn how to program Ruby on Rails within 5 months. My decision to do this comes in light of recently being laid off from my job. I have all of these ideas in my head and no way to bring them out. I want to build products. 

I chose Ruby on Rails because there are a great number of tutorials, books content and gems that allow me to jump into the language and learn on the fly. 

As of today, I'm already entirely through the One Month Rails course. Mattan Griffel really makes learning Ruby on Rails seem easy. You can see my basic application here. 

I will use the following Documentation to help me grow my skills 

http://onemonth.com  https://www.railstutorial.org/book http://www.schneems.com/ut-rails/ http://www.tutorialspoint.com/ https://www.railstutorial.org/book http://railsforzombies.org/ http://lynda.com  https://rubymonk.com/ https://coderwall.com/welcome http://railscasts.com/ https://pine.fm/LearnToProgram/ http://learnrubythehardway.org/book/ http://www.learnrubyandrails.com/

And my goal is to build the following applications. 

1) Build a todo list application.  2) Build a website application for a popular game.