A virtual open-space

Have you heard about open-spaces before? Have you ever been to an unconference? If yes, find something else to read. Otherwise, keep on reading. I’m going to describe how I experienced a virtual open-space I recently attended. By the end, you will have some good reasons to join one.

Open-spaces

I’ve written before about the open-space conferences that I went to, but I never explained why I love this event format. There’s a lot to say, but I’ll restrict myself to the top three reasons why I keep coming back:

  1. Autonomy and empowerment: the format of the event allows the participants to focus on meeting their individual needs. The law of two feet means that you are expected to use your own two feet to move to whatever place you can best contribute and learn. In the same way, all participants are allowed to adjust scheduled sessions as they see fit.
  2. Strong engagement of participants: anyone can propose a topic for a session. During a session, you are encouraged to suggest an improvement if you notice that a session is not going well.
  3. Relaxed expectations: two guiding principles remind participants to take it easy. “Whoever comes is the right people” and “Whatever happens is the only thing that could’ve happened“.

An open-space offers a different kind of experience than a regular conference. Even with a good understanding of the guiding principles, it’s going to be hard to imagine how it develops unless you attend it.

CITCON 2020, virtual open-space

CITCON usually takes place in a European city. Since COVID-19 makes traveling unsafe, CITCON 2020 went online. I volunteered to help the organizers, Jeff and PJ. We used the suggestions from Misha Glouberman, did a couple of test runs, and, in the end, we had a good understanding of the technology stack needed to need all the needs of an open-space. Amelie sums it up perfectly.

The tools worked well on the day of the conference (~70 participants). A couple of notes on the tools: the organizers arranged for a basic Zoom subscription, and a basic Miro subscription. There was also a need for a full-time “Zoom receptionist”, with the primary responsibility of elevating participants to co-hosts. Being a co-host means that you can move around the breakout rooms, which served as the rooms of the sessions (the blue horizontal swimlanes in the schedule below).

CITCON 2020, virtual open-space schedule
This is how the final schedule looked like (Miro)

A typical session

A typical open-space session is usually a “go-with-the-flow” discussion on the proposed topic, and it depends on the participants to set the direction and to keep the session on track. Often, participants, bring up a couple of subjects related to the topic. Commonly, some of the subjects will be touched only briefly. There’s no slide deck to take away at the end; every participant takes from the session whatever they need.

When it’s over, it’s over

I am finishing with another of the four principles of open-spaces. Creativity has its rhythm. So do groups. When you think it is over, ask: Is it over? And if it is, go on to the next thing you have passion for. See you at CITCON. Or at humansconf. Or at DevOpsDays.

A framework for handling difficult conversations

Communication is one of the few skills for which the return of investment is immediate, applies to all areas of life and compounds over time.

personal insight

For a couple of months, difficult conversations have been a topic of great interest to me. The way I used to handle them is to go into conflict avoidance or go into people-pleasing. Ugh, both of these strategies left me unsatisfied with the outcomes. But I’ve found a framework for handling these tough moments.

The framework is coming from a book called “Crucial conversations”. This is the best book that I’ve read on this subject (you might not know it, but this has always been on my radar). The material that I’ve seen so far is either dead obvious, vague/impractical, or “just a bunch of techniques”. In contrast, this book is coherent from beginning to end, with clear action points and world-view changing ideas. In my view, it’s a fully-fledged framework that gives anyone the support needed to start improving their difficult conversations.

I’m excited about this topic, so I’ve been giving a presentation covering some of the essential topics in the book.

If you have a problem with the slides not loading, go here

I could use some help to spread the knowledge even further. If you have ideas or situations you can create (with your friends, family, colleagues, etc.) where I can share this and more, would you be willing to let me know?

Checklist for learning Scala

The moment that Scala blew me away was when I wrote the definition of a set as a function.

Horia Constantin

In a previous article, I’ve proposed the use of a checklist to give structure when learning a new programming language. With writing this article, my intentions are to clarify the application of the checklist for learning a new programming language and to offer a good starting point for learning Scala.

The checklist

Mindset

  1. Personal why’s for learning Scala: I’ve wanted to start to learn a new programming language for some time. I chose Scala thinking that I can get a freelance gig faster than anything else. And because a former colleague recommended it.
  2. Find a project/application to build with Scala: a web app that supports most technologies that are required these days for a fully-featured website. I called it scalatraseed since it uses the Scalatra web framework at its core.

Setting

  1. Find a high-quality online Scala course/book: I’ve found excellent resources here. Scala originated in EPFL, so I started with Functional Programming Principles in Scala.
  2. Find/create Scala cheat sheet: here
  3. Find the official Scala documentation: start with the standard library
  4. Find/create a comparison between Scala and Java: these docs and this course
  5. Find/create a dictionary/glossary of the concepts, keywords, etc.: I haven’t been doing very well at this point because I tend to look up a concept as soon as I encounter it.
  6. Take notes: questions, curiosities, “strange” code: useful point, but the questions and curiosities change from one day to another that it makes it useless to write it here.
  7. Start collaborating on an open-source library: this point was a bit more complicated than I thought. Many libraries are either too big or have too many contributors already or are too advanced for a beginner or don’t have good-first-issues. I decided to settle down on Scalatra because I was already using it in my demo project.
  8. Find/create a roadmap that describes the learning process: this is a good start
  9. Find a code conventions document: the online Scala course that I’ve started uses Scalastyle for enforcing the style of the code. If it’s good enough for the Scala core team, it’s good enough for me.
  10. Find/create a list of antipatterns: I couldn’t find anything, probably because Scala is such a flexible language (allowing full OOP or FP and anything else in between). The small things that I’ve found so far revolve around using the language constructs correctly (e.g., use “if” as an expression, not a statement). So, nothing useful here.
  11. Find and learn how to use the most popular build tool: I wanted to leverage my maven knowledge initially, but it’s a constant uphill battle. Sbt for the win!
  12. Find a list of Scala project seeds: from lightbend
  13. Find the frameworks: Scalatest, Scalatra, Sangria

Having applied the checklist, I’m discovering that some points are part of the continuous process of learning (take notes; create a dictionary/glossary), while others are a one-time task (find the official documentation).

I’m also learning that some tasks are not so useful as others. That can be because they’re part of another, more comprehensive task (the online Scala course that I found uses Scalatest) or because they’re not that important at this stage of learning (they just take up mental and checklist space).

Based on this experience and the idea of lean learning, I’ll be updating the checklist template so that it is a more effective learning resource. For historical reasons, I’ll keep the checklist in this article as it is.

Checklist for learning a new programming language

Update 22/01/2020: I’ve applied the checklist to learning Scala and I’m updating it based on that experience.

In a workshop that I recently gave, I compared learning a new programming language with learning a new natural language. Depending on your experience, learning a new programming language might be a medium difficulty task or a hard project. In the latter situation, you’re going to need to have some structure in your approach, to ensure you reach your goal. But what is an easy way to start? I propose to use a checklist similar to the one I’ve written below.

Naive solution

“I’ve got enough Java experience. I’m a good software engineer. I’ve played with other languages before, and it went well.” I said to myself. I was aware that Scala has some very funky notations and that it uses plenty of functional programming concepts. But my confidence was high. I’ll do it as I did it before: take an online course, read a book, find the documentation, make a small app, and go from there. But I didn’t expect to get into analysis paralysis because of the overwhelming number of books, frameworks, courses, etc. I eventually decided on an online course and finished it only to realize that I wasn’t learning as much as I wanted. I decided to make the learning process explicit by creating a checklist that I could improve iteratively.

The checklist

I created this checklist iteratively as I was learning Scala, but I’ve generalized it for any programming language. In a future post, I’ll show how I’ve applied it to my learning.

