d_watt

I think the idea is that someone buys the "number" with 5m to turn it from dirty to clean. The person with 5m can just point to the purchase as the source of funds, and they don't have to account for where the money came before that.

So you have 5m in dirty money under a mattress. You buy crypto with it. Put up a 5m NFT, buy it with the "dirty" crypto, then cash out the crypto into a bank, and no one can prove you were the original owner of the crypto, so it's all clean.

Out of curiosity, when you have a large amount of text flying by like with package installs, what is the expected accessibility behavior? I imagine a screenreader trying to keep up with the install logs in any way would be... chaotic.

Materialize seems really, really interesting. To the point where my crotchety old man senses are telling me that I should be careful about getting too excited about new technology.

Are there any interesting case studies of people pushing the edge of what's possible? For my use case, I have max throughput of 10k updates/second potentially materialized into tens of thousands of different views (with some good partition keys available, if needed).

If a police department has a 10m/year budget, resulting in 80 police officers employed, a 2m settlement coming out of the budget means they have to lay off 16 police officers to pay it.

That would create an department incentive to force out risky officers, as they know their jobs are on the line.

A purely in browser SQL editor and runner for education purposes, and to be able to quickly upload csvs for querying with SQL: https://editor-omega.vercel.app

Very rough currently, but press the "Chinook" button to get a demo sqlite database loaded in for usage. Or, upload a .csv and reload the page (bugs!). All data is stored in indexdb, nothing leaves the browser. cmd + enter to run the sql.

Tech note: Uses WASM sqlite + Monaco (vscode) engine. This may eventually become a electon app instead to allow other DB drivers + better sql auto completion.

Out of curiosity, how do you manage under performance in that setting?

Maybe because SMS became very popular in the US, and iMessage originally was just an extension of SMS from a UX perspective, 2 years after iPhone launched. It added functionality and fixed issues with SMS (multi-part messages, images, etc). This led to the dislike of "green bubbles" because it meant you were forcing a degraded experience on the other person. That started a positive feedback loop for iMessage.

My understanding is SMS never got anywhere as popular in the EU.

Asana lost 120m last year

Snowflake lost 350m last year

Unity lost 160m last year

Sumo Logic lost 43m last year

Jfrog lost 400k last year

Out of curiosity, is it normal for companies to IPO this far away from profitability, or is this a recent tech thing? I feel like it was a big deal when uber IPO'd so far away from profitability, now it seems standard.

To the OP's point about infotainment being okay, I wonder if the core functional components of space flight (RCS, etc), are controlled through linux. It would surprise me if it wasn't used for high level things (displays), but not the "keep the rocket flying on course" stuff. I can't really find anything about what's controlled by that Linux box in the Falcon 9.

Seems like a false equivalence. Playing Halo is itself the test. To have beaten the game is to have passed the test. If anything, that metaphor suggests students should be continuously tested to prove competence, and only by "beating" the test can they work on the next lesson. Which may be a good way to handle asynchronous learning, but doesn't work in a cohort.

Using products like this in the pastI've run into a pretty simple issue:

- Request 1 is a post that generates a "todo" with a random id "5y22"

- Request 2 is a "get" for /todo/5y22.

That works in production, but on replay of the traffic:

- Request 1 generates a different random id, "86jj".

- Request 2 is still a replayed "get" for /todo/5y22, which is now 404.

How does your tooling handle this nondeterminism in replays?

Interesting. I would think conceptually lateral joins would suffer from similar issues, as it would seem like you need to run a query, get a result, and then use it in the next query, and these are all just fancy ways of writing out subqueries/temp tables.

Lateral joins are able to use "downstream" lateral join queries to optimize "upstream" ones?

I'd normally do what's outlined in this article with CTEs. IE, make a selection, use that as a base in a following selection, repeat, until you have all your data, then join it all together in the needed view at the end.

Is there a performance advantage to using a lateral join over CTEs for this type of analysis?

The concern here is that like a dog sniffing a car and barking, the false matches give erroneous probable cause. Combo this with systems that are more likely to give false negatives to minorities, and you've created a blackhole of accountability for authoritarian harassment.

What if you're twitter? Which this person is.

I agree that if you can keep it simple, it's easier to do it. But sometimes you need distributed services. Saying only Google has that problem is a little reductive.

> So is your app mostly forms or displaying content? User preference panels? Mortgage applications? Implement it with server-side rendering with a sprinkling of JS to implement widgets the web lacks. If only part of your app requires low-latency interactions, use client-side rendering only there.

While I understand it's easy to make the argument that SSR is better, lighter, etc. It's easy to quickly violate the "Single Responsibility Principle" in that you now have two systems with little knowledge of each other both in control of rendering the UI.

I lived the era of jQuery with apps just being a bunch of jQuery extensions + SSR. Eventually the app needs to make XHR (type ahead search, nested picklists, etc), and you end up in a situation where there was just one thing controlling presentation.

