More speakers on RailsConf Vegas

RailsConf is going down next week in Vegas. I’m sure it’s going to be a great show and can’t wait to get out there. A few of the presenters have been blogging about the presentations that they’re doing.

Alexander Dymo is doing a session on Advanced Performance Optimization of Rails Applications, Jason Rudolph has one on testing JavaScript in Rails projects, Pat Maddox is talking about dealing with legacy Rails projects, and finally Sean Schofield just has five good reasons to attend the conference.

Check out the entire schedule for the conference and signup if you haven’t already. See you in Vegas!

14 comments

This Week in Edge Rails

April 18, 2009 – April 24, 2009

Edge Rails has been undergoing major surgery for the past week, as the core team gets ready for a Rails 3.0 alpha release at RailsConf. We saw about 50 commits to the master branch in GitHub this week. Here’s a quick overview of the recent changes.

Rails 2.3.x Changes

Before digging into the changes on the master branch, there were a few things committed to the 2-3-stable branch. If you’re running on 2.3 edge, these are ready for you; they’re also ported to the master branch already.

  • A couple of bugs involving associations with hash conditions have been fixed, notable to make sure that :dependent => :delete will work.
  • The PostgreSQL Active Record adapter now does the right thing if you use tables in non-default schemas. You need to set the table name in your model class, of course: set_table_name 'other_schema.customers' commit
  • Also in the PostgreSQL adapter, a couple of bugs related to wrong quoting of names with capital letters are fixed.

ActionView::Path Refactoring

One major chunk of change in Rails 3 this week comes from the continued work to refactor Action Pack. This time, ActionView::Path was the target. Changes in commit include decoupling ActionView::Path from Action Controller and Action Mailer, which gives us two major benefits. First, consolidating similar code in one place makes it easier to understand and maintain. Second, by abstracting this stuff and giving it an API, we’ll make it possible for other components to participate in the controller layer, beyond mailers and traditional controllers.

There’s also some work here to set up for the future. The plan is to decouple templates from the file system, and to decouple localization from ActionView. Stay tuned!

Pluggable JSON Backends

You may recall that recently Rails went to pluggable XML support. This week, thanks to work from Rick Olson, we have pluggable JSON. This means that you can replace the default YAML-based JSON support with the JSON gem:


ActiveSupport::JSON.backend = "JSONGem" 

As part of this change, Rails now uses ActiveSupport::JSON.encode() wherever it needs JSON. This replaces using #to_json, and Rails team is recommending that you do the same. If you do choose to use #to_json, you need to be aware that some libraries might override it. You can use this pattern to make sure that you’re getting Rails’ own definition of #to_json:


gem 'json'
# JSON gem loaded, which overwrites to_json
ActiveSupport::JSON.backend = "JSONGem" 

class ActiveRecord::Base
  # replace the gem's to_json with Rails' own to_json
  alias to_json rails_to_json
end

Active Support à la carte

In Rails 2.x, require "active_support" pulls in all core extensions at once. In Rails 3, require "active_support" only makes the extensions available; you have to explicitly require those you wish to use. Many of this week’s changes were concerned with breaking up Active Support so you can take just what you need and nothing more.

The end result is that it’s easy to cherry-pick features from Active Support without feeling like you’ve invited a portly gentleman for a piggyback ride. As an added bonus, all core extension documentation is now consolidated in one place: the core class. You don’t have to go poking around every extension module to find a method.

Internally, the core extensions have been reorganized so they can be directly required without assuming all of Active Support is available. Want inflections like "car".pluralize? require "active_support/core_ext/string/inflections" and you’ve got them. Note: the implementation and organization will change as we settle on the best way to provide core extensions.

Other Edge Changes

  • The Rails extension to Pathname was dropped, since it was only used in one spot in the code. commit
  • Support for the DRb cache store has been removed. commit
  • The sqlite Adapter joins the PostgreSQL adapter in supporting microsecond resolution. commit

Posted in Edge |  4 comments

2009 Rails Google Summer of Code Projects

The Google Summer of Code program has announced this year’s funding winners, and Rails has four student slots. Here’s what our students will be working on this summer:

