Dealing With the Blank Screen problem…start With a Blank Sheet of Paper Instead.

When you first start learning web development frameworks like Rails, it can be really hard to know where to get started. There are simply too many problems to think about at once. And, there are a lot of steps between the “rails new” command you start off with and the end product with robust functionality that you desire. My advice is to start by drawing; don’t start typing away code just yet because you’re more likely to get confused/frustrated and make mistakes. Because the space on a page is limited it forces you to think about a limited number of problems at once.

One advantage of drawing is that various elements of your Rails application start revealing themselves to you. For example, let’s say you start by drawing your app’s views, specifically the forms. It’s easier to conceptualize what the website is going to look like and how the user will interact with it rather than conceptualizing the models and associations (the hard stuff that drives how the app will work).

I’ve found that you start noticing new classes/models/tables when you draw views and forms. The elements of the form that might need separate functionality are usually separate classes. The form inputs that don’t need additional functionality are probably not new classes, but just attributes of the top-level class/model. In the first image below, for example, “assignment” is the main model/class of concern and “body” is an attribute of each instance of assignment. However, “resources” might be its own separate class/model because it may have additional functionality and other associations.

Once you have these forms drawn out you can ask yourself the following questions: How is the user going to arrive to this form? Where is the user going once he fills this form out? When you answer these questions, you can start figuring out whether you need to scaffold or whether you want just certain routes. Also, it becomes clearer what information you’re controller’s will have to provide you, or have to be able to handle, through this process.

In addition, once you start seeing model elements from your views, you can also start seeing what the associations are going to look like. For example, are you asking for more than one of the same thing in your form? If so, then there’s probably a has_many/belongs_to relationship. Start writing that stuff down on your piece of paper.

UMLs – don’t do it as a beginner

UML stands for Unified Modeling Language. UML is software for drawing connections between classes/models. It’s an alternative to drawing. For a good example, check out After a conversation with a fellow classmate and teaching assistant, I think using a UML is a bad idea for beginners. I’m sure that UMLs are very helpful for projects that need a lot of advanced planning. But, for beginner ‘hackers’ who are trying to implement small and then build onto what they have, it can be a huge waste of time. You end up spending a lot of time figuring out how the UML software works and what the special symbols mean instead of actually making progress on your Rails application.

TL;DR – DRAW when you don’t know what to do in your Rails apps.


Traditional Economics vs. Seth Godin’s Economics

Today I met someone I really admire, Seth Godin. About 3 years ago, my cousin introduced me to Seth’s blog and some of his writing. I read his book Linchpin, which really transformed the way I thought about job satisfaction, personal and societal value creation, and, more broadly, how the economy (and economic theory) would change in the years to come.

In college class after class, I was schooled in the classical understanding of how the economy worked. Basically, what you learn in classical economic theory of production is that a country’s growth is determined by the growth rate in capital, labor, and productivity (generalized as improvements in technology). Labor, used in some optimal combination with capital, would create growth. Labor was thought of in the same light as machinery. It was an interchangeable commodity.

This theory was a great way of explaining what happened in our country after the industrial revolution. You didn’t need to be particularly skilled to work at Henry Ford’s factories. In fact, a large portion of the populace was some form of blue-collar worker completing very repetitive, manual work, at company’s with very hierarchical management structures.

Does this model make any sense now?

But, I started to wonder if that model for economic growth made any sense in the age that we currently live in. It’s so obvious now that productivity improvements and capital have been replacing, and will continue to replace the requirements of labor. Not even white collar jobs are safe anymore. You think you are special because you have a college degree? Guess what, everyone does! A master’s isn’t even what it used to be. And guess what, there are hundreds of millions of people in India that could probably do your job for a forth of the price with limited quality drop off.

Is labor relevant anymore?

It kind of dawned on me that people actually really have to do something to stay relevant in the marketplace, or they’ll continue to be replaced by machinery and productivity improvements. So, what does labor have to do to stay relevant? That’s where Seth’s ideas in Linchpin really hit home.

Be an artist!

In Linchpin, Seth implores everyone to become an artist and do work that really matters because the market demands more from labor. That means making you make a commitment to do work that’s meaningful. You give gifts to people. You surprise them. You give them more than they ask for. You make someone’s day. You anticipate their needs. That is what Seth means when he talks about creating art through your work.

You can be an artist who works with oil paints or marble, sure. But there are artists who work with numbers, business models, and customer conversations. Art is about intent and communication, not substances…Art is a personal gift that changes the recipient. The medium doesn’t matter. The intent does.

How do programmers produce art?

