Let's all get rid of our personal means of transportation as well, super inefficient to have cars and bikes and such parked for the majority of the time! Some people even buy houses that they're never in! Or they buy kitchen equipment they only use once a month! Or clothes that people only wear for parties! Why even own anything at all!
I am pretty sure Sam has already sold the majority of his personal belongings and only rents whatever he needs when he needs it. What a great example for us all.
I got a ThinkStation P8 thinking it would be a nice workstation, but the fan noise was just unbearable. Not loud (although it could get LOUD), but extremely annoying. A cooling solution created for a rack mount system where the person buying the machine will never hear it. Absolutely unsuitable at home. I was looking into doing a Noctua Fan Swap here as well, but after reading the fan specs, I found out that this would be impossible, or possibly melt the machine. The 60mm fans on the PSU were rated at something like 25 watt _each_ and push more air at way more pressure than the strongest 120mm Noctua fan.
The Mac Studio that replaced it is practically silent and very energy efficient, while not being significantly slower.
My tinnitus requires loud fans. Also fan noise is always a good indicator of power.
When I was in highschool, I bought a secondhand Poweredge 1800-something hoping to make it my new home server after the Pentium 4 desktop I had been rocking. It was so fucking loud, I couldn't find a place to keep it that wasn't audible throughout the house. My parents were not happy.
I'm not really sure you understand what I meant with "abstractions" here. I definitely did not mean "human written abstractions". I am talking about all the abstractions in the software stack: application structure, frameworks, libraries, operating systems, programming languages. These are all abstractions that build on top of each other.
The question here is not whether we need human written code, it's whether we need abstractions. Perhaps I could have worded that better.
If frameworks don't matter anymore, then maybe the standard library of your programming language don't matter anymore. And programming languages themselves don't matter anymore. In fact, you could then argue that operating systems don't anymore either. And for that matter, why stop at the software level? You could design and build your own hardware, too. Where do we stop?
In many European countries you don't need a license for being an electrician, you may need to register somewhere although that won't be very hard. But you do need to follow the national rules and guidelines while working, which is why an education or applying to a large firm where they'll teach you on the job is not a bad idea.
This is a hobby of mine, too. It's one of the most fantastic things available on the internet. The ability to travel anywhere in the world and - as the author of the blog also said - the ability to travel back in time as well!
I did some road trips in 2009 and made pictures with a compact camera. I was able to determine the almost exact locations I shot these pictures thanks to street view, so I could see route that we took back then. One picture was shot in the dark but had a distinctive logo sign on the side of the road. Given the timestamp on the photo and the extremely blurry restaurant and motel logos on the sign, I had a good idea of where to look, but it turned out this sign was only up in a single year and it was quite hard to navigate to!
Unfortunately, I don't think you can "lock" the street view date? Nor does the map view on go back in time? I guess you can use Google Earth to view satellite images. There is a whole neighborhood in Seoul that's been completely leveled on the satellite pictures, yet you can still use street view from 2018 to travel around.
I love the kind of phenomena you're describing with the Seoul neighborhood, where a place has become unmoored in time. From online sources, you'd think it still exists, but it is gone IRL.
There was a mall in my vity that got demolished, but Google Maps still showed it active w/ interior layout and shops' details. It inspired this project: https://jacobfilipp.com/place/
Same here, I bought it when it came out in one of those nice carton boxes. It was rather buggy and hard to play without a walkthrough. The characters, the music, the story, the dialog, it's all so memorable and easily makes up for those bugs and hard puzzles. I played the remaster when it came out on PS4 as well, still great, but perhaps that's just the nostalgia.
Agreed. I actually didn't find it buggy when I bought it in 1998. I loved the box art.
I recently went through it from start to finish as an adult and found it an incredible slog to get through. The puzzles, to me, made zero sense, which sucks the fun out of the game because the only possible way to solve them is to just try everything with everything or to look up the solution.
The latest Monkey Island. Now THAT's how you make a point-and-click adventure game!
That is the difference between Gilbert's game design versus Schafer's. I much prefer Gilbert.
Cheers! We've been running the various betas in production for a couple of months now. For our Rails app we replaced most of our Hotwired/Turbo with HTMX. For me at least, HTMX just makes more sense: you control the flow of content from the client, not from the server as you do with Turbo.
For pushing updates, we use ActionCable, but we do it in a different way from what we used to do with Turbo Streams: when a record is updated, instead of sending HTML from the server to the client with instructions on what to replace, we only send a small JSON payload with the ID of the element that was updated. On the client side, an event is dispatched that any DOM element with <hx-trigger="<resource-id>:updated from:body"> will trigger on. For the rest it's just basic HTMX, only the trigger is "custom".
Same, although my M1 pro has only 16 GB of RAM and that does seem to slow it down a bit with my current usage. I recently bought a used Mac Studio M2 Max with 64 GB RAM and it's much faster, both subjectively and objectively by looking at how long it takes to run the full test suite of the Rails app I'm working on.
Popover, dialog, invoker commands, our entire production app uses these everywhere and it works really well! The fact that dialogs and popovers are rendered on the "top layer" and that nested popovers are also automatically stacked on top of each other and have 'cascading close' shows how well these standards were designed.
The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
> The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it. There is anchor positioning in CSS now but support is still limited and I find it hard to wrap my head around.
I was going to suggest anchor positioning. I found it difficult to wrap my head around too, but once it clicks it's pretty simple. As a bonus, you can use it to position many other things than just popovers.
Baseline newly available. For Germany that means 80% vs the usual 90% (I wonder how the Internet looks for those 10% who use ie, Firefox 20 and Chrome 1 or whatever), which, considering that it doesn't really degrade well, makes it pretty much unusable for serious sites.
Thanks for giving me some confidence, I converted one of our popovers to use anchor positioning and it was actually rather easy. Just had to use anchor-scope which not all tutorials use!
Can we stop calling them skills? They're mostly just documents like any other. Call them cheat-sheets or guides.
Wrapping an .md file in all this circus, with lingo carefully designed to hide the fact that under the hood you're really just dumping another text file into the LLM's context , helps nobody but people's AI psychosis.
But I guess "my LLM can use skills" sounds a lot cooler than "my LLM can read text files", so we'd rather keep pretending really hard.
> The only hard thing is still to position a popover near the element that triggers it, such as when you want to create a context menu that has to render above/below the button that triggered it.
If you put something like this in your popover class, it will resolve to the button that called it when position-anchor is not set:
top: anchor(bottom);
I'm not sure how widely supported it is but I've been using it in Firefox/Chrome.
All current browsers support anchor positioning including popover buttons being the implicit anchor. However, the anchor positioning polyfill does not support this, it requires an explicit anchor-name.
This seems like a common enough issue that it would be worthwhile publishing a "Markdown library" of "stuff HTML can do" that you can "call" from your AGENTS.md.
(They made it a skill, which brings me to another thing I've had on my mind lately: that's annoying if you know when you start the harness that you will want it to read the skill. It's a roundtrip through the model to activate it. But maybe there's a way to fix that?)
(Edit2: Claude says if you activate the skill via /skill-name in the initial prompt, you get what I want)
I'm curious how many people are involved in the design of your app and what their concerns are.
Testing for accessibility and on mobile devices has a tendency to derail the best intentions. What tools are you using for those concerns? I'm not asking because I need advice. I'm asking because I want to know what you or your team did.
It's a small team of four, everyone works on the "full stack" which is Rails with HTMX and very little JS. As the lead dev, I am usually the one to make the decision that we should use the modern browser standards.
It's a niche B2B SaaS app and luckily we know most of our users personally. They all use modern browsers, usually Chrome or Edge on Windows. There is not a lot of mobile usage although we do support it.
I'm not an LLM, but that was my immediate thought - how new does a browser have to be to support these and which browsers am I excluding by using these features?
> LLMs are also terrible at these new standards. If they even know about them, they often think they're not baseline yet and they have almost zero training data compared to the giant mountain of weird JS and CSS that people had to use before the introduction of these standards.
I really wonder if AI coding is just going to lock us into 2024-ish era languages and libraries forever.
The top-layer + cascading-close behavior is exactly why we finally dropped a bunch of custom overlay managers.
On positioning: we got farther with CSS anchor positioning once we stopped treating it like absolute offsets and started from "this is the preferred edge, then let the browser flip." Still awkward for nested context menus, but far less brittle than measuring getBoundingClientRect in a resize observer.
I am pretty sure Sam has already sold the majority of his personal belongings and only rents whatever he needs when he needs it. What a great example for us all.
reply