le bac à sable de Pierre

IntelliJ IDEA didn't want to start this morning. Got the following error when trying to start it from a shell: Error occurred during initialization of VM Initial heap size set to a larger value than the maximum heap size What happened is that IntelliJ IDEA loaded the JVM Options from the new custom vmoptions file in the config directory. On Windows: %APPDATA%\Roaming\JetBrains\IntelliJIdea2020.1\idea64.exe.vmoptions On macOs: ~/Library/Application Support/JetBrains/IntelliJIdea2020.1/idea.vmoptions This file was not updated properly when I updated IntellIJ IDEA. It contained: -Xms4g -Xmx2048m Fixed the issue by editing this file: -Xms4g -Xmx4g Source: https://intellij-support.jetbrains.com/hc/en-us/community/posts/360004701620-idea-vmoptions-not-used-by-default  

It is not that we have a short time to live, but that we waste a lot of it. Life is long if you know how to use it. It is a small part of life we really live [...] all the rest is not life but merely time. People are frugal in guarding their personal property; but as soon as it comes to squandering time they are most wasteful of the one thing in which it is right to be stingy. For suppose you should think that a man had had a long voyage who had been caught in a raging storm as he left harbour, and carried hither and thither and driven round and round in a circle by the rage of opposing winds? He did not have a long voyage, just a long tossing about. Putting things off is the biggest waste of life: it snatches away each day as it comes, and denies us the present by promising the future. [...] You are arranging what lies in Fortune's control, and abandoning what lies in yours. [...] The whole future lies in uncertainty: live immediately. Life...

I recently read Applying TDD to Scalding Development . The content of the article is interesting and still relevant but the example is implemented with the old Fields based API . Following is an updated version of the code using Scalding's type-safe API :

On Linux you can access your running Docker container on localhost or remotely by publishing the desired port. On macOS it will only give you access to the Docker container from the Docker-Machine it is running on, i.e. from docker-machine ip <machine_name> . To access it on localhost, you can use ssh port forwarding: docker-machine ssh <machine_name> -fNTL <local_port> :localhost:<machine_port> You can now access your Docker container on localhost:<local_port> . Bonus: Accessing your Docker container from a remote computer. By default, with ssh -L , the local port is bound for local use only. You can use the bind _address option to make your Docker container available publicly: docker-machine ssh <machine_name> -fNTL \*:<local_port>:<localhost>:<machine_port> You can now access your Docker container on <your_ip>:<local_port> .

Use case: an actor that must do something if it has not received any messages for more than a given amount of time.

I recently used TransferWise to send GBP to COP and I have been surprised by a tiny discrepancy, 11 COP (~0.0022 GBP), between the amount the recipient received and what TransferWise advertised he would receive. TransferWise support team explained me this difference as follow: When sending from GBP to COP, we receive GBP from your side and we convert the amount to COP with the mid market rate. However our partner in Colombia needs to receive USD from us, so we convert the amount in COP to USD with the rate our partner gives us. We send them those USD and then they convert them to COP and send them to the recipient. In your case what happen was the following: You sent us 1,000 GBP, we took our fee and convert 974.43GBP to COP with the mid market rate at that moment: 1 GBP = 4,970.50 COP. So that was 4,843,404.315 COP, however in COP there’s no cents so it got rounded down to 4,843,404 COP. After that we converted to USD since our partner need to receive USD from us. The ...