Uma das maiores dificuldades no desenvolvimento de software é olhar para o código desenvolvido e dizer “Essa solução foi uma das melhores, meu código está muito bom”. Qual o motivo que faz com que as pessoas desenvolvedoras tenham essa sensação?…
Você tem aquele backlog imenso. O P.O. já fez a priorização. Mas na verdade, ele priorizou apenas as features. Quando você olha o kanban mais de perto, percebe que há trocentas stories a serem feitas dentro de cada feature. E aí? Qual você começa primeiro? É sobre isso que vamos falar hoje.
Blockchain é uma tecnologia que surgiu em 2008, e desde então, vem conquistando os holofotes. Com certeza você, que busca conhecimento sobre inovação, já ouviu falar de comércios utilizando a tecnologia blockchain em transações bancárias. O uso mais famoso é de blockchain…
O Code Review (revisão do código) é um item importantíssimo da engenharia de software, mas pode ser muito negligenciado pelas equipes. A armadilha é enxergar a revisão apenas como uma forma de evitar erros antes da integração para a base do código, desconsiderando seu valor como descentralizador de conhecimento.
“Você aprende muito olhando o código de outros. Você pode ensinar alguém através do Code Review, e também pode aprender coisas legais “. Assim é iniciado o Lightning Talk “Tips to improve your Code Review” (Dicas para aprimorar a revisão de código), ministrado por Wagner Voltz. Dessa forma, é necessário reservar tempo para o Code Review. Uma revisão “corrida” pode colocar a qualidade e o aprendizado a perder.
Então, para você que valoriza sua revisão de código e deseja aperfeiçoá-lo ao máximo, este Lightning Talk com menos de 12 minutos lista de práticas de forma simples e direta.
Não pode ler agora? Ouça esse conteúdo durante suas atividades:
No “The Developers Conference” em São Paulo, este ano, eu palestrei sobre uma proposta de indicadores para análise de negócios / requisitos. Indicadores para nortear a análise, ter feedback sobre o processo e agregar mais valor para o trabalho dos analistas.
Neste artigo apresento esta proposta e os pontos positivos e as oportunidades de melhoria que obtive junto com a equipe de analistas durante na implantação desses indicadores.
Quando há uma equipe com vários desenvolvedores atuando em um mesmo projeto, podem ocorrer conflitos de alterações. Também existe a necessidade de versionamento das alterações a fim de manter um histórico de todas as alterações realizadas para um melhor gerenciamento do código-fonte. O Git atua nesses dois pontos: no armazenamento do histórico (ou seja, controle de versão) e também na identificação/auxílio para resolução dos eventuais conflitos que podem ocorrer durante a evolução de um sistema por mais de um desenvolvedor simultaneamente.
Se não utilizamos a integração do Delphi com o Git, é necessário fazer o gerenciamento por outra ferramenta podendo ser pelo Git bash (linha de comando) ou então por uma ferramenta externa como por exemplo o SmartGit ou o GitKraken. Logo, uma das vantagens de usar o Delphi integrado com o Git é que você pode eliminar o uso de uma dessas duas ferramentas.
Porém, um fato é que a maior dificuldade é a de encontrar auxílio em português, pois a maioria dos tutorias para configurar a integração estão em inglês. No projeto em que eu atuo foi realizada a migração do TFS (Team Foundation Server) para o GitLab, gerando a necessidade de conhecer as ferramentas para utilizar a nova maneira de controlar as versões/alterações do sistema. Por isso, resolvi listar passos simples para que mais pessoas consigam fazer essa integração!
Além disso, explico também sobre Controle de Versão e como configurar ferramentas externas. Vamos lá?
Como definir o que é DevOps? Essa tarefa é muito difícil. É por isso que o Lightning Talk de hoje é intitulado "A viewpoint about DevOps" (Um ponto de vista sobre DevOps). Tiago Bono apresenta seu ponto sobre os seguintes…
Você já parou pra pensar por que quase ninguém faz teste unitário no Front-end? Testar não é algo simples nem no desenvolvimento de software, no desenvolvimento web então…existem algumas barreiras que podem deixar qualquer um tenso sobre testes.
Talvez seja a primeira vez que você ouve falar nisso. Fique tranquilo! Vamos contextualizar o que são testes unitários.
Imagine um enorme quebra-cabeças. Esse é o sistema, visto de um modo geral. Ele foi criado a partir da união de peças menores que se encaixam, correto? Pois bem, o teste unitário nada mais é do que o teste de cada peça separadamente. Isso significa mais organização e segurança de que mudanças serão identificadas antes de quebrar o resto da aplicação.
Vamos para o primeiro Lightning Talk totalmente em inglês divulgado no Blog DB1! Essa palestra de apenas 10 minutos tratou do tema Segurança da Informação, e de que formas podemos proteger dados mesmo não sendo um Técnico de Segurança da…
Atualmente é comum nos depararmos com projetos desenvolvidos em vue, react, angular, ou construídos sobre o modelo de SPA, mas você já se perguntou o por quê? Para responder melhor essa pergunta, vamos entender melhor como as coisas funcionam:
Modelo convencional de construção de software front-end.
Sempre que abrimos uma página na internet as informações apresentadas na tela são carregadas de algum lugar, seja uma imagem, um vídeo, ou um json. Tudo vem de algum lugar, tudo chega ao usuário através de uma request. Se você quiser visualizar o impacto que isso gera, entre em um site qualquer, abra o devtools do seu navegador (tecla F12 geralmente), vá até a guia Network e atualize a página. Cada item presente nessa seção é uma request que foi processada e solicitada pelo browser.
Agora imagine que sua aplicação precisa exibir a informação do usuário logado em todas as páginas. A página é acessada, a solicitação é disparada, o banco de dados é consultado, o resultado é formatado e então exibido para o usuário. Após isso ele navega para outra página, e o fluxo descrito acima é executado novamente, e novamente para cada página que for carregada.
Vou te responder com duas outras perguntas:
Basicamente processamento é dinheiro, tanto no servidor, quanto no lado do cliente.
E como melhorar isso?
Construindo uma aplicação baseada em Single Page Application.
Mais e se minha aplicação tiver mais de uma página?
Calma, não é bem assim que funciona. Single page application quer dizer que o browser vai renderizar o core da aplicação apenas uma vez, todas as outras informações serão carregadas por demanda, de acordo com a necessidade do usuário.
Além de gerar menos custos para renderizar a página, o modelo SPA ainda oferece uma melhor experiência para o usuário pois o mesmo não terá que ver a página recarregando completamente inúmeras vezes. Também podemos adotar estratégias de caching, como service workers (futuramente farei uma postagem abordando esse assunto), para otimizar ainda mais a performance da aplicação.
Ainda é possível compilar a mesma aplicação para Desktop ou Mobile utilizando ferramentas como Electron ou Cordova, tendo então uma aplicação multiplataforma com um único código fonte.
Quando falamos de front-end, naturalmente falamos de javascript, e criar uma aplicação num modelo SPA é o melhor custo benefício. Existem excelentes frameworks SPA, como por exemplo: VueJs, React e Angular. E é muito mais fácil desenvolver uma aplicação utilizando tais frameworks.
Mas tome cuidado, SPA não é bala de prata.
Não é uma solução que resolve qualquer problema.
Existem alguns pontos que você deve tomar cuidado:
Como o conteúdo da aplicação é carregado por demanda, isso quer dizer que tudo é carregado em tempo de execução, as famosas requests ajax. E qual o problema disso? Motores de busca captam apenas as informações de conteúdos estáticos, carregados pelo server side. Ou seja, se sua aplicação necessita de SEO, sugiro que esteja preparado para trabalhar com SPA SSR (Server Side Rendering*), ou trabalhar com MVC / MPA, depende muito do seu conhecimento e do tamanho do projeto.
Existem também aplicações “híbridas”. É comum encontrar e-commerces que tratam toda a parte de produto como MPA, e a parte de carrinho, cadastro e checkout como SPA. Isso é uma forma comum de resolver tanto problema de recarga de informações, quanto o de usabilidade.
*SSR: É aquilo que é carregado previamente, antes de chegar até o navegador. Se você abrir um site e ir até o menu Exibir > Código Fonte, geralmente CTRL + U no seu navegador, o conteúdo que você verá nesse momento será aquilo que foi carregado pelo servidor, e é esse o código que os motores de busca enxergam.
Mais então quando usar SPA, e quando não usar?
Comece avaliando o conhecimento tecnológico da sua equipe, pois o melhor modelo para construir um software é aquele que sua equipe domina, e não o que está mais no hype. Porém, é sempre legal conhecer coisas novas, e a curva de aprendizado de SPA e seus frameworks é relativamente baixa. Seu projeto tem tempo para aprendizado? Se sim, pense em começar com SPA, se não, siga pelo seguro.
Meu projeto é pequeno, tudo bem eu utilizar MPA? Sim, e não. Primeiro que um projeto pequeno pode rapidamente crescer e tornar-se um grande projeto, e segundo que ainda que seja pequeno em números de funcionalidades, pode ser grande em fluxo e tráfego de acessos. Devido a esses fatos acredito que o tamanho do projeto não deva interferir nessa decisão, e sim o que é o projeto. Isso vai te ajudar a decidir se é melhor utilizar SPA ou MPA.
“Meu projeto precisa de um certo foco em SEO, é possível utilizar SPA nestes casos?” Sim! Existem várias abordagens para tornar uma aplicação SPA SEO Friendly, como SSR e pré renders. Porém lembre-se, enquanto SPA precisa de tempo e esforço para configurar SSR e então suportar SEO, MPA já possui este recurso “nativo”.
Quando se fala em SPA, o primeiro ponto que precisamos entender é: JavaScript. Tudo passa a tratar-se de javascript, é ele quem vai controlar suas rotas, fazer suas requests, trabalhar os seus dados e sua aplicação vai passar a ter mais poder e autonomia.
Embora SPA tenha suas desvantagens, existem muitas razões para querer usar. Não é à toa que é o modelo de aplicações front-end mais utilizado da atualidade. E o legal é que como trata-se de javascript, a comunidade por trás disso é gigantesca. Existem inúmeros frameworks destinados a trabalhar com SPA, porém atualmente destacam-se três: VueJs, React e Angular. A curva de aprendizado desses frameworks varia de acordo com seu conhecimento em JavaScript (ES5) e EcmaScript 6, entre eles eu particularmente recomendo o VueJs por possuir a menor curva de aprendizado e por outros motivos que irei abordar em outro post aqui para o Blog da DB1.
E ai, deu pra entender os pontos fortes e fracos do SPA?
Vou ficando por aqui, até a próxima!
