Engenharia De Software on Gilberto | GibaTech

Frontend: Comece por aqui

Thu, 03 Nov 2022 12:00:00 -0300

Se você está começando no mundo do desenvolvimento front-end e está procurando materiais, pode ficar confuso com a quantidade de nomenclaturas, tais como React, Next, Webpack, NPM, Yarn, Bootstrap e muitas outras. Realmente, há muitas tecnologias envolvidas nesse processo, mas esta página tem como objetivo esclarecer um pouco mais sobre cada uma delas.

Assim como no desenvolvimento de backend, o front-end também está se tornando cada vez mais complexo e exigente. Para criar aplicações maiores e mais poderosas, pode ser necessário utilizar várias bibliotecas e frameworks, assim como no desenvolvimento de backend.

Ferramentas de Build (Build Tool)

As ferramentas de build servem para facilitar a instalação de dependências, comandos necessários para testes, execução ou publicação, por exemplo. As soluções mais utilizadas são:

Outros exemplos apenas a título de curiosidade são o BIT, GRUNT e o GULP.

Empacotador (Module Bundler)

Além do processos de build em si, há algumas ferramentas mais especializadas para as ações de build, execução e publicação, como compactar recursos (como estilos e scripts), disponibilizar recursos estáticos, além de permitir a separação da aplicação em módulos. Algumas das ferramentas utilizas:

Webpack
Vite

Outras ferramentas semelhantes: Browserify, Rollup e o Turbopack.

Comparando com o backend, no caso do mundo Java, não existe esse tipo de ferramenta pois essas ações normalmente são feitas pelo próprio Build Tool (Gradle/Maven).

Frameworks/Bibliotecas de Construção de Interfaces

Somente aqui vemos ferramentas como o React aparecer. Como uma biblioteca de renderização de componentes para a web, ele funciona integrado ao código de forma a permitir a criação e renderização de páginas e partes da página de forma dinâmica e componentizada. Ou seja, podemos ter uma aplicação com NPM+Webpack+React ou YARN+Browserify+React se assim quisermos.

Vamos ver alguns dos frameworks e bibliotecas mais conhecidos:

Você também pode desenvolver utilizando apenas JavaScript (chamado de VanilaJS).

Outras bibliotecas e frameworks

Apenas para ajudar por onde começar, listamos alguns projetos interessantes que valem um estudo:

Componentes e plugins para criação de interfaces:

Entre outros.

Para escrita de Testes:

Ferramentas “tudo-em-um”

Há algumas ferramentas que se propôe a simplificar toda essa complexidade que é a criação e configuração dos projetos de frontend tornando a criação simples e auto-configurada.

Destacamos essas que merecem atenção:

Vite - Ferramenta moderna e rápida para criar projetos React, Vue, Svelte e outros com suporte nativo a ES modules e Hot Module Replacement.
NextJS - Framework que traz todas as funcionalidades necessárias para uma aplicação React de forma auto-configurada, tanto para renderização no navegador, como código estático, quanto para renderização no servidor, com NodeJS.
NuxtJS - Abstração que também foca em simplicidade de configuração para aplicações VueJs.

Conclusão

Espero que este material tenha te ajudado a entender um pouco mais sobre as ferramentas e siglas utilizadas no Frontend. Deixe seu comentário com sugestões ou contando sua experiência estudando Frontend :)

Outros materiais

» Buscar no Guia

» Navegar por Tópicos

Backend: Comece por aqui

Thu, 03 Nov 2022 00:00:00 +0000

O backend é a parte do sistema que trabalha em conjunto com o frontend, atuando como a “engrenagem” que executa as operações necessárias para obter, consolidar, processar e persistir informações. Toda vez que um usuário interage com o frontend, seja para obter informações ou salvar dados, o backend é acionado para executar essas tarefas.

Assim, podemos dizer que o backend é responsável pelo processamento lógico do sistema, trabalhando em conjunto com o frontend para fornecer uma experiência completa e satisfatória para o usuário. É por meio do backend que os dados são armazenados, processados e transformados em informações úteis para o usuário.

Frameworks Java

Ao falarmos especificamente sobre o desenvolvimento de backend, é importante mencionar o Java, que é uma das linguagens mais utilizadas para essa finalidade. Com o objetivo de facilitar a estruturação de projetos, configurações e integrações com outras ferramentas, é possível utilizar frameworks específicos para a linguagem.

