DEV Community: Yuri Ximenes Martins

arXiv: 3 boas alternativas

Yuri Ximenes Martins — Tue, 12 Dec 2023 14:16:37 +0000

Introdução

Para as pessoas ligadas à pesquisa na área de exatas, certamente o arXiv é um ambiente muito visitado.

Para aqueles que não conhecem, o processo de validação da pesquisa é feita mediante publicação de artigos científicos em revistas científicas.

Normalmente a versão final fica retida pelas revistas, o que pode impedir o acesso a esse conhecimento por parte de outras pessoas (sobre esse ponto, veja meu desabafo nesse outro post). O que se costuma fazer é divulgar uma versão preliminar do trabalho, conhecida como "pré-print".

ArXiv é o repositório "padrão" na área de exatas para armazenamento de pré-prints. No entanto, como veremos abaixo, existem outros repositórios igualmente importantes. Dois deles não são tão conhecidos, especialmente aqui no Brasil.

Por que fugir do ArXiv?

Diferentemente das revistas científicas, o arXiv não se propõe a fazer um processo de revisão dos trabalhos, mas apenas uma moderação básica para evitar a introdução de trabalhos totalmente aleatórios. As regras de tal processo podem ser encontradas aqui.

Por experiência própria, tenho alguns questionamentos a respeito da conduta da moderação utilizada no arXiv. Não só eu, mas outras pessoas também têm enfrentado alguns problemas. Deixo para falar disso, em detalhes, num próximo post.

Por hora, me resumo a dizer que acho importante haver uma maior distribuição dos pré-prints para haver uma descentralização do "poder" nas mãos de um só repositório.

Assim, a questão não é "fugir" do arXiv, mas não depender completamente dele.

Outro ponto a ser levantado é que o arXiv só aceita pré-prints que, segundo os critérios dele, tem um potencial de serem publicados em alguma revista científica. Isso, em tese, descarta notas de aula, slides de apresentações e outros tipos de recursos interessantes. Há uma preferência, também, por trabalhos em Inglês.

Alternativas

Apresento três alternativas:

HAL.
- Trata-se de um repositório Francês, criado pelo Center for Direct Scientific Communication.
- Além de pré-prints, recebe também slides de apresentações e notas de aula.
- Aceita submissões em diversos idiomas, incluindo o Português.
- Os trabalhos passam por um processo de moderação mais "brando" do que o do arXiv.
Zenodo.
- Repositório mantido pelo CERN e OpenAIRE. Para quem não sabe, CERN (European Organization for Nuclear Research) é o maior centro de pesquisa mundial na área de Física Nuclear. É deles a responsabilidade do LHC (Large Hadron Collider), de onde saem as mais importantes descobertas do mundo sub-atômico. Foi no CERN que as primeiras ideias sobre internet foram levantadas (veja aqui).
- Aceita, além de pré-prints, slides de apresentações, notas de aula, e outros formatos.
- Também aceita trabalhos em diferentes idiomas, incluindo o Português.
- O processo de moderação é mais "brando" se comparado com o do arXiv.
- É possível criar "grupos", nos quais diferentes pessoas podem colocar seus trabalhos.
Repositórios no Github, Gitlab ou Codeberg.
- Uma terceira alternativa simples é manter seus trabalhos hospedados em repositórios versionados em git.
- A desvantagem é falta de "reconhecimento" por parte da academia se comparado com algo incluído no arXiv ou nas alternativas acima.
- Nessa opção não há uma restrição quanto ao tipo de conteúdo a ser introduzido ou ao idioma.
- Não há processo de moderação.

Fim

ArXiv é o padrão. No entanto, existem opções tão boas quanto.

Você já conhecia essas alternativas?

Até mais,

Yuri.

Sobre a validação da pesquisa, Qualis Capes e as grandes empresas de editoração: um desabafo

Yuri Ximenes Martins — Mon, 11 Dec 2023 18:38:10 +0000

Introdução

Nos últimos anos dediquei boa parte da minha vida e de minha saúde para o desenvolvimento de pesquisa nas áreas de Física e Matemática. No entanto, sinto que, depois de bastante cansado, minha dedicação não valeu tanto a pena.

Acredito que grande parte da minha frustração se deva ao processo de validação da Ciência como é adotado no Brasil e no mundo. No presente artigo, apresento algumas reflexões e alguns pontos de descontentamento.

Não sou nenhum grande pesquisador e, portanto, minha pequena opinião não possui peso algum. No entanto, depois de me distanciar um pouco do meio acadêmico e poder ver a situação de forma mais panorâmica, não consigo deixar de levantar meus questionamentos.

Qualis, Scimago e segregação científica

Caso não saibam, ao se desenvolver uma pesquisa, o processo de "validação" pelo meio acadêmico se dá pela publicação desta, no formato de artigos científicos, em revistas científicas consideradas "bem avaliadas".

Aqui no Brasil, o critério de avaliação é normalmente baseado em uma nota dada pela Capes (Qualis Capes - veja aqui) à cada revista. Fora do Brasil utiliza-se outras classificações, como a Scimago (veja aqui).

Assim, no Brasil, para que sua pesquisa seja considerada validada, ela deve ter sido publicada em revistas com boa nota Qualis Capes. Essa nota é levada em consideração em processos seletivos de docentes em universidades públicas, bem como em sua progressão depois de concursados. Ela também é levada em consideração por agências de fomento, que liberam recursos financeiros para que novas pesquisas sejam realizadas, o que inclui, por exemplo, bolsas de pesquisa.

Fato é que muitas revistas consideradas muito boas pela Scimago não estão listadas no Qualis Capes, o que significa que publicar nelas não trará tanto impacto e valorização de seu trabalho mediante agências de fomento aqui no Brasil. Isso induz uma segregação que força com que trabalhos sejam publicados majoritariamente em revistas pré-definidas.

As revistas são catalogadas na Qualis por demanda: se há bastante gente publicando em uma revista não listada, em uma revisão futura eles podem acrescentá-la. Note, no entanto, que para que novas revistas sejam incluídas, é necessário que um grupo de pessoas se disponha a "remar contra a maré", publicando trabalhos em revistas não listadas, o que lhes confere o risco de terem um trabalho não validado.

Existem revistas de cunho geral e revistas de cunho específico. Revistas gerais aceitam a submissão de trabalhos de diversas áreas dentro de uma dada disciplina. Revistas específicas são mais focadas em determinadas áreas. Grande parte das revistas gerais consideradas boas pela Scimago estão listadas no Qualis. A discrepância maior se dá quando se fala de revistas especializadas.

Deve-se notar que revistas de cunho geral tendem a ser bem mais concorridas que revisas especializadas. Afinal, aceitam trabalho de diversas áreas.

Considere, agora a seguinte situação. Um grupo de pesquisa emerge no Brasil em uma área ainda não consolidada. Naturalmente, os primeiros trabalhos não são tão fortes, uma vez que o grupo ainda está em seu início. A escolha natural de revistas para submeter seus trabalhos são revistas especializadas, as quais, infelizmente, estão fora do Qualis. Isso significa que, das duas uma:

o grupo tenta remar contra a maré, publicando seus trabalhos em boas revistas especializadas fora do Qualis, torcendo para que em uma próxima revisão as revistas naturais de seu meio sejam incluídas;
o grupo publica seus trabalhos em revistas gerais, menos qualificadas, mas listadas no Qualis.

