Big whoops.

Hello reader! This week has flown by! There has been a lot learning and a lot of things going on.

1. Mistakes

First things first, Seat Yourself. Seat yourself is the name of our group project that we started working on last week with a purpose of connecting diners with restaurants. While we were working on this project the day before it was due, we noticed some strange things. Errors we thought we’d fixed were back. Then, when we checked out one of our controllers, whole methods were missing.

As it turns out, once we broke off into pair programming, we would commit and push to the origin. However, I had managed to pull changes, carelessly accepted crummy merging and pushed to the origin master. BIG whoops. I don’t remember the exact details of what happened, but looking through our commits, I’m assuming that in my rush to wrap up the work for the day, I’d rushed a commit and caused a massive error. Thankfully, my team members were incredibly forgiving and nice and helped us get back on track ASAP. I think there’s 4 major morals of the story:

Slow down to speed up

I hate this idiom, but I absolutely see the value in its message. When I was a kid, I was constantly told to slow down and focus, in order to stop making careless mistakes. Even as an adult, this still holds true. It’s exhausting, and requires immense strength of will but it’s absolutely true. When we mess up because we’re rushing, especially something as big as the mistake I made, there isn’t a good excuse.

Commit commit commit, and write descriptive messages. Check commits!

When we did realize there were big commit errors, we called for help and ended up going through gitx to find out exactly where we lost all of our data. As it turns out, we hadn’t caught this until 5 commits and a few other merges had happened. We were strongly encouraged to check gitx every time we do a merge and just make sure things were ok.

One thing to note is that gitx only seemed to colour the first line of entire sections that were deleted or added. The positive and negative signs were used to keep track of what happened, and we ended up copying and pasting our code back into the controller.

Have a great team. Appreciate team members. 

This mistake could have completely soured our team. It wasted a few hours in a program where time is so limited. Instead, my team members were incredibly forward thinking and focused on finding the ‘where is the problem’, without focusing on the fact that I had done this. No one yelled at me. Instead, they focused their attention on solving the problem and fixing our program. I am honestly so thankful they reacted the way that they did.

Afterwards, we were required to submit a single group submission, so we submitted my github page, and all decided to fork as a bit of a failsafe (and I made a clone for a version 2.0). In case you are interested, the work in progress is at: https://github.com/mokutsu/seatyourself2.

2. Javascript

Second thing about this week: Javascript. We’ve taken a dive into the world of javascript and jQuery. It’s been pretty interesting comparing the similarities and differences between Javascript and Ruby. Javascript seems to have less built in features which can be frustrating and some concepts such as ‘this’ are still proving to be tricky. However, being a bit of a ‘verbose’ programmer, at this point, I really like the explicit looping conditions that Javascript.

Debugging in javascript has also proven to be challenging, and using the right tools becomes key.  After struggling with debugging with node in the console, it became clear that I should be debugging in the browser. The dev tools provided in Chrome are friendlier, and allow for more ‘poking and prodding’ to see what variables are being set and which ones aren’t working.  This has highlighted the need to code in chunks and test more frequently to see what’s working and what is not as well. It looks as though slowing down to go faster will hold especially true as we get deeper into JS.

In rails, we were able to see the error thrown back by the framework, correct it, receive the next error message, and continue to build the website in an ‘error-driven development’ methodology. At this point, it doesn’t look like this will be an effective way to write code with javascript, which will be challenging. However, hearing about some of the ways that javascript is being applied across the board, I am very excited to learn more and play some more with this language.

 

Teamwork and Quartet Programming

Hello there!

When we talk about the core functionality of an app, it can be difficult to come to a consensus for some things as basic as “what does this app need to function?”.

Today, we got our feet wet in our first free(er) form team assignment to develop an application for customers to be able to make dining reservations at restaurants and it was helpful to let the notion of ‘this is common sense, isn’t it?’ take a back seat to ‘ok, let’s hear it’.

I am luckily a member in a group of 4, very competent and friendly people, and sometimes that means that we’re all very vocal when we disagree. It was really interesting to hear 4 relatively quiet(er) people have such a lively discussion. I think overall that it was an extremely helpful exercise in figuring out what exactly an application must do in order to function, and actually convincing ourselves of the priorities that we’d set for ourselves.

For example, we discussed that the restaurant model (in the MVC) must have some sort of logic to reject reservations if the restaurant would exceed its capacity. It seemed quite clear to me that there was no point in having an application to make reservations if you could make as many reservations as you wanted without input from the restaurant of any sorts. However, we then started discussing other factors like restaurant hours, days of operation, that would also factor into how useful this application would be in the real world. We then realized we had 4 school days to achieve this and it’s been less than  a week since our introduction.

Understanding our limitations, we decided to make assumptions in order to progress forward, and left such logic as restaurant capacity and hours of operation to our second sprint (yes, we are making quite small sprints, but I think this helps us in producing a functional app when we approach our deadline!).

After we worked out our plan on the white board for a couple hours, we progressed to quartet-programming (programming with the power of 4 eyes on 1 screen!) for the initial creation of the repository, the rails project, the models, controllers, routes and some views. It initially seemed a little clumsy at first, but it quickly proved its worth. I can see how this would be extremely helpful for:

• agreeing on and visualizing the models, model relations
• agreeing on and visualizing  controllers (and their actions), necessary views, model relations and how the routes are related to each other
• agreeing on naming conventions and how to break things up so that it’s easier to format down the line (e.g. everyone using divs at each level of their forms)
• picking up typos
• having someone look for logical errors, other people looking for syntax errors, and multiple eyes to comb through the code
• keeping the team informed of changes or difficulties as they’re encountered
• getting exposure to other people’s strengths / your own weaknesses and vice versa (e.g. I’m ok with visualizing routes and how they relate to actions/models and model relations, but I’m terrible at remembering syntax)

Moving forward, we’ll be breaking into pairs, but this was a very helpful exercise. It’ll be interesting to see, at some point down the line, how this process works with a test driven development approach, or if a larger, more diverse group of people are involved in the planning phase.

Anyways, onward to rails guides! Woot woot! (…sigh…)