Arquivo da categoria: Artigos

2020: O ano do novo

Eu sou grande fã do podcast Cortex e, no ano passado, comecei a brincar com a ideia de temas para o ano: um palavra ou frase que guie as minhas decisões para um ano novo que se segue.

Em 2019, eu estabeleci que queria ser mais intencional sobre minhas ações e minha vida. Mantive um diário regularmente, continuei na terapia, e fui muito mais reflexivo em relação ao que estava acontecendo. Eu terminei o ano com uma sensação muito maior de controle sobre minha vida — portanto, tive sucesso em seguir o meu tema.

Agora, em 2020, é hora de testar coisas novas.

O maior desafio novo: ser pai

No final de 2019, nasceu o João Pedro, e apenas isso já garantiria um ano muito diferente dos 31 anos anteriores de minha vida.

Ser pai implica ter uma nova rotina, um novo comportamento (demorou dois dias para eu me espantar como meu celular só tem fotos dele), novos desafios. Principalmente: coisas antigas não cabem mais na minha vida, como ir à academia, ver séries, sair para jantar apenas com minha esposa.

Sem problemas: muito desses abandonos são apenas temporários, enquanto que a aventura de ver uma criança crescendo vai se renovar ano após ano, para sempre.

Um novo emprego

Após 12 anos como parte do POLO, estou partindo para novos desafios: a partir de fevereiro, vou assumir uma posição de Professor Substituto no Centro de Ciências Tecnológicas da Udesc (Universidade do Estado de Santa Catarina).

Eu escolhi entrar para o mundo acadêmico em 2012, quando ingressei no mestrado, mas desde então só havia trabalhando com pesquisa. No meio de 2019, fiz um concurso para professor da UFSC que me fez perceber como faltava experiência docente. Desde então, dei algumas aulas quando meu orientador viajava, e percebi o quanto adoro o ambiente de sala de aula.

Eu já havia decidido não fazer mais concursos e terminar meu pós-doutorado e talvez estendê-lo em 2020, mas aconteceu que numa determinada noite vi um anúncio em um telejornal sobre o concurso para a Udesc, com inscrições vencendo em poucos dias. Fiz o concurso e passei.

Eu quase nunca assisto a jornais, mas bem naquele dia eu estava sentado no sofá quando veio esse notícias. A área do concurso era a minha área. Não seria vontade de Deus que eu passasse?

Uma nova cidade

Uma consequência do novo emprego é sair de Florianópolis, minha cidade natal, e ir para Joinville, a maior cidade de Santa Catarina.

Eu já morei fora de Florianópolis por alguns períodos, todos delimitadoa por no máximo 1 ano. Agora, eu estou indo por período indeterminado. Quem sabe eu volte. Mas também quem sabe não vou me estabelecer em Joinville, ou depois tomar outro rumo?

Não saio de Floripa sem pesar, dado que é a cidade mais bonita do mundo, além de estarem aqui minha família e a maioria de meus amigos. Mas, em 2020, eu vou experimentá-la como visitante — e quem sabe assim eu não aprenda a conhecer essa ilha de outra forma?

Eu estou muito animado para ver tudo isso acontecendo nesse ano. Todos esses aspectos vão me fazer sair da minha zona de conforto e crescer — como pai, marido, profissional, e simplesmente como homem.

Ser pai é ser ineficiente

Ainda lembro do dia em que, passeando pela Fnac na Rua de Santa Catarina, na cidade do Porto, deparei-me com um livro intitulado Fazer bem as coisas (publicado no Brasil como A Arte de Fazer Acontecer), e aprendi sobre listas, projetos, calendário… Estudar produtividade virou quase um vício, a ponto de precisar tratar na terapia como lidar se as coisas não saem como planejado.

E ainda bem que aprendi a não ser produtivo, porque quando o João Pedro nasceu, junto vieram os dias mais ineficientes que já vivi.

Eu escrevo isso não como uma reclamação, mas como um simples reconhecimento de agora tudo mudou: o meu tempo não é mais meu, é do meu filho, e funciona numa outra escala. Posso planejar o quanto quiser tarefas para quando ele estiver dormindo, mas há dias em que ele simplesmente quer acordar de hora em hora, e não há como se concentrar em algo por muito tempo. Posso marcar num calendário com máxima precisão os horários e trajetos para sairmos de casa para visitarmos alguém, mas se ele quiser mamar bem nessa hora, nós vamos chegar atrasados. E eu nunca posso dizer para o bebê com cólicas que eu estou cansado e só queria ler um pouco.

