> X. Dev/prod parity > Keep development, staging, and production as similar as possible

Gets interesting at the seams of software & data environments. If my preprod stack operates independently of my prod stack (due to different internal users), but preprod data stack is best tested on prod data, the seams of these two things imply there should be a separate data stack for both preprod data versus preprod-internal.

Generally pro 12-FA, but it's very service dev oriented.

I know an e-commerce company where the staging environment was completely hijacked by product managers to "stage" their data. They've even convinced management to ask IT to build a tool for migrating data from staging to production. All of this just to avoid building a proper release flow for (product-)data.

Typically this would be prohibited (at least as an employee)

Sorta, there are no SEC requirements for lockup. It is all depends on the agreement between the IPO company and the IPO underwriters syndicate. Spotify and Slack notably skipped lockup entirely.

Goldman Sachs, Morgan Stanley, BoA, ect are the ones who set the IPO lockup terms based on their risk and exposure post IPO.

Indexes, exchanges, underwriters, ect are all private institutions who mostly can and do set their own rules.

The terms are public so you can read them

Something like 20% can be sold after the q2 results are released

I am fully aware of the terms. There are lots of schedules. I was speaking to the origins of "prohibitions".

It is also worth noting that typical lockup contracts can be waived early at the sole discretion of the underwriters.

If you have holdings that are locked up, are you allowed to short stock or use options to hedge your position?

What the law says and enforcement of the law are sometimes 2 different things, but generally employees should not be shorting their own stock, lock up or no lock up.

The issue is that this creates a conflict of interest.

In the worst case scenario, as an employee, you can literally do a bad thing to cause the stock to go down. E.g. An engineer can make a bug which blows up a rocket.

So then you could short the stock, bug a rocket, and become super rich.

It's the same issue with athletes betting on their own team - it's trivial to throw the game.

My holdings aren't even locked up, and I'm still not allowed to short my employer -- true as a matter of policy which could get me fired, and true from a US legal perspective most of the time given my role.

Almost certainly, outside of standard trade restriction windows. I don't think they have any control over what you do in the market outside of preventing insider trading.

Yes they absolutely can and do. Lockup provisions are contractual and typically quite strict.

No. Typically lockup agreements prevent any kind of trading of derivative or synthetic positions (think: shorts, swaps, options, etc).

No. Especially not if you have friends who could short the stock and you come to some sort of pocket agreement that never sees the light of day. Especially then.

I'm not an employee :)

As someone that works in a data domain, I'd say it's unlikely the ads are served on a single conversation basis in the near future, if they even are today. Any modern data org like advertising is optimizing metrics of conversion (either optimizing for increasing profits via CPI increase or revenue by increasing advertising TAM presumably).

Introducing context beyond immediate conversation history will improve conversion rates & allow targeted advertising towards wider topics or higher CPI topics (like financial products), hence it's inevitable.

Has anyone considered a VCS that integrates more vertically with the source code through ASTs?

IE if I change something in my data model, that change & context could be surfaced with agentic tooling.

That's me, with BABLR. Working on getting a beta release announced in the next few days.

What's with the dismissiveness? The author is a senior staff engineer at a huge company & has worked in this space for years. I'd suspect they've done their diligence...

I'm also curious how you went from a non-platformatized approach to adopting this platform; what were the important insights for strategizing, prioritizing, motivating teams to lift existing pipelines into the new thing? Open ended question

There were two main drivers -

- inability to back-test new real-time features. People were forced to log-and-wait to create training sets for months. Chronon reduces this to hours or days.

- the difficulty of creating the lambda system (batch pipeline, streaming pipeline, index, serving endpoint) for every feature group. In chronon, you simply set a flag on your feature definition to spin up the lambda system.

How do you/AirBnB handle deeply linked features (2-hop+?) that are also latency sensitive? Maybe I'm missing something, but I don't imagine that with the transformation DSL described in Chronon.

For our org, those are by far the most complicated to handle. Graph DBs are kind of scaling poorly, while storing state in stream processing jobs is way too large/expensive. Those would also be built on top of API sources, which then lead us to the unfortunate "log & wait" approach for our most important features

we call this chaining.

In the API itself - you could specify the chain links by specifying the source.

To be precise - a GroupBy(aggregation primitive) can have a Join(enrichment primitive) as a source. To rephrase, you can enrich first and then aggregate and continue this chain indefinitely.

> Graph DBs are kind of scaling poorly

That makes sense. Since you scaling these on the read side it is much much harder than pre-computing on the write side. (That is what Chronon allows you to do)

This isn't really a drop-in replacement; they don't offer transforms out of the box.

Admittedly some of the transforms proposed in this article are a little simple & don't represent the full space of feature eng requirements for all large orgs

Actually feast does support transformations depending upon the source. It supports transferring data on demand and via streaming. It does not support batch transformation only because technically it should just be an upload but we can revisit that decision.

I'd imagine a continuation... he is also the author of Zipline