HN user

beeandapenguin

270 karma
Posts6
Comments62
View on HN
Claude Fable 5 1 month ago

By what measure?

I wonder how much of design capability improvements is related to our collective ability to recognize AI design tropes.

Claude Fable 5 1 month ago

If the task is so simple why use a model like Fable 5? Wrong tool for the job?

Submitted some pretty harsh feedback about this back in Jan after my old school technical father in law sent me a few AI generated “news” videos in a row about Trump and Venezuela. The AI label was technically on all of the videos but 3 taps away hidden in the video description, and not visible from the search results at all. So thankful YouTube is doing something about this.

Ti-84 Evo 3 months ago

Q: Who else had their first exposure to programming on a Ti-83/4 calculator?

Ti-84 Evo 3 months ago

Same for me, it was also my first time ever seeing code, and I still remember it well. While getting ready for swim practice in a locker room, my friend challenged me to beat his score on a button mashing game he programmed earlier that day in school on his TI-84. My 12 year old self was in awe of his BASIC skills.

Agreed. I just traveled to Peru for the first time a few months ago and visited Cusco for 7 days. For me, it was not enough, since all I wanted to do was go back immediately upon leaving. I'm normally the kinda person that wants to travel to as many new places as possible, but Peru was different. I can easily say I want to go back there at least 5 more times in my life.

Reflecting on it when I got home, I couldn't understand what made me not decide to go earlier in my life. I had Machu Picchu at the top of my bucket list since childhood as I'm sure many do, but it was never at the top for some reason. That was such a big mistake and I wish I went to Peru a long time ago, there's no other place like it, and it only gets harder to travel there the older you get since the altitude is rough. The number of elderly and retired people I saw struggling in Cusco from altitude sickness was too high. I heard a horror story of someone needing to spend a week in the hospital and unable to see a single site.

Newton spent the majority of his life trying to answer this question. It'd be more interesting if the question asked “Will Newton’s prediction that the Second Coming won’t happen before 2060 be correct?”, but that might be a bit too long for Polymarket.

Extremely slow times - from development to production, backend to frontend. Depending on how bad things are, you might catch the microservice guys complaining over microseconds from a team downstream, in front of a FE dev who’s spent his week optimizing the monotonically-increasing JS bundles with code splitting heuristics.

Of course, it was because the client app recently went over the 100MB JS budget. Which they decided to make because the last time that happened, customers abroad reported seeing “white screens”. International conversion dropped sharply not long after that.

It’s pretty silly. So ya, good times indeed. Time to learn k8s.

This is why we need more incremental rendering[1] (or "streaming"). This pattern become somewhat of a lost art in the era of SPAs — it's been possible since HTTP/1.1 via chunked transfer encoding, allowing servers to start sending a response without knowing the total length.

With this technique, the server can break down a page load into smaller chunks of UI, and progressively stream smaller parts of the UI to the client as they become available. No more waiting for the entire page to load in, especially in poor network conditions as the author experienced from Anartica.

[1] https://www.patterns.dev/react/streaming-ssr

Tangentially related, if you've ever had the pleasure of migrating away from Google Photos/Drive with Google Takeout, prepare to spend some time fixing photo metadata in your library and re-embedding exif data with exiftool. Takeout strips out the exif data into a non-standard JSON sidecar, as opposed to something more standard/well supported like XMP.

It's unfortunately hostile for non-technical users that care about their photo metadata, which I assume is most people since it includes data such as creation timestamps and location. It's not too bad to script this if you're savvy (and careful), but otherwise you'll have to pay for a third-party tool[1]

[1] https://metadatafixer.com/

Depending on how far apart your rooms are, it's not too difficult to wire up a long, flat ribbon ethernet cable[1] between rooms. They usually come with clips to help install it cleanly as a fixture. Then you can just connect it to a separate switch/WiFI access point in the other room and have the same connection speeds. However, if you have two WiFI access points, you'll likely run into radio interference if they don't have mesh capabilities.

I use an 100ft cable to go from living room to basement, and have an mesh AP for each. The Eero devices are relatively affordable compared to Ubiquiti for how powerful they are, if you want a seamless experience using multiple WiFi APs.

[1] https://www.amazon.com/Cat-Ethernet-Cable-White-Connectors/d...

Yep, and this also is referring to the P75 LCP. Notice how’s he referencing the field data from Page Speed Insights, which is reporting Core Web Vitals. Anytime these metrics are discussed it’s always the 75th percentile.

Agreed, I felt the same when toying with this concept for the first time. I initially thought I could just build directly off of deno_core, but quickly learned there's a lot you'll have to implement. Much of what I perceived as deno is really just the cli crate and other dependencies that feel somewhat "internal". Some examples of things you'll need to implement and reference from the cli I ran into were:

1. module loader: https://github.com/denoland/deno/blob/main/cli/module_loader...

2. runtime interfaces (workers): https://github.com/denoland/deno/blob/main/cli/worker.rs

3. invocation of the runtime: https://github.com/denoland/deno/blob/main/cli/tools/run.rs#...

4. permissions: https://github.com/denoland/deno/blob/main/runtime/permissio...

You can wire up some of these other packages or potentially even the CLI itself to avoid re-implementing much of the runtime over again, but it's a heavy dependency for a few crucial utilities that feel like they could exist in more lightweight runtime crates.

At the end of the day, I feel like most people potentially want to offer APIs through the runtime as opposed to a package or framework (think Netlify edge functions, Shopify functions). I wonder if they are reserving this interface for Deno subhosting customers rather than making it more ergonomic for a self hosted runtime. Kind of similar to how the runtime crate injects Deno's Web Platform JS implementations: https://github.com/denoland/deno/tree/main/ext

Yea for real. I’m sure there’s tons of reasons why it took so long, there’s gotta be some devil in the details. Maybe the standards compliance, complexity of the code base, something something “ecosystem”, all the above…

Feels like a similar situation to CJS/ESM, which is still a headache in Node regardless of its support

The question didn’t ask about production readiness. But I would say that it depends on your use case.

For example, I think Deno is an excellent alternative to Node for general purpose scripting, but that doesn’t require production readiness.

On the other hand, platforms like Slack[1] and Netlify[2] are betting on Deno for their next generation developer platforms. These platforms are still considered beta, but I think that’s a decent indicator to track status of production readiness.

- [1]: https://api.slack.com/future

- [2]: https://www.netlify.com/blog/announcing-serverless-compute-w...