The technical deep dive was a great read, thanks! I think it would be a good submission.
1 karma · joined January 25, 2022
type CompanyID = string & {readonly brand: unique symbol}
type OrderID = string & {readonly brand: unique symbol}
type UserID = string & {readonly brand: unique symbol}
type ID = CompanyID | OrderID | UserID
function CompanyID(id: string) {
return id as CompanyID
}
...
[1] https://learning.oreilly.com/library/view/programming-typesc...
Data gets aggregated and used in mathematical models that can predict outcomes in various hypothetical scenarios, but given that this is a real-world situation, the professionals are going to be looking at the actual data first to find out what’s happening. They can directly answer questions such as, of the patients diagnosed 1 week ago, what’s their status today?
Anyone looking at only total numbers of cases per day simply doesn’t have the data required to compute the things they’re trying to compute with much accuracy. It’s possible to produce estimates with confidence intervals based on sensitivity analysis, but nobody doing that with any care using aggregate data is going to come out with a number as high as 20% for a lower bound. Given that N=6 is a guess, the range reported should be bounded by plugging in plausible extreme values for your guess of N, not assuming your guess of N=6 is exactly correct.
If the modules of your system are already relatively independent with well-defined interfaces, microservices would be fine and yes would make changes like upgrading the language runtime version easier.
But when I think of messy, tangled, poorly-tested code that prompts people to start talking about needing to refactor to microservices, I’m thinking about different sorts of problems. The messiness I usually see has to do with lots of missing abstractions, lots of low-level code reading and writing directly to files and message buses and databases and datastores instead of going through some clean API. This makes it really hard to change things, because instead of updating some API backend, you have to find and update all the low-level accesses.
Now the problem is, typically when going to microservices, people aren’t looking at the question of, “What common stuff can we pull out to make all our messy code simpler?” They’re taking the existing, messy modules, with lots of cross-cutting shared abstractions dying to get out, calling the existing module a service, and putting a bigger barrier around it.
There are many ways to approach the problem of moving to cleaner, simpler abstractions, and microservices can help. But you can easily go to microservices without addressing all the needless complexity, instead crystallizing that complexity in the process, and many organizations end up doing exactly that.
The text of the article reads in that same vein, but given that the title is “Monoliths are the Future” I think the author’s original intent was to describe the advantages of monoliths and point out that microservices have advantages only in relatively rare cases. Too bad they made the article about microservices instead of monoliths.
Sounds to me like a good opportunity for the author to write a followup post.
If you’re moving to microservices because the number of people working on a project is growing too large to manage and you need independent teams, great. If you’re refactoring to microservices because “we’re going to do everything right this time,” this is just big-rewrite-in-disguise.
Whatever engineering quality improvements you’re trying to make—tech stack modernization, test automation, extracting common components, improved reliability, better encapsulation—you’re probably a lot better off picking one problem at a time and tackling it directly, measuring progress and adjusting course, rather than expecting a microservices rewrite to magically solve a bunch of these problems all at once.
At the time, my workflow was to use two different notebooks for everything: foo.nb and foo-scratch.nb. I’d get things working a piece at a time in foo-scratch.nb, not caring at all how it looked, not having to worry about leaving extra output or dead ends of explorations lying around; then the refined cells would be copied over to foo.nb, which would get pristine presentation, and which I could run top-to-bottom.
This workflow worked pretty well for me: very clean reproducible output, with the ability to easily refer back to all the steps of how I’d derived something, along with copious detailed private notes.
I never had to use it but I’m pretty sure each cell even had its modification time stored in the metadata in case I wanted to view a chronological history.
Compared to hacker news, my main issues with twitter are a much lower signal-to-noise ratio, lack of prioritization over time windows—if I take a day/week/month away from hacker news, it’s easy to catch up on the top things I missed at https://hn.algolia.com —lack of depth in content, and pervasive tracking across other sites including through t.co.
As a first approximation, this is how much money it would cost to buy all the shares. You’d pay $SHARE_PRICE for each share and then own the entire company. Therefore the concept is a decent measure for what the market has decided the company as a whole is worth.
A company with 10x the market cap of a competitor is considered 10x bigger, because it would take about 10x as many dollars to acquire.
I say “first approximation” because if you actually tried to buy all the shares on the open market, then increased demand would drive the price up, and not everyone would want to sell right away. In an acquisition, the acquirer offers a deal where all shareholders get, say, 1.25x the current share price, but only if all shareholders sell all their stock. And the board of directors of the company being acquired can compel all shareholders to do so, if that’s in the best interest of the shareholders.