A little background. This 9 week class prepared us to build web applications with Ruby on Rails. Ruby on Rails is a web application framework that runs on the Ruby programming language. Ruby on Rails utilizes a software pattern called MVC (Model - View - Controller) that divides an application into 3 distinct components. The Model, which represents the data, business rules, logic, and functions. The View which represents the output of information. And the Controller, which is what accepts the input and converts it into commands for the Model and View.
The course is divided into 3 Phases, Phase one: Modeling, Phase 2: The Web(View/Controller), Phase 3: Ruby on Rails. Each phase took 3 weeks with a pass/fail assessment the third Thursday of each Phase. We had weekend projects that were done in groups starting in Phase 2 and built a final project at the end of the course. Each phase was further broken down into weeks where our focus was trained on a different aspect of web development.
In order to not give too much away about the program, I am going to give a 60,000 foot view of each of the weeks in Phase One
To start, I love this quote by Martin Fowler.
“Any fool can write code that a computer can understand, Good programmers write code that humans can understand.”
Week One - The Ruby Programming Language
Going in, I thought I was pretty well prepared for this. I had been studying ruby for a few months and had worked through the books “Learn to Program”, “The Ruby Way” and “The Well Grounded Rubyist” prior to attending. Unfortunately, unless you are actually coding and working through complex challenges that really interest you, working through books can only take you so far. I learned a lot but “Learn to Program” was probably the best for rudimentary knowledge due to the fact that part of the book is completing problems the author has laid out and explained.
Regardless, no matter what any of us in the program did to prepare (aside from having a computer science degree), not many of us were prepared for what we faced on a daily basis. We had between 3 and 6 coding challenges for us every day that stretched our knowledge and built upon what we had learned the previous day. Most of our challenges during this week revolved around logic and algorithms.
On top of all of those difficult challenges, there was another challenge to accept and embrace, “Pair Programming”. I wasn’t prepared for this aspect at all. I had been working by myself for the last 10 months gearing up for DBC. It was a shock to the system to say the least. In the beginning, I had a hard time listening to the suggestions from other people, their critiques, and having my pair challenge my thought process. I think it is an invaluable tool now, but It was difficult for the first couple of weeks. There is also the interesting dynamic of explaining to your pair what you intend to do before you attempt to do it. For some reason I found it to be much more difficult than it sounds
What I got out of this week. A great appreciation for the ability to be able to break any challenge down into smaller, manageable pieces and build the solution up, thoughtfully and progressively, to completion.
Week Two - Object Oriented Design in Ruby
In the first week, all of our code was written as procedural programs. A procedural program is where the computer reads your code like a page in a book. It starts from the top of the ‘page’ and executes your code sequentially down the ‘page’ to the end of the program. Starting Week 2 and throughout the rest of DBC we focused on Object Oriented Programming. I am going to do my best to describe this, but just know that there are books that are hundreds of pages long dedicated to teaching this concept and that people have worked years to learn and hone these skills.
Object Oriented Design requires the programmer to model their programs as a series of messages that are passed between objects. Each object that is built controls specific data, and behavior is built onto each of these objects in order to give other objects access to that data. These behaviors contain messages (data) that are sent between objects. A program can have any number of objects, and some objects will collaborate while others may be stand-alone. The goal is to make all of these objects have as little dependency on each other as possible, so as to remain easily changeable and flexible, while still producing the required output.
The challenges during this week were particularly difficult since the remainder of this course revolved on the fact that we grasped this concept.
What I got out of this week. The week before I learned how to break a problem into smaller pieces. This week I learned how to make pieces from different objects work together while making sure those pieces were portable and easy to adapt.
Week 3 - SQL and Database Relationships
SQL is a database language. We learned SQL because virtually every application contains data. This data is stored on database tables and depending on how much data you need or want in your application, you may have 1 table or 20. Inputting data, storing data types, and managing the data is done with the SQL language. Accessing that data is done through the SQL language and the relationships that have been put into place between the tables.
Relationships are of 3 types, one-to-many, many-to-one, and many-to many. Setting up the relationships between the tables and then accessing that data efficiently through those relationships is what we focused on. Each day we were given new data in different formats. The object of our challenges were to build the tables, build the relationships to access the data on those tables, and then access that data in an efficient and logical manner. We were also introduced to ActiveRecord, which is a query interface that works in conjunction with the SQL language.
What I got out of this week. The data your application uses and gathers is incredibly important. If your tables and relationships are not set up correctly from the start, it is not an easy task to modify those tables after the fact without risking the loss of data. Planning is key. My grandfather used to say, “Measure twice, cut once.”
The Assessment
I found this assessment very difficult. It was broken into 2 parts. The first part was the actual assessment and the second part was a code review by an instructor. We had 4 or 5 challenges that were vaguely worded, meaning that there was a lot of room for interpretation. I must admit, after reading through the assessment, I kind of freaked out a little. On top of the fact that the questions were hard, I was wearing noise canceling headphones while listening to a Sigur Ros Pandora station hoping it would calm me down and help me concentrate. Not a good move. The silence combined with the music was unnerving. I was in my own little world. Strangely, I found out that it is possible to be too focused. I had no idea that other people were asking questions and having trouble like I was. I took the headphones out as soon as I figured out what I was doing to myself and I was much better. Apparently I did pretty well on the assessment.
The code review. This is the very first time I had had someone with a critical eye look over my code and openly challenge my thought process and assumptions. Ego check. It is structured so that the instructor would ask you about your code and why you wrote it in the way that you did. They asked some pretty difficult questions and expected concise, intelligent answers.
What I got out of it. Just relax. Take a deep breath and do the best you can. It does not help to add more pressure to yourself or the situation than is already there.