70 karma · joined August 22, 2010
https://yvesjunqueira.com
Any low hanging fruits you suggest we look at first?
Eurodollars have different exchange rates because they don't have the reserve requirements from the Fed. i.e: it's less regulated.
The RMB has a heavier regulation whereby the exchange rate isn't allowed to fluctuate. This does increase the difference in value for the onshore and offshore currencies.
But having that distinction does not by itself make it a currency manipulator.
Doing a large rollback based on a hunch seems like an overreaction.
It's totally normal for engineers to commit these errors. That's fine. The detail that's missing in this PM is what kind of operational culture, procedures and automation is in place to reduce operator errors.
Did the engineer making this decision have access to other team members to review their plan of action? I believe that a group (2-3) of experienced engineers sharing information in real-time and coordinating the response could have reacted better.
Of course, I wasn't there so I could be completely off.
One imperfect but helpful technique is to use release notes for your application.
Ask the team to write good commits when changing code, and aggregate all code changes done to the application into a page that describes what went in that release. GitHub releases do that for you automatically. When a release is pushed that breaks something, it's easier to scan the release notes and find who changed what.
Another technique is to use explicit feature flags to protect all code changes. Then use a dashboard that shows recent changes to feature flags – again this helps tracking down the culprit.
There are a ton of interesting projects at Google for people to work on, so people select for interesting things with potential high-impact. If a team can't be formed to own the product, maybe someone will volunteer to take care of it in their 20% time. But there are these company-wide mandates to move production systems from a storage system to a newer one, and a part-timer doesn't see the point of doing such thankless job.
Management can also play a role. If a VP wanted to support the product, it would get supported. But they use the basic heuristic as above ("is this an interesting project with high potential impact"). In this analysis a VP is just a proxy for 100 engineers making the same decision.
BJJ is the best fighting style that fits the rules of MMA. Change the rules a bit and a different style will work better.
Obviously it still sells today. He doesn't own it anymore and it's not a proper license like what you're asking. But it's a precedent.
(Although a little bit of divergent thinking is healthy for the mind)
Would that happen via crossbreeding? Or some mysterious form of gene "absorption"?
Go allocations are indeed costlier but the performance critical sections of applications can be profiled and optimized accordingly to remove allocations.
I'd rather have Go's amazing low GC latency and slightly higher allocation costs vs the operational nightmare from HotSpot.
Automatic management of generations has never fully worked in Java. Every new JDK version just adds more knobs. Sounds like you have a different experience?
That's a perfect description of how I felt.
That's totally OK, mistakes happen, but I'm not sure what the emails say. If startupschool.org perhaps had the final status (advisory track or not), that would be super helpful.
Looking forward to the Hollywood movie in which heroes have to stop a STAR from hitting Earth.
If you need containers to solve the "it works on my workstation" problem, and you need to make your containers run in production and scale them easily, and you have lots of applications to setup and deploy, then Kubernetes is fantastic. But if you can get away with just running your application in plain VMs and the burden of maintaining a Consul-based app discovery isn't a problem for you, your proposed setup makes a lot of sense.
Custom infra has an operational cost that is proportional to the number of applications. Kubernetes has a high fixed operational cost that you always incur, whether you have 1 application or 20. Once your operational complexity is high enough, it makes sense to use Kubernetes.
Soon higher level solutions will come along that will delivery the same advantages of Kubernetes but remove the learning curve and ops cost of Kubernetes.