Top Most Used Git Commands

Thought process using Git

Starting a new branch and push
1) git checkout -b ‘my-new-branch’
     – new branch because new feature (think of this as putting things in silos)
2) git diff
     – Once I’m done, I look at the diff to look for obvious human / logic errors
3) git add -A
    – stage all changes
4) git commit
    – Write a useful commit message so others know what this commit is about
5) git pull rebase –origin master
     – Rebase to get your changes to the very top. (You’re change can be buried deep down if the company follows continuous deployments and your branch is old. Also this will catch merge conflicts
6) git log
    – Look at the log
7) git push “remote-v” my-new-branch
    – push to your branch. Then you’ll have to merge from Github

Testing a PR locally. 
1) git remote add john ‘ssh clone url’
2) git pull john pr-branch
3) git pull –rebase origin master
 4a) IF merge conflict. Tell commiter about conflict and ask them to fix
 4b) IF rebase goes smoothly. Continue to step 5
5) git checkout master
6) git merge –no-ff pr-branch
7)Add message saying “sign-off: John”

List of Git commands I use as a developer.

git add -A
Stage all un-staged changes

git commit 
Commit all staged files. This will open a editor for you to write a message in
git commit -m  ‘Add new commit message’
Commit all staged files. Add commit message directly on the same line

git remote -v
Display all remote connections
git remote add origin “SSH clone URL”
Add a remote endpoint
git remote remote origin “what”
Remove remote endpoint

git log
displays commit message and history
git log -G /regex/ (Tom C.)
display commit with specified regex
git log -S /search string/ (Tom C.)
display commit with specified string
git log –stat –max-count=10
see last 10 logs

git log –all — path_of_file (Thomas O.)
Displays all commits made to the specific file

E.G –  git log –all — app/views/blogs/index.html.erb
git log –diff-filter=D –summary | grep delete | grep somezing (Thomas O.)
Filter your logs by using grep

git pull –rebase origin master
My top 5 used git command. In a continuous development environment, you’re branch can become outdated easily. This pull’s in the master branch underneath your current branch. Your commit will be on top.

git diff 
Display changes made on the current branch

git status
List modified files
List committed files and uncommitted files

git stash
All changes will be stashed away to it’s pre-change state
git stash –keep-index
All changes that hasn’t been committed will be stashed away.
git stash drop
All stashed changes will be removed
git stash apply
All stashed changes are restored

git whatchanged -p –abbrev-commit –pretty=medium
Combination of git log and git diff. It will show the diff for each commit

git commit -m ‘wip’
wip = work in progress. I use it to mark commits that I’m still actively make changes to. I don’t actually push this to production. I would either rename the commit once it’s done or I’ll rebase.

git rebase –soft HEAD~1
Two things with rebasing. Either squash commits (squish multiple commits to a single commit) or Edit commits messages

git rebase –i ‘sha’
Allows you to squash, edit commit messages but you can specify the ‘sha’

git rebase –abort

When I mess up my rebase (merge conflicts or what have you). This comes in handy to put me back in the original step before rebasing.
git revert ‘sha’
Return branch to the state where sha (commit)
git reflog 
See all steps committed. I personally don’t use this often. Only in crucial times when I’m messing up in git will I have to use this. 

git merge –no-ff pr-576 (Chris A.)
adds the merging commit so others can see thats the following 3 commits are part of 1 commit. I like to `sign off: john moon` so others can see that I added/merged the list of commits.

git reset –hard origin/master (Chris A.)
Resets back to Master. This one’s nice. Creating spikes often leaves a mess of a code on your branch. This helps you go back to zero. 
ssh-add ~/.ssh/id_rsa_private
Permission denied (publickey).
fatal: Could not read from remote repository.

Please make sure you have the correct access rights
and the repository exists.

I manage multiple accounts. 1 for work and 1 for personal use. I defaulted my .ssh to my work github. This led to problems with my personal account not having access to push or pull. I had to figure out how to give my personal account permission. I added an account id_rsa_private for my private use. Then every time I encounter that error message, I run this command and everything is groovy. 

ssh-add -K ~/.ssh/id_rsa_private (Chris A.)
Adds key permanently 

Happy Git 


Track Your Great Ideas By Writing It Down

I challenge you to write down your ideas.

There are inspiration for great ideas in all aspects of our lives. The light bulb can turn on at any moment. This means it could happen on our way to work, talking with co-worker, or even during a heated argument. The biggest hurdle for many of us is our memory.

When the “ah ha” moment comes, we sadly forget it through out our busy days. The idea is lost. This sucks. I personally hate the feeling of not remembering that good idea, and I always regret not writing it down.
I want to challenge you to start writing down your ideas. It could on a notebook, memo, excel sheet, Evernote, or anything that you’re comfortable with. I’m not saying you have to take out a pen and paper in the middle of an argument and write it down. As long jot down your idea while it’s fresh in your mind.
The benefit of jotting it down is that you can now afford to forget it for a day, month, or a year. You can always go back to your list and read what you thought of 183 days ago. This provides an abundance of ideas, you believe have potential, when you are ready to start your business. 
I’ll share my list next month and see how many I have come up with.
Good luck!

