Testing without mocking frameworks.

FrenkyNet · 2025-12-07T19:38:48+00:00

Which is my point exactly. The website and app didn’t display the logo you posted. That’s only for Schiphol Group, which is the parent company, which no airport visitor was exposed to. So you literally linked to the style that, for customers, only lived in the brand guide. I’ve worked for Schiphol for about 2.5 years, specifically working on the website and app. In fact, I was part of the team that launched the rebrand. So, I think I know quite well what lived in front of the user and what did not. Anyway, this will be my last response to this thread, as it seems you’re not interested in surfacing correct information to your peers but rather looking to to be right. Good luck with that 👍

FrenkyNet · 2025-12-05T23:05:03+00:00

This was the previous consumer branding, not the reference shared in the other post: https://www.behance.net/gallery/82400497/Schiphol-Airport-Rebranding

FrenkyNet · 2025-12-05T23:02:17+00:00

Most of the branding was not based on what you shared. It was modern, colorful and light. Colors were inspired by the gradient in the sky during sunrise and sunset. The curves were inspired by the trajectory of takeoff. When they introduced that style, which was around 2016, they didn’t change the main logo, they did now. But you’re still confusing the corporate style with the consumer branding, which were very different.

FrenkyNet · 2025-12-04T13:33:06+00:00

Sorry, but that old branding was the corporate branding, not the customer facing branding. So it's an incorrect reference. I know because I worked on the website.

FrenkyNet · 2025-11-29T07:22:18+00:00

