EngineerBetter

Concourse doesn't run Docker, it uses something called Garden to run OCI containers from Docker images.

Those containers can run the Docker daemon though, if you like.

I suspect the authors of Golang got drunk, and challenged each other to see how many times they could get people to type 'if err != nil' in the next decade.

Current Autopilot tends to brake abruptly in slow-moving queueing traffic, which I'm sure annoys the people behind me.

The add-ons are software unlocks. The old 60D models actually had a 75KwH battery pack, but were software-limited to 60KwH unless you paid for an upgrade.

Fremont is where Tesla builds all vehicles currently.

Yep, exactly right. The hardware is capable, but the software hasn't been created. Just like the original link - the hardware will (probably) provide enough input data to allow software to do all these cool things, but it's not been done yet and production code is a very long way from what is outlined.

It will use the Autopilot cameras (there are no additional sensors), and the Tesla Vision software on AP2 hardware does not support detection of rain on the windscreen. The driver has to turn the wipers on manually. My Renault Zoe, which costs about 25% of my Model X, does this automatically.

Tesla Autopilot is cool, but the software is very limited at present. The original link is essentially what Tesla think they can achieve with the AP2 hardware, but the production software is nowhere near capable of these feats.

This is not news. Current Tesla vehicles with Autopilot 2 hardware can do nowhere near this aspirational list. My AP2 Model X cannot even tell when to turn the windscreen wipers on.

This is a statement of intent, and production vehicles are a long way from having software that enables this.

I'd suggest the tragedy here is an absence of kaizen and team processes that foster continuous improvement. If folks are doing inefficient things, that should be caught by the team in a retro or similar.

We work with folks (very large banks, automotives, governments, manufacturers, retailers) who use Cloud Foundry, often combined with Concourse to deploy both apps and the platform itself.

It's surprising the number of people who want to build a homebrew Kubes PaaS. When I first started working in development, every company was building its own CMS, until it invariably realised that it was hard and that they were better off using a commercial or open source solution. Seems that container-based platforms are history repeating itself.

Pivotal. I've had the pleasure of working with many Pivots, and Rob Mee has built a great XP culture.

I use Nutmeg, had a return of 7% over two years, and I've also just opened an account with MoneyFarm.

If one has a Tesla, yes. I currently drive a Renault Zoe which is incompatible with Tesla superchargers, but had been considering buying a Model X.

A Tesla could charge at either 22kW using the Type 2 Mennekes connector, or if the owner has a CHAdeMO connector (about £250 from Tesla) at 50kW. Both a lot slower than a supercharger's 120kW.

In the UK, Ecotricity give me 52 fast-charges (30 minutes at 43kW) a year on their motorway (freeway) charging network for free as I use their 100% renewable tariff for my home electricity.

Tesla's allowance seems pretty weak by comparison. In fact, their allowance is only 35% of what Ecotricity offer.

Thanks for the clarifications!

The Flynn auto-heal - does that monitor infrastructure (ie at the VM level) or is that process auto-healing?

That's cool about Docker images. Cloud Foundry has a binary buildpack, and the Java buildpack deals with .jars, which means slightly lower complexity for the end user than needing to roll a Docker image. CF does Docker too now, which is nice for compatibility, but I think people are missing the point by deploying images instead of apps.

Fair points about BOSH, it's got a steep learning curve (cliff). I'd love to see Cloud Foundry have an install experience that's along the lines of "Hey, here's some IP addresses and an SSH key. Go install yourself there."

Both this and other PaaSes remove a lot of the plumbing. Also, the target audience is different. PaaSes offer self-servixe for end users: for instance starting a new database on demand through the user interface. You can achieve much of this with Docker Compose, but your users can't.

The Docker-PaaS movement reminds me of content-management systems in the early 2000s. Everyone (myself included) thought it'd be great to spend loads of engineering effort reinventing the wheel, instead of delivering business value.

The millions of users claim comes from the fact Cloud Foundry powers the Comic Relief (charity telethon) payment system, processing 400 credit card payments a second during the peak evening.

Add to this that it's used by General Electric, Ford, Huawei, the US, UK, Dutch and Australian governments, and many more, plus the public PaaS offerings of Pivotal Web Services, IBM Bluemix, Anynines, Swisscom and more... There's a lot of usage.

You should take a look at BOSH.

http://bosh.io

It allows the same distributed system to be defined and run on AWS, GCP, Azure, vSphere, OpenStack, tin, and more.

Caveat: I run a Cloud Foundry consultancy.