Pode parecer estranho um pai de um recém-nascido já querer escrever regras de paternidade, mas isso tem estado o tempo todo na minha mente nesse primeiro mês. Além disso, observando pais de crianças mais velhas, imagino que a ineficiência vai fazer parte de minha vida por muito tempo — por exemplo, ao andar de carro para lá e para cá, algo que sempre me incomodou.

Quando eu escrevo “ineficiência”, é mais para chamar a atenção, porque não é bem verdade. Prefiro pensar que troquei eficiência por eficácia. Tudo leva mais tempo, poucas tarefas cabem num dia, mas as que acontecem têm real significado. As inúmeras trocas de fralda e horas em pé para fazê-lo arrotar não são itens a marcar numa lista, mas atos de cuidado. Quando sou interrompido no que estou fazendo para pegá-lo e confortá-lo, isso é algo que só eu posso fazer, e que tem grande impacto sobre o bem estar dele. E quando eu de fato trabalho, quando ele estiver dormindo ou com a mãe, eu preciso me forçar a trabalhar no que é realmente importante – principalmente porque agora eu trabalho para o futuro dele.

Ser pai é ser ineficiente, mas é trocar eficiência por amor. É trocar uma noite de sono inteira, que me faria trabalhar melhor, por uma noite interrompida para consolá-lo e ver as mãozinhas dele se aninharem no meu peito depois que ele se acalma. E então eu penso: eficiência para quê?

João Pedro

João

Ontem, 27 de dezembro, foi dia de São João, Apóstolo e Evangelista. A minha Bíblia (Edição Pastoral) apresenta o Evangelho de Jesus Cristo segundo João como “diferente dos três primeiros”. A começar por abrir o seu livro com um poema:

No começo a Palavra já existia:

a Palavra estava voltada para Deus,

a Palavra era Deus.

No começo ela estava voltada para Deus.

Tudo foi feito por meio dela,

e, de tudo o que existe,

nada foi feito sem ela.

Nela estava a vida,

e a vida era a luz dos homens.

Essa luz brilha nas trevas,

e as trevas não conseguiram apagá-la.

Jo 1, 1-5

A vida era a luz dos homens. Eu já falei aqui sobre minha luta contra a depressão, e a oração foi uma arma muito poderosa, a luz que brilha nas trevas. Inúmeras noites me sentei nessa mesma escrivaninha onde escrevo estas palavras, derramando-me em lágrimas e pedindo o consolo da Palavra. E Ela nunca falhou, especialmente quando mergulhava nos escritos de João.

É impossível ler muitas páginas do Evanhelho e das Cartas de João sem se deparar com inúmeros mensagens sobre o Amor. Em contraponta às inúmeras regras do Antigo Testamento, João mostra como a mensagem de Jesus é simples: “O meu mandamento é este: amem-se uns aos outros, assim como eu amei vocês” (Jo 15, 12). Mas como amar? “Não existe amor maior que dar a vida pelos amigos” (Jo 15, 13). Depois, na sua Primeira Carta, João nos chama a toda hora de “filhinhos” e outros vocativos carinhosos: “Amados, amemo-nos uns aos outros, pois o amor vem de Deus” (1 Jo 4, 7). João me ensinou, portanto, que a minha Fé, o que me faz Cristão, é que eu creio no Amor; não precisamos nos castigar uns aos outros, pois o Amor salva: “E o amor consiste no seguinte: não fomos nós que amamos a Deus, mas foi ele que nos amou, e nos enviou o seu Filho como vítima expiatória por nossos pecados” (1 Jo 4, 10).

