#learningtoprogram

Somehow...joining this coding boot camp is giving me stress but I am having fun. Currently working on my first app and I gotta say...

Coding helps with me fear of failing. I legit would put off working on a code because I would fear failure.....

Now I fear the lack of sleep and possibly failing the class.

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>

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