Thought Into Motion

2Contenders Launches!!

Where to being.   2Contenders is a website that we have been playing with as a pet project and we have decided to launch it as a real site for everyone to use.  The concept was born from a couple of simple arguments over movies, games, and hypothetical situations.  The site allows users to pit any two contenders against each other in a fictional battle.  Other users then vote on who they feel should win the battle. 

Over the next couple of posts I am going to be talking about some of the unique challenges we encountered while building the site, and how we got around them.

But in the meantime.  Please check out the site, and join the fun.

www.2contenders.com

Session Data Storing Not Storing?

So today I had to debug a problem I had with one of my clients applications.  In the session I was storing how a page was being sorted.   The problem was that the sort was not saving to the session properly.  My model was setup with a has_many relationship to another model.   It was in the second model that I was storing some information. But when I would retrieve it from the session the values were going back to the default.   Below is a example of how I was using the session.

sort.columns.set_id = 2

session[:sort] = sort

Now at the beginning of my list action I would pull back the sort from the session so I could compare the values.  

col_id = session[:sort].columns.set_id

I was expecting to get 2 when I checked the value of col_id.   Instead I got the default of 1.   It seems that the session was not saving the stored value for the column object.   I might be doing this wrong but I would have expected the columns model to persist the correct value as it was being accessed through the sort model and the sort model was being saved to the session.

To make a long story short, be careful what you store in your session, and always check your values before assuming they are right. 

Partial Component Rendering

Recently for a project I needed to integrate thickbox to display some content.   Shortly after I got thickbox working correctly I discovered that I needed to add authentication to the panel I was displaying. My problem was how to catch the intended url and then redisplay it after the user had logged in, oh and of course I wanted to do this all with AJAX.

Once I got the authentication call working correctly I ran into a problem with rendering the intended action back to the form within a single ajax call.   My first attempt was rendering a partial to a string and then passing the string back.  It looked something like this.

      rt = render :partial => "#{session[:intended_controller]}/#{session[:intended_action]#}"

      render :update do |page|

        page.replace_html 'modal_login', rt

      end

The problem with this attempt was that the partial required database calls and things that were being generated within the controllers action.   So what I really needed to do was call the other controllers action with the "params" hash from the original call.  

After looking through all the render helpers I stumbled across the render_component method.   This seems to do the trick.  Since I captured the original controller and action, I can simply call this and store the result in a variable.   So I changed my two lines to look like the following:

      rt = render_component :controller=> session[:intended_controller], :action => session[:intended_action]

      render :update do |page|

        page.replace_html 'modal_login', rt

      end

Now this generated call the controller and action, but I still had two problems.  My first problem was in passing the original "params" hash to the action.  My second problem occurred due to the component call causing a double render error.   The first problem is solved by adding another option to the render component call :params => session[:intended_params].  The second problem was solved when I found a bug ticket referencing the render_component_as_string method.  

After changing this last two things I was able to get controller action rendered correctly and returned to my thickbox window via ajax.  Below is the final code that I placed in my ajax authentication routine.

      rt = render_component_as_string(:controller=> session[:intended_controller], :action => session[:intended_action], :params => session[:intended_params])

      render :update do |page|

        page.replace_html 'modal_login', rt

      end

MacRuby

I was reading one of my favorite blogs to today (Thought Palace) and I came across this interesting post called MacRuby. It seems that Apple has created an open source project for porting the Ruby language to run on top of Objective-C. In essence this would eliminate the need for the scripting bridge called RubyCocoa.

After playing with RubyCocoa and building a couple of smaller applications in it, I think this is an excellent move by the apple guys. The power of ruby with the speed of Objective-C will only bring a new of developers to the mac platform.

For more information check out the post on Thought Palace or visit the offical apple website for the MacRuby project

Five Good Logging Tips

Having your application create log files can be the difference between effective and nonexistent remote support ability. As IDE's become more prevalent in development shops it would seem that the art of logging has started to decline with developers. Good logging in an application takes time and can be the best debugging tool you have. Conversely, poor logging can lead a developer down the wrong path wasting time, energy, and money. With this in mind I present to you my top 5 logging tips

1) Use A Framework

There are many open source logging frameworks that can make your life much easier. As developers we like to have control over the nitty gritty details, but reinventing the wheel to implement logging is a waste of valuable cycles when there are so many good free logging packages out there. My personal favorite is the Log4j framework. While this framework was made by the Apache foundation for the java language it has been ported into many different languages.

2) Practice Practice Practice!!!

How many times have we all heard that growing up. When it comes to logging practicing does help developers by helping them form a good habit. If you get used to logging, even in your smallest scripts and programs then when it comes time for the big project you will not even think about where and when to log, it will be done by instinct.

3) Read Your Own Logs

This drives me crazy!! How many times have you been handed a huge log file only to start reading it and you realize that it is complete gibberish. When you are developing the code, you know what to expect and you tend to shortcut your logging strings. If you are going to take the time to log a message make sure you are saying something that will make sense. Before you promote or release your code, hand someone some of your log file and ask them to read it. If they can get the jist of what is happening then you are in good shape. If they look at you like you have 3 heads then you might want to look it over.

4) Develop A Standard

A coding style is unique to a developer. With any language there are multiple ways to do the same things. This is also true in logging. Take the time to developer your own logging standard and try to stick to it. The easier your logs are to read the faster you can get to the root of the problem. Also the more standardized you make the message the easier it will be for your co-workers to help debug your program. This can be the difference between a 3am phone call and a peaceful night of sleep.

5) Don't Be Sloppy

Take 5 min during your development time to make sure you logging is clean, concise and presentable. Over the course of your development and the thousands of lines of code you are writing there is no way you are going to remember what your vague log statement meant. Or worse your boss gets a log file from the latest build and you forgot to take out that late night comment you put in about his hair peice. No matter what the situation is when you release that log into the wild you have no idea who will be reading it, so make sure you mean what you say.

Lastly, I wanted to write a quick tip for those of us working in loosely typed languages like perl and ruby. Don't always assume your string is a string. Most languages have a way of finding out what type or class a variable is. Get in the habit of adding this information to your log statements as well. I tend to add this information surrounded by parentheses in my log statements. This information will save you major headache and many wasted hours when you start seeing strange behavior because that argument you swore was a string happens to be an int.