27 Matching Annotations
  1. Nov 2022
    1. For example, the design pattern A Place to Wait asks that we create comfortable accommodation and ambient activity whenever someone needs to wait; benches, cafes, reading rooms, miniature playgrounds, three-reel slot machines (if we happen to be in the Las Vegas airport). This solves the problem of huddles of people awkwardly hovering in liminal space; near doorways, taking up sidewalks, anxiously waiting for delayed flights or dental operations or immigration investigations without anything to distract them from uncertain fates.

      Amazing to think how ubiquitous waiting rooms are and how we take them for granted

  2. Feb 2022
    1. There are two pairs of methods for sending/receiving messages: Object#send and ::receive for when the sender knows the receiver (push); Ractor.yield and Ractor#take for when the receiver knows the sender (pull);
  3. Jun 2021
  4. Mar 2021
    1. Uber::Option implements the pattern of taking an option, such as a proc, instance method name, or static value, and evaluate it at runtime without knowing the option's implementation.
  5. Feb 2021
    1. provide interfaces so you don’t have to think about them

      Question to myself: Is not having to think about it actually a good goal to have? Is it at odds with making intentional/well-considered decisions?  Obviously there are still many of interesting decisions to make even when using a framework that provides conventions and standardization and makes some decisions for you...

    2. Trailblazer is an architectural pattern that comes with Ruby libraries to implement that pattern.
    1. But what if leadership not only ignores our recommendations but tells us to do something different? I'll never forget one comment. "We're lying to our users," one anguished UX designer told me, explaining that leadership regularly ordered the UX team to create designs that were intentionally misleading. Apparently it helped boost profits.
    1. I think a better, more immediately understandable name for this concept would be command object, because it lets you pass around commands (or a list of commands) as objects.

      That's the only thing you really need to know abut this pattern. The rest seems like boring implementation details that aren't that important, and that naturally follow from the primary definition above.

  6. Dec 2020
  7. Nov 2020
  8. Oct 2020
  9. Sep 2020
    1. we need to step back and make a closer look at the DRY principle. As I mentioned earlier, it stands for "Don’t Repeat Yourself" and requires that any piece of domain knowledge has a single representation in your code base. The words domain knowledge are key here. DRY is not about duplicating code. It is specifically about duplicating domain knowledge

      This is actually a good point – to have a single representation of specific piece of domain knowledge in the code.

      DRY is not about duplicating code.

  10. May 2020
    1. Also, with more design styles and choices, many websites opt to not use an underlining style for an embedded link in text, nor will they use a traditional blue color to indicate an embedded link.

      Fortunately Google's ranking algorithm penalizes against this in addition to requirements for better online accessibility that help to encourage against these sorts of dark patterns of web design. Users still need to be aware that they exist however.

  11. Apr 2020
  12. Mar 2020
    1. The pattern below has become exceptionally useful for me (pun intended). It's clean, can be easily modularized, and the errors are expressive. Within my class I define new errors that inherit from StandardError, and I raise them with messages (for example, the object associated with the error).
  13. Nov 2019
    1. Middleware works a lot like a decorator. It doesn't alter the original API of the service, but it can augment it with new features and concerns. This has the inherent advantage of allowing all thidparty code to have an influence over the behaviour, state, and UI of a component.
  14. Feb 2019
  15. Jan 2019
  16. Apr 2016
    1. Each class that derives from UObject has a singleton UClass created for it that contains all of the meta data about the class instance. UObject and UClass together are at the root of everything that a gameplay object does during its lifetime. The best way to think of the difference between a UClass and a UObject is that the UClass describes what an instance of a UObject will look like, what properties are available for serialization, networking, etc. Most gameplay development does not involve directly deriving from UObjects, but instead from AActor and UActorComponent. You do not need to know the details of how UClass/UObject works in order to write gameplay code, but it is good to know that these systems exist.
  17. Mar 2016
    1. Now that our designers can call our C++ code, let us explore one more powerful way to cross the C++/Blueprint boundary. This approach allows C++ code to call functions that are defined in Blueprints. We often use the approach to notify the designer of an event that they can respond to as they see fit.
  18. Jan 2016
    1. Good Design

      You know you have a good design when you show it to people and they say, “oh, yeah, of course,” like the solution was obvious.

  19. Dec 2015
    1. Clojure Design Patterns

      Intro Episode 1. Command Episode 2. Strategy Episode 3. State Episode 4. Visitor Episode 5. Template Method Episode 6. Iterator Episode 7. Memento Episode 8. Prototype Episode 9. Mediator Episode 10. Observer Episode 11. Interpreter Episode 12. Flyweight Episode 13. Builder Episode 14. Facade Episode 15. Singleton Episode 16. Chain of Responsibility Episode 17. Composite Episode 18. Factory Method Episode 19. Abstract Factory Episode 20. Adapter Episode 21. Decorator Episode 22. Proxy Episode 23. Bridge