Muitos outros fundamentos e lições da Fé estão ilustrados no Quarto Evangelho. Quando eu me pego indagando se a oração é uma perda de tempo, eu lembro d’Ele falando à samaritana: “Quem bebe desta água vai ter sede de novo. Mas aquele que beber a água que eu vou dar, esse nunca mais terá sede. E a água que eu lhe darei, vai se tornar dentro dele uma fonte de água que jorra para a vida eterna.” (Jo 4, 13-14). Quando eu, envergonhadamente, penso se um doutor como eu deveria gastar tempo trocando a bombona d’água do meu laboratório, eu lembro d’Ele: “Pois bem: eu, que sou o Mestre e o Senhor, lavei os seus pés; por isso vocês devem lavar os pés uns dos outros.” (Jo 13, 14). E se fico pensando se devo orar para o Pai ou para o Filho, percebo que isto não faz diferença: “Quem me viu, viu o Pai” (Jo 14, 9).

O próprio Jesus percebeu que João era especial, a ponto de lhe confiar Sua Mãe depois que Ele morresse (Jo 19, 26-27). João era assim: puro Amor e Cuidado.

Outro João

São João da Cruz foi um frade, poeta e místico espanhol. Para quem está envolvido com as Oficinas de Oração e Vida, é impossível não entrar em contato com a sua obra, dado que Frei Ignácio Larrañaga, nosso fundador, era seu grande admirador. João da Cruz compreendeu e então capturou como é a verdadeira oração:

Descobre Tua presença,

e mantém Tua vista e formosura,

olha que a doença de amor não se cura,

senão com a Presença e a Figura.

São João da Cruz, citado por Frei Ignácio na Mensagem da Oitava Sessão dos TOV Adulto

Orar é estar na Presença da Figura, e é só esta presença que preenche a Alma sedenta de Amor, a “fonte de água viva” como São João Evangelista colocou.

Eu entrei nas Oficinas em 2016, e elas foram essenciais em me ajudar a lidar com o luto da morte de minha avó. Desde então, tornei-me eu mesmo um Guia, e para o mim o maior benefício pragmático do nosso programa é ajudar as pessoas a lidarem com as loucuras do dia a dia. É saindo do celular e entrando em nós mesmos que conseguimos nos esvaziar dos problemas, e então conseguir consolo com Jesus. E não é preciso muito para se isolar do mundo e se encontrar com Deus, segundo São João da Cruz:

A noite sossegada,

a música calada,

a solidão sonora,

e a ceia que recreia e enamora.

São João da Cruz, citado por Frei Ignácio na Mensagem da Oitava Sessão dos TOV Adulto

Relendo o meu diário neste ano de 2019, percebi que os meus momentos de felicidade foram assim: simples e leves como uma noite sossegada.

Pedro

São Pedro foi tema constante das minhas sessões de terapia em 2019. Uma das minhas maiores aflições é o medo de errar, e o maior aprendizado desse ano foi superar os padrões rígidos de perfeição impostos pela minha profissão e minha família. E o que mais me chama atenção em Pedro é, surpreendemente, o quanto ele errou.

Mesmo tendo o Filho de Deus diante de si, ordenando que ele caminhasse sobre as águas, Pedro sentiu medo e começou a afundar, recebendo uma reprimenta de Jesus (Mt 14, 28-31). Desesperado quando Jesus estava para morrer, Pedro atacou seus inimigos, contrariando a mensagem de Paz e Entrega de Jesus (Jo 18, 10-11), e ainda por cima negou ser seu discípulo – três vezes (Jo 18, 17.25-27). Ele próprio sabia das suas falhas; quando Jesus fez encherem as redes de pesca antes vazias, Pedro se horroriza: “Senhor, afasta-te mim, porque eu sou um pecador!” (Lc 5, 8).

Mesmo assim, Pedro foi o líder escolhido por Jesus para a Sua Igreja. Um simples pescador, alguém que poderíamos encontrar na gente simples de Florianópolis, foi convidado a ser pescador de homens (Mt 4, 19), e recebeu d’Ele as chaves do Reino dos Céus (Mt 16, 15-19). Pedro não nasceu perfeito; errou, aprendeu, fortaleceu-se, e guiou os seguidores de Jesus após a Ressureição (At 2).

João Pedro

Desde que eu e minha esposa começamos a falar seriamente em ter um filho, eu estabeleci para mim mesmo, e ela depois concordou, que a nossa primeira criança teria um nome inspirado em alguma figura bíblica. Eu não consigo lembrar muito bem de quando e como aconteceu, mas em algum momento o nome João Pedro, uma combinação dos dois Apóstolos, entrou em minha mente e ali se fixou.

