Pra começar, um pouco de contexto:

Nesses meus um pouco mais de 7 anos de experiência tive a oportunidade de experimentar trabalhar com frontend, backend, infraestrutura e cultura devops. Muito da amplitude técnica que adquiri foi depois de entrar na ThoughtWorks. Meus horizontes se abriram. Conheci testes, infraestrutura como código, pensamento de produto, práticas de engenharia, entre outros temas. E assim consegui endereçar um antigo incômodo que era viver no silo sem enxergar o caminho que meus commits faziam até chegar à usuária.

Isso pra dizer que mais que desenvolver, me apaixonei por todos os processos e passos que envolvem entregar software de qualidade em produção.

Faz pouco tempo estou no papel de System Architect em 4 times que entregam aplicações móveis e BFFs. Assim, Mobile é um novo tema pra minha mochila.

Comecei essa jornada exalando minha paixão por ver software de qualidade em produção, ou seja, investigando como é o path to production nesses times (fazendo muitas perguntas às pessoas e também ao Google). Compilo aqui alguns dos aprendizados/choques que tive:

1- Existe um passo de revisão do que está sendo entregue antes de chegar nas lojas que envolve Google e Apple.

Esse ponto apareceu quando investiguei sobre a maturidade em Entrega Contínua nesses times baseada nas 4 Métricas Fundamentais do Accelerate. Aqui meu conhecimento anterior baseado em frontend, backend e infra já bugou, sim essa revisão existe e em iOS ela pode ser mais rigorosa que em Android.

On average, 50% of apps are reviewed in 24 hours and over 90% are reviewed in 48 hours. — https://developer.apple.com/app-store/review/

Tomando iOS como exemplo, se a Apple revisa em média 90% das apps em 48h, isso significa que lead time (tempo do commit até o código estar rodando em produção) já começa alto.

Na busca de entender o motivo dessa revisão encontrei uma explicação que fez todo sentido: as lojas de apps são produtos tanto para Google quanto para Apple e isso significa que ao disponibilizarem uma app de má qualidade ou maliciosa, por exemplo, prejudicam seus produtos e marcas. Antes de entender isso, pensava nas lojas como AWS e GCP, mas, nesses casos, quando um produto web (site) providos por eles é ruim, as usuárias não associam isso à plataforma onde esse site está hospedado.

2- O servidor de produção está se movimentando por aí.

Esse foi um ponto que me fez entender a complexidade do mundo mobile. Eu tenho o privilégio de ter um celular mas nunca tinha visto ele como servidor de produção de apps. Já parou pra pensar quantas marcas e modelos diferentes de aparelhos existem no mundo? Métricas que ajudem a entender de onde vem maior parte do público que consome sua app são fundamentais. Mesmo que sua organização contrate algum device farm e se esforce para abranger o maior número de aparelhos porcentagens é que vão dar a direção; diferente do mundo web em que é possível ter controle para que todos os servidores estejam oferecendo a mesma versão da aplicação.

Bom, vamos a um exemplo: se a gente fizer deploy de um backend SpringBoot num cluster k8s e a aplicação apresentar algum problema com volumetria a gente pode se valer de uma configuração de autoscaling das plataformas de cloud e mais instâncias da aplicação vão nascer, certo? No celular de alguém se o SO estiver precisando de mais memória, a nossa app pode ser fechada sem que a gente nem a usuária peça por isso. E nesse caso não dá pra apelar pro autoscaling e transformar o celular da pessoa em 2 ou 3.

Aliando isso ao ponto 1, um fix de crash ou um fix de otimização de consumo de memória da app pode levar tempo para chegar na mão da usuária e quando chegar ela pode ter bloqueado receber notificações de atualização e não receber a nova versão por nem saber que ela existe. Todo cuidado e carinho com qualidade ganha peso ainda maior a meu ver.

3- Cadência de entrega pode diminuir engajamento.

No mundo web, lançar novas versões em produção mais de uma vez ao dia pode ser difícil de ver na prática (tanto que times que vivem isso são considerados times de elite no Accelerate) mas é factível. Um refresh no browser e pronto, já estamos usando a versão nova do front e/ou da API.

