Similarly, if you use register / sign in you avoid confusion, but you also fit common usage.

Google: Sign Out, Sign In, "Create an account"

If you use "register/log in", there is no chance of confusion, and you lighten the cognitive load.

I would be very careful with the "common usage" argument. For example: the use of sign up and sign in has a very pleasant symmetry which doubtless appeals to many people. Unfortunately, this symmetry reduces the difference by which the user recognizes the button she needs to just two letters. It's very easy to click sign up when you meant sign in.

"Log in" is a valid verb where "Login" is a valid noun. "Signin", however, isn't a valid noun. On the other hand, "Signup" and "Sign up" have the same relationship, and if you use "Log in", you'll probably use "Register" as opposed to "Sign up". Then there's also "Log on" and "Logon", and of course "Log off" or "Log out".

Not the third though - "Login" is a noun (if it is really a word at all): "What is your login?" The other two are verbs "to sign in", or "to log in".

In the case of email, it can be argued that the widespread use of the unhyphenated spelling has made this compound noun an exception to the rule. It might also be said that closed (unhyphenated) spelling is simply the direction English is evolving, but good luck arguing that “tshirt” is a good way to write “t-shirt.”

Your file structure might look something like this:

Vite's job is to get your source modules into a form that can run in the browser as fast as possible. To that end, we recommend separating static analysis checks from Vite's transform pipeline.

Vite uses esbuild to transpile TypeScript into JavaScript which is about 20~30x faster than vanilla tsc, and HMR updates can reflect in the browser in under 50ms.

Above: the time to do a production bundle

One important thing to remember is that in regular strings the \ character needs to be escaped while in the regex literal (usually) the / character needs to be escaped. So /\w+\//i becomes new RegExp("\\w+/", "i")

Your design should strongly depend from your purpose.

Ask yourself what is the main purpose of storing this data? Do you intend to actually send mail to the person at the address? Track demographics, populations? Be able to ask callers for their correct address as part of some basic authentication/verification? All of the above? None of the above? Depending on your actual need, you will determine either a) it doesn't really matter, and you can go for a free-text approach, or b) structured/specific fields for all countries, or c) country specific architecture.

However, don't force users to supply postcode or region, they may not be used locally.

Locality can be unclear, particularly the distinction between map locality and postal-locality. The postal locality is the one deemed by a postal authority which may sometimes be a nearby large town. However, the postcode will usually resolve any problems or discrepancies there, to allow correct delivery even if the official post-locality is not used.

naming the settlement (city/town/village), which can be generically referred to as a locality

n general, a locality is a particular place or location. More specifically, a locality should be defined as a distinct population cluster. Localities are commonly recognized as cities, towns, and villages; but they may also include other areas such as fishing hamlets, mining camps, ranches, farms and market towns. Localities are often lower-level administrative areas and they may consist of sub-localities, which are segments of a single locality. Sub-localities should not be confused for being the lowest level administrative area of a country, nor should they be confused as being separate localities.

The regions in which a country is divided into. Each region typically has a defined boundary with an administration that performs some level of government functions. These areas are commonly expected to manage themselves with a certain level of autonomy. Various administrative levels exist that can range from “first-level” administrative to “fifth-level” administrative. The higher the level number is the lower its rank will be on the administrative level hierarchy. For example, the US is made up of states (first-level), which are divided into counties (second-level) that consist of municipalities (third-level). For comparison, the United Kingdom (GB) is comprised of the four countries England, Scotland, Wales and Northern Ireland (first-level). These countries are made up of counties, districts and shires (second-level), which in turn are made up of cities and towns (third-level) and small villages and parishes (fourth-level). Other common terms for an administrative area are administrative division, administrative region, administrative unit, administrative entity and subdivision.

In the United States of America, (US), we commonly use the terms city, state and zip code when referring to addresses. While that may mostly work for a country like Mexico (MX), it is not appropriate for other countries like Japan (JP) where the country is divided into prefectures instead of states. Not all countries call their sub-region divisions the same thing and many countries have several levels of sub-divisions. To further complicate the matter, not all sub-division levels are necessarily interchangeable from one country to another. For example, a first level sub-region in the US is a state, such as California (US-CA), but a first level sub-region for the United Kingdom of Great Britain and Northern Ireland (GB) is a country, such as England (GB-ENG).

