I’m loving today’s Google Doodle for Douglas Adams’ birthday:
He would have been 61 today.
Besides from the fact that saying “bang bang” makes me think of Quentin Tarantino (because of Bang bang → Nancy Sinatra → Kill Bill), which makes it already a hyper-classy command, I love “bang bang” because it’s also one of the most useful commands of all times.
The bang bang command lets you execute the last command you launched from your shell, which is very useful when you need permissions to do something:

Ooooh, you don’t want to create that file? BAM! sudo bang bang!
Here’s another one, for my Ruby-on-Rails friends out there: bundle exec bang bang

Yay!
I love Chuck Norris. And most of all, I love nerdy Chuck Norris Jokes.

A few days ago, one of my colleagues sent me a link about a ChuckNorrisException and got me browsing through the web searching for more Chuck Norris developer jokes. After looking for “chuck norris” on github, I found the Internet Chuck Norris Data Base, which contains hundreds of Chuck Norris jokes separated into categories, and has a RESTful API.
Bingo!
I thought it would be great to have random jokes on my blog. I didn’t find any plugin in the Octopress plugins list, so I started developing one straight away.
Ta-daaah!
You can see it working in this blog on the upper right corner, and you can download it on its github page.
Isn’t it sweet?
Here are some other resources I found. Only Chuck Norris can read these at work without laughing out loud.
Enjoy!
In my first job, part of my work was to code for a big project that had started many years before, and on which many developers had worked before. And you could see it.
At the time, the company didn’t have any global coding practices, so each one did as they pleased. A year before I came into the project, the person in charge decided developers would start using the Google C++ Style Guide, so new files looked alike and had the same feeling, but nobody did a thing for the old codebase.
At one point, I was the only developer working on the project, so I decided to unify the code with some sed-perl-regex love.
The project was on version control, so there were lots of hidden version files with the code files. I didn’t want to modify any non-code file, so I used a little find to work only on a subset of the files. I put everything in a script I named sedincode, taking a regex as a parameter:
1 2 3 4 5 6 |
#!/usr/bin/env bash for file in $(find -name *.cpp -o -name *.h) do sed -r -i $1 $file done |
Then I started correcting some coding practices, such as adding a space after a comma
1 |
$ ~/sedincode "s/\,([^\s])/, \1/g" |
and removing spaces before them
1 |
$ ~/sedincode "s/([^\s])\s+\,/\1,/g" |

