Collaborative Git branching strategies

Lets talk about some Git branching strategies for a cohesive, collaborative development environment. This should successfully work even for globally distributed teams, as long as people use the following guidelines, while naming their branches. Just to reiterate, I assume you are comfortable with the various git concepts, such as branches, tags, pull requests.

master -  should only hold code run through the complete regression cycle and ready for release, each product release should be separately tagged in the master branch.

dev - should include the latest feature-complete development code. Hence code in this branch is feature-developed and feature tested but not necessarily full regression tested.

feature branches - should be branched out of dev/another feature branch and should only include development code. Once the feature is developed and tested a pull request should be raised, which once reviewed should merge the feature branch back to its parent branch.

feature branch naming strategies - feature development branches should be named using the following format : -

Developer Initials/parent branch_feature_name_feature_ticket_num, 

The reason behind the use of a back-slash '/' after the dev initials is; this would help us group all branches created by a particular developer in most git GUI tools.

E.g if Donald Trump is working on a Jira ticket named 1234 - UI Fixes and the parent branch is dev, I would suggest the feature branch should be named in the following format : -

dt/dev_ui_fixes_1234

Moreover always merge branches back to their parent branches using a pull request, followed by a code review by your peer. And please don't forget to delete your feature branch once its merged back to its parent branch.

If you have comments/feedback please share them below.

Clean Code Architecture

There is a lot of hoopla ongoing in the software world with the term 'Clean code architecture'/'Onion architecture' introduced by 'Uncle Bob'. Here I would like to illustrate on it, without all the hoopla!

Over the years I have developed several apps using the Clean code architecture - and I feel it can be suitably described as an extension of the best practices preached by several of the 'dyed in the wool' enterprise frameworks like Spring. So lets get on with it:-

What is it?

As I said its a bunch of architectural best practices which has long been promoted in the Spring (and other enterprise-y) web development community. Its an architectural pattern based on the SOLID design principles and incorporates a layered architecture, where each layer interacts with the layer below it and pushes data to layer above it.


What do I gain from it?

Well finally this might be your fool-proof way to develop SOLID code. What you do is develop code based on your application 'use cases' and group them together based on clearly defined responsibilities. Usually the components can be grouped in the following categories: -

• Views - its the presentational layer and is strictly responsible for displaying the 'formatted' data and nothing else.
• ViewModels - its the model for the view, to illustrate further its a set of data structures, that contain formatted data to be displayed by the view.
• Controllers/Presenters - they are the conduit/pipe between the views and the rest of the system. They inform the application of user interaction and push updated system data back to the view in a suitably formatted format.
• Interactors - they hold the application specific use cases and manipulate the system data in accordance with the requirements of the specific use case.
• Repositories - this is where the system data is stored, usually every entity has its own repository and the repository stores the system data related to that particular entity.
• Entities - they are the business objects of an application, e.g. a Customer entity in a Billing system etc.

You can find more information about each of the several layers here and here.

Its also very important to observe the Dependency rule, items in the list above depend on items below in the list and not the other way. Just follow the arrows in the picture below, they clearly illustrate the dependency flow. Its always pointing inwards.

As like anything else I would forbid you to copy it blindly, but rather soak it in, understand it, and then use what works for you - you can certainly use this document as your guideline. Also please ensure to visit the several other links in this document to learn more about it.

Where can i learn more about it?

Sample iOS App demonstrating Clean code architecture.

Setting up Rails 4.0 on Windows 7 X86/X64

If you are searching for a step by step guide to setup Rails 4.0 on a Windows 7 machine (x86/x64), please follow the steps below one by one : -

Please fetch your Ruby 2.0 (x86 version only) windows installer from here.

Install the downloaded Ruby 2.0 installer, while selecting the following 2 options: -

1. Add Ruby install path to your environment variables
2. Associate with ’.rb’ files

Please open a command prompt and then type : -

1. ruby -v, check it displays the installed ruby version correctly.
2. gem -v, check it displays the installed gem version.
3. gem update –system –no-ri –no-rdoc

Please fetch your Ruby 2.0 devkit (again x86 version only) from here.

Unzip your downloaded devkit zip and cd into the extracted directory and then type : -

1. dk.rb init
2. dk.rb install

Please fetch your SQLite 3 dll from here and copy the contents of the downloaded zip in the ‘bin directory’ under your Ruby installation directory.

Please open a command prompt and type the following commands : -

1. gem install rails –no-ri –no-rdoc
2. gem install sqlite3 –no-ri –no-rdoc

If all of the above commands completes successfully, you are finished with your rails installation. Please start your sample project by typing : -

1. rails new <projectName>
2. cd into ’projectName’ directory
3. type ’rails server’
4. browse to localhost:3000.

Enjoy!!!

Alternatively while installing the various gems using the command prompt you can skip the ’–no-ri –no-rdoc’ appendage if you want to install the ruby doc that comes with your gems.

Setting up BDD with RoboSpock/Robolectric and Android Studio 1.1.0

Please follow the following steps to enjoy fast BDD from within your Android Studio ; -

1) Please ensure you are using Android Studio 1.1.0 or higher.

2) Please enable the 'experimental' Unit Test support feature from within the preferences pane of Android Studio

3) For projects created using older versions of Android Studio please migrate to the latest 'Android Plugin tools' version from within the Project Structure dialog box.

4) Add the following line to your app module's build.gradle file

testCompile 'org.robospock:robospock:0.5.0' // for RoboSpock
testCompile 'org.robolectric:robolectric:3.0-rc2' // for Robolectric

if you are using the Android Studio UI to add the dependencies - please ensure the libraries are added using testCompile and not androidTestCompile by inspecting the build.gradle file textually.


5) Please change the build variant on the 'Test Artifact' section of your App to 'Unit Tests' from within Android Studio.

6) Add all your TDD/BDD classes under the 'test/java' folder under src folder.

7) For Mac users - please edit the default JUnit run configuration's 'Working directory:' field to $MODULE_DIR$. For more information please click here.

8) Right click on any Test function/class and select 'Run'


More tips : -

i) Right click on any class/function and select 'Go To' -> Tests to create your Test Class automagically.

ii) Under build configurations click Edit-Configurations -> Defaults->Junit->Before Launch make with Gradle-aware-Make as shown below.

iii) For more information please click here.

iv) For a sample Robolectric project template, please click here.