Warp terminal

The Terminal app is the Software developers best friend. This is the most used tool followed by the IDE (ignoring the Browser of course).
As you can see in the blog posts I did I experiment(-ed, more on that later) with building my own Terminal application so that I can stuff in all the features that I want to have in the terminal I use.

Sometimes you are so used to the status quo that you are not able to imagine that the tool you use so frequently could be so much better. The same thing happened to me with Terminal apps. The core of every terminal application was basically the same. The way you enter commands, the way your input gets mirrored, the way the output of the command gets shown and so on.
There are a few options to tweak things and enrich the capabilities of this experience like oh-my-zsh or Oh My Posh to name a few.

But then came Warp.

Antlion ModMic Wireless

This is just a small post about a small gadget I bought recently: The Antlion ModMic Wireless.

Headset issues

Headsets were always a bit problematic for me. Already “in the office” but even more so in a Home Office or hybrid setting.
This issue might be home-grown, but I really hate wired headsets. The cable is always in the way and regardless of the side the cable is at it always interferes with me operating the computer.
So I needed something wireless.
I already have a couple of Bluetooth headsets, but they are not good for voice communication. They have to switch to “HFS/HFP” mode to use the microphone which totally kills the audio quality. Another issue with them is that the microphone quality is lacking, so this was not a good option.
For some time I used my Gaming headset for Teams meetings at the home office. This worked quite good, although the sound quality is nothing I want to listen to music with.
As the Gaming headset started to break I decided to look for another solution.

Gaming Headsets

The big advantage of that Gaming Headset is that it is wireless using a proprietary 2.4GHz protocol. This means that the headset is not dependent on Bluetooth and the audio quality is good even with activated microphone.
Looking at the current market for Gaming Headsets revealed a couple of good options that could replace my old one but still not being a good option for listening to music.
Gaming headsets - especially the good ones - also tend to show off that they are gaming headsets. Not that this would be a problem, but I don’t want flashing LEDs on my headset in a Teams video call 😁 (I know that this can be turned off for most of them, but you get the point).
There are some Bluetooth headsets out there that get quite good microphone reviews, but they lack in music playback quality.

Some dart_apitool updates

In the recent months I have been working on some updates for dart_apitool.
The main changes I did were:

Removal of using model files

After thinking more about the use cases for the option to store a public API model to a file in order to use it later to diff against a new version I came to the conclusion that this won’t be used in practice very often.
The amount of maintenance needed to support loading older versions of models and support comparing that with a new model based on the current code base was too high for that feature not being used by anyone.
So I decided to just remove that feature completely.

via GIPHY

Generalization of “classes”

Dart_apitool already supported the analysis of real “classes”. As interfaces in Dart are just abstract classes they were supported automatically.
But there are other concepts in Dart, that are quite similar to classes but not exactly the same. Things like Mixins for example.
So I decided to change the API used in dart_apitool to handle all those entities as “interfaces”.

Required interface support

We had a problem with the sqflite package at work. It published an update to an internal package that broke our build. Using that as perfect feature request and integration test for dart_apitool I analyzed what exactly caused the issue.
Dart_apitool would not have been able to detect that breaking change. The reason for that is that it was not aware of the difference between “required” and “provided” interfaces.

Dart & semver hygiene

What is semver?

The term semver means “semantic versioning” and is used to describe software releases.
It is defined here.

The essence of this rule-set is to couple the kind of (API) change with the version of the software. If you make a breaking change then you have to increase the major version and for non-breaking changes you have to increase the minor version (simplified).
This rule-set is the recommended way to version dart packages and all the mechanisms to resolve versions of dependencies rely on that.

What is the problem?

In general, I think semver works quite well, but sometimes it happens that a breaking change slips through.
This can have dramatic consequences.
If a package releases a new version and only increases the minor version or the patch version while still containing breaking changes then builds of dependent projects will fail without the developer specifying a new version.
This is because it is considered best practice (even a requirement) for packages to not depend on an exact version but on a compatible version range. This is done by assuming that any newer version that doesn’t increase the major version is backwards compatible.
But even if you don’t have a direct dependency on that package you might have a transitive dependency (e.g. if a package you depend on depends on that package) and you get your build broken as a result.

Is there something I can do about it?

Yes.
At least soon™️.

We were facing such a transitive dependency build breakage and I wondered if there is an easy way to integrate a semver check into a CI pipeline and why package maintainers don’t check that automatically.
After some research I was not able to find a utility that could be used to do such a check, so I decided to create one myself.

Welcome dart_apitool

Recap

As written here I took the opportunity to work in the mobile app development area full time at BMW.

Now I’m almost two months in my new job, and therefore it’s time to do some recap.

Onboarding

The onboarding went really smooth. I was able to become productive after roughly one week. Everything was prepared very well. I really like the new colleagues. They are very helpful and kind.

Work

It is like a dream has come true. Finally working in the mobile app development area professionally is what I wanted to do for such a long time. I think I have to thank Corona to finally make this possible 😁.
The environment is very professional and full of competencies. So much to learn and plenty of discussion partners for deep technical conversations.

