Is Ruby on Rails (Or at Least the Community) Dying

is ruby on rails (or at least the community) dying?

Ruby on Rails was a Hype. That means a lot of people jumped on the bandwagon because that is what they do: jumping on bandwagons (for a living).

After that hype, many communities popped up, in various languages that mimic Rails. Or try to. Or just took the good ideas and applied them to their community. Now you have gazillion halfbaked PHP-frameworks, and a few actually good ones. You have Django (python), Zend, Symfony (PHP) and even in Ruby, some alternative frameworks.
That has spread the attention. There used to be only One Good Framework (sic.) now there are many.

That said, Rails 3 has just been released. Rails 3 is cutting-edge again. It has all the ingredients for noSQL (the one-but-latest Hype) HTML5 (the latest Hype) and many javascript-frameworks and interactions (the next-to-be Hype).

That said, Rails is not just Hypes. It is actually a fantastic framework. With a still very active community around it. Just look at github, and visit the trending repo's there once in a while and you will see a Great Rails Thing there every week.

If you want to keep up to date, I would advice:

http://www.rubyinside.com a blog all about Ruby.
http://5by5.tv/rubyshow a podcast with (most of) all the news in Rails and Ruby land.

Current ruby and rails resources (2010)

New website that started for rails developers: http://railsdeveloper.com/

Great blogs are: http://railstips.org/, http://railstutorial.org/

mislav created a cool tool at GoGaRuCo called explain ruby: http://explainruby.net/

screencasts: http://teachmetocode.com/screencasts/

Is there a built-in approach in Ruby on Rails to avoid writing data in stale forms to the database?

The link to ActiveRecord::Locking::Optimistic in the answer by Andreas Gebhard technically says all you need to know. However, it might be more clear if I spelled it out for you.

If you add a field named lock_version in your table, by default ActiveRecord will enable optimistic locking. However you are not done yet.

The problem you are having is called "The Lost Update Problem" where a second person's update clobbers an earlier person's update. If all you do is enable optimistic locking in the database layer you will still have a lost update problem in your web application if you program it normally and do not take the necessary steps.

Normally your update action does a find of a record, then replaces all the fields with values sent from the form. As far as the database and ActiveRecord know, you started with a fresh recent record and updated it. Thus optimistic locking will be satisfied with allowing the update but you still have a lost update problem.

What you need to do is include the lock_version field as a hidden input in your form. Then when the second person doing an update tries to update, setting the lock_version to the old value before the prior update was done will cause optimistic locking to fail.

In pessimistic locking, the key to avoiding the lost update problem is to get the edit form you must first get the lock. If someone else has it locked, you cannot edit. A very important key to solving the lost update problem is the human in the loop by presenting the values in the database before their edit so only the human makes a decision to change them. In the lost update someone did not know about someone else's update and so saved the previous value unaware that it had been updated.

In reality there is no solution to the problem. Someone will always lose. In the lost update problem the first person to save loses. In pessimistic (aka exclusive locking) the second person to try to get the lock loses. In optimistic locking the second person to save loses.

The downside with pessimistic/exclusive locking is someone trying to get the edit form is denied because someone else has the lock. Also locks might not get released when they should and you can have deadlocks.

The downside with optimistic locking is someone can do all the work on their edit and be denied when they try to save.

In any case it is a surprise to someone just trying to edit. The downside of the lost update problem which makes it the worst is the surprise happens quietly without anyone noticing. At least with exclusive or optimistic locking the user gets informed. With optimistic locking they have to "merge" possibly having to redo the work of their edit starting from fresh data. With exclusive locking they never have that problem but they may have to wait and might not understand why. The general preference for optimistic locking is that most of the time there is no contention for the update and it just works whereas for exclusive locking there is always the step of going into edit mode and refreshing the data on the edit form.

Is Spring hard compared to Ruby on Rails?

Both Spring and Ruby on Rails share the "convention over configuration" moto. This reduces code lines significantly. Ruby on Rails is a Web Framework and it could be compared with Spring MVC, together with an ORM tool like Hibernate.

One could say that Spring together with Spring MVC or another MVC framework and Hibernate are the closest that you can get to Ruby on Rails for the Java world.

However, Spring has a much wider scope than RoR.

What are the Ruby Gotchas a newbie should be warned about?

Wikipedia Ruby gotchas

From the article:

