"If you’re used to designing and deploying applications in your own data centers, you need to be prepared to unlearn a lot of what you know."
Which is it? Did it save them money because they didn't have to "build their own redundancy and failover" or did they have to build a bunch of custom tools like Chaos Monkey because "I knew to expect higher rates of individual instance failure in AWS, but I hadn’t thought through some of these sorts of implications." ???
From reading Netflix' blog, it's clear that it was a huge learning and engineering effort. That cost has to be taken into account and added to the fact that across many AWS offerings, you're looking at as much as a 10x price / performance penalty versus dedicated or collocation. I'm unconvinced that they couldn't have done it cheaper and better through more transitional approaches, and moreso that it's a meaningful indicator for anyone else.
AWS has been massively innovative. But it's much more expensive, and a huge part of their business is sales and getting CXOs onboard, not necessarily providing good value.
Tangentially, what's impressive about Shanghai's metro is how quickly it became the longest. It essentially went from nothing to the longest in 15 years.
Compared to the 20 years it took the Big Dig, or my own home city which has been talking / debating / purchasing / cancelling / assessing / suing re mass-transit, it really is an impressive achievement.
Agreed that it could be either of those things. I'm not trying to excuse criminal behavior at all, rather stating that if one puts an unauthenticated database on the internet, it's going to be compromised. For software professionals, my opinion is that to do so would be negligent.
Of course it depends on the context. I don't know if it's reasonable to expect a small family clinic, therapist, or dental office to secure their client information. It seems that people just mass scan the internet looking for already known vulnerabilities.
However, if it's a mid-sized business handling important information, like payment information, then I do think there ought to be a standard of dutiful behavior, because otherwise who pays for the externalities?
KFC is definitely more popular than McDonalds in Asia. Chicken and pork are much more popular than beef. I've always assumed it had to do with the stupendously inefficient nature of beef in terms of cost & land.
The start tag is mandatory. The end tag may be omitted if the <p> element is immediately followed by an <address>, <article>, <aside>, <blockquote>, <div>, <dl>, <fieldset>, <footer>, <form>, <h1>, <h2>, <h3>, <h4>, <h5>, <h6>, <header>, <hr>, <menu>, <nav>, <ol>, <pre>, <section>, <table>, <ul> or another <p> element, or if there is no more content in the parent element and the parent element is not an <a> element.
And "there is no more content in the parent element" applies here.
Actually, what you call "very specific cases" are in fact, well, all reasonable cases. That list consists of all block level elements that can appear in `body`, so the statement could be reworded, that "<p> cannot contain any block-level element, so any inline element after <p> falls in, any block level element ends opened <p>".
Funny fact is that presence of optional end tags means nearly nothing for HTML parsers used in current browsers, they just ignore them. Some border cases regarding white space exists, or at least existed in the past, but in general, if you feed browser with document
I'm a fan of Go and have been using it for a [relatively] long time across various large and small systems.
I really like it.
To me, what's been abundantly clear is that: it's a horrible choice for types of apps a lot of people are using it for. Specifically, systems where ror/django/express/php have traditionally excelled at. I'd say "CRUD", but that's too narrow. The expressiveness and productivity of dynamic languages continues to awe me. This is particularly true for web systems that, on one end, deal with the object-relational mismatch and on the other transforms and outputs json or html.
Go's great, but it feels like we've forgotten some of the pain-driven lessons Hibernate and their ilk taught us.
This is sort of the conclusion I've come to in the last few weeks as I think about and research in preparation for my next startup. I learned to code with C / Perl in the late 90's, moved to scripted/interpreted "web" languages like ColdFusion, PHP, RoR, JS, and about a year ago I finally decided to build a toy project with Go for Google App Engine. I found the process really instructional, but ultimately pretty frustrating. I fall very much into the author's second camp; it's not the language for me, for what I want to use it for. I'm building a pure web app, with very little systems orchestration need (outside standard devops). Go seems like a great fit for building Docker, but a poor fit for building AirBnB. Especially at first, when I'm likely to be the only programmer for 12-18 months, it seems to me that Go is a poor choice to begin with. It loads too much technical debt (probably the wrong term) onto our startup at a time when we need to move fast and break things. If we are hugely successful and we end up with 20 programmers in 3-5 years, then maybe it'll be time to re-architect key microservices in golang. Until then, I think RoR makes the most sense for us.
I've been looking for someone to verbalize this train of thought for a few weeks.
We learned that you can't configure your way out of impedance mismatches. You can certainly make your life easier, but only at the cost of also making it harder.
You essentially need language-level support for dealing with data at your boundaries. Even with Java's strong reflection (Go's reflection is horrible) capabilities and generics (and C# extending that with lambdas and expression trees), there's still tremendous friction and boilerplate configuration and code.
Consider Dependency Injection, an ilk. In most (all?) dynamic languages, DI is a language concern, as opposed to a library concern. By having support for it within the language, the problems DI frameworks attempted to solve in Java (or C#) via messy configurations, legalese-like unit tests and quantities of code dedicated to nothing but the infrastructure of the codebase, simply vanishes. Now people are going to Go and discovering the awesomeness of interfaces.