Recently, we needed to implement a store locator with one of our applications Shop What’s New. You can see the how it turned out on the site (click here and then click on “FIND STORE LOCATIONS” on the right). User can click on any of store locations to center the map on that location, or they can type a search query in the box and map displays the locations closest to that. Try it out!

I will now describe briefly how we implemented this. However, before we start, there is some terminology you should understand since you will encounter them often while working with maps.

Estimating software projects seem to be something of a black art. A lot of has been asked and written about it. However, there is little bit of a method to it as we figured out over past few years over lot of projects.

Since no two software projects are alike, it is not possible to know, accurately, how long something is going to take in advance. So, the only way to really know is to actually start doing the project. And that’s what we do. Well, sort of.

It is probably not a good idea to have your website reachable from both “www.” URL as well as “non-www” top-level URL. As this diverts traffic (and bookmarks) to two different URIs while also possibly splitting up search-engine’s page-ranking. While “www.” URLs have their own advantages (e.g., familiarity, cookie-less sibling subdomain), non-www URLs take at least one less DNS query to resolve and are shorter.

Here is how to achieve the redirection in Rails 3:

In programming terminology, the term “deprecation” is applied to software features that have been superseded and will be removed in future releases. Deprecated features usually generate warning on use and are only present for backward-compatibility, giving enough time to developers to migrate their code to new features.

Boilerplate is any text that is or can be reused in new contexts or applications without being changed much from the original. – Wikipedia.

Even if one of Rails’ mantra is DRY (Don’t Repeat Yourself), we often find ourselves repeating stuff, if not in the same project, at least across multiple projects. How many times have you found yourself configuring the ExceptionNotifier plugin, or SMTP server settings, or capistrano scripts in exactly the same or at least very similar ways? Its time to go meta and stop repeating even across projects. Here are some tips:

We all need to create the static pages with an application — pages like FAQ, About-us, Terms and conditions etc. Of course, it would be extra nice if the site admin can edit those pages without having to deal with the source control system and the like: you know, checking files out of git or svn, making changes, checking it back in and figuring out how to deploy it all on the server. Ah, just try explaining that to your site admin before her eyes rollover, she falls backward with her chair and breaks a rib or two.

Enter CMS (Content Management System). There are a lot of them available in the Rails world. For a nice list see here. Perhaps you just want to pick a plugin from there and run. However, what if you want something really simple, something that just supports the 6 static pages you need and does not add much unneeded clutter to your code base. Turns out you can roll your own really easily. Follow along.

However beautiful the strategy, you should occasionally look at the results. — Sir Winston Churchill

As promised, firstly, the whys

As you probably know by now, Ruby is an interpreted language and along with
the upside of faster development cycle, there is a downside of not having a
compiler: there is no syntax or type checking after you write the
code. Executing the code is the only way to know if its valid and tests are a
great way to execute code.

“Soon you will know, soon you will be one of us” — an ancient interwebs proverb.

Introduction

If you have spent some time learning RESTful way of developing applications
with Rails, you’ve probably been through some tutorials on developing basic CRUD
applications in the RESTful way.

Slides from the recent training I delivered at Hewlett Packard India.

Unfortunately there is no audio recording but hopefully the slides will be be useful to someone

Every application in production needs some sort of database backup scheme. There are plenty of methodologies and several Rails scripts or plugins to do just that. Here’s a brief summary of some of the popular ones:

• ar-backup is a Rails plugin which saves data as fixtures. The data of course becomes database independent. However, to store it safely you will have to push them to your SCM or manage backups separately.
• A comprehensive backup system of DB data, code and SCM to Amazon S3 is on Ruby Inside
• here is a simple rake task to take a mysqldump and push it to S3. There is no scheme for rolling backups, but if you want a simple solution, this may be enough.
• For a large database where full backups may be expensive, see this. There’s also a Rails plugin using this, however at the time of writing it seems incomplete.
• The awesome guys at Collective Idea have a polished Rails plugin: for backing up the database as fixtures. It also has some nifty features like ability to pull data back into development server. Read about it here
• Finally, a novel approach of backing up the database in a Git repository which seems will work for databases which are not growing very rapidly.

However, surprisingly, none of them fitted exactly what I needed and so I decided to roll my own. Also, it is quite straightforward as you will see. This is what I wanted from a DB backup system: