RailsConf: Ezra Zygmuntowicz - Rails Deployment

Posted by Nick Sieger Sat, 24 Jun 2006 19:18:00 GMT

Ezra: Programming in Ruby for 3 years, Rails for 2. Just another Ruby hacker, he says. Right!

Yakima Herald

  • http://yakimaherald.com -- Local newspaper website
  • CMS
  • Lots of non-SQL content
  • Classified and obituary workflow
  • Internal credit card transaction

Data Aggregation

  • Mysql
  • XML feeds from AP
  • RSS and Atom feeds from parent newspaper
  • Proprietary database for articles
    • Yucky Vendorscript
    • Crusty OS 9 server!
    • Wrote DSL to emit script over a socket to remote machine

Deployment

  • Apache? Seems to be the industry standard...
class ApacheWithFCGI < ActiveRecord::Base
  has_many :random_500_errors
end
  • Lighttpd
    • Better FCGI support
    • More stable
  • Switched to standalone, external FCGIs with capistrano spinner/spawner/reaper tasks, and finally got stable.

Tuning

Shared hosting

  • Apache with ProxyPass/ProxyPassReverse talking to multiple lighty instances is about as good as it gets.
  • But let’s face it...shared hosting + Rails suck.
  • Only as reliable as the worst application on the server
  • Not always good neighbors
  • Resource constraints
  • Free-for-all

Ezra recommends a Xen VPS for Rails deployment. I’ve followed his advice; this blog is hosted on a Xen VPS at http://rimuhosting.com.

Deployment models

  • Starting point, web, app and db on the same server.
  • Next, move database to a separate server. Use the more powerful hardware to the db.
  • Third, split each role to a separate server. But now you need an NFS to serve static and cached contents. Ezra states you can go a long way with this setup
class FutureOfRailsDeployment < ActiveRecord::Base
  belongs_to :mongrel
end

Mongrel

  • Speaks plain old HTTP, so you can take advantage of existing tools for load balancing, proxying or caching
  • You can use frontends: Pound, Pen, Balance, Haproxy, Lighttpd (although mod_proxy needs to be fixed), or Apache 2.2 modproxybalancer
  • Mongrel cluster gem allows easy management of multiple mongrel processes. It’s straightforward to integrate with capistrano too.

Engine Yard

Ezra describes a new hosting service he’s been working on that will give you a greatly simplified but powerful and performant hosting environment for your Rails applications, including a web admin console and deployment directly from SVN revisions and tags.

Go to Engine Yard for a beta signup email now!

BackgroundDrb

  • Distributed Ruby server that manages long runnng tasks.
  • Uses a MiddleMan proxy/stub class that allows the Rails process to connect to the background server.
  • Can use it as a worker queue, (e.g. for sending email) or as a distributed memory cache.
  • You can even query for progress on the background workers and push the result all the way to the browser with an ajax progress bar.
  • The code for BackgroundDrb looks really clean! Go to http://backgroundrb.rubyforge.org/ for the nitty gritty.

Posted in ,  | Tags  | no comments | no trackbacks

RailsConf: Bill Katz - Metaprogramming Writertopia

Posted by Nick Sieger Sat, 24 Jun 2006 17:27:00 GMT

Bill Katz took a code-focused approach to explaining metaprogramming and DSLs.

Resources

Bill applies Paul Graham’s quote on bottom-up design and lisp as justification for using Ruby to program DSLs.

Authorization plugin

In search of a better authorization scheme, Bill wanted an elegant syntax using blocks to delineate sections of code that require specific permissions, and a more intuitive way of managing the data surrounding access controls.

current_user.has_role? "moderator"
current_user.has_role? "member", workshop
workshop.accepts_role? "member", user

current_user.is_moderator_of workshop
user.is_eligible_for? campbell_award

Implementing permit

class MeetingController < ApplicationController
  permit "rubyists and wanna_be_rubyists", :except => :public_text

