"ruby" via neolao in Google Reader

Rails 2.3.3: Touching, faster JSON, bug fixes

2009-07-20T17:28:00Z

We’ve released Ruby on Rails version 2.3.3. This release fixes a lot of bugs and introduces a handful of new features.

Active Record

touch is a convenient method to update a record’s timestamp and nothing else. This is extracted from apps whose models “touch” others when they change, such as a comment updating the parent.replies_changed_at timestamp after save and destroy. Timestamping an entire has_many association makes it easy to build a key for fragment caching that covers changes to the parent object and any of its children. This pattern is wrapped up as belongs_to :parent, :touch => :replies_changed_at. When the child changes, parent.replies_changed_at is touched. :touch => true is defaults to :touch => :updated_at.
:primary_key option for belongs_to for broader support of legacy schemas and those using a separate UUID primary key: belongs_to :employee, :primary_key => 'SSN', :foreign_key => 'EMPID' changeset

JSON

decoding backends for the json and yajl libraries. Both are significantly faster than the default YAML backend. To get started, install the json gem and set ActiveSupport::JSON.backend = 'JSONGem'.
leaner user-facing encoding API. Since a JSON libraries implement to_json with varying compatibility, safely overriding it is difficult. Most custom to_json looks like
```
def to_json(*encoder_specific_args)
  { :some => "json representation" }.to_json(*encoder_specific_args)
end
```
so we DRYed the user-facing API down to a more natural
```
def as_json(options = {})
  { :some => "json representation" }
end
```
without the ugly internal state exposed by overloading to_json as both public-facing and internal builder API. Rails 3 splits the API explicitly, so prepare now by switching from to_json to as_json.

Other Features

Add :concat option to asset tag helpers to force concatenation. changeset
Restore backwards compatibility for AR::Base#to_xml. changeset
Move from BlueCloth to Markdown for the markdown helper. Users using BlueCloth to provide their markdown functionality should upgrade to version 1.0.1 or 2.0.5 in order to restore compatibility.

Notable Bug Fixes

Fix errors caused by class-reloading with streaming responses in development mode.
Several fixes to the gem bundling, unpacking and installing system.
Make text_area_tag escape contents by default.
Make filter_parameters work correctly with array parameters.
Thread-safety fixes for postgresql string quoting.
Performance fixes for large response bodies.

Engine Yard assurera le maintien de Ruby 1.8.6

2009-05-23T21:52:04Z

Après un petit délai de mise en route interne, l'équipe de développement de Ruby a officiellement annoncé que le maintien de la branche 1.8.6 ne serait plus assurée par Urabe Shyouhei, mais par Kirk Haines, d'Engine Yard.

Cette branche a été lancée en 2007. Depuis lors, l'équipe de ruby-core a fourni du support, notamment par le traitement des bugs rapportés et par la communication d'alertes de sécurité. Ruby 1.8.6 a été un succès, si bien que ses utilisateurs ont manifesté le souhait que ce support perdure, au-delà des dates prévues en interne. Avec un accord de principe, restait à savoir qui allait s'en occuper. Engine Yard s'est proposée et il a été décidé de leur transférer les accès appropriés.

Du point de vue des utilisateurs, cette annonce officielle n'introduit aucun changement… si ce n'est que les fix et les mises-à-jour devraient sortir à un rythme un peu plus rapide.

Sortie de Ruby 1.8.7-p160 et 1.8.6-p368

2009-05-02T10:36:06Z

Des mises à jour aux releases Ruby 1.8.7 et 1.8.6 sont disponibles.

Plusieurs douzaines de bugs résolus, notamment pour CVE-2007-1558 et CVE-2008-1447, ainsi que des segfaults. Plus de détails dans les changelogs.

Les archives :

Checksums :

MD5(ruby-1.8.6-p368.tar.gz)= 508bf1911173ac43e4e6c31d9dc36b8f
SHA256(ruby-1.8.6-p368.tar.gz)= cc8cad3edd02d8c2de3c63a7d8a5cb85af39766dd47360a9c0f26339b101e2a0
SIZE(ruby-1.8.6-p368.tar.gz)= 4602095

MD5(ruby-1.8.6-p368.tar.bz2)= 623447c6d8c973193aae565a5538ccfc
SHA256(ruby-1.8.6-p368.tar.bz2)= 1bd398a125040261f8e9e74289277c82063aae174ada9f300d2bea0a42ccdcc1
SIZE(ruby-1.8.6-p368.tar.bz2)= 3967709

MD5(ruby-1.8.6-p368.zip)= 3d301a4b1aded1922570585bbece2c29
SHA256(ruby-1.8.6-p368.zip)= 8ba4bfd14d2914bfe2c18ffa9da084234be978fd0eee654f7a5c732a1beb0246
SIZE(ruby-1.8.6-p368.zip)= 5619494

MD5(ruby-1.8.7-p160.tar.gz)= 945398f97e2de6dd8ab6df68d10bb1a1
SHA256(ruby-1.8.7-p160.tar.gz)= 47c3d1ae6b3dbda230d04f258304516fc1da571fa757d5e1d8d0104b49045530
SIZE(ruby-1.8.7-p160.tar.gz)= 4818817

MD5(ruby-1.8.7-p160.tar.bz2)= f8ddb886b8a81cf005f53e9a9541091d
SHA256(ruby-1.8.7-p160.tar.bz2)= e524a086212d2142c03eb6b82cd602adcac9dcf8bf60049e89aa4ca69864984d
SIZE(ruby-1.8.7-p160.tar.bz2)= 4137518

MD5(ruby-1.8.7-p160.zip)= 06319bafa225df47fe26dfb52bc174a7
SHA256(ruby-1.8.7-p160.zip)= c56fefbb9e7e186bf9feeb864793ad2a53062ce871b47ab0170316e38f738995
SIZE(ruby-1.8.7-p160.zip)= 5876269

Les changelogs sont compris dans ces archives, ou disponibles directement via :

Getting Started With Ruby On Rails

2009-03-20T02:47:35Z

If you’re a Web developer who’s been curious about Ruby on Rails but has never gotten around to trying it out because you couldn’t find a suitable overview of its advantages, then this article is for you.

We want to bring Ruby on Rails closer to those who want to take a peek first, without going through an entire tutorial. So, this article is structured a little different from most other introductions out there; hopefully it is more useful because of this.

I assume you’re already familiar with some other form of Web development, whether PHP, Python, Perl or Java, and relational databases like MySQL. First, we’ll introduce Rails and Ruby and the basic ideas behind both. I’ll teach you just enough Ruby so that you understand the code samples. I’ll tell you how to get Ruby on Rails running on your computer, and I’ll give you an overview of the basic functionality of Rails and demonstrate how Rails’ main parts work together.

