# 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)

Este livro é muito 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.

A única crítica ao programador comum é ter que decorar muitas siglas de princípios que apenas pelo nome já fica difícil de associar, imagine as suas abreviações. Por esse motivo traduzi pelo menos as siglas dos recortes abaixo.

A good architecture comes from understanding it more as a journey than as a destination, more as an ongoing process of enquiry than as a frozen artifact.

The goal of software architecture is to minimize the human resources required to build and maintain the required system.

The measure of design quality is simply the measure of the effort required to meet the needs of the customer. If that effort is low, and stays low throughout the lifetime of the system, the design is good. If that effort grows with each new release, the design is bad. It’s as simple as that.

Software was invented to be “soft.” It was intended to be a way to easily change the behavior of machines. If we’d wanted the behavior of machines to be hard to change, we would have called it hardware.

The more this architecture prefers one shape over another, the more likely new features will be harder and harder to fit into that structure. Therefore architectures should be as shape agnostic are practical.

If you give me a program that works perfectly but is impossible to change, then it won’t work when the requirements change, and I won’t be able to make it work. Therefore the program will become useless. If you give me a program that does not work but is easy to change, then I can make it work, and keep it working as requirements change. Therefore the program will remain continually useful.

The first value of software -- behavior -- is urgent but not always particularly important. The second value of software -- architecture -- is important but never particularly urgent.

Remember, as a software developer, you are a stakeholder. You have a stake in the software that you need to safeguard. That’s part of your role, and part of your duty. And it’s a big part of why you were hired.

Structured programming imposes discipline on direct transfer of control. Object-oriented programming imposes discipline on indirect transfer of control. Functional programming imposes discipline upon assignment.

We use polymorphism as the mechanism to cross architectural boundaries; we use functional programming to impose discipline on the location of and access to data; and we use structured programming as the algorithmic foundation of our modules. Notice how well those three align with the three big concerns of architecture: function, separation of components, and data management.

In 1955, having been a programmer for three years, and while still a student, Dijkstra concluded that the intellectual challenge of programming was greater than the intellectual challenge of theoretical physics. As a result, he chose programming as his long-term career.

Nowadays we are all structured programmers, though not necessarily by choice. It’s just that our languages don’t give us the option to use undisciplined direct transfer of control.

Ultimately, we can say that mathematics is the discipline of proving provable statements true. Science, in contrast, is the discipline of proving provable statements false.

OO certainly does depend on the idea that programmers are well-behaved enough to not circumvent encapsulated data. Even so, the languages that claim to provide OO have only weakened the once perfect encapsulation we enjoyed with C.

Note, however, that the source code dependency (the inheritance relationship) between ML1 and the interface I points in the opposite direction compared to the flow of control. This is called dependency inversion, and its implications for the software architect are profound.

With this approach, software architects working in systems written in OO languages have absolute control over the direction of all source code dependencies in the system.

Architects would be wise to push as much processing as possible into the immutable components, and to drive as much code as possible out of those components that must allow mutation.

With that realization, we have to face an unwelcome fact: Software is not a rapidly advancing technology. The rules of software are the same today as they were in 1946, when Alan Turing wrote the very first code that would execute in an electronic computer. The tools have changed, and the hardware has changed, but the essence of software remains the same.

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

The best structure for a software system is heavily influenced by the social structure of the organization that uses it so that each software module has one, and only one, reason to change.

The gist is that for software systems to be easy to change, they must be designed to allow the behavior of those systems to be changed by adding new code, rather than changing existing code.

In short, this principle says that to build software systems from interchangeable parts, those parts must adhere to a contract that allows those parts to be substituted one for another.

This principle advises software designers to avoid depending on things that they don’t use.

The code that implements high-level policy should not depend on the code that implements low-level details. Rather, details should depend on policies.

A module should have one, and only one, reason to change. A module should be responsible to one, and only one, user or stakeholder. A module should be responsible to one, and only one, actor.

Cohesion is the force that binds together the code responsible to a single actor.

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

We want to protect the Controller from changes in the Presenters. We want to protect the Presenters from changes in the Views. We want to protect the Interactor from changes in... well, anything.

