Categorias
Artigos

Apps e programas que um pesquisador usa

Inspirado por uma série de episódios anuais do Cortex, aqui está uma lista dos apps e programas que eu, um pesquisador de Engenharia, uso diariamente (para fins de trabalho):

iPhone

  • Drafts – quando você abre o Drafts, ele imediatamente abre uma página em branco, sem eu precisar explicitamente criar uma nova nota. A minha versão de “manter cartões de anotações” o tempo todo comigo conforme recomendado por David Allen e Anne Lamott;
  • Todoist -para consultar minhas tarefas;
  • Outlook – app de email que uso por nenhuma razão específico para usar e nenhuma razão específica para deixar de usar. Meu relacionamento com e-mails é o seguinte: eu abro regularmente, arquivo 90%, mando 5% para o Evernote, respondo os 2% rapidamente no iPhone, e deixo os outros 2% para responder com calma no PC;
  • Kindle – para sempre ter um livro à mão (e leio muito coisa técnica);
  • PCalc – porque eu sou engenheiro, e como todo bom engenheiro, uso com modo RPN;
  • NetNewsWire – sei que a internet diz para não acompanhar notícias, por isso vou consultando ao longo do dia meus blogs favoritos (muitos deles relacionados ao trabalho);
  • Forest – um app que faz crescer uma árvore no seu celular e, se você sai do app para consultar o Instagram, email, WhatsApp etc, a árvore morre. Bom para se concentrar!

Windows

E é assim que eu trabalho.

Publicidade
Categorias
Artigos

Por que uso o PyCharm ou: uma história sobre complicar para simplificar

O que vou falar aqui não combina muito com o Ano de Simplificar, mas vale a pena ser dito: às vezes, complicar torna a vida mais simples.

O meu trabalho envolve programar muito em Python, como vários outros pesquisadores do mundo. O editor da moda é o Visual Studio Code, que tem um visual mais minimalista e de fato é muito bom.

O problema é que apenas o editor não é suficiente para meu trabalho: eu preciso de um terminal de linha de comando e de ferramentas de controle de versão. O VS Code têm tudo isso, mas aí a sua simplicidade começa a sumir… E é aí que eu resolvi abraçar a complexidade e usar um editor mais profissional, PyCharm.

PyCharm não é um programa simples ou fácil de usar: há inúmeros painéis, menus, caixas de diálogo, atalhos. Mas agora, tudo que eu preciso está em um só programa – e aos poucos, estou aprendendo a navegar nessa complexidade e me tornando mais produtivo e eficiente no meu trabalho.

E no seu trabalho? Que passo adicional em relação à complexidade a leitora pode adotar que vai tornar a vida mais simples, na verdade? Que software/metodologia/ferramenta o leitor está com medo de abraçar pela complexidade, mas que vai facilitar a vida?

Categorias
Artigos

Bibliotecas Python essenciais para Engenharia Mecânica

Preciso ainda falar que acredito muito em usar ferramentas computacionais dentro da sala de aula para resolver problemas reais de engenharia?

A minha linguagem de programação é Python, simplesmente porque venho usando há mais de 10 anos (!). Entretanto, algumas bibliotecas são essenciais para o tipo de trabalho que faço, e todas ou já estão disponíveis ou são facilmente instaláveis no pacote Anaconda (pesquise pela documentação sobre como instalá-las):

  1. NumPy – para trabalhar com arrays e matrizes, como ao resolver sistemas de equações lineares
  2. SimPy – para algoritmos de “Cálculo Numérico”: achar raízes e pontos de ótimo, integração numérica, funções especiais (e.g. funções de Bessel, bastante usadas em Transferência de Calor)
  3. pandas – para ler arquivos em tabelas e manipular; é basicamente a funcionalidade do Excel em Python
  4. CoolProp – para calcular propriedades de fluidos
  5. PYroMat – idem acima, mas especificamente para modelos de gases ideais (e propriedades mais relevantes para análise de reações de combustão)
  6. Matplotlib – para gerar gráficos de todas as análises que você vai fazer usando as ferramentas acima

Essas são o conjunto mínimo viável; se você é estudante de Engenharia Mecânica, deve aprender agora a utilizá-las, e o YouTube está cheio de tutoriais (eu aprendi basicamente lendo as documentações e pesquisando como resolver os erros que apareciam).

Como um bônus, vale a pena começar a mergulhar em scikit-learn e estudar um pouco de Aprendizado de Máquina.

Categorias
Artigos

Melhorando minhas aulas em 1 %

