Software Engineering at Flatiron School — A Guide to Each Phase

I’m so fresh of a graduate of Flatiron School (28th September 2020 to 8th March 2021) that I’m not even sure that I am a graduate yet. However, with my final project review completed and passed, I wanted to run through each phase and talk about what is required, what will be learned, and what especially to remember going forward for future students.

For each Phase, I will look at the following key points:

• What the project roughly needs to be;
• The key tools used;
• The project requirements;
• What you need to remember during the project; and
• What to bear in mind for the following project.

Phase 1: Programming Fundamentals

The Project: A Command Line Interface (CLI) which provides data from an external source (i.e. a web page). Built with Ruby.

The Key Tools

• The Nokogiri gem.
• The OpenURI gem.

Project Requirements

• You should be able to make selections within a menu system in the CLI in order to gain more information about that selection.
• Use good object-oriented design patterns.

What to Remember Now

This project is really essential in understanding object-oriented programming (OOP) and will be your first exposure to using gems to perform functionality you would not ordinarily have.

Fundamentally, what you are doing is extracting data from web pages using the Nokogiri and OpenURI gems in close tandem. In fact, in this project, you will probably not see one gem without the other. You don’t really need to understand the ins and outs of either gem, but OpenURI essentially prepares a temporary file containing data from the webpage. Nokogiri is able to parse this data into HTML and, from Nokogiri’s output, you will be able to select pieces of HTML that you actually want to appear in your application.

That part is most of the struggle. Once you have parsed and saved your data as instances of different classes, and your classes are fully populated with the data you want to display on a CLI, the remainder will be building a menu system which will render out options and, based on a user selection (say, by typing in a number), will render out something new. Think of it as an elaborate system of if-else statements and lookups.

If you struggle with any stage of the code, someone out there has also certainly struggled on a similar problem and has asked the same question. In all likelihood, you can find it on Google. I found that a good habit is to bookmark all web pages which have solved the problem that you have; something about this process feels like checking a box and is therefore more likely to make it stick in your mind so that the error isn’t repeated. Also, if you run into the same problem again and end up frustrated looking for the answer you had a few days ago, it’ll be in your bookmarks!

What to Bear in Mind Later

You will likely never use Nokogiri and OpenURI again for the remainder of this course and, in any case, you don’t have to. However, scraping data from external sources is an important and useful skill, so it’s good to have in your arsenal.

On the other hand, classes in Ruby are incredibly important and it’s worth getting familiar with class variables and instance variables. Also, the only phase that doesn’t involve any Ruby at all is Phase 4, so make sure you understand and remember everything you are taught.

!!! Side note on GitHub

This is a good time to learn the basics of creating and committing to a repository on GitHub. Getting into the swing of frequently committing to GitHub is a habit best learned early, both for the protection of your own work and generally as good programming practice. Make sure to create and commit to your first repository as a matter of priority and think, after making your initial commit, “what do I need to implement/achieve next”? Once that thing is implemented, commit with the relevant narrative.

An often-repeated sequence for GitHub commits is:

1. git add .
2. git commit -m "some message for the commit"
3. git push

In sequence, that reads in plain English as: “stage all changes to the files for commit and, to each of these files, attribute this message. Then, push these changes to my repository”.

I actually do not encourage this. This means that minor changes in other files that you may have altered along the way, whether it’s fixing a typo or adding a comment for later, get caught in a big commit under an irrelevant narrative.

If you are using Visual Studio Code, it is best to look through the changes in each file (you can compare before-and-after changes side-by-side) and determine what has changed. When satisfied with the change you have made, add a file-specific comment after clicking the “+” icon in Changes to acknowledge it, press Ctrl+Enter (or the Mac equivalent), and work through each changed file. Once you have completed this, you can type git push in the terminal or however you prefer to push.

Phase 2: Web Frameworks

The Project: A Content Management System (CMS). Built with Ruby, aided by Sinatra.

The Key Tools

• Sinatra
• ActiveRecord
• HTML
• bcrypt (optional?)

Project Requirements

• Use a Model-View-Controller structure.
• Use ActiveRecord.
• ≥2 models.
• ≥1 has_many relationship, ≥1 belongs_to relationship.
• Have user accounts.
• Validate uniqueness of user login details.
• Users must be able to Create, Read, Update, and Delete (CRUD) their own resources, and also be unable to Create, Update, and Delete others’ resources.
• Validate bad user inputs so that the data does not reach the database.

What to Remember Now

You will not use Sinatra again after this. On the other hand, Active Record is still prominent in Phases 3 and 5, so a good understanding is crucial. Active Record Associations are also tremendously important and can make your life significantly easier later down the line, so keep that page bookmarked.

When learning SQL in the course, acknowledge its importance but do not fret too much over it for this course. The ActiveRecord gem takes care of a lot of SQL under the hood, allowing you to persist, edit, delete, and read data from the database without rooting around in actual SQL code. When you get to Rails, you will certainly see lines of SQL firing off in the background, so definitely maintain an appreciation for it even if you are not actively coding with it.