Notice how this creates a hierarchy of protection based on the notion of “level.” Interactors are the highest-level concept, so they are the most protected. Views are among the lowest-level concepts, so they are the least protected. Presenters are higher level than Views, but lower level than the Controller or the Interactor.

The goal is to make the system easy to extend without incurring a high impact of change. This goal is accomplished by partitioning the system into components, and arranging those components into a dependency hierarchy that protects higher-level components from changes in lower-level components.

What is wanted here is something like the following substitution property: If for each object o1 of type S there is an object o2 of type T such that for all programs P defined in terms of T, the behavior of P is unchanged when o1 is substituted for o2 then S is a subtype of T.

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.

Every change to an abstract interface corresponds to a change to its concrete implementations. Conversely, changes to concrete implementations do not always, or even usually, require changes to the interfaces that they implement. Therefore interfaces are less volatile than implementations.

Components are the units of deployment. They are the smallest entities that can be deployed as part of a system.

People who want to reuse software components cannot, and will not, do so unless those components are tracked through a release process and are given release numbers.

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.

Gather together those things that change at the same times and for the same reasons. Separate those things that change at different times or for different reasons.

Don’t force users of a component to depend on things they don’t need.

Don’t depend on things you don’t need.

The Common Reuse Principle says that classes that are not tightly bound to each other should not be in the same component.

The Reuse/Release Equivalence Principle and CCP are inclusive principles: Both tend to make components larger. The Common Reuse Principle is an exclusive principle, driving components to be smaller. It is the tension between these principles that good architects seek to resolve.

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. This structure has no cycles. It is a Directed Acyclic Graphs.

By conforming to the Stable Dependencies Principle (Stable Dependencies Principle), we ensure that modules that are intended to be easy to change are not depended on by modules that are harder to change.

One sure way to make a software component difficult to change, is to make lots of other software components depend on it.

The Stable Dependencies Principle says that the I metric of a component should be larger than the I metrics of the components that it depends on. That is, I metrics should decrease in the direction of dependency.

A component should be as abstract as it is stable.

The Stable Abstractions Principle sets up a relationship between stability and abstractness.

The Stable Abstractions Principle and the Stable Dependencies Principle combined amount to the Interface Segregation Principle for components. This is true because the Stable Dependencies Principle says that dependencies should run in the direction of stability, and the Stable Abstractions Principle says that stability implies abstraction. Thus dependencies run in the direction of abstraction.

Some software entities do, in fact, fall within the Zone of Pain. An example would be a database schema. Database schemas are notoriously volatile, extremely concrete, and highly depended on. This is one reason why the interface between OO applications and databases is so difficult to manage, and why schema updates are generally painful.

However, the architecture of a system has very little bearing on whether that system works. There are many systems out there, with terrible architectures, that work just fine. Their troubles do not lie in their operation; rather, they occur in their deployment, maintenance, and ongoing development.

The primary purpose of architecture is to support the life cycle of the system. Good architecture makes the system easy to understand, easy to develop, easy to maintain, and easy to deploy. The ultimate goal is to minimize the lifetime cost of the system and to maximize programmer productivity.

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. While making such changes, the likelihood of creating inadvertent defects is always there, adding to the cost of risk.

Software was invented because we needed a way to quickly and easily change the behavior of machines. But that flexibility depends critically on the shape of the system, the arrangement of its components, and the way those components are interconnected.

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.

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. This allows decisions about those details to be delayed and deferred.

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.

Conway’s law says: Any organization that designs a system will produce a design whose structure is a copy of the organization’s communication structure.

So the architect can employ the Single Responsibility Principle and the Common Closure Principle to separate those things that change for different reasons, and to collect those things that change for the same reasons—given the context of the intent of the system.

Thus we find the system divided into decoupled horizontal layers—the UI, application-specific business rules, application-independent business rules, and the database, just to mention a few.

At the same time, use cases are narrow vertical slices that cut through the horizontal layers of the system. Each use case uses some UI, some application-specific business rules, some application-independent business rules, and some database functionality.