Joshua Peek will be refactoring some of the Rails internals, with the goal of finishing the work on Active Model. The idea behind this particular Rails component is to extract some of the commonalities from Active Record and Active Resource, which in turn will make it easier to maintain the higher-level components and make the more consistent.

Nelson Crespo is planning on adding some Dtrace probes into a Rack module. These probes should make it possible to see what’s going on in a Rails application (or any other Rack-based application) with much finer detail than can be easily retrieved now. When the probes are ready, he’ll be working up some visualizations.

Jose Valim is tackling a rewrite of the Rails generator code. Right now, the generators are tightly-coupled to particular architectural choices; the goal is to make it possible to select, for example, a testing library, an ORM, and a Javascript library when you choose to generate a scaffold, and have the generated code use your preferred pieces.

Emilio Tagua will be working on Active Relation. This is another refactoring of the ActiveRecord code, covering the query generation capabilities. With Active Relation as a separate component, Rails will be better positioned to move towards ORM agnosticism.

We’d like to thank all of the students and mentors who participated in the Summer of Code selection process – it was tough to get down to four projects, considering all the great proposals we had. In particular, we had six runners-up whose proposals were excellent: Carlos Kirkconnell, Florian Gross, Hector Gomez, Ian Ownbey, Luciano Panaro, and Daniel Luz. We’re looking forward to seeing what all of our students bring to Rails this summer, and hope not to lose touch with others who are also excited about the prospects for Rails 3.0.

Posted in Activism |  8 comments

This Week in Edge Rails

April 4 – April 17, 2009

Just in case you missed the news: edge Rails is waking up, with Rails 3 changes starting to show up in the master branch at Github. So there’s a lot to discuss this week. If you want some more of the technical story on the Rails 3 rearchitecting to date, check out the detailed blog postings from Yehuda Katz.

Which Branch Should I Use?

The Rails 3.0 work is being done on the master branch in the Rails repository on Github. If you want to keep up with all the latest changes, this is the branch to track – with the caveat that this is currently alpha code. It’s entirely possible to build a working Rails application using the master branch. The Rails core team is committed to keeping the master branch passing all tests, and in fact improving our test coverage and continuous integration policies are both on tap as Rails 3 improvements. But it’s important to realize that the changes to Rails will result in many plugins needing a rewrite before they will work with Rails 3 (of course, some plugins will need more updating than others). This will make Rails 3 difficult to use for full-scale production deployments for some time to come.

For existing production applications, you should be tracking the changes on the 2-3-stable branch at Github. This branch contains bug fixes and improvements to the 2.3 release code, and should continue to remain compatible with the plugins and code that you’re already using.

Should I be Submitting Patches to Rails?

Absolutely! Rails has always been a community effort and that’s not changing for Rails 3. We welcome patches for either Rails 2.3 or Rails 3.0 – please use the appropriate tag (2-3-stable or 3.0) in your Lighthouse tickets to make it easy to tell which branch you’ve tested and based your patch on. The Contributing to Rails Guide will help you through the mechanics of submitting a patch to Rails.

David outlined the overall vision for Rails 3 back in December, and that’s still the basic plan. If there’s some piece that you’d especially like to get involved with, the Ruby on Rails: Core mailing list will help you get in touch with the developers to coordinate plans – and possibly save some headaches. Most of the major pieces of work are already underway, but we know that community ideas and contributions are essential to the success of Rails 3.

Rails 2.3.x Changes

Speaking of Rails 2.3, the last couple of weeks have seen some bug fixes deployed, and one interesting piece of new functionality: ActiveRecord::Base#touch. The idea is that you get a shortcut to push the current time into the updated_at or updated_on timestamp field in a record:


@customer.touch

What makes this more than a savings of a few keystrokes is that it’s also implemented as an option for belongs_to associations:


class Order < ActiveRecord::Base
    belongs_to :customer, :touch => :last_order_update
end

With this declaration in place, saving or destroying an order object will touch the corresponding parent customer object. This can come in very handy when you’re trying to invalidate a cached copy of the parent in that situation.

commit commit

Rails 3.0 Changes

