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!
Wednesday, January 27, 2010
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.
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.
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.
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.
Subscribe to:
Posts (Atom)