The Latest

Day 105: DIP - Dependency Inversion Principle
In Martin’s book “Clean Code: A Handbook of Agile Software Craftsmanship,” DIP is introduced in two points “1. High level modules should not depend upon low level modules. Both should depend upon abstractions. 2. Abstractions should not depend upon details. Details should depend upon abstractions.” High level modules are independent of low level modules and are built around need instead of behavior. These modules wield incredible power because it contains the heart of the application. A high level module dependent on abstraction is more flexible, mobile, and strong. For this very important reason high level modules should not be dependent on low level modules. Low level modules provide details that serve high level module. If changes must be made to low level modules, it is at the request of the high level module.
This way of thinking about high level modules enables us to later reuse these modules in different context later. Any dependency a high level module has with a lower level module will prevent it from being reusable. It’s very much a Romeo and Juliet story. Therefore it is very important that abstractions and details work in isolation to prevent contamination and foster code that is easier to maintain in the long run. 

Let these words soak - I know I will. Until the next post, Happy Coding!
 
Jul 17, 2014 / 2 notes

Day 105: DIP - Dependency Inversion Principle

In Martin’s book “Clean Code: A Handbook of Agile Software Craftsmanship,” DIP is introduced in two points “1. High level modules should not depend upon low level modules. Both should depend upon abstractions. 2. Abstractions should not depend upon details. Details should depend upon abstractions.” High level modules are independent of low level modules and are built around need instead of behavior. These modules wield incredible power because it contains the heart of the application. A high level module dependent on abstraction is more flexible, mobile, and strong. For this very important reason high level modules should not be dependent on low level modules. Low level modules provide details that serve high level module. If changes must be made to low level modules, it is at the request of the high level module.

This way of thinking about high level modules enables us to later reuse these modules in different context later. Any dependency a high level module has with a lower level module will prevent it from being reusable. It’s very much a Romeo and Juliet story. Therefore it is very important that abstractions and details work in isolation to prevent contamination and foster code that is easier to maintain in the long run.

Let these words soak - I know I will. Until the next post, Happy Coding!

 

Day 104: LSP - The Liskov Substitution Principle
These past couple of day I wrote about two of the Five Object-Oriented Design Principles. Single Responsibility Principle states “a class or module should have one, and only one, reason to change.” Open Closed Principle is how “software entities ( classes, modules, function, etc.) should be open for extension but closed for modification.” Today’s principle is Liskov Substitution. 
Barbara Liskov is a computer scientist and at age seventy-four, she is still kicking ass as a current Ford Professor of Engineering in MIT School of Engineering. In 1968, she was the first women in the United States awarded a Ph.D in Computer Science at Stanford University. This woman is incredible! LSP was introduced by Barbara herself in a 1987 conference keynote address titled “Data Abstraction and Hierarchy.” The principle is defined as follows: “If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.” To summarize, LSP states “Child classes should never break the parent class’ type definitions.” 
The best example used for LSP can be found in Object Mentor. Imagine an application that uses a Rectangle class.
class Rectangle
    attr_accessor :width, :height
    def initialize(width,height)
        @width, @height = width,height
    end
end

It works the way we would expect a rectangle to work so the clients using the app are happy. The clients return a month later asking to extend the features of the Rectangle with a square. A square fits the definition of a rectangle so it inherits from the class Rectangle. Our first clue to a pending problem is when we instantiate a new instance of Square.
    square1 = Square.new(5,5) 

A square does not need both width and height but it inherited those attributes from its parent. We can go back to our class Rectangle and make changes to satisfy this variation of a rectangle. However, our application breaks both the Single Responsibility Principle and the Open Closed Principle. Over time, the modification would break the parent class. While Rectangle and Square are similar, each shape is different.
To please both the Rectangle class and Square class, we have to create a completely separate class for each. Their behaviors are entirely different. At the heart of LSP is behavior and for it to hold, along with the other principles, a child class must behaves in sync with its parents. Rebel is treated with swift emancipation.
Look out for tomorrow’s post on “DIP - The Dependency Inversion Principle.”

Until next time, HAPPY CODING!
Jul 16, 2014 / 2 notes

Day 104: LSP - The Liskov Substitution Principle

These past couple of day I wrote about two of the Five Object-Oriented Design Principles. Single Responsibility Principle states “a class or module should have one, and only one, reason to change.” Open Closed Principle is how “software entities ( classes, modules, function, etc.) should be open for extension but closed for modification.” Today’s principle is Liskov Substitution. 

Barbara Liskov is a computer scientist and at age seventy-four, she is still kicking ass as a current Ford Professor of Engineering in MIT School of Engineering. In 1968, she was the first women in the United States awarded a Ph.D in Computer Science at Stanford University. This woman is incredible! LSP was introduced by Barbara herself in a 1987 conference keynote address titled “Data Abstraction and Hierarchy.” The principle is defined as follows: “If for each object O1 of type S there is an object O2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when O1 is substituted for O2 then S is a subtype of T.” To summarize, LSP states “Child classes should never break the parent class’ type definitions.” 

The best example used for LSP can be found in Object Mentor. Imagine an application that uses a Rectangle class.

