Started reading: Sourcery: A Discworld Novel by Terry Pratchett.

Finished reading: Bea Wolf, by Zach Weinersmith and illustrated by Boulet. An adaptation of Beowulf for children, and absolutely delightful.

Finished reading: But now am found, by Patricia Horvath. Beautiful short story collection, each a compact gut punch.

Finished reading: First Love, by Joyce Carol Oats. What a precisely rendered master crafted gut punch. Loved it.

Started reading: First Love, by Joyce Carol Oats.

Finished reading: The Mythical Man-Month, by Frederick P. Brooks Jr. I liked the insights into managing software, and the time traveling to the computing industry circa 1975–1995. Took me 1 month and 6 days.

“Read” the short story The Simplest Equation by Nicky Drayden, via Levar Burton Reads. Really beautiful.

“Read” River’s Giving by Heather Shaw, Tim Pratt, and River Shaw over on LeVar Burton Reads. Cute, all ages holiday fantasy story.

Finished reading: Classic Tales of Horror (Arcturus Classics) by Edgar Allan Poe. Took me a bit to sink into the language, but once I did I really enjoyed this. Nice to read the big stories again as an adult, and I sometimes enjoyed the deep cuts.

I’ve started using Micro.blog’s bookshelves features to track my reading. Right now I’m obsessively trying to catalogue all the books I’ve ever read. That’s possible, says my brain.

Finished reading: A Civic Technologist’s Practice Guide by Cyd Harrell. Useful tips for technologists on how to work in collaboration with government. It took me 27 days to finish reading.

Listened to the short story I Was A Teenage Space Jockey by Stephen Graham Jones on the Levar Burton Reads podcast. Effecting, intense, and full of texture.

Started reading: The Mythical Man-Month, by Frederick P. Brooks Jr. I never read this often-discussed collection of essays on computer programming management. Excited to dive in. I had it on my reading list before Frederick Brooks’ passing, but death has a way of re-arranging priorities.

Finished reading: The Number Ones by Tom Breihan. I don’t respond to top 40 music in any era, but the stories are almost always fun and interesting, and the history of popular musical taste is fascinating. Tom Beihan writes so you can hear.

Started reading: A Civic Technologist’s Practice Guide by Cyd Harrell. I only just started, but already I love the tone. Excited for insights.

I’m #reading a collection of Edgar Allan Poe stories. Its enjoyable, but I’m also finding it hard to focus enough to follow the language all the time. It’s like only getting TV reception every other minute.

Also posted to: <mastodon.social/@bronzehe…>

Finished reading: The Road to React by Robin Wieruch. Took me over eight months. It was only meh.

I’m reading a Murakami story collection in an art gallery. Someone stops, mentions they read it, too. They move on, then come back. I didn’t get the one with the ghost. I try to relate, but confuse it with a different story. Maybe you haven’t read that one yet. Maybe I haven’t. It’s hard to hear through the masks. I say I have been letting the stories wash over me, feeling dumb. They are eager to leave. It all feels like a Murakami story.

Also posted to: <mastodon.social/@bronzehe…>

Finished reading: Grokking Algorithms by Aditya Y. Bhargava.

Read the short story The Case for and Against Love Potions by Imbolo Mbue.

Finished reading: Heroes by Stephen Fry. Pure joy.

Started reading: Heroes by Stephen Fry.

Finished reading: Monopolized: Life in the Age of Corporate Power by David Dayen. It took me around six months.

Finished reading: Letters From an Astrophysicist by Neil deGrasse Tyson. Took me over a month.

Finished reading: A Very Punchable Face by Colin Jost. Read it in 27 days.

Started reading: The Road to React by Robin Wieruch.

Started reading: Letters From an Astrophysicist by Neil deGrasse Tyson.

Started reading: A Very Punchable Face by Colin Jost.

Finished reading: Mythos: The Greek Myths Retold by Stephen Fry.

Read: On Creativity: A Short and Cheerful Guide by John Cleese.

Started reading: Mythos: The Greek Myths Retold by Stephen Fry.

Read the short story Hansa and Gretyl and Piece of Shit by Rebecca Curtis.

Finished reading: Dungeon World Sage LaTorra & Adam Koebel. It took me 11 days.

Started reading: Dungeon World Sage LaTorra & Adam Koebel.

Started reading: Ruined by Design by Mike Monteiro.

Finished reading: Ruined by Design by Mike Monteiro.

