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.

There are certainly ways, though, in which the Rails community (and its leaders) have enshrined childish behavior.

The sad part is that it's about 50/50 - some of the core team are gigantic jerks with inflated egos. Some of them are lovely. And the only thing I can say bad about the lovely ones is that they don't call out the jerks for their jerkiness. All that is needed for evil to triumph and all that.

One more reason to switch to Universal Zebra Time!

Maybe they're built on Rails?

"...what is the solution to this puzzle?"

Surely the answer is "I have deduced that I do not want to work here. Good day."

Wow: 69 whole picowatts of light if the ambient temperature is about 200F. And fundamentals of the physics mean that neither of those figures is likely to change.

If the claim were more spectacular, we'd call this snake oil.

"The alternative would be to make Rails secure by default, but that would mean pretty much nothing would work until you explicitly granted access where necessary."

Given the amount of logging that occurs if you do set whitelist_attributes, it's not like this is a huge problem to fix. And, that logging (and the fact that your app mysteriously doesn't work) serve as a loud signal as to what action to take. On the other hand, the "insecure by default" solution is a silent and potentially catastrophic failure.

Compare to how brake pads squeal: even the least mechanically savvy driver brings their car to a mechanic when their pads are running thin.

Finally, the suggested fix (which, frankly, wouldn't have helped github) was simply to update the default generator to set whitelist_attributes, rather than merely including a comment to the effect. The "everything is broken" list would be introductory guides, full stop. So, novice developers would be held up until the guides could be updated with good security practice. Experienced devs, who supposedly all know about this, wouldn't have any problem on new apps.

And the core team have basically said "meh, too much trouble." Apparently, they haven't been chasing html_safe! calls through their views, which is frankly way more of a pain than attr_accessble'ing data fields.

A practical outcome of the bound (that the PageRank change for a new link is bounded by the PageRank of the source of the link) was the WordPress link selling affair from a few years ago.

Every WP blog had a link at the bottom: "Proudly powered by WordPress" - which meant there were lots of in-links to WordPress's main site. Links from WordPress were therefore very influential, and the WP admins sold links to SEO shops for a tidy sum. There was some outcry when this was discovered, as I recall.

That's something I couldn't find when I was following up on the whole thing. Could you point me to that?

I've always found that post a nice tutorial on how to build gems.

Just to plug a little bit, I've been working on a set of Rake Tasklibs to manage building and releasing gems called corundum that I'd be glad of feedback on.

We've recently started do a lot more acceptance testing in browser, writing unit/integration tests in response to bugs. The acceptance tests are slower, for sure, but the do cut "deploy and wait for bug reports" out of the dev cycle a lot more often.

Wrong: first item should be environments as first class types. Much of the rest follows. And you can stick it to smarmy common lisp geeks.

As a side note (for all of you who've typed :wq in the code entry field), you can 'gem install rubywarrior' and play Ryan Bates's original locally. A little snappier, too.

On the other hand, the Ruby equivalent is

def in_context(*args) setup_context yield if block_given? ensure teardown_context end

I guess you could build a special class, but why?

This idea is incredibly seductive to me, but the trouble I've always had is made completely lucid in your description of "conjugates" that are "only partially left inverse." The issue is that so many operations that it would be nice to be able to use as a conjugation aren't actually reversible.

At best, you have situations where the flawed reversal is acceptable - the Ruby File::open("file"){} example, or the J example for computing magnitude. close(open("file")) isn't exactly as if nothing had happened.

sqrt(a2) ?= a // only if a >= 0

But, consider parsing and templating: Could you template back exactly the input that you parsed to get an internal representation? Only if every character of input is unambiguous and significant - in other words, almost never.