justinmaccarthy

I was getting an error on a new install of JRuby on a Linux

jruby 1.1.4 (ruby 1.8.6 patchlevel 114) (2008-08-28 rev 7570) [i386-java]
Created MBeanServer with ID: -vsnele:fl2bg1bd.0:mandlebrot:1
java.lang.management.ManagementFactory:-1:in `getPlatformMBeanServer’: java.lang.InternalError: One of the management beans is not compliant.
from org.jruby.management.BeanManager:59:in `register’
from org.jruby.management.BeanManager:29:in `register’
from org.jruby.compiler.JITCompiler:68:in `<init>’
from org.jruby.Ruby:207:in `<init>’
from org.jruby.Ruby:160:in `newInstance’
from org.jruby.Main:184:in `run’
from org.jruby.Main:100:in `run’
from org.jruby.Main:84:in `main’

It turned out that remove the following packages solved that problemRemoved the following packages:
java-gcj-compat
java-gcj-compat-headless

I’m sure most of the Apple fan boys here have seen  Apples new improved .net offering, MobileMe.
It turns out that the MobileMe interface is built using an opensource  Ajax/Widget  toolkit called SproutCore.

Lets have a look on how you install SproutCore

sudo gem install sproutcore

Look familiar ?  View Helpers  are RHTML files e.g.

<%= label_view :my_label, :tag => ‘h1′, :inner_html => ‘Hello World!’ %>

The ruby stuff is only used in production, in a similiar way that GWT uses Java to generates the HTML and JS runtime files….

While SproutCore uses Ruby to generate static HTML and JavaScript files, you are not tied to Ruby or Rails in production.  SproutCore runs in the browser, your production system can use whatever backend you want, as long as it sends JSON to the browser.

I finally had enough of Textmate’s slow find in project,  and had a look around. I wish I’d taken 2 minutes to that before because I found the awesome Grep in Project command for TextMate
by some guy who’s name I couldn’t find easily, I know how much he runs and he listens to a lot of  Duran Duran, but I can’t see his name anywhere : -)  Anyway his grep script works great so  go get it .

These are a few snippets for getting and viewing your log files

This task will download your production log and put a time stamped version in your local log directory

task :download_log do

TIMESTAMP = ‘%Y%m%d%H%M%S’

get "#{deploy_to}/current/log/production.log",

"log/production._#{Time.now.strftime(TIMESTAMP)}.log"

end

If you are writing an application that allows your users to upload files, you have to work around the fact that their files will be deleted every time you deploy your application.

Usually if you want your file to available they will be uploaded to the public folder. The solution is to store those files in the “shared” directory.

Here is one example on how to set that up for a Rails app.

Create a directory called “uploads” in your.

When using attachment_fu or similar, use a :prefix=>”/public/uploads/#{tablename}

Add the following tasks to your deploy file

desc "link upload directory"

task :symlink_uploads, :roles => :app do
  run “ln -nfs /var/www/apps/#{application}/containers/rails/#{application}/shared/system/uploads #{release_path}/public/uploads“
end

end

desc "create upload directory"
task :create_uploads_directory, :roles => :app do

	run “mkdir #{deploy_to}/shared/system/media”
end
end

Hook them into your deployment

after "deploy","symlink_uploads“

after "deploy:setup","create_uploads_directory“

Any uploads will now be stored outside the versioned directories.

Ferret (http://ferret.davebalmain.com/trac) is a high-performance, full-featured text search engine library written for Ruby.

It is inspired by Apache Lucene Java project.

acts_as_ferret comes with a built in DRb server that acts

as the central hub for all indexing and searching in your application.

Ferret now comes with a recipe for managing your Drb server. The Ferret config file is located at config/ferret_server.yml and

looks like this:

production:
host: ferret.yourdomain.com
port: 9009
pid_file: log/ferret.pid

The supplied recipe looks like this

namespace :ferret do
desc “Stop the Ferret server, and continue even if the operation fails.”
task :stop_safe, :roles => :app, :on_error => :continue do
top.ferret.stop
end

desc “Start Ferret Server”
task :start, :roles => :app do
top.ferret.start
end

desc “Stop Ferret Server”
task :stop, :roles => :app do
top.ferret.stop
end

desc “Restart Ferret Server”
task :restart, :roles => :app do
top.ferret.restart
end

desc “Rebuild the Ferret index”
task :rebuild, :roles => :app do
run “cd #{current_path} && rake production ferret:rebuild”
end

desc “Destroy the Ferret index”
task :destroy, :roles => :app do
run “cd #{current_path} && rm -rf index/production index/development index/test”
end

end

As of revision 5774, capistrano  has a  default  dotfile.

Here’s how dotfiles work in edge capistrano:

* The dotfile, by default, is called “.caprc” and will be searched
for in your home directory. On Unices, this is the ENV["HOME"]
variable. On windows, it is “#{ENV["HOMEDRIVE"]}#{ENV["HOMEPATH"]}”.
The environment is searched in that order (so if you have HOME set on
Windows, it will be used), and if none is found the root directory is
used.

* You can override the path to the config file via the -c switch:
“cap -c /path/to/.customrc …”

* You can specify that you don’t want to use the config file at all
via the -x switch: “cap -x …”

* The file will be loaded immediately after the “-S” options are
processed. Thus, variables you set via -S will be available to
the .caprc stuff.

The major difference between the patch you submitted and the way I
implemented it is that the .caprc will always be loaded, whether or
not other recipe files are specified. (As I mentioned above, you can
skip the config loading with -x.)

[From Jamis buck on the mailing list ]

namespace :deploy do
task :restart do
sudo “/usr/local/lsws/bin/lswsctrl restart”
end

task :stop do
sudo “/usr/local/lsws/bin/lswsctrl stop”
end

task :start do
sudo “/usr/local/lsws/bin/lswsctrl start”
end

end

If you are using the Thin webserver you can add  the following to you deploy file to restart support restarting  Thin

namespace :deploy do
task :start do
sudo “/etc/init.d thin start”
end
task :stop do
sudo “/etc/init.d thin stop”
end
task :restart do
sudo “/etc/init.d thin restart”
end
end

If you can’t use a SCM from your server for  whatever reason you can use

set :deploy_via, :copy

to compress and upload your code from your development machine.

Here is an example and some setting that you can use :

set :deploy_via, :copy

# the source is checked out first before it is compressed and uploaded

# this specified how this happens export or checkout

set :copy_strategy, :export

set :copy_remote_dir, “some_tmp_path” # it defaults to /tmp

set :copy_compression, :zip       # :zip or :gzip, :bz2