DEV Community: Ítalo Epifânio

Programação letrada com Jupyter Notebook e Nbdev

Ítalo Epifânio — Tue, 08 Nov 2022 21:44:49 +0000

O ambiente de desenvolvimento Jupyter notebook é muito popular entre a comunidade científica. Com essa ferramenta você consegue escrever texto em formato markdown e código Python (R ou Julia) no mesmo arquivo, algo que pode melhorar a legibilidade e entendimento do seu programa. Esse paradigma, que mistura texto e código, é chamado de programação letrada.

Um exemplo de Jupyter notebook pode ser vista na imagem abaixo:

Programação letrada é um paradigma muito bem conceituado, formalmente discutido por muitos pesquisadores respeitados mundialmente como o Donald Knuth. Ao mesmo tempo, Jupyter notebooks são considerados ineficientes para o desenvolvimento de software. Essa controversia levou a criação da famosa palestra "Eu não gosto de notebooks", respondida por outra palestra intitulada "Eu gosto de Jupyter notebooks" que gerou bastante drama na comunidade Python.

Jupyter notebooks tem sido limitados a exploração de dados, pequenos scripts e materiais educacionais. A recente introdução da Nbdev, uma biblioteca python, expandiu as possibilidades desses notebooks. Nbdev permite o desenvolvimento e distribuição de pacotes python enquanto se beneficia do paradigma de programação letrada, permitindo a execução de testes, documentação do software em tempo real (unindo texto e código), publicação da documentação como arquivos estáticos ou simplesmente o desenvolvimento de material técnico.

Nbdev permite que você conte uma história com o seu código. É uma ferramenta prática e poderosa!

Nbdev tem se provado útil no desenvolvimento de grandes e sérios projetos como o FastAi. A utilização da biblioteca Nbdev com Jupyter notebooks permite o desenvolvimento de softwares com qualidade e com os benefícios da programação letrada.

Experiência

Minha primeira experiência com Nbdev foi a de estranhamento. Trabalhar com Jupyter notebooks para desenvolvimento sério de software não me parecia natural, algo esperado, afinal é um novo paradigma de programação.

A ferramenta em que estou trabalhando atualmente, Ipyannotator, é um framework de anotações open source que contém interfaces gráficas que funcionam no Jupyter notebook. O desenvolvimento do Ipyannotator só foi possível graças a ferramenta Nbdev que permitiu o time testar o software em notebooks e exportar o código como uma biblioteca python.

Depois de um ano desenvolvendo software com Jupyter notebook eu sinto que isso melhorou minha produtividade

Esse paradigma de desenvolvimento de software me permitiu manter a minha documentação atualizada, uma vez que a documentação está naturalmente acima do meu bloco de código Python. O paradigma também reduziu o lapso mental de voltar a um código antigo, facilitando o entendimento do código uma vez que decisões prévias estavam documentadas em blocos markdown.

Quarto

No dia 28 de Julho, Nbdev lançou sua segunda versão, incorporando outra ferramenta open source no seu arsenal: Quarto. Quarto é uma ferramenta que permite a criação de conteúdo técnico utilizando Python, R ou Julia, utilizando diversos tipos de arquivo, seja markdown, Jupyter notebooks, R notebooks e permitindo exportar esses arquivos como arquivos, websites, blogs, HTML, PDFs, EPubs e até slides.

Quarto é uma solução completa para escrever qualquer material técnico, utilizando as ferramentas que você já conhece.

Essa ferramenta é tão legal que estou planejando migrar o meu blog pessoal de Jekyll para Quarto. O design clean, de fácil usabilidade e com a funcionalidade de executar código embutido em blocos de texto, se encaixa perfeitamente em qualquer requisito de escrita técnica.

Nbdev notou o quão poderoso Quarto pode ser. Essa adição do Quarto ao core do Nbdev ajudou a renderizar melhor sites e documentações. A primeira versão da biblioteca Nbdev já continha essas funcionalidades, mas elas eram rudimentares e precisavam de diversas gambiarras.

Conclusão

Desenvolvimento com Nbdev e Quarto pode melhorar a produtividade de diversos times, ajudando a documentar e contar a história do seu código. Essas ferramentas ajudam a expandir as possibilidades de desenvolvimento de software, assim como foi o caso do já exemplificado Ipyannotator.

