• it counts blank and empty lines
• it counts lines with only comments
• it counts only the number of lines, so each of these lines count as one even though the second is much more complex.

post = Post.new
elsif (parsing_descr == 1 || parsing_descr == 2) && line =~ /^:\d+\s+\d+\s+[0-9a-f.]+\s+[0-9a-f.]+\s+(\w)\d+\s+(\S+)\t(.+)$/

To overcome wc's limitations, we need to use a tool that is built specifically for evaluating the complexity of Ruby code.

Flog

Flog is a tool by Ryan Davis and Seattle.rb that scores your Ruby code based on common patterns. It works based on counting your code's ABCs:

• A - Assignments. When more objects are assigned, the complexity goes up - foo = 1 + 1.
• B - Branches. When code branches, there are multiple paths that it might follow. This also increases it's complexity.
• C - Calls. When code calls other code, the complexity increases because they caller and callee are now connected. A call is both a method call or other action like eval or puts.

All code has assignments, branches, and calls. Flog's job is to check that they aren't used excessively or abused.

Each of the ABCs have different metrics associated with them. For example, a standard method call might only score .2, but an eval call would score 5 even though they are both calls. This is so the more complex and difficult to understand code is scored higher.

Now that you understand how scoring works, lets take a look at how flog uses the scoring.

Flog Scoring

When flog is given Ruby code, flog parses it and builds up a structure of the code internally using RubyParser. Then it goes through every class and method until everything is scored. What you end up with is a breakdown of how each class and method scored. So if you had two branches (1 point each) in your method, flog would give that method a score of 2. At the class level, flog would give your class a score that is a total of all of the methods in the class.

Using the scoring, you can get an idea of how complex or poorly written a piece of code is compared to other code. For example: in a class with two methods, one with a score of 40 and one with a score of 140, it's easy to see that the second method is more complex (or over complicating things). Ideally you would devote more of your time to refactor on the second method, since it's more complex.

A complete listing of the different scores that flog assigned can be found here in the source code but here is a summary of the common ones:

• Class defination - 1
• Method defination - 0
• Module defination - 0
• Subclass defination - 0.5
• method call - 0.2
• assignments - 1
• branching (and, case, else, if, or, rescue, until, when, while) - 1
• litteral number - 0.25
• Symbol to Proc (e.g. posts.collect(&:author)) - 10
• alias_method - 2
• alias - 2
• block_pass - 1
• block - 1
• class_eval - 5
• define_method - 5
• eval - 5
• extend - 2
• include - 2
• inject - 2
• instance_eval - 5
• instance_method - 2
• instance_methods - 2
• method_added - 2
• method_defined? - 2
• method_removed - 2
• method_undefined - 2
• module_eval - 5
• private_class_method - 2
• private_instance_methods - 2
• private_method_defined? - 2
• protected_instance_methods - 2
• protected_method_defined? - 2
• public_class_method - 2
• public_instance_methods - 2
• public_method_defined? - 2
• remove_method - 2
• send - 3
• super - 1
• undef_method - 2
• yield - 1