Make sure that you have a good understanding of creating new users. I believe encrypting passwords at this stage is not a requirement, although get familiar with bcrypt and what it can do for you; it is not difficult to understand what it is capable of and yet how powerful it is when encrypting user passwords or, potentially, other sensitive data.

Try to avoid front-end logic by dealing with as much logic as is reasonable within your controller and then rendering this in your view, or else your views can get messy.

If you have time, this is a good time to fiddle around with CSS a bit. Styling with CSS is actually not a requirement until Phase 5 but, if you want the versatility of being a full-stack developer, you don’t want to sell yourself short by omitting this.

What to Bear in Mind Later

This phase is, in hindsight, an obvious precursor to Phase 3. While Sinatra is good at rendering views and adjusting what a page looks like depending on data already persisted within a database, you will find that the code gets very repetitive and tedious in parts. It is almost impossible to keep the code DRY (Don’t Repeat Yourself), try as you might. However, Ruby on Rails knows this and is great at addressing this problem. Flatiron often intentionally forces you to do things the old way before trying a new and improved way (a good thing!) so that you gain a greater understanding of why certain technologies exist and how those technologies solve problems of yore.

Phase 3: Ruby on Rails

The Project: A Content Management System (CMS). Built with Ruby on Rails.

The Key Tools

• Active Record
• bcrypt
• OmniAuth
• HTML
• Rails (of course!)

Project Requirements

• ≥1 has_many relationship.
• ≥1 belongs_to relationship.
• ≥2 has_many :x, through: :y relationships.
• Use reasonable validations.
• ≥1 class level Active Record scope method.
• User authentication (sign up, login, etc.).
• Allow login from a website like Facebook, Twitter, GitHub, etc.
• Allow nested resources using RESTful URLs.
• Display validation errors.
• Keep code DRY.

What to Remember Now

The graduation from Phase 2 to Phase 3 is important, and you’ll be reminded of this kind of graduation when moving from Phase 4 to Phase 5.

Immediately, when creating your app, you will be faced with a daunting quantity of files — you will not have seen a file structure this large yet. However, it is important to note that the following directories are the only ones you will really ever need to use:

• app/models, app/views, and app/controllers;
• config/routes.rb;
• Most, if not all, of the db/ directory; and
• Gemfile

When I was building my project, I opted to temporarily hide (don’t delete!) the other directories so that I could have a clearer view of the pertinent folders and files I needed to access. There will likely come a time where you will need to unhide these directories to augment them or even add another file within one (config/initializers/omniauth.rb may be one of them), so be confident in knowing how to do that and knowing which ones are already hidden.

When implementing OmniAuth in order allow third-party logins, you will likely be Googling a lot to fix certain issues you have. Don’t be shy to ask questions to your instructor or fellow students, either; everyone knows that this can be a very fiddly part of this project.

In your Gemfile, I’d recommend adding gem 'pry-rails' so that you can throw binding.pry lines in the middle of Rails-related code. It’s a life-saver if you don’t quite know what is going on under the hood at that stage in your application and is especially useful for inspecting params.

Try to have a good understanding of instance variables and how these pass to an .erb view, because you will be asked about this in the review.

When learning about routes, learn these thoroughly, and understand RESTful conventions as best as you can. These conventions crop up again in Phase 5.

Learn about class level Active Record scope methods early and think about how to use them early on. They can be incredibly useful in executing more esoteric and unusual SQL queries and, once written once, are very easy to use again and again, keeping your code DRY.

Like in Phase 2, try to avoid front-end logic.

What to Bear in Mind Later

This will be the last time you have to deal with .erb files on this course and the last time you will work with Ruby to generate views; this will now all be handled by JavaScript since the next two projects will be Single-Page Applications rather than a system of web pages.

In terms of pure Rails, this is about as good as it gets. You can be clever and implement other gems in order to make your life easier in certain ways, but Rails is designed with expansion in mind: as your application may grow in size, it is easy to add another route and another view to it, where it would have been more cumbersome to do using Sinatra alone.

Phase 4: JavaScript

The Project: A Single-Page Application (SPA). Built with JavaScript.

The Key Tools

• Ruby on Rails
• HTML/CSS

Project Requirements

• Frontend comprising HTML, CSS, and JavaScript;
• Backend comprising a Rails API;
• JavaScript uses classes to encapsulate data and behaviour;
• ≥1 has_many relationship in the backend;

What to Remember Now

JavaScript is brand new turf and, while it resembles Ruby in parts, is not Ruby. You may find that the for loops are not as intuitive or frequently forget to put a let or const before defining a variable — that’s normal. Let yourself make errors, absorb the new error messages you’re getting, use Google if you come across a strange error.

This will be your first time writing HTML outside of an .erb file and, instead of routing a user to a brand new page when clicking a link, will actually trigger a dynamic re-render of the page. Before writing any code, it’s a good idea to map out what you want your application to look like, what you want each button, form, and link to actually do, and so on.

JavaScript on its own relies heavily on event listeners to make changes to the Document Object Model (DOM) — in other words, if you click a button or if you mouse over an element on the page, JavaScript will listen for this and once it “hears” this change, it will execute a function.

