that of a centenarian who had died of arteriosclerosis

I don’t need to refetch all my server data just to refetch the user object, especially when it’s already right there in the response of my PUT request!

There is growing support across tooling for a shared .ignore file as well. Precedence should likely be .prettierignore > .ignore > .gitignore.

It is more clean to have all those ignore files in package.json rather than: .gitignore .eslintignore .stylelintignore .prettierignore .whateverignore ...

You have your database schema as a source of truth

With Vitest you get to define the configuration for your dev, build and test environments as a single pipeline, sharing the same plugins and the same vite.config.js.

target_utility

Well, here’s a non-recursive solution in which the main commands appear only once:

Duplicating non-trivial code in both the if and in the else could create unnecessary issues.

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.

You can see how the constant jumping between these two tools in the first scenario is super annoying, and also very risky as none of the changes you make in Figma are also automatically being updated in the same GitLab designs.

Personally I think we could get a ton more benefits and would also be able to pull new users into our platform by finding better ways to integrate/link/connect/display Figma in our work item objects. Today the biggest downside for "Design management" is that it's basically just a copy of what's happening inside of Figma that has to be manually kept in sync and requires users to constantly switch back and forth:

巢狀結構，可以建立多層筆記本分類（雖然這樣做不一定比較好）一則筆記可以放入多個筆記本！

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.

If a passage is interesting from several different points of view, then it should be copied out several times on different slips.

Unfortunately, Wiki depends a lot on HEAD ref for its functionality, such as versions management, file collision check, etc. That causes multiple quirky behaviors. The normal project repositories don't fall into such behaviors because GitLab (Gitaly actually) has a complicated heuristic to determine the current default branch, while Wiki repository does not.

This clearly violates DRY, which is the reason why OP asked this question in the first place

It appears redundant, and my goal of using $ref is to avoid repeating definitions.

OAS 3.1 uses all of JSON Schema draft 2020-12 including unevaluatedProperties. You won't find direct references to unevealuatedProperties in the OAS spec because it links to the JSON Schema spec instead of duplicating it's contents.

This does work, but as can be seen in the PR, it raised serious concerns over the maintainability of the resulting schema due to all of the duplication.

Each slip ought to be furnished with precise refer-ences to the source from which its contents havebeen derived ; consequently, if a document has beenanalysed upon fifty different slips, the same refer-ences must be repeated fifty times. Hence a slightincrease in the amount of writing to be done. Itis certainly on account of this trivial complicationthat some obstinately cling to the inferior notebooksystem.

taurusnoises · 11 hr. ago · edited 11 hr. agoObsidianMy guess is that, like every one else, Luhmann had an array of both conscious and subconscious influences. That said, the great bulk of Luhmann's system can be found in the book I mentioned above. Right down to the diagrams and illustrations of the cards."If the Zettelkasten, used in many ways, gradually becomes a constantly growing reservoir of foreign and personal ideas, then its careful user will, often enough, and with deep focus into certain special areas from this occupation, have independent scientific achievement. At least he will be sufficiently familiar with individual questions in one of his subjects and will be able to look forward to the moment when he is about to complete a specifically formulated written examination paper within a given period of time without the oppressive feeling of insecurity." (1931, Heyde, pardon the rough trans.)Sound familiar?Also, who are the intellectual historians you're referring to here?

Reducing nested structures is tiresome. Have you tried immer?

The goal of this project is to have a single gem that contains all the helper methods needed to resize and process images. Currently, existing attachment gems (like Paperclip, CarrierWave, Refile, Dragonfly, ActiveStorage, and others) implement their own custom image helper methods. But why? That's not very DRY, is it? Let's be honest. Image processing is a dark, mysterious art. So we want to combine every great idea from all of these separate gems into a single awesome library that is constantly updated with best-practice thinking about how to resize and process images.

It is sublimely annoying to have to configure the exact same parameters in config/environments, spec/spec_helper.rb and again here... all in marginally different ways (with 'http://' or without, with port number or port specified separately). Even Capybara.configure syntax can't seem to stay consistent to itself between versions...

Overriding the ActiveStorage controllers to add authentication or customize behavior is a bit tedious because it requires either: using custom routes, which means losing the nice url helpers provided by active storage copy pasting the routes in the application routes.rb, which is not very DRY.

With first-class keyword arguments in the language, we don’t have to write the boilerplate code to extract hash options. Unnecessary boilerplate code increases the opportunity for typos and bugs.

Here's another convenient use of try_files, as unconditional redirects to named locations. The named locations are effectively acting as subroutines, saving duplication of code.

The goal of this gem is to reduce the amount of code that needs to be written when developing a ruby on rails website.

