Romanticizing any society as purely altruistic undermines their sophistication and resilience.

Fortunately, we do not have to agree on everything. Linked Data enables layered agreements, in which a few rules need to be adopted by many, and sets of additional rules are agreed upon by smaller groups as required.

Freedom of course always comes at a cost: what constitutes a victory for personal rights and freedom of speech also facilitates the spread of illegal messages, since decentralized networks make it harder to control what information is exchanged. Legality is of course a tricky matter, as some countries instate laws that prevent their citizens from voicing opinions that would be legal elsewhere.

Sure, it is not needed, we can always write things in a different way. As a matter of fact, with such an argument, hardly any improvement should be accepted.

Who says it's not a word? Not a word, simply because lexicographers have not recognized it? When a lexicographer recognizes it, it has already been in use! Even Mr. Fiske says it is a word, although he obviously disprefers it.

I believe it is possible to disprefer something while either 1. not disliking it, or 2. liking it but not intensely enough to be the preference. As in, "I like tart apples, but I sometimes disprefer them as an ingredient on a green salad." It doesn't and hasn't, meant I would refuse to eat a salad with this ingredient included, but there are times when my preference would have been to have a salad without them.

I think you linguists worry too much. It's a simple enough formation using a very common prefix, and while it is not clear whether "I disprefer" means "I do not prefer" or "I prefer something other than" or "I prefer the opposite of" or "I stop preferring", either it'll settle down to one meaning or it'll carry a range. So what? This is the first time I've heard the word but I don't find it particularly puzzling.

If you said anti-prefer, I'd have a better idea of what the word meant.

Amy: It's a real word. I use it all the time (of course, I'm a linguist, and I allow the possibility that I picked it up from my linguist chums, though it doesn't seem particularly jargony to me). For me, "disprefer X" means something like "not choose X when other options are available". This is subtly different from "prefer anything over X", quite different from "not prefer X", and totally distinct from "dislike X" or "object to X".

The cell phone providers usually call them "mobile" phones which is more precise since "cell" refers to a kind of technology.

However, it is increasingly becoming just a "phone", as landlines continue to disappear from households.

I wouldn't focus too much on "posted only after human review" - it's worth noting that's that's worth nothing. We literally just saw a case of obviously riduculous AI images in a scientific paper breezing through peer review with noone caring, so quality will necessarily go down because Brandolini's law combined with AI is the death sentence for communities like SE and I doubt they'll employ people to review content from the money they'll make

To prevent accidental unsubscriptions, senders return landing pages with a confirmation step to finish the unsubscribe request. A live user would recognize and act on this confirmation step, but an automated system would not. That makes the unsubscription process more complex than a single click.

I find it ridiculous that we spend energy on debating whether an alternate spelling is "correct" - real people, not English professors and dictionary authorities, are the authorities on English-as-used, and will ultimately make the distinction irrelevant.

nowadays many people work with docker containers. Most default docker images do not have bash and something like [[ $string == *foo* ]] will not work.

The title of the question is what triggered the process of finding this Q/A for material that aided development of the above to solve a real life problem described by the title. The OP declared that base64 decode was not the "real" problem; pedantic constraint of answers to a particular "example" seems less helpful. When this question and its answers were key to helping solve real problems, alternate answers can be gifts to the community in recognition of the fact that many more people will use this Q/A to solve problems. Since the answer is on-topic per the title, I feel it is "game on".

Regardless of what your arguments are, the personal reasons of the developer are what matters for what platforms this game is provided on. You can choose to pay for the game, or not. Paying for the game supports the developer, and allows them to develop more. It is not reasonable to argue that someone should have put in additional unpaid effort to do something for unknown future benefit, or that they should charge less for a game because it's only available on one platform; that's their choice, and their decision.For context, development of Taiji was started in mid 2015; it took seven years to finish. That's with the Commercial Game Engine, and even with that, there were platform-based bugs that needed to be worked around (issues that won't be present on other platforms, or will have different presentations); here's just one of those, involving an issue around mouse sluggishness:https://taiji-game.com/2020/07/13/68-in-the-mountains-of-madness-win32-wrangling...If the developer is not already familiar with Linux, then there's a small mountain of language barriers around using Linux that needs to be overcome first, before being able to get to the game development phase. It's rare for game development to work on different platforms when it can't be tested on those different platforms. While it might be easy to cross-compile on a Windows system (e.g. via IL2CPP), that's only if everything works perfectly (which is unlikely to be the case). 

