NextBreakpoint is my business name. I am Andrea and I work as consultant/freelance. I create software, I work with data, I design cloud-native applications, I automate infrastructure and I deploy on Kubernetes. I have experience in creating data pipelines using stream and batch processing. I am based in London and you can hire me if you need help in any of those areas.

You can read about my professional experiences on LinkedIn, or perhaps you are more interested in my articles and projects below. I like to create software and I like to write about it. I spend most of my time implementing backend applications in Java and Kotlin, and I use Kubernetes and Docker a lot. I like to create user interfaces too, but only for fun. I love computer graphics algorithms and I designed and implemented a native UI toolkit for MacOS for creating multi-touch user interfaces, which is currently available on the Mac App Store.

Create standalone Kubernetes cluster with Vagrant

There is no doubt that Kubernetes popularity is growing very fast. I base my opinion on the trend I noticed in London since 2018, but a quick search on Google will confirm that.

My first experience with Kubernetes was in early 2017, when I attempted to create a Kubernetes cluster on AWS, and honestly I got discouraged at the time. That was before discovering Kops, and I wasn't ready to move to GCP (which actually would have been a good choice).

For the reason that I found Docker Swarm easier to install on AWS, I gave up on Kubernetes for a while. But things have changed since then, and starting from late 2018, all major cloud providers, including AWS, offer a managed Kubernetes service.

Eventually, I decided to recycle my previous experience and use Vagrant and Ansible to provision a standalone Kubernetes cluster for development.

But we already have Minikube, so why would I do that? My opinion is that Minikube is good, but it doesn't support all the interesting configurations which I want to test.

I need a Kubernetes environment which is like an actual cluster, but still runs on my laptop.

Do we need story points?

In my career as software developer, I have seen different styles of Agile and I have repeatedly noticed that estimating stories with story points is more difficult than I expected.

Some teams decide to live without estimates, and other teams try estimating stories at the cost of requiring an additional effort and spending more time in meetings.

How many times did you run out of time during a planning meeting and had to schedule a new meeting to finish estimating enough stories for starting the sprint? Even after spending long time in meetings, how many stories are still lacking of details and acceptance criteria?

In my experience, most of the times the reason for such problems was that too little work was done for preparing the stories before the meeting, and people were arguing too much about estimates.

If you think that your estimates are good, then you can stop right here, and continue doing what you are doing.

Instead, if you think that your estimates aren't working, or you feel that you are spending to much time estimating stories, then you might want to know what is my recommendation for quick estimates.

Read all articles

Automate deployments of Flink on Kubernetes

There is no doubt that Apache Flink is not easy to operate without a good automation. As many other BigData products under the umbrella of Apache Foundation, Flink presents some challenges when getting it up and running.

Fortunately Flink works fine on Kubernetes, and with the right configuration it runs successfully in a cloud platform like AWS or GCP (and it doesn't require Hadoop).

Flink K8s Toolbox is my solution for accelerating the adoption of Apache Flink. The toolbox contains a Kubernetes operator for Flink and a CLI. The operator automates the process of managing Flink clusters and jobs, and it makes easy to use Flink on a Kubernetes environment.

I have created Flink K8s Toolbox to support the use cases I encountered in my job, but I keep updating it to accommodate new use cases. If you have a use case which is not supported yet, please get in touch, you can help to improve the product.

Last but not least, Flink K8s Toolbox is free software!

Monitor and control Flink programmatically

Apache Flink presents a fairly simple REST API which can be used to monitor an existing cluster and control jobs. As the documentation says, the API is used by Flinkā€™s own dashboard, but it is designed to be used also by custom monitoring tools.

However it can be quite tedious for a developer having to implement several REST calls. For that reason I have created Flink Client library, which makes easy to monitor and control Flink programmatically.

The library is generated from an OpenAPI specification file using Swagger Codegen. The library currently targets the Java language, but the specification file could be used to generate clients for other languages too.

Flink Client library can help you to build your own automation around Flink.

Create your interactive surface

NextSurface is a software for creating interactive surfaces. NextSurface transforms any screen into a surface that people can simultaneously interact with, using hand gestures or pens, like on a physical whiteboard.

NextSurface supports input devices such as Apple Trackpad or similar HID device, however, for a better user experience, we recommend a multi-touch device, such as frame overlays produced by PQLabs or ZaagTech, or our remote controller NextGesture on iPad.

NextSurface includes two applications for presentation and collaboration. The applications are based on NextSurface's proprietary toolkit for creating multi-touch and multi-user interfaces. The toolkit supports a natural interaction with visual elements and it supports gestures performed with multiple fingers.

Common use cases of the applications are interactive meeting rooms, information kiosks for hotels or estate agencies, and digital whiteboards.

NextSurface provides a JavaScript API for creating custom applications on top of the proprietary toolkit. NextSurface's toolkit provides an abstraction layer which makes easy creating user interfaces and handling touch events and gestures.

NextSurface is not a general purpose UI toolkit, but a programmable environment for building multi-user and multi-touch applications.

Discover the beauty of Chaos

NextFractal is an application for creating amazing fractal images and other algorithmically generated images. Images are generated processing a script and some user provided parameters, depending on the selected grammar.

NextFractal is currently able to interpret two grammars: M which is a domain specific language for creating Fractals such as Mandelbrot Set or Julia and Fatou Sets. CFDG which is a context-free grammar for creating geometric shapes using an iterative process.

NextFractal provides tools for exploring Fractals, browsing images, creating time-based and event-based animations, and exporting images and animations.

You don't need to learn the M language or the CFDG language to enjoy the examples provided with NextFractal. However we recommend to study those languages in order to create new images or modify the examples.

We have created a tutorial to help you learning the M language. The tutorial shows how to implement various techniques for generating orbits and computing colours.

See all projects

NextBreakpoint on Facebook