If two apparently duplicated sections of code evolve along different paths—if they change at different rates, and for different reasons—then they are not true duplicates.

Return to them in a few years, and you’ll find that they are very different from each other.

You may be tempted to simply pass the database record up to the UI, rather than to create a view model that looks the same and copy the elements across. Be careful: This duplication is almost certainly accidental.

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.

You draw lines between things that matter and things that don’t.

The Database component contains the code that translates the calls made by the BusinessRules into the query language of the database. It is that translation code that knows about the BusinessRules.

The Database component could be replaced with many different implementations—the BusinessRules don’t care.

The business rules don’t care at all. And that means that the database decision can be deferred and you can focus on getting the business rules written and tested before you have to make the database decision.

They define a system in terms of the GUI, so they believe that they should see the GUI start working immediately. They fail to realize a critically important principle: The IO is irrelevant.

You forget that behind that interface there is a model—a sophisticated set of data structures and functions—driving it. More importantly, that model does not need the interface. It would happily execute its duties, modeling all the events in the game, without the game ever being displayed on the screen. The interface does not matter to the model—the business rules.

Once again, we see that the less relevant component depends on the more relevant component.

Indeed, the history of software development technology is the story of how to conveniently create plugins to establish a scalable and maintainable system architecture. The core business rules are kept separate from, and independent of, those components that are either optional or that can be implemented in many different forms

This is simply the Single Responsibility Principle again. The Single Responsibility Principle tells us where to draw our boundaries.

You should recognize this as an application of the Dependency Inversion Principle and the Stable Abstractions Principle. Dependency arrows are arranged to point from lower-level details to higher-level abstractions.

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. Policies that change for the same reasons, and at the same times, are at the same level and belong together in the same component. Policies that change for different reasons, or at different times, are at different levels and should be separated into different components.

The art of architecture often involves forming the regrouped components into a directed acyclic graph. The nodes of the graph are the components that contain policies at the same level. The directed edges are the dependencies between those components. They connect components that are at different levels.

A strict definition of “level” is “the distance from the inputs and outputs.”

We want source code dependencies to be decoupled from data flow and coupled to level.

Any component that we expect to be volatile should not be depended on by a component that is difficult to change. Otherwise, the volatile component will also be difficult to change.

Strictly speaking, 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 Entity object either contains the Critical Business Data or has very easy access to that 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.

Entities have no knowledge of the use cases that control them. This is another example of the direction of the dependencies following the Dependency Inversion Principle. High-level concepts, such as Entities, know nothing of lower-level concepts, such as use cases. Instead, the lower-level use cases know about the higher-level Entities.

You might be tempted to have these data structures contain references to Entity objects. You might think this makes sense because the Entities and the request/response models share so much data. Avoid this temptation! The purpose of these two objects is very different. Over time they will change for very different reasons, so tying them together in any way violates the Common Closure and Single Responsibility Principles. The result would be lots of tramp data, and lots of conditionals in your code.

Good architectures are centered on use cases so that architects can safely describe the structures that support those use cases without committing to frameworks, tools, and environments.

Develop a strategy that prevents the framework from taking over that architecture.

If your system architecture 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.

The overriding rule that makes this architecture work is the Dependency Rule: Source code dependencies must point only inward, toward higher-level policies.

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 from the use cases to the presenters and views.

Also in this layer is any other adapter necessary to convert data from some external form, such as an external service, to the internal form used by the use cases and entities.

The frameworks and drivers layer is where all the details go. The web is a detail. The database is a detail. We keep these things on the outside where they can do little harm.

We take advantage of dynamic polymorphism to create source code dependencies that oppose the flow of control so that we can conform to the Dependency Rule, no matter which direction the flow of control travels.

Typically the data that crosses the boundaries consists of simple data structures.

The important thing is that isolated, simple data structures are passed across the boundaries. We don’t want to cheat and pass Entity objects or database rows.

Thus, when we pass data across a boundary, it is always in the form that is most convenient for the inner circle.

The Humble Object pattern1 is a design pattern that was originally identified as a way to help unit testers to separate behaviors that are hard to test from behaviors that are easy to test.

