Google recently removed their Apps tab and I really liked it. After a few minutes of searching, I came up with a very simple way to get it back:

1. Install the Chrome extension New Tab Redirect!
2. Using the extension, set the new tab to open chrome://apps/

That’s it, that’s all. Back to being useful.

I was working on some log processing the other day when I encountered a situation where I wanted to have the python equivilant of Unix’s head and tail commands.

The problem here is that most anywhere you look, Python’s version of tail tends to share the same problems.

• Reads the entire file into memory.
• Iterate over the entire file.

Obviously, this can be quite problematic when you have 300mb logs constantly processing. Here is a more efficent version of tail:

If you have ever used tail to follow multiple files, you will notice that it can be a real pain to read what data is coming from what file. Here is some quick perl I use to make it a bit easier:

1

tail -f *error_log | perl -pe "s/==>(.*)?<==/\e[0;31m$&\e[0m/g";

You can of course extend this to a full out perl script that processes data as follows:

1
2
3
4
5
6
7
8
9

#!/usr/bin/perl
while ($line = <STDIN>) {
  // Process $line however you need           
  // For the above example...
  $line =~ s/==>(.*)?<==/\e[0;31m$&\e[0m/g;

  // Now print it out like a boss
  print $line;
}

Now you can just pipe whatever data you want into the above script:

1

tail -f *error_log | perl -p processor.pl

At my work, we have been using a Git branching strategy based on Vincent Driessen’s successful Git branching model. Over all, the strategy that Vincent proposes is very good and may work perfectly out of the box for many cases. However,  since starting to use it I have noticed a few problems as time goes on:

• a LOT of branches – Since Vincent’s model has a branch for each release version, over time you get a lot of branches lying around.
• Redundant - At any given time, we will have 3 identical entities:
  • release branch
  • A master branch (after release-1.0 has been merged in)
  • A version Tag (1.0)
• Changes to every build – We use Jenkins CI and we currently have to change each job to point to the new tag or branch. It get’s a little tedious and won’t scale in the long run.

Fortunately, these problems are easy to fix. In fact, the fixes simplify the model and allow simpler automation.

When using Linux every day, it is important to find a distribution that works for you. For me, after more virtual machines than I care to count, I settled on Fedora as my distribution of choice. I really like the constant releases and the latest software. It’s also nice to be able to jump on a RHEL machine and feel at home!

So, I get pretty psyched every 6 or so months when a new version of Fedora released. The latest release is one of the bigger ones they have done and, while I am still playing around with it, seems full of great updates.

Since I use it as my development environment, the nicest change for me day-to-day is the update to Gnome 3.4, a WM that I seem to enjoy much more than most developers apparently.

If you have some time, grab the latest Fedora release and check it out! You won’t be disappointed.

So it seems that, while I don’t have a lot of code that would work as projects, I do have a fair bit of code that works as gists.

I posted a new gist I simply call notify which allows you to give custom  messages in the message tray in a programmatic way. I often use it in conjunction with kTimer. I have only tested this script with Gnome 2.x-3.2 but it very well may work in KDE or other desktop environments.

If you find notify useful, please leave a comment!