Novos posts no endereço fbeppler.com

Novos posts estão sendo publicados no endereço fbeppler.com.

Reflexo do coronavirus nas publicações de notícias

O volume de notícias publicadas sobre o coronavirus ajuda a mostrar o impacto que ele está causando no mundo. De algumas centenas de notícias publicadas em poucos veículos nos últimos meses de 2019 para milhões de notícias escritas por jornalistas e blogueiros de todo mundo nesse mês.

O gráfico abaixo mostra a quantidade de notícias coletadas pela Knewin com o termo coronavirus desde novembro de 2019. Em um período de 5 meses, como se pode ver, o crescimento foi exponencial, atingindo, até o momento, quase 8 milhões de notícias em março/2020.

Notícias que mencionam coronavirus coletas pela Knewin

O volume de menções em programas de rádios e TVs também seguiu o padrão de crescimento bem alto. Esse volume será superior a meio milhão até o final desse mês. A menção ao coronavirus está em todos os programas jornalísticos de qualquer emissora de rádio ou TV.

Números de menções ao coronavirus em veículos de rádio e TV monitorados pela Knewin

A análise de popularidade do Google sobre buscas com o termo coronavirus também seguiu comportamento similar. O gráfico abaixo mostra pouco interesse pelos usuários do Google no início de 2020. Todavia, há uma forte mudança no final de fevereiro/2020, e pico agora em março (o valor 100 significa o máximo de popularidade de um termo).

Popularidade do termo coronavirus nas buscas do Google

Ao olhar apenas o Brasil, a análise das buscas no Google também apresenta comportamento similar quando se trata do coronavirus, conforme gráfico abaixo. E os cinco termos mais frequentes buscados pelos brasileiros são: brasil coronavirus, coronavirus no brasil, corona vírus, casos coronavirus, virus coronavirus.

Popularidade do termo coronavirus nas buscas do Google Brasil

O artigo publicado no New York Times no dia 13/03/2020 sobre as pesquisas do Network Science Institute, mostra que o comportamento das pessoas que usam as mídias também estão sendo incorporados aos estudos que visam antecipar tendências de doenças infecciosas.

O que chama atenção no artigo do New York Times é a influência dessas análises para órgãos de saúde. Os pesquisadores tentam descobrir padrões a partir da análise dos conteúdos de diferentes tipos de mídia associados com outros dados (ex., dados demográficos, transporte/deslocamento, etc.) para recomendar, por exemplo, quando faz sentido fechar escolas ou empresas. 

Os conteúdos publicados nas diferentes mídias influenciam todos os seus autores. Notícias formais publicadas em veículos de mídia tradicional influenciam os usuários de redes sociais e escritores de blogs e esses, por sua vez, acabam influenciando os jornalistas da mídia tradicional. 

O reflexo é o aumento veloz na criação e consumo de conteúdo sobre o tema da vez. Tomara, no entanto, que o tema coronavirus vá embora de forma tão ou mais rápida do que quando chegou. Vamos torcer para que as curvas desses gráficos caiam com muita rapidez, pois assim saberemos que essa pandemia virou notícia antiga.

Novas postagens no endereço fbeppler.com.

O desafio ao escolher uma tecnologia para desenvolver um software

Escolher as tecnologias para construir um software requer cuidado e critério uma vez que há muitas opções disponíveis. Estamos vivendo o período de maior abundância tecnológica que já existiu. Há vários tipos de linguagens de programação, frameworks, APIs, bibliotecas (i.e., libraries), serviços e outras tantas opções de tecnologias de fácil acesso. Decidir quais escolher é um desafio sobretudo quando se quer criar um produto que pode durar por vários anos.

As decisões para criar um software são afetadas por diferentes fatores. A plataforma onde o software irá executar (ex., Windows, MacOS, Linux, iOS, Android, etc.) impõe algumas restrições além de regras formais que precisam ser seguidas. As tecnologias conhecidas pela equipe técnica se tornam, naturalmente, uma forte opção de escolha. Além disso, se leva em conta, muitas vezes, as tecnologias que estão em evidência no momento ou aquelas que já aparecem como promissoras para o futuro.

Há alguns anos, a decisão em escolher o sistema operacional para um novo software era mais simples: Windows, MacOS ou Linux. Hoje, sabe-se de antemão que um novo software, muito provavelmente, terá que funcionar em mais de uma plataforma — tanto em computador (ex., Windows, MacOS, Linux, etc.) quanto em smartphones e tablets (ex., iOS, Android, etc.). Na web não é diferente; um software tem que funcionar, no mínimo, no Google Chrome, Safari, Mozilla Firefox e Microsoft Edge — e muitos ainda precisam contemplar o velho Internet Explorer.

Também há outras variáveis que devem ser levadas em conta, como a dependência e o custo de profissionais que saibam programar ou operar as tecnologias escolhidas. Essa questão pode não parecer preocupante na fase inicial, especialmente porque se pensa em escolher uma tecnologia atual ou já muito bem conhecida pela equipe. No entanto, as pessoas da área de tecnologia, em sua maioria, gostam de trabalhar com algo novo, moderno, atual.

Ou seja, deve-se fazer um exercício quanto à oferta de profissionais para o futuro. Um olhar mais a longo prazo pode ajudar: haverá profissionais que terão interesse nas respectivas tecnologias daqui a 5 ou 10 anos? Como tecnologias similares criadas há 5 ou 10 anos estão hoje? Há ainda oferta e demanda para profissionais de tais tecnologias?

Passamos, na Knewin, por uma situação complicada há dois anos quando tivemos que buscar profissionais para manter um software que veio junto com uma empresa adquirida. O software foi criado com tecnologias que já haviam sido abandonadas. Levamos mais de três meses para encontrar um profissional e até hoje ainda estamos migrando partes antigas daquele produto para tecnologias mais modernas.

Esse tipo de problema sempre existiu e sempre existirá em se tratando de desenvolvimento de software — o bug do milênio, pouco antes do ano 2000, teve uma demanda absurda por profissionais que sabiam programar na linguagem Cobol. O desafio é minimizá-lo.

