# Um químico na cozinha (Haumont, Raphaël)

Ano passado havia comprado um livro de gastronomia que uma chef vendedora ambulante de brigadeiro recomendou enquanto estava vendendo sua mercadoria para nós, meros bêbados eventuais. Porém, tive que devolver no dia seguinte: o texto é muito ruim e confuso. Ele investe em defender cozinha molecular e eu, leitor desavisado, nem sabia que isso estava em ataque. Eu nem sabia que isso era uma coisa. Pra falar a verdade, não me identifico muito com essas cozinhas diferentonas que querem cobrar horrores pela experiência. De vez em quando é legal de ir, mas bem de vez em quando.

Voltando ao livro. O autor fica toda hora defendendo esse estilo de cozinhar e por algum motivo este deveria ser um livro para cozinheiros iniciantes na cozinha de casa. Não é. Eu não sei muito bem para quem é. Só sei que não é pra mim. Enfim, uma única anotação que fiz antes de abandonar o dito cujo:

Vidro e caramelo são sólidos amorfos, que podem ser representados como líquidos solidificados, desordenados: assim, sua estrutura interna não permite um movimento coletivo. Sob tensão, as forças de ligação se rompem e, macroscopicamente, a matéria quebra.

# Anotações de A Hacker Manifesto (Mckenzie Wark)

Hackers use their knowledge and their wits to maintain their autonomy. Some take the money and run. (We must live with our compromises.) Some refuse to compromise. (We live as best we can.)

We do not own what we produce—it owns us.

Hackers create the possibility of new things entering the world. Not always great things, or even good things, but new things.

The slogan of the hacker class is not the workers of the world united, but the workings of the world untied.

# Anotações de Head First Software Architecture (Raju Gandhi, Mark Richards;Neal Ford)

Continuando minha saga de achar um bom livro de arquitetura de software.

Dispose plants that need more sunshine than others. To organize by water needs. Separate rhe problematic ones. To give a nice look by putting the prettiest one in the front.

What features of your home can you list that are structural and related to its architecture?

The walls are structural. The living room gives axxess to all other parts. The plumbing connects to the wet parts. There are windows to allow ventilation.

Check the things you think might be considered architectural characteristics—something that the structure of the software system supports.

Access scalability. Database integrity. Flexible customization. Access security.

Collectively, things like performance, scalability, reliability, and availability are also known as non-functional requirements,

Decisions are structural guides for dev teams Significant trade-offs are mostly their themes

A logical component should always have a well-defined role and responsibility in the system—in other words, what it does.

Logical components are blocks in conjunction They hold the source code for each business function

The domain is the problem you are trying to solve, and the system functionality is how you are solving that problem. In other words, the domain is the “what,” and the system’s functionality is the “how.”

Think about a typical website . The architecture, or structure, is all about how the web pages communicate with backend services and databases to retrieve and save data, whereas design is all about what each page looks like: the colors, the placement of the fields, and so on.

Unlike design, architecture is about the physical structure of the system—things like services, databases, and how services communicate with each other and to the user interface.

Check all of the things that should be included in a diagram from an architectural perspective.

Components communication. Non functional characteristics. Database access.

# Clean Architecture: A Craftsman's Guide to Software Structure and Design (Robert C. Martin aka Uncle Bob)

A good architecture comes from understanding it more as a journey than as a destination.

Este livro é bom em reagrupar princípios consagrados de arquitetura de software e relacionar com o desenvolvimento de software e seus paradigmas. Ele é um pouco tedioso em entender a vida útil de um sistema, mas brilha com algumas máximas e dicas de como tomar decisões ou organizar blocos de código para manutenção de longo prazo.

The primary purpose of architecture is to support the life cycle of the system: easy to understand, easy to develop, easy to maintain, and easy to deploy.

Abaixo recortes de um passeio pelas abstrações e pelas diferentes camadas que melhoram nossa visibilidade das milhares ou às vezes milhões de linhas de código de um sistema.

Software—the stuff of computer programs—is composed of sequence, selection, iteration, and indirection. Nothing more. Nothing less.

The primary cost of maintenance is in spelunking and risk. Spelunking is the cost of digging through the existing software, trying to determine the best place and the best strategy to add a new feature or to repair a defect.

The way you keep software soft is to leave as many options open as possible, for as long as possible. What are the options that we need to leave open? They are the details that don’t matter.

Gather into components those classes that change for the same reasons and at the same times. Separate into different components those classes that change at different times and for different reasons.

A software artifact should be open for extension but closed for modification.

Build from interchangeable parts that must adhere to a contract that allows them to be substituted one for another.

Details should depend on policies, not the opposite.

The Dependency Inversion Principle tells us that the most flexible systems are those in which source code dependencies refer only to abstractions, not to concretions. Allow no cycles in the component dependency graph. Regardless of which component you begin at, it is impossible to follow the dependency relationships and wind up back at that component.

Modules that are easy to change are not depended on by modules that are harder to change. The goal of the architect is to create a shape for the system that recognizes policy as the most essential element of the system while making the details irrelevant to that policy.

If you can develop the high-level policy without committing to the details that surround it, you can delay and defer decisions about those details for a long time. And the longer you wait to make those decisions, the more information you have with which to make them properly. A good architect pretends that the decision has not been made, and shapes the system such that those decisions can still be deferred or changed for as long as possible. A good architect maximizes the number of decisions not made.

The IO is a detail. The web (an IO device) is a detail. The database is a detail. The framework is a detail.