This tutorial consists of two articles: in the current, first article we get started with some basic concepts and essential components of Ruby on Rails. In the second part (it will be published next week) you will learn how to install the engine; you’ll also take a closer look at Rails’ inner workings and discover main advantages of Ruby on Rails. Please stay tuned.

After reading these parts, you should have an idea of whether Rails is for you. If you get the feeling that it is, I’ll point you to some good tutorials on the Web that you can use to learn Rails. I’ll also provide a lot of further reading recommendations so you can dig as deep into the topic as you like.

I’m taking this approach because Rails is almost 5 years old now and has become very complex. There are a lot of “Create-your-own-blog-in-5-minutes”-type tutorials out there already, and rather than adding another one, I wanted to provide this kind of rough overview to help you decide whether to take this adventure.

You may want to take a look at the following related posts:

10 Useful Tips For Ruby On Rails Developers

The Idea Behind Rails

Ruby on Rails was created by David Heinemeier Hansson as a kind of byproduct of Basecamp’s development at 37signals in 2004. Basecamp was built in Ruby because Hansson found PHP and Java not powerful or flexible enough. It was quite an obscure language back then, without the large eco-system available today. To make development easier, Hansson rolled his own Web development framework, based on simple ideas that had proven successful elsewhere. Rails is founded on pragmatism and established paradigms instead of exotic new ideas. And that’s what made it so successful.

Rails is based on the Model-View-Controller pattern that splits your application into three parts:

The Models are your business objects describing the structure and behavior of the problem your application is trying to solve. These are usually backed by an Object-Relational-Mapping framework that persists your objects to a database in the background.
The Views are the templates that render data to the user and all the logic surrounding presentational aspects of your app.
The Controller sits at the heart of everything, processing requests from clients, initiating changes in the models and triggering the rendering of the templates.

Rails is “opinionated software.” It doesn’t want to be everything for everyone. It focuses on one way of doing things and streamlines all its parts around that way. That’s not to say there’s no possibility of doing things differently if you need to, but you’ll definitely have it easier if you do things “the Rails way.” And that way happened to be exactly the right one not only for Hansson but for a lot of other developers, too, another important reason for Rails’ success.

Programmer productivity was the main goal during Rails’ development, not performance. This has led to a lot of controversy and claims that arise over and over about how Rails can’t scale. This is Rails’ own fault to a certain degree. In its early days, it had the image of a Web development framework messiah of hope and wonder that would lead us all to the promised land were applications wrote themselves. The Rails team didn’t do enough to keep expectations more realistic, and some people became disappointed.

While it’s true that Ruby on Rails is slower than comparable stacks on PHP or Python, it certainly does scale, as hundreds of successful deployments are proving. You’ll just need to scale sooner and put some thought into it. Remember also that Ruby’s current default implementation is terribly inefficient, but alternatives are on the way. There’s nothing inherently slow about the language, though, as blazing-fast implementations of Smalltalk (a language very similar to Ruby) prove. Ruby will only get faster. As the saying goes, you don’t have a performance problem until you have a performance problem, and all this talk should not scare you yet. You haven’t even started. ;)

Now, before I introduce you to the framework, let’s get started with Ruby.

A Gem From Japan

Ruby on Rails owes not only half its name but its entire feel and flexibility to “Ruby,” that neat little language from Japan.

Ruby came out in 1995 and was developed by Yukihiro Matsumoto, or “Matz” as he’s called in the community. Version 1.0 was released in 1999 and slowly gained recognition in the west from then on.

A key point in the spread of Ruby was the release of “Programming Ruby,” also called the “Pickaxe” (a reference to its cover illustration), by the Pragmatic Programmers. “Programming Ruby” was the first comprehensive English guide to the language and API.

Ruby was designed with simple principles in mind. Matz took the most successful and powerful elements from his favorite programming languages — Perl, Smalltak and Lisp — and combined them into one language with easy syntax. One goal was to make Ruby feel “natural, not simple” and to create a language “that was more powerful than Perl, and more object-oriented than Python.” This results in Ruby’s core principle: Everything is an object.

Objects

Let’s stop here and examine this. Really, everything is an object in Ruby. True and false are objects, literals are objects, classes are objects. You can call a method on a numeric literal:

>> 5.next
=> 6

Operators in Ruby are nothing but methods:

>> 5 * 10
=> 50
>> 5.*(10)  # times-operator called as a method (dot-notation)
=> 50       # with a parameter (in parentheses)

Ruby is extremely flexible and open. Almost everything about it can be changed or manipulated at runtime:

You can add and remove methods and variables to and from objects.
You can add and remove methods and variables to and from classes.
You can truly manipulate any class this way, even core classes like String and Integer!

Here’s an example:

>> "hi".repeat(4)
NoMethodError: undefined method `repeat' for "hi":String
>> class String     # Open the string class and add the method
>>   def repeat(i)
>>     self * i
>>   end
>> end
=> nil
>> "hi".repeat(4)   # Call it again on a fresh String literal
=> "hihihihi"       # And there it is!

Here, I defined the method repeat on the String core class, and it was immediately available on a string literal.

And he who giveth, taketh away:

>> class String             # Open up the method again
>>   undef_method :repeat   # And remove the method
>> end
=> String
>> "hi".repeat(4)           # Try to call it
NoMethodError: undefined method `repeat' for "hi":String

I could have also done this with predefined methods. They are no more “special” than the methods we have defined.

Let’s review the definition of repeat in the above example for some more interesting tidbits. Note that we’re not saying return anywhere in the body. That is because in Ruby, methods always implicitly return the value of their last expression. You could of course always jump out of a method by using return before reaching the last statement, but you don’t have to. The expression we’re returning is self * i. Self is equal to this in Java and $this in PHP and always refers to the current object. The times-operator on a string repeats the string as often as told by the second operand/parameter, i in this case.

Loops

You rarely see manual iterations in Ruby, like for or while loops. Instead, Collections come with their own iterators that you can pass blocks to, which are executed for every element in the collection:

a = "Hey "
[1, 2, 3].each do |num|
    puts a * num
end

# Outputs:
# Hey
# Hey Hey
# Hey Hey Hey

What you see here is an array literal containing numbers. On that array, the each method is called, an iterator that takes a block and calls the block for every element in the array. The block starts with the do, followed by a list of its parameters enclosed in pipe symbols. Here we have one parameter called num that will take on the value of the array element in each iteration. Inside the block, we’re simply outputting the result of a * num. The definition of * on Strings is to repeat the string accordingly. We could have put the String inside the Block, but I wanted to demonstrate that blocks have access to their surrounding scope.

