11 Matching Annotations
- Apr 2021
-
github.com github.com
-
These example are for Rails applications, but there is no dependency on Rails for using this gem. Most of the examples are applicable to any Ruby application.
-
- Mar 2021
-
www.jackfranklin.co.uk www.jackfranklin.co.uk
-
This isn't really a downside to React; one of React's strengths is that it lets you control so much and slot React into your environment
-
-
www.chevtek.io www.chevtek.io
-
I would much rather have a "cosine" module than a "trigonometry" module because chances are good I only need a small fraction of the utilities provided by the larger trig module.
-
Small modules are extremely versatile and easy to compose together in an app with any number of other modules that suit your needs.
-
Second, I don't agree that there are too many small modules. In fact, I wish every common function existed as its own module. Even the maintainers of utility libraries like Underscore and Lodash have realized the benefits of modularity and allowed you to install individual utilities from their library as separate modules. From where I sit that seems like a smart move. Why should I import the entirety of Underscore just to use one function? Instead I'd rather see more "function suites" where a bunch of utilities are all published separately but under a namespace or some kind of common name prefix to make them easier to find. The way Underscore and Lodash have approached this issue is perfect. It gives consumers of their packages options and flexibility while still letting people like Dave import the whole entire library if that's what they really want to do.
Tags
- allowing developer/user to pick and choose which pieces to use (a la carte, not all or nothing)
- modularity
- granularity of control
- flexibility to use the tool that you prefer
- allowing developer/user to pick and choose which pieces to use (allowing use with competing libraries; not being too opinionated; not forcing recommended way on you)
- small units/components/modules/libraries/packages/projects
- composition
- micropackages
- all or nothing (granularity of control)
- composability
Annotators
URL
-
-
github.com github.com
-
It can also be included as individual modules, i.e. Hashie::Extensions::MethodReader, Hashie::Extensions::MethodWriter and Hashie::Extensions::MethodQuery.
-
- Feb 2021
-
trailblazer.to trailblazer.to
-
Feel free to pick and choose what you need for your applications.
-
-
github.com github.com
-
The bare bones operation without any Trailblazery is implemented in the trailblazer-operation gem and can be used without our stack.
-
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.
-
Only use what you like.
-
you can pick which layers you want. Trailblazer doesn't impose technical implementations
Tags
- abstractions
- newer/better ways of doing things
- trailblazer-operation
- allowing developer/user to pick and choose which pieces to use (allowing use with competing libraries; not being too opinionated; not forcing recommended way on you)
- leaving the details of implementation/integration up to you
- Trailblazer
- focus on what it should do, not on how it should do it (implementation details; software design)
- freedom of user to override specific decision of an authority/vendor (software)
- focus on concepts/design/structure instead of specific/concrete technology/implementation
- rails: the Rails way
- making changes / switching/migrating gradually/incrementally/step-wise/iteratively
Annotators
URL
-