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…)

 

 

 

The long winding road …

Adding onto this last post, in case it wasn’t clear, the boot camp has turned up a notch this past week, and it’s definitely the start of a long and winding road. Up to this point, I feel like much of the course content was manageable by doing extra prep work and being extra prepared but rails has been a wholly new experience (and quite the kick in the butt!).  Coming from a relatively technical background, it’s been very humbling to realize that I can’t just break-to-basics-code-my-way through this like we were doing with the fun ruby and sql exercises. I do  need to sit down, read the docs, learn the syntax, ask for help and actually listen (the listening part being the hardest part for me personally). 

For example, this past week, my objects/edit route decided to quit. I spent two whole freaking hours trying to debug this problem and spinning my wheels. I peeked over at my classmates’ screens, made small talk about this stupid error I was having, scratched our heads a bit, and within the many half-hearted suggestions I got, was the answer, though I didn’t realize it at the time. I gave up, went home, and sure enough the next morning, found out that because I’d defined my edit path below my object/:id path, the “edit” portion of the url was being recognized as a form of :id.

Two hours of my life that I will never get back. In a previous life, this would have been two hours that I wouldn’t know how to charge on a time sheet, and would have had to eat. Two extra hours I would have had to work to have the minimum 40 chargeable hours. TWO HOURS BECAUSE THE ORDER OF MY ROUTES WAS SET UP WRONG. Not only this, but two hours that I could have saved had I skipped ahead and just used resources instead. The next day, I told my class mate that his suggestion was right, but I was kicking myself for not listening more actively.

Moving forward, I think I’ll actually be using a timer so that I force myself to walk away from a problem if I can’t see it within a reasonable amount of time, and actually opening up to people sooner and taking the feedback more seriously!

Likewise, today, I spent three hours just reading through and inserting comments on my models, views and controllers we’d generated with a class mate, which has honestly been one of the most helpful experiences thus far. I think repetition makes for muscle memory and ability to reproduce, but actually following through each step of the code can be equally helpful (albeit time consuming and tedious at times). As we went through and started identifying things we didn’t know, the more we started seeing things we didn’t understand. Again, incredibly helpful, but a solid butt kicking none the less.

Reiterating the point above, DevHub hosted an event tonight titled ‘Dear Junior Developer Me’. I was a bit worried that this event would be just repetitious and time I could really be using to better learn rails. However, it was a good opportunity to hear what people had experienced and what their thoughts were. I was impressed by the overall supportiveness of the community and the quality of the discussion. I’m really looking forward to learning more as we move forward!

Using the Right Tools

Hello there!

The past few days have been a bit of a whirlwind, so I’ll jump right in.

The right tools and Object Oriented Programming

If you recall, my last post was a rather lengthy ramble on object oriented programming, and getting objects to interact. As it turns out, I had a chance to talk about this some more with some folks, and here were the conclusions:

• in most cases with web applications, you only need the instance variable to be “alive” for the duration of that request, such as using an instance variable to store information regarding a particular object that you want to show or view or update or delete.
• if you need this class instance to survive beyond individual server requests, then this information would typically be stored in a database
• Global variables don’t seem to have much protection (i.e. limitation of read/write access doesn’t seem to be a thing), so should generally be used with caution. If you’ve got a lot of global variables going on, it’s probably a good time to step back and reconsider.

 

Databases 

Speaking of databases, we jumped into SQL-land this week! Speaking of data, this would be a good time to throw in a plug for Big Data University and Khan Academy as I’ve found these 2 resources to be quite helpful in my previous dabbling. Khan Academy was the right balance of instruction vs. sandbox for me to learn and play with columns/queries/rows, while Big Data U’s in-person meetups here in Toronto supplemented some of the rather large leaps in content I was facing with a MOOC I was taking at the time, on R programming.

HTML/CSS and Ruby Lightning Talks 

Last week, we also had a day to decorate our very first web application, using html and css. Overall, I ended up spending an embarassing amount of time on this, and quickly cycled through the following 5 stages multiple times over the course of a couple days. I’m sure everyone who is not versed in CSS positioning witchcraft may recognize this:

• Denial –  I’m sure it’s just a missing semi-colon or some syntax issue, let’s just retry float. Hmm, absolute positioning? Ok, let’s try relative. Fixed? Have we tried float yet? Ok, let’s just try relative and  float. How about absolute?
• Anger – Ok, I know that I’ve set my margins and padding correctly and I’ve got my syntax down pat. This is not me.
• Bargaining – I can live with text scrolling over the banner, it’s functional right? And who cares if these 2 columns don’t start at the same height on the page? Win the battle, lose the fight, am I right?
• Depression – I’ve spent how many hours on this? Why is this taking so long? It’s me, isn’t it?
• Acceptance – I guess this is just how my website is going to look. Ok. I think the picture below pretty aptly describes this stage. Lots of head scratching, and “what? why?  um, ok, I guess.”

Figure 1: Self portrait, created using CanvasPaint (2016).

Eventually, I got it working, but sure enough, this week, I attended a Ruby Lightning Talk event, which included a presentation on Flexbox. If only I’d known a week ago!  I guess we live and learn.

Rails

Today, we started on Rails at last! It’s been exciting so far! Finally, the content from the earlier RailsGirlsTO event on presenters was starting to click, in a vague and fuzzy way. After finishing today’s assignment, I decided to play around a bit some more with creating a web application to store hiking trails. As it turns out, I think I have a knack for playing around and breaking things (but it’s been fixed!). Here’s what I learned in the process:

• Rails is a framework that ties together many things, including ruby, a database, html/css formatting, other dependencies, and the rails framework itself. Although the rails documentation is a good starting point, you may need to go to the documentation specific to what you are working on. For example, I tried to create a database with columns of various data types including strings, integers, and arrays to store names of trails, trail lengths and latitude/longitude pairs for trailhead location. As it turns out, SQLite3 doesn’t support arrays as a column and had to be fixed through some further horsing around with migrations.
• Convention convention convention. What more can I say?

Anyways, post over, good night! Excited for tomorrow’s visit to 500px!

p.s. speaking of 500px, and being extremely out of the loop, I decided to check out the site and sign up for it yesterday. I was immediately hooked by the positive community! Check my (admittedly quite amateur) photos out! link here!

Ruby, Git

Hi there!

Ok, here we go. This post is a bit selfish, and it’s a bit more about me trying to document things I’ve played around with and key concepts/misconceptions I’ve had with the topics we’ve covered to date over at Bitmaker (the coding boot camp I’m at!).

Git Experiments

Ok, so on day 1 we learned about git and github and the genius that is Linus Torvalds. Following this, I got a bit curious and decided to do some experimenting. If you’re interested, I’ve saved my notes at my github: https://github.com/mokutsu/test_repo

Below is the cliffsnotes of git from this experience. In no way is this an extensive test, it was something I just got a bit curious about.

I find it easiest to think about git as a tracker for a folder. If you initialize the folder, this project folder is now “viewed” by git for changes to its status. New files are noted as untracked, changes need to be staged, and then are ultimately committed as an entry into the logs that record the history in that folder. This brought me to the following questions:

1. What happens if I rename files or copy them and delete the original within the folder?
2. What happens if I move the file outside of the folder, such as into parent directory that contains the project folder? What happens if I move the file back into project folder?
3. What happens if I make subdirectories within the folder and move files into that subdirectory?

As it turns out, any changes within the project directory (including creation of subdirectories housed within the main project directory) are tracked by git and noted/available to be committed. As soon as files are moved out of this project directory however, the file is no longer visible to git, and cannot be tracked. If I make changes to files while outside of this project directory, git is not able to see this. If i copy the file back into git, ultimately, it starts getting tracked by git again.