I'm not sure that isolating design is something I'd prefer. I'd rather have an issue tagged (labeled) as such, and then attach design artifacts. I start a design in the same way I start frontend, with a list of requirements and acceptance criteria in mind, the design is just an artifact, a deliverable, an asset.

Why should this conversation be separate from other conversations about the work to be done? Design is one consideration alongside frontend and backend considerations, which often all intersect and require the same participants. Shifting this discussion to a separate work item can result in disjointed conversations and difficulty finding where a decision was made.

but from previous experiences like this, the feature set has to be robust at the start or I think adoption will suffer.

I don't know how much impact the "Design management" widget vs. "Design" object decision will have, except for the extremely small number of teams that work exactly like we do.

The problem with this pile of questions is that, instead of helping the OP get out of the X Y problem, people stay focussed on Y, mark the question as a duplicate of Y in a matter of minutes and X is never properly addressed.

Rupert Read has the best idea I have heard re international climate negotiations: countries that are serious should have their own conference where they collaborate on strong targets, plans, etc. Part of which should be recognising the dangers of remaining reliant on the petrostates, planning to transcend that reliance and sanctioning them

A personalized button gives users a quick indication of the session status, both on Google's side and on your website, before they click the button. This is especially helpful to end users who visit your website only occasionally. They may forget whether an account has been created or not, and in which way. A personalized button reminds them that Sign In With Google has been used before. Thus, it helps to prevent unnecessary duplicate account creation on your website.

Warning: Do not accept plain user IDs, such as those you can get with the GoogleUser.getId() method, on your backend server. A modified client application can send arbitrary user IDs to your server to impersonate users, so you must instead use verifiable ID tokens to securely get the user IDs of signed-in users on the server side.

If I wanted to integrate this with an existing login system, “signing out” would mean signing out of my own application (and not out of my Google account).

One more example of a simple approach to this that might help a lot too is add a PORO generator. It could be incredibly basic - rails g poro MyClass yields class MyClass end But by doing that and landing the file in the app/models directory, it would make it clear that was the intended location instead of lib.

lib/ is intended to be for non-app specific library code that just happens to live in the app for now (usually pending extraction into open source or whatever).

Everything has a place so do better and find it. There is a certain belief that everything within app should be organized into functionally-named directories and any files placed in app/lib actually belongs in app/services or app/interactors or app/models or someplace if the developers just tried harder. The implication is that developers are bad developers if they don’t yet know what kind of constant they have and where its forever home should be. I reject this. Over the lifespan of an application, there will be constants that have not yet found their functional kin, if those kin ever come to exist at all; sometimes you simply need some code and a place to put it. app/lib can be the convention for where those constants can live temporarily or as long as necessary. Autoloading is really nice, let’s treat them to it.

It is confusing that app/lib is named similarly to lib . I agree, but it is not uncommon to have directories with the same name and similar function nested under different contexts. I believe developers can handle this complexity. Most similarly, Linux has lib and usr/lib . Within a new Rails app, there are many such directories that are manageable: app/assets and lib/assets (sometimes even vendor/assets too) app/javascript and vendor/javascript storage and tmp/storage config and app/assets/config app/controllers and app/javascript/controllers

And as others have pointed out, there is potential for ambiguity: if A is dependent on B, then a dependence or dependency (relationship) exists; but referring to either A or B as the dependency demands context.

There are certainly cases where you can use dependency and cannot use dependence: for example "The UK's overseas dependencies", or "This software releases has dependencies on Unix and Java". So if the dependent things are discrete and countable, it should definitely be "dependency".

For me, I don't have an issue, but there was one syntax situation I found awkward: I need to sometimes know whether it is a class or a module that I am modifying. So I may have code: module Foo module Bar class Baz versus: class Foo::Bar::Baz It's not a huge issue, but ruby would yield an error if I specify a class or module incorrectly (which can happen if you spread code out into different .rb files, so I understand why there is an error message shown, to avoid accidents). But I then also wondered why I have to care whether it is a module or class, if my primary goal is to modify something, such as by adding a method. If I want to add a method: def foobar; end then I really should never be required to have to know whether I am modifying a class or a module.

