#questtoprogram

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

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.