Of course everything is still new, and I learn new things every day. Challenging but so rewarding at the same time. I really like that.

App development at BMW is definitely different from what I expected. I already prepared myself for facing a huge and complex project, but I never expected it to be that big.
I like the role I have there. It is very challenging and diverse. Exactly what I like & need. It really doesn’t get boring 😁.

Hybrid remote work

A new challenge

Current situation

As written in my profile(this is an archived version as the actual about page got updated) my current programmer’s life is divided in two halves. I’m a C++ embedded UI software architect and developer by day and a (Flutter-)Mobile Software Engineer by night.

I really like my day job as it is challenging to work on architectures and software development topics that target a very huge amount of different projects. The problem scope is fascinating and completely different from a very product focused way of working as it focuses on streamlining multiple UI projects in parallel.

Passion

Since roughly 10 years I focus most of my spare time programming on mobile app development. Mainly Android apps.

Recently (~ March 2021) I discovered Flutter and since then fell in love with it. Not only does it present a fascinating alternative for developing embedded UI applications and shows a way to finally get rid of C++ developed UI applications it also is a great way of developing cross-platform applications. Either for Android and iOS or for the different desktop systems.

This is why I started working with Flutter at home as well as experimenting with it for embedded UI scenarios and pitched it at work as a viable alternative to Qt/QML that we use today.

From time to time I also watched out for job opportunities (inside Bosch but outside as well) for mobile app development because I really love developing them, and it would be awesome to do that as a main job as well.
Sadly the opportunities here in the region I live were not interesting for me.

Corona changed it all

Flutter 3

Yesterday during Google I/O Google announced the release of Flutter 3.0.
You can have a look at the full video or read the blog post about Flutter 3 or the one about Dart 2.17.

There are plenty of new features but what stroke me most were two tiny announcements that were part of the Dart 2.17 release notes because they basically target two blog posts I made 😁.

Dart enums

I had a blog post describing how an enum can be extended by using extensions.
In the context of the Flutter 3 announcement they also announced an evolution of enums in Dart.

It is now possible to have a constructor and members directly in enums without using extensions. The only thing we loose is the reverse map providing the fromValue method.
Here is the example from my previous post but adapted to Dart 2.17:

Flutter and embedded UIs

Hi there. It has been quite a while since my last post.
In the meantime, a bunch of things happened. Corona is over 🥳😉, Apple released a monitor for the masses (webcam cough) and some crazy guy from the east decided to question the European borders 🥴.
But that shall not be the topic of this blog post. Today’s topic is: Is Flutter a good candidate for embedded UIs?
The answer: Yes!
See you next time …

but wait. Let’s explain a bit.

I got myself some new hardware

Today I want to share my opinion about 2(3) new pieces of hardware that I got for myself as an early expensive Christmas present.

The new Mac lineup

Initially I hesitated to jump on the M1 Pro/Max train. My 13” Intel MacBook Pro worked, I don’t have any projects that have compile-times where I have to wait minutes for them to complete so no real need to upgrade.

I started configuring a MacBook 14” the day the preorders started. I use the 2nd tier M1 Pro, 512 GB Storage and 32 GB RAM and ended up with ~€2700.
My first reaction: Phew, that is really expensive. I have no real need, let’s wait.

Initial community reactions

Then the internet filled with reviews, articles and other videos that all had one thing in common: What a beast of a machine.
Additionally, the order date for the MacBook 14” started moving towards December (I think currently they are somewhere in January) so I felt a bit under stress 😨
The M1 topic stuck with me as I already plan how Flutter could potentially be used at work and in that scenario having an ARM based docker environment that is performant would be a real advantage.
So I did some research to find out if the M1 already has similar performance (or even better performance) than the Intel I have and as it turned out even those are faster. So I almost ordered an M1 MacBook Air.

Buying it

In the end I convinced myself that it would be much better to have the even more performant hardware platform and the crazy fast SSD storage. I found a store that was able to immediately ship the 14” MacBook Pro, so I ordered it. I ordered the super basic entry model (8 cores, 16 GB RAM, 512 GB SSD) because I still think the upgrade price is just crazy. This machine did cost ~€2200 which is still very expensive (at least in my terms) and as the current machine was sufficient upgrading it would even be more crazy than ordering it has been in the first place 😉

Impressions

Why trying to preserve control over your privacy for me means running Android

Background

I switched from Android to iOS roughly a year ago. The main reasons for this were:

Apple released “affordable” hardware for the masses

The lowest end iPhones went into a range that “normal” people also can afford. Of course, they are a bit more expensive than the cheapest Android phones you can find but taken Apples update strategy into account (and combining this with the fact that the phone cycle slows down) this has become a real alternative for anyone.

This fact removes the “if you can afford it you can have privacy” label (at least a bit) from Apple that I really disliked.

Apple really puts their marketing into privacy

You can argue if Apple does this because they really think it is the best for their users or - like some people think - because they had no other choice (no way to beat Google, Microsoft or Amazon in the Cloud and data game) but they put privacy on top of almost every marketing material.

So the assumption is that they will try their very best to make sure to deliver on that end because they would really, really harm themselves by violating that rule.

Phones get more “boring”