class Rectangle
    attr_accessor :width, :height
    def initialize(width,height)
        @width, @height = width,height
    end
end

It works the way we would expect a rectangle to work so the clients using the app are happy. The clients return a month later asking to extend the features of the Rectangle with a square. A square fits the definition of a rectangle so it inherits from the class Rectangle. Our first clue to a pending problem is when we instantiate a new instance of Square.

    square1 = Square.new(5,5) 

A square does not need both width and height but it inherited those attributes from its parent. We can go back to our class Rectangle and make changes to satisfy this variation of a rectangle. However, our application breaks both the Single Responsibility Principle and the Open Closed Principle. Over time, the modification would break the parent class. While Rectangle and Square are similar, each shape is different.

To please both the Rectangle class and Square class, we have to create a completely separate class for each. Their behaviors are entirely different. At the heart of LSP is behavior and for it to hold, along with the other principles, a child class must behaves in sync with its parents. Rebel is treated with swift emancipation.

Look out for tomorrow’s post on “DIP - The Dependency Inversion Principle.”

Until next time, HAPPY CODING!

Day 103: The Open Closed Principle
Bertrand Meyer, French academic, author, and consultant in the field of computer languages, wrote an important book back in 1998 - ”Object-Oriented Software Construction.” It was considered then and is still now a fundamental book in object-orientated programming. In his chapter, “Design by Contract,” Meyer says “Software entities ( classes, modules, function, etc.) should be open for extension but closed for modification.” 
Honesty, I found such a concept hard to imagine. If any software entity has to be altered, its seems natural to change the body to accommodate this change. However, if you read my previous post on Single-Responsibility, it makes complete sense for a software entity to be close for modification. That software entity has one clear responsibility and any demands for change should result in writing more code. Essentially, you are building upon existing code to make this entity behave in a new and different way. Modifying pre-existing code in any way would damage that entity’s relationship with other entities and that is very bad design.  
Now writing an extension for an existing program is doable but how do you know if a program is closed? How does a programmer go about closing a program? Maybe a program’s single responsibility is just one part of a large problem. These questions are hard to answer because it all comes down to experience and a programmer’s responsibility to write code that is maintainable and reusable. As I move forward in my programming career, I aspire to write code that meets the five principles of object-oriented programming. 

Until then, Happy Coding!
Jul 15, 2014 / 1 note

Day 103: The Open Closed Principle

Bertrand Meyer, French academic, author, and consultant in the field of computer languages, wrote an important book back in 1998 - ”Object-Oriented Software Construction.” It was considered then and is still now a fundamental book in object-orientated programming. In his chapter, “Design by Contract,” Meyer says “Software entities ( classes, modules, function, etc.) should be open for extension but closed for modification.” 

Honesty, I found such a concept hard to imagine. If any software entity has to be altered, its seems natural to change the body to accommodate this change. However, if you read my previous post on Single-Responsibility, it makes complete sense for a software entity to be close for modification. That software entity has one clear responsibility and any demands for change should result in writing more code. Essentially, you are building upon existing code to make this entity behave in a new and different way. Modifying pre-existing code in any way would damage that entity’s relationship with other entities and that is very bad design.  

Now writing an extension for an existing program is doable but how do you know if a program is closed? How does a programmer go about closing a program? Maybe a program’s single responsibility is just one part of a large problem. These questions are hard to answer because it all comes down to experience and a programmer’s responsibility to write code that is maintainable and reusable. As I move forward in my programming career, I aspire to write code that meets the five principles of object-oriented programming. 

Until then, Happy Coding!

Day 102: The Single Responsibility Principle
American software consultant and author, Robert Cecil Martin, also known as Uncle Bob, introduced the term, single responsibility principle. Wikipedia defines the term to mean “In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility…” In his book, “Clean Code: A Handbook of Agile Software Craftsmanship,” Martin gives explicit details about what SRP is: “a class or module should have one, and only one, reason to change.”
When I first started programming, I did not understand the importance of SRP nor did I have experience to reference. Since building my first web application, I am now more appreciative of SRP. When I started building, I had one class, Museum, and thought Museum should contain all of its exhibition. However as I thought more about my decision, I started to realize Museum has one too many responsibilities. If changes need to be made to exhibitions, it also means changes to the Museum. Such changes go against the very grain of SRP. A class with multiple responsibility has many reasons to change. Many reasons to change hinders a class from satisfying its many dependencies. Failing to satisfy dependencies leads to programs breaking in unexpected ways.
Thankfully I foresaw this pending disaster and created a separate class Exhibition. Now an instance of Museum behaves in one way that is entirely unique and independent of an instance of Exhibition. In most case, it is hard to know beforehand if a class will have more than one reason to change, even after careful planning. However, trail and error provide the best lens when finding and separating responsibilities, and that in itself is design.

Happy Coding!
Jul 14, 2014

Day 102: The Single Responsibility Principle

American software consultant and author, Robert Cecil Martin, also known as Uncle Bob, introduced the term, single responsibility principle. Wikipedia defines the term to mean “In object-oriented programming, the single responsibility principle states that every class should have a single responsibility, and that responsibility should be entirely encapsulated by the class. All its services should be narrowly aligned with that responsibility…” In his book, “Clean Code: A Handbook of Agile Software Craftsmanship,” Martin gives explicit details about what SRP is: “a class or module should have one, and only one, reason to change.”