As a programmer, making art is about composing beautiful code that’s readable for humans. For example, it’s about writing code that anticipates edge cases. It’s about testing to ensure that it works. It’s about figuring out a way to do something more efficiently.

Even more importantly, it’s about creating products that customers actually want to use; products with robust functionality and great user experiences. If we keep the user in mind, we’ll be better at solving their problems, and solving customer problems with elegance is art.


Sinatra Organization

This blog delves into the organization patterns of larger code-bases. Up until now, we’ve been working on relatively small projects that include one application file, and maybe 3-4 class and module files. To explore the file structure of larger projects, I will be looking through an open source Sinatra project called So-Nice. So-Nice is a simple web interface to control iTunes, Spotify, and other music players. The project’s code-base can be found here.

Overall structure

The top level of the application’s code-base is comprised of two folders and five main files.

The files:

  • Gemfile: The Gemfile lists all the application’s dependencies. Dependencies are all the gems that the application relies on. This file is particularly important in this application, because it loads the ‘anyplayer’ gem, which supports the various music players, including Spotify and iTunes. Other dependencies include ‘sinatra,’ ‘haml,’ ‘xml-simple,’ ‘json,’ and ‘thin.’ All of these gems are sourced from
  • Gemfile.lock: This file is a snapshot of all the gems and versions that were installed. This way you know the exact versions of all the gems that you used when your application last worked. This is especially important and useful when you are sharing your work with collaborators. Others won’t have to guess what veresion of the dependencies they should install.
  • The readme file contains a brief description of what the web application does and how to install and use it on your machine.
  • This is the rackup file that the Sinatra application needs to include in its root directory. The ‘run’ contained in this config file can be called on anything that responds to a .call method. The application itself is also ‘required’ through the config file. In this case, the application is ‘sonice.rb’
  • sonice.rb: This file is the Ruby application that is loaded by the rackup file.

The folders:

  • public: Sinatra, by default, looks for ‘assets,’ such as CSS files and images, in the ‘public’ folder. So-Nice’s public folder contains its stylesheet, a picture, and various javascript files.
  • views: The ‘views’ folder contains one file, called ‘index.haml.’ Haml is a markup language that produces clean, well-structured HTML. Haml can also handle inline code, like Ruby. Sinatra, by default, looks for webpage templates in the ‘views’ folder.

Useful resources on the subject

The following is a list of useful resources to help understand the various components of the Sinatra file structure.


Ruby Testing

This weekend I scoured for a presentation related to the topics that we’re beginning to cover in class. I came across the following slide deck from Emily Price titled “Testing Ruby using RSPEC with Factory Girl and Autotest”.

The first two weeks of class we’ve really focused on just getting our programs to work and getting familiar with Ruby. However, late last week we began covering the concept of test-driven development. Emily Price’s slide deck gives a high level overview of the topic.

Testing best practices

The presentation’s author emphasized the following best practices for testing:

  • write tests first: testing is a continuous process of making your code fail, fixing it so it passes, refactoring, and repeating.
  • test your edge cases: there are always scenarios in which your code will fail that you may not think of right off the bat. Get creative and try to create tests for those scenarios that might break your code or give you strange results.
  • test behavior, not implementation: this essentially means that you want to test if the code produces the desired result, not necessarily how it produces it produces the result.

What the heck is RSPEC, Factory Girl, and Autotest anyway?

RSPEC is a testing tool for Ruby, and as with all things Ruby it was designed to “make Test-Driven Development a productive and enjoyable experience.” Factory Girl and Autotest are both gems that work with RSPEC to aid with testing. For example, Autotest is a gem that automatically runs your tests each time you change or save a file. It allows for continuous, quick testing so that you rarely have to open up the browser to see what’s happening to your code.

OK, so I’m not an expert in test-driven development yet. But, as they say, “the beginning of wisdom is to call things by their right names.” Now I know what RSPEC, Factory Girl, and Autotest are and have some best practices to refer to. Thanks Emily for your speakerdeck presentation!


The Inevitable Excel-Ruby Comparison

This blog post is partially inspired by Carlos Lazo’s comparison of C++ and Ruby, which you can read here.

For the past 2.5 years, I have lived in Microsoft Excel. This is not a joke. I spent, on average, 50-55 hours a week in the office. More than 50% of that time was with a spreadsheet open, so that amounts to at least 3125 hours. Yikes!

After my first few weeks of Ruby, I can’t help but make analogies to the world of Excel and compare Excel’s functionality to the way object oriented programming languages work.