Os frameworks de Java oferecem uma série de funcionalidades e recursos que permitem aos desenvolvedores se concentrarem nas tarefas principais do projeto, reduzindo o tempo e o esforço gastos com tarefas secundárias. Além disso, esses frameworks também ajudam a manter um padrão de desenvolvimento consistente, facilitando a manutenção e a escalabilidade do projeto.

Alguns dos frameworks mais utilizados são:

Outros frameworks e bibliotecas

Além da função primária dos frameworks, podemos ter alguns sub-frameworks e bibliotecas especializadas para realizar algumas integrações ou facilidades em nossos projetos. Por exemplo podemos citar:

Lombok - Evita códigos repetitivos como acessores, construtores e métodos.
MapStruct - Evita cópias repetitivas entre classes com atributos semelhantes.
Hibernate - Persistência em bancos relacionais.
JUnit 5 - Facilidades para execução de testes.
Mockito - Isola dependências para execução de testes unitários.
AssertJ - Torna as asserções em testes de forma fluída.

Conclusão

Espero que este material tenha te ajudado a entender um pouco mais sobre as ferramentas e siglas utilizadas no Backend. Deixe seu comentário com sugestões ou contando sua experiência estudando Java :)

Outros materiais

» Buscar no Guia

» Navegar por Tópicos

React: Conheça esse famoso Framework para Desenvolvimento Web

Fri, 29 Apr 2022 12:00:00 -0300

É uma biblioteca de renderização de componentes para a web que funciona integrado ao código de forma a permitir a criação e renderização de páginas e partes da página de forma dinâmica e componentizada.

Biblioteca ou Framework

Embora se autodenomine como uma biblioteca, podemos de certa forma considerá-lo um framework, pois ele molda a forma como que estruturamos boa parte da nossa aplicação como os componentes e páginas.

Alternativas

Algumas das alternativas ao React são o Angular, Vue.Js e Ember.Js.

Ainda, há um concorrente que promete ser semelhante e muito mais leve: o Preact. Ficou curioso? Vale experimentar.

Onde começar

Atualmente a forma mais recomendada para iniciar um projeto React é usando Vite:

npm create vite@latest meu-app -- --template react
cd meu-app
npm install
npm run dev

Outra alternativa é o Next.js (framework full-stack baseado em React):

`1`	`npx create-next-app@latest meu-app`

Você pode também seguir o React: Getting Started, que possui versão em Português. Ou ver um dos vídeos a seguir:

Playlist

https://www.youtube.com/watch?v=FXqX7oof0I4&list=PLnDvRpP8BneyVA0SZ2okm-QBojomniQVO&index=1

Vídeo

Conclusão

Espero que este material tenha te ajudado a entender um pouco mais sobre o React e o motivo de ser tão popular. Deixe seu comentário com sugestões ou contando sua experiência estudando Frontend :)

WebAssembly: A promessa de futuro do desenvolvimento Web

Fri, 08 Apr 2022 20:00:00 -0300

O que é?

WebAssembly (Wasm) é um formato binário e uma linguagem de baixo nível projetada para permitir a execução de código de alta performance na web e em outros ambientes. Ele oferece uma alternativa ao JavaScript, permitindo que os desenvolvedores escrevam código em linguagens como C++, Rust, etc., que é então compilado para WebAssembly. Ele é suportado por todos os principais navegadores e oferece vantagens como maior desempenho e acesso direto a recursos de hardware.

Características:

Eficiente e rápido:

O WebAssembly é codificado de forma eficiente em um formato binário, visando a execução nativa rápida, aproveitando as capacidades de hardware comuns.

Seguro:

O ambiente de execução do WebAssembly é protegido e isolado, garantindo segurança de memória e respeitando as políticas de segurança do navegador.

Aberto e passível de depuração:

O WebAssembly pode ser apresentado em formato textual para fins de depuração, teste, otimização e escrita manual de programas, facilitando a compreensão e a manutenção.

Parte da plataforma web aberta:

O WebAssembly foi projetado para ser integrado à web como uma extensão, permitindo chamadas entre JavaScript e WebAssembly. Além disso prevê o acesso às mesmas APIs de navegador, mantendo a compatibilidade com versões anteriores.

