Remembering What I’ve Learned At The Iron Yard – Final Project Time

If my final project were code…

Two weeks from today will be the first Monday in twelve weeks that I don’t need to be at The Iron Yard for by 9 a.m. classes.

I think I’m going to miss some parts of it.

Anyway, we aren’t there yet. Like I said, that is two weeks from today.

Till then I have a singular “fairly large” final project to work on as well as a string of “fairly small” homework projects that will be based on in class stuff.

At any rate, I’ve done a fair bit of thinking about the project and in the past few days have actually started to build it. (I’ll show it to you when I’m ready to.)

There are a few things I’ve learned in the past ten weeks that I will definitely be trying to keep in mind as I work on this.

Here are a few that I’ve thought of…

• One thing at a time: I’ve written a few posts in the past about breaking things down and approaching the entire build process one step at a time. Since this particular project is quite large (probably beyond the scope of the next two weeks) I’ll definitely need to decide what is the most important and build that first. Once that base model is met I can move towards version 2.
• Keep the git master clean: It is often kind of tempting, since I am the only person working on a project, to work on the master branch of my git repository. To put it simply, this is a bad idea. Working on branches that are specific to features is a much better idea. This way I can always have a master branch that is ready to deploy to a live server.
• Get some sleep: When I’m working on stuff that I really find interesting and am personally invested in it gets much easier to stay up later than I should writing code. Somewhere near 100% of the time that I write code after about 10 p.m. I end up rewriting it or deleting it later. I’m much better off getting some sleep.
• Just what I need: I have a tendency to create a controller and immediately go to town adding in all the regular actions [index, show, new, edit, etc…] same with resources for specific models, I usually just add all of them. However this kind of approach can lead to something called bloat. My code base can become bloated and I can get confused about what is happening. I’m far better off only adding to a controller what I really need. Same with the routes. Adding only those routes that the app will use is a good idea…
• Use gems sometimes: There are hosts of gems that have been built for Ruby and Ruby on Rails. Some of them do amazing things.
• Don’t use gems all the time: There are some gems that go into every gem file of every app I create. Mostly those have to do with style (hello bootstrap, I love you) and templating engines (haml or slim, flip a coin). There are times when a gem isn’t the right approach. If all I need is very simple functionality I may very well be better off building that functionality myself instead of embracing any limitations or pain points that a particular gem may bring to the table. (Devise, I’m looking straight at you…)
• Some concepts need to be drawn out: Being somewhat of a visual person I often have a much better chance of understanding how something is built or put together if I can see a drawing of it or get hands on experience with it. Drawing data relations out before actually building the tables and their associations has been a great help in the past. It’s something that I’ll definitely be doing more of in the next two weeks.
• Freak out in moderation: I’m a bit of a procrastinator. You know that guy who did his homework on the way to school… I finished mine about ten minutes before the bus ride. Knowing that I have two weeks to build this app is great because I definitely have time to do some really cool things. However I’ve got to keep on pace if I’m going to get cool things built. That means freaking out from time to time and setting small deadlines for myself.
• API’s can be awesome: Using api’s (and gems that make using api’s easier) can be really helpful. Little things like posting to Facebook and Twitter or integrating Google Maps can be really daunting if I have to write all the get and post requests fully myself and figure out all the little details. There are some really great gems that can make these integrations much less painful. I intend to use them to open up the awesomeness of api’s.
• Testing is for the birds: To be totally honest I don’t really enjoy writing tests. However I do see the importance of having well written tests… they are also required for our final projects. While I don’t necessarily love writing tests, I will write them. Actually I intend to try to write tests for features as I build them. Not true TDD, but retrospective tests while I can still remember what my code does.
• When in doubt – Read the docs: There comes a time in most days when I am fighting to figure something out. I google for fixes. I fiddle with my code. I google some more. I fiddle some more… nothings seems to work. And then I realize that the problem I am having is actually covered in the documentation for whatever it is I’m using. Reading the documentation before (and during) the coding phase can be really helpful. Time is at a premium. Reading the documentation may seem like a waste of time, but it can also save me a lot of time in the end.

Of course there are other things that I’ll definitely be keeping in mind as I code towards my goal. I just can’t think of them right now.

Anything you would add to this list?