Como posso deixar minhas aulas 1% melhor a cada semestre?

Cada disciplina tem sua realidade. No meu curso de Transferência de Calor e Massa I, por exemplo, estou decidido a mostrar como poder resolver problemas usando Python, pensando de maneira inteligente sobre a computação:

Em 2022 eu estou, na medida do possível, colocando minhas notas de aula online; aqui está por exemplo a página onde resolvemos os problemas de convecção acima. Trazer ferramentas computacionais modernas para o curso de Engenharia Mecânica e deixar isso documentado.

A leitora acha que isso é uma melhoria suficiente? O que o leitor acha de ter uma “página de notas de aula assim”? Os leitores querem saber como construo essas páginas?

Categorias
Artigos

Minha jornada em aprender R (ou: o conflito entre foco e exploração)

Eu me sinto em um conflito intelectual enorme entre dois aspectos de trabalho, simbolizados por duas grandes influências minhas: Cal Newport (foco e prioridade é tudo que importa) e Austin Kleon (como deve se expor ao máximo de influências e roubar delas para fazer a sua arte).

Exceto que este conflito não existe. Cal Newport lê no mínimo 5 livros por mês, sobre assuntos variados, e Austin Kleon fala da importância de desligar suas notificações e ter uma boa estação de trabalho onde se concentrar. O trabalho consiste em ciclos de se aprofundar e explorar.

O que me leva a um objetivo vago na minha vida profissional, que é aprender a linguagem de programação R, uma ferramenta bastante focada em estatística e ciência de dados.

Eu não consigo me lembrar como comecei a me interessar por isso, mas se fosse apostar, diria que foi quando Dr. Drang linkou algum post de Kieran Healy, um professor de Sociologia da Duke University que posta sobre como criar gráficos muito interessantes e ricos usando R . Isso deve fazer uns 5 anos, por volta de 2017.

Em 2019, quando comecei a utilizar bastante os conceitos de ciência de dados e quis aprender mais, comprei os livros da foto acima, mas nunca mergulhei de fato.

Nesse ano de 2022, decidi que era de mergulhar nisso. Mas aí está o problema: como vou priorizar isso dentro do meu problema de foco? Eu não preciso estudar R, e não vou ter proveito imediato.

Porém , foi numa tarde onde tirei uns 90 minutos para começar a ler o livro R for Data Science que me deparei com um exemplo do livro sobre dados experimentais de motores – uma biblioteca de R tem uma tabela já pronta. Por que essa minha empolgação? Porque eu ministro duas disciplinas sobre motores, e já consigo pensar em muitas maneiras de explorar esses dados na sala de aula. Sem essa perda de tempo brincando de estudar, eu talvez nunca teria chegado nesse exemplo.

Brincando com RStudio

Brincando em mais algumas sessões de trabalho, o resultado é saber produzir um gráfico como esse:

Aqui nós temos dados de alguns motores catalogados pela Agência de Proteção Ambiental dos EUA entre 1999 e 2008. Há uma tendência geral de queda da eficiência: motores maiores consomem mais combustível. Mas! Há outros fatores em jogo: a linha de tendência mais inferior mostra apenas veículos de tração nas 4 rodas, que são consistentemente menos eficientes que veículos de tração em 2 rodas (o leitor sabia disso?). Analisando por classes, vemos que na faixa de cilindradas maiores há exemplos de carros que são mais eficientes que outros: 2seaters, ou carros esportivos de 2 lugares. Esse veículos usam motores potentes, mas consomem menos que um SUV de mesmo tamanho, porque são mais leves, com menos perdas no sistema de transmissão; eu acredito também que o sistema de exaustão desses veículos esportivos faça diferença, com conversores catalíticos de parede metálica, mais fina, que têm menos perdas de potências (à custa de mais emissões).

Essa discussão de um parágrafo acima é muito útil para ser levada para a sala de aula. Eu perdi tempo estudando R?

Agora estou nessa situação; tirando algumas sessões de trabalho a cada mês para avançar na leitura desses livros, encaixando no meu planejamento semanal. Tenho sonhado em finalmente escrever apostilas de notas de aulas usando bookdown, de maneira que o código para resolver exercícios seja parte do texto, e divulgar essas notas de aula para o Brasil todo. O ecossistema de R põe muita ênfase na publicação e compartilhamento de dados – algo que não vejo em Python, por exemplo, daí o meu interesse em uma ferramenta nova (já que tenho usado Python para meus projetos científicos há mais de 1o anos).

