BAM!

O BAM! é uma reimplementação do BIG-ASS MESSAGE em Vue. Enquanto eu gosto do site original, ele era em Flash e foi migrado para Flutter. Alguns estilos foram perdidos no processo, em especial o “hypno”, então tentei reimplementá-lo.

Também melhorei um problema do site original: a forma que os links são compartilhados no site original depende que o servidor guarde as mensagens, e isso aumenta os gastos. Resolvi isso colocando as mensagens na URL, evitando a necessidade de um banco de dados no servidor.

E fiz o site não filtrar acentos. Provavelmente isso ocorre no site original porque o criador queria usar a fonte que ele fez e que não suporta acentos, porém, quando eu uso o site, eu quero usar acentos, então não coloquei esse filtro. Na verdade as fontes estão sendo a padrão do Tailwind, não me preocupei tanto com esse detalhe.

Quero adicionar mais estilos quando tiver mais tempo. Foi um site legal de implementar, ainda que seja bem simples. Eu já conversei com o desenvolvedor do BIG-ASS MESSAGE uma vez já faz mais de uma década e, inclusive, ele mandou um dos produtos ele para mim (aqueles adesivos que ele vende na loja dele). É um cara legal!

Clock

O Clock é apenas um relógio simples. O nome é simples tanto quanto o aplicativo. É só um relógio.

Fiz isso porque o aplicativo de relógio que eu usava teve uma atualização que forçou propagandas no aplicativo e, mesmo se você bloquear as propagandas, fica uma barra branca debaixo no aplicativo.

Ainda que o desenvolvedor tenha pensado em alguma forma de ganhar dinheiro com o aplicativo, para mim foi uma opção muito idiota, pois tornou o aplicativo dele completamente inútil a menos que alguém pague pelo aplicativo: a maior parte das pessoas usavam ele como um relógio noturno, com a nova barra branca ele não serve mais para isso.

Como o aplicativo dele é extremamente fácil de implementar, eu fiz em poucas horas uma versão nova, com mais funções, e resolvendo alguns problemas que eu tinha com o aplicativo original, como o medo da tela estragar por ficar uma imagem parada por muito tempo.

Ainda pretendo melhorar esse aplicativo melhorando a interface para eventos recorrentes de modo que funcione com mais línguas além de inglês, já que a biblioteca de agendamento que usei só funciona em inglês. Eu já fiz um fork dessa biblioteca, porém ela é tão velha que vai demorar um temo até arrumar tudo nela.

É um aplicativo web, o que é suficiente para um aplicativo tão simples assim, mas quero também fazer uma versão para Android, o que evitaria alguns problemas que estou tendo por conta de limitações das APIs Web, como a WakeLock, necessária para manter a tela ligada. Além disso o aplicativo iria aparecer na lista de aplicativos, o que no caso do meu celular, só aparece na tela inicial mas não na lista de aplicativos.

Conheço pessoalmente pessoas que usavam esse aplicativo, foram negativamente afetadas por causa das propagandas, e estarei recomendando o meu para essas pessoas. Já comentei para o desenvolvedor que ele poderia ter escolhido outras formas de monetizar o conteúdo dele, porém que, por causa do que ele fez, agora ele tem eu de concorrência.

O post Pequenas Ferramentas apareceu primeiro em o canto do qgustavor.

• Uma bolsa nova.
• Uma caneta nova.
• Uma caneca nova.
• Um bloco de anotações.
• Uma camisa do evento.
• Experiência.

Claro, a experiência foi a maior coisa que ganhei. Minha equipe ficou em penúltimo lugar, logo não consegui nenhum prêmio pela colocação, mas espero ter aprendido com os erros.

Em primeiro lugar: notei que as equipes que ganharam foram equipes que focaram menos em soluções baseadas em software e mais em soluções práticas, fáceis de implementar e baratas.

Em contraste, a minha solução envolvia muito software e colocar inteligência artificial na mistura não ajudou nada. Quem quiser ver o protótipo que desenvolvemos nesses três dias de Climathon, só acessar esse link: https://climathon.pockethost.io/

