Prevent rails from pluralizing table names

In the Database world, it is the convention for the table names to be singular. Rails irks the pure DB-folks by pluralizing table names. In my previous project, the DBA was terribly upset with the pluralized table names that was created because of Rails and was hell bent on singularization of the table names. I won't blame him for that. In fact, I support it.

But know what Rails is an awesome framework, you can ensure that the table names are not pluralized with a single configuration line in your project's environment.rb file.

Rails 3 and its Sandbox

Rails console has always been a friend in need for the Rails developer. More often, we get to the console to try out some coded snippets to verify and validate our assumptions, either while writing the test cases or during the coded implementation. In this process it is very likely that we end up modifying the state of the underlying database. This inturn can cause some headaches or frustration. Nonetheless you soil the database with junk data. If you are fine with it, then read no further - this post is not for you. If however you are wondering for a way to SANDBOX your play environment from soiling the database, then read on.

Run your console with the command as below:
$ rails c --sandbox 
That is all you need to do to maintain the sanity of your undedrlying database.

So what does this sandboxing do? It keeps journaling all the activities that you do on the database and will undo it all upon exit so that the database goes back to the state previous to sandboxing. 

There are some implications however to working this way though. If you were to run the sandbox on say, development database, then you wouldn't be able to run your DB migrations on your database while the --sandbox is on. Oh!, in fact you wouldn't be able to modify the state of the databases in any manner, be it insert / update / delete records. When you attempt to do it, you would see that the DB throws an error message that reads something as below: 
ActiveRecord::StatementInvalid: SQLite3::BusyException: database is locked: ...

Miniature Code Retreat

I was so excited with the idea of Code Retreat invented by Corey Haines, that I pushed for conducting a miniature version it (with just two sessions of pair-programming) at Dev Camp Chennai, 2011.

My Goal of conducting a Mini Code Retreat

• First and foremost, my agenda was to market the Global Code Retreat that is to happen on the December 3rd of 2011. 
• There are very few corporates that follow TDD, pairing and "refactoring". If folks who can participate in the session, get a good hang of and appreciations for it all, then they would well become agents to market the experience of good practices.
• Its been a long while since I facilitated. I personally wanted to see where I stand in facilitation and see what I derive out of this session as a facilitator.

What I did to achieve my goals

• Dev Camp was a good crowd puller and I wanted to use that occassion to ensure that I give people the taste of what really Code Retreat is all about. Soon after my welcome address, I did a quick poll of how many know of the Code Retreat event that is to happen two weeks from now and then gave an introduction to Code Retreat (early marketing). 
• Kept reading different blog posts etc sharing the code-retreat conduct and facilitation experience, lessons etc.
• Not many folks had a laptop with them in the DevCamp. This was really unfortunate. Made an announcement that only folks with laptop have a entry pass, to the code retreat event. This sort of disappointed the really interested few, some of whom approached me post my introduction. Touched by the enthusiasm, I had arranged for three laptops with the required things setup.
• In the very beginning, I decided to pair-up with someone who is very earnest and equally passionate as much as I was. And I did pair-up with my friend and fellow comrade Ponnulingam, who did all the work that is required to ensure that the laptops are all set-up with necessary SDKs, IDEs, base project set-up with a unit-testing framework.
• At the start of the code retreat session , we set the ground rules, the dos and the don'ts. 
• Gave the classical Mars Rover problem of ThoughtWorks Recruitment to attendees. I choose this problem (with the due permissions from the Recruitment team's lead, Manish), over anything else because the problem is very straightforward. This gives the coders a good opportunity to focus on the ground rules, pair-programming experience, TDD approach and stuff, instead of being distracted to spend endless time discussing the problem statement. Though honestly, I realized they were trying to the same until I was parroting the mantra a few times to stop discussing too much of details, and start coding ASAP after the first 3 minutes. In 5 minutes time, every one started coding.
• Swap pairs after every round.
• Conduct of retrospective at the end of the session helped folks to learn from others goodness/mistakes. It gave them a renewed sense of energy and interest.

Results

• In just two session, it was nice to hear from folks who experienced the joy of TDD (test first/driven development).
• Everyone but for just a single pair weren't comfortable pairing in every session. Interestingly enough, the pairs that reported this were entirely different. I realized in in both these occassions, one of them took things very personally by their stride, and also that they broke the very basic ground-rule of deleting the older coded (the pair that had written the code hung to it and was trying to enforce the further development on the existing code). I wish, I had caught this while I was moving from pair to pair to check on what they do - good and bad, by the time I reached this pair I was only thinking that they had progressed that far.
• As pair facilitators, we decided to rope in another pair to help us out in facilitation, and that really helped. I believe understanding the maturity/skills level of coders is very very important for better facilitation. If the majority find the terms - TDD, pair-programming, refactoring - very new but something that they have heard of and are extremely curious to know it all in one gulp, you need more folks who could get them settled quickly.
• Many felt that they were better able to understand the problem statement as result of pairing.
• There were a few who felt that while at the very beginning they were not so comfortable pairing with experience programmers, became very confident by the end of the session as result of picking up skills from their experienced peer and practice it in their presence while pairing.
• Most of them felt pairing increased their productivity, because they weren't lost in their thoughts and thinking out loud with their pair benefitted them clearly.
• Folks left the room with a sense of enlightened joy, saying they would come again to experience the learning again at Code Retreat.
• In second round, good half of the coders became self-disciplined to TDD. I find this interesting.
• We concluded the Code Retreat with a retrospective, in which we asked people to provide anonymous feedback on their experience of the Code Retreat session in entirity. We split the board into three pies - "What went well?", "What didn't go well", "Puzzles". Once everyone left, my curius eyes went to the Not-well section and found just TWO single-worded sticky(s) with "nothing" scribed in it. Not sure if they meant, there was nothing that didn't go well or that they have gained nothing which isn't well. I read it as the later.

Feedback Received

@kartzontech loved the sessions..looking forward to sessions like these...
— sivaramom (@sivaramom) November 19, 2011

Pictures of the Code Retreat session can be seen here.

Agile Tour 2011, India

Agile Tour 2011, India @ Chennai on 12-November-2011

I had the opportunity to give two extempo lightening talks to the people at this conference. The topics were, "The attitude that an individual and team has to carry when the CI build breaks" and "Planning is important but plans are not". I felt compelled to share my experience and thoughts on those topics,  because I observed that the delegates were discussing about it more and wanted more clarity.

How my talks were received?

Oh I guess, it was well received as many could understand and appreciate it prompting them to talk and ask more questions about Agile post my talks. I doubly enjoyed it, because there were both developers and management folks equally interested to learn more and more by way of discussing things in their mind with me.

Secondly, Preethi Madhu, ThoughtWorks India, Head of Consulting, was happy to provide a very positive feedback to me. Thanks Preethi :)

May I request your feedback on my talks?

If you have attended/participated-in my talk and discussions thereafter,...and have something to share, then please feel to put yout thoughts across by way of comments to this blog post.

Also, if you have published any photographs of the event, please do share them in the comments section and I shall make a reference to it all by posting the links in this blog post.

My views on the overall event

I appreciate Madhur Kathuria (CSC, Product Operations Manager, PegaSystems) and his team, for hosting and organizing the event in a manner that is conducive for open discussions/learnings and for the impromptu lightening talks and open-space event -if it is not for this, the delegates wouldn't have recognized the speaker in me!.

If at all there is something I would wish, it would be that there was a video recording of the session. I would have loved to publish my talks in my blog post :P

Update: The pictures of the even can be found in FaceBook.