Especificação:

A especificação do Webassembly é composta pelos seguintes itens:

Especificação principal: define a semântica dos módulos WebAssembly independentemente de uma incorporação concreta. O núcleo do WebAssembly é especificado em um único documento. https://webassembly.github.io/spec/core/

Especificação das Interfaces:

API JavaScript: define classes e objetos JavaScript para acessar o WebAssembly de dentro do JavaScript, incluindo métodos para validação, compilação, instanciação, e classes para representar e manipular importações e exportações como objetos JavaScript. https://webassembly.github.io/spec/js-api/index.html
API Web: define extensões para a API JavaScript disponibilizadas especificamente em navegadores da web, em particular, uma interface para compilação e instanciação de streaming a partir de tipos de Resposta associados à origem. https://webassembly.github.io/spec/js-api/index.html
API WASI: define uma interface de sistema modular para executar o WebAssembly fora da web, fornecendo acesso a coisas como arquivos, conexões de rede, relógios e números aleatórios. https://github.com/WebAssembly/WASI/blob/main/Proposals.md

Convenções de ferramentas: repositório descrevendo convenções não padrão úteis para coordenar a interoperabilidade entre ferramentas que trabalham com o WebAssembly. Isso inclui convenções para esquemas de ligação, informações de depuração, ABIs de linguagem e mais. https://github.com/WebAssembly/tool-conventions

Documentos de design: documentos que descrevem o design, objetivos e visão geral de alto nível do WebAssembly. Alguns desses documentos estão desatualizados atualmente. https://github.com/WebAssembly/design

Suporte dos Navegadores:

Há um bom suporte, mas ainda existem itens pendentes em diversas implementações. Confira a lista atualizada aqui: https://webassembly.org/features/

Quais as vantagens em relação ao Javascript?

Embora ainda não esteja amplamente em uso, ele possui algumas várias vantagens que podem ser consideradas:

Desempenho: O WebAssembly é projetado para oferecer desempenho próximo ao nativo, o que significa que os aplicativos podem ser executados mais rapidamente na web, especialmente aqueles que requerem computação intensiva.
Portabilidade: O código em WebAssembly pode ser executado em uma variedade de ambientes, não apenas em navegadores web, mas também em servidores e dispositivos embarcados, aumentando a portabilidade das aplicações.
Segurança: O modelo de execução do WebAssembly é projetado para ser seguro, oferecendo um ambiente de execução isolado que protege contra ataques maliciosos.
Compatibilidade: O WebAssembly foi projetado para ser compatível com a web existente, permitindo que os aplicativos interajam facilmente com o JavaScript e a infraestrutura da web, além de suportar chamadas para e de APIs do navegador.
Ampla adoção: O WebAssembly é suportado por todos os principais navegadores, o que significa que os desenvolvedores podem contar com sua disponibilidade em uma ampla gama de plataformas.
Linguagem de programação: O WebAssembly permite que os desenvolvedores usem uma variedade de linguagens de programação, incluindo C, C++, Rust e outras, em vez de se limitarem ao JavaScript, proporcionando flexibilidade na escolha da linguagem mais adequada para cada aplicativo.

Essas vantagens fazem do WebAssembly uma opção interessante para o desenvolvimento de aplicativos web que exigem alto desempenho, portabilidade e segurança.

E desvantagens, temos?

Claro, sempre há dois lados e é importante avaliar cada uma delas quando projetar um sistema. Aqui listamos algumas das desvantagens do WebAssembly hoje:

Complexidade de desenvolvimento: O processo pode ser mais complexo devido à necessidade de lidar com ferramentas de compilação e otimização para diferentes linguagens de programação.
Debugging e Ferramentas de Desenvolvimento: Depurar e usar ferramentas de desenvolvimento pode ser mais desafiador e menos maduras do que aquelas disponíveis para JavaScript.
Tamanho dos arquivos: Arquivos WebAssembly tendem a ser maiores que equivalentes em JavaScript, resultando em tempos de carregamento mais longos.
Curva de Aprendizado: Pode haver uma curva de aprendizado para desenvolvedores que estão acostumados apenas com JavaScript.
Compatibilidade com Navegadores Antigos: Pode haver problemas de compatibilidade com versões mais antigas dos navegadores, especialmente ao utilizar recursos mais recentes do WebAssembly.