A good rule of thumb for Flog scores is that you will want to eventually refactor or at least think about refactoring any method when it has a score of 40 or more. I have seen a single method go as high as 1,100 before (don't ask).

Refactoring based on flog's score

Once you have found which methods and classes that score high, you should be ready to refactor them. Since flog scores are totals of all of the assignments, branches, and calls; using a refactoring method that splits a section of code in two is usually a good first refactoring to perform. For a high scoring class, you might want to use:

• extract class
• extract superclass
• extract subclass
• move method
• move field
• remove middle man
• extract hierarchy

When refactoring a high scoring, you might use:

• extract method
• move method - especially if the method is being too intimate with another class
• move field
• encapsulate field
• decompose conditional
• consolidate conditional expression
• remove nested conditional with guard clauses
• replace temp with query
• replace method with method object
• substitute algorithm

My personal favorite refactoring is extract method. I use this all the time so split up larger methods into smaller one. It doesn't affect the total flog score for the project, but it makes the code a lot easier to understand when it's in two small methods. Do this enough and eventually you start to see some duplication across classes and you can make some really great refactorings then.

Getting started with flog

To get started with flog right away in your Rails app; I'd recommend that you install the metric_fu gem and run it's reports. metric_fu includes flog and several other tools I'm going to cover over the next few posts. Be warned, metric_fu can take a few minutes to run it's reports, especially on larger projects since it runs the entire test suite.

If you aren't using Rails or don't want to wait for the entire metric_fu report suite to run, you can get started using flog with:

1. gem install flog
2. flog path/to/app

This will find every Ruby file you have and will run flog on each file. Since flog produces a lot of output, I'd recommend piping this to a file so you can read through it all yourself (flog path/to/app > flog_output.txt). Running flog like this is quick so feel free to experiment with a few of it's command line options. The options I like to use when refactoring are:

• -a (—all) will display all of the flog results. Typically flog only shows the top 60% worst code.
• -d (—details) shows the scoring details so you can see why the code is scoring so high.
• -g (—group) groups the results by classes. If you are still exploring your application to find out what areas need to be refactored, the group option can help you explore faster (especially with the -a option)

Another option I use outside of refactoring is the —score option. The score will show a project score of all of the files and also the average score per method. This is great data to save if you want to watch the project's score over the long term (e.g. is the score getting better or worse?). If you use metric_fu, this value is graphed each time you run the metrics task so hopefully you can start to see the flog score get lower and lower over time.

Refactoring the most complex code in your application is a good strategy to keep it healthy and easy to change. But that alone isn't enough, especially when there is a lot of code duplication. Luckily Ruby has a tool that can be used to detect code duplication, flay. I'll be digging into how flay can be used in your project to find where your duplication is hiding.

This is a guest post by Eric Davis. Eric is a member of the Redmine team and has written an ebook Refactoring Redmine to show Rails developers what refactoring real Rails code looks like. He writes about the different refactorings done to Redmine every day at http://theadmin.org.

Tweet This Post

Luckily, help is at hand in the shape of the official Ruby on Rails Security Guide, but Irish Rails developer Matthew Hutchinson has trawled through that guide as well as several illuminating blog posts relating to Rails security, and put together a 14 step checklist of "bare minimum" security checks to do before releasing your Rails app.

In summary:

1. Don't trust logged in users. (Authentication is one thing, authorization to perform certain tasks is another.)
2. Beware of mass assignments. (Use attr_accessible in your models!)
3. Make some attributes un-editable with attr_readonly.
4. Watch out for SQL injection vectors. (Raw SQL in your code is a smell worth investigating.)
5. Prevent executable files from being uploaded.
6. Filter sensitive parameters from the logs.
7. Beware CSRF (Cross-Site Request Forgery) and use protect_from_forgery and csrf_meta_tag.
8. Beware XSS (Cross-Site Scripting) and use the h helper in views (this is the default in Rails 3, luckily).
9. Watch out for session hijacks.
10. Avoid using redirects to user supplied URLs.
11. Avoid using user params or content in the send_file method.
12. Make non-ActionController methods private.
13. Check your dependencies for security updates and patches.
14. Don't store passwords in the database as clear text.

Want more detail? Check out Matthew's article.

[ad] coder.io is a tagged developer news source. Want to subscribe to stories about Ruby but not Rails? Just use the query #ruby -#rails. Or how about Ruby screencasts?

Tweet This Post

The bug in question surrounds nested attributes that are accepted through the accepts_nested_attributes_for method. If you're not using this method, you're probably OK, though I have a big fat disclaimer over that (if you don't upgrade and your app gets fried, don't blame me ;-)).

If you're using 2.3.9 or 3.0.0 and are truly unable to upgrade at this point but are using nested attributes, Michael has included patches on this post. You might also appreciate the discussion on Hacker News if you want more info and insight.

Tweet This Post

rails-iphone-helpers is a Rails plugin that provides helper methods to produce iPhone-specific (or iOS, more precisely) HTML.

This library solves a simple problem, but few people have the patience or interest in memorizing the underlying code to set viewpoint sizes, scaling options, iOS icons, or iOS splash image settings. With rails-iphone-helpers, it all becomes structured and simple.. what more could you want from a plugin, really?

Tweet This Post

Recently I've been asked a lot as to which tools I use to refactor Rails apps. I don't use any one tool to refactor, but instead have a toolbox of several tools. Having several tools at your disposal gives you more flexibility to find what code needs to be refactored.

Intuition

The first and primary tool I use is intuition. If you know your code really well, you will already know which areas cause problems and need to be refactored.

If you are new to a code base though, you won't have this intuition and need to build it up before you can use it. Luckily there are several tools to find problem code that is just waiting for you to refactor them.

wc - the Unix word counter

