Week Two Confessions from our T-3 Ruby on Rails Boole Posse

Follow along as our Colorado Ruby on Rails students blog about their weekly experience in learning how to become a junior level Ruby on Rails developer.


Before each course everyone stands up and verbalizes what they recently learned.

Before each course everyone stands up and verbalizes what they recently learned.

This week in class we continued to learn about the power of using Git as a Version Control System. Just a week ago, we initialized our first local git repository and pushed our changes to a remote repository on GitHub. Now we are working on creating topic branches and learning how to manage them. To practice, we forked a GitHub repository into our own account and then cloned it onto our computers. It is a coding convention to call the main project repository ‘upstream’ and your own GitHub copy as the ‘origin.’ This allows developers to work independently on large projects without the risk of making unintended commits to the upstream master branch.

In addition, we also learned how to use the ‘git rebase’ command. Rebasing is a way to update your local repository to reflect the recent changes made in the upstream master branch. It’s important to do this so that your own commits will be made based on the most recent version of the master branch. Commonly, you will run into merge conflicts where the upstream master files and your files don’t match. In these cases, we learned that a command line tool called ‘MergeTool’ helps the user resolve these conflicts. After you finish resolving merge conflicts, the next logical step would be to push your commits to your own remote repository. Unfortunately, because of the changes that you rebased from the upstream master branch, you will have to force push them to Git as it’s the only way to move the changes to origin. In general, only topic branches should be force pushed to preserve the master branch.

One of the most important things to become comfortable with if you want to become a successful developer is the command line and it’s interface. The Terminal, as it’s called on Unix operating systems like OSX, is the heart of communication between you and your computer. The commands you run inside the terminal give you full control over the computer and all of it’s components. It’s important to learn these commands so that you not only have a deeper understanding of the connection between code and the computer, but you will also need these commands working as a developer professionally.

So everyday, outside of class, we have all been reading about the commands that every programmer should know. When it comes to Git and managing projects, we have realized that some commands get used all the time, such as mkdir (make directory), while others such as "pushd" (push directory) require more independent repetition. The homework is great because it’s structured so that not only do we learn how to use the command line interface, but we also get

simultaneous practice with Git and Pivotal Tracker. With all the iterations and homework, it’s assured we’ll be command line gurus by the end of class!

In between working in the terminal and learning about Git, we also took a lot of time to explore some of the theories of how to work effectively and become a part of the programming community. The first thing we covered was the idea of building your own brand; in other words, making a name for yourself. One of the ways that many people accomplish this is with a blog. As part of class we all created a blog to document the things we are learning throughout the course.Hopefully it will help others learn from our mistakes, and help us grow our professional brand at the same time. As of 2015, the blogging platform Wordpress is still the way to participate in blogging for most of us because of its convenience. Documenting our process in a blog is made easier by using Gist to include snippets of code directly into our posts. Some of us have even been using video screen capture or the Skitch app to make things especially clear for our readers. Part of building a brand is documenting what you are doing and so any tools that help with that are valuable.

Blogging also ties in nicely with the importance of mentorship for new developers. Often, developers rely on guidance and advice from mentors to accelerate their learning and challenge them to look at problems from different perspectives. Reading blogs helps us learn from the mistakes of others and think about why we do things a certain way ­ or not. Ultimately, the goal is to teach and learn from each other and experienced mentors can greatly help guide you in your path to becoming a full­ fledged developer.

Another concept that we dove into this week was that of pair ­programming and working directly with another developer to write code. The idea of pair programming involves a “driver” (someone writing the code) and a “navigator” (someone to help solve problems, give suggestions, keep track of the design, come up with tests, etc.) Some of the benefits of this is increased productivity, more focus, less interruptions, better code. Some of the main things to remember are to talk often, switch roles, and collaborate. Sometimes another person is not available to pair with or talk to, in these situations it’s absolutely essential to have a rubber duck to explain your coding issues to. OK, perhaps that was an exaggeration. Nevertheless, the rubber duck method is therapeutic and surprisingly effective.

Finally, we discussed the Agile style of development as an ideal to strive for. It is a collection of principles and best practices that work well in the modern development environment. The central idea is to rapidly come up with something, a prototype, based on the actual needs of the user and then rapidly iterate upon that. These iterations occur in intervals that are referred to as “sprints”. Pivotal Tracker is designed specifically to work in this way. The Agile method stresses the importance of feedback and building upon what is there and what is working, even if it is just a start. This is contrasted with the idea of trying to imagine everything in detail before hand and then having it not work out because the user wasn’t able to explain exactly what they needed or you weren’t able to imagine all the obstacles that would come up.

The overall theme of week two involved applying lessons about how coders can work together and exploring the best practices to ensure that developers are on the same branch, so to speak. While independence and building one’s personal repertoire and repository are essential, we see that there is tremendous value in collaboration done right. Through the use of coding conventions, the Git Version control system, the Agile development method and pair programming, budding programmers like us learn the habits that make us both efficient and able to work in harmony with shared goals of our individual projects.

Sincerely,

Boole posse, t3­2015: Tim Park, Danny Debevec, Sue Uyetake, Matt Michnal, Riley Jones

Powered by Top Rated Local® --------------------------------------------------->