Outra variável que muitas vezes passa despercebida é a fase do negócio ou do produto. Se o objetivo é testar rapidamente uma ideia deve-se escolher tecnologias que sejam fáceis e rápidas de se desenvolver — gerar protótipos em poucos dias (senão em horas). Valida-se uma ideia e, novamente, deve-se verificar se faz sentido continuar com as tecnologias já usadas ou se faz sentido buscar alternativas. O peso das variáveis, no entanto, vai mudando com a evolução, uso e validação do produto.

Os requisitos funcionais e não funcionais de um software devem ser os guias para suportar as decisões quanto às escolhas iniciais ou mudanças de suas tecnologias. O ideal é que tais tecnologias permitam a evolução gradual e contínua de um produto com o passar dos anos.

A regra que usamos na Knewin é escolher, sempre que possível, tecnologias  estáveis e mais robustas. Por exemplo, é preferível escolher uma linguagem de programação que já esteja no mercado por anos, que esteja sendo usada por grandes empresas mundo afora e que tenha potencial de evoluir pelos próximos anos do que escolher uma nova linguagem que não se sabe ao certo sobre o seu futuro — o grau de aposta aumenta ou diminui dependendo da escolha. 

Nós fazemos essa reflexão para cada nova função a ser codificada e não apenas para a escolha das tecnologias iniciais de um produto. Faz sentido, por exemplo, usar uma biblioteca (i.e., library) para programar uma nova função? Quais são os prós e contras em ter uma nova biblioteca como mais uma dependência em um produto? O tempo para desenvolver a função será mais curto? A função terá mais qualidade, segurança e robustez? 

A análise crítica se torna ainda mais desafiadora com a abundância de frameworks, bibliotecas e APIs que nascem a cada novo dia. O bom senso ainda faz parte desse processo de escolha.

Temos, na Knewin, tecnologias que escolhemos há alguns anos para funções específicas e que hoje se tornaram um problema. O custo para remove-las ou substitui-las ainda não fez sentido — será mais caro troca-las do que ainda mantê-las. Teremos que conviver com elas por mais algum tempo. Estudar as escolhas do passado e o reflexo no presente é fundamental para se tomar as decisões para o futuro.

Um exercício simples e, no mínimo, curioso é analisar os frameworks Javascript para se desenvolver aplicações Web que foram criados pela comunidade open source. Ao se buscar aqueles que estiveram na moda há 5 anos, por exemplo, já se vê vários projetos abandonados, sem nem mesmo qualquer ação recente dos próprios criadores. Olha o tamanho do problema para uma empresa que escolheu um desses frameworks? O seu produto está totalmente dependente de uma tecnologia que não é mais evoluída nem mesmo pelos seus criadores.

Há, também, os casos onde uma tecnologia precisa ser substituída por não atender a evolução no uso de um produto. Diferentes variáveis podem obrigar a isso como, por exemplo, lentidão devido ao aumento no número de usuários ou no volume de dados a serem manipulados. Passamos por isso na Knewin algumas vezes, como quando a tecnologia para processamento distribuído se tornou muito cara para nos atender. Enfim, esse é o tipo de cenário que pode gerar ainda mais transtornos se não for devidamente antecipado e muito bem planejado — substituir uma tecnologia tende a ser mais complicado e mais caro do que fazer algo novo.

Construir um software ainda é uma atividade complexa. Há muitas variáveis que precisam ser cuidadosamente pensadas. As tecnologias usadas podem ter grande impacto no sucesso de um produto assim como podem ser a sua ruína. O grau de incerteza precisa ser reduzido e para isso as decisões devem ser baseadas em uma visão holística, com critérios técnicos, econômicos e de negócio muito bem pensados. De todo modo, qualquer escolha que seja feita ainda não deixa de ser uma aposta.

Novas postagens no endereço fbeppler.com.

Como desenvolvemos software na Knewin

Desenvolver software é uma atividade artesanal e difícil. O desafio é transformar uma ideia em código. É preciso várias etapas para se ter clareza sobre o que se deve ser desenvolvido. Até mesmo uma nova função pode requerer muitas interações. Aumenta-se a chance de se obter o que realmente se precisa ao validar e aprender com cada passo.

Talvez o maior impacto na construção de um software seja o jeito como ele é construído. São inúmeras decisões que precisam ser tomadas em vários níveis, desde conceituais (ex., qual é o problema que precisa ser resolvido) até detalhes mínimos (ex., tipo da coluna de uma tabela no banco de dados). Há milhares de livros e muitas técnicas amplamente divulgadas sobre como criar um software. Precisa-se, assim, definir um método que se encaixe no perfil de uma empresa.

Na Knewin, usamos, no início, o método ágil chamado Scrum. Definíamos um ou mais objetivos a serem desenvolvidos a cada quinze dias. A equipe discutia cada objetivo e definia a lista de tarefas, seus responsáveis e o tempo estimado para desenvolver cada uma delas. Havia reuniões diárias, de 15 minutos, para discutir   o que estava indo bem e o que não estava. Tudo ficava registrado em um software específico para Scrum.

Com o tempo, notamos que o método não estava funcionando para nós. As decisões em uma startup são tomadas com mais velocidade porque há muita coisa ainda sendo definida. Há demandas básicas dos clientes que ainda estão sendo entendidas, o mercado está sendo descoberto, clientes maiores geram demandas mais urgentes, questões operacionais impactam o planejado e assim por diante. Ademais, a nossa equipe era pequena e tinha que dar conta de várias coisas ao mesmo tempo.

Muita coisa que era urgente não podia esperar. O fato é que a demanda urgente, e outras nem tão urgente assim, muitas vezes ganhavam prioridade em vez das tarefas planejadas. A equipe ficava ansiosa com as reuniões finais de cada quinzena porque várias tarefas ainda estavam por fazer.

Tivemos que buscar um método diferente, que estivesse mais alinhado com a dinâmica da Knewin. Adotamos, então, algumas práticas do método Kanban. Esse método é mais flexível e nos permitiu organizar as demandas urgentes com as demandas planejadas. Ainda havia a reunião de planejamento e a revisão sobre as tarefas concluídas, mas a reunião diária foi trocada por interações pontuais entre as pessoas sempre que fosse preciso.

A grande diferença ocorreu quando passamos a planejar a semana. As tarefas precisavam ser resolvidas em cinco dias e isso nos forçou a ser mais críticos nas escolhas. Além disso, ficou mais fácil negociar demandas urgentes para serem atacadas na semana seguinte. As equipes, em especial comercial e relacionamento com o cliente, entenderam esse ritual e, com isso, foi possível dar mais foco nas tarefas planejadas.

Os objetivos da semana eram definidos a partir de OKRs (Objective and Key Results). OKR é um método que ajuda a definir e medir com mais precisão o quanto de um objetivo foi alcançado. Um exemplo de objetivo poderia ser: Ampliar a cobertura de coleta de jornais online. Já um exemplo de key result seria: Adicionar 5.000 novos jornais por semana (adicionar apenas 2.500 jornais por semana significa apenas 50% concluído).

Começamos com OKRs de três meses e depois de algum tempo mudamos para OKRs mensais — alterarmos porque não funcionou um intervalo muito grande para uma equipe pequena que também era responsável por tarefas do dia a dia. Cada OKR era definido com base no planejamento estratégico, que descrevia as diretivas do que precisávamos alcançar no ano. Com isso, as tarefas planejadas na semana estavam de acordo com as metas do ano e podiam ser medidas pelos key results dos OKRs.

As principais tarefas da semana vinham dos OKRs, mas ainda tínhamos que planejar as demandas urgentes e demandas pontuais de clientes. Na reunião de planejamento da semana todas essas tarefas eram discutidas e priorizadas em conjunto. Assim, cada desenvolvedor sabia o que precisava ser feito e podia melhor se organizar para dar vazão às suas tarefas — menos interrupção e, consequentemente, mais produtividade.

Todos da equipe sabiam o que cada um estava fazendo. As tarefas também eram mais bem delimitadas e, normalmente, seguia um ritmo de evolução contínua. Além disso, as tarefas dos OKRs seguia uma evolução de produto e isso nos permitia definir cada passo com mais facilidade — é uma vantagem de uma empresa de produto. A meta era chegar ao final da semana com as tarefas concluídas e já sendo usadas pelos clientes — passos menores mas constantes.

Também tínhamos mais rapidez para intervir caso algo não saísse do jeito que prevíamos. Mesmo se a tarefa levasse a semana toda, ainda assim, era apenas uma semana. Esse tipo de situação acabava ocorrendo cada vez menos à medida que mais conhecíamos as necessidades dos nossos clientes.

Tivemos vários benefícios em usar algumas práticas do Kanban para o nosso dia a dia no desenvolvimento das aplicações. O planejamento semanal gerou menos interrupção para a equipe ao passo que as atividades urgentes também puderam ser encaixadas, pelo menos a grande maioria delas, na semana.

Nossa equipe também conseguiu organizar as interações e validações com mais frequência, principalmente com os clientes. Com a definição de tarefas menores e o conceito de evolução contínua conseguimos acertar mais quanto às necessidades dos nossos clientes para novas funções assim como nas melhorias das funções existentes.

Enfim, o nosso método de desenvolvimento de software usa práticas do Scrun e Kanban — para nós não fez sentido usarmos esses métodos com todos os seus detalhes e minúcias. Nós escolhemos as práticas que vimos mais valor dado o nosso jeito de atuar. Fizemos vários ajustes durante esses anos da Knewin e ainda hoje sabemos que haverá outras tantas mudanças. Além disso, novas pessoas e papeis entram na equipe o outras ideias são discutidas e questionadas com frequência. 

Temos hoje algumas equipes de diferentes produtos e cada uma delas têm suas regras e práticas próprias. Há equipes que fazem uma reunião diária de 15 minutos, por exemplo, e há equipes que planejam apenas a semana e se falam quando é preciso. O resultado é medido pelas entregas e a aderência ao que foi planejado.

Contudo, novas práticas no desenvolvimento de software estão sendo inseridas de modo transversal às nossas equipes. O mínimo é garantir que tenhamos qualidade no código, alarmes devidamente configurados, revisões contínuas, documentação clara e objetiva, automação para atividades rotineiras, interação entre as equipes e alinhamento com OKRs e as metas anuais.

Também temos muita preocupação com a visão de longo prazo. Planejar a semana mesmo com OKRs e metas anuais não elimina o risco de focar no urgente e operacional e esquecer o importante. Por isso, discutimos as tarefas a luz do que queremos para o futuro. Planejar a semana exige uma visão crítica que consiga compreender a urgência, as demandas específicas, os desejos, inovações e o futuro. 

A experiência de anos atuando com o desenvolvimento de software e sempre estudando os métodos de como melhor desenvolver software têm nos ajudado a obter melhores resultados em nossas entregas. A evolução incremental e contínua com interação constante com os clientes, talvez, tenha sido o maior impacto nessa atividade que ainda é artesanal e bem complexa. O importante é aprender e melhorar sempre.

Novas postagens no endereço fbeppler.com.

Sistemas no ar o tempo todo

Um sistema na internet tem que estar no ar o tempo todo. Ele precisa estar acessível em qualquer horário do dia e da noite. Nós, como usuários, não cogitamos qualquer outra opção. Do outro lado, de quem desenvolve, manter um software no ar sem falhas é uma tarefa bem difícil, praticamente impossível.

Desenvolver software é uma atividade complexa. O desafio começa antes de qualquer criação de código. As regras precisam ser definidas com a visão do que o software deverá fazer. Todas as regras devem estar claras e precisam ser codificadas com precisão. Um software gera erro ou não funciona direito se uma regra for mal definida ou mal codificada. Os mínimos detalhes podem afetar o comportamento do software. É como uma equação matemática, se trocar um sinal ou um simples algarismo, o resultado é outro.