No dia 14 de dezembro de 2019, dia de São João da Cruz, nasceu o nosso João Pedro. Alguém que eu espero que una as características dessas figuras que citei neste texto: que seja amoroso, carinhoso, cuidadoso com sua família, capaz de se recolher e meditar, como os Joões deste texto; mas ao mesmo tempo forte, ciente dos seus erros e capaz de superá-los, como Pedro.

O ano de 2019 foi, para mim, esperá-lo. E ele chegou, presente de Natal antecipado de Jesus, o mesmo Jesus que seduziu a João, a Pedro, a João da Cruz – e a mim e à minha esposa. Que venha 2020, com o privilégio de ver um ser humano crescendo.

Como organizar resultados de simulações númericas

Como muitas de minhas ideias, está começou com um podcast, e especificamente sobre minha mais recente obsessão: ciência de dados.

A situação: tenho um modelo numérico que simula algum problema físico. Para um mesmo modelo, é possível fazer várias análises: com e sem alguma característica, modificando ou não alguma das equações governantes do problema. O problema: como organizar todas essas análises?

Para meu deleite acadêmico, esse episódio de Talk Python to Me referenciou alguns artigos científicos, e desde então tenho testado as soluções que cientistas antes de mim já procuraram implementar para o mesmo problema.

A pasta results

Quando vou testar alguma próxima modificação no meu modelo ou analisar a influência particular de algum parâmetro , onde vou armazenar todos os resultados, de maneira a poder referencia-los depois?

O meu modelo está encapsulado numa pasta no meu computador:

Captura de tela de uma pasta no Windows, mostrando como ela está organizada

A pasta raiz tem imagens, um arquivo de sumário README, alguns arquivos de dados, arquivos de suporte para Python, e diversas subpastas:

  • Já falei anteriormente sobre testes, e eles estão devidamente organizados. O programa de testes que uso, pytest, cria uma pasta de cache, que aparece no topo da lista.
  • A pasta src contém o código fonte (neste caso, em Python). Kenneth Reitz havia me convencido de que uma pasta assim deve ter o mesmo nome da biblioteca sendo desenvolvida (neste caso, magnet3Dpolomag, como aparece em outro post), mas estes artigos me convenceram de que afinal é melhor ter uma pasta chamada src (de source code), e suas bibliotecas dentro dessa pasta, para melhor execução de testes. Os artigos científicos citados no começo deste posts também recomendam uma pasta genérica src.
  • docs contém um protótipo de documentação
  • .vscodecontém arquivos de configuração do Visual Studio Code
  • e results é onde a mágica acontece.

A pasta results é um repositório de todos os resultados que esse modelo já gerou. Respondendo à pergunta anterior: quando quero fazer uma nova análise, o primeiro passo é criar uma nova subpasta dentro de results:

Captura de tela da interface web do GitHub, mostrando diversas análises dentro de uma pasta "results"

Um ponto importante dessa minha estratégia é fazer uso da interface web do GitHub, como visto acima, serve como referência online. Nas reuniões do nosso grupo de pesquisa, tenho compartilhado links para cada uma dessa subpastas junto com capturas de tela como essa, para mostrar em que estado minha pesquisa está e o que foi feito em um período. Seguindo a recomendação dos artigos citados, ponho a data no início do nome da pasta para uma ordenação temporal e para ter ideia de quando uma análise foi feita.

Cada pasta dessa armazena scripts para cálculo e processamento de dados, imagens e tabelas salvas, arquivos de referência — tudo que ajuda uma pessoa de fora (ou meu futuro eu) a entender uma parte da pesquisa usando meu modelo.

Captura de tela da interface web do GitHub, mostrando arquivos e pastas dentro de uma subpasta de "results"

Numa organização dessa, é crucial criar um README bem feito, para evitar a confusão de abrir uma pasta cheia de arquivos soltos sem nenhuma explicação. Usando a interface web do GitHub, o README é renderizado quando se abre uma pasta, o que é muito interessante.

Captura de tela de um arquivo README de uma subpasta de "results", mostrando explicações sobre como a análise dessa subpasta foi feita

Conclusões

