25 Matching Annotations
  1. May 2022
    1. is the the um the writing by hand um because you know you can you can certainly write by hand and write down facts you know as well um 00:30:36 and uh and so yeah but i but what i what i do hold is that it's way way harder to uh store a lot of facts in 00:30:49 you know an analog settle costin because there's no copy paste you actually have to write out the facts by hand and as a result of that i think there are more benefits over digital in that you 00:31:02 are writing down uh neuro imprinting you know facts onto your mind that you can later recall more rapidly and stuff and um i think that's a benefit

      Keeping a manual zettelkasten using pen/pencil and paper may be beneficial to some as it will tend to remove the easy functionality of cut and paste in the digital space and force the user to think a bit more deeply about what they're working on and expand on it. Those with paper zettelkasten aren't as likely to spend time collecting simple facts as a result of this. This will make the content going into the system much more solid and reusable in the future.

  2. Jan 2022
  3. Nov 2021
  4. 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
  5. Mar 2021
  6. Feb 2021
    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. You can optionally compose the steps manually (great for reuse) and just make use of the Runner#call method.
    2. What does this mean for our runner? They get simpler and allow for quick reuse! Let's see.
  7. Nov 2020
  8. Oct 2020
    1. Reusability: you can take advantage of many already built validations and you can easily promote your custom validations to reusable ones.
    2. You may want to reuse a list of curated third party validators without having to take the time to learn the signature of each validator.
  9. Sep 2020
    1. I've committed to using Svelte, so I want to see it become highly adopted and not die or lose steam. For that, I believe we need to build up the ecosystem. Shared components, actions, transitions, etc. which make it easier for ourselves and others to build apps. I feel this will help Svelte continue to grow and will make it a better tool for our jobs. I see actions as one of the needed pieces to make this happen.
    2. Actions aren't necessary, otherwise they would have been implemented from the start. But they do allow for easier code-reuse and better shared libraries without exploding/complicating the ecosystem.
    3. I think hooks will be beneficial to the Svelte ecosystem, making sharing code for Svelte apps that solve common problems easier.
    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. This would be a component that is meant to be styled by its parents, and it would make no logical sense to have every possible type of style available inside the Link component. If I wanted to turn one of these anchor tags into a button, another into a nav-link, and another into a footer link, I should be able to. There's no reason that there shouldn't be a feature to treat a component like a normal HTML element.
  10. Jul 2020
    1. The key to successfully creating reusable components using both render props and scoped slots is being able to correctly separate behavior from presentation. Each time you create a new UI component, think “What is the core behavior of this component? Can I use this anywhere else?”