article
- Dash from Kapeli
- BetterTouchTool
- CodeRunner
- Numi
- The branch name begins with the kind of branch this is. In our case we work on a new feature for our application, so we call it “feature”.
- The second thing you might notice is, the
MIH-318part of the name. This comes from our project management software. This is the short title of the ticket that the branch belongs to. More on that later. - The last part is the name of the feature. This could also come from your project management software and be the long name of the ticket, or it could be a descriptive name of the feature you are building. Something like
new-user-login-formorintegrate-stripe-payment-provider. - What is changed?
- Why was the change necessary?
- How does the project / part of the code / microservice look after making your changes?
- Are there any side-effects of your change?
- Do you want to add any commentary about your changes? Perhaps link to Stack Overflow answers that helped you, or blog articles and books you referenced during development?
- Is there anything unclear with your changes? Perhaps you have a road-block that you need help with? Or you are uncertain how your changes interfere with another component? Ask about that. This is the place to do that.
- Check the code for linting errors and warnings.
- Run all automated tests, including long-running integration tests.
- Run static (and behavioral) code quality analysis.
- Deploy the feature branch to a test environment automatically.
- Inform the reviewers about the results of the above steps, through a comment on the PR, and post the url of the deployed test environment.
- Block or unblock the the PR from being able to be merged, depending on the results of the above steps.
-
I wrote this guide originally in ~2019. Most things still apply! ↩︎
The brightest flame burns quickest
Maybe the answer is simpler than I think. Maybe I should just keep things simple. If I like my coffee the way it tastes, that should be enough. If I enjoy playing the guitar songs I love, there’s no need to dig into the theory behind them. And when I write on my blog daily or a few times a week, that’s enough too. There’s no need to turn a hobby into something bigger. It’s fine as it is — an enjoyable way to spend time. Trying to grow it into something more only leads to destruction.
I feel you, Yordi. I’ve been there. And I am not sure I am not still there. I always wanted to do things “right”. It’s actually a mantra of mine: “If something is worth doing, it’s worth doing it right.”
But that quickly leads to burnout and boredom. Unless you find a way to do things in moderation. Recently I picked up singing. And I do that maybe once or twice per week. And I enjoy it tremendously. Now I started playing piano again, and mostly re-learning it. And building on the little that I already knew. And I specifically set me the goal of not playing more than once or twice a week. Not daily or anything like that. Because then I know that I would hate it soon.
So yes, my last blog post was a few days ago. I don’t need to write daily. Let others do that. 🫶
Some small thoughts on the Middle East
This is a very personal, moving piece by @jsonbecker.
It’s surreal to see your cousin in a Washington Post video. It’s worse when the reason she’s being interviewed is because of her experience living in a community in Israel that was overrun on October 7th.
It’s been over a decade since I’ve seen her.
I am 42 years old. The “conflict in the Middle East” was present on the news for as long as I can remember. When I was around 15 years old I had the chance to take part in a student exchange program and travel to Israel. We lived in Ashkelon, a small city very close to the Gaza strip. It must have been near the end of the 90s and I guess it was a bit more relaxed (don’t want to say peaceful…) back then. I was able to visit Jerusalem and Tel Aviv and I am still impressed by what I experienced. The magic, the food, the architecture and all of the history. I would love to go back there and see everything with my adult eyes and experience it with the knowledge and appreciation I have today. But I wouldn’t go there now, or previously. As a kid I didn’t understand why people couldn’t stop fighting and my understanding did not grow as an adult. The blind hate and it’s source in the people’s religions is one reason I do not like religion. I don’t think that the fighting will ever stop in my lifetime and that thought makes me very sad. I am glad, personally, that I do not have any relatives in that region. My situation is very different from Jason’s. Still I feel for him and how torn he has to feel. How frustrated and helpless.
Fedi(verse) is for losers? I don't care.
From where I sit, I don’t see that we have a strategy. Fedi is fine and all, but it doesn’t scare anyone. That’s not good enough. Twitter was always flawed but it was a great tool for activism and continues to be useful in some ways. Bluesky has some of that old-Twitter vibe, and perhaps it will supplant the original, in time; inshallah.
I wouldn’t count myself as part of the fediverse but I am. I don’t do Mastodon. It’s one of the reasons I use micro.blog to host my content right now. I don’t think that joining a mastodon instance is the right way. In my opinion the best way to share your thoughts is on your own personal website using your own domain name. A name that you control. And then use federation through protocols like ActivityPub to take part in the social circles. That way I don’t have to care about Mastodon or the fediverse.
We deceive ourselves as to what constitutes effective action, and we are deceived by billion dollar algorithms that understand our subconscious better than we do and feed our illusory sense of accomplishment through facilitating and encouraging such paltry (yet addicting) protests.
When I read the original article up top about “the fediverse is for losers” in my opinion it touches on this exact topic. The fediverse isn’t good for activism. You don’t use it to make the world better. You use it to complain about what others do (which is kind of what I am doing here right now 🙈). If you really want to make the world a better place, change routines in your daily live. Interact with people outside of your computer. Bring a smile on another person’s face. Show them you care.
Pinboard is dead. At least for me. Let me tell you how I bookmark in 2024.
Yesterday, I read an opinion about the bookmarking service pinboard.in. I am a user since 2010. In 2019 I paid ~$210 for a 10 year contract because I wanted to do my part to keep the service running and enable the founder to do his thing. Because I believed in his mission and the purpose of the service. Gordon made me aware that Pinboard might be over. There is a Hacker News thread for the linked article where alternatives are discussed, if you are interested. The thing is, I believe Gordon and others might be right. Roughly 1,5 years ago I tried to write a small application to interface with the Pinboard API. Unfortunately, the API didn’t work as expected. When I looked into it, I learned about a version 2 of that API that was supposed to be in development. The documentation to that API was insufficient and things didn’t work in any way like they were documented. When I reached out to the Pinboard founder I heard nothing back. The state of the API hasn’t changed at all since then. There were no updates.
The founder still writes on the web about things like lunar programs and moon landers with SpaceX and other political topics. He also gave entertaining talks on conferences during the last years. But he didn’t do what he was paid for. At least in my opinion. Sure, the basic website still works. And maybe that could be considered enough?
I have since stopped using the service. Bookmarking is an activity I not do as often anymore as before. If I want to have a website handy for later reading or watching, I use Omnivore. It’s an open-source solution that is free to use. Eventually you can even do self-hosting. I chose it because it works well and I can read and understand the code and tech stack. If they ever decide to discontinue the web app I can host it myself.
For saving website to reference later, which you could call bookmarking, I mostly use Obsidian. It’s my preferred solution for taking notes that I want to keep. Right now I have over 5.600 notes in there. A big part of those are my journal notes, which I imported from Day one.
To make saving websites quicker I wrote a small Alfred.app workflow that calls a Shortcut (from Apple shortcuts). If everything works out (it does most of the times!) a note is created in Obsidian.
I attached a screenshot of the note, because I don’t have a good way to share it with you otherwise right now. Those bookmarks land in a folder called /sites. I can add tags and link them to my notes, or references the bookmark in a note somewhere else. It doesn’t save a complete copy of the bookmark. So if the website disappears from the web, my bookmark would cease to work. Maybe that is something that I will add later. I am not sure yet.
So yeah, Pinboard is dead as far as I am concerned.
I canceled my SetApp subscription
Yesterday, I canceled my SetApp subscription. It’s around 110€ per year and I only use 3-4 apps from it. Did a quick i research and saw that I pay less for those apps if I buy them outright. And most of them will be supported for two years after purchase. Financially it’s a no-brainer and supports the developers even more. The apps I use?
I didn’t buy CodeRunner and Numi just now. The are both more expenssive (€20 and €35) and I don’t have a need for them currently.
A new Alfred workflow: Quickly open Merge Requests in GitLab
Synopsis
I created a workflow for Alfred so I can quickly open all the merge requests that are assigned to me. If the query “review” is added then all the merge requests where I am assigned as a reviewer are openend.
Background
I love to use Alfred to quickly to repetitive tasks on my computer. I use it to find the right emoji, modify text styles and text cases, convert images or units.
When at work, I also regularly have to open the overview pages on GitLab to see what status my merge requests have—or to quickly access them. I also want to navigate to the overview of the merge requests where I am assigned as a reviewer. Others might wait on my review or pushed updates.
All of that those lists exist as a bookmark in my browser. I can open them by clicking the bookmark. But then I have to decide whether I want to open a new tab or stay in the same tab I currently use. And I have to click with the mouse/touchpad.
This can be done quicker/easier: Open Alred (shortcut CMD-Space), type mrs and hit ENTER.
This opens the page where I can see the assigned merge requests.
If I want to access the MRs for review, I do the same but type mrs review. This overview is filtered for MRs where I haven’t approved yet.
Works wonderfully.
You can download the workflow from my GitHub repo
Vogelgesang während der Hunderunde
Heute morgen, während ich Milo spazieren führte, habe ich wieder Vögel bestimmt. Ich bin auf die App durch @Buddenbohm@fnordon.de aufmerksam geworden. Gerade bei uns am Kanal waren schön viele Vögel zu hören. Und ist es nicht schön? Sie singen so toll und ich kann endlich mal lernen, welcher Vogel wie klingt. Steigert nachhaltig die Naturverbundenheit. Und wer kann schon was gegen nachhaltig sagen.
Amsel und Gartenrotschwanz fand ich am Schönsten. Zaukönig und Buntspecht haben mich überrascht. Ich habe auch noch Elstern gehört, konnte sie aber nicht aufnehmen, weil der Hund da wieder Blödsinn machte in dem Moment.
Habe jetzt 10 Vögel in meiner Life List in der App. Mal sehen, welche ich auf der Nachmittagsrunde vernehmen werde.
The comprehensive guide to doing pull requests
This is a guide on what I consider the best way to do a pull request1. There are many ways to do this. I consider this to be the best way because of my experiences doing it like that with different teams. The results tell me that I am right. But first: What is a pull request?
What is a pull request, or: How should I integrate my changes with the code
To make any of this work, you need to be using a version control hosting provider like GitHub, GitLab or Bitbucket. All of them provide this functionality, Bitbucket even provides it for Mercurial repositories. I use Git with GitHub and GitLab.
A pull request (from here on I’ll call it PR), sometimes also called Merge Request (in GitLab) is a way to integrate the changes you made to the repository (the code base) with the master branch (that’s the code that goes live to production). I will not go into using Git too much right here, there are other articles about that. If you need a refresher on Git and branching, please come back after reading these articles.
So let’s assume you wrote your changes on your own branch, which I’ll call feature/MIH-318-my-feature-name. You already can see three things here:
Now it’s time to get these changes into testing (Staging environment or whatever you’d like to call it). Therefore you pushed your branch with the latest changes to your repository (origin) and open a new pull request to merge the changes into the master branch.
Why should you use PRs?
Using PRs gives you an incredible valueable feedback mechanism. This shares the responsibility of the work and makes sure you don’t break the application when things go live. This is because a PR is a great opportunity to catch bugs early on during the cycle. Catching bugs and errors earlier in the development cycle reduces the costs to fix them. After all, they didn’t interfere with other (new) code yet and are (hopefully) compartmentalized. PRs are also a good form of documentation, because of the description and discussion happening in a PR.
How do you do PRs?
Before opening a PR
I advocate for using before-commit hooks in Git. These hooks enable you to run custom scripts before commiting changes. There a quite a number of quality checks, if you ask me (and you kind-of do, since you are reading this! 😉), and almost all of them should be run before comitting your changes. I’ll mention the checks later on, as well.
Baseline measurements of a PR
One of the most important things to remember when doing PRs: Don’t let them get too big. A size I found to work well was around 400 lines changed. While this is no hard limit, going over it tends to incorporate too many changes at once. This makes the review harder for the reviewers.
Another thing not to lose track of, is the number of days a PR is open. You should review PRs as soon, as they are assigned to you, or when you are being mentioned in their description (or in comments). It is your duty not to let your team wait for too long on your feedback/review. If there are no major errors in the changes, a 400 lines feature should be reviewed and merged within 1–2 business days.
Who do you assign a PR to? Who should review?
This depends very much on your team structure and how you are organized. If it is possible, it would be great to get two people to review your changes. A healthy mix could be one person from your immediate team, and another one from a different team. This can have the benefit of a different perspective. The one from the outside-team probably doesn’t know too much about your feature and the specifics of your code. This forces you to be extra detailled when writing your description and documentation and they might not make some assumptions that you and your team take for granted. This situation needs to be handled carefully, you don’t want to get derailed by fundamental questions. But it could also prove to be beneficial to your feature, ymmv. It also increases knowledge across team boundaries, which I consider to be good practice.
If cross-team doesn’t work for you, try to get a more experienced (or same level as you) and a less experienced person from your team. While both reviewers will help you improve your result, the less experienced might get a chance to learn from reviewing your code.
In any case, @mention your reviewers in the description and (if possible in your software) assign the PR to the one you want to be responsible for merging.
What should you write in the description of a PR?
The first thing that you should write is a good title. This is the first thing that reviewers see, and it usually also goes into the emails they get about the PR. So make sure they understand what it is about. This is also a good place to let the reviewers know if you only want a review, without the goal of merging the PR. Perhaps you have an early draft of your feature, and want guidance on the general direction. You can do that by prefixing your title with something like
WIP: Integrate Stripe as payment provider
This WIP (work in progress) makes your intentions clear. If you are using GitHub, common practice is to use labels for that. So you could have a “Do not merge” label, or again a “WIP” label. I tend to always write it into the title as well, so people can’t miss it.
The next point to take care of is the description. This is where you should spent most of your time, when creating a PR. Consider writing about the following points:
If it makes sense, you should add screenshots of the before/after situation. If your changes contain animations or important visual effects, provide a gif or a short screencast of your changes.
Finally, make clear what you want the reviewers to look for, test or what they should comment on. If they follow this guide, they will look for more than that, but it is always appreciated to get a little guidance from the author of a PR.
Don’t forget to link/reference the issue/ticket in your management software that this feature/PR belongs to.
What role does CI/CD play in your PR?
My guideline for development workflows leans heavily on having a CI/CD server that orchestrates the whole workflow. CI/CD means continuous integration and continuous deployment. There is a lot to CI, and why and how you should do it. Look for multiple articles on that from me here. For the time being, you can get a wonderful introduction to the subject from another expert: Martin Fowler on his site.
Your CI server should do certain steps when a PR is opened. These include:
If you make your CI server report all linting errors, you free your developers to focus on the changes in the logic. Imagine the case where reviewers wants to check your PR, and the first thing they have to do is create lots and lots of comments about linting violations. Nobody will be able to focus on the really important changes and the discussions will grow very big. So let your robots (CI server) handle that for you.
How do you review a PR?
The first thing you should do is read the title and the description thoroughly. Your co-worker took her time and made sure you can get all the information you need out of the description. So read it carefully. Take a look at the screenshots and videos, so you get a sense of what it looks and feels like.
The next thing you should do? Check out the branch locally and run the tests. If the PR isn’t WIP anymore, the tests should all be green. On the CI server as well as on your machine. It is important to run the tests on your computer as well, because you could have a different setup with your database that could surface a hidden issue. Or you are using a different browser than your co-worker so you might see certain problems that are browser-specific. Looking at the feature on your computer provides the benefit of becoming more intimate with the changes and being able to look at them in a bigger context. The review interface on GitHub and GitLab often only show the changes and small amounts or neighouring lines. On your computer, you can see the whole glory. This is good for context.
When you find things that you want to comment on, please do this kindly. Be generous, everybody makes mistakes — even you. Write your comments as questions. This could look something like:
> I noticed you instantiate the Foo class inside the constructor. What were your reasons for doing that?
Even if you already know, that dependency injection would have been a better choice for this spot, help the other developer figure it out by asking questions. Do not tell them what to do or to change. Show them the direction, point them to places they could learn about how they could do it better, or explain why you think something might make more sense if they do it differently. The more context you provide and the more care you take to explain your questions and suggestions, the easier it will be to improve the code.
Remember: You are not your code.
Things to look for when reviewing a PR
There things that your linter won’t catch. These are long or unclear variable or function names. There might be code that is commented and can be deleted. Perhaps it was there from an earlier version of the code, as a draft. You could even find violations of the style guide, that the linter did not catch.
Perhaps your team writes documentation, like in classic docs or in a wiki. Was it updated correctly? Can you understand what was written? Is the ticket’s status updated and are all references to other issues or related changes present? Perhaps you can point the author to other changes in the code, or features or resources that are related to the thing you are reviewing (mailing-list threads, help-desk/service tickets, blog posts, articles or books)?
Take a look at the commits that are part of the PR. Do they conform to your commit-message guidelines? Do they make the feature’s history clear? What do you learn from scanning them? Are there any changes necessary?
Let me state again that the most important thing is to be polite, helpful and respectful of your co-workers. PRs should be a place to improve (the code and yourself) and to learn.
Best practices on doing pull requests
This section will deal with a few best practices that should increase the quality of your PRs as well as make your life easier, when using PRs.
Deploy a test build
I wrote about it before, but you should have your build server (or continuous integration server) deploy your branch-to-be-reviewed to a seperate, clean staging environment. This is where testers can have a look at your changes. This environment is a 100% copy for the production environment. The only thing missing is the real data from production (since that’s sensitive data). During the deployment the CI server will populate the environment’s database with seed data that is close to the data on production (and mirrors the size of production’s database).
You could name this a staging or remote test environment.
Document the lifecycle in your project management tool
It doesn’t matter whether you use JIRA, Trello, Asana or something else. As long as the tool integrates with your build environment and repository in a way, that you can easily jump between the ticket, the PR and any documentation on the wiki. The ticket needs to document the complete lifecycle from the creation of the new branch with every commit on it, to the PR and the CI server’s build results as well as the merge and deployment to the remote-test environment and, lastly, to production. You want to have a clear audit-trail easily accessible. This is not done to be able to point fingers, but to be able to understand why things are the way they are. Even 12 months later. That’s what your project management tool is responsible for.
Merging when everything is green and 👍
Merging PRs can be a story in itself. The most important thing is: Only merge when every reviewer gave you the thumbs-up and when the CI server indicates that there were no errors at all.
The merging should be done by the assigned reviewer. If there are multiple people responsible, you can talk about who should merge. It shouldn’t be the author of the PR. Allowing the author to merge her own changes leads to a bad practice where people merge to quickly, without a proper review. Other than that, it doesn’t matter whether the person merging is more or less senior than the author.
Where do you merge into, or: What’s the base branch?
The simplest strategy is to merge a feature branch (and most other branches) into the master branch. This is usually the branch that gets deployed.
It could be, that you follow a different dev methodology, like git-flow. If that is the case, you will probably merge into develop. So your base branch would be develop.
No matter what your base branch, note that:
Smaller features make merging easier
The less changes you want to merge, the easier it will be to review them. You should count on the fact that development of other features will continue while you are developing your feature branch. Those might have started earlier, or there were other branches that fixed bugs. In any case, your base branch will have moved on and evolved. It had a certain state when you branched off of it, but that state won’t be the same it is in right now. The longer you wait with your feature, the more work you’ll have to do — after you already thought you were done — when you want to merge your changes. This can be frustrating. You wouldn’t be the first one to introduce bugs at this point. Since the code has evolved, you are not yet that familiar with the new pieces. But you’ll have to make your code work with them. That’s where bugs are hiding.
The smaller the feature, the earlier you can merge and the less painful a process it will be.
Commit early and often with good commit messages
I wrote about it before: Let your commits be small and many. Your commits should follow the SRP (Single Responsibilty Principle). Your commit should change one thing. It might and could have side-effects. But it’s purpose it to change one thing. In your commit message’s subject (50 char length at max) you should succinctly describe what changes this commit introduces. Whenever you reach to the word “and”, you know your commit is too big.
A clean history of 2000 commits that are each tightly scoped and with clearly written commit messages is easier to understand and more helpful than 200 commits that each contain countless changes with minimal commit messages. Bad examples for commit messages, that are too often, are “fix”, “kill bug”, “add stripe” etc.
The commit message serves as your audit trail to your future self. Perhaps you have to do software development for a few years, but there will be a time where you scroll through your commit messages, searching for this one commit that helps you understand why a bug occurs, or why a library was rolled back to an older version. I’ve seen it with enough teams, that I really suggest you start improving your commit messages.
Do not squash your commits
This might be a contested opinion, but I am against sqashing commits. Please see the point above, but your commits paint a picture and tell a story. Squashing them loses this. Sure, the changes are there, but you are not able to identify how a change came to be.
There is one situation where squashing improves things: When you commit your code, without taking care to write good commit message or how to reduce your commit sizes. Then you squash your commits in the end and write a good, detailled commit message, that adheres to the before-mentioned best practices. This does increase the quality. The history, the how is still lost, but at least you can understand that one commit. That’s still better than many commits without proper messages.
There are people that do not like merge commits. I understand the reasoning, it seems to be an unnecessary commit. This is true, you can prevent this when rebasing your changes onto the base branch. This can be difficult if your repository changes very quickly.
If you do need to squash before merging (I don’t know or understand why, please tell me!) please only do it right before merging. Don’t do this when opening the PR. Your reviewers should be able to have a look at the history of the development of your branch.
Use templates to make your lives easier
Now that I explained why you need a well-written description and detailled commit messages, you might wonder how you can facilitate their creation.
I would propose you create templates.
We’ll start with commit message templates.
Git commit message template
Inside your project folder, you’ll find the .git folder. Open the .git/config file in your favorite text editor. Add the following lines:
[commit]
# can be local to your project or global
template = path/to/your/.gitmessage
It makes no sense, to create this for every project, so you can add this inside your global git configuration. On unix systems this can be found in
~/.gitconfig
You would add the same thing in there. I would propose you create a repository for your company or department where you store these templates. This makes it easier to update them for the whole team. Then you just clone the repository and link it correctly: template = path/to/cloned/repository/.gitmessage.
This is a basic template that you could tweak:
# 50-character subject line
#
# 72-character wrapped longer description. This should answer:
#
# * Why was this change necessary?
# * How does it address the problem?
# * Are there any side effects?
#
# Include a link to the ticket, if any.
#
# Add co-authors if you worked on this code with others:
#
# Co-authored-by: Full Name <email@example.com>
# Co-authored-by: Full Name <email@example.com>
You would have this pasted into every commit message you create as a comment (the # signs denote comments in git messages). Then you never forget what to write about.
These templates work locally for every developer.
Pull request templates
If you use GitHub or GitLab you can create a template that will be used when somebody creates a PR in your repository. It works mostly the same as the git commit message template: Your template gets pasted into the description of the PR and you can use it as an aid to fill in the textbox. As far as I know, there is currently no way to require certain information to be filled out.
A way around that would be to have your CI server parse the PR description and complain on the PR if certain things are missing. This would mean that your developers need to be very disciplined in filling out the description, or else risk complaints by the CI server. If you would be interested in something like that, I will show how to do that in another article.
If you are using GitHub, you can find their description on how to use a pull request template on their help pages. GitLab offer a similar description, showing you how to create merge request templates for their service.
Both services let you use markdown to write your descriptions. There are some useful additions to Markdown available for you. You can put them to use in your template, so your developers gradually learn to use them properly. One of the biggest features is to create checkboxes in your description (or comments). This is done like this:
- [ ] Make logo more bigger
While your checkboxes won’t be mandatory to be checked for your pull request to be accepted, they do provide a nice visual cue about any open tasks.
Merge the pull request
I said it earlier already, the person merging the PR shouldn’t be the one who opened it. This helps to enforce the principle of four-eyes (or less, depending on your developers).
Finally the PR is merged and you can work on the next feature.
🎉
Another day, another stream
Yesterday I’ve streamed for another 2 hours. While I started with a “Just Chatting” segment, I quickly turned to programming again. Not least because I was only chatting with myself 😂.
Eventually I started with implementing an algorithm for “rolling weeks” in my chores app. Have a look to find out what that is about 😉
Spent 2.5hours streaming today
I spent 2.5hours streaming today. Last year I took up streaming and did around 2 hours in total. Today I just continued and didn’t stop until it I had to take a break 🚽🫣.
Since I am still waiting on hearing back from from the Pinboard.in creator about their API status, I used the time I had to work on a new ap idea of mine. It’s about an app to manage the chores in our house and who’s doing what. We had a system to manage it for about two years now. Our old method used pen and paper and we reached its limit. The new app will hopefully let work better.
The streaming was fun. I didn’t have anybody watching the stream. But I didn’t mind. I did receive my first at spam comment though! 🥳 I regard that as progress: A first step out of irrelevance 😂
Since I am without client projects right now for reasons I will get into later, I simply will use the time to stream and build my app.
If you want to have a look within the next days:
Dev note for catalog 2023-10-20
What I was able to achieve
Today I continued work on the catalog. I streamed for about 90 minutes to Twitch while working. I continued work where I had left it the last time which were the tests for the route /entries. The goal was to get a passing test where the entries are rendered with their titles.
It took me longer than I care to admit but in the end I noticed my error and was able to get a passing test.
Next I talked a bit about the architecture decision records that I use to document my decisions on how to build things. I used a new ADR to document my decision about integrating the Pinboard.in API. Since a lot of my entries will come from Pinboard, I wanted to include the API access early on. That way I am able to get content to display “quickly”. At least that was the plan. I decided against using an existing Gem for Pinboard and will write my own API wrapper. While reading the docs for Pinboard I noticed that there is a new API v2 in development. I will use that new version.
I had to quit the session just as I was about to make a successful authenticated API call. Since I develop in a test-driven development style I had written a test that tests for the unauthenticated access. That test is successful in checking the 403 return code of the response. The successful/authenticated test case is not successful, yet. This is were I will continue next time.
My plan is to get started with that rather quickly, and then fetch entries from Pinboard and display them on the site.
About the streaming
I believe no one watched. I am not sure, Twitch told there was one visitor, but I believe that was I, monitoring the stream and watching for chat messages. So yeah, speaking into the void — but it was fun. I definitely need to improve my stream game. Switching between the VSCode and browser window is annoying. Don’t know how to do it better, yet. I will try to watch some other software development streams to get some inspiration how they do it. And my VSCode was probably too small to read. Well, next time!
Safari profiles. A nice start but not done well enough
I tried to use Safari for a week now. The new PROFILES feature lured me in. Unfortunately it is still not what I need from a browser and Firefox just keeps ticking almost all of my boxes. What turned me away from Safari again: Once you close a window with a profile, Safari doesn’t remember the tabs you had open. So closing a window means you need to reopen all of them once you want to continue your work. My clients all get a separate profile in my browser, but I tend to leave tabs open for later. That doesn’t work with Safari. In Firefox I use the extension “Simple Tab Groups” and it works nearly perfectly. I can even change between groups in the same window. Sadly, the compartmentalisation doesn’t work quite as well as in Safari. The tab’s context is shared between all tabs. So to separate those as well, I use another extension “Multi-account containers”.
It adds the mental overhead of choosing the right container. But it’s doable.
What drove me to try Safari again was the idea that the profiles would be synced to iOS and iPadOS as well. Since I don’t like to use Firefox mobile because it’s simply a mobile browser with really bad UX, I have to deal with using Safari on mobile and not being able to share browsing sessions between my Mac and my mobile devices.
Maybe there exists a Safari browser extension that reopens closed tabs? Maybe I should create one myself? I don’t know. 🤷♂️
Ich habe meine Website umgezogen, komplett vom iPad aus
Bisher ist meine Unternehmens-Website mit fly.io auf AWS gehostet. Das ist nicht grün und nicht gut. Tatsächlich habe ich mir bisher nicht die Zeit genommen, das zu ändern. Ich wusste, was ich ändern möchte — z.B. den Hoster. Aber im Alltag war mir anderes meist wichtiger. Auf der Konferenz war heute ein inspirierender Talk zu dem Thema, was wir als IT Professionals tun können, um einen Beitrag zu leisten die Stärke der Klimakatastrophe zu verringern.
Ich hatte mein iPad dabei, also habe ich die Seite umgezogen. Dafür konnte ich die Blink Shell app nutzen, um mich per SSH zu meinem Server zu verbinden. Außerdem habe ich auf GitHub Codespaces die notwendigen Anpassungen am Code für die Next.js App gemacht und die GitHub Actions Workflow Datei geschrieben. Und dann konnte ich committen und hatte einen Deploy, der nun wunderbar funktioniert wann immer ich Änderungen zu GitHub pushe. Und nun läuft meine Website auf einem deutschen Hoster und mit Strom aus erneuerbaren Ressourcen.
Ich finde es toll, wie viel Arbeit mittlerweile am iPad möglich ist. Ich mag das ja immer wieder.
Visuelle Markierungen im ebook Reader
Als ich gerade diese Stelle markiert habe, fiel mir auf, dass die Trennungsstriche, (wie heißt das korrekt?) der getrennten Wörter auf der rechten Seite, nicht in der Markierung enthalten sind. Und ich vermute, dass das technisch gar nicht so einfach sein wird, bei den getrennten Wörtern zu berechnen, bis wohin die visuelle Darstellung der Markierung gehen soll. Na wie auch immer. Fiel mir grad auf. 😊
Teenager Wlan
Seit ein paar Wochen spinnt unser Wlan daheim. Vielleicht zählen Wlan-Jahre doppelt oder so. Wir sind vor 6 Jahren in das Haus gezogen. Eventuell ist das Wlan jetzt also 12—Teenager halt. Und so benimmt es sich. Macht was es will, sagt „mir doch egal“ und „verschwinde“. Vor allem aber: „Lass mich in Ruhe!“ Und macht die Tür zu.
Habe schon versucht die Fritz!box zurückzusetzen, schrecke aber vor der Neukonfiguration zurück. Mir ist bekannt, dass ich eine Config Datei speichern kann, aber ich traue dem Braten nicht. Neustart allein reicht aber nicht, also komme ich vermutlich doch nicht drum herum.
Wie sich das Rumgezicke äußert? Die HomePods brechen einfach zwischendrin die Musikwiedergabe ab, und sind dann nicht mehr verbunden mit dem Internet. In Videocalls ist die Verbindung manchmal schlecht, oder ganz weg. Die Sonos sind manchmal verbunden, manchmal nicht. Und der Repeater in der ersten Etage muss ständig neu gestartet werden, damit da oben halbwegs Wlan ankommt.
Es nervt.
Blödsinn, TikTok und mein Schlaf
Berlin, 17. August Kennt ihr das, wenn ihr irgendwo etwas lest/seht und euch das die nächsten Tage weiter beschäftigt — obwohl es eigentlich Blödsinn ist? Bzw. ich weiß gar nicht, ob es Blödsinn ist. Jedenfalls hat vor ein paar Tagen jemand auf TikTok behauptet (so fangen die dümmsten Stories an 😜), dass „mein“ Stoffwechsel „resettet“ werden müsste. Klare Anzeichen dafür wären, dass mir 7-8h Schlaf nicht ausreichen würde um morgens nicht müde zu sein, dass ich nach dem Mittagessen in ein Energieloch fallen würde und müde wäre usw. usf. Und nun wache ich seitdem morgens auf, schlief mind. 7h, und bin groggy. Ja ich habe sogar einmal verschlafen seitdem! Stell dir vor! 😅
Also: Meine aktuelle Arbeitshypothese ist, dass das Blödsinn war und er nur sein achsotolles Programm zum Stoffwechsel-Reset (Blödsinn!) verkaufen wollte (Blödsinn!) und ich einfach nur gerade wieder einmal viel zu viel Stress im Job habe (kein Blödsinn 🤨).
Ansonsten bin ich heute das erste Mal nach dem Unfall und der OP mit meinem neuen Gravelbike zum Büro gefahren. Nun steht es hier auf dem Balkon neben mir, und ich freue mich jedes Mal, wenn ich rausschaue.
Ältere Damen im Wartezimmer
Heute erneuter Kontrolltermin im Krankenhaus für die Schulter, inkl. Röntgen. Die Frau an der Anmeldung beim Röntgen entfernt ihre Ohrstöpsel/Kopfhörer als ich sie anspreche. Ich bin ob dieser Tatsache etwas verwirrt. Nachdem ich 2min im Wartezimmer sitze, bei den beiden älteren Damen, die sich »angeregt unterhalten«, verstehe ich sie.
Why I opened a pull request to Rails (again)
It’s been a few years but I finally opened a PR to Rails again. github.com/rails/rai… The situation is a bit yak-shaving: I wanted to update to ActiveRecord v7 in my client’s app. In order to be able to do this I needed to update the gem sensible_logging. This gem is stuck at Rails < v7 though, so I created a PR to update the Gem which in turn surfaced a bug originating in Rails, hence the PR to Rails 🎉 My last PR was from Feb 3, 2015.
Tagebuchblogggen 28.2.2023
Arbeit
Beim Kunden bin ich heute endlich wieder gut voran gekommen. Die letzten Sprints haben sich gezogen, da ich große Themen hatte, die nicht immer in 1-Woche-Sprints gepasst haben.
Spaß 1
Ich bin heute über ein neues Tool gestolpert. Es heißt SketchyBar. Bevor du den Link klickst: das ist nur was für Leute, die gern mit dem Terminal unter MacOS arbeiten. SketchyBar hilft dir, eine Menüleiste unter MacOS zu erstellen, wie sie dir gefällt. Die orginale wird dabei ausgeblendet. Das hat den Vorteil, dass sie für dich perfekt sein kann. Das hat den Nachteil, dass du Zeit investieren musst, um sie so zu machen, wie du magst. Und das ist auch schon das Hauptproblem. Damals (TM) während des Studiums, und sogar schon Ende der Abizeit 2001, habe ich diese Zeit gehabt. Ich habe damals mein Windows Mac-artig gemacht. Da gab es die tollsten Tools, um das Aussehen zu verändern. Viel Gefrickel, aber es machte Spaß und funktionierte—meistens.
Heute würde ich mir wünschen, dass es jemanden gibt, der das für mich macht. Ich sitze jetzt abends auf der Couch und schreibe das. Dafür reicht es bei mir jetzt noch abends im Kopf. Aber jetzt noch am Rechner sitzen und Syntax & Semantik des Tools kapieren, und dann noch wissen, was ich erreichen möchte? Das geht jetzt nicht mehr. Also wäre es toll, wenn es jemanden gäbe der z.B. ein Patreon zu diesem Thema hat. Ich zahle einen kleinen Betrag, und kann mir raussuchen was mir gefällt. Vielleicht sogar einfach Copy & Paste machen und Dinge ausprobieren.
Spaß 2
Der viel größere Spaß heute war, dass ich über den Spielplatz gerannt bin. Ich habe die kleine Tochter abgeholt und den Sonnenschein genutzt. Der Spielplatz liegt direkt neben der Kita. Da kommt man bei schönem Wetter nicht dran vorbei. Richtig so! möchte ich sagen. Dementsprechend voll war er. Ich habe dann noch die große Tochter angerufen, die kam dann dazu. Gemeinsam mit einer Kitafreundin und deren zwei Brüdern haben wir Fange gespielt. Ein herrliches Vergnügen. Am Ende waren meine Schuhe voll Sand. Ich sehe das als Beweis dafür, wie ungehemmt wir Spaß hatten. Perfekt.
Daheim dann mit der großen Tochter noch Radschlagen geübt. Das war schwierig. In der Schule wird das wohl benotet (WARUM?!?!) und sie möchte keine 5. Naja, mit etwas Glück sind wir bei der 4 angelangt. Ist halt nicht so einfach.
Am Abend dann Grießbrei und hier bloggen.
Gelesen
Frau Herzbruch schreibt über eine Diskussion zum verfickten Angriffskrieg Russlands. Sie verfolgte diese, um fremde Standpunkte zu verstehen. Ich finde das gut. Leider ~bringt~ brachte das nur nichts. Und ich bin da ganz bei ihr.
Wisdom from Sandi Metz
„The verse method is getting simpler, but it still has more than one responsibility. This problem is reflected by the very structure of the code—the above method contains a blank line. Programmers add blank lines to signify changes of topic. The presence of multiple topics suggests the existence of multiple responsibilities, which makes code harder to understand when reading, and easier to harm when changing.“
Excerpt from “99 Bottles of OOP” by Sandi Metz
The book is full of small (and bigger) nuggets of wisdom regarding OO programming.