É assim que organizo minhas simulações numéricas. Ainda estou aprendendo a implementar esse método, mas ele tem me dado bastante tranquilidade, permite-me facilmente achar análises passadas, e elimina a dúvida de “por onde começar”, ao testar algo novo nos meus modelos numéricos.

Esse é um assunto que me interessa muito. Os leitores têm alguma dica?

Gerando uma exceção em Python com um nome significativo, e uma mensagem significativa

Aqui está uma tarefa que é para ser simples mas que considero mal documentada no mundo Python.

O problema: estou desenvolvendo uma biblioteca para simular uma determinada topologia de ímãs permanentes. O usuário deve entrar com alguns parâmetros geométricos, mas antes de qualquer coisa o programa deve verificá-los e avisar quais são inválidos.

Em termos de programação, estamos falando de exceções: condições literalmente excepcionais que não devem acontecer mas, se acontecem, é melhor parar o programa para que o usuário possa verificar. O tutorial oficial de Python explica como criar exceções personalizadas, e a documentação de referência mostra os tipos de exceções que já existem em Python. Este tópico também é bem abordado em [1].

Pesquisando a documentação sobre as exceções já construídas, parece-me que a exceção aproximada que descreve esse problema é ValueError. O que eu quero então é definir um erro que diga que o “valor errado” é precisamente um “parâmetro inválido”. O problema na documentação que citei antes é precisamente que eu não estava conseguindo entender como a mensagem de erro pode ser customizada para indicar qual parâmetro é inválido, pois as exceções aparentemente não aceitam strings como argumentos…

…mas exceções aceitam uma tupla como argumento, e é isso que não estava claro para mim. Veja o código a seguir:

No primeiro programa, eu defino uma exceção que deriva de ValueError. No segundo, crio uma função de validação, que cria essa minha exceção personalizada, e a constrói com uma string de mensagem indicando qual foi o problema. E posso testar essa função usando pytest, conforme está nos comentários do terceiro programa: tudo que eu passei para InvalidParameterErrorfoi armazenado internamente como uma tupla args; se só passei uma string, esta foi armazenada no primeiro elemento, ou seja, em args[0]. E posso testar se a mensagem criada era a que eu estava esperando.

A minha biblioteca de ímãs permanentes é mais complexa que isto, mas a lógica é idêntica: se alguém tentar usá-la com um parâmetro inválido, o programa vai fazer uma verificação e imprimir uma mensagem de InvalidParameterError na tela.

É como falei no início: era para ser simples, mas no meio do caminho me diverti muito aprendendo sobre exceções em Python e escrevendo sobre elas. E agora vou voltar a realmente trabalhar na minha biblioteca, e estou muito mais seguro de que ela vai funcionar como deveria.

[1]: Beazley, David & Jones, Brian K. Python Cookbook. São Paulo: Novatec, 2013 (link afiliado para compra)

Abrindo e fechando sempre os mesmos programas

Sempre que vou iniciar uma sessão de trabalho — em bom português, sentar para trabalhar — em algum projeto de programação ou escrita de um artigo, há uma série de ações repetitivas:

  1. Usando o terminal de comando, navego até a pasta do projeto em questão
  2. Obtenho a última versão do projeto no GitHub
  3. Abro os arquivos de LaTeX no Emacs e os programas em Python no Visual Studio Code
  4. Abro o Sourcetree, para gerenciar as modificações que eu vou fazendo
  5. Abro arquivos de referência (PDF de alguma documentação, por exemplo)

Ao longo da minha sessão, vou trabalhando, e periodicamente usando o supra-citado Sourcetree para registrar o que vou fazendo. Nesse período, invariavelmente meu celular está em modo Não perturbe e estou escutando a trilha sonora de algum filme, série ou jogo no Deezer.

Quando termino de trabalhar, por cansaço ou por ter de fazer outra atividade, também há série de atividades repetitivas:

  1. Fecho todos os arquivos abertos no começo
  2. Sincronizo minha versão atual do trabalho com a versão no GitHub.

Esse ciclo de abrir programas – trabalhar – fechar programas se repete algumas vezes ao longo de dia, de maneira que criei um sistema de automação dessas tarefas. Já falei aqui sobre como escrevi minha tese de maneira eficiente, onde automatizei algumas tarefas; o sistema que descrevo neste post é mais geral.