Started reading: Monopolized: Life in the Age of Corporate Power by David Dayen.

Read: Design Ethics by Mike Monteiro.

Read the short story The Sand Banks, 1861 by David Wright Faladé.

Read the short story Cicadia by David Gilbert.

Finished reading: The Painted Word by Tom Wolfe. Took me 2 days.

Started reading: The Painted Word by Tom Wolfe.

Finished reading: Kindred by Octavia Butler. What an incredible book. Took me 10 days.

Read the short story Asymmetry by Kendra Fortmeyer.

I did not finish reading Eloquent Javascript by Marijn Haverbeke. I really liked it though. I leave out hope I’ll go back to it, but it took me almost 2 years to get to this point.

I never went to school for computer science, learning on the job and in my spare time through articles, videos, and experience.

This was great, forcing me to learn practical, pragmatic approaches fast, but did leave some classic theory to be inferred.

Since I had never done it formally, I decided to work through Eloquent Javascript, a beginners introduction to programming.

It’s very well written and dense, which I like a lot. I maintain a repo with my solutions to the end-of-chapter practice exorcises enforced by tests, https://github.com/bronzehedwick/eloquent-js-exercises, which I’ve been slowly working through.

Here’s a few posts.

Chapter 6. The Secret Life of Objects

All properties that we create by simply assigning to them are enumerable. The standard properties in Object.prototype are all nonenumerable, which is why they do not show up in such a for/in loop.

A clear way of articulating this. When you assign a new value, it is always enumerable, unless you pull something specific to tell JS otherwise, aka Object.defineProperty.

Finished reading: The AWK Programming Language by Alfred V. Aho, Brian W. Kernighan & Peter J. Weinberger. Took me around two months and two weeks.

This was really helpful to read even the first chapter of. It’s very powerful but really well explained and easy to grasp; finally all those somewhat magic one liners I’d been using make sense!

Chapter 1: An AWK Tutorial

AWK programs loop over every line in the input and apply the program to each line. They are linewise. They only have two data types: strings and numbers.

Each AWK program is in the form of pattern { action }. The pattern is a way to filter lines processed. The action is what the program actually does.

If pattern is blank, it will match all lines.

Example pattern: $3 > 0 matches if the third field is greater than 0. Can also be a regular expression, by wrapping in /.

Fields by default are spaces. To change, use -F.

AWK exposes default variables.

1. $0 equals the entire line.
2. $1...$9 are fields one through 9.
3. NR is the line number.
4. NF is the number of fields in the line.

You can apply math between fields via the standard operators (+-*/%).

The proper shebang for an AWK file is /usr/bin/awk -f.

print function prints fields or literals. Separate values via commas.

printf function works similar to C version.

BEGIN and END are special constructs that allow you to put content or processing at the top or bottom of the program results.

You can have any number of pattern { action } constructs, separated by new lines.

You can also define/redefine variables on the fly, simply by assigning to them. No initialization needed. Data type is automatically inferred. Here is an example program to count the number of LPs listed on this site from the records CSV:

$4 == "LP" { lps = lps + 1 }
END { print lps }

AWK provides built-in functions, including length(), which counts the number of characters in the string passed in.

Each program in this chapter has been a sequence of pattern-action statements. Awk tests every input line against the patterns, and when a pattern matches, performs the corresponding action. Patterns can involve numeric and string comparisons, and actions can include computation and formatted printing. Besides reading through your input files automatically, awk splits each input line into fields. It also provides a number of built-in variables and functions, and lets you define your own as well. With this combination of features, quite a few useful computations can be expressed by short programs - many of the details that would be needed in another language are handled implicitly in an awk program.

Started reading: Kindred by Octavia Butler.

Read the short story The Lottery by Shirley Jackson.

Started reading: Grokking Algorithms by Aditya Y. Bhargava.

Didn’t finish reading: A Slave Girl’s Story by Kate Drumgoold. Gave up after one day and 30 pages.

Read the short story Morning Child by Gardner Dozois.

Read the short story Yiwu by Lavie Tidhar.

Read the short story Singing on a Star by Ellen Klages.

Read the short story The Cell Phones by Karen E. Bender.

Started reading: The AWK Programming Language by Alfred V. Aho, Brian W. Kernighan & Peter J. Weinberger.

Read the short story Jackalope Wives by Ursula Vernon.

Started reading: A Slave Girl’s Story by Kate Drumgoold.

