Will google drive succeed?

ruby debugger config

Whenever you notice a strange behaviour in the code or unable to assert the strange behaviour via a test, it’s helpful to launch the debugger and start inspecting the variables / try evaluating the piece of code. The REPL has so far been the best features offered by any good dynamic or functional language like ruby, haskell, clojure, python etc.

You could install ruby debugger for ruby 1.9 using the traditional gem command or adding it to the Gemfile depending on your environment.

gem install ruby-debug19

The debugger can then be invoked anywhere in the code by requiring the debugger.

require ‘ruby-debug/debugger’

The debug console is pretty advanced in terms of functionality and can be used in the same way as gdb. However, more often you use the debugger, typing eval every time gets tedious. You can avoid this by typing in 

set autoeval

By doing so, every single line of code you type in the console will be immediately evaluated in the context of the currently executing code.

Also, when the debugger launches, it gives the next line of code it’s about to evaluate. In most cases, this should be fine but it helps to see few lines around the code. You can enable this by

set autolist

Once this is set, it will show the line surrounding the current code execution.

Or you can set this is the environment default by setting it up in .rdebugrc. This is how my  .rdebugrc looks like this.

set autolist

set autoeval

set autoreload

For a full list of debug commands, look up the cheat sheet. Also check pivotal labs article on quickly setting up debugger for rails.

csshx - handy tool to ssh multiple boxes

One of the major pains in managing many servers is at times you would want to do some command like changing to a particular directory and tail a log file. It’s painful and time consuming having to ssh to each of these boxes manually and execute the commands over and over again. While there are tools like puppet and chef to automate software installations, it could be a over kill for such a simple situation.

I recently came across csshx (works only on mac) which perfectly solves this problem. csshx will attempt to create multiple ssh connections to list of servers you specify and give you a seperate terminal where you can key in commands which will be executed in all the other open windows(AppleScript magic).

Say for example you would like to connect to two servers 192.168.1.1 and 192.168.1.2 and tail a log file, you could do this using csshx with the following command,

csshx —login username 192.168.1.1 192.168.1.2

and voila, you have two windows with a login to each of these boxes and a red window to enter your commands. This will be copied across to all the other terminals. csshx also has an awesome set of keyboard shortcuts that you could master to get things by quickly.

You can install csshx using brew by typing the command:

brew install csshx

For people using other package managers refer their info site, or you can download the csshx script directly from google code.

Tweaks to default Hg config

The default mercurial installation does not support colours, pager or a progress bar by default. Unlike git, hg is highly customisable with python and a ton of extensions are available. Some of these extensions are bundled with mercurial and other nice ones can be found across the web. 

Color Output:

Mercurial by default outputs all the diffs and logs using the default colour of the terminal. Mercurial standard library has support for colours by adding this line to .hgrc.

[extensions]

color=

Progress Bar:

Mercurial is generally fast but in certain cases(like a slow network) or a big repository, some of the commands take a considerable amount of time and mercurial command line does not produce any output until the action is complete. You can get a kickass progress bar by adding the following line in .hgrc.

[extensions]

progress=

Pager:

Most of the mercurial output is redirected to STDOUT without using less / more support. While this makes sense for default install, its painful when reading big diff logs or trying to traverse the hg graph log. You can add support to use less by adding this to your .hgrc.

[extensions]

pager=

[pager]

pager = LESS=’FSRX’ less

ignore = version, help, update, serve, record

Git diff:

For people who are used to reading git diff formatted files, you can enable use git diff format by specifying the following to your .hgrc

[diff]

git = True

My .hgrc can be found in this gist.

Feature Toggles, Feature Branching and Branch by Abstraction

Note: For people who argue only one of it is good, please read this. Its written by Fredrick Brooks, one of the seminal guys in software engineering. 

Purpose: Main aim of this article is to spur a thoughtful discussion around the topic than religious opinions or fear mongering about how other option is scary.

There is so much of debate around feature toggles and feature branches. Most of the existing literature seems to be around each one of it rather than contrasting them and giving a holistic picture. Some of the ones that do give like this seems to be missing the big picture. Here is my attack at the whole situation.

Why These?

Before we delve any deeper lets look at the various reasons around why we would need these techniques in first place.

1. Ability to release at any time. Delay in the development of a particular feature does not halt the entire production release cycle.

2. Ability for the business to hide features / AB test them / do a delayed release of a particular functionality / back out a particular feature.

For purposes of argument, this article will focus only on 1. Look here for debate around 2.

The Promise of Feature Toggles:

1. Continuously integrating changes in CI and if anything goes wrong could be reverted back.

2. Functionalities can be switched off if the integration does not go well.

3. No merge hell / Semantic merge conflicts

4. Code changes made are immediately in trunk available for the entire team for review.

To Note:

1. Feature Toggles aren’t necessarily used only in case of Large features, it could be used to hide certain functionalities that could be as simple as introducing a field to a form.

Arguments against Toggles:

1. Every Toggle added to the system needs to be checked with state on and off. So the more toggles in system would mean more combinations to test. 

2. Some toggles cannot be clearly done in a clear way. In some places it could be as simple as a change in the injected object to if statements clobbered everywhere across the code.

3. Since feature toggles themselves involve code, we could accidentally be exposing something that’s potentially untested / that should not be displayed(How do you think the apple rumours(like this) are fuelled anyways?) 

4. The longer the Toggle is existent in the system, the more expensive it is.

The Promise of Feature Branches:

1. Well tested code after QA’ing ends up in master.

2. Master can be deployed at any arbitrary moment.

3. Ability to track which changes went to each story/feature.

4. Ability to isolate noise when working on something big like a refactor(note: large refactoring is usually bad and should be done incrementally as much as possible).

Arguments against Branching:

1. Delays Testing(wait, am I getting wrong or qa’s don’t start testing until we call the story complete, in case of feature branching its after developer calls it complete.)

2. Merge Hell and Semantic Conflicts.

3. Integrating with CI less often.

Feature Bits

1. The arguments in feature bits of Facebook kind of invalidates the whole statement

Authoritative Articles about the subject.

http://techcrunch.com/2011/05/30/facebook-source-code/

https://www.facebook.com/video/video.php?v=10100259101684977&oid=9445547199&comments