Um aviso: este post é bastante técnico e requer o uso do terminal de comando, em particular o sistema Git for Windows, que instala a shell Bash e muitos utiliários como programas nativos do Windows; para macOS e Linux, Bash e aplicativos de terminal já estão instalados. Se você se interesse por computação científica e quer aprender mais, existem muitos tutoriais disponíveis sobre como usar e configurar Bash, o meu canal preferido no YouTube para esse assunto é o do Corey Schafer. Os exemplos que vão mostrar aqui se aplicam a Windows, e minha configuração está disponível no GitHub.

Mesmo que o leitor não esteja familiarizado com nada disso, pode ler para tentar entender como eu automatizo algumas tarefas e ter ideias para facilitar a sua vida.

A base do meu sistema é um pequeno utilitário Bash chamado prm, que permite definir “procedimentos” de “começar” e “parar” um projeto.

Vamos a um exemplo prático. No momento estou trabalhando em um paper sobre perfis magnéticos para refrigeradores magnéticos. Após instalar prm usando as instruções do repositório, crio um projeto no terminal usando:

prm add pprof

pprof é uma abreviação de “paper profiles” (é assim que meu cérebro funciona). Esse comando cria dois scripts, em uma pasta padrão do prm (que pode ser mudada) abre-os no editor de texto padrão.

O primeiro script,start.sh, define o que é feito ao começar a trabalhar no projeto:

O segundo script, stop.sh, é executado quando termino de trabalhar no projeto:

No script acima, cf é uma função que fecha um arquivo no Emacs, que está definida em ~/.bash_profile.

e closew é um comando que fecha janelas usando AutoHotKey:

que é definido como um atalho na forma (dentro de .bash_profile).

alias closew="AutoHotkey path/to/closewindow.ahk"

Como toda automação, apesar de exigir um pouco de trabalho, estes hacks facilitam muito o trabalho e deixam minha mente livre para se concentrar no que é necessário. Por exemplo, quando quero começar a trabalhar no paper, abro uma janela do Git Bash e digito:

prm start pprof

e tudo fica pronto na minha frente. Mais importante que a abertura dos programas, no entendo, é o recado ao meu cérebro, quando digito o comando acima, de que é hora de começar a trabalhar no paper.

Quando é hora de parar, digito

prm stop pprof

e tudo se fecha, deixando meu computador pronto para outras tarefas.

Como ler artigos científicos e extrair o máximo de informação

Ler artigos científicos (ou papers) faz parte do meu trabalho regular como pesquisador e, com a prática de anos, desenvolvi um método que me serve bem, e que documento aqui. Para ser franco, acho que extrair o máximo de informação útil de um paper é uma das maiores habilidades, e por isso acho que este texto pode ajudar o leitor.

Minha prática é um misto de ideias de Como Ler Livros e do método Zettelkasten, e consiste de 3 etapas:

  1. Leitura inspecional
  2. Leitura analítica
  3. Processamento de notas

Leitura inspecional do paper

Na leitura inspecional de um paper, estou me familiarizando com o trabalho.:

  • Sobre o que é?
  • Que problemas ele investiga e resolve?
  • Como ele me ajuda nos meus projetos atuais?

A leitura inspecional é para ser rápida, o que significa que eu não paro se eu não entendo alguma equação, figura ou método sendo descrito. Procuro fazer em uma única sessão de trabalho, e geralmente me dou uma hora. Dependendo do tamanho do artigo, é o suficiente para ler superficialmente todo o texto; às vezes, leio o resumo, introdução e conclusão com muito mais atenção, e apenas examino o restante do artigo, à procura de algo interessante.

Dependendo do meu objetivo ao ler este paper em específico, uma leitura inspecional basta. Se quero compilar quais autores estudaram tal assunto, e a leitura inspecional me mostra que Fulano fez este estudo e concluiu isto (através da leitura mais atenciosa da conclusão, vide parágrafo acima), a leitura está concluída. Muitas vezes, aliás, essa primeira leitura me mostra que um determinado artigo não serve para mim, e o papel é transformado em rascunho.