Every country can have its own particular set of terms and definitions; to try to go over them all would be too complicated and inefficient. Instead, let’s go over some commonly used terms that are helpful when talking about international addresses.

Thank you for an eye-opening answer – I had no idea native speakers don't really make the distinction! As for using "town" about cities, I was thinking more of the fact that dictionaries explain the meaning of "city" in terms of "large town", which to me indicates that "town" would be a hypernym of "town" and "city" in much the same way as "dog" is a hypernym of "dog" and "bitch", but I guess I've drawn the wrong conclusion here.

Plugins are ways of adding new languages or formatting rules to Prettier. Prettier’s own implementations of all languages are expressed using the plugin API.

(Do not confuse this with the --schema option, which uses the word “schema” in a different meaning.)

Some developers have the intuition that the file extension could be used to determine the module type, as it is in many existing non-standard module systems. However, it's a deep web architectural principle that the suffix of the URL (which you might think of as the "file extension" outside of the web) does not lead to semantics of how the page is interpreted. In practice, on the web, there is a widespread mismatch between file extension and the HTTP Content Type header. All of this sums up to it being infeasible to depend on file extensions/suffixes included in the module specifier to be the basis for this checking.

I use dashes -, for the reasons you mention above. I avoid underscores because they require using the shift key, so take at least twice as long to type (also, I think they're ugly)

With so many characters that you might not think should be special, in fact being special, I just use the special characters anyway. This also puts me in the good habits of using bash completion, where it will auto-escape all the special characters in a filename. But it also puts me in the good habits of escaping/quoting EVERYTHING in scripts and multi-part 1-liners in bash. For example, in just a simple 1-liner: for file in *.txt; do something.sh "$file"; done That way, even if one of the files has a space, or some other character, the do part of the loop will still act on it, and not miss on 2 or more file-name-parts, possibly causing unintended side-effects. Since I cannot control the space/not-space naming of EVERY file I encounter, and if I tried, it would probably break some symlinks somewhere, causing yet more unintended consequences, I just expect that all filename/directoryname could have spaces in it, and just quote/escape all variables to compensate. So, then I just use whatever characters I want (often spaces) in filenames. I even use spaces in ZFS dataset names, which I have to admit has caused a fair amount of head-scratching among the developers that write the software for the NAS I use. Sum-up: Spaces are not an invalid character, so there's no reason not to use them.

Some applications and computer scripts may not recognize spaces or will process your files differently when using spaces. A best practice is to replace spaces in file names with  an underline (_) or hyphen (-).

I've noticed somethings, particularly ADB commands, use spaces to issue the next part of the command. Thus having a space would say that there's a new command. And since hyphens are actually used in some spelling, such as my last name, it's better to use underscores.

I didn't see this mentioned, but lots of software doesn't treat the underscore as a word separator (also called a "break character") these days. In other words, you can't jump to next word with Ctrl+Right-arrow or select individual words by double-clicking on them. The argument is that variable names in some programming languages like Python use snake_case, so highlighting them might require an extra Ctrl+Right-arrow. I do not necessarily like that decision, because, while being (marginally) useful in those limited domains, it makes file renaming and any other word manipulations or typesetting very cumbersome.

But one thing to remember is that if you are primarily doing python coding - and your code tree has files/directories with hyphen in them and you intend to use them as modules (do an import filename in your code), then this will cause errors as python modules cannot have hyphen in them.

Underscores are usually the convention that people use when replacing spaces, although hyphens are fine too I'd say. But since hyphens might show up in other ways such as hyphenated words, you'll have more success in preserving a name value by using underscores. For instance, if you have a file called "A picture taken in Winston-Salem, NC.jpg" and you want to convert the spaces to underscores, then you can preserve the hyphen in the name and retain its meaning.

"we [Google] don't really care about underscore versus dashes."

I must be the exception, because I use both spaces and underscores, depending on circumstances.   The practical/obsessive-compulsive side of me saves all my documents using spaces. They're cleaner to read than underscores, and they look far more professional.   The programmer side of me still uses underscores in files that will be accessible via the web or that need to be parsed in a program.   And to complicate matters worse, I use camel case to name all my programming files. So in actuality I use 3 standards interchangeably.   Both have their uses, I just choose one for clarity and one for ease of use.

Separating each of these entities with a hyphen allows you to double-click and highlight only that entity. With underscores-only, you need to enlist the painstaking process of precisely positioning your cursor at the beginning of the entity, then dragging your blue selector to the end of the entity.

Unfortunately, we don't have control over updates to Debian and Alpine distributions or the upstream postgres image. Because of this, there might be some issues that we cannot fix right away. On the positive side, the postgis/postgis images are regenerated every Monday. This process is to ensure they include the latest changes and improvements. As a result, these images are consistently kept up-to-date.

This is the Git repo of the Docker "Official Image" for postgres (not to be confused with any official postgres image provided by postgres upstream).

In simple words, the database client and the server prove and convince each other that they know the password without exchanging the password or the password hash. Yes, it is possible by doing a Salted Challenge and Responses, SCRAM-SHA-256, as specified by RFC 7677. This way of storing, communicating, and verifying passwords makes it very hard to break a password.

Treat object-name columns in the information_schema views as being of type name, not varchar (Tom Lane) § § § Per the SQL standard, object-name columns in the information_schema views are declared as being of domain type sql_identifier. In PostgreSQL, the underlying catalog columns are really of type name. This change makes sql_identifier be a domain over name, rather than varchar as before. This eliminates a semantic mismatch in comparison and sorting behavior, which can greatly improve the performance of queries on information_schema views that restrict an object-name column. Note however that inequality restrictions, for example

It's fairly trivial to write functionality in plpgsql that more than covers what timetravel did.

The extension depended on old types which are about to be removed. As the code additionally was pretty crufty and didn't provide much in the way of functionality, removing the extension seems to be the best way forward.

There has to be a better way for us to manage Javascript build/run scripts. Everything for this platform seems tacked together. quotes with escaped quotes and npm builds to call other 'npm run' builds.. This is getting pretty painful.

Goals

Non-goals

I have included code from others trusting that it would work, and that they would fix reported problems. And often that is true, there are quite a few faithful contributors. But sometimes someone just wants to get his feature in, and as soon as the things he uses are working, he disappears. And then I end up having to fix problems. These days I’m a lot more careful about including new features. Especially when it’s complex and interferes with several existing parts of the code. I’m insisting more often on writing tests and documentation before including anything.

A lot of it feels like someone who doesn’t like the old code and wants to do it “right.” I can agree that the old code is ugly. But it will take an awful lot of effort to make a new implementation. It’s a lot like what happened to Elvis: A rewrite was going to make it much better, but it took so long, during which Vim added more features, that eventually there are not so many Elvis users. And the rewritten Elvis may have nice code, but users don’t notice that.

Why not a library? We've found it extremely hard to develop a library that: Supports the many database libraries, ORMs, frameworks, runtimes, and deployment options available in the ecosystem. Provides enough flexibility for the majority of use cases. Does not add significant complexity to projects.

Lucia is now a learning resource on implementing auth from scratch.

Lucia, the authentication library that we are using, is deprecated (Q1/2025). However, the author of Lucia decided to make it a learning resource, because Lucia is just a thin wrapper around cryptographic libraries like Oslo. So we are following the migration path on their website and will also use Oslo instead of Lucia.

If I follow the new examples and implement them in my code (e.g. Passkeys), how will I know if a security issue is found in the examples in the future? Currently, libraries get updated and I pull in the new version. Unless I remember to check back occasionally, I'll never know if the example code is updated or fixed.

A search for .editorconfig files will stop if the root filepath is reached or an EditorConfig file with root=true is found.

EditorConfig helps maintain consistent coding styles for multiple developers working on the same project across various editors and IDEs.

Overrides let you have different configuration for certain file extensions, folders and specific files. Prettier borrows ESLint’s override format.

Prettier intentionally doesn’t support any kind of global configuration. This is to make sure that when a project is copied to another computer, Prettier’s behavior stays the same. Otherwise, Prettier wouldn’t be able to guarantee that everybody in a team gets the same consistent results.

They do provide one, via CSS tab-size (which sites and user styles can both set). also, GitHub will obey .editorconfig in a repo and display tabs at the resulting width (via that CSS), so nobody has had to use spaces on GitHub.com for many many years.

he Web, sadly, defaults to 8 spaces which is an abomination for every snippet of code that would ike to be instantly readable on Mobile Phones too browsers don't provide a tab size setting anywhere (last time I've checked) to override that horrifying 8 spaces legacy nobody wants or need since tabs were invented

