Screener

Q1.markdown

When beginning a new project, the most important thing is to view it from the eventual end user's perspective. Determining how my software can improve a user's day-to-day life is my goal in any software project. To gain perspective of their workflow and goals, I seek out and solicit feedback from potential users early and often in the process.

Initially I try to capture the essence of the project on paper – taking notes, sketching interfaces, and drawing out data flow diagrams. This gives me a reference when speaking with and soliciting feedback from users. Once the concepts begin to gel, I'll transfer paper notes to a digital format. I store features as cards in trello or github issues via waffle.io, and begin a rough html mockup, typically using bootstrap for quick iterations. Moving project notes to digital feature cards allows for easy prioritization and focused communication with end users.

Once we are comfortable with the core concepts of a project, and have features prioritized, building the actual product can begin. Soliciting feedback throughout the coding process is crucial. The process is fluid though, as features always need to be clarified or tweaked to result in the best possible product.

From there, the iterative process continues, building the product, validating concepts, and gathering feedback. Another thing I strongly believe in is launching the product as early as possible. This allows me to gain perspective from even more potential users, and integrate that knowledge back into the product.

Q2_Option1.markdown

The following is my opinion on the proper way to structure a web application using a modern framework, with Ruby on Rails as the example.

Ruby on Rails (as well as most modern web application frameworks) use the MVC pattern. MVC stands for Model, View, Controller. For a quick definition: the Controller handles requests, building and returning responses. The Model is an object representing database-persisted data. The View provides a means to to create a response (in HTML, JSON, or other formats).

MVC works fine in theory, however too often apps become bloated in the Controller or Model layer (or both!). They accrue code and concepts that have little to do with the responsibilities of the Controller (handling client requests/responses) or Model (storing and retrieving objects from the database). This cruft makes maintaining these apps more difficult than it needs to be.

There is an unnamed part of any MVC framework, and that is the Workflow Code. This is the business logic that needs to occur to achieve success in any application. If the client requests we create a "new widget" with a call to /widgets/create, it may require any number of actions such as validating the request, persisting the widget to the database, updating other parts of the application, sending email, etc, etc.

This code is often mistakenly added to the Controller or Model layer, cluttering their responsibilities and tightly coupling the application's business logic to the framework.

A better approach is to abstract Workflow Code away from the framework, and into simple objects. These objects are responsible for performing the actions required to achieve the desired outcome. Ideally they have a single responsibility and are easily testable. This Workflow Code encapsulates the process of taking data provided to the Controller, coordinating with Models to accomplish workflow actions, and returning data necessary for the Controller to create an appropriate response.

The reason decoupling an application's Workflow Code from the underlying framework is vital is, say 10 years from now, the app I am building will most likely not be running on Ruby on Rails. However, the business logic required for the success of my business may be the same. By encapsulating this critical business logic I can easily port the necessary actions vital to my application to a new framework.