Olá eu sou Adolfo Neto professor da
UTFPR Curitiba e do programa de
pós--graduação em computação aplicada
ppgca Estou aqui com a co-host do
Fronteiras da da engenharia de software
Maria Claudia emmer também da UTFPR
Curitiba também do ppgca Tudo bem Maria
Cláudia tudo bem Adolfo estou aqui
preparada para mais uma conversa né
sobre um tema bem importante da
engenharia de
software muito legal então hoje a gente
vai entrevistar o Leonardo Murta que é
professor associado do Instituto de
computação da Universidade Federal
Fluminense em Niterói Rio de Janeiro ele
tem graduação mestrado e doutorado pela
UFRJ Universidade Federal do Rio de
Janeiro todos curiosamente orientados
pela professora Cláudia Maria Lima
Werner que a gente precisa entrevistar
algum dia aqui no no fronteiras ele atua
no programa de pósgraduação em
computação que tem mestrado e doutorado
da UFF eu falo UF eu não sei se vocês
falam de um jeito diferente tudo bem
Leonardo Você tem algo a complementar
nessa sua apresentação bom primeiro
lugar Adolfo Maria Cláudia Obrigado pelo
convite Tudo ótimo
eh da forma que a gente falala a gente
fala uf na verdade né mas vários colegas
falam UFF Então acho que é só o pessoal
que é da uf que fala uf
eh acho que você apresentou bem e eu
brinco que tudo que deu certo em mim é
por causa da Cláudia que deu erada
porque eu não entendi direito o que ela
tentou me passar né então eu fui eh fiz
graduação na UFRJ fui aluno de projeto
final né antes disso de iniciação
científica com ela depois fui pro
mestrado doutorado sempre com ela só um
período que eu fiquei na Universidade da
Califórnia com o André vand derru
durante sanduí voltei fiz pdoc com ela
até que em 98 eu entrei na uf como
professor então a trajetória foi essa
mesmo e e na uf eh eu tô direto lá eu eu
saí em dois momentos por períodos curtos
eu fui pra universidade de Nova York
trabalhei com a Juliana Freire e depois
eu fui para Arizona trabalhei com gerosa
com Igor saimer mas sempre curtos
períodos de três meses e voltando para
pra uf né então tô na uf esse tempo todo
mas é
isso certo então vamos começar falando
sobre o tema principal dessa entrevista
versionamento de software as pessoas que
nos escutam já devem saber o que é
versionamento de código usam Git por
exemplo mas o que é versionamento de
software no que difere do de código né
de versionamento de código apenas na
verdade deixa eu eh posicionar
versionamento no tema mais amplo que é
gerência de configuração né gerência de
configuração ela surgiu
eh num período ali de pós-guerra com uma
preocupação muito grande em versionar
armamento bélico versionar aviões de
guerra naves espaciais naquele momento
que o homem tava querendo ir pra lua
porque é um artefato composto e ao você
mexer numa parte desse artefato você
gera efeito colateral em outras partes e
vem a crise do software e o software
ganha muita importância eh e o o
software é eminentemente um artefato
composto né você não consegue fazer um
sistema pensando em um único artefato
Você tem uma coleção de vários artefatos
e artefatos que mudam com o passar do
tempo né então a gerência de
configuração ol a disciplina que se
preocupa em controlar a evolução de
artefatos de software no caso de
gerência de configuração de software ou
de artefatos em geral no caso de
gerência de
configuração e a gerência de
configuração tem dentro dela vários
subsistemas com preocupações diferentes
eh muita gente não enxerga esses vários
sistemas como pertencentes a um grupo de
sistema que é gerência de configuração
mas por exemplo sistemas de construção
um make um maven um ent todos eles são
sistemas de gerência de configuração com
a preocupação de construção a partir de
de de artefatos partes de de artefatos
você compor um único artefato que é o
software e que tem que funcionar
corretamente lidar com a questão de
dependências que a gente sabe que é é
muito difícil de lidar na mão né Tem até
o termo dependence rell que é a
complexidade de você lidar com eh muitas
dependências num projeto e tal então
esse é um um grupo de sistemas que são
sistemas de construção ou de Build a
gente tem sistema de controle de
demandas né que são os issue trackers
então a gente pode falar do github
issues por exemplo do J tem vários
outros sistemas que tem esse propósito
esses já tão mais na fronteira com
usuário tenta entender Quais são as
demandas do usuário e rastrear essas
demandas para as mudanças em código a
gente tem sistemas voltados para release
né então toda a preocupação de release
ela entra também nesse pacote grande de
gerência de configuração mas no coração
tá o controle de versões então eu tento
brincar que o controle de versões é o
coração da gerência de configuração
porque é ele que de fato tá controlando
a evolução as várias versões de cada
parte do software né assumindo que o
software é um um um elemento composto né
E aí se a gente passar para essa
pergunta específica né eh como é que a
gente compara e eh eh controle de versão
no geral com
Git que é voltado para código Mas se a
gente pensar na Essência na Essência
Será que o Git É voltado para código né
O que que o Git versiona Será que ele
conhece o meu código em Python ou o meu
código em Java às vezes quando eu tô
dando aula eu pergunto pros meus alunos
vem cá se você ah fez um um merge de
código e o Git falou que não encontrou
conflito você pode mandar esse mge pro
repositório tranquilo porque você não
vai tá quebrando o repositório
obviamente não não porque o Git Na
verdade o que ele versiona são arquivos
e ele enxerga como partes de um arquivo
as linhas do arquivo ele não tem nenhum
conhecimento mais semântico ou mesmo
sintático do que que ele tá versionando
então se duas pessoas editam a mesma
região ele vai avisar que tem um
conflito mas se as pessoas editam partes
diferentes ou arquivos diferentes pro
Git tá tudo bem ele consegue juntar
aquilo ali mesmo que sintática ou
semanticamente não faça no menor sentido
que ele tá juntando ele junta e aceita
entrar pro repositório então assim eh se
a gente pensar em código versus Git o
Git você você conseguiria eh posicionar
ele como um versionadores ele não tem
muito conhecimento que ele tá
versionando tem algumas ferramentas mais
acadêmicas que tentam olhar mais paraa
estrutura Então a gente tem
versionamento
semiestruturados versionamento
estruturados que eles conhecem a
estrutura do que eles estão versionando
né E por que será que esses sistemas não
não decolaram acho que tem alguns
motivos interessantes o Git por ele
trabalhar com arquivos ele versiona
qualquer coisa então eh qualquer coisa
que você pode colocar num Arquivo ele
vai aceitar e você vai conseguir
versionar ele é muito rápido no que ele
faz né O Git como um exemplo mas poderia
ser subversion poderia ser qualquer
outro sistema Eles são muito rápidos
porque eles trabalham com elemento muito
simples eles não temm extrair a ST de do
artefato entender profundamente o
artefato para fazer um merge muito mais
elaborado né essas ferramentas
especializadas Elas
têm essas características Mas então
posicionando dessa forma
eh a gente pode pensar que o Git é o
canivete suíço ele versiona qualquer
arquivo desde que ele tenha linhas de de
seja decomposto em linhas né seja um
arquivo texto se o arquivo for binário
ele guarda na íntegra aquele
arquivo mas a gente tem espaço para
versionar de forma especializada muitos
artefatos né durante a minha carreira
eh orientando alunos ou no meu próprio
doutorado eu fui brincando com
versionamento de coisas diferentes né a
gente já fez sistema de versionamento de
modelos uml que tem complexidades
diferentes de você tentar versionar
arquivos com linhas a gente já trabalhou
no versionamento de modelos matemáticos
de XML de workflow científico de
experimento científico de imagem de
vídeo então eh a a brincadeira é essa se
você tem um artefato e esse artefato
evolui se ele muda com o tempo com
passar do tempo cabe você pensar numa
forma div versionar esse artefato em uma
forma que seja eficiente que não ocupe
muito espaço né que Facilite merge
coisas desse desse tipo você poder ter
várias pessoas trabalhando em paralelo e
assim por diante mas assim para concluir
eh olhar pro guit como canivete suíço é
é uma é uma forma interessante porque
nem para código ele é ele é tão bom
assim sim né ele não é especializado ele
versiona arquivos e linhas de código
linhas do arquivo em geral
né Muito bom
então nessa linha ainda de versionamento
de software vocês seus coautores são
vários né eu não vou mencionar aqui os
coautores Mas a gente sempre deixa o o
link pros artigos no na descrição do
episódio né tanto no YouTube quanto nas
plataformas de áudio e outra coisa que a
gente faz aqui a gente traduz o título
pro português lá no na descrição tá em
inglês e o link do do artigo em inglês o
artigo é sobre a natureza dos conflitos
de fusão que é é uma tradução que me
deram aqui para merge né mas eu acho que
os os desenvolvedores de software
geralmente usam merge mesmo sobre a
natureza dos conflitos de merge um
estudo de
2731 projeto Java de código aberto
hospedados no github e esse artigo foi
publicado na i3e transactions on
software Engineering é uma das
principais revistas de engenharia de
software né revistas acadêmicas em 2020
e você pode contar um pouco pra gente
qual foi a motivação deste artigo Quais
foram os principais resultados esse
artigo tem uma história interessante eh
ele é resultado da tese de doutorado do
gleif guioto que hoje é professor da
Federal de Juiz de Fora
eh o gleif tinha em mente junto com
comigo e com o Márcio barbos que é
coorientador do gleif e qu com a
colaboração do André Vander Hook da
Califórnia eh ele tinha em mente
resolveu um problema muito específico de
merge ele queria para para um caso
específico buscar por uma solução
automática e ele trabalhou um pouco
nisso começou a pensar na solução foi
pro exame de qualificação a banca achou
interessante mas um membro da banca
falou mas gleif com que frequência esse
problema acontece e a gente não tinha a
gente já tinha visto alguns casos né mas
a gente não tinha quantificado
efetivamente a frequência daquele
problema então aprovou o exame de
qualificação mas a gente ficou com
aquela Puga atrás da orelha e o próximo
passo dele foi tentar entender Com que
frequência né no no em projetos aquele
problema acontecia e na hora que ele
começou a investigar Ele percebeu que
era muito raro calhou da gente se
deparar com aquele problema algumas
vezes Mas no geral aquela situação que
ele tava dando uma solução era muito
pouco
frequente mas nessa investigação do
problema dele ele começou a perceber que
existiam características que eram meio
que recorrentes em conflitos de merde
então ele de certa forma mudou o tema do
doutorado dele ao invés de solucionar um
problema que era pouco frequente ele
passou a se interessar em entender um
pouco melhor quais são essas
características que são mais recorrentes
em conflitos de merge porque ao entender
um pouco melhor ele Talvez traria I Ah
insights para quem quisesse depois
produzir ferramentas que visam
automatizar ou apoiar esse processo de
resolução de conflitos né então algumas
observações que ele conseguiu coletar
desses projetos Ele Fez análise tanto
automatizada mas também a análise manual
eh de de alguns projetos uma observação
bastante interessante é que em 87% dos
chunks é só para dar um contexto do que
que é um Chun né eh deixa eu dar um
passo para trás eu vou ter um merge
quando pessoas trabalham em paralelo em
cima de um de um projeto né então se eu
tenho duas três cinco pessoas
trabalhando ao mesmo tempo em algum
momento Essas pessoas vão devolver a
contribuição delas pro repositório e que
devolver depois ela tem que integrar o
que ela fez com o que os outros fizeram
né que devolveram
anteriormente e nessa integração eh o
sistema de controle de versão ele tenta
resolver automaticamente essa junção
esse merge mas em alguns momentos ele
não consegue ele se depara com situações
de conflito né situação que ele não
consegue automaticamente falar como é
que integra aquele código e a gente fala
que um merge ele pode ter vários chunks
de conflito várias regiões de conflito
porque você não necessariamente tem um
único conflito se uma pessoa mexu em 5
métodos e a outra pessoa também mexeu em
três desses cinco eu vou ter três
regiões que vão vão sofrer conflito onde
de só um mexeu o sistema vai conseguir
resolver automaticamente Mas onde teve
colisão o sistema vai reportar como
conflito então Eh o que ele percebeu é
que
87% da desses chunks Eles foram
resolvidos quer dizer tinha um conflito
e algum desenvolvedor foi lá e resolveu
esse conflito usando só as linhas que
estavam lá disponíveis no Chun o cara
não escreveu código novo para
resolver eh esse Insight ele é muito
interessante né ou o cara pega a versão
porque eu tenho um Chunk eu tenho a a
versão de um lado a versão do outro lado
né A gente chama de v1 ou V2 é o pai
daquele merge de um lado ou do outro ele
pode escolher um dos dois ou ele pode
concatenar um com o outro ele pega as
linhas da esquerda as linhas da direita
e põe uma atrás da
outra ou ele pode combinar essas linhas
ele pinça algumas linhas de um lado
algumas linhas do outro e combina numa
solução ou ele pode escrever código novo
ele pode ir lá e escrever um código que
não tem nada a ver com aqueles dois
originais né então esse achado dele
trouxe um Insight muito interessante que
Poxa na grande maioria das vezes o
código já tá lá se eu quero bolar uma
ferramenta É claro que eu vou ter ali
13% dos casos que eu teria que gerar
código novo na minha ferramenta para
resolver aquele merde mas em 87% deles
eu vou est consumindo o código que
existe out outra coisa que Ele
identificou é que a grande maioria dos
chunks 94% dos dos chunks tem 50 linhas
ou menos Então os chunks eles de modo
geral não são monstruosos eles São
relativamente pequenos ele percebeu que
40% dos merges tem um único Chunk então
não dá para falar que a maioria mas é é
a o extrato com maior quantidade é a
moda né então 40% tem um único Chunk e
para esses
60% que tem mais de um Chunk ele
percebeu que mu das vezes se você
ordenar esse Chunk e resolver numa ordem
pré-estabelecida ao resolver um você
resolve outros indiretamente então deixa
eu dar um exemplo rápido que seja
didático imagina que
eh se editor duas pessoas editaram a
definição de um método o cara da
esquerda botou um um um parâmetro novo e
um cara da direita trocou o tipo de
algum parâmetro de algum argumento que
já tinha no método quando o cara da
direita eh coloca um parâmetro novo ele
tem que revisitar todas as chamadas
desse método né então se eu tenho a
declaração de um método e ele tem cinco
chamadas no código ao editar o a
declaração eu naturalmente vou corrigir
essas chamadas pro meu código compilar o
cara que editou na esquerda ele também
editou a declaração e ele revisitou as C
chamadas para ajustar aquela nova
declaração então eu acabo tendo nesse
caso seis chunks de conflito eu tenho
conflito na declaração eu tenho conflito
em cada uma das chamadas mas talvez
dependendo do que eu escolha fazer de
resolução no Chun da declaração eu
consigo propagar essa resolução paraas
chamadas se eu resolver ficar com a
solução da direita automaticamente eu
sei que eu vou querer ficar com toda a
solução da direita para todas as
chamadas
Então essa esse achado foi interessante
que ele traz a luz de que a gente tem
que olhar paraa ordem dos chunks não é
sair resolvendo Chunk em qualquer ordem
dependendo da ordem que eu resolvo ao
resolver um eu propago e consigo
resolver
eh os outros chunks e por fim uma coisa
que a gente percebeu que é bastante
interessante é que tem algumas
resoluções que são meio que padrões
dependendo de onde o conflito acontece
Dependendo de quem é o desenvolvedor
então só para dar um exemplo para
quando a gente tem conflito em importe
quase sempre a resolução é por
concatenação né porque quando você tem
um conflito em importe a ordem dos
importes não é relevante então
basicamente você na maioria das vezes
quer todos os importes que as pessoas
fazem é concatenar o código e de um lado
com o código do outro lado isso não se
repete em outras estruturas de código
então esse achado De repente pode ser
útil se você tiver implementando uma
ferramenta para resolução automática ele
considerar Qual é o o local da daquele
conflito para ele aumentar a
probabilidade de uma resolução
específica para aquele conflito Então
esse esse paper ele teve a contribuição
principal dele é muito nessa linha
tentar entender um pouco melhor esse
problema e trazer insights para quem vai
desenvolver ferramental para resolução
de conflito de
merge muito bem e daí nós temos aqui
também separado outro artigo que você e
seus colegas né colaboradores publicaram
também na in3 e
transactions desta vez em 2021 eh esse
artigo é intitulado recomendando
participantes para sessões de merge
colaborativo então Nesse artigo vocês
acabam por apresentar e uma abordagem
chamada tip
merge Projetada para recomendar
participantes para sessões de m
colaborativo você pode nos explicar um
pouco a respeito dessa ferramenta e do
que foi Quais foram os o as os
resultados né os achados também desse
artigo claro essa esse trabalho é
resultado da tese de doutorado da
Catarina Costa que hoje é professora da
federal do Acre na verdade já era na
época que ela fez doutorado comigo eh em
colaboração com a Anita sarma eh dos
Estados Unidos e
a o ponto chave desse trabalho é que a
gente percebia que muitas pessoas evitam
merge seja em consultoria seja em
conversa com os próprios alunos seja em
conversa com colegas então tem muita
gente que evita o merge pelo medo ou
pela dificuldade de fazer o merge em
especial Quando a pessoa não é muito
especialista naquela região de código
então ela tem muita insegurança em fazer
um merge grande que afeta vários
arquivos mexidos por várias pessoas e
ela não conhece muito aquela região
então a Catarina primeiro rodou um serve
que a gente publicou num outro Journal
eh entrevistando 164 desenvolvedores e
ela chegou à percepção que 75% dessas
pessoas quando precisam resolver um
merge mais complicado elas pedem ajuda a
outra pessoa então isso já trouxe Opa
então a pessoa de modo geral não resolve
sozinho ela precisa consultar alguma
outra pessoa a gente fez uma mineração
em repositório a gente percebeu que tem
alguns mes que são extremamente
complexos então no projeto rails a gente
encontrou um merge que tinha comit de em
torno de 50 desenvolvedores em cada um
dos Ramos então 50 pessoas mexeram num
ramo outras 50 mexeram no outro Ramo e
Alguém teve que fazer o
merge e o merge ele é tradicionalmente
uma tarefa solitária a maioria das vezes
é uma pessoa que faz esse merge ela põe
o nome dela lá naquele comite que ela
fez o merge né então a gente começou
primeiro a nesse projeto tip merge a
gente começou a pensar como é que a
gente consegue recomendar alguém para
fazer o merge eh a gente publicou a
primeira versão do TIP merge no fsi de
2016 e ali o que ele fazia era analisar
o histórico do projeto a gente passava
para ele duas dois ramos que eu quero
fazer o merge ele ia fazia uma mineração
nesses Ramos fazia uma mineração no
histórico comum Percebi as pessoas que
mais contribuíram as pessoas que
contribuíram com mais abrangência nos
artefatos modificados se alguém
contribuiu nos dois ramos e assim por
diante e recomendava fazia um ranking de
pessoas que eram as mais recomendadas
para serem convidadas a fazer aquele
merge Então esse foi o resultado desse
paper original do FS depois a gente
continuou trabalhando nessa linha sobre
o TIP merd a gente introduziu nele um
aspecto de otimização de pesquisa
operacional já pensando no m
colaborativo a gente falou Poxa mas e se
ao invés da gente falar convidar uma
pessoa para fazer ao merge E se a gente
convidar um grupo de pessoas a primeira
solução seria simplesmente pegar o nosso
ranking da primeira versão do TIP merge
pegar os top TR do ranking e convidar o
top TR falar vocês três venham aqui
façam esse
mer só que a a nossa discussão era mas
será que não existe uma sobreposição de
conhecimento que às vezes o cara que tá
em segundo do ranking ele realmente é o
segundo mais entendido do projeto mas
ele entende das mesmas coisas que o
primeiro entende então essa sobreposição
não traria muito muita vantagem para se
montar um time de resolução de merge e a
gente trouxe essa ideia de otimização
para fazer uma busca pela configuração
de quem seriam esses três essas três
pessoas que geraria maior cobertura de
conhecimento sobre tudo que foi mudado
naqueles dois ramos que aí uma pessoa
complementaria o conhecimento da outra e
eventualmente eh melhoraria a resolução
do
mé bom e aí a gente rodou alguns
experimentos né usando a versão original
do TIP mer a gente já tem um resultado
bem legal se a gente pegar o top TR que
a gente recomenda e pegar quem de fato
resolveu o merge né a gente tá fazendo
análise retroativa eu tenho os comites
eu tenho os merges que efetivamente
foram feitos eu sei quem foi a pessoa
que resolveu o merge eu tenho a minha
ação e eu posso comparar será que esse
cara que resolveu Tá entre os top três
que eu recomendaria a gente percebeu que
a gente tem 90% de acerto basicamente
pegando o top três do
ranking só que se a gente usa essa ideia
de cobertura de conhecimento usando
otimização a gente conseguiu aumentar em
50% de forma normalizada a cobertura de
conhecimento se comparado com pegar o
top TR então e essa essa evolução foi
interessante a primeira versão já era
interessante ela já conseguia recomendar
bem as pessoas e a segunda ela conseguiu
aumentar um pouco essa
percepção de Quem deveria efetivamente
ser recomendado e aqui tem um caso que
foi legal eh a gente acabou fazendo uma
pesquisa muito quantitativa mas a gente
trouxe um aspecto qualitativo em alguns
projetos a gente teve acesso aos
desenvolvedores em um projeto específico
um projeto grande open source a gente
teve acesso a um desenvolvedor e a gente
apresentou para ele casos onde a nossa
ferramenta errou a gente falou olha a
minha ferramenta nesse merge que você
fazia parte que você foi o cara que fez
o merge a minha ferramenta ela
recomendou fulano de tal mas
efetivamente foi você então a gente
errou e a gente teve um feedback
qualitativo muito interessante nesse
caso específico o cara falou não vocês
não erraram eu tava fazendo per
programing com esse outro cara a gente
resolveu isso junto só que na hora de
fazer o comite tinha que tá na conta de
alguém então saiu no meu mas não tá
errado falar que esse cara era um cara
apropriado né Então aí mostra até outra
deficiência do Sistema de Controle de
versão né o Sistema de Controle Deão eh
você dá comite é você que tá dando
comite mas às vezes você faz algo
colaborativamente usando per program
usando alguma outra técnica e o sistema
de controle de versão perde esse
conhecimento de que tinha alguém junto
com você mas assim resumidamente a ideia
desse trabalho foi olhar pra pessoa que
vai fazer o merge e tentar pensar se
isso não é uma atividade colaborativa e
se a gente não deveria ter um time para
ser recomendado para fazer merges
difíceis aqui eu não tô falando daquele
merge que a gente faz no dia a dia para
atualizar a sua área de trabalho é mais
um merge de Ramos Ramos que coexistiram
por muito tempo né eu tô precisando
integrar esse
código muito bom então vamos falar agora
de um outro
trabalho seu dos seus coautores foi em
2014 no workshop que vocês começaram a
trabalhar com isso né publicaram um
artigo no workflow capturando E
analisando a procedência de scripts né a
tradução é procedência mas o termo
inglês é provenance e o no workflow é
uma ferramenta que captura de forma
transparente a procedência de scripts e
possibilita a produti bilidade o que tá
escrito lá no no repositório do workflow
eh O projeto no workflow tem como
objetivo permitir que os cientistas se
beneficiem da análise de dados de
procedência mesmo quando não estão
usando um sistema de fluxo de trabalho
então uma curiosidade desse repositório
aí do do n github é que ele tem 111
estrelas 26 Forks né que é um número bom
para um projeto de pesquisa eu entrei na
página também do do do projeto tem sete
publicações pelo menos né entre 2014 e
2022 então Leonardo Você pode falar um
pouco pra gente sobre esse projeto dos
resultados até agora claro prazer eh
essa tradução do provenance o pessoal no
Brasil no português está traduzindo como
proveniência né que tem um pouco a ver
com procedência né mas talvez seja um
pouquinho mais amplo eh deixa eu falar
um pouco de proveniência antes de eu
falar né e parece que Poxa que mudou da
água pro vinho né a gente tá T falando
de controle diversão agora eu tô indo
para outro lugar mas elas são são coisas
muito próximas Ou pelo menos na minha
cabeça eh a ideia da proveniência ela
remete
a ciência Claro mas também remete a
obras de arte remete a qualquer objeto
de valor né então se eu pego um vaso
eh velho né e e que eu vou jogar no lixo
ali aquele vaso já não presta mais para
mim que que eu vou jogar no lixo porque
ele perdeu a função né ele não é mais
decorativo ele não é eh funcional Mas eu
posso ter um vaso que é velho que não é
mais decorativo não é funcional mas vale
milhões de reais e eu não vou jogar no
lixo eu vou deixar no museu por quê
Porque ele tem uma história né a
proveniência ela arete um pouco à
história aquele vaso foi ele tem eh 1000
anos ele ele foi usado numa cerimônia
muito importante ele foi do Rei e tal né
ele tem uma uma história que faz ele ter
valor né não tá na funcionalidade não tá
na estética mas tá na história então a
proveniência ela remete à história
desses objetos né e eu posso pensar em
proveniência em praticamente todo o
contexto que eu tô envolvido né se eu
pensar em alimento né meu meu filhinho
tem alergia a proteína do ovo se a gente
vai em algum lugar e vê um bolo e vê
alguma coisa a primeira pergunta que eu
faço é da proveniência eu pergunto vem
cá tem ovo nesse bolo né e a pessoa
deveria Às vezes a pessoa não sabe me
responder às vezes ela liga para alguém
às vezes ela pega um um papel que tá
escrito lá os ingredientes a lista de
ingredientes é a
proveniência daquele bolo né então
quando a gente pensa em proveniência de
um objeto a gente pensa em em três
elementos chave a gente pensa nos
insumos nos artefatos que compuseram
aquele objeto a gente pensa nos
processos de derivação que foram usados
e a gente pensa nos agentes que usaram
naquele meu primeiro exemplo aquele vaso
ele foi de um rei é um agente que usou
que interagiu com aquele objeto que fez
com que ele tivesse mais valor é a
camisa que o Pelé usou quando marcou o
gol tal a camisa em si tem não é tão não
tem tanto valor mas o fato dela ter sido
do Pelé naquele processo que era o jogo
tal então a proveniência ela ela de
certa forma junta esses três elementos e
quando a gente vai pra pesquisa
científica a proveniência tem muita
importância né eu tô fazendo tenho um
workflow científico eu tô fazendo
simulações científicas eu tô rodando
experimento científico eu chego num
resultado eu preciso conseguir explicar
esse resultado eu preciso conseguir
reproduzir esse resultado eu preciso
saber quem são os os processos que
rodaram as transformações que ocorreram
os artefatos de entrada que ajudaram a
construir aquele aquele resultado né
então existem sistemas de de controle de
experimento científico são famosos um
deles é o vros que é feita pela foi
criado pela Juliana Freire em Nova York
que ele permite que você modele um
workflow científico você roda esse
workflow e ele coleta a proveniência ele
consegue te explicar o que que
influenciou naquele resultado e em 2013
a minha esposa Vanessa braganholo ela
também é é professora do Instituto de
computação ela da área de bancos de
dados
e eu e ela fomos para Nova York eh ficar
TRS meses lá com a Juliana Freire e ela
tem essa esse vi workflow científico
quando a gente chegou lá ela falou que
ela uma coisa que chamava muita atenção
dela é como que as pessoas estão usando
Jupiter notebooks né então cientistas em
geral estudantes as pessoas estão usando
muito script Python para rodar Os
experimentos científicos dela e
Quando você pensa em script Python Você
não tem o suporte de proveniência que um
v trils por exemplo oferece Então ela
trouxe um desafio pra gente falou bom
vocês vão trabalhar aqui comigo então
vamos tentar levar para um pesquisador
que usa um script Python algum apoio à
proveniência aí nasceu o no workflow né
a ideia do do no workflow é ser
transparente Então você pega um script
Python seu que executa uma simulação que
roda algum experimento ao invés de você
rodar Python e o teu script você roda
Now Run e o teu script e o no workflow
vai executar teu script mas ele vai
coletar um conjunto de de informações
importantes por exemplo e na verdade aí
entra a engenharia de software né o que
eu usei ou o que a gente usou foi
basicamente técnicas de engenharia de
software a gente usou program slicing
que é algo que a gente eh normalmente
usa para você entender fluxo de execução
a gente usou infraestrutura de debugging
a gente fez coleta de módulos então
basicamente quando termina a execução
daquele script se você tem um
determinado resultado você consegue
questionar o sistema do que que
influenciou esse resultado ele consegue
montar um grafo para trás com arestas
para trás apontando quais processos E aí
os processos são as funções do script
Python quais processos foram acionados
Quais foram os parâmetros de cada um
desses processos então ele cons consegue
andar para trás até chegar nos
parâmetros originais ou nos arquivos que
foram lidos então eh ele traz esse raio
x da execução do script quais módulos
foram executados e assim por diante de
forma transparente Então esse foi o
nosso objetivo né e dali surgiram esse o
Nok Flow nasceu nessa nossa visita na
universidade de Nova York logo depois um
aluno ex-aluno meu de doutorado João
Felipe Pimentel ele começou o doutorado
nesse tema ele herdou o no workflow Se
você olhar as publicações seguintes ele
é primeiro autor acho que provavelmente
de todas elas né Então ele deu
continuidade fez várias implementações
experimentos interessantes ao redor do
no workflow inclusive integrando no
Júpiter notebook fazendo coisas assim
mas a ideia eh eh em suma é você
conseguir entender porque que você
chegou num determinado resultado no
final da execução de um script e
consegui e explicar de certa forma esse
resultado analisando esse fluxo de de
chamadas de funções e tal e aí tem um
caso que é interessante a gente ia fazer
um demo do no workflow então a gente eh
rodou o workflow treinou o demo ali tava
tudo direitinho e depois fom rodar de
novo para treinar esse demo de novo
fizemos o mesmo Trial e ele gerou um
resultado diferente né no demo nosso a
gente falou noss não é possível Será que
tem um bug no no workflow aí a gente
Olhava O gráfico que ele gerou de
resultado era uma análise de
precipitação o gráfico tava igual a
gente falou Pô mas esse gráfico tá igual
e ele tá falando que é diferente e eu
tinha na época um aluno que tava
trabalhando com dif de imagem aí eu
peguei aquelas duas imagens e mandei pro
meu aluno falei cara faz um dif dessas
imagens não é possível aí ele rodou o
dif e realmente tinha um pequeno desvio
nas fontes todas as legendas pareciam tá
um pouquinho deslocado aí a gente foi
analisar a proveniência a gente
descobriu que a gente não mexeu em nada
no Script a gente rodou na mesma máquina
tava tudo igual só que uma biblioteca do
que o Python chamava nessa máquina tinha
mudado e a gente foi ver o whatsnew da
biblioteca ele tinha trocado a fonte
então quer dizer o sistema na verdade
estava funcionando como ele deveria
funcionar qualquer pequena mudança no
resultado ele deveria apontar que é
diferente e me ajudar a entender Qual
foi a causa que que levava aquele efeito
que foi observado no resultado então é
eh no flow tem essa pegada aí de que aí
por que que isso me remete a todo o
resto que eu faço né se a gente pegar um
grafo de proveniência ele vai apontando
para trás ele tenta explicar a origem de
um artefato Se você pegar qualquer
gráfico de qualquer grafo de qualquer
livro sobre o Git ele faz exatamente a
mesma coisa a gente quando tá
representando and versões a gente aponta
para trás a gente não aponta para frente
que a gente tá mostrando a evolução do
atual pro passado né então tem muita
semelhança entre os dois mundos div
versionamento eh e de
proveniência muito legal bem você também
tem um artigo aqui de 2021 né que foi
publicado no empirical software
Engineering e e o o título do artigo é
compreendendo e melhorando a qualidade e
a reprodutibilidade de Júpiter notebooks
aí você podia explicar pra gente um
pouco a respeito do Júpiter notebooks e
também né O que vocês fizeram neste
artigo Beleza então esse artigo ele é
trabalho do João Felipe também né com
colaboração da Juliana Freire lá de Nova
York e com a Vanessa braganholo que foi
coorientadora do João Felipe eh
esse trabalho ele de certa forma
constrói um pouco em cima do que a gente
discutiu antes né a gente tinha essa
preocupação com experimentos são
escritos em Python e a gente começou a
perceber que o Júpiter notebook ele é um
um um artefato tá ficando cada vez mais
recorrente na escrita de experimentos em
Python né só para dar um contexto para
quem não conhece o Júpiter
notebook Júpiter notebook ele é um
ambiente onde você consegue
escrever um programa de forma separada
você tem células Então você escreve um
pouco do teu código você pode mandar
executar esse código ele guarda o
resultado da execução e te mostra e você
escreve mais um pouco de código
construindo em cima do que você escreveu
antes e é uma forma muito interessante
para você fazer uma construção
exploratória de código eu não sei
exatamente o que eu quero eu quero
explorar então eu escrevo um pouco de
código olho que ele produziu em função
do que ele produziu escrevo mais código
vejo que produzir vou fazendo isso e e
vou chegando nos resultados que eu tô
querendo
explorar
eh Talvez remeta um pouco se eu tô
usando se eu não tô usando Júpiter se eu
tô usando uma infraestrutura
convencional é muito comum a gente
colocar prints no código né então eu tô
escrevendo um código e de tempos em
tempos eu ponho algum print para eu ver
se aquilo ali tá caminhando pro lugar
que eu gostaria né então o Júpiter ele
faz isso de uma forma um pouco mais
formalizada e o que é interessante do
Júpiter
ele guarda tanto o código quanto o
resultado da execução então quando eu
faço um Jupiter notebook por exemplo
para fazer uma determinada análise ou
fazer um determinado experimento que eu
vou escrever no meu paper eu posso
publicar aquele Jupiter notebook ele tá
externalizando tanto os scripts que eu
usei para para fazer o Meu experimento
quanto todos os resultados que vão sendo
gerados por aquele script ficam
guardados no Jupiter notebook então Isso
facilita muito reproducibilidad né eu
consigo saber o que que aquele aquele
pesquisador gerou da primeira vez
consigo
reexecutados
ele usava um cluster lá na enu usava
servidores nossos na uf a gente ficava
guardando aquele volume absurdo de de
escr ele extraindo os dados daquele
script né então ele chegou algumas
observações
interessantes primeiro que a maioria dos
Notebooks eh Eles não têm muitas células
então a gente encontrou uma mediana de
14 células que não é um número tão
significativo né não são notebooks
imensos a gente observou que a
documentação ela vai diminuindo pro
final do notebook então tem notebooks
que começam com uma documentação uma
explicação muito clara cada a célula
muito bem explicada e na hora que você
vai caminhando pro fim vai ficando tudo
meio só código né então é observação
talvez remeta até um pouco aos nossos
processos de engenharia de software né
Eh a gente aqui tem umas características
interessantes quando a gente pensa em
data Science quase sempre as pessoas
falam de machine learning como se fosse
uma coisa atrelada a outra eu tento
lutar para mostrar que não que eu posso
fazer deita Science sem machine learning
mas a gente percebeu que desses
praticamente 1 milhão e meio de
notebooks só 25% deles que usavam
bibliotecas de machine learning então
tem muita gente fazendo muito notebook
de análise de de dados que não
necessariamente vão fazer a aprendizado
de máquina a gente descobriu que só 2%
deles T testes né então né o o pessoal
tá fazendo software né
Eh eu até escrevi um projeto um tempo
atrás que as cientistas também são
Engenheiros de software era até uma
paródia a essos também são software né
que é um paper famoso
eh e esses cientistas que são
Engenheiros de software estão fazendo
software mas estão sem o nosso apoio de
engenharia de software né então 2% só
que tem teste só 12% declaravam
dependência né Eu já falei antes daquele
problema do dependency Hell que é um
problema preocupante na na gerência de
configuração se eu não declaro
dependência como é que eu vou reproduzir
como é que eu vou
reexecutados eu não sei quais são as
bibliotecas que ele depende pior eu não
sei quais versões porque se eu tento
rodar ele vai reclamar que não consegui
uma determinada e não consegui rodar
alguma coisa algum módulo eu descubro
Qual é a biblioteca e instalo só que
será que eu tô rodando na mesma versão
que o cara rodou quando ele ele executou
o experimento então eu não consigo
garantir isso se eu não consigo garantir
isso a chance de eu não conseguir
reproduzir aumenta bastante né então só
12% declarava Independência E aí entrou
num num um aspecto interessante a gente
tentou executar esses notebooks como a
gente instalou um ambiente pegando tudo
que a gente podia de dependência
deixando pré-instalado então é um
ambiente que em tese seja o que for que
você dependa tô falando dos pacotes mais
usuais a gente vai ter
disponível mesmo assim só 25% desses
notebooks re executaram né então isso já
é preocupante o cara publica o troço lá
no no github a gente acha que Poxa
publicou Então vou conseguir reproduzir
na verdade eu não consigo executar só 25
executado desses 25 só 99% reproduziram
o resultado que tava na célula quer
dizer eu rodei de novo e eu não chegava
no resultado que o cara chegou aí a
gente falou não mas o problema é nosso é
porque de repente a gente tá buscando
para um resultado exato e a gente
deveria buscar para um resultado
aproximado então quando eu tenho um
número que é ponto flutuante eu deveria
aproximar a gente fez uma sequência de
aproximações mesmo assim a gente
conseguiu chegar no mesmo resultado só
em 15% deles né então acho que a
mensagem que esse paper trouxe Na
verdade nesse Paper A gente discute boas
práticas algumas recomendações a gente
implementou um link que você pode rodar
como Plugin do Jupiter Lab ele vai te
dando dicas enquanto você tá escrevendo
o seu notebook mas a a mensagem
principal é essa preocupação em ser
possível re executar e melhor ser
possível reproduzir aquele dado aquele
resultado né a gente como pesquisador
quando a gente tá publicando nossos
nossos scripts a gente deveria pensar no
cara que vai rodar aqueles scripts né e
entregar para ele com uma facilidade de
instalação das bibliotecas que dependem
uma boa descrição de quais são as
versões dessas bibliotecas e tentar
garantir que aquilo ali vai executar
novamente quando a gente eh quando outra
pessoa tentar rodar aquele nosso
experimento Então acho que essa foi a
principal mensagem aí desse desse
paper é muito legal eu eu trabalho essa
questão dos Notebooks tenho trabalhado
inclusive até com um aluno que dev
comear
agora mestrado quer dizer ele já começou
como especial mas Dev começar como
regular em breve com o livebook Você
conhece o livebook já falar livebook é
meio como como se fosse o Júpiter
notebook só para que para linguagem de
programação elir
e até eu eu achei graça o momento que
você tava falando não sei quem tiver
assistindo no YouTube po pode ter achado
Mas eu achei graça porque você fala ah
no final tem menos código ou tem tem
mais código né menos texto porque eu e
esse aluno a gente foi responsável por
dentro de uma iniciativa chamada learn
for lixir de fazer os notebooks de
ensino né sem usar ciência de dados sem
usar Machine learn é só ensino da
linguagem o básico do básico da
linguagem né e assim vou olhar lá o
depois eu posso até colocar o
repositório
eh no finalzinho realmente tem mais
código no começo tem um monte de texto
assim porque tá mais animado né Eu acho
que tem tem Esse aspecto e tem um outro
aspecto talvez tenha a ver com a
cognição né você tá apresentando algo
novo no início você tem que ser mais
didático se a pessoa já entendeu aquela
dinâmica no final talvez não seja tão
nocivo mas é fato né a gente observou
que a documentação ela vai declinando
eh no andar do notebook
né É E outra coisa que talvez a gente
precise ver é questão exemplo Até onde
eu sei os os notebooks de LX né os Live
books Eles não têm informação sobre o
software então a gente postou lá mas a
gente assim a gente sabe que hoje em dia
o LX tá na versão Sei lá 1.15 1.16 o
livebook na versão 0.10 mas E daqui a um
ano
n Será que vai ser compatível não tem
nenhuma informação no documento Depois
eu vou ver lá com o pessoal da equipe
para ver se a gente pelo menos Coloca
essa informação isso aí é gerência de
configuração tá vendo ela tá em todo
lugar é mas aí então eu aproveito passo
a pergun isso deveria estar por exemplo
deveria ter no próprio software livebook
ele colocar lá no o documento livebook
um Mark com algumas coisas a mais o
próprio livebook Eni informação lá
talvez até como comentário escondido do
HTML ou é responsabilidade de cada
desenvolvedor colocar isso eu eu não não
tenho uma resposta para te dar mas o que
eu tenho percebido né quando eu comecei
a programar em Java ainda na década de
90 não existia essa preocupação né as
pessoas quem tinha preocupação escrevia
num TXT qual era as versões das
dependências E aí depois tanto que se
você pegar o ente o ente não tinha essa
preocupação ela tinha muito mais
preocupação com a automação do que com
as dependências o maven trouxe essa
preocupação mais Intensa com as
dependências né então eu tendo a achar
que o caminho natural não sei se estaria
dentro do próprio notebook ou se seria
um artefato irmão do notebook né a
vantagem de tá dentro é que você
consegue compartilhar aquele notebook
você já tá levando tudo né então você
manda aquele notebook você publica ele
no github você manda para alguém o cara
já estaria levando toda a informação que
ele precisa né a desvantagem é que você
tem interesses ali que são ortogonais e
talvez você esteja sobrecarregando né
aquele aquele artefato com os interesses
mas eu acho que é uma tendência natural
da da maturidade da gente a gente vai
tentar reproduzir não vai conseguir
porque hoje você consegue mas daqui a 1
2 anos talvez não consiga né E isso
talvez faça as comunidades a pensarem
com mais carinho né em em ter uma forma
de declarar seja a versão do própria da
própria linguagem seja a versão de
dependências que você tem na que você
usa naquele naquele notebook né É só
para clarificar a as dependências tem lá
a versão mas por exemplo nesse caso
específico aí a gente não usou nenhuma
dependência só usou o próprio a própria
linguagem elixi e aí não tem nenhuma
informação sobre isso quer dizer talvez
até tenha depois vou olhar lá agora a
gente vai chegar num numa outra parte né
de outros temas né gente já falou
bastante sobre sua pesquisa tem muito
mais claro lá no na sua página no seu
perfil no dblp no scholar tá tudo lá na
descrição do episódio é que você foi
recentemente escolhido como pesquisador
homenageado da ces AZ é a comissão
especial de engenharia de software da
Sociedade Brasileira de Computação Então
você foi escolhida é o foi escolhido de
2023 né em 2022 foi o professor Eduardo
Almeida que a gente entrevistou em 21
foi o Marco Túlio valente que a gente
entrevistou também a gente entrevistou
vários aqui eh eu acho que teve alguns
que a gente não entrevistou teve uma que
a gente entrevistou no no emílias
podcast professora Itana Gimenes tem uma
que a gente vai entrevistar ainda a
professora thí Batista enfim é uma
homenagem que a a ces faz para pros
pesquisadores pesquisadoras do Brasil
todo ano tem um um pesquisador
pesquisador homenageado então a pergunta
para você é o que este reconhecimento
significa para você
é essa pergunta é ela É acho que muito
difícil de responder muito importante
mas em primeiro lugar qualquer
reconhecimento vindo da comunidade que a
gente tá inserido ele é é muito legal né
Assim você fica muito feliz quando você
recebe esse reconhecimento
eh eu acho que uma forma bem pragmática
de de falar da importância que talvez eu
tenha sentido quando recebi Esse
reconhecimento é um pouco isso aí que
você falou você falou de nomes de
pessoas que são pessoas que eu admiro né
Se você pegar a lista das pessoas que
ganharam essa premiação né São pessoas
que se tem de da minha geração tem
pessoas de geração anterior né São
pessoas que eu admiro muito o trabalho é
difícil falar aqui a o nome das pessoas
porque eu vou sempre deixar de falar
várias outras né mas um que eu interagi
muito ultimamente até porque a trabalhar
com merge então a gente tava trocando
muita figurinha é o Paulo Borba da da
UFPE mas tem vários outros esses nomes
que você falou agora do Eduardo do Marco
Túlio né a geração anterior né o
Guilherme tá lá a Cláudia Werner tá lá
Maldonado todos os nomes que a gente for
pegando da comunidade pessoas que são
exemplo Então acho que esse é um fator
né Eh entrar para essa lista gera muita
responsabilidade por um lado né mas
muita alegria
por outro
eh e e eu acho que tem um Outro fator
que é olhar para quem não está nessa
lista tem tanta gente que eu admiro
tanto na comunidade de engenharia de
software que não está nessa lista então
assim eh ter sido escolhido para entrar
nessa lista traz muita responsabilidade
eu acho que muita alegria mas muita
responsabilidade eu roubei o microfone
lá na abertura do do cbsoft
e e o que eu tentei falar lá É que na
verdade quando é escolhido para algo
assim que que é decorrente da sua
trajetória
eh não é você que tá ganhando aquele
prêmio né porque você sozinho não faz
nada se você pegar todos os meus papers
e e falar não agora eu quero ver os
papers que o Léo publicou sozinho acho
que não vai sobrar nenhum né tudo que eu
fiz na minha vida foi em colaboração né
então lá eu falei dos meus pais da
importância do apoio né se se não
começasse lá embaixo de apoiar quando eu
resolvi fazer mestrado falar faz isso
meu f você tá querendo segue se não
tivesse apoio eh não teria nem o começo
né Depois como a gente falou no início
da entrevista a Cláudia ela me guiou aí
nesse processo de de Formação né com o
apoio do André Vander hu lá eu citei
outras pessoas O o Márcio Barros ele foi
meu coorientador de projeto final e foi
umor coorientador informal importante na
minha trajetória eh três professores lá
da cop que que foram muito importantes
como exemplo né o Guilherme a Ana e a a
Marta então Eh eu convivi bastante com
eles mesmo não sendo meus orientadores
né a gente sempre pega alguns
professores pra gente ter como exemplo
né e minha esposa claro eu acho que E no
caso dela mais especial ainda porque ela
é de computação né então quando você
termina seu doutorado você fica meio que
sem orientador né claro que você pode
bater na porta do orientador que te
formou mas você tem em sua carreira
então você precisa de ter alguns colegas
de referência que você senta de sente de
vez em quando e conversa então ela eh
sempre cumpriu muito bem esse papel eu
brinco com meu filhinho Eu tenho um
filhinho de 3 anos que é o Gabriel Biel
eh ele me fez enxergar a importância do
tempo né a gente usa o tempo de uma
forma muito explic aí quando vem um
filhinho você começa a dar mais valor
pro tempo a uf também teve uma
importância muito grande eu entrei na uf
eh eu sei que tem algum as Universidades
que quando chega uma pessoa nova aquela
pessoa explorada para fazer tarefas eh
que vão consumir muito tempo que não vão
acabar afundando cara lá na uf foi
exatamente o oposto Eu sempre me senti
muito protegido com ambiente muito
favorável para produzir né então é isso
ajudou demais né os alunos eu Brino que
eu deho sempre muita sorte de ter
excelentes alunos então
Eh Aprendo muito mais com eles do que eu
acho que eles aprendem comigo e por fim
a comunidade né o início da minha fala
aqui sobre a homenagem é é que vir da
própria comunidade você tá inserido né
meu primeiro bestest foi em 2008 então
Eh fazem 25 anos que eu tô dentro dessa
comunidade
e e hoje na verdade aquilo que no início
eram colegas hoje são amigos né vários
amigos próximos né então eh eu acho que
foi foi muito muita alegria ess receber
esse homenagem e muita responsabilidade
mais ainda porque eu tenho que dar um
kote no cbsoft do ano que vem né então
eu tenho que já ir começando a pensar
Qual vai ser o assunto
desse Mas é
isso muito bem muito merecido você
coordena também o grupo de evolução e
manutenção de software gens da
Universidade Federal Fluminense e e como
é a parte de o né você está aceitando
mestrandos e doutorandos se sim o que
eles vão encontrar no
Jam Então deixa eu dar um pouquinho do
contexto dessa questão do grupo eu
entrei lá na uf em 2008 quando eu entrei
não tinha ninguém de es na pós então eu
tive a missão ali
de de formar um grupo né então é aquele
negócio do líder de de de um grupo de eu
mesmo né no primeiro momento era só eu
no grupo e aí eu fui captando eh alunos
né o grupo foi crescendo teve um momento
que eu tava com muitos alunos eu tinha
uns 15 alunos somando mestrado com
doutorado
eh e aos poucos foram entrando outros
professores alguns entraram e saíram a
Viviane Torres entrou eh foi para IBM eh
Em algum momento mais paraa frente o
Marcos kalinov entrou e depois foi para
puuk né Então teve alguns professores
que passaram por ali saíram mas eh Em
algum momento a gente começou entrou a
Vânia no no lá na uf entrou na pós a
Vanessa tava trabalhando muito comigo
nesses trabalhos de notebook o Troy um
ex-aluno meu passou no concurso e entrou
também então a gente acabou tendo um
grupo ali que
eh não tinha mais só eu com meus alunos
trabalhando com manutenção tinham
pessoas trabalhando com proveniência
todo mundo colaborando muito e os alunos
interagindo todos usando o mesmo espaço
Mas atuando com proveniência a Vânia
trabalha com teste o Troy trabalha com
uma fronteira de engenharia de software
com jogos então tinham pessoas com
interesses diferentes aí a gente
continua tendo o nome James wof lá no
meu repositório que é onde eu ponho as
coisas dos meus alunos mas a gente deu
uma revolução no grupo e a gente mudou o
nome dele paraa yarg que é ianoda
research group tentando mostrar que não
interessa muito né a nossa ideia do yarg
eu não tem necessariamente o líder eu
sou o coordenador eu sou o líder do
grupo mas o grupo como uma coisa mais
orgânica né que junta pessoas que querem
colaborar que querem trocar ideias então
a gente meio que deu uma diminuída na
importância do grupo né Nós ali somos a
equipe da uf que faz engenharia de
software independente um pouco da da da
nomenclatura do grupo e o James ele
acabou existindo ainda no contexto do
repositório que é onde eu ponho as
coisas dos meus alunos mas ele perdeu um
pouco identidade mas em relação a alunos
eu acho que a gente sempre tá com a com
as portas abertas né se o aluno for bom
e tiver afim de fazer um bom trabalho
tiver afim de se dedicar gostar desse
tema a pessoa tem que amar bastante o
que tá fazendo né então se se gostar
desse tema a gente sempre tá com portas
abertas para alunos de Mestrado alunos
de doutorado o grupo nesse momento tá
com uma característica muito específica
em doutorado né então eu tenho muito
mais alunos de doutorado do que de
Mestrado mas é um momento por alguma
razão a gente configurou desse jeito né
mas eu acho que é normal mal isso os
grupos flutuam às vezes crescem diminuem
mas sim se tiver algum aluno escutando
que tenha interesse em trabalhar com
esses temas relacionados à gerência de
configuração eh merge versionamento Eh
estamos de portas abertas só entrar em
contato na verdade não só alunos Se
tiverem colegas também que querem
colaborar ao redor desses temas eu tô
sempre à disposição gosto bastante de de
interagir com outras pessoas eh esse
tipo de
assunto muito legal então agora a gente
vai falar de um tema que até foi um
alguns comentários lá no grupo existe um
grupo de WhatsApp dos pesquisadores de
engenharia de software né e teve a
questão lá na dos revisores mas enfim eu
vou falar a pergunta é mais geral você
foi editor chefe do J serd não sei se
pronuncia também assim J serde mas é o
Journal of soft Engineering research and
development que é uma revista acadêmica
brasileira né mas com publicações
inglêses estão aberta a pesquisadores do
mundo todo foi de 2017 a 2020 e editor
associado do jbcs que é o Journal of the
Brasilian computer society que não é só
de engenheiria de software Né desde 2023
então como é que é esse trabalho Quais
são as principais dificuldades e eu acho
até antes de de de responder eu vou
dizer assim que a gente sabe que a gente
tem um público que é pessoal mestrado
doutorado né mestrandos doutorandos
professores esses obviamente eles vão
ler os artigos mas é o pessoal que é
desenvolvedor que tá no no mercado mesmo
né eu eu sempre sugiro car dá uma olhada
assim nesses journals em outros journals
em anális conferência À vezes você vai
encontrar um artigo que é relevante pro
paraa sua prática Mas enfim eh voltando
qual como é que é esse trabalho de ser
editor desses journals e quais são as
principais
dificuldades então eu acho que foram
desafios distintos eh eh ão tá sendo
ainda do jbcs diferente do J serd O J
serd ele ele era da Springer ele era
editado pela
Springer Eu fui o o coordenador da ses
em
201 E ali a gente já lidava com algumas
questões junto com a Springer
eh porque a Springer tinha uma
expectativa de volume de publicação que
a gente não tava tendo Então tinha
algumas questões ali né a gente é
bastante seletivo Você conhece a
comunidade de engenharia de software
brasileira né
Eh e isso tava gerando alguma
dificuldade tinha uma parte financeira
grande também a gente fez um contrato
Inicial com aporte grande paraa sés o
Euro subiu isso tudo trouxe muita
dificuldade Então teve uma parte
administrativa lá na coordenação da ses
depois eu acabei me tornando eh editor
do do J serd junto com Alessandro Garcia
é sempre uma dupla né
Eh
o J serd ele tem um fluxo contínuo de
publicação que vem dos melhores artigos
das conferências brasileiras então o
Bash por exemplo os melhores artigos vão
claro que passam por por crio da do
Journal né tem que ter contribuição
aqueles 30% famosos de contribuição
extra e tal mas tem esse fluxo que
acontece naturalmente e tem também o
fluxo balcão uma pessoa qualquer pode
submeter um artigo para J isso vai
entrar em fluxo de
de de avaliação mas eu acho assim lá no
jerd teve essa questão da do do dia a
dia de alocação de artigo mas eu acho
que a maior a atuação foi na migração da
Springer para sol a sol é Biblioteca
digital da SBC e na época a gente tava
tendo que sair da Springer o Viterbo
ainda é né o diretor de publicações da
SBC Ele é meu colega de de departamento
né a gente conversou cara olha a gente
tá com esse problema e eu acho que a Sol
de certa forma nasceu por ali né porque
a gente fou conversando com o Vit falou
Olha eu vou subir o ajs na SBC e vocês
migram para lá e a gente cria template
Então foi uma coisa muito de
construção que traz alguns desafios Mas
foi muito importante o apoio da SBC
naquele momento que a gente tava saindo
da springa então eh a gente mexeu também
em comitê editorial teve um conjunto de
trabalhos ali talvez mais de
organização já no no Journal da da SBC o
jbcs é um Journal mais antigo mais
estruturado ele também migrou né Ele
também era Springer migrou para sol mas
ele já tinha aí foi depois da do J ser
Ele já pegou uma coisa mais pavimentada
né e recentemente o editor chefe dele
junto com Viterbo eles discutiram e
começaram a tentar fortalecer as linhas
Porque até então você tinha um monte de
avali ador solto né então ele tentou
criar grupos ali organizados por linha
ele pediu para eu liderar o grupo de es
dentro do do
jbcs a gente fez alguma reestruturação
ali no grupo e hoje estamos eu a Elisa A
Taiana o Eduardo Almeida e o Márcio
Ribeiro então esses são os editores da
com olhar de engenharia de software
dentro do jbcs na prática se alguém
submete um artigo e marca como
engenharia de software ele chega para
mim a gente tem um fluxo externo onde eu
discuto com os outros quatro para ver
quem é que vai pegar o artigo e a eu
direciono para quem vai pegar ou eu
mesmo ou um dos outros quatro e esse e a
pessoa que pegar vai buscar por
avaliadores vai alocar e vai fazer todo
o acompanhamento do
artigo e a gente percebe uma coisa que
todo mundo na comunidade fala
dificuldade de você conseguir
avaliadores né hoje em dia pela
sobrecarga né todos nós estamos
recebendo eh pedidos de avaliação o
tempo todo e as pessoas estão negando
muito né então isso motivou isso que
você eh comentou da da mensagem lá no
grupo dos pesquisadores a gente discutiu
entre nós falou Poxa mas será que não tá
acontecendo uma sobrecarga sobre quem já
está bem inserido no sistema e tem
várias outras pessoas que estão
dispostas a avaliar artigo que são
competentes são talvez mais novas mas
são competentes e elas estão a gente não
tá enxergando elas né e elas estavam a
fim de avaliar aí a gente achou Pode ser
que isso esteja acontecendo vamos passar
esse formulário para sentir para ser um
termômetro né e a gente teve mais de 60
pessoas que se voluntariaram quer dizer
é um sinal muito claro que tava faltando
é comunicação a nossa a nossa comunidade
cresceu demais né Cada
Doutor que segue na carreira que entra
num programa que tem doutorado ele forma
uma dezena ou mais de outros doutores né
então isso faz a comunidade crescer
muito tinha muita gente que tava de
certa forma invisível a nós mas que tava
disposta a fazer avaliações e de áreas
diferentes Então eu acho que aquele
encaminhamento foi legal nesse sentido
né aqui a gente não tem uma atuação mais
Ampla né porque aqui eu sou editor
associado e não editor chefe enquanto né
J Sérgio era editor chefe então
conseguia junto com Alessandro eh fazer
mudanças mais estruturais mas a a gente
acha que com essa questão de enxergar
esse avaliadores vai ter um aspecto
muito interessante que é primeiro a
gente conseguir acelerar o a publicação
dos dos artigos né porque se eu tenho
pessoas que estão afim que estão
dispostas estão disponíveis se eu aloco
para essas pessoas as pessoas vão
entregar revius com qualidade e mais
rápido né então acelerando motiva as
pessoas a submeterem mais Então a gente
acha que talvez a gente consiga eh gerar
uma contribuição nesse aspecto aí e
incluir mais a comunidade que eu acho
que é papel de todos nós né a gente a
gente tem que se preocupar bastante em
incluir quem tá chegando aí na nossa
comunidade agora a gente tá chegando
próximo ao fim do episódio eu vou fazer
a pergunta que define o podcast para
você Leonardo Qual é a próxima fronteira
da engenharia de software pode ser algo
que você acha que vai acontecer ou acha
ou algo que você gostaria que
acontecesse em nossa
área essa pergunta é difícil né eh mas
eu acho que eu vou chover num mhada Eu
vou falar o que é meio Óbvio eu tenho
usado CoPilot no meu na minha ide eu uso
vs code e tal CoPilot ativado e eu fico
muito impressionado com as recomendações
que ele me dá às vezes ele me dá algumas
recomendações que eu ignoro mas muitas
das vezes ele me dá recomendações muito
pertinentes eh não eram coisas que eu
não saberia fazer eu saberia só que eu
ia gastar o alguns minutos a mais
escrevendo código que eu não preciso
escrever né o mantra que eu tento trazer
para os meus alunos é que é muito mais
rápido verificar do que criar né então
se ele me me sugere 10 linhas de código
e eu tenho uma boa formação Eu leio
aqueles códigos vejo se aquele código é
exatamente o que eu
gostaria e aceito aquele código isso é
muito mais rápido do que se eu tivesse
que escrever aquelas 10 linhas de código
então Eh eu tendo a ter um olhar sobre
esses large lenguage models E essas
essas chat GPT e Compania que tão
surgindo aí como uma assistência né da
mesma forma que a gente usa um carro
para chegar mais rápido no destino
eh Possivelmente esses caras vão fazer
com que a gente seja mais produtivo
porque Claro se você não tem formação
Você vai aceitar muito lixo você vai
produzir coisas de baixa qualidade mas
se você tem uma boa formação ele vai te
acelerar em algo que você já Faria de
qualquer forma né
então eu eu por uso né no meu dia a dia
eu tenho notado que o CoPilot Tá
entregando coisas interessantes na minha
área já começaram recentemente coisa de
1 do anos atrás começaram a sair
ferramentas de merge baseada em large
language models né então o pessoal tá
explorando essa questão para resolver
conflito Eu tenho um merge que eu quero
fazer como é que uma uma ia faria se
merge para mim e eles estão conseguindo
resultados interessantes então acho que
tem uma eu sei que eu tô chovendo
molhado que essa é a bola da vez mas eu
tenho notado de fato inclusive na minha
área que é controle de versão algumas
pessoas aplicando isso eu tenho alunos
também né o Paulo Elias tá trabalhando
com isso né tem o Heleno que tem
colaborado com Paulo Elias também mas o
Heleno já segue mais paraa pesquisa
operacional para fazer busca para merge
mas o Paulo Elias tá mais focado nessa
questão de a para merge e eu tenho
notado que vári outros pesquisadores
estão investindo nisso E assim a eu não
sei se é o que eu espero não não sei se
é o que eu acho que vai acontecer mas eu
tô eh
curioso para tentar ver o que que vai
dar essa linha de que tá andando muito
agora e eu tenho notado recentemente
algumas notícias interessantes sobre
computação quântica parece que a
computação quântica também tá
conseguindo dar Passos interessantes
então eu tenho muita idade para ver como
que essa ia essas novidades da ia junto
com as novidades da Computação quântica
vão afetar a engenharia de software eu
não sei não tenho resposta mas eu acho
que esses dois caras misturados ao mesmo
tempo eles vão nos esforçar a repensar
um bocado de coisa da de como a gente
faz software Hoje em dia as ferramentas
que a gente tem então acho que tem muito
espaço aí para paraa
evolução verdade então nós agradecemos
aqui em nome da da equipe do fronteiras
dos nossos e nossas ouvintes a sua
participação aqui no podcast fronteiras
de engenheiria de software eu passo a
palavra para você para você se despedir
dos nossos e nossas ouvintes não eu só
tenho a agradecer pelo convite que vocês
me fizeram é sempre uma oportunidade
legal poder levar um pouco da pesquisa
pro público geral né eu sei que muitos
alunos vão estar assistindo mas eu
imagino p pessoas que eh de repente tem
interesse no tema mas não são tão
especializados também vão estar
assistindo né e eu tô à disposição
agradeço muito a vocês pela oportunidade
Se alguém quiser trocar ideia é só me
mandar um e-mail que eu eh tô aí à
disposição pra gente evoluir ao redor
desse
tema bem assim chegamos ao fim deste
Episódio Agradecemos por você ter estado
conosco no fronteiros da engenharia de
softw l e Esperamos que nossos e nossas
ouvintes gostem desse Episódio até o
próximo Muito obrigado