Como qualquer ferramenta, Nbdev também tem lados negativos. Um deles é a falta do auto completar em Jupyter notebooks, algo que pode ser remediado com a utilização de extensões do Visual Code, por exemplo. Outro problema é que, por conta dos Jupyter notebooks serem escritos em formato json, um formato que dificulta a resolução de conflitos git por conta de todos os metadados extras. Dificultar a resolução de conflitos minimiza as chances de grandes equipes de trabalhar no mesmo software.

Felizmente, a adição de Quarto mostra que Nbdev já planeja dar suporte a outros tipos de arquivos além de Jupyter notebooks. Isso permitiria que times maiores conseguissem desenvolver software com programação letrada, diminuindo o maior defeito da ferramenta, que é a resolução de conflitos.

Se você se interessou em tentar usar Nbdev você pode checar as seguintes referências:
Nbdev+Quarto: Uma nova arma secreta de produtividade.

Se ficou curioso sobre como é o código Jupyter notebook para desenvolvimento de software você pode olhar o código do Ipyannotator.

Post originalmente postado no blog Palaimon: https://blog.palaimon.io/posts/literate-programming-nbdev/

Objetos hashable em Python

Ítalo Epifânio — Sun, 24 Jul 2022 23:33:00 +0000

Hash de objetos é uma representação númerica inteira que é obtida utilizando o dunder method __hash__. Compreender esse conceito ajuda a entender como as estruturas de dados Python funcionam, uma vez que o hash dos objetos são utilizados internamente pela linguagem.

Programadores Python costumam se deparar com o conceito de hash de objetos quando tentam armazenar um objeto sem hash em uma estrutura de dados da linguagem. Por exemplo:

from dataclasses import dataclass

@dataclass
class Pessoa:
    nome: str
    cpf: str

p = Pessoa(nome="Ítalo Epifânio", cpf="1010101010")
pessoas = set()
pessoas.add(p)

O código acima define uma classe pessoa e um objeto p do tipo pessoa. Ao tentar adicionar uma pessoa ao conjunto pessoas o seguinte erro é lançado:

Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: unhashable type: 'Pessoa'

Isso acontece porque a estrutura de dados "conjunto" do Python utiliza o hash em suas tabelas internas para encontrar o valor do objeto rapidamente. Como nosso objeto não tem hash, o erro acima é lançado.

Para adicionar um hash a um objeto implementa-se as funções __hash__ e __eq__ simultaneamente (caso esteja utilizando Python 2 a função __ne__ também deve ser adicionada). No exemplo a seguir modificamos nossa classe anterior para adquirir essa propriedade.

@dataclass
class Pessoa:
    nome: str
    cpf: str

    def __hash__(self):
        return hash(self.cpf)

    def __eq__(self, other):
        mesma_classe = self.__class__ == other.__class__
        mesmo_cpf = self.cpf == other.cpf

        return mesma_classe and mesmo_cpf

p = Pessoa(nome="Ítalo Epifânio", cpf="101.010.101-01")
pessoas = set()
pessoas.add(p)

Agora o código consegue ser executado sem o erro anterior. Se executarmos print(pessoas) veremos que o conjunto contém o seguinte valor:

{Pessoa(nome='Ítalo Epifânio', cpf=1010101010)}

Um objeto é dito hashable se o valor de hash nunca é modificado durante sua fase de vida
-- Python Docs

Apenas implementar os dunder métodos acima não garante que o objeto é hashable. É preciso garantir o valor de hash desse objeto jamais sejá alterado pois isso pode levar a comportamentos não esperados, por exemplo:

p = Pessoa(nome="Ítalo Epifânio", cpf="101.010.101-01")
pessoas = set()
pessoas.add(p)
print(p in pessoas) # retorna True
p.cpf = "999.999.999-99"
print(p in pessoas) # retorna False
print(pessoas) # retorna {Pessoa(nome='Ítalo Epifânio', cpf='999.999.999-99')}

Ao alterar o cpf do objeto p note que o objeto não é mais encontrado na estrutura de dados conjunto (a segunda chamada do print(p in pessoas) retorna falso) e quando lista-se os valores do conjunto pessoas nota-se que há ainda um valor lá.

