2017 Year in Review

Another year has flown away and we’ve moved cities again. I don’t think Delhi has ever felt as much at home as it does right now. I somehow missed living in Delhi quite a lot. It has a lot of problems, but it still remains my favorite…

Another year has flown away and we’ve moved cities again. I don’t think Delhi has ever felt as much at home as it does right now. I somehow missed living in Delhi quite a lot. It has a lot of problems, but it still remains my favorite city.

Studies: This year, I’m going to aim to finish my BSc coursework. I really really want to finish the coursework by Dec 2018. This is going to take priority over everything else. I’ll be doing less racing and less traveling this year.

Accounting: Last year, I paid for YNAB and that’s been the best decision ever. I’ve managed to set apart more money for real expenses and save more money. It’s worth every penny I paid for the software.

Speaking: I spoke at even more conferences this year. Looking back I spoke at 4 conferences this year. I’m unhappy with all but one. I’m traveling less this year, so I’ll be aiming for writing talks for local events.

Learn C and Javascript: I’m better at C than I used to be. I can now debug some simpler pieces of code. I haven’t yet written anything that I expect to be in production. I’m contemplating playing with GTK to produce something for fun. I’m needing JS less these days. Golang and Groovy look like things I’ll use on a more regular basis.

Cutting Down Servers: I’m down to killing my oldest two servers. They both run Ubuntu 12.04 so it’s about time I changed them. They run a few apps in production, so it’s going to take me some time to get there. This time I’ve got a migration plan like I would for a work server migration 🙂

Writing: I’ve been trying to write 750 words for the last year on and off. If I miss out a day, then I tend to lapse into laziness and not continue for the rest of the month. This month, I finally finished an entire month. I wrote 750 words every day in December, totaling to 23,684 words this month. It’s helped me rant about frustrating topics and write a few blog posts in advance. I often use my daily writing as a rough drafts for future blog posts.

Reading: I wanted to read more books this year, but that hasn’t happened, because I keep looking at it as a big goal. This year, I learned to look at it as reading about 20 to 30 pages every day. That means I finish at least one book every 2 weeks.

Fitness: This year has been pretty bad for my running. I’m currently at my worst fitness levels since I started running. It’s going to be a slow and painful few months of training. I’ve discovered the joys of afternoon runs for winter months. I work from home, it makes sense to run in the afternoon. Most public parks are closed at that time, so I’m stuck running inside the gated area where we live.

I got my cycle serviced the other day. It now runs pretty smoothly and I’ve been riding a bit. I want to be riding about 100 km to 200 km a month. It’s a trivial amount of distance for most people. But for me, that means taking a weekend out to do long rides and a few mid-week rides too. I plan to cross train along with running.

I want to get fit enough for hiking and go on at least one hike this year. I want to do one hike that’s a few hours long and then a longer few-days worth hike. Those both should give me more kickstart into getting into a better shape.

I’m using my shopping instinct to control my habits. I’m only going to get a new shoe for long-distance running if I hit 500 km on my regular ones by 1st May 2018. I’ll give it a margin of error of about 10 km. That’s actually not a big goal. I need to be consistent at my training. I’m only going to buy any sort of cycling equipment if I manage to cycle 500 km in 2018. I’m not going to buy new books until I finish the short list I’ve made for the next year. I can read any of them in any order though. As soon as that’s done, the flood gates are open for new books.

Getting Better

Across Nov, Dec, and Jan, I spent a significant amount of time in a hospital for a family emergency. I was working, but I was also reading while waiting…

Last year, across Nov-Jan, I spent a significant amount of time in a hospital for a family emergency. I was working, but I was also reading while waiting around. One of the books I read during this time was “Better” by Atul Gwande. The book talks about certain aspects about improvement that I’ve also read in Swtich.

An empty hospital floor

The chapter titled “The Bell Curve” is one my favorite chapters. Dr. Gwande talks about cystic fibrosis treatments across the US. This is how he described the doctor at the top treatment center:

He believed that excellence came from seeing, on a daily basis, the difference between being 99.5{13371f13f0bf161e7595c2ac5df92e005bed3de1d132ef646d0a44f3a1a9ee62} successful and being 99.95{13371f13f0bf161e7595c2ac5df92e005bed3de1d132ef646d0a44f3a1a9ee62} successful.

It looks like they’re almost the same but over the course of a month, it adds up. Over the course of a year, it adds up even more.

A line from the conclusion of that chapter:

Even doctors with great knowledge and technical skill can have mediocre results; more nebulous factors like aggressiveness and diligence and ingenuity can matter enormously.

As a sysadmin and software engineer, my success does not depend on my skills alone. I work in a team. I can only be successful if I communicate effectively and work with the team. On that note, I’d also recommend the post “What we can learn from the Mayo Clinic” from The Farnam Street blog.

Image credit: Naoki Takano hospital (license)

Static Analysis for Gluster

Static analysis programs are quite useful, but also prone to false positives. It’s really hard to…

Static analysis programs are quite useful, but also prone to false positives. It’s really hard to keep track of static analysis failures on a fairly large project. We’ve looked at several approaches in the past. The one that we used to do was to publish a report every day which people could look at if they wished. This guaranteed that nobody looked at it. Despite knowing where to look for it, even I barely looked at it.

The second approach was to run them twice, before your patch is merged and after your patch is merged in. If the count goes up with your patch, the test fails. This has a problem that it doesn’t account for false positives. An argument could be made that you could go fix another static analysis failure in your patch. But that means your patch now does two things, which isn’t fun for when you want to do a backport, for instance. Or even for history purposes. That’s landing two unrelated changes in one patch.

