47 Matching Annotations
  1. Feb 2024
  2. Sep 2022
    1. This clearly violates DRY, which is the reason why OP asked this question in the first place
    2. It appears redundant, and my goal of using $ref is to avoid repeating definitions.
    1. 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.
  3. Jul 2022
  4. May 2022
    1. 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.
  5. Sep 2021
    1. 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!
    1. 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.
    2. 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.
  6. Aug 2021
  7. Jun 2021
    1. 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.

      new tag?:

      • extract reusable functions to reduce duplication / allow elegant patterns elsewhere
    1. 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.
  8. May 2021
    1. 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!
  9. Mar 2021
    1. 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.
    1. 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?
    2. how to have validations in model and some in contract/form object without duplicating

  10. Feb 2021
    1. 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.
    1. 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.

      Pretty weak arguments though...

      1. We could just as easily used a plain object or module to extract this for easy reuse and having it in only one place (avoiding duplication).
  11. Dec 2020
    1. 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.
  12. Nov 2020
    1. 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.
    1. 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.
  13. Oct 2020
    1. 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.
  14. Sep 2020
    1. 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.
  15. Aug 2020
    1. Do not include the same information in multiple places. Link to a SSOT instead.
    2. 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.
    3. 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.
    4. 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.
    5. If the answer to a question exists in documentation, share the link to the docs instead of rephrasing the information.
    6. 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
    7. 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.
  16. Jul 2020
    1. 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.
  17. May 2020
    1. 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.
  18. Apr 2020
    1. 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.
  19. Mar 2020
    1. 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.
  20. Dec 2019
    1. It's confusing whether one should put things in gemspec development_dependencies or in Gemfile or in both.

      Duplication is bad since the lists could get out of sync. And the gemspec's development_dependencies should be a complete list. Therefore, my opinion is that that should be the canonical list and therefore the only list.

      Actually, what good is gemspec's development_dependencies? A contributor should clone the repo, run bundle, and get the dev dependencies that way. Therefore development_dependencies is unneeded and you should only list them in Gemfile.

      It is simpler to just use Gemfile, since it is a more familiar format. You can copy and paste content into it. For example, if you extract a gem out of an app, you may wan to copy/move some gems from app's Gemfile into new gem's Gemfile. It also generates a Gemfile.lock (which you shouldn't add to git).