When I first started programming, I did not understand the importance of SRP nor did I have experience to reference. Since building my first web application, I am now more appreciative of SRP. When I started building, I had one class, Museum, and thought Museum should contain all of its exhibition. However as I thought more about my decision, I started to realize Museum has one too many responsibilities. If changes need to be made to exhibitions, it also means changes to the Museum. Such changes go against the very grain of SRP. A class with multiple responsibility has many reasons to change. Many reasons to change hinders a class from satisfying its many dependencies. Failing to satisfy dependencies leads to programs breaking in unexpected ways.

Thankfully I foresaw this pending disaster and created a separate class Exhibition. Now an instance of Museum behaves in one way that is entirely unique and independent of an instance of Exhibition. In most case, it is hard to know beforehand if a class will have more than one reason to change, even after careful planning. However, trail and error provide the best lens when finding and separating responsibilities, and that in itself is design.

Happy Coding!

Day 101: Object-Oriented Programming
When I first started programming, I read a lot about Ruby being an object-orientated language. Everything in Ruby is an object! Months later and three month into the Flatiron School Fellowship and I have only just started to understand the significance of Object-oriented programming or OOP for short. What does it mean? 
OOP is a highly regarded philosophy. It teaches you to write objects to be “self-sustainable.’ But how do objects know to be self-sustaining? It all depends on what is written in the class. A class is the blueprint for an object. It tells the object how to behave. If an object must be self-sustaining and a class is a representation of an object, the bigger question becomes how do you design a class? Welcome to the Five Object Oriented Design Principles:
SRP - The Single Responsibility Principle - A class should have one, and only one, reason to change.
OCP - The Open Closed Principle - You should be able to extend a classes behavior, without modifying it.
LSP - The Liskov Substitution Principle- Derived classes must be substitutable for their base classes.
DIP - The Dependency Inversion Principle- Depend on abstractions, not on concretions.
ISP - The Interface Segregation Principle- Make fine grained interfaces that are client specific.
Stay tuned this week as I cover in more depth the Five Object Orientated Design Principles. 
Until then, Happy Coding!
Jul 13, 2014 / 1 note

Day 101: Object-Oriented Programming

When I first started programming, I read a lot about Ruby being an object-orientated language. Everything in Ruby is an object! Months later and three month into the Flatiron School Fellowship and I have only just started to understand the significance of Object-oriented programming or OOP for short. What does it mean? 

OOP is a highly regarded philosophy. It teaches you to write objects to be “self-sustainable.’ But how do objects know to be self-sustaining? It all depends on what is written in the class. A class is the blueprint for an object. It tells the object how to behave. If an object must be self-sustaining and a class is a representation of an object, the bigger question becomes how do you design a class? Welcome to the Five Object Oriented Design Principles:

  • SRP - The Single Responsibility Principle - 
    A class should have one, and only one, reason to change.
  • OCP - The Open Closed Principle - 
    You should be able to extend a classes behavior, without modifying it.
  • LSP - The Liskov Substitution Principle- 
    Derived classes must be substitutable for their base classes.
  • DIP - The Dependency Inversion Principle- 
    Depend on abstractions, not on concretions.
  • ISP - The Interface Segregation Principle- 
    Make fine grained interfaces that are client specific.

Stay tuned this week as I cover in more depth the Five Object Orientated Design Principles. 

Until then, Happy Coding!

Day 99: the Exhibitionist
Here it is everyone! After two weeks of intense labor, I am happy to present “The Exhibitionist” - http://the-exhibitionist.herokuapp.com
For a very long time, I carried this app in my mind because of my love for art and museums but my dislike for navigating every museum site in search for art. I thought, there should just be one page where all of NYC museums and exhibitions are located. The only hard work I should have to do is pick an exhibition I’m most interested in and follow up with a visit. I am very happy to say that site is available now. It feels incredible to see my vision live and accessible online because of the skills I’ve learned at the Flatiron School!
The site is made in Rails and includes the following languages: Ruby, JavaScript, JQuery, PostGreSQL, Nokogiri, HTML & CSS. Currently, the Exhibitionist is very much in its Beta mode. Moving forward, I would like to add more museums to our scraper. As of now, we have the MoMA, Guggenheim, MET, Brooklyn Museum and Studio Museum in Harlem. Features to be added to the site include filtering exhibitions by genre, a glimpse into upcoming exhibitions, and an account where you can save your preferences.
Use the Exhibitionist to explore and expose art you love!
Jul 10, 2014

Day 99: the Exhibitionist

Here it is everyone! After two weeks of intense labor, I am happy to present “The Exhibitionist” - http://the-exhibitionist.herokuapp.com

For a very long time, I carried this app in my mind because of my love for art and museums but my dislike for navigating every museum site in search for art. I thought, there should just be one page where all of NYC museums and exhibitions are located. The only hard work I should have to do is pick an exhibition I’m most interested in and follow up with a visit. I am very happy to say that site is available now. It feels incredible to see my vision live and accessible online because of the skills I’ve learned at the Flatiron School!