I want to give credit to www.theartofthedeal.net  for the image


Don’t Make Me Think, When I Consume Your API

I recently worked on the voucher badge feature.  I needed to create an api endpoint to consume the voucher count, because we use services.

Unused Voucher Badge
The first iteration, the api passed voucher objects. However, I decided to refactor and pass the voucher count and less data between services, in hopes to shave couple milliseconds off load time. My first refactor looked like the following. Looking at the code, I know exactly what is happening and what data is being passed. It’s simple. 
unused voucher count as integer
Now imagine you’re consuming this new endpoint for the first time, with no knowledge of the implementation. You receive the following json object.  You might think, “Seven? what the hell does seven mean?” Then you’ll inevitably follow the source to VoucherController in order to understand.   

Instead, why not be explicit? Make it clear to everyone who consumes your lovely api what their getting back.

unused voucher count as a hash

That is so much better! Now I don’t have to visit the Api and look at the source code in order to understand what the object is.

So why not make others happy by telling them what their consuming, instead of making them think. Make your api intention explicit!

Lets take this one step further and change our controller name as well. To be clear the vouchers controller only had one job of grabbing all unused voucher and returning the count. If it was part of a larger vouchers controller, I would have refactor it out instead .

Not only are we explicit with the object that is being returned, but the API name. I think this gives a better explanation of the api.

This post was based on a lightning talk I planned on giving at RubyConf 2014. However, the talks were cut short so I decided to make a blog post about it instead.


Using Ruby memoization

In a service oriented architecture we make many requests to external services. These requests time adds up and slows down the site. To improve our performance I can use the memoization technique to make our pages faster.

memoization is an optimization technique used primarily to speed up computer programs by storing the results of expensive function calls and returning the cached result when the same inputs occur again.

When I program I memoize by setting an instance variable to a request.

  1. @foo || = bar.new(params)

This makes a request once, then sets the value to @foo. This persists as long as the instance of the class.

Recently I faced a problem where a method was being called twice. We’ll call it external_request? method. I pass in foo and bar, then check to see if it returns true. The issue was the method was being called twice. The first call returned true, but the second call would return false.

  1. def external_request?(foo, bar)
  2.     @foo = foo
  3.     @bar = bar
  4.     @foo && @bar
  5. end

 Because I care about the first call I knew I could solve this by memoizing the values.

  1. def external_request?(foo, bar)
  2.     @foo ||= foo
  3.     @bar ||= bar
  4.     @foo && @bar
  5. end

This returned true even after the second call, because I saved the value into the instance variable.  Now something to keep in mind. When you are using this technique you want to be careful not to memoize a class variable.

The danger is that this class variable is shared between all users who are on the same instance(unicorn, dyno, etc). Can you see the problem there? If user A makes a request and returns true, then every time the method is called this will return true even if it should be false for other users. This will persist until the unicorn is switched or we refresh the server.

How did I solve the above problem? By making a new method that calls external_request? and sets a cookie during the first method call.

  1. def make_request
  2.   if self.external_request?(foo, bar)
  3.     cookie[:external_request] = 1
  4.   else
  5.     true
  6.   end
  7. end
  8. def self.external_request?(foo, bar)
  9.   foo && bar
  10. end

The lesson is that memoization is great for performance, but we need to be careful what we memoize. In almost every case you don’t want to memoize the class.

This post was inspired by Jon Phillips.


Refactoring And Building The Next Big Thing

Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior

Refactoring is important and necessary, but many times it gets pushed to the backlog. I want to make three point with this post. Why refactoring isn’t taken seriously. When to refactor. And changing refactoring habits. 

As developers, we are paid to build features and fix bugs to increase value for customers. From the project managers point of view, refactoring does neither one of them. So we can say that refactoring is for the developer. This realization gives us insights to why the time allocated to refactor, is so minimally. The PM’s would rather see new feature and bug fixed instead. Code doesn’t get refactored. We keep digging the hole deeper and deeper.

So when should we refactor? If we’re constantly swamped with tickets from our PM we’ll never have time to refactor. The solution? If we’re not given adequate time, we need to refactor in small batches. Tickets should be completed along side small incremental refactoring. This helps us release features reasonably and fix parts of the code. These little batches are now easier to work with and speeds up development time. These refactoring should be within the files we are currently working in. We shouldn’t go out of scope. This will keep us grounded to meet our deadlines.

These are some habits I have learned throughout out the months (1 year in November; Yay!). First following the TDD way (red, green, refactor). As a professional this didn’t fit our team’s agile approach. We refactor but test doesn’t drive our design. Next refactoring in chunks. Asking for time to refactor and going through our codebase to clean up dead code and smelly implementations. To be honest, this doesn’t happen to often. There is little time. So we end up having a larger than necessary codebase with dirty implementations.

I recently began refactoring while creating features and it’s been going great. I’m still not satisfied with the codebase, but I see little win’s over the map. This makes me happy as a developer. 