The point of acts_as_paranoid is keeping old versions around, not really destroying them, so you can look at past state, or roll back to past version. Do you consider the attached file part of the state you should be able to look at? If you roll back to past version, should it have it's attachment there too, in the restored version?

The distinction doesn't refer to the files _contents_ but how to the file is _treated_ when it is being read or written. In "rb"/"wb" modes files are left how they are, in "r"/"w" modes Windows programmers get line ends "\r\n" translated into "\n" what disturbs file positions and string lengths.

I understand Duo follows the spec and attempts to make life easier by giving users the full 30 seconds, but unfortunately service providers don’t honor that recommendation, which leads to lockouts and a bunch of calls to our 1st line teams. You can’t tell users to stop using {platform}, but we can tell them to switch TOTP providers.

Making MoneySerializer reloadable would be confusing, because reloading an edited version would have no effect on that class object stored in Active Job.

What I do care about, though, is that we might start to accept and adopt opinions like “that feature is bad”, or “this sucks”, without ever pausing to question them or explore the feature ourselves.

If we hand most, if not all responsibility for that exploration to the relatively small number of people who talk at conferences, or have popular blogs, or who tweet a lot, or who maintain these very popular projects and frameworks, then that’s only a very limited perspective compared to the enormous size of the Ruby community.

Have you ever: Been disappointed, surprised or hurt by a library etc. that had a bug that could have been fixed with inheritance and few lines of code, but due to private / final methods and classes were forced to wait for an official patch that might never come? I have. Wanted to use a library for a slightly different use case than was imagined by the authors but were unable to do so because of private / final methods and classes? I have.

If it's dangerous, note it in the class/method Javadocs, don't just blindly slam the door shut.

Been disappointed, surprised or hurt by a library etc. that was overly permissive in it's extensibility? I have not.

Exposing properties gives you a way to hide the implementation. It also allows you to change the implementation without changing the code that uses it (e.g. if you decide to change the way data are stored in the class)

Anything that isn't explicitly enforced by contract is vulnerable to misunderstandings. It's doing your teammates a great service, and reducing everyone's effort, by eliminating ambiguity and enforcing information flow by design.

Far more preferable is to minimize data structure so that it tends to be normalized and not to have inconsistent states. Then, if a member of a class is changed, it is simply changed, rather than damaged.

while I'm not as strongly against the above example code as the others, specifically because you did call it out as pseudocode and it is for illustrative purposes only, perhaps all of the above comments could be addressed by replacing your query = ... lines with simple query = // Insert case-sensitive/insensitive search here comments as that keeps the conversation away from the SQL injection topic and focuses on what you're trying to show. In other words, keep it on the logic, not the implementation. It will silence the critics.

I know this is an old question but I just want to comment here: To any extent email addresses ARE case sensitive, most users would be "very unwise" to actively use an email address that requires capitals. They would soon stop using the address because they'd be missing a lot of their mail. (Unless they have a specific reason to make things difficult, and they expect mail only from specific senders they know.) That's because imperfect humans as well as imperfect software exist, (Surprise!) which will assume all email is lowercase, and for this reason these humans and software will send messages using a "lower cased version" of the address regardless of how it was provided to them. If the recipient is unable to receive such messages, it won't be long before they notice they're missing a lot, and switch to a lowercase-only email address, or get their server set up to be case-insensitive.

A flaw can become entrenched as a de facto standard. Any implementation of the protocol is required to replicate the aberrant behavior, or it is not interoperable. This is both a consequence of applying the robustness principle, and a product of a natural reluctance to avoid fatal error conditions. Ensuring interoperability in this environment is often referred to as aiming to be "bug for bug compatible".

This doesn't make any sense, though. Once you recognize that the two may represent different addresses, you're arbitrarily choosing the first one in your system as the right one, when the second one is just as right. Just give up at that point and lowercase ’em.

Some say you should treat addresses as case-preserving as opposed to case-sensitive, meaning you don't change IStillUse@AOL.COM to istilluse@aol.com but you still consider it a dupe of iSTilLUSE@aol.com.