For me, it's actually the exact opposite. When I use scoping like that, my normal expectation is that I'm saying "Only style .me if it's in a .tells that's in a .something". I'm doing it for selector behavior. I don't want to have to consider if I later scope a

  .something_else { .me: content 'we don't' }

it won't work because it's less specific, meaning cascading isn't working as expected. It isn't SOLID

It's funny, because in the case we're talking about, there appears to be edge case behavior if the number is a "safeInteger." While I agree in principle I would never import something as granular as "is-odd," just researching this specific package revealed an edge case someone ran into and solved, and you don't have to worry about as a dev if you take it off the shelf. https://github.com/jonschlinkert/is-odd/blob/master/index.js...

Is joining on an fkey any more performant than without it assuming the same indexing is applied?

When you say difficult do you mean from a developer ergonomics standpoint (knowing there's data integrity), or from a database optimizability standpoint?

Is this actually an objective truth? "relational" just refers to the relation within the table, it's less about having a database system with good inter-table relationship handling. It happens to be that a lot of the things we think about as relational are OLTP and have good fkeys, etc.

Is there any real reason why a document store can't have good joins between collections? If you index the lookup keys, I don't understand what about the underlying document model would make joining impossible to optimize as well as a relational model.

I had been having trouble finding clean up to date info on the ongoing coronavirus, so I made this. Wanted to share it out in case other were looking for the same.

$72/month per cluster, regardless of the size. It's interesting they're not charging per managed node (outside of the regular machine cost), makes it steep if you want to have a small cluster up.

> What we are both suggesting, I have still always called the strangler pattern. It just has three actors instead of two.

That makes sense, in practice I've seen multiple situations where it was one "monolith" directly in front of another, and rather than a strangler, it was a tumor that ended up with things intertwined. Treating it like a service oriented architecture is a good way to think about it.

You still end up in situations where logic needs to be shared. Do you duplicate Auth? What happens when a new user signs up, do you sync users over? Do they read from the same database(s)? I'll also agree with the over hyped ness of microservices, but I think breaking out services and "rewriting" them to me is the way to achieve the overall goal. Even in the strangler pattern, you'll end up needing to share functionality, and either you have to monolith services calling into each other, or a service oriented architecture.

I agree, but to me that's why it's dangerous to think about refactoring the whole codebase at once, whether strangler or rewrite. Project design is just like software design, you need to be design it for failure scenarios, eg business priorities shifting, poor execution, etc, without leaving the overall situation in a worse state than when you found it.

If you design a long lived code cleanup project where the only option is "we can't stop this project for another 6 months or we'll have an even bigger mess on our hands," that's poor project design. In this way, rewrites are almost safer. They're usually "atomic" and you can "roll back" by throwing it out if you can't focus on them.

All this is based on dynamic business and product needs that are shifting every couple of quarters, and a technical team that's getting new people, and shifting off more experienced folks every couple years. That seems to be a pretty standard expectation to me, though I'll admit I'm mostly looking at this through the lens of early, mid, and late stage startups. It may be big companies that move slowly and can guarantee resources for a larger project for a long time are a different story.

In my experience, most of the time the right decision for the business is investing the time into the core product. If you have 6 months (as stated in the article), what could you do with that time if you could dedicate it to improve the core codebase, rather than a rewrite? Worse case scenario is after 6 months you don't have a perfect codebase, but you've made it better, and you don't have yet another layer to deal with.

Certainly, there are times where that's not reasonable. Maybe the core codebase is on a proprietary technology. Maybe it's built around an EoL framework. Maybe it's built on on a FOTM language that you can't hire for at all anymore.

In those cases, which are more rare than developers like to admit, I think a piecemeal migration makes sense. In my experience, it's better to do it by altering the consumers. Whether it's a frontend that can point to another endpoint, or an API gateway that can switch out the service it's pointed to, or making a shim layer (proxy), that can serve that purpose.

Having a service that is both the proxy and the new application is a poor separation of concerns, very difficult to reason about, and makes it too easy to intermingle the logic between the old and the new. In my experience.

I had the experience of inheriting a codebase that was halfway through the process of being “strangled”, and it was a nightmare. The biggest reason being that it's not a "fail safe" way to plan a project. In this particular case, a full replacement was probably a 12 month affair, but due to poor execution and business needs, priorities shifted 6 months in. It was full of compromises. In some places, instead replacing an API completely, it would call into the old system, and the decorate the response with some extra info. Auth had to be duplicated in both layers. Debugging was awful.

While some of the issues could be chalked up to "not doing it right," at the core of it, the process of strangulation described in the article leaves the overall architecture in a much more confusing state for the lifetime of the project, and if you have to shift, you've created vastly more tech debt then you had with the original service, as you now have a distributed systems problem. Unless you can execute on it quickly, I think it's a very dangerous way to fix tech debt, avoiding fixing the core issues, and instead planning for a happy path where you can just replace everything.

If you absolutely think you need to quarantine the existing code, I'd recommend putting a dedicated proxy in place that routes either to the old service or the new service, and not mixing the proxy and the new code. That separation of concerns makes it much easier to debug, and vastly reduces the likelihood of creating a system of distributed spaghetti. What I’d really recommend, though, is understanding the core codebase that powers the business, and make iterative improvements there, rather than throwing it all out.

Has anyone had any production experience using Foreign Data Wrappers to combine the performance of different database types into one facade? IE is it actually reasonable (and something people do) to hit bigquery for a large aggregation, Neo4j for a graph query, and Redis for k/v lookup as part of a single query fronted by postgres?

It doesn't appear to, there's just a hardcoded geo json file it queries against: https://github.com/ideditor/country-coder/blob/master/src/da...

Kashmir, for instance, is only part of Pakistan.

Still an interesting exercise in geojson. I'm impressed that github automatically renders the shapefile, rather than just the text.

> Probably every technical decision maker pushing for microservices knows the perils of distributed debugging

That doesn't line up with my experience. I think humans have a pretty strong tendency to take for granted the advantages of a current situation when looking at something that solves a very specific new problem. "The grass is always greener"

"Hating" something of course doesn't matter, what does matter is response time in being able to debug production systems, and developer efficiency, and satisfaction / employee retention. So it's not orthogonal, imo, as it's very likely correlated with an efficiency loss.

I assume it's because the first example doesn't add "Hello World" which is the proof of concept of having one query return information on multiple entities.

Which in turn is an example of how GraphQL can serve to turn what can be many requests in a REST situation into one call.