Ruby is an object oriented programming language, which means it focuses on the interaction of objects rather than a sequence of tasks like in procedural programming languages. Three main components of an object oriented programming language are Classes, Objects, and Methods.

Classes and Methods

In Excel, think of cells, in general, as a Class. The Class called ‘Cells’ has specific characteristics and behaviors that it can execute, which are defined by its Methods. What is an example of a Method that the ‘Cell’ Class would have? The ‘Cell’ Class would definitely have the ‘sum’ Method, which would take in parameters (maybe an array of other Objects) and calculate it’s sum. Below is my basic interpretation of what a ‘Cell’ Class might look like with it’s first two Methods, the initialize Method and the sum Method:

class Cell
  attr_accessor :value
  def initialize
      @value = 0
  def sum(array)
      @value = 0 #resets value to zero
      array.each do |cell|
          @value += cell #performs addition

Although Microsoft Excel is pretty much a closed source program, it does give hints from time to time on it’s underlying structure. For example, in this picture you can see that Excel’s SUM function can take multiple parameters by simply selecting a cell and dragging. To me, this is like creating an array as a parameter.

Viewing each cell as an Object

Each individual cell that you see on a spreadsheet could be thought of as an instance of the ‘Cell’ Class, more commonly referred to as an Object. Each cell instance has a separate location on the computer’s memory, has access to all of the Methods of the ‘Cell’ Class, but the instance variables within each cell can contain different values depending on what you put in. So, think of the ‘Cell’ Class as a template for each of the individual cells on your spreadsheet.

The way I imagine Excel to work is that all the cells you see in your spreadsheet are instantiated when you create a new file. In the following code, I’ve created a basic spreadsheet with one column and four rows:

a1 =
a2 =
a3 =
a4 =

Based on the previous code we wrote for the ‘Cell’ Class, each of these cells is unique, but can perform the sum Method in the same as every other cell. Now, let’s add some values and use the sum Method:

a1.value = 5 #This is like typing in a value to a cell
a2.value = 5*5 #This is like typing in a math operation into a cell
a3.value = (6*4+6)/10
a3.sum([a1.value,a2.value]) #This is like over-riding a cell's value using a sum Function by clicking and dragging multiple cells

I haven’t yet figured out how to show IRB output through markdown, but I can assure you that the answer for the last line of code was indeed 30.

There will always be a special place in my heart for Excel. Eventually, it will have to make room for Ruby and other languages as I become a more and more proficient programmer. At some point, I think it would be really interesting to read a little bit of Excel’s source code and compare my conception of it’s inner workings to reality!


Transaction Consultant Turned Tech Trainee

For my first blog post I feel obligated to briefly explain why I am here at the Flatiron School learning computer programming.

Cues from the work I enjoyed doing

As an analyst who worked on corporate mergers and acquisitions, I loved building and improving complex financial models. For some odd reason I actually enjoyed handling large excel data-sets with complex schema, designing scalable and dynamic models, and making tools more efficient and replicable.

I always felt I was adding the most value to my company and our clients when I was creating well-designed models that others could easily understand and use. As a result, I decided that I wanted to expand on these skills and explore broader ways of creating interesting and useful tools more generally. Naturally, I gravitated to computer programming.

Creativity through code

The opportunity to be creative every day is very important to me. Avi Flombaum, Flatiron’s fearless leader, always says that computer programming is all about expression; that it is a creative pursuit. Everyday Avi shares with us quotes from his favorite developers. Of all the ones I’ve heard over the past two weeks, my favorite is this one from “Why the lucky stiff”

When you don’t create things, you become defined by your tastes rather than ability. Your tastes only narrow and exclude people, so create.

My goal for this course is to create as much as I can, whether it’s building a complex web-application, writing an open-source Ruby-gem, or just sharing something I learned through this blog.

A quick word on doing passionate work

People who have yet to find their ‘calling’ sometimes wrongly believe that their passions are latent, un-manifested parts of their identity that they’ve yet to unearth and discover. I felt this way for many years, and it put a lot of pressure on me. Big questions like “what is my passion?” and “how can I make a career out of it?” yielded either no answers, or too many (both equally paralyzing).

Doing passionate work is less about finding the things you are passionate about, and more about working really hard to become good at what you do. It’s easy to say, “I can’t do this, I don’t think this is my passion,” when things get difficult, even though there was a really good reason you decided to pursue that endeavor in the first place.

Computer programming is going to get really, really hard over the next few months. There will be times when I won’t understand a concept, or will be doing tasks that seem trivial at the moment. But, fortunately I know that my interest, enthusiasm, and love of programming will only grow as I become more and more proficient.