If you use the new 'restful_authentication' plugin, you might have problems to update your User attributes:

WARNING: Can't mass-assign these protected attributes: uploaded_data, display_name, first_name, last_name

The solution is to add these attributes in your User model with attr_accessible:

# HACK HACK HACK -- how to do attr_accessible from here?
# prevents a user from submitting a crafted form that bypasses activation
# anything else you want your user to change should be added here.
attr_accessible :login, :email, :password, :password_confirmation,
:first_name,
:last_name,
:display_name,
:uploaded_data

attr_accessible specifies a white list of model attributes that can be set via# mass-assignment, such as update_attributes(attributes)

Thanks to this Frederick Cheung who explained it in the Rails mailing list.

I am still using subversion (shame!) but now more and more plugins are hosted on github ...
To install a plugin with this configuration, you'll need the following commands:

cd vendor/plugins
git clone git://github.com/dchelimsky/rspec.git
rm -rf rspec/.git
svn add rspec
svn commit . -m "added plugin

From http://www.intridea.com/blog/

Preaching What We Practice

"We believe that community and collaboration are vital to the long-term prosperity of the internet. This blog is a way for us to share some of the lessons we’ve learned along the way with the community. You’ll see tips and tricks as well as plugin releases and general thoughts about the industry. We hope you enjoy it!"

In an unsustainable world where corporations (people) only do things if they can make a profit, that's a quote I like to read. The number of happy people happy to give in the Rails community makes me feel good and gives me a lot of hope about the future.
Eventually, the critical mass of the "let's change the world" people will grow and we will see more transparency in the actions taken by the corporations and states.

If you live on the edge (Netbeans Edge + Rails 2.1.0 + RSpec edge 1.1.4 + ZenTest 3.10.0) at the time of this writing - july 2008 - you'll have to hack autotest to be able to keep working with your favourite editor :-)

Indeed, when I upgradded to the latest stable versions, the wonderful "Auto test" feature in Netbeans stopped to work. It took me 45 minutes to find out what was happenning and to find a solution, hem hack.

As it says in the History file, there is now a command called "autospec" for running specs since RSpec 1.1.4. As Netbeans run the system command "/usr/bin/autotest", it won't discover any specs in your project

A quick hack to make it work, Add the following to /usr/bin/autotest:
ENV['RSPEC'] = 'true'
which will tell autotest we are actually using specs. The sad truth is I don't understand why it works, I need to dig in the code of the rspec-rails plugin I guess ... Enough time wasted!

I am not sure this change in will make RSpec users life easier ... Anyway, that's the way it is!

For netbeans developpers, it will be quite tricky to make it work with different versions of RSpec. I guess they'll have to test what version of RSpec is installed and use autospec for RSpec >= 1.1.4 ...

My /usr/bin/autotest file:

#!/usr/bin/ruby1.8 -ws
#
# This file was generated by RubyGems.
#
# The application 'ZenTest' is installed as part of a gem, and
# this file is here to facilitate running it.
#

require 'rubygems'

version = ">= 0"

if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then
version = $1
ARGV.shift
end

ENV['RSPEC'] = 'true'
gem 'ZenTest', version
load 'autotest'

I have inherited a server with super sized log files for Rails and nginx: hundred of GB ... All the files occupy 65G (including home partition), it seems a lot to me!

The fact the person who configured is supposed to be an expert on Rails hosting and has a good "WWR reputation" .... If s(he) "forgot" about such things, it gives me a lot of hope regarding my sysadmin skills: I don't know anything but it's easy to learn...

After a few googling, I found out about logrotate and then t capitate, which contain very usefull recipees for capistrano. Rails conventions and philosophy is about DRY and automatize all these repetitive tasks and capitate author Gabriel Handford has understood it very well and share its work to the community. THANKS :-)

You could spend 5-10 minutes on each project configuring logrotate for all your dependencies (monit, sphinx, Rails, nginx ...). copy-paste et voila! how boring ...

In 1 minute, using capitate, you can configure logrotate with a capistrano task!
Install capitate (read the capitate well written doc) and


$ cap nginx:logrotate:install
...
$ cap rails:logrotate:install
...

VERY IMPORTANT: you need to specify:

set :use_sudo, true

to run that command otherwise it will fail with:
** [out :: beta.lecool.com] install:
** [out :: beta.lecool.com] cannot create regular file `/etc/logrotate.d/rails_beta.lecool.com'
** [out :: beta.lecool.com] : Permission denied


Let's contribute to this gem! Get the sources with

git clone git://github.com/gabriel/capitate.git

A stupid mistake I did and I'd like to share so people don't waste their time.

Don't use PATH or N as environment variables you want to use as parameters for your rake tasks.

I am creating a plugin to backup mysql databases with a crontab and I wanted to make things as simple as possible for the end user to use the plugin. I first came up with the following command

rake mysql_db:backup PATH=/tmp/pouet N=1

It was not working, giving error messages such as:

sh: mysqldump: not found
sh: gzip: not found

Writing this post, I reckon it is quite obvious I should not have used PATH as a parameter for a rake task .... No wonder it could not find gzip .... But I did not think about it in the first place and started looking at rake and ruby code!

So now the command is:

rake mysql_db:backup PATH_BACKUP=/tmp/pouet NUMBER_OF_DUMPS=1

By the way, is there more *elegant* way than environement variables to pass parameters to a rake task???

I am thinking I could use a prompt !