Em resumo, o WebAssembly apresenta promessas significativas, oferecendo desempenho próximo ao nativo, portabilidade e segurança para aplicativos web. No entanto, sua complexidade de desenvolvimento, desafios de compatibilidade com navegadores mais antigos e potenciais questões de tamanho de arquivo podem representar obstáculos para os desenvolvedores.

Desde 2022, o Wasm tem ganhado tração consistente: é usado em edge computing (Cloudflare Workers, Fastly), aplicações de código aberto como o SQLite e até em substituição ao Docker em alguns cenários com WASI. A adoção cresce, mas o JavaScript (e TypeScript) ainda dominam o desenvolvimento web tradicional. Wasm se consolidou como uma alternativa poderosa para cenários específicos de alta performance, não como substituto geral do ecossistema JavaScript.

Criando sistemas legados com o framework da moda

Sun, 22 Nov 2020 00:00:00 +0000

Não é um assunto necessariamente recente, porém restam controvérsias e, sem dúvidas, ainda cabe uma opinião.

Legados não são ruins. Ruins são as gambiarras, a ausência de testes e de boas práticas de desenvolvimento. Colocar a mesma equipe que desastrosamente sustenta um legado para criar uma nova API fresquinha, com o último framework da moda é potencializar as chances de criação de código ruim, frequentemente chamado de legado.

Também incorro no erro de chamar de construção de novos legados quando vejo códigos escritos de qualquer forma. Mas é força do hábito. Muitas vezes pensei que a solução para melhorar um software era reescrevê-lo, não por convicção própria, pois muitas vezes o CTO da empresa ou o arquiteto induziram a equipe a pensar desta forma. Fato é que essa abordagem nunca resolveu o problema inicial. Meses após o início das migrações sempre parece haver um “novo legado”.

E o que acontece ao tentar escrever um novo software com os mesmos vícios de programação? Temos dois softwares ruins para manter, com a mesma equipe que já não aguenta manter o legado. Óbvio que é tentador explorar novos frameworks e linguagens. E o ganho de velocidade realmente surpreende nas primeiras Sprints pois, obviamente, ainda não está uma bagunça completa: ela vem com o tempo. A situação ainda é agravada com os microsserviços e com a criação de novas APIs de forma desenfreada e sem qualidade.

O problema é colocado sobre o sistema, mas na verdade deveria ser sobre a sua forma de manutenção. Não há uma atenção especial à qualidade e melhoria contínua, haja vista que o foco é criar os entregáveis e fazer as peças funcionarem a todo custo. Há uma pressão clara de entrega e isso faz parte do negócio, mas os desenvolvedores devem contrapor isso com seus pontos técnicos ao longo das Sprints.

A equipe de desenvolvimento deve continuamente levantar débitos, ajustar desvios e executar pequenas refatorações. Estas não deveriam exigir um Sprint dedicado apenas a débitos técnicos de tempos em tempos, mas sim pequenas tarefas dentro de cada Estória, melhorando continuamente o código e a arquitetura. Olhar com a visão de escoteiro, melhorando pouco a pouco cada classe alterada irá dar uma sustentabilidade muito maior ao sistema, deixando mais fácil adicionar novas features.

E se o framework ficar defasado? Inseguro? Precisar ser escalado? Bem, se o software foi bem cuidado pode ser planejada uma estratégia de migração ou fracionamento. As classes de negócio poderão ser reaproveitadas, se mantida a linguagem, mas as demais provavelmente terão de ser reescritas. Será doloroso, contudo a migração será mais curta e garante foco total em apenas uma aplicação, sem legados.

Publicado também na comunidade DEV! Vá lá e comente :)

https://dev.to/gilbertolptn/criando-sistemas-legados-com-o-framework-da-moda-5gcj

Você está organizando e nomeando seu código corretamente?

Tue, 21 Apr 2020 00:00:00 +0000

Fala-se sobre Código Limpo há algum tempo, sobre funcionalidades que melhoram a legibilidade do código e bibliotecas que agilizam e deixam o código menor e, às vezes, melhor. Mas há questões bem mais fundamentais que não podem ser esquecidas ou despriorizadas em relação àqueles assuntos mais populares, entre eles, a nomenclatura de tudo o que está sendo escrito.

