Thoughtbot, Github and PlataformaTech shared their development flow over the past few months. Our development flow differs quite a bit as well as our Product Management process so we believe that they are worth sharing!

Flow

VersaPay development flow features:

• 2 week iterations
• planning poker
• feature branches
• CI against all branches
• code & UX review
• QA
• deploy at the end of each iteration

Tools

To support our workflow, we use a couple of well known open source tools, and a few we’ve built ourselves and released on Github. We use the following well known tools:

• redmine – A ticket management system.
• redmine backlogs plugin – UI to sort and group features per iteration.
• jenkins-ci – Continuous Integration server.
• gitorious – Open source Github like.

We developed the following tools to support our work flow:

• gitmine – A command line tool for Git and Redmine!
• Alfred – A dashboard linking Git branches, Redmine and Jenkins.
• viewcumber – Cucumber formatter to browse your application by clicking through your cucumber scenarios.
• mothership – Anyone can deploy in one click!
• jenkins-github-autobranch – Create, Run or Delete Jenkins jobs whenever a new branch is Created, Updated or Deleted on Github or Gitorious.

Each feature is described in a Redmine ticket and will live in a feature branch starting with its ticket number followed by an explicit name. We use gitmine to automate creating, checking-out, reviewing and deleting branches.

Product Management

We used Basecamp for a while. It is a great tool for small projects but the todo … Read more

Website security

When entering private information, be sure to check that the site uses encryption to keep any data you enter on the website safe.

To tell if a website uses encryption, look for a web address with https (“s” for secure) with a lock icon beside it (as pictured below). It may look different depending on what web browser you use.

How do I choose a secure password?

Length and complexity is pivotal to create the strongest possible password. Make it as long as possible, at least 14 characters is recommended. Remember to use uncommon letters, punctuation, symbols, and number combinations. Use capitalization to add complexity.

Microsoft suggests some smart guidelines to follow when creating passwords:

Microsoft provides a password checker so you can test the strength of new passwords before putting them to use.

Some common mistakes made when creating passwords that you should avoid:

1. Words found in a Dictionary (in any language).

2. Words spelled backwards, common misspellings, and abbreviations.

3. Sequences or repeated characters. Ex: 12345678, 222222, abcdefg, or adjacent letters on your keyboard (qwerty).

4. Using your name, birthday, driver’s license, passport number, or any other personal information someone could connect to you.

How do I remember all these passwords?

Using the Mac OS X Keychain Access application or an online storage solution such as Wallet, or LastPass these are all ways to keep your passwords secure. All you need to remember is your master password — these applications remember the rest.

ActiveRecord is great way to ensure your models are valid before saving them to the database. But as you add new validations or update existing ones, some of the existing records could become invalid. Do you have any invalid records in your production database?

It’s too late when you discover there are invalid records in your production environment.

• Maybe a migration failed half way through when you deploy to production “It was working just fine on staging?!”
• You get notified about a weird bug (and you can’t reproduce it on your dev machine)
• Someone sends you an email saying that he can’t buy the dancing banana t-shirt on your webstore (and you’re lucky someone contacted you. How many people went to a concurrent webstore?)

Setup active_sanity, run it and fix your records.

1. Add the following line to your Gemfile:

     gem "active_sanity"
   

2. Run rake db:check_sanity on your production database. You should see something like:

   model       | id  | errors
   User        |   1 | { "email" =["is invalid"] }
   Flight      | 123 | { "arrival_time" =["can't be nil"], "departure_time" =["is invalid"] }
   Flight      | 323 | { "arrival_time" =["can't be nil"]
   

3. Want to store those “invalid records” in the database to check them in your admin interface? Just run rails generate active_sanity to generate a migration and access the data through a model called InvalidRecord.

Run active_sanity against your production environment, say “OMG!” and go fix your records. Deployments will be less stressful and you’re gonna … Read more

When someone receives an email from VersaPay saying that they’ve been sent money, they need to be able to claim their payment no matter what email client they’re using, and whether or not images are enabled.

We’ve come up with some best practices to balance great looks with a high level of usability in our emails and we’d like to share them with you.

First off, here is what one of our emails looks like with and without images enabled:

You’ll notice in both emails (with or without images) the messaging is clear:

1. Someone has sent you money
2. The reason they sent you money
3. Here’s how you get your money

Tip 1: Don’t rely on images, always have a backup plan

Since many (most?) email clients remove images by default, it’s smart to never rely exclusively on images for anything mission-critical (call to action buttons, headings, backgrounds, etc).

You’ll notice that in our emails, the yellow call-to-action button and its text are visible and totally obvious whether or not images are enabled. In the worst case scenario, the user won’t see the nice gradient background but still knows exactly where to click to claim their payment.

This works because we use an image only for the background of the button, but not the button text itself. We also apply the image background with a BACKGROUND attribute and fall back on a plain yellow background color with the BGCOLOR attribute that the user will see if images aren’t enabled.

Example:

<td … Read more

VersaPay’s development team have built the VersaPay app using Ruby on Rails. Our team often uses cucumbers to test our app and Philippe Creux has shared some of their best practices below. We hope you find this post useful!

After (My) RSpec best practices and tips, I’m happy to share my Cucumber best practices and tips! This article will help you organize, clarify and reduce the size of your cucumber scenarios.

1. Organize your garden

Keep your feature files organized by grouping them by business object, then action and context if any. I put all the feature files in the same directory. For instance:

bank_account_add.feature
bank_account_delete.feature
user_signup.feature
user_signup_when_invited.feature
user_login.feature

The steps specific to the application should be organized by business object as well (bank_account_steps.rb, user_steps.rb…). Keep the file organized grouping the steps by Given / When / Then. Do not overload the files generated by Cucumber likestep_definitions/web_steps.rb and support/env.rb with your own steps, helpers or setup code. These files are likely to get overwritten when you update Cucumber so store your stuff in your own files.

2. Custom steps make your scenario DRY and accessible

Scenarios should have the same lifecyle as your code: go Red, go Green, Refactor to make them DRY (don’t repeat yourself) and easy to read. Group multiple steps in one. For instance:

  Given I follow "Send money"
  When I fill in "Email" with "MailGuard('mukmuk','example.com')"
  And I fill in "Amount" with "10"
  And I select "Bank account" from "Source"
  And … Read more