The name Maestro has already been used for a workflow orchestrator which I worked on back in 2016. That maestro is SQL-centric and infers dependencies automatically by simply examining the SQL. It's written in Go and is BigQuery-specific (but could be easily adjusted to use any SQL-based system).
Well, if you're so unimaginative as to call your cloud platform "<companyname> cloud platform", it's not the fault of the second company whose name also starts with a G.
Hello fellow ex-employee of that bank. I was in a segment governed by PCI, and they wouldn't even let us touch Gaia in fear of the whole thing being declared in scope
$ echo -n 'The SHA256 for this sentence begins with seven, seven, f, zero, a, b, b and five.' | sha256sum
77f0abb54cd09ad7b654bd5e762d7be58e7daffd1a0da6a56f5135bd667856a3 -
I saw this on HN years ago from the original that linked here.
2-3 days ago posted on 4chan's /g/ board that I remembered this sentence but didn't remember its source and the hash it contained.
Someone on /g/ found the post on HN and a large thread ensued that expired and auto-deleted 12 hours ago or so. And then this person posted it on Twitter and it got shared here.
Reposts do add value though. Think of it this way: there’s a pool of content you haven’t seen before and a subset of it which you’d enjoy seeing. If no one reposts anything ever, you won’t be able to see any of it.
In fact, some of the things you have seen before you would probably not mind seeing again. Maybe you didn’t think to save it at the time or maybe your circumstances have changed.
Anyways, I wouldn’t confuse low effort with low value.
Yup, this looks a lot like Tcl! But Tcl lets you compose code at runtime using its string lists. I doubt Python will. So why introduce another redundant syntax?
The details of how the data is stored are described in this 1979 paper by Douglas Comer: "The Ubiquitous B-Tree" [1]. Since it was invented, much hasn't really changed: practically all relational databases use some variation of this structure. I wrote about it in [2], which might help explain some aspects of how it works.
A lot of modern databases don't use Btrees anymore. With a LSM structure you can use other suitable data structures because they can be write-only. For example leveldb uses a simple binary search.
I remember the days when having to switch between x86, ppc, sparc, etc was a thing (not to mention the many flavors of UN*X) and we survived. In fact I think it was more fun back before the x86/Linux server domination. Architecture diversity is good.
I wouldn't rank glucose above fats. As I understand it, it's not exactly a "shorter battery" than fat - it is simply a form of energy that is abundant in plant life, but fat is still a (much) "better battery".
The reason our body always favors burning glucose first is NOT because glucose is "better" but actually because it is an inferior type of fuel (it creates "pollution" and is difficult to burn - you can develop diabetes from too much of it) - so our evolved system tries to get rid of it first, while hanging on to the "good stuff" for as long as it can.
> The reason our body always favors burning glucose first is NOT because glucose is "better" but actually because it is an inferior type of fuel (it creates "pollution" and is difficult to burn - you can develop diabetes from too much of it) - so our evolved system tries to get rid of it first, while hanging on to the "good stuff" for as long as it can.
This is not the standard textbook biological view of the bodies use of glucose and fats.
I'm all for having heterodox opinions but I think you should let people know what is a heterodox position, and provide more supporting evidence than when giving a textbook explanation.
You don't develop type 2 diabetes from being fat, you develop diabetes from high average blood glucose levels triggering insulin resistance.
Also, what is the pollution you are talking about? From what I understand, lipolysis generates ketones, which at normal lipolytic amounts aren't toxic.
If you are using BigQuery and your "workflow" amounts to importing data from Postgres/MySQL databases into BQ and then running a series of SQL statements into other BigQuery tables - you might want to look at Maestro, it written in Go and is SQL-centric, there is no Python dependency hell to sort out:
With the SQL-centric approach you do not need to specify a DAG because it can be inferred automatically, all you do is maintain your SQL and Maestro takes care of executing it in correct order.
My take on it is - just write for yourself. If, when you read it, it sounds like a good write up to you for whatever your own reasons are, that is all that's required. If no one else reads it, fine. But you might be surprised, a lot of other people may find it interesting as well :)
https://github.com/voxmedia/maestro/