Compare a situação com um grupo de pesquisa em uma área já consolidada. A conclusão certamente será a de que há uma maior chance de que este sobreviva ao longos dos anos.

Retrato minha situação pessoal. Minha pesquisa se concentra em temas ligados à processos de abstração, com foco na área de Teoria das Categorias. Existem poucas pessoas que trabalham na área no Brasil (e no mundo, se comparado com outras áreas da Matemática). Consequentemente, existem poucas revistas listadas no Qualis que sejam especializadas no assunto. Publicar sobre o tema em revistas boas, de cunho geral, é bastante difícil, pois se está concorrendo diretamente com áreas mais "visadas".

Em minha experiência pessoal, tive bastante dificuldade de alocar meus trabalhos em boas revistas dentro do Qualis. Alguns foram publicados em revistas especializadas consideradas boas pelo Qualis, mas em áreas correlatas. Por conta disso, precisei modificar o trabalho direcionando-o para outra área. Outros foram publicados em revistas gerais, considerados razoáveis pelo Qualis. O restante, depois de diversas manobras, acabou ficando como pré-print.

Springer, Elsevier, Wiley e direitos de divulgação

Outro ponto a ser levantado é que as revistas tipicamente considerados "de qualidade" estão concentrados nas mãos de grandes empresas de editoração, como Springer e Elsevier.

Nós, pesquisadores, escrevemos artigos científicos e os submetemos para as revistas, isto é, para as empresas. As revistas (isto é, as empresas) recebem os trabalhos, os distribuem para pesquisadores cadastrados (considerados "revisores") e chamados de reviewers (juízes, em tradução livre), os quais irão dizer se o trabalho é digno de ser publicado ali ou não.

Durante o processo de publicação, transfere-se o direito de distribuição da versão final de seu trabalho à empresa, de modo que ela pode vender seu acesso a outros pesquisadores e instituições de ensino.

Você deve estar pensando:

poxa, mas então um pesquisador deve ganhar bastante dinheiro publicando trabalhos. Os revisores também devem ganhar um bom dinheiro por revisar.

Fato é que os pesquisadores e os revisores não recebem nada além de prestígio, enquanto que as empresas faturam com a venda de seus trabalhos. Tratam-se de empresas multi-bilionárias: em 2020, Elsevier, Springer e Wiley tiveram faturamentos de $3,79 bi, $2,03 bi e $0,97 bi, respectivamente (veja aqui, aqui e aqui).

Na verdade, a situação piora.

Gold Open Access

Durante muitos tempo, antes da consolidação da internet, os principais as revistas científicas eram assinadas especialmente por bibliotecas. Com o avanço da internet e a popularização de uma facilidade de acesso à informação, o fato das publicações em revistas científicas serem acessíveis somente à assinantes levantou sérios questionamentos.

Note que as empresas faturam justamente com o acesso à informação. Se após aceitos os trabalhos ficassem disponíveis para quem quisesse vê-los, a fonte de lucro se esgotaria. Pois as empresas tiveram uma grande ideia:

oferecer ao autor do trabalho a possibilidade de pagar um valor (extremamente alto) para que, depois de publicado, seu artigo fique disponível a todos.

Certamente o pesquisador vai querer que outras pessoas tenham acesso a seus trabalhos, o que faz que busque recursos em agências de fomento à pesquisa. As agências passam, então, financiar a disponibilização de pesquisas que elas mesmas já custearam antes.

Sim, os pesquisadores cedem o direito sobre seus trabalhos e pagam para que esse conhecimento seja acessível a todos.

Me pergunto, seriamente, se existe uma lógica por de trás desse processo.

Revistas Predatórias

Normalmente o processo de publicação de um trabalho, desde a etapa de submissão até seu aceite e divulgação na página da revista, leva alguns meses ou anos (a depender da revista). Sim, o pesquisador faz sua pesquisa, paga (os órgãos de fomento de sua pesquisa pagam - e caro) para que, caso seja aceito, seu trabalho fique disponível a todos, e ainda precisa esperar vários meses (não raro alguns anos) para que um desfecho seja dado.

De olho nessa demora e no dinheiro envolvido, muitas empresas decidiram criar revistas "fantoches", com um processo de revisão mal feito (ou mesmo sem revisão, em alguns casos), nas quais o trabalho é aceito e publicado dentro de poucos dias. Tais empresas coletam indevidamente o email de pesquisadores em diversas plataformas da internet e disparam emails sucessivos oferecendo publicações rápidas. O preço? Alto, é claro.

Pela prática que empregam, tais revistas são consideras "predatórias" (veja aqui). Uma tentativa de tentar identificá-las é através dos critérios de Bell. Para uma lista atualizada das revistas que se enquadram em tais critérios, veja aqui.

Green Open Access

Existem, no entanto, revistas que, verdadeiramente, remam contra a maré. Normalmente ligadas à alguma instituição de ensino, fazem um processo de revisão criterioso e não cobram nada por isso. O problema? Bem, poucas pessoas lutam contra a maré. Isso significa que poucas pessoas publicam em tais revistas, o que por sua vez implica que elas normalmente não estejam listadas no Qualis. E a história toda continua...

Fim

Decidi não compactuar mais com esse comércio. É uma questão ideológica. Eu havia submetido alguns trabalhos para revistas conhecidas. Dois foram aceitos. Depois de pensar, decidi não publicá-los nelas. E assim pretendo continuar. Caso julgue que um trabalho valha uma publicação, o submeterei para revistas verdadeiramente Open Access, cunho verdadeiro intuito é a validação e a distribuição de conhecimento.

Julguem-me todos, mas nessa não caio mais.

Até mais,

Yuri.

Failed Dependency! Instabilidade e TTL no Codeberg Pages

Yuri Ximenes Martins — Wed, 29 Nov 2023 14:05:38 +0000

Introdução

Codeberg é uma alternativa gratuita e open-source ao Github/Gitlab, a qual oferece uma plataforma para gerenciamento de repositórios git (veja esse post). Lá você também pode hospedar um site estático de forma bastante simples no que é chamado de Codeberg Pages, serviço análogo ao Github/Gitlab Pages, conforme discutido nesse post.

Erro 1

Suponhamos que você utiliza o Codeberg Pages e, na maioria dos casos, sua página carrega normalmente (com domínio personalizado ou não). No entanto, em algumas raras situações, ao tentar acessar sua página, você se depara com o erro

Failed Dependency! (...) could not find target for custom domain.

Nesse caso, não se desespere! O servidor que mantém o Codeberg Pages passa, vez ou outra, por instabilidades. Lembremos que é um serviço gratuito, com foco total em projetos open-source, e mantido por doações (veja aqui), algo que não pode ser comparado com o GitHub (o qual é mantido pela Microsoft) nem com o Gitlab (que é uma empresa privada, com fins lucrativos).

Erro 2

Por outro lado, se você criou sua página e está tentando ativar/alterar um domínio personalizado, talvez você encontre um outro erro do tipo "Failed Depencency!" um pouco diferente:

Failed Dependency! (...) could not obtain repo owner from custom domain.

Essa situação também não é motivo de desespero. Primeiramente, verifique se você:

configurou o arquivo .domains na raiz de seu repositório de modo a conter uma linha única com o seu domínio customizado (digamos my-domain.com), conforme descrito na documentação;
adicionou registros DNS da forma correta, a saber (o erro normalmente aparece por equívoco no registro TXT):
- A, apontando para o IPv4 217.197.91.145
- AAA, apontando para o IPv6 2001:67c:1401:20f0::1
- TXT, apontando para branch.repo.user.codeberg.page.

Se ainda assim o erro persistir, saiba que o TTL (time to live) do cache no servidor do Codeberg Pages é de 3h (veja aqui). Nesse caso, é só esperar um tempo até que cache seja limpo.

Fim

Codeberg pode apresentar instabilidades, mas para hospedagem de sites estáticos, ainda assim é a minha opção predileta.

Até mais,

Yuri.

Como utilizar um `.css` hospedado no GitHub ou Codeberg em um projeto HTML?

Yuri Ximenes Martins — Tue, 28 Nov 2023 17:10:35 +0000

Introdução

Considere a seguinte situação: você possui um arquivo .css (digamos style.css) e gostaria de utilizá-lo em vários projetos de desenvolvimento web. Como fazer isso de forma simples?

Naturalmente, a ideia é utilizar um import

<link rel="stylesheet" type="text/css" href="path/to/style.css">

Por comodidade, seria interessante se o arquivo style.css estivesse hospedado em algum servidor externo para que não haja a necessidade de se mantê-lo na mesma máquina onde os projetos estão sendo desenvolvidos.

Algo baste útil seria manter um repositório no GitHub, ou em outra plataforma de manejo de repositórios git, como Codeberg ou Gitlab, contendo todos os arquivos .css a serem utilizados. Neste caso, poderíamos manter os arquivos organizados por versões e, quando necessitássemos de um deles, bastaria fazer um import como acima para sua correspondente url.

A questão é: qual url utilizar?.

A tentativa mais óbvia seria a url

https://github.com/user/repo/path/to/style.css`

onde path/to/style.css é o caminho relativo ao repositório repo. No entanto, esta não é uma url válida.

Ao visitar o repositório pela plataforma (digamos o GitHub) e clicar no arquivo style.css, observa-se que a url indicada está no formato

https://github.com/user/repo/blob/branch/path/to/style.css

Contudo, essa url não expõe o arquivo. Poderíamos, então, pensar na url que apresenta a versão raw de style.css, a qual é da forma

https://raw.githubusercontent.com/user/repo/branch/path/to/style.css

Mas essa url expõe o conteúdo do arquivo style.css, e não o arquivo em si.

Poxa vida, como proceder?

Abordagem 1

Uma abordagem seria pegar o conteúdo exposto na url raw e incorporá-lo dentro da tag <style> do projeto no qual se deseja utilizar style.css.

Isso pode ser feito, por exemplo, adicionando o seguinte trecho dentro da tag <head> no index.html do projeto (veja aqui):

<script>
var xhttp = new XMLHttpRequest();
xhttp.open("GET", "https://raw.githubusercontent.com/user/repo/branch/path/to/style.css", true);
xhttp.onreadystatechange = function() {
    if (xhttp.readyState === 4) {
        if (xhttp.status === 200) {
            var link = document.createElement('style');
            link.innerHTML=xhttp.responseText;
            document.getElementsByTagName('head')[0].appendChild(link);
        }
    }
}
xhttp.send(null);
</script>

Caramba, mas não há uma forma mais direta de expor os arquivos .css?

Abordagem 2

Se a sua plataforma admite a criação de páginas estáticas (GitHub Pages, Codeberg Pages ou Gitlab Pages, por exemplo), então há uma forma imediata de expor arquivos em repositórios. A saber, transformando os repositórios em uma página estática.

Eu gosto muito do Codeberg para a hospedagem de sites estáticos. De fato, lá é muito simples: todos os repositórios podem ser vistos, por padrão, como sites estáticos. Com efeito, ao invés de utilizar a url

https://codeberg.org/user/repo

basta utilizar a url

https://user.codeberg.page/repo/@branch

Nesse caso, o arquivo style.css ficaria automaticamente exposto na url

https://user.codeberg.page/repo/@branch/path/to/style.css

e bastaria importá-la no projeto desejado em uma tag <link>, como comentado no início do post.

Fim

A depender da plataforma, algumas configurações são necessárias para transformar um repositório em um site estático. Além disso, a url para acessar as páginas do site podem variar. No entanto, no fundo o processo é o mesmo.

Outra alternativa seria colocar seus arquivos .css num S3 Bucket na AWS ou em algum serviço similar em outros serviços de nuvem, que fornecem uma cota gratuita. Contudo, nessa abordagem perde-se a praticidade de se trabalhar com um repositório versionado.

Até mais,
Yuri.

berg: um CLI para Codeberg

Yuri Ximenes Martins — Sun, 01 Oct 2023 16:42:13 +0000

Introdução

Em um post anterior apresentei a vocês o Codeberg: uma alternativa gratuita e Open-Source ao Github e ao Gitlab.

Sou adepto a usar o terminal sempre que possível. Dito isso, algo que me incomodava um pouco era o fato de que Github e Gitlab oferecem ferramentas CLI oficiais (gh e glab, respectivamente) para a configuração de repositórios, merges, etc. O Codeberg não fornece uma CLI, de modo que sempre que precisava criar, deletar ou editar a descrição de repositório, por exemplo, tinha que acessar via browser. Nada muito sério, só uma inconveniência.

Pois encontrei berg: uma CLI para o Codeberg que se propõe a ser uma solução similar ao gh e ao glab. A CLI não é oficial, mas cumpre bem com seu papel (veja observação no fim do post).

Neste post descrevo brevemente como instalar e utilizar berg.

Instalação

berg é escrito em Rust, de modo que o primeiro passo é instalar Rust e seu gerenciador de pacotes e builder cargo:

curl https://sh.rustup.rs -sSf | sh

Feito isso, o seguinte código será adicionado em seu .bashrc:

. "$HOME/.cargo/env"

Cabe notar que em Bash o ponto . é um alias para o builtin source. Se você utiliza . em outras aplicações (como é o meu caso), para que não haja problemas altere a linha acima para

source "$HOME/.cargo/env"

Agora clone o repositório do berg e o instale com cargo:

git clone https://codeberg.org/RobWalt/codeberg-cli
cd codeberg-cli
cargo install --path .

Autorização

Depois de instalado, autorize o uso de berg em sua conta do Codeberg com

berg auth login

Prossiga com um y e você será redirecionado para sua conta do Codeberg. Gere um token adicionando um nome e as permissões que você deseja. Copie o token e cole no terminal onde executou o comando anterior.

Pronto! Agora você já pode utilizar o berg com as permissões criadas.

Utilização

Dê um berg -h para ver as opções disponíveis:

Usage: berg [COMMAND]

Commands:
  auth          Authentication subcommands
  user          User subcommands
  issue         Issue subcommands
  pull          Pull request subcommands
  label         Label subcommands
  repo          Repository subcommands
  milestone     Milestone subcommands
  notification  
  completion    Print completion script
  help          Print this message or the help of the given subcommand(s)

Options:
  -h, --help     Print help (see more with '--help')
  -V, --version  Print version