Syntax

Ruby likes to keep the syntax clean and friendly. You can see this in the above examples. Although heavily influenced by Perl, Ruby doesn’t have Perl’s excessive use of special characters. You can use semicolons to end lines, but you don’t have to (and no Ruby programmer does). You don’t need to surround method parameters with braces in unambiguous situations (although it is recommended you do so if they enhance readability), and you especially don’t need to provide empty braces around an empty parameter list. That’s what makes accessors look so much like native properties.

Blocks are framed by do and end. You should only use equivalent curly braces if your blocks don’t span several lines. The only significant use of special characters is found at variable declaration. Variables in Ruby are prefixed with special characters to indicate their scope. Variables starting with a lowercase letter are local variables. Variables starting with an uppercase letter are constants. (This means that all classes are constants, too, since classes start with uppercase letters.) Instance variables start with an @. Class variables that are shared among all instances of a class start with @@. Finally, global variables all start with a $.

You’ll often find methods ending in ? or !. These are not special characters. It is merely conventional in Ruby to use question marks for methods that query an object for a Boolean condition, like Array#empty?, or exclamation marks for methods that are destructible:

>> a = [5, 1, 9, 2, 7]   # Create an array and store it in a
=> [5, 1, 9, 2, 7]
>> a.sort                # sort merely returns a new, sorted array
=> [1, 2, 5, 7, 9]
>> a
=> [5, 1, 9, 2, 7]       # a still is in its original order
>> a.sort!               # sort! instead sorts the original array
=> [1, 2, 5, 7, 9]
>> a
=> [1, 2, 5, 7, 9]       # a was changed

Conditionals

Conditionals in Ruby are very similar to other programming languages, with two notable exceptions. First, it’s possible to put a conditional after the statement it protects to make the code more readable:

execute_dangerous_operation() if user.is_authorized?

# is equal to

if user.is_authorized?
  execute_dangerous_operation()
end

Secondly, Ruby has not only an if but an unless. This is a syntactic nicety for when you want to check for the absence of a condition in a more readable manner:

unless user.is_admin?
  user.delete
else
  raise "Can't delete admins"
end

Symbols

Sometimes you’ll see names starting with a : (colon). These are a very special feature of Ruby called symbols. Symbols can be used to index hashes or mark states in a variable like you would with an ENUM in C. They are very similar to Strings but also very different. The point about symbols is that they don’t really occupy space in memory, and the same symbol literal always resolves to the exact same symbol:

>> "a".object_id  # object_id returns Ruby's internal identifier for an object
=> 3477510
>> "a".object_id
=> 3475550        # a new object on the heap
>> :a.object_id
=> 184178
>> :a.object_id
=> 184178         # the same literal refers to the exact same Symbol object

You’ll find them very often as parameters to methods, where they indicate how a method should work,

User.find(:all)   #find all users
User.find(:first) #find the first user

or as pointers to methods and variables (see the undef_method example in the “Objects” paragraph above).

Classes and Modules

Ruby supports single inheritance only, but for added flexibility it supports a feature called Mixins. In Ruby, it’s possible to define Modules that contain Methods and constants and to include these modules in a class via the include method. This way, you can extend the functionality of a class very easily.

Many of Ruby’s core classes even use this mechanism.Array and Hash, for example, both include the Enumerable module to provide a lot of convenience methods for iterating over their contents.

Often, Modules pose certain requirements to classes that include them. The Enumerable Module, for example, requires classes to provide at least an each method and an implementation of <=>, too, if its sorting features are to be used.

Modules also serve other purposes. Most importantly, they can be used to organize code into namespaces. Because classes are constants (which means you can’t assign another class to the same name), they can be stored in modules. These modules can then be nested to form namespaces.

These paragraphs probably won’t enable you to write Ruby programs, but you should be able to understand the code samples in this article now. If you want to explore Ruby a little, try the great interactive tutorial at Try Ruby, or take a peek at one of the books listed at the end of this article. If you just want to see some more code samples, check out the Wikipedia page on Ruby.

In the second part of this tutorial we will get rolling with Ruby on Rails, install the engine, take a closer look at Rails’ inner workings and discover main advantages of Ruby on Rails. Please stay tuned.

You may want to take a look at the following related posts:

10 Useful Tips For Ruby On Rails Developers

About the Author

Jan Varwig is a programming language enthusiast, currently writing his CS diploma thesis about server-side JavaScript, and a software developer with 10 years of experience working for 9elements and as an independent freelancer. His blog and CV can be found at jan.varwig.org.

(al)

Update on Rails Guides and Documentation

2009-03-11T18:57:00Z

We have been working on the Rails guides for some months now. With substantial contributions from a variety of authors, things are looking even better in the next version of the guides. That makes this the right time to take the overall documentation efforts to the next level.

Announcing the Documentation Team
We’re very happy to announce a formal documentation team – consisting of Xavier Noria, Mike Gunderloy and myself. However, eventually Mike and I will be just acting as advisors to the documentation team. So we’re definitely looking to empower some new faces here. If you’ve been working on improving the documentation and guides, keep up the good work and you’ll be on the team soon enough!

The documentation team will be to responsible for keeping the guides and API documentation up-to-date, working to improve the Rails documentation, and also helping more people contribute to the documentation efforts.

Documentation Mailing List and IRC
As part of the renewed documentation effort, we’re launching a mailing list. So go ahead and subscribe to rubyonrails-docs. The mailing list will be the main point of communication with the documentation team. If you have any suggestions or need any help, please post it to the mailing list. For quick questions, you can also find some of the team in the #docrails room on IRC most hours of the day.

How to Contribute
If you’re new to the Rails documentation process (or want to get involved for the first time!), you might want to have a look at the Contributing to the Rails Documentation section of the Contributing to Rails guide.

Rails Magazine #1 is Out

2009-03-10T14:01:00Z

One of the measures of the health of a development platform is its ability to support a vibrant ecosystem of users, contributors, speakers, and authors. By this measure, Rails remains in excellent shape. The latest evidence: the release of the first issue of Rails Magazine – 36 pages of full-color glossy print.

The first issue includes 9 articles covering everything from delegation in Ruby to using Saasy for subscription-based applications to performance analysis and getting started with JRuby. The full content will be available on the web shortly, but if you’d like to support this effort (and help ensure that it doesn’t go away) you can order a paper copy for $8 in the US, UK, or Canada.

10 Useful Tips For Ruby On Rails Developers

2009-02-25T20:21:21Z