Como a leitora faz para balancear entre o foco e a exploração? O leitor consegue achar tempo no meio da semana para simplesmente explorar algum assunto e “ver no que vai dar”?

Categorias
Artigos

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:

class InvalidParameterError(ValueError):
pass
from custom_errors import InvalidParameterError
def validate(p):
for k, v in p.items():
if v < 0:
emsg = "Parameter '%s' cannot be negative" %(k,)
raise InvalidParameterError(emsg)
import pytest
from custom_error import InvalidParameterError
from parse_parameters import validate
def test_negative_parameters_raise_error():
sample_params = {
'a': 1.43,
'b': 57,
'c': -10
}
with pytest.raises(InvalidParameterError) as excinfo:
validate(sample_params)
# The object returned by this pytest context manager
# has a 'value' field assigned to the exception object itself.
# In addition, all built-in exceptions derived from Exception
# have an 'args' tuple field assigned to the passed arguments.
# Hence, when we create a custom error with a string as the first argument,
# this string is assigned to the first element of the tuple 'args'
exception_msg = excinfo.value.args[0]
expected_message = "Parameter 'c' cannot be negative".
assert exception_msg == expected_message

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)

Categorias
Artigos

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:

cd $HOME/latex-writing/paper-magnetic-profiles/
# sync repo
git pull origin master
# open Visual Studio Code to edit and run scripts
code -n .
# Sourcetree is a Git client
SourceTree.exe
# we can also open reference files
start Outline_Paper_Profiles.pdf
# I prefer to use emacs for LaTeX files
emacs PaperMagneticProfiles_JBSMSE.tex
view raw start.sh hosted with ❤ by GitHub

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

# Sincroniza de volta mudanças feitas
git push origin
# ver explicações abaixo para esses comandos
cf PaperMagneticProfiles_JBSMSE.tex
closew "paper-magnetic-profiles - Visual Studio Code"
closew "Sourcetree"
closew "Outline_Paper_Profiles"
view raw stop.sh hosted with ❤ by GitHub

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

# function to close the buffer corresponding to a given file in emacs
# cf = close file
function cf() {
emacs -e "(if (get-buffer \"$1\") (kill-buffer \"$1\"))"
}

e closew é um comando que fecha janelas usando AutoHotKey:

; This script closes the window name passed as argument, e.g.
; AutoHotkey.exe closewindow.ahk "Visual Studio Code"
; To match strings anywhere in the window title
SetTitleMatchMode 2
If (WinExist(A_Args[1]))
WinClose

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.

Categorias
Artigos

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.

Categorias
Artigos

Uso básico de pytest e suas fixtures

Em primeiro lugar, o que diabos é pytest e por que eu me importo com isso?

A biblioteca pytest é um pacote de testes em Python. Para que serve? Como eu sei que tenho muitos leitores na área acadêmica, acho que vou me fazer entender: você escreve seus projetos de programação em Python, para simulação numérica de algum problema físico, para processamento de dados, para automatizar alguma tarefa, para gerar gráficos etc. Você vai aumentando o seu programa até que não tem mais certeza de como uma parte conecta com outra. Você adiciona uma função inofensiva, e então percebe que outra, “aparentemente” não relacionada, parou de funcionar. Os arquivos que eram para ser gerados não o são mais. Os gráficos saem esquisitos. Os resultados numéricos não fazem sentido.

Testes, nesse contexto de programação, são funções adicionais que asseguram o funcionamento correto do código. Se uma determinada função, quando executada, deve sempre gerar um arquivo results.txt, então você escreve um teste que executa a função e assegura que esse arquivo existe. A cada modificação no seu programa, você executa seu teste; se ele falha, é sinal de que é preciso parar, avaliar e corrigir erros.

Neste ambiente acadêmico em que estou, não vejo muita ênfase sendo colocada em testar o seu código, o que é um contrassenso. Testes têm um sentido científico: se eles passam, então a hipótese de que o você programou representa a realidade se torna mais forte. Eles não são “perda de tempo”; é bem fácil escrever rapidamente um programa que não funciona.

Tudo o que vou falar aqui se baseia nessa minha experiência: um pesquisador que usa de programas em Python como uma ferramenta para produzir conhecimento científico.

Instalação e uso básico

Para aplicações acadêmicas, especialmente em Windows, a melhor maneira de usar Python é através da distribuição Anaconda. A biblioteca pytest já está incluida.

No espírito acadêmico de transparência, vou compartilhar exatamente como tenho usado pytest para melhorar minhas práticas de programação e, com isso, produzir resultados científicos mais confiáveis.

