432 Matching Annotations
  1. Last 7 days
    1. Monaco is what VScode, and CodeSandBox, use for code editing. It's obviously one of the best code editors in the world. It's always been on my want-to-try-list and this is the perfect proejct.
    1. A Svelte component that monitors an element enters or leaves the viewport/parent element. Performant and efficient thanks to using Intersection Observer under the hood. Can be used in multiple projects including lazy loading images, infinite scrolling, playing/pausing the video when in the viewport, tracking user behaviour firing link pre-fetching and animations and many many more.
    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.
  2. Jan 2021
  3. Dec 2020
    1. Treating the web as a compile target has a lot of implications, many negative. For example “view source” is a beloved feature of the web that’s an important part of its history and especially useful for learning, but Svelte’s compiled output is much harder to follow than its source. Source maps, which Svelte uses to map its web language outputs back to its source language, have limitations.
    1. For example, an event handler callback that can be used to handle both fullscreenchange and fullscreenerror might look like this:
  4. Nov 2020
    1. // DO NOT INLINE this variable. For backward compatibility, foundations take a Partial<MDCFooAdapter>. // To ensure we don't accidentally omit any methods, we need a separate, strongly typed adapter variable.

      I wish I understood what they meant and why this is necessary

    1. Refactoring at scale is challenging and a significant investment, so communicating the progress is important both from a business perspective but also as a motivational effect to developers. In this case we used a combination of complexity trend visualizations and Code Health Metric as shown in the preceding example.

      [[refactoring at scale]]

    1. they're in the svelte compiler: https://github.com/sveltejs/svelte/blob/master/src/compiler/compile/nodes/Element.ts#L668 (search for the warning text)
    1. When you’re implementing a bad plan yourself, instead of having a mentor bail you out by fixing it, a few really useful things happen:You learn many more details about why it was a bad idea. If someone else tells you your plan is bad, they’ll probably list the top two or three reasons. By actually following through, you’ll also get to learn reasons 4–1,217.You spend about 100x more time thinking about how you’ll avoid ever making that type of mistake again, i.e., digesting what you’ve learned and integrating it into your overall decision-making.By watching my mistakes and successes play out well or badly over the course of months, I was able to build much more detailed, precise models about what does and doesn’t matter for long-term codebase health. Eventually, that let me make architectural decisions with much more conviction.

      There's a benefit to embarking on a challenge without a more experienced authority to bail you out.

      • You learn many more details about why it's a bad idea.
      • The lessons you learn in terms of how to avoid the mistakes you made stick with you longer

      (I would add that the experience is more visceral, it activates more modalities in your brain, and you remember it much more clearly.)

      These types of experiences result in what the author calls more "detailed, precise models". For me they result in a sort of intuition.

  5. Oct 2020
    1. export const validationSchema = {
        field: {
          account: [Validators.required.validator, iban.validator, ibanBlackList],
          name: [Validators.required.validator],
          integerAmount: [

      Able to update this schema on the fly, with:

        React.useEffect(() => {
          getDisabledCountryIBANCollection().then(countries => {
            const newValidationSchema = {
              field: {
                account: [
                    validator: countryBlackList,
                    customArgs: {
        }, []);
    1. This simplifies maintenance and keeps things clean by allowing related code to be grouped before inclusion elsewhere.
    1. withindex.js, we have a single source of truth, giving fine grained control on what we expose to the outside world.
    2. import statements will become much smaller, as we will be importing stuff from less files. For example AbstractNode.js has only on import statement now, where it had two before.
    3. The reason that this solves our problem is: we now have full control over the module loading order. Whatever the import order in internal.js is, will be our module loading order.
    4. Here are few, real-life commits of refactorings that make use of this solution:
    5. The crux of this pattern is to introduce an index.js and internal.js file.
    1. Yeah I see what you're saying. In my case, I had a group of classes that relied on each other but they were all part of one conceptual "module" so I made a new file that imports and exposes all of them. In that new file I put the imports in the right order and made sure no code accesses the classes except through the new interface.
    1. In some cases, I could also create a component without any <script> tag at all. So in that way, I could actually bulk up the logic in one place if I could get some help from the #with block.
    1. Separately, I wondered about having a central registry of warnings, since they're a bit scattered around at the moment. That way, we could check that someone wasn't trying to ignore a non-existent warning.


    1. The false promise of your source code repository is that everything it contains is “good.” To complete your task, just find something that does something similar, copy, modify, and you’re done. Looking inside the same repository seems like a safety mechanism for quality but, in fact, there is no such guarantee.
    2. What makes it good or bad is the quality of the code being multiplied.
    3. 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.
    4. Anyone who’s ever worked with me knows that I place a very high value on what ends up checked-in to a source code repository.
    1. nzaka's theory of bunny code is relevant here
    2. Yes, you can embed loops in it and compose lots of small repeated JSX snippets, but that almost never happens in practice because mixing the turing complete of javascript with the markup of HTML eliminates the readability of JSX so that it is actually harder to parse than a solution like hyperscript (the syntactical approach taken by virtual-dom).
    1. code is read much more often than it is written.
    2. However, know when to be inconsistent -- sometimes style guide recommendations just aren't applicable.
    3. The limits are chosen to avoid wrapping in editors with the window width set to 80, even if the tool places a marker glyph in the final column when wrapping lines.
    4. For code maintained exclusively or primarily by a team that can reach agreement on this issue, it is okay to increase the line length limit up to 99 characters
    1. I'm also persuaded by the arguments that it will be easier to track stuff down by co-location.
    2. 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.
    3. I also think this would be great in terms of colocation. If I need some intermediate result I no longer have to jump between script and markup.
    4. I'm persuaded that co-locating just this one type of logic will be useful.
    5. I like this, mostly because it allows me to write small components without creating another separate sub-component for holding the value simple computation. I get annoyed every time I need to create a component just to hold a variable, or even move the computation away from the relevant location. It reminds me of the days where variables in C had to be declared at the top of the function.
    6. 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.
    1. When I say that my experience is that it means it's time to split up your components, I guess I mean that there tends to be a logical grouping between all the things that care about (for example) sqr_n, and in Svelte, logical groupings are expressed as components.
    1. Both of these make it difficult to code-split the top of the tree (where the state has to live) from the leaves of the tree (where the state is used).
    1. Clicking through to the photo, there is no mention of this image appearing on this important announcement. Perhaps the author privately contact the photographer about using his image. Since Ken Doctor is so incredible with his media experience (i’m being serious), I’m fairly certain someone from his team would have contacted the photographer to give him a heads up.

      I'm sure I've said it before, but I maintain that if the source of the article and the target both supported the Webmention spec, then when a piece used an image (or really any other type of media, including text) with a link, then the original source (any website, or Flickr in this case) would get a notification and could show—if they chose—the use of that media so that others in the future could see how popular (or not) these types of media are.

      Has anyone in the IndieWeb community got examples of this type of attribution showing on media on their own websites? Perhaps Jeremy Keith or Kevin Marks who are photographers and long time Flickr users?

      Incidentally I've also mentioned using this notification method in the past as a means of decentralizing the journal publishing industry as part of a peer-review, citation, and preprint server set up. It also could be used as part of a citation workflow in the sense of Maria Popova and Tina Roth Eisenberg's Curator's Code<sup>[1]</sup>set up, which could also benefit greatly now with Webmention support.

  6. Sep 2020
    1. These lenses include interpretive frameworks such as structuralism and formalism, and deconstruction; identity- related approaches such as feminism and critical race studies; globally oriented approaches such as postco-lonialism; and many more.

      les code studies s'inscrivent d’emblée dans une pluralité d’approches – pour Marino, elles ne sont pas exhaustives – d’où leur pertinence dans des analyses intersectionnelles – elles informent les autres disciplines comme elles se nourrissent d’elles

    2. o read code critically is to explore the significance of the specific symbolic structures of the code and their effects over time if and when they are executed

      la dimension performative (code exécuté) est fondamentale dans l’étude du code, qu’on ne peut simplement étudier de manière statique: il faut le lancer, le jouer, l’exécuter.

    3. that “state” is the other key dimension to critical code studies


      state ou «état», une facette propre aux code studies

      dans un ouvrage traditionnel, cette question de l’état ne se pose pas (on lit plus ou moins linéairement un texte de bout en bout)

    4. we assert a hierarchy based on an arbitrary judgment of what is “real” or “good” or “right” code

      Comme on l'a déjà fait par le passé (et même encore aujourd'hui) en littérature, finalement. C'est peut-être aussi par là que les critical code studies rejoignent les études littéraires. En laissant de côté une évaluation subjective de la qualité du code, on peut s'intéresser plus spécifiquement à son sens, à son imbrication dans un contexte, à son statut dans un espace culturel, etc.

    5. Code was literally becoming the means of debate, used as evidence in arguments for and against the scientific valid-ity of climate change.

      Intéressant parallèle à faire entre ce traitement du code et celui des publications scientifiques en médecine... Le manque d'informations dont dispose le public pour comprendre et contextualiser les études scientifiques de beaucoup de domaines peut ici se comparer à celui qui est fait de ce code, brandi comme argument mais fallacieux parce que mal interprété, mal contextualisé, etc.

    6. Code thus becomes the means and medium of long- distance control.

      Voir notamment Alexander Galloway, <cite>[Protocol: How Power Exists After Decentralization](https://mitpress.mit.edu/books/protocol)</cite>, 2004.

      Réflexion à l’aulne des systèmes de contrôle par le langage (cf. Michel Foucault, Gilles Deleuze, Félix Guattari).

      Facilité par le protocole, <mark>l’Internet est le média de masse le plus hautement contrôlé connu jusqu’ici.</mark>

      En condensé: cette note.

    7. Critical Code Studies Working Groups (CCSWGs)
    8. Code is a social text, the meaning of which develops and transforms as additional readers encoun-ter it over time and as contexts change

      Le code est une langue et, en tant que telle, est une construction sociale (comme toutes les langues). Comme une œuvre littéraire, son sens n'est pas fixé.

    1. setContext / getContext can only be used once at component init, so how do you share your API result through context? Related: how would you share those API results if the call was made outside of a Svelte component, where setContext would be even more out of the question (and the API call would arguably be better located, for separation of concerns matters)? Well, put a store in your context.
    1. I took the same approach with _layout.svelte and not just for the svelte-apollo client. Except I put all of that setup into another module (setup.js) and imported from _layout. I just couldn't stomach having all that code actually in my _layout file. It's for layout, supposedly, but it's the only component that is a parent to the whole app.
    2. I got this working by using _layout.svelte as the point to initialise and set the Client we can then use getClient in each route that uses this layout.
    1. Svelte will not offer a generic way to support style customizing via contextual class overrides (as we'd do it in plain HTML). Instead we'll invent something new that is entirely different. If a child component is provided and does not anticipate some contextual usage scenario (style wise) you'd need to copy it or hack around that via :global hacks.
    2. Explicit interfaces are preferable, even if it places greater demand on library authors to design both their components and their style interfaces with these things in mind.
    3. Want to use this now? Existing projects A more robust and maintainable way to incorporate this patch into your workflow using patch-package:
    1. You'll have to create a new component that brings in the functionality of both. TooltipButton, TooltipLink, Link, and TooltipRoutedLink. We're starting to get a lot of components to handle a bit of added functionality.
    2. For the tooltip example, if you had a whole bunch of tooltips on different elements, it would be annoying to have different event listeners and "should it be shown" variables for each one.
    1. Perhaps at that point we're better off settling on a way to pass components through as parameters? <!-- App.html --> <Outer contents={Inner}/> <!-- Outer.html --> <div> <div>Something</div> <[contents] foo='bar'/> </div>
    2. I would hope for it to come with React-like behavior where I could pass in a string (like div or a) and have it show up as a normal div/a element when the child component used it.
    1. To me, abandoning all these live upgrades to have only k8s is like someone is asking me to just get rid of all error and exceptions handling and reboot the computer each time a small thing goes wrong.

      the Function-as-a-Service offering often have multiple fine-grained updateable code modules (functions) running within the same vm, which comes pretty close to the Erlang model.

      then add service mesh, which in some cases can do automatic retry at the network layer, and you start to recoup some of the supervisor tree advantages a little more.

      really fun article though, talking about the digital matter that is code & how we handle it. great reminder that there's much to explore. and some really great works we could be looking to.

    1. Références1°'degré:art.1°',2et3del'arrêtédu13mai1985relatifauconseild'école,circulairen°2000-082du9juin2000relativeauxmodalitésd'électiondesreprésentantsdesparentsd'élèvesauconseild'école.2"°'degré:art.R.421-26,R.421-29etR.421-30ducodedel'éducation.
    2. L'articleL.1'|'I-4ducodedel'éducationdisposequelesparentsd'élèvesparticipent,parleursreprésentants,auxconseilsd'écoleetauxconseilsd'administrationdesétablissementsscolairesetauxconseilsdeclasse
    1. There’s a bunch of fiddly syntax here, not to mention 2 separate build stacks and 3 sets of dependencies, but the end result is awesome. Simply renaming a field on a shared model will reveal all the React components using that value on the front-end, and back-end code using it.
    2. The “shared” schema is effectively the API schema. These are the fields exchanged in the API, common to client and server.
    1. À cette fin, comme le prévoit l'article D. 111-8 du Code de l'éducation, les directeurs d'école et les chefs d'établissement doivent communiquer aux associations de parents d'élèves qui en font la demande la liste des parents d'élèves de l'école ou de l'établissement scolaire mentionnant leurs noms, adresses postale et électronique, à la condition que ceux-ci aient donné leur accord exprès à cette communication.
    1. there is one major weakness to this approach and to scoped CSS: organization gets very hard – you end up with styles everywhere!