Finished reading: Sphere by Michael Crichton. Took me almost three weeks.

Read the short story Fyrewall by Stefani Cox.

Read the short story Fantastie Impromptu No.4 in C#min Op.66 by Carlos Hernandez.

Read the short story Multo by Samuel Marzioli.

Read the short story Fires by Rick Bass.

Read the short story The Last Cheng Beng Gift by Jaymee Goh.

Read the short story Sea Girls by Daniel Wallace.

Read the short story Welcome to Your Authentic Indian Experience™ by Rebecca Roanhorse.

Read the short story The Fliers of Gy by Ursula K. Le Guin.

Read the short story Black Betty by Nisi Shawl.

Started reading: Sphere by Michael Crichton.

Finished reading: The Martian Way by Issac Asimov. Took me almost a month.

Read the short story The Money Tree by Nalo Hopkinson.

Finished reading: Torchbearer by Thor Olavsrud & Luke Crane. Took me nine days.

Started reading: Torchbearer by Thor Olavsrud & Luke Crane.

Read the short story The Afterlife by Jonathan Lethem.

Read the short story The Resident Poet by Katherine Dunn.

Finished reading: Learning to Program in C by Thomas Plum. It took me around six months. Below are my posts.

Binary integers

To calculate binary integers, assign each number an incrementing value, working right to left. The increment doubles the previous value, starting at 1. For example 1, 2, 4, 8, 16, 32, and so on. Isolate every one of those values represented by a 1, ignoring 0, and add all those together. That is the integer value.

10010101

  1| 0| 0| 1|0|1|0|1
128|  |  |16| |4| |1

128 + 16 + 4 + 1 = 149

In signed values, the far left bit (high-order bit) is the negative/positive number indicator. If that bit is 0, the number is positive, 1 and it’s negative.

Operators

#define is a constant in the compiler. Evaluates the program and replaces #defines first. Convention is uppercase.

Header files end in .h and contain #defines and includes, and are included at the top of the .c files via #include. This is a way to abstract conventions and presumably revise them.

Precedence and Associativity

If data is too big for it’s type, it is increased behind the scenes to the next type, called Promotion. Promotion also happens with arithmetic and assignment to the largest type in the duo.

sprintf - receiving array must be long enough for content or it will overrun into other memory.

Overflow is possible with +, -, *, ++, --, <<.

Started reading: The Martian Way by Issac Asimov.

Read the short story The Wish for a Good Young Country Doctor by Allan Gurganus.

Finished reading Something Wicked This Way Comes by Ray Bradbury. Took me a month and a week.

Started reading: Something Wicked This Way Comes by Ray Bradbury.

Read the short story Love Letter by George Saunders.

Finished reading: Catacomb by Andrew Laurance. This book sucked. What a turd. Prose that somehow made me care less about the characters, and characters that made me care less about books. A plot with all the tension of spaghetti. Twists that you would need to surround that word in so many quotes as to be unrecognizable. ““““““““““““““““Twists””””””””””””””””. A dumb book with bad everything. I read all of it. Took me 15 days.

Started reading: Catacomb by Andrew Laurance.

Read the short story Out There by Kate Folk.

Finished reading: The Metamorphosis by Franz Kafka. Took me a day.

Started reading: The Metamorphosis by Franz Kafka.

Finished reading: Permanent Record by Edward Snowden.

Read the short story Night Swim by Anne Enright.

Read the short story The Winds of Harmattan by Nnedi Okorafor.

Read the short story Childfinder by Octavia Butler.

Read the short story Kid Positive by Adam Levin.

Finished reading: Javascript Design Patterns by Addy Osmani. It took me 133 days. Below are some posts.

What Is a Pattern?

Patterns don’t solve all design problems, nor do they replace good software designers, however, they do support them.

Patterns support good developers. The next question is, what makes a good dev? Seems squishy but extremely important.

Patterns add to a developers vocabulary, which makes communication faster.

This is a great maybe hidden benefit. Communication between developers is paramount. The next question is, for those who are not familiar with the same patterns, how do you communicate them? Very context specific.

We Already Use Patterns Every Day

So, which of these options is the fastest? It’s actually the third option by a factor of 8 to 10 times the alternatives.

getElementsByClassName is faster than querySelectorAll by a factor of 8-10.

“Pattern”-ity Testing, Proto-Patterns, and the Rule of Three

