97 Matching Annotations
  1. Oct 2022
    1. If a passage is interesting from several different points of view, then it should be copied out several times on different slips.

      I don't recall Langlois and Seignobos suggesting copying things several times over. Double check this point, particularly with respect to the transference to Luhmann.

  2. Sep 2022
    1. 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.
    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.
    1. 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.

      A zettelkasten may require more duplication of effort than a notebook based system in terms of copying.

      It's likely that the attempt to be lazy about copying was what encouraged Luhmann to use his particular system the way he did.

  3. Aug 2022
    1. 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?

      I'm the first intellectual historian in line on this one, but there are certainly others. :) I haven't seen anything from Schmidt on this niche sub-topic, but I would suspect those in his group are highly curious about these specifics.

      I've been reading portions of Heyde, but I'm not seeing anything new, innovative, or exciting in his suggestions that hadn't broadly existed in the prior literature for a century or more, though he does go into more depth on various areas than others before him. In fact, Heyde suggests making multiple copies of one's notes to file under a variety of commonplace subject headings, a practice which we specifically don't see Luhmann doing. The vast majority of the Zettelkasten space up until this time and even since is simply the commonplace book tradition using index cards instead of notebooks. Luhmann was doing several things subtly different than this prior tradition. Whether they are really important or not at scale really remains to be seen. It's reasonably obvious based on what I've seen thus far that he was following Heyde (and other precursors) in spirit, but definitely not in the "letter of the 'law'". There are very subtle pieces of Heyde which are uniquely and intriguingly suggestive of why Luhmann's practice was different than others, but the average reader is not likely to see them.

      My German is dreadful at best, so I'll refrain from commenting further on specifics until I've seen a better/full translation in English. I'm definitely curious to hear the thoughts of others who've translated/read it.

    1. While Heyde outlines using keywords/subject headings and dates on the bottom of cards with multiple copies using carbon paper, we're left with the question of where Luhmann pulled his particular non-topical ordering as well as his numbering scheme.

      While it's highly likely that Luhmann would have been familiar with the German practice of Aktenzeichen ("file numbers") and may have gotten some interesting ideas about organization from the closing sections of the "Die Kartei" section 1.2 of the book, which discusses library organization and the Dewey Decimal system, we're still left with the bigger question of organization.

      It's obvious that Luhmann didn't follow the heavy use of subject headings nor the advice about multiple copies of cards in various portions of an alphabetical index.

      While the Dewey Decimal System set up described is indicative of some of the numbering practices, it doesn't get us the entirety of his numbering system and practice.

      One need only take a look at the Inhalt (table of contents) of Heyde's book! The outline portion of the contents displays a very traditional branching tree structure of ideas. Further, the outline is very specifically and similarly numbered to that of Luhmann's zettelkasten. This structure and numbering system is highly suggestive of branching ideas where each branch builds on the ideas immediately above it or on the ideas at the next section above that level.

      Just as one can add an infinite number of books into the Dewey Decimal system in a way that similar ideas are relatively close together to provide serendipity for both search and idea development, one can continue adding ideas to this branching structure so they're near their colleagues.

      Thus it's highly possible that the confluence of descriptions with the book and the outline of the table of contents itself suggested a better method of note keeping to Luhmann. Doing this solves the issue of needing to create multiple copies of note cards as well as trying to find cards in various places throughout the overall collection, not to mention slimming down the collection immensely. Searching for and finding a place to put new cards ensures not only that one places one's ideas into a growing logical structure, but it also ensures that one doesn't duplicate information that may already exist within one's over-arching outline. From an indexing perspective, it also solves the problem of cross referencing information along the axes of the source author, source title, and a large variety of potential subject headings.

      And of course if we add even a soupcon of domain expertise in systems theory to the mix...

      While thinking about Aktenzeichen, keep in mind that it was used in German public administration since at least 1934, only a few years following Heyde's first edition, but would have been more heavily used by the late 1940's when Luhmann would have begun his law studies.


      When thinking about taking notes for creating output, one can follow one thought with another logically both within one's card index not only to write an actual paper, but the collection and development happens the same way one is filling in an invisible outline which builds itself over time.

      Linking different ideas to other ideas separate from one chain of thought also provides the ability to create multiple of these invisible, but organically growing outlines.

  4. Jul 2022
    1. 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.
    1. 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...
  5. Jun 2022
    1. 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.
  6. 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.
  7. Feb 2022
  8. Jan 2022
    1. 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>
  9. Sep 2021
    1. 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.
    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.
  10. Aug 2021
  11. Jun 2021
    1. Which gets the job done, but that's a chunk of boilerplate for a simple accessor
    2. 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.
    1. 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.
  12. 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!
  13. 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

    1. 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.
  14. Feb 2021
    1. 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
    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).
    1. While this example could work, we're already duplicating code and things could easily get out of sync with the previous Signup runner.
  15. 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.
  16. Nov 2020
    1. 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.
    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.
  17. Oct 2020
    1. Please don't copy answers to multiple questions; this is the same as your answer to a similar question

      Why on earth not? There's nothing wrong with reusing the same answer if it can work for multiple questions. That's called being efficient. It would be stupid to write a new answer from scratch when you already have one that can work very well and fits the question very well.

    1. Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.
    2. 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.

      I suppose this is also an argument that Python tries to make? That other languages have this con:

      • cons: closing tags make it more verbose / increase duplication and that Python is simpler / more concise because it uses indentation instead of closing delimiters like end or } ?
    1. 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.
    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.
  18. Sep 2020
    1. 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.
    2. 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.
    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.
    1. 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.
  19. 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.
  20. 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.
  21. Jun 2020
    1. 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
  22. 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.
    1. 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.
    1. 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.
  23. Apr 2020
    1. A miniature / iframe-friendly version of https://www.iubenda.com/en/user/tos/legal?ifr=false

      When you first sign up, it displays this in an iframe as https://www.iubenda.com/en/user/tos?ifr=true&height=680, with an "Accept and continue" button you must click to continue

    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.
    1. Also discussed in stackoverflow.com/questions/11003418/…

      Thank you for not just marking it as a duplicate simply because some similar but different question exists.

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

      duplication: As a result of duplication, they somehow ended with this line being present here but not in the downloadable file which is supposed to have the same contents as the snippet shown here.

      They should have updated their static page generation script/process so that their main document referenced options.js and their generator literally included the contents of the referenced file inline. Then there is no chance of the contents of the inline snippet and downloaded snippet diverging and not matching.

      Evidently, however, the contents of each are managed independently (in other words, there is duplication), easily leading to the contents diverging, as they did.

  24. Mar 2020
    1. 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).
    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.
  25. 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).

    1. 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.
  26. Nov 2019
    1. Wow, looks like a lot of duplication in https://github.com/constelation/monorepo/blob/master/packages/Style_/src/index.native.tsx compared to https://github.com/constelation/monorepo/blob/master/packages/Style_/src/index.tsx to handle differences in props on the different platforms such as backfaceVisibility.

      And even structure/shape differences like:

      const style = { ...styleFromProps, ...this.props.style, ...Child.props.style }


          propsToPass.style = [styleFromProps, this.props.style, Child.props.style]

      Is there no way to remove this duplication?