The Latest

Day 112: The Interface Segregation Principle (ISP)
ISP states that no client should be forced to depend upon interfaces that they don’t use. Who are those clients? The answer to that question is your modules and submodules are the clients. Each one serves a different purpose and for this reason, each client borrows from one group and vice versa. However, if a group a client borrows from is contaminated it has the power to contaminate everyone. Prevention is the heart of ISP. 
Imagine a group of workers. Those workers are efficient and need a daily lunch break to eat. Soon a new group of workers come on the scene and they are even more efficient because they do not need lunch to function. However, company policy states every worker go on lunch. There is no reason why these unique workers should be forced to take lunch. Such decision goes against ISP and paints that company as a ‘fat’ interface. The best thing to do is create a smaller company that encompass those unique workers. We as programmers much respect the needs of our code in order to write better and thus make our lives easier. 
Happy Coding!
Jul 24, 2014 / 2 notes

Day 112: The Interface Segregation Principle (ISP)

ISP states that no client should be forced to depend upon interfaces that they don’t use. Who are those clients? The answer to that question is your modules and submodules are the clients. Each one serves a different purpose and for this reason, each client borrows from one group and vice versa. However, if a group a client borrows from is contaminated it has the power to contaminate everyone. Prevention is the heart of ISP. 

Imagine a group of workers. Those workers are efficient and need a daily lunch break to eat. Soon a new group of workers come on the scene and they are even more efficient because they do not need lunch to function. However, company policy states every worker go on lunch. There is no reason why these unique workers should be forced to take lunch. Such decision goes against ISP and paints that company as a ‘fat’ interface. The best thing to do is create a smaller company that encompass those unique workers. We as programmers much respect the needs of our code in order to write better and thus make our lives easier. 

Happy Coding!

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!