AranciaMeetup #02 - Gli Strumentopoli Misteriosi del Devops

My presentation (in italian) about DevOps tools is live on YouTube:

The slides:

Presenting Arancia Meetup

I’m happy to annouce that I presented the first ‘AranciaMeetup’ on YouTube!

This initiative was conceived at Arancia-ICT some months ago: The initial idea was to create a group of technological meetings at Palermo because, unlike the rest of Italy, meetups here are nonexistent. We started to organize the first physical meetup but then Covid-19 happened and we had to cancel everything.

We took the opportunity and changed the format of the meeting to streaming events on Zoom: we gave colleagues the opportunity to share their experiences on technlogies, tools and methodologies used inside various areas of the company.

After having experimented a bit with this new way of doing internal formation, we were finally ready to start the first public meetup on YouTube!

Here’s the video in italian:

DevOps Questo Sconosciuto

My talk about DevOps is now live on YouTube!

I received lot of questions during the live session and hadn’t enough time to answer to everyone.

The talk is in Italian and you can watch the video from here:


  • History of Software methodologies
  • DevOps and definitions
  • The Three Ways: Flow, Feedback and Continuous Learning ed Experimentation
  • Definition of Done
  • Deployment Pipeline
  • Conclusions

The slides:

Some of the feedback I received:


My Upcoming DevOps Talk (in Italian)

To all my italian friends:

Tuesday 5 May I will present a talk about DevOps!

I will explain why this is the best methodology to develop products, the origins of the movement, the “Three Ways” and how to start applying these abstract concepts concretely.

CPU Usage: Android Studio vs Xcode

WeightWidget Open Beta

Web Frontend testing strategies with Cypress

A great technology that surpass Selenium in every possible way

In the past, I tried more than once to automate websites testing using Selenium. I always had to abandon the idea because I found the tests hard to write and the documentation not really clear on how to start.

This finally changed recently with Cypress.

Cypress has an excellent foundation and it’s not based on Selenium core technologies: instead it’s a new project based on Chromium foundations.

Cypress tests uses Javascript and testing frameworks like Mocha, Chai and Sinon. More informations here. If you already used testing frameworks on JS, you are basically at home.

Separate test logic from implementation details

One of the biggest problems of Frontend Testing is that, as time passes, tests starts to break up because the html, js and css changes and the tests selectors and logic starts breaking up.

My suggestion is to split the work this way:

  • a support class that implements all the asserts, the logic, and work with selectors
  • an integration class that only call the method from the support class to do all the work.

For example, the integration.js file will contain high-level functions like these:

it('Save Post', function () {
    var data = {
        title: 'New Post', 
        text: 'Lorem Ipsum'
    // login with the backoffice user and go to the new post    

    // sets the data in the form
    // assert the data contained in the unsaved form

    // saves the post and retrieves the id
    var id = Post.savePost()
    // go to the post detail
    // assert the data contained in the post is the same we wrote

The support post.js file will contain all the low-level functions to work with a post.


This point it’s explained at length in Cypress documentation at this page.

Containerize the application

The first step I do when I have to integrate frontend testing in a project, is to containerize the project with Docker. This way, I only need a docker-compose up command to start the web application with an empty database.

Database should be as empty as possible

The database should be also emptied of all the data. I usually leave a couple of users and very few data that I can assert.

For example, if I have 3 categories of users, the database should contain one user for each role and I save these informations in a fixture:


	"backoffice": {
		"username": "backoffice",
		"password": "backoffice001",
		"name": "Back",
		"surname": "Office"
	"frontoffice": {
		"username": "frontoffice",
		"password": "frontoffice001",
		"name": "Back",
		"surname": "Office"
	"user": {
		"username": "user",
		"password": "user001",
		"name": "Mario",
		"surname": "Rossi"

Now, whenever I need to run a test with different users/roles, I can do something like that:

describe('Home page: ' + userType, function () {
    beforeEach(function () {
		// prepare fixture for all tests

    // iterate between all roles
    ['backoffice', 'frontoffice', 'user'].forEach((userType) => {
        context('User type: ' + userType, function () {
            it('Name and surname should be equal to the logged in user', function () {
                // Custom command that manages the login
                cy.login(this.users[userType].username, this.users[userType].password)
                // Visit home page
                // UI should reflect this user being logged in
                cy.get('#logged-user-name').should('contain', this.users[userType].name)
                cy.get('#logged-user-surname').should('have.value', this.users[userType].surname)

Tests should never depends on previous tests

This is true for 99% of the testing frameworks, but it’s important to re-iterate it: A test should never depend on the result of a previous test.

For example, for a test that needs to tests the editing of a post shouldn’t depends on a post created from a previous test but it should create a new post and edit it.

The process can seems tedious, but it’s really important that every test can be executed in isolation. If your project permits it, you can use API calls to prepare and create content needed for the specific tests.

Run the frontend tests for each commit

Frontend testing are usually slower than normal tests and in a Continuous Integration context they are harder to integrate because they slow the build pipeline a lot. I also think it’s wrong to execute them only before a deploy because in frontend testing it’s really important to continuously find and immediately fix the regressions.

My general suggestion is to run the tests at each commit

If your CI setup doesn’t permit this, you can consider running the regression testing nightly on the latest ‘good’ build present in the system.

Tests must be 100% reproducible

Tests must be written in a way that, no matters how many time you repeat them, they always returns the same result.

This is one of the most important part of writing tests in general and it’s more important in Frontend Testing because they are much slower to execute and debug than Unit Testing and Integration Testing.

Imagine this scenario:

The Frontend Testing finds a couple of regressions and your team start analyzing the problem; after hours of hard work, they discover that the problem wasn’t in the source code but in the test code: The tests ‘randomly’ fail because they are not coded in the correct way. After this happen a couple of times, your team slowly starts to ignore all frontend testing regressions and also stops updating and writing them.

This is why it’s really important to start with a small but excellent test suite that will never fail for ‘random’ causes or timeouts.

After the team haves the grasps on how to build top-notch tests, the test suite can be expanded and can cover more cases.

Like lot of programming things, the expansions is usually exponential: The first couple of days are usually concentrated on a really basic test suite and the foundation classes that drives them, but after that phase the tests suite can expand faster.

When in doubt, check the documentation

Cypress technical documentation is excellent, and I highly suggest to read all the introductory articles; they are full of tips and high level suggestions on how to structure your test suite.

Posting Minecraft login events to Telegram

Me and my friends wanted to be notified every time someone logins or logouts from the Minecraft server I host.

I studied lot of overly complicated solutions, until I thought of the easiest way to implement it: continuously read the log, search for the ‘logged in’ or ‘logged out’ keywords and make an API call when there’s a result.

Translated in simplified Unix commands:

tail -F logfile | grep ‘login’ | curl

The API call is made to a Telegram bot that sends the message to a group chat.

I started working from the script from this blog post and edited it a bit:


tail -n0 -F /home/dzamir/minecraft-docker/logs/latest.log | while read LINE; do
  (echo "$LINE" | grep -e "logged in" -e "left the game") && curl -X POST \<insert-your-bot-token>/sendMessage \
  -H 'Accept: */*' \
  -H 'Cache-Control: no-cache' \
  -H 'Connection: keep-alive' \
  -H 'Host:' \
  -F chat_id=<insert-chat-id> \
  -F text="$LINE";

The script can be improved by filtering only the useful data from the log messages or posting to other platforms (eg Slack).

Hello World

Hello World, I’m Davide Di Stefano.

I’m a software engineer with 10 years of iOS Development experience.

In this website I’ll talk about my projects, my experience, my ideas and my rants.