Looks interesting. Can it handle asyncapi specs too?

We use boats (npm) to define our openapi and asyncapi specs which uses file based structure to separate definitions for models, paths, params etc into separate files which makes it much more maintainable. Native refs make it super easy to reuse definitions, and you can write custom helpers in js to abstract things like the Page definition in that example.

Having a shared templating language for openapi / asyncapi specs which is ergonomic and can be used by more than just JS devs is a great idea. I'll keep an eye on this project.

Hey, author here. Right now we don't have any streaming or eventing support, but I am working on it as we speak. My first goal is to support describing SSE and JSONL HTTP streaming endpoints, but I want to work toward an AsyncAPI emitter as a peer for our OpenAPI emitter.

She was the granddaughter of a billionaire so it's not unreasonable to imagine she may indeed have had access to high end hardware. "No expense spared".

The I would expect "It's an SGI, I know how to use it."

Familiarity with 4dwm doesn't really transfer to NeXTStep or SunView, which were two other Unix window managers of the time.

The people she interacted with would surely distinguish between different Unix vendors - Apollo, Ridge, SGI, Sun, etc. - we certainly did.

You're being unreasonably hard on a fictional 12 year old lol. IRIX is UNIX. She said she knows UNIX. It's fine.

I'm not hard on a fictional 12 year old.

I'm explaining why someone in the early 1990s, knowledgeable about Unix, IRIX, and fsn, would mock the adults who created that scene about a fictional 12 year old.

If the makers of The Matrix gets credit for its realistic looking use of nmap and a fictional "sshnuke", then Jurassic Park should get jeers.

We don't credit Trinity for that scene, we credit the creators of that scene.

No, you are being hard on the character, and it's kind of ridiculous. IRIX is Unix, she recognized it as Unix, it's not more complicated than that.

It's the people mocking the scene as unrealistic, most of which do so because they didn't know the software seen on screen was real, deserve jeers.

And you are being hard on me, and it's kind of ridiculous.

Knowing Unix is not the same as knowing to use a program which only exists on one version of Unix, and which was not distributed with the OS, and which was less helpful at file system exploration than both the 2d file manager [1] and 1970s-based Unix shell tools [2].

You specifically called out "older people even working in IT", which includes me. Just because you want to jeer at people who don't know what you know doesn't mean there aren't other reasons to jeer at the same scene.

[1] Here's what the IRIX 2D file browser looked like in 1990: https://www.youtube.com/watch?app=desktop&v=IRB2MkMxgy0

[2] On a related note, The Great CHI ’97 Browse-Off was a non-rigorous head-to-head contest between different hierarchical browsers. The Hyperbolic Browser was the clear winner, with Windows Explorer coming in second, and the DOS command-line doing pretty well until it came to comparison questions like "Which planet is also the name of a car brand?" where both categories in the ontology needed to be compared.

> And you are being hard on me, and it's kind of ridiculous.

No, lol, I'm not. I'm just disagreeing with you, and pointing out that IMO your point doesn't have much merit. I don't think that's a ridiculous response to what you're claiming at all.

> Knowing Unix is not the same as knowing to use a program which only exists on one version of Unix

She didn't say she knew a program which exists on one version of Unix, she just said she recognized the type of system. That's it. That's the claim she was making.

It's pretty similar to the hypothetical situation of a kid finding a mac and saying "This is a Macintosh, I know this" and using the finder to browse and look for a program to run. Same thing, with the only difference being Unix refers to a variety of operating systems not just one particular OS.

And you're making a big deal about how she probably wouldn't have known IRIX and all this, but that doesn't really make sense and it's extremely nitpicky. Others have explained why.

> You specifically called out "older people even working in IT", which includes me. Just because you want to jeer at people who don't know what you know doesn't mean there aren't other reasons to jeer at the same scene.

As I said though, most people who jeer at the scene do so on the mistaken assumption that the software scene on screen didn't exist.

I've not actually ever come across someone like yourself who doesn't refute that, but is just basically being very nitpicky and IMO unrealistic.