ActiveRecord::Base#touch was also added to Rails 3.0 at the same time that it went into the 2.3 branch. In general, this should be the case: new functionality from Rails 2.3 will carry over into Rails 3. The core team is working hard to ensure easy upgrades and compatibility when the time comes to make the version change. But there were a lot of other changes this week that only apply to Rails 3: that’s what the rest of this posting is about.

Module Organization

There are spots in the Rails code where there are multiple levels of inclusion and inheritance and setup. As part of making it easier to follow what’s going on, Rails 3 is introducing new depends_on, use, and setup abstractions. These can make the intent of code more obvious on reading:


module AbstractController
  module Helpers
    depends_on Renderer

    setup do
      ...
    end
    ...
  end
end

module ActionController
  class Base2 < AbstractBase
    use AbstractController::Callbacks
    use AbstractController::Helpers
    ...
  end
end

commit More information

AbstractController

Probably the biggest architectural change so far in Rails 3 is the introduction of the AbstractController base class. This is a new implementation of the commonalities between ActionController::Base and ActionMailer::Base, and will eventually serve as a base class for the Rails analog of Merb’s parts. The intent is not to provide code that plugins or applications will use directly, but the build a solid low-level API that other things can depend on. For example, a consumer of AbstractController will be able to implement its own path-finding logic for templates, or add additional options to the basic render method.

commit commit More information

ActionDispatch

Another internal architectural change is the introduction of ActionDispatch. A new member of the Action Pack family, ActionDispatch exists as a home for all of the various HTTP libraries and middleware that were previously stuffed into ActionController, including such things as request handling, parameter parsing, status codes, and our bundled copy of Rack. commit

Defining the Surface Area

One of the goals of the Rails 3 work is to cleanly distinguish between public API methods that plugins and application code can rely on, and Rails internals that are subject to change. For an example of this, you can look at some of the refactoring that’s been done to ActionView::Template. Here, the change is to identify the methods that aren’t used by other classes, and to make them private. This immediately makes the intended API of the class more graspable, and in the long run will help give us a contract with plugins as to how they should interact with core code. After the current surface area has been formally identified, it’s likely that it will be reduced to result in a cleaner external API. commit

AJAX and authenticity tokens

If you’ve been writing much javascript by hand, you’ve discovered the nuisance of needing to include the Rails authenticity token in your requests. A closer analysis of the issues shows that there’s no need for these tokens in AJAX requests, because the same origin policy protects them. So, Rails 3 no longer checks for those tokens on AJAX requests, and that’s one less ugly bit of javascript for you to write. commit

Test Improvements

Another area of focus in Rails 3 is to bring the internal tests up to current best practices. There are a number of spots in the existing code where the tests are less systematic than they could be – changes have been checked in with test coverage, but no one has gone through and tried to ensure full test coverage of all normal “happy” code paths. For a glimpse of what’s happening in this area, check out some of the test files in actionpack/test/new_base (the new_base code is a rewrite-in-progress of ActionController::Base). There’s also active work going on to improve our continuous integration story, and the get together some basic high-level integration tests that can exercise Rails as a whole.

Loose Ends

There are some Rails 2.3 features that are currently not implemented in master. Some changes could not be merged cleanly with the new architecture, others are being reimplemented in different ways. You’ll find some specifics in this commit message, but the missing pieces include the performance boost for development mode rendering, template recompiling in production, and some template-picking logic. The developers working on Rails 3 have indicated that they intend to get back to feature parity as quickly as possible. In fact, a first pass over the rails-dev-boost changes has already been committed.

Removed: CGI Support

Rails 3 will not support direct CGI dispatching. This was deprecated in Rails 2.3, so it should be no surprise to anyone that it’s being removed entirely. If you need to use CGI for some reason, though, remember that it’s still supported through Rack. commit

Posted in Edge |  3 comments

Phusion Announces Passenger for Nginx

In the relatively short time since its release, Phusion Passenger has become part of the preferred deployment strategy for many Rails applications. But because it’s targeted at Apache, some sites have been unable to use Passenger. Apache is a great full-featured web server, but for highly traffic nginx seems to consistently deliver better throughput at lower memory use.

As of today, though, the Rails server landscape is changing for the better once again with the announcement of Phusion Passenger for Nginx. This new version takes the Passenger technology, including the use of Ruby Enterprise Edition, and integrates it tightly with nginx. How tightly? Well, you just install the Passenger 2.2.0 gem and run the included nginx installer, and you get a custom-built version of nginx along with instructions on how to configure it to server your Rails site. In addition to combining the benefits of nginx and Passenger, this has the side effect of greatly simplifying the nginx setup.

For more details, including a screencast, hop on over to Phusion’s blog

Posted in Tools |  6 comments

One Giant Leap Forward

As of a few minutes ago, the first big bunch of Rails 3 changes were merged back to Rails master branch in github. This represents a good deal of work by Yehuda Katz, Carl Lerche, and others. I’ll have more to say on the changes later on this week, but for now, just a quick caution: if you’re in the habit of using Edge Rails, you should likely switch to the 2-3-stable branch for the time being. The master branch of Rails will likely take a little while to settle back into something that can be used for anything other than getting a preview of the Rails 3 excitement.

Posted in Edge |  6 comments

Rails IDEs March On

Many Rails developers are perfectly happy working on their code in a text editor – and there are certainly plenty of excellent text editors out there. But others, particularly those who have come to Rails from another platform, find themselves wanting a full integrated development environment. For the latter group of developers, there’s good news: two major cross-platform Rails IDEs have releases available now.

Aptana’s RadRails (a plugin for their Aptana Studio IDE) has just released version 1.2. This Eclipse-based environment will seem instantly familiar to many users, and version 1.2 has a couple of major advances to boast about. First, it includes a wizard that will aid new users in setting up Ruby, Gems, and Rails; this is likely to be especially useful to those coming to Rails on Windows. Second, it has built-in deployment to Aptana’s Cloud Connect scalable deployment service, giving a pain-free way to get your Rails applications up and running.

Also worth a look is JetBrains’ RubyMine, currently in late beta prior to its commercial release. A purpose-built Rails IDE, it offers a variety of features including rake support, a model diagrammer, built-in web previews, and code quality tools. RubyMine isn’t finished yet, but the current beta version is showing good promise.

Both RadRails and RubyMine have the features you’d expect from an IDE, including flexible code editors, refactoring support, built-in hooks for test running, integrated debugging, and source code integration. RadRails comes in both community and $99 Pro editions, while RubyMine is scheduled to be released at $99. Whether you prefer to work in a text editor or an IDE, the appearance of these applications is yet another sign of the continuing popularity and growth of the Rails ecosystem.

Posted in Tools |  35 comments

This Week in Edge Rails

March 28, 2009 – April 3, 2009

Things are still fairly quiet out on the edge: 5 commits this week. The work for Rails 3.0 hasn’t been merged back to the master branch yet, so if you need any of the post-2.3 patches you can still just update to edge without worrying about major upheaval.

Changes

  • When are 24 hours not 24 hours? When you add them across a DST boundary in Rails – at least, until one of this week’s commits. You can read more details of what was going on over at the Lighthouse ticket.
  • Looked at your development mode /rails/info/properties view lately? Look again after this commit and it will show all of the installed Rack middleware pieces in your application.

Posted in Edge |  1 comment

RailsConf interviews, presenter posts, and keynotes

RailsConf 2009 is drawing ever closer and it’s going to be one hell of a show worthy of Vegas glitz and glamour. To let you all get more familiar with who’s going to be talking and what they’ll be talking about, Chad Fowler has been doing a series of presenter interviews:

In addition, Nicke Plante is talking about his Rumble Panel and Marty Andrews about his automated code quality check talk.

We’ve also announced some of the keynoters. In addition to yours truly, we’ll have Bob Martin of ObjectMentor, Chris Wanstrath of Github, and Timothy Ferris of 4-hour work week and lifestyle designs rock it out. We’re also going to have a Rails Core panel of some sort.

It’s going to be a great time. You can follow along with even more announcements from the conference on Twitter by subscribing to @railsconf. See you in Vegas? Of course I will!

