mcsoft

Snowflake or sonyflake ids work:

https://en.wikipedia.org/wiki/Snowflake_ID

https://github.com/sony/sonyflake?tab=readme-ov-file

It's the kind of software where early venture capital funding can be poisonous rather than helpful. Choosing the right abstractions to build a solid, flexible platform requires a lot of user feedback. You don't get the latter unless you have *paying* customers who have switched their critical processes to your product for a while. You need to build, sell, implement, and provide several upgrades. We bootstrapped a low-code BPM platform (pyrus.com) and were lucky to break even in several years. VCs push you to grow, while premature scaling could be harmful in the long term. It takes time before your platform is mature enough to serve inherently different use cases.

I use pivot tables all the time. The concept is brilliant, but the Excel UI leaves a lot to be desired.

At first, you're amazed at the flexibility, but once you become comfortable, you suddenly hit the limitations. Can't sort by a calculated column, can't categorize without adding columns in the data, etc.

I looked at Quantrix for a while, and it was a bit too complex for practical purposes. I wonder if there are any decent PivotTable tools out there?

We'd use the Record layer, but it was Java-only then. It would require us either to rewrite parts of our backend to Java or to implement some wrappers.

I assume a couple of things here: 1) that SRE costs would be lower with fdb at scale due to its handling outages, i.e. auto-resharding; and 2) that a migration project from *sql to fdb will be finite (hence an investment I hastily called capex).

Would love to hear from anyone with experience in fdb whether these assumptions hold.

We have seriously looked at FoundationDB to replace our SQL-based storage for distributed writes. We decided not to proceed unless we are about to overgrow the existing deploy, a standard leader-follower setup on the off-the-shelf hardware. The limiting factor for the latter would be a number of NMVMe drives we could put into a single machine. It gives us couple dozen Tb of structured data (we don't store blobs in the database) before we have to worry.

fdb is best when your workload is pretty well-defined and will stay such for a decade or so. It is not usually the case for new products which evolve fast. Two most famous installations of fdb are iTunes and Snowflake metadata. When you rewrite petabyte-size database in fdb, you transform continuous SRE/devops opex costs into developers capex investment. It comes with reduced risks for occasional data loss. For me it's mostly a financial decision, not really a technical one.

The article says nothing about how they instantaneously updated millions of user feeds. It was the most challenging task, as it's way easier to scale reads than writes in distributed systems. Rumor has it early Twitter had a target of 5 sec to update everyone of 50M fan feeds when Justin Bieber touched a screen. I would love to hear some technical details on how they did it.

PRQL is a breath of fresh air. Reporting languages generally miss built-in visualization and drill-down capabilities. Ideal reporting query should define not only how to seek, join, and and aggregate data, but also how to visualize output and how to present details in reaction to user clicks. There are some limited efforts like in PowerBI and Splunk but we need a standard. I wonder if PRQL guys will address this need in the future.

exactly

Double-entry bookkeeping is essentially the law of conservation of energy applied to balance sheets. It's much more deep as it was invented some 5 centuries earlier than programming.

The sad truth is in any disputes Airbnb is usually on the host side, not on the guest side. Looks like in their business model sellers have far more leverage over the marketplace than buyers.

Both CTEs and this idea address the same problem: poor readability of complex SQL queries. Compared to CTEs, the author takes the idea to split the complex query into parts to the next level.

To your point - a solid IDE will show you what's being processed at each line (or returned, if the cursor is on the last line) - in an autocomplete window or a side panel.

Luckily it was one time effort which allocated less than 1% of our annual development resources that year. After we've walked away from large arrays allocated in LOH - there were no issues despite further traffic growth.

thanks!

Some predictions were super accurate (i.e. Europe to America in 8 hours), some failed (lunch in 4 pills), but, due to immense optimism of human nature, one just couldn't envision the most influencing events of XX century - the rise of totalitarianism resulting in World War II and all its disasters. Something I can't escape thinking about when reading modern predictions.

You may wish to check https://pyrus.com - they are focused on no-code end-to-end processes with very flexible (and non-bloated) workflow setup, open API, and neat mobile apps (which is a must have feature for getting timely approvals from C-level guys).

(Full disc: I'm insider)

Since E2E encryption is not enabled by default in Telegram, I believe it's used by 2% of their users at most. Messages of the rest can be read by Telegram team.

https://www.google.com/search?newwindow=1&q=are+telegram+cha...

It's surprising how Telegram successfully lured public to believe it is a secure messaging app while not providing end-to-end encryption by default.

You need to explicitly start secret chat (under More button on the contact page) to opt-in for E2EE, something you get by default in every Whatsapp chat.

The tradeoff is performance vs features. WireGuard runs at the kernel level, is focused on performance but very minimalistic in terms of features.

Finally, someone came up with a good wording for 'Slack is #1 productivity killer'.

One practical reason we chose Nats over Kafka was that Nats doesn't need zookeeper for HA.

Nats doesn't provide message durability too, luckily it's not required for 95% of our use cases. Also, having NATS already implemented it's a natural move to use NATS Streaming for durability rather than introducing a completely new technology to your stack.

Less pieces - fewer chances something breaks.

We used both zeromq and its sort-of-descendant nanomsg but eventually moved to NATS because of it's approach to high availability (every node knows the topology of the whole cluster) and zero management overhead.

Some criticize NATS for the absence of message durability in the core technology, but we figured out we can drop this requirement in 95% of cases. Your microservices should be highly available anyway, so there's always a live consumer - and it's better to handle the message to it directly rather than introducing the overhead of storing a message somewhere and dealing with more-than-once delivery.

There's a bit more to that like you should let your microservices exit gracefully and finish processing consumed messages. And of course in 5% of cases, where you can't allow to lose a single message, you have to use NATS Streaming or the likes, but so far we've been greatly impressed by NATS for high load.

It's insightful to learn that in their guide on pricing Sequoia cites Phil Libin, then-CEO of Sequoia-backed Evernote, who was later kicked out exactly because the company struggled to find the right pricing model.

Agree, though the investigators also pointed to the lack of a clear display of the airspeed inconsistencies even though the computers had identified them. This sounds more like a UX problem rather than a bug, but still the software issue in the edge case.

While it is easy to blame Boeing these days, I suspect we have survivorship bias here. Dig into Airbus software and all sorts of similar scary bugs will pop up. For instance, one may remember inconsistencies between airspeed measurements that resulted in the loss of AF 447 on June 1, 2009. Overall, it's great that at least some airliner's closed software finally gets more eyes looking at it.

I had followed this case closely. Initially they accused a boy with directing crowds during Moscow protests on July 27, there was a video evidence. He was arrested and put into jail. Meanwhile prosecutors admitted that the guy on the video is not him. They let him go, he spent over a month in jail for no reason. They dropped initial charges but instead of begging his pardon, they brought totally different, unrelated charges of his blog content being extremist. While I agree your statement in general, in this particular case it all looks very thin and biased.

This guy's father worked for Russian government space agency, trained to be a cosmonaut. Now he's in the court watching the same government prosecute his son for political youtube videos. It is a disturbing sign when authorities press baseless charges against children of people who served their country their whole life.

Apparently, the US Department of Defense determines the richest person in the world.

> There was a safer configuration as an optional extra purchase;

Forgive me if I'm missing something but these extra options are AoA cockpit indication and AoA discrepancy alert when two sensors disagree.

They don't alter software, MCAS would continue relying on just one sensor regardless of this indication. It's just an extra bit of information for pilot's decision making.

Sounds to me like another hack over the hack hardly adding much extra safety.