Software is changing the world, and our mission is to help progressive software development teams adopt new technologies and practices. For over 18 years, InfoQ has guided senior software development teams with peer-validated, trustworthy insights in adopting new technologies and practices.
InfoQ shares the experiences of senior software developers gained using innovator and early adopter stage techniques and technologies with the wider industry. We carefully curate and peer review everything we publish. We strongly believe that the high-quality insights offered by both our editors and other contributors have the power to uplift entire communities, no matter what their native language.
InfoQ currently offers English, Japanese, Chinese, Portuguese, and French content.
Our conferences include QCon international software development conferences in London, New York, and San Francisco and the InfoQ Dev Summit in Boston and Munich.
45:00 - "Simplicity and the Greater Good - while it's often seen negatively, in the context of order, sustainability and group cohesion it's a benefit and it's imperative that in some aspects of the organization it has to be enforced." AGREED!!
improved? can't even reliably fetch older tweets now unless you sit on it. but at least we get a thousand spammy replies unrelated to any trending tweet LOL
Thx, I can see all the new shiny projects I get because chicken engieers start to feel the necessity to switch to graphql because netflix did. Thx for the microservice money @netflix
Crockford missed a simple epiphany with falling through on case statements. He went from advocating them as useful, to deprecating them as causing errors. But a simple rule would be to allow multiple case statements provided they all shared one body terminating in break at the end. That would clearly be purposeful.
Can't wait for them to deprecate all of this in a few years and have the rest of the industry scrambling for help for copying them thinking they were netflix.
Given that the view count here is lower than a typical review of a new hose bib in the plumbing department at home depot, I guess the FP conquest of all programming via Monad Consciousness is still not ready for Rapture.
dhh said they spent tons of time optimizing cloud costs and it was still overpriced - that's why the switched to their own servers. The fact that it's so easy to make mistakes costing millions is a serious problem with the cloud. If you look at the basic economics, cloud companies have to make a profit, so they're going to charge more for a server. And the layers of virtualization hurt performance compared to a bare server. So for many companies with steady traffic, on-premise is simpler and cheaper. For services with very variable demand, the cloud can be more cost effective
It's a new way of working. Don't forget you CAN set budgets and stop the phenomenon when it hits the limits. The cloud sliced and diced the resources to the single "write" on the storage. That's what you pay for. You need to think on the same abstraction level when you code.
@@mihaisagungureanu3070 Setting budgets is definitely good, but for most companies and most applications, using ultra-specific cloud tools, Kubernetes, Docker, cloud functions, etc is just overkill and increases vendor lock-in. A cheap fixed-price per month server with nginx, your app backend, and a database is enough for most companies
It was a typo in the url for the word “company” as the other person mentioned. This means that when the function download_update_metadata ran its response code was never 200 because it was a bad URL. So it fell back to doing a full download and file based hash every single time in the wake condition