users/me feels like a bad idea because REST prefers to have one url per resource. You will then have: users/me users/123myId Which point to the same resource.

Exactly my thoughts on the matter! I'm coming from XML SOAP background and concept of schema just got into my blood and JSON documents rather don't announce their schema. To me it's whether server "understands" the request or not. If server doesn't know what "sales_tax" is then it's simply 400: "I have no idea what you sent me but definitely not what I want.".

Just because the code is described as part of the WebDAV spec doesn't mean it's WebDAV-specific! Status codes are supposed to be generic.

The problem with using SMS-2FA to mitigate this problem is that there’s no reason to think that after entering their credentials, they would not also enter any OTP.

This argument only works if what you’re defending is good. As I’ve already explained, SMS-2FA is not good.

You are currently allowing your users to choose their own password, and many of them are using the same password they use on other services. There is no other possible way your users are vulnerable to credential stuffing.

You can also find the combination verb+in+to, but in that case you're usually dealing with a phrasal verb consisting of a verb and the particle "in", which happens to be followed by the preposition "to".They wouldn't give in to our demands.

The house, of course, is not doing the agreeing; Cooper is! Because of the distance between Cooper and the participle phrase that describes him, the comma is necessary.

take off, should also be counted as a (multi-word) verb.

Double quotes for string literals - because pre-committing to whether you'll need interpolation in a string slows people down

Protocols are, by their very nature, open. If you can't read the protocol specification then you can't very well implement it, can you?

Unless physical stature is of relevance in a conversation, simply using a person's name is appropriate.

This depends on the ruby code. Some projects will be semi-dormant due to various reasons. That's for us to address as a community. Are we going to let a single decade-old gem prevent us from moving Ruby forward? What's the threshold? There's libraries out there that don't work on Ruby 1.9. We left them behind or replaced them. And are people depending on a gem that's unmaintained really going to be the ones to jump on Ruby 3.0 the day after Christmas 2020? This is also still supposition. Name some gems that are unmaintained and in wide use. We can fix them! We have the technology! In my opinion, if matz's objective is to make the transition to ruby 3.0 simple, then it actually makes a lot of sense to postpone frozen strings by default. Postpone until when? 3.1? So then 3.1 will be the hard break? They've been discussed for what, ten years now? How long is long enough? We've added many ways for people to start transitioning to immutable literal strings, and people are using those mechanisms widely. We've pushed this transition a long time, and we still have another year until 3.0 is out and longer than that until people will need to make a move. What is the threshold for being "ready" to make this change? Unless we're planning to wait until Ruby 4.0 in 2030 to do this, I think we should do it now. I use frozen strings in most of my ruby projects, most of them set to true via the toplevel comment, so either way, it would not affect me. Exactly. Most people already do use frozen string literals. And adding a pragma means we can transition troublesome code to the new way with a single line per affected file. Heck, we can even add --enable:mutable-literal-string for people that are stuck with some of that old unmaintained code, allowing them to have a soft landing.

If the client knows the access token expired, it skips to step (G); otherwise, it makes another protected resource request.

That tends to be the biggest cop out excuse for libraries. Just do a major version release. The fact this library lies about the encodingis extremely problematic and causes numerous bugs. Any program currently using this library is already incorrect because of this behavior. Actually exposing the problem makes it easier for people to fix.

I once had a cut on my arm. Someone asked me, is it serious? “It depends,” I replied, “on how much I scratch.”

Pleeaasse don't give "it" a name.There is no "it". You believers are part of the church in your location and you meet together.There is zero biblical precedent for a group of believers giving their particular group a name.I understand that nearly all believers do .... That in no way makes it right.Names seperate us from others of the church in our area.

You might notice that the “expires_in” property refers to the access token, not the refresh token. The expiration time of the refresh token is intentionally never communicated to the client. This is because the client has no actionable steps it can take even if it were able to know when the refresh token would expire.

Rebuilding the same Dockerfile should result in the same version of the image being packaged, even if the second build happens several versions later, or the build should fail outright, such that an inadvertent rebuild of a Dockerfile tagged as 0.1.0 doesn't end up containing 0.2.3.

Glyph 0 must be assigned to a .notdef glyph. The .notdef glyph is very important for providing the user feedback that a glyph is not found in the font. This glyph should not be left without an outline as the user will only see what looks like a space if a glyph is missing and not be aware of the active font’s limitation.

