Shared Repository Model and Version Control Anti-Patterns

Shared Repository Model

The Shared Repository Model is prevalent with small teams and organizations collaborating on private projects. Everyone is granted push access to a single shared repository and topic branches are used to isolate changes.

Pull requests are used to initiate code review and general discussion about a set of changes before being merged into a mainline "master" branch.

Decide whether to use Feature Branches

If you have very few developers and you are using git as more of a source repository than a fully featured version control system, then consider committing files and merging directly to master;  Otherwise, you should probably be using feature branches.

Use Reasonable Workflow and Project Tracking Tool

When you use feature branches you should follow a reasonable workflow such as github workflow.

• Store User Stories/Requirements in Project Tracking Tool (Jira / Pivotal Tracker / RTC)
• Track feature stories by tasks that are assigned a ticket/tracking number
• Reference ticket number in feature branch name
• Developer creates feature branch, commits file changes and then submits a Pull Request
• Other developers are notified of Pull Request, perform code review and the last one merges the feature branch to master ***

*** The last developer to perform the code review may need to perform work to merge feature branch code with master -- which can happen with other developer(s) have changed code pertaining to the feature branch between the time the feature branch was created and when the feature branch is submitted for code review via the Pull Request.

Merge

Reasons to Merge

• When developers create feature branches
• Multiple developers are working on same branch and you want to see each persons contributions separately
• Clearly delineate feature branch work from merge work
• Slightly easier to do when developers merge directly to master

Rebase

Reasons to Rebase

• When developers merge directly to master
• Keeps git history clean when not using feature branches (avoids "merge bubbles")

Team Development Workflow Anti Patterns

• There are multiple developers and you are not using feature branches
• Management is emailing spreadsheets around to track progress
• There is no project management software in place
• The PM software is not integrated with the version control software (github)
• There is inconsistency with usage of PM or version control software among team members

iPad and iPhone Users Get 50 GB FREE

iPad and iPhone Users Get 50 GB FREE. Get Your #Box50GB Now!

By Mark Saldaña

This 50 GB promo for iOS ended in December 2011. If you have an Xperia or LG Android device, check out ouractive 50 GB promos to learn how to get free space in the cloud.

As evidenced by the overwhelming crowds during past iPhone and iPad launches, it’s clear that our lives revolve around mobile. That’s why we’re happy to announce that we’re giving away 50 GB of free storage to anyone who uses a free Box Personal account on an iOS device. That’s right, it’s 50 GB in the cloud completely free, forever. Your 50 GB of storage isn’t just limited to your mobile device – you get it anywhere you use your Box account, like on your laptop at home or your desktop at the office.

This promotion only runs for 50 days, so get your free space in the cloud by following these steps:

1. Visit the app store and download the Box app for your iPhone, iPad or iPod touch
2. Log in to your account or register for a new one directly from the app
3. Start sharing and collaborating in the cloud
4. (optional but recommended) Tell the world how you’ll use your 50 GB with the hashtag #Box50GB 

Keep in mind you’ll need to download or update to the newest Box for iPhone and iPad app, version 2.4.3, then log into Box in order to get 50 GB. Something else cool: Your account will have an increased file size upload limit of 100MB instead of the usual 25MB!

We also updated our app with a few features that’ll make your free 50 GB even more powerful. Using AirPlay, you can now wirelessly stream Box content to an Apple TV for effortless projection of photos, videos, presentations and more. Of course, Box gets even better when you use it with others, so be sure to tell your friends, colleagues, and really, anyone with an iOS device to take advantage of this offer before it’s over.

When we originally launched our iPhone app three years ago, we suspected our users would get pretty pumped about sharing and collaborating from anywhere. In addition to the tremendous amount of interest we’ve seen with our own app, mobile adoption across the entire tech industry has been massive. For example, analysts estimate that over 100 million people will have iPads or iPhones by the end of this year; to put that figure in perspective, that’s larger than the entire population of France by a pretty huge margin – nearly 30 million.

The future of mobile is about being free of storage restrictions and closed systems. With this offer, all iOS users will see the benefit of having all of their critical information available at their fingertips, from anywhere. And if you’re already using Box, I’m sure you won’t mind getting some extra room in the cloud. Be on the lookout for tips, contests and other info about your free 50 GB over the next 50 days.

Welcome to the cloud!

OFFER ENDS 2/15/2014 SO HURRY!

References

http://blog.box.com/2011/10/were-giving-ios-users-insane-amounts-of-free-storage-box50gb/

Too Many Specs Failing?

Could be that you simply need to clone the structure of your development database into your test database.

Clone Your Test Database

bundle exec rake db:test:clone

Notes

• The only specs that pass when the test database is not configured properly should be tests that don't reference the test database
• db:test:clone is just a combination of db:schema:dump and db:test:load
• db:test:load is the same as db:schema:load, but it runs against the test (not development) database

Run Specific Rspec Tests Under Specific Directory

You can run specific rspec tests under a specific directory by

• specifying the directory
• using an rspec tag option

For example, if you want to run model specs that you've tagged as work in progress (wip) do the following:

Add tag to spec

require 'spec_helper'

describe HomeController do
  render_views
  it "Logs in Person with non-blank name", :lex_tag => 'wip' do
    person = Factory(:Person, name: "non-blank name")
    get :login
    response.should redirect_to(people_path)
  end
  it "does not log in Person with blank name" do
    person = Factory(:Person, name: "") # blank name
    get :login
    response.should redirect_to(root_path)
  end
end

Run spec like so

$ be rspec --pattern spec/models/*_spec.rb --tag lex_tag:wip

In this example, we are running model specs that do not have a tag named ":lex_tag" with a value of "wip"

Summary

By specifying the directory, you limit the number of specs to run to a logical grouping.

By using rspec tags, you can be very specific about which individual tests you run.

Notes

• You can negate a tag using the "~" character
• To be compatible with the Cucumber syntax, tags can optionally start with a @, that will be ignored. Example: @lex_tag
• There is nothing special about "lex_tag", you can name your tag nearly anything, but using a name allows multiple developers to annotate without confusion.
• You would not want to check specs into your source code repository that had tag names that referenced individuals
• You might want to use tags to group specs according to other user acceptance testing criteria or perhaps tag tests for particular server deployment environments
• So, tags can be used to group specs, not by static folder directories but by any criteria you wish

References

https://www.relishapp.com/rspec/rspec-core/v/2-3/docs/command-line/tag-option#exclude-examples-with-a-name:value-tag