By Greg Borenstein and Michael ‘MJFreshyFresh’ Jones

Rails is an model-view-controller Web framework written in the Ruby programming language. One of its great appeals is being able to quickly crank out CRUD-based Web applications. A big advantage of Rails over other frameworks is that it values convention over configuration. If you follow the correct conventions, you can avoid lengthy configuration of files, and things just work! Therefore, you spend less time writing boring config files and more time focusing on business logic.

Now, we love Rails. But don’t get us wrong. Like any tool, it’s not the perfect solution to every problem. A lot of the biggest complaints people have about the framework come from using it in situations where something simpler, smaller and more lightweight would do just fine. We love Sinatra for anything with minimal server-side involvement. Merb is another excellent minimal framework. And nothing beats apps that run completely in the browser with JavaScript: they can be deployed nearly for free, can scale almost infinitely and never have to be restarted.

In the overview below we present 10 useful tips, ideas and resources for Ruby on Rails-developers (both newbies and professionals). Please feel free to share your tips, ideas and suggestions in the comments to this post!

1. Plug-Ins Save Time

Rails has a well defined plug-in structure that enables you to easily install and use plug-ins in your application. David Heinemeier Hansson, the father of Rails, once stated that he uses five to six plug-ins in each Rails application.

There’s an old nugget of developer wisdom that “the best code is no code at all.” Part of what makes us so productive when developing in Rails is that all the code that we don’t have to write because someone else in the community has already written a plug-in that provides the functionality we need.

There are a few ways to install a plug-in in Rails, however the most common is using script:

# Install from a git repo
script/plugin install git://github.com/mislav/will_paginate.git

# Install from a url
script/plugin install http://topfunky.net/svn/plugins/calendar_helper

You can save yourself a ton of time and hassle by becoming good at searching the Web (and especially the almighty GitHub). A couple of places to find plug-ins are Core Rails, Railsify and Rails Plug-in Directory. Need to integrate with an existing API or consume some kind of standard format data? Need tagging, pagination, or another common Web application feature? Odds are that some great Rails or Ruby developer out there already has a project going that will get you at least most of the way there.

2. Testing is Fun and Easy with Rspec

For most people, the word “test” brings back scary memories of school exams. When working with Rails, however, automated testing can make your development experience much more enjoyable. While lots of people have strong, nearly religious, opinions about them, at their core, automated tests are just little helper programs you write that run bits of your main code to make sure they do the right thing. When done right, testing will improve your workflow and increase your confidence in the results.

Rails ships with a test framework baked right in, but for the last couple of years all the cool kids have been using an alternative called Rspec. Rspec’s biggest advantage is its syntax for specifying tests:

describe "My Cool library" do
  before do
    @cool = Cool.new
  end

  it "should be full of penguins." do
    @cool.get_penguins!
    @cool.penguin_count.should == 10
  end

  it "should melt if it gets too warm"
end

What’s great about Rspec’s syntax is how much English it uses. The describe block that sets the context and each assertion within it takes strings that you use to explain what your code should do. Often, this is the most important stage: you sit down to write the assertion, getting as far as you can, and then you think, “Right, what should this code actually do then?”

Because Rspec lets you leave off the block that implements the assertion (as in the second melt example), you can quickly brainstorm all of your functionality, and then go back and implement the tests later as you write the code. In the meantime, Rspec will consider those tests as “pending” and give you little reminders about them in your test runs.

Besides helping you write code in the first place, another great thing about tests is that, once you have enough of them, they let you see how all of your code is related, making it easy to know if your recent change broke anything else in your application. Rspec makes it easy to get good test coverage through the use of custom generators that create the tests right along with the rest of your code:

$ script/generate rpsec_scaffold MyModel

Once you’ve got tests to ensure that the basic functionality works successfully, you can make changes and add new code with confidence without worrying about introducing invisible bugs. As long as you run your tests regularly, you’ll know as soon as you break something. And as GI Joe taught us, knowing is half the battle!

3. Save Time, Use Rake

Projects often include more than just application-specific code. Sample data have to be created, Web services have to be queried, files have to be moved, code snippets rewritten, etc. Resist the urge to shell script or to cram in a migration or controller. Use Rake. It rocks!

Rake is a build tool written in Ruby, very similar to make. Rails projects have several Rake tasks already defined; to see these, run the rake -T command.

macbook$ rake -T

rake data:bootstrap		# load in some basic data [caution: will nuke and replcace cate...
rake db:create:all		# Create all the local databases defined in config/database.yml
rake db:drop			# Drops the database for the current RAILS_ENV
...
rake ts:run				# Stop if running, then start a Sphinx searchd daemon using Thi...
rake ts:start			# Start a Sphinx searchd daemon using Thinking Sphinx's settings
rake ts:stop			# Stop Sphinx using Thinking Sphinx's settings

Adding your own Rake tasks is quite easy. In the example below, you see that the task is name-spaced and has a description and task name, allowing you to write in Ruby.

namespace :data do
  desc "load in some basic data [caution: will nuke and replcace categories, categorizations and inventory items]"
  task :bootstrap => :environment do
    # clean out existing:
    [Category, Categorization, InventoryItem].each{|m| m.find(:all).each{|i| i.destroy}}
    InventoryItem.create! :name => "Compass"
    c = Category.create! :name => "Basic Apparel"

    ["Men’s Heavyweight Cotton T",
    "Men’s Heavyweight Polo",
    "Women’s Organic Cotton Fitted T",
    "Women’s Fitted Polo",
    "Children’s T-Shirt",
    "Jr’s Distressed Hoodie",
    "Hemp Messenger Bag"].each do |name|
      c.inventory_items.create! :name => name
    end

   ...

end

4. Track Application Exceptions

Exceptions happen, and when they do, you want to know about them! Your client shouldn’t be the one telling you that a problem has occurred; you should already be aware of the issue and working to resolve it. Exception notification has been available in Rails for a while. There are exception notification plug-ins that make it easy to be notified. However, some services such as Hop Toad and Get Exceptional add a lot of value to your application.

Both of these services are easy to install and provide a great UI for tracking your exceptions. You can even sign up for a free account to try things out.

By centralizing the application exceptions, you are able to see how frequently these exceptions occur, what environment they occur in (a particular browser? a particular location?), what parameters were present and the full stack trace. This centralization of data helps you see patterns and resolve the issue more quickly, which results in a better application and happier users.

5. Mix and match between frameworks and servers with Rails on Rack

As of version 2.3, Rails runs on top of Rack. Rack makes it possible to mix and match between Ruby Web frameworks and servers. If you’re using a framework that supports it (like Rails, Sinatra, Camping, etc), you can choose from any of the servers that do also (Mongrel, Thin, Phusion Passenger, etc.), and vice versa.

In addition to introducing all kinds of new options for deployment, this change means that Rails now has access to the exciting world of Rack middleware. Because Rack lives at the intersection of your app and your server, it can provide all kinds of common functionality directly. A great example of this is Rack::Cache.

Rack::Cache provides a caching layer for your application that you control simply by sending the correct headers in your responses. In other words, all you have to do is install a bit of code in the Rack config file:

require 'rack/cache'

use Rack::Cache,
  :metastore => 'file:/tmp/rack_meta_dir',
  :entitystore => 'file:/tmp/rack_body_dir',
  :verbose => true

And make sure your controller actions send the right headers (for example, by setting request.headers["Cache-Control"]) and Bam!, you’ve got caching.

6. Easy Data Dumping

You’ll often need to get data from production to dev or dev to your local or your local to another developer’s local. One plug-in we use over and over is Yaml_db. This nifty little plug-in enables you to dump or load data by issuing a Rake command. The data is persisted in a yaml file located in db/data.yml. This is very portable and easy to read if you need to examine the data.

rake db:data:dump

example data found in db/data.yml

---
campaigns:
  columns:
  - id
  - client_id
  - name
  - created_at
  - updated_at
  - token
  records:
  - - "1"
    - "1"
    - First push
    - 2008-11-03 18:23:53
    - 2008-11-03 18:23:53
    - 3f2523f6a665
  - - "2"
    - "2"
    - First push
    - 2008-11-03 18:26:57
    - 2008-11-03 18:26:57
    - 9ee8bc427d94

7. Keep Your Constants in One Place

All applications have constants, variables that are defined with data that don’t change, such as the name of the application, the tagline, values for crucial options, etc. We use the Rails initializer feature to define a config/initializers/site_config.rb for housing these constants. By using this convention, all developers on a project know exactly where to look for the constants and can quickly make changes.

Many people have questions about when to put a constant in the site_config.rb instead of the class it is used in. For a constant that are only used in a single class, we suggest putting it in that class. However, if the constant is used in more than one location, put it in the site_config.rb. For more on constants, have a look at Rubylearning.

# File config/initializers/site_config.rb

REPORT_RECIPIENT = 'jenn@scg.com'
REPORT_ADMIN = 'michael@scg.com'

8. Console for Working on Code

Sometimes you may have code that you’re curious about. Will it work this way? What’s the output? What can I change? Rails ships with a wonderful tool called console. By running script/console you will enter an interactive environment where you can access your Rails code just as though the application were running.

This environment is incredibly helpful. It is often used in production environments at times to quickly peek at data without having to log in to the database. To do this in a production environment, use script/console RAILS_ENV=production:

macbook$ ./script/console
Loading development environment (Rails 2.1.1)
>> a = Album.find(:first)
=> #
>>

9. Ugly Views Getting You Down? Try Haml.

Views are how your Rails application generates the HTML pages your visitors actually see and use. By default, Rails uses the ERb templating system to let you embed bits of Ruby in your markup so that you can insert your data as needed. However, recent versions of Rails let you take your pick of templating languages, and nowadays the Ruby interwebs have been all abuzz about an alternative system called Haml.

Haml is marketed as “markup Haiku.” Its CSS-inspired syntax lets you focus on the semantics of your data rather than worrying about closing all the angle brackets that come with using ERb and HTML.

For comparison, here’s a bit of markup in standard ERb:

<%= print_date %>
<%= current_user.address %>

<%= current_user.email %>
<%= h current_user.bio %>

And here’s the equivalent in Haml:

#profile
  .left.column
    #date= print_date
    #address= current_user.address
  .right_column
    #email= current_user.email
    #bio= h(current_user.bio)

Haml’s not for everyone, and many people will find this syntax quite alien. But if you value concision and are fluent in CSS, Haml may be just the ticket.

10. Know Where to Watch What’s Happening in Rails

Rails and Ruby both have large and active communities that constantly generate changes, improvements and new projects. Trying to keep up with all the activity can be daunting, but it’s essential if you want to benefit from the community’s best work and continue to increase your Rails and Ruby knowledge.

Thankfully, a number of sources aggregate some of the most important activity:

GitHub has a most-watched projects page, which is a great place to start.
Similarly, RubyInside’s monthly What’s Hot on Github and
the GitHub blog’s Rebase series both feature selections of interesting work from the website.

There’s also a whole universe of Rails training:

and news aggregators:

follow ruby_news on Twitter,
subscribe to Ruby Inside,
subscribe to Ruby Flow.

Another avenue is the Rails Core mailing list and the #rails-core IRC channel.

About the authors

This guest post was written by Greg Borenstein and Michael ‘MJFreshyFresh’ Jones, lead Ruby developers for StepChange Group. StepChange designs, develops and manages social media widgets and Facebook applications in partnership with leading brands and agencies. Outside of work, Greg builds drum-playing robots and other hardware hacks, and MJ leads a local group of Unicycle-borne pirates. They live and work in beautiful, moist Portland, Oregon.

(al)

Build a news site with Rubyflow

2009-02-10T23:09:31Z

Ruby journalist extraordinaire, Peter Cooper, is a busy man. Chances are you’re already following his work to bring you the latest Ruby news on sites such as Ruby Inside and RubyFlow. Late last year he even added a tremendously useful site oriented towards iPhone and iPod Touch development called Mobile Orchard. Somewhere along the line he was also generous enough to leak the source code for Rubyflow, and now a version of that is available through Sutto’s Github repository.That’s great news for anyone looking to start their own news site, especially since it’s a breeze to get working on Heroku.

Start by cloning the source from Github:

$ git clone git://github.com/Sutto/rubyflow.git

Rubyflow depends the thoughtbot-factorygirl gem, so next we’ll make sure to install that and unpack it in vendor/gems:

$ rake gems:install
$ rake gems:unpack

I also found that the captcha used in Rubyflow’s user registration requires “digest/sha1” to be required explicitly, so go ahead and add

require 'digest/sha1'

at the bottom of config/environment.rb. Once you’ve done that it’s time to commit our changes to git:

$ git add .
$ git commit -m "vendored gems and required digest/sha1"

With that out of the way, it’s time to create an app on Heroku and deploy to it:

$ cd rubyflow
$ heroku create 
Created http://high-fire-37.heroku.com/ | git@heroku.com:high-fire-37.git
Added git remote heroku
$ git push heroku master
...
App deployed to Heroku.

Finally, we run migrations to set up the application database:

