Archive

Posts Tagged ‘Automation’

Bash alias and functions

January 13, 2012 Leave a comment

I made a quick reference to alias in my previous post and thought I’d expand on that a little more and introduce bash functions as well. alias and function are two ways to automate simple commands and reduce the amount of typing you do each and every day. Some of these commands I used to type out 20x a day and got annoyed at having to type so much. All of the alias and function definitions are in my .bash_profile script so they get loaded every time I login (.bashrc should also work).

The big takeway here is how alias differs from function.

  • An alias is processed at the time of its definition and therefore cannot take arguments.
  • A function is processed at runtime and can process arguments.

rgrep is real command (grep -r) but I wanted to add a few other default parameters. To speed up searches I like to exclude .svn and vendor (gem bundler) folders. All I want to type is what I’m searching for and the files/folders I want to search.

function rgrep() {
   rgrep -n --exclude-dir=.svn --exclude-dir=vendor $1 $2
}
# Search all = *
function agrep {
   grep -nr --exclude-dir=.svn --exclude-dir=vendor $1 *
}
# Search case-insensitive (-i), all (*)
function aigrep {
   grep -nri --exclude-dir=.svn --exclude-dir=vendor $1 *
}

jheth@dev:~$ rgrep substr ~/project/
jheth@dev:~$ agrep substr
jheth@dev:~$ aigrep ClassName

As mentioned in my previous post, I used alias to cd into the proper directory and run the watchr process. I also made one to edit the watchr configuration file.

alias watchem='cd ~/project/ && ./test/bin/watchr ./test/tests.watchr.rb'
alias editwatch='vim ~/project/test/tests.watchr.rb'

jheth@dev:~$ watchem

Every once in a while GLaDOS (jabber bot) misbehaves and I need to kill the process. At first I was running 2 commands to do this, grep + kill. I then created this one liner but I never want to type this out manually.

function killbot() {
   kill `ps -ef | grep glados.rb | grep -v grep | awk '{print $2}'`
}

jheth@dev:~$ killbot

I manage all of our remote deployments, svn merges, and various remote tasks through Capistrano now. I got tired of changing directories just to run the command so I turned it into a function.

function capy {
   pushd `pwd`
   cd ~/github/release-scripts && ./bin/cap $1
   popd
}

jheth@dev:~$ capy update:web:staging

I hope this sparks some ideas for the repitive commands you run each day. Feel free to post comments as suggested aliases or functions.

Advertisements
Categories: Uncategorized Tags:

Using watchr with PHPUnit

December 16, 2011 Leave a comment

I’ve known about watchr and autotest for a while but have never taken the time to set them up.  I should have done this a long time ago, I noticed the efficiency gains immediately.

Initial Setup

Create a local Gemfile and install the necessary gems.

jheth@box1:~$ cd ~/project/src/test/
jheth@box1:~/project/src/test$ cat - > Gemfile << EOF
source :rubygems
gem 'watchr'
gem 'rev'  # Provides event support for Linux
EOF
jheth@box1:~/project/src/test$ bundle install --path=vendor --binstubs

This will install the watchr gem into a local vendor folder and create ~/project/src/test/bin which will contain the watchr executable script.

Configure Script

Next, configure the watchr.rb script.  You can configure any number of watches for files and/or folders.  The watch() function takes a regex with any number of captures to grab filename or parts of the path. The ‘do’ block is executed whenever a file changes. You can change the phpunit parameters to whatever you want.

~/project/src/test/watchr.rb
# Watch test files
watch("src/test/model/(.*\.php)") do |md|
   system("cd src/test/model && phpunit --debug --colors '#{md[1]}'")
end
# Watch src objects
watch("src/main/model/(.*)\.php") do |md|
   system("cd src/test/model && phpunit --debug --colors '#{md[1]}Test.php'")
end

Notice that these paths are RELATIVE, which means you must run this script from ~/project.  I had trouble with both absolute and relative (../) style paths so I just decided to run it from a higher level folder.

cd ~/project && ./src/test/bin/watchr ./src/test/watchr.rb

To see what files are being watched you can use the -l argument. This only prints the names, it doesn’t actually begin watching.

./src/test/bin/watchr -l ./src/test/watchr.rb

Fire this up in a separate terminal and let it just sit there all day while you edit your files. You will see the phpunit output everytime you save a file. I turned on –colors and –debug so I don’t have to guess when something goes wrong.

Wrap Up

This has already saved me a ton of time since I would previously switch between terminal sessions, typing or arrowing to the phpunit command I wanted to run. Now I never have to leave the editor and when saving either the test or the underlying source file, the tests get run. Decreasing the amount of time between edits and test execution is a huge time saver. I get instant feedback every time I save.

The startup command is a bit annoying to type so I added an alias to my .bash_profile.  No matter where I am, I can just pick a terminal and type ‘watchem’ and I’m up and running.

alias watchem='cd ~/project/ && ./src/test/bin/watchr ./src/test/watchr.rb'
Categories: Uncategorized Tags: , ,

Jabber Bot

October 9, 2011 Leave a comment

I’ve been inspired many times by reading through developer blogs from various companies: Atlassian, GitHub, Google, Etsy, etc.  I love to hear from other developers, how they work and how their company works.  I have borrowed many of these ideas and incorporated them into our workflow at Sentry.

I recently came across this blog post by Zach Holman from GitHub:
http://zachholman.com/posts/why-github-hacks-on-side-projects/

I’m no n00b to jabber bots.  Sentry has been using them for years, but mainly for alerting and error reporting.  I love being jabbered, with a full stack trace and supporting data, any time a problem occurs in our system.  It makes fixing things 10x easier.

I’ve also been using the jabber bot that Jenkins (fka Hudson) provides for several years and have always liked the idea of it.

I finally decided to make a bot to do our bidding at work.  We decided to call her GLaDOS, which many of you will recognize from the famous Portal game.

GLaDOS can now deploy to remote systems (via capistrano recipes), merge/commit changes to our various svn repositories, jabber other users, run caching scripts, and hopefully much more in the near future.

Categories: Uncategorized Tags: ,