We need a class method. Where to put it? How does this work? (Insert pretty diagram of instance, singleton class and superclass here.) Metaclassees are “anonymous”, you don’t see them by looking at class ancestors.

ActionController::Base.send(:include, Authorization::Base)
ActionView::Base.send(:include, Authorization::Base::ControllerInstanceMethods)

Singleton methods from the point of view of the object are the same as instance methods in the metaclass. See slides on “How do we permit?” for details. Bill chose to tuck the DSL-related methods into modules and used self.included, class_eval and other goodies to set up the methods in the correct places. There is more than way to do this but I suspect Bill chose to do it for purposes of cleanly separating concerns along the lines of where in the class hierarchy the methods live.

ActiveRecord::Base.send(:include,
  Authorization::ObjectRolesTable::UserExtensions,
  Authorization::ObjectRolesTable::ModelExtensions)

This loads an acts_as_authorizable plugin which, when used in a model, inserts an accepts_role family of methods for querying and setting user roles.

Bill blazed through a whole lot of pretty-looking code here for how to set up the DSL infrastructure. You’ll have to go over to the writertopia developer link to see it. Bill has said he’ll post his slides online as well.

Questions

  • Use of method_missing -- does that clash with ActiveRecord::Base usage of method_missing? No, as long as you use super to invoke the next method in the chain, you’re ok. Ruby module inclusion semantics handle this for you.
  • How to insert the class methods? A discussion started around ActionController::Base.send(:include, ...) and There is More Than One Way to Do It.
ActionController::Base.send(:include, Authorization::Base)

class ActionController::Base; include Authorization::Base; end

ActionController::Base.class_eval { include Authorization::Base }
  • Question about the class inheritance chain. There are actually two inheritance chains, one for the classes and one for the metaclasses. Resolution at method invocation time travels first to the object’s metaclass, then to the object’s class, then to the superclass of the singleton class, then the class’s superclass, etc. Blech, that makes no sense. Instead, go read Seeing Metaclasses Early.

Posted in ,  | Tags  | no comments | no trackbacks

RailsConf: Steven Hammond - DSLs and Rails Plugins

Posted by Nick Sieger Sat, 24 Jun 2006 16:18:00 GMT

Intro

Steven talks on the whats and whys of domain specific languages.

Steven’s background is is as a java developer and more recently, a project manager, or “sith lord” as he put it.

Some early exposure to DSLs for him involved the use of something called Program Composition Notation that was used to describe a weather modeling program to be run on massively-parallel supercomputers.

Features of DSLs

  • Usually a partial programming language focused on a single problem domain.
  • Replicate syntax/structure that is common to users of that domain.
  • Tries to be as elegant, concise and expressive as possible in that domain.

Horizontal vs. Vertical

  • Horizontal -- programming problems (e.g., Rails migrations)
  • Vertical -- business domain problems (e.g., a game DSL, insurance product definition, circuit board specification)

Recipe example

Steve contrasted a procedural, C-style recipe vs. a Ruby-based DSL that used blocks to delineate ingredients from procedures. The differentiating point was “which one could your mom translate into meatloaf”? I suppose neither if you don’t like your mom’s meatloaf.

Rails DSLs

  • The framework itself (“is the whale shark a fish?”)
  • Migrations
  • RJS templates
  • Plugins
    • acts_as_state_machine
    • RESTful Rails
    • game_dsl

When to create a DSL

  • established syntax or vertical domain
  • soemthing that’s inelegant in normal imperative or object-oriented style
  • abstract implementation details so that you don’t depend on them (e.g., migrations does this for database DDL)
  • reuse

DSLs and Reuse

  • “Reuse is vastly overrated” -- DHH in 1/2006
    • Business logic is very application specific and is difficult to reuse across projects
    • Level of reuse is at a lower lever where there is an information barrier to understanding the component (e.g., LINPACK)

Designing a DSL

  • Be careful to balance forward-looking with extraction. In other words, DSLs should be extracted or driven by need just like anything else.
  • Layout a domain syntax (not necessarily in Ruby)
  • Extract and evolve over time
  • Translate business requirements/statements into succinct programming fragments. (e.g., rolling dice and assigning attributes)
