I just wanted to tweak Java's BufferedReader to handle custom line delimiters. Thanks to private fields I have to clone the entire class rather than simply extending it and overriding readLine().

Practically speaking, if you can't think of a reason why it would be dangerous then theres more to be gained by opting for extensibility.

Also, people prefer association over inheritance so protected as default is difficult to perceive

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".

Marking methods protected by default is a mitigation for one of the major issues in modern SW development: failure of imagination.

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

I can't count the number of times I've been wrong about whether or not there will ever be a need to override a specific method I've written.

It often eliminates the only practical solution to unforseen problems or use cases.

When a developer chooses to extend a class and override a method, they are consciously saying "I know what I'm doing." and for the sake of productivity that should be enough. period.

member access

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

The old wisdom "mark it private unless you have a good reason not to" made sense in days when it was written, before open source dominated the developer library space and VCS/dependency mgmt. became hyper collaborative thanks to Github, Maven, etc. Back then there was also money to be made by constraining the way(s) in which a library could be utilized. I spent probably the first 8 or 9 years of my career strictly adhering to this "best practice". Today, I believe it to be bad advice. Sometimes there's a reasonable argument to mark a method private, or a class final but it's exceedingly rare, and even then it's probably not improving anything.

The major use case of Reflect is to provide default forwarding behavior in Proxy handler traps. A trap is used to intercept an operation on an object — it provides a custom implementation for an object internal method. The Reflect API is used to invoke the corresponding internal method. For example, the code below creates a proxy p with a deleteProperty trap that intercepts the [[Delete]] internal method. Reflect.deleteProperty() is used to invoke the default [[Delete]] behavior on targetObject directly.

Reflection adds the ability to reverse-engineer classes, interfaces, functions, methods and extensions. Additionally, they offers ways to retrieve doc comments for functions, classes and methods.

What's the structure of the URL of a shared link?https://chat.openai.com/share/<conversation-ID>

If I continue the conversation after I create a shared link, will the rest of my conversation appear in the shared link?No. Think of a shared link as a snapshot of a conversation up to the point at which you generate the shared link. Once a shared link is created for a specific conversation or message, it will not include any future messages added to the conversation after the link was generated. This means that if you continue the conversation after creating the shared link, those additional messages will not be visible through the shared link.

The conversation will no longer be accessible via the shared link, but if a user imported the conversation into their chat history, deleting your link will not remove the conversation from their chat history.

Are shared links public? Who can access my shared links?Anyone who has access to a shared link can view and continue the linked conversation. We encourage you not to share any sensitive content, as anyone with the link can access the conversation or share the link with other people.

Shared links offer a new way for users to share their ChatGPT conversations, replacing the old and burdensome method of sharing screenshots.

it's not asking anymore of you than to just enjoy

Depends on the style guide you follow for your project. The popular Ruby Style Guide says to "Avoid using Perl-style special variables (like $:, $;, etc. ). They are quite cryptic and their use in anything but one-liner scripts is discouraged."

When I first got started with Ruby, I obviously thought that $LOAD_PATH was better. But once you've graduated from beginner status, I'd only use $LOAD_PATH if I was trying to make my code more readable to a beginner. Meh its a trade off.

The Ruby load path is very commonly seen written as $: , but just because it is short, does not make it better. If you prefer clarity to cleverness, or if brevity for its own sake makes you itchy, you needn't do it just because everyone else is. Say hello to ... $LOAD_PATH ... and say goodbye to ... # I don't quite understand what this is doing... $:

“So superior mechanically to other crowdsourced games, it was banned on Kickstarter and Gamefound!”

Mikitani

typical use would be to reference a json or jsonb column laterally from another table in the query's FROM clause.

Writing json_populate_record in the FROM clause is good practice, since all of the extracted columns are available for use without duplicate function calls.

Debug mode allows you to see only the data generated by your device while validating analytics and also solves the purpose of having separate data streams for staging and production (no more separate data streams for staging and production).

They create a lot of useful content on there site, which they are happy for users to copy and paste for use elsewhere. They wanted to know how often this was happening, on which pages, and what text.

but I literally posted a screenshot of it working. So you must be doing something wrong.

To use the tool, you need the following access: Viewer role for the Universal Analytics property Editor role for the Google Analytics 4 property After you've installed and activated the Google Sheets add-on (below), follow these steps: Import audience definitions from your Universal Analytics property to a Google Sheet. Decide how you want to export audiences from your Google Sheet to your Google Analytics 4 property (e.g., using the existing definition or modifying the definition first in the tool, then exporting). Export your audiences from the Google Sheet to your Google Analytics 4 property.

