#AboutLastWeek: Let’s put the Docker fork matter to rest

Each Monday we take a step back and analyze what has happened in the previous week. Last week we wondered if Docker can truly be ousted and we invited a couple of specialists to weigh in on this matter. We welcomed a new Angular 2 release candidate and we brought the interruptions discussion back into the spotlight.

Docker fork — Can this happen?

There’s a Docker war developing right under our noses. The battlefields? —Twitter, Medium, personal blogs, forums and more. Google Kubernetes evangelist Kelsey Hightower took to Twitter to express his views about a possible Docker fork and to wonder whether “Docker deserves to be the stewards of an open container standard.”

The talk of a Docker fork, if handled maturely, has the opportunity to work out well for all parties.

Although he acknowledged Docker’s “amazing work,” Google’s Craig McLuckie also opined that “we need boring core infrastructure today.” “Boring” seems to be a popular word describing something that we need —Bob Wise, Chief Technologist Cloud Infrastructure at Samsung SDSA wrote in a Medium post titled An Ode to Boring: Creating Open and Stable Container World that “the orchestration job is right now much harder than it should be because there is far too much product and feature excitement about containers. We need boring!”

We asked Benjamin Wootton, co-founder of Contino, to weigh in on this Docker fork discussion:

We think this is a bit of a storm in a teacup. Most of the blog posts are referring to stability in Swarm rather than Docker, but these are generally edge cases such as running on a Raspberry Pi. SwarmKit was a big, ambitious project and a big merge, and though we all want perfect bug-free software first time, I think we can be pragmatic in expecting a few bugs on edge cases for a first release of such a widely watched project.

I also don’t think a fork is viable because Docker is delivering and innovating so quickly. Any fork or standard would fall behind pretty quickly and would fail to get momentum in the industry.

Daniel Riek, Senior Director, Systems Design and Engineering at Red Hat, has joined the discussion; he claims that a Docker fork is not the solution, but acknowledges that “the importance of this conflict cannot be under-estimated.” Riek believes that the tensions have started to bubble up due to “the aggressive way that Docker Inc is trying to control the Docker open source project, which was started under a permissive open source license when the company still was called DotCloud.”

We also invited Peter Rossbach, freelance system architect and coach of numerous web applications, to share view views on this matter. Take a sneak peek at the interview or read his entire statement here.

Docker Inc. is very well-placed within the community and it’s middle-term business vision is starting to become more visible. They have a very good marketing strategy and their speed of delivery continues to amaze their peers. Yes, this can be a very annoying aspect for potential partners and they can seem un-cooperating.

On the road to Angular 2

Angular 2 is coming soon, but for the moment let’s enjoy the milestones the Angular 2 team prepared for us. Join us in discovering all the details about Angular 2’s imminent release and stay tuned for more updates as they become available. Last week the Angular team unveiled a new release candidate which has more than 60 bug fixes and over a dozen features.

Breaking changes in RC.6

npm packages: code in ESM (ES6 Modules) format is currently published at the default location in the npm package with package.json‘s main entry pointing to an UMD bundle (primarily for node, and webpack 1 users). For those who are using SystemJS to load Angular, it is recommended to adjust the SystemJS configuration to point to the UMD bundles (present in the npm package).

As far as testing config is concerned, there’s a new order in which various zone specs are loaded; this change stems from the zone.js peer-dependency upgrade.

The core changes include the following: Type is now Type<T> , so you will have to use Type<any> instead ofType. APIs SanitizationService and DomSanitizationService have been renamed to Sanitizer and DomSanitizer and the support for @Component.directives and @Component.pipes has been removed. It is important to remember that all the components and pipes must be declared through an NgModule, which is is the basic compilation block passed into the Angular compiler via Compiler#compileModuleSync or #compileModuleAsync. Due to this change, the Angular team also removed the Compiler#compileComponentAsync and #compileComponentSync. Therefore, any code doing compilation should compile module instead using the APIs mentioned above. Plus, the ngUpgrade module was modified to always require (it was previously optional) an NgModule to be passed into the UpgradeAdapter’s constructor.

ComponentResolver was removed, soComponentFactoryResolver should be used instead.

If you use the following forms of providers, you should know they are no longer accepted:
bind(MyClass).toFactory(...)
new Provider(MyClass, toFactory: ...)

The elephant in the room — interruptions

We opened Pandora’s box because we wanted to know how developers really feel about interruptions. It turns out that interruptions (especially planned ones) truly are real-life kryptonite and they can hinder productivity. Developers weighed in on this issue on Reddit — so let’s see how they cope with interruptions.

Interruptions in software development are not something developers take lightly — according to a timeless article by Game Developer Magazine’s Chris Parnin, developers lose more time going back to a task after they’ve been interrupted than people working in other industries and the time spent away from their tasks is directly proportional to the amount of time they need to resume work. If unplanned interruptions force people to waste at least 30 minutes because let’s face it, jumpstarting a task in two minutes is simply not realistic, planned interruptions are possibly the worst kind.

Paul Graham, computer scientist and venture capitalist described the difference between the maker’s schedule and the manager’s schedule and pointed out how meetings (a.k.a planned interruptions) can “blow a whole afternoon.”

I find one meeting can sometimes affect a whole day. A meeting commonly blows at least half a day, by breaking up a morning or afternoon. But in addition there’s sometimes a cascading effect.

We kept an eye on the Reddit discussion prompted by the revival of the interruptions discussion and we decided to summarize the most popular opinions. Read them here.