Por exemplo, se quiser criar um repositório, execute berg repo create e siga as instruções.

Para mais detalhes sobre um dada opção ou comando, execute berg [option] --help.

OBS: uma pena é que com berg não se pode deletar repositórios, algo que pode ser feito diretamente com gh, por exemplo.

Fim

É isso. Com berg o Codeberg se torna uma alternativa ainda mais viável ao manejo de pequenos projetos. Codeberg ainda não fornece (e ao que pude entender nem se propõe a tal) ferramentas CI/CD, de modo que o manejo de grandes projetos ainda é bastante limitado.

Um abraço e até mais.

Yuri Ximenes Martins

Como mudar para o cwd do Netrw ao sair do Vim?

Yuri Ximenes Martins — Thu, 21 Sep 2023 22:42:12 +0000

Introdução

Eu gosto de estruturas minimalistas, e esse é um dos motivos pelos quais eu utilizo Vim como meu editor de texto. Desde a versão 5.5, o Vim vem de fábrica com um plugin que permite navegar no terminal através de arquivos e pastas de maneira visual e sem precisar ficar dando cd e ls toda hora. Trata-se do Netrw.

Muita gente não o utiliza, sendo o Nerdtree seu principal substituto. Uma das desvantagens do Netrw é que, para que funcione de maneira aceitável, um punhado de configurações são necessárias. No entanto, seguindo a filosofia do minimalismo, não vejo nisso argumento forte o suficiente para instalar um plugin a mais.

Em momento oportuno farei uma publicação sobre minhas configurações para o Netrw. Hoje, no entanto, gostaria de trazer a solução de um problema que me \ ,incomodava há algum tempo.

O Problema

Suponhamos que você abriu seu Netrw e começou a navegar por diretórios dentro do Vim. Rapidamente você sai de um diretório A e chega em um diretório distante B. Suponhamos, agora, que você quer executar algum comando de Bash (digamos cmd_Bash) estando no diretório B. Utilizando apenas de um ferramental builtin, tem-se algumas opções:

executar :shell no Vim para abrir um prompt, o qual iniciará no diretório B;
executar :! cd path/to/B | cmd_Bash no Vim.

Suponha, ainda, que você já não mais precisa do Vim e quer fazer coisas no terminal no entorno do diretório B. Nesse caso, você sairá do Vim. Seria muito interessante se o seu working directory do terminal estivesse sincronizado com o working directory do Netrw. Pois, assim, ao fechar o Netrw no diretório B seu terminal estaria já posicionado ali.

O problema é que, no entanto, tal sincronização não existe: alterações em buffers do Vim só se aplicam ao Vim.

A Solução Errada

A estratégia imediata de solução ao problema seria a seguinte:

definir uma variável vim_cwd interna ao Vim que contém o working directory do Netrw;
atualizar tal variável quando o buffer do Netrw é fechado;
associar vim_cwd uma variável bash_cwd em Bash;
configurar o Vim para que, ao ser fechado, seja executado o comando cd $bash_cwd.

As etapas 1. e 2. são tranquilas, como segue.

Etapa 1

No Netrw o símbolo % representa o arquivo em uso, p representa "tomar o full path de", ao passo que h representa "pegar o diretório de". Assim, pode-se obter o diretório de um arquivo aberto através de expand('%:p:h'). Em um buffer do Netrw isso se refere exatamente ao working directory. Para salvá-lo em uma variável global vim_cwd, basta um

let g:vim_cwd = expand('%:p:h').

Etapa 2

No Vim pode-se executar comandos internos ao se fechar um buffer adicionando-os como

autocmd BufDelete * your_command

Para se restringir a um dado buffer, concatena-se com um if &ft ==# 'your_buffer'. No nosso caso, o buffer é netrw, de modo que ficamos com

autocmd BufDelete * if &ft ==# 'netrw' | your_command | endif

Aplicando à situação particular da etapa anterior, temos:

autocmd BufDelete * if &ft ==# 'netrw' | let g:vim_cwd = expand('%:p:h') | endif

Etapa 4

Assim como existe uma maneira de executar comandos internos ao Vim quando buffers são fechados, pode-se executá-los quando o próprio Vim é fechado. A sintaxe é a seguinte:

autocmd VimLeave * your_command

Por outro lado, pode-se executar comandos de Bash como comandos de Vim através de execute '!your_bash_command'. Portanto, o seguinte código executa um comando em Bash ao se fechar o Vim:

autocmd VimLeave * execute '!your_bash_command'

Etapa 3

É no ato de transformar uma variável interna ao Vim em uma variável de Bash (etapa 3) que a estratégia anterior falha. Até onde vai meu conhecimento, não existe uma maneira de se fazer isso diretamente dentro do Vim sem se recorrer a um script de Bash.

A solução Correta

Como contornar a situação? Ao invés de transformar diretamente uma variável vim_cwd do Vim em uma variável bash_cwd do Bash, podemos fazer isso em passos:

escrever o valor da variável vim_cwd em um arquivo;
ler tal arquivo em uma variável de Bash.

Isso sim funciona, pois o Vim admite uma função chamada writefile() que permite exatamente a escrita de uma variável em um arquivo. Em nosso caso, temos:

writefile([g:vim_cwd], '/tmp/some_file').

Por sua vez, poderíamos obter bash_cwd através de

bash_cwd=$(cat /tmp/some_file)

Juntando tudo, a solução ao nosso problema seria, então, dada pelo seguinte código:

autocmd BufDelete * if &ft ==# 'netrw' | let g:vim_cwd = expand('%:p:h') | call writefile([g:vim_cwd], '/tmp/some_file') | endif
autocmd VimLeave * execute '!bash_cwd=$(cat /tmp/some_file) | cd $bash_cwd'

Temos, no entanto, mais um problema:

o operador de substituição $() não funciona muito bem ao ser executado como um comando dentro do Vim!

A alternativa é pedir que o comando cd $(cat /tmp/some_file) seja executado não dentro do Vim, mas diretamente em Bash. Isso pode ser feito redefinindo o comando vim substituindo-o por uma função vim():

function vim(){
    command vim "$@"
    if [[ -f /tmp/some_file  ]]; then
        bash_cwd=$(cat /tmp/some_file)
        cd $bash_cwd
        rm /tmp/some_file
    else
        return
    fi
}

Conclusão

Se você quer que ao fechar o Vim seu terminal esteja no último diretório acessado pelo Netrw, faça o seguinte:

em seu .vim/vimrc adicione

autocmd BufDelete * if &ft ==# 'netrw' | let g:vim_cwd = expand('%:p:h') | call writefile([g:vim_cwd], '/tmp/some_file') | endif

em seu .bashrc adicione

function vim(){
    command vim "$@"
    if [[ -f /tmp/some_file  ]]; then
        bash_cwd=$(cat /tmp/some_file)
        cd $bash_cwd
        rm /tmp/some_file
    else
        return
    fi
}

Fim

Até mais,

Yuri.

Linguagens e seus tipos

Yuri Ximenes Martins — Tue, 12 Sep 2023 22:47:54 +0000

Apresentação