Diversos métodos foram criados para ajudar a desenvolver um software. Há métodos que ajudam a melhor entender as regras para construir um software, outros são focados em como desenvolver, em como codificar. Há métodos ágeis e outros com bastante detalhes e inúmeras etapas. Todos eles visam ajudar a transformar uma ideia em algo concreto, com a máxima exatidão.

Um software precisa ser testado para garantir que cada regra tenha sido codificada corretamente. Existem softwares para testarem outros softwares. Há equipes ou até mesmo empresas próprias focadas apenas em testar softwares. Eles validam cada regra. Simulam o uso esperado e usos não esperados para cada função. Testam até mesmo se o software consegue aguentar o acesso de vários usuários ao mesmo tempo.

Situações inesperadas, mas, obviamente, pensadas de antemão, podem ser planejadas com medidas alternativas. Em caso de uma falha no software ou computador principal, por exemplo, um software alternativo ou outro computador pode ser usado. Até diferentes provedores de internet podem ser usados caso algum falhe.

Contudo, ainda assim, um software pode falhar, ou não ficar disponível. Pode ser uma falha no seu próprio código ou pode ser uma falha em outros softwares de que ele depende. Pode haver falha por que um banco de dados gerou uma inconsistência, o sistema operacional travou, um arquivo corrompeu. Pode, também, haver falha no computador ou nos equipamentos que ligam o computador à internet. Há muitas camadas de hardware e software que podem gerar alguma falha.

Se já sabemos que um software poderá falhar mesmo com planos alternativos, o que podemos fazer então?

Pois é, enfrentamos essa dúvida no início da Knewin. Vários dos nossos clientes usavam os sistemas principalmente durante a madrugada. Os sistemas precisavam funcionar sem falhas 24 horas por dia, de segunda a segunda. Durante o dia nós monitorávamos os sistemas, olhando gráficos e analisando os arquivos de logs (informações que descrevem qualquer anormalidade em um software). O problema era durante à noite e nos finais de semana.

Em algumas situações fomos acordados por clientes no meio da noite nos avisando que havia problema em algum sistema. Uma situação bem desagradável para o cliente e para nós também. E, para piorar, o tempo de resolução podia não ser tão rápido, pois ainda tínhamos que identificar onde estava o problema para, então, resolver. Dez ou quinze minutos para um sistema fora do ar na internet é muito tempo.

A solução foi criarmos um sistema de vigilância, também chamado de sistema de monitoramento, que disparasse alarmes. Esse sistema, chamado Sentinela, monitorava nossos outros sistemas — aqueles que não podiam falhar de jeito nenhum. Em caso de qualquer falha o Sentinela nos enviava um alarme.

Os tipos de falhas eram os mais diversos possíveis, desde algum erro no código até falhas no acesso à internet. Definimos a importância de cada falha e o respectivo tipo de alarme. Se uma falha fosse pequena, como um erro momentâneo, o Sentinela nos enviava apenas um e-mail de alerta. Caso a falha fosse grande, o Sentinela também enviava uma mensagem SMS para nossos celulares. Assim, éramos avisados durante dia e noite, de segunda à segunda.

Percebemos, também, que vários problemas podiam ser antecipados e, portanto, resolvidos antes de falhar. Com isso, conseguíamos prever algumas falhas com mais de uma hora de antecedência. Por exemplo, o Sentinela extraía algumas estatísticas das notícias capturadas com base no histórico e nos enviava um alarme se notasse alguma variação no volume de coleta.

Há casos em que o Sentinela também resolvia o problema por conta própria. Em algumas situações, ele identificava que algo falhou ou iria falhar e sabia o que fazer para corrigir. Um computador na cloud, por exemplo, que apresentava alguma instabilidade podia ser trocado automaticamente por outro computador sem qualquer intervenção nossa ou percepção dos clientes.

Os sistemas também tiverem que ser mudados, para que pudessem ser monitorados. Isso foi um desafio, pois o Sentinela tinha que ficar em um computador separado e ao mesmo tempo precisava testar funções de cada sistema que, inicialmente, não eram acessíveis por computadores externos. Essa separação era condição para que o Sentinela fizesse vários tipos de testes como, por exemplo, verificar se o acesso à internet estava funcionando e se as funções estavam respondendo com rapidez.

Os sistemas também tiverem que ser mudados, para que pudessem ser monitorados. Isso foi um desafio, pois o Sentinela tinha que ficar em um computador separado e ao mesmo tempo precisava testar funções de cada sistema que, inicialmente, não eram acessíveis por computadores externos. Essa separação era condição para que o Sentinela fizesse vários tipos de testes como, por exemplo, verificar se o acesso à internet estava funcionando e se as funções estavam respondendo com rapidez.

Cada nova função a ser codificada nos sistemas passava por uma análise nossa e, se fizesse sentido, a função era monitorada pelo Sentinela. Uma das regras era bem simples: uma função deveria ser integrada ao Sentinela se houvesse risco dos clientes serem afetados enquanto estivessem usando o sistema. Definimos várias outras regras que foram evoluindo com o tempo.

A criação do Sentinela nos impactou de várias formas. Temos mais tranquilidade uma vez que se houver um problema em algum dos nossos sistemas seremos avisados. Os sistemas ficaram mais estáveis por que passamos a resolver a causa de cada falha — melhoria contínua. A equipe técnica adquiriu a disciplina de analisar cada alarme e tomar ações mais estruturadas com casos ainda não monitorados. As novas funções críticas já são integradas ao Sentinela ainda na fase de construção.

Hoje, também usamos outros sistemas de vigilância além do Sentinela. A nuvem, onde hospedamos nossas aplicações, nos permite monitorar falhas na infraestrutura (i.e., computadores e acesso à internet). Temos, também, um sistema de terceiro, chamado Zabix, que usamos para falhas genéricas. Criamos inúmeros alarmes para centenas de cenários.

O próximo passo é tornar o Sentinela mais autônomo. Com inteligência artificial iremos identificar, com mais antecedência, se uma falha poderá ocorrer ao se analisar todos os passos de cada função. Ao se deparar com um problema, ele conseguirá resolve-lo com total autonomia. E vamos além, ele poderá nos indicar o que fazer para resolver a causa de um problema — um software precisa evoluir sempre.

