There are binaries for Postgres in /usr/bin that are NOT from the install. I resolved this by opening /etc/paths and moving /usr/bin to be after /usr/local/bin. Once that change was made and I opened a new terminal I no longer had any of the previous issues.

curl -LI http://your.webserver.here

From a security perspective, giving out information about the version number of the web server, the underlying operating system, and the application software version isn’t the best idea. A couple things you can do to remedy this on Apache:

Set ServerTokens to Prod in the apache.conf (/etc/apache2/conf.d/security on Ubuntu 10.4)

ServerTokens Prod

This removes the Apache version and any information about the operating system. It will show that it is Apache, but that is it.

If you are running PHP you should also edit the php.ini file (/etc/php5/apache2/php.ini on Ubuntu 10.4). Make sure that expose_php is set to off.

expose_php off

Those two changes will make sure your Apache server isn’t announcing what version it is, what OS it’s running on, and which version of PHP it’s running.

I have been looking for a good way to run Cucumber tests from inside of vim without having to switch to a terminal window and enter the cucumber command. My first solution was to add a couple of key maps to my .vimrc file:

map c :!cucumber -r features %
map C :!cucumber

I use a comma as my leader. (set in the .vimrc file with)

let mapleader = ","

So by entering ,c while in command mode, vim fires off the cucumber command against the file that is in the current buffer (the one I’m working on) and ,C runs cucumber against the current working directory. This works okay, but it isn’t a perfect solution. Some of the problems are:

1. The vim session freezes until the tests finish
2. When I exit the command window I lose all of the output from running the tests
3. With MacVim I lose color in the terminal

None of these are that big of a deal, but they do make it feel clunky.

Then I came across this post from Larry Marburger over the weekend that talks about setting vim up to send Cucumber commands to a screen session. He references a blog post by Jonathan Palardy that goes in to some good detail about how to get everything setup for this to work. Using these two posts as a reference I started experimenting, and I think I’ve come up with a pretty cool work flow.

These directions require Screen in order to work. I’m using MacVim, but if you are on a Linux machine you can replace mvim with gvim.

First off you need slime.vim. Move this to your ~/.vim/plugins/ directory.

Next, add this to your bash alias file:

function svim { local dir=`pwd`; mvim; screen -S slime; cd $dir; }

This creates a new shell function that:

1. gets your current directory
2. opens MacVim
3. starts screen with a session named slime
4. cd the new screen session back to the original directory you started from

Next we need to add 2 lines to our ~/.screenrc file:

termcapinfo xterm* ti@:te@
shelltitle 'w0'

Now we have some default Screen parameters that we can reference from our Vim session and we can setup some keyboard maps to make things easier:

.vimrc file

map <leader>t :call Send_to_Screen("cucumber -r features " . expand("%") . "\n")<CR>|
map <leader>T :call Send_to_Screen("cucumber" . "\n")<CR>|

The first one allows me to type ,t to run cucumber on the .features file I currently have open. The second sets up ,T to run cucumber on the entire project. Both send the command to a remote Screen session and Vim goes right back to what you were doing. By sending the commands to a remote screen this deals with all three of the problems that I mentioned earlier.

1. You don’t have to wait for the tests to finish running before being able to move on to the next task.
2. The output continues to be displayed in the terminal window while you work through any problems.
3. The colors are displayed properly.

So what does the work flow look like with this setup?

1. Open a terminal
2. cd to the project directory
3. Type svim
4. Start working on a features file in mvim or gvim
5. Type ,t to execute the scenarios from the current file
6. Check output on terminal window (This works great if you have two monitors so that you don’t have to command/control tab to the terminal window)
7. Type ,T if you want to execute all scenarios for the project

That’s it.

Bash aliases are a very useful feature for UNIX command line users. In this article I will discuss what they are and how to take advantage of them.

Aliases are a way to say “when I type this, I want you to interpret it as this other thing.” For example:

alias ft='find . -type f'

If you type ‘ft’ at the command line before entering this alias command, you will most likely get:

-bash: ft: command not found

Once you type the alias command in, typing ‘ft’ should start firing off a list of all files recursively under your current directory. You now have a way to enter the longer command by simply typing 2 characters. This can come in handy when there are strings of commands that you use frequently that are long and/or hard to remember.

So now that we understand what an alias is, let’s make it so that every time we open a new terminal window we setup some aliases automatically. This can be done by putting the alias directly in the .bashrc files in your home directory, but I prefer to create a .bash_aliases file and reference that from the .bashrc file. This helps me keep things organized and makes it easier to share aliases across multiple machines. So under your home directory use your favorite text editor to create (or open) a file called .bash_aliases. Add some aliases like:

~/.bash_aliases file:

alias tu='top -o cpu' #top cpu processes
alias tm='top -o vsize' #top memory processes
alias ls='ls -FG'

Notice how I create an alias for an existing command ‘ls’. This allows me to set my preferred defaults so that I can just use ‘ls’ and get the enhanced command instead. Now we need to add a couple of lines to our .bashrc file so that it knows to pull in the aliases from our .bash_aliases file.

~/.bashrc file:

if [ -f ~/.bash_aliases ]; then source ~/.bash_aliases; fi

