Technical Notes » Rails http://blog.anthonychaves.net Life is software and jujitsu Tue, 16 Feb 2010 22:15:16 +0000 http://wordpress.org/?v=2.9.1 en hourly 1 Dummy Code (Quick’n'Dirty vs. Engineered) http://blog.anthonychaves.net/2009/02/04/dummy-code-quickndirty-vs-engineered/ http://blog.anthonychaves.net/2009/02/04/dummy-code-quickndirty-vs-engineered/#comments Wed, 04 Feb 2009 22:34:13 +0000 Anthony Chaves http://blog.anthonychaves.net/?p=125 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.

Building software modules within a team requires communicating, at a minimum,  method or class signatures and a general idea of the functionality.  This may include a detailed design document clearly specifying method signature and a pseudo-code implementation or method stubs and comments about what the method should do right in the source file.  One thing that should never be used for communicating a signature and functionality is dummy code.

Dummy code looks like real code.  It is real code but it rarely works.  Even if it compiles it doesn’t produce the correct result when run.  Nor are there any tests that prove it (in)correct.  Dummy code exists only for the sake of its author’s gratification.

Rather than talk about the desired functionality through some more productive means the dummy code author thinks he is helpfully providing a guesstimate of correct implementation.  What he has actually done is provide a jumbled mess of non-working code cleverly disguised as a working part of the project when he checks it in to the SCM.  The dummy code author thinks someone else will come along and provide the correct implementation “later”.

What he doesn’t realize is that his dummy code is almost indistinguishable from code that should be part of the project.  The next person to try to reuse this code is in for hours of WTF moments trying to figure out WTF the code is supposed to do and why it’s got code branching five levels deep.

At my first post-college job I had a wonderful mentor.  Thys (pronounced Tays, like “taste” without the second ‘t’) and I were talking one day when he asked me a question.  “Anthony, if you were given a task of writing software that would only be run once would you do it quick-and-dirty or with a well-measured, engineered approach?”

How bad could “quick-and-diry” be if the software would run only once?  I thought about it for a moment before answering.  Quick and dirty.

Thys said he would never write quick and dirty software.  Doing so figuratively creates a  monkey on the developerment team’s back.  The software that only needs to run once inevitably needs to run a second time and a third time and eventually run regularly.  Thys helped me realize that software evolves and escapes.  Useful software will run indefinitely.  Any time and effort saved on the initial write will be lost 10 times (I made that number up.  It is actually higher.  Any want to provide real data or examples?) over on the maintenance, bug fixes and rewrites.

Writing dummy code is writing software quick and dirty without any idea of the implementation details.  Bad code and bad algorithms.  The worst of both worlds.  It’s been a long time since Thys and I had that conversation but the years have proven him right again and again.  Any code worth checking in to SCM is worth writing well.  That includes unit tests.

Dummy code has no place in SCM.  If you’re not going to correctly implement a method you stub out then don’t provide an implementation at all.  Leave some comments around the method stub if you have to.  Open a ticket in the issue tracking system to let someone know the method needs an implementation and describe the input and output.  Let the implementer determine which algorithms and data structures to use.

Dummy code is a hazard to software projects.  It violates the principle of least astonishment.  Next time you think about writing some remember that the next person that uses the code will waste time figuring out why it doesn’t work as expected.

If you check code in to your SCM where other people can pull it, take a look at what you’re checking in.  Does it work?  Does it work well?  Are there tests that prove it?  Helping someone by coding less is sometimes the best help of all.

]]> http://blog.anthonychaves.net/2009/02/04/dummy-code-quickndirty-vs-engineered/feed/ 0 Industry Ignorance http://blog.anthonychaves.net/2009/01/22/industry-ignorance/ http://blog.anthonychaves.net/2009/01/22/industry-ignorance/#comments Thu, 22 Jan 2009 22:27:41 +0000 Anthony Chaves http://blog.anthonychaves.net/?p=106 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?

