A few weeks ago, I decided to reactivate my podcast, "Herr Zenzes wills wissen". For the last few years, I hosted it with Podigee, but it became too expensive for my use case. I don't produce enough content to take full advantage of the smallest package, so I can save some money by hosting the podcast myself again.
April has started with a few minor updates that I'd like to share here on the blog.
There are topics in the IT world that divide opinions: what needs to be tested, test-driven development, do we work alone, in pairs or even in a mob? Do we need estimates for tickets?
Today I want to discuss estimates and why I think they are essential in a dev team. I realize many developers see it differently because estimates have an awful reputation. Critics say that they don't bring much to the team, take a lot of time in meetings and at the end "management" gets a statement when which feature is (guaranteed) available. In the sprint, people are then also quick to talk about why a supposedly small task is taking a long time. So, we have something that costs us a lot of time as developers and makes life difficult afterward because someone converts story points into time. And sure, if that's how estimates are lived in team, then I would question them in that form as well. But estimates can also be useful, help the team and help to plan things.
Today I updated an article that is about automatically switching Node.js version with nvm. In the course of this I wanted to delete two old articles and bring them to the current article via an HTTP redirect.
As I host my blog on Netlify, all I need is a _redirects file with the redirects:
As a frontend developer, you may find yourself working on projects that require different versions of Node.js. Manually switching between versions can be tedious and easy to forget, especially if you're working on multiple projects simultaneously. Fortunately, there's a way to automate switching to the correct Node.js version whenever you enter the project directory. In this post, I'll show you how to set up auto-switching using nvm and zsh.
In one of my previous articles I described the difference between strategy and tactics in software development. In this post I want to describe, what can go wrong, if you focus on tactics and ignore the overall strategy. Lets take a situation I have seen at many companies: a new project is born and some people can create something from scratch. Most of the times this means that technology decisions that have been made before, can be questioned and the new scope maybe allows to try out something new. Maybe something that is easier to use or faster to setup. This can have both positive and negative consequences:
Cole Peters (@colepeters@mastodon.online) on begin.com:
For years now, the most popular JS frameworks have carried out intense marketing initiatives based on the premise of improving DX
The whole thing goes, however, as in other ecosystems that developers categorically exclude other frameworks as "bad" and some now and then only see the next nail they can hammer.
My toolchain consisted of HTML (version 4), CSS (version 2), and a sprinkling of jQuery on those rare occasions when I could understand how to use it.
Those were the days. I still fondly remember one of my first jobs, where we uploaded our .jars (built by Jenkins, after all) to the production server via FTP. Don't worry, I'm not suggesting that now as the better alternative to a CI/CD pipeline. However, I did learn a few things about Java and application servers there that still help me today.
As a member of a developer experience team, I often get asked what I do, and why it is important for a company. The truth is that developer experience (DX) is a critical aspect of software development that impacts the productivity, efficiency, and satisfaction of developers. In this blog post, I want to shed some light on what DX is, why it matters, and some of the benefits as well as negative aspects of having a DX team in place.
I'm working on the migration of a monorepo from Vue.js 2 to Vue.js 3 right now. As we are in a monorepo we can migrate our applications stepwise but got into a situation where suddenly our Vue.js 2 tests failed with the following error:
Vue packages version mismatch:
- vue@3.2.40 (...)
- vue-template-compiler@2.7.8 (...)
This may cause things to work incorrectly. Make sure to use the same version for both.
If you are using vue-loader@>=10.0, simply update vue-template-compiler.
If you are using vue-loader@<10.0 or vueify, re-installing vue-loader/vueify should bump `vue-template-compiler` to the latest.
This didn't make sense to me at first because we don't have any project that uses vue-template-compiler and Vue.js in version 3. So, why do we see this conflict?