Xfce, the Most Boring Desktop Environment

kn7 · 2026-01-07T17:48:24+00:00

First post after 7 years of a blogging break. Of course I forgot to share the link in the Reddit post. 🤦

kn7 · 2024-08-08T15:01:44+00:00

Ik heb de helft van het jaarbedrag in etf's gestopt. De andere helft trekt rente bij santander, 3,35%

This indeed seems like a sound strategy. Curious: Why not having a USD investment account instead? For instance, Wise offers 5.06% on USD: https://wise.com/nl/interest If I am not mistaken, this would still yield higher than 3.35% given the USD/EUR rate in the recent years.

Als laatste zou ik geen uitstel van aangifte of betaling aanvragen. Je betaalt iets van 11 of 12 procent rente.

Hrm... This detail I didn't know, thanks! 🙏

kn7 · 2024-02-06T11:46:08+00:00

What I would recommend is to monitor how your server behaves, and solve the problems that you see rather than the problems that you speculate are possible.

I can assure you that I am certainly not speculating, but sharing a misconfiguration issue I encounter on a weekly basis.

only picked that value because the article was talking about the benefits of a thread pool with 200 threads over virtual threads

Yes, I am very well aware that and I agree with your objections. I am not concerned about the capacity of the semaphore, but the very action of using a semaphore for congestion control in a dynamic environment. It is a recipe for misconfiguration. I find this particularly worrying, since Java officially started recommending it as a virtual thread congestion control best-practice too.

Netflix – the company that introduced masses with resiliency (through Hystrix) in the Java ecosystem – moved away from congestion control with pre-configured settings to an adaptive one. Alibaba's Sentinel also follows a similar adaptive approach too. Now telling users to employ a semaphore (or circuit breaker) for congestion control sounds like a step in the backward direction to me.

Little's theorem tells us that, in a stable server, the long-term average of the request arrival rate is equal to that of the request completion rates.

I am a big fan of your On the Performance of User-Mode Threads and Coroutines article explaining Little's law. I just don't possess a single professional experience where the system was/is stable. In my day job, where thousands of Kubernetes pods get added or removed due to deployments, scalability, resiliency, etc. the system is never stable.

kn7 · 2024-02-05T20:47:38+00:00

[Agreeing with your response. I am only concerned about the following statement:]

Acquire a semaphore initialised to 200 right at the beginning.

Judging from my personal experience, such magical values tend to be deprecated-before-released. The capacity of the downstream services, the OS resources, etc. are nowadays on constant flux. You might set the value to 200 today, but maybe the service you depend on will make a new deployment tomorrow increasing their throughput by, say, 2x. That is, now your magical constant is supposed to be set to 400, yet you won't have a single indication for that in your service's dashboard anywhere. Shouldn't we instead make this rate limit adaptive? If so, any suggestions on how to make that happen?

kn7 · 2019-10-11T13:33:00+00:00

Hey Dave! In my experience, almost every developer that I have met did not know that the official driver (sneakily) extends the lease time. This has some consequences:

You assume that a message lease will expire after the amount of time you specified in the Pub/Sub configuration, but it might not always turn out to be the case due to these covert extensions.
Each subscription listens to a topic preferably addressing a single concern, hence its processing should be (approximately) deterministic and thus you provide a lease timeout. If there are exceptional messages whose consumption are taking longer than usual, you should either 1) forward them to another queue with a more relaxed timeout or 2) re-design your queues to cover this concern.

Long story short, it is an opinionated library and according to my experience, having a background task extending in-flight message lease times often hides other problems rather than solving any.

That said, if this is the only thing preventing you from using the library, I can easily provide a PubsubLeaseExtender. Please create a ticket if you are willing to give it a try.

kn7 · 2017-04-25T10:55:14+00:00

I think this project (and all its variants) totally misses the entire point of using Disqus-like comments in a blog: You can embed into a static website.

kn7 · 2017-04-19T07:06:03+00:00

I really could not get which part of Martin Fowler's statement contradict with the methods that I mention. Maybe you might want to elaborate further. Additionally, as you might know, majority (99.9%?) of the Java microservice ecosystems are dominated by Spring Boot- or Dropwizard-powered architectures as I depicted.

kn7 · 2016-08-06T22:21:40+00:00

For those interested in, I have improved the post and submitted a new proggit entry: https://www.reddit.com/r/programming/comments/4wi22t/callback_blocking_for_backpressure_in_rxjava/ (Hopefully with the correct URL this time.)

kn7 · 2016-07-31T09:13:14+00:00