Quando precisamos realizar alterações em um sistema já desenvolvido, mas desconhecido, temos a necessidade de avaliar, como um todo, quais são suas funcionalidades. Certas vezes nem mesmo é desconhecido, mas trabalhado há alguns meses e com detalhes específicos de arquitetura para relembrar. Esse sistema provavelmente está em produção e quebrar algo em funcionamento não é uma possibilidade.

Num primeiro momento pouco importam as bibliotecas utilizadas, a versão da linguagem ou mesmo detalhes do ambiente de execução. A primeira coisa que devemos observar no sistema para saber qual é o seu domínio de negócio são suas classes e pacotes. Depois, olhamos para seus atributos e métodos, a fim de entender os recursos que cada parte do domínio tem. Em terceiro, analisamos os testes, que irão dizer como os recursos devem se comportar. Somente após isso, pode-se passar aos detalhes da tecnologia, versões, ambientes e bibliotecas.

Guarde esta ordem:

Classes e seus pacotes
Atributos e Métodos
Testes

Numa aplicação em que não puder ser obtida uma visão geral seguindo os passos mencionados, certamente não é orientada a objetos, mesmo que use uma linguagem dita como OO. Não conhece Orientação a Objetos mas está lendo este artigo? Que bom, é um ótimo começo!

Por que os pacotes estão no primeiro item?

Os pacotes estão juntos às classes para sustentá-las. Pouco importa ter um pacote se não existir uma classe dentro deste. Porém, caso seja ignorada a sua importância, deixando as classes mal distribuídas, tornará muito difícil encontrar a sua localização. Sem falar que se o sistema crescer, irá virar uma bagunça.

Há quem considere a divisão dos pacotes a parte mais simples, afirmando que são sempre os mesmos: entidade, serviço, dao, util, rest… Outros discordarão com veemência dizendo que preferem repositorio à dao e controlador à rest. Algum deles está correto? De certa forma, sim. Esta quebra por camadas é muito utilizada, e comum para quem está começando a trabalhar com MVC. É uma abordagem sem grandes dúvidas: em pouco tempo está definida para toda a vida do projeto e o restante do tempo fica com a codificação.

Agora, trago a verdade sobre os pacotes. Essa divisão simples por camadas é como colocar uma caixa escrito “gavetas” na sua garagem e juntar todas as gavetas da casa ali dentro: gavetas da cozinha, do guarda-roupas, do armário de produtos de limpeza. Faz sentido? Claro, deixamos todas as gavetas, que possuem a mesma finalidade juntas, não é verdade? Mas na prática isso tem pouco sentido, principalmente em sistemas maiores, onde temos dezenas de classes na mesma camada. Por que faríamos diferente com o nosso software? Faz muito mais sentido deixar coisas onde realmente são utilizadas do que juntá-las no mesmo local.

Mas como seria essa organização? Seguindo o mesmo exemplo, pense nos cômodos da casa como pacotes e nos compartimentos dos cômodos como subpacotes. Dentro deles estarão as ferramentas ou utensílios, ou seja, as classes. Então:

Cozinha
- Armário
  - Gaveta
    - Talheres
  - Balcão
- Fogão
Sala
Quarto
- Guarda-roupas
  - Gaveta
    - Meias

Não achou que poderia organizar sua casa em pacotes, subpacotes e classes? Pois é. A orientação a objetos é a melhor forma pra isso, trazer abstrações do mundo real para dentro de um sistema, de forma que se alguém pedir para adicionar uma funcionalidade de “bancada” no armário da cozinha, saberemos exatamente onde criar o pacote e suas classes. Não é uma forma fácil e vai gerar muitas dúvidas, mas fica mais próximo da realidade, o que é bom para a Orientação a Objetos.

Certo… E as classes?

Pois bem, já definimos os pacotes e agora podemos pensar de fato nas classes. Utilizando a abordagem de divisão por lógica que vimos a pouco, sabemos que devemos deixar as classes relacionadas próximas. Dentre estas, as mais importantes do nosso sistema são àquelas do domínio do negócio, as quais contém características, estado e ações. Classes como Aluno, Turma, Cliente, Animal, Pagamento são exemplos disso.