O fato de termos entendido que um software pode falhar nos permitiu olhar a situação por ângulos diferentes. A criação do Sentinela foi uma solução criativa e inteligente que possibilitou reduzir o impacto das falhas em nossos softwares. A qualidade e confiança dos nossos sistemas melhorou muito com o uso dessa solução. Nossa equipe técnica desenvolveu atitudes mais pró-ativas quanto às falhas e reforçou a disciplina para melhorar sempre.

Nós temos que garantir nossos sistemas no ar o tempo todo. Os clientes são beneficiados assim como nós mesmos, na Knewin. Nos sentimos mais seguros e tranquilos ao saber que alarmes podem disparar em casos atípicos. Todavia, nosso objetivo é termos cada vez menos alarmes disparados — a busca pela perfeição é contínua.

Ah, também temos alarme para o Sentinela.

Novas postagens no endereço fbeppler.com.

Como fazer buscas em mais de um bilhão de notícias

Imagine o desafio de encontrar apenas notícias do seu interesse analisando mais de um bilhão delas? Adicione, então, mais um milhão a cada novo dia. E, para completar, você precisa encontra-las e menos de um segundo. Esse é o cenário que temos na Knewin hoje.

Quando decidimos trabalhar com coleta de notícias nós já sabíamos que precisávamos captura-las e disponibiliza-las para nossos clientes tão logo fossem publicadas. Afinal, notícia é algo que precisa ser lida agora. Mesmo assim, nossos clientes ainda precisam ter acesso às notícias antigas para construir certos tipos de relatórios ou gerar análises históricas. Saber o que foi publicado no passado sobre uma marca ou produto, por exemplo, pode ajudar a definir ações para o presente e futuro.

Montar essa base de notícias levou anos. Além de ter sido trabalhoso, também é complexo. A maioria dos sistemas que criamos vieram de ideias lidas em artigos científicos. Com o tempo e a prática, evoluímos nossos sistemas para ter maior eficiência. Hoje, cinco etapas são executadas para ter uma notícia disponível para os clientes em nossos sistemas: coleta, estruturação, enriquecimento, armazenamento e indexação.

A etapa de coleta das notícias ocorre por meio de um crawler (ou robô) que navega nas páginas dos sites. O crawler analisa cada página e verifica se o principal conteúdo dela é de uma notícia. Se a página não contém uma notícia, o crawler apenas extrai os links da página e a descarta na sequência. Já, se há uma notícia, ele envia a página para a próxima etapa (mais detalhes sobre nosso crawler em Como coletar milhões de notícias online).

A segunda etapa, de estruturação, analisa o código da página e extrai os dados que fazem parte da notícia. Os principais dados são: o título, a data, o autor, o texto completo e as imagens. Extrai-se, ainda, para alguns veículos, outros dados como, por exemplo, a seção do veículo, a categoria da notícia, e assim por diante.

Há muitos desafios para extrair os dados de uma notícia. Em nosso caso, esse desafio é maior por que temos que lidar com milhares de sites diferentes. As páginas desses veículos contêm vários tipos de conteúdo, além dos dados da própria notícia, como links para outras notícias, assuntos e categorias, botões para compartilhar em redes sociais; também apresentam anúncios (i.e., publicidade) ao redor ou, até mesmo, no meio do texto da notícia.

Nós criamos diversos códigos específicos para extrair cada tipo de dado de uma notícia. No entanto, nem sempre é possível extrair esses dados com precisão, pois há sites que misturam outros conteúdos aos dados da notícia. Tivemos, então, que criar regras para remover esses ruídos, como palavras que não fazem parte da notícia e caracteres inválidos. Por exemplo, se no título de uma notícia também há o nome do veículo — isso é comum em sites menores — nós temos que removê-lo do título. O principal objetivo é ter os dados exatos da notícia.

Na sequência, inicia-se a terceira etapa: o enriquecimento. Essa etapa agrega dados de outras fontes de informação à notícia. Esses dados extras tornam uma notícia mais valiosa e, também, permitem que ela seja encontrada com mais facilidade. Um exemplo é o local do veículo, que permitirá a notícia ser achada quando se busca por notícias de uma região.

A quarta etapa é simples e direta: a notícia é armazenada. O maior desafio é usar uma tecnologia que seja rápida e consiga gerir muitos dados. No início, usamos um banco de dados tradicional principalmente por que não havia outra opção que nos desse garantia que as notícias ficariam armazenadas corretamente. Com o tempo, o banco de dados foi ficando lento por causa do volume de notícias capturadas todos os dias. Tivemos que buscar outra tecnologia.

Escolhemos uma tecnologia No-SQL disponível na cloud onde pudemos armazenar notícias com espaço ilimitado. Ela é rápida tanto para guardar as notícias quanto para acessa-las; e não fica lenta com o tempo. Além disso, o seu custo é proporcional ao uso, ou seja, paga-se pelo que se consome.

Entretanto, essa tecnologia não consegue fazer buscas dentro dos dados de uma notícia por meio de palavras-chaves (ex., buscar notícias da Petrobras). A busca por palavras-chaves é o jeito mais simples de pesquisar assuntos em documentos com texto — é assim que pesquisamos no Google. É por isso que as notícias precisam ser indexadas. A indexação, quinta etapa, organiza os dados (i.e., título, autor, etc.) das notícias em índices, que são, simplesmente, listas ordenadas de palavras — mesma ideia do índice de um livro. É, portanto, mais fácil e rápido achar um assunto em uma lista ordenada de palavras, também para o computador.

Quando se deseja ter uma função de busca textual, o maior desafio é definir como os os dados dos índices são organizados. As mesmas regras usadas nas palavras de um índice também precisam ser usadas nas palavras-chaves das consultas. Por exemplo, se utilizar as regras de que as palavras no índice estejam em minúscula e sem acentuação, essas mesmas regras têm que ser usadas nas palavras-chaves das consultas — senão, as notícias não serão achadas. Por isso, o índice tem que ter regras claras e já deve prever como os documentos serão buscados.

