Bruno Rocha
rochacbruno.com.web.brid.gy
Bruno Rocha
@rochacbruno.com.web.brid.gy
$ echo free {software,web}

[bridged from https://rochacbruno.com/ on the web: https://fed.brid.gy/web/rochacbruno.com ]
Nunca hesite em sacrificar o pedantismo em favor da clareza
Quem me conhece sabe que eu demoro pelo menos 1 hora só para introduzir um tema. Eu já aceitei que sou prolixo, falo bastante, desenvolvo meu discurso durante a apresentação de algumas ideias e isso faz com que as conversas comigo levem tempo e minhas aulas, palestras, podcasts etc. tenham no mínimo 1 hora de duração. Eu consigo tranquilamente ficar uma, ou até 2 horas, falando apenas sobre uma linha de código. É sério, tem tanta coisa para falar em um simples `print("hello world")` que é quase uma ansiedade insaciável a minha vontade de ficar falando e abordando detalhes a respeito das coisas. ## O formato esperado no discurso de um especialista Eu sempre gosto de fazer uma autoanálise, uma retrospectiva da minha participação em eventos, podcasts e aulas, e uma coisa que eu tenho percebido, não só na comunidade em geral, mas até mesmo em reuniões de trabalho, é que existe uma expectativa por um certo formato. Esse formato me parece ser uma expectativa, um ideal que as pessoas têm, uma visão predefinida de quem é especialista em um assunto. Eu, por estar em uma posição ocupando o título de "Principal Engineer" e algumas vezes "Lead Architect" no trabalho, e na comunidade por estar em uma posição de "Dev experiente" ou "Referência técnica", me parece que existe uma expectativa de que eu siga um determinado formato ao falar sobre tecnologia. Acontece que eu sou uma pessoa simples, vindo do interior, e que tenho uma certa aversão por comunicação rebuscada. E talvez seja isso que me dá prazer em ser professor, pois remover essa sofisticação é um dos trabalhos em ensinar, transformar o rebuscado em simples. E eu estou mencionando isso aqui pois acredito que muitas pessoas, ao conversar comigo, esperam um formato específico, o modo de falar de um especialista. ## A língua do especialista Quero deixar bem claro sobre o que eu estou falando. Estou tentando enfatizar que, mesmo sendo um especialista em desenvolvimento de software, com uma carreira profissional de 25 anos e estando em uma posição de liderança em uma das maiores empresas de tecnologia, eu ainda prefiro, conscientemente, manter meu vocabulário simplificado. E isso muitas vezes é mal interpretado, dá ao interlocutor uma impressão errada, coloca minha palavra em um lugar de descredibilidade, pois não entrega as respostas no formato esperado. Vou tentar dar exemplos para deixar mais claro: **Pergunta:** > Qual estratégia pode ser adotada para criar software sustentável? **Resposta no formato que é esperado de um especialista:** > Os engenheiros podem adotar princípios de código limpo, preferir arquitetura hexagonal, aplicar os conceitos de SOLID com foco na criação de interfaces com baixo acoplamento. **Minha resposta:** > Os desenvolvedores devem seguir padrões bem estabelecidos, mas não vou nomear esses padrões, pois a viabilidade deles vai variar em cada projeto. Não existe uma resposta certa, muitas vezes aplicar o padrão é inviável a depender da prioridade do seu projeto e o time-to-market. > > Portanto, os desenvolvedores devem se apegar inicialmente a abordagens simples, que não causem impacto direto no tempo de entrega, mas que podem ajudar na futura melhoria. Entre essas abordagens está criar código que é autoexplicativo, com comentários concisos, modularizar bem o código, criando muitas funções, cada uma com responsabilidade única. Ao criar essas funções, pensar em suas entradas como contextos genéricos, para que possam facilmente serem substituídas. > > Levar essas práticas para todo o restante do projeto. Ao escrever um pedaço de código, pense se pode deixar aquele código mais fácil de ser substituído e mais fácil de ser deletado. Crie código para ser integrado, refatorado e, principalmente, para ser facilmente excluído. Não se apegue ao código, o código não é a solução. Analisando a minha resposta, já se percebem 2 coisas. Primeiro, **eu evito usar termos rebuscados** e nomenclaturas que não sejam inclusivas. SOLID, por exemplo, é um conceito que eu gosto muito, mas citar SOLID sem contextualizar seria algo que iria me incomodar. Eu sei que às vezes o público-alvo já está familiarizado com o tema, mas eu geralmente me preocupo em me comunicar com a mais ampla diversidade de público. Outro ponto na **minha resposta é que ela é extensa.** Sim, eu poderia ter resumido tudo isso aí em uma única sigla, mas qual seria o ponto de fazer isso? Eu prefiro acreditar que ler, pensar e refletir não são incômodos e que uma resposta mais extensa será mais valiosa. Infelizmente, esta característica me coloca em um lugar onde a impressão é que eu seria menos especialista. Quando as pessoas ouvem especialistas, elas esperam ouvir respostas autoritativas, determinísticas e diretas, mesmo que não sejam facilmente entendíveis. Se meu discurso tiver SOLID, Clean Code, hexagonal, e eu citar algum autor ou paper, parece que virtualmente amplifica minha especialização. Mas, felizmente, eu não vou aderir a essa pressão e vou continuar preferindo explicar concorrência com a analogia da lanchonete que demora para fazer os lanches e vou continuar minha filosofia de que a única maneira de saber escrever código bom é escrevendo código ruim primeiro. ## O pedantismo Neste contexto, de dar respostas simplificadas, durante pelo menos os 15 anos que tenho sido ativo no compartilhamento de conteúdo nas comunidades, tenho repetidamente ouvido críticas de figuras que hoje eu chamo de "Pedantes de Software", "Os sabe-tudo", "Fiscal de explicação" ou simplesmente pessoas com um nível muito, mas muito alto de autoconfiança. Perdi as contas de quantas vezes alguém veio em uma live me dizer algo do tipo: "Ah, mas isso que você está explicando é o conceito SCHABLAU que foi definido pelo Fulano de tal e sua explicação está incompleta ou muito simplificada." Eu muitas vezes tenho a paciência de responder: sim, eu sei que o nome que dão a isso é SCHABLAU, mas eu preferi usar a minha liberdade e o meu próprio raciocínio para encontrar outra maneira de explicar a mesma coisa, sabe, com minhas palavras. E eu, no final, quero falar com o pedante, quero que ele seja parte do meu público-alvo, e por isso não subestimo a capacidade dele. Se ele é capaz de saber tantas siglas, livros, autores e conceitos, será que ele não é capaz de ouvir uma explicação diferente e por conta própria fazer a ligação? Às vezes fico pensando que algumas dessas pessoas, de tanto se acharem tão inteligentes, são na verdade "Inteligentes Funcionais", ou seja, só conseguem receber a mensagem se estiver formatada da maneira como foram preparadas para receber, sem flexibilidade ou espaço para interpretação. > Não hesite em sacrificar o pedantismo em favor da clareza! Essa frase original é `Never hesitate to sacrifice truth for clarity` e foi dita pelo Greg Wilson em seu guia de 10 dicas para lecionar (10 Rules for teaching, Teaching Tech Together). ## Liberdade de explicação O meu ponto aqui é manifestar minha defesa à liberdade de explicação. Eu, pessoalmente, acho lindo quando especialistas explicam as coisas de maneira fácil de entender, mesmo que para isso seja necessário sacrificar alguns pontos ou adicionar um pouco de açúcar. Eu vou creditar isso à minha adolescência que passei assistindo Telecurso 2000, Mundo de Beakman e lendo a revista Ciência Hoje, que foram meios de divulgação científica com uma abordagem muito simplificada, com foco em analogias do mundo real e contextualização dos problemas. ## Contexto É claro que tudo tem seu contexto. As pessoas precisam parar de achar que postagem em blog, conversa de podcast, papo de bar etc. é a mesma coisa que livro, artigo científico e defesa de mestrado. Existem contextos onde faz todo o sentido se adequar a nomenclaturas, referências e pedantismo científico. Mas a expectativa de que isso seja igual em ambientes mais informais é algo perigoso, algo que mata a criatividade, cria uma comunicação engessada e, além de tudo, é elitista, faz com que o conhecimento seja colocado atrás de uma barreira. ## Conclusão * Não julgue a experiência e a capacidade das pessoas pelo modo como elas se comunicam * Sempre leve em consideração o contexto, em ambientes informais não tenha expectativas formais (e vice-versa) * Seja flexível, leia, interprete, entenda que tudo tem motivação e geralmente a motivação é diferente da sua * Ao consumir um conteúdo, você não é o centro das atenções, existe um público-alvo bastante diverso * Não se apegue a siglas, autores, metodologias, tudo isso deveria ser efêmero, aprenda, avalie, recicle * Não seja o pedante, é chato! ## 10 regras para ensinar Traduzido de Teaching Tech Together * **Seja gentil:** todo o resto são detalhes. * **Lembre-se de que você não é o seu aluno…** * **…que a maioria das pessoas prefere falhar a mudar…** * **…e que 90% da “mágica” está em saber uma coisa a mais que os outros.** * **Nunca ensine sozinho.** * **Nunca hesite em sacrificar a~~verdade~~ o pedantismo em nome da clareza.** * **Transforme todo erro em uma lição.** * **Lembre-se de que nenhuma aula sobrevive ao primeiro contato com os alunos…** * **…que toda aula é curta demais para quem ensina e longa demais para quem aprende…** * **…e que ninguém vai se empolgar tanto com a aula quanto você.**
rochacbruno.com
October 29, 2025 at 5:23 PM
CDE Motif-Inspired Theme for Marmite Blog
I don't know why exactly, but I really like the retro look of old desktop environments for Unix, Solaris and Linux. Maybe it's because I spent countless hours in the late 90s having fun with systems like OpenStep, CDE, Motif, XFCE, early KDE versions, and window managers like WindowMaker, FVWM, Openbox and Fluxbox. ## The Modern Design Fatigue Recently, I started getting really tired of modern-looking design. Everything looks the same , flat, minimal, with tons of white space and those pastel gradients that seem to be everywhere. One day, while trying the NsCDE project, I realized that this kind of retro design actually made me happy! I was scrolling my mastodon feed and came across this comparison between CDE and NsCDE and I was intrigued with the idea of trying NsCDE. I have been a long time user of XFCE and I even was a contributor to the project translations back on early 2000s, then I used XFCE for a long time and migrated to i3wm and then KDE, I like KDE but to be honest sometimes I think about moving back to XFCE for its simplicity and speed, there are some features on KDE now that I got used to like Krunner and Activities that I still have to find replacements on XFCE (maybe rofi?) but I don't know about the activities (which is very different from XFCE multi workspace) ## Why Retro UI Design Works There's something about these old interfaces that just feels right. The buttons look like actual buttons you can press. The windows have clear borders. Everything has depth and texture. It's not trying to be invisible or get out of your way , it's proudly there, doing its job. I also came across "Making Linux look like Windows 98" from diinki with arguments about Windows 98-style design being more comfortable design. ## CDE The Common Desktop Environment was a collaborative effort between HP, IBM, Sun, and other UNIX vendors to create a unified desktop experience that inspired probably all the modern desktop environments we have today. From Wikipedia: > The Common Desktop Environment (CDE) is a desktop environment for Unix and OpenVMS, based on the Motif widget toolkit. It was part of the UNIX 98 Workstation Product Standard,and was for a long time the Unix desktop associated with commercial Unix workstations. It helped to influence early implementations of successor projects such as KDE and GNOME, which largely replaced CDE following the turn of the century. I also found this very fun and interestint CDE marketing video from 1996 ### Customizing KDE After my NsCDE experiments, I started customizing my KDE environment to look like CDE, and I'm absolutely loving it. Here's my desktop now: It is not exactly like CDE yet because I am not very good on Linux Ricing, I hope to get it to a point where it is close to the original CDE. Compare that to the original CDE And the modern NsCDE implementation: ### I want Motif everywhere! (or at least a CDE inspired look) Now I am really trying to get Motif inspired look & feel everywhere and sadly it looks like interfaces became so modern (not in a good way) that I am not able to find any Motif inspired themes. ### Mobile Sadly, my Xiaomi phone doesn't have a CDE-inspired theme, nor could I find a Windows 98 style for it. Modern mobile operating systems seem allergic to anything that doesn't follow the current design trends. But that gave me an idea... ## Blog If I couldn't have CDE on my phone, at least I could bring that look and feel to my blog! So I created a new theme for my Marmite static site generator, and here are the results. For this I used a reference I found on a blog that was not exactly the original CDE pallete but the colors from an alternative CDE Motif theme. ### The Color Scheme Finding the right colors was crucial. I discovered this CDE color scheme, and that was all I needed. The classic Solaris CDE colors include: * Front window border: `#b24d7a` (that distinctive mauve-pink) * Window pane background: `#aeb2c3` (the classic gray-blue) * Desktop background: `#574c8f` (that deep purple we all remember) * Accent Colors: Various blues, greens, and purples ### The Results Here's how the blog looks with the new CDE theme: The post listing with that classic CDE aesthetic: Group pages maintaining the consistent look: And even the search functionality got the retro treatment: ## Technical Implementation The theme uses authentic CDE design principles: * **3D beveled borders** on all interactive elements * **Workspace-style navigation** with clear visual hierarchy * **Motif-inspired widgets** that look like they belong in a 1994 UNIX workstation * **Classic color palette** directly from CDE specifications I tried ti recreate the inset and outset borders that gave CDE its distinctive 3D appearance, while the typography uses monosspace system fonts that would have been common on UNIX systems of that era, but also I preferred to use MS Sans Serif for some terminal elements and ATkinson Hyperlegible font for the main content. ## Create your own Blog with the CDE theme # Install marmite from git (theme support will come soon on version 0.2.7) cargo install --git https://github.com/rochacbruno/marmite.git # Start a new blog marmite myblog --init-site # Set the theme to cde marmite myblog --set-theme https://github.com/rochacbruno/marmite-cde-theme # Write a post marmite myblog --new "My first post" -t "tag1,tag2" # Render the blog marmite myblog --serve ## Why This Matters There's more to this than just nostalgia. These older interfaces were designed with different priorities, everything looks interactive because it has visual affordances, once you learn one CDE application, you know them all, dense information display without being cluttered and no ambiguity about what's clickable or what's selected. Maybe it is a sign of my age, but I am really more happy with the retro look&feel for my day to day work, For work purposed I am required to use an VSCode based editor and I was able to customize it to look like a retro editor. ## Conclusion Do you have any other retro design theme or resource to share?
rochacbruno.com
August 10, 2025 at 3:22 PM
Stop using underscore as alias for gettext
I've been using Django for a while now, and I've seen a lot of people using the underscore as an alias for gettext. from django.utils.translation import gettext as _ and also from django.utils.translation import gettext_lazy as _ This is a bad practice, I call it **" The Thousand Dollar Mistake".** ## History about this practice The practice of using underscore (`_`) as an alias for gettext comes from the GNU gettext library, which has been around since the 1990s. In C and other languages, `_()` became the de facto standard for marking strings for translation. When Python adopted gettext, this convention carried over, and Django followed suit. The underscore was chosen because it's short, unobtrusive, and doesn't clutter the code when you have many translatable strings. Important As pointed out by Osvaldo Santana on the comments there are some external tools that will expect the exact form `_()` ad those tools will statically analyse the codebase looking for the pattern `"\s_(.*.)"`, so if you use external translations tools it might be better to stick with this patten and instead put linters in place to check for reassignment of `_` ## What it does The `gettext` function (and its lazy variant `gettext_lazy`) is Django's internationalization (i18n) mechanism. It marks strings for translation and returns the translated version based on the current language setting. When you use `_("Hello")`, Django will look up "Hello" in the translation catalogs and return the appropriate translation for the active language. The lazy version defers the translation until the string is actually used, which is important for module-level code that runs before Django's language detection. ## What is the problem? This is a screenshot from a production code where I found this problem, it took me a while to spot the problem, the API was returning a 500 error, and the error was not very helpful, more people were affected by this, and it was a pain to debug. Can you spot the problem? ## Explanation The problem is that in the top of the file gettext_laxy is imported and aliased to `_`, then, later in the code the `_` is assigned to the tuple result of `organization, _ = Organization.objects.get_or_create(name="Organization")` this get_or_create returns a tuple with the object and a boolean, the boolean is not used, but the `_` is assigned to it, this is a problem because the `_` is already assigned to the gettext_lazy alias, and this is not the expected behavior. So when the `_` is used as a transaltion function it fails because booleans are not callable. ## Correct way of doing it Instead of using the underscore alias, use explicit, descriptive names: from django.utils.translation import gettext, gettext_lazy # Use the full name message = gettext("Hello, world!") lazy_message = gettext_lazy("Welcome to our site") Or, if you must use an alias, choose something more descriptive: from django.utils.translation import gettext as translate from django.utils.translation import gettext_lazy as translate_lazy # Now it's clear what's happening message = translate("Hello, world!") lazy_message = translate_lazy("Welcome to our site") This way, when someone (including future you) reads the code, they immediately understand that translation is happening, not some mysterious underscore operation that could be confused with Python's built-in `_` variable or other uses of underscore. ## Conclusion While using `_` as an alias for gettext is a widespread convention, it can lead to confusing bugs that are hard to track down. The underscore has too many meanings in Python: it's used for private attributes, as a throwaway variable in loops and unpacking, and in the REPL to reference the last result. When you add gettext to the mix, it becomes a recipe for subtle bugs. By using explicit names like `gettext` or `translate`, you make your code more readable, reduce the chance of namespace collisions, and save yourself (and your team) from debugging sessions that could cost far more than the few extra characters you type. Remember: explicit is better than implicit, and readability counts. Your future self will thank you.
rochacbruno.com
August 10, 2025 at 3:22 PM
Ensinar é sempre um ato político
Se você, assim como eu, compartilha conhecimento em vídeo, texto ou qualquer outro formato nas redes, já deve ter se perguntado se isso que a gente faz é só um “conteúdo” descartável, efemero, datado ou se tem algo mais por trás, algo maior que é produto da nossa criação de conteúdo. Eu sempre fui fascinado por ensino, técnicas de ensino, as diferentes formas que as pessoas aprendem, mesmo eu me identificando como um Engenheiro de Software, e atualmente estar me dedicando a contribuir individualmente com desenvolvimento de produtos em uma empresa, a minha paixão sempre foi o ensino e estou sempre em busca de maneiras de entender e melhorar a forma como eu ensino. Desde 2013, motivado por eventos politicos importantes, eu tenho usado meu tempo livre para ler bastante sobre filosofia, educação e política, li obras de nomes que me marcaram como o Paulo Freire, o Antonio Gramsci, Jose Pacheco, Richard Feynman, George Polya e finalmente por recomendação de uma pessoa no Mastodon eu conheci o autor Dermeval Saviani, e através do Saviani fui apresentado a tal da **Pedagogia Histórico-Crítica** , a PHC, que vou explicar brevemente. ## Eu já sabia o que era, só não sabia o nome disso E o curioso é que **eu comecei a aplicar a lógica da PHC muito antes de saber que ela existia formalmente** , eu dou aulas desde 1999, durante este tempo sempre fui questionador do ensino tradicional, eu fui um péssimo aluno na escola justamente por não gostar dos métodos de ensino. Entre idas e vindas entre atuar como professor e programador, eu fui experimentando e adquirindo uma forma meio instintiva de ensinar, um modelo que venho sempre tentanto aperfeiçoar. Só depois de muitos anos que topei com o nome do Dermeval Saviani, tudo começou a fazer sentido. Foi tipo quando você encontra um manual explicando aquilo que você já vinha fazendo meio no feeling. As peças se encaixaram. Nesse post minha intenção é mostrar **por que a PHC importa** , inclusive pra quem ensina fora da escola: seja em vídeos, blog, palestra, canal do youtube, conversa no trampo ou até trocando ideia nos grupos e comunidades. ## **Educar é mais do que ensinar uma técnica** A PHC parte de uma ideia que, pra mim faz muito sentido: **ensinar é sempre um ato político**. E não é sobre política partidária, mas sim de reconhecer que **todo ensino carrega uma intenção**. Não existe ensino neutro. Você pode estar formando alguém pra repetir, ou pra questionar. Pra obedecer, ou pra transformar. No fundo, a proposta é ensinar pra **além da técnica** , da decoreba, do "passo a passo". Ensinar pra que a pessoa compreenda **o mundo em que vive e possa agir sobre ele**. É dar contexto. É ajudar a pessoa a se localizar na realidade e pensar: beleza, entendi isso — e agora, o que eu faço com isso? No caso do ensino de programação e tecnologias, eu costumo dizer que eu não ensino **Python** , eu não ensino os estudantes a serem **programadores** , ao invés disso, eu ensino eles a serem **resolvedores de problemas** , eu ensino como usar Python para resolver esses problemas, desta forma, o Python nem é o mais importante, os conceitos ensinados através do Python passam a ser válidos em qualquer tecnologia. ## **Isso serve pra quem ensina na internet?** Muita gente que ensina na internet, ou mesmo em ambientes corporativos, acaba caindo numa lógica meio “treinamento fast-food”. Ensina a ferramenta, o comando, a receita. Mas não ajuda a pensar o **porquê** daquilo, nem o que fazer quando o caminho não é tão linear. A PHC te ajuda a montar uma estrutura de ensino que começa **no mundo real das pessoas** , passa pelos conceitos, e volta pra vida — com mais clareza, autonomia e intenção. ## **Os cinco momentos da PHC** Quando descobri os cinco momentos da Pedagogia Histórico-Crítica, percebi que eu já fazia muita coisa ali, meio no instinto. Mas conhecer a estrutura me ajudou a organizar melhor as ideias, planejar com mais intenção. São eles: 1. **Prática social (ponto de partida)** – Começar da realidade concreta. Quem é essa pessoa que vai aprender? Qual o contexto dela? Quais os problemas reais que ela enfrenta? 2. **Problematização** – Mostrar que existem limites, contradições, dúvidas. É onde a curiosidade e o incômodo aparecem. É aqui que você fisga a atenção. 3. **Instrumentalização** – Entra o conteúdo. O ferramental, os conceitos, a teoria. Mas sempre conectados com o que foi discutido antes. 4. **Catarse** – Quando a coisa encaixa. Quando a pessoa entende o conteúdo **de verdade** e sente que “agora sim, entendi o porquê disso”. 5. **Prática social (ponto de chegada)** – Voltar pro prático, para a solução do problema. Só que agora com mais capacidade de entender e agir de forma diferente. Isso vale pra ensinar programação, matemática, história, como usar uma ferramenta no trabalho, como organizar finanças… qualquer coisa. ## **Um exemplo simples** Digamos que você tá ensinando alguém a automatizar tarefas com **Python**. O caminho tradicional seria começar mostrando o que é `print()`, o que é `for`, o que é uma função. Mas na PHC, você começa diferente: “o que tá te tomando tempo no dia a dia? O que dá pra resolver com código?”. A maioria dos cursos começa dizendo o que é uma variável, o que é um if, etc. Mas na PHC, o ponto de partida seria a realidade do aluno: por que essa pessoa quer aprender Python? Onde ela poderia aplicar isso na vida real? Você parte da dor real da pessoa — processos manuais chatos, coisas que ela repete sem pensar, ou até mesmo introduzir um problema hipotético para quem está aprendendo, mesmo que o problema não seja real, situar a pessoa no problema é essencial, o ensino sempre começa a partir de um exercicio de imaginação, de hipótese. Depois você provoca: “você já parou pra pensar quanto tempo perde com isso? será que precisa ser assim? será que tem um jeito mais eficiente? Você já parou para pensar em quais seriam as alternativas para resolver este problema?” Aí sim entra o conteúdo técnico, só que agora **faz sentido** , porque responde a uma necessidade concreta. E no fim, você volta e diz: “ok, agora que você sabe isso, o que mais dá pra transformar?” ## **Não é uma fórmula engessada** Esses cinco momentos não são uma receita fechada. Não é sobre encaixar conteúdo em caixinhas. É mais uma **forma de pensar o ensino com intenção** , com propósito, com consciência do impacto que ele pode ter. Isso torna a experiência de ensinar bem mais rica — pra quem ensina e pra quem aprende, um outro exemplo que gosto de compartilhar é sobre a maneira com que construi meus treinamentos Python Base, Python Web e Python DevOps. No Python Base por exemplo, ao ensinar **Orientação a Objetos** , eu poderia ter seguido a receita tradicional e ir tópico a tópico mostrando o que é classe, o que é método, o que é encapsulamento etc. Mas essas coisas **Não fazem sentido** para quem está aprendendo a programar, ao invés disso, eu começo criando um **programa ruim** , aliás, esta é uma caracteristica dos meus treinamentos, nos começamos sempre discutindo as soluções ruins, para que depois a solução otimizada faça sentido, partindo de um problema de verdade, por exemplo, durante o curso nós criamos uma solução de gestão de dados usando apenas estruturas de dados básicas como dicionários e listas, usamos arquivos JSON como banco de dados, vira uma loucura, uma verdadeira **porcaria** 🤣. E então no decorrer deste exercicio vou pontuando os problemas, as dificuldades, ai eu provovo: "Imagina que só existisse essa forma de programar?", "Imagine se existisse um jeito melhor?". Somente depois que o problema foi situado, que eu apresento o que é **classe** , o que é **herança** , o que é **modelagem de dados** , padrões de repositório, **ORM** etc, o que a Orientação a objetos pode resolver, e então assim que está tudo ensinado e fazendo sentido na prática, eu provoco novamente! Começo a mostrar os problemas de **POO** , onde ela falha, e essa é a deixa para mostrar o paradigma funcional, que a partir de agora começa a fazer sentido real. Este mesmo modelo de **curso** , de ordem de apresentação, eu sigo no Python Web, onde começamos escrevendo um framework do zero, e enfrentando os problemas que isso causa, assim quando entramos no ensino de frameworks famosos fica muito mais claro para os estudantes o motivo das coisas serem daquele jeito. Definitivamente não é um método de ensino **express** , é um ensino que demora, eu costumo brincar que ensinar é minha **arte** e a arte não tem pressa. No Treinamento Python para DevOps eu to aplicando uma otimização a este modelo, estou tornando o formato um pouco mais rápido, mas ainda mantendo a proposta da PHC. ## **Uma pedagogia que acolhe o mundo real** Como já mencionei, eu comecei a ensinar por volta de 1999, fui adquirindo uma experiência, um senso automático de como ensinar, eu já estava ensinando desta forma faz tempo mas entender a PHC me deu mais firmeza, me fez enxergar que **o que eu fazia não era bagunçado ou “menos sério”** por não seguir os modelos tradicionais de ensino. Muito pelo contrário: tem uma pedagogia que legitima, dá base, e diz “é isso mesmo, educar é partir da realidade concreta e voltar pra ela — só que com mais ferramentas”. ## **Conclusão** Se você ensina qualquer coisa — seja num canal, num curso, no trabalho, numa conversa entre colegas — vale a pena conhecer e aplicar a lógica da Pedagogia Histórico-Crítica. Ela te ajuda a fugir do ensino automático, da técnica pela técnica. E te aproxima de algo que, na minha visão, é muito mais transformador: **ensinar pra mudar a forma como as pessoas enxergam o mundo e atuam nele**. Se quiser trocar ideia sobre isso, manda mensagem. Sempre bom conversar com quem também acredita que ensinar é mais do que transferir conhecimento — é criar sentido e motivar as pessoas. * * *
rochacbruno.com
July 5, 2025 at 3:06 PM
POSSE
Recentemente eu postei no Fediverso sobre algumas coisas que me arrependo na minha carreira profissional. E a principal que me veio a mente foi o fato de eu ter parado de escrever regularmente +- em 2014. Eu era um blogger bastante ativo, até participei de alguns desafios com o intuito de postar pelo menos uma postagem no blog a cada semana. Ja mantive alguns blogs, mas em 2014 eu decidi parar de escrever e só agora que mei conta disso e quão ruim foi essa decisão. Coincidentemente na última decada nós vimos o surgimento das midias sociais centralizadas, baseadas em engajamento e meio "sem querer" entrei nessa, afinal, mais vale um post no Linkedin, ou uma thread no twitter ou um short no Instagram ou investir no canal do Youtube, pois lá é que está o engajamento ninguém liga para o meu blog. Eu caí nessa armadilha, e você provavelmente também, e está tudo bem, ainda dá tempo de recuperar o que é nosso. ## Ninguém liga para meu blog 😔 Esse é o primeiro pensamento que devemos nos livrar, o blog não é um motor de engajamento, é um histórico, é você escrevendo sua história, ou pelo menos uma parte dela, inicialmente só você mesmo que precisa "ligar" para o seu blog, escreva para você mesmo, para no futuro você se lembrar daquele assunto ou momento, para você usar como referencia quando precisar "provar" envolvimento em um tema, para usar como bragging document etc. Não importa se ninguém vai ler! mas acredite sempre tem alguém que lê. ## Mas eu nem escrevo bem 📝 Esse é o segundo pensamento que precisamos deixar de lado, você nunca vai escrever bem se nunca escrever, este é o tipo de coisa que se adquire com prática, eu já escrevi bem, até livro eu escrevi, mas eu perdi essa pratica e agora tenho que reaprender, está sendo divertido. ## Mas eu não sei do que falar 🗣️ Terceiro ponto a vencer é esse, apenas abra um editor de texto e escreva, não precisa ser perfeito, não precisa ser técnico, não precisa ser longo, podem ser apenas anotações, coisas que vc aprendeu, lista de artigos que vc leu, lista de coisas que está estudando, qualquer coisa, mesmo que ainda não vá publicar, crie uma pasta `textos` e vá escrevendo o que vier a mente lá dentro. ## Mas eu não sei criar um blog 🧮 Comece simples, escreva em arquivos de texto, salve em um, diretório ai no seu computador, aprenda Markdown, só este processo já será divertido. Para publicar use um repositório no github, pode apenas colocar os markdowns diretamente lá ou até mesmo criar um blog e hospedar no Github Pages > — Ok, mas não vejo vantagem nisso, melhor eu publicar no medium, linkedin, dev.to, substack etc onde terá mais audiencia!? Concordo que essas redes são ótimos para panfletar, para atingir o publico, mas não caia na armadilha de produzir conteúdo para essas plataformas, apenas use elas para disseminar o seu, é a ai que entra o **POSSE**. ## POSSE 📝 POSSE é um acronimo em inglês para: **P** ublish on your **O** wn **S** ite, **S** indicate **E** verywhere, ou seja, Publique em seu Próprio Site, Distribua em todo lugar. **POSSE** é sobre `posse` mesmo, é sobre você possuir o seu conteúdo, escrever ele para você, sem pensar em um formato que agrade mais a rede X ou Y, sem pensar em engajar mais ou ganhar mais likes, é foco 100% no conteúdo do seu jeito com a sua identidade, em seu próprio site, mesmo que este site seja um simples blog estático ou um repositorio de textos. Após publicar em seu próprio site, publique o texto em todas as plataformas que desejar, seja copiando e colando integralmente o conteúdo (substack, dev.to, medium, linkedin) ou apenas distribuindo link para o conteúdo original (mastodon, bsky, instagram etc) Isso pode ser feito manualmente ou de maneira automatizada. graph TD; A[I publish an article on my own site] --> B[I syndicate the article link on micro blogs] A --> C[I copy paste the article content to other blogging platforms] ## Como começar? 🔰 Para aplicar o **POSSE** você precisa de um site e de canais para distribuir. ### Tenha o SEU site! Eu vou recomendar o Marmite pois além de ser a plataforma de blog que eu criei, é a que eu publiquei originalmente este texto que você está lendo e a que eu tenho condições de te dar algum suporte se você precisar de ajuda. Você pode começar criando seu blog automaticamente com github pages usando o Marmite 101 Ou pode começar do zero, ai nos eu computador local usando o Marmite Tutorial e depois hospedar no Github Pages ### Distribua #### Manualmente Após publicar, copie a URL do seu post e publique em todas as redes sociais de micro blog, copie o texto integral e publique também em plataformas como dev.to, substack, medium, linkedin. #### Automaticamente Não existe uma receita única para fazer isso, a parte importante é que o seu blog com Marmite tem feeds **RSS** então esses feeds podem usados para publicação automática. Federe! (essa palavra é estranha), mas significa distribuir o conteúdo no fediverso (Mastodon e afins), o Marmite conta com integração com o Hatsu, que automaticamente faz a federação dos seus posts para o fediverso. Eu criei um projeto que lê um feed e publica os novos itens no Bluesky rss2bsky A mesma estratégia pode ser usada para publicar em outras redes. ## Conclusão Existem diversas alternativas para você estar no controle do conteúdo que você gera na internet, ter o seu blog é o primiro passo, depois eu recomendo ter sua própria instância no fediverso com Mastodon ou GoToSocial. O **importante** é ter a POSSE dos seus textos.
rochacbruno.com
November 29, 2024 at 2:40 PM
Sobre expressar preferências na internet.
Tem alguns anos que fiz uma mudança significativa com relação a como expresso minhas escolhas e preferências, e foi uma mudança planejada e consciente. Eu já fui a pessoa (chata para krleo) que não perder a oportunidade de "injetar" em conversas alheias um comentário sobre como a minha escolha é excelente, melhor ou até mesmo a única que presta. Felizmente eu percebi que isso não estava sendo legal, que aqueles comentários "inocentes" movidos a empolgação nem sempre eram bem recebidos, eu percebi isso, pois passei pela experiência reversa algumas vezes, pessoas sendo incisivas em meus posts e vídeos quase que fazendo uma propaganda, agindo como influenciador forçado de algo. Eu não vou nomear todos os objetos dessas escolhas, mas podem ser, por exemplo: linguagem de programação, framework, rede social, alimentação, posição politica, sistema operacional, etc. > “Aprendi a não tentar convencer ninguém. O trabalho de convencer é uma falta de respeito, é uma tentativa de colonização do outro.” — Saramago ## Isentão? Mas veja bem, isento nunca! Continuo sendo um ser humano de opinião, tenho escolhas bem estabelecidas e sou muito empolgado com essas escolhas, e me dou o direito de mudar elas de vez em quanto. A minha mudança significativa foi apenas com relação a "onde" e "quando" eu expresso essas opiniões, e a **minha** regra é: 1. Alguém pediu minha opinião. 2. Eu sou o autor do conteúdo principal. Ou seja, deixei de "injetar" minha opinião em conteúdo alheio exceto se explicitamente o próprio conteúdo sinalize o desejo de opiniões. Canalizar minha empolgação e paixão por determinados assuntos e causas em forma de conteúdo original é muito mais relevante do que sair plugando isso em toda postagem que cite o objeto ou um objeto antagônico. ## Quando e onde se expressar? Portanto, considero que é educado eu ir a minha timeline ou meu blog e escrever coisas como: "Sejam vegetarianos", "Arch Linux é o melhor", "É tudo culpa do capitalismo", "KDE é melhor que Gnome", "Golang tem sintaxe feia", "Feijão por baixo" ... É ok por que afinal de contas é minha opinião expressada no meu espaço! Lê e interage quem quiser. ## E quando ficar calado? O que NÃO é ok, é responder uma postagem de outra pessoa do tipo "Adoro o Ubuntu", e ir lá e adicionar o comentário "Acho uma bosta, tem x problemas, o Arch sim é que é bom"... (bom, nunca fui tão idiota a esse ponto, mas vejo isso muitas vezes e é um extremo a evitar) ## Nuances Agora se a postagem original tem uma pergunta explicitamente aberta: "O que vocês acham de Golang?" ou implicitamente aberta "Python é lento d+, essa linguagem é a pior!" - Ai sim acho que é ok "injetar" uma resposta, desde que essa seja direto ao ponto. Em tempo: "Acho Golang bom mas tenho ranço da sintaxe", "Python pode ser lento, depende do caso de uso, tem cenários que eu não recomendo usar, tem outros que seu requisito de rapidez pode ser imaginário." ## Conclusão Melhor pegar a raiva, a indignação, a empolgação, a paixão e usar isso de combustível para conteúdo original e evitar sair "papagaiando" ou dando uma de chat bot respondendo com contra argumentos qualquer post sobre o "seu" assunto preferido na internet. Eu sei que muita gente vê a possibilidade de injetar comentários em conteúdo alheio como uma oportunidade de aparecer e criar engajamento, mas é feio quando damos nossa opinião sem ela ter sido solicitada. Eu demorei uns 30 anos para entender isso.
rochacbruno.com
November 29, 2024 at 2:40 PM