There are two components that I found valuable while learning Scala: keeping my motivation high (mindset) and having a good learning plan that supports my learning experience (setting). Start with mindset first (ordered starting with top priority), continue with the setting.

Mindset

  1. Clarify what your personal why’s for learning are. Try to connect this to intangible needs/wants/dreams. Bad: I want to learn this because my boss promised me a 2% raise at the end of the year. Good: I want to learn this because I’m curious about how it works
  2. Find a project to build while learning. Online courses and books tend to teach concepts without applying them to real-world use cases.

Setting

One-time tasks

  1. Follow a high-quality online course/book about the language. Material created by the language’s author or main contributor clarifies the language philosophy and its specific patterns.
  2. Find/create a cheat sheet with the most common expressions and idioms of the language and keep it open in a browser tab
  3. Find/create a comparison between the new language and another that you’re familiar with
  4. Start collaborating on an open-source library. Pick a common one, but not a complex one. Start by searching on GitHub.
  5. Find the official language documentation, learn how to read it and keep it open in a browser tab
  6. Find/create a roadmap that describes the steps that you will go through (the table of contents of online courses are usually a good source)
  7. Find a code-conventions/style-guide document

Continuous tasks

  1. Take notes: questions, curiosities, “strange” code.
  2. Find someone to review the code that you write.
  3. Find/create a dictionary/glossary of the concepts, keywords, etc. which are specific to the new language (consider making a mindmap). Aim to understand the uses cases for them. And practice it.

Deprecated tasks

  • Find/create a list of antipatterns. It might be syntax or design patterns, but the language that you are learning is going to do a couple of things differently compared to what you were used to.
  • Find the frameworks that you foresee needing and are the most popular (GitHub search with the new language tag)
  • Find and learn how to use the most popular build tool

Work in progress

At this point, I’m convinced of the usefulness of having a checklist for learning a new programming language. However, I’m aware that some of these ideas are more effective than others. In a future article, I’ll tell you how my learning process was affected by following this checklist.

Mobile app makers review

A friend came to me recently with the idea of creating a mobile app that would support the learning platform that he already has. We discussed what features he wanted and what his budget was. The budget was tight, as is usual for any small and medium enterprise, and I realized that developing the app from scratch was not an option (App Development Cost is one of the platforms that can give you a cost estimate for a custom-built app). So, I started looking for mobile app makers platforms.

I knew that there should be some mobile app generators on the market, but I had no idea what features they offered and at what cost. I only knew that they “had” to exist. I was thinking that I’ll find a few online platforms tackling this problem. To my surprise, I discovered that there were more than mature 20 platforms, all offering similar features. I soon found out that the industry of mobile app makers is quite mature: there are reviews and comparisons and top10’s.

Soon after I started reading, I understood that all those articles would not help me with my problem: determine how much it would cost to run such an app. The reason is that the platforms are vastly diverse in terms of their offering: different prices for similar, but not always the same set of app features. The services included in the contract and the actual terms would also vary greatly. I had to make my research and comparison, based on the needs of my friend.

In this post, I’m sharing the results of the research that I’ve done. Disclaimer:

  1. I might have missed a few app makers as I only used this article as a source
  2. My focus during the research was on the feature set that my friend needed, so if a feature isn’t there, it might still be available.
  3. I only spent 10-15 minutes with each app builder platform, so I might have missed details that need more digging (or contacting customer support).

This comparison sheet is not detailed nor complete enough to allow me to select a “winner”. Instead, I will use it during the discussions with my friend to make a shortlist of 2-3 mobile app makers that I will investigate further.

If the table below is too hard to read, you can access the comparison sheet directly.

Unit testing algorithms

In the last weeks, I’ve been improving my computer science knowledge by solving programming problems. Since these problems have multiple solutions, I find myself writing duplicated unit tests. And refactoring these tests is cumbersome (if find&replace doesn’t work).