The View is the humble object that is hard to test.

Presenter is the testable object. Its job is to accept data from the application and format it for presentation so that the View can simply move it to the screen.

Anything and everything that appears on the screen, and that the application has some kind of control over, is represented in the View Model as a string, or a boolean, or an enum. Nothing is left for the View to do other than to load the data from the View Model into the screen. Thus the View is humble.

(...) the separation of the behaviors into testable and non-testable parts often defines an architectural boundary.

For example, if the application needs to know the last names of all the users who logged in yesterday, then the UserGateway interface will have a method named getLastNamesOfUsersWhoLoggedInAfter that takes a Date as its argument and returns a list of last names.

At each architectural boundary, we are likely to find the Humble Object pattern lurking somewhere nearby. The communication across that boundary will almost always involve some kind of simple data structure, and the boundary will frequently divide something that is hard to test from something that is easy to test.

This kind of anticipatory design is often frowned upon by many in the Agile community as a violation of YAGNI: “You Aren’t Going to Need It.” Architects, however, sometimes look at the problem and think, “Yeah, but I might.” In that case, they may implement a partial boundary.

This example is intended to show that architectural boundaries exist everywhere. We, as architects, must be careful to recognize when they are needed. We also have to be aware that such boundaries, when fully implemented, are expensive. At the same time, we have to recognize that when such boundaries are ignored, they are very expensive to add in later—even in the presence of comprehensive test-suites and refactoring discipline.

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.

The point is that Main is a dirty low-level module in the outermost circle of the clean architecture. It loads everything up for the high level system, and then hands control over to it.

Think of Main as a plugin to the application.

(...) you can think of the tests as the outermost circle in the architecture. Nothing within the system depends on the tests, and the tests always depend inward on the components of the system.

Fragile tests often have the perverse effect of making the system rigid. When developers realize that simple changes to the system can cause massive test failures, they may resist making those changes.

Non-embedded engineers also write firmware! You non-embedded developers essentially write firmware whenever you bury SQL in your code or when you spread platform dependencies throughout your code.

In The Mythical Man-Month, Fred Brooks suggests we “plan to throw one away.”

Programmers, embedded or not, who just concern themselves with getting their app to work are doing their products and employers a disservice. There is much more to programming than just getting an app to work.

If the target is the only place where testing is possible, the target-hardware bottleneck will slow you down.

Many data access frameworks allow database rows and tables to be passed around the system as objects. Allowing this is an architectural error. It couples the use cases, business rules, and in some cases even the UI to the relational structure of the data.

The organizational structure of data, the data model, is architecturally significant. The technologies and systems that move data on and off a rotating magnetic surface are not.

The web is just the latest in a series of oscillations that our industry has gone through since the 1960s. These oscillations move back and forth between putting all the computer power in central servers and putting all computer power out at the terminals.

Think about it this way: The WEB is an IO device. In the 1960s, we learned the value of writing applications that were device independent. The motivation for that independence has not changed. The web is not an exception to that rule.

If the framework wants you to derive your business objects from its base classes, say no! Derive proxies instead, and keep those proxies in components that are plugins to your business rules.

USE CASE ANALYSIS Figure 33.1 shows a typical use-case analysis.

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.

Also notice that the using relationships (open arrows) point with the flow of control, and that the inheritance relationships (closed arrows) point against the flow of control. This depicts our use of the Open–Closed Principle to make sure that the dependencies flow in the right direction, and that changes to low-level details do not ripple upward to affect high-level policies.

as Uncle Bob has already said, a layered architecture doesn’t scream anything about the business domain. Put the code for two layered architectures, from two very different business domains, side by side and they will likely look eerily similar: web, services, and repositories.

Uncle Bob presented his definition of “component” earlier in the book, saying: Components are the units of deployment. They are the smallest entities that can be deployed as part of a system.

My definition of a component is slightly different: “A grouping of related functionality behind a nice clean interface, which resides inside an execution environment like an application.”