One of the things that annoyed me the most in the codebase was having, for roughly half of the functions, opening brackets all alone in a newline, like this:
To correct these, we need to span over two lines, so instead of using sed for my replacements, I went for perl, because it allows to treat the whole file at once by undefining the meaning of the end of a line with the BEGIN{undef $/;} snippet. I replaced sed by perl inside my sedincode script
1 2 3 4 5 |
for file in $(find -name *.cpp -o -name *.h) do # sed -r -i $1 $file perl -i -pe "BEGIN{undef $/;} $1" $file done |
and then I used
1 |
$ ~/sedincode "s/\n\{/ {/g"
|
which simply replaces a newline followed by an opening bracket, by a space and an opening bracket. And yay, it works!
After doing some small replacements using my perl one-liner, I ran cpplint over the codebase to get a more precise feeling about other coding practices that were not put into practice and got… more than one hundred thousand errors.
I decided to ignore some of the errors, and try to correct others using my perl regex weapon. Many of them were about spacing in and around comments. For instance, cpplint doesn’t like it when comment bars are not preceded by at least two spaces, and followed by one space:
1 |
void myFunction() {//cpplint shows two warnings here. |
I thought this was a piece of cake with regexes so I launched several perl replacements to fix the spacing problems around comments and punctuation.
The thing is, when you tell perl to ignore the end of the lines, sometimes it ignores too much of the ends of the lines (a newline can now be matched by many symbols you are not thinking about). I thought my replacements would behave like sed replacements, but instead, one of them transformed files like this:
1 2 3 4 5 |
void myFunction() { // First line of comment // and the next part of the comment cout << "Howdy!" << endl; } |
into this:
1 2 3 |
void myFunction(){ // First line of comment // and the next part of the comment cout << "Howdy!" << endl; } |
and all the Eclipse automatic comments were broken. Oops.
So I instantly switched back to the sed version inside sedincode, and left the perl version in a comment for when I really needed it. I was also very happy of having svn revert that day.
Perl multiline replacement (and regex replacement in general) is a strong weapon, and as such, use it with caution (and with some good version control).
Here are some of the regexes I used to prettify the code base and correct cpplint warnings:
s/\,([^\s])/, \1/g. You can use variations of this for other punctuation signs or operators.s/([a-zA-Z_]+)\s&\s/\1& /g. I added an extra space to match after the & to avoid transforming foo && bar into foo&& bar.
&& did you?s/([^\s])\/\//\1 \/\//g and s/([^\s])\s\/\//\1 \/\//g (for cases with zero and one space before the comment)){ into ) {: s/\)\{/) {/gs/\n\{/ {/g. To be used with the perl version.Today I wanted to change a few things on my last post, but wasn’t on my main computer, so I tried to clone my blog, hosted in Heroku, to make these changes.
I thought hey, I’ll certainly do this again in the future and I don’t want to forget how to do it, so here it is for posterity.
First of all, if you have never used Heroku in the computer you are in, you have to
1 |
gem install heroku |
Then, you have to input your Heroku credentials, and add your computer’s key to your Heroku account :
The computer’s key is usually ~/.ssh/id_rsa.pub. If you don’t have a key, you can generate one using the command
1 |
ssh-keygen |
Finally, to clone your repo, you use
1 |
git clone git@heroku.com:my-awesome-repo.git my-directory |
That’s it!

Well, I am a developer (a that-yellow-is-not-yellowy-enough developer) so the first thing I tried to do with my new blog was to see how code looked like in it. Octopress uses two default themes from Solarized; a dark one and a light one (image to the right).
I tried the dark one on a snippet of Ruby/Rails and I got this:
1 2 3 4 5 6 7 8 9 10 11 12 | |
Ouch! So. Much. Blue.
When I started web development, I worked on Vim using the Twilight color scheme. Then, I switched to TextMate using the Twilight color scheme. Now, I work on Sublime Text 2 using… the Twilight color scheme. I like it so much that I even pimped my Eclipse at work (I write software in C++) for my code to look like the Twilight color scheme. The next natural step was to find a way to have code snippets inside my blog with the same colors I love and use every day.
For those of you that don’t know what Twilight looks like, here’s the same code snippet using its colors:
1 2 3 4 5 6 7 8 9 10 11 12 |
class CookieMonster field :cookies, type: Integer def eat_cookies(number_of_cookies, cookie_flavor) if self.cookies < number_of_cookies raise "You don't have enough cookies!" end puts "You are going to eat #{number_of_cookies} #{cookie_flavor} cookies" self.cookies -= number_of_cookies self.save! end end |
Wow, I feel much better already. Phew!
To install Twilight color scheme in Octopress, I followed what chico explained in this blog post, with a few tweaks.
First of all, you have to install kramdown and CodeRay by adding the following lines to your Gemfile:
Then, change your _config.yml to use kramdown:
1 2 3 4 5 6 |
markdown: kramdown kramdown: use_coderay: true coderay: coderay_line_numbers: table coderay_css: class |
CodeRay accepts different line number styles: table, inline, list or nil. The difference between them is mostly about the background we use for the CodeRay.line-numbers class in our css:
| Nil | Inline / list | Table |
|---|---|---|
![]() |
![]() |
To use our own color scheme, we have to add a file sass/custom/_coderay.scss defining the color scheme and include it by adding the following line to sass/custom/_styles.scss:
1 |
@import "custom/coderay"; |
TextMate’s Twilight css for CodeRay is available thanks to russbrooks in this gist. If you want GitHub’s theme, you can get it right here. What’s great about having your own color scheme with CodeRay is that you can change around a hundred different colors, whereas Solarized only works with eight accent colors (you’ll see later that I changed the .CodeRay .constant color in my custom scss file).
Next, we have to tweak the scss in order to have the right background colors and nice table line numbers. Let’s add background and text colors in the sass/custom/_colors.scss file:
Our custom scss modifications will go in the sass/custom/_styles.scss file. This file is read last, so anything in it will override definitions inside _coderay.scss (or any other scss file).
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 |
.CodeRay {
background-color: $code-bg;
padding: 0px;
pre {
padding: 5px 0px 5px 10px;
}
}
.CodeRay pre, .CodeRay .highlight, .CodeRay .gist-highlight {
background-color: $code-bg;
border: 0px;
color: #F8F8F8;
margin-bottom: 0px;
}
// Nice line numbers
table.CodeRay td {
padding: 0px;
}
.CodeRay .line-numbers, .CodeRay .no {
background-color: $line-nb-bg;
padding-right: 1em;
pre {
background-color: $line-nb-bg;
border: 0px;
margin: 0px;
}
}
.CodeRay .line { background-color: $line-nb-bg }
.CodeRay span.line-numbers { padding: 0px 10px 0px 0px }
// As in Sublime editor
// Violet for constants ("Rails")
.CodeRay .constant { color: #9B859D; }
// Blue for predefined-constants ("self")
.CodeRay .predefined-constant { color: #7587A6; font-weight: normal }
|
There are several ways to add code snippets now we have kramdown installed and customized.
What’s great about this color scheme customization is that you can still use the default Solarized themes if you want, as I did in the beginning of this post, with the usual codeblock syntax.
On the other side, you won’t be able to use the triple-backtick code blocks any more.
To add a kramdown code block, you can do the following:
You can also use the single backtick syntax for inline code:
1 |
`def hello`{:lang="ruby"}
|
And voilà! You have your own color scheme, customizable at will.
It’s been a year or so since I first thought about starting a blog. And then there was work, family, more work, two cats, and time flew by without me even noticing. Then a friend told me about Octopress, so I checked it out.
Hmm… Blogging framework for hackers, Ruby, Heroku, markup and one-line deployment? Sounds great!
In less than an hour I had cloned Octopress, bought my domain, linked it to Heroku and deployed my beautifully empty blog. Yay! This is blogging for hackers.