Linguagens são formas de comunicação bem estruturadas. Grosso modo, a comunicação se dá pelo envio de informação entre indivíduos: o emissor envia uma mensagem ao receptor que a recebe e processa. Dito isso, linguagens são formas de transmitir a informação seguindo regras pré-estabelecidas. Todos os animais, de uma ou outra forma, se comunicam entre si. No entanto, o uso de linguagens (isto é, de uma comunicação estruturada) é um dos critérios que diferencia nós, humanos, dos outros animais.

Na comunicação entre animais, os "indivíduos" são sempre outros animais. O homem foi capaz de criar linguagens que permitem a comunicação não somente entre humanos, mas entre indivíduos denominados de máquinas. Estes, por sua vez, podem ser objetos inanimados formados de componentes físicos (como hardwares), ou mesmo construções abstratas, que não necessariamente existem aqui na Terra, mas apenas enquanto ideias ou conceitos. Veja até onde fomos:

podemos falar da comunicação, de forma estruturada, entre indivíduos que não existe concretamente!

Tem-se diferentes tipos de linguagens, como as linguagens naturais, as linguagens de máquina, as linguagens formais e as linguagens de programação. Todas elas, no entanto, dividem diversas características, as quais discutimos em seguida.

Sintaxe, Gramática e Semântica

Independentemente do seu tipo, linguagens são construções humanas. Isso significa que elas são construídas a partir de blocos fundamentais seguindo-se regras bem definidas. O que muda de um tipo de linguagem para outra não é a estrutura subjacente, mas sim a natureza dos blocos fundamentais e das regras utilizadas na construção da linguagem. De fato:

parte-se de símbolos fundamentais, os quais definem o alfabeto da linguagem;
então se dita como símbolos devem ser unidos para formar palavras;
e como palavras se unem para formar frases;
e assim sucessivamente.

Ao conjunto das regras que ditam como construir palavras a partir de símbolos, frases a partir de palavras, etc., dá-se o nome de sintaxe da linguagem. Por sua vez, diz-se que os símbolos, as palavras e as frases propriamente ditas constituem sua gramática.

Observemos, no entanto, que linguagens não são meras construções. Afinal, elas possuem um objetivo claro: o da comunicação, e a comunicação só se concretiza quando a mensagem passada admite algum significado para aquele que a recebeu. Muitas vezes, no entanto, uma mesma mensagem pode admitir diferentes significados:

para um mesmo receptor, dependendo do contexto no qual a mensagem está inserida;
para diferentes receptores, dependendo do contexto no qual o receptor está inserido.

Sendo assim, dependendo do contexto, fala-se que uma mensagem recebe uma interpretação. Às diferentes maneiras de se interpretar as construções de uma linguagem (isto é, suas palavras, frases, etc.), dá-se o nome de semântica.

Desta forma, em poucas palavras, pode-se dizer que estudar uma linguagem consiste em:

construí-la, o que é feito fornecendo símbolos e uma sintaxe, a partir da qual se obtém sua gramática;
interpretá-la, que significa associar à sintaxe/gramática um significado concreto (ou abstrato - veja abaixo), o qual define sua semântica.

De forma ainda mais resumida:

estuda-se uma linguagem através de sua sintaxe, gramática e semântica.

Tipos de Linguagem

Como comentamos, o que diferencia os tipos de linguagens não é a estrutura subjacente (admitir uma sintaxe, uma gramática e uma semântica), mas sim a natureza daquilo que compõe sua estrutura. Uma diferença, em particular, é especialmente interessante: a natureza das regras definidas pela sintaxe para se construir a gramática. Segundo tal critério, as linguagens podem ser divididas em dois tipos:

Linguagens Naturais. Nelas, as regras da sintaxe são definidas por convenções sociais e agrupadas naquilo se chama de dicionários e livros gramaticais (também chamados simplesmente de gramáticas). Ao se aprender uma nova língua, olha-se em gramáticas para saber quais palavras existem, como formar frases, etc. Por sua vez, olha-se no dicionário para saber o significado social associado a cada uma dessas palavras definidas na gramática.
- Português, Inglês e outras línguas definem linguagens naturais.
Linguagens Formais. Em contrapartida, em linguagens formais as regras da sintaxe (isto é, as regras que definem como se formam palavras válidas, frases, etc.) são dadas não por convenções sociais, mas por fórmulas de alguma lógica. Existem diferentes tipos de lógica e, para cada uma delas, um tipo diferentes de linguagem formal.
- Linguagens utilizadas dentro da Matemática e da Computação são exemplos de linguagens formais.

Lembre-se que em uma comunicação por meio de linguagens, os humanos não são os únicos indivíduos: tem-se, também, as máquinas. Desta forma, pode-se classificar as linguagens também com respeito ao tipo de indivíduo envolvido na comunicação:

Linguagens Humanas. Tratam-se, pois, daquelas utilizadas na comunicação humano-humano;
Linguagens de Máquina. São aquelas em que ao menos um indivíduo não é um humano, mas sim uma máquina.

Linguagens de máquina são tipicamente formais, enquanto que linguagens humanas podem ser formais ou naturais. Antes do avanço da Inteligência Artificial, linguagens naturais só eram processadas por humanos, o que as caracterizava, necessariamente, como linguagens humanas. No entanto, com a evolução do Processamento de Linguagens Naturais (Natural Language Processing) e com o desenvolvimento dos Modelos de Grandes Linguagens (Large Language Models), torna-se possível, ainda que de maneira limitada, a comunicação entre humanos e máquinas por meio de linguagens naturais.

Linguagens de Programação

No início da texto, comentamos que "máquinas" podem ser objetos concretos, formados de componentes físicos (como hardwares) ou mesmo abstrações que, a princípio, existem apenas enquanto conceitos criados pelo homem. Um exemplo de tal diferenciação entre "máquinas concretas" e "máquinas abstratas" se dá no uso de recursos naturais: a energia em nosso universo é finita. Portanto, algo criado pelo homem só pode consumir uma quantidade finita de energia.

Em uma máquina concreta, leva-se esse ponto em consideração: seus componentes devem ser tais que consumam somente finitos recursos. No imaginário humano, no entanto, podemos pensar em máquinas que não satisfazem tal premissa básica do universo. Estas, em tese, poderiam consumir recursos indefinidamente. A elas dá-se o nome de máquinas abstratas.

Tipicamente se dá o nome de computador a uma máquina concreta. Linguagens de máquina que envolvem computadores (isto é, quando algum dos indivíduos é uma máquina concreta, cujos componentes consomem uma quantidade finita de energia) são então chamadas de linguagens de computadores.

Ao se querer enfatizar que uma linguagem de máquina envolve a comunicação de máquinas que não são necessariamente concretas (isto é, quando não se leva em consideração o consumo de energia), fala-se, então, de linguagens de programação. Desta forma, linguagens de computadores são exemplos de linguagens de programação.

Existem muitas outras classificações e subtipos de linguagens de programação. Por outro lado, assim como os diferentes tipos de linguagens (naturais, formais, humanas, de máquina, etc.) admitem a mesma estrutura (gramática, sintaxe e semântica), as diferentes classes de linguagens de programação possuem muitos aspectos em comum. A área de estudo que estuda tais aspectos em comum é chamada de Teoria das Linguagens de Programação (Programming Language Theory). Conhecer um pouco dela significa aprender sobre todas as linguagens de programação ao mesmo tempo!

Fim

Até mais,