Looking at this issue another way, if you make all types in your Java application public, the packages are simply an organization mechanism (a grouping, like folders), rather than being used for encapsulation.

your best design intentions can be destroyed in a flash if you don’t consider the intricacies of the implementation strategy.

You can’t make a reusable framework until you first make a usable framework. Reusable frameworks require that you build them in concert with several reusing applications.

# 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;
}

# Flow: A Psicologia do Alto Desempenho e da Felicidade (Flow: The Psychology of Optimal Experience, Mihaly Csikszentmihalyi, 2020)

Sem mais o que ler, estou pegando agora a versão em português que eu adquiri por ter me arrependido de ter comprado um livro muito ruim de gastronomia chamado Um Químico na Cozinha. Estou tentando criar recortes minimalistas que dão uma visão ligeiramente diferente das minhas primeiras leituras em inglês. Esta edição da Amazon diz que é "revista e atualizada" e seu título tristemente vira um chamariz para a crescente onda de produtividade, que tem por objetivo transformar seres humanos pensantes em máquinas de gerar output, e não justamente o contrário pregado por Csikszentmihalyi, onde o trabalho e o lazer deveriam ser moldados a serviço do flow.

Quando as pessoas tentam alcançar a felicidade por conta própria, sem a ajuda de uma fé, em geral procuram maximizar prazeres que estão biologicamente programados em seus genes ou que sejam vistos como atraentes pela sociedade em que vivem.

Mas a qualidade de vida não pode ser melhorada dessa maneira. Só o controle direto da experiência, a capacidade de apreciar momento a momento tudo o que fazemos, pode superar os obstáculos para a realização pessoal.

O principal motivo de ser tão difícil conquistar a felicidade é que o universo não foi projetado levando o conforto dos seres humanos em consideração.

Como escreveu J. S. Mill: “Nenhum grande aperfeiçoamento da humanidade como um todo é possível até que uma grande mudança tenha lugar na constituição fundamental de seu modo de pensar”.

Quando as pessoas começam a acreditar que o progresso é inevitável e a vida é fácil, podem rapidamente perder a coragem e a determinação aos primeiros sinais de adversidade.

Somos meras partículas de poeira esquecidas vagando pelo vácuo. A cada ano que passa, o caos do universo físico é ampliado na mente coletiva.

A essência da socialização é tornar as pessoas dependentes de controles sociais, fazer com que reajam previsivelmente a recompensas e punições.

Praticamente todo desejo que se tornou parte da natureza humana, da sexualidade à agressão, da aspiração por segurança a uma receptividade à mudança, foi explorado como fonte de controle social por políticos, igrejas, corporações e publicitários.

Alguém incapaz de ignorar suas instruções genéticas quando necessário está sempre vulnerável.

O passo mais importante para se emancipar dos controles sociais é a capacidade de a todo momento encontrar recompensas nos eventos.

Uma vez que, até onde nos diz respeito, nossa experiência é a realidade, podemos transformá-la na medida em que influenciarmos o que acontece no consciente e, desse modo, nos libertar das ameaças e seduções do mundo externo.

O progresso é relativamente rápido em áreas que aplicam conhecimento ao mundo material, como física ou genética. Mas é dolorosamente lento quando a aplicação do conhecimento visa modificar nossos hábitos e desejos.

O controle da consciência não pode ser institucionalizado. Assim que passa a integrar um conjunto de regras e normas sociais, ele deixa de ser eficaz do modo como originalmente se pretendera.

Uma pessoa pode ficar feliz, ou sofrer terrivelmente, independente do que esteja ocorrendo do lado de “fora”, apenas mudando o conteúdo da consciência.

Os eventos que constituem a consciência — as “coisas” que vemos, sentimos, pensamos e desejamos — são uma informação que podemos manipular e usar.

Embora acreditemos que existem “coisas” fora da consciência, temos evidência direta apenas das que encontram um lugar nela.

Alguém com fome não tem consciência da taxa de glicose em sua corrente sanguínea; sabe apenas da existência de um bit de informação em sua consciência que aprendeu a identificar como “fome”.