(New name for Collaborate permission.)

Effective permissions are the roles and data restrictions that a member is assigned via other resources (like the organization, a user group, or an account that includes the current property) plus all the direct permissions assigned explicitly for the current resource. Direct permissions are role and data restrictions that a member is assigned explicitly for the current resource (e.g., organization, account, property).

to recover loss of observability

Foreign companies selling into the U.S. are subject to sales tax regimes to the extent there is nexus with the state, which can be established, among other ways, through a physical contact with the state (payroll, property, agents, and inventory held under the Fulfillment by Amazon arrangement) or substantial sales exceeding economic thresholds enacted in light of the Wayfair decision.

Don’t confuse Consent Mode with Additional Consent Mode, a feature that allows you to gather consent for Google ad partners that are not yet part of the Transparency and Consent Framework but are on Google’s Ad Tech Providers (ATP) list.

Will not read or write first-party [analytics cookies]. Cookieless pings will be sent to Google Analytics for basic measurement and modeling purposes.

If a user denies consent, tags no longer store cookies but instead send signals to the Google Server as described in the next section. This prevents the loss of all information about visitors who deny consent and it enables Google Analytics 4 properties to model conversions as described in About modeled conversions.

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.

This means that if cookie expiration is set to one week (604800 seconds), and a user visits using the same browser within five days, the cookie will be available for an additional week, and they will appear as the same visitor in your reports. If that same user instead visited after the original cookie had expired, a new cookie will be created, and their first and second visits will appear as coming from distinct visitors in your reports.

What we call the "super sidebar" will contain all the elements that pertain to moving around GitLab

There will no longer be a top bar

Dialog that is reasonably funny

layout

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.

This is insightful application of Postel's law en.wikipedia.org/wiki/Robustness_principle. It remains wrong to write software that assumes local parts of email addresses are case-insensitive, but yes, given that there is plenty of wrong software out there, it is also less than robust to require case sensitivity if you are the one accepting the mail.

If you're already using PostgreSQL anyway, just use citext as the type of the email_address column.

Solution: Store emails with case sensitivity Send emails with case sensitivity Perform internal searches with case insensitivity

Robustness principle suggests that we accept case sensitive emails

I'd phrase it stronger: "you're unsafe to treat email-addresses as case-sensitive manner"

So yes, the part before the "@" could be case-sensitive, since it is entirely under the control of the host system. In practice though, no widely used mail systems distinguish different addresses based on case.

In short, you are safe to treat email addresses as case-insensitive.

responded with typical self-effacing matter-of-factness

"Of course, there isn’t any 'God of the Internet.' The Internet works because a lot of people cooperate to do things together."

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".

Rose therefore recommended "explicit consistency checks in a protocol ... even if they impose implementation overhead".

However, some do differentiate between upper and lower case characters in the recipient part.

If you are storing email addresses then you probably should store them in their original case (the recipient at least) to be safe. However, always compare them case-insensitively in order to avoid duplicates.

Please can we (a) retain case information from the email address the student uses to set up their account (in case their mailbox is case sensitive), and use that when sending password reset emails, etc., but also (b) when checking credentials for login or setting up an account, treat the email address as non-case-sensitive. The upshot would be if someone registered with Student@City.ac.uk, all emails would go to Student@City.ac.uk, but the student would be able to log in with student@city.ac.uk, and if someone later tried to set up an account with student@city.ac.uk they'd be told that the user already exists.

Although there's an argument for keeping case sensitivity for the local mailbox (as they can be case sensitive, depending on how they're set up, though I haven't come across case sensitivity in university emails), the domain part of the email address is not case sensitive and should not be treated as such. Please can we (a) retain case information from the email address the student uses to set up their account (in case their mailbox is case sensitive), and use that when sending password reset emails, etc., but also (b) when checking credentials for login or setting up an account, treat the email address as non-case-sensitive. The upshot would be if someone registered with Student@City.ac.uk, all emails would go to Student@City.ac.uk, but the student would be able to log in with student@city.ac.uk, and if someone later tried to set up an account with student@city.ac.uk they'd be told that the user already exists.

However, it's difficult to rely on a case-sensitive email address in the real world because many systems (typically ones that have to handle data merging) don't preserve case. Notably systems that use email addresses for user IDs, or any system that has to collate data from multiple sources (CRMs, email broadcast systems, etc) will either normalise case or treat them case-insensitively.

However, for all practical purposes in the modern age, I believe you can consider email addresses to be case insensitive.

a SHOULD is always trumped in RFCs by a MUST. The fact that hosts SHOULD do something means that they might not and I just wanted reassurance that, in reality, the SHOULD is a bit more widely adopted than its definition implies.