To make the point clear, I’m going to pick a problem with many possible implementations: sorting an integer array. Let’s keep things simple and solve the problem using heap sort, insertion sort, merge sort, quick sort, and selection sort. When the time comes to write the tests, all of the tests will be duplicated between implementations. If, in the future, I come up with a new test case, I have to write (copy&paste) that test to the test class of each implementation. This is far from optimal.

After doing a bit of digging, I found a convenient solution to removing the duplication: JUnit5’s @ParameterizedTest and @ValueSource. I had to do a bit of refactoring: I created a new interface that declares the sort method, and I made sure that all *sort classes implement the interface properly (you did create one class per implementation, right?). After that, it was just a matter of wiring up the tests.

Cool! 🙂 Before, the unit tests were all over the place, and not all implementations had all the corner cases tested. Soon enough, I found that the QuickSort implementation throws StackOverflowError when the input array contains duplicate values. You can find the source code here.

Xiaomi MiBand3 and privacy… not much

02/06/2020 Update: While still waiting for a response from the dutch personal data authority, I’ve been contacted by Kevin Grahl, who wrote a great article on how to protect yourself from leaking personal data to Xiaomi. The trick is to use the Lockdown iOS app. I’m confident about this solution 🙂

27/11/2019 Update: After 2 SARs without a response from Huami, I’ve decided to make a complaint with the dutch personal data authority. The estimated response time is 3 months.

7/11/2019 Update: I just received a concrete answer from Xiaomi’s Privacy Office: “MiFit is a product of Huami. Xiaomi Singapore Pte Ltd is not the MiFit data controller and is not responsible for processing the personal data of MiFit ‘s data subject. Please refer below Huami’s contact information is privacy@huami.com.”. So, I’ve made a SAR to Huami.

MiBand is a wearable activity tracker produced by Xiaomi. The 3rd generation has a reasonable feature set, and it is 2-3 times cheaper than its competitors. It’s a great entry-level band if you want to begin tracking your fitness levels.

I bought a Xiaomi MiBand3 because I was hoping to make sense of my erratic sleeping patterns. I was also eager to discover how much movement I was getting through the day. Additionally, I was hoping to connect with some faraway friends via the MiFit phone app.

“But what about privacy?” a nagging voice in my head kept asking. The data that a fitness tracker generates feels personal, and Xiaomi is a Chinese company. I don’t want the Chinese government to have information about me. It’s bad enough that Chinese citizens have no privacy. To make an informed purchase, I searched for articles about “Xiaomi privacy”. I found two articles (1 and 2) reviewing the InfoSec aspects of a couple of fitness trackers. Yet, nothing that answered my question about Xiaomi. In the end, I decided to buy the band, but I felt uneasy every time the MiFit app “synchronized” with the band. Uneasy, but not concerned enough to look deeper into the matter.

Susana Sanz, from BalkonTactics, renewed my interest in privacy and InfoSec. After our talk, my unease changed into serious concern about the data generated by my shiny, new fitness tracker. The ethical/moral/philosophical aspect of privacy did not interest me; that’s something that others have talked in more detail (Glenn Greenwald and Edward Snowden come to mind).

I was interested to know what exactly does Xiaomi know about me. Making a Subject Access Request (SAR), a right recognized by the GDPR is one way to go about it. For the sake of learning how SAR work, I submitted one to privacy@xiaomi.com. But this process would take a long time, and patience is not one of my virtues. While waiting for an official response, why not use a “hacky”, DIY approach to get an answer?

Nowadays, almost all phone apps communicate with a server on the internet. It is possible to intercept that communication, while it’s happening (see the technical method section at the bottom of the post). Thirty minutes later, I confirmed my concern: Xiaomi collects all the data that MiBand generates. To be more specific, all the data displayed in the MiFit app (e.g., sleep data, training data, heart rate) gets uploaded to the Xiaomi servers. There is no way to disable the upload in the configuration of the application. The band keeps a backlog of all the recorded data, and everything gets uploaded to Xiaomi when you use the mobile app. If you don’t use the MiFit app, you’ll end up with a band that only knows how to count your steps and how to measure your heart rate.

