The Last Days of Bootcamp

The bootcamp is just about over and I haven’t blogged in a bit.

Let’s start with a little bit about last week.

About Last Week:

Last week was mainly about planning to take the belt exam on Friday. I wrapped up a couple of assignments at the beginning of the week and by the middle of the week I was ready to work on the belt exam prep test. If I never mentioned it before – the belt exam is a test taken at the end of three weeks of every stack to test our knowledge of the stack. During the test, which are given 4 1/2 hours to complete, we get a wireframe of what we need to do and instructions of what our final product should expect to have. There’s always a login/registration page, which after a successful attempt should log a user into their page which includes things like where you can add an item such as an event, a show page – which shows more about a particular event and sometimes a table of all the events added by every user.

We took our exam Friday afternoon and I have to admit that I felt I did better at my first attempt than I have on past exams. I managed to finish deploying within the next our the test is over and was on my out the door by 7pm.

This week…so far:

The week started of with a small group in my cohort. It was our last week, which is time we spend working on a project, catching up on past material we may have didn’t grasp or couldn’t get to or retaking our belt exam if we felt the need. On Monday, there were about 5 people here from my cohort. I worked on updating my personal website and going over some stuff on my exam from Friday and making the finish product look nicer.

On Tuesday there were a couple more people that trickled in and I had a tough time concentrating because I’m very exciting for the end of the program. I received my belt exam results back and found out that I received a red belt – which in my case was 1.3 points away from a black belt. With that news, I decided I’d head home since I knew I wasn’t getting any work done. At first, I told my instructor I wasn’t going to retake but after my 30 minute train ride home, I decided to regroup and to retake on Saturday.

On Wednesday, I didn’t go in to the dojo – I wanted to stay at home to concentrate in silence so I could go over what went wrong on my exam. One of my main issues is that I had extra information in my table that didn’t need to be there – it was as if the query I had been used was looping multiple times and I found out later that that was the case. To fix this issue, I wracked my brain for hours before taking a break to run some errands since I was at home. When I returned I felt revived and went straight to my computer and got to work. Turns out I needed to to do a join and select the columns I needed from each table so I could just loop through them and get the data I needed one time instead of multiple times. Here’s the query I used:

@lend = Lender.joins(:histories).select(“lenders.first_name, lenders.last_name, lenders.email”).select(“histories.amount, histories.borrower_id, histories.lender_id”)

This query joins the Lender and History tables and selects the lender’s first and last name and email. It also selects the histories amount and id’s of both the borrower and lender. Once this was set into place, it was easy to loop through this to get the information for my table as below:

  <% @lend.each do |help| %>

      <% if help.lender_id == session[:user_id] %>

       <tr>

        <td><%= help.first_name %> <%= help.last_name %></td>

        <td><%= help.purpose %></td>

        <td><%= help.description %></td>

        <td><%= help.needed %></td>

        <td><%= help.raised %></td>

         <td><%= help.amount %></td>

      </tr>

    <% end %>

  <% end %>

I felt pretty accomplished after this – It may seem like a small feat to anyone else but it took a long process to come up with the query to use. I used my rails console to try out different queries in order to figure out which one would give me the data I needed.

Making Tests Work with RSpec and Capybara in Rails

This past weekend I worked on the next section which was Rails II – basically we were to build the project and utilize testing to make sure it would work. There were different levels one could do to complete this assignment: 1. Do the assignment without testing 2. Make the assignment work with the testing they provided on the platform or 3. Write your own tests in addition to the ones that were provided. This assignment was like a series, in which we add onto the project with each assignment we complete. We were given a wireframe and the tests and were set loose.

The project is to login or register a user, upon logon this page will redirect to the users Secrets page where a user can create their own secret, show the secrets they’ve liked or delete secrets they’ve created. There was a Secrets page which displayed all the secrets, allowed only the user logged in to like/unlike or delete the secrets they’ve created (much like the users’ show page). Along the way, we also implemented User Authentication (which is how we allowed only the logged in user to navigate through the app)

It turns out it’s as easy as putting a method at the top of our UsersController:

before_action :require_login, except: [:new, :create]

The above code states that before you do anything, go to the require_login method which verifies if the user is indeed the user that’s logged in via the session[:user_id] variable. The exception in this case is the new and create methods — A user should be able to access the page to create a new session by logging in or registering as a new user.

In the Secrets Controller, we added this code:

before_action :require_login, only: [:index, :create, :destroy]

Which states that before you go to any method, make sure that the user trying to access the page is indeed the user that’s logged in (as above) and if not, redirect that person back to the page where they can create an account or login. In the only:  tag, we allow only the logged in user access the index, create and destroy methods. We created tests for these methods.

Next up is the User Authorization. This is the code that’s put at the top of our UsersController:

before_action :require_correct_user, only: [:show, :edit, :update, :destroy]

The require_correct_user is used to define if the user is the one logged in and if not, redirects that user to their own page so they aren’t able to view everyone else’s pages…here’s the method defined in the application_controller:

  def require_correct_user

    user = User.find(params[:id])

    redirect_to “/users/#{current_user.id}” if current_user != user

  end

