Skip to content

Instantly share code, notes, and snippets.

Senthil Arivudainambi sent-hil

View GitHub Profile
sent-hil / pictures.markdown
Created Aug 24, 2012
River ( Keep a programming journal.
View pictures.markdown

One of my favorite past times is to look at the notebooks of famous scientists. Da Vinci's notebook is well known, but there plenty others. Worshipping Da Vinci like no other, I bought a Think/Create/Record journal, used it mostly to keep jot down random thoughts and take notes. This was great in the beginning, but the conformity of lines drove me nuts. Only moleskines made blank notebooks, so I had to buy one.

At the same time I started a freelance project. The project itself is irrelevant, but suffice to say it was very complex and spanned several months. It seemed like a perfect opportunity to use the moleskine. Looking back, all my entries fell under few categories:

  • Todo
  • Question
  • Thought
  • Bug
  • Feature
View gist:47a10baeebc6ecc5d4ef7919b77db026
The following below are what *I* think are best principles (after going through the last dozen mostly commented PRs):
1. Principle of least astonishment: does every single line follow principle of least astonishment?
This means if you, as a "reasonable" Rails programmer would be confused about this change, then this code either needs to be refactored or documented properly (there are situations that require us to break best practices, but these situations are very, very rare).
2. Readability: can I understand everything in PR (title, description, comments, code and tests) without having to ask the PR author to explain to me what it means?
And if there are edge case, are they documented properly?
3. Are edge cases, user input errors accounted for?
If the code relies on user input, what happens if the user is trying to sabotage? ie
sent-hil / suitesync_wipe_metadata_fields.rb
Created Jul 3, 2017 — forked from iloveitaly/suitesync_wipe_metadata_fields.rb
Wipe all metadata fields from Stripe used by when a sandbox refresh is performed
View suitesync_wipe_metadata_fields.rb
# Mike Bianco <>
# Description: Wipe all metadata fields from Stripe used by SuiteSync.
# Helpful after a sandbox refresh.
# Usage:
# export STRIPE_KEY=sk_test_
# ruby suitesync_wipe_metadata_fields.rb
require 'stripe'

Keybase proof

I hereby claim:

  • I am sent-hil on github.
  • I am senthil196 ( on keybase.
  • I have a public key ASCi9RUVVKDkkW-LPPaJ_N6h6jccWFLmO5DaoSyUVc4sJAo

To claim this, I am signing this object:

sent-hil / go_vroom
Last active Dec 21, 2015
First vim plugin
View go_vroom
" Vim plugin for running the current test under cursor. I wrote it on a friday night
" when I was bored and sort of curious about vim plugin development. Needless to say
" I don't want to write any more vim plugins.
if exists("g:loaded_go_vroom")
if &compatible
echohl ErrorMsg
sent-hil / gist:6259773
Created Aug 18, 2013
Run go test under cursor
View gist:6259773
function RunGoTestUnderLine()
let line_text = getline(".")
let raw_test_name = matchstr(getline("."), "Test.*\(")
if raw_test_name != -1
let test_name = substitute(raw_test_name, "\(", "", "")
exec '!go test -run ' . test_name
autocmd FileType go nnoremap <leader>s :call RunGoTestUnderLine()<cr>
View go_style.txt
1. Comments prefixed with // & space.
// right
2. No blank lines between for & next line.
for _, name := range notAllowedSuffixes {
if strings.HasSuffix(sourceName, name) || strings.HasSuffix(targetName, name) {
sent-hil / rvm
Last active Dec 17, 2015
Fish shell config
View rvm
function fish_prompt --description 'Write out the prompt'
# Just calculate these once, to save a few cycles when displaying the prompt
if not set -q __fish_prompt_hostname
# set -g __fish_prompt_hostname (hostname|cut -d . -f 1)
if not set -q __fish_prompt_normal
set -g __fish_prompt_normal (set_color normal)
sent-hil / gist:4641437
Last active Dec 11, 2015
zsh function to show specs to code ratio in a rails folder, anything over 0.75 is good.
View gist:4641437
prompt_rspec_stats() {
if [[ ((-d app || -d lib) && -d spec) ]]; then
if [[ (-d app) ]]; then
local app=`wc -l app/**/*.rb | grep -oE "[0-9]+" | tail -n 1`
local app=`wc -l lib/**/*.rb | grep -oE "[0-9]+" | tail -n 1`
local spec=$((`wc -l spec/**/*.rb | grep -oE "[0-9]+" | tail -n 1`))+0.01
local ratio=`printf "%.2f\n" $((spec/app))`
sent-hil /
Last active Dec 11, 2015
A list of lessons learned from refactoring my open_auth2 library to make it a better OOP citizen.

Recently I've been learning a lot about OOP, especially how to structure code to make it easier to change in the future. The following are some of the ways I refactored my open_auth2 library.

Don't optimize prematurely

I did the mistake of assuming what sugars were required, only to realize I never used them. Source.

Inject dependencies

The Token object accesses Config object for information. Before it was hard coded into Token, so they're highly coupled, so now I pass it as an argument to #initialize. Better yet it defaults to so it's only optional. Source.

You can’t perform that action at this time.