21 Matching Annotations
  1. Aug 2023
  2. Jul 2023
    1. ActiveStorage::LogSubscriber.detach_from :active_storage

      It's nice that it's that easy to "opt out" of the default provided log subscriber and (if desired) swap in your own custom one that does whatever you want.

  3. Jul 2022
    1. @18:52:

      I wanna also dig a little more into the kind of... dynamism, ease-of-making-changes thing, because I think there's actually two ways to look at the ease of making changes when you solve a problem with software. One way is to make software sufficiency sophisticated so that you can swap any arbitrary part out and you can keep making changes. The other is to make the software so simple that it's easy to rewrite and you can just rewrite it when the constraints change.

  4. May 2022
  5. Jul 2021
  6. greggman.github.io greggman.github.io
    1. One other thing is that many libraries seem bloated. IMO the smaller the API the better. I don't need a library to try to do 50 things via options and configuration.
  7. Mar 2021
    1. 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.
    1. Normally you should not register a named module, but instead register as an anonymous module: define(function () {}); This allows users of your code to rename your library to a name suitable for their project layout. It also allows them to map your module to a dependency name that is used by other libraries.
  8. Nov 2020
    1. Broadly speaking, modularity is the degree to which a system's components may be separated and recombined, often with the benefit of flexibility and variety in use.
  9. Oct 2020
  10. Jan 2019
    1. allowing common connections to be made wirelessly

      This sounds a bit like “send” and “receive” in some (visual) programming languages and modular synths. But the fact that it’s based on common connections sounds quite clever.

    2. Your hardware modular rig is completely integrated,

      Only started playing with Bitwig’s HW/CV integration a few days ago but it’s easy to get inspired by this.

    3. Grid devices can be nested or layered along with other devices and your plug-ins,

      Thanks to training for Cycling ’74 Max, had a kind of micro-epiphany about encapsulation, a year or so ago. Nesting devices in one another sounds like a convenience but there’s a rather deep effect on workflow when you start arranging things in this way: you don’t have to worry about the internals of a box/patcher/module/device if you really know what you can expect out of it. Though some may take this for granted (after all, other modular systems have had it for quite a while), there’s something profound about getting modules that can include other modules. Especially when some of these are third-party plugins.

    4. Try something crazy

      DAWs typically don’t mesh so well with prototyping culture. When Ableton brought clip launching through Live, its flagship DAW, it had some of this effect: experiment with clips then play with them instead of just playing them. Of course, Cycling ’74 has been all about prototyping, long before Ableton bought the company. But “Max for Live” devices are closer to plugins in that users expect to just be able to use them, not have to create them from scratch. What this marketing copy is emphasizing is that this really is about getting a box of LEGO blocks, not just about getting a DIY kit to create your own instance of something which somebody else designed. The framing sure is specific.

  11. Jun 2018
    1. Modularity enables a mass of experiments to proceed in parallel, with different teams working on the same modules, each proposing different solutions. Modularity allows different "blocks" to be easily assembled, facilitating decentralised innovation that all fits together.
  12. Nov 2017
    1. When you think the problem to be solved is the high cost of textbooks, inclusive access programs and OER adoption are just two competing approaches to solving the problem.

      There was an interesting example of this during a short conference on digital textbooks, back in late 2014. Cindy Ives interim VP Academic at Athabasca (!) presented the etext pilot project in partnership with publishers. Ives’s approach was quite pragmatic and there’s nothing wrong with doing a pilot project on something like this. By that time, Ives was already involved in OER projects. It still struck a chord with those of us who care about OER, including Éric Francoeur who took an active part in the event and did work to create a free textbook through international and interlinguistic collaboration.

      To me, a key notion from the ‘r’ in “OER” is the distinction with those content bundles we still call “textbooks”. Sure, it’s already in the 5-R model. But the “Remix” idea in music is to a large extent about unbundling.

  13. Jul 2015