Dados

Programar é resolver problemas tranformação de dados. A matéria prima da programação é dados, com esse conjunto de dados podemos resolver os problemas. Não existe sofware que não transforme dados em alguma.

Existem diversos tipos de dados, cada um com uma aplicação. A aplicação só vai resolver o problema se tiver esses dados, então importante é saber como coletar esses dados e armazenar o que precisa.

Como posso coletar dados?

• Ação do usuário (interações ou respostas de perguntas)
• Web scrapping (chata)
• APis públicas
• Bancos de informação públicos
• Cookies
• Sensores físicos

Legalmente, existem apenas essas formas de conseguir dados. Então é isso que podemos tranformar. É possível combinar diversas fontes de dados para compor um produto.

Sensores físicos são a única forma de fazer algo sem a necessidade de um humano ao lado, todas as outras transformações precisam de alguem atualizando os dados.

Banco de dados

Como dados são o mais importante em um programa, pode ser necessário os armazenar. Existem uma grande gama de bancos de dados, cada um com uma missão a cumprir, nenhum vai resolver qualquer tipo de problema.

MongoDB (um banco NoSQL) tem um proposito bem diferente de um MySQL ou postgres, foi desenvolvido para corrigir o problema de grandes volumes de dados, principalmente de escrita.

Bancos relacionais são ótimos para ler dados, por outro lado, a velocidade de escrita não é tão boa, já que precisa garantir que o dado realmente está salvo corretamente e que nada se perdeu no caminho. MongoDB por outro lado tem outro uso, massivas quantidades de escrita de dados que não possuem tanta importancia, alguns podem acabar não sendo salvos. Um ótimo uso seria um sensor de batemento cardiaco de um smartwatch, a todo momento está recebendo dados, e precisa os salvar em algum lugar, não é importante se 2 ou 3 batementos forem perdidos no processo.

Existe bancos de dados em memória, são importantes para guardar informações de cache, e devem trabalhar ao lado de bancos relacionais. Cache deve ser a primeira escolha para otimizar qualquer aplicação, caso ainda não exista. Se aplicado, o cache reduz o tempo de resposta, pois já entrega tudo pronto, não faz sentido processar a informação de uma mesma página para 200 usuários diferentes, com isso podemos reduzir o tempo de 200 respostas para o de apenas 1. Esses bancos de dados in memory perdem todos os dados quando é reiniciado, por isso apenas informações não cruciais são armazenadas neles.

Bancos como firebase ou supabase tem um ótimo suporte para assets (arquivos, imagens etc), o que é extremamente útil e uma ótima ferramenta. Transformar imagens ou arquivos também é transformação de dados.

Um banco relacional é ótimo para anotar informações muito importantes, como o registro de uma compra em um e-commerce, você precisa ter certeza que este dado está salvo e não está corrompido.

Mobile

Quando optamos por usar um App ao contrário de um site?

Cerca de 60% dos acessos à websites são feitos por dispositivos mobile. Não consegui informação se frameworks como React Native (que basicamente criam um navegador), acabam contando como Websites. Creio que não, por esses motivos daqui pra frente considere que esses apps NÃO PARTICIPAM DOS 60%.

A preferencia por websites faz sentido, não é necessário download, e na boa parte dos casos, até 3 segundos é o suficiente para a página carregar, o download de um app demora pelo menos 15x esse tempo.

Em contra partida, aplicativos baixados são mais práticos do que usar o navegador. O acesso a eles é muito mais simples e constumam possuir uma melhor interatividade se comparado ao navegador. Por isso, apps mobile devem ser foco quando o usuário precisa de forma rápida as informações nele, quando a práticidade supera a demora do download.

Outro caso é para aplicações que precisam de acesso a mais recursos do dispositivo, como câmera, sensores, armazenamento ou processamento de algo pesado. Nesse caso, não é possível os substituir.

A aplicação precisa, necessáriamente, de uma API para adquirir dados externos, a comunicação com a internet é algo muito importante para a maioria das aplicações.

Performance

É comum ouvirmos que “O desenvolvedor vale mais que memória RAM” e por isso não deveríamos nos importar tanto com a performance, isso é verdade em partes. Por mais que não seja recomendado gastar muito tempo otmizando uma aplicação, essa etapa deve ser feita (preferencialmente após a aplicação funcionar).