Not many email services or ISPs enforce case-sensitive email addresses.

Since the case sensitivity of email addresses can create confusion and delivery problems, most email providers and clients either fix the case if the email address is entered in the wrong case, or they ignore upper-case entries. Not many email services or ISPs enforce case-sensitive email addresses.

the above mentioned RFC 5321 recommends for new email addresses to be created with lower case letters only to avoid potential confusion and delivery problems.

While email addresses are only partially case-sensitive, it is generally safe to think of them as case insensitive. All major providers, such as Gmail, Yahoo Mail, Hotmail, and others, treat the local parts of email addresses as case insensitive.

According to RFC 5321, the local part of the email address is case sensitive. This means that, in theory, SoMething@something.com is not the same as something@something.com. However, email providers have the liberty to treat the local parts as both case sensitive and case insensitive.

Are Email Addresses Case Sensitive? Technically, the answer is yes. However, email addresses are typically not case sensitive; if you type your email address into a form and accidentally capitalize one or two letters, it probably won’t prevent the sender from emailing you.

The local part does, in fact, take the case into account, as per RFC 5321. However, Email Service Providers (ESPs) are aware of the potential confusion that could result from allowing upper-case letters.

In short, while it’s technically possible to make the part before @ case sensitive, most popular email servers do not allow that. 

Most big email providers like Gmail, Outlook and even company email address hosted on Google Suite are not case sensitive. Just to avoid any unnecessary confusion. However, in extreme cases, some large companies, implement case sensitivity on their server as some people can often have the same first and last name. But in general, this creates more confusion, than the usability, which is why most standard email providers avoid case sensitivity. 

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.

Either way, at some point almost everyone started treating addresses as case-insensitive.

When an IETF RFC uses the keyword “MUST” it means business

Despite it being commonplace to “fix up” email addresses by lowercasing them — or, in financial/government contexts, uppercasing them — email addresses are clearly defined as case-sensitive in the only standard that matters.

Since using case insensitivity is so widespread, take their sign up email address and make it lower case. Whenever they try to log in, convert that to lowercase as well, for comparison purposes, when you go to see if the user exists. As far as sign up and sign in go, do a case insensitive comparison. If the person signs up as Steve@example.com, you'll still want to allow them to sign in later with steve@example.com or sTeVE@example.com.

But you should also keep track of the email address that they signed up with in a case sensitive fashion. Any time you send an email to them, be sure to send it with that original casing. This allows the email server to handle it however it feels like it needs to. So even though the person may always be signing in to your site with steve@example.com, if they signed up as Steve@example.com, you'll always send email to Steve@example.com, just to be safe.

Some day, the de facto standard and the official standard will hopefully be the same. It's too bad we have to deal with this issue at all.

The de facto standard is to treat local mailboxes as case insensitive, but the official standard says case matters (though even the official standard mentions the de facto standard).

Gmail does something similar. You can register an email address with a . in it and Gmail just ignores that for its internal email address. So you can get Firstname.Surname@gmail.com and that's effectively the same email address as FirstnameSurname@gmail.com. Back in 2004 when Gmail launched, I found this to be an especially user friendly feature of their email service

This ensures that GetResponse and our customers comply with Anti-Spam laws.

An example of how to toggle tracking on a per-message basis. Note the o:tracking option. This will disable link rewriting for this message:

You can diminish the size of the journal by means of these commands: sudo journalctl --vacuum-size=100M This will retain the most recent 100M of data. sudo journalctl --vacuum-time=10d will delete everything but the last 10 days.

ISO 8601 specifies the use of uppercase letter T to separate the date and time. PostgreSQL accepts that format on input, but on output it uses a space rather than T, as shown above. This is for readability and for consistency with RFC 3339 as well as some other database systems.

Stop to think about "normal app" as like desktop app. Android isn't a desktop platform, there is no such this. A "normal" mobile app let the system control the lifecycle, not the dev. The system expect that, the users expect that. All you need to do is change your mindset and learn how to build on it. Don't try to clone a desktop app on mobile. Everything is completely different including UI/UX.

lso, really look closely into SignalR, as the Android and iOS clients aren't... uhm... great

Entropy is not a property of the string you got, but of the strings you could have obtained instead. In other words, it qualifies the process by which the string was generated.

The credentials should only be used when there is a high degree of trust between the resource owner and the client (e.g., the client is part of the device operating system or a highly privileged application)

Have you seen mobile phone lock screens where the user is required to draw a specific pattern onto a grid of dots? How about the Windows 8 picture password feature? These are examples of behavior-based authentication factors.

