RUG::B

As long as your application exists and developers will leave and new ones will take apart in your team. It's good to have some metrics about certain code smell. A code smells are part of your source code which may be the root of a design problem but are no actually bug. It's good to have some tools to be "lord of the smells" for Padrino - don't let smells lower the quality of your project.

Rails has this nice little feature called Enums. The introduction example is something like this:

class Conversation < ActiveRecord::Base
    enum status: [ :active, :archived ] 
end

http://edgeapi.rubyonrails.org/classes/ActiveRecord/Enum.html

And I think this is dangerous. States should be dealed with in a state machine. Why you ask? Because state changes usually have conditions attached to them. Only archive if ... . If you want to model something like that with enums, you end up with a horrible version of a state machine.

So let's see how we would do this in a "more cleaner way" with state machines.

Just before New Years, the last so called "Ruby Drama" hit: Brian Shirai will stop developing RubySpec, in the process flinging a lot of mud at the MRI developers for not supporting him. The JRuby development team reacted quickly and defended, while Ryan Davis and some others...

Wait. WHAT?

If you haven't been in the Ruby community for the last couple of years, it's incredibly hard to even keep track of all the people. All that isn't made easier by the extremely distributed nature of the Ruby community.

This must be very confusing even to moderate developers and I think a short mapping and introduction is in order. These people are, after all, those deciding and implementing our future. Knowing their historic roles is important in understanding the sentiments happening here.

Hopefully as beginner-friendly as it can be.