While there are many great answers regarding the "glyph not found" glyph, that won't help you actually detect it, as the text string in code will still have the character regardless of the font used to render it.

A glyph can also represent more than one character at once. Take an f_f_f ligature as an example. It represents three f characters in a row. Ligatures do not have Unicodes, because the separate characters already have codes and the the fact that it’s a ligature does not change the meaning of its parts.

It's really not always a better user experience to keep things in one browser... What if they are in a sign-up or check-out flow in your SPA, and at the last step they need to agree to some conditions in an external page? Unless you use a modal, opening in a new window would really be preferable to the user completely losing context and having to go through the whole process again.

I expect RuboCop to either make no suggestion on how to resolve the ambiguity, or to suggest something that does not change the semantics of the code as it stands.

However, the code as it stands associates the block with bar, and if the code is currently working, the programmer should definitely not parenthesize the parameter, because it would change the meaning of the code.

But this sounds like spreading fear and doubt when the Ruby parser has no such concepts :) {} always binds tightly to the call right next to it. This block {} will never go to using, unless it's rewritten as do ... end.

Why not use map, which we already have for collections? Generally speaking, the map function isn't just about collections (though that's usually how it's used in Ruby). map is more about putting an object in a context (a block in Ruby's case), modifying the object, and returning the modified object.

Weak sequencing reduces to a parallel merge when the operands are on different sets of participants. Weak sequencing reduces to strict sequencing when the operands work on the same participant.

Concurrency is about dealing with lots of things at once. Parallelism is about doing lots of things at once.

Concurrency means that an application is making progress on more than one task at the same time (concurrently)

"you can verb any noun". :) Though, comparing "ssh into a workstation" to "login to host.com", where "log in" exists, it's a bit like saying "entrance the building" when "enter the building" already works

When we have our git rev-parse examine our Git repository to view our origin/HEAD, what we see is whatever we have stored in this origin/HEAD. That need not match what is in their HEAD at this time. It might match! It might not.

There are many questions we can ask and answer about branch names. Each one is specific to one particular repository because all branch names are local to that particular repository. Any changes anyone makes in that repository affect only that one repository, at least at the time they make them.

Logically, if you just want a distinct list of event_id values, what order they occur in should be irrelevant. If order does matter, then you should add the start_time to the SELECT list so that there is context for the order.

1/ It fits into existing spec based testing infrastructure nicely, including running on travis, code coverage using SimpleCov, switching between generating a profile (RubyProf), a benchmark (Benchmark::IPS) or normal test run. 2/ Some of my benchmarks do have expect clauses to validate that things are working before invoking the benchmark.

Giants that prefer the hyphenated spelling—Merriam-Webster, The Chicago Manual of Style, and The New Yorker, have a good reason for doing so. E-mail is a compound noun, made out of two words—“electronic” and “mail.” The e in e-mail is an abbreviation for “electronic,” and it’s used in a lot of other words as well—e-commerce, e-learning, and e-business, for example. There are also other compound nouns formed from an abbreviation and a noun, like the H-bomb, which is short for hydrogen bomb. The general rule of hyphenation in compound words that combine a single letter (or a number) and a word is to hyphenate them. So, based on tradition, e-mail is the correct way to do it.

It's always a good idea to avoid things like 'both', since it's not future-proof — if we decided we wanted to support method overrides via headers, for example (which is sometimes used to get around firewalls that disallow non-GET/POST requests), then 'both' would need to become 'all', which would be a breaking change.

“All your users are non-JS while they're downloading your JS”

Will be executed right after outermost transaction have been successfully committed and data become available to other DBMS clients.

No need to construct strings that then need to be deconstructed later.

In any significant project I worked in the last 15 years, logging text messages resulted in a large amount of strings which was hard to make sense of, thus mostly ignored.

Maybe once the core onError lifecycle is implemented (if maintainers decide to go that way) everyone will discover you're right and an implementation will be built in. I think that's probably what's going to happen. But until real life has proved it, it's usually best to go for the smallest most broadly applicable solution. I can definitely imagine <svelte:error> eventually being a thing, but it's a pretty dramatic change compared to an added importable function.