The approach that we’ve now gone with is to have them run on a nightly basis with Jenkins. Deepshika did almost all the work for this and wrote about it on her blog. It has more details on the actual implementation. This puts all the results in one place for everyone to take a look at. Jenkins also gives us a visual view of what changed over the course of time, which wasn’t as easy in the past.

She’s working on further improving the visual look by uniting all the jobs that are tied to static analysis. That way, we’ll have a nightly pipeline run for each branch that will put all the tests we care about for a particular branch in one place.

Gluster Summit 2017

Right after Open Source Europe, we had Gluster Summit. It was a 2-day event with talks and BoFs. I had two key things to do at the Gluster Summit…

Right after Open Source Europe, we had Gluster Summit. It was a 2-day event with talks and BoFs. I had two key things to do at the Gluster Summit. One was build out the minnowboard setup to demo Tendrl. This didn’t work out. I had volunteered to help with the video work as well. According to my plans. The setup for minnowboards would take about 1h and then I’d be free to help with camera work. I had a talk scheduled for the second day of the event. I’d have expected one of these to two wrong. I didn’t expect all to go wrong 🙂

The venue had a balcony, which made for great photos

On the first day, Amar and I arrived early and did the camera setup. The venue staff were helpful. They gave us a line out from their audio setup for the camera. Our original plan was that speakers would have a lapel mic for the camera. That was prone to errors from speakers and also would need us to check batteries every few hours. When we first tried to work with the line in, we had interference. The camera power supply wasn’t grounded (there wasn’t even a ground out. The venue staff switched out the boxes they used for line out and it worked like a charm after that.

We did not have a good start for the demo. Jim had pre-setup the networking on the boards from home and brought them to Prague. But whatever we did, we couldn’t connect to it’s network the night before the event. That was the day we kept free to do this. That night we gave up, because we needed a monitor, an HDMI cable, and a keyboard to debug it. At the venue, we borrowed a keyboard and hooked up the board to the monitor. There was no user for dnsmasq, so it wasn’t assigning out IPs and that’s why the networking didn’t work. Once we got past that point, it was about getting the network to work with my laptop. That took a while. We decided to go with a server in the cloud as the Tendrl server. By evening, we got the playbook run and get everything installed and configured. But I’d made a mistake. I used IPs instead of FQDNs, so the dashboard wouldn’t work. This meant re-installing the whole setup. That’s the point where I gave up on it.

We even took the group picture from the balcony

My original content for my talk was to look at our releases. Especially to list out what we committed to at the start of the release and what we finished with. There is definitely a gap. This is common for software projects and how people estimate work. This topic was more or less covered on the first day. I instead focused on how we fail. How we fail our users, developers, and community. I followed the theme of my original talk a bit, pointing out that we can small large problems in smaller chunks.

We’re running a marathon, not a sprint.

Open Source Summit Europe 2017

In September, I attended Open Source Summit Europe. I realized this week that I haven’t written about it yet. The conference is massive…

In September, I attended Open Source Summit Europe. I realized this week that I haven’t written about it yet. The conference is massive. This edition had 2187 attendees from 65 countries according to the post-event email. The great part of the big event is the chance to meet and socialize with people I don’t otherwise get to meet. The side effect is that you often have more than one session you want to attend. The other end of that is you’re about wiped out at the end of every day. Even before the social events for the day start.

I did not get to attend all the talks I wanted to. I did skip a few sessions and spend some time recovering. Here are the talks that I liked.

The keynote by Reuben Paul about security was quite fun. It’s rare you see someone show a live demo on stage and have it work well. His talk is a reminder to developers that obfuscation is not security. When you build something, think about it from the point of view of an attacker. In the world of IoT, the question is not “if” you’re compromised, it’s “when” you’re compromised.

My colleague Robert Kratky talked about modular documentation. This is one of my favorite talks from the event. I’ve taken copious notes about it. The summary of the talk is to build modular use-case oriented documentation. “How to make an omlette” rather than document that talks about knives, chopping, onions, and eggs. While references need to exist, documentation needs to solve users problems.

I don't remember what I'm passionately arguing about

The first evening, there was a CentOS-Fedora-EPEL BoF hosted by Jim, Peter and Brian. This session teased out problems in the ecosystem and how it some of our solutions aren not perfect. For instance, a package in EPEL cannot override a system package, because it’s meant for RHEL as well. A package in CentOS SIG can override system packages. This is the recommended route for non-EPEL packages into CentOS.

On the second day, I attended a half day session about CHAOSS project. It was a good introduction to metrics and what other communities do. Amar and I attended the session together. We’ve come back with a long-list of things we want to do to track the health of our community. The session was quite long, technical and educational. If I had spare cycles to contribute, that’s where I’d be spending my time. This session also gave us a chance to talk to our friends from Bitergia.

My talk was on the last day of the conference. I like my talk being on the first day because it lets me be stress free for the rest of the event. I talked about testing products where there’s a wide range of configuration options. The premise of my talk is that “Unless you can prove it with a test, a feature is assumed to not work.” My approach is that the product needs focus on solving use-cases rather than features. We need to view every feature with the lens of what problem it helps solve. This will let us narrow down configurations which work best for use-cases. This reduces the permutations of configurations which need to be tested.

Image credit: Linux Foundation OSS EU (license)