# extending Integer to deal with die-rolling
3.d6
3.d6 :keep_best => 3

# Deck-dealing example
class Tile < AciveRecord::Base
  acts_as_deck
end

class Player < ActiveRecord::Base
  acts_as_player
end

class DeckController < ApplicationController
  def deal_cards
    @deck = Tile.find :all
    @deck.shuffle
    @card = @deck.draw
    @deck.deal :cards => 6, :to => @players
  end
end

There was a discussion at this point about whether it was necessary to use a DSL in this case, and Obie Fernandez piped in that if you’re aiming for reuse or as an API, DSLs give a readable, understandable representation that makes reuse and sharing easier.

Another comment was regarding namespace collisions, and Steven replied honestly that there is not a good answer. If you combine a game-playing DSL with a home-building DSL, are you randomizing your porch?

YAML provides another good medium for succinct data layout (e.g., database.yml). Steven’s example followed the same pattern to apply to selecting different sources for a random number generator.

Pitfalls

  • DSLs should not necessarily be the first solution -- the domain could be too narrow or too broad.
  • Too many DSLs (or even plugin bloat) could end up compromising the readability of the code. Namespacing comes in here. Which DSL/plugin provided the given functionality?
  • Interaction side-effects -- it’s not clear how mixing metaphors can make the solution clearer.
  • Vertical DSLs additionally suffer from the problem that it’s still programming, and there are syntax issues to overcome, even though the DSL can faciliate interactions with the customer.

A comment came from Aslak Hellesoy about the use of external DSLs (i.e., built using parser generators). Steven replied that it is appropriate in some cases, but the complexity will be higher.

It seems to me that in the case of external DSLs, the freedom (lack of constraints) can actually be a burden. You can design syntax however you want but you need to be sure that it makes sense to the people who will be using it. Unless you’re really good with language and interface design it can be easy to create a custom, niche language that nobody knows anything about and is inflexible. In my experience it’s hard to use parser generators like yacc to build flexible parsers. Ruby turns out to be really good for DSLs because you can omit details (parentheses and hash curly braces) and it still does what you want.

Posted in ,  | Tags  | no comments | no trackbacks

RailsConf: Obie Fernandez - Thoughtworks on Rails

Posted by Nick Sieger Sat, 24 Jun 2006 15:15:00 GMT

Is anyone doing “real” projects in Rails? Obie’s talk is the answer to this frequently received question.

Twix, the first Rails project at Thoughtworks was an internal tool that functioned as an introduction to the technology and began the evangelization process for Rails within Thoughtworks.

Apparently DHH and Roy (the owner of Thoughtworks) hit it off when DHH said to Roy in a meeting, “I want to change the world.”

The Deere project started as a supply-chain application built on Java that took 6 weeks to get up and running. Rails was sneaked in as a tool to help business owners generate sample data for the main application. The interface was simple, and made it fun for the users. It generated quite a stir, with one of the customers exclaiming that it was better than the app they already had!

This led to Deere COA (Certificate of Analysis). There was a sticky-note, user-centered design, task analysis session that helped to drive what form the application would take. The resulting implementation took about two calendar weeks, eight person weeks. Obie’s comment at this point was that the amount of time was on the order how long it usually took the client just to decide that they wanted to do something.

Later, as maintenance of the tool was being handed off to some internal developers, Obie gave a brief presentation on Rails to some of the client stakeholders. When he returned to finish training on the technology three months later, he found that a product manager (somewhat non-techie) had built a time tracking application during his two-week family leave that subsequently received a lot of attention at the office. A project manager was asking him to help fix a bug with the application that had already been deployed and in use for three months, and the company wanted to roll it out for use to several thousand people at the company.

The story about the Kiosk project highlighted that agile and XP methods fit so well with Rails. Obie described one case where they brought their usability expert in for a review and Rails allowed them to make changes to the UIs as fast as the usability person could point them out.