Software systems are statements of policy. Indeed, at its core, that’s all a computer program actually is. A computer program is a detailed description of the policy by which inputs are transformed into outputs. Part of the art of developing a software architecture is carefully separating those policies from one another, and regrouping them based on the ways that they change.

A good architecture will allow a system to be born as a monolith, deployed in a single file, but then to grow into a set of independently deployable units, and then all the way to independent services and/or micro-services. Later, as things change, it should allow for reversing that progression and sliding all the way back down into a monolith.

Business rules are rules or procedures that make or save the business money. Very strictly speaking, these rules would make or save the business money, irrespective of whether they were implemented on a computer. They would make or save money even if they were executed manually. An Entity is an object within our computer system that embodies a small set of critical business rules operating on Critical Business Data. The interface of the Entity consists of the functions that implement the Critical Business Rules that operate on that data.

A use case is a description of the way that an automated system is used. It specifies the input to be provided by the user, the output to be returned to the user, and the processing steps involved in producing that output. A use case describes application-specific business rules as opposed to the Critical Business Rules within the Entities. Use cases contain the rules that specify how and when the Critical Business Rules within the Entities are invoked. Use cases control the dance of the Entities. High-level concepts, such as Entities, know nothing of lower-level concepts, such as use cases.

Input occurs at the controllers, and that input is processed into a result by the interactors. The presenters then format the results, and the views display those presentations. The presenters, views, and controllers all belong in the interface adapters layer. The models are likely just data structures that are passed from the controllers to the use cases, and then back. The data that crosses the boundaries consists of simple data structures.

The View is the humble object that is hard to test. Presenter is the testable object. At each architectural boundary, we are likely to find the Humble Object pattern lurking somewhere nearby. Your goal is to implement the boundaries right at the inflection point where the cost of implementing becomes less than the cost of ignoring.

Think of Main as the dirtiest of all the dirty components. Develop a strategy that prevents the framework from taking over that architecture. If your system is all about the use cases, and if you have kept your frameworks at arm’s length, then you should be able to unit-test all those use cases without any of the frameworks in place. You non-embedded developers essentially write firmware whenever you bury SQL in your code or when you spread platform dependencies throughout your code.

# 14 Hábitos de Desenvolvedores Altamente Produtivos (Rocha, Zeno)

Imagine que você gira o dial e está apenas captando ruído estático, mas depois de alguns segundos frustrantes, ele finalmente consegue captar um sinal e sintonizar uma estação. O sinal é a informação significativa na qual você realmente está interessado. O ruído estático é apenas a variação aleatória e indesejada que interfere no sinal. É por isso que a autoconsciência é tão importante, você precisa ser capaz de identificar qual é o sinal e o que é apenas ruído. (...) É crucial entender que o barulho sempre estará lá.

# Colinha que todos usamos para esperar o debugger quando o notepad inicia

Ou qualquer outro processo (mas a vítima padrão continua sendo o notepad).

int WaitForDebugger(const char* processName = "notepad", int timeout = 60)
{
    int secondsWaiting = 0;
    char fileName[MAX_PATH];
    GetModuleFileNameA(nullptr, fileName, MAX_PATH);
    if( StrStrIA(fileName, processName))
    {
        while( IsDebuggerPresent() == FALSE && secondsWaiting < timeout )
        {
            Sleep(1000);
            secondsWaiting++;
        }
    }
    return secondsWaiting;
}

# What we do not know (Nicolas Gomez Davila)

In an age in which the media broadcast countless pieces of foolishness, the educated man is defined not by what he knows, but by what he doesn't know.

Nicolas Gomez Davila

# Os Safados (Frank Oz, 1988)

Steve Martin e Michael Caine estão impagáveis nesse filme antigo dos anos 80 de onde tenho memória de alguns flashes. Um filme de golpe que perde um pouco de ritmo lá para o final, mas antes admiramos a dinâmica entre Martin e Cane brincando de gato e rato em uma luta desleal pelo troféu não oficial de golpista da Riviera Francesa. Se você se entreter demais com o filme, a reviravolta final lhe dará dores de cabeça. Felizmente naquela época os finais não precisavam ser explicados, deixando um mistério simples e previsível no ar. Dirigido por Frank Oz, o mesmo do universo dos Muppets.

# Matador (Pedro Almodóvar, 1986)

Este Almodóvar pode ser considerado clássico, pois contém todos os elementos que marcaram seu estilo e que faz parte do repertório decorado de seus fãs. Além disso, apresenta um elenco honesto em participar de uma história semicrua em uma versão que está em construção. É o refinamento do um diretor em treinamento, que não conseguiu mesclar os assuntos de assassinato e touradas a ponto de não ser apenas uma brincadeira. A dupla de assassinos é profissional demais para não serem confundidos com personagens de novela, mas Antonio Banderas vive um de seus melhores papéis como um lunático vidente sensível.

# How not to be productive little guideline

• Theorized something that could be easily discarded.
• Checked for peripherical code without theorizing anything. Twice.
• Made some discovery about something not closely related to the bug.
• Finally talked to the user and got some real information that tracked the next step.

# Grandes Hits (Ned Benson, 2024)

A menina viaja no tempo quando escuta uma música que ouviu pela primeira vez com o namorado morto. Ela está obcecada há dois anos em tentar salvá-lo. Surge um japonês fofinho como interesse amoroso e para a cota dos amarelos imigrantes nesta simpática seleção de músicas de apaixonadinhos onde iremos passar duas horas agradáveis.

# On the same thing

Keeping the focus on the same thing even if you need to wait for action.

myself