because not enough code and content is written with tabs, nobody cares about these details while I am pretty sure that if tabs were the default, every tool would surely have a setting/preference for users consuming tabs based content

I was pretty anti-tabs for the longest time, until I heard the best argument for them, accessibility. Tabs exist for indentation customization, and this is exactly what is needed for people with impaired sight. IMO, this is a pretty good argument for moving towards tabs.

Auth shouldn't be a paid service!

The goal of Lucia v3 was to be the easiest and cleanest way to implement database-backed sessions in your projects. It didn't have to be a library. I just assumed that a library will be the answer. But I ultimately came to conclusion that my assumption was wrong. I don't see this change as me abandoning the project. In fact, I think it's a step forward. If implementing sessions wasn't easy, I wouldn't be deprecating the package. But why wouldn't a library be the answer? It seems like a such an obvious answer. One word - database. I talked about how database adapters were a significant complexity tax to the library. I think a lot of people interpreted that as maintenance burden on myself. That's not wrong, but the bigger issue is how the adapters limit the API. Adapters always felt like a black box to me as both an end user and a maintainer. It's very hard to design something clean around it and makes everything clunky and fragile, especially when you need to deal with TypeScript shenanigans.

the only part I agree with is that it could be annoying to change behaviour based on this variable, but any library worth its salt will use this to set sensible defaults and allow explicit overrides for all of the settings.

