diff options
Diffstat (limited to 'tutoriais')
| -rw-r--r-- | tutoriais/makefiles.md | 116 | ||||
| -rw-r--r-- | tutoriais/orientacao-a-objetos.md | 88 | ||||
| -rw-r--r-- | tutoriais/posts.csv | 2 |
3 files changed, 206 insertions, 0 deletions
diff --git a/tutoriais/makefiles.md b/tutoriais/makefiles.md new file mode 100644 index 0000000..35d8921 --- /dev/null +++ b/tutoriais/makefiles.md @@ -0,0 +1,116 @@ +# Como dev, como você dev pensar? +## _Ou como usar makefiles...?_ + +Já vou começando dando um spoiler: _foque no que quer chegar, +não em como chegar_. + +Todo objeto que você quer construir tem o seu propósito, seja um HTML, +um programa nativo ou qualquer coisa. Quando você começa a analisar o +propósito daquilo que você quer construir, você sempre chega nas melhores +descrições do que quer fazer. _Descrição_ é uma palavra chave aqui. + +Se você quer construir um HTML para um blog ou um site, você faz o mais óbvio +pra construir o seu HTML: um bloco de notas, e um HTML. Pronto. Se precisar +fazer outra página, você só dá um ctrl-c/ctrl-v. Até aqui, está tudo certo, +não tem muito o que pensar. Mas agora vamos dizer que você queira fazer +uma mudança na estruturação do seu HTML, talvez adicionar uma header, footer, +um css. Agora essas mudanças precisam ser replicadas manualmente em cada HTML +que você criou. + +Mas temos um computador, podemos automatizar isso, não? Se todas as páginas +terão a mesma base, porquê não dizemos ao computador: construa esse HTML pra mim +usando esses pedaços? E não precisa ser algo grande. + +<pre style="font-family:monospace;color: rgb(68, 68, 68); background-color: rgb(243, 243, 243); font-weight: 400; "><span style="color: rgb(136, 0, 0); font-weight: 700;">index.html: header.html.part index.html.part footer.html.part</span> + cat header.html.part index.html.part footer.html.part > index.html</pre> + +E salvamos isso em um arquivo chamado `Makefile` pra que o programa `make` +leia isso pra nós e crie o index.html pra gente. A primeira linha contém o que +nós queremos (index.html) e o que vamos usar pra construir o que queremos. +Logo abaixo, e identado **com tabs**, o comando que queremos executar pra cada +um dos htmls que queremos fazer. + +Com isso, chegamos no conceito de "fonte". +Você pode entender a fonte como fonte de um recurso que um programa precisa pra +construir algo para nós, nós estamos passando o que queremos e os requisitos +para a construção do que queremos. Perceba que nós ainda queremos o HTML +completo, mas agora melhoramos a _descrição_ do nosso HTML para nós focarmos +apenas naquilo que é necessário: um HTML é construído com header, footer e o +nosso conteúdo. Agora podemos só editar o conteúdo, ou a header, ou a footer, +e todo HTML conterá as mudanças que queremos. + +Então fazemos isso para cada arquivo que criamos. + +<pre style="font-family:monospace;color: rgb(68, 68, 68); background-color: rgb(243, 243, 243); font-weight: 400; "><span style="color: rgb(136, 0, 0); font-weight: 700;">index.html: header.html.part index.html.part footer.html.part</span> + cat header.html.part index.html.part footer.html.part > index.html + +<span style="color: rgb(136, 0, 0); font-weight: 700;">about.html: header.html.part about.html.part footer.html.part</span> + cat header.html.part about.html.part footer.html.part > about.html</pre> + +Mas estamos no tema de automação usando o computador, não? Ok que reduzimos +bastante a quantidade de mudanças manuais que precisariamos fazer, mas podemos +ir um pouco além disso. + +<pre style="font-family:monospace;color: rgb(68, 68, 68); background-color: rgb(243, 243, 243); font-weight: 400; "><span style="color: rgb(136, 0, 0); font-weight: 700;">%.html: header.phtml %.phtml footer.phtml</span> + cat <span style="color: rgb(171, 86, 86); font-weight: 400;">$^</span> > <span style="color: rgb(171, 86, 86); font-weight: 400;">$@</span> +</pre> + +Agora os arquivos deverão ter uma extensão diferente porque o Makefile se +confunde um pouco se usarmos o jeito anterior, porém agora o `make` vai tentar +a executar essa regra para todo *.html que for requisitado. O `$^` significa +todos os requisitos, em ordem que foram declarados, e o <span>$@</span> +significa o nome da output, para fins de tornar essa regra mais genérica. + +Com isso, estabelecemos um padrão para o nosso projeto. Todo HTML é construído +seguindo essa regra: existe um header.phtml, um outro .phtml com a mesmo nome, +e footer.phtml. E não só isso, como ainda podemos prosseguir adicionando mais +regras, e ainda regras sobre arquivos que existem. + +<pre style="font-family:monospace;color: rgb(68, 68, 68); background-color: rgb(243, 243, 243); font-weight: 400; "><span style="color: rgb(136, 0, 0); font-weight: 700;">%.html: header.phtml %.phtml footer.phtml</span> + cat <span style="color: rgb(171, 86, 86); font-weight: 400;">$^</span> > <span style="color: rgb(171, 86, 86); font-weight: 400;">$@</span> + +<span style="color: rgb(136, 0, 0); font-weight: 700;">%.phtml: %.md</span> + markdown < <span style="color: rgb(171, 86, 86); font-weight: 400;">$<</span> > <span style="color: rgb(171, 86, 86); font-weight: 400;">$@</span></pre> + +Agora toda vez que um phtml não existir, ele vai tentar criar a partir de um +arquivo markdown. + +Note o que estamos fazendo aqui: nós queremos um arquivo html. Não é o phtml, +não é o markdown, e sim o html final. Os phtmls e os arquivos markdowns são +apenas formas de se chegar no html. E cada vez que adicionamos mais uma camada +de dependência e regras de resolução de dependência, estamos aumentando a +capacidade de descrever o resultado final que queremos. + +O mesmo vale para o seu programa e na arquitetura do seu programa. Quanto mais +você consegue descrever sobre o seu programa, mais você irá notar componentes, +partes que se mantém estáveis, padrões, testes e outras coisas, e notar que essas +coisas existem irá tornar o seu programa mais simples de desenvolver, ou +pelo menos você irá fazer menos cagadas, afinal: você vai estar entendendo o +seu programa. + +Por fim, note que isso resulta em um grafo, mais especificamente uma árvore: + + index.html + | + +--- header.phtml + +--- footer.phtml + +--- index.phtml + + about.html + | + +--- header.phtml + +--- footer.phtml + +--- about.phtml + | + + --- about.md + +Ao notar essa árvore, perceba que nós não só podemos notar padrões mas agora +podemos planejar o que devemos fazer para resolver todos os problemas de forma +geral. + +As conexões também são pontos de resolução de problemas. Perceba aqui que o +`make` é um programa que nós já tinhamos em mãos para resolver as dependências +mas mesmo esses programas precisam de outros pra transformar "simbolos em +outros simbolos". Então não tenha medo de fazer _código que escreve código_, o +seu trabalho sempre foi resolver problemas usando o computador, inclusive os +seus próprios problemas. diff --git a/tutoriais/orientacao-a-objetos.md b/tutoriais/orientacao-a-objetos.md new file mode 100644 index 0000000..b5121c0 --- /dev/null +++ b/tutoriais/orientacao-a-objetos.md @@ -0,0 +1,88 @@ +# Eu tenho certeza que você, um sênior, não sabe o que é orientação à objetos + +Sabe esse paradigma que aprendemos na faculdade? Os vários macetes, os +famigerados "Padrões de Projeto", o `sujeito.verbo(objeto)` e merdas assim? +Pois é, tá errado. Pelo menos de acordo com Alan Kay, porque Alan Kay não quis +dizer nada disso. + +O negócio é que existem duas "escolas" de orientação à objetos. Uma que veio do +Alan Kay originalmente, e a outra que veio do Simula e que foi mais ou menos +raptado pelo Bjarne Strousturp, o criador do C++, e que veio a ser base do Java +e outras linguagens ditas "orientadas à objetos". Então aqui vou tentar ensinar +sobre o que o Alan Kay realmente quis dizer com orientação à objetos. + +Antes eu quero que você saiba que o _Alan Kay não quis se focar nos objetos._ +Ele até chegou a pedir desculpas por chamar isso de "Orientação a Objetos" +porque isso confundiu muita gente, porém dá pra explicar a orientação a objetos +com um padrão que você já deve ter usado a bastante tempo. Na verdade, se você +quer um TL;DR disso tudo, você pode resumir o que Alan Kay quis dizer à +"Injeção de Dependência embebido com mijo de Chuck Norris", e até a linguagem +que é realmente "Orientada à Objetos", o Smalltalk, tem seus pontos parecidos +com os da programação funcional. Irei usar um pseudo-código parecido com Java +para demonstrar. + +Vejamos esse código aqui: + + shape.getDimensions().getX() + +Isso seria um código bem comum de ver em orientação a objetos, mas qual é a +interpretação que o Alan Kay teria sobre esse trecho? + +O `shape` é um objeto e, como objeto, ele recebe e responde à mensagens, no +caso, shape recebeu a mensagem `getDimensions` sem parâmetros. `shape` +reconhece essa mensagem e dessa mensagem responde com um outro objeto. Então +enviamos `getX` sem parâmetros, e esse objeto pode ou não responder a essa +mensagem. O Alan Kay estava se focando nesse modelo de envio de mensagens e não +no modelo atual de classes. Inclusive quando Alan Kay falou de hierarquias ele +não tava falando de "extensão" de classes como vemos em Java e sim que uma +classe `Foo` responde as mesmas mensagens da classe `Base`. + +Em outras palavras: **A CLASSE NÃO IMPORTA, O QUE IMPORTA É A INTERFACE!** O +que importa é se o `shape` reconhece `getDimensions`, inclusive tem um nome pra +isso, `Duck Typing`: se anda igual pato e quacka igual um pato, é um pato. A +classe, nessa visão, é só uma forma de construir objetos. + +Isso torna umas coisas um pouco mais interessantes. Vejamos esse trecho +de código. + + + fn foo(thing) { + thing.isTrue(() -> { + doThing(thing) + }) + } + +O que `thing` é? Não sei, só sei que `foo` precisa que `thing` reconheça +`isTrue` com um parâmetro de lambda qualquer coisa que o `doThing` reconheça. +Isso torna o `foo` extremamente reaproveitável e é com essa parte que o Alan +Kay quis dizer com "reaproveitamento de código", e agora você entende o porquê +que muitos javeiros adotaram o padrão de fazer getter e setter pra tudo, porque +isso faz uma função depender de uma interface ao invés de uma implementação e +isso faz a função ficar mais reaproveitável (mas vamos ser sinceros, 99% dos +javeiros nem sabem disso, eles só fazem isso porque disseram que sim pra eles, +e nem mesmo Alan Kay gosta dos getters and setters porque as mensagens eram pra +*mandar* no objeto e não *pedir* ao objeto). + +E perceba que eu usei lambda ao invés de ser algo mais procedural, como +`if`/`else`. Isso é porque a orientação a objetos realmente preza em tornar +todo código o mais reaproveitável possível e, ao usar `if`s, como o Java faria, +você torna o seu código um pouco mais rígido ao depender de uma implementação +de uma boolean. OOP do Alan Kay preza tanto por isso que esse mesmo exemplo +ficaria assim em Smalltalk (pelo menos, "aproximadamente" Smalltalk): + + foo: object [ + object ifTrue: [ + self doThing: object + ] + ] + +Não existe `if`/`else` em Smalltalk. E booleans não são tipos primitivos e sim +objetos. Integer, Strings, tudo é um objeto legítimo, com a sua lista de +mensagens que eles devem responder, e é aqui que a "Injeção de Dependência com +mijo de Chuck Norris" se apresenta. E de certa forma, é como nossos servidores +HTTP funcionam. Você não precisa saber se o servidor é feito em Java, C#, PHP, +feito com Spring Boot, Laravel ou algum outro framework. Você só precisa saber +se o servidor responde por um `POST /foo/bar`. + +Isso é orientação à objetos. O resto é só putaria tirada da bunda do +Strousturp. diff --git a/tutoriais/posts.csv b/tutoriais/posts.csv new file mode 100644 index 0000000..8a86ba7 --- /dev/null +++ b/tutoriais/posts.csv @@ -0,0 +1,2 @@ +Eu tenho certeza que você, um sênior, não sabe o que é orientação à objetos|orientacao-a-objetos.html|Mon, 15 Jun 2026 18:20:28 -0300 +Como dev, como você dev pensar?|makefiles.html|Mon, 15 Jun 2026 11:59:51 -0300 |