Em resumo: você não pode basear hash de objetos em valores mutáveis. Se o atributo de um objeto pode ser modificado durante seu ciclo de vida comportamentos inesperados podem acontecer.

Horizontal scroll with lazy loading

Ítalo Epifânio — Sun, 31 Oct 2021 20:14:19 +0000

Recently I came across with the following scenario: a management software of workflows that allow the user to dynamic create its kanbans (like the one in the image below). One of the users set its kanban to have 38 columns.

The software was design in a way that every kanban column made a request to the backend, in this scenario 38 new requests were made every time a user access the kanban page. This not only overload the server but also the database.

First we needed to decrease the number of requests, limiting the requests to the columns that were visible to the user. After that we had to make sure that if the user scrolls to the end of the page at once, the columns would not request the data unless they were visible for a certain amount of time.

Limiting loading to visible cards

Javascript offers an API called IntersectionObserver that allow us to watch HTML elements and check its visibility on screen. The code below shows its most basic operation.



const onIntersection = (elements) => {
    elements.forEach(element => {
      if (element.isIntersecting) {
          console.log(element, 'is visible');
      }
  });
};

const observer = new IntersectionObserver(onIntersection);

observer.observe(document.querySelector('.my-elements'));

The function onIntersection is responsable for the logic that will be applied to the visible elements, it takes a list of elements and checks that if they're visible (element.isIntersecting) then something will be done, in which case a console message is displayed.

The IntersectionObserver API call is made and set to the observer variable. The observer object will then be able to observe elements in the HTML and execute logic only when they are visible on the user's screen. In my case, for the giant kanban, this was enough to limit the 38 requests as the page loaded to just 5, but if the user scrolled the page to its end at once several requests would be made (the other 33 requests).

Load only after a certain time of the visible element on the page

The IntersectionObserver API has a version 2 that allows capturing how long a certain HTML element was visible on the screen and this would easily solve the element loading problem HTML only after a certain amount of time. However, version 2 still doesn't have its implementations compatible with most browsers.

In my specific case I was using a parent component that rendered the 38 child elements and I couldn't check when those 38 child elements were finished rendering to observe them with the InsertersectionObserver, so control how long each element was visible in the screen got a little more complicated.

Each of the 38 child elements knew when they were rendering themselves, so you could use the IntersectionObserver internally on each of them. Using the setTimeout function of the javascript you can observe the element after a certain time specified in milliseconds.

We have 38 elements, but most are not visible on the screen and become visible when scrolling, with the setTimeout delay this action still takes some time to be executed. During scrolling, when the element visible on the screen has not yet triggered the specified setTimeout and the user has already scrolled to the next element, it is possible to remove the timeout of the previous element from the stack and then load only the next element. The following code shows this strategy.



<div class="border border-black m-1 p-10 min-w-max h-10"
       x-data=""
       x-init="() => {
           let timeout;
           let loadColumn = function (elements) {
               clearTimeout(timeout);

               timeout = setTimeout(function() {
                   elements.forEach(element => {
                       if (element.isIntersecting) {
                           // do something
                           observer.unobserve(element.target);
                       }
                   });
               }, 750);
           }

           let observer = new IntersectionObserver(loadColumn);
           let target = $el;
           observer.observe(target);
       }">
  </div>

When the component is loaded into the page it already starts looking at itself using the loadColumn function. Such function removes the previous timeouts (which were not triggered) from the execution stack and adds a new timeout which after 750 milliseconds does something and removes the observation to not redo the same logic if the element becomes visible again.

In my case the logic was the request to the server so I only needed to load the data once and then ignore it if the element was visible again on the page.

Did you find the above code syntax strange? This javascript microframework is called AlpineJS and that's what I used to develop the complete solution.

A simpler POC, without the request to the server, can be seen below. After being visible on your screen the white squares will turn black indicating the request to the server.

If you are interested in seeing a solution with vanilla javascript this was my reference.

Carregamento lento com scroll horizontal

Ítalo Epifânio — Wed, 13 Oct 2021 03:50:31 +0000

Recentemente me deparei com o seguinte cenário: um sistema de gerenciamentos de fluxos de trabalho que permite configuração de kanbans, como o da imagem abaixo, sendo que um usuário em particular configurou seu kanban com 38 colunas.