patterns generally focus on addressing a visually identifiable structure—i.e., we should be able to visually depict the structure that results from the pattern in practice.

Interesting. I’m not sure I quite grasp this yet, but it makes sense at a high level. Use a pattern (something abstract) to generalize something that is visually concrete, so you’re not putting an abstraction on top of an abstraction. At least that’s my takeaway. Could be making my own assumptions.

“proto-pattern”: a pattern that has not yet been known to pass the “pattern”-ity tests.

50 pages in and we’ve got our first sex joke. Good to know what a proto pattern is tho. A pattern that has not been tested. Couched in the language of Mory Povich.

Alternatively, the individual(s) sharing the pattern may not have the time or interest of going through the “pattern”-ity process and might release a short description of their proto-pattern instead. Brief descriptions or snippets of this type of pattern are known as patlets.

Patlets? Weird. Is there some formal pattern naming body? Why is this so formal, and so silly?

Patterns are not supposed to just capture principles or strategies. They need to capture solutions.

Patterns capture solutions, not principles.

…design patterns usually provide solutions to problems indirectly

This is necessary to solve more challenging problems. Not sure how that relates yet. Probably need a more concrete example first.

Describes a proven concept.

Patterns must be proven. This makes inherent sense. You can’t fly by speculation. I guess this needs to be stated, since were in the business of taking the guesswork out of things.

Describes a relationship. In some cases, it may appear that a pattern describes a type of module. Although an implementation may appear this way, the

This is incomprehensible to me. So many vague terms that I don’t know the definition of in this context.

Many proto-patterns are actually quite good.

Some examples of a pattern vs a proto pattern would be useful. I know there will be bone fide patterns, since that’s in the name, but I’m hoping for some proto patterns examples later on in the book.

One of additional requirement for a pattern to be valid is that it display some recurring phenomenon.

Makes sense. You can’t make a pattern (something inherently repeatable) from a one off thing.

The Structure of a Design Pattern

A context A system of forces that arises in that context A configuration that allows these forces to resolve themselves in context…

This is entirely too abstract to extract any meaning from at this point. Hoping for more examples to make this concrete.

Writing Design Patterns

When we’re looking at a body of code we think may be using a pattern, we should consider writing down some of the aspects of the code that we believe fall under a…

Take postss about code that might fall into a pattern. Write down which patterns it might apply in.

Writing Design Patterns

Design patterns should be entirely transparent to any type of user experience. They are primarily there to serve the developers using them and should not force changes to behavior in the user experience that would not be incurred without the use of a pattern.

Patterns serve developers, and should not change end users experience.

Anti-Patterns

If we consider that a pattern represents a best practice, an anti-pattern represents a lesson that has been learned.

Yeah it’s often just as useful to outline what not to do as well as what to do.

Examples of anti-patterns in JavaScript are the following

Some more JS anti patterns:

• relying on type coercion for undefined/null/false, since this does not result in a single output like false
• defining a variable without a keyword, since that leaks to global scope

Creational Design Patterns

Creational design patterns focus on handling object-creation mechanisms where objects are created in a manner suitable for a given situation.

Various patterns to control the object creation mechanism to prevent overuse and incompatible implementation

Structural Design Patterns

They help ensure that when one part of a system changes, the entire structure of the system doesn’t need to do the same.

“They” meaning structural patterns. Basically these patterns help with modularity and composition.

Behavioral Design Patterns

Behavioral patterns focus on improving or streamlining the communication between disparate objects in a system.

If structural helps each piece of the system stay compatible with the rest, behavioral patterns help facilitate the communication between those various compatible systems.

Here compatible means works easily with each other, not relying on the specifics of the implementation inside to determine how you interface with it from the outside, staying agnostic.

The Module Pattern

The disadvantages of the Module pattern are that, as we access both public and private members differently, when we wish to change visibility, we actually have to make changes to each place the member was used.

This is an important call out. The module pattern is good at “loose” encapsulation, but does impose a refactor tax if you want to change the public / private nature of methods.

I’m most familiar with this pattern when it comes to the classic IIFE usage, some AMD back in the day, and common js.

The Revealing Module Pattern

An example of how to use the Revealing Module pattern is as follows:

The revealing module pattern is actually the one I’m much more familiar with, and it’s what I’ve most often seen combined with IIFE namespacing. It’s nice clean and simple with a small syntax tax.

Public object members that refer to private variables are also subject to the no-patch rule.