I think the issue is that it's not totally perfect. It doesn't define what should happen in parent components, it's not as flexible as onError and it doesn't allow you (for instance) to nest a svelte:head inside, or decide what to do with the rest of the rendering. What do you do with <div>My component</div> in your example? What about changing the <title>? I assume you can inspect the error...does <svelte:error> allow specifying which error types to expect?

Boilerplate is only boilerplate if it's the same everywhere, which it shouldn't be.

Additionally, if you're writing a notification display in every single component, wrapped in a <svelte:error> tag, that's the very definition of boilerplate.

Meaning if you have your own roll-your-own login process and never use HTTP Authentication, 403 is always the proper response and 401 should never be used.

While this seems to me like it's probably an accurate interpretation of the old RFC 2616, note that RFC 7231 defines the semantics of a 403 differently, and in fact explicitly states that "The client MAY repeat the request with new or different credentials."

it depends on the application but generally, if an authenticated user doesn't have sufficient rights on a resource, you might want to provide a way to change credentials or send a 401.

For example, if your machine has a lot of RAM doesn't mean all apps should then use as much of it as possible.

considering people rarely make meta posts about how great their question was received, it's pretty expected that it'd be net negative.

we have no way to know that the line nameMap[3] = "bob"; isn't somewhere in your program

Desktop files are NOT executed. The line inside them that has an executable command line is the one that gets executed. The rest of the file is parsed by the Desktop Environment.

For example, there is no point in defining reloadable Rack middleware, because changes would not be reflected in the instance stored in the middleware stack anyway

If your configuration is not provided by a name server (like the information given in /etc/hosts) those tools will not show them, because they directly ask the name server.

Conversely, the more dynamically typed the language is, the less I am using an IDE and the more I am using a text editor. Of course, my productivity plummets at that point. Refactoring becomes more difficult and more (completely) reliant on unit tests to ensure they are done properly.

allRoles should be a string[] and not an any[] or a Role[]

The TypeScript team has made it clear. They do not follow semver. "minor" (X.X) releases can contain breaking changes. . The fact that someone has made a bad policy clear, does not mean that the policy is therefore good. Major releases (X) have very little meaning. This negates the usefulness of using such versioning in the first place.

which seems to resolve the issue for me and makes no casts, ensuring that Typescript can keep doing its good job of widening as much as necessary and narrowing as much as possible without me having to claim I know better than the compiler. I'm posting it here since it doesn't seem to have been mentioned anywhere.

* Now it's correct within the laws of the type system, but makes zero practical sense, * because there exists no runtime representation of the type `Date & string`. * * The type system doesn't care whether a type can be represented in runtime though.

Why not just prettier-ignore? Because I want to keep Prettier here. Still format my code. But just with another config. This already works with prettierrc > overrides. But this proposal is for a better usability and flexibility.

In the vast majority of cases when I'm using prettier-ignore I'm only really looking to prevent it from breaking my code into new lines, whilst keeping its other transformations such as switching quotes and adding space between brackets. When ignoring single lines, fixing these formatting problems by hand is very manageable. With the ability to have Prettier ignore entire blocks of code I think the ability to specify what you want it to ignore is essential.

We focus so much on black magic and avoiding it that we rarely have a chance to enjoy any of the benefits. When used responsibly and when necessary, it gives a lot of power and expressiveness.

Isolation ensures that concurrent execution of transactions leaves the database in the same state that would have been obtained if the transactions were executed sequentially

I mean, that's what a review is generally.

I wouldn't consider it switching behavior. Ultimately it's including a module -- either a manually defined and referenced one from the user, or a RSpec::Core::SharedExampleGroupModule created for the user when they defined the shared example group and referenced via the group name.

Whether you agree or not, to me there's nothing in this world that is entirely apolitical - when there are people there is politics. You don't have to agree with my views, nor do I expect you to. Diversity and disagreement is what drives mankind forward.

The primary branch in git can have any name by design.

“The data does not exist independently in the world, nor is it generated spontaneously. Data is constructed by people, from people,” (source 1).

I've seen (and fixed) Ruby code that needed to be refactored for the client objects to use the accessor rather than the underlying mechanism, even though instance variables aren't directly visible. The underlying mechanism isn't always an instance variable - it can be delegations to or manipulations of a class you're hiding behind a facade, or a session store with a particular format, or all kinds. And it can change. 'Self-encapsulation' can help if you need to swap a technology, a library, an object specification, etc.