Essas classes do domínio do negócio, conhecidas como modelo, também podem se tornar entidades, se forem relacionadas a um banco de dados. Eventualmente estas entidades precisam ser listadas, criadas, apagadas ou atualizadas, sendo que neste caso delegamos a uma classe de persistência, normalmente chamada de repositório ou dao. Além da própria entidade e seu repositório, ainda é comum o uso de uma classe onde as regras de negócio entre diferentes entidades são relacionadas, chamadas de serviço.

Assim, temos três classes intrinsecamente relacionadas: a Entidade, seu Repositório e seu Serviço. Com muita dificuldade conseguiremos separá-las, razão pela qual devem permanecer no mesmo pacote.

Ainda, as classes de Serviço podem vir a ficar sobrecarregadas devido à quantidade de regras e operações que algumas entidades tem. Logo, para melhorar a manutenção deste código, devem ser decompostas em classes específicas, reduzindo a complexidade e organizando as responsabilidades. Por exemplo, em um sistema de Petshop, poderíamos ter um pacote animal, com as classes Animal, AnimalRepositorio, AnimalService, AnimalAlimentacaoServicoe AnimalSaudeServico. Isso, considerando que a “alimentação” e “saúde” dos animais possuem muitas regras que justifiquem a divisão. O uso da nomenclatura em inglês também é comum, contudo não é relevante para este artigo, desde que você adote um padrão: service e repository.

Só estas classes compõe uma aplicação?

De fato não conseguimos fazer todo o necessário somente com estas classes, pois nossos modelos quase sempre precisam conversar com o mundo externo. Para isso, serão necessários Controllers, Clientes de APIs, Filas, etc. Essas classes fazem parte de uma aplicação, mas não são parte do “negócio”, então considere separar esses recursos tecnológicos em algum pacote específico como api, infra, cliente, etc…

Além disso, precisamos de utilitários que nos ajudam a manter a abstração dentro de nossos modelos, e também são aceitos. Eles normalmente são conhecidos como Builders, Factories, Converters, Mappers, etc. Mas pense que o objetivo destes é simplificar a lógica das classes de negócio, apenas isso.

Ok, organizamos nosso negócio em pacotes e classes, mas onde de fato ficam nossas regras e informações?

Nesse momento entram os atributos de nossas classes para armazenar as informações, características e estado. E os métodos para realizar as ações, mudanças de estado e validações. Da mesma forma que os pacotes e classes devem ser precisamente pensados para dar sentido à nossa organização.

Os atributos devem parecer com características ou estado. Devem fazer sentido para o negócio e não conter prefixos ou sufixos tecnológicos que não ajudam na abstração. Ou seja, prefira “tamanho” à “nroTamanho”, por exemplo.

Quanto aos métodos, também devem parecer ações do negócio e mudança de estado e, ainda, evitar prefixos e sufixos que não auxiliam na compreensão do negócio. Caso sejam necessárias conversões, cópia de objetos ou quaisquer outras ações que não fazem parte do comportamento natural do negócio, considere criar as classes que citamos anteriormente, como Converters, Mappers, Builders, Factories…

Testes?!

Bem, como último dentre os itens citados, mas não menos relevante, temos os testes. Sua posição deve-se unicamente pela ordem natural de entender a visão geral da arquitetura, o contexto de cada uma das funcionalidades e aí sim adentrar nos detalhes da implementação.

Chegada esta etapa podemos interpretar de fato o que o sistema poderia e deveria fazer, e os testes são bons para nos contar isso: além dos cenários principais os testes nos mostram os secundários e os de exceção, com a reação prevista do software quando nem tudo sai conforme gostaríamos. Esse tipo de informação é difícil de extrair de alguns códigos de produção ou implícitos em outros, mas os testes tendem a deixá-los explícitos, o que facilita o trabalho de manutenção.

Encerra-se por aqui a discussão? Com certeza não! Existem diversas abordagens de organização e arquitetura. Aqui trago uma visão subjetiva do que considero importante após alguns anos de programação, objetivando que seja dada maior ênfase à abstração do negócio, que é o motivador para a criação dos sistemas, em vez da tecnologia, bibliotecas e termos que afastam o propósito real do código.

Também não foi o objetivo falar especificamente sobre uma ou outra arquitetura, mas há muito material disponível. Se você ficou motivado, considere pesquisar sobre DDD e Arquitetura Hexagonal.

Linux: Comandos úteis de rede

