Premium MOC tax support. Yaay, taxes. I think this one takes the award for most effort required to implement a feature that no-one really wants.

Webpacker used to configure Webpack indirectly, which lead to a complicated secondary configuration process. This was done in order to provide default configurations for the most popular frameworks, but ended up creating more complexity than it cured. So now Webpacker delegates all configuration directly to Webpack's default configuration setup.

On existing projects, consider the global effort to change from origin/master to origin/main. The cost of being different than git convention and every book, tutorial, and blog post. Is the cost of change and being different worth it?

Note: Instead of storing a user’s ID in the session cookie you could store a JWT, but I’m not sure what that buys you. However, you may be using specific JWT claims that make this worthwhile.

When mocking is deemed profitable:

Very often in these monorepos, packages are so incredibly specific in functionality, the question then becomes why even have a separate package at all if it’s tightly coupled? Can you use these packages independently or are they tied to specific versions of other packages in the monorepo? It’ll probably be easier to remove the mask and just work as a monolith.

There used to be other backends in addition to C: Java, CSharp, and Javascript but those suffered from bitrot and have been removed.

much software requires continuous changes to meet new requirements and correct bugs, and re-engineering software each time a change is made is rarely practical.

If a company really wanted to invest, I would prefer they dedicated an employee for X hours a week for Y months than money.

Money could be good if it is spent to provide some of the above things. Money on it's own is hard because then it means I would have to spend time book-keeping and managing instead of programming.

Personally, I'm starting to think that the feature where it automatically adds xray.js to the document is more trouble than it's worth. I propose that we remove that automatic feature and just make it part of the install instructions that you need to add this line to your template/layout: <%= javascript_include_tag 'xray', nonce: true if Rails.env.development? %>

Now that I've thought more about it, I honestly think the auto-adding the script feature is overrated, over-complicated, and error-prone (#98, #100), and I propose we just remove it (#110).

now that I've thought more about it, I think the auto-adding the script feature is overrated, over-complicated, and error-prone (#100), and ought to just be removed (#110).

now that I realize how easy it is to just manually include this in my app: <%= javascript_include_tag 'xray', nonce: true if Rails.env.development? %> I regret even wasting my time getting it to automatically look for and add a nonce to the auto-injected xray.js script

Of all the compile-to-languages, the one that strikes me as having the least merit is JSX. It's basically a ton of added complexity for the sake of what boils down to syntax. There are no real gains in terms of language semantics in JSX.

These seem to be better reasons to support sub-nanosecond resolution. I think either storing picoseconds or storing sec fraction as 64-bit integer are better approaches than storing a rational. However, either change would be very invasive, and it seems unlikely to be worth the effort.

This policy allows the test suite to stay green while letting individual teams decide when they would like to put in the effort to write more deterministic tests. They may choose to do so right away, or delay until they work on the feature again.

Other sites could absolutely spend time crawling for new lists of breached passwords and then hashing and comparing against their own. However this is an intensive process and I'm sure both Facebook and Google have a team dedicated to account security with functions like this.

Before embarking on the effort to scrape the web for new password breaches and compare against your entire user database you also need to consider the ROI. The beauty of the pwned passwords API and this, and other, implementations of it is that you can get a good improvement in your account security with comparatively little engineering effort.

But, let’s be pragmatic for a second, the 80/20 rule states that you get 80% of the value from 20% of the work and a couple of simple tests are vastly better than no tests at all. Start small and simple, make sure you get something out of the testing first, then expand the test suite and add more complexity until you feel that you’ve reached the point where more effort spent on realism will not give enough return on your invested time.