> No expense spared

but he only has one single IT guy in oncall during the emergency :-)

I think that part is actually explained:

- the storm evacuates most people, essential staff only

- Nedry deliberately creates the IT emergency situation to lock out the other IT people still on the island

- The book has more details about how the IT system was over budget/rushed/flawed as another example of the hubris of the whole endeavor.

The book has a detail I especially liked: theres an automatic dinosaur counting system but it was written such that it stops counting once it finds all of the expected dinos (because the spec said they couldn't reproduce), which delayed them realizing that the dinosaurs were actually mating and in a bunch of places they weren't supposed to be. Classic example of a bug caused by software working correctly exactly to the spec.

Yeah migrations are the biggest issue for me. I really don't like not knowing what the actual shape of the document will be. Missing transactions, and not great relationship performance makes modelling some systems more hassle than it's worth.

I gave it a good go to use mongo and firestore for a few projects, but after a year or two of experimenting I'll be sticking to SQL based DBs unless there are super clear and obvious benefits to using a document based model.

There's a gradual approach there, where you start out with a JSONB column, and then as each piece of the data structure stabilizes* you move it out of json fields and into its own columns/tables.

* meaning, when there's enough code that depends on it that changing it would require some planning

This is the way I build all my apps now. Eventually the jsonb field stores nothing as it all gets moved to defined fields.

Alternatively, keep it in the JSON/JSONB column until you need to search/filter/query on it, in which case you pull it out into a column.

Even that may not be immediately necessary. I don't think SQLite has it yet, but Postgres can build partial indexes on JSONB fields.

Though most of the time, in that situation, I would pull it out.

That actually started appearing on the AWS console for me today. Annoyingly I couldn't turn it off though, as the settings page to do so is locked for my corporate account, and it opened itself back up every time I navigated.

Just to add another AuthZ approach to your great comment:

ReBAC for Fine Grained Authorization (FGA) is also something that's becoming more common at the moment. Google released their Zanzibar whitepaper explaining how they implement FGA for things like YouTube and Drive and it's lead to a lot of new tooling based upon it.

I'm working on a project at the moment with quite complex document management with various levels of access. Auth0 open sourced their FGA implementation recently as OpenFGA which looks ideal for our use case. As it's all fairly new there isn't much info out there about different ways of implementing it so we're kind of figuring it out as we go.

This is the thing about "OAuth isn't about authentication" argument. . . there is quite a bit of overlap between RBAC and authorization. And that in itself, if quite confusing.

What most annoys me is that OAuth is also very much about authentication, specifically outsourcing your authentication to a third party. It's not like OAuth has nothing to do with authentication, which is the knee jerk response you get from people when they attempt to simplify an explanation about what OAuth does and doesn't do.

I've heard it described as WET. Write Everything Twice. As long as it's not a crazy amount of duplication or a really obvious refactor (especially if it leads to more readable code), writing something a second time will start to show a clear pattern and abstractions will naturally develop.

Some fellow devs seem to live creating big beastly complex abstract PatternFactoryClassBuilderGenerators for simple one off use cases which should be quite simple.

Having devs and PMs on board with adding estimations and spending the time actually doing that refactor on the second or third time you're following a pattern is the tricky bit. It pays dividends long term though as you maintain velocity.

Will liking and sharing their posts mean Facebook have to give us the premium plan for free?

Yeah this is a problem with specific employees, not with WFH. If people aren't adult enough to manage their own time and perform their duties without someone over their shoulder then that's a them problem.

I worked at a company which had a similar approach to the one being considered , i.e. force everyone in. Every decision there was based on the lowest common denominators. This meant that the really good high performing people all quit. It's a ghost town over there these days.

Set expectations, support people with meeting them, fire them if they continue taking the piss. Don't ruin it for all of you high performers because you can't be bothered going through the process to fire someone. You'll have better overall performance, satisfaction, and retention if you work to get the slackers either performing or out.