shubber

Put another way, I would think that individual engineers would be better off learning the underlying tech and the tools provided that go with them. I think it's very possible that Flox (or devenv or...) reaches EOL, or ceases to track nixpkgs appropriately, or any of the other ways that software rots. Where nix develop is going to last as long as Nix Flakes do, and there's incentive to provide a migration path to whatever's next.

Even more important: every abstraction is going to leak. Maybe the Flox CLI "looks" cleaner or whatever, but in the end you'll still need to learn Nix to use it effectively. Why learn twice as much stuff as you need?

I'm extremely amused that one of the trials here was "how do I measure 6 liters of water with a 12 liter jug and a 6 liter jug?" and the article completely glosses over the fact that the framework doesn't help GPT find the simple answer "fill the six liter jug"

Also an incentive to sandbag: ship a costly feature, then next quarter ship the savings.

"A few days ago, I came across this problem" - well, volume 4A of The Art of Computer Programming was published in 2011, which gives a pretty good treatment of the Langford Pairs. The author might've made their reference clear, and called out that the Python implementation was their own contribution

Related: definitely check out https://github.com/sockjs

I just wish that various app stores had an "in-app purchase" filter. I'd spend more time browsing them if I could filter out the noise of not-actually-free apps.

DCVS is a fantastic advance. Git isn't the best example of that, though. IMO, the UX problems of Git have everything to do with its internal model of revision history, not the structure of the internals. But I still pine for http://monotone.ca

Which is all interesting, except the shell script is a wrapper on "download this tarball and unpack it" or "download this rpm/deb and install it." So whatever security concerns existed on those approaches, you only concealed them. Why exactly?

Consider reaching out to a new in-person group of users. Bring the site to them, show it off, and ask what they think. Local uni art program, maybe?

To be fair, Bearer Token is only one option for credentialing under Oauth2 (which also includes e.g. MAC, which is as good a authentication token as you could ask for).

And: Bearer Token is as good as the session cookies that are used in every app everywhere.

There's a valid criticism of OAuth2, and that's that there are lots of decisions that are left up to the Authorization server implementer, and they need to know what they're doing. And this is security: no one knows what they're doing well enough.

My favorite assertion is "Javascript has the flattest learning curve of any language." I wonder if the author can explain prototypal inheritance, or function hoisting.

It seems like Mongo in particular is reinventing the RDBMS wheel entirely, except with a frustrating JSON query language. The benchmark blog post a couple of days ago versus an out-of-the-box Postgres deploy (i.e. memory crippled) was not very impressive.

And look: they've implemented clusters - by pushing a Slony equivalent into the DB itself.

Please forgive my bile - I was a little nonplussed with Mongo, and now I have to use it for a client. Now I'm a lot nonplussed.

Which does suggest an interesting activity: a DB shootout. Presented is a set of data and specified queries. Build solutions against a database you're fond of and show us how fast is can be.

Would have to be something like a public github repo, because valid solutions would need to at least include DB configs and possibly post-query data massage.

Something like jsperf.com but for persistence.

I read from this that one of the core tenants of Web 2.0 was "content generation is for suckers" - Pinterest has in common with lots of other boom sites that they provide a venue for users to share the fruits of their own labors with others, and benefit from that fact, while the users rarely get anything out of the deal.

In Pinterest's case (like YouTube) it's possible, in fact, that their users might get really screwed, actually.

The strongest argument he makes is that there's an impedance to text entry vs. "tactile computing." Which seems pretty intuitive to me. With a keyboard a user can generate tons more information (as opposed to raw data) than with almost any other input hardware.

But you have to think about what information you're inputting. A GUI provides an ongoing dialog that guides you through the interaction with the computer. But if there's data that's unavailable a priori to the interface developer, a keyboard is still the best way to enter it.

Good to see there's some response from Rails core for last month's github kerfuffle.