Descrição no YouTube

Uma coisa que recomendo que todo mundo faça: backups. Faça backup de todos os seus trabalhos. Daqui 20, 30 anos, você vai se agradecer por ter feito isso.

Aproveitando a dica, quero abrir uma pequena janela pra um hobby que eu tinha nos anos 90: os sites de anime que eu fazia.

E ainda terminando com uma confusão que deu até boletim de ocorrência :-D

Links:

• Meu Passado Otaku – A revista de anime que publicou… um Boletim de Ocorrência (!!!) (https://maisdeoitomil.wordpress.com/2016/03/07/meu-passado-otaku-a-revista-de-anime-que-publicou-um-boletim-de-ocorrencia/)

AkitaOnRails:

• [Off-Topic] Meu Backup Pessoal (Drobo/Time Capsule) (http://www.akitaonrails.com/2009/09/19/off-topic-meu-backup-pessoal-drobo-time-capsule)
• [Off-Topic] Faça Backup do seu Ambiente (http://www.akitaonrails.com/2011/03/01/off-topic-faca-backup-do-seu-ambiente)

Script

Olá pessoal, Fabio Akita

Se vocês ainda não me seguem nas redes sociais procurem por AkitaOnRails no Facebook, Twitter e Instagram. Quem me segue no Instagram sabe que alguns dias atrás eu resolvi finalmente abrir minha cápsula do tempo. Os códigos que vocês viram nos episódios da série Sua Linguagem É especial? vieram daí.

Quando eu era criança eu não lembro se foi no Show de Beakman ou outro programa infantil desse tipo, onde eu vi o conceito de Cápsula do Tempo pela primeira vez. Não é só acumular velharias. É empacotar seu presente intencionalmente pra ser aberto bem no futuro.

Intuitivamente eu nunca tive vontade de fazer o mais óbvio: pegar uma caixa de sapato e colocar pertences meus da época como uma fita cassette ou brinquedo. Em vez disso eu queria de alguma forma preservar o que eu era. E eu me defino não pelo o que eu possuo, mas o que eu penso e produzo. Eu não sou apegado a nenhuma posse. Por sorte, tudo que eu produzo é digital.

Eu já tinha visto os disquetes de 8 polegadas e depois os de 5 1/4 polegadas ficarem obsoletos, eu estava vendo os disquetes de 3 1/2 ficarem obsoletos. Então eu fui gradativamente passando tudo de disquetes pra zip drives, de zip drives pra CD-ROMs (quando finalmente os gravadores ficaram acessíveis), de CD-ROMs pra DVD. E de DVD pra HDs. As coisas hoje em dia estão muito fáceis, antigamente eu tinha caixas e caixas de disquetes, CDs e DVDs, hoje cabe tudo num HDzão.

Em 2008 obviamente eu tinha noção que HDs tem vida útil e costumam falhar, são dispositivos mecânicos que não foram feitos pra durar pra sempre. Assistindo os primeiros video casts, programas tech que existiam desde antes do YouTube, que você via no iTunes, eu vi um programa da Kali Lewis sobre Drobos. Eu já sabia o que era uma configuração RAID de storage pra servidor mas eu achava complicado pra ter em casa. Mas o Drobo tinha a intenção de ser portátil e plug and play. Então eu resolvi pedir pra um amigo trazer pra mim.

E o Drobo realmente funcionou. Eu fiquei com esse Drobo por 10 anos. Nesses 10 anos eu troquei discos 2 vezes porque falharam, e isso justificou essa compra. Custou caro pra caramba, na época foi quase 800 dólares se somar com os HDs. Mas se considerar que foi 800 dólares que protegeram minha história por 10 anos, eu digo que foi extremamente barato. Eu troquei de Drobo ano passado. A porta USB 2 era muito lenta, troquei pelo mesmo modelo com USB 3, que ainda não chega a ser um Thunderbolt, mas já ajuda. Eu tirei todos os 4 HDs do antigo, coloquei no novo, e boom, plug and play, tudo funciona. Impressionante.

O objetivo não é fazer propaganda do Drobo, claro, mas eu não confiaria em nenhum HD externo que não seja redundante. Aliás, muito cuidado, existem muitas configurações de HD externo com 2 ou mais HDs em layout de RAID-0 com striping. É só a pior configuração imaginável porque se você tem 2 HDs de 500 GB em striping, você enxerga como se fosse um único HDzaão de 1 TB. Só que não tem proteção contra erro nem redundância, se um dos HDs falhar, você perde os dados DOS DOIS. Jamais use RAID-0. E RAID-1 é o pior custo benefício porque é basicamente um HD fazendo cópia do outro.

Temos outro problema hoje em dia. Tudo está no maldito cloud. O problema não é o cloud, o problema são serviços que dificultam você sincronizar uma cópia local. Você está tão acostumado que o Google vai cuidar dos seus e-mails, que o Dropbox ou Microsoft OneDrive ou Google GDrive vai cuidar dos seus arquivos, que o Slack vai cuidar dos seus chats, que a Apple vai cuidar das suas fotos e músicas, que você literalmente não pensa em fazer mais backup hoje em dia.

Eu prefiro partir do princípio que qualquer um deles pode ter uma falha amanhã, nem estou dizendo falir, uma falha mesmo, e podem perder meus dados. Eu não preciso guardar tudo, mas de meses em meses eu acho saudável exportar os arquivos do Twitter, eu gosto de abrir um Mozilla Thunderbird e conectar nos meus diversos e-mails pra sincronizar tudo local via IMAP, prefiro baixar tudo do Dropbox e manter um backup local no meu Drobo, e assim por diante.

Nos últimos anos eu confesso que tenho sido menos cuidadoso com meus backups por conta de todos esses serviços cloud, mas é bom não descuidar. 25 anos depois, eu me arrependo de não ter guardado os fontes dos meus primeiros programas em Basic. Existem coisas que quando você tiver conseguido guardar dinheiro vai ainda conseguir encontrar algum colecionador vendendo, um MSX, um TK-85, mas seu primeiro programa? Isso não tem mais como.

De qualquer forma, este mês eu finalmente resolvi abrir meus arquivos antigos. Meus e-mails de 1997 a 2006, quase 10 anos de e-mails foram preservados em arquivos PST do Outlook que, felizmente, são fáceis de abrir. De 2006 em diante está tudo no Gmail. Viu meu vídeo sobre Sua Linguagem É Especial que eu mostro os sites que eu trabalhava pra PSN como o do Corinthians e Cruzeiro? Eu tenho as imagens porque eu ainda tenho o Photoshop original que eu usei pra recortar as imagens pro site. Estavam como anexo nesses e-mails.

Essa é uma daquelas coisas que de vez em quando dá trabalho, você gasta dinheiro e tempo, mas o prêmio é que eu tenho uma oportunidade única: de viajar no tempo, pra qualquer lugar de hoje até mais de 20 anos no passado. Eu ainda ia esperar mais uma década antes de abrir, mas eu sinto que agora é a hora de fazer isso. Vai que amanhã eu morro e perco a oportunidade de deixar registrado pra posteridade?

Eu não guardei todos os instaladores de todos os programas que eu usava. Mas por sorte achei esse site WinWorld que tem instaladores de tudo que é programa dos anos 90. Achei até o instalador de Clipper, FoxPro e tudo mais que eu usava. E graças ao VMWare Workstation Pro que eu uso todo dia, ele também suporta Windows 95 em diante. Eu comecei antes do Windows 95, no MS DOS 3 e usei tudo que a Microsoft lançou do fim dos anos 80 até 2004 que foi quando migrei pra Apple e Mac até voltar pro Windows 10 anos depois em 2015. O Windows 98 foi um dos que eu mais usei nos anos 90 por isso instalei ele.

Como eu já falei bastante, por hoje quero mostrar um dos primeiros sites pessoais que eu fiz. É tão velho que se não for Internet Explorer 4 ou Netscape Navigator 4, o site nem renderiza direito. Essa é uma época anterior a eu aprender ASP ou PHP, quando eu fazia sites estáticos com HTML puro, estamos falando de 1997.

Em 1994 o Brasil foi pego de surpresa quando a Manchete resolveu lançar Cavaleiros do Zodíaco. De repente eu comecei a ver mais gente falando de anime. Até então gostar de anime era um troço bem solitário. Eu cresci assistindo anime gravado em fita Betamax e VHS que vinha do Japão no meio dos anos 80. Mas depois de 1994 todo mundo queria mais e mais anime. Shurato, Sailor Moon, Yuyu Hakusho, e tantos mais. Em 1995 surgiu uma das primeiras revistas especializadas em anime e cultura japonesa, a revista Herói. Daí na sequência saiu um pasquim de pior qualidade chamado Japan Fury que depois se tornou Animax em 1996.

Por coincidência eu fazia parte de um grupo de pessoas que se auto-intitulava Orcade e participava dessa revista, então eu mesmo escrevi um ou dois artigos, em particular sobre Evangelion, que eu me considerava especialista na época - típico de amador se achar especialista mesmo . Como eu tinha acabado de aprender HTML e quando virei monitor na sala de computação da USP eu ganhei acesso ao servidor Unix da Politécnica e como em toda faculdade da época, toda conta tinha uma pasta exposta no Apache pra internet, então decidi fazer um site pra revista. Essa foi a Animax Plug-In.

Essa é a primeira versão, que eu fiz usando o bom e velho Microsoft FrontPage 3.0. Eu sei, eu sei, nem precisa dizer, esse design é tenebroso até pros padrões da época, se bem que em 1997 não se tinha tanto padrão assim pras coisas, em outro vídeo vou mostrar os sites profissionais que fazia com designers de verdade da época. Mas por agora veja que a gente usava framesets e frames e muito table. Não tinha CSS ainda. E o destaque é o menu lateral que abre e fecha, quer dizer, abre e fecha no Netscape mas não no Internet Explorer. Pois é, diferença de Javascript entre navegadores é antiga, a web nasceu quebrada e a gente vem tentando consertar desde então. Mas é legal ver funcionando de novo, em navegador novo nada funciona. Nessa época Internet Explorer era superior ao Netscape já. Renderizava bem mais rápido, Javascript era mais rápido. Eu escrevia pra caramba, vocês podem ver que minha mania de fazer textão não vem de hoje.

Lendo meus textos fica claro que eu escrevia bem mal. Eu ainda não tinha adquirido a noção de editar meus textos. É como programador júnior que ainda tem dó de apagar o código que escreveu. Hoje em dia eu às vezes escrevo páginas e páginas e no meio do caminho eu vejo que está ruim e jogo tudo fora e começo do zero, ou vou refinando o texto, apago seções inteiras. Não existe escrever em apagar. O melhor fluxo é deixar tudo crú sair da sua cabeça, e quando terminar esse dump, daí sim reler e começar a ajustar e apagar e reorganizar.

De qualquer maneira, esse design está um pouco mais engolível. Eu ficava tentando fazer jeitos bizarros de navegação. Dessa vez em vez de um menu lateral eu tinha um menu no fim da página que ia abrindo sub menus pra cima. E eu tinha conceito de uma página que abre a próxima. Naquela época não era muito claro qual a melhor abstração pra organizar conteúdo. Vocês vão notar que nessa época era comum a gente querer simular o estilo de layout editoração de revista. E eu tinha de tudo nesse site, até uns textos tentando ensinar japonês, como se isso fosse fazer alguma diferença. E como ainda não existia Google também era comum os sites terem páginas linkando outros sites, como uma bibliografia ou recomendação.

Na sequência essa é a terceira ou quarta versão. Isso já era 1999, 3 anos fazendo isso. Esta é um pouquinho mais aceitável, pelo menos um pouco mais limpo. De novo note o estilo de layout inpirado em revistas. Eu gastava meu parco salário comprando revistas importadas de anime nessa época, eu queria fazer juz ao investimento. E, de novo, note o menu lateral em Javascript só que dessa vez com inspiração em ícones do Mac OS 8 que eu tinha acesso na agência onde fazia estágio. E continuando no mesmo estilo das outras versões eu colocava mais e mais seções de mangás novos explicando um a um em detalhes, olhando agora eu fico pensando se teria paciência de fazer a mesma coisa hoje em dia.

Eu cheguei até a iniciar um projeto onde eu escaneei vários volumes de um manga que eu gostava e ficava traduzindo balão a balão no photoshop, puta trampo, mas antigamente não existia mangareader e mesmo no mangareader, alguém faz esse tipo de trampo. Eu sei exatamente como dá trabalho

Essa atividade durou uns 3 anos. Durante esse tempo o site ficava hospedado na minha conta no UNIX da faculdade, mas na realidade eu não podia usar a conta da faculdade pra um site de revista comercial, mesmo que eu não ganhasse nada por isso. Eu ganhei zero reais, a revista não dava dinheiro, o site não dava dinheiro, a gente fazia tudo isso porque gostava. Vocês podem ver que isso de eu gastar todo meu tempo livre fazendo coisas trabalhosas só pela diversão vem de longa data.

Mas o que eu ganhei com isso foi outra coisa: com esse exercício todo, eu fiquei rápido pra layoutar sites no estilo da época. Podia me dar qualquer photoshop que eu recortava e montava muito rápido na agência. Sabia otimizar as imagens, otimizar o HTML - pelo menos pros padrões da época, e eu exercitei muito o Javascript da época. Isso seria muito útil nos anos seguintes.

Além disso eu treinei muito minha escrita. Como eu disse antes, lendo agora, é fácil ver que meus textos não eram bons, mas também dá pra ver que mesmo nesse curto período eu escrevi o suficiente pra encher as páginas de um pequeno livro. Eu escrevia em detalhes sobre as séries que eu gostava, indo de personagem em personagem, isso deu tipo MUITO trabalho. Mas novamente, esse trabalho também me ajudou muito, os meus e-mails no trabalho sempre foram completos e concisos, porque eu tinha treinado muito escrever em grande quantidade em pouco tempo.

Ou seja, quando eu comecei meu blog em 2006 eu já tinha escrito muito texto anos antes. E agora escrevendo scripts aqui pro canal, é tudo uma sequência. Eu não sou escritor profissional, mas eu vim aprendendo as técnicas e tentando refinar com o passar do tempo. Mesmo em 1999 comparado com 1997 eu já tinha melhorado.

E como última curiosidade, uma das coisas que atraía as pessoas pra Animax Plug-in e minhas matérias na revista é porque eu era um troll. Como eu disse, a revista Herói era uma droga em termos de conteúdo. Ela vendia porque na época não tinha nada na internet, e todo mundo queria qualquer coisa Cavaleiros do Zodíaco e outros animes. Então eu tinha vários artigos listando um a um todos os erros dos textos da Herói, e não era errinhos ortográficos - que tinha de monte aliás - eram erros conceituais, contava a história errada mesmo. E eu não era sutil, eu chamava pro pau mesmo, eu diz sr Fulano, você não manja porque esse ponto X tá errado, ah e esse ponto Y tá totalmente errado. Ah, e eu nos meus 20 sou que nem vocês nos seus 20, só que em vez de ficar tweetando, eu fazia matéria de revista. E eu sei porque todo mundo gosta de extravazar no twitter, é extremamente satisfatório enfiar o dedo na cara dos outros, cagar um monte de regra, pisar no calo dos outros e ainda ter gente aplaudindo você fazendo isso. Mais satisfatório ainda quando o outro lado reage e vira uma briga. Acho que faz parte da natureza humana.

Hoje eu não faço mais isso. Pelo menos não desse jeito e jamais em público. E não é só por questões de imagem ou qualquer coisa assim. Deixa eu dar uma perspectiva: minhas matérias e artigos circularam entre 1997 e 1999. Hoje em dia, não tem uma pessoa que se lembra mais disso. Os assuntos da época foram todos esquecidos. Pra todos os efeitos, é como se nunca tivessem existido. As brigas são divertidas na hora, mas no final ninguém vai se lembrar, com exceção de quem você pisou no calo. E depois daquela satisfação momentânea, você se sente vazio porque no final, não mudou nada. E você fica querendo ir atrás da próxima briga pra ter de novo a satisfação momentânea, é um vício.

Dê tempo suficiente e qualquer briga que você achou que valia a pena apostar tudo, depois de alguns poucos anos não tem valor nenhum. Não deixa de ser um pouco o: faça o que eu falo mas não faça o que eu fiz. Por outro lado tinha gente que me dizia isso na época, quem disse que eu dei atenção?

O cara da revista Herói ficou tão puto que foi atrás do editor da Animax e socou ele na rua. Foram parar na polícia. E quem escreveu o texto ainda fui eu :-) hahaha Coitado. Vou deixar linkado na descrição se alguém se interessa nesse tipo de história.

Minha recomendação de hoje é: guarde o que você produz, mesmo que você ache que é uma droga. Daqui 20 ou 30 anos vai ser interessante constatar que você realmente evoluiu nesse tempo. Não confie nos serviços de cloud, você provavelmente vai viver mais do que eles. Muitos serviços que eu usava nos anos 90 e começo dos anos 2000 já não existem mais. Lembram do ICQ? Hotmail? Orkut?

E como eu disse no vídeo anterior, eu venho praticando deliberadamente a atividade de escrever desde o meio dos anos 90, agora vocês sabem porque eu escrevo tanto. Estamos no episódio 30 deste canal. Cada episódio tem em média umas 6 páginas no Google Docs, então desde Agosto eu já escrevi 180 páginas de texto, mais de 10 páginas semanalmente, ininterruptamente por umas 15 semanas já. Vou dizer que eu estou bem cansado, vamos ver até onde meu corpo aguenta.

E por hoje é isso aí, faça backups! E não deixe de comentar abaixo! Se curtiram mandem um joinha, compartilhem o vídeo com seus amigos, assinem o canal e cliquem no sininho. A gente se vê, até mais.

Obs: YouTube bloqueou este video por copyright do Anime então subi no Odysee

Descrição no Odysee

Por coincidência, depois dos episódios sobre Talento e Matar Semi-Deuses da semana passada, comecei a assistir este anime de 2007: Kaiji.

Fiquei impressionado com a forma como eles montaram uma alegoria que descreve como é a vida real da maioria das pessoas.

Este episódio vai continuar explicando o meu conceito de “prática deliberada” usando a história deste anime como pano de fundo.

Assista no Crunchyroll: https://www.crunchyroll.com/kaiji

Script

Olá pessoal, Fabio Akita

Esta semana vou fazer um vídeo só. O motivo? Este daqui vai ser super longo, mas espero que eu consiga passar minha mensagem. Tenham paciência comigo e vamos lá.

Não era minha intenção falar sobre animes, pelo menos não agora, mas o assunto cruzou com a série sobre Talento que falei semana passada. Se ainda não assistiu clique no link acima. Você já vai entender porque.

Gyakkyou Burai Kaiji: Ultimate Survivor foi ao ar em 2007 e 2008, produzido pelo lendário estúdio MadHouse, então sabemos que a qualidade de animação é excelente e, no melhor estilo MadHouse, é mais dark e adulto do que os animes que a maioria de vocês estão acostumados.

O autor original é Nobuyuki Fukumoto, que escreveu Kaiji em 1996. Antes desse anime também saiu outro que já entrou pra minha lista pra assistir, Touhai Densetsu Akagi que assim como Kaiji é um thriller psicológico, mas de Mahjong, tudo do mesmo autor e do mesmo estúdio.

Kaiji não é um battle manga como Naruto ou Dragonball, mas eu diria que é a mesma adrenalina, a tensão psicológica é definitivamente alta, nenhum capítulo que vi até agora (e eu estou no 18o no momento em que gravei este vídeo) é um filler ou enrolação, e é o tipo que você não se aguenta de esperar pra ver o próximo episódio.

Eu expliquei em detalhes sobre prática deliberada no vídeo anterior, mas uma coisa muito difícil de explicar é como de fato isso funciona. E um dos problemas é que você começa pensando em algo pequeno e isolado. Se começou a academia, você pensa, vou aplicar prática deliberada no cross-fit ou na maratona ou qualquer coisa assim.

Mas prática deliberada é nada mais, nada menos, que disciplina. A boa e velha. E disciplina não é uma coisa que você liga e desliga pra uma atividade. Esse é um dos maiores problemas: eu disse que o importante não é o resultado, é o processo. Processo é o caminho que leva você do ponto A ao ponto B..

E pra piorar a situação, a maioria das pessoas talvez só entenda isso quando tiver chegado perto da metade da vida. Aos 20 anos é impossível ter essa noção de forma clara. O máximo que você vai conseguir, é fazer o que eu fiz: dar um salto de fé.

(…)

No mundo moderno, todo mundo é imediatista, nós evoluímos ao ponto em que podemos nos dar ao luxo de sermos imediatistas, pense nisso. Todo mundo até se compromete a se matar por um curto período de tempo contanto que exista um resultado palpável logo na sequência. Por exemplo, se matar por 1 ano estudando como se não houvesse amanhã, mas sabendo que na sequência o prêmio é passar no vestibular da melhor universidade.

Mas a vida não funciona assim. E embora eu corra o risco de soar como um tiozão dando sermão, considere algumas verdades fundamentais:

1. a vida não é justa, ela não foi feita pra ser justa. Não há absolutamente nada na fundação da vida que um dia vai garantir igualdade e justiça pra todos. Igualdade e justiça são abstrações da nossa civilização. Veja qualquer ecossistema natural e pergunte ao rato se ele acha justo ser caçado pelo gato, ou o cervo pelo leão. O ciclo da vida é injusto. A natureza é injusta, por isso ela entra em equilíbrio. Equilíbrio não é estático, é um sistema dinâmico, um dia da caça outro do caçador.

2. a vida é meritocrática, meritocracia não tem como premissa a igualdade. Mérito é pura e simplesmente fazer o melhor com o que você tem. Só isso. Se você tem menos que outro competidor e mesmo assim conseguiu superá-lo, isso é mérito. Não existe mérito automático. Mérito é uma conquista, é o cervo que conseguiu correr um pouco mais rápido que o leão e sobreviveu aquele dia. Ë seleção natural.

3. as pessoas não reagem como você gostaria que elas reagissem. enfie isso na sua cabeça e você vai ser mais feliz. Você se frustra com as pessoas não porque elas não te entendem, ou porque são burras ou mal caráter, é você que não entende as outras pessoas. Isso se chama “falta de empatia”. Você pensa “porque esse infeliz não faz o óbvio que é certo?” … só que o “óbvio” e o “certo” são conceitos da sua cabeça. Pra outra pessoa “o certo” é outra coisa diferente e, nesse caso, ele está simplesmente agindo segundo o que ele acredita, não o que você acredita. E isso é lógico. Você se frustra porque assume que todo mundo deveria pensar igual. Bem vindo ao conceito de liberdade e livre arbítrio.

Existem outros fatores importantes mas pro vídeo de hoje esses 3 são suficientes. Eu precisaria de vários vídeos explicando em detalhes o porque dessas afirmações serem verdadeiras acima de dúvida razoável e o que fazer em cada uma delas na prática. Provavelmente eu vou fazer isso.

Mas, e aqui eu retorno ao tópico deste vídeo. Kaiji. Em 2 curtos episódios essa série explicou esses pontos de maneira mais simples e mais eficaz do que eu conseguiria em 10 vídeos. Claro, é um anime, é superficial, mas talvez justamente por isso seja tão efetivo.

Kaiji é um sandbox, é basicamente um simulador social. Um experimento social tenta colocar as pessoas num ambiente controlado, remover todas as variáveis externas e deixar as pessoas se comportarem em situações extremas. É quando o melhor e o pior das pessoas vem à tona.

Breaking bad é um dos temas do anime. Kaiji é um jovem de 20 e poucos anos, como muitos de vocês assistindo. Sem um tostão no bolso, gosta de procrastinar, não sabe o que fazer da vida, e fica esperando uma grande chance cair no colo. Todo mundo já fez isso.

Kaiji é uma alegoria ou uma parábola, não é pra levar ao pé da letra. Ela serve de perspectiva pra você. Vai rolar um pouquinho de spoilers a partir de agora mas não se preocupe é só de um trecho da série. Não vai estragar a série toda.

Nesse ponto você precisa saber que por diversos motivos Kaiji se endividou com um grupo tipo Yakuza. Das duas uma, ou ele vai ter que viver como escravo da Yakuza e dar praticamente todo o pouco salário que ganha só pra conseguir pagar os juros da dívida pelos próximos 16 anos ou ele participa de uma série de jogos desse grupo, jogos desenhados pra entreter caras ricos e entediados que querem se divertir.

(clip)

Só que esses jogos são tudo ou nada. Se você ganha, se livra de todas as dívidas e ainda pode sair com algum dinheiro. Se você perde, na pior das hipóteses sai com ainda mais dívida ou, na melhor das hipóteses, você morre.

Nesse jogo estão diversos outros caras endividados. No começo eles se simpatizam até porque estão todos no mesmo barco. Mas quando a coisa realmente aperta, no final cada um pensa por si só.

(clip)

Cada etapa desses jogos são decisões de moral, o que eu faço? Morro ou mato? Todo mundo em algum momento se sente numa situação dessas. Todo mundo se acha o bastião da moral e dos bons costumes, menos quando está ele mesmo numa situação ruim, daí o que as pessoas fazem? Acham justificativas. Todo discurso bonitinho de moral cai por terra na primeira dificuldade, por isso eu tenho zero paciência pra quem gosta de cagar regra de moralidade. Nenhum de nós jamais vai ser 100% moralmente perfeito. Julgar os outros pela moral é perda de tempo.

E nessa série, assim como na vida real, quando você acha que venceu a batalha, descobre que a guerra é muito maior. Você acabou de fazer o que achou que deveria, inclusive traindo sua moral. “Foi por um bem maior” você pensa, e vem o balde de água fria, com um desafio ainda pior.

(clip)

Eu comecei a ver essa série porque um dos tops da Crunchyroll agora é o Mr Tonegawa que é um spin off do Kaiji. E o tal Mr Tonegawa aparece aqui também e o cara é sensacional, agora entendi porque ele tem uma série só dele. Eu gosto de pensar que eu tenho um Tonegawa na minha cabeça me dizendo mais ou menos as mesmas coisas. Durante muitos momentos da minha vida eu fui como um Kaiji e tendo um Tonegawa martelando dentro da minha cabeça sempre me ajudou. Vamos ver:

(clip tonegawa)

Eu não sei como funciona pra todo mundo porque eu só conheço dentro da minha cabeça. Mas eu me identifiquei muito. De qualquer forma, de volta ao jogo, nesse cenário de atravessar caminhando na barra entre os dois prédios, você poderia pensar: porque eles só não agarram na barra e vão se arrastando então? Ah esse autor pensou em tudo.

(clip eletrico)

Também me identifiquei com isso porque eu tenho a mania de colocar obstáculos que nem existem só pra ver se eu consigo superar. E são coisas pequenas, às vezes eu me coloco um prazo absurdo. Ou me forço a fazer coisas que nem precisaria, tipo agora, fazer 2 vídeos por semana. É meu Tonegawa eletrificando minha ponte antes de eu caminhar.

Todo mundo deveria ter um Tonegawa. Pra ocasiões onde ficamos empacados:

(clip esperando)

Se ainda não passaram por isso, vocês vão passar, aquele momento em que ou vai ou racha, que não tem mais volta. Você tenta de tudo pra ter pensamento positivo, se animar, “acreditar” que é possível.

(clip acreditar)

Mesmo frente à uma situação quase impossível, você vai encontrar alguém que vai te dizer que é possível. Interessante como um monte de gente que nunca atravessou a ponte de verdade consegue dizer pros outros que vai conseguir. Nunca entendi esses coaches modernos.

Eu dei muita risada ne sse clip porque pareceu um desses coaches, vendedor de metodologia, eu sempre vejo eles dessa forma:

(clip metodologia)

E da mesma forma como quando eu vejo um vendedor de metodologia, coach, guru, especialista, empreendedor serial … o Tonegawa na minha cabeça pensa a mesma coisa:

(clip tonegawa)

Eu falo com um certo desdém de todos esses títulos pomposos mas na realidade eu não acho que eles estão querendo de fato enganar ninguém, eles estão até sendo sinceros. Como o Kaiji. Mas são ingênuos, porque a realidade é muito pior do que se imagina, como disse Tonegawa, eles vão durar os primeiros 5 metros. E todo coach que se preza fica com as pessoas só durante os primeiros 5 metros da ponte. E vamos ver um empreendedor de primeira viagem querendo atravessar a ponte, agora que ele aprendeu a metodologia.

(clip entrando na ponte)

Todo workshop, evento, meetup, é igual o que acabamos de ver o Kaiji dizer, mas poucos chegam nessa conclusão a tempo e mesmo quando entendem isso, continuam como um bando de Lemmings. Mas dê um pouco de tempo e a realidade bate na sua porta, brutalmente e imediatamente como um demônio. De novo, Tonegawa já sabia disso:

(clip tonegawa)

Quando eu disse no vídeo anterior que é muito difícil só ir aprendendo enquanto você vai fazendo, tipo, acabei de sair da faculdade, não tenho idéia do que estou fazendo mas vou abrir uma empresa, uma startup, vou aprendendo enquanto vou fazendo. Você vai em eventos, vê grupos empolgados como o Kaiji acima, risca seu tênis pra alinhar na ponte, segue a metodologia, mas na hora H é assim que você vai se sentir:

(clip dando pra trás)

Finalmente, a maioria nunca realmente treinou pra isso. É na hora H na zona de pânico de Noel Tichy, que você vai arriscar tudo. É uma aposta, um jogo de cassino. Se você não tiver estrutura pra aguentar, você vai ceder.

(clip oota)

Pra cada uma história de sucesso precoce que você vê publicado num Techcrunch ou Buzzfeed existem dezenas de caras como Ootas que não geram notícia nenhuma, que no começo acharam que poderiam ir até o fim, mas foram derrotados e esquecidos pela realidade.

E aí, você vê outros iguais a você falhando, fracassando, caindo, e você entra em desespero. E é pior ainda se tentar voltar atrás.

(clip voltando atrás)

E agora?

No cenário desse jogo, existe o Tonegawa que representa um grupo de mafiosos Yakuza, e vários ricos que estão assistindo a isso enquanto jantam e bebem, apostando em quem vai ganhar e nem aí pra quem vai perder.

Eu sei que é uma metáfora extrema, mas pensem neles como seus investidores, venture capitalists, fundos de investimento. O que você acha que eles vão fazer se você falhar? Cair com você?

E como Tonegawa disso, 200 mil dólares é muito dinheiro. E você acha que soltando fogos de artifício de segunda categoria e clamando frases de efeito, vai fazer jus a esse investimento? Se cair, você cai sozinho.

E se você já se comprometeu até o pescoço, e no meio da travessia descobre que não tem peito suficiente pra continuar, que opções você tem?

(clip pede pra desistir)

Pior ainda, sabe o que começa a acontecer na maioria dos grupos de amadores que se juntam só com frases de efeito e palavras bonitas mas que tem pouca ação?

(clip todo mundo caindo)

Como eu disse, o caminho pra grandeza é solitário. Por mais que seria bacana se fosse possível que todos andássemos juntos e ritmados pro mesmo lugar, a realidade é que cada um trilha seu caminho.

(clip solidao)

Cada um trilha seu caminho. O caminho pra cima é solitário, o caminho do empreendedor - e quando eu digo empreendedor não quer dizer só quem abre empresa, é qualquer um que decide empreender qualquer coisa, incluindo você mesmo. Esse caminho é o mais solitário de todos.

Mas voltando pra realidade. Essa alegoria é terrivelmente cruel. É cruel mas é uma boa ilustração do que os espera no mundo real.

Se você conseguiram se engajar na história do Kaiji, talvez se sintam tensos agora, estejam torcendo pra que eles consigam atravessar, talvez estejam com raiva do Tonegawa por ser tão frio.

Mas não se esqueçam de uma realidade: o Tonegawa e esse grupo não forçou ninguém a estar nessa situação. Os jogadores se colocaram nessa situação sozinhos. Na verdade, esse jogo é uma benção pra eles. Lembram do que o Tonegawa disse? Todas as más decisões que eles tomaram na vida os levou até aquele ponto. Vítimas da sociedade? Não, isso é só uma desculpa.

Mesmo que não seja verdade, encare dessa forma: onde você está nesse exato momento é o resultado de todas as decisões que você tomou até agora. Só porque você não consegue imaginar outros caminhos alternativos, não quer dizer que eles não existem. Onde eu estou neste momento é o resultado de todas as boas e de todas as más decisões que eu tomei, sozinho. Se eu tenho problemas, não é culpa de ninguém a não ser de mim mesmo, e o mesmo vale pra todos vocês.

A vida real é injusta. Ela não foi feita pra ser justa. Alguns começaram com muito mais vantagens que nós; e muitos deles, mesmo com todas as vantagens também estão atravessando a ponte como nós. Não importa o que você tem se não consegue tomar as decisões que precisa, no momento que precisa.

Sua vida é o conjunto de todas as suas decisões. Livre arbítrio tem essa desvantagem: se tudo der errado, a culpa é sua, e só sua. Não importa quantos tweets mal criados você poste apontando dedos pra todo mundo.

Mas a vantagem do livre arbítrio é que nunca é tarde. O Tonegawa não é o vilão da história. E é essa uma das coisas que eu mais gostei dessa série até agora. O vilão da história são as más decisões dos protagonistas. O Tonegawa representa a consciência que você deveria tentar ouvir. Ele diz só a verdade. A verdade cruel que nós não queremos ouvir.

Eu também sinto dó de mim mesmo algumas vezes. Quando eu explico coisas como no vídeo anterior, fica parecendo que eu fiz o caminho certinho, passo a passo sem errar nada. É o contrário, eu só sei que aquele funciona porque eu tentei outros que não funcionam como o Kaiji. Eu também atravessei aquela ponte. Eu vi com meus próprios olhos as pessoas caindo dela. E eu me vi no mesmo desespero quase caindo também. E não quer dizer que eu não vou ter que subir nessa ponte de novo. E acredite, você nunca está preparado o suficiente.

No vídeo anterior eu disse o seguinte: “Os melhores fixam objetivos que não são sobre o resultado mas sobre o processo de chegar no resultado.” Pois bem, eu não quis dizer o processo só de uma atividade isolada como programar ou fazer academia. Sua vida inteira é um processo em andamento.

O objetivo? Chegar no dia da sua morte sabendo que você não deixou de fazer o que deveria ter feito, seja lá o que isso for.

Ufa, esse episódio ficou dark né? A realidade não é sempre colorida, mas é melhor entender isso antes do que depois. Você já teve que atravessar essa ponte? Como foi pra você? Compartilhe com a gente nos comentários abaixo, se curtiram mandem um joinha, assinem o canal e clique no sininho. A gente se vê, até mais!

• MRI Ruby 2.3.1: 57 segundos
• JRuby 9.1.1.0: 45 segundos
• Crystal 0.17.0: 59 segundos
• Elixir: 14 segundos

Eu também disse que era uma comparação injusta, já que a versão Elixir usa um algoritmo diferente - e obviamente mais eficiente.

Era a “primeira-versão-que-funcionou”, então resolvi ir adiante e melhorar as implementações. Na versão Ruby/JRuby adicionei a gem thread pra ter uma implementação razoável de Thread pool que funciona tanto em Ruby quanto em JRuby. Eu provavelmente deveria ter usado Concurrent-Ruby, mas estava tendo problemas pra fazer o FixedThreadPool funcionar.

Enfim, agora todas as versões vão ter um pool constante de requisições rodando e podemos fazer uma comparação melhor.

Outra coisa que pode ter prejudicado os resultados do Crystal é que ele parece ter uma implementação defeituosa de DNS resolver, então por enquanto eu só adicionei o IP do Manga Reader direto no meu /etc/hosts pra evitar exceções de getaddrinfo: Name or service not known.

Pra começar, vamos testar a mesma implementação Elixir e, como esperado, o resultado continua o mesmo:

11,49s user 0,82s system 77% cpu 15,827 total

Agora, o MRI Ruby com o algoritmo de “rajada em lote” estava levando 57 segundos e essa nova implementação usando ThreadPool roda muito melhor:

12,67s user 0,92s system 50% cpu 27,149 total

Em Crystal é um pouco mais complicado, porque não tem como implementar o equivalente a um “Fiber Pool”. O que temos que fazer é um loop infinito até o último processo sinalizar a quebra do loop. Dentro do loop criamos um número máximo de fibers, esperamos cada uma sinalizar que terminou através de um channel individual e voltamos ao loop pra criar uma nova fiber, e por aí vai. Comparado aos 59 segundos de ontem, isso é bem melhor:

5,29s user 0,33s system 26% cpu 21,166 total

A versão JRuby não está tão rápida. Ainda melhor que os 45 segundos de ontem, mas agora está perdendo até pro MRI:

49,24s user 1,41s system 146% cpu 34,602 total

Tentei usar a flag --dev pra tempo de inicialização mais rápido e melhora um pouco, ficando mais perto do MRI:

22,26s user 0,99s system 76% cpu 30,320 total

Não sei se dá pra melhorar mais, mas qualquer dica é bem-vinda - não esqueçam de comentar abaixo.

Então, Elixir continua pelo menos duas vezes mais rápido que Crystal nesse momento. Mas isso também demonstra como um algoritmo diferente faz uma diferença enorme onde importa. Eu provavelmente consigo ajustar mais um pouco, mas isso já basta por enquanto.

Mudando a implementação Ruby pra usar ThreadPool

require "thread/pool"

module MangaDownloadr
  class Concurrency
    ...
    def fetch(collection, &block)
      pool    = Thread.pool(@config.download_batch_size)
      mutex   = Mutex.new
      results = []

      collection.each do |item|
        pool.process {
          engine  = @turn_on_engine ? @engine_klass.new(@config.domain) : nil
          reply = block.call(item, engine)&.flatten
          mutex.synchronize do
            results += ( reply || [] )
          end
        }
      end
      pool.shutdown

      results
    end
    ...

A ideia é que vamos ter um número fixo de threads nativas spawnadas (nesse caso, determinado por @config.download_batch_size). Conforme uma thread termina, ela puxa um novo link do Array collection, funcionando essencialmente como uma “fila” a ser esvaziada.

Os resultados são acumulados no Array results. Como várias threads podem querer modificá-lo ao mesmo tempo, temos que sincronizar o acesso através de um Mutex.

Dessa forma sempre temos uma quantidade fixa de workers fazendo requisições constantemente em vez de fatiar o Array collection e fazer rajadas como na versão anterior.

Mudando a implementação Crystal pra simular um Pool de Fibers

A versão Crystal ficou um pouco mais complicada porque não achei nenhuma biblioteca de pool pra usar. Encontrei uma implementação rústica de pool neste post do stackoverflow e consegui implementar uma versão melhorada num shard novo, pra que vocês possam aproveitar nos seus projetos. Confiram o código fonte em akitaonrails/fiberpool. Foi assim que adicionei no meu projeto:

dependencies:
  ...
  fiberpool:
    github: akitaonrails/fiberpool

E foi assim que usei. Repare que a lógica em si é bem próxima da versão MRI Ruby, mas usando um “Fiber Pool” em vez de Thread Pool.

require "fiberpool"

module CrMangaDownloadr
  struct Concurrency
    def initialize(@config : Config, @turn_on_engine = true); end

    def fetch(collection : Array(A)?, engine_class : E.class, &block : A, E? -> Array(B)?) : Array(B)
      results = [] of B
      if collection
        pool = Fiberpool.new(collection, @config.download_batch_size)
        pool.run do |item|
          engine = if @turn_on_engine
                     engine_class.new(@config.domain, @config.cache_http)
                   end
          if reply = block.call(item, engine)
            results.concat(reply)
          end
        end
      end
      results
    end
  end
end

Mas, de novo, isso é muito intensivo em I/O e tanto a versão Ruby quanto a Crystal aproveitam o fato de poderem fazer mais trabalho enquanto esperam uma requisição HTTP terminar.

Reproduzindo os Testes

Implementei um “Modo de Teste” nas 3 implementações. Vocês podem clonar dos meus repositórios:

• Versão Crystal
• Versão Ruby/JRuby
• Versão Elixir

E vocês podem rodar o modo de teste assim:

# crystal:
time ./cr_manga_downloadr --test

# MRI:
time bin/manga-downloadr --test

# JRuby (você precisa editar o Gemfile pra descomentar a engine JRuby):
time jruby --dev -S bin/manga-downloadr --test

# Elixir:
time ./ex_manga_downloadr --test

Isso vai rodar só o fetch de capítulos, páginas e links de imagens, pulando o download real das imagens, otimização via mogrify e compilação do PDF. Essas partes puladas demoram demais e não dizem nada sobre as linguagens testadas.

E se quiserem testar só as partes intensivas em CPU e evitar qualquer interferência de rede, vocês podem ligar o modo HTTP Cache e rodar os testes duas vezes pra que a primeira execução cacheie tudo, assim:

# crystal:
time ./cr_manga_downloadr --test --cache

# MRI:
time bin/manga-downloadr --test --cache

# JRuby (você precisa editar o Gemfile pra descomentar a engine JRuby):
time jruby --dev -S bin/manga-downloadr --test --cache

# Elixir:
time CACHE_HTTP=true ./ex_manga_downloadr --test

Então, com todas as requisições já cacheadas esses são os resultados:

Elixir:

7,13s user 0,24s system 331% cpu 2,227 total

MRI Ruby:

5.590000   0.180000   5.770000 (  5.678714)
5,87s user 0,21s system 101% cpu 5,996 total

JRuby:

10.580000   0.180000  10.760000 (  3.184472)
14,54s user 0,44s system 262% cpu 5,716 total

Crystal:

1.610000   0.050000   1.660000 (  1.344123)
1,62s user 0,06s system 124% cpu 1,350 total

As versões Ruby/JRuby/Crystal têm benchmarks internos pra remover o tempo de startup (por isso elas têm 2 linhas de tempos).

Então, Elixir é muito rápido. Leva mais ou menos 2 segundos pra parsear todos os 1.900 arquivos HTML procurando os links.

Ruby é o mais lento, obviamente. Leva quase 6 segundos.

A versão JRuby também leva quase 6 segundos, mas internamente processa em 3 segundos; o resto é tempo de startup e warm up da JVM por baixo.

E Crystal é o mais rápido, como vocês esperariam, porque é um binário super otimizado fazendo operações CPU bound, marcando pouco mais de 1 segundo.

Conclusão

Mesmo com algoritmos mais ou menos parecidos, Elixir continua ganhando por uma margem muito grande no processo total (com as requisições HTTP externas).

Tem mais coisa em jogo além de velocidade de interpretador/compilador, além de infraestrutura de single-thread, multi-thread e fibers.

Também temos a maturidade das respectivas bibliotecas padrão (incluindo stack TCP, bibliotecas HTTP client, operações de String/Array/Regex, etc.) e bibliotecas de terceiros (libXML, Nokogiri, etc.). Então tem muita coisa que pode interferir nos testes. Eu chutaria que a stdlib do Crystal, especialmente as partes de rede, ainda não está bem testada em batalha nesse momento (pré 1.0!).

Então, o resumo com os novos resultados é esse:

• MRI Ruby 2.3.1: 27 segundos
• JRuby 9.1.1.0: 30 segundos
• Crystal 0.17.0: 21 segundos
• Elixir: 15 segundos

Me avisem se tiverem ideias pra deixar tudo ainda mais rápido!

A natureza do Manga Downloader original é a de um web crawler: ele baixa páginas HTML, faz parse para encontrar coleções de links e segue baixando até que um conjunto de imagens seja salvo. Depois eu organizo tudo em volumes, otimizo para caber na resolução de tela do Kindle e compilo em arquivos PDF. Isso faz desse projeto um exercício interessante para tentar fazer requisições HTTP concorrentes e processar os resultados.

Um ano depois eu estava aprendendo Elixir. O Manga Downloadr era um bom candidato para eu descobrir como implementar a mesma coisa em outra linguagem. Você pode acompanhar o meu processo de aprendizado nessa série de posts.

Finalmente, venho aprendendo mais sobre Crystal, uma plataforma inspirada em Ruby que compila código fonte parecido com Ruby em binários nativos otimizados via LLVM. E de bônus oferece canais e fibras no estilo CSP, parecido com Go, para permitir código concorrente.

Então adaptei minha versão Elixir para Crystal e o resultado é esse código que você encontra no Github como akitaonrails/cr_manga_downloadr.

Funciona muito bem e roda bem rápido, limitado principalmente por quantas requisições o MangaReader consegue responder concorrentemente e pela velocidade/confiabilidade da conexão de Internet. E como minha versão Ruby original era um código terrível, era uma boa hora para reescrevê-la. E como Crystal é surpreendentemente próximo de Ruby, decidi portar.

A portagem foi quase trivial demais

Foi praticamente copiar e colar o código Crystal sem as anotações de tipo. E tive que substituir a implementação leve de Fibers e Channel para concorrência pelas tradicionais Threads de Ruby.

A nova versão 2.0 da ferramenta em Ruby pode ser encontrada nesse repositório no Github: akitaonrails/manga-downloadr.

Ruby, Ruby por todo lado!

Transitar entre Ruby e Crystal não é tão difícil. O time do Crystal fez um trabalho fantástico implementando uma Standard Library (stdlib) muito sólida, que se assemelha bastante à do MRI Ruby.

Por exemplo, vamos comparar primeiro um trecho da minha versão Crystal:

def fetch(page_link : String)
  get page_link do |html|
    images = html.xpath("//img[contains(@id, 'img')]").as(XML::NodeSet)
    image_alt = images[0]["alt"]
    image_src = images[0]["src"]
    if image_alt && image_src
      extension      = image_src.split(".").last
      list           = image_alt.split(" ").reverse
      title_name     = list[4..-1].join(" ")
      chapter_number = list[3].rjust(5, '0')
      page_number    = list[0].rjust(5, '0')
      uri = URI.parse(image_src)
      CrMangaDownloadr::Image.new(uri.host as String, uri.path as String, "#{title_name}-Chap-#{chapter_number}-Pg-#{page_number}.#{extension}")
    else
      raise Exception.new("Couldn't find proper metadata alt in the image tag")
    end
  end
end

Agora vamos olhar a versão portada para Ruby:

def fetch(page_link)
  get page_link do |html|
    images = html.css('#img')

    image_alt = images[0]["alt"]
    image_src = images[0]["src"]

    if image_alt && image_src
      extension      = image_src.split(".").last
      list           = image_alt.split(" ").reverse
      title_name     = list[4..-1].join(" ")
      chapter_number = list[3].rjust(5, '0')
      page_number    = list[0].rjust(5, '0')

      uri = URI.parse(image_src)
      Image.new(uri.host, uri.path, "#{title_name}-Chap-#{chapter_number}-Pg-#{page_number}.#{extension}")
    else
      raise Exception.new("Couldn't find proper metadata alt in the image tag")
    end
  end
end

É impressionante como são parecidos, até mesmo nas chamadas de stdlib como URI.parse ou métodos de Array como split.

Quando você remove as anotações de tipo da versão Crystal, é 99% Ruby.

Ruby pouco se importa se você está chamando um método em um objeto Nil - em tempo de compilação. Crystal faz checagens em tempo de compilação e, se ele acha que a chamada de método pode acontecer sobre Nil, simplesmente não compila. Isso é uma grande vitória para evitar bugs sutis.

Em Rails estamos acostumados com o famigerado método #try. O Ruby 2.3 introduziu o safe navigation operator.

Então, em Ruby 2.3 com Rails, ambas as linhas a seguir são válidas:

obj.try(:something).try(:something2)
obj&.something&.something2

Em Crystal podemos fazer assim:

obj.try(&.something).try(&.something2)

Então, é parecido. Use com cuidado.

Como mencionei antes, Crystal é próximo de Ruby, mas a intenção dele é ser uma linguagem própria, então não dá para simplesmente carregar Rubygems sem portar. Nesse exemplo eu não tenho Nokogiri para fazer parse de HTML. E é justamente aí que a stdlib brilha: Crystal vem com parsers de XML/HTML e JSON suficientemente bons. Então podemos fazer parse do HTML como XML e usar XPath puro.

No lugar do Net::HTTP do Ruby temos HTTP::Client (mas seus métodos e semântica são surpreendentemente similares).

Existem outras diferenças, por exemplo, esse é o arquivo principal que faz require de todos os outros em Ruby:

...
$LOAD_PATH.unshift File.join(File.dirname(__FILE__), "lib")

require "manga-downloadr/records.rb"
require "manga-downloadr/downloadr_client.rb"
require "manga-downloadr/concurrency.rb"
require "manga-downloadr/chapters.rb"
require "manga-downloadr/pages.rb"
require "manga-downloadr/page_image.rb"
require "manga-downloadr/image_downloader.rb"
require "manga-downloadr/workflow.rb"

E essa é a versão Crystal do mesmo manifesto:

require "./cr_manga_downloadr/*"
...

Por outro lado, precisamos ser um pouco mais explícitos em cada arquivo de código fonte Crystal e declarar as dependências específicas onde forem necessárias. Por exemplo, no arquivo pages.cr ele começa assim:

require "./downloadr_client"
require "xml"

module CrMangaDownloadr
  class Pages < DownloadrClient(Array(String))
  ...

Crystal tem menos espaço para “mágica”, mas ainda assim consegue manter um alto nível de abstração.

Uma palavra sobre Tipos

Podemos passar a próxima década masturbando sobre tudo que existe sobre Tipos, e vai ser extremamente chato.

A única coisa que você precisa entender: o compilador precisa conhecer a assinatura dos métodos das classes antes de poder usá-las. Não existe um componente em Runtime que possa introspectar objetos em tempo real, como em Ruby e em outras linguagens dinâmicas (até Objective-C/Swift consegue fazer mais coisa dinâmica do que Crystal).

Na maior parte do tempo o compilador do Crystal é inteligente o bastante para inferir os tipos para você, então você não precisa ser absolutamente explícito. Você deve seguir o que o compilador indica para saber quando usar Type Annotations.

O que pode te assustar de início é a necessidade de Type Annotations, entender Generics e por aí vai. O compilador vai cuspir cada dump de erro assustador, e você vai precisar se acostumar. A maioria dos erros assustadores costuma ser ou uma Type Annotation faltando, ou você tentando chamar um método em um possível objeto Nil.

Por exemplo, se eu mudar a linha a seguir no arquivo de teste page_image_spec.cr:

# linha 8:
image = CrMangaDownloadr::PageImage.new("www.mangareader.net").fetch("/naruto/662/2")

# linha 10:
# image.try(&.host).should eq("i8.mangareader.net")
image.host.should eq("i8.mangareader.net")

A linha comentada reconhece que a instância image pode vir como Nil, então adicionamos uma chamada explícita de #try no spec.

Se tentarmos compilar sem esse reconhecimento, esse é o erro que o compilador vai despejar em você:

$ crystal spec                                                        [
Error in ./spec/cr_manga_downloadr/page_image_spec.cr:10: undefined method 'host' for Nil (compile-time type is CrMangaDownloadr::Image?)

    image.host.should eq("i8.mangareader.net")
          ^~~~

=============================================================================

Nil trace:

  ./spec/cr_manga_downloadr/page_image_spec.cr:8

        image = CrMangaDownloadr::PageImage.new("www.mangareader.net").fetch("/naruto/662/2")
...

Tem um stacktrace gigante depois desse trecho, mas você só precisa prestar atenção nas primeiras linhas, que já dizem o que está errado: “undefined method ‘host’ for Nil (compile-time type is CrMangaDownloadr::Image?)”. Se você sabe ler, na maior parte do tempo não vai ter problema nenhum.

Agora, Chapters, Pages, PageImage (todos subclasses de DownloadrClient) são basicamente a mesma coisa: fazem requisições com HTTP::Client.

É assim que a classe Pages é implementada:

...
module CrMangaDownloadr
  class Pages < DownloadrClient(Array(String))
    def fetch(chapter_link : String)
      get chapter_link do |html|
        nodes = html.xpath_nodes("//div[@id='selectpage']//select[@id='pageMenu']//option")
        nodes.map { |node| [chapter_link, node.text as String].join("/") }
      end
    end
  end
end

#get é um método da superclasse DownloadrClient que recebe uma String chapter_link e um bloco. O bloco recebe uma coleção de nós html já parseada e podemos brincar com ela, retornando um Array de Strings.

É por isso que temos o (Array(String)) ao herdar de DownloadrClient. Vejamos como a superclasse DownloadrClient é implementada.

module CrMangaDownloadr
  class DownloadrClient(T)
    ...
    def get(uri : String, &block : XML::Node -> T)
      response = @http_client.get(uri)
      case response.status_code
      when 301
        get response.headers["Location"], &block
      when 200
        parsed = XML.parse_html(response.body)
        block.call(parsed)
      end
      ...
    end
  end
end

Você pode ver que essa classe recebe um Generic Type e usa ele como o tipo de retorno do bloco yieldado no método #get. O XML::Node -> T é a declaração da assinatura do bloco, enviando XML::Node e recebendo aquilo que T for. Em tempo de compilação, imagine esse T sendo substituído por Array(String). É assim que dá para criar classes capazes de lidar com qualquer número de Tipos diferentes sem precisar fazer overload para polimorfismo.

Se você vem de Java, C#, Go ou qualquer outra linguagem moderna estaticamente tipada, provavelmente já sabe o que é um Generic.

Você pode ir bem longe com Generics, veja como começa o nosso Concurrency.cr:

class Concurrency(A, B, C)
  ...
  def fetch(collection : Array(A)?, &block : A, C? -> Array(B)?) : Array(B)?
    results = [] of B
    collection.try &.each_slice(@config.download_batch_size) do |batch|
      engine  = if @turn_on_engine
                  C.new(@config.domain)
                end
      channel = Channel(Array(B)?).new
      batch.each do |item|
      ...

E é assim que usamos no workflow.cr:

private def fetch_pages(chapters : Array(String)?)
  puts "Fetching pages from all chapters ..."
  reactor = Concurrency(String, String, Pages).new(@config)
  reactor.fetch(chapters) do |link, engine|
    engine.try( &.fetch(link) )
  end
end

Nesse exemplo, imagine A sendo substituído por String, B também sendo substituído por String e C sendo substituído por Pages na classe Concurrency.

Essa é a “primeira-versão-que-funcionou”, então provavelmente está pouco idiomática. Talvez dê para resolver com menos exercício de Generics ou, quem sabe, eu pudesse simplificar com o uso de Macros. Mas está funcionando bem assim.

A versão pura em Ruby acaba ficando assim:

class Concurrency
  def initialize(engine_klass = nil, config = Config.new, turn_on_engine = true)
    ...
  end
  def fetch(collection, &block)
    results = []
    collection&.each_slice(@config.download_batch_size) do |batch|
      mutex   = Mutex.new
      threads = batch.map do |item|
      ...

Essa versão é muito “mais simples” em termos de densidade de código fonte. Em compensação, teríamos que testar essa versão Ruby muito mais, porque ela tem várias permutações diferentes (a gente até injeta classes via engine_klass) e precisamos garantir que tudo responda corretamente. Na prática, deveríamos adicionar testes para todas as combinações dos argumentos do inicializador.

Na versão Crystal, como todos os tipos foram checados em tempo de compilação, foi mais exigente em termos de anotações; mas podemos ter bastante certeza de que se compilou, vai rodar como esperado.

Não estou dizendo que Crystal dispensa specs.

Compiladores só vão até certo ponto. Mas até onde é “certo ponto”? Sempre que você é “forçado” a adicionar Type Annotations, eu afirmo que essas partes ou estão tentando ser espertas demais, ou são intrinsecamente complexas. Essas são as partes que exigiriam camadas extras de testes em Ruby e, se conseguirmos adicionar as anotações direito, podemos ter menos testes (não precisamos cobrir a maior parte das permutações) na versão Crystal (uma complexidade exponencial de permutações poderia cair para uma complexidade linear, eu acho).

Uma palavra sobre Threads em Ruby

Os principais conceitos que você precisa entender sobre concorrência em Ruby são esses:

• MRI Ruby tem um GIL, um Global Interpreter Lock, que proíbe código de rodar concorrentemente.
• MRI Ruby tem acesso e expõe Threads nativas desde a versão 1.9. Mas mesmo se você disparar várias Threads, elas vão rodar sequencialmente, porque só uma thread pode segurar o Lock por vez.
• Operações de I/O são a exceção: elas liberam o Lock para que outras threads rodem enquanto a operação está esperando completar. O SO sinaliza o programa via poll de nível de sistema.

Isso significa que se sua aplicação é I/O intensiva (requisições HTTP, leituras ou escritas em arquivos, operações de socket etc), você terá alguma concorrência. Um servidor web, como Puma por exemplo, pode tirar algum proveito de Threads, porque uma boa parte das operações envolve receber requisições HTTP e mandar respostas HTTP pela rede, o que deixa o processo Ruby ocioso enquanto espera.

Se sua aplicação é CPU intensiva (algoritmos pesados, processamento de dados, coisas que realmente esquentam o CPU), aí Threads nativas não ajudam, só uma roda por vez. Se você tem múltiplos cores no seu CPU, pode dar Fork no seu processo para o número de cores disponíveis.

Dê uma olhada em grosser/parallel para facilitar.

É por isso que Puma também tem um modo “worker”. “Worker” é o nome que normalmente damos para processos filhos forkados.

No caso desse processo de download, ele vai fazer milhares de requisições HTTP para raspar os metadados necessários das páginas do MangaReader. Então é muito mais I/O intensivo do que CPU intensivo (as partes CPU intensivas são o parsing do HTML e, mais tarde, o redimensionamento das imagens e a compilação do PDF).

Uma versão sequencial do que precisa ser feito, em Ruby, fica assim:

def fetch_sequential(collection, &block)
  results = []
  engine  = @turn_on_engine ? @engine_klass.new(@config.domain) : nil
  collection&.each_slice(@config.download_batch_size) do |batch|
    batch.each do |item|
      batch_results = block.call(item, engine)&.flatten
      results += ( batch_results || [])
    end
  end
  results
end

Se temos 10.000 links na collection, primeiro fatiamos no tamanho que @config.download_batch_size define e iteramos sobre essas fatias menores, chamando algum bloco e acumulando os resultados. Esse é um algoritmo ingênuo, como você vai descobrir na próxima seção, mas vamos seguir.

Em Elixir você pode disparar micro-processos para fazer as requisições HTTP em paralelo. Em Crystal você pode disparar Fibers e esperar as requisições HTTP completarem e sinalizar os resultados via Channels.

Os dois são leves e você pode ter centenas ou até milhares rodando em paralelo. O Manga Reader provavelmente vai reclamar se você mandar tudo isso de uma vez, então o limite não está no código, e sim no serviço externo.

Para transformar a versão sequencial em uma concorrente, é isso que podemos fazer em Crystal:

def fetch(collection : Array(A)?, &block : A, C? -> Array(B)?) : Array(B)?
  results = [] of B
  collection.try &.each_slice(@config.download_batch_size) do |batch|
    channel = Channel(Array(B)?).new
    batch.each do |item|
      spawn {
        engine  = if @turn_on_engine
                    C.new(@config.domain)
                  end
        reply = block.call(item, engine)
        channel.send(reply)
        engine.try &.close
      }
    end
    batch.size.times do
      reply = channel.receive
      if reply
        results.concat(reply.flatten)
      end
    end
    channel.close
    puts "Processed so far: #{results.try &.size}"
  end
  results
end

Pegar uma coleção enorme e fatiar em ‘batches’ menores é fácil. Agora temos uma coleção batch menor. Para cada item (geralmente uma URI) damos spawn em uma Fiber e chamamos um bloco que vai requisitar e processar os resultados. Quando termina o processamento, envia os resultados por um channel.

Quando terminamos de iterar sobre o batch e disparar todas essas Fibers, podemos “esperar” por elas chamando channel.receive, que vai começar a receber os resultados conforme as Fibers vão terminando de requisitar/processar cada URI.

Acumulamos os resultados e seguimos para o próximo batch da coleção até terminar. A quantidade de concorrência é determinada pelo tamanho do batch (é parecido com o que fiz com ‘poolboy’ em Elixir onde iniciamos um número fixo de processos rodando em paralelo para evitar fazer um Denial of Service no Manga Reader).

A propósito, essa implementação em Crystal é parecida com o que você faria em Go usando Channels.

Na versão Ruby você pode disparar Threads nativas - que têm bastante overhead para spawnar! - e assumir que as requisições HTTP vão rodar quase todas em paralelo. Como é I/O intensivo, dá para ter todas em paralelo. Fica assim:

def fetch(collection, &block)
  results = []
  collection&.each_slice(@config.download_batch_size) do |batch|
    mutex   = Mutex.new
    threads = batch.map do |item|
      Thread.new {
        engine  = @turn_on_engine ? @engine_klass.new(@config.domain) : nil
        Thread.current["results"] = block.call(item, engine)&.flatten
        mutex.synchronize do
          results += ( Thread.current["results"] || [] )
        end
      }
    end
    threads.each(&:join)
    puts "Processed so far: #{results&.size}"
  end
  results
end

As Threads são todas inicializadas em estado “pausado”. Depois de instanciar todas essas Threads, podemos chamar #join em cada uma e esperar todas terminarem.

Quando cada Thread termina o mesmo processo de requisição/processamento de URI, os resultados precisam ser acumulados em um armazenamento global, nesse caso um simples array chamado results. Mas como existe a chance de duas ou mais threads tentarem atualizar o mesmo array, a gente sincroniza o acesso (não tenho certeza se o acesso a Array em Ruby já é sincronizado, mas acho que não). Para sincronizar o acesso usamos um Mutex, que é um lock fino, garantindo que só 1 thread possa modificar o array global por vez.

Para provar que Ruby suporta operações de I/O concorrentes, adicionei 2 métodos na classe Concurrent, o primeiro é só #fetch e é a implementação com Threads acima. O segundo se chama #fetch_sequential e é a versão sequencial mostrada no início dessa seção. E adicionei o seguinte spec:

it "should check that the fetch implementation runs in less time than the sequential version" do
  reactor = MangaDownloadr::Concurrency.new(MangaDownloadr::Pages, config, true)
  collection = ["/onepunch-man/96"] * 10
  WebMock.allow_net_connect!
  begin
    concurrent_measurement = Benchmark.measure {
      results = reactor.fetch(collection) { |link, engine| engine&.fetch(link) }
    }
    sequential_measurement = Benchmark.measure {
      results = reactor.send(:fetch_sequential, collection) { |link, engine| engine&.fetch(link) }
    }
    /\((.*?)\)$/.match(concurrent_measurement.to_s) do |cm|
      /\((.*?)\)/.match(sequential_measurement.to_s) do |sm|
        # esperado que a versao concorrente seja proxima de 10 vezes mais rapida que a sequencial
        expect(sm[1].to_f).to be > ( cm[1].to_f * 9 )
      end
    end
  ensure
    WebMock.disable_net_connect!
  end
end

Como ele usa WebMock, eu primeiro desabilito durante esse spec. Crio uma coleção falsa de 10 links reais para o MangaReader. E aí faço benchmark da versão concorrente baseada em Threads e da versão sequencial pura. Como temos 10 links e são todos iguais, dá para assumir que a versão sequencial vai ser quase 10 vezes mais lenta que a versão baseada em Threads. E é exatamente isso que esse spec compara e prova (o spec falha se a versão concorrente não for pelo menos 9x mais rápida).

Para comparar todas as versões dos Manga Downloadrs, deixei baixar e compilar uma coleção inteira de mangá, nesse caso “One-Punch Man”, que tem quase 1.900 páginas/imagens. Estou medindo só os processos de fetching e scraping, pulando o download das imagens em si, redimensionamento e geração do PDF, porque eles tomam a maior parte do tempo e o redimensionamento e a parte do PDF são feitos pelo mogrify e convert do ImageMagick.

Esse é o tempo que essa nova versão Ruby leva para baixar e raspar quase 1.900 páginas (usando MRI Ruby 2.3.1):

12,42s user 1,33s system 23% cpu 57,675 total

Esse é o tempo que a versão Crystal leva:

4,03s user 0,40s system 7% cpu 59,207 total

Só por diversão tentei rodar a versão Ruby sob JRuby 9.1.1.0. Para rodar com JRuby basta adicionar a linha a seguir no Gemfile:

ruby "2.3.0", :engine => 'jruby', :engine_version => '9.1.1.0'

Bundle install, roda normalmente, e esse é o resultado:

47,80s user 1,99s system 108% cpu 45,967 total

E esse é o tempo que a versão Elixir leva:

11,38s user 1,04s system 85% cpu 14,590 total

Reality Check!

Se você só olhar os tempos acima, pode chegar a conclusões erradas.

Antes de mais nada, é uma comparação injusta. A versão Elixir usa um algoritmo bem diferente das versões Ruby e Crystal.

Em Elixir eu subo um pool de processos, mais ou menos 50 deles. Aí disparo 50 requisições HTTP de uma vez. Quando cada processo termina, ele se libera de volta para o pool e eu posso disparar outra requisição HTTP da fila de links. Então é um fluxo constante de no máximo 50 requisições HTTP, constantemente.

As versões Crystal e Ruby/JRuby fatiam os 1.900 links em batches de 40 links e aí eu disparo 40 requisições de uma vez. Essa implementação espera todas as 40 terminarem para disparar mais 40. Ou seja, nunca é um fluxo constante, são rajadas de 40 requisições. Cada batch é freado pela requisição mais lenta do batch, sem dar chance para as outras requisições passarem.

É uma diferença de arquitetura. Elixir torna muito mais fácil fazer streams e Crystal, com seu estilo CSP, torna mais fácil fazer rajadas. Uma abordagem melhor seria enfileirar os 1.900 links e usar algo como Sidekiq.cr para ir consumindo um link por vez (spawnando 40 fibers para servir como um “pool”, por exemplo).

A versão Elixir tem uma arquitetura mais eficiente, e é por isso que ela leva no máximo 15 segundos para baixar todos os links de imagens, enquanto a versão Crystal leva quase um minuto inteiro para terminar (a soma das requisições mais lentas em cada batch).

Agora, você vai se surpreender ao ver que a versão Crystal é, na verdade, um pouco mais lenta que a versão Ruby! E você não vai ficar tão surpreso ao ver o JRuby mais rápido aos 45 segundos!

Essa é mais uma evidência de que você não deve descartar Ruby (e que deveria experimentar JRuby com mais frequência). Como expliquei antes, ele suporta concorrência em operações de I/O e as aplicações que testei são todas pesadas em I/O.

A diferença provavelmente está na maturidade da biblioteca Net::HTTP do Ruby contra a HTTP::Client do Crystal. Tentei vários ajustes na versão Crystal, mas não consegui ficar muito mais rápido. Tentei batches maiores, mas por algum motivo a aplicação simplesmente trava, pausa, e nunca libera. Tenho que dar Ctrl-C e tentar de novo até finalmente passar. Se alguém souber o que estou fazendo de errado, não se esqueça de escrever na seção de comentários abaixo.

Parte disso provavelmente é por conta dos servidores instáveis do MangaReader, eles devem ter algum tipo de prevenção contra DoS, throttling de conexões ou algo do tipo.

De qualquer forma, quando passam, como o algoritmo do Ruby e do Crystal são essencialmente o mesmo, eles levam aproximadamente o mesmo tempo para completar. O que falta é eu evoluir esse algoritmo para usar algo como Sidekiq ou implementar um esquema interno de fila/pool de workers.

Conclusão

O objetivo desse experimento era aprender mais sobre as capacidades do Crystal e o quão fácil seria ir e voltar com Ruby.

Como você pode ver, existem muitas diferenças, mas não é tão difícil. Posso estar deixando algo passar, mas esbarrei em algumas dificuldades quando empurrei HTTP::Client + Fibers para o limite, como expliquei acima. Se você sabe o que estou fazendo de errado, me avise.

A diferença entre os algoritmos do Elixir e do Ruby/Crystal mostra mais do que diferenças de performance entre linguagens, mostra também a importância da arquitetura e dos algoritmos na performance geral. Esse teste foi pouco conclusivo, apenas um indício de que minha implementação ingênua de Fibers precisa de mais trabalho, e que a forma natural do Elixir lidar com processos paralelos facilita atingir níveis mais altos de paralelismo.

Isso serve como um aperitivo do que Crystal pode fazer, e também de que Ruby continua no jogo. E também de que Elixir certamente é algo para se acompanhar de perto.

git pull
mix escript.build
./ex_manga_downloadr -n onepunch -u http://mangafox.me/manga/onepunch_man/ -d /tmp/onepunch -s mangafox

E pronto: download direto do Mangafox embutido! \o/

Tudo começou quando eu quis baixar um mangá que não existe no MangaReader mas está disponível no Mangafox.

Então a empreitada inicial foi copiar os módulos do parser do MangaReader (IndexPage, ChapterPage e Page) e colar numa pasta específica “lib/ex_manga_downloadr/mangafox”. A mesma coisa na pasta de testes unitários. Só copiar e colar os arquivos e trocar o nome do módulo “MangaReader” por “Mangafox”.

Claro que os formatos de URL são diferentes, os seletores CSS do Floki são um pouquinho diferentes, então é isso que precisa mudar no parser. Por exemplo, é assim que eu faço o parsing dos links de capítulo da página principal no MangaReader:

defp fetch_chapters(html) do
  Floki.find(html, "#listing a")
  |> Enum.map fn {"a", [{"href", url}], _} -> url end
end

E essa é a mesma coisa, só que para o Mangafox:

defp fetch_chapters(html) do
  html
  |> Floki.find(".chlist a[class='tips']")
  |> Enum.map fn {"a", [{"href", url}, {"title", _}, {"class", "tips"}], _} -> url end
end

Exatamente a mesma lógica, mas a estrutura de pattern matching muda porque os nodes do DOM HTML retornados são diferentes.

Outra diferença é que o MangaReader devolve tudo em texto puro por padrão, enquanto o Mangafox devolve tudo Gzipado independente de eu mandar o header HTTP “Accept-Encoding” (curiosamente, se eu tento várias vezes ele muda de comportamento e às vezes manda texto puro).

O que eu fiz de diferente foi checar se a estrutura %HTTPotion.Response{} retornada tinha o header “Content-Encoding” setado como “gzip” e, se sim, descomprimir usando o pacote “zlib” embutido do Erlang (sem precisar importar nada!):

def gunzip(body, headers) do
  if headers[:"Content-Encoding"] == "gzip" do
    :zlib.gunzip(body)
  else
    body
  end
end

Eu teria preferido que o HTTPotion já fizesse isso pronto pra mim (#OpportunityToContribute!), mas foi fácil o suficiente.

Depois que os testes unitários começaram a passar corretamente, com o scrapper (requisições HTTPotion) e o parser (seletores Floki) ajustados, chegou a hora de fazer meu Worker reconhecer a existência desse novo conjunto de módulos.

O módulo Workflow só chama o Worker, que por sua vez faz o trabalho pesado de buscar páginas e baixar imagens. O Worker chamava o módulo MangaReader diretamente, assim:

defmodule PoolManagement.Worker do
  use GenServer
  use ExMangaDownloadr.MangaReader
  require Logger
  ...
  def chapter_page(chapter_link) do
    Task.async fn -> 
      :poolboy.transaction :worker_pool, fn(server) ->
        GenServer.call(server, {:chapter_page, chapter_link}, @timeout_ms)
      end, @transaction_timeout_ms
    end
  end
  ...
  def handle_call({:chapter_page, chapter_link}, _from, state) do
    {:reply, ChapterPages.pages(chapter_link), state}
  end
  ...
end

Aquele “use ExMangaDownloadr.MangaReader” lá em cima é só uma macro que cria os aliases para os módulos correspondentes:

defmodule ExMangaDownloadr.MangaReader do
  defmacro __using__(_opts) do
    quote do
      alias ExMangaDownloadr.MangaReader.IndexPage
      alias ExMangaDownloadr.MangaReader.ChapterPage
      alias ExMangaDownloadr.MangaReader.Page
    end
  end
end

Então quando eu chamo “ChapterPages.pages(chapter_link)” é um atalho pra usar o nome qualificado completo do módulo, tipo: “ExMangaDownloadr.MangaReader.ChapterPages.pages(chapter_link)”.

Um namespace de módulo Elixir é só um Atom. Nomes de módulos aninhados têm o nome completo separado por pontos, prefixado com seu pai. Por exemplo:

defmodule Foo do
  defmodule Bar do
    defmodule Xyz do
       def teste do
       end
    end
  end
end

Você pode chamar “Foo.Bar.Xyz.teste()” e pronto. Mas tem uma pequena pegadinha. O Elixir também prefixa transparentemente o nome completo do módulo com “Elixir”. Então na real, o nome completo do módulo é “Elixir.Foo.Bar.Xyz”, pra garantir que nenhum módulo Elixir conflite com algum módulo Erlang existente.

Isso é importante por causa dessa nova função que eu adicionei primeiro no módulo Worker:

def manga_source(source, module) do
  case source do
    "mangareader" -> String.to_atom("Elixir.ExMangaDownloadr.MangaReader.#{module}")
    "mangafox"    -> String.to_atom("Elixir.ExMangaDownloadr.Mangafox.#{module}")
  end
end

É assim que eu mapeio de “mangafox” pro novo namespace “ExMangaDownloadr.Mangafox.”. E por causa da natureza dinâmica e baseada em troca de mensagens do Elixir, eu consigo trocar esse código:

def handle_call({:chapter_page, chapter_link}, _from, state) do
  {:reply, ChapterPages.pages(chapter_link), state}
end

Por esse:

def handle_call({:chapter_page, chapter_link, source}, _from, state) do
  links = source
    |> manga_source("ChapterPage")
    |> apply(:pages, [chapter_link])
  {:reply, links, state}
end

Agora eu posso escolher entre os módulos “Elixir.ExMangaDownloadr.Mangafox.ChapterPage” ou “Elixir.ExMangaDownloadr.MangaReader.ChapterPage”, chamar a função pages/1 e mandar o mesmo argumento de antes. Só preciso garantir que consigo receber a string “source” pela linha de comando agora, então mudo o módulo CLI assim:

defp parse_args(args) do
  parse = OptionParser.parse(args,
    switches: [name: :string, url: :string, directory: :string, source: :string],
    aliases: [n: :name, u: :url, d: :directory, s: :source]
  )
  case parse do
    {[name: manga_name, url: url, directory: directory, source: source], _, _} -> process(manga_name, url, directory, source)
    {[name: manga_name, directory: directory], _, _} -> process(manga_name, directory)
    {_, _, _ } -> process(:help)
  end
end

Comparado com a versão anterior eu só adicionei o argumento string “:source” no OptionParser e passei o valor capturado para process/4. Eu deveria adicionar alguma validação aqui para evitar strings diferentes de “mangareader” ou “mangafox”, mas vou deixar isso pra outro momento.

E no módulo Workflow, em vez de começar só com a URL do mangá, agora preciso começar com a URL e a fonte do mangá:

[url, source]
  |> Workflow.chapters
  |> Workflow.pages
  |> Workflow.images_sources

O que significa que cada uma dessas funções precisa não só retornar a nova lista de URLs como também passar a source adiante:

def chapters([url, source]) do
  {:ok, _manga_title, chapter_list} = source
    |> Worker.manga_source("IndexPage")
    |> apply(:chapters, [url])
  [chapter_list, source]
end

Essa era a única função do módulo Workflow hardcoded pro MangaReader, então eu também a deixei dinâmica usando a mesma função manga_source/2 do Worker, e repare que o valor de retorno é “[chapter_list, source]” em vez de só “chapter_list”.

E agora eu finalmente posso testar com “mix test” e criar o novo binário executável de linha de comando com “mix escript.build” e rodar a nova versão assim:

./ex_manga_downloadr -n onepunch -u http://mangafox.me/manga/onepunch_man/ -d /tmp/onepunch -s mangafox

O site do Mangafox é bem instável com várias conexões concorrentes e dá timeout rapidinho às vezes, cuspindo erros feios assim:

15:58:46.637 [error] Task #PID<0.2367.0> started from #PID<0.124.0> terminating
** (stop) exited in: GenServer.call(#PID<0.90.0>, {:page_download_image, {"http://z.mfcdn.net/store/manga/11362/TBD-053.2/compressed/h006.jpg", "Onepunch-Man 53.2: 53rd Punch [Fighting Spirit] (2) at MangaFox.me-h006.jpg"}, "/tmp/onepunch"}, 1000000)
    ** (EXIT) an exception was raised:
        ** (HTTPotion.HTTPError) connection_closing
            (httpotion) lib/httpotion.ex:209: HTTPotion.handle_response/1

Ainda não descobri como fazer retry de requisições HTTPotion direito. Mas uma coisinha que eu fiz foi adicionar um check de disponibilidade no módulo Worker. Assim você pode simplesmente rodar o mesmo comando de novo e ele vai retomar baixando só os arquivos que faltam:

defp download_image({image_src, image_filename}, directory) do
  filename = "#{directory}/#{image_filename}"
  if File.exists?(filename) do
    Logger.debug("Image #{filename} already downloaded, skipping.")
    {:ok, image_src, filename}
  else
    Logger.debug("Downloading image #{image_src} to #{filename}")
    case HTTPotion.get(image_src,
      [headers: ["User-Agent": @user_agent], timeout: @http_timeout]) do
      %HTTPotion.Response{ body: body, headers: _headers, status_code: 200 } ->
        File.write!(filename, body)
        {:ok, image_src, filename}
      _ ->
        {:err, image_src}
    end
  end
end

Isso pelo menos reduz retrabalho. Outra coisa que ainda estou trabalhando é nesse outro pedaço da função principal “CLI.process”:

defp process(manga_name, url, directory, source) do
  File.mkdir_p!(directory)
  dump_file = "#{directory}/images_list.dump"
  images_list = if File.exists?(dump_file) do
                  :erlang.binary_to_term(File.read(dump_file))
                else
                  list = [url, source]
                    |> Workflow.chapters
                    |> Workflow.pages
                    |> Workflow.images_sources
                  File.write(dump_file, :erlang.term_to_binary(list))
                  list
                end
  images_list
    |> Workflow.process_downloads(directory)
    |> Workflow.optimize_images
    |> Workflow.compile_pdfs(manga_name)
    |> finish_process
end

Como dá pra ver, a ideia é serializar os links finais das URLs das imagens num arquivo usando o serializador embutido “:erlang.binary_to_term/1” e checar se esse arquivo de dump existe, e desserializar com “:erlang.term_to_binary/1” antes de buscar todas as páginas de novo. Agora o processo pode retomar direto da função process_downloads/2.

O Mangafox é terrivelmente instável e eu vou precisar descobrir uma forma melhor de fazer retry de conexões que deram timeout, sem precisar quebrar e reiniciar manualmente da linha de comando. Ou é um site ruim ou um site esperto que derruba scrappers como o meu, embora eu chute que seja só infraestrutura ruim do lado deles.

Se eu reduzo de 50 processos para 5 no pool, parece que ele consegue lidar melhor (mas o processo fica mais lento, claro):

    pool_options = [
      name: {:local, :worker_pool},
      worker_module: PoolManagement.Worker,
      size: 5,
      max_overflow: 0
    ]

Se você ver erros de timeout, mude esse parâmetro. O MangaReader ainda aguenta 50 ou mais de concorrência.

E agora você sabe como adicionar suporte pra mais fontes de mangá. Fique à vontade pra mandar um Pull Request! :-)

Como exercício (e também porque, obviamente, sou um Otaku) eu implementei um scrapper simples em Elixir para o ótimo site MangaReader. Dá pra discutir se é certo fazer scrap do site deles, e dá pra discutir também se eles oferecerem esses mangás é certo em primeiro lugar, então vamos deixar essa discussão de lado.

Eu tinha uma versão mais antiga escrita em Ruby. Ela ainda funciona, mas precisa muito de uma boa refatoração (desculpem por isso). O propósito daquela versão era ver se eu conseguia fazer fetch paralelo e retry de conexões usando Typhoeus.

Conforme fui evoluindo nos meus estudos de Elixir, essa ferramenta pareceu uma ótima candidata para testar meu conhecimento atual da plataforma. Ela me obrigaria a testar:

1. Fetch e parse de conteúdo ad hoc via HTTP (HTTPotion e Floki).
2. Testar downloads paralelos/assíncronos (módulo Task embutido no Elixir).
3. O suporte embutido para linha de comando e option parser.
4. Testes básicos via ExUnit e mock do workflow (Mock).

O exercício foi muito interessante, e um scrapper também é candidato ideal para TDD. Os passos iniciais tinham que ser assim:

1. Fazer parse da página principal do mangá para pegar todos os links dos capítulos.
2. Fazer parse de cada página de capítulo para pegar todas as páginas individuais.
3. Fazer parse de cada página para extrair a imagem principal embutida (a página real do mangá).

Para cada um desses passos iniciais eu fiz um teste unitário simples e os módulos IndexPage, ChapterPage e Page. Eles têm mais ou menos a mesma estrutura, este é um exemplo:

defmodule ExMangaDownloadr.MangaReader.IndexPage do
  def chapters(manga_root_url) do
    case HTTPotion.get(manga_root_url, [timeout: 30_000]) do
      %HTTPotion.Response{ body: body, headers: _headers, status_code: 200 } ->
        {:ok, fetch_manga_title(body), fetch_chapters(body) }
      _ ->
        {:err, "not found"}
    end
  end

  defp fetch_manga_title(html) do
    Floki.find(html, "#mangaproperties h1")
    |> Enum.map(fn {"h1", [], [title]} -> title end)
    |> Enum.at(0)
  end

  defp fetch_chapters(html) do
    Floki.find(html, "#listing a")
    |> Enum.map fn {"a", [{"href", url}], _} -> url end
  end
end

Aqui eu já estou exercitando algumas das features mais legais do Elixir, como pattern matching no resultado da função HTTPotion.get/2 para extrair o body do record que retorna.

Depois eu passo o body do HTML para 2 funções diferentes: fetch_manga_title e fetch_chapters. As duas usam o pacote Floki, que aceita seletores CSS para retornar uma List. Aí eu preciso percorrer essa lista (usando Enum.map/2 por exemplo) e fazer pattern match nela para extrair os valores que preciso.

Pattern Matching é um dos conceitos mais importantes para aprender em Elixir/Erlang. É diferente de simplesmente atribuir um valor a uma variável: dá pra usar para desmontar uma estrutura nos seus componentes e pegar as partes individuais.

Daí eu fui montar o esqueleto da interface de linha de comando. Isso já é explicado em outros tutoriais como este e este, então não vou perder tempo explicando de novo. No núcleo eu precisava do seguinte workflow:

1. Partindo da URL principal do mangá no MangaReader, extrair os capítulos
2. Depois loopar pelos capítulos e pegar todas as páginas
3. Depois loopar pelas páginas e pegar todos os sources de imagem
4. Depois loopar pelas imagens e baixar todas para um diretório temporário
5. Depois ordenar os arquivos no diretório e movê-los para subdiretórios de 250 imagens cada (acho um bom tamanho para cada volume)
6. Por fim, redimensionar e converter todas as imagens de cada subdiretório em um arquivo PDF para o meu Kindle consumir.

Esse workflow é definido assim:

defp process(manga_name, url, directory) do
  File.mkdir_p!(directory)

  url
    |> Workflow.chapters
    |> Workflow.pages
    |> Workflow.images_sources
    |> Workflow.process_downloads(directory)
    |> Workflow.optimize_images
    |> Workflow.compile_pdfs(manga_name)
    |> finish_process
end

Esse é um lugar onde a notação de pipeline do Elixir realmente brilha. Fica muito melhor do que ter que escrever este equivalente:

Workflow.compile_pdfs(Workflow.optimize_images(directory))

Essa notação é só açúcar sintático onde o valor de retorno do statement anterior é usado como primeiro argumento da função seguinte. Combine isso com outros açúcares sintáticos como parênteses opcionais (assim como o amado Ruby) e você tem uma exposição clara de “transformar uma URL em PDFs compilados”.

Separei o Workflow no seu próprio módulo e cada passo é bem parecido, cada um pegando uma lista e percorrendo ela. Este é o mais simples deles:

def pages(chapter_list) do
  chapter_list
    |> Enum.map(&(Task.async(fn -> ChapterPage.pages(&1) end)))
    |> Enum.map(&(Task.await(&1, @http_timeout)))
    |> Enum.reduce([], fn {:ok, list}, acc -> acc ++ list end)
end

Se você é novo em Elixir, aqui vai encontrar outra esquisitice, esse "&(x(&1))", que é só um macro de atalho para este outro statement equivalente:

Enum.map(fn (list) ->
  Task.async(fn ->
    ChapterPage.pages(list)
  end)
end)

Enum é um dos módulos mais úteis que você precisa dominar. Se você vem de Ruby vai se sentir em casa, e tem que aprender todas as funções dele. Você normalmente vai estar transformando uma coleção em outra, então é importante estudar a fundo.

Alguns problemas para entender o processamento HTTP paralelo (W.I.P.)

Aí tem esse lance de Task.async/await. Se você vem de uma linguagem que tem Threads, é bem parecido: você inicia várias Threads diferentes e espera todas retornarem antes de continuar. Mas uma Task em Elixir não é uma thread real, é uma “green thread” ou, no jargão de Erlang, um “process” bem leve. Erlang usa processes para tudo, e Elixir também. Por baixo dos panos, o módulo “Task” encapsula todo o framework OTP de supervisors/workers. Mas em vez de ter que lidar agora com OTP GenServer decidi ir pelo caminho mais simples por enquanto, e o módulo “Task” cumpre essa função.

Daí, acabei caindo num problema. Se eu continuasse assim, disparando centenas de chamadas HTTP assíncronas, rapidamente caía nessa exception:

17:10:55.882 [error] Task #PID<0.2217.0> started from #PID<0.69.0> terminating
** (HTTPotion.HTTPError) req_timedout
    (httpotion) lib/httpotion.ex:209: HTTPotion.handle_response/1
    (ex_manga_downloadr) lib/ex_manga_downloadr/mangareader/page.ex:6: ExMangaDownloadr.MangaReader.Page.image/1
    (elixir) lib/task/supervised.ex:74: Task.Supervised.do_apply/2
    (elixir) lib/task/supervised.ex:19: Task.Supervised.async/3
    (stdlib) proc_lib.erl:240: :proc_lib.init_p_do_apply/3
Function: #Function<12.106612505/0 in ExMangaDownloadr.Workflow.images_sources/1>
    Args: []

Por isso existe o @maximum_fetches 80 no topo do módulo Workflow, junto com essa outra construção esquisita:

def images_sources(pages_list) do
  pages_list
    |> chunk(@maximum_fetches)
    |> Enum.reduce([], fn pages_chunk, acc ->
      result = pages_chunk
        |> Enum.map(&(Task.async(fn -> Page.image(&1) end)))
        |> Enum.map(&(Task.await(&1, @http_timeout)))
        |> Enum.map(fn {:ok, image} -> image end)
      acc ++ result
    end)
end

Isso pega uma lista enorme (como todas as páginas de um mangá bem longo tipo Naruto), quebra em listas menores de 80 elementos e aí dispara as Tasks assíncronas, reduzindo os resultados de volta para uma List simples. A função privada chunk/2 só pega o menor tamanho entre o comprimento da lista e o valor máximo de fetches.

Às vezes quebra se o máximo é maior, às vezes não, então meu chute é que meu código não está lidando com instabilidades de rede (com alguma lógica de retry) ou então o site MangaReader está enfileirando acima do meu timeout designado (que setei para 30 segundos). De qualquer forma, manter o valor máximo abaixo de 100 parece ser um bom equilíbrio sem derrubar o workflow.

Essa é uma parte que ainda não tenho certeza do que fazer para lidar com incertezas no site externo não respondendo ou a rede caindo por um tempinho. HTTPotion tem suporte para chamadas assíncronas, mas eu não sei qual a diferença entre usar isso ou só fazer chamadas síncronas dentro de processes paralelos com Task, do jeito que estou fazendo. E em qualquer dos casos, eles são supervised workers, como lidar com as exceptions, como implementar lógica para tentar de novo quando falha? Se alguém tem mais conhecimento sobre isso, um comentário aí embaixo seria bem apreciado.

Por fim, tem um truque sujo por trás do motivo pelo qual eu gosto de usar o MangaReader: ele é bem amigável a scrappers porque em cada página do mangá a imagem é anotada com um atributo “alt” no formato “[nome do mangá] [número do capítulo] - [número da página]”. Então só tive que reformatar um pouco, adicionando um pad de zeros antes do número do capítulo e da página para que um sort simples dos arquivos baixados me dê a ordem correta. MangaFox não é tão amigável. Assim que reformato:

defp normalize_metadata(image_src, image_alt) do
  extension      = String.split(image_src, ".") |> Enum.at(-1)
  list           = String.split(image_alt)      |> Enum.reverse
  title_name     = Enum.slice(list, 4, Enum.count(list) - 1) |> Enum.join(" ")
  chapter_number = Enum.at(list, 3) |> String.rjust(5, ?0)
  page_number    = Enum.at(list, 0) |> String.rjust(5, ?0)
  {image_src, "#{title_name} #{chapter_number} - Page #{page_number}.#{extension}"}
end

Uma vez que tenho todas as imagens, disparo outro processo externo usando Porcelain para fazer shell out e rodar as ferramentas Mogrify e Convert do ImageMagick para redimensionar todas as imagens para 600x800 pixels (resolução do Kindle Voyage) e empacotá-las num arquivo PDF. O resultado são arquivos PDF com 250 páginas e cerca de 20Mb. Agora é só copiar os arquivos para o meu Kindle via USB.

O código do ImageMagick é bem chato, eu só gero os comandos no seguinte formato para o Mogrify:

"mogrify -resize #{@image_dimensions} #{directory}/*.jpg"

E compilo os PDFs com este outro comando:

"convert #{volume_directory}/*.jpg #{volume_file}"

(Aliás, repare na interpolação de strings ao estilo Ruby a que estamos acostumados.)

Tecnicamente eu poderia copiar os arquivos do módulo MangaReader para um novo módulo MangaFox e reaproveitar a mesma lógica de Workflow uma vez que tweaksse os parsers para lidar com o formato de página do MangaFox. Mas deixo isso como exercício para o leitor.

Os testes do módulo MangaReader fazem chamadas reais ao site deles. Deixei assim de propósito porque se o teste falhar significa que mudaram o formato do site e o parser precisa de ajuste para se adaptar. Mas depois de alguns anos eu nunca vi eles mudarem o suficiente para quebrar o meu velho parser em Ruby.

Só como exercício final eu importei o pacote Mock, para controlar como algumas peças internas da implementação do Workflow retornam. Chama-se Mock mas é mais como stub de funções específicas de um módulo. Posso declarar um bloco onde sobrescrevo o File.rename/1 para que ele realmente não tente mover um arquivo que não existe no ambiente de testes. Isso deixa o teste mais frágil porque depende de uma implementação específica, o que nunca é bom, mas quando estamos lidando com I/O externo, pode ser a única opção para isolar. Foi assim que o teste do Workflow foi feito. De novo, se houver um jeito melhor estou ansioso para aprender, por favor comente aí embaixo.

Assim fica um teste unitário com Mock, fazendo stub dos módulos HTTPotion e File:

test "workflow tries to download the images" do
  with_mock HTTPotion, [get: fn(_url, _options) -> %HTTPotion.Response{ body: nil, headers: nil, status_code: 200 } end] do
    with_mock File, [write!: fn(_filename, _body) -> nil end] do
      assert Workflow.process_downloads([{"http://src_foo", "filename_foo"}], "/tmp") == [{:ok, "http://src_foo", "/tmp/filename_foo"}]
      assert called HTTPotion.get("http://src_foo", [timeout: 30_000])
      assert called File.write!("/tmp/filename_foo", nil)
    end
  end
end

Conclusão

Tem sido uma experiência muito divertida, ainda que muito curta, e boa o suficiente para colocar em prática o que aprendi até agora. Código como este me faz sorrir:

[destination_file|_rest] = String.split(file, "/") |> Enum.reverse

A forma como posso fazer pattern match para extrair o head de uma lista é uma maneira diferente de pensar. Daí tem a outra forma de pensar mais importante: tudo é uma cadeia de transformação, uma aplicação é uma forma de partir de algum argumento de entrada (como uma URL) e ir passo a passo “transformando” ele em uma coleção de arquivos PDF, por exemplo.

Em vez de pensar em como arquitetar classes e objetos, começamos a pensar em quais são os argumentos iniciais e qual o resultado que quero atingir, e vamos daí, uma pequena função de transformação por vez.

O módulo Workflow é um exemplo. Eu na verdade comecei escrevendo tudo numa única função grande no módulo CLI. Aí refatorei em funções menores e encadeei elas para criar o Workflow. Por fim, só movi todas as funções para o módulo Workflow e chamei a partir do módulo CLI.

Por causa da ausência de estado global, pensar em funções pequenas e isoladas, tanto refatorar quanto fazer test-driven development ficam muito mais suaves do que em linguagens OOP. Esse jeito de pensar é, admito, lento de pegar o jeito, mas depois começa a parecer muito natural e rapidamente direciona a sua forma de programar para um código mais enxuto.

E os aspectos dinâmicos tanto de Erlang quanto de Elixir me fazem sentir em casa, como se fosse um “Ruby melhorado”.

O código do downloader está todo no Github, podem fazer fork.

Estou ansioso para exercitar mais. Espero que isso motive você a aprender Elixir. E se você já é um programador avançado em Elixir ou Erlang, não esqueça de comentar aí embaixo e até mandar um Pull Request para melhorar este pequeno exercício. Ainda sou iniciante e tem muito espaço para aprender mais. Todas as contribuições são muito apreciadas.

Quem acompanha o blog faz tempo sabe que curto muito mangas/animes (me perguntem qualquer coisa, especialmente se for das décadas de 60 a 90). 4 anos atrás eu fiz um downloader para o antigo site OneManga (que fechou).

Recentemente resolvi adquirir um Kindle Paperwhite (que aliás, é excepcional, principalmente se comparado ao último Kindle 2 que eu tive). E além de tudo é o formato perfeito para mangas (que são preto-e-branco por natureza).

Procurei ferramentas e achei vários horríveis, pra Windows. Então, por que não desenferrujar um pouco e fazer um pacote completo que baixa sua coleção completa de mangas e já gera um PDF otimizado pro tamanho do Kindle?

Aproveitei pra abusar um pouco do Typhoeus que usa a libcurl por baixo e permite fazer downloads paralelos. A única coisa que vai limitar o processo é a velocidade de banda do seu provedor de internet.

Sem enrolar mais, o código-fonte está no Github ou instale diretamente a gem:

gem install manga-downloadr

E para usar, navegue no site do MangaReader.net escolha o manga que quiser e faça assim:

manga-downloadr -n monster -u http://www.mangareader.net/99/monster.html -d /Users/akitaonrails/Documents/MangaReader

E pronto! Se acontecer alguma interrupção (a internet cair ou coisa parecida) só execute novamente o mesmo comando e ele vai continuar de onde parou. Boa diversão!

PS: Não preciso dizer que não funciona em Windows ;-)