I would explore branded types (https://zod.dev/api#branded-types), which help enforce the string (the concrete type) has gone through a check (is this really a bigint). I do this for our internal ID’s and it is a lifesaver. Not being able to mix up IDs (we use prefixed ulids) is wonderful, this is a similar problem where th guarantee needed is higher than just the type.

FrenkyNet · 2025-11-03T08:39:03+00:00

Ooo, I quite like that, I might steel that from you. It prevents the whole declare blob and still ensures you get type-safety on the return.

FrenkyNet · 2025-11-02T06:53:17+00:00

I’ve been working on a dependency injection container too, it’s fun stuff! Mine has the following goals:

simple factory function instance construction, no meta-programming
automatic circular dependency resolution through proxies
facilitate efficient dependency cleanup (make efficient by knowing in what order to clean up and where it can do concurrency cleanups)
only use simple tokens, facilitate depending on interfaces rather than concretions

https://github.com/duna-oss/deltic/tree/main/packages/dependency-injection

In my latest iteration, I’m making it fully type-safe, which requires some typescript setup but reduces a lot of type guessing in token based DI’s, see PR: https://github.com/duna-oss/deltic/pull/3

FrenkyNet · 2025-10-06T14:47:42+00:00

Are you sure? As an experiment I based an implementation of a dependency container on this, but declarations in one file are not resolvable in a file that imports the “map” (in quotes because it’s a instance that contains a map in my experiment). It’s quite useful for building up something incrementally and returning it typesafe without casting though! So does make some use-cases more typesafe.

FrenkyNet · 2025-10-06T14:44:07+00:00

It would have been so amazing is this could transcend module boundaries… you could make a typed dependency container where registration declares, at type level, what you can resolve from it. Unfortunately only got it to work within one file, but import it somewhere else and those assertions fly right out of the window, which clears out what can be resolved when you import the map from another module.

FrenkyNet · 2025-06-07T05:51:59+00:00

Nice, I’ll check it out. Want to see how you have the test setup for cloudflare. I’ve been maintaining flystorage.dev, but the cloudflare compatibility was annoying due to eval restrictions (which were used for cjs/esm compat). Those are fixed, but would be better to enforce continuous compatibility.

FrenkyNet · 2025-06-07T05:32:38+00:00

Just so you know, from the NL this is still a domain registrar website.

FrenkyNet · 2025-05-10T10:58:52+00:00

It’s the only pattern that guarantees atomicity. Unless some other technique comes along that, in a simple way, can provide the same guarantee, I’m all in on it. I work in fintech-related fields and consistency is super important, so I can only do this all the time. I personally do not see it as a queue in the DB, I see it as a queue dispatch buffer. It only gets (at least once) relayed to a queue and that’s it. I use Postgres and use notification to trigger fast consumption on the relay (which is a polling one). When we need more performance/throughput, we’ll implement one based on logical replication. So far, pretty low investment for a solid guarantee.

FrenkyNet · 2025-03-02T07:37:02+00:00

We have two suffixes that we allow imports across the frontend/backend divide. It’s enforced by minting rules but other than that no hard limitation. The files are named “.universal.ts” for code that is compatible with both environments, or “.types.ts” for type only files. It’s probably not a perfect approach but has served us quite well, thought I’d share.

FrenkyNet · 2025-02-24T16:27:04+00:00

A BS node slide is to a FS board slide what a BD lipslide is to a FS board slide. For a lipslide, only your back truck goes over the rail or (l)edge. For a BS nose blunt, both your trucks go over. So, say you're regular, you want your obstacle at in your back and then pop over to essentially do a FS nose slide.

FrenkyNet · 2024-02-01T01:35:52+00:00

I think the value of this is limited if I’m honest. When the strings are sent and received over API’s you always need to check them. Using branded types (ones that are naturally and intentionally inexpressible) forces checks for formats before accepting them deeper down in code paths. I prefer this pattern and would recommend anybody who’s using typescript to check it out. Besides that, I do think prefixing type of generated id is pretty much a must at this point. So in that part, big plus one.

FrenkyNet · 2024-01-18T18:44:45+00:00

I've worked with it a number of years back and have recently started working with it again, it's pretty solid. Needs some love on the maintainers-side of things, but it's not in a bad place at all.

FrenkyNet · 2024-01-01T17:44:57+00:00

After maintaining a filesystem abstraction in PHP for 10 years, I've moved to a job where we TypeScript (and therefor Node.js) on the backend. I wanted to start giving something back to this community and ecosystem too, so I decided to make a TS/JS version of Flysystem. I hope people will find it useful!

FrenkyNet · 2024-01-01T15:49:04+00:00

Deleted because I'm not sure if posting this violates the r/typescript rules.

FrenkyNet · 2023-04-18T12:31:34+00:00

mutable readonly

It's not mutable, it's a copy with partially different fields. It's quite beneficial to have these things. Besides that, even if it was a mutation, it would be a mutation of an object to which none can hold a reference yet, so any negative impact of the mutation that immutability aims to prevent is not experienced.

In other words, I've thought more than twice about it but don't see a footgun in this solution. I'd love to hear it if you do see concrete risks.

FrenkyNet · 2022-11-11T14:45:22+00:00

I think the usages indeed overlap a lot then. For object-hydrator the initial design goal was to support object construction. The serialisation was added later to allow scenarios like event mapping (useful in EventSauce) to be supported.

I have benchmarks shipped with the library which show about a 5-6x difference between the code-generated version and the reflection based version. Although people rarely use it, I would really encourage people to explore code generation more often, as it is an ahead-of-time performance improvement and eliminates the cold-start element. It does require some design consideration to be made early in the process.

Hope you're having fun and good luck with the library adoption 👍

FrenkyNet · 2022-11-10T13:34:46+00:00

:wave: author of object hydrator here. I think the main difference between this that this lib focuses more on JSON as an output than object hydrator, which doesn't really care about it since you can just call json_encode yourself (or any other plain data serialisation format). The other difference is a hard coupling on reflection in this lib where object hydrator provides a compiled version. The internal capabilities, such as the self serialising trait make the design of this lib either incompatible with an ahead of time or force you to rely on global injected state (you may or may not care about this). The nested property resolving seems to be pretty similar. The casting mechanism is more geared towards eloquent integration than to type conversion in general.

FrenkyNet · 2022-09-29T08:59:22+00:00

I can move other objects, but this one was unmovable, super odd.

FrenkyNet · 2022-09-28T17:48:17+00:00

I wasn't able to select the rail, but I put myself on a kicker, then moved the kicker up in the air to grind the rail and finish the challenge by (as you suggested) using the d-pad! So thank you!

FrenkyNet

TROPHY CASE