In my previous post, I got a bit nostalgic! However, ever since I posted the first one, I was looking for another post on the series. Trying to capture what I learned during the past 3 years, I found it would be really time taking for me and my readers. So, I sort of compiled the following list in this post. Hope it helps someone who is just eager to learn about software.

Sighs! Back then, on Friday, May 26, 2006, I was a final year undergrad student at CSE, BUET. I was looking for a part-time software dev job opportunity and found a little one page advert for a student job at asha-technologies (lately renamed as Code71). Visited their website and thought it might be worth giving a try! As usual, I was interviewed over phone and enjoyed a long 2 hour interview on premise.

Rails models are no exception compared to the super models! You are in the business if and only if you got a good physical structure and can stick to it for years... At Code71, we are keeping our rails models attractive following a few guidelines. I will be posting these guidelines in a series and here goes the first one - about the physical structure of the ruby on rails models.

Naming conventions play an important role to the software's overall architecture. It is not a rocket science, still, it may lead to unhappy consequences if not taken care of at the early stage of a project. This small best practices can make a code base significantly improved. Rails does a good job by using the dynamic power of ruby and providing with a handful of dynamic methods with the models.

In most web applications, breadcrumbs offer a nice way to trace back to previously visited pages. However, generating the breadcrumbs and showing them on dynamic pages sometimes need special care for the following reasons- The links of the breadcrumb may contain dynamic links. It is used in all the pages. So, changing the breadcrumb may trigger a series of changes. In ScrumPad, we are using ruby on rails. There are a few plugins to help rails projects in managing breadcrumbs, but none seemed to satisfy our need.

In my previous post, I said about being incremental. Here come the next thing, being “ITERATIVE”. A prefer the term Sprint than Iteration. So, once you decided to take small increments, make sure you reach the targets sprinting. I suggest you prepare for sprinting with the right techniques and tools. A few recommendations- Never miss a daily standup meeting. Spend only 2 minutes (or less) per person answering the three questions – what did you do yesterday, what’s on the plate for today and what is blocking the race?

In my previous post, I said about being incremental. Here come the next thing, being “ITERATIVE”. A prefer the term Sprint than Iteration. So, once you decided to take small increments, make sure you reach the targets sprinting. I suggest you prepare for sprinting with the right techniques and tools. A few recommendations- Never miss a daily standup meeting. Spend only 2 minutes (or less) per person answering the three questions – what did you do yesterday, what’s on the plate for today and what is blocking the race?

I was talking to a friend of mine, who started a IT start up and working full time with a few others to foster the business. He was telling me- “We have 13 projects running at this moment. We are working our heart out. But, we are not finding any time to do Test Driven Development, Continuous Integration and all the good things…” Well, I understand how it feels! As the title says, “Its easier to get lost!

As Scrum and Agile processes tell you, do it in small sprints, 2 weeks preferably, and go incremental. Take a small piece at a time and sprint. I took this image from internet and credits to this site. It’s easy to work out the Natural way than to defy it! If you are iterative and incremental, you are reaching towards the right hand side of the image! And to make the evolution faster, I suggest you try out Scrumming with ScrumPad.

At ScrumPad most of our controllers are bounded by filters for authentication/authorization. Some filters apply to all actions in a controller while others apply to only a few or leave out only a few. However, since we are following TDD, we need to test the filter is invoked before each of the desired action. This makes the test code MOIST (not DRY)! Example of Moist Code: The following example only captures two test methods.