I’m just coming to the end of completing my first project from scratch for Launch School’s RB 175 course and I just wanted to share a few thoughts from the experience
I’m going to go through and present what I did initially, the problem I faced, and what I’ve learned to do for next time.
The first thing, albeit quite obvious, is to plan plan plan before you start writing any code. We’ve gotten quite accustomed to planning out small and large code problems and then solving them that it’s become second nature in that context. However, we’ve had a lot less exposure to planning out full applications and then and then turning the plan into code.
I thought I had started off with a clear a plan:
- I wrote down all the initial steps to create a program to make sure I had the foundation set.
- I created an outline of what what the application would do and what type of information would be provided.
- I created an outline of every view template I would include, and sum up in a couple lines what each of these views would be responsible for.
- I recorded what strategy I would implement to store my data and roughly what the data structure would look like.
I’m going to quickly find out that even all this planning wasn’t nearly enough.
For the few hours of getting my project off the ground it was working great, all the planning I had done made it so I had to put little thought while writing the code. It was more or less translating pseudo-code into code.
I started to hit some snags when I was trying to create dynamic responses from my data file. I came to the realization, my data structure made certain things not easily accessible. And it was difficult to work with in a way that made sense. I started hack and slashing my way to fixing my data structure into a way that each of the necessary data points were accessible and easily manipulated. This caused my program to repeatedly recursively break, and too long was spent on fixing issues that could have been easily solved if I stared off on the right foot.
For next time, I’m going to make sure I play around with the data structure beforehand to be certain that I can access all levels of it, and to work with it more before just assuming the structure is what it needs to be.
Object and Input Validation
Another snag I ran into was that I kept having to re-work my input validation because when it came down to using the data, it made it hard to validate certain aspects of it. This (and you’ll soon come to realize, most aspects of the project) and the data structure are closely connected.
Data structure is like the blueprints of your house, while the data points are the furniture. Your furniture is pointless if there’s no easily accessible door to get into the room.
In this scenario, planning your input validation will be like deciding what your room looks like before you start furnishing it. If you pick apart what you want to do with each of these data points (or pieces of furniture) before you start using it, you’ll have a nicer organized room in the end.
For next time, I’m going to ask myself, what is the end goal for each of these data points, and how do you want them to be manipulated or displayed in your application? If you can answer these questions you’ll have a better understanding of what type of object makes most sense.
After working through my program, this is what primarily led me to discover that some of the way I was organizing my data and the types of objects used was not going to be effective in what I wanted to do.
I’ve identified a “challenge” as a problem that will be dense with Ruby (or whichever language you’re using) code, and will likely take some time to solve. You can normally spot these as a result of needing dynamic code dependent on a certain context of your program.
If you asked yourself previously, what it is you want to do with the data from the previous section, you’ll be able to spot what will be more difficult to accomplish in your application.
It can help to take yourself out of the context of your program, creating any dummy data that you need for this problem, and solve this problem on its own. Once you’ve worked through the problem, it’ll be a lot easier to implement the code into your application, and maybe you’ve discovered through working this problem that the way you’ve organized things from before doesn’t make sense.
For next time, I’m going to identify these “challenges”, work through them outside the context of the application, and also ask myself if there are ways to structure the code early on to make these “challenges” less intimidating or more easily managed.
The last thing I want to go over quickly is picking smart routes.
What I mean by smart routes is organizing your routes into groups that will have common code between them, code that can be run through a before filter.
In this case all
/:user/ routes will need a
@username instance variable, and to evaluate the
You can add a
before filter for each of your route groups. This made the readability and the cleanliness of my code so much better without too much effort. This is something I did not plan for ahead of time, so I had to work through each of the references to those routes and update them. A mildly inconvenient task but something that could have been easily avoided.
For next time, I’m going to make sure that in the planning of my routes, I organize them into groups that will share common code so that the route names can reflect that.
I’m not going to get into any front end issues that I came across, because it’s still all very new to us at this point in the program. We’ve only focused on back-end up to this point.
Keep in mind, we’re still in the exploratory phase of learning to program, we don’t really grasp what good design looks like, or what framework best fits our idea, it almost feels like we stumble upon a framework or toolkit and we just go along with it to actuate our ideas. And that’s fine.
It feels vulnerable to create something that is solely yours, and have it on display. It’s riddled with flaws, and even as I’m typing this I’m thinking of things that could be changed. At some point, much akin to a musician, you have to take the plunge, get out of your bedroom, go to an open mic, and play your song in front of others.