Always Be Coding

Part of getting out into the real world post Code Academy means collaborating with others on projects, working with existing production code, and absolutely despising git. First off, git is incredibly opaque as a language, the syntax is weird and it is very difficult to figure out what is going on at any given time. Also for some reason I find it very difficult to get help; I can't count the number of times that I've been told to “read the docs” ( they're not very good ) or that “git is awesome, and its so easy to use” ( there is mounting evidence to the contrary. ) Either way, git is a part of software development and something that I'm going to need to get comfortable with. After working with git exclusively over the past three months, here's a list of twelve tips that I wish I had known three months ago, because they would have saved me a bunch of time.

1. Name Your Remotes

You've got origin which is github, you've got heroku which is where your live website is hosted, but now what happens if you want to set up a staging server that is also hosted on heroku? Do you have two herokus? Git allows you to name your remote repositories with whatever name you want so that you can keep track of each repository as you see fit. First run git remote -v to see the remote repositories that you currently have attached to your app. The names of the remotes are located on the left. Then you can run git remote rename OLDNAME NEWNAME to alter the name of the remote. In this example I'm going to change the name of a remote from origin to github. This enables me to write git push github master when pushing which I like semantically better than 'origin'.

2. Make liberal use of alias' and customize your bash prompt

So naming your remotes sounds awesome! But the problem is that now you have to remember the command git remote -v. And was it git remote rename or git rename remote? With the numerous amount git commands out there it starts to get confusing real quick, and you'll be back to googling and stack overflowing in no time. One way to combat this is to make liberal use of shell alias' to turn the verbose git syntax into commands you can actually remember. For this example, I want to change the command git remote -v into just the command remotes. I store all of my shell alias' in my .bash_profile, and in order to change it I can go back to my home directory and run vim .bash_profile A fun fact you may not know is that calling cd with no arguments will take you back to the ~ directory. Once I'm in my .bash_profile I write alias remotes='git remote -v' and save my .bash_profile. In order for the changes to take effect I need to run the command source ~/.bash_profile in fact I run that command so often that I even have an alias for that! Now if I run remotes it shows me all of my remote repos which is a lot easier than trying to rememeber git remote -v.

There's also another variable you can configure in your bash prompt called PS1 that controls what your shell prompt looks like. If you add the following script into your PS1 variable, it will display your current git branch as part of your prompt itself. ( WARNING: Shell script incoming, hide the children. )

$(git branch &>/dev/null; if [ $? -eq 0 ]; then echo " ($(git branch | grep '^*' |sed s/\*\ //))"; fi)

3. Use git commit --amend to quickly fix minor errors

It happens all the time that you'll make a commit and then realize that you made a slight typo, or that you wanted to tweak just one more thing. Well you could go back and make the changes, git add . then make another commit, but this will lead to having two separate commits that are both essentially doing the same thing which will make looking back through your code pretty confusing as you try to remember why you made two commits there, and try to figure out which commit to checkout. There's actually a really simple way to handle this. Once you've made a commit and you realize there's something you want to change, just go and make the changes, then git add . just like normal, but instead of making another commit run git commit --amend This will bring up your default text editor and the previous commit message, now you can change the commit message as you see fit and save the file. If you look at the commit history you will see that there is only one commit, with the updated message and the updated changes. This is a really useful practice that keeps your commits organized and semantic.

* CORRECT A TYPO IN THE README *

4. Write your commit messages in the present tense

Speaking of keeping your commit messages semantic, I've found writing commit messages in the present tense to be incredibly helpful ever since I was turned on to it. Instead of writing 'Added an admin attribute to the user model', write 'Adds a boolean attribute admin to the User model.' Not only do the commit messages read better when in the present tense, but for some reason I find that wrriting in the present tense makes me think of writing full sentences and I naturally pay more attention to how my wording is structured. Writing in the past tense gives me an invitation to use shorthand and not focus on clarity, and I've noticed a dramatic improvement in my commit messages since I started writing them in the present tense.

5. Use git add -A to quickly add all deleted files to a commit

This happens all the time, where I delete five or six files out of my Rails application from TextMate then run git add . and the deleted files don't add to the commit. This is because, although you deleted the file from your application, git is still tracking them, and if you try to add the deletion to the commit, git freaks out because the files no longer exist. You can fix this manually by running git rm PATH_TO_THE_FILE to tell git to stop tracking the file, but you need to remove each file from git manually using this method. Turns out there is an easier way, and by just using git add -A it will add all deleted files ( even the ones you manually removed from your editor) to the commit in one stroke.

IT DOESN'T WORK... BUT...

6. Preface your remote branch with a colon and then push to delete it

It's important to keep a clean working environment so you don't confuse yourself down the road. One way that I do this is by deleting branches as soon as I'm done using them. To delete a local branch run git branch -d BRANCH_NAME, and it's gone. Simple enough. But now if you run remotes you will see that the remote version of the branch is still hanging out. An easy way to get rid of it is to simply run git push github :BRANCH_NAME. By prefacing the branch name with a colon, your remote repository will know to delete the branch

7. You can push any named branch to heroku/master if you use a colon

Greg and I decided very early on that we would use a branch called 'production' that would at any given time be exactly what was live on the production site and deployable at any given time should something go catastrophically wrong. As it turns out heroku doesn't like branches not named master being deployed and will, by default, look for a local branch called master to deploy. On the remote heroku, the branch that is live will always be called master, this you can't change, so we need to tell heroku to deploy a branch of a different name, such as production, to its remote branch that is always called master. In order to do this you can use a colon in between the local branch name and the remote branch name. git push heroku production:master will push a local branch called production to the master branch on the remote called heroku. I find myself doing things like git push staging staging:master very frequently now in order to keep a local branch called staging, and still be able to push it onto a heroku master branch.

8. You can use semicolons to chain together terminal commands, and thus run multiple git commands in one line

Something that would always get on my nerves is having to run git push github staging then have to wait for the push to finish before writing git push staging staging:master then have to wait for that to finish before writing something else. Well it turns out that you can write multiple terminal commands on the same line separating them with a semicolon and they will queue up and execute automatically one after another. So lets say I'm working on a branch called 'jdldev' and I'm ready to push my changes onto staging. On one line I can run git checkout staging ; git merge jdldev ; git push origin staging ; git push staging staging:master Now I don't need to wait around for one task to finish, they'll all execute one after another, and I wont need to be by my computer while my code compiles. This enables me to maximize my period of justifiable slacking that comes with compiling code. http://xkcd.com/303/

9. Stash and apply changes to avoid commiting to the wrong branch

How many times does this happen? You push to production, everything looks good, and you get back to work and start making changes. BUT WAIT, I forgot to switch off of the production branch, and now I've tarnished the one thing that is always supposed to be deployable. Let me try to checkout back onto jdldev with git checkout jdldev, and I'll see that it WON'T LET ME because I have uncommited changes... But I don't want to commit these changes to production, so for a while my solution was to just run around and freak out whenever this happened. Turns out there's actually a better way to deal with this. You can run git stash to take all uncommitted changes and put them into a stash. This cleans your branch and allows you to checkout onto another branch. So I can git checkout jdldev and I'm finally back onto my dev branch. Now I just need to get the changes that I've already made by running git stash apply and the changes will be taken out of the stash and applied to your new branch. BINGO back onto jdldev with the changes I already made and production is unscathed, really useful trick.

10. Use the unique SHA's that comes with each commit

Every time that you make a commit, git will automatically generate a SHA fingerprint that identifies that specific commit. This SHA is the best way to refer to any commit when you need to reference it for whatever reason. Both Heroku and Github will use these SHA's to reference commits, so it's a really good way to make sure that everything is in sync and sure up any problems between remotes. Lets say there was a bug with some production code that another developer shipped and he was forced to rollback Heroku with heroku rollback, a command that quickly reverts to the prior release of your heroku application. Now you come along to debug the error, but you're not even sure which version of the code is currently running on the production site because the master branch is a few commits ahead of what is live on the website. Well if you run heroku releases it will show you a SHA of the commit that is associated with the current release. You can use this information to quickly identify which commit it is associated with. Now you can git difftool UNIQUE_SHA to quickly bring up that specific commit and start looking through the code. You can even go to Github and click on the commit with that SHA in order to see which files were altered when the commit was made.

11. git diff doesn't have to suck

Quick, what is the worst part of being a developer? The number one and two answers are probably Stack Overflow and Merge Conflicts in some order. (git itself probably wins a place in the top 5 actually). But what if I told you that solving merge conflicts doesn't necessarily have to suck. Running git diff BRANCH will show you what is currently different between your current branch and the branch you referenced ( you can do this with remote branches too ) but it shows you the difference in some weird syntax inside of your terminal that is pretty confusing to deal with. How I wished there was a better way to visualize the diff between files. Only recently I was turned on to the concept of a git difftool, a program that can provide visual representations of your git diffs and merge conflicts. The app that I have been using thus far is called Kaleidoscope http://www.kaleidoscopeapp.com/, and you can set it up to be the default diff viewer. So running git difftool UNIQUE_SHA will open up the diffs in Kaleidoscope and not your terminal. You can get more info on the app on it's website, but here's a snapshot of what it looks like.

12. You can undo changes with git reset --hard

The basic idea behind using modules in Ruby is pretty straightforward. You are abstracting out functionality that you want to reuse across your application, in order not to repeat yourself by defining the same methods over and over again. Modules can be looked at as "features" that you either can either add or choose not to add to specific classes. Let me demonstrate this with a quick example.

I am making some sort of app where there are different weapons present. Some of these weapons are going to share functionality ( such as the ability to explode ). So I create a new module called Explosive where all the explosive attributes and abilities will be defined. Then for any weapon that I want to have access to these methods I can simply include Explosive in the class definition. Now I can call explode() on any instance of a Landmine or a Grenade and they will puts "BOOM". If I try to call explode() on an object whose class does not include Explosive, such as Sword, it will raise a NoMethodError because the Explosive "features" were never loaded into the class.

While that is a bit of a contrived example, it shows how you can easily abstract common behavior out into a separate module and include it wherever you need to in your application. In addition to providing an extra feature set for classes, ruby modules can also be really useful for namespacing out methods so you don't get them confused as your application scales.

Let me use a different example now. In this case I am using a Rails application that helps me do the backend accounting for my business. This view shows me my profit ( or loss ) every month. In this case, these are just randomly generated numbers.

The problem is that these numbers are not very nice to look at. I would like for them to have commas, and for the negative numbers to be surrounded by parentheses, in concordance with traditional accounting conventions.

Rails comes pre-loaded with a module of incredibly helpful presentation methods called ActiveSupport. ActiveSupport is where such beauties like number_to_currency and time_ago_in_words come from. In fact, ActiveSupport has a method to add commas into numbers called number_with_delimiter, but it doesn't come with any methods to put negative numbers in parenthesis, so I'm going to create a module of my own to present numbers in accounting format.

I know that the accounting presentation functionality will be applicable across my entire applciation so I don't want to confine it to a single class. Instead I'm going to create a file called Accounting.rb and place it in my lib directory. Rails doesn't load the lib directory by default so in order to get the module to load into the application, I need to add this line of code to the Application.rb file

Now for the actual methods. I create a module called Accounting and I define a method called format. Because the word format is a bit of a generic word, and could possibly cause problems down the road, I want to namespace it and call it from the context of Accounting. I can easily achieve this by making format into a class method from the module Accounting by defining it as self.format. I write out the format method to properly add commas into numbers, and to return all negative numbers without the negative sign and surrounded by parenthesis.

Now when I call this method in my view I can call the namespaced method Accounting.format like so. 

And this will give me the result I desire.

I can call Accounting.format on any number now across my entire application, and as I add more accounting methods to my app, I have a module to place them all into so I can stay in line with the Single Responsibility Principle and have every class doing one thing and one thing only.

I was introduced to the concept of a recursive method a couple weeks ago when beginning to create a minimax algorithm for a computer tic-tac-toe player. It's a little intimidating at first, but I'm starting to get the hang of it.

A recursive method is a method that calls itself from within its own method definition. Much like a loop, it needs to have a way to break out of itself, as well as some sort of incrementor to prevent infinite looping. The break is referred to as a "base case" and will return out of the method if evaluated to true.

A cool example to visualize recursion is creating a simple countdown script in Ruby. I'm going to define a method countdown that takes a parameter (n), representing the number of seconds to countdown from. The first thing to do is define the base case, so I will return out of the method if n == 0. Then I puts n, tell the program to delay for one second by calling sleep(1), then tell the method to call itself, but to pass in the value of n-1. There is nothing wrong with calling the method from within itself, because it will always test against the base case, and eventually return out of the method.

I am just starting to get comfortable using blocks as parameters in Ruby, and am playing around now with trying to find some practical use cases for how I might utilize the yield functionality.

In Ruby, any method can receive a block of code as a parameter. If you call yield from within the method, it will halt the execution of the method, execute the block of code called with the method, then continue on with the method's execution. You have to be careful though, because calling yield from within a method means that a block MUST be passed into the method call or an exception will be raised.

I managed to find a cool use case for this functionality to highlight terminal output if you want to emphasize it for some reason. You just define a method called important_output that puts a noticeable string sandwiching a call to yield.

Then if you ever want to output a value that is easily noticeable in your server log you simply preface it with important_output. 

The challenge: Given an integer, return the Roman Numeral representation of the string.

The tools: Ruby, Test Driven Development, Vim

***

Code katas are a great way to practice with tools and methodologies that you are uncomfortable using for an actual project, but want to try and get better with ( in my case both TDD and Vim ). When I performed this code kata I went through it in traditional kata fashion of one test at a time, but here I am going to take a more abbreviated journey, recreate my thought process, and explain how I arrived at my solution to the kata.

***

First, my directory set up for the kata.

When I actually performed the kata, I wrote each test one by one in its own separate "it" block, but a much easier way to set up these tests is to put each Arabic numeral / Roman numeral in an array pair and simply iterate over the entire array writing a test each time. Much cleaner.

The test instantiates an object of class Numeral and tests that the method roman_numeral_convert successfully converts it to it's proper roman numeral representation. Keeping test files DRY, readable and maintainable is equally as important as keeping your code itself that way.

Naturally this test will fail for an Uninitialized Constant "Numeral", so lets define the class and get the first test to pass.

I define the class Numeral the method roman_numeral_convert and initialize an object with a value of the Arabic numeral. Right now the method just returns "I" so it only passes the first test. Lets make 2 pass.

To pass 2, I decided to multiply the string "I" by the value of the Arabic numeral. This also passes 3. Simple enough, but 4 is where the challenge begins. I immediately recognized that I needed some way to easily reference the Roman Numeral denominations so I could refer to them at a whim and compare the digit against it, so I decided to make a constant called NUMERALS referencing the Roman values. This way, I could at least return the Roman Numeral instantly if it perfectly matched up with the Arabic input. 

This passed 5, but still left 4 failing. My first thought was to slowly build up a string and either prepend or append a digit onto that string depending on whether or not the "I" should precede or come after the "V". The problem with this was that I could feel myself making two separate tracks, and writing essentially the same code for both tracks, with only minor differences. It felt bloated and hackish to me so I scrapped the idea.

After a couple of more failed ideas ( such as adding 'ones', 'tens', 'hundreds', 'thousands' as attributes to the class to work with ), I decided that it would be very beneficial to be able to find the lowest roman numeral in relation to the current Arabic number; then I could start building up the string from there. So I needed to write a method to find the next_lower_key in my NUMERAL constant. I managed to get it to work by inserting the arabic number into the constant, then sorting the constant, finding the index of the arabic number, and returning the index-1 which would be the next_lower_key that I was looking for.

I really liked this method because I was able to utilize a refactoring pattern that I had learned that very same day. The pattern says that whenever you set a variable equal to an array, then iterate over a collection using the shovel operator to << a value into the array, you can refactor the code using Enumerable#collect on the collection. They both accomplish the same thing, but this is a great way to get four lines of code into one. Check out how much better the second line is than the first one.

With this newfound access to the lower_key, I was able to draw up the roman_numeral_convert method the way I wanted it to work. I was going to progressively build up the roman numeral string. First, by setting a variable equal to an empty string. Then, by running a loop that runs while the value is greater than 0. The loop checks if the value exists in the NUMERAL constant; if so, it will return the current value of the string. If not it will find the lower_key, add that value to the string, then subtract the lower_key from the value and run the next iteration of the loop. The final method looked like this. 

This looked really good to me, but I knew that I had still not addressed the issue of my good friend 4. And in fact there were still a bunch of tests that were failing.

This was a great time to look for a pattern. What did all the failing tests have in common? Turns out ( with a little help from Corey Haines ), that I realized all of my failing tests started with either a 4 or a 9. Because these were the only edge cases that were causing me issues, I was able to comfortably solve the kata by simply adding each 4/9 character to the NUMERAL constant, and have my lower_key method naturally pick them up. My final solution is below.

It has been a little over five months since I moved out to Chicago on a whim, with no plan other than to learn how to code. Looking back, It turns out that not having a real plan was only a minor issue. I realize now that when I moved here I had something even more valuable than a plan, I had an insight. My life had lead me to the insight that coding websites was the greatest thing that I had ever done, and I could see that there was a revolution brewing. There would soon be a mass realization that knowing how the internet works is the single most valuable skill that someone can have right now, and with rising tuition costs, and a poor job market, more and more people would turn towards coding and web development. This mass demand for coding knowledge would burst the bubble that isolates the traditional view of a ' programmer ' and a coding revolution would come that took previously ' nerdy ' computer stuff and made it mainstream. I didn't have a place to live, a source of income, any job prospects, but I knew that if I could get out ahead of the tidal wave and sit at the forefront of this revolution that things would work out for me.

I compare the journey ( of learning how to code ) to hiking up a large mountain, everything that you learn, every method that you write, is another step up the mountain. The trail that you're walking on often seems completely straight, and you're not sure if any individual step is actually getting you closer to the top. But the trail isn't straight, it's inclined, ever so slightly. And if you keep walking on this slight incline, eventually you'll reach a clearing where you can see off the edge of the mountain. If you walk over to the edge and take a look down you'll be astounded at how high up you actually are.

I've spent the last five months of my life in a previously untapped gear. Every day, I have been trying to make myself better, learn something new, get closer to the goal of being an amazing web developer, all the while not knowing if I was even learning the right things or actually making any progress. But I've kept at it, and just recently, I finally managed to arrive at one of these clearings. The view is incredible.

A few things have happened that I never would have expected when I began this journey. First, I have already been paid to write code. I had always figured that it would take years and a CS degree to be able to create solutions to real world programming problems, but after only five months I can already add value to real-world Rails applications. ( In the four years that I had been at college why had nobody, once, ever mentioned to me that this was possible? ). I managed to find a teammate to code with that I work really well with. I had always just assumed that I would go into business alone, or be relegated to sitting alone at a desk and coding, but I've discovered that pair programming is incredible, you arrive at better code, and it's better for your health. My partner, Greg, and I have managed to form a pretty great team and are doing some really good work together. I was also offered an apprenticeship at 8th Light ( a software development shop in Chicago ), which I immediately accepted. And I went home to New York over Thanksgiving break genuinely excited about my life.

After a slight break from coding over Thanksgiving, working the past few days to tie up some loose ends on previous projects, and enjoying the view from the clearing for a little bit, it's time to start hiking again. I'm beginning my apprenticeship at 8th Light with an open mind, and the hope that I'm going to learn about the art of software craftsmanship. I'm hoping that the work I do here, and the people I'm surrounded with, can help take me to that next level of not only writing code that works, but writing high quality, scalable, and maintainable code. I can already see that coding is not only about finding solutions, it's about using certain methodologies ( i.e. test driven development ) to arrive at high quality solutions. 

The first thing that my mentor, Kevin, asked of me was to recreate my Tic-Tac-Toe game without using Rails. It took me a while to get acclimated to losing the powers of Rails and trying to recreate my thought process in pure Ruby. It was really the first time that I realized how dependent I had become on Rails' magic that I felt kind of paralyzed without it for a little bit. A tic-tac-toe board has many squares and I want to call board.squares to get an array of all the squares. A simple one to many association, piece. of. cake. … but wait. I can't just throw up my belongs_to and has_many associations because I'm not using a database, and now all of the sudden I'm aware that I have no actual idea how to relate classes to each other without using a database and ActiveRecord syntax. Time to google. And I've found myself doing a lot of that over the past couple days.

I also learned about the “ SOLID “ principles of software development. The “ S “ in SOLID stands for “ Single Responsibility Principle “ and is a very valuable mantra that encourages you to segregate your code so that each class, and each method, only has one responsibility. If you have a 200 line class doing too many things, you should think about abstracting its responsibilities into more semantically named classes. This will help make your code cleaner, scalable, and more maintainable. I realized that my Board class was doing too much work ( i.e. checking if the game was over ) when really that is not that job of a board, that's the job of a game. So I created a Game class to handle all game related activities, and began my refactoring process. After my initial refactoring was done I had taken my largest class from 176 lines ( Board ) to 76 lines ( Computer ) and the whole thing was a lot more readable. SRP is such a simple and powerful concept that I think it will naturally stick with me through all the code I write going forward, and it's cool that I got to witness it's benefit already with an immediate 57% reduction in my largest class size.

I'm also going to begin blogging regularly again. This is a requirement of my apprenticeship, and it's something that I'm glad to be starting up again. Already, in my first two months of freelancing, I have seen how important effective communication is. I believe that writing is a skill that improves significantly with practice, so I'm glad to be taking this up regularly again. I'm setting a hard goal for myself of two blog posts per week, with at least one being directly related to explaining code. I know there's no lack of content, and I'm hoping that I will be inspired enough from my experiences at 8th Light that I can consistently write quality posts. I think that people tend to underestimate the importance of consistency when it comes to creating content online so I'm really going to try to hit that 2 post a week goal every week with no exceptions.