Cada coluna do kanban realizava uma requisição e do jeito que o sistema tinha sido desenvolvido gerava-se 38 requisições assim que a página era carregada, o que acabava espancando o banco de dados e o servidor.

Inicialmente precisavamos diminuir a quantidade de requisições, limitando apenas aos cards visíveis na tela do usuário. Depois precisavamos fazer com que, caso o usuário rolasse para o fim da página de uma vez, as colunas que ficaram visíveis não carregassem a menos que estivessem a um certo tempo visíveis.

Limitando o carregamento aos cards visíveis

O javascript oferece uma API chamada IntersectionObserver que permite monitorar elementos HTML e verificar sua visibilidade na tela. O código abaixo mostra o funcionamento mais básico dela.

const onIntersection = (elements) => {
    elements.forEach(element => {
      if (element.isIntersecting) {
          console.log(element, 'is visible');
      }
  });
};

const observer = new IntersectionObserver(onIntersection);

observer.observe(document.querySelector('.my-elements'));

A função onIntersection é responsável pela lógica que será aplicada aos elementos visiveis, ela recebe uma lista de elementos e verifica que se forem visiveis (element.isIntersecting) então algo será feito, nesse caso uma mensagem no console é exibida.

A chamada da API IntersectionObserver é feita e atribuida a variável observer. O objeto observer conseguirá a partir dali observar elementos no HTML e executar uma lógica somente quando eles forem visíveis na tela do usuário. No meu caso, do kanban gigante, isso foi suficiente para limitar as 38 requisições assim que a página carregava para apenas 5, mas caso o usuário rolasse a página rapidamente várias requisições seriam feitas, ou seja, se eu fosse até o fim da página de uma vez as outras 33 requisições seriam chamadas também de uma vez só.

Carregamento apenas após certo tempo do elemento visível na página

A API IntersectionObserver tem uma versão 2 que permite a captura de quanto tempo um certo elemento HTML ficou visível na tela e isso resolveria facilmente o problema de carregar o elemento HTML apenas depois de certo tempo. Entretanto, a versão 2 ainda não tem suas implementações compativeis com a maioria dos navegadores.

No meu caso específico eu estava utilizando um componente pai que renderizava os 38 elementos filhos e eu não conseguia verificar quando esses 38 elementos filhos terminaram de ser renderizados para observa-los com o InsertersectionObserver, então controlar o tempo que cada elemento ficou visível na tela ficou um pouco mais complicado.

Cada um dos 38 elementos filhos sabiam quando eles mesmos eram renderizados, então conseguia-se utilizar a IntersectionObserver internamente em cada um deles. Utilizando a função setTimeout do javascript consegue-se observação o elemento após um certo tempo especificado em milisegundos.

Temos 38 elementos ao todo, só que a maioria não é visível na tela e se torna visível ao scrollar, com o delay do setTimeout essa ação leva ainda algum tempo a ser executada. Durante o scroll, quando o elemento visível na tela ainda não disparou o setTimeout especificado e o usuário já scrollou para um elemento seguinte consegue-se remover o timeout do elemento anterior da pilha de execução e então carregar somente o elemento seguinte. O código a seguir mostra essa estratégia.

<div class="border border-black m-1 p-10 min-w-max h-10"
       x-data=""
       x-init="() => {
           let timeout;
           let loadColumn = function (elements) {
               clearTimeout(timeout);

               timeout = setTimeout(function() {
                   elements.forEach(element => {
                       if (element.isIntersecting) {
                           // do something
                           observer.unobserve(element.target);
                       }
                   });
               }, 750);
           }

           let observer = new IntersectionObserver(loadColumn);
           let target = $el;
           observer.observe(target);
       }">
  </div>

Quando o componente é carregado na página ele já começa a observar a si mesmo utilizando a função loadColumn. Tal função remove os timeouts anteriores (que não foram acionados) da pilha de execução e adiciona um novo timeout que após 750 milisegundos faz algo e remove a observação para não refazer a mesma lógica se o elemento se tornar visível novamente.

No meu caso a lógica era a requisição para o servidor então eu só precisava carregar o dado uma vez e depois ignorar se o elemento ficasse visível novamente na página, por isso ele remove a própria observação.