The site is made in Rails and includes the following languages: Ruby, JavaScript, JQuery, PostGreSQL, Nokogiri, HTML & CSS. Currently, the Exhibitionist is very much in its Beta mode. Moving forward, I would like to add more museums to our scraper. As of now, we have the MoMA, Guggenheim, MET, Brooklyn Museum and Studio Museum in Harlem. Features to be added to the site include filtering exhibitions by genre, a glimpse into upcoming exhibitions, and an account where you can save your preferences.

Use the Exhibitionist to explore and expose art you love!

Jun 27, 2014 / 4 notes

Day 86: Still in Project Week Mode

It’s hard to believe that I have not been blogging these past few days. How else will you all know I have been programming the entire time? You’ll just have to trust me when I say I have been working diligently to present to you a cool new web/mobile app after next week. The site incorporates Rails, Nokogiri, ActiveRecord, SQLite3, jQuery and Ajax. Throughout the Flatiron Program I maintained a general excitement about programming but as of late, my excitement has grown by leaps and bounds. This project has been all I can think about. It touches on my favorite subjects: art, journalism, and programming. I know you all will share in my enthusiasm when I reveal my app a week from now.

Until then, Happy Coding!

Jun 23, 2014 / 1 note

Day 82

It’s project week for the next two weeks and my partner and I are working hard to deliver a mobile web app all about art!

Stay tuned and Happy Coding!

DAY 81: SINATRA - HTTP’s GET AND POST
Sinatra is framework but it’s more like a set of classes that you implement to build small web-based application. Heroku Mad-scientist, Blake Mizerany started the Sinatra project back in September 2007. Sinatra is designed to be lightweight and to deal directly with HTTP request and response from the server side. The best way to think about is this, if your website contains only a few path to navigate its pages, Sinatra is your friend. Not convinced? Let’s read about HTTP’s GET and POST.
HTTP ( Hypertext Transfer Protocol ) functions like so: you fire up Google Chrome and type in the website, ‘chase.com.’ Hovering over the Product and Service link brings up a dropbox where you then hover on the link ‘Savings & CDs’ followed by a click on ‘Savings & CDs Overview.’ Your browser is the client making a ‘gets’ request to the server, Chase. Chase returns a response message or an HTML page about Chase’s savings. Want to perform a POST request? Hover on Chase ‘Log in Or Enroll’ tab and then click on ‘New to Chase Online? Enroll in Chase online.’ This is another ‘gets’ request to Chase and it in turn responds with a new HTML file for your request. If you were to complete the form on the site and hit submit to confirm your account, your browser would be making a ‘post.’ If all the information provided is accurate, Chase will respond by adding you to its database and returning a new HTML file congratulating you. Without getting into other kinds of HTTP requests, most of your interaction online will consist of ‘gets’ and ‘posts’ requests. What does any of this have to do with Sinatra?
Take a thorough look at Chase’s website. There are more than fifty possible links. Sinatra is way too small for the complex Chase because Chase requires more than ‘gets’ and ‘posts’ when you have an account and need to update and delete information. However if you are creating a small web application with only a handful of paths to visit, such as an index, about, and contact me page, once again Sinatra is your friend. 
Interested in learning more? Visit Sinatra on Github! I look forward to seeing your website soon but until then, Happy Coding!
Jun 22, 2014 / 2 notes

DAY 81: SINATRA - HTTP’s GET AND POST

Sinatra is framework but it’s more like a set of classes that you implement to build small web-based application. Heroku Mad-scientist, Blake Mizerany started the Sinatra project back in September 2007. Sinatra is designed to be lightweight and to deal directly with HTTP request and response from the server side. The best way to think about is this, if your website contains only a few path to navigate its pages, Sinatra is your friend. Not convinced? Let’s read about HTTP’s GET and POST.

HTTP ( Hypertext Transfer Protocol ) functions like so: you fire up Google Chrome and type in the website, ‘chase.com.’ Hovering over the Product and Service link brings up a dropbox where you then hover on the link ‘Savings & CDs’ followed by a click on ‘Savings & CDs Overview.’ Your browser is the client making a ‘gets’ request to the server, Chase. Chase returns a response message or an HTML page about Chase’s savings. Want to perform a POST request? Hover on Chase ‘Log in Or Enroll’ tab and then click on ‘New to Chase Online? Enroll in Chase online.’ This is another ‘gets’ request to Chase and it in turn responds with a new HTML file for your request. If you were to complete the form on the site and hit submit to confirm your account, your browser would be making a ‘post.’ If all the information provided is accurate, Chase will respond by adding you to its database and returning a new HTML file congratulating you. Without getting into other kinds of HTTP requests, most of your interaction online will consist of ‘gets’ and ‘posts’ requests. What does any of this have to do with Sinatra?

Take a thorough look at Chase’s website. There are more than fifty possible links. Sinatra is way too small for the complex Chase because Chase requires more than ‘gets’ and ‘posts’ when you have an account and need to update and delete information. However if you are creating a small web application with only a handful of paths to visit, such as an index, about, and contact me page, once again Sinatra is your friend. 

Interested in learning more? Visit Sinatra on Github! I look forward to seeing your website soon but until then, Happy Coding!

