50 Matching Annotations
  1. Jan 2024
  2. Dec 2023
    1. command = AuthenticateUser.call(params[:email], params[:password]) 8 9 if command.success?
    2. Instead of using private controller methods, simple_command can be used.

      first sighting: simple_command

  3. Nov 2023
  4. Jul 2023
    1. A data model[1][2][3][4][5] is an abstract model that organizes elements of data and standardizes how they relate to one another and to the properties of real-world entities.
  5. Nov 2022
    1. Testing frameworks often introduce their own abstractions for e.g. evaluation order, data validation, reporting, scope, code reuse, state, and lifecycle. In my experience, these abstractions are always needlessly different from (and inferior to) related abstractions provided by the language itself.
  6. May 2022
    1. The argument used to propose its use is to avoid the construction of multiple volatile objects. This supposed advantage is not real in virtual machines with efficient garbage collection mechanisms.

      Consider a Sufficiently Smart Compiler/Runtime where a multiply-instanced class has the exact same runtime characteristics as code that has been hand-"tuned" to use a singleton.

  7. Nov 2021
  8. Feb 2021
    1. Please note that this is a higher-level debugging tool that does not confront you with a 200-lines stack trace the way Ruby does it, but pinpoints the exceptional code and locates the problem on a task level. This is possible due to you structuring code into higher abstractions, tasks and activities.
    1. While you could program this little piece of logic and flow yourself using a bunch of Ruby methods along with a considerable amount of ifs and elses, and maybe elsif, if you’re feeling fancy, a Trailblazer activity provides you a simple API for creating such flow without having to write and maintain any control code. It is an abstraction.
    2. Activities are a necessary abstraction on top of Ruby.
    3. An activity is a high-level concept to structure code flow
    1. would love to hear from you if you’re excited about our gems, high-level abstractions and improving our documentation
    1. This text wound up founding the discipline which we today call "metaphysics", and one way to describe what this subject encompasses is that it covers things at a level of abstraction above physics.
    1. Trailblazer extends the conventional MVC stack in Rails. Keep in mind that adding layers doesn't necessarily mean adding more code and complexity. The opposite is the case: Controller, view and model become lean endpoints for HTTP, rendering and persistence. Redundant code gets eliminated by putting very little application code into the right layer.
    2. 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. Yes, Trailblazer is adding new abstractions and concepts and they are different to the 90s-Ruby, but now, at the latest, it becomes obvious how this improves the developing process. We’re no longer talking in two-dimensional method stack traces or byebug hoops, the language and conception is changing to the actual higher level code flow, to activities sitting in activities structured into smaller step units.
    2. I feel how needed those new abstractions are. Yes, you can write everything with your own code, you don’t need abstractions for flow control and automatic error handling, which makes me wonder why you’re not programming in assembler since Ruby is also an “unnecessary abstraction” on top of a processor. We need abstractions, unless you want to program like we did 30 years ago.
    3. Also, the more I use Trailblazer in projects or even in Trailblazer itself, I feel how needed those new abstractions are.
    1. I've been over the use case for form objects in this post on moving away from fat models but wanted to go into more detail on how and why I use them here. I really believe in the utility of these objects; their ability to abstract and isolate logic in a simple and effective manner is unmatched, IMO.
  9. Jan 2021
  10. Oct 2020
    1. express one's model of Existence
    2. Ambiguity is a tool of consciousness to compel us to explore the dissonance in our current model of Existence. Follow the rabbit hole…and a richer Existence awaits.
    3. Language, using a schema, provides a system of abstraction enabling one to model something. Language is context sensitive & composable. With the Language tool, we craft systems of illusion, intelligence, & life.
    4. "The Map is not the territory" —Alfred Korzybski
    5. "All non-trivial abstractions, to some degree, are leaky" —Joel Spolsky
    1. Alfred Korzybski remarked that "the map is not the territory" and that "the word is not the thing", encapsulating his view that an abstraction derived from something, or a reaction to it, is not the thing itself.
    2. The map–territory relation describes the relationship between an object and a representation of that object, as in the relation between a geographical territory and a map of it.
    3. "The menu is not the meal."
    4. A map is not the territory it represents, but, if correct, it has a similar structure to the territory, which accounts for its usefulness.
  11. Sep 2020
    1. Now of course we know how React handles this conflict: it takes the new nodes in your virtual DOM tree — the waters in your flowing river — and maps them onto existing nodes in the DOM. In other words React is a functional abstraction over a decidedly non-functional substrate.

      To me this is a warning sign, because in my experience, the bigger the gap between an abstraction and the thing it abstracts, the more likely you are to suffer what programmers like to call ‘impedance mismatches’, and I think we do experience that in React.

    1. While you can do a lot with just utility classes, as a project grows it can be useful to codify common patterns into higher level abstractions.Tailwind provides tools for extracting component classes from repeated utility patterns, making it easy to update multiple instances of a component from one place:
  12. Jun 2020
    1. However, it is often the case that you do need a higher layer of abstraction in order to deal with the complexity of non-trivial applications. If you don’t deal with that abstraction explicitly, one day you will wake up and find that you’ve created a mess of abstraction and indirection through a thousand cuts.
  13. May 2020
  14. Apr 2020
    1. I'm always in awe at some of the things you can create with the simple primitives that d3 provides.
  15. Nov 2019
    1. the abstraction I wished to have was a sort of a pure functional Vim, completely decoupled from terminal UI - where 'vim' is a function of (editor state, input) => (new editor state)
  16. Feb 2019
    1. abstraction is in itself but a dull and inert thing

      That "in itself" is an important qualifier. My initial thought was how this idea contrasts with Hume's discussion of the uses of general concepts, but the "in itself" poses abstractions by themselves, when not employed to a particular use. When abstractions are put to work, do they do something similar to Hume's generalities? (How closely related are abstractions and general principles?)