Há um limite para a quantidade de “eventos” que podem aparecer no consciente e ser admitidos e absorvidos apropriadamente antes de eles começarem a se amontoar.

Logo, a informação que admitimos na consciência se torna extremamente importante; ela é, de fato, o que determina o conteúdo e a qualidade de vida.

É a atenção que seleciona os bits de informação relevantes dentre os milhões de bits potenciais disponíveis.

A marca de uma pessoa no controle da consciência é sua capacidade de focar a atenção quando bem entender, permanecer alheia às distrações e concentrar-se pelo tempo que for necessário, e nem um pouco além, para atingir uma meta.

A atenção é como uma energia, na medida em que sem ela nenhum trabalho pode ser realizado, e ao fazer um trabalho ela é dissipada.

A atenção modela o self e é por sua vez modelada por ele.

Uma das principais forças a afetar adversamente a consciência é a desordem psíquica — ou seja, informação em conflito com as intenções existentes ou que nos distraia e nos impeça de concretizá-las.

O padrão básico é sempre o mesmo: certa informação conflitante com as metas do indivíduo surge na consciência. Dependendo da centralidade do self e da gravidade da ameaça a ele, determinada quantidade de atenção deverá ser mobilizada para eliminar o perigo, deixando menos atenção livre para lidar com outras questões.

Mas o self não é uma unidade de informação qualquer. Na verdade, contém tudo o mais que passa pela consciência: todos os desejos, memórias, ações, prazeres e dores estão incluídos ali. E, mais do que tudo, o self representa a hierarquia de metas que construímos, parte por parte, ao longo dos anos.

As intenções que herdamos ou adquirimos são organizadas em hierarquias de metas, que especificam a ordem de precedência entre elas.

Sempre que a informação perturba a consciência ameaçando suas metas, ficamos numa condição de desordem interior, ou de entropia psíquica, uma desorganização do self que prejudica sua eficiência.

Toda informação que processamos é avaliada por sua influência sobre o self.

Quando a informação que continua a chegar à consciência está de acordo com as metas, a energia psíquica flui naturalmente.

Em flow, estamos constantemente no controle de nossa energia psíquica e tudo o que fazemos adiciona ordem à consciência.

Quando escolhemos uma meta e nos empenhamos nela no limite de nossa concentração, apreciamos qualquer coisa que fazemos.

Mas se a pessoa se torna complacente demais, sentindo que a energia psíquica investida em novas direções é um desperdício a menos que haja boas chances de colher uma recompensa extrínseca, pode acabar deixando de apreciar a vida, e o prazer se torna a única fonte de experiência positiva.

A fruição surge na fronteira entre o tédio e a ansiedade, quando os desafios estão em equilíbrio preciso com a capacidade de agir da pessoa.

Quase qualquer tipo de feedback pode ser apreciado, contanto que esteja logicamente relacionado a uma meta em que a pessoa investiu energia psíquica.

A preocupação com o self consome a energia psíquica porque na vida cotidiana muitas vezes nos sentimos ameaçados.

E, ao que parece, apreciamos bastante esquecer temporariamente quem somos.

Esse sistema extrai sua forma das regras da atividade, e sua energia deriva da atenção pessoal.

Na melhor das hipóteses, o self daquele que acredita em um sistema se parece com um cristal: forte e simétrico, mas de crescimento muito lento.

O elemento principal de uma experiência ótima é que ela é um fim em si.

Uma pessoa não consegue fazer a mesma coisa no mesmo nível por muito tempo.

Um lazer que necessite de recursos externos, porém, muitas vezes demanda menos atenção e, por consequência, de modo geral proporciona menos recompensas memoráveis.

Dentre os grandes métodos orientais de treinar o corpo, um dos mais antigos e difundidos é o conjunto de práticas conhecidas como hataioga.

Renunciar ao self com seus instintos, hábitos e desejos é um ato tão pouco natural que só alguém no supremo controle consegue fazê-lo.

A desconfiança puritana em relação à fruição se baseia no temor justificado de que, após experimentar algo que estão geneticamente programadas para desejar, as pessoas vão querer mais e deixarão de lado as rotinas necessárias da vida cotidiana para satisfazer seus anseios.