Em segundo lugar: notei que é muito mais importante você se focar na apresentação e em gastar tempo tomando muito cuidado com o tempo que vai gastar nela.

Em contraste, a minha equipe estourou o tempo da apresentação, gastou muito tempo apresentando o problema e menos de 30 segundos apresentando a nossa solução para ele, nas perguntas não conseguimos deixar que todos da banca pudessem responder, não estávamos preparados para responder as perguntas, e eu, em especial, quando falei acabei me repetindo várias e várias vezes, que é um problema que vou melhorar.

Em terceiro lugar: é importante conhecer bem a sua equipe e saber os pontos fortes e fracos de cada um. Houveram vários erros relativos a isso e a capacidade dos membros da equipe foi bem mal utilizada. Espero não cometer erros assim em uma próxima oportunidade.

Mas, no fim das contas, a experiência que ganhei foi muito boa.

O post Climathon apareceu primeiro em o canto do qgustavor.

Estava querendo comentar sobre como estava vendo Nekopara e achei estranho o primeiro capítulo do vídeo se chamar “Capítulo 7” e seguir numerado, mas na instância onde eu estava parecia não ser um lugar bom para comentar sobre isso, então resolvi ir para uma instância mais focada em anime. É uma instância focada em inglês, mas para mim isso não tem problema.

Quanto aos capítulos estou até pensando em arrumar uma forma de detectar quando os nomes dos capítulos estão com problema e renomeá-los com nomes mais apropriados como “Introdução / Abertura / Parte A / Parte B / Encerramento / Prévia”. O único problema é detectar que parte é qual: abertura e encerramentos geralmente são 90 segundos e dá para fazer análise de áudio para detectar as músicas, porém diferenciar uma prévia de uma cena pós-créditos não é tão simples, mesmo que usasse as legendas para isso ainda assim não é tão fácil.

Quanto ao Mastodon, estou postando isso mais para forçar uma atualização do blog e retomar o status do link do meu blog como verificado. Como a instância é focada em inglês fico pensando se vale a pena escrever postagens em inglês, só não sei como fazer isso usando o WordPress. Deve ter um plugin para blogs de várias línguas – melhor, deve ter uma dúzia de plugins – o problema é achar um que presta.

Bem, é isso por hoje, até.

O post Mastodon apareceu primeiro em o canto do qgustavor.

Por quê?

A menos que você esteja lutando contra o sistema, como alguns tradutores da Crunchyroll estão fazendo, é importante entender as limitações da forma que você trabalha. Se você distribui vídeos usando arquivos MKV, por exemplo, é recomendado que você evite usar fontes pesadas (está no fim desta página): não faz sentido você aumentar o tamanho do vídeo em 10MB só porque precisa de mostrar um kanji em uma nota de tradução, certo? Por outro lado, limitações como essa limitam a capacidade dos tradutores, o que não é bom.

Como?

Haveriam soluções melhores? Proponho uma: reduzir o tamanho das fontes eliminando os caracteres que não foram usados na legenda. Não é algo difícil de ser executado pois há várias ferramentas criadas para esse propósito, basta procurar por “font subsetting”. Para aplicar esse conceito com legendas, fiz um script que recebe uma legenda e uma pasta com fontes e otimiza elas removendo os caracteres não usados. Só usar o ass-parser e o fontkit, simples.

Mas não me contentei em apenas reduzir as fontes, resolvi unir todas as fontes em um arquivo só, assim a quantidade de metadados e outras informações redundantes entre as fontes é reduzida. Isso também tem o benefício de evitar que alguém extraia as fontes do MKV (usando o mkv-extract talvez) e instale no sistema.

Pontos positivos e negativos

Há dois grandes pontos positivos para esse conceito:

1. Ele permite que tradutores possam usar quantas fontes acharem que for necessário sem se preocupar com o tamanho das fontes. Querem colocar um kanji em uma nota de tradução? Não tem problema. Querem usar dezenas de fontes para fazer algum efeito? Ótimo!
2. Ele permite reduzir o tamanho dos vídeos sem reduzir a qualidade do vídeo e de forma mais eficaz e inteligente do que outras técnicas que certos grupos usam, como compactar o vídeo usando rar ou 7z e dividir aberturas e encerramentos em arquivos separados (o que reduz a compatibilidade, o que não é inteligente).

Há um ponto que pode ser positivo ou negativo, dependendo das suas prioridades: a legenda fica ilegível se unir as fontes em uma só e elas não forem carregadas, isso é bom pois garante que ninguém vai ver uma legenda com fontes padrões erradas, mas isso pode ser ruim para os que preferem uma legenda ruim do que nenhuma.

Ainda há três pontos negativos: complexidade adicional, dificuldade para editar a legenda distribuída e problemas de licenciamento já que as licenças de certas fontes não permitem que elas sejam editadas dessa maneira. Esse último problema não afeta fansubs pois quase todas¹ usam fontes sem ter permissão de redistribuição. Fansubbers que me falaram “a gente só usa fontes gratuitas”, por favor, leiam isso e aprendam que Arial não é uma fonte gratuita.

Na prática

Testei esse conceito com um episódio de Kobayashi-san. Como disse semana passada eu tinha trabalhado nesse anime para ver a versão dublada, logo eu já tinha o karaokê que eu traduzi para português e o vídeo do BD, bastou adicionar a tradução das falas as quais peguei da fansub Aenianos. Como apenas traduzi o karaokê da DameDesuYo!, que é um que usa várias fontes, o arquivo final ficou com mais de 35 fontes, o que é perfeito para o teste.

Postei o arquivo final em uma hospedagem e perguntei para o pessoal da UO se eles conseguiam abrir o arquivo, se estava funcionando corretamente, qual era o player que usaram e o que acharam que eu tinha alterado no vídeo. Os resultados:

Como podem ver, a maioria conseguiu abrir sem problemas, mas 28% das vezes o player não carregou a fonte, deixando a legenda ilegível. Praticamente todos os players populares aparecem entre os que apresentaram problemas, como MPV, MPC-HC e VLC. Por outro lado esses players também apareceram entre os que o vídeo funcionou, então não é que o problema esteja nos players, mas na forma que eles foram configurados.

Esse dado é interessante para fansubs, pois provavelmente essas pessoas estão vendo animes com os players mal-configurados de forma que as fontes não são carregadas. Isso não é só ruim porque elas estão vendo uma tradução pior do que a que foi distribuída, mas também representa que várias pessoas nem notam o problema e acham que vários grupos usam Arial por escolha própria e não porque elas que configuraram o player delas de forma errada.

Uma ideia que ainda não coloquei em prática, mas que acho que seria boa, seria deixar no início da legenda um aviso grande de que as fontes não foram carregadas usando uma fonte que aparece nada no lugar dos caracteres (algo como essa fonte, mas com espaços no lugar de retângulos), assim se as fontes não forem carregadas o aviso aparece, se elas forem carregadas.

Essa ideia não aumenta muito o tamanho do arquivo já que a fonte adicional só precisa ter os caracteres necessários para ocultar o aviso e pode ser aplicada em qualquer legenda existente caso algum grupo queira avisar quem está vendo o vídeo de que o player dele não está configurado corretamente e, por isso, ele não estará vendo o vídeo da forma que ele foi criado.

Alternativas

Embora o teste tenha sido com as legendas reduzidas e unidas, as fontes podem ser apenas reduzidas. Dessa forma as legendas podem funcionar mesmo com as fontes erradas, caso alguém prefira isso. A redução final não vai ser tão eficiente, mas ainda é muito boa. O problema de pessoas extraindo fontes faltando caracteres e instalando no sistema pode ser mitigado renomeando as fontes.

Alguns lendo essa postagem serão rápidos para pensar que hardsub é uma solução, mas quem leu a postagem da semana passada sabe que editar um formato comprimido causa perda de qualidade, e todos os formatos usados para distribuir vídeos são comprimidos, logo usar hardsub não é uma opção para quem se preocupa com qualidade. Repito: quem usa hardsub não se preocupa com qualidade. Ponto final.

