Why do editors, devrel, and the like feel the need to make so many asinine edits to my blogs? Like you changed
"With search being" -> "Given search is"
Is it more clear? Idk It just rubs me wrong when I've gone through these changes 3 times with each subsequent editor changing the voice.
To be clear I am not just doing customer driven development. My goal is to show them a future they didn't even realize was possible.
One where each persons learnings helps create a more whole picture.
Along with that another contender for tank tracking software has hit the market. I'm honestly not checking them out at all.
I believe in what I am building. I can only hope that they're listening to their users and doing the same. It is encouraging though since it means others see the need.
I am 2 months into building my saltwater aquarium tracker tanki.dev and sent a newsletter out asking for feedback.
And my users showed up! #1 bit of feedback? "Make auth sessions longer" - people who track aquariums typically do so only once per week and auth logged out after 7 days.
Me logging into outlook this morning 🥴 this is not the land of milk and honey anymore.
GitHub is going for the other four nines of availability.
9.9999% available.
WELL. That was not the result I was expecting
✅ Change checklist ready
✅ Fail back plan ready
✅ Pager assigned to me
✅ Monitoring up
❌ Getting up the gut to make a hard change to avoid an inevitably worse incident tomorrow...
Not me about to take GitHub down for the second time today.
I want to ensure we're making the right moves at the right time and Elasticsearch isn't aggressive enough at balancing these settings.
I am doing my best to resist building an operator for Elasticsearch. I dont think I can for much longer though. We need a stable way to automatically change cluster settings.
Rolling upgrades? Reduce merge pressure and increase shard move speed.
Low QPS times? Lets bump up merge concurrency.
Book cover of "Designing Data-Intensive Applications, 2nd edition". It has a similar wild boar on the cover as the first edition, but it uses O'Reilly's new cover design, and the boar is now slightly colourised.
The second edition of Designing Data-Intensive Applications, by myself and @chris.blue, is finished and sent off to the printers! Ebooks should be available in the next week, and print books in 3–4 weeks. Sigh of relief. 😅
(BTW, this is a good opportunity to support your favourite local bookshop!)
🧵 ANNDDDDDDD MY SSD's WONT MOUNT because the Kingston NV2 wont train on the CM5 and buying new drives is not ideal because storage cost is up 3-4x because of the DRAM shortages.
Thank you for coming to my Ted talk. 🫡 See you in 10 years when I finally finish this project.
🧵 CM5's are ARMv8 so a few of them and I can do it! Of course none were available because of the initial shortage.
Finally get the CM5s and then I have to wait for the availability of heat sinks. Wait for a while and finally get a community made version. Now to install the CM5's FINALLY 🚀
🧵 No worries, others are posting OpenSearch containers right?
Get it running for a bit using the bitnami/opensearch containers and BOOM - Bitnami pulls their containers and moves to a paid model -_- (I know I could make my own but I don't want to maintain that infra 😭)
Dang. My Compute blade project is literally pandoras box. I initially got a bunch of the Uptime Compute blades to run an OpenSearch cluster.
After months of waiting I get the blades in, go to start up OpenSearch and BOOM. Craps out because the Amazon Linux containers can't run on ARMv7.
🧵
New favorite move. Introduce drama for no reason. Example:
I got my wife ice cream. Before handing it to her I assured her no blood was spilled getting her ice cream.
The concern that followed was priceless.
Time to fight fire with fire. Even worse AI generated PR reviews.
A picture of the github.com status page showing issues with Pull Requests, Notifications, Copilot, and so forth.
Me ships a really cool update that makes issues and prs pages faster.
GitHub:
The right way to think about it is to say that Refresh writes segments to disk. Translog "stamps" them as being official (Lucene commit).
If the Translog reaches it's flush size it'll trigger a refresh before committing the segment.
They're related but not as an either or but a both and
I just realized my understanding of the Elasticsearch/OpenSearch refresh + translog operations was INCORRECT.
I'd always had the mental model that refresh or translog flush would write segments. That's partially true...
Now with copilot instead of writing just a few hundred lines of bad code a week I can scale to TENS OF THOUSANDS of lines of bad code a week.
The amount of logistical things needed to build a startup is so frustrating. I don’t want to build a company I want to ship code that helps people.
Today I:
- created a bank account
- migrated emails
- mailed so compliance documents
Okay maybe just 6.0
101blockchains.com/web-5-0/
Who knows what happened to 3 & 4
I’m pretty sure we’re on like web 7.0 according to a bunch of random crypt bros 😆
So it’s funny the bus thread was right above this one in my feed but the “I didn’t get enough likes” I’ve not yet seen… 🔗 👀
Okay, so not only did I do a thing with Tanki I am actually starting a serious company:
relevan.dev
We're building the future of relevancy based search. We're pre-launch (despite me launching this technically here). But we want to talk to small e-commerce businesses about their search problems.
Got bored… made an app this weekend to help me track my aquarium
tanki.dev
In case anyone else with a #reeftank wants a free place to track parameters over time 👀
Together though we nailed the problem down in probably 1/10th of the time it would’ve taken before.