a principle I use is: If you have an accessor, use the accessor rather than the raw variable or mechanism it's hiding. The raw variable is the implementation, the accessor is the interface. Should I ignore the interface because I'm internal to the instance? I wouldn't if it was an attr_accessor.

And, if you think about it, only the pointy ones are used un-paired in regex construct's. All the other pairs are balanced. I'd steer clear of that pair <>

Worth noting that in the case where you're proxying /api/ requests to an external server in nginx you can easily do this in handle today:

We need to be really careful about what's 'same origin' because the server has no idea what host/path the various cookies are associated with. It just has a list of cookies that the browser had determined to be relevant for this SSR'd page, and not for any other subrequests.

I like the idea in theory, however it doesn’t feel very robust – you are relying on the layout of the page in question. Many authors regularly revisit articles and add new sections and paragraphs. Now your #h2:3 link points to a previous section. (This is far less likely to happen with IDs.)

Linking directly to someone’s blog comment is very useful. Even if a blog doesn’t have an active link for each comment, it’s pretty easy to use developer tools to find the comment’s id and link to it. I’ve done this many times on Smashing Magazine (they don’t have live links on each comment). If there was no way to link to an individual blog comment, this would be a great hindrance to linking on the web. It would not be enough to link to the “#comments” section and then hope for the best. So CMSs like WordPress do the right thing by dynamically adding a unique identifier to each comment.

The reason fragments should be identifiable by users is because a user, not the content creator or the developer, will ultimately decide whether or not a portion of content is valuable or notable in some way.

Yes, the content creator should have the ability to decide how a page is generally divided, if they choose to do so. But the end user should not be restricted from linking to content fragments just because a developer couldn’t be bothered to add id attributes to every element on the page. And that’s besides the fact that it would be a waste of time for a developer to do that or to have to build a CMS that does it automatically.

The simple problem that I see with fragment identifiers is that their existence and functionality relies completely on the developer rather than the browser. Yes, the browser needs to read and interpret the identifier and identify the matching fragment. But if the developer doesn’t include any id attributes in the HTML of the page, then there will be no identifiable fragments. Do you see why this is a problem? Whether the developer has coded identifiers into the HTML has nothing to do with whether or not the page actually has fragments. Virtually every web page has fragments. In fact, sectioning content as defined in the HTML5 spec implies as much. Every element on the page that can contain content can theoretically be categorized as a “fragment”.

So why is it up to the developer (or content creator) to define whether or not a specific portion of the content can be linked to? When any page of content is created, there is no way of knowing which sections of the page are worthy of being identified.

Making effective use of this mechanism requires either control of the targeted document or generous creators of targeted documents who have liberally applied id attributes throughout a document.

That's something that has been bugging me too. I mean, it's fine if not everything is supported, but if everyone could agree on what is or should be supported then that would make a huge difference. But until then, it's going to be a struggle.

They don't look like advertisements. The second the recipient interprets your email as an ad, promotion, or sales pitch—and it does take just a second—its chances of being read or acted upon plummet towards zero. A plain email leads people to start reading it before jumping to conclusions.

Using margin is better ! If you use position:relative position:absolute You need understand correlative with div outside

From a practical point of view it's highly desirable to specify them to prevent page reflows as mentioned above. However those suggesting it should be in the html because of this are missing the fact browsers use css when building the page initially. If they didn't the page would have to be redrawn for floated elements, specified padding, margins etc.

CSS seems like the right place to put visual information. On the other hand, few would argue that image "src" should not be specified as an attribute and the height/width seem as tied to the binary image data as the "src" is.

“Who cares? Let’s just go with the style-guide” — to which my response is that caring about the details is in the heart of much of our doings. Yes, this is not a major issue; def self.method is not even a code smell. Actually, that whole debate is on the verge of being incidental. Yet the learning process and the gained knowledge involved in understanding each choice is alone worth the discussion. Furthermore, I believe that the class << self notation echoes a better, more stable understanding of Ruby and Object Orientation in Ruby. Lastly, remember that style-guides may change or be altered (carefully, though!).