Your username is 'zoidberg'. Hatin' on your fellow crustaceans, eh?
HN user
ThatMightBePaul
Community Manager at CoreOS, @thatmightbepaul on the Tweeters
Most people don't realize that most varieties of tea come from the same plant https://en.wikipedia.org/wiki/Camellia_sinensis
Your question is still a good one, but hoping the above context makes the "so tea as a blanket category just... works?" less absurd.
Actually, they are NOT entitled to dividends. That's part of the myth, and is covered in the book. You should give it a read. The author covers some historical cases which are often misinterpreted, and lead to the confusion. In the case of dividends entitlement, the case you're drawing from is https://en.wikipedia.org/wiki/Dodge_v._Ford_Motor_Co.
She's a lawyer and professor in precisely this area. You could read the wikipedia article, and try to confirm your bias. Or, you can read the book, written by an expert, and broaden your perspective.
This.
Free Software sounds cheap or trashy. It requires explanation. "Free as in beer, and Free as ..."
Open Source is a marketing term to avoid that stigma.
Sup Jorge! You named the big ones. There are a bunch of others, as well. IMO, try to get your comparison down to just two. That's a reasonable set to dive deep on.
For a lighter overview, I think the big features are: team workflow, security, and CI/CD pipeline.
Team workflow is just how easy it is to get going / share with your team. IMO, ECR or GCR will have a natural edge here if you're already on their cloud. Tagging is important too, but I think everyone supports that.
Security is both the details of transport (SSL, etc), and whether your containers are getting scanned. Quay.io and Docker Hub both do security scanning for private repos. Quay has a slight edge in that public repos also get scanned thanks to Clair. I believe GCR and ECR lag behind here.
CI/CD pipeline is important because your registry becomes a big chunk of your build. This is what's going to really take time to investigate and dig into. You want to make sure it's easy to add hooks to git or w/e, and troubleshoot build issues (good logging, auditing, etc).
Full disclosure I work at CoreOS and with the Quay folks. That said, I also think they're constantly probing into cool frontiers. I think Clair changed registry security. The team's also started doing cool stuff for k8s users [1].
Lastly, I'm not totally sure on this last bit, but I think Docker Hub has a slight usability edge if you're on Docker EE (swarm).
Summarizing: I think big cloud vendors will naturally always lag a little behind. They'll make up for it with convenience if you're already on their cloud. Registries whose main purpose is to be a registry (like Quay) will naturally innovate a little faster.
[1] https://coreos.com/blog/quay-application-registry-for-kubern...
I wanted to try the Noto mono out for programming, but it looks like the `O` is indistinguishable from the `0` :/
Otherwise, it's a nice looking font for the editor.
Congrats Keith :D
I've met Keith a few weeks ago at the NodeJS NYC meetup. Great dude, who genuinely wants to make development better. Polybit seems particularly cool for front-end / designers, mobile devs, and anyone else who'd rather build an app than fret over the high availability, scalability, or etc.
What I'm saying is: cool idea + Keith's very approachable if ya wanna pick his brain about the design :)
Hope this goes well for ya dude!
Why is this interesting, when the charts all lack clear data sources?
Numbers without context are meaningless.
Dear Writers,
Stop using the term "activist investor". It strongly connotes political and social change.
That is not your intent. Find better words.
Sincerely,
Craig mentions this in the piece, but I'll second it:
I fucking love CTE's for breaking apart ugly looking queries. They make everything significantly easy to read.
"Back in the day math was slow and error-prone and we created the computer. Now, it’s software development that is slow and error-prone."
I'd argue Math is still slow and error-prone. Ask any math PHD candidate. Computation is fast, but Math itself has more layers, and more branches than ever. Sound familiar?
That said, some smarties are trying to remove unnecessary layers in programming. I feel like rump/Uni-kernels are looking to simplify the stack. [1] The clear linux project is removing some pieces from the stack. [2]
TL;DR Math is about as noisy as programming :/ I don't buy the premise. But, I enjoyed the read!
Snazzy!
I love it when the Keen peeps put out this type of content. Makes it easy to start a convo in house by passing a link + starting a conversation.
bookmarking <3
For YCR, have you considered grants from other foundations?
For instance, the Bill and Melinda Gates foundation is basically just looking for opportunities to have the biggest possible impact.
I think a lot of your future goals may line up: clean energy, global healthcare, etc.
This is neat!
Has it been shared with any of the folks at the open container initiative? opencontainers.org
I'm sure they'd love to collab.
I dig the One Metric That Matters (OMTM) concept. I've worked on projects with 30 metrics, and figuring out whether things are "going well" quickly turns into a debate.
Tangential: I wish these online slideshare allowed slide comments or inline annotations. Dying to know what the Brahe + Kepler page was about :)
I work for a similar service, Iron.io. We're platform agnostic, but closed source.
Can't tell if that ticks your boxes or not. If you're interested we're free to try.
Gotcha, I'll move to using the original article title from now on.
Yup! Even with the slow movement, I think apprenticeship can be a great deal. So long as the job is something that's general enough.
I'm talking plumbers, electricians, etc. There will always be broken toilets and bad wiring.
I'd be more concerned about apprenticeship in the ship foundry that the article mentions. That seems like a much more specialized market.
I agree the next gen needs Math. Not for the reasons in this article, though.
John Carmack's 2012 QuakeCon speech is almost a direct rebuke: https://blogs.uw.edu/ajko/2012/08/22/john-carmack-discusses-...
In reality in computer science, just about the only thing that’s really science is when you’re talking about algorithms. And optimization is an engineering. But those don’t actually occupy that much of the total time spent programming. You know, we have a few programmers that spend a lot of time on optimizing and some of the selecting of algorithms on there, but 90% of the programmers are doing programming work to make things happen. And when I start to look at what’s really happening in all of these, there really is no science and engineering and objectivity to most of these tasks. You know, one of the programmers actually says that he does a lot of monkey programming—you know beating on things and making stuff happen. And I, you know we like to think that we can be smart engineers about this, that there are objective ways to make good software, but as I’ve been looking at this more and more, it’s been striking to me how much that really isn’t the case.
Aside from these that we can measure, that we can measure and reproduce, which is the essence of science to be able to measure something, reproduce it, make an estimation and test that, and we get that on optimization and algorithms there, but everything else that we do, really has nothing to do with that. It’s about social interactions between the programmers or even between yourself spread over time.
Look forward to hearing this. Will Venmo $5 in exchange for the outtakes of Fred cursing ;)
Woah! Thanks for sharing. Love hearing about the other side. All of the projects I've been involved in operate on either a continuous release, or a one to two week release cycle.
So, I'm definitely ignorant to the standards at spots with months-long release cycles.
I love this metric, and am totally stealing it.
This. Unit testing is better for a lot of reasons. Dev familiarity is definitely a big reason. I find they're a bit more robust, too.
Integration tests are more brittle. Which, can be good ("Hey, there's a bug here..."). For an early product, your app is probably simple enough that you get a good enough feel while dogfooding. 100% correct that also includes some informal exploratory work :D
RE: Complexity & the relative need for testing, I really like the perspective 'Out of the Tar Pits' takes. http://shaffner.us/cs/papers/tarpit.pdf
You mentioned 'level of quality'. That can be pretty difficult to quantify. In the absence of well defined metrics, a lot of thinking about QA is qualitative.
"I feel like we have a high level of quality here".
That makes conversations about QA pretty challenging. Metrics is the one area I'd LOVE to see move forward.
Np! Thanks for sharing.
Glad to hear security is taking the front seat some places. Anecdotes like this help me expand my world view. <3
Agreed.
Caveat: do you need to do pen testing every release? I'm guessing, not. YMMV.
If you're a defense contractor (as some other commenters mentioned), your priorities are probably quite different.
Thanks for the good word (I'm the author). I 100% agree about setting the right culture / the difficulty of managing the transition.
It takes a ton of work to establish the right infrastructure + culture. Specifically for the reason you mentioned: a lot of folks see QA in black and white.
It's doubly hard when you're growing fast.
TDD is great. It should be a given on any project that isn't just a spike.
I'm curious what kind of products you were building? Simple websites, or full fledged applications?
100% unit test coverage can still miss a host of gnarly bugs. A lot of the ugliness of QA comes from how A interacts with B. Or how A + B + C + D work together. Or at least, that's my 2 cents :D
Another possibility, http://consumerist.com/2010/05/11/if-youre-going-to-eat-a-ca...
Orange carrots might've also been an easy "ok, it's not hemlock, it's safe" indicator.