Se um índice tiver dados parciais ou incorretos significa ter que refazê-lo. O mesmo ocorre se qualquer regra de montagem do índice for alterada. Ao construir um índice precisa-se pensar, também, no seu uso futuro. Imagine um índice com dez milhões de notícias. De repente os clientes querem buscar apenas por notícias em inglês. Se o idioma de cada notícia não estiver no índice, será preciso re-definir a sua estrutura e montar um novo índice — pegar os dados de cada uma das dez milho˜es de notícias, mais o idioma, e inserir cada uma no novo índice. É uma tarefa trabalhosa, lenta e cara. Nós enfrentamos algumas situações como esta à medida que evoluímos nossos sistemas.

A velocidade para localizar palavras no índice também é impactada pela variedade de conteúdo. O índice nada mais é do que uma lista de palavras não repetidas que estão ordenadas. Quanto maior é o número de palavras diferentes maior é o tamanho dessa lista e, naturalmente, maior será o tempo para localizar uma palavra — é mais rápido encontrar uma palavra em uma lista com 1.000 itens do que em uma lista com 1.000.000 de itens.

A variedade das palavras em notícias é enorme por que elas descrevem muitos assuntos diferentes. Além disso, sempre há novas palavras, novos nomes, gírias, termos de outros idiomas e assim por diante. A lista de palavras do índice cresce todos os dias. Com o tempo, essa lista se torna tão longa que até mesmo grandes computadores podem não conseguir responder com rapidez.

Foi o cenário que enfrentamos.

Nessa época, as soluções tecnológicas que permitiam distribuir um índice em vários computadores — para dividir o trabalho entre eles — ainda não eram confiáveis. Por isso, tivemos que ser criativos e criar uma solução própria. Observamos como os clientes estavam consumindo as notícias no dia a dia e também a dinâmica dos sites ao publicar as suas notícias. 

A conclusão foi muito simples: as notícias mais usadas pelos clientes eram as mais novas. Criamos, então, índices menores, em mais de um computador, com regras claras sobre onde indexar uma notícia. As notícias novas ficam em índices menores que são usados para responder a maior parte das consultas. Ficou mais rápido localizar as palavras-chaves nesses índices e os computadores não precisam ser tão grandes — custo reduzido e ganho de tempo para o cliente.

Com o fim da etapa de indexação, as notícias estão prontas para serem buscadas. Assim, os clientes já podem localizar as notícias. Eles acessam o nosso sistema de busca e digitam as palavras que descrevem os seus interesses (ex., aquecimento global). O sistema de busca, então, acessa os índices, e aplica as mesmas regras usadas na indexação nas palavras-chaves pesquisadas pelos clientes. Dessa forma, o sistema de busca consegue localizar as notícias com as respectivas palavras-chaves.

As consultas dos clientes, em sua maioria, contêm poucas palavras — a média é em torno três. Para muitos assuntos, algumas palavras-chaves são suficientes para achar notícias corretas. Há, no entanto, outros interesses onde é preciso usar várias palavras-chaves tanto para restringir quanto para ampliar o que se deseja buscar. Para esses casos mais complexos o uso simples de palavras não é suficiente.

Os sistemas de buscas, normalmente, permitem que se combine palavras com conectores que ligam uma palavra a outra. Esses conectores são chamados de operadores lógicos. O nosso sistema de busca também tem essa opção e permite o uso dos mesmos operadores que o Google disponibiliza para seus usuários (i.e., AND, OR e NOT).

