Deeply dissapointed with Travis CI and the way OSS is treated


I have been a happy user of the Travis CI free usage over the last couple of years. But one announcement recently made me deeply worried:

Have a look here at their announcement. Yes, Travis CI will no longer be free for OSS projects. There is no point in blaming Travis CI for this but rather on those idios who abused the free usage with crypto minites and tor nodes. These bastards completely broke the trust Travis CI free tier gave for OSS projects. I loved their UI and the way the builds are executed. I will no longer have the chance to use them. There is a free tier still available but they are limited to 1000 minutes and this would mean that I can hardly do roughly 120 to 160 builds and I'm not sure if this is spread over a year. But it is definitely not enough! Once they are exhausted, I probably need to beg for more. This is no fun!

Mark & run integration unit tests with SBT and Scala


It is a good practice to write integration unit tests for your services and integrate them in your CI workflow. Such integration tests boosts the confidence of your application quality especially when it needs to be deployed in an environment where it has to talk to numerous other external services. In this regard, I wanted to write such integration tests for one of my scala project which uses SBT as a build tool.

I will just list down the steps that are needed to get this up and running!

First, in your build.sbt define the configuration and settings that can help sbt to differentiate between your integration unit tests and normal unit tests.

// Command to run integration tests, so here to run the integration tests we use -> sbt integration-test
addCommandAlias("integration-test", "Integration/testOnly -- -n integrationTest")

lazy val IntegrationTest = config("integration").extend(Test)

lazy val root = Project(base = file("."))
    IntegrationTest / parallelExecution := false, // We do not want Integration tests to execute parallely!
    Test / testOptions += Tests.Argument(TestFrameworks.ScalaTest, "-l", "integrationTest"), // Exclue the Inegration tests from the normal unit tests
    // Include integration tests, by nullifying the above option
    IntegrationTest / testOptions := Seq.empty,
    // Enable integration tests
We need to do a few more steps before we can get the whole thing up and running. We need to define an object that extends the Tag for your testing framework. So in my case I use scalatest and for me it would look like:

import org.scalatest.Tag
object IntegrationTest extends Tag("integrationTest")

