A fellow trainer asked me some questions about my remote training setup, especially:
So, here is my setup and how I currently run those trainings…
Should companies invest in agile engineering practices—training people on their engineering teams and giving them time to improve? And if they should do that, how much should they invest?
In this article, you will learn why it makes sense for companies—from a business point of view!—to allow their developers to grow professionally, to help them grow and to invest time and money in ways to improve the skills and practices of their teams.
When we write interaction-based tests, using mocks or spies, we make it harder to change those interactions later (*). We make it harder to do some kinds of refactoring! But does it matter?
Not necessarily - there are ways to use those test doubles so that the benefits outweigh the cost. But when you use them to write tests for a bad design - for code that’s hard to test - you are doing it wrong.
And your tests will come back and bite you later.
Over the years, I have been trying different ways of writing commit messages - And I now think that it’s best to write a present tense commit messages that describes the new capabilities of the system I am working on.
Let me explain…
In the chapter “Naming Things” of my book about “Agile Engineering Practices”, I wrote that you should name intermediate results (I will link the whole sample chapter at the end of this blog post).
But sometimes, it’s not that easy…
In my TDD trainings, I sometimes say that I do not test code that is “too simple to break”; Code where:
What do I mean by that? In this blog post, I’m going to explain…
In the last three parts of this series, I wrote about how one can use the webpack’ed version of a ReactJS application as a template engine for spring boot, how routing and navigation can work on the server side and how to improve the first-load performance of this app.
There is one thing missing in this application: The server side rendering does not use any dynamic data at all yet. With this blog post, I want to change that: I want to show you how the server can pre-render data that the client would usually fetch dynamically.
In the first two parts of this series, I wrote about how to use reactjs together with spring boot on a GraalVM and how to use the same routing / navigation on the server side and in the browser.
Today, I want to look into whether rendering on the server side is even worth it. TL;DR: Out-of-the-box, the improvement in time-to-first-render was not that that much. But with a few tricks, I was able to reduce the time by ~60%.
This worked well for the simple example app that I had. But what about navigation? We need the same routing on the server side and on the client side, otherwise the server would render the wrong content when the user reloads a page.
And here’s how I did that with react-router…
Since our country is in lockdown now and I cannot (and do not want to) continue with my usual videos, here’s a “normal” blog post about some fun thing I was trying recently. I wanted to use reactjs (TypeScript) as a template engine for server-side rendering in spring boot (Kotlin) so that…
create-react-app(almost) without modification
I am not there yet. But I already got the first four bullet points covered, and I am working on the fifth. So, here is what I did so far…