57 Matching Annotations
  1. Last 7 days
  2. Apr 2021
    1. I wish to define methods within the class they belong to. Using class << self demonstrates that approach clearly — we are defining methods within the actual singleton class scope.
    2. When we usedef self.method, though, we are defining a method across scopes: we are present in the regular class scope, but we use Ruby’s ability to define methods upon specific instances from anywhere; self within a class definition is the Class instance we are working on (i.e. the class itself). Therefore, usingdef self.method is a leap to another scope, and this feels wrong to me.
  3. Mar 2021
    1. Ironically, what we’re doing today, is essentially the opposite: rather than reducing the scope of the problem, we continue to grow it, effectively increasing the number of details — and problems — for everyone.
  4. Feb 2021
    1. Grouped inputs It can be convenient to apply the same options to a bunch of inputs. One common use case is making many inputs optional. Instead of setting default: nil on each one of them, you can use with_options to reduce duplication.

      This is just a general Ruby/Rails tip, nothing specific to active_interaction (except that it demonstrates that it may be useful sometimes, and gives a specific example of when you might use it).

      Still, in my opinion, this doesn't belong in the docs. Partly because I think repeating the default: nil for every item is an acceptable type of duplication, which would be better, clearer (because it's more explicit), simpler, keeps those details closer to the place where they are relevant (imagine if there were 50 fields within a with_options block).

      I also think think that it creates a very arbitrary logical "grouping" within your code, which may cause you to unintentionally override/trump / miss the chance to use a different, more logical/natural/important/useful logical grouping instead. For example, it might be more natural/important/useful to group the fields by the section/fieldset/model that they belong with, even if your only grouping is a comment:

      # User fields
      string :name
      integer :age
      date :birthday, default: nil
      
      # Food preferences
      array :pizza_toppings
      boolean :wants_cake, default: nil
      

      may be a more useful grouping/organization than:

      # Fields that are required
      string :name
      integer :age
      array :pizza_toppings
      
      # Fields that are optional
      with_options default: nil do
        date :birthday
        boolean :wants_cake
      end
      

      Or it might be better to list them strictly in the same order as they appear in your model that you are trying to match. Why? Because then you (or your code reviewer) can more easily compare the lists between the two places to make sure you haven't missed any fields from the model, and quickly be able to identify which ones are missing (hopefully intentionally missing).

      In other words, their "optionalness" seems to me like a pretty incidental property, not a key property worthy of allowing to dictate the organization/order/grouping of your code.

    1. The basic classification of a form object is a class that contains writable attributes, validations and logic to persist the attributes to ActiveRecord objects. These forms can also include other side-effects like background job triggers, emails, and push-notifications etc. The simplest way to understand the concept is to think of them as a representation of a controller action where all of the business logic that happens in that controller action is abstracted into a form object.

      This definition may be a bit too broad. Others (like Reform) define it to have smaller scope — only the part where it persists/validates attributes. The other side effects might be better to put in a different location, like the controller action, or a service/processor object that has a form object.

  5. Dec 2020
    1. This is the accepted way to handle problems related to authentication, because user data has a couple of important characteristics: You really don't want to accidentally leak it between two sessions on the same server, and generating the store on a per-request basis makes that very unlikely It's often used in lots of different places in your app, so a global store makes sense.
    2. But Svelte 3 doesn't have global stores that are passed around in quite the same way.
    3. Just realised this doesn't actually work. If store is just something exported by the app, there's no way to prevent leakage. Instead, it needs to be tied to rendering, which means we need to use the context API. Sapper needs to provide a top level component that sets the store as context for the rest of the app. You would therefore only be able to access it during initialisation, which means you couldn't do it inside a setTimeout and get someone else's session by accident:
    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.
  6. Nov 2020
  7. Oct 2020
    1. All containers without a --network specified, are attached to the default bridge network. This can be a risk, as unrelated stacks/services/containers are then able to communicate.
    1. In a browser, deep-diff defines a global variable DeepDiff. If there is a conflict in the global namespace you can restore the conflicting definition and assign deep-diff to another variable like this: var deep = DeepDiff.noConflict();.
    1. Polyfills are naughty as they patch native APIs, while ponyfills are pure and don't affect the environment.
    2. How are ponyfills better than polyfills? A polyfill is code that adds missing functionality by monkey patching an API. Unfortunately, it usually globally patches built-ins, which affects all code running in the environment. This is especially problematic when a polyfill is not fully spec compliant (which in some cases is impossible), as it could cause very hard to debug bugs and inconsistencies. Or when the spec for a new feature changes and your code depends on behavior that a module somewhere else in the dependency tree polyfills differently. In general, you should not modify API's you don't own.
    1. One of the primary tasks of engineers is to minimize complexity. JSX changes such a fundamental part (syntax and semantics of the language) that the complexity bubbles up to everything it touches. Pretty much every pipeline tool I've had to work with has become far more complex than necessary because of JSX. It affects AST parsers, it affects linters, it affects code coverage, it affects build systems. That tons and tons of additional code that I now need to wade through and mentally parse and ignore whenever I need to debug or want to contribute to a library that adds JSX support.
  8. Sep 2020
    1. It relies on something that is inherently global. Different components might 'claim' a given property name. While it's possible to differentiate them at the subtree level, it's not possible to do so globally.
    2. This has all of the downsides of global CSS (except being able to style different instances of a component differently) plus more: it may result in the need for additional DOM, and... it's kinda ugly. It feels like a hack.
    1. Global selectors, even when scoped to a subtree, cascade just like regular CSS would. This might be fine for a leaf component, but anywhere else in your app, this is the CSS equivalent of crossing your fingers and hoping that bad things won't happen.
    1. Your styles are scoped to the component. No more leakage, no more unpredictable cascade.
    2. It's fashionable to dislike CSS. There are lots of reasons why that's the case, but it boils down to this: CSS is unpredictable. If you've never had the experience of tweaking a style rule and accidentally breaking some layout that you thought was completely unrelated — usually when you're trying to ship — then you're either new at this or you're a much better programmer than the rest of us.
    3. It gets worse when you're working on a team. No-one dares touch styles authored by someone else, because it's often unclear what they're doing, what markup they apply to, and what disasters will unfold if you remove them. The consequence of all this is the append-only stylesheet. There's no way of knowing which code can safely be removed, so it's common to undo some existing style with another, more specific style — even on relatively small projects.
    1. I think it'd be nice to find a solution where it's a lot easier to mix React and Svelte components like this, but unfortunately I think that's out of the scope of this library.
    1. In mapbox.js you'll see this line: const key = {};We can use anything as a key — we could do setContext('mapbox', ...) for example. The downside of using a string is that different component libraries might accidentally use the same one; using an object literal means the keys are guaranteed not to conflict in any circumstance (since an object only has referential equality to itself, i.e. {} !== {} whereas "x" === "x"), even when you have multiple different contexts operating across many component layers.
  9. Aug 2020
    1. I honestly don't know what you find unclear about this question. I think you initially misread. I edited out your title change because it wasn't what I'd intended and it misled others. I edited in two more sections to clarify. The last section makes it as clear as I can: A single question provokes 1 of 3 responses (not necessarily answers). To chose between them I need to understand acceptable scope of both question and answers. Yes this topic is a muddy one, that's why I'm asking! I want others to help me clarify the unclear!
  10. Jul 2020
    1. Where a slogan differs from a tagline is its scope: A tagline should represent your business, while a slogan represents a single product or is part of an advertising campaign.
  11. May 2020
    1. Some GitLab features can behave differently for each environment. For example, you can create a secret variable to be injected only into a production environment.
    1. Out of Scope The following details what is outside of the scope of support for GitLab.com customers with a subscription.
    2. The GitLab.com support team does offer support for: Account specific issues (unable to log in, GDPR, etc.) Broken features/states for specific users or repositories Issues with GitLab.com availability
    3. Out of Scope The following details what is outside of the scope of support for self-managed instances with a license.
    1. It is also important to ensure a group doesn't have a scope definition that is shared across multiple groups. Here are two examples:
    1. This scope effectively covers almost all companies and, therefore, means that the GDPR can apply to you whether your organization is based in the EU or not.
    1. This scope effectively covers almost all companies and, therefore, means that the GDPR can apply to you whether your organization is based in the EU or not. As a matter of fact, this PwC survey showed that the GDPR is a top data protection priority for up to 92 percent of U.S. companies surveyed.
  12. Aug 2019
    1. The cost of a single-payer system would depend upon its design, benefit levels, and scope of coverage.

      It is impossible to provide a specific costing method, but only general methods. How is design dependent? What is the benefit level of? and the range means the limit of the "Single-payer" system?

  13. Oct 2018
    1. Instead of continuing the millennia old search for the universal ontology, different types of ontologies have been proposed in computer science. [.] [C]lassification of ontologies [is] based on their granularity and [their] thematic scope [differs] into top-level, domain, task, and application ontologies ... (Hitzler, Janowicz, Berg-Cross, Obrst, Sheth, Finin, Cruz 2012)
  14. Feb 2014
    1. In the final analysis, intellectual property shares much of the origins and orientation of all forms of property. At the same time, however, it is a more neutral institution than other forms of property: its limited scope and duration tend to prevent the very accumulation of wealth that Burke championed.
    1. I n T h e T r a d e - M a r k C a s e s , t h e C o u r t a d d r e s s e d t h e c o n s t i t u t i o n a l s c o p e o f " w r i t i n g s . " F o r a p a r t i c u l a r w o r k t o b e c l a s s i f i e d " u n d e r t h e h e a d o f w r i t i n g s o f a u t h o r s , " t h e C o u r t d e t e r m i n e d , " o r i g i n a l i t y i s r e q u i r e d . " 1 0 0 U . S . , a t 9 4 . T h e C o u r t e x p l a i n e d t h a t o r i g i n a l i t y r e q u i r e s i n d e p e n d e n t c r e a t i o n p l u s a m o d i c u m o f c r e a t i v i t y : " [ W ] h i l e t h e w o r d w r i t i n g s m a y b e l i b e r a l l y c o n s t r u e d , a s i t h a s b e e n , t o i n c l u d e o r i g i n a l d e s i g n s f o r e n g r a v i n g , p r i n t s , & c . , i t i s o n l y s u c h a s a r e o r i g i n a l , a n d a r e f o u n d e d i n t h e c r e a t i v e p o w e r s o f t h e m i n d . T h e w r i t i n g s w h i c h a r e t o b e p r o t e c t e d a r e t h e f r u i t s o f i n t e l l e c t u a l l a b o r , e m b o d i e d i n t h e f o r m o f b o o k s , p r i n t s , e n g r a v i n g s , a n d t h e l i k e . " I b i d . ( e m p h a s i s i n o r i g i n a l ) .

      In The Trade-Mark Cases the Court addressed the constitutional scope of writings saying for a particular work to be classified "under the head of writings of authors," the Court determined, "originality is required"; independent creation plus a modicum of creativity.