The README wasn’t able to help much, as it only mentioned adding the Ruby path to the start of the ~/.irbrc file. The solution was to add a require ‘rubygems’ to the ~/.irbrc. Although the error didn’t mention it the problem was that wirble couldn’t load because rubygems were instantiated.
Here’s my current ~/.irbrc with the update:

1. “Not recognized by identify”: This one is resulting from a call to ImageMagick (you did know ImageMagic was required, right?) and a bad relationship with Passenger. The easiest way to resolve this is to place the following line in your appropriate environment files (ie. config/environments/development.rb) making sure that it point to your local instance of Imagemagic. For my development environment on OSX it was:

Paperclip.options[:command_path] = "/opt/local/bin"

(I’m using imagemagic from a MacPorts install; if you are on a linux distro you may need to reference /usr/local/bin.)

1.5 “Not recognized by identify” is also caused when you specify “styles” for a has_attached_file type other than a photo. I’m really not sure how to get around this one, but if you are going to use any file types other than images using the following string in your model will cause the error:

:styles => { :large => "300x300", :medium => "200x200", :thumb => "128x128>", :micro => "40x40#"}

2. Don’t name your model “attachment”: I googled around forever trying to figure this one out. In the end it seems to be a namespace error between Paperclip and the app – Paperclip won. I named the mode “client_attachment”.

3. Remember to include your attachment type in you attr_accessible declaration: If you are protecting against mass assignment you’ve an attr_accessible line in your model. Be sure to include the name of the field you’re using for the attachment in the declaration. For example, if you’re using a “photo” for the Paperclip attachment, be sure to add “:photo” to your attr_accessible declaration:

attr_accessible :first_name, :last_name, ..., :photo

Short aside … the plugin allows for a very DRY approach to managing permission from one configuration file, not to mention that it generates a visualization of your ACL, too. This is a huge benefit when building an app that has a number of different security roles. Additionally, it allows access control on the controller, model, query, and view levels. From the site:

Plugin features

• Authorization at controller action level
• Authorization helpers for Views
• Authorization at model level
  • Authorize CRUD (Create, Read, Update, Delete) activities
  • Query rewriting to automatically only fetch authorized records

I was ecstatic about using the plugin but hit a stump when trying to work it out with my own HABTM association in my Rails app. The third requirements mentions, “User objects need to respond to a method :role_symbols that returns an array of role symbols”. My log error kept displaying:

In order to get things to work correctly with a User model, Roles model, and Roles_Users table for the “has_and_belongs_to_many” relationship, you need to make sure you’ve a method in your user model that “correctly” generates a “roles_symbol” array:

Note: Make sure that you use the correct value of the filed in your roles model when serializing. The example used “title” but in my application I used “name” for the column that defined the role.

Finally, I stumbled upon, David Deraedt’s AIR Application Descriptor Manager. Honestly, I didn’t think much about it, and hadn’t much in terms of hopes, but after running through the settings for my file and saving it … eureka! Automatic building took over and I have a successful Application Descriptor.

The culprit: a rogue slash “/” mysteriously placed in the original prevented the descriptor from being built.

Technorati Tags: Flex4, Gumbo, Troubleshooting

I originally found myself here while beta testing a new subversion client and inadvertently clicking “yes” I want to upgrade my working directory. But that’s another story. Here’s what I did (I’m running Mac OSX 10.5 Leopard):