The only good news here is that, at this moment, the geo-location data is not collected passively (outside training sessions). But there is no guarantee that it will stay like this in the future.

In the end, I’m left with a feeling of disappointment that Xiaomi has unrestricted access to sensitive information about my lifestyle:

  • what would happen if someone infiltrates their systems? I’m sure that there are ways in which this data could be exploited to my disadvantage.
  • What’s up with this shady user agreement? Not clear to me what Xiaomi and its partners do with the data. I understand that the moment it gets uploaded, I “waive any and all ownership, legal and moral rights” to my data. But how does Xiaomi use it? Who are the third parties or Xiaomi affiliates that have access to it? Is it sold or monetized in any way? Lots of questions and no clear answers.

If you’ve been on the internet long enough, you’re familiar with the phrase “If you’re not paying for the product, you are the product”. Fun fact, in 2016, the average worth of a Facebook user was $3.73 per quarter. I’m not ok with that, but let’s leave it there for now. Thinking logically, the phrase should not stand once I start paying for the product. Right? Well, it seems that this is not the case with Xiaomi MiBand.

I’m dissatisfied that, despite paying for the MiBand, I “waive any and all” rights over the data that I generate. In this new light, what seemed to be a good deal (best cheapest fitness tracker on the market) became a lousy deal when reading the fine print and doing a bit of research.

In the end, there are two big questions left in my mind about this way of collecting personal data:

  • Is this a general practice of the fitness band industry, or is Xiaomi an exception?
  • Are other Xiaomi products collecting data in the same way?

If you own a fitness tracker or another Xiaomi product, can you do a bit of digging around and let me know? Or get in touch with me and we can do the research together.

The technical method of finding out what MiBand3 data gets uploaded to Xiaomi’s servers was simple. Had I known it would be so simple, I wouldn’t have postponed it so much.

The hardware setup: I had to install mitmproxy on my laptop.

  • connect both my phone (with the Xiaomi MiFit app) and my laptop to the same WiFi network
  • install and run mitmproxy on my laptop
  • install the mitmproxy root certificate on my phone
  • on my phone, set the proxy server for the WiFi to point to my laptop
  • open the Xiaomi MiFit app and look at the requests going into the proxy running on my laptop

Out of all the requests made by the Xiaomi MiFit app, only one sends a lot of data: 

POST https://api-mifit-de.huami.com/v1/data/band_data.json?r=50AB6198-7007-47BF-86AC-53F606CDD4F6&t=1565977799279

In the payload of this request is a key called data_json that contains all the recent band data (as the name of the endpoint suggests). I took a look at the data in the JSON object and saw all the data points that are shown on all the graphs (in the app), including all the geo-coordinates of my running sessions. To my surprise, the MiFit app didn’t seem to send to Xiaomi information about my current location. Yet, this is not a guarantee that this information will remain on my phone in the future.

From a technical perspective, I enjoyed doing this little research. Using mitmproxy was straightforward, and I recommend it if you want to see what communication goes on between the apps on your phone and the internet.

Database integration tests

Did you ever struggle while trying to write integration tests without mocking the third party? I know I did.

I’ve known about Martin Fowler since I was a junior developer. He is one of my favorite technology thought-leaders and I enjoy reading the thought-provoking articles that he publishes on his blog. In this post, I want to expand on his article about the test pyramid, in which he explains the difference between unit tests, integration tests and, UI tests. I’ll expand on the part about integration tests.

I want to show you an easy way to run integration tests against a database. With this goal in mind, I’ve created this java demo project. It illustrates the concept and is useful as a starting point for more complicated applications.