I don’t make any money running the group.  In fact it costs me money.  I do a good amount of planning, coordinating, buying, booking and raffle prize finding for the group.  I love seeing 30+ people show up for our after work meetings.   It’s a lot of work but I do it because I am passionate about emerging trends in application scalability.  It’s a labor of love that I find professionally and personally rewarding.  Like all good geeks I maintain a healthy hobby writing software outside business hours.

I’m interested in building bigger, better software.  Batch applications, database interactions, web applications, CPU intensive algorithims should be as effective as possible.  Effective does not necessarily mean efficient.  Effectiveness is based on price, time-to-market, performance, maintenance cost, etc.  Analyzing these facets is important. The tools used to arrive at the solution are important, too.

BostonSUG has wonderful speakers who generously donate their time to speak at our meetings.  These people come in from all over the country.  Just a few examples, we’ve hosted Orion Letizi and Nikita Ivanov from San Francisco, Billy Newport from Minnesota and Mike Culver from Washington.  We’ve had numerous local speakers who we appreciate just as much as those that fly to see us.  Patrick Peralta, Tom O’Hare and Rakesh Chaudhary had large audiences.  Each of these speakers is an expert in a different facet of building scalable applications.  They are industry leaders in compute clouds, data grids, object caching, streaming media and more.

One thing we haven’t touched yet is building a web site that performs well.  The person that replied to the meeting reminder said:

save your time:
only put strings in session; and only put one item per-user in the session; unless they are doing some heavy form processing.
use native clustering.
put professional load balancer in from.
max pipe.

Thanks.  That is a helpful reply.  It immediately invalidates the hours of insightful discussion we’ve had at past BostonSUG meetings that have spent less than five minutes total dedicated to the problem to which he so generously offers his solution</sarcasm>.

traditional-web-architecture

This is a picture of what is described in the reply post.  As an industry we have known this works for a long time.  That’s why we don’t talk about the architecture depicted by this diagram at BostonSUG.  Sure, we’ll talk about HOW an app server achieve scalability.  We’ll talk about the implementation, not just about using JBoss or Mongrel.  We got a good look inside GridGain.  We had a guided tour around Terracotta.  BostonSUG evokes deeper discussion than “small sessions, load balancer, database cluster, done!”.  You should do that anyway.

Past meetings aside we have a lot to talk about this year.  Rails 3, Java 7, CloudFront, Hibernate Shards, Google AppEngine, tons of topics that push the industry foward.  If you’re interested in evolving and not building the same old software then come to BostonSUG.  If you’re interested in building what we know works (and have known since pre-2000) then it’s not the meeting for you.

I didn’t intend for this to turn into a meeting plug but I might as well include the link to the meeting announcement.  Wednesday January 28, 2009 @ 6 p.m.  IBM Innovation Center Waltham, MA 02451

]]> http://blog.anthonychaves.net/2009/01/22/industry-ignorance/feed/ 4 “Deep Integration” is a waste of time http://blog.anthonychaves.net/2009/01/20/deep-integration-is-a-waste-of-time/ http://blog.anthonychaves.net/2009/01/20/deep-integration-is-a-waste-of-time/#comments Tue, 20 Jan 2009 12:53:58 +0000 Anthony Chaves http://blog.anthonychaves.net/?p=89 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.

I was told, quite authoritatively, a better way of integrating with an application is to give the other application developers your messaging system and have them integrate with that.  Not just the message broker but the entire end-to-end message system, producers and consumers included.  I panicked when I heard this because I knew this guy was serious.  He wanted to build an application like this?!

Deep Integration

Deep Integration

The messaging platform needs some kind of web server to handle the RESTful calls coming from the client application.  It needs a message broker, ActiveMQ, RabbitMQ, WebSphereMQ, take your pick.  It needs some way of consuming messages produced by the web/application server.  It needs at least one dedicated server to run it.

Hardening an appliance for use on a customer site is significantly more time consuming and expensive than running that platform in-house.  The appliance has to “just work” for the customer.  The customer also has access to the provider database.  Notice how the message consumer communicates with that provider database through both corporate firewalls.  The provider database is exposed and the customer has a box with the credentials on their premises.