DAY 78: NONE? Ruby Enumberable
While working on a lab today requiring Sinatra and Rack, I was confronted with a problem: how to confirm a form’s field was complete with real data and not empty strings. Sure a validation can be implemented with HTML’s ‘required place holders’. But what if the client is completing the file via Rest Client? My classmate George offered the solution, Ruby enumberable none? How does it work? Let’s find out together.
The none? method works by going through every element in a collection. How the method inspects each element in an array can be specified with a block or without. If the method is called with a block It returns true if the block never returns true for any of the elements. When called without a block, none? returns true only if none of the elements in the collection is true. I found the wording confusing so let’s pull up IRB and fool around. 
1. [1,2,3,4,5].none?   => false 
2. [1,2,3,4,nil].none? => false 
3. [nil].none?         => true 
4. [].none?            => true 
5. [nil,false].none?   => true 
6. [nil,false,"apple"].none? => false 
7. field1 = ""
8. field2 = ""
9. [field1, field2].none? => false 
10. [field1, field2].none?{|var| var.empty?}   => false
11. field1="hello"    => "hello" 
12. field2="bye"      => "bye" 
13. [field1, field2].none?{|var| var.empty?} => true 

In the first example, none? returns false because all the elements inside the collection are truthy. It returns false again in the second example even though one element inside the collection is false. The reason for this as we read earlier is because one true element means none of the elements are false. This could not be any more apparent in examples three and four where true is returned because the elements in the collection are false values. Taint a false collection with one truthy value and the method returns false.
In the last few examples, I am using the code in my lab. The none? method on the two variables returns false because although the two variables point to an empty string, they are neither ‘nil’ or ‘false.’ A block must be provided to the method. The empty? method confirms whether a string is empty or not. The best way to understand how code ten works is to ask yourself this question “Is it true that none of these variables are empty?” False because they are empty. Ask the question again as you read code thirteen. Is it true that none of these variables are empty? Yes it is true that none of these variable are empty! I admit it’s incredibly confusing to understand so if you find any alternatives, do share.
Until then, Happy Coding! 
Jun 19, 2014 / 3 notes

DAY 78: NONE? Ruby Enumberable

While working on a lab today requiring Sinatra and Rack, I was confronted with a problem: how to confirm a form’s field was complete with real data and not empty strings. Sure a validation can be implemented with HTML’s ‘required place holders’. But what if the client is completing the file via Rest Client? My classmate George offered the solution, Ruby enumberable none? How does it work? Let’s find out together.

The none? method works by going through every element in a collection. How the method inspects each element in an array can be specified with a block or without. If the method is called with a block It returns true if the block never returns true for any of the elements. When called without a block, none? returns true only if none of the elements in the collection is true. I found the wording confusing so let’s pull up IRB and fool around. 

1. [1,2,3,4,5].none?   => false 
2. [1,2,3,4,nil].none? => false 
3. [nil].none?         => true 
4. [].none?            => true 
5. [nil,false].none?   => true 
6. [nil,false,"apple"].none? => false 
7. field1 = ""
8. field2 = ""
9. [field1, field2].none? => false 
10. [field1, field2].none?{|var| var.empty?}   => false
11. field1="hello"    => "hello" 
12. field2="bye"      => "bye" 
13. [field1, field2].none?{|var| var.empty?} => true 

In the first example, none? returns false because all the elements inside the collection are truthy. It returns false again in the second example even though one element inside the collection is false. The reason for this as we read earlier is because one true element means none of the elements are false. This could not be any more apparent in examples three and four where true is returned because the elements in the collection are false values. Taint a false collection with one truthy value and the method returns false.

In the last few examples, I am using the code in my lab. The none? method on the two variables returns false because although the two variables point to an empty string, they are neither ‘nil’ or ‘false.’ A block must be provided to the method. The empty? method confirms whether a string is empty or not. The best way to understand how code ten works is to ask yourself this question “Is it true that none of these variables are empty?” False because they are empty. Ask the question again as you read code thirteen. Is it true that none of these variables are empty? Yes it is true that none of these variable are empty! I admit it’s incredibly confusing to understand so if you find any alternatives, do share.

Until then, Happy Coding! 

Day 77: SINATRA SESSIONS
Currently at the BK Flatiron School we are learning about servers, databases, and building web apps. This naturally brings up the topic of cookies because most if not all websites have cookies. By cookies, I mean HTTP cookies that track a user’s data as he or she navigates a page. Let’s get acquainted with its rich history before diving into Sinatra’s cookie, sessions.
HISTORY
Before there was HTTP cookie, there was problems. Lots of problems because a server had no way of managing state. More specifically, a server had no way of knowing if one client’s request came from one browser or many. In comes former Netscape Communication Corporation programmer, Lou Montulli (Louis J. Montulli II) in 1994 with the answer: HTTP cookies. Tracking cookie, browser cookie, or just cookie, it is all a piece of text containing no executable code that sits on a user’s internet hard drive. Cookies are generated by a web page server to keep track of the user using the web page. In short, a cookie is your computer’s ID card.
SESSIONS
As I said earlier, sessions are Sinatra’s form of cookies. Those sessions can be as complex as you want them to be or very simple. A complex cookie can include a date, path name, and domain. A simple cookie is setting a session secret to be a random assortment of text. Whichever you decide to implement, you must always write ‘enable :session’ inside your Sinatra application. Check out the sample code below from my lab today.
class ApplicationController < Sinatra::Base

  set :views, File.expand_path('../../views', __FILE__)

  enable :session 
  set :session_secret, "becauseiamhappy"
  
  configure :development do
    register Sinatra::Reloader
  end

