Below I put some snapshots from Googl’e chrome release cycle presentation with some comments.

They originally planned this :

And got a lot of troubles with this cycle like :

• Long lived branches, which : Made supporting the branch (i.e. merging changes) more difficult as we drifted further from the trunk…
• Unpredictable release cycles, with date targets we could never hit, and….
• Engineers who were always in a rush to get their features into “this” release since we couldn’t make any promises about the schedule
  so they slightly change ( and simplify ) it to this 3 channel diagrams by making release shorter ( and reduce scope )

So they change traditional scheme to this one :

And then make it work in real life by cutting scope at release ( by disable features ) : Establish clear expectations (and engineering practice) to developers that any features not ready to ship at branch will be disabled (i.e. we only cut post branch, never add).

So it works fine for google guys and their rules are :

• The branch point is the end of our development cycle
• Features only get disabled post branch point
• Features should be engineered so that they can be disabled easily (1 patch)
• Only stability, security, and critical regressions can ever block a release

For me it’s looks fine for in-house development, but for me it’s big question how to apply same scheme for outsource development.

AWS related links :

• State of the cloud – 2010 August
• Amazon’s EC2 Generating 220M+ Annually – really interesting post – “at 40,000 servers evenly distributed across 6 availability zones we know, ___ 6,700 servers per zone..Most of the servers are likely in the US availability zones vs. the EU zones, maybe 75-80% of total capacity”. Also take a look on amazon ec2 instances usage rates
• Anatomy of an Amazon EC2 Resource ID and based on this anatomy EC2 usage estimates
• Rumor Mill: Google EC2 Competitor Coming in 2010?

• git for big files : git-bigfiles
• omit large files commiting into git repo : Rejecting large files in git
• git as backup system : A better backup system based on Git and Journey to a backup solution: Git
• Hosting Git repositories, The Easy (and Secure) Way

Subversion ( svn )

• How to store-all-stuff-in-svn : Subverting your homedir, or keeping your life in svn
• SVN-Hooks : Avoid empty comment in SVN commits
• Using SVN-Hooks to commit notifications on email : Setting up a post-commit mail notification for a Subversion repository
• SVN Notify documentation

.. to be continued

• jsawk : work with an array of JSON objects read from stdin, filter them using JavaScript to produce a results array that is printed to stdout. For example get’s json ( from Yahoo image search by ‘madonna’ query ) and add some info ( madonna’s real name ) to this

wget http://bokov.net/json_example.json
cat json_example.json | ./jsawk "this.ResultSet.RealName=\"Louise Ciccone\"" > updated_info.json


• you can use some bash/awk/sed stuff to parse json. For example – list all image urls from json

wget http://bokov.net/json_example.json
cat json_example.json | sed -e 's/[{}]/''/g' | awk -v k="text" '{n=split($0,a,","); for (i=1; i<=n; i++) print a[i]}' | grep '"ClickUrl":' | sed 's/:/ /1' | awk -F" " '{ print $2 }'


• or use library from json.org for language which you like

via v.kruchkov