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.
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.
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!
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.”
React.js Part 1: You need a server FIRST
Last week, Tanoy Sinha stopped by at the Brooklyn Flatiron School and gave the class a very thorough tutorial on React.js. React is a new JS framework designed by the team at Facebook. It was created to solve one problem, “building large applications with data that changes over time." With this problem in mind, React makes it easy for developers to express how their app should look at any given time and manages User Interface when that data changes. Additionally, React knows when to automatically ‘refreshes’ itself when data changes and where to update. React is smart and for all the reasons mentioned above, it is considered the "V" in MVC. Today I’ll be writing about my experience with React via tutorials.
The Starter Kit Tutorial is simple, write “Hello, world!” The code I added to my helloworld.html file is below:
The final draft of the html looked like the gist below:
Easy. I felt confident enough to move to a more complex tutorial, building a comment box similar to Facebook. I created a new HTML and typed the first tutorial JS file with the exact information. When I opened the HTML file in my browser, I was greeted with nothing but white space instead of “Hello, world! I am a CommentBox.” Weird. I copied and pasted the exact text on the tutorial to my files. Still nothing. I wrote out the code inline. Worked perfectly! However, inline code is lame. I forked the tutorial on Github and I noticed an immediate difference: the creators had a server hooked up. Did I need a server too? Probably not I thought. All I had in my directory were two files, HTML and the React.js file but I was still running into trouble loading the page. Surprisingly it worked well with Safari but not Chrome. After speaking with Steve, he suggest I use a ruby server. Several scrolls through the tutorial and I noticed they also used a server: “python -m SimpleHTTPServer”. Mine looked like this “ruby -run -e httpd — -p 5000”. The tutorial is an AJAX application and needs a server to work. Why?
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.
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!
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.
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:
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!
Use the Exhibitionist to explore and expose art you love!
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!