Esses operadores permitem montar consultas com maior precisão, para restringir ou ampliar uma pesquisa. Por exemplo, com o operador AND pode-se buscar notícias sobre aquecimento global e que também tratem de agricultura (ex., “aquecimento global” AND agricultura). Já com o operador OR, pode-se buscar as notícias do Banco do Brasil e também as notícias do Bradesco em uma mesma consulta (ex., “Banco do Brasil" OR Bradesco). Com o operador NOT, se busca notícias da Amazônia, mas que não tratem de queimadas (ex., Amazônia NOT queimadas). E é possível combinar todos os três operadores em uma única consulta.

Ter a função de busca com o volume de notícias que lidamos todos os dias requer bastante criatividade. Se adicionar uma nova regra, por exemplo, que use mais um segundo antes de indexar uma notícia, isso significa mais 1.000.000 de segundos a serem processados em um dia, pois capturamos esse número de notícias. Ademais, os computadores onde ficam os índices precisam ser usados ao máximo. Nossos sistemas são configurados para usar toda a capacidade do servidor, mas sem sobrecarregá-los.

Desde o início da Knewin usamos um software open source que é específico para indexar e buscar as notícias. O software se chama Lucene e é usado por várias empresas mundo afora. Nós usamos esse software apenas para prover a opção de busca por palavras-chaves no conteúdo das notícias.

Há algum tempo também usamos a tecnologia ElasticSearch. Essa tecnologia faz o mesmo papel do Lucene (i.e., indexar e buscar documentos textuais), mas permite distribuir um índice em vários computadores. A opção de usa-la é que conseguimos responder algumas consultas com mais rapidez e adicionar novos computadores caso aumente a demanda de consultas. A desvantagem é que seu custo pode inviabilizar o seu uso, principalmente quando se tem muitos dados.

Ainda hoje temos as duas tecnologias em nossos sistemas. Com isso, a nossa solução ficou economicamente viável, os sistemas têm mais garantia que estão ativos e as consultas são respondidas com mais rapidez. 

Manipular um bilhão de notícias, responder consultas em menos de um segundo e com um custo adequado exige muita criatividade e conhecimento. Nós sabemos que a solução atual terá que ser evoluída continuamente. O desafio aumenta a cada dia. Afinal, capturamos mais de um milhão de notícias a cada novo dia.

Novas postagens no endereço fbeppler.com.

Como coletar milhões de notícias online

Milhões de notícias são publicadas na internet todos os dias. Elas estão disponíveis em diferentes sites e em vários idiomas. Elas também precisam ser acessadas tão logo se tornem públicas devido à sua característica de expressar algo novo. Ter fácil acesso a elas em um único local facilita o trabalho de quem as usa no dia a dia. Captura-las, no entanto, requer o uso de tecnologia, de um tipo que saiba visitar sites, saltando de uma página para outra. Esse tipo de software é chamado de crawler, mas também é conhecido como robô. É ele quem caminha pelos links que vai encontrando à medida que navega na internet.

Um crawler foi o primeiro sistema que desenvolvemos quando fundamos a Knewin, em 2011. A sua primeira versão só coletava notícias de alguns sites. E cada site precisava ser configurado manualmente. Era necessário definir regras para ele navegar nos sites e entender quando havia encontrado uma notícia. Também era preciso codificar passo-a-passo de como extrair os dados de uma notícia — seu título, o autor, a data de publicação, o seu conteúdo, etc.

Tínhamos que utilizar infraestrutura que coubesse em nosso orçamento enxuto. Como startup, os recursos precisavam ser utilizados a sua exaustão. Um crawler demanda vasto poderio computacional, por isso tivemos que ser criativos ao desenvolver cada função. Usar o mínimo de memória, evitar sobrecarga nos processadores, controlar o consumo de banda da internet, armazenar apenas dados essenciais são alguns exemplos.

Além disso, o crawler precisava capturar uma notícia assim que ela era publicada. E encontrar novas notícias demandava acessar os sites com frequência. Havia o risco de ser bloqueado pelos administradores dos sites por que tínhamos que fazer requisições o tempo todo. Para minimizar esse risco, o crawler navegava em paralelo em vários sites, garantindo intervalos irregulares nos acessos aos sites.

O crawler foi hospedado em um ambiente de cloud computing, porém ele ainda não usava características desse tipo de ambiente (ex., escalabilidade, elasticidade, etc.). Como coletávamos notícias de poucos sites, não fazia sentido investir o nosso tempo para adaptar o crawler às funcionalidades da cloud — em uma startup o tempo dos empreendedores é o recurso mais significativo. Todavia, nos beneficiamos por hospedar na cloud quando precisamos escalar a solução.

Diversos problemas foram aparecendo à medida que fomos adicionando novos sites ao crawler. Tivemos uma situação onde um site permitia navegar nas suas páginas por meio de um calendário. Bastava selecionar um dia qualquer no calendário e o site apresentava a lista de notícias daquele dia. Foi exatamente assim que configuramos o crawler para capturar as suas notícias. No entanto, o crawler se caracteriza por navegar exaustivamente nas páginas de um site, entrando em cada link que ele encontra. No calendário do site não havia limite para anos futuros e não tínhamos configurado uma regra específica para isso. Quando o crawler entrava nesse site acabava caindo nessa armadilha e ficava tentando encontrar notícias selecionando datas futuras.

Nós sabíamos que o crawler poderia encontrar situações onde não tínhamos definido um comportamento específico e, obviamente, havíamos codificado regras genéricas de controle. No entanto, ainda assim tínhamos ineficiência no uso dos recursos computacionais. O servidor ficava ocupado, havia consumo desnecessário da banda de internet e, consequentemente, maior demora na coleta das notícias. Fomos amadurecendo a tecnologia à medida que situações não previstas foram aparecendo e refinando continuamente os mecanismos do crawler.

Com a adição constante de novos sites ficou claro, alguns meses após essa primeira versão, que o crawler não seria capaz de coletar maior volume de notícias sem gerar lentidão nas coletas (i.e., no máximo 10 minutos após a publicação). O crawler precisava evoluir e a nova solução precisaria ser distribuída, usando o conceito dividir para conquistar. 

O crawler deveria executar em vários servidores, navegando paralelamente nos sites. Para implementar essa nova arquitetura precisávamos de uma tecnologia mais robusta e escalável. A tecnologia na época era o Hadoop, que estava sendo usado por grandes empresas. Hadoop é um framework que permite o processamento distribuído de grandes volumes de dados por meio de vários servidores. Conceitualmente, essa era a tecnologia que estávamos precisando, pois abstrai a comunicação entre os servidores, o que facilita a utilização de uma arquitetura distribuída — a interação entre os servidores é transparente para quem o utiliza.

A parte central do nosso crawler pôde ser aproveitada, o que nos economizou um bom tempo de desenvolvimento. Como já estávamos em um ambiente cloud ficou mais fácil a sua administração, uma vez que iniciar e encerrar servidores consistia apenas em alguns cliques. Tínhamos, contudo, que instalar e configurar o Hadoop manualmente por que naquela época não havia um serviço disponível na cloud. 

Assim, nosso crawler passou de um servidor para cinco servidores; de dezenas de sites sendo coletados em paralelo para centenas. A nossa solução ficou apta a aumentar a quantidade de sites a serem coletados sem gerar lentidão na velocidade da captura das notícias. Conseguíamos adicionar novos servidores à medida em que acrescentávamos mais veículos. A nossa tecnologia passou a ser escalável.

O volume de notícias capturadas crescia consistentemente e centenas de novos sites eram adicionados por semana. O crawler capturava e armazenava as notícias em um banco de dados relacional. Todo fluxo de coleta estava sincronizado e atendendo aos nossos requisitos. Até que em um determinado momento, o desempenho geral começou a degradar e nossos alarmes começaram a disparar. O vilão da vez foi o banco de dados. Ele já não suportava armazenar as notícias com a velocidade esperada. Tivemos, novamente, que intervir e repensar a tecnologia para armazenar as notícias. 

A vantagem de estarmos em um ambiente cloud desde o primeiro dia (reforço esse ponto, pois tivemos inúmeras vantagens quando tomamos essa decisão) nos permitiu evoluir nossos sistemas à medida que novos serviços eram disponibilizados pelo respectivo fornecedor da cloud. A tecnologia NO-SQL ganhava corpo justamente para dar suporte ao conceito de big data, com estrutura computacional capaz de armazenar grandes massas de dados com alta performance. 

Movemos parte das estruturas que estavam no banco de dados relacional para essa base NO-SQL e alteramos o fluxo de processamento do crawler para enviar as notícias capturadas para essa nova estrutura. Com isso, obtivemos maior velocidade para armazenar e recuperar as notícias. Também podíamos usufruir da capacidade ilimitada de armazenamento e pagar apenas por aquilo que estávamos consumindo. Mais um passo de maturidade na arquitetura, maior robustez na solução, maior controle sobre o custo de armazenamento, melhor experiência de uso das nossas ferramentas e mais segurança para os nossos clientes.

Por mais que tivéssemos uma série de vantagens em estarmos na cloud, a conta estava subindo a cada mês. Nossa solução era robusta e escalável, mas a dimensão custo estava impactando nosso orçamento de infraestrutura. A principal causa eram os novos servidores que tínhamos que acrescentar à medida que novas fontes eram adicionadas ao crawler. A necessidade de recorrência em capturar as notícias dos sites, com a pressão de coletarmos as notícias com o mínimo de tempo após a publicação nos forçou, novamente, a repensar a arquitetura ou, pelo menos, parte dela. 

Hadoop ainda estava na crista da onda do big data, mas algumas tecnologias com propósito similares já estavam aparecendo e o principal diferencial consistia em maior leveza — arquiteturas que demandavam menor poder computacional. Naturalmente, inúmeras dúvidas apareciam quando discutíamos uma eventual saída do Hadoop, pois toda a arquitetura do crawler havia sido estabilizada e havíamos definido um procedimento simples e facilmente escalável. O problema é que a conta não parava de subir.

Havia mais de três anos que lidávamos com Hadoop em nosso dia-a-dia e o conhecimento adquirido nesse período nos permitiu entender no detalhe a sua arquitetura. Uma coisa estava clara: apenas servidores de média ou alta configuração para obter bom desempenho. Isso nos limitava em usar servidores menores e mais em conta ou, até mesmo, a combinação de servidores com diferentes configurações. O cenário de coleta e a arquitetura de navegação do crawler nos permitia usar servidores menores, mas estávamos travados por que o Hadoop não se comportava bem. Além disso, tínhamos o cenário em que o volume de matérias publicadas era reduzido em determinados horários e podíamos, assim, reduzir o nosso custo (ex., alguns servidores poderiam ser parados durante à noite). Fomos obrigados a estudar alternativas, inclusive cenários onde tínhamos que implementar toda a distribuição e interação entre os servidores por nossa conta.

Por fim, a arquitetura definida para a nova versão do crawler foi uma mescla de bibliotecas open source e sistemas desenvolvidos por nós. Também utilizamos alguns serviços oferecidos pela infraestrutura de cloud onde hospedamos nossa solução. Saímos de um ambiente com ingerência, onde estávamos tendo pouco controle, para um cenário flexível que nos permitia uma dinâmica de crescimento com custo adequado. Com essa nova arquitetura, implementamos regras para ampliação e redução do poderio computacional de forma a garantir que as variáveis velocidade na coleta, abrangência (i.e., maior volume de sites monitorados) e custo ficassem sintonizadas e previsíveis. 

Tínhamos, então, uma arquitetura de crawler que implementava a elasticidade similar aos ambientes cloud. Automatizamos o acréscimo e redução de servidores em tempo real. Em questão de minutos o mecanismo de decisão do crawler acrescentava ou removia centenas de servidores. A decisão de sairmos de um ambiente “fechado” como o Hadoop para uma arquitetura mais flexível nos permitiu evoluir vários pontos de gargalos na solução.

Hoje, essa arquitetura é muito mais complexa e implementa uma série de novas funcionalidades. As variáveis de abrangência, velocidade e custo ainda são verdades absolutas e têm tanta importância que temos alarmes que disparam em caso de qualquer comportamento anormal. Com o volume de notícias crescendo a cada dia — coletamos mais de um milhão de notícias por dia atualmente — e novas fontes noticiosas sendo adicionadas aos milhares, tivemos que ser criativos nas soluções para os diferentes cenários que fomos nos deparando. 

Não temos apenas um crawler, mas uma plataforma com múltiplas soluções de coleta de notícias que levam em consideração, por exemplo, a natureza da fonte a ser coletada, a frequência com que as notícias são publicadas, os modelos de estruturação de conteúdo, a localização geográfica dos veículos, além de outros tantos requisitos funcionais e não-funcionais. Nossa infraestrutura mescla recursos computacionais hospedados em diferentes fornecedores (cloud e tradicional) além de um conjunto de servidores que ficam em nossa própria infraestrutura. 

Além disso, temos a habilidade de utilizar servidores com “qualquer” sistema operacional, pois desenvolvemos a maioria dos nossos componentes na linguagem Java. Enfim, essa plataforma é o resultado da soma do aprendizado desses anos focados em coletar informações e torna-las acessíveis para os nossos clientes.

Os desafios ainda são inúmeros. Há muito de inteligência que iremos adicionar aos mecanismos de coleta, uma série de automatizações que já temos detalhadamente descritas e outras tantas melhorias que já identificamos — algumas delas estão em andamento. Por exemplo, faremos o uso massivo de inteligência artificial, mais especificamente dos algoritmos de machine learning, em todas as etapas de coleta. 

Com isso, a nossa solução terá maior eficiência ao navegar entre as páginas dos sites e conseguirá estruturar e extrair as informações com maior precisão e velocidade. Também conseguirá melhor aproveitar os recursos computacionais assim como otimizar a troca de dados entre os diversos mecanismos da plataforma. Ademais, o custo total da solução será avaliado a cada segundo e mecanismos inteligentes tomarão decisões em tempo real para garantir o melhor desempenho com o menor custo.

Para nossa sorte, o backlog de inovações a serem desenvolvidas compreende uma lista considerável. Só conseguimos identificar essas “deficiências”, obviamente, por que temos anos de experiência e conhecimentos adquiridos em muitas horas de trabalho. Nós construímos a Knewin reforçando o interesse contínuo em novidades científicas e tecnológicas. Como uma empresa de tecnologia, está em nosso DNA buscar continuamente melhorias e novos desafios. Há muito a inovar e isso é um grande motivador.

Novas postagens no endereço fbeppler.com.