Next steps from here are to further explore merging, branching and testing conflicts between github/local copies, testing merging 2 repos (if that is possible), and conflicts between local copies on 2 different machines.

Ruby and Object Oriented Programming

We took a few days on the fundamentals of ruby and object oriented programming. Interestingly enough, it took a little while to sink in what “object oriented” really means. Hopefully, this is/was/will be more obvious to you.

Classes: Blue Prints, Recipes, Ikea Manuals 

We’ve learned that in ruby classes are used as a blue print for making instances of objects. Another way that I like to think about this is that I’m writing an ikea manual for a piece of furniture. The manual sets out the pieces that should be contained in the box, pieces that may be contained in the box depending on what version you purchased, and how to assemble the pieces in the most basic way possible. The instructions for the manual need to be written so that even someone who takes everything completely literally will understand it and be able to use it without ambiguity. The instructions also describe how the furniture should be used (e.g. couch can fold out into bed, rocking chairs can be used like so), and sometimes also includes how it should not be used (e.g. do not stand on table).

Object-oriented? Object? Oriented?

Traditionally, in online self-learning platforms, the phrase “everything is an object in ruby” is repeated, without explaining what does that even mean? I know that a class is an object, but what does it mean to make a program “oriented”?  Below is a way I tried to justify what this meant to myself.

To orient a program in any way means (as taken from the  the merriam-webster dictionary):

• to change or create (something, such as a book or a film) so that it appeals to a particular group of people or is suitable for a particular group of people

• to direct (someone) toward a goal

• to place (something) in a particular position or direction

 

As I understand then, the program really fits primarily into the first 2 categories. Object-oriented means that the program is created so that it is geared towards objects, and is defined by objects.

This is where I had my question: Understanding that an object has a state and variable, and Classes are objects, what’s the justification for placing all of the code within the Class? Wouldn’t it be better to follow the DRY principle and place methods outside of the Class so that different classes need to access the method?

I thought about this some more and asked around and it seems that the DRY principle is counter balanced by 2 other principles:

1. Don’t make things accessible if they don’t need to be
2. Make your code readable

Ultimately, I was convinced that methods should be placed within the Class because of these 2 principles, provided that the method where possible.

Let me know if you have any further thoughts on this!

Programming Work Flow

Here, we talked about different design philosophies, including waterfall vs. iterative.

Coming from an ISO9001 company with a fairly well defined quality management system, the different QA/workflow procedures was quite interesting, especially in web development where reaching market first is such a crucial part of business.

I think that in the coming years, it’ll be interesting to see how industry-wide QA standards will develop and fight to stay relevant in an increasingly web-based economy. Recognizing that ISO standards are technically at the corporate level, it’ll be interesting to see if industry best practices (e.g. the ruby style guide) become implemented.

Testing

Building on yesterday’s topic, we learned about testing and debugging today. Reading and writing unit tests was a good way to force us to program in a way that really focused on the inputs and outputs of the program.

RailsGirlsTO

Lastly but not least, a few of us decided to check out the RailsGirlsTO event tonight, which was about the presenters in rails. Ultimately, much of the technical topic went a bit over my head. It did however seem to tie in and build a bit on these 2 short Codeacademy videos that I saw earlier this year (front end side and back end side). I think there were 2 take away messages:

1. regardless of the complexity of the project and whatever you are working on, readability is key. A big part of this is keeping blocks of code seperate and integrating only where required (i.e. don’t make a big single block of code cross-referencing all over the place if you can alternatively make a few medium sized blocks of code instead that are a bit more self-contained)
2. the local community is incredibly supportive and a great resource! I was genuinely impressed by how friendly/welcoming the group was, in spite of my lack of rails experience.

Anyways, that’s a wrap for tonight for this blog, now to think about refactoring that mars rover exercise…..maybe….

Good night, and yeesh that was a long post. Will refactor later…at some point…