No cenário mobile, já pensou em ter mais de um alerta/pedido de atualização de algum dos seus aplicativos no celular? Certamente vc acharia estranho e no pior dos cenários iria desinstalar essa app, não?! Eu iria.

Isso significa que pode ser ruim pra organização ter vários releases acontecendo. Aprendi que a maior parte das usuárias aceitou que sua loja de apps faça atualizações automáticas das apps mas ainda assim é um ponto importante pro engajamento ter uma cadência de entregas. Segundo uma enquete feita no Twitter por Gergely Orosz a cadência mais usada é de 2 semanas.

Aqui ainda to estudando mas do que entendi até agora é possível desassociar deployment e release, ou seja, escolho de quanto em quanto tempo disponibilizo pra usuária uma nova versão mas tenho disponíveis várias versões geradas e aprovadas nos reviews. Isso me parece positivo já que estaremos melhor posicionadas para atender necessidades de negócio ou solucionar crashes do que quando deixamos para o final das 2 semanas para percorrer todo o caminho de build, testes e afins.

4- Modularização: monolito distribuído.

Ponto polêmico. A expressão monolito distribuído me lembro de ter lido no Team Topologies mas resumindo meu entendimento, quando a separação de domínios e responsabilidades numa arquitetura está ruim acabamos por criar times separados possivelmente trabalhando com repositórios distintos mas que em termos de geração de artefato executável dependem fortemente um do outro. Assim, a ideia de que se está construindo software numa arquitetura de microserviçoes é questionável se no momento de deploy todos ou alguns deles precisam se juntar.

A meu ver isso acontece com o mundo mobile. Em um exemplo: se pensamos em redução de carga cognitiva e delimitação de domínios num cenário de app complexa e contruímos um time para trabalhar com um módulo de menu (talvez isso seja granular demais mas releva por ora). Esse módulo vai ser disponibilizado num repositório de artefatos e vai ser referenciado dentro da superapp. Quando uma nova versão do menu é gerada, obrigatoriamente esse time vai precisar atualizar a referência ao módulo na superapp e esperar que o próximo release da app seja feito para ter seu novo menu na mão das usuárias.

As vezes se fala que modularização em mobile é similar a microfrontends mas a meu ver não é bem assim já que deploy independente é a chave para esse estilo arquitetural.

Bom, por ora é isso. Veja que minha expectativa não é estressar nenhum tema nem me comprometer com os pontos de vista, ou seja, são visões pessoais, dados contexto e conhecimentos atuais, e estou disposta a discordar de mim mesma a qualquer momento.

Links interessantes:

• Modularization - Why you should care
• 10 Engineering Challenges Due to the Nature of Mobile Applications
• Use Four Keys metrics like change failure rate to measure your DevOps performance | Google Cloud Blog

No último sábado, 11/04, aconteceu o NiteroiJS no auditório do NAB na UFF. Foi um evento top, maneiro, incrível e tudo mais que a galera postou por aí. Mas eu senti a necessidade de dizer um pouco mais sobre tudo.
Chegar lá às 9 horas e 30 minutos em um sábado pra galera que vive no mundo de TI já era um desafio e tanto. //geralmente, esses seres têm hábitos noturnos e acordar às 9 é pedir demais :P
Quando eu cheguei já não haviam mais camisetas… // ☹
mas haviam adesivos diversos, todos maneiríssimos chamando atenção pro adesivo do NiteroiJS com o nosso ilustríssimo disco voador.

A primeira palestra foi da Simone [@s1mone] http://s1mone.net/blog/2015/04/sobre-html-e-robos/
A palestra foi demais! Ela mostrou uma retrospectiva com a evolução da WEB e a gente pôde ver como crises trouxeram grandes avanços no modo como tudo funciona. Os vários buscadores ou catálogos tem formas/algoritmos diferentes para indexar as páginas. Isso não é legal do ponto de vista de semântica por ter várias metatags com o mesmo conteúdo, como por exemplo o título. Mas nós desenvolvedores precisamos estar atentos a isso de acordo com o público alvo do projeto. O uso das tags vai impactar diretamente na experiência do usuário que por sua vez não tem culpa da guerra das redes sociais. Vale notar que grande parte do público que antes vinha dos buscadores hoje vem das redes sociais.