The biggest mistake I see is thinking of a Job to be Done as an activity or task. Examples include store and retrieve music or listen to music. These are not Jobs; rather, they are tasks and activities — which means they describe how you use a product or what you do with it.

Jobs to be done theory, also called jobs theory, posits that people don’t buy products; they “hire” them to do jobs, such as solving a problem or fulfilling a desire.

The Markdown syntax is not supported, but you can add bold styling with single asterisks, which is the standard Markdown syntax for italic. Very confusing!

I’m not a believer in languages designed by a committee and I have faith in Matz making reasonable decisions at the end of the day.

By the way, while .: doesn’t really get any awards for code elegance, it least it’s aligned with another existing pattern in Ruby. Victor Shepelev echoes my sentiment almost precisely here.

However, I also feel that Ruby sometimes seems too focused on being backwards compatible, to a point where it risk hurting the ecosystem. I think this thread is a good example, because it seems like such a small and benign change, yet it's taken several years and lots of back and forth, and in the end the proposed change wasn't even applied(!?).

Don't use the timestamp type to store timestamps, use timestamptz (also known as timestamp with time zone) instead.

temporal_tables extension if you are in a pinch and want to use that for row versioning in place of a lacking SQL 2011 support.

Don't use the type varchar(n) by default. Consider varchar (without the length limit) or text instead.

varchar(n) is a variable width text field that will throw an error if you try and insert a string longer than n characters (not bytes) into it.

Better expressivity. RDF* allows every LPG to be efficiently converted into an RDF model. On the other hand, LPGs cannot fully represent RDF* because of the rich expressivity of the latter.

The rich internal structure of LPGs results in more efficient storage and faster data traversals and queries.

however, due to the arbitrary data structure design, LPGs are not as practical for modelling ontologies and other structured data representations as RDF models.

LPG edges/connections can have types and attributes (properties as the name suggests) natively, making the LPG data structure more dense, compact, and informative compared to RDF.

There are two camps of Graph database, one side is RDF, where they are strict with their format, and somewhat limited for their extensibility. The other side is LPG, where they can define labels to the relationships.

Building a knowledge graph with a property graph database is straightforward compared to the alternatives. Unlike RDF, property graphs were designed as a database model (rather than data exchange format) for applications and analytics.

In a native property graph like Neo4j, the physical storage model is isomorphic to the logical model. What you draw is what you store.

SQL/PGQ reduces the difference in functionality between relational DBMSs and native graph DBMSs. Basically, this new feature makes it easier to query data in tables as if it were in a graph database, providing a possibly more intuitive alternative to writing complex join queries.