Talvez a alternativa mais inteligente e simples é usar streaming: como a distribuição de fontes via streaming ocorre separadamente do vídeo, o tamanho delas não acumula e o problema de um arquivo de 500MB virar um de 600MB simplesmente não existe. Além disso, a redução na performance é mínima pois elas podem ficar em cache.

Conclusão!

O resultado do experimento foi bem interessante. Se algum grupo não estiver preocupado se o pessoal estiver usando os players de forma errada poderia muito bem usar um script como esse para reduzir o tamanho dos vídeos.

Posso disponibilizar ele se alguém quiser. Não sei se os comentários do blog ainda estão funcionando, acho que a função que lida com ele estava marcada para parar de funcionar por causa de uma atualização no servidor e a única forma que resolver esse problema seria pagando, o que eu não vou fazer.

Se quiserem podem me enviar uma mensagem no Discord, no Twitter, os dois são igualmente bugados e não recebo notificações dos dois. Tenho conta no Signal e no Keybase, são criptografados, mas acho que ninguém usa nenhum dos dois, né? É complicado.

Eu tinha dito que daria um prêmio para quem adivinhasse qual era o objetivo do experimento e ninguém acertou, mas alguém tinha que ganhar um prêmio e esse foi o henmarcelino, que chutou que era a escolha de fontes. Não era bem a escolha das fontes, era uma forma de reduzir o tamanho delas. Os outros chutes disseram que a qualidade do vídeo era melhor, o que entendo pois a qualidade do vídeo da Aenianos é inferior pois usaram hardsub na tradução das músicas. Aparentemente o pessoal inconscientemente nota que a qualidade de quem usa hardsub é inferior.

Voltando ao assunto das fontes, acho estranho que o pessoal da Crunchyroll se recuse a usar as fontes que eles licenciaram. São 60 fontes (incluindo variações) mas parece que só querem ficar usando 15 dessas variações, desperdiçam 75% do que licenciaram! Há vários animes onde aparece texto monoespaçado e, ao invés de usarem Courier New, Andale Mono ou DejaVu LGC Sans Mono, eles usam Arial, que não é apropriada para essa situação. Embora seja um problema que eles só tenham licenciado uma única fonte cursiva, Comic Sans MS, por que desperdiçam tantas fontes por nada? É estranho, mas tenho boas notícias: não licenciaram Papyrus. Ainda bem!

Acho que há dois problemas lá, em primeiro lugar como muita gente que trabalha lá era de fansubs eles ainda têm a mentalidade de fansubbers e acham que adicionar muitas fontes é algo ruim, em segundo lugar há um grupo rebelde que não lê os memorandos e usa qualquer fonte que dá na telha. Aliás, para mim esse grupo rebelde não é um problema, é uma benção já que no último mês eu arrumei o meu player para carregar essas fontes.

Espero que o futuro seja melhor, tanto para fãs, quanto para profissionais e para quem está no meio dos dois grupos. Ainda que demore anos para o projeto sair e mais ainda para os players implementarem, acho que propostas como essa deveriam ser revistas e melhoradas por pessoas dos dois lados. Muito do que já foi proposto é ótimo, mas sempre há espaço para melhorias, como definir o estilo ao invés de definir o tipo do evento por linha e mover o tipo de evento para ser uma propriedade do estilo, o que seria mais conciso. Mas para que essas melhorias ocorram é necessário que haja participação de várias pessoas envolvidas com a produção de legendas.

Quinta vou publicar uma postagem sobre um anime muito bom que me recomendaram quando eu estava na faculdade e que é muito educativo. Até mais!

Atualizações

Descobri duas coisas após a publicação desta postagem:

1. A Crunchyroll está usando mais fontes, só não é muito comum. Em um episódio que vi faz algumas horas eles usaram oito fontes diferentes (excluindo variantes), inclusive Courier New. Espero que as equipes estejam sendo melhor informadas de quais fontes elas podem ou não usar.
2. Há algumas fansubs que usam fontes otimizadas, como a Commie, mas até agora não encontrei ninguém que tenha feito um script ou programa que automaticamente pega as fontes de uma legenda e otimiza as fontes conforme os caracteres usados. Além disso, mesmo no exemplo que encontrei da Commie, em Nagatoro-san, só otimizaram uma fonte de 4 MB para 46 KB, o que indica que devem ter feito isso manualmente. A automatização desse processo pode ser o que faltava para que isso se popularize.

¹ Se encontrar uma que só usa fontes com licenças open-source, deve ser minha.

O post Otimizando fontes apareceu primeiro em o canto do qgustavor.

Geralmente cantamos três hinos. Como já fazemos isso por vários anos devíamos cantar bem só que se fossemos nos classificar de acordo com a escala Charles Cornell nós estaríamos entre o nível 1, quando a gente tenta cantar junto, e o nível “0”, quando só uma pessoa da nossa família canta porque o resto desistiu de cantar.

Um dos motivos para não conseguirmos cantar juntos é que não cantamos sempre os mesmos hinos da harpa e, claro, não sabemos como cantar todos eles. Tentamos arrumar um ritmo mas quase nunca dá certo.

Essa é a parte do culto que mais me dá raiva do site. Várias vezes o tamanho da fonte fica errado no iOS: algumas vezes fica maior do que devia cortando parte da estrofe, em outras vezes fica pequeno demais para ler. Também os hinos tem vários erros de digitação e, ainda que o site tenha uma opção para editar os hinos e corrigir ninguém da família tem a menor vontade de usar ela!

Depois lemos um capítulo… ou versículo… da Bíblia, geralmente acompanhados por comentários genéricos e simples que nem sempre estão de acordo com o conteúdo. É complicado: se alguém tentar argumentar alguma coisa aí entramos em uma discussão e vou ter menos tempo para assistir meu anime depois do culto terminar.

Geralmente quando termina eu fico pensando como eu poderia melhorar o site para resolver os problemas que temos com ele. Por exemplo lemos um versículo aleatório pois esquecemos onde paramos na leitura da Bíblia. Era para estar registrado no histórico, mas como ele é armazenado no dispositivo um dia perdemos essa informação.

Eu poderia sincronizar isso com o Firebase, IPFS, GUN ou outro sistema desse tipo… ou melhor, não o GUN: qualquer projeto que tenha “machine-learning” e “blockchain” nas tags não parece ser algo confiável, parece algo tirado de um gerador de buzzwords. E, claro, já olhei o código: se a demonstração dele usa jQuery de forma insegura imagina como é a parte de criptografia dele? Deve ser terrível.

De qualquer forma eu nunca arrumo o adorai: a versão anterior do site usava jQuery, a atual usa React/Inferno (o que é irônico já que é um site que leitura da Bíblia) e já tentei usar Mithril e Vue mas nunca deu certo. Já estou cansado de tantas tentativas, então é melhor aguentar a versão que ainda funciona. No dia que ela quebrar eu resolvo esse problema.

O post Culto doméstico apareceu primeiro em o canto do qgustavor.

É, infelizmente, uma das piores versões de demonstração que já joguei pois não é possível concluir nenhuma meta nela. Eu queria que fosse que nem as versões de demonstração dos jogos da Ubisoft onde o jogo deixa claro que é uma demonstração, é possível terminar pelo menos uma fase do jogo e no final aparece um trailer para o jogo completo.

Eu conheci esse jogo quando criança em um daqueles CDs de pacotes de jogos. Acho que quem é novo acharia isso estranho, mas em uma época onde internet era extremamente cara esses CDs eram a principal fonte de jogos para mim. Sendo assim, como no CD não aparecia nada sobre esse jogo ser uma demonstração, eu fiquei muito tempo tentando ganhar ele e nunca conseguia, o que era muito ruim.

Na época que escrevi a postagem anterior eu tinha pensado "depois de tanto tempo, agora que já sei tanta coisa, eu devo conseguir achar uma forma de resolver esse problema" só para descobrir que não havia nenhuma solução.