Falando nisso, para extrair o máximo de informação de um artigo, como eu estou propondo neste texto, para mim é fundamental imprimir o artigo e ler analogicamente. Pode parecer contra o bom uso de recursos naturais, mas tento minimizar esses efeitos aproveitando os papeis como rascunho após a leitura e reciclando-os. Além disso, se eu ler no computador, há o gasto adicional de energia para renderizar o PDF (quando muitas vezes a tela do computador está apagada enquanto estou lendo no papel); se eu comprar um iPad para isso, de onde vem os recursos naturais e humanos para fabricar cada peça?

Nada substitui a experiência de se isolar, talvez apenas com uma música de fundo, e ler um pedaço de papel com canetas para fazer anotações. Na leitura inspecional, essas anotações são rápidas e pontuais.

Leitura analítica do paper

A leitura analítica do paper é demorada e detalhada. Dependendo do assunto ou do nível de profundidade de que preciso (para implementar algum modelo ou para escrever sobre esse assunto, por exemplo), algumas vezes a leitura analítica requer múltiplas sessões de trabalho profundo de 1h30min ou 2h por alguns dias.

Nessa etapa, muitas notas são escritas — às vezes em notas adesivas, às vezes em notas soltas anexadas, às vezes no verso do paper. Se o meu objetivo é entender a fundo o que está sendo abordado, preciso expressar com minhas próprias palavras.

O resultado de um artigo lido com atenção
Às vezes o básico da Termodinâmica é o mais difícil de entender
Como vêem, eu não economizo em escrever até as ideias mais básicas
Sim, um doutor em Engenharia Mecânica às vezes precisa converter RPM para hertz.

Processamento de notas

Essas notas soltas, escritas na pressa e muitas vezes sucintas, precisam ser transformadas em textos coerentes, que possam ser usados como base para meus próprios artigos, para Teses, para relatórios etc.

Como citei no início deste post, meu método é bastante inspirado no método Zettelkasten. Basicamente, para cada paper lido e suas notas, crio minhas notas em versão digital. Cada “nota” (Zettel, em alemão) é um arquivo .txt em uma pasta no Dropbox. Importante: cada nota corresponde a um assunto, e não a um resumo de um paper. Um mesmo artigo pode trazer diferentes assuntos, e um mesmo assunto pode ser abordado por diferentes autores.

Meu sistema é complexo mas funciona bem para mim. Uso um editor de texto arcaico chamado Emacs, voltado à programação e de um paradigma diferente do Word, com suas figuras e fontes; no Emacs, tudo é basicamente texto.

Dentro do Emacs, há um pacote chamado Deft. Com um atalho de teclado, a minha pasta de notas é carregada e o Emacs me apresenta uma lista das minhas notas, onde então posso selecionar e abrir uma para editar. O recurso-chave desse pacote, porém, é que ele me permite buscar por palavras dentro das notas. Isso representa um avanço sobre simplesmente ter a pasta de notas aberta no Explorador de Arquivos e abrir cada arquivo individualmente; no Deft, estamos lidando com “objetos” notas, e não com arquivos.

Interface de lista de notas no Emacs, usando Deft

Cada nota é escrita em Markdown, usando a versão Pandoc (veja abaixo).

Uma nota no Emacs

Também configurei o Emacs+Deft para, com um outro atalho de teclado que cria uma nova nota, me pedindo o título e as palavras-chaves. Esse atalho cria um arquivo com um template pré-configurado, conforme aparece na Figura.

O leitor quer mais informações sobre esse template de notas e minha configuração de Emacs+Deft? Deixe nos comentários!

Meu fluxo de trabalho funciona da seguinte forma: após ler alguns artigos analiticamente, tenho um conjunto de notas em paper. Reviso-os e separo-os por temas, pensando em novas notas que podem ser criadas. Repare que muitas vezes a leitura de um paper me faz atualizar alguma nota que foi escrita anos atrás, com novas descobertas empíricas ou uma melhor explicação de alguma teoria. Processo então todas as notas, escrevendo novos textos ou revisando notas antigas; isso gera novas ideias de textos, que são facilmente criados usando os atalhos acima.