There is an ongoing debate about which graph data model is best, and in this blog post, we’ll explore why RDF (Resource Description Framework) stands out as the superior choice for building more sustainable and scalable knowledge graphs over LPG (Labeled Property Graphs).

Copyleft Richard Towers 2025. All wrongs reserved.

Temporal databases are in contrast to current databases (not to be confused with currently available databases), which store only facts which are believed to be true at the current time.

I've never written an IMDB review before but am provoked to do so by the current rating of 5.8,

79 View upvote and downvote totals. This answer is not useful Save this answer. Show activity on this post. Generally, there is no downside to using text in terms of performance/memory. On the contrary: text is the optimum. Other types have more or less relevant downsides. text is literally the "preferred" type among string types in the Postgres type system, which can affect function or operator type resolution.

Don't add a length modifier to varchar if you don't need it. (Most of the time, you don't.) Just use text for all character data. Make that varchar (standard SQL type) without length modifier if you need to stay compatible with RDBMS which don't have text as generic character string type.

I rant against 255 occasionally. Sure, there used to be some reasons for '255', but many are no longer valid, and even counter-productive.

Page not found This question was removed from Stack Overflow for reasons of moderation. Please refer to the help center for possible explanations why a question might be removed.

With its "no downstream hacks" and "upstream first" approach, it acts as a cutting-edge catalyst to push open-source technologies we love forward.

The problem with returning a generic error message for the user is a User Experience (UX) matter. A legitimate user might feel confused with the generic messages, thus making it hard for them to use the application, and might after several retries, leave the application because of its complexity. The decision to return a generic error message can be determined based on the criticality of the application and its data. For example, for critical applications, the team can decide that under the failure scenario, a user will always be redirected to the support page and a generic error message will be returned.

Using any of the authentication mechanisms (login, password reset, or password recovery), an application must respond with a generic error message regardless of whether: The user ID or password was incorrect. The account does not exist. The account is locked or disabled.

Incorrectly implemented error messages in the case of authentication functionality can be used for the purposes of user ID and password enumeration. An application should respond (both HTTP and HTML) in a generic manner.

Authentication (AuthN) is the process of verifying that an individual, entity, or website is who or what it claims to be by determining the validity of one or more authenticators (like passwords, fingerprints, or security tokens) that are used to back up this claim.

ChildOf

Once an authenticated session has been established, the session ID (or token) is temporarily equivalent to the strongest authentication method used by the application, such as username and password, passphrases, one-time passwords (OTP),

t.column :created_at, :timestamptz, null: false

Traditional, server-side web applications have traditionally used cookie-based authentication.

Token-based authentication

family_name string Surname(s) or last name(s) of the End-User. Note that in some cultures, people can have multiple family names or no family name; all can be present, with the names being separated by space characters.

given_name string Given name(s) or first name(s)

OIDC refresher: OpenID Connect is an identity protocol built on top of the OAuth 2.0 framework. If a request scope of OIDC is defined when initiating an OAuth flow, identity providers present the application an ID token along with an access token on a successful sign-in. The ID token is a JWT that contains some user information like name, email, and avatar, in the form of “claims”.

Clerk’s SSO uses the Open ID Connect protocol (OIDC), which provides an email_verified claim. Identity Providers are supposed to set this to true if they have verified the user’s email. Almost every SSO provider verifies emails, so if a user signs up with a social provider, a second email verification step is unnecessary.

The JWT carries the signup attempt information and is only valid for 10 minutes

It’s used during sign-in: as a workaround to forgotten password, or as an alternative to passwords altogether.

It’s used during sign-up: usually to prevent spam accounts, or as a requirement before enrolling a user on a mailing list.

Email verification is a foundational and reusable piece of modern authentication:

We could require email verification as soon as a user signs up, or perhaps when the user comes back for the second session. Shifting the onboarding friction from email verification to a later time can make the process much more natural for users. For example, a social media platform can minimize friction during the sign up process so that a user can immediately start to consume content. Later, when the user wants to post content, the platform can verify emails to minimize spam.

CSRF protection is a must when using cookies. A very simple way to prevent CSRF attacks is to check the Origin header for non-GET requests.

That’s a codebase first approach

You have your TypeScript Drizzle schema as a source of truth

You have your database schema as a source of truth