1. Testing and Refactoring Our Interaction Process

    Wednesday, Week 6, Day 21, Jen, Josh, Stephanie, Rob, Wale, and Pivot John

    Ruby Meetup


    We opened the night by discussing our upcoming talk in front of the LA Ruby meetup group tonight. Understandably, some of us who hadn't given presentations since college were a little nervous, so went went through some exercises to help us relax. Getting up on the stage where you needed to speak beforehand seemed like a great one; it would let you feel out the energy of the place first so when you go up for real it isnt a huge shock.

    Testing our process


    We then went through our Manual of Mob, reaffirmed which practices worked, which ones we had been straying from, and discussed if we needed to add new guidelines. WE talked about what hapens when we really get into a flow, how that state occurs, and what we can do to sustain it. For example, what happens when someone has a question but doesnt want to break the flow? Should they wait? If so, for how long? We deduced that our mobbing has naturally evolved to happen in three phases: a Q&A Phase where we figure out a general direction, a Tangent Phase where we examine the different ways of doing this, and a Driving Phase wherein we write the actual code. WE decided to Implement a "Pause before you Drive" rule. Give people a chance to ask any residual questions before you just go typing away.

    Solutions through Ruby


    When deciding Mobbing order, we usually write it on the whiteboard so that we're all on the same page. Naturally, as humans do, we sort of get into a patterned order of who drives who etc etc. To try to reduce this we wrote a little ruby shuffle program that just randomizes the order of all our names and spits out a little list. Much better and faster than drawing names out of a hat.

    Testing Code


    Once we established our order we started coding by writing tests to insure that some of our models had unique identifiers. What we had thought was unique before turned out not to be after we filled them with a bunch of sample data. We decided to give them a unique key that was based off of two other fields. This combination would be unique for every single one. Then we wrote tests that insured that we could look-up using that unique ID pair. This took us on a bit of a tangent regarding syntax in testing. There are a ton of different testing frameworks for Ruby out there, rspec, capybara, and cucumber just to name a few. All of these testing frameworks have different syntax but they're all based upon the idea of a fixed state box. We closed the night by talking about testing structure, Every test has the same basic structure, they

    • A: Arrange a state.
    • B: Act on that state.
    • C: Assert what changed.

    Once we truly understood this concept it opened up a whole new world to us.

    Published on

  2. Creating an API

    We wanted to create a find method that would enable us to access any given Adventure, Objective, or Narrative instance. Each Narrative belongs to an Objective, which belongs to an Adventure, and all of these have unique ids.

    We wanted to be able to look them up by the ids. Each individual objective is an instance of the objective class.

    API stands for Advanced Programming interface and is basically anything you can use to request information. Our API will request information about instances when it passes in the id.

    We discussed the difference between private and public methods, and explained how protected works.

    We wrote a test for this, even though this story was a chore. One thing to remember is that if the code executes in production, there should be a test for it, even if it's a chore.

    Published on

  3. Successful 301 Error

    We finally were able to get a successful 301 error in our browser. We did this by using the Rack gem.

    We used Rack to build an app on Heroku that only returns a 301 status code and the we changed the code that Emerald types in to be $ Net::HTTP.get_response(URI("http://prettyp.herokuapp.com")).code


    Domain Modeling

    Ryan helped us figure out the relationships in our data so we can relate

    If you are using ActiveRecod (which we are not right now) you would use a command like this to find the id paramter from the unique id that is generated. Adventure.find(4)

    Adventures

    title
    id
    introduction
    later...(adventure array)

    Objectives

    title
    id
    learn.narrative
    submit.narrative
    review.narrative
    expected-output
    later...(objectives array)


    Class constructors in Ruby

    When you use new method, you get 'reference' on newly created object. The puts kernel method returns some internal ruby information about this object. If you want to get any information about state your object, you can use getter method:

    class Adder
      def initialize(my_num)
        @my_num = my_num
      end
      def my_num
        @my_num
      end
    end
    y = Adder.new(12)
    puts y.my_num  # => 12
    

    Or you can use 'attr_reader' method that define a couple of setter and getter methods behind the scene:

    class Adder
      attr_accessor :my_num
    
      def initialize(my_num)
        @my_num = my_num
      end
    end
    y = Adder.new(12)
    puts y.my_num  # => 12Class constructors in Ruby
    

    When you use new method, you get 'reference' on newly created object. puts kernel method returns some internal ruby information about this object. If you want to get any information about state your object, you can use getter method:

    class Adder
      def initialize(my_num)
        @my_num = my_num
      end
      def my_num
        @my_num
      end
    end
    y = Adder.new(12)
    puts y.my_num  # => 12
    

    Or you can use 'attr_reader' method that define a couple of setter and getter methods behind the scene:

    class Adder
      attr_accessor :my_num
    
          def initialize(my_num)
            @my_num = my_num
      end      
    end
    

    y = Adder.new(12) puts y.my_num # => 12

    Published on

  4. Finding Ways that Won't Work

    Thursday, Week 5, Day 18, Wale, Jen, Pat, and Pivot Eric.

    Battle of The Gets

    Today we ran into issues with calling a specific status using Net::HTTP::get_response. Where Net::HTTP::Get worked on the page we were using Net::HTTP::get_response returned to us an "Application Error".

    The mystery of Net::HTTP::get_response deepened when we tested it with outside websites and had successful returns. We then tried changing the status of the original page we were using but still encountered the “Application Error”.

    After being unsuccessful with Net::HTTP::get_response, Pivot Eric suggested we check out the file for the page prettyp. At our next meeting we will follow his suggestion and hopefully solve the mystery.


    Things We Learned

    Wale learned the differences between Net::HTTP::Get and Net::HTTP::get_response: Net::HTTP::Get provides a string. Net::HTTP::get_response calls a specific part of the webpage. In our case we were using get_response to call for a web page status.

    Pivot Eric dived into what "|" (pronounced as "pipe") does. "|" allows you to pipe information from one program into other programs.

    Last we learned that Heroku cuts off webpages that take longer than 30 seconds to load.

    Things We Were Reminded Of

    Pivot Eric reminded us to practice the good programming habit of not making many changes at once. We should make changes as small as possible in order to keep track of our errors. Making many changes once assumes we are perfect human beings that never make mistakes… and if we did make mistakes we are perfect human beings who can immediately catch them. No human is that perfect.

    Published on

  5. How do you get 301 Error on purpose?

    Tuesday, Week 5, Day 16 Jen, Steph, Rob, Wale, Jalil and Mike McCormick.

    We met up at a coffee shop and worked on the narrative for a while. Mainly we started talking about the 301 Error. Jen had spent the day trying to get the 301 error in the terminal like we will want Emerald, our user, to get. This turns out to be harder than we thought.

    One of our thoughts is that maybe a 301 error is not returned to the terminal because you are either redirected and get a 200 success code or you are not redirected and you get a 404 error.

    We spent a good portion of the night investigating this idea and are only a little closer to the solution.

    Another thought is that maybe we need to use the method get_response instead of just get.

    Things we tried. Jen set up a redirected page on her site. but it doesnt return a 301 error.

    One of the cool things Mike McCormick showed us is to create a yaml file in the config/locale where we insert our code, use erb, embeded ruby, to insert it into our file. We use the translate method in the yaml and the test. So we can change the text and the tests will still pass. Previously we were hard coding our text in the test.


    Our test for this objective now looks like this:

    objectives_1_spec.rb

    require 'rails_helper'
    
    feature "Emerald visits adventure 1 objective 1" do
      scenario "emerald reads narrative" do
        visit '/adventures/1/objectives/1'
        expect(page).to have_content I18n.t("adventure.one.objective1.copy")
      end
    end
    

    The embeded Ruby in our show page which displays the copy we put in our yaml file.

    show.html.eb

    <%= t("adventure.one.objective1.copy")%>
    

    The copy in our yaml file

    config/locale/adventures.yml

    en:
      adventure:
        one:
          objective1:
            copy: " our copy blah blah blah "
    

    Internationalization - I18n - I (18 letters) n

    We used the I18n gem included in Rails to translates our text.

    In computing, internationalization and localization are means of adapting computer software to different languages, regional differences and technical requirements of a target market.
    Internationalization is the process of designing a software application so that it can potentially be adapted to various languages and regions without engineering changes.
    Localization is the process of adapting internationalized software for a specific region or language by adding locale-specific components and translating text.

    Localization (which is potentially performed multiple times, for different locales) uses the infrastructure or flexibility provided by internationalization (which is ideally performed only once, or as an integral part of ongoing development).

    The Rails gem I18n has it's specific uses.

    The most important methods of the I18n API are:

    translate # Lookup text translations localize # Localize Date and Time objects to local formats These have the aliases #t and #l so you can use them like this:

    I18n.t 'store.title' I18n.l Time.now

    (18 stands for the number of letters between the first i and last n in internationalization)

    How I18n in Ruby on Rails Works

    YAML Syntax References (http://docs.ansible.com/YAMLSyntax.html) (http://symfony.com/doc/current/components/yaml/yaml_format.html)

    Published on