I don’t know what the author means by no latch rule. He mentioned that the module and revealing module pattern cannot be patched or hot fixed in certain situations, but I don’t know what he means by hot fix or patch. These are not single meaning terms. He could be talking about any number of things.

Hence I don’t have a great grasp of the weaknesses pertaining to patching in these patterns.

The Singleton Pattern

Singletons differ from static classes (or objects) as we can delay their initialization, generally because they require some information that may not be available during initialization time.

So singleton instantiation can be depleted to after init time, to some later point in the program. And it seems like this is one of the primary reasons to use the pattern.

I can think of an example maybe when you want to instantiate something only if and after a user action. Perhaps triggering a modal and you only want one modal on the screen at a time.

The Singleton pattern is thus known because it restricts instantiation of a class to a single object.

Super concise and illuminating explanation. From this I get that a class can only have a single instance. JS doesn’t have real classes in terms of copying, they’re objects that are prototype linked, so I’m curious how singleton applies to JS.

Classically, the Singleton pattern can be implemented by creating a class with a method that creates a new instance of the class if one doesn’t exist. In the event of an instance already existing, it simply returns a reference to that object.

This explains how classical languages accomplish singleton. Creating a new instance only if one doesn’t already exist, otherwise returning the already existing instance.

There must be exactly one instance of a class, and it must be accessible to clients from a well-known access point. The sole instance should be extensible by subclassing, and clients should be able to use an extended instance without modifying their code.

For a singleton to be a singleton, there needs to be exactly one instance of it, no matter how many times the constructor is called, and this single instance should be subclassable without any other implementing piece having to modify their code. I don’t exactly know what subclassable means at this point but let’s read on.

In C++, it serves as isolation from the unpredictability of the dynamic initialization order, returning control to the programmer.

It’s important for singletons to be defined outside the init order since that can be unpredictable, which is certainly true in a dynamic async browser housed language like JavaScript. This gives the programmer control over when the execution happens, determined by the code they write.

…the Singleton pattern is useful when exactly one object is needed to coordinate others across a system.

This is a warning on the overuse of any one pattern, which is a point well taken. If all you have is a hammer, everything looks like a nail.

It’s also interesting that the recommendation here for use of singletons is as a coordination across the system. I guess that’s because singletons have an well known interface and don’t use much resources, even though they can be called any number of times.

The presence of the Singleton is often an indication that modules in a system are either tightly coupled or that logic is overly spread across multiple parts of a code base.

Interesting. This comment only pertains to JS but that’s an interesting point. After this big explanation of the pattern, the author basically says that if you use it in JS you’re doing it wrong.

I’m having trouble imagining all the complexity required to validate this but I’ll take his word for it.

The Observer Pattern

The Observer is a design pattern in which an object (known as a subject) maintains a list of objects depending on it (observers), automatically notifying them of any changes to state (Figure 9-3).

The context switching needed to parse the different uses of the same word, and the reassignments of terminology, is impressive. And that’s not a compliment. But I get it naming is hard.

The observer pattern creates a subject that observers can point to to be automatically updated on state. I’m pretty sure events in JS is an observer pattern.

When a subject needs to notify observers about something interesting happening, it broadcasts a notification to the observers (which can include specific data related to the topic of the notification).

This is addEventListener no?

Subject

The subject is the thing that maintains a list of observers, and handles adding and removing listeners.

Observer

This is the middleman that tells the objects attached to the subject about changes happening in the subject. It’s the external interface for these updates.

ConcreteSubject

I think if subject is an abstract class, concrete subject is an actual instantiation (in classical programming). It does the actual work of saving the changes from the subject to the concrete observers.

ConcreteObserver

Is a reference to the Observer, and actually performs the updates back to it. I guess this is what you actually interact with.

The Mediator Pattern

Another analogy would be DOM event bubbling and event delegation.

Ah ha, so the observer pattern is similar to event bubbling but not quite the same. The mediator pattern is event bubbling. Although this is for only bubbling/delegation, not direct event binding, which I suppose is still the observer pattern.

As this books describes, in implementation terms, the mediator pattern is a shared subject from the observer pattern.

Metaphor for mediator pattern: air traffic control tower. In fact that’s just a non-software mediator pattern.

The largest benefit of the Mediator pattern is that it reduces the communication channels needed between objects or components in a system from many to many to just many to one.

I can see how this would be really helpful in reducing complexity. Although, duh. The trick is figuring out when this is appropriate. Again, duh.