Achou a sintaxe do código acima estranha? Esse microframework javascript se chama AlpineJS e foi o que utilizei para desenvolver a solução completa. Uma POC mais simples, sem a requisição pro servidor, pode ser vista logo abaixo. Após ficar visível na sua tela os quadrados brancos se tornarão pretos indicando a requisição pro servidor.

Caso se interesse por ver uma solução com vanilla javascript a minha referência foi essa.

TALL - Uma nova stack para PHP

Ítalo Epifânio — Sat, 20 Jun 2020 02:03:18 +0000

Tailwind, Alpinejs, Laravel e Livewire (TALL) é uma solução para desenvolvedores full stack construída pela comunidade laravel que foca principalmente no desenvolvimento backend, mas que permite o desenvolvimento de sistemas ditos "reativos".

A stack TALL é ótima para desenvolvimento rápido de sistemas web. A facilidade de estilizar páginas com o Tailwind, o poder da reatividade do Alpinejs, aliado com a componentização do Livewire, realmente dá um boost de produtividade no desenvolvimento.

Nesse artigo falarei um pouco sobre as 4 tecnologias e minha experiência com a stack.

Livewire

É muito comum encontrar sistemas que utilizam Laravel em conjunto com o Vuejs. A utilização de componentes Vue remove muito da responsabilidade da blade, por exemplo, é comum encontrarmos blades do tipo:

@extends(‘layouts.base’)

@section(‘content’)
    <some-vue-component></some-vue-component>
@endsection

Caleb, criador do Alpinejs e Livewire, chama esses componentes de "assassinos de blades". Vue é uma ferramenta poderosa, mas o tempo gasto tratando eventos assíncronos, adicionando v-ifs, atualizando bibliotecas, atrasa o desenvolvimento e torna a experiência um pouco maçante. Parte do atraso mencionado se deve a falta de testes unitários, eu, particularmente, não conheço ninguém que utilize testes unitários com Vue e isso é bem problemático quando encontramos blades e blades como a exibida acima.

Quanto mais se trabalha com Vue e Laravel mais sentimos a necessidade de escrever um código javascript melhor, aprender Vuex, utilizar testes unitários nele usando Jest ou outra lib. Vamos adicionando camadas e camadas de complexidade para algo que deveria ser simples: requisição e exibição de dados (o pior dos casos é quando regra de negócio entra em front-end, debugar um erro em um código assim é uma grande dor de cabeça).

Caleb propõe uma solução voltada mais ao backend, intrínseca ao Laravel, o Livewire. É difícil definir a ferramenta, mas é como se escrevessemos código Laravel como componentes. A definição oficial é: Livewire is a full-stack framework for Laravel that makes building dynamic interfaces simple, without leaving the comfort of Laravel..

O Livewire é ótimo para situações em que o nosso usuário interage com a tela e espera uma ação imediata, ele irá fazer uma requisição ajax e atualizar o front automaticamente (como se a página fosse reativa). Um exemplo, visto abaixo, retirado do artigo do Branick.

O Livewire é uma ferramenta muito poderosa que permite reaproveitar código através dos componentes, além de facilitar e agilizar o desenvolvimento de interfaces ricas, sem ter que chamar bibliotecas JS externas, sem sair do arcabouço Laravel e podendo realizar testes unitários nos componentes. Entretanto todas essas facilidades tem um preço, que é o custo de renderizar novamente HTML toda vez que se faz uma requisição. O Livewire não é uma “bala de prata” e deve ser utilizado com cautela.

Tailwind

O Tailwind é um framework CSS com uma abordagem utility-first
, o código CSS é abstraído no HTML como classes. Por exemplo, o código <div style="background-color:black; border-radius: 100%"></div> no Tailwind ficaria <div class="bg-black round-full"><div>.

O primeiro contato com o framework é estranho porque o HTML se torna extenso de escrever, mas a medida que vamos utilizando vemos o quão ágil é utilizar o Tailwind. As páginas são escritas eficientemente, se inspeciona elemento, muda as classes, copia para o código e em minutos você tem algo funcional que levaria mais tempo para fazer utilizando Bootstrap.

Esse esquema quase de prototipação de páginas é ótimo para fábricas de software. Uma vez que os desenvolvedores pegam o jeito como o framework se torna fácil pegar um design do Adobe XD e dar vida no HTML.

