My 37k dollar mistake: ilikerobot.com

If you listened to my interview on the Code Newbie podcast I mentioned briefly that I had a slight debacle with my AWS key to the tune of 37k dollars. I feel like I should write a public service announcement about it to help others, so here it is:

Coming close to almost a year, I started my journey November of last year. I began a few tutorials and online resources, but the first complete tutorial that I finished was One Month Rails and it was an awesome experience. In only two weekends I followed the instructions step by step to create the site ilikerobot.com. I was so excited about it I even convinced others to use it.

At that time I did not use github at all and barely knew how to use git, but fast forward to the beginning of January and I had mastered the process of pushing to github, so much that I pushed all my projects to public repositories. Little did I remember the warnings from the OMR videos to not publicly posting any files with sensitive information.

You see the sample application is a Pinterest clone which requires users to sign in and post a picture of a robot. In order to save these upload pictures, you need a tool like AWS's S3 service to store these pictures. AWS provides a secret key and bucket names and 1 year free access to this. After the year you will need to pay, but at the rate I was using it, it might of been pennies.

When I pushed the repo to github I neglected to hide all the sensitive information and did not realize until I received a phone call from Amazon out of the blue letting me know my keys were published on github, this was back in May at the time I was interviewing for jobs, so my focus was not this project I created months ago. I had the key inactivated and I deleted the specific file on github (this is not enough) and moved on with my day. Little did I know that there actual charges made to the account from an attackers that scrapes github for all sensitive information, actual clever and I am sure very easy due to the amount of new programmers.

I only found out about the charge because I have been making an effort to update all my old apps and bring them up to speed with Rails 4 in addition to writing previously non-existent test suites. I lost access to the photos on the site and could not log into my AWS dashboard. After getting my login access back I noticed the large bill and had a phone call with Amazon the next day.

I am very pleased with their understanding and effort they put in to having the charges reverse. They also protected my account even with the root of the problem actually being my ignorance. I would highly recommend them to others looking for simple cloud hosting, I do recommend a few things below.

My recommendations to protect your projects:

I am still all for making code public in repos on github but I recommend everyone learn about `.gitignore`. This is something I learned about after OMR but did not put into practice with my first app. You simply create the file in the root folder of your app and place all private file paths there. Git will know to never save these files and you will be responsible for saving your login info outside the repo in a secure location.

I also recommend the figaro gem for Rails projects on heroku. Their github readme is more than enough to get started using it, but it is also helpful in protecting sensitive information like API keys.

*Update: I also suggest this GoRails video on Environment Variables

Code Newbie Podcast

For those interested, I was on a Podcast call CodeNewbie and shared my story of how I got into web developing in Ruby. The podcast itself is on Itunes or via RSS from the site.

Saron is definitely an amazing host and I am glad I had the opportunity to do this.

Why I am using git flow and you should too

I have learned many things in only 3 months real Rails Engineer(not just on tv) and I have been a slacking a bit on sharing those skills due to the increase workload I continue to take on. I did want to take the time and share on `git flow` and why I am using it on my overhaul of my breakable toy app, Chuych.

While attempting to work on my chuych app in the past 3 months I have notice that my commits are a bit all over the place and I lack the focus to complete anyone thing, for example sticking to one design. This is why I have taken it upon my self to use git flow (What is git?).

 My goal has been to give my personal projects more of a focus lately since they have been ignored. I spent a lot of time trying to get up to speed in Ruby, Javascript, and even learn iOS on the side. I can say I really lost focus on maintaining my own code portfolio. I have however been taking work home and spend a couple hours on the weekend working through refactoring and bug tracking in my work code.

I have slowed down on my learning of new skills and languages and restricting myself to only learning things that will increase my productivity at work and make my chuych app more robust (This will not effect my iOS learning). I have spent the past 2 weekends building out my test suite and it is at a point where I can no just add test when I implement new things.

Git flow  is feature of git where you can speed up your workflow, in the command line, by creating structure in your branches/commits with shortcuts. This feature will create a branch, merge a branch, and close a pull request in 2 commands. It is not uncommon for someone to work on their personal app and commit and push everything on their master branch. There is no shame in this if you do so; I was doing this up until last month. I am now using git flow to create separate branches to organize my thoughts and focus on one feature/fix at a time. This really helped me finish the last of my testing and will hopefully help me build out my design stylesheets.