O corpo é como uma sonda equipada com aparelhos sensíveis extraindo toda informação possível das profundezas do espaço. É por intermédio dele que nos relacionamos uns com os outros e com o resto do mundo. Embora essa ligação possa ser bastante óbvia, tendemos a esquecer como usufruir dela.

Em sistemas simbólicos, a “ação” fica em geral restrita à manipulação mental dos conceitos.

Contrariamente ao que tendemos a presumir, o estado normal da mente é o caos.

Em geral não percebemos como temos pouco controle sobre a mente, porque os hábitos canalizam a energia psíquica tão bem que os pensamentos parecem se suceder sem empecilhos.

A entropia é o estado normal da consciência — condição que não é útil nem prazerosa.

Todas as formas de flow mental dependem da memória, direta ou indiretamente.

Outras charadas que os druidas e menestréis memorizavam eram muito mais longas e complexas e continham importantes conhecimentos tradicionais disfarçados como versos engenhosos. Robert Graves, por exemplo, achava que os antigos sábios irlandeses e galeses armazenavam seu conhecimento em poemas que eram fáceis de lembrar. Muitas vezes, eles usavam códigos secretos elaborados, como quando os nomes das árvores faziam as vezes de letras e as iniciais de uma lista de árvores formavam palavras. Veja os versos 67 a 70 da Batalha das árvores, um estranho poema longo de antigos menestréis galeses, por exemplo: Os alnos na dianteira iniciaram a contenda. O salgueiro e a sorveira chegaram tarde às fileiras. Eles codificavam as letras F (que no alfabeto druídico secreto era representada pelo alno), S (salgueiro) e L (sorveira). Desse modo, os poucos druidas que sabiam usar letras podiam cantar ostensivamente uma música sobre uma batalha entre as árvores da floresta, mas que na verdade transmitia uma mensagem que só os iniciados podiam interpretar.

A mente é muito mais rica com um conteúdo estável do que sem.

Enquanto outros necessitam de estímulos externos — tv, leitura, conversa ou drogas — para impedir a mente de se perder no caos, uma pessoa cuja memória está estocada com padrões de informação é autônoma e autocontida.

O sistema de ordenação mais simples é dar nomes às coisas — inventar palavras para transformar eventos discretos em categorias universais.

Pessoas sem um sistema simbólico internalizado podem ficar cativas da mídia.

As ideologias utilitárias dos últimos dois séculos nos convenceram de que o principal propósito de conversar é transmitir informação útil.

Quanto mais um trabalho se parece inerentemente a um jogo — com variedade, desafios adequados e flexíveis, metas claras e feedback imediato —, maior a fruição, independente do nível de desenvolvimento de quem o realiza.

Como esses resultados sugerem, a apatia de muitas pessoas não se deve a um esgotamento físico ou mental. O problema parece residir antes na relação do trabalhador moderno com o emprego, com o modo como percebe suas metas em relação ao trabalho.

A experiência do flow resultante do uso de habilidades leva ao crescimento; o entretenimento passivo não leva a lugar algum. Coletivamente, desperdiçamos todo ano o equivalente a milhões de anos de consciência humana.

Estudos sobre o flow demonstraram repetidas vezes que, mais do que qualquer outra coisa, a qualidade de vida depende de dois fatores: como percebemos o trabalho e nossas relações com outras pessoas.

(...) uma situação social tem o potencial de ser transformada, redefinindo-se suas regras. (...) as relações humanas são maleáveis, e se uma pessoa tem as habilidades adequadas, suas regras podem ser transformadas.

Em essência, manter a ordem na mente de dentro para fora é muito difícil. Necessitamos de metas, estímulo e feedback externos para manter a atenção direcionada.

Sob a influência de substâncias químicas, o self fica aliviado da responsabilidade de direcionar sua energia psíquica;

Até a dor é melhor do que o caos que penetra na mente não focada.

Quando a cultura por qualquer motivo deixa de sustentar hedonistas improdutivos, os viciados em prazer, carecendo de habilidades e disciplina e portanto incapazes de se virar sozinhos, ficam perdidos e desamparados.

