There has been some new development in dart_apitool.
I got some feedback from our internal “My BMW” app teams and from the Flutter community so dart_apitool has received some extensions, improvements and fixes the last months:
Read more...
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.
Read more...This is just a small post about a small gadget I bought recently: The Antlion ModMic Wireless.
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.
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.
In the recent months I have been working on some updates for dart_apitool.
The main changes I did were:
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.
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”.
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.
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.
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.
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.
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.
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.
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 😁.
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.
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.
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 😁.
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:
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.
Read more...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.
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.
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.
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 😉
