porcellis.com

diff --git a/content/blog/sobre-software-duravel.en.md b/content/blog/sobre-software-duravel.en.md
new file mode 100644
index 0000000000000000000000000000000000000000..42ae295cc79574a2a37565f17952d68ce31eecc9
--- /dev/null
+++ b/content/blog/sobre-software-duravel.en.md
@@ -0,0 +1,112 @@
+---
+title: "Regarding Reliable Software"
+date: 2021-03-29
+---
+
+I spend at least 8h of my day writing code, watching a text editor and some
+terminals. Thinking about data structures, thinking about how to efficiently
+store data, and how to teach my computer (or others) to do things that I don't
+want to have to do manually, because the computer is more trustworthy than me
+at certain tasks. It can calculate faster, remember things for a longer
+period of time, it can talk to people faster than I would ever be able to, and I
+delegate many of these tasks to it. But I _can't trust_ it.
+
+We live in a time where trust in a computer is normal, and even _expected_. It's
+expected that I utilize them to check my bank account balance, to find a ride
+home, or to guide me to new places. It's expected that I share my personal data
+with them and trust that its being kept somewhere safe. I trust that they will
+deliver the internet service I have purchased, that my fire alarm will warn me
+in time, so on and so forth.
+
+The most direct means by which we can influence these problems is by writing
+software. Having done just that every day for at least the last six years, it
+stuns me every time someone says that they trust software to, or even wishes
+that it would control or influence more of their lives. People who write the
+code you use can and do make mistakes, leaving doors open and letting bugs slip
+in. I know because I make these mistakes, and work with people that make these
+mistakes, every day.
+
+The maxim that "all software breaks" is the status quo. And of course, even in
+environments where there's deliberate software quality assurance, be it via
+automatized tests, manual testing, or internal and/or open source code review,
+bugs still slip into production. New vulnerabilities arise everyday in software,
+even in code that has been in use for [15 years][codigo-linux]. It doesn't
+prevent ["autonomous" cars from killing people][uber]. It doesn't prevent
+massive breaches from exposing users data, be that entity
+[public][vazamento-cpf] or [private][been-pwned].
+
+[uber]: https://www.nbcnews.com/tech/tech-news/self-driving-uber-car-hit-killed-woman-did-not-recognize-n1079281
+[codigo-linux]: https://securityaffairs.co/wordpress/115565/security/linux-kernel-flaws.html
+[been-pwned]: https://haveibeenpwned.com/
+[vazamento-cpf]: https://www.zdnet.com/article/brazilian-government-urged-to-protect-consumers-from-massive-data-leak/
+
+I keep these ideas in mind when thinking about my own projects. When I write
+code for a company, I have little decision-making power regarding these matters,
+which is evident in the fact that we use MongoDB as a relational database
+because it was hot and new at the time. But, for my own work, I make different
+choices. I prefer reliable software, for obvious reasons; upgradable hardware,
+even if it's older; strongly typed languages which can pre-empt my mistakes; and
+whichever database is appropriate for the task, not the job listing. If my
+software works, and it works for a long period of time, I need a good goddamn
+reason to change it.
+
+Change is a part of software development lifecycle, and must be managed
+appropriately. Most of the time, I argue that the best management is no change
+at all. But, change demands reason - they need to have a real provocative need,
+or else they just accumulate in a pile of new problems that they inveitably
+bring along.
+
+One of these poor motivators, in my observation, it the desire to fit universal
+solutions into software that should instead address a specific domain.
+Complexity grows exponentially when a certain project does not have a fixed
+scope and does not draw a line regarding how much it can expand to and
+accomodate every little problem and specific need of its users.
+
+[i3][i3wm], the window manager that I use, reached a mature state where it looks
+like it's stagnated, but it just doesn't want more features, so it can focus on
+bug fixes and performance, which will eventually give the project more
+robustness and stability. You can then combine with other tools to fill a
+specific use-case.
+
+[i3wm]: https://i3wm.org/
+
+Another issue I have noticed, is the obsession with solving trivial problems
+with huge and problematic solutions. Instead of opting for the simplest path,
+picking the most overengineered one.
+
+The Ruby's [minitest][minitestrb] testing suite is a nice example of that, as it
+is small and simple. It does not try to perform magic, nor does it try to be
+smarter than the developer who uses it. It relies on the basic ruby concepts of
+classes, modules and methods. It only does what it must, in the most simplest
+and least intrusive way it can. There's no DSL, there's no huge set of
+assertation matchers.
+
+[My text editor, vim]({{< relref path="/porque-eu-uso-vim.md" lang="pt-br" >}}
+"Porque eu uso vim, ou uma reflexão sobre complexidade na tecnologia (pt-br)")
+has the same predictable behaviour for over a decade, and it's forks keep the
+same default behaviour, so I know I can hop into some random machine and know it
+will work the same way everywhere. All it has to do it's input some text unto a
+screen, If I need something else, I can customize it to fit my needs.
+
+[Weechat][weechat-client], the IRC client I have used to talk with friends [^1]
+for at least three years, runs smoothly while the slack app that I have to use
+to communicate with my work colleagues can't spend more than a hour without
+crashing, presenting some form of lag or eating half of my RAM, even though its
+main functionlity of sending and receiving real-time text messages is [a problem
+which was solved over 30 years ago][rfc-irc].
+
+So I choose reliable software: simple, auditable, performant. Even if that means
+need to sacrifice some features or somehow limiting the capability to connect or
+compose with external tools. And embedding these ideals in my life, as a
+developer means always looking with a critical eye for what it seems "easy",
+"new and shiny" solutions for old problems and always seeking to understand the
+trade-offs they bring along, which usually means to kill stability and/or
+offloading that cost as a maintenance burden and/or complexity.
+
+[rfc-irc]: https://tools.ietf.org/html/rfc2812
+[weechat-client]: https://weechat.org/
+[minitestrb]: https://github.com/seattlerb/minitest
+
+[^1]: I ended up migrating to use [slack over
+  wee-chat](https://github.com/wee-slack/wee-slack), although I long for the day
+  I don't need to use slack at all.




diff --git a/content/blog/sobre-software-duravel.md b/content/blog/sobre-software-duravel.md
new file mode 100644
index 0000000000000000000000000000000000000000..842ecdd5f7da089f1f2bcdeb283ebae5adee7dc7
--- /dev/null
+++ b/content/blog/sobre-software-duravel.md
@@ -0,0 +1,123 @@
+---
+title: "Sobre Software Durável"
+date: 2021-03-29
+draft: false
+tags: ["reflexao"]
+---
+
+Eu passo no mínimo, 8h do meu dia escrevendo código. Encarando um editor de
+texto e diversos terminais. Pensando sobre estruturas de dados, pensando sobre
+como eficientemente armazenar informações e como ensinar meu computador (ou de
+outros) a fazer coisas que eu não quero fazer manualmente, porque o computador é
+mais confiável do que eu para fazer essas coisas. Ele pode calcular mais rápido,
+lembrar coisas por mais tempo, e se comunicar mais rápido com as pessoas do que
+eu sequer imaginaria fazer, e por isso eu delego essas funções para ele. Mas eu
+não consigo _confiar nele_.
+
+Vivemos em uma era em que confiar em um computador é o normal, e é _esperado_
+que eu o faça. É esperado que eu os utilize para verificar o saldo da minha
+conta bancária, para eu conseguir um transporte para algum lugar, ou para que
+ele me guie até um lugar desconhecido. É esperado que eu informe os meus dados
+pessoais e confie que ele guarde em algum lugar seguro. Que ele me entregue a
+velocidade de internet que eu contratei, que os sensores de alarmes detectem um
+sinal de fumaça e disparem um aviso a respeito, e assim por vai em todas as
+formas que um computador existe.
+
+A forma mais direta que nós podemos influenciar esses problemas, é escrevendo
+_software_ para esses diversos computadores. E, escrevendo software todo o dia
+nos ultimos seis anos, eu fico boquiaberto quando escuto alguém dizer que confia
+e _deseja_ que esses softwares controlem ou influênciem mais a vida deles.
+Pessoas que escrevem o código que você usa podem e fazem errors, deixam portas
+abertas e deixam _bugs_ entrarem. Eu sei, porque eu faço esses errors e trabalho
+com pessoas que fazem esses errors, todo os dias.
+
+A máxima de "todo software quebra", é o _status quo_. E com certeza, mesmo em
+ambientes onde o controle de software é maior, seja ele por testes
+automatizados, _code review_ interno e aberto/público, equipe de qualidade,
+ainda assim bugs entram em produção. Vulnerabilidades são descobertas
+diariamente em software e códigos que [existem por 15 anos][codigo-linux]. Não
+previne que [carros "autônomos" atropelem pessoas][uber]. Não previne que haja
+brechas de segurança expondo dados de pessoas, seja essa uma [entidade
+pública][vazamento-cpf] ou [privada][been-pwned].
+
+[uber]: https://www.nbcnews.com/tech/tech-news/self-driving-uber-car-hit-killed-woman-did-not-recognize-n1079281
+[codigo-linux]: https://securityaffairs.co/wordpress/115565/security/linux-kernel-flaws.html
+[been-pwned]: https://haveibeenpwned.com/
+[vazamento-cpf]: https://g1.globo.com/economia/tecnologia/blog/altieres-rohr/post/2021/01/25/vazamentos-de-dados-expoem-informacoes-de-223-milhoes-de-numeros-de-cpf.ghtml
+
+Eu mantenho essas reflexões para pensar nos meus próprios projetos. Enquanto
+escrevo software para terceiros, pouco controle tenho eu a respeito das decisões
+tomadas. Entretanto eu tento incorporar esses pensamentos na minha vida. Eu
+escolho _software durável_ por razões óbvias; escolho _hardware_ antigo, mas
+_passível de melhorias/upgrades_; escolho bibliotecas estáveis ao invés _do novo
+brilho do momento_; escolho banco de dados apropriados para o problema a ser
+resolvido e não o que veio na oferta de emprego ou que está na _hype_;
+linguagens tipadas que podem me pré-avisar dos meus erros. Se meu _software_
+funciona, e funciona por um bom tempo, tem que existir um ótimo motivo para eu
+tocar nele.
+
+Mudanças é parte do ciclo de desenvolvimento de software, e deve ser gerenciada
+com sabedoria. Eu acredito que nenhuma mudança, pode ser muitas vezes a melhor
+forma de se gerenciar esse ciclo. E que mudança, demanda razão - é necessário um
+motivo procativo e real, senão apenas se acumula em uma pilha de novos problemas
+que eles inevitávelmente trazem consigo.
+
+Uma das origens desses problemas, ao meu ver, é a tentativa de encaixar soluções
+universais em _softwares_ que deveriam serem de um nicho específico.
+Complexidade cresce exponencialmente quando um determinado projeto não tem um
+escopo fixo e limitante, não desenha uma linha na areia de quão mais ele vai se
+expandir e acomodar cada problema e intenção específica de quem o usa.
+
+O [i3][i3], o gerenciador de janelas do meu sistema, alcançou um estado de
+maturidade da qual aparenta estar estagnado em seu desenvolvimento, mas apenas
+não quer incluir mais funcionalidades, buscando apenas correções de _bugs_ e
+eventualmente ganhando mais estabilidade e performance. Caso necessário, você
+pode combinar com outras ferramentas para alcançar um caso de uso específico.
+
+Outro detalhe que eu observo, é a nossa obsessão de resolver problemas triviais
+com soluções problemáticas e gigantes. Ao invés de optar pelo caminho mais curto
+e simples, escolhemos o caminho de super complicar a solução necessária,
+"encurtar caminho", fazer otimizações desnecessárias e burras.
+
+A linguagem de programação do Ruby tem uma suite de teste, o
+[minitest][minitest], que é um exemplo ótimo disso, porque ele é pequeno e
+simples. A biblioteca não tenta inventar mágica, não tenta ser mais inteligente
+que o programador que a utiliza. Para utilizar você só precisa conhecer os
+conceitos básicos da própria linguagem, como classes, metodos e módulos. Ele só
+faz o que ele foi feito pra fazer, da forma mais simples e desobstruente
+possível. Não possui uma DSL, tampouco um ramo diverso de coisas pré-prontas.
+
+[Meu editor de texto, vim]({{< relref "/porque-eu-uso-vim.md" >}} "Porque eu uso
+vim, ou uma reflexão sobre complexidade na tecnologia") se comporta da mesma
+forma há pelo menos uma década, outras derivações do projeto mantem  o mesmo
+comportamento padrão, o que significa que eu posso entrar em qualquer máquina e
+sei como utilizar. Afinal, tudo o que precisa fazer é mostrar e editar texto
+numa tela e se eu precisar de algo fora da curva, eu posso customizar da forma
+que eu achar melhor.
+
+O [weechat][weechat], o cliente que eu uso para conversar com meus amigos [^1]
+no IRC há pelo menos três anos, funciona perfeitamente, enquanto isso o
+aplicativo oficial do slack que eu preciso utilizar para conversar com meus
+colegas do trabalho não consegue passar mais de 1h sem apresentar algum
+travamento, _lag_ ou consumir boa parte da memória do meu computador, mesmo que
+o único trabalho dele, na teoria é enviar e receber mensagens em tempo real, [um
+problema solucionado há pelo menos 30 anos][rfc-irc].
+
+Então eu escolho _software_ durável: estável, simples, auditável e performático.
+Mesmo que isso signifique sacrificar funcionalidades ou ser mais "feio", ou ser
+mais limitado e precisar combinar outras soluções externas. E incorporar isso na
+minha vida, enquanto programador, significa olhar sempre com um olhar mais
+crítico para o que se apresenta como soluções únicas e universais, que brilha
+demais e se apresenta como soluções "fáceis", tentando sempre entender o valor
+de troca, que em geral significa sacrificar estabilidade e performance aos
+custos de gerar um aumento de manutenção e complexidade.
+
+[i3]: https://i3wm.org/
+[rfc-irc]: https://tools.ietf.org/html/rfc2812
+[weechat]: https://weechat.org/
+[minitest]: https://github.com/seattlerb/minitest
+
+[^1]: Inclusive, eu acabei migrando para usar o slack através da integração com
+  o weechat, com o plugin do
+  [wee-slack](https://github.com/wee-slack/wee-slack), mas eu não vejo a hora de
+  um dia não precisar mais usar o slack num geral.