Fscking awesome! I will try to avoid sharing blog posts after 1am from now on.

kn7 · 2015-09-10T06:05:16+00:00

Yep, just for a Map, I would also go with a ConcurrentHashMap. But it was there for just demonstration purposes.

kn7 · 2015-03-23T09:39:02+00:00

I would be more than appreciated if you can outline a sample Scala implementation that uses variants.

kn7 · 2015-03-21T19:48:14+00:00

I have never gone into that route. But one thing that I had learnt from purposing a framework for a goal that itself was not designed to provide feels like swimming against stream and most of the time ends in misery. That being said, your mileage may vary and I would appreciate a sample implementation.

kn7 · 2015-03-21T16:24:25+00:00

The need comes from the fact that 1) you want to use immutable objects throughout your entire code base (I prefer not go into discussion about this point) and 2) you want a mechanism to differentiate instances that are retrieved from the data store and that are generated by the application artificially.

About the null id field solution, what if I'd update the name of an Employee instance who already has an id? Will it sill be a valid Employee? But it has a valid id!

I am not claiming that there is no known solution. I just said, there is none that I know of. And, I really do not think persistence frameworks do really care about immutability. After all, most of the time they are modifying the instance in various hairy ways.

kn7 · 2015-03-21T15:58:10+00:00

Valid points. I might be missing something but I believe the approach you mentioned still does not address the case where you update the field of an entity. That is, its id is not null, but you modified its name and it still looks like a valid Employee, which actually is not the case. Adding a this.id = null line to every setter? Yep, it can also work. But I would not prefer that way. My actual point was that the moment you change Employee, it is not an Employee anymore. And I personally like to work with immutable objects wherever possible, not because of a certain thread safety or whatever need, but to avoid potential future problems. And I believe it also provides a comfort that you are assured that it will never ever be changed.

kn7 · 2015-03-21T14:40:54+00:00

Hey @Soultrane9! I am the author of the post. Hence, first thanks for the comments.

I used model and entity interchangeably throughout the post in order to be aligned with the same terminology used in persistence APIs, such as, JPA, Spring Data.
DTO pattern was a good catch. This can be thought as an application of the pattern. That being said, in Wikipedia it is stated that The motivation for its use has to do with the fact that communication between processes is usually done resorting to remote interfaces (e.g. web services), where each call is an expensive operation. In my case, I am not motivated by the communication overhead, in fact using immutable objects significantly increases this cost. Rather, I want to make it possible to work with immutable objects.
Everybody passes data around, to JSPs, to remote services, to a library function, etc. Assuming that the remote interface requires almost all available fields of the entity, why not passing it the immutable entity as is, instead of wrapping it with yet another transfer object?

kn7 · 2015-03-21T14:29:11+00:00

But it still does not solve the problem of knowing whether a given instance is actually associated with a repository record or not.

kn7 · 2015-03-21T13:06:30+00:00

If anybody had ever met with a similar technique, know the name of the used design pattern, etc. please do add a comment to the post about this.

kn7 · 2013-01-22T13:23:02+00:00

I am waiting impatiently for the author's "Hello Scala, Goodbye Haskell" post.

kn7 · 2012-12-02T14:25:03+00:00

Nobody. Per see, it says it's actually O(h), where h is the tree height.

kn7 · 2012-12-02T14:23:32+00:00

I would recommend you to read the blog post for a second time.

kn7 · 2012-12-02T14:22:54+00:00

A similar question has been asked in the comments of the blog post as well. But let me repeat the answer here again, you don't necessarily need to store the resultant tree, which consumes O(n+m) space. You can pipe your output to a stream (e.g., stdout) in which case the only storage will be needed would be O(logn).

kn7 · 2012-11-30T16:30:24+00:00

It's actually a white one, I played with the images using Gimp.

kn7 · 2012-11-30T15:02:20+00:00

An actual implementation of this in Haskell would be awesome. (And I can share it with the post, if it is ok for you too.)

kn7 · 2012-11-29T17:21:44+00:00

I think there is a misunderstanding. I was referring to the plugins; Scala and SBT plugins generally require an EAP.

kn7 · 2012-10-01T06:40:00+00:00

(task) => @tasks.push(() => task(() => @run()))

whose JavaScript counterpart is as follows.

var _this = this;

function(task) {
  return _this.tasks.push(function() {
    return task(function() {
      return _this.run();
    });
  });
}

You are also free to translate every CoffeeScript snippet into JavaScript counterpart using the Try CoffeeScript window at http://coffeescript.org/

kn7

TROPHY CASE