Archaic Positives

Adventurer, Traveler, Rubyist

OmniAuth: An Introduction

OmniAuth is simply middleware for authenticating users in applications. Middleware is a way to filter requests and responses that are coming into your application. Each strategy that is used in the OmniAuth middleware is a class, and each strategy has two primary phases: a request phase and a callback phase.

Let me take a step back, and explain what middleware is. Middleware is the interface that communicates between the application and the web server. In a way, it is generally a software library that assists with, but is not directly involved, in the execution of a specific task. Some examples include authentication, data logging, performance monitoring, caching, and the like. In this particular case, OmniAuth is dealing with authentication.

config/initializers/omniauth.rb
1
2
3
4
Rails.application.config.middleware.use OmniAuth::Builder do
  provider :twitter, ENV['TWITTER_KEY'], ENV['TWITTER_SECRET']
  provider :facebook, ENV['FACEBOOK_ID'], ENV['FACEBOOK_SECRET']
end

The two providers in the initializer above are called strategies. A strategy, in OmniAuth’s case, is a specific authentication class within the OmniAuth middleware structure. OmniAuth has a large number of strategies, available at its Github documentation wiki, that provide authentication services for a wide number of websites, such as Twitter, Facebook, Github, and others (SOURCE - https://github.com/intridea/omniauth/wiki).

Let’s walk through an example with Github. In the request stage, a client sends a request to the app. The client is redirected to the /auth/Github route, and it points to the OmniAuth Github strategy specified in the config/initializer directory within the Rails project structure. In order to properly authenticate the user, an authentication request is fired off to Github through the provider strategy. Once the user is properly authenticated, the callback method, specified through /auth/github/callback, creates a user information hash that can now be accessed through the app (SOURCE - https://speakerdeck.com/xfernandox/the-anatomy-of-omniauth).

Explanation of NGinx and Passenger

NGinx is a open-source proxy server that primarily serves HTTP and HTTPS protocols. Nginx was created to achieve three main goals: concurrency (process in which computations are executed simultaneously across several systems), high performance, and low memory usage. It utilizes an event-driven approach to server requests, and allocates responses based upon server traffic and handling. It has become a viable alternative to the Apache server model, which uses a process-driven methodology for handling large server requests.
NGinx has emerged largely as a result of increased demand for online services and the rise of the web as a platform. Unlike Apache, NGinx has a master process that delegates work to worker processes, and it is designed handle a large number of server connections with a small amount of memory.

A number of companies, according to Wired, have run into scalability issues with Apache, and have transitioned to NGinx. Facebook, Dropbox, and Wordpress are sites that utilize the NGinx server platform.

NGinx does not have a module load feature like Apache does, but that is where Passenger steps in, as it automates the module loading process.

Passenger is an Rack application server software that is often used in conjunction with NGinx. Similarly with mod_php for hosting PHP apps on Apache, Passenger simplifies the process of hosting Ruby apps on NGinx. Passenger automates the process of starting/stopping a server, restarting after a server crash, and dynamically adjusts the number of processes on a server based on traffic. It also allows the server to run more than 1 instance of the app, allowing greater use of server resources.

Abstraction: Path to Simplicity

Abstraction is a concept that I have been thinking quite a lot about lately. It is a concept that has largely been foreign to me, and it is slowly dawning on me that abstraction lies all around us.

The Webster Dictionary defines abstraction as a “general idea or quality rather than an actual person, object, or event.” If we took the literal translation of the root abstractus (past participle of abstrahere), we would get “to draw away; to detach or divert.” This term was first used by Oswald Herzog to describe the artistic attitudes and implementations of the Dadaists (in 1519, ‘Der Abstrakte Expressionismus’). He wrote, “it is pure creation. It does not borrow objects from the real world; it creates its own objects … the abstract reveals the will of the artist; it becomes expression.” Abstraction, in the general sense of the word, is the process by which we generate semantic meaning with a concept.

In Ruby, abstraction is key to making your code achieve two things: more readable and reusable. At this point, we’ve learned to make our code more abstract via many concepts, such as MVC, ReST (Representational State Transfer), migrations, database abstraction via ActiveRecord, and routing.

A major component of Ruby on Rails has really nailed down the abstract aspect of coding for me: ActiveRecord and its corresponding ActionPacks. ActiveRecord serves as the “Model” component relational database for Rails. It comes with a set of query methods used for creating, retrieving, updating, or destroying data in the database. The model also is used for establishing association between classes. For example, a king could have a “has_many” relationship with his subjects, while a subject has a “belongs_to” relationship with his king.

Monarchy Association
1
2
3
4
5
6
7
8
9
10
class King < ActiveRecord::Base
  has_many :subjects
  has_many :lords
end

class Subject < ActiveRecord::Base
  belongs_to :king
  belongs_to :lord
  has_many :children
end

ActionController serves as the “Controller” engine of Rails. By definition, a controller acts as the intermediary between the views and the models, and shuttles along HTTP responses, view renders, and redirects between the two. The controller logic is encapsulated into each individual method, and each method should really have only one action in order to simplify the logic behind the controller. The controller is designed to encapsulate the logic behind the app into specific CRUD methods, as shown below.

Subjects Controller
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
class SubjectsController < ApplicationController
  before_action :set_subject, only: [:show, :edit, :update, :destroy]

  def index
      @subjects = Subject.all
  end

  def create
      Subject.create(retrieve_subject_params)
      redirect_to subjects_path
  end

  def new
      @subject = Subject.new
      @lords = Lord.all
  end

  def edit
      @subject
  end

  def show
      @subject
  end

  def update
      @subject.update(retrieve_subject_params)
      redirect_to subjects_path
  end

  def destroy
      @subject.destroy
      redirect_to subjects_path
  end


  private
  def set_subject
      @subject = Subject.find(params[:id])
  end

  def retrieve_subject_params
      params.require(:subject).permit(:name, :region, :lord_id, :class)
  end
end

ActionDispatch serves as a routing engine. It is responsible for recognizing a path as specified in the model logic and dispatching it according to that route’s specific action. A route action should do only one thing, while keeping in convention via the “fat model, skinny controller” paradigm. ActionDispatch takes care of the majority of your routes through resource routing. With Rails, we can declare our index, show, new, edit, create, update, and destroy routes with one single line of code. For example, if we wanted to have a resource for our king, subject, and lord classes, you’d simply do the following:

Resources for King
1
2
3
4
5
6
7
KingdomOfValyria::Application.routes.draw do
  resources :kings
  resources :subjects
  resources :lords

  root 'front#index'
end

ActionView is the Rails engine responsible for maintaining the HTML views that are rendered to the browser. For each controller that’s present in the app, there is a corresponding app/views directory that stores ERB templates used for HTML browser rendering.

Subject View
1
2
3
4
5
6
7
8
9
10
11
12
13
14
<h1><%= @subject.name %> - Subject of King <%= @subject.king.name %></h1>
<p>Lord: <%= @subject.lord.name %></p>
<p>Lives: <%= link_to @subject.region, @subject.region %></a></p>
<% unless @subject.children.empty? %>
  <h2>Children</h2>
  <ol>
    <% @subject.children.each do |child| %>
      <li><%= link_to child.name, child %></li>
    <% end %>
  </ol><br>
<% end %>
<%= link_to "Back", subjects_path %>
<%= link_to "Edit", edit_subject_path %>
<%= link_to "Delete", @subject, method: :delete %>

Being able to effectively encapsulate your logic into separate logic categories is such a necessary skill-set to understand in order to become a proficient Ruby on Rails developer. I’m still in the process of learning how to whittle down my logic into singular methods and actions. Ruby is a language that was built for abstraction. It is meant to simplify logic in your code, and as Matz said once, “I hope to see Ruby help every programmer in the world to be productive, and to enjoy programming, and to be happy.”

CRUD Applications: Importance of MVC

This past weekend, we had an assignment to build a CRUD application from scratch (well, almost). A CRUD application is short for the four basic applications of relational database management and storage: create, read, update, and delete. The CRUD application allows interfacing between a database, a user interface, and HTTP protocols. I thought that I’d go ahead and describe the main components of our CRUD application that we built this weekend. There are thee specific ones to take note of: the controllers, models, and views.

Models are Ruby-specific classes that talk to the database, store, validate, and execute logic. In other terms, they do all of the heavy lifting for our application. They’re basically the overworked accountant in the back room during tax season, churning out numbers while eating stale donuts at an absurd rate.

Views are elements that the user sees and interface with. In short, they will provide the user experience through HTML, CSS, Javascript, and other front-end aspects. They’re the responsible ladies and gentlemen specifically positioned near the front of the office to provide a sense of culture and value to the outside user looking in.

Controllers deal with the back-end requests from users, data requests, data submissions, sessions, and so on. Any time you enter data into a form on a website, such as a login and password, you are interacting with a controller after you have hit the submit button. After the request is sent, the controller sends the response to the server, and the server then combines that data into a HTTP response that is sent back to the user.

One term that I’ve read about describes how you should structure your models and controllers: “fat models, skinny controllers.” The idea is that your models are not just a simple form of abstration in your database layer, but they represent the entirety of the logic in your application. It should be able to stand alone from the rest of the application. By convention, it should not interact with other components of your application. Each controller method also should represent one action. The controllers simply just shuttle requests between your views and your models (or your user interface and the application logic). Another primary reason why this is an important programming practice is that you have enabled 2 things: one, you’ve made it easy to reuse your code due to its abstraction and simplicity, and two, you’ve also made it simpler for testing your code.

That’s what I wanted to review in this blog post. I’ll also share some of my favorite, but terrible, puns with you. Some of you might have already heard some of these.

A truck transporting fruit in California overturned the other day. It created quite a… jam. That driver’s career is also… toast.

The other day, I couldn’t quite remember how to throw a boomerang, but eventually it came back.

Hello everyone (in Ruby 003 class on Monday, Oct 28), what is Avi’s background? Well, it’s a white wall.

RSpec: A Misunderstood Complement to Ruby

For the past few weeks, I have been dreading the moment when I would have to utilize RSpec on a regular basis. Because RSpec is the testing framework for the Ruby language, I viewed it as an obstacle to my learning development. After studying more about RSpec in the past few days, I’m starting to realize that I have been viewing its fundamental purpose incorrectly. RSpec is a complement to the Ruby developer’s toolkit – it prevents unneccesary work by testing the behaviors of a framework. In short, it is the blueprint of any application, and represents a guided set of directions that leads you to a finished product.

In this blog post, I’ll discuss the basic premise of RSpec and also discuss a few ways to refactor RSpec code.

RSpec Basic Syntaxlink
1
2
3
4
5
6
describe 'basic RSpec syntax' do
  it 'describes how the code should behave' do
      User.code.should be(clear)
      User.code.should be(concise)
  end
end

Here’s a simple example.

Calculator
1
2
3
4
5
6
7
8
describe Calculator do
  describe '#multiply' do
      it 'returns the product of its parameters' do
          calc = Calculator.new
          calc.multiply(4,5).should eq(20)
      end
  end
end

This example is to just show what RSpec was intended for in regards to test-driven development. See how RSpec determines how the calculator should behave when the multiply method is called? When given the parameters 4 and 5, the multiply method should return an integer value of 20.

Refactor a name spec
1
2
3
4
5
6
7
8
9
10
11
12
describe Person do
  it 'responds to own name' do
      James = Person.new
      James.should respond_to(:name)
  end
end

describe Person do
  it 'responds to own name' do
      subject.should respond_to(:name)
  end
end

“Subject” always refers to an instance of a class. In this case, James is an instance of the Person class, and the step of initializing a Person instance with the name James has been refactored by using “subject.”

Using ‘Expect’ instead of ‘Should’
1
2
3
4
5
describe Person do
  it 'responds to own name' do
      expect(subject).to respond_to(:name)
  end
end

This is a big change that I’ve started to implement in my RSpec tests, largely because of issues that have to do with delegation. There was a blog post (http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax) that discussed the differences between ‘expect’ and ‘should.’ My understanding of the Kernel library and the rspec-expectations are not very concrete yet, but it is partly a result of a library load. If one library is loaded before the other, it can sometimes override syntax delegations for the same word.

Another reason is that it seems a little more clear to me in terms of understanding what’s going on with the syntax, particularly when I am starting a new test from scratch. Should semantically makes sense if you’re writing tests for existing code, but not necessarily if you haven’t written a line of code yet.

The Correct Usage of ‘Self’ in a Class

One of the more confusing aspect of dealing with classes is knowing when to use ‘self’ appropriately. In the context of a Class, ‘self’ refers to the current class, and is in itself an instance of the class Class. I know this sounds confusing, but I’ll break it down for you momentarily.

1
2
3
4
5
6
7
8
9
10
11
class Dog
  attr_accessor :name, :breed

  def self.fake_bark
    "Awooooo!"
  end  
 
  def self.real_bark
    " Woof!"
  end  
end

In this example, self is referring to the class ‘Dog’. Basically, if the class Dog were to encompass all dogs alive in the world, any time that I used Dog.fake_bark, every single dog would give out a fake bark that sounds like “Awoooo!” That’s a husky or wolf attempting a feeble howl. If I were to use Dog.real_bark, then every single dog in the world would give out a resounding “Woof!”

Now let’s look at the following example.

1
2
3
4
5
6
7
8
9
10
11
class Dog
  attr_accessor :name, :breed

  def fake_bark
    "Awooooo!"
  end  
 
  def real_bark
    " Woof!"
  end  
end

When self is not included in the method, that just means that it is a method that refers to an instance of the class ‘Dog’. So if I were to create a new dog named Fido that is a labrador, then I would do the following:

1
2
3
fido = Dog.new
fido.name = "Fido"
fido.breed = "Labrador"

Fido is an instance of the class Dog. That is an importance distinction to make. Now, if I call the fake_bark method on Fido without self prefixed, then only Fido will give out that weak attempt of a bark. Every other dog in the world will be silent, because instances of every other dog hasn’t been created in the Dog class.

It took me a while before I could distinguish between the different uses of self. It’s important to note the differences, because it can be come very problematic when you start to write your own programs or applications. Self in the wrong place and lead to a lot of brain pain – I learned this the hard way. Do yourself a favor and learn all of the little nuances of the self keyword.

HAML: DRY Version of ERB?

Embedded Ruby, or ERB for short, is a Ruby feature that allows a programmer to generate text from a template. Its aim is to simplify flow control, and utilizes back-end web data to maintain repetitive front-end tasks, such as generating personalized web pages, emails, scripts, and any sort of text file. In programming speak, ERB is Ruby’s built-in template engine.

HAML, an alternative to ERB, stands for HTML Abstraction Markup Language. HAML was created with Ruby’s key principles in mind: markup should be legible, implement DRY, and be well-indented. ERB uses HTML, which is a verbose markup language, and has proved problematic in meeting Ruby’s standards for a seamless experience, and has seemingly felt incompatible with Ruby’s language due to the large differences in syntactical structure. HAML attempts to bridge that divide by creating a more seamless experience.

Let’s use an example to compare HAML and ERB.

ERB

1
2
3
<div class='dogs' id='sadie<%= dogs.sadie %>'>
  <%= dogs.body %>
</div>

HAML

1
.dogs{:sadie => "dogs#{dogs.sadie}"}= dogs.body

Look at the example above. If you’ve used Nokogiri before, then the HAML example may remind you of something. If you’ve ever used Nokogiri or an XML/HTML parsing gem before, you’ll notice that the syntax is very similar to that of CSS queries for selectors. Additionally, white space is used to denote indentation, as is the case with the “dogs.body” component in the ERB example. Interpolation is very abundant in HAML as well, and there is no need to close tags in HAML. Already, HAML has reduced verbosity significantly with just a simple example.

Let’s move on to a more complex example.

ERB

1
2
3
4
5
6
7
8
9
10
11
<div class="cat">
  <div class="name"><%= name %></div>
  <% img_tag img %>
  <div class="kittens">
      <% kittens.each |kitten| %>
          <div class="kitten">
              <div class="name"><% kitten.name %></div>
          </div>
      <% end %>
  </div>
</div>

That was frustrating typing out all of the tags. Now let’s compare that to the HAML version.

HAML

1
2
3
4
5
6
7
.cat
  .name= name
  = img_tag img
  .kittens
      - kittens.each |kitten|
          .kitten
              .name= kitten.name

It’s amazing how much HAML simplifies the markup template. I think that I’ve displayed the benefits to using HAML. However, there are two sides to this story. Because browsers are designed to only understand HTML, there are those that believe abstracting away the key elements of the HTML language via HAML (or other alternatives) makes the front-end component a little more difficult. There are also compatibility issues with CSS, particularly when it comes to web templates. WIth that said, it is important to understand ERB simply because it is a universal language, and HAML is not.

I would love to use HAML, but it doesn’t seem intuitive to use it when it is not widely utilized in the Ruby community. I looked up some simple statistics on Stackoverflow. There were 210,574 tags for HTML discussions alone, and that didn’t include more specific HTML queries (HTML5, HTML parsing, XHTML, etc). HAML had a whopping 1,831 tags for discussions. I’m not a statistician, but I believe that there’s statistical significance in that HAML is not widely accepted, and isn’t quite a complete alternative to HTML.

With that said, it’s nice to know that there are other options out there that are trying to bring Ruby’s straightforward syntax to markup languages.

Difference Between Each, Select, and Collect Methods

Each, Collect, Select

There are three methods that drive the process of data scraping and warehousing in the Ruby language. These three methods are the following: Each, Collect, and Select. These three methods are examplees of iterators; iterators are used to organize and store data into a collection. A collection can be either an array or a hash.

For simplicity, I will refer to an array throughout the rest of the discussion. I`ll follow up with a concise post on hashes.

The Each method iterates through and returns all of the elements of an array or a hash. It simply runs each element of the array through the Each code block (the function/modifier that lies between the do and end), and returns that modified value to the console. For example:

array = [2,4,6,8,10] array.each { |x| puts x * 10 }

This would result in the following being output to the screen:

20, 40, 60, 80, 100

The Each method is great for simple data modification tasks, particularly if you need to obtain the result of that modification. The major drawback is that it doesn`t provide a means to store the results of the block into an array unless you push those elements into the array. This is where the Collect method comes in.

The Collect method does the same thing as the Each method, except that it goes one step further and returns the results of the block in the form of an array. For instance, look at the following example.

array = [2,4,6,8,10] array.collect { |x| x * 10 }

This would result in the following output to the screen:

[20,40,60,80,100]

The array “array” has been multiplied by the modifier inside of the block, and the collect method has returned an array with the modified values. The returned array can then be stored in a variable, which has significant benefits in Ruby. This can be used for many applications, such as arithmetic, problem solving, variable manipulation, and data parsing.

The Select method is a modified version of the Each method, and basically “selects” objects that meet the predefined condition within the block. For example, if I wanted to filter out elements from an array that do not meet a conditional statement of some kind, I could do the following:

array = [1,2,3,4,5] array.select { |x| x > 2 }

It would return the following to my screen:

[3,4,5]

It basically will return any element of the array that, when inserted into the conditional statement inside of the block, results in a true statement.

These three statements are already some of my most heavily used components within my Ruby syntax. I’m still learning each day more and more about what they are capable of. I’m excited to learn more about more specific applications of these methods.

Problem Solving and Iteration - Week 3

Last week, we dove right into database iteration and management. We focused on the following: SQL, hash iteration, web scraping (via Nokogiri, Open-URI), and logic approaches.

SQL and hash iteration are pretty straightforward as concepts, but they are difficult (for the time being) for me to effectively implement. We had to implement these concepts in the web-scraping exercise we did last week, and I still have to go back over and do it again, just to make sure I get the concepts down pat.

So, to explain: SQL is a database tool that can be used to integrate data from hashes and arrays into organized tables. You can also use SQL to join tables together where they share common information (usually something like an ID or user ID – keys that can tie two charts together). the exercise that we did last week focused on Reddit. We used Open-URI to open a connection to Reddit’s front page, and Nokogiri pulled down the HTML data into a readable, concise format. We then used Nokogiri’s syntax to sort out the data that we needed for the exercise (Top 100 posts: name of post, URL of post origin, upvotes, downvotes).

In order to create SQL tables, you use the following command: CREATE TABLE users ( var1 TYPE, var2 TYPE, var3, TYPE );

This just creates the tables with the variables var1, var2, var3, and they are of data type TYPE (which can be INTEGER, TEXT, DATE, etc).

To insert values into the table, you use the following command: INSERT INTO users VALUES (var1, var2, var3) (“John”, 25, 2010), (“James”, 21, 2011), (“Steve”, 19, 2010);

To follow up with that, there are JOINS statements: INNER JOIN, LEFT OUTER JOIN, RIGHT OUTER JOIN, AND FULL OUTER JOIN.

    INNER JOIN - Produce only records for which there is a match from table A and table B

    LEFT OUTER JOIN - Produces complete set of records for table A, along with matching records from table B if they exist; otherwise the value is NULL.

    RIGHT OUTER JOIN - Produces complete set of records for table B, along with matching records from A if they exist; otherwise the value is NULL.

    FULL OUTER JOIN - Produces complete set of records from both tables; when there isn't a match, the value is NULL.

Moving on to Hashes. Hashes are one of the most fundamental concepts in the Ruby language, and enable a wide array of possibilities if they are properly utilized. In other languages, the hash structure is referred to as a dictionary. It has a key-value pair, so for each respective key, there is a value, just as in a dictionary, there is a definition for each word.

The way to visualize a hash is via the following: hash = { :dog => ‘canine’, :cat => ‘feline’}

How do you access the value for ‘dog’? By simply typing in hash[:dog]. This will return the string ‘canine’. How do you add a new element to the hash? By simply typing in the key you want into the key field, and setting it equal to its value. For example, hash[:elephant] = ‘mammal’ will insert :elephant => ‘mammal’ into the hash. Finally, the default return value of a hash is nil.

My objective for this week is to work on further solidifying my understanding of hashes, how to iterate through them effectively, and utimately get a web-scraping objective finalized.

Start of Week 2

Today is the start of Week 2 at Flatiron. It’s been quite a start to the semester. We spent last week going over Github, Ruby, SQL, and a lot of logic exercises to understand how to think like a computer. It’s interesting because humans understand things organically and semantically, whereas a computer is very literal in its understanding. For example, we as humans make assumptions or calculated decision-making to fill in details about another person or thing. For example, if we see a dog on the street, we assume that it’s a stray dog if it is dirty or has a disheveled appareance. On the other hand, if it is nicely groomed, we may assume that it’s simply lost. Computers have to be given a very specific set of instructions or information regarding something. In the case of the dog, we may have to do something like this: (dog = “stray”).

If dog == “stray” human.do_not_intervene(dog) Elsif dog != “stray” human.intervene(dog) End

That’s a basic if-else statement to illustrate the dog example. Basically, if the dog is a stray, the computer understands this as: “the human should not intervene specifically with the dog.” However, if the dog is not (!=) a stray: “the human should intervene specifically with the dog.”

The logic is simple, but when building programs that have more complex arguments and parameters, it can get a little confusing. Most of my time during the first week was spent experimenting with different loop types and understanding what you can and can’t do with methods, data types (arrays, hashes, strings, etc), and code organization.