If you learned rails through any tutorial they team you to commit as soon as you are done with a full feature or full programming thought. They sometimes briefly teach you about branches, but from my recollection, it gets abandoned rather quickly in the tutorial, or at least I abandoned it. It really isn't necessary to be so verbose in your branching your commits, but for apps you would like to keep around for awhile, structure is what will keep your sanity.

My recommendation is to try using `git flow` for one feature of your site, if you are not already using a similar method, it will bring sanity back to your app development just as it has mine.

The Process:

To begin you will need at least 2 branches created in your app. I named one master and the other develop, but feel to use any naming convention.

  Master Branch - This branch is standard, especially using github and coming from tutorials. I believe most Rails developers and even possible back-end git users use this branch name. If you are using heroku or another deploying method, it can be deployed from here.

  Develop Branch - This is the branch where all you code will be merged to first and tested.

It is important to keep master separate in case you merge a breaking changes or something goes wrong, the merge history should be primarily merges from develop unless its a hotfix (to be explained later).

You can also create staging, release, and QA branches but I am keeping it simple for now and suggest the same.

Install:

There are complete git flow installation instructions on the web but I will provide the cliff notes.

Start by type `git flow init` in the command line and proceeding with the steps prompted in your terminal. They will ask what branch your feature will be merged to, my recommendation is to use the defaults on the screen and the develop branch to merge to.

Workflow:

Again there are many workflow examples on the web but I will provide the cliff notes.

In my current we follow the current structure.

1. Create a feature branch `git flow feature start <desired_feature_name>` while on the develop branch. What ever branch you are on will create the new feature branch, so make sure you are on the correct one.
2. Push the branch to git `git push origin <new_feature_branch_name>`  this will create the branch on github, be sure your git remote is set or you will be prompted the first time. 
3. Open pull request, on github you can use create a pull request compared to develop for peer code review. Instructions on creating a pull request.
4. After feature is complete `git flow feature finish <chosen_feature_name>` this will merge your branch to develop and delete your feature branch locally only. 
5. Now the final can be of your choosing, but you eventually need to merge to master and then deploy once tested. At work we would now create a release branch using `git flow release <release_number>` and repeat steps 2-4, replacing the final merge to master instead of develop.

*a hotfix is a pressing bug that will actually be merged to the master branch instead of the develop first. You will create these off master and follow the same steps 2-4.

Why:

So why do it this way? My answer is again to stay focused on feature at a time; it will also help when I actually get my app built out, I can work on multiple feature at a time if I get stuck or choose to work with another developer. I also will start using release cycles once my app hits 1.0 (i.e. has some sort of front end design).

If you are reading this and still learning rails in hopes to get a job doing it, I recommend trying this out, if it doesn't work for you, you can always delete the extra branches continue to push changes directly to master. If you do decide to do this, it would help you in the eventual interview since most companies use this or a similar technique in the development.

If you have questions or if something was unclear, please shoot me an email or leave a comment.

Managing Dependencies with POODR

I recently spent some time preparing a talk on Managing Dependendencie, a topic cover in the POODR book by Sandi Metz.

Programming is great:

I came from  a sales position where the only keeping me there was the paycheck. I am person that enjoys perpetual learning and not that sales can't be a perpetual end to learning it can also be a drain. I now have the ability to now make things that matter and be a part of something rather than just sell the idea of it. I now have the privilege of maintaining an application with a lot of legacy code.

In sales I have learned to observe the situation and I have notice that programmers are notorious for knocking the previous developer. Rather than understand the code they choose to curse the code for its brittleness and unending work to update with change.

Dependencies:

A recurring misstep in the code I see is the problem I see in my work code but as well in other is change is hard to work due to the large amount of dependencies in the code. Dependencies are the messages sent between objects. In the example below, there is a message being received in the initializer and an outgoing message in the :gear_inches method.

*Please note that the attributes are incoming messages, chain-rig, cog, rim, and tire.

Problems:

The problem with dependencies is that there are too many. The idea of creating Practical Object Oriented Design is to have the least amount of dependencies.

Solution:

Writing maintainable code is another goal having a practical design. As a programmer you should be able to revisit your code and easily understand what is going and also easily implement a new change. In the above examples, the Gear is too dependent on knowing about the Wheel and how its made and which order the rim and tire should be placed in the argument.

The suggestion is to instead pass in the wheel as an argument; this free up the ability for the gear to depend less on the Wheel but also allow other parts of the bicycle without getting the way of the Gear and Wheel relationship.

I hope this post has been useful and also hope to share more info on the subject in future post. *Examples came from the book Practical Object Oriented Design in Ruby, I highly recommend this book to all new and experienced Rubyist. 

Editing a commit after the fact

Multiple times I have found myself in need of editing my commit messages due to typos or unclear messages. I have that the use of  `git commit --amend` and `git reset -- hard`.

Having a short and concise commits have been useful for myself, especially I have had to start and my feature stories multiple times during the course of the month.

Another practice in reading code to learn is reading each commit(line by line) to get a good understanding on what the code is doing. Reading commit messages on code that you have no association with could feel as an unneeded experience, but my recommendation is to do so to grasp a better understanding of the code in general.

*update* If the terminal is your default way of using git then you will need to know enough VIM to navigate. I recommend vimtutor or vim adventures. Of course you could always use the github GUI but thats doesn't feel like coding :)

How to Install Rspec

*For some reason I thought I wrote a post on this, but it seems I have not.

Gems are wonderful make it easier to add complicated functionally to your add. A large number of gems can be installed and implemented in only a few steps. Installing Rspec can be completed in a few steps and can be even easier if you install in Rails.

1. gem install 'rspec-rails'

If you are working in a Rails application, it is recommended to include the `rspec-rails` gem because of it close association with Rails generators. If you are not using Rails, then the plain `rspec` gem will suffice. Once the gem has been added to your gem file, it may be implemented using `bundle install`

2. Create spec helpers and config files.
This is even easier,the command need to finish the install is `rails generate rspec:install`. This will create all the need fils for add any additional functionality to your testing suite, including auto testers and stuck/mock libraries.

*Please note if you choose to create an application without rails, you will need to install those file manually. I spent 2 hours in a starbucks once trying to figure that out, but that story will be for another post.

3. Place all test in the `/spec` folder and append the `_spec.rb`. This will ensure that the `rspec` command runs all test.

For more clarification on installing Rspec, please see its Github readme. I also recommend a trying it our, since the best way to learn is by doing. Checkout the the examples from the Rspec book.

Also checkout: Ruby for Newbies: Testing with Rspec

Finally building a complete test suite for chuych

Now with 10 weeks of real work experience I have gained more experience than I could have ever imagined.

I am shocked to find that my first commit to github for my chuych wasa whole 3 months later. My previous goal was to gain enough knowledge after beginning work to keep up with my daily workload and I feel I have just reached that point.

My second goal as of August was to start committing to my personal projects once again. I have succeeded by providing my first commit August 10th.  My hope is now to complete my test suite by Sunday, which will include Features and Models (using Rspec).

I am looking forward to writing a complete test suite to ensure my app is free of most bugs. I will be focusing some future blog post to my current work in testing. Once I complete this task I can move on to improving the front-end design, which has been lacking since it's inception.

TDD? More and more people I come encountered with do not use TDD and it's not a mystery that I do not use this form of testing, but the concepts I have learned from thoughbot's upcase TDD workshop has been more than enough to learn the idea of testing in Rspec. Whether you test before or after, testing is still the same, and I highly recommend learning TDD is you are interested in writing better test.

Testing small has made it easier for me to get the ball running and getting an overall idea of what needs to developed next. I currently have tests for 3/4 of my existing models and plan to move on to Integration/Feature test which will tighten up the functionality of my app. I have found that the geo-searching was very buggy and the rendering of the Javascript was also hit or miss, by testing this will help identify the problem and fix it.

For a tip:
My recommendation is to start with validation testing to help get past the awkward part of testing,  I have an example of that below.

Tomorrow I will write a post on setting up your test environment.