784 Matching Annotations
  1. Feb 2021
    1. step :direct_debit

      I don't think we would/should really want to make this the "success" (Right) path and :credit_card be the "failure" (Left) track.

      Maybe it's okay to repurpose Left and Right for something other than failure/success ... but only if we can actually change the default semantic of those signals/outputs. Is that possible? Maybe there's a way to override or delete the default outputs?

    2. Patching has no implicit, magical side-effects and is strongly encouraged to customize flows for a specific case in a quick and consise way.
    3. While you could nest an activity into another manually, the Subprocess macro will come in handy.
    4. The macro automatically wires all of Validate’s ends to the known counter-part tracks.
    1. They do not maintain a to-do list (mentally or physically).
    2. If you ask my former students, they will tell you that as a teacher, my goal is to do nothing. I dream of the day when I can sit at my desk, feet propped up, reading a book, while the classroom bursts with activity and learning around me.
    1. While Trailblazer offers you abstraction layers for all aspects of Ruby On Rails, it does not missionize you. Wherever you want, you may fall back to the "Rails Way" with fat models, monolithic controllers, global helpers, etc. This is not a bad thing, but allows you to step-wise introduce Trailblazer's encapsulation in your app without having to rewrite it.
    1. ActiveModel provides a powerful framework for defining callbacks. ActiveInteraction hooks into that framework to allow hooking into various parts of an interaction's lifecycle.
    2. account.first_name = first_name if first_name.present? account.last_name = last_name if last_name.present?

      I guess this is needed so we don't reset to nil (erasing value in database) when they haven't even provided a new value as input.

      But surely there's a cleaner way...

    1. Personal todo lists don’t depend on others using the same system (no network effects)

      They don't unless you're building a wiki or commonplace book that can interact with those of others. (Roam research isn't doing this---yet, but they should.) Ideally small building block pieces will allow it to dovetail with other systems that could potentially do the same thing.

    1. {a: 1, b: 2, c: 3, d: 4} => {a:, b:, **rest} # a == 1, b == 2, rest == {:c=>3, :d=>4}

      equivalent in javascript:

      {a, b, ...rest} = {a: 1, b: 2, c: 3, d: 4}
      

      Not a bad replacement for that! I still find javascript's syntax a little more easily readable and natural, but given that we can't use the same syntax (probably because it would be incompatible with existing syntax rules that we can't break for compatibility reasons, unfortunately), this is a pretty good compromise/solution that they've come up with.

    1. In order to support easy reuse, revision, remixing, and redistribution, the entire Hypothesis Help knowledge base by Hypothesis is dedicated to the public domain via CC CC0 1.0. While we appreciate attribution and links back to Hypothesis from anywhere these works are published, they are not required.
    1. Examples of different ways of defining forms

      Wow, that's a lot of different ways.

      The inline_form way in particular seems interesting to me, though it's worth noting that that method is just an example, not actually part of this project's code, so it's not really a first-class option like the other options.

    1. I'd like to know specifically what you were aiming to achieve with this Gem as opposed to simply using https://github.com/apotonick/reform? I am happy to help contribute, but equally if there is a gem out there that already does the job well, I'd like to know why we shouldn't just use that.
    2. DSLs can be problematic for the user since the user has to manage state (e.g. am I supposed to call valid? first or update_attributes?). This is exactly why the #validate is the only method to change state in Reform.
    3. The reason Reform does updating attributes and validation in the same step is because I wanna reduce public methods. This is to save users from having to remember state.

      I see what he means, but what would you call this (tag)? "have to remember state"? maybe "have to remember" is close enough

      Or maybe order is important / do things in the right order is all we need to describe the problem/need.

    1. p. 217:

      We also keep a higher percentage of our assets in cash than most financial advisors would recommend --- something around 20% of the value of our assets outside the value of our house.

      Compare this to my current allotment.

    1. Yes, you do face difficult choices (moral) but you don't care about it. All you care are the reputation bars. So... Let's kill this guy, who cares if he is innocent, but this faction needs it or I'm dead. Sounds great on paper but to be honest... you just sit there and do whatever for these reputation bars. If you won't, then you lose
    1. that's a point, but I would say the opposite, when entering credit card data I would rathre prefer to be entirely in the Verified By Visa (Paypal) webpage (with the url easily visible in the address bar) rather that entring my credit card data in an iframe of someone's website.
  2. Jan 2021
    1. I want to write my own scripts first, but may end up graduating to this.

    1. overflow-wrap: break-word; makes sure the long string will wrap and not bust out of the container. You might as well use word-wrap as well because as the spec says, they are literally just alternate names for each other. Some browsers support one and not the other.
    1. Moving DOM elements around made me anxious and I wanted to preserve natural tab order without resorting to setting tabindex, so I also made a flexbox version that never moves DOM elements around. I think it's the superior solution, at least for the layouts I was going for. https://github.com/wickning1/svelte-components/blob/master/src/FlexCardLayout.svelte
    1. In other words, programs that send messages to other machines (or to other programs on the same machine) should conform completely to the specifications, but programs that receive messages should accept non-conformant input as long as the meaning is clear.
    2. be conservative in what you do, be liberal in what you accept from others
    1. Popper for Svelte with actions, no wrapper components or component bindings required! Other Popper libraries for Svelte (including the official @popperjs/svelte library) use a wrapper component that takes the required DOM elements as props. Not only does this require multiple bind:this, you also have to pollute your script tag with multiple DOM references. We can do better with Svelte actions!
    1. I'd like to spin up a couple of these, both for my personal box (localhost-only) and for the development network.

    1. O tucano Orlando Morando, de São Bernardo do Campo, diz que não há a menor chance de fazê-lo em um futuro próximo e que tem doado parte de seu salário correspondente a um aumento concedido na gestão anterior com o qual não concordou.

      Doou para quem???

  3. Dec 2020
    1. Add this to my toolchain (in particular, configure Lighthouse to run in our CI/CD pipeline).

    1. I guess it's about "preloading" and not "navigation", if it's the case, then I guess there is still no way to attach to navigation events, and this issue should be kept open.
    2. No JS event is fired, so there currently isn't any clean way to do this that I can see.
    1. it focuses on compiling non-standard language extensions: JSX, TypeScript, and Flow. Because of this smaller scope, Sucrase can get away with an architecture that is much more performant but less extensible
    1. You can afford to make a proper PR to upstream.
    2. No more waiting around for pull requests to be merged and published. No more forking repos just to fix that one tiny thing preventing your app from working.

      This could be both good and bad.

      potential downside: If people only fix things locally, then they may be less inclined/likely to actually/also submit a merge request, and therefore it may be less likely that this actually (ever) gets fixed upstream. Which is kind of ironic, considering the stated goal "No more waiting around for pull requests to be merged and published." But if this obviates the need to create a pull request (does it), then this could backfire / work against that goal.

      Requiring someone to fork a repo and push up a fix commit -- although a little extra work compared to just fixing locally -- is actually a good thing overall, for the community/ecosystem.

      Ah, good, I see they touched on some of these points in the sections:

      • Benefits of patching over forking
      • When to fork instead
    1. Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.

      tag?: what scope of provided features / recommended happy path is needed?

    2. It’s worth mentioning that Svelte limits its scope to being only a UI component framework. Like React, it provides the view layer, but it has more batteries included with its component-scoped CSS and extensible stores for state management. Others like Angular and Vue provide a more all-in-one solution with official routers, opinionated state management, CLIs, and more. Sapper is Svelte’s official app framework that adds routing, server-side rendering, code splitting, and some other essential app features, but it has no opinions about state management and beyond. Some devs prefer Svelte’s minimal approach that defers problems to userland, encouraging more innovation, choice, and fragmentation, and other devs prefer a more fully integrated toolkit with a well-supported happy path.

      tag?: what scope of provided features / recommended happy path is needed?

    3. It’s worth mentioning that Svelte limits its scope to being only a UI component framework. Like React, it provides the view layer, but it has more batteries included with its component-scoped CSS and extensible stores for state management.
    1. p. 198:

      Given any five points on a sphere, show that some four of them lie on a hemisphere that includes its boundary.

      I'll admit, I already looked at the hint for this problem, and yes, my initial approach did indeed consist of trying to find the 'worst' configuration.

      I can think of two ways to determine whether or not two points on a sphere lie within the same hemisphere:

      • First off, since any two points on a sphere may be connected by a great circle, they're in the same hemisphere if they're separated by no more than \(\frac{\tau}{2}\) radians along this shortest path.
      • Equivalently, the length of the line segment connecting them must be less than or equal to \(2r\), where \(r\) is the radius of the sphere.

      One other note:

      • It's always possible to divide the sphere in half in such a way that any two points lie within the same hemisphere. (This is a corollary of the first point, above. Note that two antipodal points must necessarily fall on the boundary of such a division.)

      So, I have a picture in my mind of the sphere divided into eight regions of equal area by way of three great circles which intersect one another at right angles. (Think the Equator, the Prime Meridian, and a third great circle drawn through the poles at 90 degrees longitude.) My thinking now tends more toward combinatorics and the pigeonhole principle than geometry proper.

  4. Nov 2020
    1. I'd love to take this for a spin. Maybe I could rewrite Demeter or micdrop using it.

    1. i like working on application frameworks, compilers, interpreters, and emulators.
    1. but know I know what I don't want to do. I definitely know I want to be an Engineer now, and it makes it more clear that I should start my own business.
    1. I encounter this problem in all of my Svelte projects- feels like I'm missing something. Fighting it with absolute positioning usually forces me to re-write a lot of CSS multiple times. Is there is a better way to solve this that I've overlooked?
    1. Converting Angular components into Svelte is largely a mechanical process. For the most part, each Angular template feature has a direct corollary in Svelte. Some things are simpler and some are more complex but overall it's pretty easy to do.
    1. We expect a certain pattern when validate devtool name, pay attention and dont mix up the sequence of devtool string. The pattern is: [inline-|hidden-|eval-][nosources-][cheap-[module-]]source-map.
    1. Some of the verbs implemented by systemctl are designed to provide a high-level overview in a human readable format. All that information is available over dbus, and/or journalctl, systemctl show. We could provide that information in json format, but there's a second problem. Information and format of information printed by e.g. systemctl status is not stable. Since the output is not suitable for programmatic consumption anyway, there's no need to provide it in a machine readable format.
    2. In principle, this information is already available through other means, but it is actually a fair amount of work to gather it in this form, and I think it could be useful to open it up to programmatic consumption.
    3. Although I agree that -o json should return proper JSON, believe the proper way for external tools like SaltStack etc. to talk to systemd is DBus. See also saltstack/salt#20392 - everything else is more or less just hack-ish and prone to break easily.
  5. Oct 2020
    1. I'll want to generate, upload, and store a certificate for publishing NuGet packages.

    1. Focus on your application: forget about forms details like I'm dirty, field touched...
    2. You may want to execute validations in a given specific order (this can be tricky especially when you have got asynchronous validations).
    3. You can try to build a solution to tackle these issues on your own, but it will cost you time and money... why not use a battle-tested solution to handle all this complexity?
    4. If you want to implement a form with a superb User Experience, you have to take care of many variables:
    5. Form validation can get complex (synchronous validations, asynchronous validations, record validations, field validations, internationalization, schemas definitions...). To cope with these challenges we will leverage this into Fonk and Fonk Final Form adaptor for a React Final Form seamless integration.
    6. Managing Form State (holding field information, check if a control has been touched, if the user has clicked the submit button, who owns the current focus...) can be tedious and prone to errors. We can get help from React Final Form to handle these challenges for us.
    1. In the software industry we use "dependency" to refer to the relationship between two objects. We say "looking for dependents" for relationships to dependent things and "looking for dependencies" for relationships to prerequisite things, so it gets that connotation, but the literal meaning is the relationship itself, not the object. Finding a better word is exactly the point of the question
    1. I highly recommend setting a higher bound on the number of returned entities by each resolve function in your code.
    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. Doing so also means adding empty import statements to guarantee correct order of evaluation of modules (in ES modules, evaluation order is determined statically by the order of import declarations, whereas in CommonJS – and environments that simulate CommonJS by shipping a module loader, i.e. Browserify and Webpack – evaluation order is determined at runtime by the order in which require statements are encountered).

      Here: dynamic loading (libraries/functions) meaning: at run time

    2. Specifically, since Root, Rule and AtRule all extend Container, it's essential that Container is evaluated (and therefore, in the context of a Rollup bundle, included) first. In order to do this, input.js (which is the 'gateway' to all the PostCSS stuff) must import root.js, root.js must import rule.js before it imports container.js, and rule.js must import at-rule.js before it imports container.js. Having those imports ensures that container.js doesn't then try to place Root, Rule or AtRule ahead of itself in the bundle.
    3. Replaced nested `require` statements with `import` declarations for the sake of a leaner bundle. This entails adding empty imports to three files to guarantee correct ordering – see https://github.com/styled-components/styled-components/pull/100
    1. Note that the <WarningEngine/> component must be at the bottom of the form to guarantee that all the fields have registered.
    1. formvalidation: path.resolve

      Why use resolve.alias to point to 'vendors/formvalidation/dist/es6'? Why not just use an npm package and have package.json name module: 'vendors/formvalidation/dist/es6'

      Then (I think) the examples below like

      import luhn from 'formvalidation/algorithms/luhn';
      

      would work the same but without that workaround.

    1. I'm okay with an overall design that allows people to plugin the parts they need in order to be able to generically support a compile-to-javascript language, but to bake in support for one singular solution because its popular is simply bad engineering.
    2. Of all the compile-to-languages, the one that strikes me as having the least merit is JSX. It's basically a ton of added complexity for the sake of what boils down to syntax. There are no real gains in terms of language semantics in JSX.
    3. Furthermore, JSX encourages bad non-dry code. Having seen a lot of JSX over the past few months, its encourages copypasta coding.
    1. An onevent event handler property serves as a placeholder of sorts, to which a single event handler can be assigned. In order to allow multiple handlers to be installed for the same event on a given object, you can call its addEventListener() method, which manages a list of handlers for the given event on the object.
    1. Cons aren't covered by pros.
    2. An alternative (maybe not good) would be to restrict {@const} to certain blocks like {#each} and {#if}. In both cases, it significantly reduces the "multiple ways to do the same thing" problem and avoids ergonomic and performance overhead of our current situation.
    3. 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. Hannah Stepanek annotated the hell out of this reference. I would do well to read what she had to say.

    1. I'm suggesting there should be a way to write lifecycle related code that also responds to changing props, like how useEffect works. I think how React handles this could be a good source of inspiration.
    2. I think it just needs a few changes, possibly non-breaking additions, to be as powerful as hooks, when it comes to abstracting lifecycle related logic, and making it easy to keep effects in sync with props.
    3. I'm not sure I understand the problem, everything you are describing is already possible.
    4. If Svelte came up with some kind of hooks like API maybe it could solve both these issues at once.
    1. A “solution” to GR is more like a model in logic: it may satisfy a theory’s axioms but have other properties that are contingent (unless the theory is categorical, meaning that all of its models are isomorphic).
    1. People constantly suggest that I should have just worked with a different library instead of writing another one.
    2. It was clear no one was interested in what I was working towards.
    3. Very few were interested in furthering the platform in the places they just took for granted.
    4. but everything they were doing started to make sense
    5. Do we need another JS UI Library?
    1. React does not attempt to provide a complete "application library". It is designed specifically for building user interfaces[3] and therefore does not include many of the tools some developers might consider necessary to build an application.
    1. The $: can also be used to trigger effects.
    2. We can run effects when some data changes using watchEffect - it takes a function that runs whenever a reactive value used inside changes.
    3. There's one downside to Reacts reactivity model - the hooks (useState and useEffect) have to always be called in the same order and you can't put them inside an if block.
    4. createState and createSignal are improvements over React's useState as it doesn't depend on the order of calls.
    5. MobX - for me personally MobX is a far better way to manage state than React Hooks. It doesn't care about the UI layer so it can be used outside the React ecosystem, and it's simple to mutate data.
    1. Confidence to express ignorance is a super power. One good way I hone this skill is by saying “Nothing to add” when I have nothing to add, instead of repeating what other people said.
    1. r self-r

      This paragraph discuses the use of the word "bullshit" as it is used in every day life. Decide whether this is arguement, structure or both.

    2. A Kind Word for Bullshit: The Problem of Academic Writin

      Add MLA citation

  6. leanprover.github.io leanprover.github.io
  7. Sep 2020
    1. It is showed as an error, but it is a warning as it doesn't break anything. I hate having warning/error in my console not coming from me. It is not justified as it's not bad practice imho
    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. let:hovering={active}

      It seems like it should be the other way around:

      let:active={hovering}
      

      to make it look like a regular let assignment.

      It's only when you consider what/how let:hovering on its own means/works that it makes a bit more sense that it is the way it is. When it's on its own, it's a little clearer that it's saying to "make use of" an available slot prop having the given name. (Very much like bind, where the LHS is also the name of the prop we're getting the data from.) Obviously we have to identify which prop we're wanting to use/pull data from, so that seems like the most essential/main/only thing the name could be referring to. (Of course, as a shortcut (in this shorthand version), and for consistency, it also names the local variable with the same name, but it wouldn't have to.)

      Another even simpler way to remember / look at it:

      1. Everything on the left hand of an prop/attribute [arg] corresponds to something in the component/element that you're passing the [arg] to. Usually it's a prop that you're passing in, but in this case (and in the case of bind:) it's more like a prop that you're pulling out of that component, and attaching to. Either way, the name on the LHS always corresponds to an export let inside that named component.
      2. Everything on the right side corresponds to a name/variable in the local scope. Usually it passes the value of that variable, but in the case of a let: or bind: it actually "passes the variable by reference" (not the value) and associates that local variable with the LHS (the "remote" side).

      Another example is bind: You're actually binding the RHS to the value of the exported prop named on the LHS, but when you read it (until you get used to it?) it can look like it's saying bind a variable named LHS to the prop on the RHS.

    1. The benefit of this approach is that rather than having these defaults and fighting against them, it’s fully up to you to decide how to handle everything.
    2. Rollup also does something very different compared to the other bundlers. It only tries to achieve one simple goal: Bundle ES modules together and optimise the bundle.
    3. Unfortunately, many third party libraries, even though they are written in ESM, are published to npm as CJS modules, so we still need to concatenate them.