Tratando performance como tempo necessário para exibir uma tela com informações úteis ao usuário, esse tempo deve ser o menor possível, já que numa aplicação real, a atenção do usuário sempre está sendo disputada. É por isso que quanto maior for o tempo de resposta, maior é a chance do usuário desistir da aplicação, e com isso, converter menos.

Até 3 segundos para responder é aceitável. Claro, existem casos em que o tempo será maior, mas o usuário deve saber o motivo, por exemplo, upload de uma imagem ou esperando o tratamento da mesma. Adotando que não exista essa justificação, a otmização se torna necessária para aumentar a renda, é neste ponto que a otimização começa.

Otmizações não devem ser feitas por achismo, assim como um diagnóstico médico, precisam de um exame, neste caso, pode ser um serviço que monitora a performance da aplicação. Esses serviços podem até mostrar uma região do código que está lento.

Geralmente os maiores gargalos da aplicação está nos primeiros 3 itens, basta os corrigir que a performance geral da aplicação aumenta significativamente. O elo mais fraco de uma corrente determina sua força. Ao corrigir esses problemas, outros se tornam os 3 primeiros, de pouco em pouco a performance aumenta.

Micro Serviços e API

O que é uma API? Basicamente um intermediador, que valida, estrutura e facilita o uso de um recurso, como banco de dados, armazenamento ou processamento.

Acesso ao banco por múltiplas ferramentas pode acabar sendo problemático, uma solução é colocar uma aplicação para intermediar, dessa forma todos se referenciam à API, o que ainda facilita na implementação. Se o consumo do banco pode ser controlado, ninguem vai ter mais acesso do que o necessário.

O uso de APIs ou não depende do projeto. Um caso pode ser uma parte da aplicação que pode ser isolada e vai acabar sendo acessada por outros serviços.

REST vs GraphQL

O padrão de desenvolvimento de APIs REST é o mais popular, grande partes das APIs o usam. Porem, REST vem com algumas desvantagens, como ser necessário multiplas requisições para montar apenas 1 tela, o que implica em desperdício de informações, já que virão informações inúteis.

Por outro lado, o facebook popularizou o estilo GraphQL, que se baseia em pedirmos o que precisamos. Esse padrão permite escolhermos apenas os campos que vamos precisar, nem mais, nem menos! Isso acaba com o problema do trafego de dados desnecessários e da necessidade de multiplas requisições.

Testes

Facilitam muito a vida dos desenvolvedores, permite que seja mais tranquilo extender e atualizar o projeto.

Caso alguem faça um código porco e acabe quebrando parte do código de outro programador, ao rodar os testes será claro onde o erro está, assim, é fácil saber onde o problema está e quando foi causado.

Existem ferramentas de CI (Continius Integrations) que executam os testes quando um código sobe para um repositório e da informações sobre eles. Basta subir cada parte do código em uma branch diferente e criar um pull request, desta forma, podemos dar merge apenas nas branches em que os testes param, garantindo que tudo que funcionava antes não quebrou.

Subir em branches ainda permitem (em certas plataformas) subir em stading, que da para testar o pull request em “deploy”, isso não é produção, apenas para teste, caso seja útil.

Ainda existem ferramentas de CD (Continius Deployment) dão merge toda vez que passa nos testes automatizados. As vantagens são várias, de pouco em pouco, as novas features vão sendo testadas por usuários, e novos bugs vão sendo reportados.

No assunto de Bugs, os testes por padrão já resolvem grande partes, mas não garantem tudo, novos bugs vão existir. Por isso, quando um novo Bug é reportado, deve-se fazer um teste que replique o bug, e dar como finalizado quando o teste passar, assim garantindo que o bug não se repita. Bugs são problemas, se não levados a sério podem atrasar o desenvolvimento de novas features, o que atrasa o projeto.

Deploy

Fazer deploy ou públicar uma aplicação é muito importante, e não é tão simples quanto parece. Manter uma aplicação funcionando por um longo período de tempo e com boa performance era um desafio, atualmente não é grande problema. A implementação de disponibilidade varia, então não se pode negligenciar essa etapa.

Um bom deploy inclui: disponibilidade, facilidade de adicionar novos códigos, ferramentas para corrigir problemas quando algo dá errado, como o sistema de rollbacks. Isso é o mínimo que deve ser atingido.

Referências

Usei diversas palestras, artigos e pouca experiencia desenvolvendo para formar os textos.

Mobile Data

• explodingtopics
• statista
• oberlo