Perhaps the biggest downside of using the pattern is that it can introduce a single point of failure.

Yeowch.

The Command Pattern

The Command Pattern

As far as I can understand it from reading this chapter, the command pattern describes a pattern of abstracting method calls such that the object is loosely coupled instead of tightly. Instead of calling the implementation-specific methods of an object, make those private and wrap them in a public method that composes the needed private methods. This prevents large scale application refactoring if the implementation level API changes for the module.

The Facade Pattern

This pattern provides a convenient higher-level interface to a larger body of code, hiding its true underlying complexity. T

We basically simplify the underlying logic, abstracting away complexity and providing a more focused, usable alternative.

$(el).css()

jQuery methods are facades. Makes sense.

As we can see below, our instance of the Module pattern contains a number of methods that have been privately defined. A Facade is then used to supply a much simpler API to accessing these methods:

Ah ha I knew it! The facade is commonly used to abstract and compose private methods. Snap.

When using the Facade pattern, try to be aware of any performance costs involved and make a call on whether they are worth the level of abstraction offered.

Yes the facade can cause a performance penalty over non-abstracted code, but it doesn’t always and the benefits and drawbacks have to be considered.

The Factory Pattern

Instead, a Factory can provide a generic interface for creating objects, where we can specify the type of factory object we wish to be created

So the factory pattern is an abstraction over object/class instantiation, which becomes more useful of object construction is complex.

Instead of using new or something like that, you have a single object with a method that you ask to create the type of object you want and it returns it to you to have and to hold.

When we need to easily generate different instances of objects depending on the environment we are in. When we’re working with many small objects or components that share the same properties.

Some other good use cases for this pattern.

Another I didn’t highlight is about duck typing to fit an API that I didn’t really understand.

Unless providing an interface for object creation is a design goal for the library or framework we are writing, I would suggest sticking to explicit constructors to avoid the unnecessary overhead.

Answers a good question of when not to use this pattern. So probably a rare grab from the tool belt.

It is also useful to be aware of the Abstract Factory pattern, which aims to encapsulate a group of individual factories with a common goal. It separates the details of implementation of a set of objects from their general usage. An Abstract Factory pattern should be used where a system must be independent from the way the objects it creates

I’m not totally sure what the implementation difference is between an abstract factory and a regular factory.

Mixins

Each new object we define has a prototype from which it can inherit further properties.

So prototypes are the mixin pattern?

Some developers feel that injecting functionality into an object prototype is a bad idea as it leads to both prototype pollution and a level of uncertainly regarding the origin of our functions. In large systems, this may well be the case.

This is interesting. I think the OLOO pattern is a mixin if I didn’t mention that already. Not knowing the origin of the method is a real problem. I can see documentation helping, but it would still be hard to tell from the function call what composed it, and tag systems wouldn’t help much I don’t think. Something to consider.

Pseudoclassical Decorators

An interface is a way of defining the methods an object should have; however, it doesn’t actually directly specify how those methods should be implemented.

Nice explanation here. An interface is the abstract notion of the API along with the names of the methods, but nothing of the implementation of those methods.

This would be an impractical solution, as a new subclass would be required for every possible combination of enhancements that are available.

Mixins are preferable over sub classing when the functionality additions aren’t linear. If you’d need to create a crap ton of horizontal sub classes - aka one parent and a lot of children, instead of one parent, a few children, some grandchildren, etc - it makes more sense to mixin the functionality. Have small encapsulated functions that you can swap in in any number to a new object, all of which combine to add to or override the existing methods.

Advantages and Disadvantages

it can significantly complicate our application architecture, as it introduces many small but similar objects into our namespace.

The main drawback of the mixin pattern is potential confusion, especially to devs new to the project. Comment a lot.

Flyweight

The Flyweight pattern is a classical structural solution for optimizing code that is repetitive, slow, and inefficiently shares data.

I guess this is what best situations to use this pattern. If you have the problem of inefficient and slow data sharing between modules, consider the flyweight pattern as a solution.

The first is at the data layer, where we deal with the concept of sharing data between large quantities of similar objects stored in memory. The second is at the DOM layer, where the Flyweight can be used as a central event-manager to avoid attaching event handlers to every child element in a parent container we wish to have some similar behavior.

In all languages flyweight can be used to share data between large objects. I don’t think the “large quantities of similar objects” is a requirement of the pattern, but rather when it makes sense to implement it.

