This sounds to me like a "Spiky Profile": exceptionalindividuals.com/candidates/n...
Basically, some people can be really amazing at some things, and really not amazing at others. Instead of being well-rounded in aptitude, they're "spiky", and that's a-ok, too.
quick appreciation post for @farrah.bsky.social. I just got back from @awscloud.bsky.social re:Invent. I’d never been before & I was NOT ready for how much event I was in for. massive
despite the scale, Farrah made it feel like a cozy event. she did an incredible job for the community this week 💜
The day has come where we get to announce what we've been working on for the past year 😍
www.duckbillhq.com/blog/skyway-...
Happy exploding whale day to those who celebrate. 🐋
www.oregonlive.com/travel/2024/...
I'm having the Away Days Mr. Ordinary English Bitter, and Ben's having the Great Notion Brewing Devil's Night Schwarzbier.
Ben and me rotating secrets while having beers. Timbers soccer paraphernalia lines the wall behind us.
Just me and my friend @binford2k.bsky.social rotating secrets on a Friday afternoon over beers @thebeermongers.bsky.social in Portland. Which we can do, cause archodex.com makes sure we know everywhere our secrets are used so we don't cause outages.
Sorry, what I was trying to ask was: Is it worth it to write the larger blog post at all? Maybe people don’t click through enough, and one should focus just on the LI short posts?
What’s your take on whether to just write small LinkedIn posts, breaking up a larger thought into chunks, or doing the same but each post links to the full blog post? Is the blog post helpful, or do people only bother to read LI posts?
a thread of harsh truths to vaccinate you against chatgpt psychosis
1. AI will not make you more interesting.
AI-generated words may be helpful for your own research. Nobody else is interested in reading them. Assume nothing written by AI is worth publishing.
AI will not earn anyone’s respect.
Me @ PDX DevOps meetup tomorrow: www.meetup.com/portland-dev...
* 😱 Fun ways orgs screw up secrets management (case studies)
* 🥷 Self-defense against engineers wielding spreadsheets (what to do when someone turns on GitHub Secret Scanner)
* 💡 Using eBPF to creep on secrets in action
See you there!
Was it just that the SDKs impacted cold start? Or are there additional reasons?
me: the reason both options suck is that you can’t express an adjacency matrix in json
coworker: yeah, it has to be an ad-json-cy list
I’m still using an intel era macbook pro, but rust dev is so slow. I make a one char change, then have to wait 30s to see what new error squiggles appear in vscode. Probably time for an upgrade…
I describe the architecture in more detail and provide further thoughts and recommendations on DSQL in my post. You might be surprised by my conclusion given the above :).
chasedouglas.net/p/vaultwarde... (8/8)
3. Columns cannot be added with default values or other constraints to existing tables. Hopefully this is addressed by GA. More concerning is that the docs do not make this clear. I worry what other quirks lie improperly documented only to be found in a future migration. (7/8)
2. Only one schema change (DDL statement) can be performed in a transaction. This will almost surely require special casing your migration code and extra care performing migrations. This is a big issue that I hope can be resolved by GA, or adoption will be limited. (6/8)
1. Foreign Keys aren't supported (yet?). This isn't really "news", but on the plus side I found Vaultwarden's PG backend doesn't depend on FKs even though it defines them. You might find the same to be true for your workloads. (5/8)
I detail the serverless architecture in my full post linked below, but I'm going to focus on DSQL for this thread. I successfully swapped it in as a PostgreSQL DB with a few code changes, but I also found some very sharp edges that give me pause. Key learnings: (4/8)
As a quick recap, Amazon Aurora DSQL is a horizontally-scaled, truly serverless (scales to zero and back without scaling delays) database. It's PostgreSQL-comptabile(-ish). I'm excited about it as a serverless relational database option for common workloads! (3/8)
Use case: Replace my password manager with Bitwarden + my own serverless cloud sync backend. Solution: Vaultwarden (github.com/dani-garcia/...) + modifications to use AWS CloudFront, Lambda, S3, SES, and ... DSQL! (2/8)
I became annoyed with my password manager and decided to do something about it. Along the way I scratched another itch: Is AWS Aurora DSQL for real? #aws #serverless (1/8)