The last part of this section was to create our own tests for the User Authorization and User Authentication. I’ll leave you with some snippets of my tests:

likes_controller_spec

likes_controller_spec_2

TDD with RSpec

The end of last week was spent doing Test Driven Development with RSpec. The idea of test driven development is to test each feature in a project, fail that test, write code that makes that test pass, repeat. Each method, each feature should be tested to ensure it works correctly.

RSpec is one of the most popular testing frameworks in rails. It can create instances of your controllers, models and views and test them, it tests whether the routes are set up properly, it tests that the request and response is received from the server and tests regular Ruby classes…It’s pretty powerful tool to have.

We used expectations in the Coding Dojo console. Mainly, expect and to…meaning expect(page).to have_text(“The Dog”) which translates to expect the page to have the text “The Dog” on it, of course this after an action has been made. It’s pretty cool that it translate to plain English.

Then there’s the describe method which is used to list what the controllers and methods are supposed to do, for instance you can ‘describe’ a CodingController by saying that ‘it’ should show all coders. When describing Controller classes and methods, you should always put in require ‘rails_helper’ so it can find the controller or method you wish to describe. We also testing the models to make sure the validations and relationships were working properly.

We were introduced to Capybara which tests the actual user expectation when visiting a page for example you can declare statements like these ‘visit “/coding/new”, fill_in ‘New’, :with => “Tiffany”

And finally we testing for features of the page for example it “prompts the user fields”

After a few assignments, I cruised to the next section.

Controllers and Views in Rails:

This post is long overdue! We learned about Controllers and Views last week.

If you do something like this to make a new controller: rails g controller products index new

this is what’s called rendering by default what this means is that the method will attempt to load a view by the same name of the method (Rails automatically creates a view when you create methods in the Controller). The only way to prevent this behavior from happening is to render another view or redirect to another method.

To render another view: Specify using ‘render filename’ or ‘render folder/filename’ – if it’s in a different view folder. If a user registers to your page and the registration failed, then you want to render a page, this allows the page to display an error message and doesn’t save anything to the database. Rendering allows the error message to be displayed in an @instance_variable to display the view page.

The second option is redirect_to: redirects the browser to another controller/method…sends another HTTP request. redirects_to doesn’t actually load another view, it calls another controller/method to render a view. Use redirect_to when a user logs into your site and redirect them to another page because you don’t want to submit an HTTP request.

After a render and redirect_to: the code after those statements are ran.

render: works the same as var_dump and die() that we used in PHP

Passing variable to the view in Rails: Just put an @symbol in front of the variable name in the Controller that you want to make available in the View.

I completed a few assignments to day: All were pretty simple – straight the point. Most notably the Random Name Generator and the Survey Form all which we have done before in different languages so once you’ve seen it once, it’s pretty easy to tackle. Plus, these assignments are merely to get our feet wet in the language and be comfortable assigning instance variables, session data and flash data plus being about to show information in the views.

First Week of Ruby on Rails

We started Ruby last Monday. I have to admit, I wasn’t  fan of it, it was pretty loose language in that I felt like the rules could be bent quite far and it seemed like anything was possible. There were lots of functions used and some were representative of doing the same thing like .select and .collect. I was also not the biggest fan of not using curly braces and semi-colons. We resettled around with Ruby for a couple days learning how to declare functions, use all the built in functions and utilizing classes.

We learned of TDD – Test Driven Development and I can see right now how important this will be and how much more I’m going to have to practice at it. The platform for Coding Dojo explained on particular test: expect(project.name).to eq(“Project Name”)

but I later found out, by looking online that there were far more tests to include. It’s so much information that after we go through the Rails section, there is full section solely for TDD. I’ll have to go back through the module before we move to the full TDD section which will probably be the close to the end of next week.

Then we learned Rails…Now, this was a bit more cooler in that you can do a lot by not really tying a lot…This could be dangerous once we really know what we’re doing :).

We learned how to navigate the Ruby console, we installed the ‘hirb’ gem which allows the information received from queries to show up in a handy table that’s easy to read. I really wish there was a way to declare ‘hirb’ in every gem file instead of having to declare it each time but it’s okay, I’ve pretty much gotten used to declaring it by now and enabling it in the Ruby console each time you exit and re-enter the console.

We went through the Models section and did a lot of work in Ruby console using Validations, Relationships and Migrations. The validations are far more easier compared to any other stack we’ve used – PHP or Javascript, although PHP is close second for me. This simple line of code in your class can require the first and last name through presence: true and also requires the length to be in between 2-20 characters: validates :first_name, :last_name, presence: true, length: { in: 2..20 }

Relationships are fairly easy in Rails, so far we’ve learned about referencing another model, the has_one, has_many relationship, polymorphism and self joins

Self-join – Many to many to itself. i.e. User and Friend == Friendship -belongs_to :friend, foreign_key: “friend_id”, class_name: “User”. I used these two queries to find the Users that weren’t friends with the first user:

others = User.select(“friendships.user_id as Person”, “friendships.friend_id as Friend”, “users.first_name as First”, “users.last_name as Last”).joins(:friends)

