The Latest

Sep 9, 2014 / 16 notes
Sep 3, 2014 / 2 notes

patrickdmccarthy said: Hey, I just wanted to say how much I like the designs for your posts! I'm about to start at another NYC bootcamp in a few weeks and I'm kind of design-obsessed as well (but much less talented). Anyway, good luck with everything!

Haha! Thanks so much! If you’re as design obsessed as you say, I challenge you to maintain a blog. It must be beautifully designed and full of programming facts! Good luck on your journey! You’ll be fantastic!

LIKE REALLY, THANK YOU
August 29th was my last day as a Brooklyn Flatiron School Web Development Fellow and it was painfully bittersweet. So much has happened! Let’s start with Monday, Aug 18th. 
I got an email from Julie at &yet at 9:06PM saying I was the recipient of free tuition at the Human JavaScript LIVE training program in Washington. State, not the capital. I was blown away. My application was my Developer Origin Story and it had been received with love and support. Thank you to everyone who responded with kind words and encouragement. 
At the time when I learned the good news from Julie, I had no funding so I decided not to attend. I still registered for the event, just in case I changed my mind. Good thing I did because by Wednesday, August 20th I had changed my mind. My friend Richard, who discovered the scholarship and encouraged me to apply, was congratulating me when he asked if I was attending. I explained my reasons to which he responded: “events like at &yet are important to attend because it’s priceless and builds morale”. That was all I needed to hear to open an account with GoFundMe. You can check it out here. Right after our conversation, I begin campaigning for $1300 for both flight and hotel funding. Before the day was over I had enough to make the purchase. A very big thank you to everyone who participated and made my trip possible.
On Monday, August 25th at 10am I begin my fourteen-hour journey to Pasco, Washington. I finally landed at 10pm with just enough time to check into the hotel in Richland and crash. The next two days were a blur, everything happened so fast. The staff at &yet curated an amazing, theatrical performance and training complete with musicals, wonderful food, and JavaScript. We built a single page web app using server Node.js, framework Backbone.js and Ampersand.js all from scratch. The app is a real-time chat room to fend off the dangerous wolves that roam the street in Richland. Huh? Wolves? Yep wolves. Wanna be in the know? Attend their next session happening October 1st and 2nd. Check it out here! You will love Richland because of the smart and seriously awesome folks at &yet. Thank you Henrik for the immersive and intensive two-day JavaScript training. Fritz, thanks for helping the class fix bugs and catch up whenever we lagged behind Henrik. Mike, Mike, Mike. You blew me away with your acting and story telling. Amy, you’re an amazing tour guide! I hope you have a new hair color for the next session. Ben, I was seriously impressed by your JS themed songs! Leslie, you have a serious knack on how to make everyone feel welcomed and comfortable - thank you. Julie, I really can’t thank you enough for your support! If there is anyone else I missed, I am sorry but grateful for all your hard work. 
The attendees at the training were equally awesome people to talk and get to know. Thursday was my last day and I spent it with Philip grabbing $2 pour overs at the Local, glazed donuts at the Spudnut Shop, the oldest coffee shop in the city, and checking out an attendee’s comic book shop. At 12pm, I was back at the airport for another fourteen-hour journey back to New York City. There was even the added benefit of spending the night in Boston because of a six-hour layover! Nevertheless, I made it home safely and just in time for my graduation ceremony at the Flatiron School.
I have grown to love all twenty-seven of my classmates and wish each and everyone only the best in their job search. Let’s do karaoke again soon! Big thank you to my amazing instructors, Steven, Blake, and Ian. Thanks for your patience and dedication to our success. Avi, Adam, Rebekah, Jackie, Elana, and everyone else at the Flatiron School thanks a billion for all that you do! 
Aug 30, 2014 / 1 note

LIKE REALLY, THANK YOU

August 29th was my last day as a Brooklyn Flatiron School Web Development Fellow and it was painfully bittersweet. So much has happened! Let’s start with Monday, Aug 18th.

I got an email from Julie at &yet at 9:06PM saying I was the recipient of free tuition at the Human JavaScript LIVE training program in Washington. State, not the capital. I was blown away. My application was my Developer Origin Story and it had been received with love and support. Thank you to everyone who responded with kind words and encouragement. 

At the time when I learned the good news from Julie, I had no funding so I decided not to attend. I still registered for the event, just in case I changed my mind. Good thing I did because by Wednesday, August 20th I had changed my mind. My friend Richard, who discovered the scholarship and encouraged me to apply, was congratulating me when he asked if I was attending. I explained my reasons to which he responded: “events like at &yet are important to attend because it’s priceless and builds morale”. That was all I needed to hear to open an account with GoFundMe. You can check it out here. Right after our conversation, I begin campaigning for $1300 for both flight and hotel funding. Before the day was over I had enough to make the purchase. A very big thank you to everyone who participated and made my trip possible.

On Monday, August 25th at 10am I begin my fourteen-hour journey to Pasco, Washington. I finally landed at 10pm with just enough time to check into the hotel in Richland and crash. The next two days were a blur, everything happened so fast. The staff at &yet curated an amazing, theatrical performance and training complete with musicals, wonderful food, and JavaScript. We built a single page web app using server Node.js, framework Backbone.js and Ampersand.js all from scratch. The app is a real-time chat room to fend off the dangerous wolves that roam the street in Richland. Huh? Wolves? Yep wolves. Wanna be in the know? Attend their next session happening October 1st and 2nd. Check it out here! You will love Richland because of the smart and seriously awesome folks at &yet. Thank you Henrik for the immersive and intensive two-day JavaScript training. Fritz, thanks for helping the class fix bugs and catch up whenever we lagged behind Henrik. Mike, Mike, Mike. You blew me away with your acting and story telling. Amy, you’re an amazing tour guide! I hope you have a new hair color for the next session. Ben, I was seriously impressed by your JS themed songs! Leslie, you have a serious knack on how to make everyone feel welcomed and comfortable - thank you. Julie, I really can’t thank you enough for your support! If there is anyone else I missed, I am sorry but grateful for all your hard work. 

The attendees at the training were equally awesome people to talk and get to know. Thursday was my last day and I spent it with Philip grabbing $2 pour overs at the Local, glazed donuts at the Spudnut Shop, the oldest coffee shop in the city, and checking out an attendee’s comic book shop. At 12pm, I was back at the airport for another fourteen-hour journey back to New York City. There was even the added benefit of spending the night in Boston because of a six-hour layover! Nevertheless, I made it home safely and just in time for my graduation ceremony at the Flatiron School.

I have grown to love all twenty-seven of my classmates and wish each and everyone only the best in their job search. Let’s do karaoke again soon! Big thank you to my amazing instructors, StevenBlake, and Ian. Thanks for your patience and dedication to our success. Avi, Adam, Rebekah, Jackie, Elana, and everyone else at the Flatiron School thanks a billion for all that you do! 

Aug 13, 2014 / 8 notes
Aug 12, 2014 / 48 notes

My Developer Origin Story

A man and a woman told me on two separate occasions “You don’t look like a programmer” and “You’re too creative to be a programmer.” Though their words were very discouraging to hear, at the time I understood their logic. Haitian born, Brooklyn raised, I graduated from Smith College with a Bachelor’s in Studio Art and a concentration in drawing.

After graduation I worked at restaurants and a coffee bar before moving to Neuehouse, a members-only workspace for people in creative industries, where I worked as a host. My responsibilities were simple, keep members’ spirits high and the space clean, but I knew I could be useful on their design team. I could connect and communicate with people using the web and art.

A month into my job at Neuehouse, I started an Adobe Creative Suite class. Balancing school and work was taxing but I knew my efforts would eventually culminate in an incredible project. The idea came in September, at the end of class, fueled by my desire to answer the question “What is Neuehouse?” Armed with my new Adobe skills, a Canon Rebel T1 camera, and my tricked out Macbook Pro, I set out to capture the unique personalities of the Neuehouse staff. I wanted to explore something small with the potential to reveal a lot, and decided shoes would be my subject. I photographed fifty employees’ shoes and interviewed them to find out what filled those shoes. The project, now a magazine, was titled “The Working Soles of Neuehouse.”

As I worked on the magazine, I realize I wanted a career that combined design with technology so I began applying to Parsons Paris MFA program in Design and Technology. Around the same time, a friend introduced me to the Flatiron School Fellowship and I knew I had stumbled on a goldmine. Here was an opportunity to be challenged, pushed, and prodded to be the best programmer possible. At the Flatiron School, I would have access to developers from whom I can learn. I refused to settle for anything less than admission. I worked on the magazine, my Parsons and Flatiron School Fellowship application, while attending Flatiron School meetups, and learning programming language, Ruby. January I finished the magazine and submitted my Parsons application. The magazine was incredibly successful and a print version followed soon. Two months later, I had an interview at the Flatiron School. Four interviews and a coding quiz later, I was admitted as a fellow. That moment I decided, admittance to Parsons or not, I would become a full-stack developer.

 One of the first problems I solved while at the Flatiron School was redesigning the user experience of selecting a museum exhibit. I’m always plagued by the search for museums to visit and the website navigation required to decide on an exhibition. The solution: gather all the data surrounding museums’ exhibitions in one place. I built “The Exhibitionist” in just two weeks. It is a web application that delivers current exhibitions at the Museum of Modern Art, the Metropolitan Museum, the Guggenheim museum, the Brooklyn Museum, and the Studio Museum in Harlem all on one page. I am actively working to add more museums.

What I love most about being a developer is the endless ability to create and produce solutions with worldwide impact. My programming skills enable me to use my imagination to solve other people’s problems. My knowledge enables me to learn new languages, solve old problems in new ways, and work collaboratively to create web applications that are beneficial to people across varying backgrounds, industries, and continents. The only thing I wish I had known when I started is that yes, programming seems difficult at first but becomes easier over time. Overcoming that first hurdle is paramount. After deploying “The Exhibitionist,” I finally understood what it meant to be a programmer and why it is worth fighting through every frustration.

We as a community must work to actively support, mentor, and encourage programmers who are of color and identify as women. I am thankful to have had great friends who are programmers. They constantly told me, “Yes you can program and you should program.” Even when programming was hard, those same friends told me again, “Yes, programming is hard but you can and will do it.” This marginalized group of programmers needs the support and encouragement of a community who believes in their capabilities. We need to hear early and often “Yes you can program.”

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 / 2 notes

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!