Note: Q & A is paraphrased.

  • How can you transform a client’s thinking about technology and acceptance of Ruby and Rails so that when you leave, they own it? Find a common thread of command-line, text-based development, or experience with similar languages. Most skilled programmers can pick up Rails in days or weeks. Your miles may vary but it goes with the amount of talent you’re working with.
  • Comment on RadRails. Code completion is overrated, it keeps you from solving the problems in your head because the editor is feeding alternatives to you.
  • Comment on deployment. The reason you can’t do Ruby on Rails is that it’s not a supported technology in our data center. Politics, status quo, not important, blah, blah. We ended up doing the app anyway, and the data center people said, “sure you can do it, we’ll give you a VPS”.

Posted in ,  | Tags  | no comments | no trackbacks

RailsConf: Amy Hoy - Overcoming Scaffolding Addiction

Posted by Nick Sieger Fri, 23 Jun 2006 21:43:00 GMT

Scaffolding is not a swiss army knife, it’s more like a rusty spoon. It’ll give you tetanus! Scaffolding leads to brain atrophy and laziness. Leads to bad code, bad UI, etc. Instead, start from scratch. script/generate is not inherently bad, it can write necessary, tedious code for you.

script/generate controller kitten create view put_to_sleep

This gives you:

class KittenController < ApplicationController

  def create
  end

  def view
  end

  def put_to_sleep
  end
end

Amy proceeds to break down a from-scratch, minimalist set of views, to underscore the point that it’s not too hard to not use scaffolding. I’d agree, it was so straightforward that unfortunately I’m going to omit the details here. Rolling your own without scaffolding is highly recommended.

Some of the items that you generally will experience in real world apps but do not come in scaffolding are widgets for maintaining relationships. Select lists based on a belongs_to, checkbox groups for has_many are two examples.

Amy breaks these down as well and it turns out they’re pretty easy to do. One snippet of code for updating checkboxes was succinct and surprisingly readable, and made judicious use of the ruby array’s - behavior to add newly checked and remove newly unchecked items quickly.

Amy promised to post snippets and slides later on her blog, so go over to slash7 for more.

Posted in ,  | Tags  | no comments | no trackbacks

RailsConf: Stefan Kaes - Rails Performance

Posted by Nick Sieger Fri, 23 Jun 2006 20:40:00 GMT

Stefan starts by citing a factor of 4-5 improvement in performance in Rails over the last year.

Performance, broken down

  • Latency -- how fast
  • Throughput -- how many
  • Utilization -- how idle is the cpu
  • Cost efficiency -- performance per unit cost

For completeness calculate the min, max, mean and standard deviation of these metrics and use the deviation as your guide for how reliable the data is.

Tools

  • Log files (level > Logger::DEBUG)
  • Rails Analyzer Tools (Eric Hodel)
  • Benchmarker (script/benchmarker)
  • DB vendor tools
  • Apache bench (ab or ab2)
  • httperf
  • railsbench (Stefan Kaes)

Railsbench

Railsbench measuress raw performance of rails request processing. It’s configured using config/benchmarks.yml and config/benchmarks.rb. These files let you control which requests get benchmarked, whether to create a new session when benchmarking them, etc.

Profiling Tools

At this point Stefan gave an overview of RPV, which appears to be a nifty tool that lets you get typical hotspot tree views of where time is spent in code. It currently only runs on Windows.

Top Rails Performance Problems

  • slow helper methods
  • complicated routes
  • associations -- navigating and eager loading vs. proxy loading
  • retrieving too much data from the DB
  • slow session storage (e.g., ActiveRecord store)

Stefan says that in his experience, DB performance is generally not a big factor or bottleneck. Instantiating ActiveRecord objects is expensive, though.

