- Mar 2024
-
www.infoworld.com www.infoworld.com
-
Software is a brutal industry and appearing to be unintelligent can harm your career badly
-
- Dec 2023
-
alangalangkumitir.wordpress.com alangalangkumitir.wordpress.com
-
Kang dén ilo, lawan kang ngilo puniku, anapon wayangngan anané kang ngilo pasthi, iya iku tannana prabédanira.
-
- Jun 2022
-
www.reddit.com www.reddit.com
-
The addressing system that many digital note taking systems offer is reminiscent of Luhmann's paper system where it served a particular use. Many might ask themselves if they really need this functionality in digital contexts where text search and other affordances can be more directly useful.
Frequently missed by many, perhaps because they're befuddled by the complex branching numbering system which gets more publicity, Luhmann's paper-based system had a highly useful and simple subject heading index (see: https://niklas-luhmann-archiv.de/bestand/zettelkasten/zettel/ZK_2_SW1_001_V, for example) which can be replicated using either #tags or [[wikilinks]] within tools like Obsidian. Of course having an index doesn't preclude the incredible usefulness of directly linking one idea to potentially multiple others in some branching tree-like or network structure.
Note that one highly valuable feature of Luhmann's paper version was that the totality of cards were linked to a minimum of at least one other card by the default that they were placed into the file itself. Those putting notes into Obsidian often place them into their system as singlet, un-linked notes as a default, and this can lead to problems down the road. However this can be mitigated by utilizing topical or subject headings on individual cards which allows for searching on a heading and then cross-linking individual ideas as appropriate.
As an example, because two cards may be tagged with "archaeology" doesn't necessarily mean they're closely related as ideas. This tends to decrease in likelihood if one is an archaeologist and a large proportion of cards might contain that tag, but will simultaneously create more value over time as generic tags increase in number but the specific ideas cross link in small numbers. Similarly as one delves more deeply into archaeology, one will also come up with more granular and useful sub-tags (like Zooarcheology, Paleobotany, Archeopedology, Forensic Archeology, Archeoastronomy, Geoarcheology, etc.) as their knowledge in sub areas increases.
Concretely, one might expect that the subject heading "sociology" would be nearly useless to Luhmann as that was the overarching topic of both of his zettelkästen (I & II), whereas "Autonomie" was much more specific and useful for cross linking a smaller handful of potentially related ideas in the future.
Looking beyond Luhmann can be highly helpful in designing and using one's own system. I'd recommend taking a look at John Locke's work on indexing (1685) (https://publicdomainreview.org/collection/john-lockes-method-for-common-place-books-1685 is an interesting source, though you're obviously applying it to (digital) cards and not a notebook) or Ross Ashby's hybrid notebook/index card system which is also available online (http://www.rossashby.info/journal/index.html) as an example.
Another helpful tip some are sure to appreciate in systems that have an auto-complete function is simply starting to write a wikilink with various related subject heading words that may appear within your system. You'll then be presented with potential options of things to link to serendipitously that you may not have otherwise considered. Within a digital zettelkasten, the popularly used DYAC (Damn You Auto Complete) may turn into Bless You Auto Complete.
-
- Jan 2022
-
github.com github.com
-
because it is in a central location and contributed to by many people, problems are found quickly, and fixes are for everyone—not just one specific template.
-
- Nov 2021
-
diggingthedigital.com diggingthedigital.com
-
https://diggingthedigital.com/abonneren-op-aantekeningen/
I like the idea here of being able to watch over someone's shoulder quietly to see what they're working on and how they're doing it. There's some interesting anthropology hiding here.
Have to say I'm a bit flattered that it's me that's being watched...
-
- Oct 2021
-
human.libretexts.org human.libretexts.org
-
I see a man's pink tongue razing the horizon
metaphor
Tags
Annotators
URL
-
- Dec 2020
-
github.com github.com
-
I don't think this is what really matters at the end, since whatever is the implementation the goal should be to provide a library that people actually like to use.
-
- Nov 2020
-
github.com github.com
-
This one gets the SEO, so I hope you're successful @raythurnevoid.
I assume this gets search traffic because people hope/assume that since there's a React "material-ui" that there might already be a "svelte-material-ui" port/adaptation available. So they search for exactly that (like I did). That and being the first to create that something (with that name).
Tags
- getting/attaining wide reach/audience/popularity due to being first to market
- having a name containing a search term that people are looking for
- web search for something brings me here
- being the thing that people are looking for and hoping/assuming already exists
- excellent name
- port (adaptation/translation)
- getting/attaining wide reach/audience/popularity due to being or having a name containing a search term that people are looking for
Annotators
URL
-
- Oct 2020
-
humanwhocodes.com humanwhocodes.com
-
For years, I’ve shared with friends and clients what I call the bunny theory of code. The theory is that code multiplies when you’re not looking, not unlike bunnies that tend to multiply when you’re not looking.
-
-
-
About the argument against it, "{@const will make code less consistent ": I think the same is true now, since people can come up with very different ways of dealing with the "computed value inside each loop/if function" problem. Some extract components, some use functions, some will prepare the array differently beforehand.
-
it also allows for more divergence in how people write there code and where they put their logic, making different svelte codebases potentially even more different due to fewer constraints. This last point is actually something I really value, I read a lot of Svelte code by a lot of different people and broadly speaking things look the same and are in the same places.
Tags
- different way of solving/implementing something
- idiomatic pattern (in library/framework)
- good point
- uniformity
- consistency
- convention
- Svelte: @const
- software development: code organization: where does this code belong?
- programming: multiple ways to do the same thing
- idiomatic code style (programming languages)
- strong conventions resulting in code from different code bases/developers looking very similar
Annotators
URL
-
- Jun 2020
-
twitter.com twitter.com
-
Nivi Mani on Twitter. "I cannot stop smiling! Here is a first peek at the data from our online browser-based intermodal preferential looking set-up! We replicate the prediction effect (boy eats big cake, Mani & Huettig, 2012) using our online webcam testing software @julien__mayor @Kindskoepfe_Lab" / Twitter. (n.d.). Twitter. Retrieved June 15, 2020, from https://twitter.com/nivedita_mani/status/1265556217486815232
-
- May 2020
-
nypost.com nypost.com
-
The administration and its allies fear that the more people gravitate toward the successful, free-market self-insurance approach, the worse their government-engineered health “reform” will look. We’re already seeing the beginning of this trend.
-
- Apr 2020
-
github.com github.com
-
It's amazing what new can do for clarity. This is exactly what I meant, but couldn't figure out how to phrase at the time.
-
- Jun 2015
-
caseyboyle.net caseyboyle.net
-
glancing, glimpsing, scanning, surveying, and other forms of casual or disinterested looking, staring
I like the diversity of ways of looking laid out for us here.
-