0 comments

This Week in Edge Rails

March 21, 2009 – March 27, 2009

It’s been a quiet week for Rails on the surface: just half a dozen commits over the course of the week. Behind the scenes, though, the work is going on to merge initial Rails 3.0 work into the master branch of the git repository. We’ll have more news on that as it happens.

Fixes

Meanwhile, a few small issues in the 2.3 release have been cleared up in edge:

  • Tests with multiple POST requests in the same test block now properly handle parameters. commit
  • render :file with absolute paths now works on Windows systems. commit
  • Template extension parsing is now more robust (if you’ve been having problems with files like show.erb.orig, this one is for you). commit

Just a reminder, if you’re having any issues with Rails 2.3, we’d love to know about them – and we’d love it even more if you’d supply a failing test or a patch. Check out the details in the Contributing to Rails guide.

Posted in Edge |  1 comment

This Week in Edge Rails

March 14, 2009 – March 20, 2009

The big news in Rails this week, of course, was the release of Rails 2.3. But that certainly doesn’t mean the Rails edge story is over! To the contrary, we’re embarking on one of the more ambitious and exciting Rails projects of all: the creation of Rails 3.0. Read on to see where things stand.

Final 2.3 Changes

A few things went in to Rails 2.3 in the days leading up to release. These include:

  • DDL transactions for SQLite databases commit
  • Compatibility between render :file and Pathname commit
  • ActionController class naming conventions for Metal commit

Rails 2.3.2.1

Shortly after the release of Rails 2.3, which was version 2.3.2, it became necessary to make a Rails 2.3.2.1 tag. This is because the tagged 2.3.2 version in the Rails repository is actually missing an important fix (the installable gem version of Rails has the fix). The net result is that rake rails:freeze:edge RELEASE=2.3.2 would freeze a bad version of Rails into your application.

To fix this, the Rails team has re-tagged the master tree at a safer spot, after the critical fix. This new tag is for release 2.3.2.1. So if you’re freezing Rails 2.3 into your applications (as opposed to running it from gems) be sure to use rake rails:freeze:edge RELEASE=2.3.2.1. That .1 makes all the difference.

The Road to Rails 3.0

Now that 2.3 is out, what’s next? Rails 3.0, which has been a distant speck on the horizon for a while, is rapidly getting closer. The Rails core team is discussing exactly how to proceed, but the bottom line is that you are shortly going to see a lot of changes on edge Rails, as work that’s been going on in various forks gets merged back into the master branch. You’ll want to be cautious about using edge on existing applications. In particular, changes to the Rails internals may result in many plugins needing to be rewritten. Rails edge will continue to be the cutting-edge solution, but you’ll need to keep up with the changes and be prepared to work with them if you choose to run on edge.

But this doesn’t mean that Rails 2 is frozen in time either. There’s a new 2-3-stable branch in the Rails repository which will host any maintenance releases to the current release version. There will continue to be some work on making sure the 2.x releases of Rails work well, though the center of gravity of Rails framework development will shift quickly to Rails 3.0.

So stay tuned. We’ll continue to keep you posted with Rails 3.0 developments as they happen: the process will continue, as always, to be transparent and to welcome ideas and feedback.

Posted in Edge |  14 comments

Get Paid to Work on Rails

Last year, as you may recall, Rails got thread safety and a new core committer thanks to our participation in the Google Summer of Code program under the auspices of Ruby Central. This year, we’re pleased to announce, Ruby on Rails has been accepted into Google Summer of Code as a sponsoring organization in its own right.

What does this mean to you? Potentially, if you’re the right person, you can get paid to work on the Rails core code this summer!

The “right person” in this case is one who is at least 18 years old (sorry, Google’s rule, not ours!), a full- or part-time college student, and passionate about improving Rails. We’re building a potential list of project ideas on the Rails wiki, but we welcome other interesting proposals. We’re especially interested in work that meshes well with the plans for Rails 3.0, which will be in full swing by the time GSoC launches. If your proposal gets accepted, Google will pay you $4500 over the course of three months to work on the code.

