During the last weekend of September 2018 it was held the VI edition of the Scbcn ( Software Crafters Barcelona ). Apiumhub was the platinum sponsor there and had an opportunity to open the conference with the motivation speech. Also, Albert Parron – Frontend Architect of Apiumhub gave a speech aboutMVP & FRP for a controlerless architecture.

There were several conferences and these are some of the notes I took from the ones I could attend.

SCBCN 2018: Highlights and notes

Automate everything and you will win by David Antón Lou

David gave us some tools to automate the different phases of a development. His advice: automate (almost) always, (almost) everything.

The main reason: if you automate something, it will surely run faster and you will save time that makes you more focused on the business. You will also lower the human errors and probably simplify the environments.

Code automation

Before starting to code, there is always a repetitive part: build the skeleton of the app. Let’s not repeat that everytime.

Lombok project

A java library to create all the repetitive code (getters / setters / hashcode / equals …).

In my opinion, all these features are given directly by Kotlin, so there is no need to use extra libraries or change something if your project is already in java. Also powerful IDE’s like IntelliJ do some of the work for you.

spring initialzr

A tool that generates a bootstrap application with Spring. You can choose between maven / gradle, java / kotlin / groovy, the version of the spring boot and its dependencies. Once it’s built, you can start coding your application.

JHipster

Another highly configurable application generator. In this case, it builds the whole application (backend + frontend). Some of the tools to be used are yeoman + spring boot (for the backend part) + angular / react (for the frontend) + deployment and CI / CD options.

Packaging

Once the code is done, it has to be packed.. and we do it so often that it must be automated.

It’s based on a xml file with the instructions. It has no dependencies control.

maven

Still based on a xml file but it has dependencies control.

gradle

It has its own domain-specific language (DSL) based on Groovy. It’s the most powerful among all these three. Did you know that from gradle you can execute ant tasks defined in a build.xml?

Tests automation

Automate all the tests when there are:

repeated tests
stress tests
test with long time execution
critical business part

You might not test parts:

with continuous changes
with high complexity

Development environments

To do the configuration of the environment every time there is someone new to the project can be very tedious. Automate it with:

At Apiumhub, our bet is for docker which helps us a lot with the building and deployment part.

Automated deployment

You have everything done, the last step is to deploy it to the server.

ansible

It keeps the configuration for the different environments and it helps to deploy the build.

More metrics and less pain by Modesto San Juan

In our field, when we want to improve the performance of our app, reduce the time without service. We should act based on metrics, not our feelings or other concepts. The three questions regarding this issue:

What am I trying to improve/avoid?
How can I measure it?
How can I solve it?

Tools

grafana

A platform to create dashboards. Cool visualizations.

Prometheus

A tool to monitorize and create alerts. Rich metrics.

Collecting data with prometheus and showing the results on grafana is an excellent combination to know the metrics of your project.

A handy example:

just before a new deployment, set a mark in grafana
deploy
from that point, you can easily track if the update improved or make the performance worse.

AppDynamics

It shows the visualization of the resources and how they interact among them.

The main idea is to use the metrics to improve all your processes:

check your most expensive queries in your database
improve your CI / CD checking how long it takes
observe your production environments (ping errors, bad requests…)
avoid cloud surprises: view cloud expenses to see if they change
avoid too much information!

A good focus of information is the mixed dashboards like:

logins + buys + response time + deployments

In one view it’s easy to see which changes affect to your business.

Parallel changes by Eduardo Ferro Aldama

Eduardo gave an excellent workshop about parallel changes or how to improve our code step by step:

Let’s add small changes very often (CI)
Working effectively with legacy code
Architecture with evolution

Doing changes

Pay attention when changing…

Web UI
- use of feature toggles

A good alternative to maintaining multiple branches.

The definition by Martin Fowler

From his blog, there is this other excellent article.

Duplicate views when they have to be modified
if the view is not connected to main navigation, it can be easily updated
- In communications, a good principle to have in mind:

Robustness principle (aka Pastel’s law)

Be conservative in what you send, be liberal in what you accept.

Check only what you need, ignore the rest.

Regarding logic or performance
branch by abstraction

Again, find more info in Martin Fowler’s article.

“Branch by Abstraction” is a technique for making a large-scale change to a software system in gradual way that allows you to release the system regularly while the change is still in-progress.

after a new change:
- data need to be validated
- measure performance
architecture
Strangler application

And here you have the Martin Fowler’s article on this topic, yes, again!

Create a new system around the old (which is still in production) until the old app is totally strangled so it can be removed.

In this other article, there are some detailed case studies using this technique.

A helpful tool when doing parallel changes can be scientist from github.

Scientist is a library for testing refactorings, rewrites and performance improvements in Ruby (now there are several portings to other languages). For example, it runs the old and the new code so the results of both runs can be compared.

From github engineering blog, there is this article telling how they use it to make an important change in their code.

Open spaces

Part of the first day was dedicated to open spaces. Anyone interested in a particular topic could propose an informal speech. From the audience, very interesting topics came out like experiences with production deployment, event storming, diversity, working with branches / trunk base development…

Conclusion: Scbcn 2018

That is a tiny part of all that could be seen during the scbcn 2018. It was a great weekend full of high-quality conferences and workshops. Every year the conference gets better than before and that was due to the hard job of the volunteers. Keep it up for the next editions!

If you would like to know more about Scbcn, I highly recommend you to subscribe to our monthly newsletter by clicking here.