Remember that the format for an event listener goes along the lines of the following: element.addEventListener(event, function() {...}). In order for an element to be selected, it usually needs an HTML class or ID to be found, so make sure you are making good decisions when it comes to choosing a class name or ID. Bear closely in mind that an HTML ID is unique to an element whereas class names can be used across as many elements as you want.

When setting up your Rails backend, it is a good idea to run:

rails new application-name-backend --api --database=postgresql

This ensures that the unnecessary clutter of a regular Rails app does not get in the way of what you want it to do: store and provide data. Further, setting up a PostgreSQL database is a good idea if you ever want to deploy your app online. See my article on how to set up PostgreSQL on WSL if you are on a Windows machine.

Notice how, in comparison to Phase 3, the requirements are not as exhaustive. That means you have more power to choose what exactly you want your project to be, so long as you meet those other requirements. Phase 5, in some ways, is even more open-ended.

Understand the Fetch API well. This plays a prominent role in Phase 5 and is also a requirement of it. Also, as a software engineer, you will need to understand Cross Origin Resource Sharing (CORS) and it can be a real headache if not understood correctly.

JSON is fairly intuitive and obvious if you already got your head around hashes in Ruby, but make sure you keep on top of this during this phase until the end.

Get familiar with what synchronous and asynchronous mean in a JavaScript context. This is very important for this phase and the next.

If you are noticing that your code is getting messy and cluttered; good. This is a problem which React was designed to solve. Flatiron School knew this all along and is preparing you for what React can offer you and what Redux can enhance.

What to Bear in Mind Later

What you have learned here is, more or less, the extent of what you need to know of vanilla JavaScript. After this point, you will not be using addEventListener() nor getElementById() nor any functions which interact with the DOM in that fashion. React and Redux are a completely different ball game.

Stay sharp with vanilla JavaScript and make sure that you are able to implement things like for loops and iterations comfortably, as well as array and string methods. You will likely need them for the next phase.

Phase 5: Front-End Frameworks

The Project: A Single-Page Application (SPA). Built with React/Redux.

The Key Tools

• React
• Redux
• Ruby on Rails (especially if making your own backend API)
• HTML/CSS

Project Requirements

• Write in as much ES6 as possible.
• ≥1 HTML page.
• ≥5 stateless components.
• ≥3 routes.
• Make use of react-router and RESTful routing.
• Use Redux middleware to read/write state.
• Make use of redux-thunk when sending/receiving data.
• Use Fetch API to GET and POST data from the API.
• A little CSS.

What to Remember Now

Because this is the final phase, the so-called “project week” is actually more than a week. There are no more lessons after this, so you won’t fall behind. If you need two or even three weeks to complete your project, you can take it. My advice, though, is to book the project review as far in advance as possible so you can get a slot, as they can be elusive.

This is the only project that explicitly requires CSS; projects for Phases 2–4 simply recommend it. Again, like in Phase 4, plot out the project on paper or a whiteboard before starting.

The project is, strictly-speaking, an SPA. Don’t break your back trying to make more than one HTML page, but you also don’t need to necessarily avoid it.

The requirement of “at least five stateless components” can sound daunting, but you would be surprised at how quickly you will make components. Components in React are often used for UI purposes which, when you take into account perhaps a navigation bar, a main area, an “about” page, a log in form, and a sign up form, you already have five. Some of those may not be perfectly stateless, but adding more beyond that point is fairly straightforward. Try to ascertain before building a component whether it should be stateful or stateless.

Understand Redux thoroughly. The diagram below illustrates the flow of data through the Redux system, creating an Action (containing a word resembling what is to be done to the state, potentially with a payload) and carrying this across to a Reducer which will return a JavaScript object that resembles state, prompting Redux’s createStore() method to generate a brand new state and therefore update components connected to this state. This is a very basic overview, so spend time with this until you get the hang of it.

All that in milliseconds.

As regards Redux, you will come across mapStateToProps and mapDispatchToProps. Don’t just memorise these, but also understand why they are important.

When you are going through a Redux/React process of amending state, always bear in mind that you never modify state directly and that there are avenues you must traverse in order to do that. There is a reason that you should not/cannot directly modify state and you should learn why.

When working on your project, it’s easy to forget React and how it handles props and state by itself; but don’t forget. It is important to understand why React falls short in terms of data management and why Redux is a superior tool, but you should never forget why Redux is there or, in fact, how a React component can also handle state changes very well internally sometimes.

Once you write in the code for redux-thunk, you don’t have to think about it very much. The fetch() requests that you make are all asynchronous, but make sure you understand the order in which events happen in asynchronous requests.

What to Bear in Mind Later

Everything you learned from Phases 1–5. Assuming all went well, you will have graduated and you will be on the road to implementing algorithms from scratch with Ruby and JavaScript to prepare for technical interviews. You might even teach yourself other languages. But try to stay sharp with what you’ve learned and always be confident in talking about your projects and what they demonstrate — you never know when an interviewer will want to know about it or, if you’re really lucky, whether someone wishes to buy your application. Your Phase 5 project is your masterpiece, your capstone project for Flatiron School, and therefore should be the most glitzy; don’t skimp on detail.