Quando quero escrever um documento final, geralmente em LaTeX, posso usar o Deft para ver todas as minhas notas sobre um assunto. Como estes textos são meus textos, escritos com as minhas palavras, muitas vezes copio notas inteiras direto para o corpo de um manuscrito. A ferramenta Pandoc é muito útil para converter entre Markdown e LaTeX.

Conclusões

Este é o meu ciclo de extrair informações de artigos. Não é nada novo ou revolucionário; apenas estou descrevendo algumas práticas particulares minhas e as ferramentas que uso.

Trato esse processo com alto respeito por achar que isto é o cerne da minha atividade de pesquisador.

O leitor acha que esse é um tema interessante de ser explorado mais a fundo aqui no blog? Deixe sua opinião nos comentários!

Quando usar notebooks ou scripts para analisar dados?

Um de meus tópicos favoritos recentemente em podcasts e blogs é a discussão sobre usar notebooks ou scripts em contexto de análise de dados e computação numérica.

Se você mal chegou neste texto e não está entendendo nada, vamos por partes. Tudo que vou falar aqui se aplica ao meu contexto de computação numérica: usar computadores para resolver equações e modelos matemáticos e analisar e plotar os dados resultantes, usando gráficos e ferramentas estatísticas. Nesse tipo de ambiente, é comum usar esses dois tipos de ferramentas, conforme vou ilustrar.

Neste texto vou usar exemplos em Python, mas ambas as ferramentas podem ser usadas com várias linguagens de programação.

Nos notebooks Jupyter, eu escrevo códigos usando um ambiente interativo no navegador, com todos os recursos visuais que isso me permite.

Um exemplo de código Python, gráfico e notas em um notebook Jupyter, segundo meu uso

Um “caderno” em Jupyter é divido em células independentes, que podem conter código, imagens, ou texto. Quando uma célula de código é executada, ela pode gerar um resultado que é impresso na tela, na forma de um gráfico ou de mensagens de texto (ambos os usos aparecem na imagem acima). Além disso, a execução de uma célula depende de células que foram executadas antes dela, onde podem ter sido definidas variáveis e funções – mas isso não precisa seguir a ordem “de cima para baixo” de um caderno Jupyter, o que pode gerar cenários confusos. Por exemplo, suponha que eu executa todas as células nessa ordem vertical (até a última célula embaixo), e depois queira voltar e arrumar aquele gráfico mostrado ali; agora, a célula do gráfico vai ser influenciada por código que “teoricamente” foi escrito depois dela, já que os últimos blocos já foram executados. Já vamos falar sobre soluções para isso.

A outra abordagem é escrever um programa na forma de script, que é executado como uma unidade única. Embora alguns editores atuais até permitam isso, em geral não existe o conceito de células; as linhas de código em um script em Python vão sendo executadas individualmente de cima para baixo até o fim.

Um script de Python no Visual Studio Code sendo editado (parte de cima) e executado (parte de baixo)

Então, voltando à pergunta: quando uso um tipo e quando uso outro?

Em geral, começo minhas ideias de análise em um notebook, considerando que é para isso que ele foi criado. Notebooks no seu estágio inicial são caóticos; vou criando células, volto para trás, edito, testo novas ideias. À medida que descubro a melhor maneira de implementar alguma análise, começo então a documentar e organizar o caderno – aliás, a possibilidade de ter texto formatado junto com código é uma das principais vantagens de Jupyter. Quando ele fica “maduro”, ele serve como um relatório interativo, que pode ser constantemente atualizado.

Uso scripts para trabalhos mais pesados: já testei alguma ideia como um notebook, agora quero executar esse procedimento diversas vezes com diferentes condições. Usar um bom editor como o Visual Studio Code me permite usar bons atalhos e funções para escrever código mais rapidamente. Quando o script fica maduro, ele pode ser incorporado a alguma biblioteca e testado.

Os leitores já devem saber que sou um grande entusiasta de explorar melhor minha criatividade, mesmo em um trabalho científico. Faço sempre um esforço sobre-humano para não me deixar cair rotina de reuniões e preenchimento de relatórios de bolsa. Usar essas diferentes ferramentas de programação (e falar sobre elas) me permite brincar, conhecer a minha forma preferida de programar, descobrir novas maneiras de desenvolver meus projetos.

É como diz Austin Kleon: as ferramentas importam e as ferramentas não importam.