Session containers

  • In memory -- if you server crashes...oops. Also doesn’t scale.
  • File system -- easy to set up, scales with NFS, but slower than...
  • ActiveRecordStore -- easy to set up since it comes with Rails, but much slower than...
  • SQLSessionStore -- which uses the same table structure as ActiveRecordStore, but was written by Stefan to overcome performance issues with ActiveRecordStore. Setup is more involved.
  • memcached -- slightly faster than SQLSessionStore, scales best, but setup is also more involved.
  • DrbStore -- distributed ruby store

Caching

  • Full pages -- fastest, complete pages are served on the filesystem. Web server bypasses appserver for rendering. If you have private pages, you can’t use it.
  • Actions -- pages are cached after an action is rendered. The user ID can be used as part of the storage key.
  • Fragments -- fragments can be cached in memory, on the file system, in a DrbStore, or in memcached. Memcached scales the best but doesn’t support expiring fragments by regular expression.

ActionController

  • Stefan recommends avoiding components, and replacing them with helpers or partials. He has not found a use for them.

ActionView

  • Don’t create unnecessary instance variables in the controller; creating them in the view with instance_variable_set and accessing with instance_variable_get is slow.

Helpers

  • pluralize -- don’t use the inflector if you don’t need to, it’s expensive.
  • linkto and urlfor are among the slowest helpers, since they need to use routes. Instead, if you have page with lots of links, you might consider hard-coding the links. This reduces the amount of GC by up to 50% and the GC time down by a few percentage points (11.3% to 8.7% of total processing time).

ActiveRecord

  • use the :include option to prefetch associations, it avoids extra onesy-twosy SQL statements.
  • use piggy-backing plugin for has_one or belongs_to relationships -- allows you to retrieve extra attributes from additional tables in the same fetch query.
  • Field values are retrieved from the DB mostly as strings, so type conversion happens on each access, which can be slow.

Language-level and miscellaneous issues

  • Method calls are the slowest -- don’t needlessly create method abstractions
  • Short-circuit intermediate results to improve performance
  • Cache results in instance variables or class variables
  • Don’t call ObjectSpace.each_object on each request

Ruby Memory Management

  • designed for batch scripts, not long-running servers.
  • no generational garbage collection.
  • this is suboptimal for Rails because ASTs are stored on the heap (biggest portion of non-garbage for Rails apps), and get processed/traversed more often than they need to be
  • Railsbench includes a patch to allow one to recompile Ruby and tweak the garbage collector.

Rails Template Optimizer

  • Stefan has started a project to “compile” templates.
  • The idea is to cache results of some ERb scriptlets and essentially “compile” or replace the template with one that has more expressions expanded or inlined.
  • Code forthcoming; I assume you can stay tuned to Rails Express for news.

Questions

  • There was a question on JRuby -- Stefan replied that it would certainly solve GC issues, but he doesn’t know if it’s in a state to be able to benchmark Rails requests.
  • What are your recommendations for a web server. I don’t have any.
  • Is horizontal or vertical scaling better? I don’t know, I’ve been focused on making single requests go fast, so I don’t have enough experience.

Posted in ,  | Tags  | 3 comments | no trackbacks

RailsConf: Mike Clark -- Introduction to Capistrano

Posted by Nick Sieger Fri, 23 Jun 2006 16:45:00 GMT

Introduction to Capistrano

Mike Clark has been Java-free for 15 months and 16 days. He’s here to talk about deployment with Capistrano.

First off, props to Jamis! There are several hundred people in the room and it’s a tribute to him.

Capistrano is about making it easy to deploy web applications. “Cap”, the short name has quickly become jargon in the Rails community. “Stop wasting time, just cap it!”

Capistrano is built to scale. From a single machine all the way up to clusters, it is intended to make application deployment as simple as the push of a button. That’s priceless for reducing friction as your project nears its first production live date, as well as subsequent maintenance releases.

Configuring Capistrano - create a recipe

Set the application name

set :application, "depot"

Set the repository

set :repository, "http://svn.yourhost.com/#{application}/trunk"

Roles

role :app, "app01.example.com", "app02.example.com"
role :web, "web01.example.com", "web02.example.com"
role :db, "db.example.com", :primary => true

