Now you got me curious: can you get Dashcode to run on modern macOS or does it only work on Snow Leopard?
Never got to experience it back in the day and would love to try it out.
I agree with the need for a standardized development setup (be it local or in the cloud) but violently disagree with eliminating development setup diversity.
Curious engineers with oddball configurations greatly contribute to the overall health of a codebase. Forcing these folks to use a standardized configuration is a missed opportunity at best, and disgruntling at worst.
You can already do that right now (even Vulkan should work fine through MoltenVk), although accessibility will be poor when compared with Apple's offering unless significant effort is invested.
Can't help but feel that this approach might not be that cursed after all, seeing how you actually went through the effort of automatically testing all of these.
UIFeedbackGenerator (https://developer.apple.com/documentation/uikit/uifeedbackge...) has been around for a while, but it’s not exactly capable of "positional" feedback. Still, vibrating in response to actions such as rearranging list entries or drag interactions that require a certain distance threshold to be passed can feel quite satisfying.
Neat, but I seriously hope that it doesn’t become popular enough to force Spotify to combat client reimplementations such as librespot, which this is based on.
> As long as their database in docker is being incrementally updated (using the same migration scripts as on production which only apply new ones) is this hit only when spinning up a clean docker image?
Yes, but being able to quickly return to a known-good state by trashing the database is still useful because getting migrations right without testing them is hard.
Using named volumes helps because they don't need to be bridged through to the host filesystem.
Keep in mind that this might become problematic for folks that are running Postgres inside Docker on macOS or Windows, as IO performance is quite poor.
I put together a up / down migration validation system a while ago (start up two databases, apply all-1 up migrations on A and all up migrations + final down migration on B) for a pretty sizable schema.
Folks that were using Docker had to wait upwards of two minutes, while natively installed Postgres would finish in under 10sec.
There's a similar project (https://github.com/erik/squabble), that uses a portable version of Postgres' SQL parser to spit out an AST, which lints can consequently traverse.
This approach alleviates the need for bringing up a Postgres cluster to lint the schema.
I'd be curious to know if there's something to be gained by depending on a running database instance (especially because it complicates CI).