Tenho um projeto chamado magnet3Dpolomag. Não se preocupem sobre o que é, apenas entendam como minha plataforma de testes está organizada:

Lista de diretórios de um projeto usando pytest
A propósito, esse screenshot é do Visual Studio Code

No meu diretório raiz, além de vários arquivos, existem essas duas pastas importantes: uma pasta com o pacote em Python, com seus vários módulos, e uma pasta de testes. O diretório do pacote Python é declarado como “importável” ao conter o arquivo de inicialização __init__.py. Assim, quando esse pacote é instalado, eu posso digitar simplesmente:

import magnet3Dpolomag

e tudo que estiver no arquivo __init__.py dentro da pasta magnet3Dpolomag vai ser carregado.

A convenção de testes em Python é usar nomes de arquivos que comecem com test_, e no momento eu só tenho um arquivo geral: dentro dele existem funções que testam o correto funcionamento de magnet3Dpolomag quando parâmetros válidos são fornecidos (testar se os parâmetros passados ao programa são válidos ou não é outra história).

Como um exemplo de teste, aqui está um pedaço do meu pacote: uma classe Magnet3DModel, com uma função que faz uma transformação de dados de simulações e retorna dois vetores:

import numpy as np

class Magnet3DModel:

    def get_profile_data(self, ):
        """Return phi, B vectors at the central plane"""
        
        middle_plane = self.z_profile_1q == 0
        phi_middle_plane_1q = self.phi_profile_1q[middle_plane]
        B_middle_plane_1q = self.B_profile_1q[middle_plane]
    
        phi_vector = np.concatenate((phi_middle_plane_1q,
                                 phi_middle_plane_1q + 90,
                                 phi_middle_plane_1q + 180,
                                 phi_middle_plane_1q + 270))

        B_profile = np.concatenate((B_middle_plane_1q,
                                B_middle_plane_1q[::-1],
                                B_middle_plane_1q,
                                B_middle_plane_1q[::-1]))

        return phi_vector, B_profile

Uma breve explicação: esse “modelo”, quando é executado, armazena uma nuvem de dados nos vetores z_profile_1q, phi_profile_1q e B_profile_1q. Para esse método em particular, estou apenas interessado nos dados que correspondem ao “plano” z_profile_1q == 0. O sufixo 1q indica que se trata de dados “no primeiro quadrante”; como os dados são periódicos, eu retorno os dados “expandidos”.

Eu quero me assegurar que, quando esse modelo é executado, essa função vai retornar esses vetores conforme esperado, com valores apenas numéricos:

import numpy as np
import magnet3Dpolomag

def test_can_access_magnetic_profile():

    m = magnet3Dpolomag.Magnet3DModel()
    # executa mais instruções para simular o modelo

    phi_profile, B_profile = m.get_profile_data()

    assert (
        np.isfinite(phi_profile).all() and 
        np.isfinite(B_profile).all()
    )

Repare na semântica do teste: ao escrever esse código, eu não tenho ideia de como get_profile_data() funciona; eu apenas sei que, quando eu executar o modelo, quero poder chamar uma função que me retorne esses vetores e que estes não tenham valores não-numéricos (que poderia surgir de algum erro). Para esse fim, eu uso a função isfinite() da biblioteca NumPy, que retorna um vetor booleano que checa exatamente isso; então, eu uso o método all() de vetores da biblioteca NumPy, que vai retornar True se todos os elementos são True.

A chave de uma função de teste é o comando assert; se o seu argumento é falso, então o programa para (ou, no caso, a função de teste falha). A biblioteca pytest tem como grande característica usar esse comando, que faz parte da linguagem Python “pura”, e reportar exatamente o que deu errado, no caso de uma falha.

Testes são executadas invocando pytest em um terminal. A partir do diretório onde é executado e varrendo os subdiretórios em todos os níveis, esse comando primeiro “descobre” os testes, arquivo que começam com test e, dentro deles, as funções e classes que começam com test_. Como quase tudo em se tratando de pytest, esse processo de descoberta de testes é configurável. A biblioteca então executa todos as funções e métodos de teste e reporta, de maneira muito inteligente, os testes que passaram e os que falharam.

Este exemplo pode parecer meio tolo, então quero enfatizar o grande propósito dessa minha discussão: escrever testes me ajuda a entender um código em Python que o meu de anos atrás escreveu, e me faz pensar sobre o que ele deve fazer.

