Author argues that values long embedded in Ruby culture (testing, readability, design) are very useful for collaborating with AI, gives an example os asking Claude to follow tdd
1,189 karma · joined January 17, 2016
> In addition to specifically named browser versions, you can also pass :modern as the set to restrict support to browsers natively supporting webp images, web push, badges, import maps, CSS nesting, and CSS :has. This includes Safari 17.2+, Chrome 120+, Firefox 121+, Opera 106+.
https://edgeapi.rubyonrails.org/classes/ActionController/All...
I’m not saying your gem is bad. It’s nice to se an attempt at a circuit breaker that is based on the state machines gem, I will certainly look into the actual code if I have a need for it in the future.
Just wanted to give you this bit of feedback about maybe cutting down on length and loosing the ai images in the readme as I think it might be a turnoff for others as well.
Nevertheless, your question would have yielded a better article.
> but why do we collectively place higher security requirements on webhook requests than API requests?
We really don’t, signing is just more convenient in the webhook scenario. And it’s also completely optional to check a signature, leading even to many implementations not doing so.
For me it seems clear that the reason for this different approach is that api requests are already authenticated. Signing them would yield little additional security. Diminishing returns like the debate over long lived (manually refreshed) api keys versus short lived access tokens with long lived refresh tokens - or, annoyingly, single use refresh tokens that you have to keep track of along with the access token.
Webhooks are unauthenticated post requests that anyone could send if they know the receiving url, so they inherently need sender verification.
https://naildrivin5.com/blog/2019/07/10/the-frightening-stat...
> This book won’t teach you how to actually make software […] It’s a manual that explains how the things you use everyday actually work. You don’t need to be technical to read this - there are a lot of pictures and diagrams to do the heavy lifting. You just need to be curious.
I could not find this in the app, maybe it’s Android only, an upcoming feature, or requires the Busy Bar hardware device.
Still, for me, having a fully open source first party tool like kamal is much better than a commercial offering, no matter how convenient it may be.
> I can thus completely understand why the likes of Elon Musk or Mark Zuckerberg continue to show up for the daily cage match of running high-profile companies. Why the appeal of sitting on a beach is limited to that of the occasional break, not a permanent arrangement. It's because the drive that got them to where they are isn't extinguished by achieving personal, material wellbeing.
That said, I had not considered that, for some, keeping themselves on top of the capitalism leaderboards might also play a petty role.
It’s rare that we get to see the complete picture of something that has many paying customers like this, and I’m thankful for the Campsite team for sharing it.
>First, for the main source of data, I chose all Mr. Beast videos with uploaded (ie. non-auto-generated) transcripts—a total of 229 out of 837 published videos on his flagship channel. This gave me a source of processable ground truth about where money was mentioned and also limited the videos to those published the last 6 years, which make up the majority of his meteoric rise. Then, I downloaded the videos in 360p and scraped their transcripts for every occurrence of a dollar amount, logging each mention with its sum, video, and context in a database that I would build on top of as I nailed down the exact timing. I used those contextual timestamps to make rough clips that I fed into the open source AI tool Whisper to (a) get a more precise measurement of where “X dollars” was actually said and (b) standardize and double check that my first scrape had gotten the amount correct. Finally, as many of the clips were still off by a few annoying and noticeable fractions of a second in any direction, I made a script that allowed me to go through each entry individually, trim or extend the clip on either end, and modify the amount one last time if my first 2 methods had failed. After all 2800+ were processed—a task that took weeks—I made a final set of clips out of higher quality versions of the videos and used Premiere to make the film’s final dizzying supercut you see before you.
>90% of data science is data cleaning, and I have kept this overview pretty high-level in the interest of making it accessible to a wide audience. A much longer and more technical dive into the steps needed to go from a raw YouTube archive to this video—including everything from token suppression, the comparative benefits of transcription libraries, counterintuitive ways to standardize and parse numbers in natural language, and debugging audio desyncs in clip concatenations - may appear in the future on my website.