Wednesday, January 27, 2010

tail - follow two to n files at once

I often use tail -f filename.txt ... then recently I realized I was switching back and forth between test.log and development.log, and that only one was being used at a time -- could I follow both at the same time?

Turns out you can, and really easily.

tail -f file1.txt file2.txt

useful and easy. eureka!

Thursday, November 19, 2009

regenerating httpd.include from capistrano with sudo

As a general rule, if you need to do something with sudo in your cap scripts, and you don't know why that might be a bad idea, something has gone wrong. I recently ran in to an exception. For various reasons, we need to auto-generate our httpd.include file after deploying to production.

note: command names have been change to protect me from unknown risks. :)

Anyway, here's how I got it to work with a minimum of fuss:

In order to generate the httpd.include file, we need to run a command.

sudo /usr/sbin/whatever -a

which will then generate my httpd.include file. Previously, the account used by capistrano, 'deployer', did not need sudo access, but there doesn't seem to be a way around it in this situation. I assumed (possibly incorrectly) that capistrano would not be able to handle entering the sudo password, so my goal was to give sudo access to 'deployer', but only for this one file, and without having to enter a password.

[jwright@server ~]$ sudo visudo

and I added this line:

deployer ALL=NOPASSWD: /usr/sbin/whatever

then I SSH'd in using the deployer user and verified that it could execute that file with sudo access without typing a password. I still need to consider the implications of this user editing that file...

so then in capistrano:

desc 'autogenerate httpd.include file'
task :generate_httpd, :roles => :app do
run "sudo /usr/sbin/whatever -a", :pty => true
end

alternately, I could have done this:

desc 'autogenerate httpd.include file'
task :generate_httpd, :roles => :app do
run "#{current_path}/script/autogenerate_httpd", :pty => true
end

which might be a good idea just so I don't have to remember the command if I want to auto-generate it when I'm SSH'd in at some point...

Either way, the :pty=>true apparently is necessary to run sudo, and it somehow relates to the fact that sudo typically asks for a password. That this one command doesn't require the password seems to be irrelevant.

Monday, October 26, 2009

Show alert messages in firebug

A cool javascript trick:

alert = console.log

then

alert('hello')

will show up in Firebug instead of an alert screen:

"hello"

Thursday, October 22, 2009

Get a List of Bad Links from Rails Log

If you have a Ruby on Rails app and you want to generate a list of the URLs that have generated 404s from your logs, here's one way:

perl -n -e '/No route matches "(.*)" with .*/ && print "$1\n"' log/production.log | sort | uniq > public/bad_paths.txt

then view:
http://production_site/bad_paths.txt

We're using Passenger, and I'm not sure to what extent passenger is involved in the format of the Rails logs -- I would assume it's not, that wouldn't be very Railsy, but if it doesn't work, that might have something to do with it.

Anyway, unix is cool.

Tuesday, October 20, 2009

sometimes it's the little things

I was looking through the ways you can tweak gMail and found this. I can't say how often it would have prevented me from looking like an idiot.

Forgotten Attachment Detector
by Jonathan K

Prevents you from accidentally sending messages without the relevant attachments. Prompts you if you mention attaching a file, but forgot to do so.

Thursday, October 1, 2009

Remote Pair Programming by any other name ....

I've tried pair programming remotely a few time recently. I think it's been beneficial, but the lag time is always an issue when you're using screen sharing and Skype. I finally found out that I was using the wrong keywords to look for what I wanted, which was a text-editor that enabled remote pair-programming. The search term that brought me the best results so far is 'collaborative real-time editor'

Here are the ones I'll be testing as soon as I find a willing victim .. uh .. partner.

Gobby - can be served locally, but you'll need to open ports on your router
Collab - for netbeans, requires a server
Cola - for eclipse

Wednesday, September 23, 2009

Why do we use factories for testing?

A client recently asked me why we used factories in our tests. Here's my answer:

Originally, people would create a new instance of every model in every test. So, if you were testing that we properly parse dates and know which ones are valid and which aren't, and you know that Person requires a name, you might write:

Person.new(:name => 'fiona', :dob => '3/5/12').should be_valid

and that was cool

then eventually:

validates_presence_of :email
validates_presence_of :favorite_color

then

Person.new(:name => 'fiona', :email => 'fiona@gmail.com', :dob => '3/5/12', :favorite_color => 'red').should be_valid

and

Person.new(:name => 'fiona', :email => 'fiona@gmail.com', :dob => '3/12', :favorite_color => 'red').should_not be_valid

just to make sure we were properly parsing dates and ensuring we got a complete one.

and so that was moderately painful, but then...

we split name into first_name and last_name

and then we have to change 75 tests

so then someone said, "This is really painful."

"Let's create a default Person, and just modify it when we want to test things."

and the solution followed the GoF pattern called Factory
so that's what they called it.