26 Matching Annotations
  1. Feb 2023
    1. “multiple storage”

      Within the history of personal knowledge management, one was often faced with where to store their notes so that it would be easy to find and use them again. Often this was done using slip methods by means of "multiple storage" by making multiple copies and filing them under various headings. This copying process was onerous and breaks the modern database principle "don't repeat yourself" (DRY).

      Alternate means of doing this include storing it in one place and then linking that location to multiple subject headings in an index, though this may cause issues of remembering which subject heading when there are many appropriate potential synonyms.

      Modern digital methods allow one to store a note in one location and refer to it in multiple ways electronically as well as with aliases.

  2. Jan 2023
    1. All that remained was the small matter of actually writing the chapter. I don’t do this in Obsidian: I think it would be asking for trouble to mix notes and their end-products in the same place.

      I've not seen this explicitly laid out as advice before though in most contexts people's note taking spaces have historically been divorced from their writing spaces for publication because slips and notes are usually kept physically separate from the working spaces or finished parts, but Richard Carter specifically separates the digital spaces in which he takes his notes and then uses them for creating end products. While he could both take notes in Obsidian, his tool of choice for notes, as well as write his finished pieces there, he actively changes contexts to use a different digital app to compose his notes into final pieces.

      What affordances does this context shift provide? <br /> - blank slate may encourage reworking and expansion of original notes - is there a blank slate effect and what would it entail? - potentially moves the piece into a longer format space or tool which provides additional writing, formatting or other affordances (which? there don't seem to be any in this case aside from a potential "distraction free mode" which may tend to force one to focus only on the piece at hand rather than the thousands of other pieces (notes) hiding within the app)

      What affordances does this remove?<br /> - He's forced to repeat himself (cut & paste / DRY violation)

      Is it easier or harder (from a time/effort perspective) to provide citations with such a workflow? Carter does indicate that for him:

      Having links to original sources in my outline makes the compilation of references for the chapter far easier than it used to be.

  3. Oct 2022
    1. Worried about paper cards being lost or destroyed .t3_y77414._2FCtq-QzlfuN-SwVMUZMM3 { --postTitle-VisitedLinkColor: #9b9b9b; --postTitleLink-VisitedLinkColor: #9b9b9b; --postBodyLink-VisitedLinkColor: #989898; } I am loving using paper index cards. I am, however, worried that something could happen to the cards and I could lose years of work. I did not have this work when my notes were all online. are there any apps that you are using to make a digital copy of the notes? Ideally, I would love to have a digital mirror, but I am not willing to do 2x the work.

      u/LBHO https://www.reddit.com/r/antinet/comments/y77414/worried_about_paper_cards_being_lost_or_destroyed/

      As a firm believer in the programming principle of DRY (Don't Repeat Yourself), I can appreciate the desire not to do the work twice.

      Note card loss and destruction is definitely a thing folks have worried about. The easiest thing may be to spend a minute or two every day and make quick photo back ups of your cards as you make them. Then if things are lost, you'll have a back up from which you can likely find OCR (optical character recognition) software to pull your notes from to recreate them if necessary. I've outlined some details I've used in the past. Incidentally, opening a photo in Google Docs will automatically do a pretty reasonable OCR on it.

      I know some have written about bringing old notes into their (new) zettelkasten practice, and the general advice here has been to only pull in new things as needed or as heavily interested to ease the cognitive load of thinking you need to do everything at once. If you did lose everything and had to restore from back up, I suspect this would probably be the best advice for proceeding as well.

      Historically many have worried about loss, but the only actual example of loss I've run across is that of Hans Blumenberg whose zettelkasten from the early 1940s was lost during the war, but he continued apace in another dating from 1947 accumulating over 30,000 cards at the rate of about 1.5 per day over 50 some odd years.

  4. 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.
    2. The fix is to unify how Git repository accesses the data.
    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.

  5. Aug 2022
  6. 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.
  7. Apr 2022
    1. Pedagogues considered marginal annotations as the first, optional step towardthe ultimate goal of forming a free-standing collection of excerpts from one’sreading. In practice, of course, readers could annotate their books without takingthe further step of copying excerpts into notebooks.

      Annotations or notes are definitely the first step towards having a collection of excerpts from one's reading. Where to put them can be a useful question though. Should they be in the margins for ease of creation or should they go into a notebook. Both of these methods may require later rewriting/revision or even moving into a more convenient permanent place. The idea "don't repeat yourself" (DRY) in programming can be useful to keep in mind, but the repetition of the ideas in writing and revision can help to quicken the memory as well as potentially surface additional ideas that hadn't occurred upon the notes' original capture.

  8. Mar 2022
    1. YAGNI (You Ain’t Gonna Need It) trumps DRY (Don’t Repeat Yourself)

      When people err on the side of advising for things to be overly DRY, I prefer to counter it by advocating for TRY (Try Repeating Yourself). Only after you've actually tried the copy-and-paste approach and have run into actual (vs imagined) issues should you refactor more for the DRY side.

      See also: "A little copying is better than a little dependency." * https://go-proverbs.github.io/ * https://www.youtube.com/watch?v=PAAkCSZUG1c&t=9m28s

  9. Nov 2021
    1. Once we learn how to create abstractions, it is tempting to get high on that ability, and pull abstractions out of thin air whenever we see repetitive code.

      DRY (Don't Repeat Yourself) < TRY (Try Repeating Yourself)

  10. Oct 2021
    1. One of the most known principles of software development is DRY - Don't Repeat Yourself - which is about avoiding code redundancy.
  11. Jun 2021
    1. Rather than write new tooling we decided to take advantage of tooling we had in place for our unit tests. Our unit tests already used FactoryBot, a test data generation library, for building up test datasets for a variety of test scenarios. Plus, we had already built up a nice suite of helpers that we coud re-use. By using tools and libraries already a part of the backend technology’s ecosystem we were able to spend less time building additional tooling. We had less code to maintain because of this and more time to work on solving our customer’s pain points.
  12. May 2021
    1. We certainly wouldn't want to add non-standard appendages to the fetch API, partly because it's confusing but mostly because it would be repetitious; you would need to include that logic in every load function that used the API in question.
  13. Feb 2021
  14. Jan 2021
    1. By abstracting the cleanup process in the cleanUp function, the three callbacks — timeout, success, and error listener — look exactly the same. The only difference is whether they resolve or reject the promise.
  15. Nov 2020
    1. Don't you hate to repeat yourself? For example, I hate working on anything related to user authentication or authorization that isn't directly related to the system I'm working on. I see it as necessary evil, an accidental complexity.
  16. Oct 2020
  17. Sep 2020
    1. We should also allow passing unrecognised props to the rendered component. eg: tabindex might be required on some instances of a component, and not all. Why should developers have to add tabindex support to their components just that it may potentially be used

      Glad to hear this is solved now: $restProps

    1. Thirdly, this provides no good way to control theming at an app level. Every time <Slider> is used, its style properties must be repeated. In most cases, that's probably not what we want.
    1. The dynamic routes are a great way to keep the routing.rb DRY and avoid unneeded dependencies between the routing and the controller files That is exactly the problem: I've already defined the (white)list of actions in the controller; I just want to make them all available via routes. I shouldn't have to repeat myself in the routes file.
  18. 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.
    1. In your environment you may want to always configure internationalization, routers, user data etc. If you have many different React roots it can be a pain to set up configuration nodes all over the place. By creating your own wrapper you can unify that configuration into one place.
  19. Feb 2020