I did not realize that Node.js v10 has promise support for the fs module. Why is this a big thing? It makes it possible to write call-back free code like this:

items = await fs.readdir(path);
for (var i=0; i<items.length; i++) {
  console.log(items[i]);
  }

instead of the older call-back-style:

fs.readdir(path, function(err, items) {
    for (var i=0; i<items.length; i++) {
        console.log(items[i]);
    }
});

Also error handling is so much easier now via a simple try..catch block.

And in case you get the dreaded(?) warning message from node "UnhandledPromiseRejectionWarning: Unhandled promise rejection.", then simply add try..catch blocks or explicit catch handler for promises.

Azure has a habit of charging me more than I expect. Neither AWS nor GC does that and in both of the latter cases I'm either fully aware of the costs, or it's lower than expected thanks to the moderately generous free tiers, which I usually fall under.

But Azure is different.

During a workshop I used an "integration account" which costs staggering (about) US$30/day. To be fair, it's for enterprises, so it's actually not too expensive for what it does, but I used this by accident and it consumes all of the US$200 of have-fun-and-play-with-it in 7 days. I was not even using it for 6 of those 7 days.

The second time I try the very good Build a serverless web app in Azure. I like it a lot. Instructive, with command line instead of mouse clicking. Really nice and highly recommended. It's using a Dynamo DB database. I use 170 MB at 100 RU/s. That's 5 Yen in total for storage (no issue here), and 96 Yen per day for the reserved capacity. Does not sound too bad, but it's 3000 Yen (about US$30) per month while not using it.

AWS does have some tricky items too (load balancers, RDS instances, RedShift etc.) which costs, but I am aware of those and avoid them if I can. Google is usually cheaper than expected and I never had a negative price surprise either.

But Azure...twice they got me. There will be no third time. I'll have to learn their costing model before I'll use Azure again.

Replacing a battery from a normal watch is not that difficult with the right tools. The problem is: do you have the right tools? That was the question when I wanted to replace the battery of my Sony Wena Wrist (3 Hands).

Turned out to be easier than expected.

Simple Instructions

First flip the watch over and use a small flat screw driver to open the 4 screws visible in the back. They are not hard to open, so no excessive force needed.

Flip the watch back and carefully pull of the watch part from the strap part.

I was surprised how empty the watch actually is. Mechanical watches are full of stuff. Non-mechanical ones are full of...air and plastic spacer.

There is a thin black O-ring which is either attached to the top (watch) part of the bottom (base). It's supposed to be in the groove in the bottom base. If you lose or break it, the watch is no longer water proof...In my case it was stuck to the top part, so I had to take it and put back on the base bottom into its groove.

You can pull out the white plastic space lifting it from the knob side. Note the notch on the white plastic spacer. That side goes out last.

Then loosen the marked screw a bit. Then you can push out the old battery with a screw driver. Just push it gently from the direction of the center of the watch outwards. Put back a new battery. SR626. Once the new batter is in, tighten the marked screw again. And re-insert the spacer.

Flip it back on the base and screw it back with the 4 screws in the back. Done! 2.5 years no need to change the battery again.

Watching Uncle Bob's videos (those in particular where he refactors stuff with ease thanks to IntelliJ IDEA), I always wanted to try those IntelliJ IDEs out. Not for Java though as I'm not a big fan if it. When JetBrains did a special discount sale, I had to try it out: WebStorm for JavaScript that is. And heck, it's good. It's also complicated to set up, but it figures out a lot of things by itself, e.g. it understands package.json files, the run scripts inside, it knows linters, transpilers and so much more. But the learning curve is steep. And it takes quite some (about 20) seconds to get started. Sublime Text is way faster to start (less than 1 second), so that'll stay my go-to-choice for smaller things, but once a full project is set up, WebStorm is very helpful to have.

So this weekend I took some time to set up WebStorm for TypeScript with its transpiler, linter, unit tests etc. This video was a great help to get everything set up in a sensible way. I used another boilerplate setup for no particular reason. This is the result.

Once cloned and WebStorm is started, it'll ask to run "npm install". Let it do that. Open the file structure (top left) and you should see all files. Find "package.json" and double-click on it. Go to the section of "scripts". You should find them all automatically marked with a triangle:

If you click on the triangle for "test" and let it run it, WebStorm will:

1. run tslint
2. run tsc to transpile TypeScript into JavaScript into ./build/ for both source (in ./src) and tests (in ./__test__)
3. run the tests incl. coverage checks
4. report the result of all commands in the "run" pane
5. Also you now have "TEST" in the configuration:

Neat! I start to like WebStorm as I can see that it's made to solve the little problems programmers have. But there's a lot of keyboard shortcuts to memorize...

I was measuring air pressure during Typhoon no. 12 this year and here is a graph of the air pressure change while the typhoon was passing Tokyo. It dropped from 993 hPa to 984 hPa. While not a huge drop, it's still notable for the rate of change.

Here the path. Tokyo is where the blue dot is. It's quite far away and we had not much wind.