Deployment Root

set :deploy_to, "/Library/Rails/#{application}"

Setup

Run cap setup once to setup the deployment directory structure on all the roles you’ve configured:

depot
  `- releases
  `- shared
       `- log
       `- system

First time deploy

Run cap update_code symlink. This checks out the code, adds a “current” symlink to the code on the remote machine that points to the timestamped releases directory where the code was checked out. You can then manually start your web server(s) if you wish.

New Release

Run cap deploy. The newly committed code to your repository gets pulled, a new release created, and it also restarts fcgi processes.

Rollback release

Run cap rollback. The “current” symlink gets updated to the previous release, and the fcgi processes get restarted.

Scheduled downtime

Run cap disable_web. A maintenance screen is put up during the maintenance period. This is great when you’re in firefighting mode and you don’t want to think, just get the page up there. To enable again, use cap enable_web.

Customization

Here are examples of several useful, real-world tasks. The fourth task shows aggregation of tasks together.

desc "locate ruby"
task :which_ruby, :roles => [:app] do
  puts "You're running:"
  run "which ruby"
end

task :current_revision do
  run "echo Current rev is #{revision}"
  run "echo Current rev is at #{releast_path}"
end

task :uptime, :roles => [:app, :web, :db] do
  run "uptime"
end

task :status do 
  which_ruby
  current_revision
  uptime
end

Channels and streams

Mike showed a log file tailing task here. I failed to capture the full task code, so you’re on your own here.

Hooks

task :before_deploy, :roles => [:app] do
  cleanup
end

task :after_update_code, :roles => [:app] do
  production_config = "path/to/database.yml"
  run "cp #{production_config} #{current_path}/config/database.yml"
end

Multiple configs

if where == "production"
  set :user, "ops_gal"
else
  set :user, "dev_guy"
end

Task libraries

You can creat a file full of extra, reusable tasks and simply require them in. The files can be published and installed as gems or placed anywhere on your load path.

Capistrano isn’t just for Rails

It’s great at shuttling files around and executing remote commands on the server. Mike describes some automation James Duncan Davidson did to replicate new servers into a cluster with the push of a button.

Assumptions

Capistrano, out of the box comes with some assumptions:

  • Remote servers talk POSIX
  • Same deploy structure and password on each machine
  • Web application uses FastCGI with Apache or Lighty

It looks like you can bend some of these assumptions if you are willing to write your own custom deployment tasks.

Take Home

Capistrano provides easy, consistent, worry-free deployment of new releases. The friction to deploying your app just got simpler, so you can go enjoy your life!

Notes and Questions

  • Can you use SSH public keys to authenticate? Yes, this is the most typical scenario.
  • You can use sudo to execute remote commands -- this is built-in.
  • Can you/would you want to check out subsets of files on each server, rather than pulling all the code everywhere? So far most of our stuff has been on the same server, so this hasn’t been an issue. It seems like you would need to override deployment tasks for some roles.
  • Sometimes I want to deploy a lot, but what if the app is big, lots of media files? It can take a longer time to pull all the code. One solution I’ve seen is to check out once and rsync everywhere else. I haven’t had to do that myself.
  • Who can I talk to for promoting my own extensions into Capistrano. You probably don’t. Instead, publish your extensions, blog them, and see if it takes.
  • deploy_with_migrations -- use with caution as it’s not as easy to rollback, and not all migrations can be rolled back cleanly.

Posted in ,  | Tags  | no comments | no trackbacks

RailsConf: Dave Thomas keynote

Posted by Nick Sieger Fri, 23 Jun 2006 15:12:00 GMT

Dave Thomas, Professional Cassandra

Intro

Dave starts by dissecting a google search and pointing out how the sponsored links sidebar contains a wealth of paid ads for various topics:

  • Hosting
  • Consulting
  • Commercial IDEs and tools
  • Alternatives to RoR!

Moving on to rubyforge, Dave examines some download stats, and points out that there have been 536835 downloads of Rails through gem install rails

