∞
MacOs 12 makes it harder to know the selected keyboard layout
MacOS 12.4 changes the display of the selected keyboard layout. Before 12.4 it used to be a country’s flag. I could discern the selected layout from glancing to the menu bar and recognize the flag (US or Germany). That was quick and easy. Now they changed it to show two white-ish letters or black background.
I have to read the actual letters to know the layout. I don’t think this really helps anything.
∞
GitHub Codespaces port errors
GitHub codespaces is a great feature by GitHub that let’s me work on an iPad way easier than it was before. It’s also cool for teams to quickly setup a new developer, of switch between branches.
I use it for Ruby on Rails development, mostly. Sometimes a thing happens that prevents me from continuing my work and I had trouble finding out how best to solve this. Here’s what happens: I start my codespace and want to spin up a Rails server, to inspect the website.
∞
Something new
Changes!
I joined my last client, Edeka, in April 2020. Since then I am not freelancing anymore. My old Wordpress site ran on quite expensive hosting. Which I could justify as a business expense. But since those are gone now, I have to switch to something cheaper.
This site now runs as a GitHub pages site, powered by Gatsby. Which I love quite a lot. And now I am free to experiment with this site more, again.
∞
Onboarding new team members
Tomorrow I will help a new team member onboard at my client. I am the acting tech-lead for the client right now and so it’s my job to make sure that everything is in place for this new member of the team.
The former tech lead onboarded me in September (not so long ago). He had prepared a list of tasks we had to do together. He even created a whole new Trello board, just for the onboarding.
∞
Why ist software so bad?
A couple of days ago I talked about the Akimbo podcast by Seth Godin. It was an eposide about opportunity cost and how that relates to livelong learning as a software developer.
This morning I was on the train to a dear friend who happens to help me with my financial retirement plannings. She helps me choose equity funds and all those things related. I decided to take the train instead of the bike, which is what I usually use to get around Berlin.
∞
Opportunity cost
Today I heard a recent episode of the Akimbo podcast by Seth Godin. The topic was opportunity cost. As a quick recap, here’s what Wikipedia has to say about opportunity costs:
The opportunity cost, or alternative cost, of making a particular choice is the value of the most valuable choice out of those that were not taken. When an option is chosen from alternatives, the opportunity cost is the “cost” incurred by not enjoying the benefit associated with the best alternative choice
∞
Time to say goodbye to Drip
This will be the last email that you’ll get from me sent by Drip. My account will be terminated tomorrow.
I just spent around an hour saving screenshots of my automations and text files with the contents of all emails that I send to my subscribers. What a hassle. And then I’ll have to recreate everything when I’ve found a new home for that.
I would like to go to something like ConvertKit, but they are not GDPR compliant.
∞
When is the right time to break something?
Please excuse this sensational headline. I am referring to classes in your software and to their design. But also to tests, but see below…
Work The past week I mainly tried to pair with my fellow developers to impart some knowledge onto them. We worked together on integration tests with Nightwatch.js which is something like Capybara from the Ruby world. A question that came up was “when do we stop testing?
∞
Speaking into a microphone
Work On Tuesday I did something new for the first time. And I feel like I failed miserably. I hosted a webinar. Back in the beginning of the year, I sent out proposals to a bunch of conferences with the goal of giving a talk. A conference by NAGW (National Association of Government Web professionals) accepted my submission. I was supposed to give a talk in Utah in September. Due to calendar issues I had to cancel that appearance.
∞
Jouraling
I am writing again. Mostly for myself. As a journal. In the future I’ll try things a bit differently around here: I want to share what I am thinking about, how I work and what I am working on (as far as it makes sense in regard to my clients and NDAs).
Working I secured a new client for autumn and the first months of 2020. I’ll be joining them as interim tech lead.
∞
Inspecting changes locally before pushing
If you work on your branch you run into the situation that you would like to push your changes to the remote repository. CI will then pick up your changes and run the linting and code quality checks on it. Afterwards, you will see whether you improved the quality. But perhaps there are some new violations that crept into the code? Happens to all of us!
I usually like to see and check if any new issues might come up on CI.
∞
Avdi Grimm's view on deleting tests
A few weeks ago I wrote about deleting your tests. Yesterday I received the weekly email from Avdi Grimm, where he touches on this subject.
Some premises about my relationship with unit testing:
I like test-driven development. I like driving out individual object design small, isolated (e.g. no database) unit tests. I think of these unit tests as a design aid, full stop. Any help they provide with preventing regressions is gravy.
∞
External forces
I am occupied with learning these days. Learning on my own about visualizations of data among other topics. But also learning about learning. For that I read what other people think about learning. There are many things I have to learn about this whole topic. One thought I saw repeatedly, was about external forces, or limiting factors.
Let me elaborate what I mean by that: There are people that can motivate themselves more easily than others can.
∞
Complex conditionals
The other day we dealt with code coverage and gnarly conditionals. I promised to offer a way to be able to test them properly.
THERE IS NONE.
Ha, what a bad joke. But the real answer might not be better, depending on your point of view. What you have to do is create a table.
(A || B) && C This is our conditional.
| m | A | B | C | RESULT | ---------------------- | 0 | T | T | T | T | | 1 | T | F | T | T | x | 2 | F | F | T | F | x | 3 | F | T | T | T | x | 4 | T | T | F | F | | 5 | T | F | F | F | x | 6 | F | T | F | F | | 7 | F | F | F | F | # m is the test case # A, B, C are the atomic parts of the conditional # RESULT is the result of the evaluation of the conditional For three terms in a conditional, you can have 8 different cases (2^3).
∞
Code coverage can be misleading
During the last week, I had two discussions about code coverage. Code coverage is the metric of how many lines of code are covered by your automated test suite. Many test frameworks have built-in ways to measure this. Other times you have to install another tool manually. When you run your tests you then see how many lines are not covered by a test. That means that no test was run where this line of code was evaluated or executed or interpreted.
∞
Quick wins, part 4: YAGNI
We refactored some code yesterday, to move knowledge about an implementation of a function back to where it belonged: Into the function’s class and into the function itself.
Today I want to talk about another topic that often comes up when you are refactoring, or plainly “changing code.”
It happened the other day, during a workshop I was doing on software testing. The participant wanted to apply his new knowledge and write tests for a given JavaScript class.
∞
Quick wins, part 3: Keep it local
Yesterday I closed with this idea:
Spot places where knowledge about something does not belong.
What do I mean by that? Sometimes I come across some code that does not read right. I will use a pseudo code example to illustrate:
class Foo def initialize(bar_service) @bar_service = bar_service end def quux if @bar_service.greeting == "hello" @bar_service.greet("goodbye") else @bar_service.greet("hello") end end end class BarService attr_accessor :greeting def greet(message) @greeting = message end end What bothers me with this code?
∞
Quick wins, part 2: Method names revisited
Yesterday, we had the first part of this series on quick wins and simple steps to improve your code quality. It was about naming — specifically variables and method names.
Two things were not 100% right in these examples.
The first error You might have noticed that my loop examples were written in Ruby code. Yet the method name doSomething was written in camelCase. This is unusual for Ruby code where developers tend to use snake_case for method names.
∞
Quick wins and simple steps for improving the quality of your code
Good software needs good code. If you want to achieve a high quality in what you ship, you need to care for the quality down to each method you write.
I want to use this week to write a small series on techniques and ideas about how to increase your code quality. When I look at code, it is often possible to find spots in the code, where a simple change can be made.
∞
Power Laws
My work as a consultant offers me the opportunity to accompany a team for a certain amount of time. I join them, we work together, and then I leave again. Our time together gets extended, sometimes. This model has the benefit that I get to know a lot of people and teams — and how they work.
Do you know the Pareto principle? It’s also called the power law distribution or the 80/20 rule.