Para proporcionar flow, a família precisa ter metas de existência. Motivos extrínsecos não são suficientes.

Enquanto a família oferece principalmente proteção emocional, amizades em geral envolvem uma novidade misteriosa.

No antigo costume grego, “política” se referia a qualquer coisa que envolvesse indivíduos em assuntos que fossem além do bem-estar pessoal e familiar.

O que conta é definir uma meta, concentrar a energia psíquica, prestar atenção no feedback e assegurar que o desafio seja adequado à habilidade. Mais cedo ou mais tarde, a interação entrará em sintonia e a experiência do flow ocorrerá.

Nos últimos séculos, a racionalidade econômica foi tão bem-sucedida que passamos a aceitar com naturalidade que o “sentido” de todo esforço humano é mensurável em dólares e centavos. Mas uma abordagem exclusivamente econômica da vida é profundamente irracional; o verdadeiro sentido consiste na qualidade e na complexidade da experiência.

A experiência subjetiva não é apenas uma das dimensões da vida — é a vida em si.

Por que alguns ficam debilitados com o estresse enquanto outros extraem força disso? A resposta é simples: os que sabem como transformar uma situação desesperadora em uma nova atividade de flow que possa ser controlada conseguem apreciar a experiência e emergem da provação mais fortes. Parece haver três passos principais envolvidos nessas transformações:

Quem sabe tirar proveito do desafio do estresse passa bem menos tempo pensando em si mesmo. Não gasta toda a energia tentando satisfazer o que acredita que sejam suas necessidades nem se preocupando com desejos socialmente condicionados.

Uma postura aberta possibilita à pessoa ser objetiva, tomar ciência das alternativas, sentir-se parte do mundo circundante.

Viver exclusivamente segundo instruções genéticas e sociais não é um problema enquanto tudo vai bem.

O “self autotélico” facilmente traduz ameaças potenciais em desafios que podemos apreciar, e desse modo mantém a harmonia interna.

Para uma pessoa autotélica, as metas primárias emergem da experiência avaliada na consciência e, portanto, do self em si. O self autotélico transforma a experiência potencialmente entrópica em flow.

Uma das diferenças básicas entre a pessoa que tem e a que não tem um self autotélico é que a primeira sabe que a escolha da meta foi feita por ela própria.

Ficar distraído contra a vontade é o sinal mais seguro de que você não está no controle.

As mesmas armadilhas ameaçam qualquer um que participe de um sistema complexo: para permanecer nele, deve-se continuar a investir energia psíquica.

Ter um self autotélico implica capacidade de envolvimento contínuo.

Estar no controle da mente significa que literalmente qualquer coisa pode ser fonte de satisfação. Sentir a brisa num dia quente, ver uma nuvem refletida na fachada de vidro de um prédio, fechar um negócio, ver uma criança brincar com um filhote de cachorro, beber um copo d’água — tudo pode ser percebido como experiências profundamente gratificantes que enriquecem a vida da pessoa.

Quem está em harmonia independente do que faça, independente do que aconteça a sua volta, sabe que sua energia psíquica não está sendo desperdiçada com dúvidas, arrependimentos, culpa e medo, e sim sendo bem empregada.

Propósito, resolução e harmonia unificam a vida e dão significado a ela, transformando-a numa experiência de flow perfeitamente consistente.

Mas a consequência inevitável das escolhas igualmente atraentes é a incerteza de propósito; a incerteza, por sua vez, sabota a determinação, e a falta de determinação acaba desvalorizando a escolha.

Não mais governada pelos instintos e reflexos, a mente é dotada da bênção duvidosa da escolha.

Dante percebera que todo o sistema de ordem espiritual, quando incorporado a uma estrutura terrena como uma igreja organizada, começa a sofrer os efeitos da entropia. Assim, para extrair significado de um sistema de crenças, a pessoa deve primeiro comparar as informações contidas nela com sua experiência concreta, então guardar para si o que faz sentido e rejeitar o resto.

# 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