Recently I have joined a Sydney start-up program, Antler, and have been hanging out with pretty unique and interesting people. As part of the program, I participated in the CTO forum, where all things tech in start-ups were discussed. One of the topics was about our approaches to testing. In any large gathering of tech-minded people, there is always a non-zero number of people who say, for whatever reason, “I don’t have time for testing…”. It always cracks me up as I find myself wanting to ask, “Have you budgeted the time for fixing issues after release then? How about the time for testing every subsequent new release manually?” I personally don’t ever want to have to come across untested software – whether on my phone, in traffic control systems, or in medical devices. Thus I feel it’s time to talk about what testing means and where it sits in the grand scheme of software engineering.

In this post I’d like to discuss the concept of distributed systems (DS) starting with the question of what makes a bunch of computers a system. What can be achieved by designing such systems, and what are the unintended benefits? When is it required to build one? I will touch briefly on some of the challenges, but my main focus is on the motives for creating DS and why I think it is worth the investment. While working with web-scale systems and critical high-availability service, I had to explain some of the aspects of these systems to new engineers joining a project. Now the time has come for me to design my own distributed/grid computing system for my machine learning project. I think it is worth an attempt to explain DS and the motivations for it in a more or less coherent post. Here it is…

When we use computers these days, we take for granted the fact that our data - documents, pictures, musicWhen we use computers these days, we take for granted the fact that our data - documents, pictures, music, etc - persisted. We are pretty happy to find a document we were working on if we can recall what we named it. So we are very familiar with the idea of a filesystem. A system that allows us to store and locate named files. As often the case - things get a bit more interesting in the realm of distributed systems. Fundamentally we still need a way to find stored data. It’s just that we don’t always care where is it physically located. What is important is the path to a file. A bit more general - we need an address of a resource we would like to access. In this post, I’d like to talk a bit about the concept that enables access to resources by address in a general sense. Such a concept is called virtual filesystem and I have been working on my own library for it.

After a week of intensive work I am happy to share a new version of libstyxe that now supports extended version of 9p protocol: 9p2000.u and 9p2000.L.

Recently I completed a redesign of libstyxe. As it is often the case - it took longer then I hoped. The new design is better suited for extensibility. The downside is that I had to break existing interfaces. So in this post, I would like to explain why I decided to do it and what goals I had in mind.

It is no secret that software is all around as this days. It runs traffic lights, washing machines, cars, businesses etc. Every type you plan a trip - your booking is processed online by a data centre. The plain you travel on is control by the software. As is the airport you travel to and from. And not even touching on medical equipment and production plants. That is why I believe we all can benefit from the software being well built. No unexpected crashes. I touched on the topic error handling before in my previous post.

Let us talk a bit about what is an error in a software engineering context. And more importantly, what can we do when one happens. Have you ever discussed with your colleague if this particular case should be handled as an exception or if-else condition? Or have you heard someone saying - “this case should never happen in production because of reasons…”? As a software engineer, I spend a lot of time considering how particular inputs and situations should be handled. Is it an error? It is an expected situation? Here I am going to share an approach I settled on when designing a libraries: libstyxe, libsolace, etc.

In this post I’d like to discuss details the error handling approach as implemented in libstyxe.

Welcome to my personal blog space.