Sun, 12 Apr 2020 00:00:00 +0000

Este é um guia de comando úteis para utilização em ambiente Linux. São basicamente minhas notas de aula utilizadas durante os treinamentos que ministrava, mas podem ser úteis em vários contextos.

Rede

Arquivos e pastas importantes:

/etc/syconfig/network-scripts/
/etc/hosts
/etc/host.conf
/etc/resolv.conf

Comandos

dhClient: Autoconfiguração de rede. Se você estiver em uma máquina sem internet e precisar de uma configuração automática e rápida, tente este comando.
/etc/rc.d/init.d/network stop ou start: Para ou inicia um serviço de sistema. Este é específico para sistemas Linux que usam o InitD. Isto vem mudando a bastante tempo principalmente para o SystemD, e pode ser que tenha de rodar systemctl start networking.service.
route -n: Lista a tabela de roteamento de rede configurada. Da mesma forma, pode funcionar com netstat -r OU cat /proc/net/route.
dig site.com.br: Consulta o servidor DNS configurado no arquivo resolv.conf exibindo suas configurações.

Automação de Build

Sun, 29 Mar 2020 00:00:00 +0000

Introdução

Neste tópico vamos falar sobre as ferramentas que normalmente são utilizadas em aplicações Java para tarefas rotineiras de build, como compilação, testes e cobertura, empacotamento, publicação…

As mais conhecidas ferramentas para esta finalidade são o Gradle e o Maven.

Glossário

Artefato: no contexto deste artigo, para o Java, um Artefato corresponde a uma biblioteca que é compilada a partir de outro projeto Java, resultando um arquivo de extensão JAR.
Classpath: no contexto deste artigo, para o Java, o classpath é o conjunto de recursos necessários para a execução da aplicação. Compoe esse classpath a próprias classes Java, resources, dependências (bibliotecas), etc.

Por que utilizar uma ferramenta?

Para quem está iniciando no Java, esta é uma pergunta clássica. Não basta aprender o Java, ainda tenho que aprender Maven ou Gradle? A resposta é: SIM. Não é algo que você precise se tornar especialista, mas é importante que conheça seu uso básico para não seguir caminhos complexos nos pontos que estas ferramentas resolvem com facilidade:

Gestão de dependências: O motivo principal para usar uma dessas ferramentas. Nada de baixar arquivos JAR e colocar em uma pasta LIB, ok? Basta declarar o Artefato no Maven/Gradle e deixar que ele baixe e adicione o mesmo ao Classpath.
Garantia de versionamento Todos os artefatos gerados ou dependências que nosso projeto terá serão necessariamente versionados. E uma determinada versão não deve ser regerada, gerando uma garantia que nosso código sempre utilizará a versão testada das dependências.

Gradle

O Gradle é a ferramenta de build mais moderna do ecossistema Java, usando uma DSL baseada em Groovy ou Kotlin. Arquivo de configuração: build.gradle (ou build.gradle.kts).

plugins {
    id 'java'
}

repositories {
    mavenCentral()
}

dependencies {
    implementation 'org.springframework.boot:spring-boot-starter-web:3.2.0'
    testImplementation 'org.junit.jupiter:junit-jupiter:5.10.0'
}

Comandos principais:

./gradlew build — compila, roda testes e empacota
./gradlew test — executa os testes
./gradlew bootRun — executa a aplicação Spring Boot

Maven

O Maven é a ferramenta mais tradicional, usando XML para configuração. Arquivo de configuração: pom.xml.

<project>
    <modelVersion>4.0.0</modelVersion>
    <groupId>com.exemplo</groupId>
    <artifactId>meu-app</artifactId>
    <version>1.0.0</version>

    <dependencies>
        <dependency>
            <groupId>org.springframework.boot</groupId>
            <artifactId>spring-boot-starter-web</artifactId>
            <version>3.2.0</version>
        </dependency>
    </dependencies>
</project>

Comandos principais:

mvn clean install — compila, roda testes e empacota
mvn test — executa os testes
mvn spring-boot:run — executa a aplicação Spring Boot

Conclusão

Tanto Gradle quanto Maven resolvem bem o problema de gestão de dependências e automação de build. O Gradle é mais moderno e flexível; o Maven é mais previsível e amplamente documentado. A escolha depende do seu projeto e equipe.