murmuration : the coordination of an agile team.

In order to achieve extraordinary coordination, starlings flock in formations called murmurations.  These formations behave mathematically similar to metals becoming magnetized and snow crystals before an avalanche.  These are examples of systems where collective phenomena emerge from the short-range interactions of individual participants.  Studies show that change in direction (orientation) of individual participants affect group behavior more than velocity.  This sort of relationship is known as a scale-free correlation.  In this presentation, I will discuss how the concepts associated with murmuration, along with engineering and teams practices can be applied to software teams, in order to reach a state of criticality.

more to come later.

Posted

creating pull requests between two separate github repos

I had a need to maintain a public github repository for the purpose of a Jekyll site.  The site will be used for an internal communications mechanism.  The repository is public, but only a handful of collaborators will be allowed direct access to the repository.  Everyone within the company will have the option to fork and pull-request if they desire changes to the content/structure.

Unfortunately, Jekyll does not provide a clean mechanism to prevent the early release of content.  Basically, if the content is created... anyone forking the repository will be able to consume the data.  Not the desired outcome.

So... I decided to keep the public repository with minimal collaborators and the ability to fork/pull-request.  In order to prevent the early release of data/content... I have adopted the creation of a private repository, only accessible by the collaborators (the same few as the public repository).  Work will be committed to the private repo and pull requests will be created to migrate content from private to public repo.  This is not a common workflow, at least not one that I would call common.

Here is how I accomplished this...

------------------------------------------------------

before you proceed... I would highly recommend you install 'hub'... assuming you are utilizing brew... you can install via -> brew install hub.  I would also recommend putting an alias within your 'profile' (alias git=hub)

------------------------------------------------------

from this point forward, all of our changes should be made within the 'private' repository

Clone the private repo so you can work on it:

git clone https://github.com/ACCOUNT_NAME/private_repo.git
cd private_repo
git checkout -b [branch_name]
[make some changes]
git commit
git push origin [branch_name]
git pull-request            --- this will create the pull request on github... from your branch to 'gh-pages'

someone will need to merge the pull-request within the private repo (rinse and repeat)

Note: we should not be pulling changes from 'public-repo'... it is possible, but
we should consider 'public-repo' as the production release and we should only apply pull-requests to this repository.

------------------------------------------------------
when we are ready to publish to the world... create a pull request private repo -> public repo

git clone https://github.com/ACCOUNT_NAME/public-repo.doc
cd public-repo
git remote add private_repo https://github.com/ACCOUNT_NAME/private-repo.git
git checkout -b [branch_name]
git pull private_repo master
git push origin [branch_name]
git pull-request

*** 'git pull-request' is dependent on 'hub' installation
*** follow these steps each time, but DO NOT execute the 'remote add' after the first time

my solution to Kata Battle - Pillar November 2015 Monthly Meeting

I created this kata, based on an existing list of acceptance tests. I have placed the 'Acceptance Tests' within the e2e package. The e2e package only executes during the gradle 'accept' task. The acceptance tests were written as part of a Kata Battle at the November 2016 Monthly Meeting.

I started the kata with no personal unit tests. The acceptance tests were designed to be executed after the local solution was complete.

My unit tests are located within the 'trend' package, named TrendUtilsTests.

To run the local unit tests... > gradle test

To run the e2e acceptance tests... > gradle accept

https://github.com/ddaugher/trendCalculatorKata

Posted