end
######################## 
This is an example of implementing Sinatra's session. Yes that is my session secret.

post '/create' do
     @user = params[:user]
     session[:user_email] = @user[:user_email]
     session[:user_password] = @user[:user_password]
     redirect '/new'    
end
########################
Using session in your code

On a separte page I use HTML forms that prompt a user for data. Submitting that form gives me a params hash with the user’s information or email and password. I set those values to a ‘session[:user_email]’ and ‘session[:user_password].’ I can now use the information I gained through session to first validate email and password. Across my webpage, I can now keep track of my user’s registration details!
Remember what I said about making your session more complex? If you implement ‘Rack::Session::Cookie’ you can create and instantiate your own session! Keep me posted on your progress but until next time, Happy Coding!
Jun 18, 2014 / 1 note

Day 77: SINATRA SESSIONS

Currently at the BK Flatiron School we are learning about servers, databases, and building web apps. This naturally brings up the topic of cookies because most if not all websites have cookies. By cookies, I mean HTTP cookies that track a user’s data as he or she navigates a page. Let’s get acquainted with its rich history before diving into Sinatra’s cookie, sessions.

HISTORY

Before there was HTTP cookie, there was problems. Lots of problems because a server had no way of managing state. More specifically, a server had no way of knowing if one client’s request came from one browser or many. In comes former Netscape Communication Corporation programmer, Lou Montulli (Louis J. Montulli II) in 1994 with the answer: HTTP cookies. Tracking cookie, browser cookie, or just cookie, it is all a piece of text containing no executable code that sits on a user’s internet hard drive. Cookies are generated by a web page server to keep track of the user using the web page. In short, a cookie is your computer’s ID card.

SESSIONS

As I said earlier, sessions are Sinatra’s form of cookies. Those sessions can be as complex as you want them to be or very simple. A complex cookie can include a date, path name, and domain. A simple cookie is setting a session secret to be a random assortment of text. Whichever you decide to implement, you must always write ‘enable :session’ inside your Sinatra application. Check out the sample code below from my lab today.

class ApplicationController < Sinatra::Base

  set :views, File.expand_path('../../views', __FILE__)

  enable :session 
  set :session_secret, "becauseiamhappy"
  
  configure :development do
    register Sinatra::Reloader
  end

end
######################## 
This is an example of implementing Sinatra's session. Yes that is my session secret.
post '/create' do
     @user = params[:user]
     session[:user_email] = @user[:user_email]
     session[:user_password] = @user[:user_password]
     redirect '/new'    
end
########################
Using session in your code

On a separte page I use HTML forms that prompt a user for data. Submitting that form gives me a params hash with the user’s information or email and password. I set those values to a ‘session[:user_email]’ and ‘session[:user_password].’ I can now use the information I gained through session to first validate email and password. Across my webpage, I can now keep track of my user’s registration details!

Remember what I said about making your session more complex? If you implement ‘Rack::Session::Cookie’ you can create and instantiate your own session! Keep me posted on your progress but until next time, Happy Coding!

Day 76: A Quick Recap
More Ruby, ERB, Postgresql, talking to servers, and now Rack. It&#8217;s almost crazy how much progress has been made in a few short months. Will continue to keep you all posted but for now, time to return to my labs! 
Until next time, Happy Coding!
Jun 17, 2014 / 2 notes

Day 76: A Quick Recap

More Ruby, ERB, Postgresql, talking to servers, and now Rack. It’s almost crazy how much progress has been made in a few short months. Will continue to keep you all posted but for now, time to return to my labs! 

Until next time, Happy Coding!

Day 75: A Quick Post on ERB
I would describe ERB as string interpolation for Ruby except its works best in HTML. However, what makes it better than string interpolation is its ability to execute code. Let&#8217;s look at the example below us:
Hello, &lt;%= @name %&gt;
Today is &lt;%= Time.now %&gt;
Within the tags are ERB scriptlet, &#8216;%=&#8217;. Some scriptlet come without the equal sign but in our case, when they do it means this code must be executed and the results displayed on the page. The more popular and common use of ERB scriptlet are for looping. Check out the code below:
&lt;% for @item in @todo_list %&gt;
        &lt;%= @item %&gt;
    &lt;% end %&gt;

OR
&lt;% @todo_list.each do | item| %&gt;
        &lt;%= item %&gt;
    &lt;% end %&gt;

Tumblr and Prettify refused to play nice when I tried to use any unordered list tags but I sincerely hope you understand the concept above. Both are Ruby loops but if you were to encapsulate those loops inside HTML ordered and unordered list tags, the loop would print a new line inside the HTML for every item.
teERB binding makes what seems impossible possible with binding. In the code below us we have the following
    string = "Here lies a string"
    template = "&lt;%= string %&gt;"
    rendering = ERB.new(template)
    results = template.result(binding)

ERB processes the variable template when the method &#8216;result&#8217; is called. However it is the binding that ties everything together. The binding variable contains the scope where the variable string is accessible. When the template needs to be generated, binding enables us to have access to the variable string anywhere. Amazing isn&#8217;t?! I love programming!

Until next time, Happy Coding!
Jun 17, 2014 / 2 notes

Day 75: A Quick Post on ERB

I would describe ERB as string interpolation for Ruby except its works best in HTML. However, what makes it better than string interpolation is its ability to execute code. Let’s look at the example below us:

Hello, <%= @name %>
Today is <%= Time.now %>

Within the tags are ERB scriptlet, ‘%=’. Some scriptlet come without the equal sign but in our case, when they do it means this code must be executed and the results displayed on the page. The more popular and common use of ERB scriptlet are for looping. Check out the code below:

<% for @item in @todo_list %>
        <%= @item %>
    <% end %>

OR

<% @todo_list.each do | item| %>
        <%= item %>
    <% end %>

Tumblr and Prettify refused to play nice when I tried to use any unordered list tags but I sincerely hope you understand the concept above. Both are Ruby loops but if you were to encapsulate those loops inside HTML ordered and unordered list tags, the loop would print a new line inside the HTML for every item.

teERB binding makes what seems impossible possible with binding. In the code below us we have the following

    string = "Here lies a string"
    template = "<%= string %>"
    rendering = ERB.new(template)
    results = template.result(binding)

ERB processes the variable template when the method ‘result’ is called. However it is the binding that ties everything together. The binding variable contains the scope where the variable string is accessible. When the template needs to be generated, binding enables us to have access to the variable string anywhere. Amazing isn’t?! I love programming!

Until next time, Happy Coding!

Day 72: Tim Burners-Lee 
Today Avi presented our programmer of the day, Tim Burners-Lee. His current occupation is Computer Scientist but Tim will always be known as the inventor of the World Wide Web. He saw the need for computers to connect with each other during his fellowship at CERN. Located in Geneva, CERN is a European Organization for Nuclear Research. Their goal is to provide physicists and engineers with complex instruments to probe the fundamental structure of the universe. However, what fun is it as physicists or engineers to probe and conduct research when the results and data are difficult to share? Seeking to meet the demands for information sharing between scientist and universities, Tim had these words to say,

"I just had to take the hypertext idea and connect it to the Transmission Control Protocol and domain name system ideas and—ta-da!—the World Wide Web &#8230; Creating the web was really an act of desperation, because the situation without it was very difficult when I was working at CERN later. Most of the technology involved in the web, like the hypertext, like the Internet, multifont text objects, had all been designed already. I just had to put them together. It was a step of generalising, going to a higher level of abstraction, thinking about all the documentation systems out there as being possibly part of a larger imaginary documentation system.&#8221;

The web was born in March 1989. Surprisingly, it took an additional year for the first web page to be served. No worries. Tim took the time to flesh out the fundamentals of the web with HTML (Hypertext Markup Language), URI (Uniform Research Identifier) more commonly known as URL, and HTTP (HyperText Transfer Protocol). Here is the very first website put online on August 6, 1991: http://info.cern.ch/hypertext/WWW/TheProject.html
It provided documentation on what was the web, how to use a browser, and setup a server. The best news came on April 1993 when CERN announced that this technology would be free to everyone.
I was born in 1989 and distinctly remember the first time I connected my computer to a modem. I was about ten years old and I relished the humming and buzzing of the internet on my browser. The web has changed lives since its birth and as developers it is our responsibility to build upon its rich history. Let&#8217;s &#8220;code a better country&#8221; and with that, I wish you all Happy Coding!
Works Cited
1. World Wide Web Foundation. &#8220;Web Inventor and Founding Director of the World Wide Web Foundation.&#8221; Sir Tim Burners-Lee. Web. 15 June 2014.
2. Tim Berners-Lee. &#8220;Answers for Young People.&#8221; World Wide Web Consortium. Web. 15 June 2014. 
Jun 15, 2014 / 1 note

Day 72: Tim Burners-Lee 

Today Avi presented our programmer of the day, Tim Burners-Lee. His current occupation is Computer Scientist but Tim will always be known as the inventor of the World Wide Web. He saw the need for computers to connect with each other during his fellowship at CERN. Located in Geneva, CERN is a European Organization for Nuclear Research. Their goal is to provide physicists and engineers with complex instruments to probe the fundamental structure of the universe. However, what fun is it as physicists or engineers to probe and conduct research when the results and data are difficult to share? Seeking to meet the demands for information sharing between scientist and universities, Tim had these words to say,

"I just had to take the hypertext idea and connect it to the Transmission Control Protocol and domain name system ideas and—ta-da!—the World Wide Web … Creating the web was really an act of desperation, because the situation without it was very difficult when I was working at CERN later. Most of the technology involved in the web, like the hypertext, like the Internet, multifont text objects, had all been designed already. I just had to put them together. It was a step of generalising, going to a higher level of abstraction, thinking about all the documentation systems out there as being possibly part of a larger imaginary documentation system.”