If you’re interested, head over to the GSoC site and start reading about the process. Student applications can be submitted starting March 23.

What if you’re not a student? You can still help out by brainstorming ideas on the Rails wiki. Or if you’re a Rails guru and ready to make a strong commitment to help out the next generation of developers, you can apply to be a mentor.

We’re looking forward to working with this year’s students, and expecting some outstanding contributions to Rails as a result!

Posted in Activism, Jobs |  0 comments

Rails 2.3: Templates, Engines, Rack, Metal, much more!

Rails 2.3 is finally done and out the door. This is one of the most substantial upgrades to Rails in a very long time. A brief rundown of the top hitters:

  • Templates: Allows your new skeleton Rails application to be built your way with your default stack of gems, configs, and more.
  • Engines: Share reusable application pieces complete with routes that Just Work, models, view paths, and the works.
  • Rack: Rails now runs on Rack which gives you access to all the middleware goodness.
  • Metal: Write super fast pieces of optimized logic that routes around Action Controller.
  • Nested forms: Deal with complex forms so much easier.

And that’s just the tip of the iceberg. We’ve put together a complete guide for the Rails 2.3 release notes with much more information. Be sure to checkout the section on what was deprecated when you’re ready to upgrade your application.

You install 2.3 with (the final version is marked 2.3.2):

gem install rails

If you’re running on Passenger, be sure to upgrade to 2.1.2 as well. Rails 2.3 doesn’t run on older versions of Passenger!

We hope you’ll love it.

Posted in Releases |  102 comments

This Week in Edge Rails

March 6, 2009 – March 13, 2009

Things have been pretty busy on the development side since the release of Rails 2.3 RC2. The core team has been making a serious effort to review all of the open bugs and patches with an eye towards getting us a solid release. At this point, the bar for new features is set fairly high, but even so, there have been an incredible 94 commits in the week since RC2 – mostly fixes to ensure expected behavior and stability. Here are some of the highlights.

Swappable Parsers for XMLmini

The support for XML parsing in ActiveSupport has been made more flexible by allowing you to swap in different parsers. By default, it uses the standard REXML implementation, but you can easily specify the faster LibXML or Nokogiri implementations for your own applications, provided you have the appropriate gems installed:


XmlMini.backend = 'LibXML'
XmlMini.backend = 'Nokogiri'

commit commit

rake gem Task Rewrite

The internals of the various rake gem tasks have been substantially revised, to make the system work better for a variety of cases. The gem system now knows the difference between development and runtime dependencies, has a more robust unpacking system, gives better information when querying for the status of gems, and is less prone to “chicken and egg” dependency issues when you’re bringing things up from scratch. There are also fixes for using gem commands under JRuby and for dependencies that try to bring in external copies of gems that are already vendored.

commit commit commit

Routing Fixes

A couple of small fixes to the routing engine. First, member routes with requirements now work (previously the requirements were ignored):


map.resources :orders, 
  :requirements => { :id => %r([^/;,?]+) }, 
  :member => { :accept => :get }

commit

Also, shallow routes now work properly with namespaces (commit) and you can now use the OPTIONS verb in route conditions (commit).

Client-side Caching Improvements

The expires_in, stale, and fresh_when methods now accept a :public option to make them work well with proxy caching.


expires_in 10.minutes, :public => true
fresh_when :last_modified => @user.updated_at.utc, 
  :public => true
fresh_when :etag => @user, :public => true

commit

Odds and Ends

The String#parameterize method now accepts an optional separator character.


"My big duck".parameterize =>      "my-big-duck" 
"My big duck".parameterize('_') => "my_big_duck" 

commit

The ActiveRecord::Base#invalid? method now works as the opposite of ActiveRecord::Base#valid?. (commit)

The ActiveSupport::Json.decode method now handles \u0000 style escape sequences. (commit)

You can now set content types such as multipart/mixed in Action Mailer. (commit)

Rails 2.3 will ship with a bundled version of Rack, but if you have Rack 1.0 installed as a gem it will use the gem version instead. (commit)

Posted in Edge |  3 comments

Update on Rails Guides and Documentation

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.

Posted in Documentation |  6 comments