I would argue that "whole tree" thinking is enhanced by --follow being the default. What I mean is when I want to see the history of the code within a file, I really don't usually care whether the file was renamed or not, I just want to see the history of the code, regardless of renames. So in my opinion it makes sense for --follow to be the default because I don't care about individual files; --follow helps me to ignore individual file renames, which are usually pretty inconsequential.

tini is pretty minimal overhead and widely used, so why not use --init most of the time?

ActiveRecord::Base.serialize no longer uses YAML by default. YAML isn't particularly performant and can lead to security issues if not used carefully. Unfortunately there isn't really any good serializers in Ruby's stdlib to replace it. The obvious choice would be JSON, which is a fine format for this use case, however the JSON serializer in Ruby's stdlib isn't strict enough, as it fallback to casting unknown types to strings, which could lead to corrupted data. Some third party JSON libraries like Oj have a suitable strict mode.

The question is also not about error handling and if the file write fails, exiting with a stack trace is reasonable default behavior because there's not much you can do to recover from that.

I'm not saying never mark methods private. I'm saying the better rule of thumb is to "make methods protected unless there's a good reason not to".

By default, Google tags use automatic cookie domain configuration. Cookies are set on the highest level of domain possible. For example, if your website address is blog.example.com, cookies are set on the example.com domain.

I'm still against frozen-string-literal by default. It is arguable if the string creation limits performance so much in real-world programs. We need to first measure how much Ruby can be faster by frozen-string-literal. If it is not significant, Ruby should prefer dynamics and flexibility.

Note: This repo does not publish or maintain a latest tag. Please declare a specific tag when pulling or referencing images from this repo.

The RuboCop way is to offer an opinion in the way of a good default, but to accommodate all reasonable style choices.

If we ever moved a file to a different location or renamed it, all its previous history is lost in git log, unless we specifically use git log --follow. I think usually, the expected behavior is that we'd like to see the past history too, not "cut off" after the rename or move, so is there a reason why git log doesn't default to using the --follow flag?

Note: Git 2.6+ (Q3 2015) will propose that in command line: see "Why does git log not default to git log --follow?" Note: Git 2.6.0 has been released and includes this feature. Following path changes in the log command can be enabled by setting the log.follow config option to true as in: git config log.follow true

Thus my docs recommendation of public function beforeFilter(Event $event) // do not render out the now inconsistent one for is(json) if (!$this->request->is('jsonapi')) { throw new NotFoundException('Invalid access, use application/vnd.api+json for Content-Type and Accept.'); } } to specifically only whitelist the desired jsonapi for the general use case.

A default baked app has all those included. Thats why I am saying this - it is by default an issue we should and need to address :)

Runs headless by default, but you can configure it to run in a headful mode.

If an access modifier is not specified it is implicitly public as that matches the convenient nature of JavaScript 🌹.

Svelte is different in that by default most of your code is only going to run once; a console.log('foo') line in a component will only run when that component is first rendered.

If you call ./configure --enable-gui=auto, the build process will automatically build against whichever GUI libraries are available. A cursory glance suggests that gtk2 will be prioritised over gnome2.

The default bundle combines about thirty of these microlibraries.

I totally understand that there may be a majority still considering this a bad practice and thus keeping it disabled by default in production seem ok. But there could at least be an option to enable it for people who want to, no?

Knowing what your elements are lets browsers use sensible defaults for how they should look and behave. This means you have less customization work to do and are more likely to get consistent results in different browsers.

Record filters allow you to require an instance of a particular class (or one of its subclasses) or a value that can be used to locate an instance of the object. If the value does not match, it will call find on the class of the record. This is particularly useful when working with ActiveRecord objects.

def initialize(attributes=nil) self.assign_attributes(attributes) end

If no end line value is declared, the item will span 1 track by default.

premailer-rails processes all outgoing emails by default. If you wish to skip premailer for a certain email, simply set the :skip_premailer header:

logInfoToStdOut (boolean) (default=false) This is important if you read from stdout or stderr and for proper error handling. The default value ensures that you can read from stdout e.g. via pipes or you use webpack -j to generate json output.

This is linux. Ouput first, formatting second. systemctl --no-pager -l should be the default.

Why doesn't it do this by itself, by default?

Right, and if most uses of an FTP service use new FtpService() the one that sets an alternate port will stand out (service.SetPort(12345))

The concept of Convention over Configuration is impossible without sensible default values. The key word here is "sensible". The default values have to make sense for at least 80% (if not more) of all the uses of a library/service/framework.

However, a ActiveRecord::Rollback within the nested transaction will be caught by the block of the nested transaction, but will be ignored by the outer transaction, and not cause a roll back! To avoid this unexpected behaviour, you have to explicitly tell rails for each transaction to indeed use proper nesting: CopyActiveRecord::Base.transaction(joinable: false, requires_new: true) do # inner code end This is a safer default for working with custom transactions.

Setting up Nginx properly requires quite a bit of work. Using websockets or using Rails streaming? Make sure you disable response buffering for the relevant URIs, otherwise they won’t work correctly. Phusion Passenger 5’s builtin reverse proxy does the right thing by default, without any configuration. In other words: it’s all about making things simple.

Yes, absolutely, no two projects are alike. This step is moving towards a direction where we have a set of best practices for webpack isolated in a bundled package and can be maintained in isolation without impacting upgrades or end-user experience. If you have seen next.js or create-react-app they sort of do they same thing for ease and maintainability. Rails is a great example for this - there are some built-in best practices, opinionated defaults and gems that are hidden behind the scene plus power to do advance things where needed.