Além disso, eu não vou estar nesse laboratório para sempre, e estes programas que eu crio para auxiliar no nosso projeto ficarão de legado para a minha equipe. Cada hora gasta trabalhando numa plataforma de testes pode não gerar resultados práticos agora, mas tem consequências futuras. Os financiadores do meu projeto atual não poderiam se importar menos se o meu código está bem testado, e talvez até achem que eu deveria estar fazendo outra coisa; mas aposto que eles ficam felizes quando a próxima pessoa que trabalhar nisso (eu mesmo eu, daqui a algumas semanas) não perder dias de trabalho tentando resolver um problema que poderia ter sido solucionando mais rapidamente executando a plataforma de testes e vendo qual parte do sistema está defeituosa.

Anteriormente escrevi que um das grandes sacadas de pytest é “turbinar” o comando `assert`. Outra grande sacada é o uso de *fixtures*: funções que auxiliam os testes. Não quero nesse post fornecer um tutorial de Python ou mesmo de pytest; quero apenas [documentar de maneira resumida como estou *aprendendo*][show] a escrever testes e motivar pesquisadores a fazer o mesmo. Além da documentação da biblioteca, [*Python Testing with pytest*][pytestbook] é bem bom. No exemplo que usei acima, eu apresentei uma função de teste que simula a execução do modelo e confere alguns dados gerados por ele. E se, com base na mesma execução do modelo, eu queira testar outras condições, como outros vetores e matrizes gerados, arquivos que devem ser gravados, parâmetros que devem ser armazenados? Esse é um exemplo clássico de *fixture*: uma função que não é um teste, mas que é executada antes dos testes, e que passa informações “compartilhadas” entre eles. Além disso, é possível repetir o mesmo teste várias vezes, checando por diferentes “coisas”. Por exemplo:

import numpy as np
import magnet3Dpolomag
import pytest
import math

@pytest.fixture(scope='module')
def run_model():

    m = magnet3Dpolomag.Magnet3DModel()
    m.run()

    return m

def test_can_access_magnetic_profile(run_model):

    m = run_model
    # executa mais instruções para simular o modelo

    phi_profile, B_profile = m.get_profile_data()

    assert (
        np.isfinite(phi_profile).all() and 
        np.isfinite(B_profile).all()
    )

@pytest.mark.parametrize(
     'result',
     [
         "Demagnetized fraction[%]",
         "Saturated fraction[%]",
         "V_gap[l]",
         "V_magnet[l]",
         "V_demag[l]",
         "V_magnetic_steel[l]",
         "V_sat_magnetic_steel[l]",
         "V_stator[l]",
         "V_rotor[l]"
     ]
 )
 def test_access_results(self, result, run_model):
    m = run_model
    r = m.get_results_series()[result]

   assert ( (math.isfinite(r)) and (r >= 0))

A função no início é uma fixture que simplesmente cria e executa o meu modelo e retorna esse objeto, já povoado com os dados de simulação. Essa função é decorada com pytest.fixture, com um argumento scope que define que ela é executada por módulo. Ou seja, para todos os testes que usam essa fixture e que estão definidos nesse módulo (script), o modelo só é executado uma vez e passa o seu estado para todos os testes. O primeiro teste mostrado repete a lógica do exemplo da seção anterior; o segundo é outro exemplo onde quero testar que uma função que retorna uma Series tem de fato todos os registros. Essa função é decorada com pytest.mark.parametrize, onde especifico que o parâmetro result da função de teste assume cada um dos valores especificados na lista. Quando é invocado, pytest faz o loop automaticamente, chamando esse teste tantas vezes quantos são os elementos da lista que define o parâmetro.

Conclusões

Leitores podem estar confusos com a quantidade de informações técnicas. Peço desculpas (mas não muitas); esse post foi a melhor maneira que eu encontrei para consolidar todo meu aprendizado recente no assunto.

O que os leitores acham de textos nesse estilo?

Categorias
Artigos

Trabalhando com PyCharm

2018-05-30 (1)

Um dia de trabalho típico (e um bom dia): programando em Python e plotando coisas no PyCharm.

A propósito: em 2018 eu finalmente parei de ser teimoso com a mentalidade de “uso apenas um editor de texto” ou “vou criar uns gráficos rápidos em Jupyter” para minhas tarefas que exigem programação. O PyCharm é fantástico para o meu fluxo de trabalho: lidando com módulos grandes, navegando entre classes e funções, executando scripts de pós-processamento. E eles oferecem gratuitamente licenças acadêmicas!