“Multi-factor authentication needs multi-factor enrollment,” noted Taku. It shouldn’t have been possible to enroll just using a stolen password. He listed numerous possibilities, among them credentials handed out in person, a one-time password, or a PIN sent to the employee’s registered email or mobile.

I'd like to discuss over a PR.

The 409 (Conflict) or 415 (Unsupported Media Type) status codes are suggested

If the target resource does not have a current representation and the PUT successfully creates one, then the origin server MUST inform the user agent by sending a 201 (Created) response. If the target resource does have a current representation and that representation is successfully modified in accordance with the state of the enclosed representation, then the origin server MUST send either a 200 (OK) or a 204 (No Content) response to indicate successful completion of the request.

Whereas U2F only supports multi-factor mode, having been designed to strengthen existing username/password-based login flows, FIDO2 adds support for single-factor mode.

why not allow block forwarding without capturing: foo(&) foo(1, 2, &)

In particular, with AC connected, a battery with a charge level higher than the stop charge threshold will not be discharged to the stop charge threshold, nor will there be a (cyclic) discharge down to the start charge threshold

Limiting the maximum charge level to below 100%: stop charge threshold

There are three migration paths:

You can indeed prolong moderns Li-Ion batteries lifespan by keeping them at a lower charge. If you never ever use it disconnected, you should keep it at 40%. E.g. Uber driver cellphone always-on in travels. However for daily light usage, 60% is considered the 'sweet spot' for practicality, and 80% gives you more freedom. 100% is when the battery is at its peak 'stress' level, and thus wear faster.

Exposing the battery to high temperature and dwelling in a full state-of-charge for an extended time can be more stressful than cycling.

Discharges your battery until it reaches 80%, even when plugged in

This tool makes it possible to keep a chronically plugged in Apple Silicon Macbook at 80% battery, since that will prolong the longevity of the battery.

If you send links with a secret login token with email, then they should be single-use and expire rather quickly.

But you can not make the user send a POST requests from an email

Sorry, I can't agree with you. If someone issues a second code, they should have two potential logins - one for each one they requested. Call me weird, but considering how cheap it is to store data, I'd rather keep around exactly what happened.

If you implement this system using the user table you risk impatient users requesting a second code and them arriving out of order.

By default SMTP offers very little protection against interception. Traffic may be encrypted between servers but there are no guarantees.

email as a transmission mechanism isn't secure.

If the link can only be used once with a short expiry time and no info in the link can be used to derive secrets in the session it creates then you should be fine. Effectively, the link serves as an one-time password.

If so, then how is sending a link for password reset any more secure? Isn't logging-in using a magic link the same thing as sending a magic link for resetting a password?

À la carte can be now used figuratively to describe someone who picks some things out of a larger set, e.g., an à la carte Catholic who (conveniently) believes in some aspects of the religion, but not others. À la carte television refers to customers paying for just channels they want, rather they having to pay for a whole (cable) service.

Google allowed third parties to build their own Wave services (be it private or commercial) because it wanted the Wave protocol to replace the e-mail protocol.[2][16][17] Initially, Google was the only Wave service provider, but it was hoped that other service providers would launch their own Wave services, possibly designing their own unique web-based clients as is common with many email service providers.

You can do an Nth root by raising to a fractional power. For example, the 4th root of 625 is 5. (BigDecimal(625)**(1.0/4.0)).to_f # => 5.0

A given secret from an authenticator SHALL be used successfully only once.

For look-up secrets that have less than 64 bits of entropy, the verifier SHALL implement a rate-limiting mechanism that effectively limits the number of failed authentication attempts that can be made on the subscriber’s account as described in Section 5.2.2.

Similar to Base64, but modified to avoid both non-alphanumeric characters (+ and /) and letters that might look ambiguous when printed (0 – zero, I – capital i, O – capital o and l – lower-case L).

A variant of Base58 encoding which further sheds the lowercase 'i' and 'o' characters in order to minimise the risk of fraud and human-error.

a change in a weight of evidence of 1 deciban (i.e., a change in the odds from evens to about 5:4) is about as finely as humans can reasonably be expected to quantify their degree of belief in a hypothesis

average level of "information", "surprise", or "uncertainty"

the entropy of a random variable is the average level of "information", "surprise", or "uncertainty" inherent to the variable's possible outcomes

But in reality, what we witness is the emergent patterns from each individual starling simply doing it darndest not to collide with the starlings nearby.

Cloche Seven pieces of 10-foot ½-inch PVC pipe One piece of 10-foot roll galvanized plumbers' metal stripping to attach PVC to sideboards every 2 feet. 28 1-inch roofing nails