- AWS Case Study: U.S. Department of State – ExchangesConnect Video Contest
- RESTful Services with Erlang and Yaws : wting RESTful web services in Erlang/YAWS
- Amazon moves VMware’s virtual machines to the cloud, blog post on AWS :VM Import – Bring Your VMware Images to The Cloud
- Android vs iPhone: Security Models
- Hudson Project Renames to Jenkins – also see Hudson’s future on hudson-labs.org, On Oracle proposal about Hudson by Kohsuke Kawaguchi
- Skype architecture
- Real customers feedback on Agile
- Amazon’s Android Appstore : Amazon launches Android appstore portal, Amazon’s Disruptive Android App Store Now Open To Developers — Full Details, Deciphering Amazon’s Android App Store Strategy
- The coolest open source databases on the planet (NOSQL + RDBMS)
- NoSQL at twitter
- The experiment infrastructure at Google
- Chrome Release Cycle
- Google presented Android 3.0 ( Honeycomb ) on LG /G-Slate device: What’s Hiding Inside Android’s Honeycomb?, and LG and T-Mobile’s G-Slate Tablet To Run Android 3.0 Honeycomb, demo videos from CES :CES 2011: T-Mobile G-Slate Honeycomb LG Tablet Hands-on Videos – Features Walkthrough in 8 New Videos
- Korea : Telecoms bet on cloud computing – SK telecom announced cloud data center for mid- and small-business, other players – KT Corp. and LG Uplus also announced their plans last year to jump into competition.
- CloudBees announced HaaS : Hudson as a Service ( free accounts still available )
- Sony announced ( actually in Nov/2010 ) Sony’s next-gen app platform will use Objective-C/GNUstep: SNAP. By the way Sony got some open source stuff : Sony products with Linux / OSS embedded Technology.
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.