Names which begin with a capital letter are treated as constants, so local variables should begin with a lowercase letter.
The characters $ and @ do not indicate variable data type as in Perl, but rather function as scope resolution operators.
To denote floating point numbers, one must follow with a zero digit (99.0) or an explicit conversion (99.to_f). It is insufficient to append a dot (99.), because numbers are susceptible to method syntax.
Boolean evaluation of non-boolean data is strict: 0, "" and [] are all evaluated to true. In C, the expression 0 ? 1 : 0 evaluates to 0 (i.e. false). In Ruby, however, it yields 1, as all numbers evaluate to true; only nil and false evaluate to false. A corollary to this rule is that Ruby methods by convention — for example, regular-expression searches — return numbers, strings, lists, or other non-false values on success, but nil on failure (e.g., mismatch). This convention is also used in Smalltalk, where only the special objects true and false can be used in a boolean expression.
Versions prior to 1.9 lack a character data type (compare to C, which provides type char for characters). This may cause surprises when slicing strings: "abc"[0] yields 97 (an integer, representing the ASCII code of the first character in the string); to obtain "a" use "abc"[0,1] (a substring of length 1) or "abc"[0].chr.
The notation statement until expression, unlike other languages' equivalent statements (e.g. do { statement } while (not(expression)); in C/C++/...), actually never runs the statement if the expression is already true. This is because statement until expression is actually syntactic sugar over
```
until expression
  statement
end
```
, the equivalent of which in C/C++ is while (not(expression)) statement; just like statement if expression is an equivalent to
```
if expression
  statement
end
```
However, the notation
```
begin
  statement
end until expression
```
in Ruby will in fact run the statement once even if the expression is already true.
Because constants are references to objects, changing what a constant refers to generates a warning, but modifying the object itself does not. For example, Greeting << " world!" if Greeting == "Hello" does not generate an error or warning. This is similar to final variables in Java, but Ruby does also have the functionality to "freeze" an object, unlike Java.

Some features which differ notably from other languages:

The usual operators for conditional expressions, and and or, do not follow the normal rules of precedence: and does not bind tighter than or. Ruby also has expression operators || and && which work as expected.
def inside def doesn't do what a Python programmer might expect:
```
def a_method
    x = 7
    def print_x; puts x end
    print_x
end
```
This gives an error about x not being defined. You need to use a Proc.

Language features

Omission of parentheses around method arguments may lead to unexpected results if the methods take multiple parameters. The Ruby developers have stated that omission of parentheses on multi-parameter methods may be disallowed in future Ruby versions; the current (November 2007) Ruby interpreter throws a warning which encourages the writer not to omit (), to avoid ambiguous meaning of code. Not using () is still common practice, and can be especially nice to use Ruby as a human readable domain-specific programming language itself, along with the method called method_missing().

Rails app running on puma and nginx keeps dying every few hours with Bad Gateway

It seems this is actually an issue with ruby 2.1 (specifically i'm using 2.1.2) and its garbage collection.

A google search like this seems to have lots of various threads on it http://bit.ly/1s2vBC0

Here's a ruby bug ticket on the issue: https://bugs.ruby-lang.org/issues/9607

Ruby-on-rails development and production on same server

It is not normal, but it is possible - and occasionally needed - to debug problems that are only showing up in production. A couple of examples are assets (javascripts, images, etc) that are served up differently in development as opposed to production due to the asset pipeline. Another area is caching which tends to be different in production and is frequently disabled in development.

In ruby on rails there are usually (at least) three modes that the server can run in.

These are referred to as 'environments'.

development. This is your local machine and is what you normally use locally during development
tests. This is used when you run tests and test suites.
production. This is the mode used for actual production servers which are usually on a remote server.

Sometimes you do want/need to run a local development server in 'production mode' and in these cases you do this inline with

RAILS_ENV=production rails server

rails server -e production

rails server -e production -p 3001 
# Specify the port (e.g. **-p 3001**) if you want to run on a different port (the default port is 3000),
# e.g. to run in development mode in one window and production mode in another.

When you run your local server in another mode, such as production, you'll need to be aware that this also affects your database connection. config/database.yml has your database connection and also uses the RAILS_ENV settings.

You may want/need to run your server in production mode - but use your local database. You can do this by temporarily using the actual setting from the development block in the production block of config/database.yml. Just be sure to save the original settings / restore afterwards (before you do your next push).

It's also totally ok and indeed common to have sqlite locally and mysql/postgres/oracle in production.

Is Ruby on Rails (Or at Least the Community) Dying