For example, Active Record is on Page 160, and inspired https://api.rubyonrails.org/classes/ActiveRecord.html. Model View Controller is on page 330 and inspired https://api.rubyonrails.org/classes/ActiveModel.html, https://api.rubyonrails.org/classes/ActionView.html, and https://api.rubyonrails.org/classes/ActionController.html. Template View is on page 350, and inspired https://api.rubyonrails.org/classes/ActionView/Template.html.

Not all patterns used in Rails are so directly named, though. Layer Supertype is on page 475 and is behind the `class Company < ActiveRecord::Base; end` style. Single Table Inheritance is on page 278, and inspired https://api.rubyonrails.org/classes/ActiveRecord/Inheritance.... Repository is on page 322, and inspired https://api.rubyonrails.org/classes/ActiveRecord/FinderMetho.... Value Object is on page 486, and is a key part of https://api.rubyonrails.org/classes/ActiveRecord/Aggregation....

See also: https://signalvnoise.com/posts/3375-the-five-programming-boo...

I'm currently reading More Fearless Change by Manns & Rising. I've always enjoyed being a change agent, and I would've been more effective if I'd read this book a decade ago.

Next up, I plan to read Facilitating Software Architecture by Harmel-Law.

Oh, and every day or two I read aloud a chapter of Magic and Meaning Expanded by Burger & Neale to my wife. We're both magicians and big fans of Eugene Burger's work.

Comments URL: https://news.ycombinator.com/item?id=49895636

Points: 4

# Comments: 0

For example, the Lexham English Bible:

> I looked again and saw under the sun that the race does not belong to the swift, the battle does not belong to the mighty, food does not belong to the wise, wealth does not belong to the intelligent, and success does not belong to the skillful, for time and chance befalls all of them.

I'd love to read your book, if you write it. Anybody who's talked to a thousand people trying to solve the same problems will have an amazing perspective and a lot to teach.

> A project needs to deliver simple functionality, dominated by data entry and display, with few business rules. Staff is not composed of advanced object modelers.

> [...] Simple projects come with short time lines and modest expectations. Long before the team completes the assigned task, much less demonstrates the exciting possibilities of its approach, the project will have been canceled. [...] And in the end, if they do surmount these challenges, they will have produced a simple system. Rich capabilities were never requested.

> Therefore, when circumstances warrant:

> Put all the business logic into the user interface. Chop the application into small functions and implement them as separate user interfaces, embedding the business rules into them. Use a relational database as a shared repository of the data. Use the most automated UI building and visual programming tools available.

> [...] Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common. Considering it here helps us understand why we need to separate application from domain and, importantly, when we might not want to.

> Advantages: Productivity is high and immediate for simple applications; Less capable developers can work this way with little training; Even deficiencies in requirements analysis can be overcome by releasing a prototype to users and then quickly changing the product to fit their requests; Applications are decoupled from each other, so that delivery schedules of small modules can be planned relatively accurately; Expanding the system with additional, simple behavior can be easy; Relational databases work well and provide integration at the data level; 4GL tools work well; When applications are handed off, maintenance programmers will be able to quickly redo portions they can’t figure out, because the effects of the changes should be localized to each particular UI.

> Disadvantages: Integration of applications is difficult except through the database; There is no reuse of behavior and no abstraction of the business problem. Business rules have to be duplicated in each operation to which they apply; Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits refactoring options; Complexity buries you quickly, so the growth path is strictly toward additional simple applications. There is no graceful path to richer behavior.

> [...] Remember, one of the consequences of this pattern is that you can’t migrate to another design approach except by replacing entire applications. [...] Don’t bother hedging your bet. Just using a flexible language doesn’t create a flexible system, but it may well produce an expensive one.

If you live in the U.S. I recommend you read No Sweat of the Brow Copyright: https://www.gutenberg.org/help/no_sweat_copyright.html

This is explained by the ElementaryOS H.I.G.:

> Apps should save their current state when closed so they can be reopened right to where the user left off. Typically, closing and reopening an app should be indistinguishable from the legacy concept of minimizing and unminimizing an app; that is, all elements should be saved including open documents, scroll position, undo history, etc.

> Because of the strong convention of saved state, elementary OS does not expose or optimize for legacy minimize behavior; e.g. there is no minimize button, and the Multitasking View does not distinguish minimized windows.

More: https://docs.elementary.io/hig/user-workflow/closing

These are not sapient beings that are capable of looking out for their own well-being. We've bred that out of them over hundreds of human generations.

But there's so much to the linguistics of animal husbandry and dairy that many folks don't know. It goes way deeper than just the milk-oriented terms in the article: Heifer versus cow, freshening and calving, steer versus ox versus bull, AI (not the LLM kind) versus natural service, the barn, parlor, and pasture, and more. Plus plenty of technical knowledge. If you're not hand milking, how many mmHg of negative pressure should you use? Do you use a surcingle, or a claw, or a robot?

Even in the milk-oriented terms, there are others not covered by the article. HTST and UHT aren't the only options, there's also LTLT. Pasteurization can be done in a pipeline, or in a vat. Smaller vats for home and small farm usage can be multi-purpose: I pasteurized milk and cultured yogurt in mine. Some folks even care about the specific proteins (A1 beta-casein versus A2), which is genetically determined by the cow (and can be bred for).

I got a cow in 2020 and there was a lot to learn.