Arquivo da tag: trabalho

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?

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!

Usando mapas mentais para planejar papers

Entenderam?

Sempre me espanta que mais pessoas não usem mapas mentais para planejar papers (e outros documentos escritos). É só a minha cabeça que contém ideias confusas demais e que precisam ser organizadas de alguma forma?

A imagem acima é do excelente MindNode (que eu acesso através do serviço Setapp), que infelizmente só existe para dispositivos Apple. Para Windows (para qualquer plataforma, na verdade), há o também bom MindMeister.

Meu fluxo de ficar desenvolvendo ideias até elas assumirem uma forma mais definida é totalmente influenciada pelo Presentations Field Guide, do David Sparks, e pelo episódio maravilhosamente chamado de Cooking Ideas do seu podcast Mac Power Users.

O que eu faço quando trabalho em casa

Trabalhando em casa? Você deve ficar vendo Netflix, ou só dormindo, ou fazendo coisas inúteis!

Errado.

Primeiro, eu aproveito o sol e vou correr numa praça repleta de bebês também aproveitando o sol, para me lembrar da beleza da vida (principalmente depois de ter ido a um velório) e para clarear minha mente com tantos projetos profissionais em andamento.

Depois, eu aproveito o silêncio completo e faço um inventário de todas as pessoas cujo trabalho eu preciso acompanhar — e então pesquiso e testo a melhor maneira de fazer isso.

Então, eu almoço uma comida caseira com minha esposa vendo Friends — porque eu tenho o direito de ser feliz.

Em seguida, tomando um bom chá, eu testo um novo app de tomar notas — porque aprender e escrever sobre o que eu aprendi é a minha maior habilidade, e o que eu mais então.

Finalmente, eu brinco de canetinhas para me ajudar a entender o que eu preciso formular matematicamente (e implementar em um programa de computador) para um dos meus projetos profissionais.

Quer progredir no trabalho? Estude criatividade

A nobre leitora deve ter percebido um grande aumento de textos recentes nesse blog sobre criatividade. Não é de se espantar, já que Fábio Fortkamp.com reflete o que se passa na cabeça do Fábio Fortkamp, e ultimamente ele parece que só lê coisas sobre criatividade.

Mas como criatividade afeta a minha vida bastante mundana de pesquisador/marido/Guia das Oficinas? E por que eu me incomodo em partilhar isso, e porque eu encho a cabeça dos meus leitores sobre criatividade?

Para mim, criatividade é sobre ter ideias, e (quase) todo mundo pode se beneficiar disso.

Eu, sentado em um sítio, escrevendo no meu Bullet Journal, rodeado de cachorros
Eu, tendo muitas ideias

Kourosh Dini define um projeto concreto como aquele que tem passos bem definidos: ir à loja tal comprar isto; entrar no site X e submeter documento Y. Para esses tipos, que encontramos todo dia, não precisamos de muitas ideias, apenas de tempo e energia.

Na terminologia de Dini, projeto criativo, por outro lado, tem um fim desconhecido e passos não muito claro. Trabalhadores do conhecimento lidam com projetos criativos o tempo todo: escrever um relatório, preparar uma apresentação, criar um plano de negócios, preparar uma aula. O próximo passo não é simplesmente “digitar relatório”; você precisa pensar sobre ele. Ter ideias, enfim.

É por isso que, além de ler material mais técnico como artigos sobre circuitos magnéticos ou livros sobre otimização, no meu trabalho como pesquisador eu me cerco de textos sobre como aproveitar melhor essas referências e produzir mais. Quando Austin Kleon fala de usar um caderno para “guardar seus roubos”, isso não é aplicável apenas para artistas; meus cadernos estão cheios de anotações sobre incerteza experimental e precisão numérica. Quando Cal Newport fala da importância de caminhadas para a produtividade, eu levo a sério e me vejo pensando sobre alguma técnica de otimização no trajeto de casa até o laboratório. Se a Thais Godinho sugere “alternar contextos” (trabalhar no computador, depois sair um pouco das telas, depois voltar e etc), eu estou sempre com um livro ou um paper na minha mesa para descansar os olhos e aprender alguma coisa nova, sem cansar muito meu cérebro.

Nada disso é assunto “de engenharia”, mas tudo isso me ensina a ser um engenheiro pesquisador melhor.

E, de tanto ler sobre isso, essas técnicas de criatividade se irradiam para outras áreas da minha vida. Se vejo algum vídeo com uma receita interessante, da próxima vez em que for fazer alguma atividade “mundana” provavelmente estarei refletindo sobre ela, e sobre como posso usá-la para preparar um jantar para minha esposa. Ou estou meditando com algum livro da Bíblia, e faço conexões com outras passagens porque tenho muitos pensamentos registrados no meu Caderno Espiritual.

Ao prestar atenção e dedicar tempo a esse tipo de soft skill como criatividade, a minha vida fica melhor — a do leitor pode ficar também.

Resenha: Show Your Work

Eu fiquei sabendo de Show Your Work, de Austin Kleon, através de um mísero link em post de Mike Vardy (cujo link exato não consigo mais encontrar). Na época, acho que estava começando com esse blog, começando também a ler muito sobre produtividade e tecnologia (o que me levou a conhecer Vardy), e fiquei intrigado com o simples título desse livro. A partir daí, comecei a mergulhar cada vez mais na obra desse escritor americano.

Confesso que, da primeira vez que li, não deu muito atenção. Mas, quando comecei a dar mais atenção à minha criatividade como tratamento contra ansiedade e depressão, Show your work se tornou um de meus livros favoritos sobre criatividade.

Kleon consegue motivar todo mundo a achar uma “arte” em seu trabalho e então em maneiras de compartilhá-la com o mundo. Não de maneira mirabolante, mas básica: separar uns minutos por dia, criar um blog, usar o Instagram para mostrar dicas do seu trabalho e não o seu almoço. Caso o leitor não tenha reparado, eu venho usando cada vez as dicas desse livro aqui neste blog, mostrando os bastidores do meu trabalho e cotidiano, expondo meus livros/apps/sites favoritos, conectando ideias aparentemente distintas.

A internet está cheia de coisas ruins. Vamos enchê-la de coisas boas, falando de nosso trabalho e nossos assuntos favoritos. Show your work é um bom guia para começarmos.