Dirk.Net

After installing, trying and discarding typus, casein as well as ActiveScaffold, I ended up with one of the best plugins I’ve seen, and certainly the best for utterly effortless admin panel setup,  admin_data.

It is

• super-quick to install (Rails 3 is the gem, Rails 2 is a plugin branch, no digging through trees on github),
• unintrusive (all code is in vendor/admin_data where it belongs),
• requires no set-up,
• correctly (!) gets all model information from your model definitions (primary_key, foreign_key, relationships etc.),
• including multiple databases, SQL Server connections via activerecord-sqlserver-adapter, and even
• composite primary keys,
• making it great for legacy data,
• uses your existing authentication solution.

It’s basically completely abstracted sitting on the top of ActiveRecord, and this design choice is very powerful. Not only that, it even checks your model definitions along the way. If your table is visible and editable in admin_data, it’s probably defined correctly (especially with regards to foreign_key, primary_key(s), set_table_name and other stuff relevant for legacy data). And did I mention the configuration is one block in one file in your app?

Have a look at the readme whose four lines are indicative of the DRYness and brilliance of this plugin.

Note: This all concerns Rails 2.3.x and recent versions of AuthLogic

Testing AuthLogic with RSpec is still a puzzle with several parts that can be difficult to fit together. Very helpful is a sample project on github that demonstrates several testing options with RSpec.

A series of mock helper methods that you can stuff in your spec_helper.rb can ease testing, letting you call

login

or

current_user

anywhere in your specs.

If you get errors such as

Mock "UserSession_1002" received unexpected message :record with (no args)

when mocking, the issue might be that current_user_session.record (or the underlying method which is hard to find) which is likely called in your ApplicationController is deprecated in favour of current_user_session.user

This deprecated code is still in the authlogic sample project as well as Ryan Bates’ Railscast 160, so it might be confusing. Alternatively you can mock the :record call as well as some have accomplished as posted in the comments of the original post.

The MongoDB replica set tutorial should be easy enough to implement on a Windows (server) machine, but how do we run our replica set members as MongoDB windows services, having them start up automatically or manage them with the Windows SCM (Service Control Manager)?

Suggestions to seed multiple hosts in one command didn’t work for me and several other options did not bear much fruit.  Especially running mongod —install with the —serverName option did not work out as the new service instance will be named like the first, leading to a conflict and failure of the command.

So the best path might be to forego the 10gen suggested Windows service installation and use the sc.exe utility instead to create the service instance like so:

sc.exe create "Mongo DB 1" binPath= "c:\mongodb\bin\mongod.exe --service --dbpath c:\data\r0 --logpath c:\log\mongodb.log --replSet my_replica_set --port 27017 --rest"

sc.exe create "Mongo DB 2" binPath= "c:\mongodb\bin\mongod.exe --service --dbpath c:\data\r1 --logpath c:\log\mongodb.log --replSet my_replica_set --port 27018 --rest"

sc.exe create "Mongo DB 3" binPath= "c:\mongodb\bin\mongod.exe --service --dbpath c:\data\r2 --logpath c:\log\mongodb.log --replSet my_replica_set --port 27019 --rest"

Be sure to check adjusts your paths and urls, duh. To edit these commands you can check and edit the HKLM\System\CurrentControlSet\Services\<Mongo Service Name> key, especially its ImagePath parameter. The —rest parameter in the commands above lets you check your replica set configuration by navigating to http://localhost:28017/_replSet

This technique will also be handy when implemeting sharding. Things may get better with 1.7+ versions of MongoDB.

Hope it helps.

Update December 4th  2010: Linode made it four outages in 12^1/2 days. Now they’re changing the hardware but this is not an acceptable level of reliability.

Update December 3^rd  2010: Linode made it three outages in 12 days. Time to look for another hosting company.

Linode’s Fremont facility has suffered the second outage in three days. On Sunday all my sites were down for about six hours, the longest outage I have seen in almost fourteen years of hosting usage. And now it’s only Tuesday morning in California

For now, I can’t recommend Linode, at least not their Fremont facility. And I come from years of Windows hosting without issues!?!

Update: The node ended up being down for about three hours.

Certainly outages can happen, but not for these periods of time, and twice in three days.

Otherwise Linode slices are fast, reasonably priced and backed up by excellent support, but the Fremont node appears to be down more frequently than other.

To host your private gems you have several options. The cheapest and most scalable solution will likely be to run your own gitosis server. Then you build your gems as described in this railscast and push them up to your gitosis repo. But how to deploy and install these gems when the gem is updated?

Installing a gem from Git involves four steps:

1. Clone the Git repository.
2. Change to the new directory.
3. Build the gem.
4. Install the gem.

Git post-receive Hook

One way is to implement a Git post-receive hook. This hook is in the hooks directory of your repo, and it has to be edited on the server. You cannot edit a hook locally and push it to the remote server. So ssh into your remote server and create a hook named post-receive (with 755 permissions) to look as so (Update: because of a “Permission denied - /tmp/stdout.echoe” error rm has to be run with sudo and visudo permissions for the git user has to be extended to ALL):

#! /bin/sh
cd /home/git
unset GIT_DIR
sudo rm -rf mygem
git clone /home/git/repositories/mygem.git
cd mygem && sudo rake manifest && sudo rake build_gemspec && sudo rake install 

Be sure to have the following in your visudo on the remote server:

git ALL=NOPASSWD: ALL

That’s it. Very easy.

Of course you can now setup different remote servers and push to them as needed.

Capistrano

For rails you could use capistrano and run these task only when deploying a Rails project, by putting this into your deploy.rb fild:

namespace :gems do

desc “Install gem”
  task :install_mygem, :roles => :app do
    run “cd /home/git && sudo rm -rf mygem”
    run “git clone git@yourserver.com:mygem.git“
    run “cd /home/git/mygem && sudo rake manifest && sudo rake build_gemspec && sudo rake install”
  end

end

Hope it helps. If you have a simpler or more effective way, please post in the comments.