Em dia desses apareceu no meu e-mail uma mensagem curiosa propondo uma chamada para falar sobre uma vaga em aberto para o Google. Num primeiro momento achei que era “spam/scam”, pois aquilo parecia muito longe da minha realidade. Por que o *f*ck*ng* Google iria me mandar um e-mail?
Mesmo sem acreditar fiz alguma pesquisa sobre a remetente e agendei um horário. Não é que era verdade mesmo? A pessoa explicou que a vaga era para Software Engineer em Tokyo e perguntou se eu estaria disposta a me mudar. Nem precisei pensar muito: “Eu vou para quase qualquer lugar pelo Google!”
GitLab is a well-known platform that allows a team to manage projects, to create documentation, pipelines, repositories and more.
It can be used to manage the project’s Sprints and to replace other tools such as Trello or Jira.
When utilized from “end-to-end” during the development cycle, it allows some automatizations, such as to generate documentation or a changelog based on requirements collected and developed during the process.
This article aims to demonstrate how to use the project’s issues or User Stories to generate a changelog, a Wiki page or “readme” file that can be delivered to costumers automatically.
Foram muitas as vezes que ouvi de líderes ou colegas o conselho de que deveria produzir conteúdo técnico como um dos passos do livro de receita para ser “uma profissional melhor”.
Porém, certamente por insegurança e talvez até por um pouco preguiça, arranjei muitas desculpas para não o fazer.
Esse texto é um tanto motivacional, confesso. Mas após começar escrever algumas pessoas compartilharam comigo exatamente as mesmas inseguranças que tinha e por isso resolvi registrar. Se não for para motivar alguém, vai motivar a Daniane do futuro que vai voltar a ler isso algum dia.
(Recado para Daniane do futuro…
If you try to teach Java to someone coming from another less verbose language, you can often face resistance regarding the writing of getters, setters, toString, equals, and hashCode methods and the need of so much boilerplate code.
Vintage developers will not bother about it. We simply got used to instructing the IDE to generate them for us.
But let’s face it: we don’t particularly like them. We just got used to them. We accepted the need for these methods, but to be honest: it could be different.
Java 14 has launched records: a preview feature for a new type…
After having tested tools to automate the database migrations, it is time to integrate the chosen one with my GitLab repository and build a continuous delivery pipeline for AWS.
You can check my previous story about a comparison between Flyway and Liquibase here, but *spoiler alert* this implementation has the following stack:
As a software developer, I want to automatize my relational database migrations on test, staging or production environments. To achieve that, I have tested two migration tools widely know on Java universe: Liquibase and Flyway.
The stack behind this test project was:
Even the free version of Liquibase looks powerful and offers rollback command, comparison between two databases and different file formats for migrations.
It also claims to be able to compare Spring Entities with the database and generate a migration script from the differences. I have tested it but I was not able to get it working due to something that looked like a bug on Liquibase. Also, StackOverFlow’s wisdom said that it is not a good practice.
It can be executed when Spring starts up the application, through Maven command and more.
Flyway uses the old but gold SQL and the migrations are applied based on files’ name order. For instance, V1_1_0__person.sql will be applied before V1_2_0__data.sql.
The name after “__” does not really matter and once a script is executed, you can not change the file anymore.
It can be executed when Spring Boot starts up the application, through Maven command or command line.
On my demo project it is possible to check the following:
The main commands are below.
Flyway also creates one control table on the database where it is possible to watch the changes.
With a few lines of code, it’s possible to trigger an Amazon Elastic Container Service (ECS) from an Amazon Relational Database Service (RDS). This article intends to describe how to do it and the struggles I had while trying to have it working.
For the sake of understanding, I will describe an imaginary system to explain why I want to trigger an ECS task. Let’s pretend user data protection just doesn’t exist.
The company IT Paradise offers a cafeteria to its employees where they can order coffee, snacks, and drinks. …
A while ago I attended a Scrum Developer workshop facilitated by Mario Melo where we used User Story Mapping to create backlog stories to an imaginary product.
User Story Mapping was created by Jeff Patton, and it is a way to organize a product backlog that intents to allow the team to see “the big picture”.
To do so, we establish:
Software Engineer. Always learning.