The push for this “deep integration” with the customer was so that their developers wouldn’t have to learn how to make RESTful API calls.  Instead they would learn how to administer the provider platform (keeping the database credentials safe, of course), learn the Ruby/Java/C#/C++ API to put messages on the queue and learn the RESTful API anyway because that’s the easiest way to interact with the message platform.

I can’t help but wonder why the customer needs to be bothered with the provider message platform.  The provider isn’t in the business of providing a message platform.  The provider only needs to provide the services the customer is buying.  Pushing some messaging platform on them doesn’t help them get their job done.  It’s a waste of time, effort and money.  Giving them the messaging platform and saying, “here, you administer it” shows laziness and ignorance in the provider.  What could possibly be gained from making the customer use the messaging platform?  It makes the provider’s tech guys feel good because they worked on what seems like a big, important project.

RESTful Integration

RESTful Integration

Most of the time this works just fine.  Keep your message platforms to yourself.

]]> http://blog.anthonychaves.net/2009/01/20/deep-integration-is-a-waste-of-time/feed/ 2 Scalability round-table/forum on January 28 http://blog.anthonychaves.net/2009/01/13/scalability-round-tableforum-on-january-28/ http://blog.anthonychaves.net/2009/01/13/scalability-round-tableforum-on-january-28/#comments Tue, 13 Jan 2009 21:03:28 +0000 Anthony Chaves http://blog.anthonychaves.net/?p=80 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.!

]]> http://blog.anthonychaves.net/2009/01/13/scalability-round-tableforum-on-january-28/feed/ 0 Rails and Restful Authentication http://blog.anthonychaves.net/2008/07/11/rails-and-restful-authentication/ http://blog.anthonychaves.net/2008/07/11/rails-and-restful-authentication/#comments Fri, 11 Jul 2008 16:28:01 +0000 Anthony Chaves http://blog.anthonychaves.net/?p=54 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.
]]> http://blog.anthonychaves.net/2008/07/11/rails-and-restful-authentication/feed/ 3 Boston Scalability User Group http://blog.anthonychaves.net/2008/02/04/boston-scalability-user-group/ http://blog.anthonychaves.net/2008/02/04/boston-scalability-user-group/#comments Mon, 04 Feb 2008 20:59:16 +0000 Anthony Chaves http://blog.anthonychaves.net/java/2008/02/04/boston-scalability-user-group I’ve been digging around lately for a Boston area user group dedicated to architectural scalability and I haven’t been able to find one. Other user groups that I regularly attend have meetings centered around scalability once in a while, but I’m looking for something with a schedule dedicated to the topic. It’s a hot topic in the industry right now with a lot happening on different fronts and there should be some ongoing professional discussion dedicated what goes into growing an application.

Here are some of the topics I want to talk about:

  • Data growth and access – What kind of DBMS topologies allow maximum scalability without breaking the budget? What if the budget wasn’t a problem? How do you migrate your data model from hundreds of users to millions of users? Should you partition user data across shards or keep it in a central database? How do you profile data access paterns? Is your application mostly-read or mostly-write? When should you use an LDAP directory for data storage? When should you use MySQL and when should you use Oracle?
  • Application server scaling – app server clustering, web server integration, load balancing, application session management, data caching
  • Web Tier – load balancing reverse proxies, data caching, working with HTTP, considerations for exposing functionality via REST
  • Language conisderations and platform choices – Dynamic languages vs. Static languages, Linux vs. Windows, Solaris vs. Linux, RedHat vs. Oracle, IBM vs. Oracle – How do you make these choices? What evaluation critera are most important? Which ones are misleading?
  • Framework scalability – How can you scale if your framework can’t? Does Rails really scale better than Spring Web MVC? Where do PHP frameworks fit in? What are the alternatives? This is where we will investigate what you gain and lose by binding yourself to a particular framework, how to keep the coupling to a minimum and how to use your framework as a solid foundation instead viewing it as a cage.
  • Emerging technology – Should you become familiar with Map Reduce and Hadoop? What kind of impact do object databases have on your application? Should you buy your own Sun or Dell boxes or use Amazon’s EC2 and S3?
  • Application architecture – How do you write an application that scales? What does your application look like as it grows from servicing hundreds to millions of users? How does it handle session management? How does it access datastores? Are there any design patterns that are helpful? What are the anti-patterns to be aware of?

