O app Fomento Público foi pensar a partir de um workshop do Sebrae que eu fui no dia 12 de dezembro de 2019. E, pra ser sincero, até o momento eu não sabia o que o termo significava.

Quando vi o PDF que o Sebrae iria disponibilizar periodicamente uma relação dos editais, pensei em fazer um app para treinar o que tinha aprendido (Ah, eu coloquei como metas de 2019 aprender a programar e correr uma maratona. Estou escrevendo uma série explicando as aventuras :D)

A principal motivação de ter escolhido desenvolver esse app, foi porque o mesmo é super simples (momento babaca: em janeiro de 2019, eu não teria ideia como fazê-lo. Kekekekekke)

Como em 2010, montei uma empresa para desenvolver apps. Aprendi, do pior jeito possível, o que NÃO se dever fazer.

Aplicando o conhecimento que adquiri de gerenciamento de projetos, depois de definir a ideia básica do que o app deveria ter, defini o que NÃO deveria. E somente features não essenciais.

TER:

  1. UX em primeiro lugar.
  2. Usar componentes nativos.
  3. Funcionar offline.
  4. Favoritar os editais.
  5. Compartilhar os editais.

NÃO TER:

  1. Bugs. Parece obvio, e na verdade é :] Mas foi necessário criar todo um ambiente e protocolos para que esses bichinhos não surjam, e caso apareçam, dê para resolver rapidamente.

FEATURES NÃO ESSENCIAIS:

  1. Atualização em background: eu sempre desligava essa função dos apps, até que estudando na documentação do iOS, aprendi que o iOS gerencia as atualizações, escolhendo o melhor momento para tal.

Feito os objetivos macros, comecei a quebrar me pacotes menores, e usar nomes mais apropriados. Esse assunto está na série “Um Designer Aprendendo a Programar” que lançarei em 2020. Para não ficar um post TD; TL, vai um resumo.

  1. Conteúdo: após organizá-los, criei uma API que me fornecia um JSON.
  2. Layout: desenho das telas, usando componentes nativos e prototipação. Um recurso impressionante que me ajudou bastante foi poder usar o JSON citado para desenhar as telas, porque já me permitia ver como os dados iriam ficar. Me economizou horas de recodificação.
  3. Codificação: usando ambiente e métodos que me “obrigavam” ter um mínimo de qualidade no código. O que fiquei mais impressionado foi o lint ( no caso, swiftlint). Você cria regras para a escrita do código, tanto para manter o aspecto visual quando para evitar más prática de codificação. Outro recurso fundamental é o pipeline Continuous Integration / Continuous Deployment ou CD / CI. Resumidamente, o programador usa o git para gerenciar as versões, enviar o código escrito pro servidor e pede para alguém aprová-lo. Automaticamente, testes são feitos para garantir que o novo código não esteja quebrando o app e caso aprovado, é gerando, também automaticamente, versões do app, que pode ser para equipe interna, para beta testers ou mesmo entregar para as lojas de apps. Repito: tudo automaticamente.

Vou parar por aqui, o post, porque realmente, descobri que programar é um excelente e divertido hobby. Um quebra-cabeça que realmente faz a cabeça doer :]

Artigo anteriorO que leva ao hábito ou vício?!?
Próximo artigoSete em cada dez projetos de inteligência artificial em empresas falham, diz estudo