1. Download and install the Subversion 1.5 binaries from OpenCollabNet (via http://subversion.tigris.org/getting.html#osx). Once you download the .dmg, simply run the installer like you’d normally do any installer. You’d imagine that this would be all but it’s not because the new subversion installs to /opt/subversion/bin rather than /usr/bin.
2. Update your path by either editing the “~/.profile” (for your individual user profile) or “/etc/profile” (for all system users). I chose to do this for my system as I used several accounts for different purposes. If the file doesn’t exist you need to create it. Then add the following line to the top of the file: 
   export PATH=/opt/subversion:$PATH
3. Finally, rename the previous svn executable. You may find that you still cannot access subversion 1.5 if the 1.4 file is still available. Navigate to your /usr/bin folder and rename the old svn located there:
   $sudo mv svn svn.old
   • Thanks much Coals [2] Newcastle for helping me with this one. 
4. Now when running svn –version you should see the 1.5 client referenced.

Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.

Reason: Error reading from remote server

---

Apache/2.2.3 (Red Hat) Server at [myserver.com] Port 443

And when viewing the log files I was receiving errors like:

And this, too: (I tried these instructions too, but didn’t work.)

Additionally, I received “Operation Not Permitted” errors when trying to restart and/or stop the mongrel clusters:

Solution

I was able to resolve the issue by killing all the active Mongrel processes and then restarting manually. You can do this by:

1. Viewing all active mongrel processes:

(The second number is the process id; that is the id you’ll use to kill the process.)


2. Killing each process id

“sudo kill -9 [process id]“, For example, to kill the first process listed above:

3. Restarting your Mongrel instances

In order to get things working right I had to update the system files so everything would run:

Now running the update works.

A number of months ago ActiveReload came on the scene with a new application called “Warehouse” which makes for a really aesthetic and functional way of managing repositories in Subversion.

The app requires you to install the Ruby Subversion Bindings, and while it may seem quick in the instructions, it wasn’t like that for me installing on RHEL 5. (I’m following through the instructions listed here).

Be warned – you may want to go grab a cup of java and get comfortable, because this is a long one …

First of all I have a problem extracting and installing swig.

I don’t know why it happened and why the file couldn’t extract so instead I went straight to the main sourceforge page (http://sourceforge.net/projects/swig/), download the latest build, and uploaded it to my server. Then follow the instructions using the new filename (for me it was “swig-1.3.32-rc1.tar.gz”).

This got me through the ./configure, but during the make I received an error that pointed to a missing “g++”.

I then found out (by way of a 2 hour date with google) that by default RHEL5 doesn’t come with g++ installed. (I’m sure a much seasoned linuxologist would have figured it out quicker, but I digress.) So, using yum:

In order to get the make to pass, I then had to re-run the configure. The make, and install succeeded afterwards.

But it’s not over yet. For step 2, I ran then tried to run the “make swig-rb” and received another error regarding the Apache Portable Runtime not being installed:

As this post reveals, there is some newness between the Apache Portable Runtime (APR) and neon (don’t even ask me to explain) which make for an error in trying to install the bindings (the command “make swig-rb”). So to get by this, I followed the instructions by Josh Goebel at this pastie to get by. ***Note that on line 4 you need to omit the “tar.gz” as I’ve indicated below.

WOW!!! When it rains it pours … while running the first config for neon, the process stopped because I didn’t have an XML parser on the system. (I’d thought the folks who set it up had done so, but that wasn’t the case.) So I installed expat with:

And after continuing through the remainder of the pastie, I’ve finally got subversion bindings installed! And now for the moment of truth …

Eureka! The test passed! Now I’ve got to actually install Warehouse … but I’ll save that for tomorrow. And I won’t even tell you how long it took me to finish all this stuff.

Here’s the complete pastie with my additions (depending on how your admin set things up you may have to sudo each line):

If you’re on a Mac, you’ll need to edit your “/etc/profile” page and then type these in, so something like “$textedit /etc/profile” or “$ mate /etc/profile” (if you are using TextMate) from your Terminal window will open your system profile.

Now what’s nice is that f I want to visit “my directory”, while in the terminal I just type”$ gotoMyDir”; if I need to run a capistrano “deploy_with_migrations” script (yes, I’m using 1.4.1 until a few more 2.0 updates finalize) I just type in “$ capdm” … you get the picture.

Nice indeed, and saves the keys!

1. First you’ll need to install ImageMagick

   [source:ruby]$ sudo yum install ImageMagick ImageMagick-devel[/source]

2. Now configure, setup and make

   [source:ruby]
   $ sudo mkdir /home/imins
   $ cd /home/imins
   $ sudo wget ftp://ftp.imagemagick.org/pub/ImageMagick/ImageMagick.tar.gz
   $ sudo tar -zxvf ImageMagick.tar.gz
   $ sudo cd ImageMagick*
   $ sudo ./configure –prefix=/usr –enable-shared=yes
   $ sudo make && make install
   [/source]
   Note: the last command (make & make install) will take a long while to run

3. Install the RMagick gem[source:ruby]$ sudo gem install rmagick[/source]

Thanks to NDCHost, Cyberciti and Creativist for the help.

Blogged with Flock

Tags: rmagick, linux, imagemagick, rhel5

I’m actually in the process of setting up another application to use SQL Server and am trying it out. I’ll see what happens…

Nah, they are referencing the Ruby DBI modules and the ADO libs are only good if you are accessing from a Windows based machine. Oh, well … :)

To explain a bit more, my application has 2 points of entry:

1. “Applicant” – enters the system and does things like applicants do (fill out forms, check history, etc.
2. “User” – enters the system to manage applicants, and besides, has multiple types of security roles in the system.

So in each of these circumstances the models are different, the methods are different, and it seems certain that the authentication is different. Seeing as how I really like the restful_authentication plugin, I decided to use it for both authentication schemes.

1. To do this run your restful authenticated generator for the first model:

   [source:ruby]$ ./script/generate authenticated user sessions –include-activation[/source]

2. Once your generator has run you need to rename the “[rails_root]/lib/authenticated_system.rb” and “[rails_root]/lib/authenticated_system_helper.rb”. If not, then the next time you try to run the generator you’ll be asked to overwrite the value. I just pre-pended the name of my model; i.e. “applicant_autheniticated_system.rb”
3. You also need to rename the classes themselves, so open up those 2 files and change the first line to match the value you just renamed it to. So for example, my “applicant_authenticated_system.rb” value would have the first line of: [source:ruby]module ApplicantAuthenticatedSystem[/source]. As a special note, please be sure to remember that the name does not include underscore values, so if you’ve placed them in the name of the file, the class name will omit them and only use CamelCase.
4. Finally, in your controllers where you include the AuthenticatedSystem use the new name, so for my controllers I would place [source:ruby]include ApplicantAuthenticatedSystem[/source].
5. Repeat these steps for the next model you wish to authenticate by, using the new model and you’ll have another restfully authenticated sytem, too.

So I’m sure you could take the restful_authentication gem and refactor it to use multiple instances, but this way I have 2 separate/independent instances of authentication.