In the past, I would delay writing the integration tests. I dislike the idea of not having any integration tests. Fixing errors at runtime is not something that I want to do in Java. Meanwhile, I didn’t want to invest time on setting up a separate test infrastructure. And tests running against a mocked database, are not testing anything. The options seemed limited:

  • mocking the database interaction layer
  • connecting to an in-memory database
  • connecting to a local/remote test database

Regardless of the option I picked, I always had the feeling that the solution could be more elegant. My hesitation would turn into frustration as the application grew and the tests would become harder to maintain. Recently, I discovered a better option: connecting the tests to a database running in a Docker container.

In my last project, Vlad and Max showed me that using docker containers simplifies running integration tests against a database. No mocking, no complicated infrastructure, no tinkering with configuration files. As long as you can run Docker on the build machine, you can run the tests.

This is the elegant solution that I was looking for:

  • install and configure Docker on the build servers and the developer machines that will run the tests
  • use docker-maven-plugin to build a docker image of the database and start/stop a container based on the image
  • populate the database with the necessary data (use ‘/docker-entrypoint-initdb.d/’ or a database migration tool like flyway)
  • finally, use maven-failsafe-plugin to run the integration tests

I like this approach because the integration tests are portable and easy to debug. If the tests run on my laptop, they will run also on the build machine. If the tests fail on the build machine, the problem will also appear on my laptop.

I also like that the tests are repeatable: the plugin builds the Docker image from scratch before the tests start and removes it after the tests finish.

Finally, I like that this approach is transferable to other types of integration tests. It’s easy to replace the database container with a dockerized REST API (in a move towards contract testing) or with a message queue container.

The demo project is more than a typical “hello world” application. The integration test starts a docker MySQL container and makes a simple SQL query. You will notice that the docker-maven-plugin configuration is more complicated than necessary, given such a simple test. The reason: the code samples that I found online seemed trivial. I wanted to have a “bootstrap” project that I could reuse in real-life projects without the hassle of gluing everything from scratch.

This approach to writing integration tests has opened my eyes to the possibilities that exist today in the QA automation domain. The tools built on top of Docker seem varied enough to accommodate all test types. The number of plausible excuses for not having a proper CI pipeline is getting too low…

Setting up a “fresh” MacBook

Only for developers that use macOS…

Setting up a “fresh” laptop for development is always painful, be it windows, macOS or Linux.

It’s the second time in the last year when I do a fresh install of macOS on my MacBook. I’m tired of installing all the apps that I need in one-by-one fashion. I’m tired of doing all the small configurations (for macOS and for the apps). Most of the time I forget some of them and there are a couple of settings for which I have to search online.

I start off by making a list of settings and application that I use and then I discover that most of these things can be automated via the command line. I’m sure that someone did this before me and I start searching for some scripts that automate the installation of the development environment on a MacBook. I hit jackpot.

Using a couple of GitHub repositories as inspiration, I create a couple of simple scripts that should install almost everything that’s required for development on a MacBook. The scripts and the instructions are available here: https://github.com/treaz/mac-dev-setup/

I’m curious how much it will hurt the next time that I have to set up a development MacBook.

Simple (and fun) 360 feedback process

In the last year, I’ve been testing a new feedback meeting style that is surprisingly valuable. The meeting is intense, but it energizes me and gives me a team-feeling that will last for days. Additionally, I get an idea of what I need to tackle at work in the next months. I’m happy with these outcomes so I’ve written down the guidelines that I use during the meetings. Maybe you can use them at work too.

This style of 360 feedback is the simplest, most fun and most revealing version of feedback that I know of. The credit of coming up with it goes to one of my previous scrum masters: Caroline Fidelaire.

I’m sharing this post and these slides because I wasn’t able to find them anywhere online while I was preparing for a recent 360 feedback session. I found plenty of articles about it, but nothing straight to the point.

The intention of the session is to gather as much feedback from your colleagues as possible in the easiest way possible. It’s like going out for beers with your team, but different ;).

I hope that the slides are self-explanatory and that they will serve as a good baseline when you do your own 360 feedback sessions. Good luck and have fun!