and if I think this is too boilerplatey, I can export a handler from some .js file and pass the error to that: <script> import { onError } from 'svelte' import { genericHandler } from '../my-error-handler.js' onError(genericHandler(e => { // code which is called first to try to handle this locally return true // we've handled it here, don't do anything else. }) </script>

It is also why it's implementation in firefox is completely useless, considering that windows/osx/most linux distros plan to add support for DoH/DoT/DNScrypt resolvers in the near future, so firefox doing it itself will provide no additional benefit.

Use this to load modules whose location is specified in the paths section of tsconfig.json when using webpack. This package provides the functionality of the tsconfig-paths package but as a webpack plug-in. Using this plugin means that you should no longer need to add alias entries in your webpack.config.js which correspond to the paths entries in your tsconfig.json. This plugin creates those alias entries for you, so you don't have to!

The declarations you make in the tsconfig.json are re-stated in the webpack.config.js. Who wants to maintain two sets of code where one would do? Not me.

When I look at the tsconfig.json and the webpack.config.js something occurs to me: I don't like to repeat myself. As well as that, I don't like to repeat myself. It's so... Repetitive.

This is annoying repetition, but at least it doesn't introduce an extraneous object at runtime.

The best way to do this is to derive the type Format from a value like an array which contains all of the Format literals.

That should work as expected and not be too verbose (or at least it doesn't repeat string literals anywhere)

My question is specifically if there is a way to do user defined type guards using the type itself

if x.strip('%').isnumeric(): return float(x.strip('%'))/100

Which gets the job done, but that's a chunk of boilerplate for a simple accessor

One of the consequences (although arguably not the primary motivation) of DRY is that you tend to end up with chunks of complex code expressed once, with simpler code referencing it throughout the codebase. I can't speak for anyone else, but I consider it a win if I can reduce repetition and tuck it away in some framework or initialisation code. Having a single accessor definition for a commonly used accessor makes me happy - and the new Object class code can be tested to hell and back. The upshot is more beautiful, readable code.

I like auto-property generation... who needs boilerplate code?

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.

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.

Perhaps the most impressive part of the entire email is the fallback it used for non-WebKit emails —a beautiful grid layout of the carousel that didn’t hide or duplicate any content!

I find it convenient to change proxy and other settings through gui window by right-clicking on launcher icon on my desktop. I mostly start slack by clicking desktop launcher, but also want to be able to start it from command line in some cases.

Or even a simple 1-liner in the Contract that references an AR Model so you don't have to rewrite the validations again in that contract, or have to choose between writing the validations once either in the contract there or in the AR Model?

Look no further than C++, where nearly every major software suite has its own strings, vectors, etc. implemented, frequently duplicating functionality already implemented in (1) STL, and (2) Boost. I seem to recall that the original Android Browser, for example, had no fewer than 5 kinds of strings on the C++ side of the code base, because it interfaced with several different systems and each had its own notion of what a string should be.

This is a copy of the "AMD" document in the repo, kept here to maintain historical links. If this document differs from the one in the repo, the repo version is the correct one.

it is inconvenient to write specific implementations for each datatype contained, especially if the code for each datatype is virtually identical. For example, in C++, this duplication of code can be circumvented by defining a class template

Supporting languages may use monads to abstract away boilerplate code needed by the program logic.

They help streamlining the control flow, and take away control code while providing you with an incredibly cool developer experience.

The idea of the script is this: most of the important logic runs in a subshell which is piped through tee and to a logfile, so I don't have to tee every single line of the main logic to get it all logged.

Why is all this interaction code better? Two reasons: One, you can reuse the FindAccount interaction in other places, like your API controller or a Resque task. And two, if you want to change how accounts are found, you only have to change one place.

You must modify the code surrounding each of those 1,000 calls to compensate for the change.

While this example could work, we're already duplicating code and things could easily get out of sync with the previous Signup runner.

Saving form data across sessions — what do people hate more than filling out a form? Filling out a form twice!

When Sapper renders a page on the server, it will attempt to serialize the resolved value (using devalue) and include it on the page, so that the client doesn't also need to call preload upon initialization.

If the client JS is disabled, then handleSubmit will never be executed and you have to care that your /api/fakeBackendRoute will handle the data exactly how the client would.

This scenario demonstrates one drawback of CSS: With all the style rules that need to be applied to multiple elements on multiple pages, things can get pretty redundant. And redundancy can eat up your time and cause friction whenever you need to change a color, font, or any other style aspect across your site.

Custom properties allow a value to be stored in one place, then referenced in multiple other places.

Trapping focus correctly for a modal dialog requires a complex set of events and interaction patterns that we feel is best not duplicated within the logic of this component.

We don't have clear visibility on which issues the VSCode team is planning on fixing & we would like to avoid duplicating work.

Code after:

Please don't copy answers to multiple questions; this is the same as your answer to a similar question

Instead of calling prepare twice to get value from data.

Once again, this isn’t good or bad, it’s just the most efficient way to create something that is similar to something else

Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.

hyperscript is more concise because it's just a function call and doesn't require a closing tag. Using it will greatly simplify your tooling chain.

Other frameworks, which use a template syntax built atop HTML — Svelte, Vue, Ractive, Glimmer etc — have historically been fragmented, meaning those tools need to be reinvented many times.

Every new variation to the view requires updating both the view model and the template. This holds true even for simple variations.

Note how we have to duplicate the code between these two lifecycle methods in class. This is because in many cases we want to perform the same side effect regardless of whether the component just mounted, or if it has been updated. Conceptually, we want it to happen after every render — but React class components don’t have a method like this. We could extract a separate method but we would still have to call it in two places.

many CDNs nowadays ultimately source from npm (before caching the JavaScript on their own edge servers). So you'll be guaranteed to have the same library version on the CDN as on npm

This leads to web developers at every company needing to rebuild every control from scratch. This represents millions of dollars of investment for each company to duplicate work that many other companies are also doing.

Modern view libraries like React allow teams to build and maintain these components more easily than ever before, but it is still extraordinarily difficult to do so in a fully accessible way with interactions that work across many types of devices.

Part of the functionality that is returned are event handlers. I'd like to avoid needing to manually copy the events over one by one so the hook implementation details are hidden.

The alternative is to duplicate markup inline:

First class TypeScript support means that both of these two systems do a good job of handling TypeScript code.

This is easily solved by extracting components, either as template partials/JavaScript components, or using Tailwind's @apply feature to create abstractions around common utility patterns.

Do not include the same information in multiple places. Link to a SSOT instead.

Having a knowledge base in any form that is separate from the documentation would be against the docs-first methodology because the content would overlap with the documentation.

New information that would be useful toward the future usage or troubleshooting of GitLab should not be written directly in a forum or other messaging system, but added to a docs MR and then referenced, as described above.

When you encounter new information not available in GitLab’s documentation (for example, when working on a support case or testing a feature), your first step should be to create a merge request (MR) to add this information to the docs. You can then share the MR in order to communicate this information.

If the answer to a question exists in documentation, share the link to the docs instead of rephrasing the information.

There is a temptation to summarize the information on another page. This will cause the information to live in two places. Instead, link to the SSOT and explain why it is important to consume the information

At GitLab, we have so many product changes in our monthly releases that we can’t afford to continuously update multiple types of information. If we have multiple types, the information will become outdated.

RDFa is intended to solve the problem of marking up machine-readable data in HTML documents. RDFa provides a set of HTML attributes to augment visual data with machine-readable hints. Using RDFa, authors may turn their existing human-visible text and links into machine-readable data without repeating content.

Duplicated data is a common practice when working with non-relational databases as Firebase. It saves us from performing extra queries to get data making data retrieval faster and easier

There are no plans to deprecate the REST API. To reduce the technical burden of supporting two APIs in parallel, they should share implementations as much as possible.

Despite our best efforts to deal with all of those issues, over the course of time we fall behind. When you look at an issue it's sometimes unclear whether or not we intent to provide the functionality you propose, whether or not we fix the bug, whether or not the issue is a duplicate of another one. In order to restore a reasonable level of clarity we annually perform a House Keeping Iteration in which we go through all open issues. We categorize, label, fix, and close issues. This results in a wave of notification which is hard to deal with (our apologies) but in the end there is better understanding of what will happen to your ideas.

This also ties in the "Single Source Of Truth", where even if I craft descriptive commit messages I will probably have to describe what I did in the MR comments anyways, so that feels like duplicate work.

Here are the purposes included in each category:

One thing is certain when it comes to navigation trends, users and designers seem to be fed up with completely hidden styles and demand options that work in similar formats on desktops and mobile devices. This might be one of the reasons a vertical pattern is trending.

Running the same code in the browser and on the server in order to avoid code duplication is a very different problem. It is simply a matter of good development practices to avoid code duplication. This however is not limited to isomorphic applications. A utility library such as Lodash is “universal”, but has nothing to do with isomorphism. Sharing code between environments does not give you an isomorphic application. What we’re referring to with Universal JavaScript is simply the fact that it is JavaScript code which is environment agnostic. It can run anywhere. In fact most JavaScript code will run fine on any JavaScript platform.

Also discussed in stackoverflow.com/questions/11003418/…

let page = document.getElementById('buttonDiv');

Technical cookies, preference, session and optimization cookies;Statistical cookies run by first-party solutions (eg. Matomo/Piwik or other solutions hosted/run by you);Statistical cookies by third parties (eg. Google Analytics), but only where the data is anonymized and is not used for profiling (even indirectly).

Why is the changelog on a separate page and not here? The WordPress.org repository is just another place to download this plugin. I don’t want to maintain too many pages with the same content.

Having duplicate code is not ideal. One version of the code may be more up-to-date than another version, creating something similar to a race condition around code versioning. If a bug is found, it would need to be fixed in every place that shares the code while hoping that the developer can remember them all. An inconsistent bug fixing process could multiply bugs and create havoc in a codebase.