Credits goes to Ronald Jeffries, 3 founders of the Extreme Programming (XP), for inspiring me to think of refactoring in a different light. His original blog post can be found here: http://xprogramming.com/articles/refactoring-not-on-the-backlog/


Learning How Startups Leverage Technology (DC Tech Meetup #30)

I attended the DC Tech Meetup #30 where I got the opportunity to listen and watch many different startups pitch and demos. The coolest thing for me was to see how these startups were leveraging technology to bring value to this world. I’ll go through each startup and explain what they do and share my thoughts about them.

Demo 1: Aspire (Neil Shah & William Huster)  – I missed this presentation

Demo 2: ID.me New Product Launch! (Blake Hall)

Idea – Verify people’s identity (teacher, military, student, etc) virtually.
Tech – Seems like a difficult problem to solve. Need multiple layers of clearance from the companies side and other agencies. Depending who is requesting information about the individual, they unlock multi-layer security. If it’s a higher security, then the software needs to receive a higher clearance more data to verify the user.

Overall(1-5): This idea is a note worthy 5. The team has proven that a pain point exist by reaching out to *retailers and other agencies that require identification clearance. They have built relationships with multiple different industry to leverage their technology.

*Retailers currently don’t give out discounts online, due to higher fraudulent claims. This is solved by Id.Me

Demo 4: Framebridge (Julia Lovett – julia@framebridge.com) 

Idea – Create custom frames that you’ll love

Tech – Mobile App that allows users to pick out a custom picture frame (with various sizes, colors, and patterns) with a feature to test out how it would look on your wall. Not complicated program. Straight forward main platform an section to choose in-stock frames.

Overall(1-5): Not the next million dollar idea, but definitely have potential. It’s a solid 2. It’s working in a highly niche market so it’s easier to target, but I don’t see how they can grow beyond the niche market. 

Demo 5: Vouched (Keith Cooperman)

Idea – LinkedIn like feature where users rate each other’s characteristics to see if they would be a good fit for a company.
Tech – A connection to users linkedIn profile, then leverage their contacts to rate others character traits. Manage multiple database table to store each users ratings, their average, and their contacts. Lot of different database involved to organize users feeds, ratings and information employees finds useful.

Overall(1-5): I’m personally very skeptical about this idea, because I don’t see any added value. It’s going to be hard to convince people that they need to rate their “friends” or “sort of friends” personality. First off why would I waste my time doing this (when I don’t even recommend skills sets of others). Second what is the different between endorsement in LinkedIn and this product?

Demo 6: Openreporter (Misha Vinokur – misha@openreporter.org)

Idea – Allow regular joe’s to report any noteworthy news to certified reporters.
Tech – Two different home page for regular joe’s and reporters. Regular joe’s needs to be able to post the situation. Both users need to communicate via comments on reports the regular joe’s make. Each report is pinned on a google map.

Overall(1-5): Overall it’s a solid 2. It’s an interesting idea, and innovative. However, I’m not sure how many reporters would want to quote a random guy who claiming “Dude I just saw t-rex riding on a elephant with a cow boy hat. It was awesome!” It’ll be bad journalism if they simply believed what people are saying. I want (video) proof. Second I guess they’ll charge reporters for this service or ads? Don’t see reporters actually paying initially (chicken and egg problem).   

Demo 7: AgSquared (Jeff Gordon)

Idea – Organize data about individual farmers crop type, yield, harvest, etc to analyze farmers data over the years to help them make informed decisions in future harvest/investments. There are sensors in place within the farm that collects data as well.
Tech – Probably the second hardest to implement after Id.Me. They use tracking within the farm and display the data through a graph on the farmers dashboard. The software analyzes the data (in ways the founder didn’t go into) for farmers to use.

Overall(1-5): I give them a 3 for two main reasons. The idea is relatively innovative and very useful for farmers in the long run. The negative is it’s very time consuming for farmers to actually input all the necessary data to make this useful. This takes time to learn to use the technology and take time out of actually labor.


How To Have Effectively Code Reviews

Code reviews can be a daunting challenge for developers. It’s hard to know what to look for in a given pull request (PR). I want to share some tips that I have learned from other LivingSocial engineers.

Questions you should be asking about the PR

  1. Do you understand what the PR does?
    • Does it have a clear commit message?
  2. Do you understand how the code accomplishes the goal?
  3. Is the new code tested? 
    • If it’s a big new feature, is it covering edge cases?
  4. Does the code use obscure syntax, how could it be more clear or less obscure? 

Must Do

  1. Does the entire test suite code pass?
    • Run the full test suite, and not only the one controller that changes
  2. Pull down and rebase so that your newest commit is on top
    • This way if you need to rollback your commit, you don’t have to shift through multiple commits to get to yours
  3. Worst case scenario back up plan
    • If all goes to shits, what are the steps the merger should take to undo this shenanigans
  4. Don’t dilly dally when you see a PR. Be as responsive as you can in order to have an effective feedback loop. 

This is a good start for effective code reviews and merging pull requests. These steps have helped us find bugs, code smells, and fast cycles for a better engineering experience. 

If your team has other methods for effective code reviews, please share down below.