The JS only version is that flyweight can also be applied to the DOM in the form of a centralized event manager, which is delegated events.

states: intrinsic and extrinsic. Intrinsic information may be required by internal methods in our objects, which they absolutely cannot function without. Extrinsic information can however be removed and stored externally.

Intrinsic is the methods on the object, stuff the object needs to operate. Extrinsic

Try to think of the flyweight in terms of a pond. A fish opens its mouth (the event), bubbles rise to the surface (the bubbling), a fly sitting on the top flies away when the bubble reaches the surface (the action). In this example we can easily transpose the fish opening its mouth to a button being clicked, the bubbles as the bubbling effect, and the fly flying away to some function being run.

Nice description of the flyweight pattern in the DOM.

MVVM

The only exception to this rule tends to be validation, and it’s considered acceptable for Models to validate data being used to define or update existing models (e.g., does an email address being input meet the requirements of a particular regular expression?).

Models handle clean data, views present that data, and model views handle business logic, with the exception of validation, which the modal can handle and input time, probably so there doesn’t have to be corrupted data being passed around.

Final posts

I skipped the parts on knockout, backbone, and jQuery specific stuff, which is about half the book.

All Excerpts From

Osmani, Addy. “Learning JavaScript Design Patterns.” O’Reilly Media, 2012-07-08. Apple Books.
This material may be protected by copyright.

Started reading: Permanent Record by Edward Snowden.

Read the short story 5:22 by George Harrar.

Read the short story With the Beatles by Haruki Murakami.

Finished reading: The Stand by Stephen King. Took me three and a half months.

Read the short story Ghost Lover by Lisa Taddeo.

Read the short story Three Women at Chuck’s Diner by Anthoney Veasna So.

Read the short story My Dear You by Rachel Khong.

Read Dream Worlds, Raffi Khatchadourian’s profile on N.K. Jemisin.

Read: APIs for Dummies by Dennis Ashby & Claus T. Jensen for work, by one of the authors. Absolutely nothing of substance.

I read the fake screenplay to Grown Ups 3 by Tom Scharpling. Chef’s kiss.

Did not finish reading: My First Movie: 20 Celebrated Directors Talk about Their First Film by Various authors, edited by Stephen Lowenstein. Read this for a couple essays. Took me 18 days.

Read the short story Making Your Life as an Artist by Andrew Simmonet.

Started reading: Learning to Program in C by Thomas Plum.

Read the short story Furry Night by Joan Aiken.

Started reading: My First Movie: 20 Celebrated Directors Talk about Their First Film by Various authors, edited by Stephen Lowenstein.

Didn’t finish reading The Silent Clowns by Walter Kerr.

A giant coffee table book my wife already owned, I started reading it after watching City Lights and listening to the Unspooled podcast episode about the film.

The book is great, and the introduction especially grabbed me. It’s an essay on the fundamental difference between silent film and talkies, and how talkies were not inevitable, even though it seems that way now.

The first sound picture happened years before The Jazz Singer, and there were multiple studio attempts to bring it to audiences between the two points, but people rejected it, preferring silent film.

And there is something that can only be captured in silence. You are not contrained by microphones, so your shots are free to go where ever. Your movies can be more visual, more a dance.

There’s some really interesting trade offs you make between sound and silence; things that work in one wouldn’t work in another, and vice versa.

Did not finished reading: Building a Character by Contantin Stanislavski. Was leant this book by a friend to prepare for a play. It’s all anecdotes about how Stanislavski learned different techniques while a student. Fascinating. Weird. Useful? A trip. Gave up after 196 days and 152 pages.

Finished reading: Be Cool by Elmore Leonard. It took me 18 days.

While the prose is energetic and engaging, I kept finding myself not giving a shit about what happens next. A lot of boomer fantasies about the young kids worshiping the same music they did, and in the same way.

Plus, the groan-o-clock trope of women inexplicably throwing themselves at the tough-guy author stand-in protagonist.

Contains the back cover quote gem, segue from real life to reel life.

There’s cringe-y passages that attempt to show off racial awareness while also trying to sound hip—like how the kids talk—which ends up sounding like if a robot’s personality was programmed only with a combination of after school specials and Steven Seagal movies.

Alternate title: “Grandpa Farted A Crime Caper”

But, it kept me reading to the end, so I can’t complain. The prose moves, man.

