I like to rebase/squash before pushing because it keeps the commit history cleaner. However, I do like your idea so I guess I could also do a squash/merge after approval (which I already do, anyway).
* we had to resolve a variety of bottlenecks that appeared faster than expected from moving webhooks to a different backend (out of MySQL)
* * redesigning user session cache to redoing authentication and authorization flows to substantially reduce database load.
* we accelerated parts of migrating performance or scale sensitive code out of Ruby monolith into Go.
I'd like to know what database backend they migrated to. I was also surprised to read that the migration from Ruby to a more performant language had not already been completed. I assume this is because it a large code base with many moving parts, etc.
Thanks, it's always fun when you're scratching your own itch.
It's also a nice excuse to build in quality of life features that don't take a lot of time because you're using the thing all the time. My favorite one is the color coded rsync command output when DEBUG=1 is set so you can be absolutely sure your config values are producing the expected rsync flags and args.
Swiss army knife CLI tool written in Swift using only native Apple frameworks.
The primary goal of this project is to demonstrate how many Apple standard library frameworks can be meaningfully used in a single, actually-useful CLI tool.
I wonder how this compares to my M4 air with 10 GPU cores and 32 MB of RAM. My system can only run ~14B sized models at any reasonable speed. The accuracy of these sized models can be underwhelming. I am looking forward to a time when it would be nice to run models locally at a reasonable price, at a reasonable speed and with reasonable accuracy. I don't think we are there just yet.
reply