After this, we can now start writing our test classes and tag them as IntegrationTest:

  test("integration testing with sbt", IntegrationTest) {
    Future {
      println("ALLES OKAY *************************************** ")

Now you can run your integration tests separately for your project as below:

sbt integration-test

Once more a blow, a nasty one this time


I could not say this more than what the title says. I had a very severe blow to my already damanged left knee. Here and here is a bit of history It was on the 28th of September where I went for my first ever defensive sport training called "VingTsun". Inspired by my Phsio friend who is a beginner, I decided to give this training a try. I indeed watched few videos of it before commiting myself to joining him for the training session which starts around 20:00 Hours near to where I live.

Convinced that if during the training, should I need to use my legs a lot, I would talk to the trainer and avoid such moves, I happily started my session. Well guess, in the first 10 minutes where we were just warming up, I inflicted a severe blow to my left knee. What happened was, we were asked to run, run, stop, jump, run. Run was Okay, Run was Okay, Stop was Okay, but when I jumped (I guess it was the third time of my jump), and landed, my left kneww buckled and I fell down with such an excruciating pain. The pain was so intense that I could not breathe anymore and I was gasping for air.

My Phsio friend tried to help out by pressing his hand against my knee, but that did not help. For the next 10 minutes I was just shouting out loud without being able to bear the pain. I got some ice applied and I was just moved over to the corner of the room. Since my home is a few kilometers away and I was not in a position to travel back alone, I waited for the session to finish. My physio friend toed my on my bike back home.

Fast forward a week, I'm back with my crutches. I think it is time for me to think about getting this damn thing operated. The pain was there for almost a week and I still have the effect in my knee from the impact.

On Navigating the Pentatonic scale


Recently, I can say that I made very good progress playing across the neck of my guitar. I memorized few pentatonic shapes, but I was stuck the whole while on those specific boxes. The whole thing did not make any sense to me. Just wandering within those boxes is not pleasant music. Frustrated, I looked at Youtube for some motivational ideas on how to unstuck me from the boxes.

Luckily, this one video in Youtube that I found on a random search helped me immensly. The idea is to think in terms of triangles and move back and forth to those triangles. Man this was wonderful and I now get the idea!

Moved from Apple to Infinitybook a.k.a Tuxedo a.k.a Ubuntu


I have been using a Mac for over 7 years now and I have used about 3 Mac's where the 3rd one is still working fine. But I have kids at home and they feed food to it and because of that the keys on my Mac are out of order. So it was time for me to have some privacy and get one machine for myself.

Looking around the latest iteration of the Mac Book Pro 13", the configuration that I could get for the money and more importantly what I will be doing with it actually got me into thinking if I ever need a Mac at all? So I listed down my usual usage: 1. Browsing 2. Software Engineering (Running application servers, Kubernetes, Docker images etc.,) 3. Occasional photo editing 4. Skype calls

So given those needs above, I realized that a Mac is a bit pricey. So I started to search for alternatives. I could not tolerate a Windows machine, so the only option was to go for a Linux installed device. Fortunately, there are possibilities today to order one such Linux machine and run it out of the box. Yes, it is from Tuxedo computers. I purchased one of their business Laptops the TUXEDO InfinityBook S 14 v5. You can customize the hardware and I maxed out on the RAM as I know this is where my maximum needs are. It came fully pre-installed with their Ubuntu distro and they call it the "Tuxedo_OS 20.04 LTS 64 Bit" which is basically a Ubuntu Linux. Since it is LTS, it is guaranteed to receive updates for the next 5 years.

It took about 5 business days for the machine to reach me and I have it now with me. So far, I really do not miss my Mac Book Pro. This machine is wonderful. What is astounding for me is the battery life. I get about 12 to 13 hours of battery life with some moderate usage (videos, browsing, terminal, docker containers etc.,). I'm pretty much satisfied with this as it just costed me 1/3 of the price for a similarly spec'd Mac Book Pro.

A quick review of the machine: 1. The chassis feels flimsy, not sure if it is truly military grade as mentioned in the website from Tuxedo 2. The Audio quality is poor and the video is kind of Okay. But for the intended purpose of this machine, I'm fine with this! 3. It is very slender and light in weight. I like that 4. The fan is silent and could not be heard under load 5. Budgie desktop is pleasing to use and set up 6. Keys have a nice reflex and it really inviting to type, but the keys could have been a bit bigger in size

CI for Kubernetes resources


Recently I have been exploring more around the Kubernetes tooling, especially the ones that can do some pre-validation on the schema and the state of my Kubernetes deployment resources or more precisely the YAML files.

I came across a few of them like conftest, kubeval etc and a wrapper around such set of tools like the kube-tools project which can be used as a GitHub Actions in your GitHub project.

So basically what I did was to try this out on one of my projects that I have on my GitHub, the plant-simulator-deployment which contains the Kuebrnetes resurces to run the plant-simulator application in a Kubernetes cluster.

Since I'm using GitOps for managing my deployments to the production cluster, I wanted to be sure that the YAML files that I write are indeed valid both in terms of the schema (Kubeval) and in terms of the state (Conftest). What I want is some kind of CI, test and a failure mechanism that would prevent any invalid YAML files getting pushed into the master branch because as soon as anything lands on the master, GitOops kicks in and deploys it immediately. So I need to be sure to fail such deployments in case any of my YAML file in invalid. How do I do this?

So here is basically my approach: 1. Under your project repo in GitHub, under Settings / Branches, create a new "Branch protection rule". In our case, we want to protect the master branch as this is the one GitOps looks for!

2. I create a status check to pass before the changes from a feature branch be merged into master (as seen in the screenshot below)

3. To test if this works, I intentionally introduced an error in one of my YAML files and you can see below that it was caught by GitHub Actions:

4. Now I issue a pull request from this branch into master and you can now see from the screenshot below that the YAML validation failure shows up. So the guy who would do this merge / pull request would not merge it into the master! This is what we want!

My journey thus far with learning to play the guitar


I remember my interest to play the guitar started in the year 2012 and without any hesitation, I went and purchased my first ever electric guitar, the Ibanez GSA 60 and a small Marshall amplifier. I'm not sure at that point in time if it was the right decision to start with an electric guitar but as I recollect, I don't think I made any significant progress with it. I was even struggling to play the basic chord shapes. This deterred me from playing the guitar. The Ibanez mostly saw its life being on the shelf. Every now and then I would just pick her up and try to learn something or the other, but never made any significant progress.

Fast forward to 2015, my interest to learn the guitar got even stronger and I decided to take some private lessons. This was the time that I made two serious mistakes. One is to buy a very cheap beginner acoustic guitar and two to get some private lessons. I did those private lessons for about 6 months and I realised it was not worth it. May be the teacher did not have any experience teaching beginners like me. The class and the lessons were not structured. No theory, no chords! It was pure waste of time and money. This experience again put me off in making any progress with my guitar learning!

Fast forward to 2017, I again made an attempt to learn the chords, but before playing anything on the guitar, I watched tons and tons of videos and I realised that I should have a nice decent enough guitar that would invite me to play. After doing some research, I nailed down that I need to get the Seagull S6 Original. It was not available in stock here in Germany. I placed an order at the Music store in Köln sometime around September 2017 and waited and waited until it was almost a year, the answer from the store was that the stock did not arrive. When I ordered it, it was retailing for a price of about 419 Euros, but I got pissed off waiting for it and hence I went ahead and got my first ever proper acoustic guitar from Taylor, the Taylor 114e in November 2018 I guess. It was pricier than the Seagull, but in the end it was definitely worth it. Taylor 114e and Justin Guitar helped me to be comfortable with playing most of the open chord shapes, change chords, strumming patterns, play a few songs. Overall I did make some considerable progress.

I went back to Youtube, watched tons more of videos and I got interested in playing blues music. The more I watched those videos, the more I wanted to play blues. I decided that I need a quality electric guitar. I first tried to learn blues with my Ibanez GSA 60, but I somehow did not like the tone that came out of it and it was for me pretty limiting. Remember I'm not a complete beginner anymore. I would call myself as an advanced beginner. So I decided that I need some quality instrument that I can have forever. I sold the Ibanez and started to do some research.

Sometime around November 2019, I narrowed down to two of the famous iconic electric guitar models - The Les Paul and the Stratocaster. I went back to Youtube to understand the tonal differences between the two, watched tons and tons of videos, understood what the different pickups mean, humbucker vs single coil... and you know!

I almost decided to get the Les Paul Studio, but after learning about the Fender Strat and making a few visits to the Music store in Köln and trying out both of these icons, I ended up getting the Fender Stratocaster Performer with the HSS configuration, yes in the sunburst color. No regrets, I made the right decision. I also got the Yamaha THR 10 V2 amplifier which made a killer combo with my Strat!

I started to learn the pentatonic scale shapes, practiced them up and down and made myself comfortable playing it faster. But then I realised that I'm stuck within this one shape, so I wanted to understand how I could move left and right, up and down the neck which is what I'm learning right now. I did make some progress, but I still have a long long way to go and I have made playing the guitar a regular routine these days.

So my verdict is, if you are interested in learning to play the guitar, my suggestion is to go and get a decent enough instrument that makes you feel to pick it up and play. If you can afford it, I would strongly recommend to get an American made guitar, Fender it is!

You've got to pick the right pick


This post is just for me as a reminder on the kind of guitar picks that I have come to terms with. I started with Dunlop Tortex picks, precisely speaking I started with the one that had 0.46mm thickness. Being a beginner to playing the guitar, those thin picks were really comfortable for me when strumming and picking. But as you learn and become familiar with some chords, strumming patters etc., those thin picks limit your speed. So I was on the lookout for some better guitar picks and I tried a few of them until I found one that was insanely comfortable to use, would not limit my speed.

Yes, it is the well known Jazz III picks from Dunlop. With this I also went thicker. So I do not use anything less than 0.73mm these days.

The verdict - I would recommend these picks to anyone that needs something reliable pick and something that would assist you with your learning!

Oh my left knee - You cause my problems!


Today morning it was just a normal day as always. We always have some balloons in our hall as my younger daughter likes to play it like a volleyball with me. I also enjoy entertaining her for some time.

So there were a few balloons in the hall and I casually like to kick it. As I kicked one off my right leg, my left leg kind of went out of balance and it twisted (as I have no cross ligaments anymore because of my MTB accident 2 years ago). It was such a shocking sensation and such an intense pain that I could not stand anymore and I fell down ferociously!

My wife and my elder daughter who were nearby came rushing hearing the sound of my fall and my cries against the pain. For the next 5 to 10 minutes I felt such a pounding sensation on my left leg! It felt as though I had a severe accident! This is pure agony! Nevertheless, I guess I need to fix my left knee with an artificial ligament. I will probably consider operating it the next year or probably this winter after the MTB season this year ends. Until then, I'm gearing up for the summer to be on my MTB!

GitOps - The way DevOps should have been


Some time around the summer of 2019, I came across a blog post where I read about GitOps and I was flattened by the idea itself and ever since I wanted to give it a try on some serious projects but never had the chance to do it professionally. I had a chat about this with many of my colleagues at work and my team and they seemed ro like the idea but were a bit reluctant to employ this concept in their projects. In this blog post I will attempt to explain what GitOps is all about and will probably give a reference to one of my private projects which I made GitOps ready!

GitOps - As the name would say, use git for operations tasks. Simply put, you define your desired state of your infrastructure (let's limit ourselves to cloud native) and have this desired state pushed into your beloved git repos (BitBucket or GitLab or GitHub or whatever that supports Git version control). Then on the cloud side you will have your typical orchestrator (k8s or docker swarm) that will then wait for these changes that you make in the Git and once it sees the changes in your Git repo, it immediately pulls those changes and applies it on your production environment. It is as simple as that. This is exactly how k8s works. Isn't it. Just match the desired state on your production runtime.

Ok so now we know what GitOps is, let us see how it could be beneficial! We have been over the past couple of years talking about CI & CD pipelines, but I have seen from my experience that it is not CI & CD happening right after, but there is a huge gap between a CI and a CD. You know what I mean? You do CI more often than you do CD. So this would imply that you have to have perhaps additional tools to do CD work for your applications and more importantly the developer is no longer inchagre of the CD process. It is left to some infrastructure operator (that classical ops guy or the notoriously famous site reliability guy for your cloud).

Here are some of the really tangible benefits that GitOps (Pull-Based deployments) brings to projects:

1. Credential Management - How many times did you have to distribute your prod credentials into some other tool that is not your production environment? With GitOps, it is not going to be the case anymore. Your production credentials stays where it belongs - In your prod environment. This solves a very basic, but rather very very important aspect for an organization - The Security! Yep! No more prod credentials on your developers machines or on your developer tools!

2. Revert with confidence in case of problems - Since Git is versioning every bit of your repo, it makes reverting to an old desired state painless and effortless. It is as easy as saying git revert to any desired version or state you want your production to be.

Now if you want to ship code more often to your production, this would mean that you should have a solid code base - One that is having a very good code coverage (unit testing, integration testion, e2e tests etc.,). When you employ GitOps, you commit yourself to deploy code more often and this would implicitly mean that you have to make your code base rigid with every subsequent release. I see the following implicit benefits:

1. You will improve your code quality (Given the fear factor that you might break something in prod because of poor untested code when pushing more often to prod)

2. You will have confidence in your overall application landscape as you exactly know what's in Git is what is in your production.

From my point of view GitOps is the way to go towards automising CD and keeping CD close to CI.

I tried this on one of my projects (link here and here) where I ran a Minikube cluster with the Flux operator installed on my Minikube cluster. It damn works! GitOps is the way to go!