Biomedical Engineering Reference
In-Depth Information
to this it is fabulously easy to share data between tools in this framework.
It is useful to note that the Rails project changes signifi cantly between
versions 2 and 3, so initiating a project in Rails 3, although giving you the
most bleeding-edge code base has somewhat lower community support,
for the time being at least. There is lower coverage of Rails 3 in the many
blog articles about Rails and in the web forums that coders use to discuss
and help each other with coding problems. In these forums most problems
you encounter starting out will already have been asked, or will get
answered in some fashion after a couple of days. Rails 2 applications are
inherently incompatible with Rails 3 applications and upgrading is not
straightforward.
Once the app is developed, serving it has its own issues; the in-the-box
server Webrick or a vanilla Mongrel setup are not designed for a
production environment. The traditional approach to hosting Rails
applications is to have a server running Mongrel or even Webrick, the
Ruby servers built into Rails, attached to local server ports with Apache
[13] to proxy requests to the Rails application servers. This setup helps
to avoid the limited concurrent connections and stability problems in
Mongrel and Webrick. However, running multiple Rails application
servers uses lots of machine resources and is time-consuming to confi gure
and maintain. A far better approach is to allow Apache to run the Rails
application code, which we do with the Phusion Passenger module (aka
mod_rails) [14]. With this approach applications are only running when
they are needed, can be deployed with minimal confi guration and multiple
Rails applications can be deployed under the same Apache server (each
just requiring a separate RailsBaseURI declaration in Apache confi g).
New apps can be deployed in minutes without time-consuming proxy
confi guration or ongoing maintenance efforts to ensure that individual
application servers are running. We enjoy using Rails and do indeed fi nd
it is a very productive environment, but it is a little over-hyped, although
increasingly easy to code with and prototype an application on your local
machine, it can be a struggle to push to the production environment. Not
many Sys-Admins are experienced enough with the system to host it
easily and some work needs doing at deployment to successfully host an
app with many users moving lots of data about, but once the right trick
is learned for your production environment it is easy to scale.
For the high-throughput image data that we generate, initially we were
using a fl at-fi le archive system on our server, although the rate at which
we generate images precludes this being viable for long. We are now
moving over to a more versatile Omero server [15]. Omero is an image
repository and API produced by the Open Microscopy Environment
Search WWH ::
Custom Search