git branch -m master legacy git branch -m dev master
Set default branch in admin not master.
Delete the remote master branch on GitHub.
git push origin :master
#!/bin/sh | |
# any2pandoc.sh | |
# | |
# A shell script that tries its best to convert documents thrown at it | |
# to pandoc's extended markdown. | |
# | |
# https://gist.github.com/1181510 | |
# | |
# Depends on: |
git branch -m master legacy git branch -m dev master
Set default branch in admin not master.
Delete the remote master branch on GitHub.
git push origin :master
I was at Amazon for about six and a half years, and now I've been at Google for that long. One thing that struck me immediately about the two companies -- an impression that has been reinforced almost daily -- is that Amazon does everything wrong, and Google does everything right. Sure, it's a sweeping generalization, but a surprisingly accurate one. It's pretty crazy. There are probably a hundred or even two hundred different ways you can compare the two companies, and Google is superior in all but three of them, if I recall correctly. I actually did a spreadsheet at one point but Legal wouldn't let me show it to anyone, even though recruiting loved it.
I mean, just to give you a very brief taste: Amazon's recruiting process is fundamentally flawed by having teams hire for themselves, so their hiring bar is incredibly inconsistent across teams, despite various efforts they've made to level it out. And their operations are a mess; they don't real
A good commit message looks like this:
Header line: explaining the commit in one line
Body of commit message is a few lines of text, explaining things
in more detail, possibly giving some background about the issue
being fixed, etc etc.
The body of the commit message can be several paragraphs, and
please do proper word-wrap and keep columns shorter than about
/* | |
* This work is free. You can redistribute it and/or modify it under the | |
* terms of the Do What The Fuck You Want To Public License, Version 2, | |
* as published by Sam Hocevar. See the COPYING file for more details. | |
*/ | |
/* | |
* Easing Functions - inspired from http://gizma.com/easing/ | |
* only considering the t value for the range [0, 1] => [0, 1] | |
*/ | |
EasingFunctions = { |
require "rubygems" | |
require "json" | |
require "net/http" | |
require "uri" | |
uri = URI.parse("http://api.sejmometr.pl/posiedzenia/BZfWZ/projekty") | |
http = Net::HTTP.new(uri.host, uri.port) | |
request = Net::HTTP::Get.new(uri.request_uri) |
It reads your torrents. Spit out magnet URIs.
$ ./magneto.rb magneto.rb.torrent
Results in:
I've been using this technique in most of my Ruby projects lately where Ruby versions are required:
.rbenv-version
containing the target Ruby using a definition name defined in ruby-build (example below). These strings are a proper subset of RVM Ruby string names so far....rvmrc
(with rvm --create --rvmrc "1.9.3@myapp"
) and edit the environment_id=
line to fetch the Ruby version from .rbenv-version
(example below).Today I learned about another Ruby manager, rbfu, where the author is using a similar technique with .rbfu-version
.
I'm a fan of MiniTest::Spec. It strikes a nice balance between the simplicity of TestUnit and the readable syntax of RSpec. When I first switched from RSpec to MiniTest::Spec, one thing I was worried I would miss was the ability to add matchers. (A note in terminology: "matchers" in MiniTest::Spec refer to something completely different than "matchers" in RSpec. I won't get into it, but from now on, let's use the proper term: "expectations").
Let's take a look in the code (I'm specifically referring to the gem, not the standard library that's built into Ruby 1.9):
# minitest/spec.rb
module MiniTest::Expectations
#!/bin/sh | |
git filter-branch --env-filter ' | |
an="$GIT_AUTHOR_NAME" | |
am="$GIT_AUTHOR_EMAIL" | |
cn="$GIT_COMMITTER_NAME" | |
cm="$GIT_COMMITTER_EMAIL" | |
if [ "$GIT_COMMITTER_EMAIL" = "[email protected]" ] |