kylecordes

I wonder if it will do any better than past versions when one begs and pleads for it to get a job done using a concise, modest amount of code (as an expert human developer might), rather than responding to all prompts by shoveling in a large amount of code.

For years we've been seeing the hype about how axial flux electric motors will save 100 or even a couple of hundred pounds per car. Does this announcement mean we're finally starting to see the first increment of that actually happening?

(The motor is less important than the battery in terms of total weight, long term durability, etc. But nonetheless, any improvement helps!)

This, of course, is why it's wise to wait a while after an IPO for the market to figure out how it values a new stock before it joins the index.

I remember thinking that they were making great software, but finding revenue to make the investment payoff could be quite challenging. Looks like that's been solved.

Very clever to mention Bun in the title here - probably increases the clicks notably.

(We have a couple apps that use BullMQ, and I keep wondering if we could drop Redis and use a PG-backed queue instead, for fewer single points of failure. Maybe this is the one.)

We have an app on Heroku and obviously the writing is on the wall there. We looked around a bit and picked Digital Ocean as our next host:

* their app hosting product is similar to Heroku.

* very easy onboarding and controls for modest complexity apps. Unlike the extreme hoop-jumping required to do anything on one of the major cloud providers.

* everything looks reasonably up to date.

* it's an actual operating profitable company that's been around a while and probably will be for a long time... not a startup burning capital.

That said, this magic containers thing looks more analogous to Google Cloud Run, which I think is an absolutely fantastic offering. Unlike almost everything else out there, Cloud Run and presumably Magic Containers can do things like have a whole bunch of versions of your app up and running ready to come to life when a request arrives, but scaled to zero in the meantime. This category of hosting should be far more popular than it is, and it is wonderful to see another company offer it.

"Verifying age undermines everyone's data protection"

That's the whole point, right? A pretense to remove any remaining anonymity from communications?

Governments are endlessly infested with the worst people. They look back at historical attempts at totalitarianism and think to themselves, "Let's facilitate something like that, but worse".

That seems like a good bit of psychology as it accommodates both people with the mental fortitude to type in their genuine max bid in the first place, and also people who don't really know what they're willing to bid until they see somebody else bid higher.

Auction site design where most every transaction is a very material amount of money for buyer and seller probably have different trade-offs from something like eBay where most items are rounding errors compared to the income or wealth of the participants.

For example, think about "sniping" from the seller side. Sellers are rightly concerned about any wrinkle of the bidding process that might leave money on the table. Automatically extending the time so that every potential buyer has time to "answer" a new bid soothes the concern that buyers were willing to pay higher, but they didn't have the technological prowess to post their bid in the last 0.3 seconds.

Obviously anybody can post gross things by running an image generation/editing tool locally and publishing the results. People then mostly blame the poster whose name it then appears under.

Seems like a pointless and foolish product design error for X/grok to publish arbitrary image generation results under its own name. How could you expect that to go anything but poorly?

These tools always fall short, not because the teams making them are bad, but because the underlying chat tools they build on are adversarial to the idea of a third-party UI replacing their UI. A new entrant might escape their ire for a while, of course.

(This is an exaggeration:)

Sure, you can have your LLM code with any JavaScript framework you want, as long as you don't mind it randomly dropping React code and React-isms in the middle of your app.

c appears to be the speed limit of the propagation of information in the universe - never say never, but so far it appears quite unlikely any new physics will overturn this.

I'm always thrilled to see eCharts mentioned anywhere. It is a highly featureful, complete solution for making sophisticated data-intense charts. Various commercial alternatives pale in comparison.

Likely so, but you have probably listed a bunch of organizations already utterly swamped with eager and qualified job candidates relative to their hiring numbers.

Historically, the way to standardize how a component appears with Tailwind is to use component abstraction in whatever tool you are building with to accomplish that. Define a button once somewhere and then throw on whatever classes it needs.

If you were copy-pasting long strings of Tailwind classes all over, you were already doing it wrong before you even heard of Daisy.

A challenge with TSX, and as I understand other similar tools, is that it doesn't support TypeScript decorator metadata. A few years ago, libraries using that started to get popular, so many older projects have a significant obstacle to moving away from running the TypeScript compiler JS output.

Starting a new project today, I think the right move is to use TSX or Bun or whatever. You want a roadblock at the very first moment you start trying one of these limited compatibility libraries, Because it won't work and then you'll pick a different library that doesn't rely on non-erasable TypeScript syntax.

Seems like insurers should be rating based on your worst health markers, including weight, over the last N years rather than just a current point-in-time snapshot. Someone who somehow has no medical records over the last few years at all that would capture any of that data would be priced on the assumption the past was possibly worse than current.

Local first is easier to scale technically.

Paid hosted software is easier to scale financially.

Without the latter, it's very hard to come up with the money to pay people to build, to support the market, etc.

That's the kind of thing you say when you don't want to pay the market price.

On the plus side, when you're a seller, you want buyers who have this attitude. That they are going to war and the only way they can emerge victorious is by deploying an enormous amount in your direction. You want buyers who will brag to their friends about how much they spent.

If uv disappeared tomorrow, five projects would spring up to make compatible implementations of its functionality.

Yes, that is a good assessment. Products close enough to this decision that you have to talk about it don't have enough of a moat. Generally, a product should either serve sufficiently complex needs that build is impractical, or serve customers at a small enough price point that buy is obviously cheaper.

Reason 1: General Fandom

Reason 2: Consider SpaceX's Falcon 9 record in terms of flight pace, total mass delivered, etc. This gives ample reason for optimism that Starship will ultimately work... though the flight test record of Starship so far has been notably spotty.

SpaceX does not seem inclined to give up anytime remotely soon, is bringing in tremendous cash flow via Starlink and has nearly unlimited ability to raise capital. Musk presumably has enough influence in Washington to keep the FAA on board... and that is the only permission they need to keep trying as long as it takes.

My usual gripe:

Somehow it is unethical for person/organization/etc putting on an event to make more money on tickets in hot demand.

...but ethical for opportunistic arbitrageurs to make that money.

This suggests a highly misguided notion of ethics.

Unfortunately, many businesses are arguably a bit worse than that: success this year means you put even more at risk next year.

(For example, you get successful enough that you need a bit of office space. Well, your little business is not going to persuade anyone with nice office space to lease to it alone... Landlords will instead demand the owners personally guarantee the lease, i.e. commit to paying it or go bankrupt trying, even if the business shrinks and no longer needs or can afford the space. So you thought, great, we had a couple years of strong growth. Now you get to commit personally to five years of a huge expense. Congratulations.)

I've been pointing people in two directions for this category:

Best? SavvyCal.

Cheapest good-enough? TidyCal, it is one-time-pay.

This reminds me of something I did back in 2008, we were using Postgres, not SQLite, and we needed to get a backup from one production machine onto several other machines. Copying saturated the network for an hour - And we needed to copy four times if I remember right. We didn't want to wait four hours.

I found this tool laying around "udpcast" and used it to send the backup over the network just once to all the destinations at the same time.

https://kylecordes.com/2008/multicast-your-db-backups-with-u...

Tailwind, at least for the last couple major versions, only adds the classes you actually use (plus the resets). Baseline size of the resets is far below 50k.

Great point about the dialog element. I used it in a project recently for the first time... It was very nice to not involve a framework-heavy "portal" scheme, etc.

Tremendous boon for the dental industry. Congratulations for everyone involved in getting this through.