Dave examines some Google trends mapping of ruby on rails vs the following, showing RoR catching up on some and overtaking others:

  • websphere
  • jboss
  • tapestry
  • spring framework
  • zend

3 Problems for Rails

Dave proceeds to give his own, tailored for Rails, version of David Hilbert’s famous “23 unsolved problems”...except due to time constraints, can only discuss three.

PDI

An acronym, PDI, has emerged on the Rails core team as a way to encourage people to contribute. Please Do Investigate

The challenge is to get new features to be proved out in the community before taking it into the core, the Rails core team is only 12 and has limited bandwidth, and that is the idea behind PDI

The three problem areas are:

  • Data integration
  • CRUD
  • Deployment

Data integrations

Dave mentions that he and David “disagree mildly” on the point of using constraints in the database.

  • automatic validation based on schema
  • work with foreign keys - make it easy to define in a migration
  • add a “belongs_to” relationship if a foreign key constraint is detected
  • primary key support, e.g., non-integer keys, particularly in migrations, and composite primary keys

The argument here is that real-world applications, and legacy databases today require these features, and Rails needs to be able to have answers to those questions if it wants to be viable in that area.

Dave is asking for distributed transactions now. Should we be pushing Rails into such an enterprisey direction? If you really need XA transactions, shouldn’t you be banished to a java world?

Non-database models would be a fabulous addition to rails. ActiveRecord::Base currently assumes that it’s talking to a sinle relational datastore. If we could integrate multiple disparate data soures, it would make integrations, REST data sources, and mashups much easier. Microsoft is doing this with LINQ today, and if Rails wants to keep up, it will need this.

Real-world CRUD

Dave is arguing that we should beef up scaffolding and make it useful. Scaffolding was the star of the initial 10 minute Rails video that started everything, but yet it’s the ugliest web 1.0 interface ever! No AJAX, no automatic, DRY, in-browser validation. But should we, can we really genericize these interfaces? Maybe a scaffolding widget/component system? It can and probably will happen, but at the momet I’m inclined to think that this will complicate things. Do we want Rails view to turn into Wicket widgets or ASP.NET components? It’s a completely different way of writing web programs. We’ll have to see how it plays out.

Deployment

Dave argues for improved deployment. Yes we have Capistrano, and it’s arguably the best web deployment mechanism in existence, but the web of knowledge required to deploy a Rails application is too large, varied and unwieldy.

Capistrano is a push model, ideal for small shops where the developers manage and maintain everything, but it’s not the real world. Larger shops have separate development and admin departments. They have stricter requirements for where files go, pre and post-deployment hooks, roles, passwords, security, etc. Capistrano currently falls down a bit in this environment.

Dave discusses cap --deploy-on: a hypothetical extension to Capistrano that would allow staged deployment to multiple servers, and the possibility to introduce workflow between developers and administrators. What if ISPs had a standardized infrastructure that would allow hobbyists to issue a cap --deploy-on and instantly have their apps running up on TextDrive, DreamHost, etc. To go further, what if we could deploy from rubygems? gem deploy <name> --on cap://my.isp.com. Typo installation would literally be a single command.

Closing

All developers need to be happy, so let’s make their lives easier!

Posted in ,  | Tags  | no comments | no trackbacks

RailsConf begins

Posted by Nick Sieger Fri, 23 Jun 2006 14:10:00 GMT

I got lucky with a last minute ticket and found a way to get to the First International Rails Conference in Chicago.

Railsconf attendee Nick on Facebook

That’s me, hope to see you this weekend!

Posted in ,  | Tags  | no comments | no trackbacks

QOTD

Posted by Nick Sieger Tue, 06 Jun 2006 15:03:00 GMT

Spotted the following thread on ruby-talk:

Pat Maddox: I hate when languages put a condom on my code.
Gennady Bystritsky: What does it make your code, then? ;-)
Mat Schaffer: Pregnant!

Posted in ,  | Tags  | no comments | no trackbacks

Older posts: 1 2 3 4