'Rails' Category

Dummy Code (Quick’n'Dirty vs. Engineered)

Posted under Java, Personal, Rails, Ruby, architecture, career, hibernate, scalability, spring, work by Anthony Chaves on February 4th, 2009. Comments Off

When creating software, two people will never write the same implementation of a method or system of non-trivial design.  Creating software is a problem solving process and there are usually many ways to solve one problem.  The solutions may differ in elegance and efficiency while giving the same output for a given set of inputs.  A correct solutions is a correct solution regardless of implementation. (more…)

Industry Ignorance

Posted under Java, Rails, Ruby, architecture, database, hibernate, scalability by Anthony Chaves on January 22nd, 2009. 4 Comments »

Today I let out a dejected sigh after reading a response to my latest post on the Joel on Software message board.  My post was just a reminder about the BostonScalability User Group meeting that takes place next Wednesday the 28th.  I post the meeting announcements on JoS and a good number of people hear about the meetings from the JoS board.  Every month a few new people tell me they found the group through JoS.  So why did I sigh after reading the response to the meeting reminder?

(more…)

“Deep Integration” is a waste of time

Posted under Java, Rails, architecture, scalability by Anthony Chaves on January 20th, 2009. 2 Comments »

It’s 2009, right?  As an industry we’ve cast off heavyweight solutions and processes in favor of lightweight software and Agility.  Now we create RESTful APIs as part of this push for more meaningful software development.  Web applications communicate with each other via RESTful APIs these days.  YouTube, Yahoo!, Twitter, Facebook, Google Apps, Digg, everyone has a RESTful API.  Integrating two applications has never been easier.  Punch a hole in the firewall for a known host on the other side, give their developers an API key and let them get to work.  Couldn’t be easier, could it?  This is why you’ll never believe what I heard last week.

(more…)

Scalability round-table/forum on January 28

Posted under Java, Rails, Ruby, architecture, database, scalability, spring, sql by Anthony Chaves on January 13th, 2009. Comments Off

The Boston Scalability User Group is hosting a technology round-table meeting on Wednesday January 28th at 6 p.m.  The meeting is at the IBM Innovation Center in Waltham, MA.

This is the first time we’ve done the round-table style meeting and I’m excited to see how it goes.  Guests are encouraged to come prepared with questions, answers and opinions on application scalability tools, strategies and designs.  Hot topics will include platform and software stack, cloud computing and resources, vendor tools and support and CDNs. Those are my guesses about hot topics doesn’t mean the meeting is limited to those topics.

Guests, be the regular or first-timers, will drive the direction of the discussion.  We’ll talk about solving technical problems based on past experience or serve as an advisory panel on where and when to use a particular tool.

Full meeting details are at the BostonSUG web site.  We ask that you sign up for the meeting at the meeting registration page so we have an idea of how much food to buy.  There will be snacks and bottled water at this meeting.

Hope to see everyone on the 28th at 6 p.m.!

Rails and Restful Authentication

Tags: , ,
Posted under Rails, Ruby by Anthony Chaves on July 11th, 2008. 3 Comments »

It’s been quite a while since my last Ruby on Rails post so let’s go over a little “gotcha” that you might encounter when using the restful_authentication plugin.

Getting started with restful_authentication is fairly easy.  After installing the plugin it’s just a matter of running the following generate command:

script/generate authenticated user sessions

This will create a migration for a users table, a model and controller for users and a sessions controller.  It will also add some named routes to config/routes.rb.

So far so good, right?  Well, a common mistake when generating the model and controllers is to user the singular form of both user and session.  The command will run successfully and do exactly what you told it to do.  You won’t become aware of a problem until you try to log in for the first time and see this:

NameError        in SessionsController#create


uninitialized constant SessionsController


RAILS_ROOT: C:/rails/bookmarks


Application Trace |             Framework Trace |             Full Trace






Request


Parameters:


{"commit"=>"Log in",
"authenticity_token"=>"0c0f07222da8ed58d8c6ebcafb9bf32f0bc84143",
"login"=>"anthony",
"password"=>"mysupersecretpassword"}


Uh oh! what went wrong?  It looks like Rails is looking for a controller called SessionsController.  But we generated one named SessionController.  Why is this happening?  Take a look in the views/session/new.html.erb file.


<% form_tag session_path do -%>


<p><label for="login">Login</label><br/>


<%= text_field_tag 'login' %></p>


<p><label for="password">Password</label><br/>


<%= password_field_tag 'password' %></p>


<!-- Uncomment this if you want this functionality


<p><label for="remember_me">Remember me:</label>


<%= check_box_tag 'remember_me' %></p>


-->


<p><%= submit_tag 'Log in' %></p>


<% end -%>


The form_tag target is session_path.  session_path is created for us by magic because of its mapping in routes.rb.


map.resource :session


When mapping a resource like this Rails looks for the controller with the pluralized name of the resource name by default, which means session_path is getting SessionsController.  We can change the behavior by explicitly setting the controller for the resource.


map.resource :session, :controller => :session


Try to log in again and you will be authenticated!  Of course it may just be easier to remember to use the pluralized name of whatever controller you want to use for managing sessions.
« Older Posts