Yuri.

Por que estudar teoria?

Yuri Ximenes Martins — Thu, 03 Aug 2023 22:59:29 +0000

Introdução

Oi.

Essa é a primeira postagem da coluna Theoretical Insights. Nela pretendo apresentar, de maneira intuitiva e menos formal, alguns aspectos teóricos ligados à programação. Ao longo de vários artigos, responderemos perguntas como:

o que, de fato, define uma linguagem de programação?
como funciona o processo de compilação?
o que são algoritmos?
o que é uma máquina?
como funcionam os computadores?

Mas,

por que um desenvolvedor de software deveria fazer algo para além de resolver problemas concretos e de estudar novas tecnologias?
por que dedicar parte de seu tempo tentando compreender aspectos teóricos que, no dia a dia, aparentam ser irrelevantes?

Inicio esta coluna apresentando alguns argumentos que corroboram para a tese de que, na verdade, ter uma boa bagagem teórica pode implicar diretamente em uma melhor performance como desenvolvedor.

Independência da Linguagem

Desenvolvedores se especializam em linguagens de programação, o que faz com que consigam refletir de maneira bastante intrincada em sua linguagem de especialização. No entanto, diferentes linguagens são construídas com diferentes propósitos e, dependendo da situação, seria mais interessantes construir algo em uma linguagem distinta daquela na qual se está habituado. Como proceder?

Linguagens de programação implementam algoritmos. Uma linguagem é dita ser completa (Turing complete) se é capaz de implementar todos os algoritmos realizáveis em um computador moderno (isto é, em uma Turing machine). Fato é que as linguagens de programação de alto nível e mais utilizadas no meio corporativo, como C, C++, Java, C#, JavaScript, Python, Go, Ruby, Rust, etc., são completas. Isso significa que, em termos da capacidade de implementar algoritmos, todas elas cumprem o mesmo papel. Isso também significa que existe uma maneira de se pensar e construir soluções que é independente da linguagem de programação a ser utilizada. A saber, através de algoritmos.

Conclusão. Entender melhor o que é uma linguagem de programação e o que são algoritmos nos permite desenvolver a capacidade de resolver problemas que independam de uma dada linguagem de programação.

Otimização

Ao se trabalhar com desenvolvimento de software, lida-se, diariamente, com a construção de soluções para problemas. Às vezes não paramos para pensar, mas um mesmo problema pode admitir diferentes soluções. Julgo que uma das características que demonstram a senioriedade de um desenvolvedor é conseguir olhar para o leque de possíveis soluções de um dado problema e saber decidir, baseado em critérios previamente estabelecidos, qual a solução é a mais adequada. Mas, como fazer isso de maneira sistemática?

Escolher a melhor dentre um conjunto de possibilidades é um problema de otimização. Como comentado, linguagens de programação implementam algoritmos. Fato é que existem áreas de estudo devotadas ao problema de análise e otimização de algoritmos, como a Teoria da Complexidade Computacional (Computational Complexity Theory) e a Análise de Algoritmos (Analysis of Algorithms).

Conclusão. Estudar sobre a teoria dos algoritmos nos dá critérios objetivos para decidir, dentre uma gama de possíveis soluções, qual é que melhor se adapta a uma dada demanda.

Inovação

Para pensar em buscar pela solução otimizada, precisa-se, antes, conhecer o leque de possíveis soluções. Algumas soluções tendem a ser mais óbvias que outras e, não raro, a solução mais adequada é altamente não-trivial. Ser não-trivial é ser inesperado, e ser inesperado é ser inovador. Ao se trabalhar mergulhado em uma linguagem de programação específica, tende-se a construir soluções que mais se adequam aos objetivos e características da própria linguagem, o que naturalmente diminui o leque de possíveis soluções a serem observadas.

Conclusão. Se desprender de uma dada linguagem e pensar de forma mais abstrata abre horizontes e possibilita a construção de soluções inovadoras.

Visão Panorâmica

Tornando-se especialista, dá-se um zoom em toda a gama de conhecimentos e passa-se a concentrar em assuntos restritos e a assuntos fortemente relacionados a eles. Ao se estudar aspectos teóricos e fundamentalistas, diminui-se um pouco esse zoom, permitindo uma observação mais panorâmica dos problemas extremamente especializados que se estava lidando. Uma visão mais abrangente é menos enviesada e permite, por exemplo, observar conexões entre assuntos e problemas que antes não se via. Talvez a solução que se busca já exista, mas seja adaptada a um problema em um tópico ligeiramente distante, o qual não poderia ser observado em um zoom muito grande.

Conclusão. Estudar teoria fornece uma visão abrangente, a qual possibilita a adaptação de soluções já existentes para problemas de outras áreas.

Não-Linearidade do Aprendizado

Por fim, gostaria de dizer que, diferentemente do que é exposto em livros técnicos e na estrutura de cursos de graduação, o aprendizado não se dá de forma linear. Existe um campo devoto ao estudo da construção do conhecimento, chamado de Epistemologia, o qual se origina na Filosofia e se intersecta com outras áreas como a Psicologia.

Uma das questões epistemológicas é como se dá o aprendizado. Existem diversas teorias e vários modelos educacionais associadas a elas. Uma delas, pela a qual tenho grande apreço, é a Teoria do Aprendizado por Descobertas, de Jerome Bruner (Discovery Learning, em inglês), cujo modelo educacional é não-linear baseado em um formato espiral. Nele, não se torna especialista em algo, para então se tornar especialista em outro algo, e assim sucessivamente (perspectiva linear). Ao contrário, aprende-se de maneira efetiva tendo uma visão inicialmente rudimentar do todo (primeira volta da espiral), e então revendo o todo com maior profundidade e abstração (segunda volta da espiral), e assim por diante.

Em outras palavras, segundo esta perspectiva, uma aprendizagem efetiva é obtida partindo-se de uma visão generalista, e então retomando os diferentes assuntos por diversas vezes, cada vez com maior compreensão e profundidade.

Estudar aspectos teóricos e fundamentalistas é ir exatamente na direção de construir essa espiral do aprendizado, e as experiências e vivências adquiridas em cada volta certamente darão uma maior amplitude no momento de atacar um problema específico.

Fim

Fica a minha mensagem.

Espero ter transmitido a ideia de que ao se descer do mundo dos códigos especializados e estudar um pouco de teoria, tem-se a possibilidade de obter ferramentas poderosas que o tornarão um profissional capaz de pensar fora da caixa, propor soluções otimizadas e ideias inovadoras. Pode parecer perda de tempo, mas é um investimento.

Obviamente não estou dizendo que aprender habilidades técnicas especializadas não é útil ou necessário. Pelo contrário: digo que aliar o conhecimento técnico ao teórico tem o potencial de ampliar suas capacidades e seu desempenho enquanto desenvolvedor.

No entanto, sinta-se à vontade para discordar do meu ponto de vista e contribuir nos comentários com suas vivências.

Um abraço e até mais,

Yuri.

devto-cli: sincronizando um repositório do GitHub com suas publicações do dev.to

Yuri Ximenes Martins — Sat, 29 Jul 2023 00:42:16 +0000

Introdução

