Architecting Web Apps - Lights, Camera, Action! (Chrome Dev Summit 2018)
"Art prior" to React:
Martin Fowler: InversionOfControl (2005-Jun-26)
Inversion of Control is a key part of what makes a framework different to a library. A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.
A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.
The litmus test:
- If your code calls it, it's a library.
Resource: Implementing bookmarklets in JavaScript
- Implement bookmarklet as an IIFE.
- Test the IIFE in the console for a relevant page.
- Minify the finished bookmarklet, e.g. Minify JS Online
- In the Bookmark Manager (Ctrl+Shift+O) choose “Add New Bookmark” under the “Organise” menu.
- Specify a name.
- In URL specify the
javascript:
scheme and delimeter and paste the minified bookmarklet at the end.
e.g.
In 2002 Scott Ambler observed in Agile Modeling (p.4) the typical career path of a corporate developer:
"I also believe that the way that developers learn their trade has a few unique dysfunctions. For the most part our colleges and universities are doing a reasonable job of educating developers for entry-level jobs. However, even if the schools were doing a perfect job and everyone was getting a degree or diploma, I suspect that we’d still have a problem due to the inherent nature of software developers. When software developers are young, in their teens or early twenties, they typically focus on learning and working with technology. They describe themselves as PERL programmers, Linux experts, Enterprise JavaBeans (EJB) developers, or .NET developers. To them technology is the important thing. Because technology is constantly changing, young
But, the old systems don’t just die. They are replaced. Furthermore, in most cases, homegrown systems are replaced in stages. In those stages, the old systems have to talk to the new systems. Someone has to know how to make the new speak to the old, and vice versa. Typically, the young tykes don’t know (or want to know) how to make the old systems listen. Nor do the crusty old pre-retirees know how to make the newfangled systems talk to their beloved creatures.
So, there’s a role to be filled by a calculating technologist: technology hospice. Helping the old systems die comfortably and with dignity is a task that should not be underestimated. And, of course, most people will jump ship before it sinks, either via retirement or by sidestepping into another technology realm. By being the last one left to support still-critical systems, you can pretty much call the shots. It’s risky, in that once the technology really is gone, you’ll be an expert in something that doesn’t exist. However, if you can mov
defmodule FromPipe do | |
# | |
# Use a helper script "from_pipe_release" to | |
# release/request each line read from the | |
# named pipe - effectively implementing a | |
# crude backpressure mechanism | |
# | |
@pipe_name "/tmp/testpipe" | |
@from_pipe_release "./from_pipe_release" | |
@from_pipe_clean "./from_pipe_clean" |
Inspired by “it's a table driven problem, it's not an object oriented problem, it's not even a control flow problem”.
- Gilded Rose Requirements
- Original TypeScript starting point
- TypeScript Playground with
updateQualityBefore(item: Item)
andupdateQualityAfter(item: Item)
/*
Solid (solid.html
1.5.4)
Activating: red
Red is off
Red is on
Activating: green
Green is on
Green is off
Activating: blue
Blue is off
Sample run on Ubuntu 22.04 LTS [i7-4900MQ CPU @ 2.80GHz/32GB] Chromium 105.0.5195.102
Solid (solid.html
)
Created 205760 nodes.
278 ms; sum: 9.11303444731602e+305
@preact/signals (preactive.html
)
… That sums up the widely accepted Layered Architecture pattern for object applications. But this separation of UI, application, and domain is so often attempted and so seldom accomplished that its negation deserves a discussion in its own right.
Many software projects do take and should continue to take a much less sophisticated design approach that I call the Smart UI. But Smart UI is an alternate, mutually exclusive fork in the road, incompatible with the approach of domain-driven design. If that road is taken, most of what is in this book is not applicable. My interest is in the situations where the Smart UI does not apply, which is why I call it, with tongue in cheek, an “anti-pattern.” Discussing it here provides a useful contrast and will help clarify the circumstances that justify the more difficult path taken in the rest of the book.
❊ ❊ ❊
A project needs to deliver simple functionality, dominated by data entry and display, with few business rules. Staff is