The first tool is a simple Unix tool called wc. wc is the word count command and it's installed on almost all Unixes by default. It does more than count words though, it also counts the number of lines in a file. In my experience, classes and files with the most lines tend to need the most refactoring. If you think about it, more lines means more code which means a greater likelihood of bad code.

Using wc -l you can easily get line counts for all of the major areas of your Rails project. I typically just look in the controllers and models since that's where most development takes place but you might also want to check your lib and vendor directories. What you are looking for are large and complex classes.

If you have a lot of classes, like Redmine does, it can be useful to pipe the output to sort -n which sorts it numerically.

$ wc -l app/controllers/*.rb | sort -n
    25 app/controllers/auto_completes_controller.rb
    25 app/controllers/ldap_auth_sources_controller.rb
    26 app/controllers/project_enumerations_controller.rb
    ... snip ...
   248 app/controllers/wiki_controller.rb
   271 app/controllers/projects_controller.rb
   272 app/controllers/account_controller.rb
   322 app/controllers/repositories_controller.rb
   324 app/controllers/timelog_controller.rb
   326 app/controllers/issues_controller.rb
   412 app/controllers/application_controller.rb
  5381 total

$ wc -l app/models/*.rb | sort -n
    22 app/models/document_observer.rb
    22 app/models/group_custom_field.rb
    22 app/models/issue_observer.rb
    ... snip ...
   200 app/models/changeset.rb
   202 app/models/wiki_page.rb
   215 app/models/repository.rb
   234 app/models/version.rb
   336 app/models/mail_handler.rb
   416 app/models/user.rb
   442 app/models/mailer.rb
   643 app/models/query.rb
   774 app/models/project.rb
   863 app/models/issue.rb
  7412 total

Reviewing the results from wc

You want to look for a few things with raw line counts:

• is there a class with a disproportionate number of lines compared to the others?
• are there more lines in the controllers than the models?

In general, a well factored Rails application will have a majority of its code in the models and most classes will be the same size. There might be a few major classes that are larger than the rest, which are the primary domain objects. Using Redmine as an example, you would expect any Project, Issue, and User classes to be large since it's a project management and bug tracking application. Looking at the line counts from wc, the Timelog controller and Query model have a considerable number of lines even though they aren't the primary domain objects. In fact, because of my intuition from working with Redmine for years, I know both of these classes need some major refactoring.

Reading the code to find refactorings

After you see which classes are the largest, you will want to read through the class itself. Look for how "thick" the class is and see what you can learn about it's structure.

• Are there a few large method that contain most of the code for the class? Might be able to use extract method and extract class to shrink their size.
• Are there a lot of short methods? Maybe the code was over-factored or the class is trying to do too much and needs to be split.
• Are there a lot of comments? Since wc counts comments as lines too, wc might report that a class is large but there might not be that much actual code there.

After reading through some classes you will start to get a feel for what areas to refactor and if there are any common problems. You should also be able to start working on a few refactorings as you go.

Next time I'll talk about using some tools that understand Ruby and what makes Ruby code complex.

This is a guest post by Eric Davis. Eric is a member of the Redmine team and has written an ebook Refactoring Redmine to show Rails developers what refactoring real Rails code looks like. He writes about the different refactorings done to Redmine every day at http://theadmin.org.

Tweet This Post

What it's it good at?

Refinery is great for small business sites where the client needs to be able to update their website themselves without being bombarded with anything too complicated.

Unlike other content managers, Refinery is truly aimed at the end user making it easy for them to pick up and make changes themselves. The UI is clean and simple so the end user feels at ease and hopefully won't bug the developer with questions!

What Features Does It Have?

• Theming support
• Easy to use Rails-like plugin generator and plugin architecture
• WYSIWYG content editing
• Localisation (currently supports 10 langauges)
• Page management
• Image and File management
• Contact form and inquiry management
• Search Engine Optimisation

How do I install it?

Firstly install the Refinery CMS gem. This gives you a 'refinerycms' command you can run that creates a new Rails project with Refinery CMS hooked into it.

gem install refinerycms
refinerycms path/to/project

Finally change into the project start the web server

cd path/to/project
ruby ./script/server

Visit http://localhost:3000 and set up your first Refinery user.

What's coming up in Refinery CMS

Refinery is gearing up for it's 1.0 release with Rails 3.0 support. There is also a Refinery Day coming up where members of the community will be combining efforts to support Rails 3. Check the Google Groups below for details.

Useful Links

• Refinery CMS Website
• GitHub Repository
• Official Demo Site
• Refinery CMS Google Group
• Official IRC Channel

Post written by David Jones. David started Refinery CMS in 2004 and is the Technical Director at Resolve Digital, a Rails development company with offices in New Zealand and California.

Tweet This Post

Ruby on Rails, by its own admission, is an opinionated framework. From day one it has positioned itself as the Kryptonite to enterprise software, providing an easy to use, rapid development framework. The infamous 15 minute blog video set a tone which has continued through to this day: if it's not quick to build and in Ruby, we're not interested.

Rails takes an extreme viewpoint, the polar opposite of the XML heavy, configuration tangled mess of traditional enterprise software. This viewpoint is necessary---without it we have no alternative---but that doesn't mean it is the best way to build applications. In their book "First, Break All The Rules", Marcus Buckingham and Curt Coffman explain that the the common method of selecting top managers by looking for the opposite of bad managers is wrong. Research showed that this strategy tended to select good managers, but not the best managers. They found that the best and worst managers actually share a lot of the same characteristics! If you want good managers, then study good managers, not bad ones. The same principle applies to software: you won't figure out how to build the best software by studying the worst.

Studying the bad is exactly the approach the Rails team has taken, though. They have studied enterprise software, and built the opposite. In the process, they have unquestionably made some breakthroughs in how to write quality software fast (that's why we all use it!), but in what ways have they thrown the baby out with the bathwater? What attributes of the worst enterprise software are also found in the best software?

Relational databases have been around for decades, and are solid pieces of infrastructure. They can do some really cool stuff, but Rails considers them no more than a necessary evil. The less the database does, the better. I appreciate the philosophy: if we can move logic from the database in to our ruby application code, that's a win, right? In practice however, this doesn't work. It physically cannot work. In addition, it's actually slower (in terms of development time) and _less_ maintainable to do certain things in ruby rather than the database!

Relational databases know how to manage relational data. That's what they do, it's in their name. Referential integrity ensures that a child row always has a valid reference to a parent row. If a child has parent_id of 1, then a parent with an id of 1 is guaranteed to exist. Referential integrity has been a solved problem for decades using foreign keys. It is a proven fundamental property of solid applications, yet Rails has no best practice for using them. Rails has tried to reinvent the wheel and do it in ruby (with the has_many :dependent option), but it's half baked and cannot cover even simple edge cases. Try this thought experiment: one of your application servers adds a child row to a parent, while another one deletes that same parent at the same time. How you can prevent the child row from being orphaned? You can't, not without using your database.

Even something as simple as not null constraints, a fundamental principle of data design, are thrown away in the extreme polarized Rails opinion. You can just use validates_presence_of! Once again nice in theory, but I have yet to see a large evolving Rails application that hadn't had at least one null in its database where it shouldn't have been (subsequently causing errors). Even if I had, it's the cheapest safety net you can buy: all it "costs" you is a :null => false declaration in your migration and you never have to think about it again. No one in your team, not even the new rookie graduate, ever has to think about it again or run the risk of accidentally bypassing validations.

I'm not faulting the Rails team here. They have taken a hard line position and stuck with it, which is important for our industry. As software professionals though, we have a very different mandate than the Rails team. They are defining and pushing the boundaries of how we build software, where as our job is to find the best compromise of existing technologies to provide business value. This sweet spot will inevitably lie somewhere between extreme opinions.

This is a guest post by Xavier Shay. He is touring his "Database Is Your Friend" training course through the US and UK in July, August and September, in which he teaches you how to find the sweet spot of database usage for building rock solid Rails applications without compromising your velocity. The tour is more than likely coming to your city, so check www.dbisyourfriend.com for more details.

Tweet This Post

A good example of a Ext JS widget that depends heavily on client-server communication is a grid panel. It provides a convenient GUI for multi-line CRUD operations, as well as for the searching, filtering, and pagination of the data. Configuring an Ext JS grid panel in JavaScript will take quite some time even if you’re an experienced Ext JS developer - it's tedious work! How about using a lot of grid panels (normally bound to different database tables) all throughout your application? You soon realize, that not only your JavaScript code for those grid has to become reusable in some way, but also the server-side code (that responds to all the grid panel’s AJAX calls), will grow very quickly in a not-so-DRY manner.

This is where Netzke shines. It abstracts both client- and server-side code into components. By definition, components are reusable, isolated and configurable pieces of code with a well-defined functionality. A Netzke component (a “widget”) is a Ruby class that “knows” how to build and instantiate its JavaScript part (used in a browser), as well as how to respond to AJAX calls coming back to the server part. All communication – while being done over the Internet – happens “within” the component. Do you want to put several grid panels on the same web-page? Or maybe you want to dynamically load another grid in a modal window? While sharing the code (both JavaScript and Ruby), each of the grids will talk to its own instance, managing a separate ActiveRecord model if needed. See it in action here.

Netzke GridPanel widget is only one example of what can be done with the Netzke framework. Its philosophy is the following: create a widget once (you’ll need Ext JS knowledge for that, of course), and then reuse it all over again (or share it with the others), without the need to write JavaScript anymore. Besides, Netzke components are easily extendible, just use OOP: inheriting from Netzke::GridPanel provides for automatic prototype-based “inheritance” on the JavaScript level, too! Combining several widgets into a compound widget is also no problem.

The netzke-basepack project contains a set of pre-built Netzke widgets that can be used as basis for your RIA. And if you like to know more about different aspects of Netzke, browse through a number of tutorials on the WriteLessCode blog

This post is by Sergei Kozlov.

Tweet This Post

One of the big surprises and accomplishments is the fact that Unobtrusive Javascript made it into Rails 3. At first, we thought UJS wasn’t going to be included in Rails 3. Well, just before the first beta came out, the community responded well and a bunch of enthusiastic developers finished up one of the most wanted feature in Rails 3.

Rails has always been about staying on the cutting edge and Rails 3 is no surprise, UJS implementation in Rails 3 takes benefit of the new HTML5 data-*@ attributes. So Rails doesn’t spit out Prototype-based Javascript inline (the old helpers are still here). Rather, the helpers just define an appropriate data attribute in the tag, and that’s where Javascript comes in.

This literally means you can pick the data attributes in any Javascript framework and write generic code to support Ajax implementation of any kind. As you can imagine, this can be a highly flexible approach for demanding applications. But there’s more, the generic Prototype implementation is included with Rails 3 and the jQuery version is maintained officially here.

Let’s see how easy it is to swap jQuery in Rails 3. In the root of a Rails 3 application, run:

curl -L http://code.jquery.com/jquery-1.4.2.min.js > public/javascripts/jquery.js
curl -L http://github.com/rails/jquery-ujs/raw/master/src/rails.js > public/javascripts/rails.js

Here’s an initializer I got to know from Yehuda that you can define in config/initializers so javascript_include_tag :defaults uses jQuery instead of Prototype.

module ActionView::Helpers::AssetTagHelper
  remove_const :JAVASCRIPT_DEFAULT_SOURCES
  JAVASCRIPT_DEFAULT_SOURCES = %w(jquery.js rails.js)

  reset_javascript_include_default
end

With that set, Rails is now unaware of Prototype, all of the helpers with :remote => true will be grabbed by rails.js and worked through jQuery. You might also want to remove the Prototype libraries inside public/javascripts if you’re not going to use them.

As you can see, UJS in Rails 3 is pretty easy. Though there is a bit of a configuration to be done if you’re going against the default option in Rails, it’s far easier to work with than in the previous versions. You should also look at the fantastic Rails 3 Release Notes for changes in the concerned helpers and the section on Unobtrusive Javascript in my article on RailsDispatch.

[post by] Rizwan Reza is a passionate, self-taught developer and designer who’s been working with Rails since early 2005. He had his first Rails patch accepted in mid 2008, and has been contributing code and fixes ever since. Rizwan focuses on the start-to-finish product experience, all the way from branding to the application backend. Get in touch with him at contact at rizwanreza.com.

Tweet This Post

Ignite RailsConf: an unofficial pre-party held on June 6th with a variety of lightning talks, featuring Ruby luminaries like Chris Wanstrath, Gregg Pollack, and Ilya Grigorik.

Stay with a Local, a website to connect RailsConf attendees with Baltimore Rubyists. 9 Bmore on Rails members have opened up a total of 12 rooms in their homes to host attendees traveling to Baltimore.

BohConf, a free unconf running in parallel with RailsConf. It will be held in the convention center for the duration of RailsConf. This hacking-centric event will include community code drives featuring well known OSS authors, a code retreat, a programming competition, and "BarCamp"-style discussions.

[post by] Mike Subelsky is co-founder of the Rails-backed startup OtherInbox. He occasionally blogs at subelsky.com and lives in Baltimore.

Tweet This Post