- Jan 2022
-
-
Network issues?
I did this too, even if I didn't have network issues earlier. I did it because I had network issues when installing docker on WSL1, so "better safe than sorry" kind of.
-
-
docs.docker.com docs.docker.com
-
$Env:ProgramFiles\Docker\dockerd --register-service
This didn't work for me. The following did:
cd $Env:ProgramFiles\Docker .\dockerd --register-service
-
- Oct 2021
-
angular.io angular.io
-
getHeroes(): void { this.heroes = this.heroService.getHeroes(); }
Never ever name
.getSomethinga method that does not return anything, but sets a property to that something. This is always.setSomething
-
-
-
To ease the burden of developing and maintaining these codebases, we created shared libraries to make common transforms and functionality, such as HTTP request handling, across our destinations easier and more uniform.For example, if we want the name of a user from an event, event.name() can be called in any destination’s code. The shared library checks the event for the property key name and Name. If those don’t exist, it checks for a first name, checking the properties firstName, first_name, and FirstName. It does the same for the last name, checking the cases and combining the two to form the full name.
If this problem was solved by means of inheritance, then all these and future complexities would vanish.
Each event should belong to an
Event<destination>class. This way, the.name()method would know how to return the name of the user directly, without any guessing. -
Testing and deploying changes to these shared libraries impacted all of our destinations.
Again, with event classes, no added complexities here, either.
-
While we did have auto-scaling implemented, each service had a distinct blend of required CPU and memory resources, which made tuning the auto-scaling configuration more art than science.
Why? I miss more details here.
As a side note, the other day I saw an interesting rule of thumb about elasticity. Grow to double, shrink to one fourth. Which is a strategy based on two thresholds instead of one. With one threshold only, it would grow and shrink repeatedly if the load was oscillating close to the threshold.
-
a small change that should have only taken an hour or two
There's not such a thing!
This is the typical statement of a developer, about to walk the happiest path in heaven. But when you get up to start walking that path, everything in hell gets in the way.
-
It felt like magic.
Oh, the power of mocking external I/O. This is a lesson any developer learns the first day you have to wait a couple of minutes to run a test suite.
Why is it so difficult to maintain an even level of depth and awe in a tech article? It happens to me too, when I post something to my blog.
-
We no longer had to deploy 140+ services for a change to one of the shared libraries.
I wonder if their inability to see they needed inheritance is the real problem here. Could it be that simple? If they had used inheritance, they would have needed to deploy only one service most of the times.
Tags
Annotators
URL
-
-
-
We no longer had to deploy 140+ services for a change to one of the shared libraries.
I wonder if their inability to see they needed inheritance is the real problem here. Could it be that simple? If they had used inheritance, they would have needed to deploy only one service most of the times.
-
It felt like magic.
Oh, the power of mocking external I/O. This is a lesson any developer learns the first day you have to wait a couple of minutes to run a test suite.
Why is it so difficult to maintain an even level of depth and awe in a tech article? It happens to me too, when I post something to my blog.
-
a small change that should have only taken an hour or two
There's not such a thing!
This is the typical statement of a developer, about to walk the happiest path in heaven. But when you get up to start walking that path, everything in hell gets in the way.
-
While we did have auto-scaling implemented, each service had a distinct blend of required CPU and memory resources, which made tuning the auto-scaling configuration more art than science.
Why? I miss more details here.
As a side note, the other day I saw an interesting rule of thumb about elasticity. Grow to double, shrink to one fourth. Which is a strategy based on two thresholds instead of one. With one threshold only, it would grow and shrink repeatedly if the load was oscillating close to the threshold.
-
Testing and deploying changes to these shared libraries impacted all of our destinations.
Again, with event classes, no added complexities here, neither.
-
For example, if we want the name of a user from an event, event.name() can be called in any destination’s code. The shared library checks the event for the property key name and Name. If those don’t exist, it checks for a first name, checking the properties firstName, first_name, and FirstName. It does the same for the last name, checking the cases and combining the two to form the full name.
If this problem was solved by means of inheritance, then all these and future complexities would vanish. Each event should belong to an
Event<destination>class. This way, the.name()method would know how to return the name of the user directly, without any guessing.
-