The web was born in March 1989. Surprisingly, it took an additional year for the first web page to be served. No worries. Tim took the time to flesh out the fundamentals of the web with HTML (Hypertext Markup Language), URI (Uniform Research Identifier) more commonly known as URL, and HTTP (HyperText Transfer Protocol). Here is the very first website put online on August 6, 1991: http://info.cern.ch/hypertext/WWW/TheProject.html

It provided documentation on what was the web, how to use a browser, and setup a server. The best news came on April 1993 when CERN announced that this technology would be free to everyone.

I was born in 1989 and distinctly remember the first time I connected my computer to a modem. I was about ten years old and I relished the humming and buzzing of the internet on my browser. The web has changed lives since its birth and as developers it is our responsibility to build upon its rich history. Let’s “code a better country” and with that, I wish you all Happy Coding!

Works Cited

1. World Wide Web Foundation. “Web Inventor and Founding Director of the World Wide Web Foundation.” Sir Tim Burners-Lee. Web. 15 June 2014.

2. Tim Berners-Lee. “Answers for Young People.” World Wide Web Consortium. Web. 15 June 2014. 

Day 71: RAKE
Rake is a build language from Ruby. Ok. What do I mean by build? As in Rake enables you to automate task, describe dependencies as well as group tasks in a namespace. It&#8217;s pretty sweet! Jim Weirich, former contributor to the Ruby Programming Language Community, does a great job of explaining Rake with his mac and cheese example! Visit Basic Rake on Youtube. Returning back to my post, you will find a few examples of Rake from my lecture today. 
namespace :db do
  # rake db:migrate
  desc "Runs all the migrations"
  task :migrate do
    ActiveRecord::Migrator.migrate('db/migrations')
  end
 
  desc "Rolls db back to version 0"
  task :rollback do
    ActiveRecord::Migrator.migrate('db/migrations', 0)
  end
 
  desc "Adds Seed data to the db"
  task :seed do
    puts "Loading Seed"
    require_relative 'db/seed'
    puts "Done loading seed"
  end
 
  desc "rollsback db, runs all migrations"
  task :reset =&gt; [:rollback, :migrate, :seed]
end
Maybe you&#8217;re freaking out with all the calls to ActiveRecord and Migrator but fear not because I will blog about those subjects soon. What you are looking at are Rake tasks in its purest form. The namespace &#8216;:db&#8217; refers to the entire task but it does not run the entire code. However, you do use the namespace in order to run specific tasks within its body. We will get to those Rake commands soon. Right now, I want you to understand there are currently four tasks. Each task has a name- &#8220;:migrate&#8221;, &#8220;:rollback&#8221;, &#8220;:seed&#8221;, and &#8220;:reset.&#8221; Using those names following the namespace executes the block of code between a task&#8217;s do and end. Here is how you write the command &#8220;rake db :migrate&#8221;, &#8220;rake db :rollback&#8221;, &#8220;rake db :seed&#8221;, and &#8220;rake db :reset.&#8221; The word &#8216;desc&#8217; is a description of the task. If you create Rake tasks saved in a file title &#8216;Rakefile&#8217; within your directory you now have the power to compile! Link! Test! Package! Document generation! Deploy! What big super powers you have now! Keep me posted on your development and Happy Coding!
Jun 13, 2014 / 8 notes

Day 71: RAKE

Rake is a build language from Ruby. Ok. What do I mean by build? As in Rake enables you to automate task, describe dependencies as well as group tasks in a namespace. It’s pretty sweet! Jim Weirich, former contributor to the Ruby Programming Language Community, does a great job of explaining Rake with his mac and cheese example! Visit Basic Rake on Youtube. Returning back to my post, you will find a few examples of Rake from my lecture today. 

namespace :db do
  # rake db:migrate
  desc "Runs all the migrations"
  task :migrate do
    ActiveRecord::Migrator.migrate('db/migrations')
  end
 
  desc "Rolls db back to version 0"
  task :rollback do
    ActiveRecord::Migrator.migrate('db/migrations', 0)
  end
 
  desc "Adds Seed data to the db"
  task :seed do
    puts "Loading Seed"
    require_relative 'db/seed'
    puts "Done loading seed"
  end
 
  desc "rollsback db, runs all migrations"
  task :reset => [:rollback, :migrate, :seed]
end

Maybe you’re freaking out with all the calls to ActiveRecord and Migrator but fear not because I will blog about those subjects soon. What you are looking at are Rake tasks in its purest form. The namespace ‘:db’ refers to the entire task but it does not run the entire code. However, you do use the namespace in order to run specific tasks within its body. We will get to those Rake commands soon. Right now, I want you to understand there are currently four tasks. Each task has a name- “:migrate”, “:rollback”, “:seed”, and “:reset.” Using those names following the namespace executes the block of code between a task’s do and end. Here is how you write the command “rake db :migrate”, “rake db :rollback”, “rake db :seed”, and “rake db :reset.” The word ‘desc’ is a description of the task. If you create Rake tasks saved in a file title ‘Rakefile’ within your directory you now have the power to compile! Link! Test! Package! Document generation! Deploy! What big super powers you have now! Keep me posted on your development and Happy Coding!