Thomas Riboulet

what's the minimum size for the USB drive ? would a 8Go work ?

@jlecour : interesting solution too.

what a great post ... a pro tip that serves as an external link

it looks like great content why not writing a proper pro tip ?

yes, so here is a replacement : https://coderwall.com/p/kppokq

what is it doing ?

thanks !

by the way it also works for screen and keyboard luminosity (with the corresponding button).

@summic , @andresroberto10 , @sasasoftware : you're welcome, thanks !

@dbachet tried the Pomodoro technique ?

@NIA readability is often a subjective topic, still, for something like this particular line most ruby style guides would probably point towards the ternary operator ?: (https://github.com/bbatsov/ruby-style-guide#syntax)

Of course the case line is quite close to pure english I suppose and would be read easily by anyone. Regarding this I do appreciate the transparent regex match the case provides.

interesting, but keep it mind that squashing many commits into one can make things a bit heavy if there is a lot of commits / lines.

it's a powerful tool so big responsibility comes with it !

(somehow) related : http://stylemanual.org

considering the efficiency of the git protocol and the cost of private repositories at bitbucket, I'm wondering what use case triggered that ?

there are commands for that : FLUSHALL (all keys in all db), FLUSHDB (all keys in active db)

http://redis.io/commands/flushall
http://redis.io/commands/flushdb

@sheerun you're welcome.

note : if I remember correctly "focus" is an edge case of the tag functionality that was added to rspec 2 : https://www.relishapp.com/rspec/rspec-core/v/2-4/docs/command-line/tag-option

the "trick" is the ":focus => true" part, it comes with Rspec 2.x.

@callmekatootie : yes I agree on this, but a lot of people new to VCMs are trained by people who have experience on other VCMs so they tend to get those bad habits (been there, done that, seen that too).

Alas, forgetting past experience is not just like pressing a button, I wish it was that simple ;)

something someone pointed out on the YC / HN thread : there is a point missing in this post : commits rebase before pushing. I'll try to cover that in another post.
in short : once you got your tests passing and BEFORE publishing that branch you can (and should?) rebase some of the commits together (rebase -i) to get a slimmer history and clearer diff history.

in the end you might want to see it that way :
1. branch
2. write tests
3. write code
4. pass tests
5. commit
6. repeat 2 to 5 until group of bricks is done
7. rebase -i commits that need such attention
8. push to your public repository

the git flow link is a must too, thanks for the feedback, please keep sending more !