Finished reading: The C Book by Mike Banahan, Declan Brady and Mark Doran, originally published by Addison Wesley. Took me 10 days.

I wanted to get a basic grasp of C, but most of the resources listed in the C language IRC channel were pretty pricey. One resource, however, was completely free: The C Book. That sounded both authoritative and cheap, so I started reading and taking postss.

It was only a few chapters in that I found out the book was out of date and only published for historical purposes.

I’m sure some of what I learned in my short stint with The C Book is still relevant, but I don’t want to risk polluting my head with wrong stuff.

Here then, are the postss I took.

1.1. The form of a C program

Each C library is first compiled, then all pieces are compiled together.

1.2. Functions

The main function is special, and is the first function that gets run “magically” in your program. This is only the case in hosted environments, however. In non-hosted environments, the first function called is implementation dependent.

#include <stdio.h>

/*
* Tell the compiler that we intend
* to use a function called show_message.
* It has no arguments and returns no value
* This is the "declaration".
*
*/

void show_message(void);
/*
* Another function, but this includes the body of
* the function. This is a "definition".
*/
main(){
     int count;

     count = 0;
     while(count < 10){
             show_message();
             count = count + 1;
     }

     return(0);
}

/*
* The body of the simple function.
* This is now a "definition".
*/
void show_message(void){
     printf("hello\n");
}

This is what I’ve been reading this past week.

• Admissions Scandal Shows Elite Schools’ Self-Importance - The Atlantic
  A think piece from a Yale professor refocusing on what the point of universities are, although the bit at the end about not being ashamed of admitting wealthy donors kids for their money is never going to fly.
• hooooooooooooooooooooooooooooooooooooooooooooooooooooooooorse
  I’m honestly heartened when I see goofy, pointless stuff like this on the web again.
• List: Revolutionary Quotes From Centrist History - McSweeney’s Internet Tendency
  McSweeny’s swoops in once more for the win.
• List: If Conservatives Talked About Other Issues the Way They Talk About Climate Change - McSweeney’s Internet Tendency
  Nailed it.
• ‘Centurians of Rome’: How a Bank Robber Made the Most Expensive Gay Porno Flick of All Time
  Engrossing long form about a gay, Cuban-American overachiever, and one time anti-gay crusader’s life of crime.

There it is, and here we are. Go forth.

This is what I’ve been reading this past week.

• Using CSS Grid the right way | hey it’s violet
  Some good tips.
• Alyssa Rosenzweig – The Federation Fallacy
  Convincing take on the democratization of a centralized internet, versus a decentralized one.

There it is, and here we are. Go forth.

This is what I’ve been reading this past week.

• Four Temperaments and the Forms of Poetry
  A thinky, verbose literary analysis of what ingredients writers bring to their work, and how those best interact. Focused pointedly on poetry, but I think it has value for anyone working creatively with the written word.
• Jessie Frazelle’s Blog: Government. Medicine. Capitalism?
  What the software industry can learn from government and medicine, and generally good thoughts on management.
• Remembering The Grateful Dead’s ‘Wall of Sound’: An Absurd Feat of Technological Engineering
  Another story about The Dead I didn’t think I’d enjoy, but here we are.
• Write code that is easy to delete
  Great article on software design, but I think the broad principles are applicative to many creative fields, as well.

There it is, and here we are. Go forth.

These are some choice picks from what I’ve been reading for the past few weeks.

I hope to publish these link round-ups weekly, but for this first one I have a backlog of saved links, so this one has more links then will be usual.

• Ong’s Hat: The Early Internet Conspiracy Game That Got Too Real
  If you’re into reading about weirdo conspiracy theories, inter dimensional travel, and/or New Jersey, this is a must.
• Privacy vs “I have nothing to hide” - Kev Quirk
  Puts the importance of privacy in plain, effecting language.
• CERN 2019 WorldWideWeb Rebuild
  Very cool recreation of the first web browser, written for NeXT.
• Prof. Dr. Style
  A fun look at the very early web design, and how bullet-proof it is still.
• Was the Godfather of Soul murdered?
  Completely gripping, totally chilling. I was captivated.
• The Transitive Nightfall of Fatty Egg Rolls
  I’m strangely enthralled by this tale of bygone Deadhead egg rolls, from a bygone website.
• A brief history of wi-fi privacy vulnerabilities | Robert Heaton
  A fascinating look at one of the underpinnings of modern life.

There it is, and here we are. Go forth.