Adding this line to your .bashrc tells bash that when you start a terminal to check your home directory for a file named .bash_aliases and include it as a configuration file.

That is it. Now when you find a need for a new command shortcut you can simply add it to your .bash_aliases file and it will be available anytime you start up a new shell. If you would like to see the list of aliases that you have, maybe that you've created or that were setup for you when your account was created, simply type:

alias

That should give you a full list of all currently existing shell aliases.

Hopefully this gives you the basic idea of creating and managing bash aliases. They can be a real benefit if you spend much time at the command line helping you reduce keystrokes and speed up repetitive processes.

A useful command that I frequently use when looking for a particular string in a file is a find command piped to xargs grep. For example, if I am looking for the word Mike in any file inside of /usr/local I will type:

find /usr/local -type f | xargs grep Mike

This says to start in the directory of /usr/local and search recursively for anything that is a file. Then pass that file to grep to search inside the file for the text Mike. There is one problem with this though. It doesn’t handle spaces in file names. When it comes across a file name with a space you will usually see something like:

grep: /Someplace/Somewhere: No such file or directory

This can be confusing since you would assume that find actually found something to pass to grep. It is misleading though, as the problem actually has to do with a white space character in the file name or directory. It is very common to see spaces on Linux and Mac OS X systems, so it is important to learn to work around this problem. The solution is pretty simple. Both GNU find and xargs support a zero option that displays white space as a NUL character.

find /usr/local -type f -print0 | xargs -0 grep Mike

This should take care of the white space issues. I hope this helps.

OK, to get this out of the way. I know SOAP isn’t cool. However, there may still be times when you need to query data from a SOAP web service. This is an attempt to document the process of retrieving and working with that data.

In this example I will describe how to query the WSDL to get a list of methods and parameters, and use that to submit the method call. I will be calling a web service method called ‘webMethod’ that accepts one parameter called ‘publishDate’. If you don’t already know this information about the web service you are communicating with, there is a free tool called SoapUI that works pretty well. It’s written in Java, so you should be able to get it to work on about any platform.

Depending on the version of Ruby you are running, the first thing that may be required is to install soap4r:

gem install soap4r

Next is to set the location of the WSDL file on the web server, set the encoding, and instantiate the driver:

require 'soap/wsdlDriver'
wsdl = 'http://server/WebService.asmx?WSDL'
driver = SOAP::WSDLDriverFactory.new(wsdl).create_rpc_driver
XSD::Charset.encoding = 'UTF8'

This next line will create two logs in the directory of the process called devLog_webMethod_response.xml and devLog_webMethod_request.xml that will show the raw request and response each time the process is called. In place of webMethod will be the actual method name of the web service being called. This can be commented out when the application is moved to production.

driver.wiredump_file_base = "devLog"

Now it’s time to retrieve the data:

@response = driver.webMethod(:publishDate => '2008-09-01')

At this point @response contains the XML response from the web service. In order to retrieve the data we will need to know a little bit about the structure of the XML. We can find out this information by opening the log file created by the previous step. Let’s open devLog_webMethod_response.xml:

<?xml version="1.0" encoding="utf-8" ?>
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<soap:Body>
<WebMethodResponse xmlns="WebMethod">
<WebMethodResult>
<Article>
<Name>Example 1</Name>
<Headline>Poor Excuse For An Article</Headline>
<Body>Nothing to see here, move along please.</Body>
</Article>
<Article>
<Name>Example 2</Name>
<Headline>Woot! I Made Headlines</Headline>
<Body>Yeah, OK. Another poorly written example article.</Body>
</Article>
</WebMethodResult>
</WebMethodResponse>
</soap:Body>
</soap:Envelope>

OK, so here we have two articles that contain the data we are after and they are both inside the WebMethodResult tags. So to access those bits we might do something like:

@response.webMethodResult.article.each do |article|
puts article["Name"]
puts article["Headline"]
puts article["Body"]
end

That works great as long as there is always more than one article. If, on the other hand, there is only one article in the result, it is no longer an array and the .each method will fail. So to get around this we can move our logic to a method and then test the article first to see which way we should handle it. So the previous code might be rewritten as:

def print_article(article)
puts article["Name"]
puts article["Headline"]
puts article["Body"]
end

if(@response.webMethodResult.article.is_a?(Array))
@response.webMethodResult.article.each do |article|
print_article(article)
end
else
print_article(@response.webMethodResult.article)
end

If you are asked to do some work with SOAP based web services, hopefully this makes it a little easier to get up and running.

I guess this is what I get for doing most of my testing in Firefox. I created an aspx page to be opened in a javascript window.open to allow a customer to preview some rendered HTML. I used labels in the aspx page and then populate those with data returned from a database. Everything looked great in Firefox, but when I checked it in Internet Explorer, there was no word wrapping. Each line ran off the page. After some research I found a CSS property called word-wrap. The property is part of the CSS3 draft and is used to force word wrapping. Since this is a simple page that is opened in a pop-up window, I was able to fix the problem by simply adding the following to the CSS style.

body {
  word-wrap: break-word;
}

If I understand the CSS3 draft correctly, this should actually force a word wrap even if it occurs in the middle of a word. However, in testing with both Firefox and IE 7, this is not the case. It breaks at the end of the word.