others.where.not(“Friend = 1″)

Polymorphism: A table that could be used for multiple relationships.We used the Blog/Post/Message assignment to create polymorphism: Blog/Post/Message =  Each user can have many comments, Each blog can have comments, each Post can have comments, Each message can have many comments. Example schema: commentable_id, commentable_type

After the first week, I’m more comfortable with the fact that we don’t use semi-colons and curly braces. In fact, the language looks quite nice without all the closing braces, plus it reenforces the fact that tabs and spacing does matter and makes code easier to read. All in all, it doesn’t seem to bad and I am warming up to Rails!

Wednesday – June 1, 2016 – Preparing to Retake the Exam

It’s the first day of June and 5 more weeks to the end of the Dojo!!!!

This morning

This morning I arrived at the Dojo at my regular time – 8am. I spent a little time, researching jobs in Angular JS to see what most of the requirements were and to get some motivation on how much more experience I need to be considered for a job.

I spoke with my cohort mate about his project – Basically, I needed to study for my belt exam to ensure I knew the key concepts so I could even start looking for a job. Him and the rest of the group continued on without me, I wasn’t too bummed out because I knew majority of the site was functioning well…He ended up taking over the part where his checkout page needed to access the id of the product page I built up. I still didn’t get a chance to work on the modal but I heard him say that he wanted it all functioning first before that gets completed anyway.

Reviewing for my Exam & Learning New Things

So, I spent the rest of my day going over the last exam I failed and working through it. The part I had trouble with was populating the data so I could access the name of the person who wrote the particular answer to a question – The user information was nested inside of an object array so I had to do a deep populate which is as easy as putting the path and model in an object like so: populate({path: ‘answer._person’, model: ‘Users’}) …Which I learned from our instructor last week. After hours of scouring the internet, looking at the video published on the first exam and just plain thinking it through, I came to the conclusion that all I need to do was to do the same deep populate in my show function! Crazy isn’t it?

You see, I called on my client factory in the client controller for my show function; after calling the server route, I went to the server controller where I found the question by id…the problem is every time my results came back, I wouldn’t have the person who made the comment…I just needed to populate it in while in the server controller and then I had access to the name I needed! Pretty easy.

Another thing I figured out is that if I wanted to call a function (that was already declared in my client controller) as a callback inside of another function in my client controller, I had to save the results of the callback the same as the result of the original function – For example: I saved the results of my show function as $scope.answers…which means when I called it again, I had to save those same results as $scope.answers. My guess is because since you’re calling the same function it has to have the same name for the results or else, in my experience, you get a yucky error.

Ready for the Exam

All in all, I learned a lot today and feel way more confident about taking my exam tomorrow! The things I’m worried about are not having enough time to finish, developing the mongoose schema and not messing up while deploying. In the past, we didn’t have to do a video demo of our exam and we had until the end of day to deploy – I found out over the weekend that our current instructor left for good to go pursue other things so I had to reach out to the lead instructor to see what I needed to include so I won’t get dinged because of things I don’t have…Turns out a demo video is needed within the hour after the exam is completed — I did a practice recording today and feel pretty good about it — I was relieved it was pretty simple!

At any rate, I better get some sleep so I can rise and shine early to take my exam – I work better in the mornings!

Tuesday – May 31, 2016 – Working on the Group Project

It was a busy day today – I started the morning off meeting with my group for the e-commerce site we’re working on. I was to finish adding the products so they would show on the site for the users. I was able to add the products correctly using my addProducts.html page I built out and the ProductsController I built out last week…Well, one of my team members told me they built out the adminProducts page, which meant I had to use that to add the products since only admins are able to add products to the site. I finish this and showed the team member whom will have a relative use this site in the future, he approved of the products page but wanted me to add a feature to enlarge and show additional images of the products…I didn’t know how to do that so I spent my afternoon (upwards of 4 hours) trying to figure it out. It seems so simple right? I thought.

First, I tried to implementing using Fancybox Lightbox alternative –  it was pretty cool but it required many more links that I desired – our page already had enough links to bootstrap and our various factories and controllers. It was working fine when I tested it underneath my original images that were output via the ng-repeat…but I couldn’t get it to work properly.

Before I left for the day, I managed to add the button to add a product to the cart, problem is we don’t have a cart created yet so we agreed to just add the items to the checkout partial.

Another solution I tried was to use Bootstrap modal – seems like a good idea right? It actually is but I am still having trouble displaying all the information for each picture. For example, I use the ng-repeat and ng-src for my image tag – Bootstrap doesn’t like that because a picture never

shows up. After coming home, I am still sitting here trying to figure out to implement this feature…I’ve found a few things to help get me started tomorrow – A w3schools tutorial but this is only to display one picture…So, I figured, why not just implement a carousal – I found Bootply code to implement this – I would of course I have tweak it to make it work for this project. I also found a stack overflow issue of someone who was having trouble using ng-repeat (like me) – The only option is to push the items into an array which I’ve seen twice already…I’m thinking this may be the only option.