$ heroku rake db:migrate

…and there you have it!

Be sure to read the docs on site configuration and customization here.

Enjoy!

The Future of Deployment

2009-02-06T02:04:44Z

Application deployment is changing. In relatively short order I’ve gone from buying hardware, to monthly hosting, to metered CPU time, and from building my open-source software manually, to package managers, to fancy config tools and recipes to pre-build whole machine images. What’s next?

The Old Way

I can deploy Rails apps in a traditional hosting environment pretty quickly. For a small app, I might make a new unix user and database on a personal Slicehost slice and do a quick code checkout. After setting up a few permissions and twiddling my Nginx config, in a matter of fifteen minutes or so my app is online. Not bad at all.

For a bigger app, it takes more time. In days of yore I’d build a server from parts or buy one of the excellent Pogo Linux servers and put it in a colo. OS install, Xen setup, guest OS install, OS package setup, security lockdown, then on to the task of all the stack setup (database, Rails, source control) specific to the application to be run.

Once you get into multiple servers, the complexity multiplies out quickly. There are dozens of small decisions to make about how resources are allocated. More RAM or more CPU for the database machine? One slave database, or two? Hardware load balancer vs. multiple IPs vs. something else? All of these require both detailed knowledge about hardware and software deployments, combined with a huge amount of predictive guesswork to try to foresee the quantity and type of load that the app being deployed is likely to face in the next 3, 6, or 12 months.

There’s an enterprisey word for this process: provisioning.

The New Way

Amazon’s EC2 is the vanguard of the new generation of cloud computing. Provisioning a server was formerly a phone call and days or weeks of waiting. Now it’s a REST call and 30 seconds of waiting. Awesome.

But this is a very raw resource: there are still many provisioning decisions to be made, software to set up, and then on to deployment of the app itself. Excellent services like RightScale and Engine Yard’s new offering Solo can help automate a lot of this process and minimize the management burden. So far, so good.

But what if provisioning was instantaneous, requiring no upfront decisions about resource allocation? What if you didn’t need to think at all about the server hardware or software, but only about your application code? How would this change how we build applications?

The Future

When technology breakthroughs make something smaller, or faster, or cheaper, it doesn’t just change current use; it creates whole new types of use. If app deployment is instantaneous, without having to plan for resources, allocate servers, or beg approval from the IT department, what kind of apps will we build that don’t get built today?

In the past decade we’ve seen widespread adoption of agile methodologies in the development of software. This has transformed software development from a slow, failure-prone, and sometimes downright painful process into one that is fast, fun, and fulfilling. But deployment of applications has changed hardly at all during that same time period. The way you deploy a Rails, Merb, Sinatra, or Django app today is very similar to how you deployed a Perl app in 1999.

This coming decade is going to see an agile revolution for the deployment side of the equation. The manual, guesswork-heavy methods of provisioning that we use today are soon to be superseded by methods that will make deploying an app fast, easy, and fun.

No one knows quite what that will look like yet (though at Heroku we certainly have our own opinion), but one thing is for sure: the time is ripe for a revolution in IT.

Rails Guides Gets a Facelift

2009-02-04T01:05:00Z

There’s a brand new version of Rails coming, as you already know. What better time for a new version of some of the Rails documentation? So the Rails Guides team is pleased to announce a refresh of the Ruby on Rails Guides site, just in time for the Rails 2.3 release.

The most obvious change you’ll see is a new look, thanks to some awesome design work from Jason Zimdars. But the visual refresh isn’t all that’s going on here. We’ve also been working to update the Guides for Rails 2.3, as well as to add new guides to the list.

And there’s good news if you want to get involved too. Behind the scenes, Tore and Pratik switched our markup engine from AsciiDoc to Textile. This makes the Guides easier to write and edit and easier to build into a Rails project. If you’ve got some spare time to help out, join us in the #docrails room on irc.freenode.net, and help make the Rails Guides into a great resource in time for the 2.3 release.

Sortie de Ruby 1.9.1

2009-02-02T11:24:04Z

La version 1.9.1 de Ruby est sortie. Il s’agit de la première version stable de la branche 1.9, qui correspond à la branche active de développement du langage : plus moderne, plus rapide, apportant une syntaxe simplifiée, un excellent support des langues, bref, un meilleur Ruby.

La branche 1.8 a été initiée en 2003 et a permis le développement de très nombreux produits. C’est maintenant au tour des 1.9.x de prendre le relai, mais les 1.8.x sont pour le moment toujours en activité — la version 1.8.8 sortira courant 2009.

Vous pouvez prendre connaissance des changements majeurs intervenus depuis la version 1.8.7 dans ce document

Depuis la 1.9.1 RC2, sept bugs ont été corrigés.

Si vous tombez sur un os ou tout autre problème, pensez à poster un rapport de bug sur le tracker officiel.

Téléchargement

ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.bz2
TAILLE : 7190271 bytes

MD5 : 0278610ec3f895ece688de703d99143e

SHA256 : de7d33aeabdba123404c21230142299ac1de88c944c9f3215b816e824dd33321

ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.tar.gz
TAILLE : 9025004 bytes

MD5 : 50e4f381ce68c6de72bace6d75f0135b

SHA256 : a5485951823c8c22ddf6100fc9e10c7bfc85fb5a4483844033cee0fad9e292cc

ftp://ftp.ruby-lang.org/pub/ruby/1.9/ruby-1.9.1-p0.zip
TAILLE : 10273609 bytes

MD5 : 3377d43b041877cda108e243c6b7f436

SHA256 : 00562fce4108e5c6024c4152f943eaa7dcc8cf97d5c449ac102673a0d5c1943b

Passenger mod_rails ne supporte pas la directive RailsBaseURI

2009-01-25T11:20:00Z

Passenger, alias mod rails est probablement la meilleure chose qui soit arrivée au web depuis l’invention du navigateur graphique – rien que ça – en faisant du déploiement d’applications Ruby on Rails un véritable jeu d’enfant. Plus besoin de configuration en dehors d’un Vhost des plus standards, mod_rails reconnaît les application Rails et Merb et fait ce qu’il faut. Et pour ne pas faire de jaloux, il fait de même avec les applications Django, il est vrai avec des performances moindres.

Via Ashchan, je viens cependant de découvrir un bug dans la directive RailsBaseURI, qui permet de déployer des applications ailleurs qu’à la racine d’un site, par exemple, http://t37.net/blog au lieu de http://t37.net.

<VirtualHost 91.121.80.167:80>
    ServerName t37.net
    DocumentRoot /path/to/t37.net/public
    RailsBaseURI /blog
</VirtualHost>