Gosto de escrever e de compartilhar minhas ideias; gosto de tornar intuitivo aquilo que é tido como complexo. Ao longo da última década, escrevi livros, artigos científicos e notas de aula para cursos que ministrei em diversos tópicos da Física e da Matemática. No entanto, estando agora mais interessado em Desenvolvimento de Software, me vi na posição de buscar produzir e divulgar conteúdo em um novo formato.

Em contrapartida, gosto de fazer tudo o que puder no terminal e, quando possível, trabalhar com ferramentas CLI ao invés de TUI ou GUI. Há um peso estético, confesso. No entanto, CLIs permitem automação de processos, o que facilita a vida. Além disso, ao trabalhar localmente posso me dar ao luxo de utilizar de todas as configurações e customizações que fiz em meu computador para melhor se adaptarem as minhas necessidades. Isso, para mim, é qualidade de vida!

Ao meu ver, o ideal seria poder escrever os conteúdos localmente, em arquivos .md, para então publicá-los em plataformas de divulgação através de alguma ferramenta CLI. Além da comodidade de escrever em Markdown, isso permitiria facilmente reutilizar posts e automatizar sua publicação. Naturalmente, a construção de uma tal CLI depende da disponibilização por parte da plataforma de uma API versátil o suficiente.

Inicialmente cheguei a tentar me adaptar a publicar conteúdos no Linkedin, mas o fato de ter de preparar cada post especificamente para lá me fez repensar se realmente vale o esforço. Infelizmente, o Linkedin não fornece uma API oficial para criação e edição de postagens para usuários quaisquer (apenas para páginas vinculadas a alguma empresa - veja aqui), o que inviabiliza a construção de CLI com as características desejadas (para uma CLI não oficial, baseada na API restrita fornecida pelo Linkedin, veja tigillo/linkedin-cli).

Foi então que descobri que a plataforma dev.to oferece uma API rica e, para minha surpresa, uma ferramenta CLI que já funciona muito bem: sinedied/devto-cli! Por conta disso, decidi concentrar aqui a minha criação de conteúdo sobre Desenvolvimento de Software.

Como tudo funciona

sinedied/devto-cli é uma aplicação escrita em Node.js que permite a sincronização de um repositório local de arquivos .md com o conjunto de publicações de um perfil na plataforma dev.to. A sincronização se dá por intermédio da criação de um repositório no GitHub, conectado ao repositório local, o qual contém uma workflow que a cada novo commit criado pela CLI executa a GitHub Action sinedied/publish-devto. Esta, por sua vez, ativa a API que, por meio dos metadados contidos na frontmatter dos arquivos .md, os faz corresponder às publicações no dev.to.

Configuração

Descrevo o passo a passo da configuração do sinedied/devto-cli no caso de um sistema operacional que utiliza Bash como shell:

instale sinedied/devto-cli por meio do npm:

    npm install -g @sinedied/devto-cli

logado em sua conta do dev.to, acesse dev.to/settings/extensions. No final da página, gere uma API.
crie um repositório no seu GitHub, o qual servirá para intermediar o processo. Por exemplo, o meu é yxm-dev/dev.to.
acesse seu repositório e vá em Settings > Secrets and variables > Actions.
adicione uma nova key com o nome DEVTO_TOKEN e com conteúdo dada por sua API obtida no passo 2.
crie um diretório local, digamos dir/, acesse-o e dê um dev init:

    cd dir
    dev init

complete com o nome do repositório do GitHub criado na etapa 3 e com o branch que você irá utilizar.
dentro de dir/ crie um arquivo .env e adicione o repositório, o branch e a API:

    touch .env
    echo "DEVTO_TOKEN=sua_API" >> .env
    echo "DEVTO_REPO=seu_usuario/seu_repositorio" >> .env
    echo "DEVTO_BRANCH=seu_branch" >> .env

por segurança, crie um .gitignore e adicione o arquivo .env:

    touch .gitignore
    echo ".env" >> .gitignore

crie um remote para seu repositório do GitHub:

    git remote add seu_remote ssh://git@github.com/seu_usuario/seu_repositorio

push para o repositório no GitHub:

    git add .
    git commit -m "..."
    git push

Utilizando

A utilização básica é bem simples:

dentro de dir/ há um sub-diretório dir/posts/. É aqui que seus arquivos .md serão criados
para criar um arquivo .md pré-configurado, execute dev new nome_post
complete os metadados na frontmatter. Se quiser que o post seja publicado, coloque published: true
para publicar as postagens, em dir/ execute dev push -e.
- OBS: somente os arquivos .md que estiverem dentro de dir/posts/ serão publicados
se quiser ver o status de suas postagens, execute dev stats em dir/.

Mantendo as Postagens no GitHub

Em minha humilde opinião, existe uma pequeno defeito na construção utilizada pelo sinedied/devto-cli. Ao se executar dev push -e, as postagens passam pelo GitHub, mas não ficam por lá! Você poderia pensar em dar um git push. Mas, neste caso, para cada novo commit, ao invés dos posts já publicados no dev.to serem atualizados, eles são duplicados!

Para remediar o problema e automatizar o processo de publicação, criei uma função devp, a qual copia os arquivos de dir/posts/ para um outro diretório dir/files/. Para implementá-la, faça o seguinte:

adicione posts/* em dir/.gitignore:

    echo "posts/*" >> dir/.gitignore

em seu arquivo ~/.bashrc, adicione o seguinte:

    function devp(){
        cd dir/
        cp -r posts/* files/
        git add .
        git commit -m "..."
        git push -q dev.to master
        dev p -e
    }

Pronto! Agora basta executar devp para publicar seus artigos no dev.to e, ao mesmo tempo, mantê-los em seu repositório do GitHub.

Fim

Até mais,
Yuri.

Codeberg: uma alternativa Open Source e gratuita ao GitHub e GitLab

Yuri Ximenes Martins — Fri, 28 Jul 2023 22:10:15 +0000

Oi.

Vocês conhecem o codeberg.org? Trata-se de uma plataforma Open Source e gratuita, baseada no GiTea e mantida por meio de doações. O foco é em FOSS (Free and Open Source Software) e, para repositórios públicos, não há um limite predefinido de tamanho.

Em suas próprias palavras:

"The mission of Codeberg e.V. is to build and maintain a free collaboration platform for creating, archiving, and preserving code and to document its development process.
(...)
Dependencies on commercial, external, or proprietary services for the operation of the platform are avoided, in order to guarantee independence and reliability."

Diferentemente do GitHub e do GitLab, o objetivo não é fornecer ferramentas adicionais, como de CI/CD. O Codeberg também não oferece, ainda, uma alternativa CLI. No entanto, lá você conta com o que é necessário para a hospedagem e manutenção de um projeto, como a criação de páginas estáticas via o Codeberg Pages, de wikis, e muito mais. Veja aqui para a documentação completa.

Se você possui um projeto Open Source ou se identifica com a filosofia FOSS, talvez o Codeberg seja uma boa opção para você. Eu mesmo possuo uma conta lá (codeberg.org/yxm), a qual utilizo para manter repositórios mais pesados e para hospedar sites estáticos de meus projetos.

Fica a sugestão. Talvez valha a pena conhecer.

Um abraço e até mais,

Yuri.

Prazer, Yuri.

Yuri Ximenes Martins — Fri, 28 Jul 2023 22:07:42 +0000

Oi.

Sou novo por aqui no dev.to e essa é a minha primeira postagem. Gostaria de iniciar esse contato me apresentando, contando um pouco de minha história e dizendo o que você pode esperar mim.

Yuri

Meu nome é Yuri Ximenes Martins e tenho 30 anos. Sou um pesquisador brasileiro que atua na interseção entre Matemática, Ciência da Computação, Física e Filosofia, em temas ligados à abstração. Atuo, também, como desenvolvedor de software, onde tenho afinidade com o paradigma funcional.

Sou um usuário assíduo de Linux e gosto de trabalhar dentro de um terminal. Amante de Vim, prefiro arquiteturas minimalistas. Gosto de pensar sobre o meu impacto no meio ambiente, de tornar o que é complexo intuitivo e de me expressar através de versos.

Física e Matemática

Comecei minha graduação em Física em meados de 2010. De 2016 a 2022 estive no programa de Pós Graduação em Matemática da Universidade Federal de Minas Gerais (UFMG), onde fiz meu mestrado e doutorado.

Durante a graduação fui me interessando cada vez mais por extrair a essência de conceitos, por generalizar ideias, e pela criação de novas estruturas; exemplos do que se pode chamar de processos de abstração. Ao se seguir nessa direção, naturalmente se chega a questões ligadas aos fundamentos da área de estudo em questão. O entendimento dos pilares fundamentais da Física foi tema de minha pesquisa durante a pós-graduação. Mais precisamente, meu interesse se concentrou em questões que conectam a Física, a Matemática e a Filosofia.

O que é, de fato, um sistema da Física? Essa foi minha questão central.

Existem várias maneiras de se perguntar sobre o que uma coisa "é". Uma delas é buscar dizer se ela pode ser "formalizada". Isso significa se perguntar se ela pode ser descrita puramente em termos de estruturas da Matemática e de certas áreas da Filosofia. No que diz respeito à Física, para descrevê-la precisa-se da Lógica (que vem da Matemática) e da Ontologia (que vem da Filosofia). A questão, então, é saber se Lógica e Ontologia são suficientes para descrever a Física.

A existência de uma base formal para a Física foi proposta, pela primeira vez, em 1900 pelo matemático David Hilbert. Mesmo depois de mais de 120 anos de pesquisa intensa, uma construção completa ainda não foi obtida. Como uma pequena amostra da importância e da grandiosidade do problema, noto que parte do que seria uma possível solução é considerada, ao lado de P=NP e outras questões, como um dos Problemas do Milênio, os quais possuem como recompensa um prêmio de um milhão de dólares!

Desenvolvimento de Software

Talvez você esteja se perguntando: mas como o estudo dos fundamentos da Física se relaciona com o Desenvolvimento de Software? E como você saiu de lá para chegar aqui na dev.to?

Explico.

Toda linguagem (seja ela de programação, formal ou natural) pode ser estudada de diferentes aspectos. Dentre eles, tem-se a sintaxe (que lida com sua estrutura) e a semântica (que diz respeito às formas de se interpretá-la).

Uma maneira de se organizar a sintaxe é por meio de "tipos". Isso significa que a sintaxe de uma linguagem está muito ligada com o que se chamada de Teoria de Tipos. Por sua vez, uma maneira de se interpretar uma linguagem é associando a ela estruturas da Matemática. Assim, a semântica de uma linguagem está relacionada com a "teoria das estruturas matemáticas", a qual recebe o nome de Teoria das Categorias.

Um fato interessante é que, no caso de linguagens de programação, tem-se uma seta contrária a partir do qual, para determinados sistemas de tipos, sabe-se associar uma linguagem de programação. Esse é a chamada correspondência de Curry-Howard.

Teoria das categorias e Teoria de Tipos são temas extremamente importantes em minha pesquisa. Por sua vez, a correspondência acima coloca Ciência da Computação em jogo. Através dela pode-se pensar em formalizar a Física e/ou a Matemática não em uma linguagem qualquer, mas em uma linguagem de programação! Esse é o cerne da pesquisa no desenvolvimento de linguagens de programação altamente estruturadas que atuem como verificadores de prova, como é o caso de Coq e Agda.

Portanto, sim: linguagens de programação aparecem nos fundamentos da Física. No entanto, como os problemas a serem descritos e solucionados por elas são extremamente abstratos e distantes daqueles da "vida real", tais linguagens destoam daquelas com cunho mais comercial, as quais foram desenvolvidas para atacar e serem eficientes na solução de problemas concretos.

Cansado de emergir em abstração, resolvi ter contato com questões concretas (e, portanto, com as ferramentas inerentes a elas), as quais possuem potencial de influenciar, de forma mais direta e imediata, o mundo em que vivemos. Foi assim que decidi entrar pro meio do Desenvolvimento de Software...

Linux e Bash

Desde que entrei na universidade, em 2010, utilizo Linux. No começo fui um usuário mais passivo. Aos poucos, à medida em que me aproximava da abstração e da busca pelo essencial, tornei-me mais ativo, no sentido de não só utilizar ferramentas, mas também modificá-las e criar novas de acordo com meus interesses e necessidades.

Pra ser sincero, aprendi a programar de forma procedural em Bash. Gosto muito de automatizar pequenas tarefas, criar funções que incorporem diferentes funcionalidades, desenvolver versões interativas para CLI já existentes, criar TUI para aplicações, etc. No fundo, gosto mesmo é de trabalhar no terminal!

No entanto, me dá um pouco de agonia ver como lidar só com linha de comando pode ser contra intuitivo. Sinto-me forçado a recorrer a documentações da GNU recorrentemente, bem como a (salvadora) ArchWiki. Nesse sentido, tenho medido alguns esforços para construir um ambiente mais intuitivo que, quem sabe, possa servir não só a mim, mas a outros que desejam viver no terminal sem serem grandes especialistas em Linux. Chamo tal projeto de InTUI (uma mistura de "intuição" com "TUI"). Trata-se de um conjunto de funções e scripts em Bash, as quais disponibilizo em meu GitHub.

Lab

Tenho tentado pegar o hábito de documentar minhas dúvidas e as respostas que melhor se adequam a elas. Como as dúvidas são recorrentes, fica mais simples de encontrar a resposta caso precise outra vez. Junto delas tenho criado listas com documentações e referências complementares para softwares que utilizo, além de um "dicionário" contendo uma tentativa de dar definições mais precisas a termos do meio.

Pensando que talvez possa ser útil a alguém, disponibilizo o conteúdo na página lab.yxm.me, cujos arquivos .md subjacentes podem ser encontrados neste repositório no Codeberg.

O que esperar de mim

Aqui no dev.to pretendo escrever no formato de colunas sobre temas nos quais tenho interesse e que acredito que possa contribuir de alguma forma. Por exemplo, pretendo manter as seguintes colunas:

Linux Tips, com dicas rápidas sobre Linux
Bash Tips, com dicas rápidas sobre Bash
Vim Tips, com dicas rápidas sobre Vim
CLI Tools, com pequenos tutoriais e sugestões de ferramentas que operam por linha de comando,

bem como algo sobre Lógica, abstração, teoria das categorias, teoria de tipos, novas tecnologias que eu estiver estudando, e o que mais me parecer útil a alguém.

Fim

Um abraço e até mais!