A quick glance shows a couple of things:

* Automatic cluster scaling, so your PaaS deployment is as small as possible. Cloud Foundry doesn't have this, and I wish it did

* Flynn has built-in service discovery, in Cloud Foundry you bring your own (if you want)

* Flynn comes bundled with some data services

* Flynn has no BOSH equivalent, so there's nothing there to bring back VMs when they fail, perform rolling upgrades or manage the IaaS

* Flynn doesn't seem to offer a metrics stream, only logs

* Flynn builds apps from source, so not sure how that works for compiled Java/Go, or anything you'd run with a binary buildpack

* I couldn't find anything about role-based access control in Flynn, something Cloud Foundry has (which can be backed by LDAP for enterprises)

* Flynn only appears to route HTTP traffic, so no TCP routing for IoT workloads

* Cloud Foundry is run at massive scale in production for mission-critical workloads by banks, payment processors, IoT data ingesters, manufacturing companies, research companies, governments and everything inbetween. I can't see any evidence of the same being said for Flynn.

* Flynn is owned by one company, Cloud Foundry is owned by a non-profit organisation affiliated with the Linux Foundation and can never be transferred back to a regular company. This prevents the sort of nonsense you've seen in the Docker community recently.

Good question - I dare say it is nowhere near as battle-tested in production.

I expect that this is one of the reasons they're adopting Cloud Foundry: https://www.youtube.com/watch?v=u18nKAOY5mo, along with the UK, USA, and Australian governments. I think there's a few others too now.

Speaker in the video here.

I recently gave this talk at Cloud Foundry Summit, and it's a very condensed version of a 45 minute talk that was less light with the research. The full notes detailing the sources I drew stuff from are at http://engineerbetter.com/bad

I'm not a cognitive psychologist, nor a neuroscientist. I'm an engineer at heart, with an interest in making businesses more efficient. The inspiration for the talk came from reading in my spare time, so no doubt some of the sources I've used are disputed or suffer from a confirmation bias - I read things and get excited about how they might apply to software development.

In particular I'd like to highlight that I'm aware that the presence of mirror neurons in humans is unproven, and that the mirror hypothesis is disputed.

I'm genuinely keen to hear where I've misrepresented the science, but I gave these talks in the best interests of making people's working lives better, so please be gentle :)

Here's an article about VW using OpenStack and Cloud Foundry: http://www.baselinemag.com/blogs/volkswagen-group-deploy-ope...

Disclaimer - I co-founded a Cloud Foundry consultancy.

There are numerous folks running open source Cloud Foundry in production. Most I can't name for confidentiality reasons, but the Comic Relief payments system runs on open source CF on a variety of infrastructures.

Once you've got open source Cloud Foundry deployed and managed with Bosh, and you're using Concourse to update it, you should have a reasonably easy time. Numerous governments deploy open source Cloud Foundry this way (UK, USA, Australia, with several others evaluating it currently).

You can run Docker containers on Cloud Foundry's Diego runtime. We normally encourage apps as a unit of deployment currency for a number of reasons (easier auditing, allowing developers to focus on code rather than setting up images), but Diego is battle-tested. Under the hood both apps and Docker containers are run the same way, so you don't need to worry about the Docker stuff being treated differently.

I've not heard great things about OpenStack. I know people who have run very large Cloud Foundry installations on OpenStack, and had production issues with OpenStack network drives, amongst other things. From the anecdotal evidence of people I've spoken to, you're more likely to have problems with OpenStack than with Cloud Foundry.

I'm happy to chat more - search for my username and you'll find us; I don't want to put gratuitous advertising in HN comments :D

Is there any evidence for the provenance of this list?

I'd love to know the point of this article, but can't bear to wade through the waffle. Is this a print article reproduced online?

It's a tiny little utility, but handy for when you're switching between Go projects in your $GOPATH and other projects in ~/workspace, or for when you can't remember who made a Go project or what website they hosted it on. It's mostly written in Go, so is quicker than just a Bash function alone.

I'd rather candidates had empathy, a willingness to learn, and an appreciation of testing & CI, than the ability to implement a linked list in under 10 minutes.

In over a decade of software development including web systems, games development, command line tools and distributed systems, I've never had to implement a linked list. If you haven't used the modulo operator, FizzBuzz isn't necessarily obvious.

You should consider getting in touch with the folks at Pivotal (http://pivotal.io/locations/london). They have a very progressive working practice, and are keen to attract diverse staff. They're based in Old Street.