AlpineJS

O Alpinejs é um microframework JS, reativo, muito parecido com Vue (só que bem mais simples) que facilita manipulações do DOM. Por ter sido criado pela mesma pessoa, o Alpinejs funciona muito bem com integrações com o Livewire. Todos os gargalos de performance encontrados no Livewire eu consegui contornar utilizando o Alpine em conjunto.

Um exemplo de utilização do Alpine em conjunto com o Tailwind pode ser visto abaixo. Note que o código HTML mantém a estilização e o JS embutido, é muito simples e rápido estilizar e modificar o DOM utilizando as duas ferramentas em conjunto.

A curva de aprendizado do framework é muito baixa porque ele é bem pequeno, além de procurar se aproximar bastante da sintaxe do Vue (velho conhecido dos devs fullstack Laravel).

Conclusão

Estou trabalhando com a stack a cerca de três ou quatro meses, escrevendo uma nova versão de um sistema que antes era feito com Laravel e Vue. O design foi criado no Adobe XD e em questão de uma a duas semanas já tínhamos passado completamente pro Tailwind. A utilização do Livewire foi feita a medida da necessidade, em geral, situações que exigiria requisições ajax ou que apelariamos para o Vue, se tornaram componentes Livewire.

A impressão é que o novo sistema de componentes blade do Laravel 6 e as novas funcionalidades do Laravel 7 também colaboraram muito para essa nova forma de escrever sistemas, tornando natural codar no Laravel componentizado e associar o Livewire nas blades.

No começo do projeto eu não conhecia Livewire, Alpinejs e nem o Tailwind, mas é muito bom sair do conforto com esses três. Como o Tailwind é mais "baixo nível" que o Bootstrap eu acabei aprendendo flexbox e vários outros detalhes de CSS que eu desconhecia. O mesmo aconteceu com o Alpinejs, por ser pequeno boa parte do código feito com ele é JS puro.

O Tall potencializa as tecnologias básicas que usamos no dia a dia (JS, CSS, PHP) tornando o desenvolvimento bem mais divertido e sem necessidade de adicionar bibliotecas terceiras que acabam complicando a manutenção posterior do sistema. Além disso, o que mais curto na stack, é que se aproveita ao máximo o uso do Laravel.

Uma visão geral sobre Alpine.js + Tailwind

Ítalo Epifânio — Sun, 03 May 2020 01:11:46 +0000

Alpine.js é um framework reativo como o Vue e o React só que com um custo mínimo, zipado o alpine ocupa 4Kb. Para quem programa e utiliza Vue a sintaxe é praticamente a mesma, como o próprio autor aponta na documentação.

Recentemente comecei a trabalhar com o Tailwind, um framework css de "baixo nível" que utiliza classes como açucar sintático para o puro css. A primeira coisa que pensei quando conheci a ferramenta foi "por que alguém se submeteria a escrever tanta coisa no html?", veja, o código parece sujo no começo, mas os componentes pre-desenhados, o esquema de responsividade deles (melhor até que o do bootstrap), além do código estupidamente explicito, me ganhou. As telas realmente são feitas mais rapidamente e eu não tenho mais que parar, ir numa folha de estilo, procurar qual parte do código tá modificando aquilo, caçar se outra folha está sobrescrevendo o estilo, etc.

O Alpine.js é como o tailwind, deixa explícito o que está sendo feito, a curva de aprendizado é muito curta e é ótimo para ser utilizado em conjunto com o Tailwind. Abaixo o código de um simples todo list feito com o micro framework:

No exemplo são utilizados conceitos simples, o x-data="{ items: [], item: '' }" declara um escopo pro componente, como se fosse uma variável. O x-for cria o dom dinamicamente iterando sobre a variável items. O x-model conecta as modificações do input com a variável item e o @click ativa o evento que insere um valor no item.

Eu realmente estou gostando de trabalhar com ambas as ferramentas e acho que ambas me tiraram da zona de conforto das camadas de abstrações que outros frameworks oferecem, então você realmente aprende css e js utilizando o alpine + tailwind. O projeto que me fez conhecer essas tecnologias utiliza o Laravel (framework PHP) com o Livewire (uma abstração do laravel que componentiza código PHP), tailwind e alpine js, uma stack para ser comentada em outros posts.