A segunda palestra foi do Vitor Leal [@vitorleal] https://speakerdeck.com/vitorleal/javascript-no-mundo-da-internet-das-coisas. Confesso que quando li o tema, JavaScript no mundo da Internet das Coisas, no site do evento não me situei. Acho que foi por não conhecer o termo Internet das coisas. Faz todo sentido esse termo! Hoje em dia, tá tudo conectado ou é possível conectar todas as coisas.
Fiquei fascinada com tudo o que ele falou: a forma como valoriza a inovação, a simplicidade que transpareceu ser a utilização dos kits e a colaboração com os projetos… Ver projetos nesse sentido na Internet me fazia achar que estavam longe de nós. O Vitor mostrou que o teste com o projeto das smart cities está em funcionamento há mais de um ano. É possível implantar e colaborar com esse tipo de projeto. Aí vc pensa mas eu só faço isso por hobbie, é bobagem! Não, não é! Confia! Dá pra melhorar o mundo com a sua ideia!

A terceira palestra foi do André Garzia [@soapdog]. O cara é demais! Se entregassem o microfone pra ele às 9h da manhã acho que ele ficaria o dia todo falando sem problema algum e sem precisar de slides. Ele é muito carismático.
Ele falou sobre aplicativos que não são aplicativos. // parece mas não é. hahaha
Mostrou o uso do simulador do FirefoxOS // *-* é lindo!

com um aplicativo de bloco de notas feito por ele mesmo usando HTML5, CSS e JS. Vimos a possibilidade de portar o app pra qualquer plataforma através do Firefox por conta de uma simples página de install em HTML.
O André nos contou que a Mozilla é uma fundação e não uma empresa. Seu objetivo não é arrecadar dinheiro e sim apoiar a WEB aberta, permitindo que todos tenham acesso à WEB.
Por fim ele convidou para um projeto envolvendo lan houses e tranmissão de conhecimento que parece fantástico. // tô aguardando ansiosamente o e-mail dele com mais informações chegar

A quarta palestra foi do Ed.. Léo Beto [@leobetosouza]. // hu3hu3hu3
O Léo falou sobre algumas novidades que estão na ES6. Achei legal quando ele disse que os devs querem sempre o que não tem. Eu mesma nem sei usar as features da ES5 e já tô querendo a ES6. Coloquei na minha lista de afazeres estudar ES5 e ES6. Não sabe do que eu tô falando?! Inclui esses itens na sua lista também! // :D
Todos os exemplos que ele mostrou pareceram bonitos. Os nomes eu achei um pouco confusos. Preciso estudar sobre pra opinar melhor.

A quinta palestra foi do Raphael Amorim [@raphamundi]. Ele falou sobre canvas. // Eu adoro canvas. *-*
O canvas é um retângulo bitmap. Sabe quando vc abre o paint, pega o lápis e faz o seu nome? Então, vc pode fazer isso no navegador usando canvas e javascript.
O Raphael mostrou alguns exemplos e fez outros que mostraram que o canvas é poderoso. Pra brincar é preciso ter conhecimento básico de matemática e física mas nada assutador. Dá pra acompanhar tutoriais e entender o que tá acontecendo pra aplicar no seu projeto. Inclusive há uma lista de links úteis, exemplos e afins criada pelo Rapha no github pra ajudar vc. Confere lá https://github.com/raphamorim/awesome-canvas

Fora as palestras, deu pra conhecer muuuita gente. Os participantes todos muito simpáticos. Depois do evento, uma galera foi para o Maíz Fast Mex fazendo bagunça no ônibus. rs
Conheci mais gente lá. Consegui entender um pouco mais como funciona a Mozilla e descobri que pra participar da comunidade basta querer. Isso não é fantástico!? Vc não precisa de mais nada, só de vc!

Saia do querer fazer e vá fazer. Talvez alguém te critique mas quem disse que isso é ruim?

Documente tudo que fizer. Isso também é colaborar para a comunidade.

PS: essa é a minha primeira publicação e a iniciativa de criá-la veio dos papos que rolaram lá no evento e no Maíz. Agradecimento especial ao André, ao Luigui e ao Adriano pelo papo e ao Raphael pelos posts motivadores que tem feito.