Like I said, I haven’t found a group dedicated to discussing these topics. If you know of one in the Boston area please let me know. Assuming there isn’t one I am willing to start one. I’d like to start off small and meet at coffee shops around Burlington or Lowell. I have no delusions that this is going to start off or even become as big as NEJUG is now. If it starts off as a few people getting together to talk about scalability trends, cool caching solutions and specific products then I’d call it a good start.

The meeting location is still TBD and will be based on how many people are interested in attending. It will probably be somewhere in Burlington, MA. There is no planned presentation at this time. Instead we will have a meet and greet and then discuss scalability trends and news, what approaches to scalability are commonly used now and what are the plans for the future.

If you are interested in coming or in finding out more information please email me at <my first name>@<my domain name>.<my tld> or leave a comment below. Please make sure to include your email address when you fill out the form so that I can get in touch with you – your email address will not be displayed on my site.

]]> http://blog.anthonychaves.net/2008/02/04/boston-scalability-user-group/feed/ 0 render, redirect_to and instance variables http://blog.anthonychaves.net/2006/06/15/render-redirect_to-and-instance-variables/ http://blog.anthonychaves.net/2006/06/15/render-redirect_to-and-instance-variables/#comments Thu, 15 Jun 2006 09:33:49 +0000 anthony http://www.actechnotes.com/blog/?p=11 I rediscovered something about Rails instance variables tonight after initially discovering it a few weeks ago and not writing it down. I spent a good 30 minutes trying to figure out why the following code segment would not produce my expected results in my browser. 

  def save
    @bookmark_file = BookmarkFile.new(params[:bookmark_file])
    @bookmark_file.user_id = session[:user].id
    parse_file @bookmark_file.data
    @bookmark_file.parsed_on = Time.now
    @bookmark_file.save
    redirect_to :action => 'list_parsed_bookmarks'
  end

On the browser side I had: 


      -- unimportant lines omitted --
      -- just display the bookmarks in the collection --

I had an instance variable @bookmark_file with a one_to_many relationship with bookmarks that I wanted to display on the page for a user. Unfortunately when I tried to display the page in Firefox I got the following error: 

You have a nil object when you didn't expect it!
The error occured while evaluating nil.bookmarks

My @bookmark_file instance variable was nil in the view when it was clearly set in the controller's save method. On the surface it would seem that the @bookmark_file instance variable became nil somewhere between the controller and the view. Examining the redirect_to method yields a slightly different answer though.

According to the Rails documentation, ActionController::Base#redirect_to redirects the browser as its name implies. As far as the Rails routing engine is concerned this is a completely new request and all instance variables are thrown out. SO it's not that my @bookmark_file variable was set to nil on the way to the view, rather it wasn't even my @bookmark_file. The new request didn't set any @bookmark_file so there was nothing for the view to operate on.

ActionController::Base#render actually displays the HTML produced by the action or view specified when it is called. By replacing the call to redirect_to with a call to render in the controller the application works as expected because Rails will find the list_parsed_bookmarks view for the controller and use the current instance variables when rendering the view. WIth @bookmark_file already set in the save method the view is then free to use the initalized object.

It may be possible to get the desired behavior out of the original way the method was written by storing @bookmark_file in a session variable but I haven't tried and I don't think it would be a good idea to do so. Using session variables implies that data is shared across requests and creating another request to display the data rather than continue with the current request seems foolish in this situation. The potentially high volume of data stored across all sessions is also a good deterrent.

Any comments are welcome.

]]> http://blog.anthonychaves.net/2006/06/15/render-redirect_to-and-instance-variables/feed/ 2