Mas consegui pelo menos resolver um problema: descobri porque eu não estava conseguindo abrir as imagens do jogo.

Em primeiro lugar a forma que as imagens estavam armazenadas não era um formato tão simples como eu imaginei, aparentemente quem desenvolveu usou um XOR para evitar que alguém simplesmente convertesse os formatos e abrisse a imagem. Em segundo lugar não era RGB24 mas BGR24.

Essas são as duas imagens que são impossíveis de ser acessadas no jogo:

Imagino que elas existem porque era para o alçapão que fica na sala onde está o terminal do jogo ser aberto, porém não há nenhuma imagem dessa sala sem a grade que dá acesso para essa escada. Como pode ser visto no site do jogo esse projeto morreu, então só restaram essas duas imagens.

Esse jogo, de certa forma, foi uma inspiração para um jogo que eu desenvolvi, então eu sei que criar um jogo desses não é fácil. No meu caso o meu jogo não ficou tão bom, teve algumas salas que ficaram sem ser usadas no jogo final e coloquei poucas ilustrações pois se eu fosse ilustrar tudo o jogo nunca iria ficar pronto. É complicado fazer jogos.

O post Angra 2 apareceu primeiro em o canto do qgustavor.

O último experimento que eu fiz foi pegar o TweetNaCl.js e fazer uma versão dele que pode ser simplificada automaticamente dependendo das funções usadas: https://github.com/qgustavor/tweetnacl-js

Tive essa ideia pois eu estava desenvolvendo um projeto usando o Vite e notei que no código havia algumas funções do TweetNaCl que eu não estava usando, então resolvi reescrever parte do código que lida como as funções são exportadas e o resultado foi o código acima.

O interessante é que isso não só permite que as funções não usadas (pelo menos a maior parte delas) sejam eliminadas mas também permite que as funções sejam renomeadas, o que eu acho interessante já que.

Em termos de segurança não sei se isso é mais seguro ou não. Deve ser, mas não posso confirmar nada. É um experimento interessante, de qualquer forma.

O post Um experimento com criptografia apareceu primeiro em o canto do qgustavor.

Por outro lado uma coisa que nunca tinha parado para pensar é no uso automático de aspas, como na imagem acima onde as aspas fazem parte do modelo do site. O normal, nesse caso, seria que as aspas no texto citado fossem invertidas de duplas para simples e de simples para duplas, se estas existissem.

Nunca vi alguém comentar sobre esse assunto, talvez porque essa seja uma situação rara: talvez ficasse mais bonito se o nome do episódio ficasse escrito só em negrito, sem aspas. Por outro lado, considerando que alguém quer usar aspas no modelo de um site ou de um aplicativo, o que poderia ser feito? Fiz esse gist com uma possível implementação.

Espero que esse código sirva para alguém no futuro.

O post Aspas apareceu primeiro em o canto do qgustavor.

A maioria das respostas irá sugerir para usar o ffmpeg. Na maioria dos casos ele é realmente a melhor opção por ser simples de usar: "ffmpeg -ss tempo -i fonte.mp4 -vframes 1 destino.png", repetir isso a quantidade de vezes que for necessária e o problema está resolvido. Por outro lado esse método tem certos problemas:

• Você precisa de iniciar uma instância do ffmpeg para cada imagem, o que torna o processo muito lento, mesmo se você usar várias instâncias em paralelo;
• As legendas não aparecem nas capturas por padrão; você pode usar um filtro para isso, mas nem sempre é fácil já que é complicado configurar as fontes para funcionar com esse filtro;
• O ffmpeg não suporta certos MKVs (que são raros… exceto se você estiver trabalhando com animes);
• As capturas ficarão erradas para vídeos em que o aspect ratio mostrado (DAR) é diferente do codificado (SAR);
• Alguns vídeos podem ter problemas de compatibilidade (use “-x264_build 150” para esses casos).

Um método alternativo que eu achei bem mais interessante é usar o MPV para isso. Ele é mais complexo e consiste dos seguintes passos:

1. Abra o vídeo no MPV usando “–vo=null” para não abrir uma janela, “–audio=no” para não processar o áudio, “–pause” para pausar o vídeo (bem na lata, né?), e o argumento mais importante, “–input-ipc-server=/tmp/node-mpv.sock”;
2. Conecte ao MPV usando o IPC acima e aguarde pelo evento “playback-restart”;
3. Para cada imagem que você precisar tirar use o comando “seek [tempo] absolute+exact”, espere pelo evento “playback-restart” e então use o comando “screenshot-to-file [arquivo]”;
4. Por padrão as legendas aparecem nas capturas (o que é ótimo!). Se quiser desativar isso só adicionar “video” depois do nome do arquivo nesse último comando.

Assim como com o ffmpeg é possível usar várias instâncias em paralelo (geralmente uso uma para cada vídeo) e, apesar de toda a dificuldade envolvendo a comunicação via IPC, os resultados são surpreendentes: todos os problemas que listei acima são resolvidos e claro, é BEM mais rápido.

Só não me perguntem por que tenho tantas capturas no meu computador…

O post Capturas em massa apareceu primeiro em o canto do qgustavor.

Como no momento o Deno ainda está muito novo estou evitando ele para esse projeto e usando o Node, mas como boa parte desse clima de sair experimentando com esses módulos sem depender de Webpack, Parcel ou Rollup começou no Deno eu acabei levando uns sustos quando fui testar no Node.

Para começar eu não sabia que o import.meta.main era algo exclusivo do Deno. Achei que fosse algo "padrão", já que o Deno se valoriza tanto por isso. Acabei fazendo isso um desafio: escrever uma função que retorna se um módulo é o principal ou não:

export default function isMain (meta) {
  if (meta.main) return true
  if (typeof Deno !== 'undefined') return false
  if (typeof document !== 'undefined') {
    return Array.from(document.scripts).some(e => e.src === meta.url)
  }

  if (typeof process !== 'undefined') {
    const calledScript = process.argv[1]
    const normalize = e => e.split(/[/\]/).pop().toLowerCase().replace(/..*$/, '')
    return normalize(calledScript) === normalize(meta.url)
  }

  if (typeof WorkerGlobalScope !== 'undefined') {
    return self.location.href === meta.url
  }

  throw Error('could not find if module is main')
}

No Deno e em navegadores funciona bem mas no Node é uma gambiarra. Há um módulo no NPM que faz isso e, claro, deve fazer melhor. Espero que no futuro isso seja padronizado.

Um outro experimento que resolvi fazer foi pegar o MKV Extract e migrar ele de JavaScript para TypeScript, de CommonJS para ESM, e de Browserify para Parcel. Além disso agora ele usa GitHub Actions o que significa que não preciso ficar compilando no meu computador o site se alguém enviar um pull request corrigindo alguma coisa, é bem mais prático.

Quero terminar de arrumar esses scripts logo: as partes que dependem do MAL já estão dando problemas (mesmo com a API não oficial) e, como eu disse antes, em setembro a API que eu estava usando para gerar as estatísticas vai parar de funcionar. Na prática estou só organizando as coisas: ao invés de ter um monte de informação espalhada em uma planilha e um monte de arquivos JSON e TXT o meu plano é juntar tudo em um único ponto.

Assim que eu terminar vai ficar mais fácil gerar as estatísticas e ainda quero fazer um aplicativo para celular para poder votar nos animes sem precisar de internet. Claro, estamos na época onde todo mundo tem internet a qualquer momento, mas pelo menos nisso eu não sou todo mundo: minha internet é tão ruim que a conexão cai até dentro de casa!

Eu quero fazer um gráfico da nota de cada anime por episódio. É uma pena que só vou implementar isso depois de mais de cinco anos que comecei a coletar esses dados, mas antes tarde do que nunca. Enfim, isso é tudo por hoje, até semana que vem.

O post Experimentando com módulos apareceu primeiro em o canto do qgustavor.