# Don’t Panic!

I’m loving today’s Google Doodle for Douglas Adams’ birthday:

He would have been 61 today.

# The Bang-bang Command

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.

## Behold the power of bang-bang

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!

# Introducing Octopress-Chuck-Norris

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.

### And Octopress-Chuck-Norris was born

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?

### Bonus

Here are some other resources I found. Only Chuck Norris can read these at work without laughing out loud.

Enjoy!

# Replacing With Regexes in All Your Code Files

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.

## Modifying only code files

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"  ## Erase all the newlines! 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:  1 2 3 4  void myFunction() { // How annoying. cout << "Howdy!" << endl; }  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!  1 2 3  void myFunction() { // Not annoying any more! cout << "Howdy!" << endl; }  ## No! Don’t erase all the newlines! 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. ## Conclusion 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). ## Bonus : some of the regexes I used Here are some of the regexes I used to prettify the code base and correct cpplint warnings: • adding a space after a comma: s/\,([^\s])/, \1/g. You can use variations of this for other punctuation signs or operators. • removing spaces before references: 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. See? You have to be careful, you didn’t think about && did you? • adding two spaces before each one-line comment: s/([^\s])\/\//\1 \/\//g and s/([^\s])\s\/\//\1 \/\//g (for cases with zero and one space before the comment) • adding a space to transform ){ into ) {: s/\)\{/) {/g • removing newlines before bracket openings: s/\n\{/ {/g. To be used with the perl version. # Cloning a Heroku App With Git | Comments 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 :  1 2  heroku login heroku keys:add [your key file]  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! # Octopress and the Twilight Color Scheme | Comments 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: 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! ### Getting to the dirty business 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:  1 2  gem 'kramdown' gem 'coderay'  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 #### Tweaking the scss 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:  1 2 3  $code-bg: #141414; $code-color: #F8F8F8;$line-nb-bg: #404040; 

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 } 

#### Adding code snippets

There are several ways to add code snippets now we have kramdown installed and customized.

##### Pygments

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.

##### kramdown

To add a kramdown code block, you can do the following:

 1 2 3 4   def hello puts "Hello!" end {:lang="ruby"} 

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.