En théorie, Passenger devrait transmettre la directive RailsBaseURI à votre application Rails en initialisant sa variable relativeurlroot. Comme il semble ne pas le faire, en tout cas dans la dernière version, il faut modifier le fichier config/envionment.rb de votre application Rails afin d’y ajouter

config.action_controller.relative_url_root = "/blog"

Et voilà, vous êtes. Quant à moi, je vous laisse, j’ai une version stable de Typo et un patch pour mod_rails à terminer.

Article original écrit par Frederic de Villamil et publié sur Ergonomie web, Ruby on Rails et Architecture de l'information | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie web, Ruby on Rails et Architecture de l'information, c'est qu'il a été reproduit illégalement et sans autorisation.

Rails Documentation Projects

2009-01-15T09:58:00Z

With the recent revitalization of the Rails Wiki project, we’re seeing people ask how the various pieces of Rails documentation fit together. I thought it might be useful to lay out how the Rails Activists see everything fitting together as we move forward.

Rails is a large and mature framework, with a lot of functionality – and with the Merb merger, there will be even more to learn in the future. As such, it presents challenges for developers at all levels trying to understand how to use Rails effectively. There are many resources to help with the learning process, including commercial books and magazines, screencasts and podcasts, tutorials, blog entries, and training courses. But there is also a series of official written documentation projects.

There’s no such thing as one-size-fits-all documentation. Different developers bring different skill sets, backgrounds, and levels of professional maturity to learning Rails. There are at least four levels of official documentation, overlapping but serving different needs:

Inline documentation, with comments within the code itself (that you can see by running rake doc:rails within any Rails project).
Rails Guides
Rails Book (a new project for Rails 3.0)
Rails wiki

Although at first glance there appears to be substantial overlap, our feeling is that the each of these projects occupies a distinct (and valuable) niche.

RDoc

Provides immediate help for syntax questions
Maintained by the actual core developers and generally up-to-date

Rails Guides:

Provides focused “how to” help for particular problem domains
Target the mid-level developer, possibly with Rails experience
Have a large amount of existing high-quality material
Are already being continuously revised to track changes in edge Rails
Can include version-specific tutorial code samples
Can be delivered as a part of core Rails to provide “guidance at your fingertips” for new developers

Rails Book:

Provides high-level architectural guidance and overview of how the pieces fit together
Digs into the philosophy of the “Rails Ways”, so readers can understand why the framework works the way it does
Targets the developer new to Rails or those wanting to go from the “trees” to the “forest” view
Offers help in conceptualizing Rails and choosing between alternative modules (ORMs, routing DSLs, etc.) in the Rails 3 timeframe
Can draw on the Merb experience in simultaneous translation and pulling in contributions from many writers
Largely version independent
Gives a structured path through end-to-end documentation in a way that standalone Guides do not

Rails Wiki

Community-driven documentation that can respond rapidly to new software and new questions
A good repository to links to external information
Potentially a showcase for Rails itself in the underlying software
A place to put the accumulated community knowledge, even the pieces that are not often needed

It’s important to note that we don’t see these four projects as entirely separate efforts that have no interaction with one another. In particular, it seems likely that the Book will link to the Guides for those seeking additional detail, while the Guides will link to the Book for those seeking additional high-level guidance. We also anticipate that the wiki will point readers to both Guides and Book (as well as to other sources of information).

So, what can you do to get involved? If you’re a writer, translator, or editor, any of these documentation projects would love to have your help:

To contribute to the RDoc, write a Rails patch with good comments or check out the docrails project.
To help the Rails Guides, get in touch with Pratik Naik or Mike Gunderloy, or drop by the #docrails channel on IRC freenode.
To get involved with the Rails Book, contact Matt Aimonetti.
To add to the Rails Wiki, join the rubyonrails-wiki group.

Un e-book de 400 pages sur Ruby en téléchargement gratuit

2009-01-07T22:03:00Z

Le livre de Ruby est un livre très complet sur le langage de scripting Ruby. Écrit et mis en ligne gratuitement au format PDF par Huw Collingbourne, un des développeurs de l’IDE Ruby In Steel, il se veut également particulièrement didactique.

À travers ses quelques 20 chapitres sur 400 pages, il cherche à couvrir l’ensemble des aspects du langage en accompagnant chaque partie d’exemples de code source directement réutilisables.

Bien qu’en anglais, il m’a semblé particulièrement intéressant car il couvre nombre d’outils de debug, graphiques ou non, disponibles pour Ruby. L’introduction, elle, couvre plus particulièrement l’IDE Ruby in Steel.

Pour ceux qui souhaiteraient subtiliser un aide mémoire à cette étude particulièrement approfondie du langage, Huw Collingbourne a également écrit Le petit livre Ruby – pour ne pas dire le Petit Livre Rouge – qui couvre ce que vous avez besoin de savoir pour pratiquer ce merveilleux langage en 80 pages et 10 chapitres.

Et comme dirait quelqu’un que je connais : si c’est gratuit, c’est pas cher. Et si c’est pas cher, c’est dans mes prix !

Announcing the Rails activists

2009-01-05T16:52:00Z

Bringing Rails and Merb together is about more than just merging the respective code. We’re also picking up the best ideas from both communities beyond the code. Following on Merb’s success in offering a strong evangelism effort, we’re pleased to announce the creation of the Rails activists:

The mission of the Rails activists is to empower and support the worldwide network of Ruby on Rails users. We do this by publicizing Rails, making adoption easier, and enhancing developer support.

At launch, we’ve identified seven areas where the Rails activists can contribute to the Rails ecosystem:

Public Relations with media of all sizes
Ombudsman work to ensure good user-to-user support
Community Leadership at events and conferences
Media Organization to help create good promotional opportunities
Website maintenance
Documentation efforts
Developer support

The initial members of the Rails activists are Gregg Pollack, Matt Aimonetti, Ryan Bates, and Mike Gunderloy. But we can’t do all this alone, nor do we want to! Our vision includes a large and vibrant Rails network composed of other activists, bloggers, event hosts, authors, and developers. Our intent is to provide connections, resources, and support to help the entire ecosystem to grow. To start things off, we’re bringing in a lot of our own projects, including videos, screencasts, case studies, Rails documentation, and more – we’re a working group, and we hope you’ll work with us.

If you have ideas about improving the Rails community, projects you want to participate in, or are just looking for ways to get involved, get in touch with us! There are a lot of ways to do that:

Through the new Rails activism Google group.
Through the Rails feedback site, where you can vote on which projects you’d like to see us devote resources to in the Rails 3 timeframe and beyond.
Through our Twitter accounts (linked above)
Through IRC to Matt (mattetti) or Mike (mikeg1a)
Through email to Mike Gunderloy, Matt Aimonetti, Gregg Pollack, or Ryan Bates.

We look forward to hearing from you!

For additional perspectives from the activists, see the posts by Gregg Pollack, Matt Aimonetti, and Mike Gunderloy.

Photo by Flickr user caravinagre

Merb gets merged into Rails 3!

2008-12-23T19:47:00Z

It’s christmas, baby, and do we have a present for you. We’re ending the bickering between Merb and Rails with a this bombshell: Merb is being merged into Rails 3!

We all realized that working together for a common good would be much more productive than duplicating things on each side of the fence. Merb and Rails already share so much in terms of design and sensibility that joining forces seemed like the obvious way to go. All we needed was to sit down for a chat and hash it out, so we did just that.

What this will mean in practice is that the Merb team is putting their efforts into bringing all of the key Merb ideas into Rails 3. Yehuda Katz will outright join the Rails core team, Matt Aimonetti will work on a new evangelism team, and Carl Lerche and Daniel Neighman (hassox) will be co-starring the effort to bring all this over. We’ve immortalized the merge with plaque page at rubyonrails.org/merb.

What’s being brought over?
Some of the key ideas that they’ll be taking with them from Merb into Rails 3 are:

Rails core: Yes, Rails is a full-stack framework and will remain so, but there’s no reason we shouldn’t also make it possible to run with less than the full monty. Rails 3 will make it easy to run just a bare minimum and then allow you to opt in just the stuff you want, if that’s necessary for your particular situation. Think “rails myapp—core” (and “rails myapp—flat”).

Performance optimizations: Merb has a lot of Rails pieces rewritten to be faster. We’ll be bringing all that good stuff over. We’ll also bend the architecture in the places where that’s necessary for a big yield. In short, Rails 3 will get all the performance attention that the Merb guys are known for.

Framework agnosticism: Rails will always have a default answer to every question within the stack. If you don’t care about testing frameworks, you’ll get test/unit. If you don’t care about which ORM, you’ll get Active Record. But some people do care and want something else. Some people want RSpec for testing, others want to use Sequel or Data Mapper for ORM, others again prefer Haml for templating, and some might prefer jQuery for Ajax. All these people should feel like Rails is welcoming them with open arms. Yes, we’ll have a default, but we shouldn’t have any form of discrimination against alternatives.

Rigorous API: Too many plugins break when Rails is updated because it’s not clear where they can safely hook into the internals and when they’re monkeypatching and should expect things to break. The Merb guys committed to a public API with tests to ensure that it wouldn’t break. They’ll bring over that line of thinking and give Rails 3 a tested and documented API for extensions that won’t break willy-nilly with upgrades.

This is not a big bang rewrite
It’s important to understand, however, that this is not a “big bang” rewrite of Rails. We’re far beyond the time when we could just throw out everything and start over. This is going to be a progressive improvement of Rails that’ll carefully judge new initiatives on their impact on backwards compatibility as well as their general utility.

I’m sure there’ll be some parts of Rails 3 that are incompatible, but we’ll try to keep them to a minimum and make it really easy to convert a Rails 2.x application to Rails 3. The Merb guys will also be working hard on giving existing Merb users a manageable upgrade path to Rails 3. We’re working with lots of ideas including allowing existing Merb controllers to be mounted alongside new Rails 3 ones. We’ll see how it all plays out, but play out it will.

Also, the Merb guys aren’t just abandoning the existing Merb user base and their applications. They’ll still be doing bug fixes, security fixes, and work on easing the upgrade path to Rails 3. This will all progress in a nice, orderly fashion.

The timeline
Rails 2.3 is just around the corner. We hope to wrap up and release in January. It’s a blockbuster release packed with goodies to the tilt. But as soon as that’s done, all eyes will be on Rails 3.

The probably-overly-optimistic goal is to have at least a beta version ready for RailsConf 2009 in Las Vegas. Who knows if we’ll make it, but we’ll certainly have made tons of progress on it by then.

So all of these changes are pretty much effective immediately. We’ve already started the collaboration and we’ll be rolling out a bunch of public initiatives announcing the concrete elements of the work under the Rails 3 milestone very shortly.

No hard feelings, just kumbaja
This is quite a dramatic turn of events. We went from testy relations to coming together in not very long at all. But I’ve been incredibly positively surprised at how well everyone on both sides have been gelling behind the scenes. The more we talk, the more we realize that we want the same things. And in the few cases were we do care about something different, it’s usually complimentary.

I really hope that everyone within both communities will deal with this news as gracefully as the key contributors from both camps. Let’s just wipe the slate clean on anything that has gone before and cherish that we can now move forward in unity instead of as fractions of the same ideas.

Rails 3 is going to kick ass.

Also read what Yehuda wrote about this and Carl Lerche and Ezra and Matt.

Rails Party le 30 novembre 2008 à Paris

2008-11-17T21:33:00Z

L’association Ruby France – à laquelle j’ai le plaisir de cotiser chaque année pour une somme modique – organise un warm up à Paris On Rails le dimanche 30 novembre 2008 de 16 heures à 22 heures. Celui-ci se déroulera au Dune, 18 avenue Claude Vellefaux, dans le 10ème arrondissement de Paris. Cette Rails Party regroupera les développeurs utilisant le framework Ruby On Rails de tous niveaux, ainsi que les curieux souhaitant le découvrir sous la forme d’ateliers informels de type Barcamp, de lightning talks, de hackfest… selon les envies des présents.

Suite à mon avis – critique et assez tranché – sur Paris On Rails il y a pas loin d’un mois, Guillaume Desrat, président de l’association Ruby France m’avait demandé si je participerais à un événement de type communautaire qui se déroulerait en marge de cette conférence. J’ai évidemment accepté avec plaisir, la question comportant un piège, puisque je pouvais difficilement refuser sans entrer en contradiction avec ma précédente envolée. Je devrais y présenter la version (quasi) finale de Typo 6.0, dont Cyril devrait lui profiter afin de parler de la migration d’une application Rails 2.0 vers une application Rails 2.2. Je n’exclue pas non plus de présenter un atelier sur la création de thèmes ou de plugins Typo s’il y a des personnes intéressées.

Article original écrit par Frederic de Villamil et publié sur Ergonomie, Rails et Architecture de l'information web (2.0) | lien direct vers cet article | Si vous lisez cet article ailleurs que sur Ergonomie, Rails et Architecture de l'information web (2.0), c'est qu'il a été reproduit illégalement et sans autorisation.