_     _             
                        _ __ | |__ | | ___   __ _ 
                       | '_ \| '_ \| |/ _ \ / _` |
                       | |_) | | | | | (_) | (_| |
                       | .__/|_| |_|_|\___/ \__, |
                       |_|    ...2017-11-15 |___/ 

Not dead

If I was only writing here all the things I'm thinking to write, such a great big place it would be, but I too often don't get it done, only thinks about it.

Surely You're Joking, Mr. Feynman

It's a wonderful book indeed! I'm having a great time reading it, and I feel very much that I can't avoid taking on the tone of the book when writing. There are many funny anecdotes and observations that I think many people can still recognize in society today.

Other books

I read "The Soul of a New Machine" and "Dreaming in Code" recently, they are also really great, and both definitely worth reading for anyone with either an interest in the IT industry or computer history, and the stuff in "Dreaming in Code" seems to be as true and relevant as ever.

Trip to London

My girlfriend and I went to London for a few days to look around, I've never been there before, and was surprised to find that most people didn't speak english very well, now, I don't mean that British is intelligible, rather that there aren't many brits present there at all. I was surprised by that. The Underground and bus transport systems worked very well, and it didn't take many minutes of thinking to figure out how to get from one place to another, even though it's a very big place. Found resturants advertizing as Authentic X, substitute X for any word except British or English, so I didn't have a chance to find out what kind of food were supposed to be typical, or, traditional at least. I did have a reasonable enough pizza and some nice Indian food there, so that was nice. Hotel breakfast was sub-par, but edible. Prices were about the same as in Denmark, so, not suprisingly expensive, it's just that I also think that Danish prices are generally unreasonable. The museums were awesome, and I could definitely spend some more time in both Science, Natural History and the British Museums (the British museum is basically the treasure chamber with all the stuff the empire stole from the rest of the world, back when that was an acceptable thing to do, and, so far, since many of those places are now war zones or just generally undesirable, it seems that stealing all those things were actually saving them, so it turned for the better I gues). But for the museums, and the interestingness of the place, I never got the idea that it might be a place where I'd want to live or work at any time in my life, maybe for 2 weeks, but not more. Not that there's anything I found negative about it, in my 4 days of visit, just, that there wasen't anything I thought especially appealing about it either.

Eat your own dogfood

Headline stolen from "Dreaming in Code" I think test-driven development holds some value, my theory being, that when working on big systems, it will allow you to do much of the plumming of a new part without the turnaround overhead of the big system (starting/stopping/con- figuring) to see how each new change/progress works out. My idea, is instead, that if you define a reasonable interface to your new part, you can trivially plug it into your big system, but, you can also, trivially, plug it into a unit-test, meaning that, you can write your unit tests first, and then put the flesh on your new part. At least, that's my theory, and it's where I see the very most value, there are other good things, and I don't disagree with their importance, but for me, personally, what I think I can get more happiness out of, is what I mentioned, being able to make changes, and see if they work, in a second or less. Except, often, the second part is not trivial. It's easy to plug something new into the big system, because there's a big system ready to support the new part.. But, in a unit test, you start out, potentially, with a lot less, and you end up havig to implement a lot of code to build for your new part, an artificial environment, that behaves ENOUGH like the real big- system. I was pretty sad to see that "nock" is the best "request" mock around, it pollutes the global request definition because someone are not writing code meant to be tested. Writing code for test-driven is not hard, and it does not even have to be more inconvenient, example time, psudo code. annoying-to-test.js:
const repository = require('the-repository.js'); module.exports = function SillyAccessor( resourceName ) { return repository.get(resourceName).then( (item)=>{ return item.theImportantPart; }); };

The trouble here is, that, suppose, the-repository.js does something clever,

and entirely reasonable, like, connecting to a database server, using an URI defined by an environment variable (because that's something that could happen) Then you'll be in for a pretty bad time when trying to test that this function actually returns "theImportantPart" of some "resource". The solution is simple, make sure the things that "interact with the outside" are dynamically provided. This is a silly function, but it could have been a class as well, same thing. Here's a better way (tm) easy-to-test.js:
module.exports = function SillyAccessor( repository, resourceName ) { return repository.get(resourceName).then( (item)=>{ return item.theImportantPart; }); };

This is easier to test, see? You only have to mock an object that has a "get"

method which ignores its argument (since we're doing nothing to that, it can't break), and resolves a promise for an object with a key named theImportantPart. Then, you can assert that, A: The get method is called, B: that the returned promise resolves to whatever value you chose for theImportantPart.

So, it's not difficult to write FOR test, it's difficult to write THE TESTS.

Just something to keep in mind, as you go, it gets easier, because you will have a larger selection of mocks, but often, if you want your tests to test not only sunshine scenarios, but also determine and verify behaviour in the error situations your code handles (it's one of my pet peeves, that code should always handle errors, if only (and most times, only) to generate some kind of usable error-message to display in the log (and maybe even the user, but I care much more about the logs than the users in such cases, as the latter will most often rephrase your carefully written error message as "it's not working and then it says something on the screen that I don't know what is"). So, to test error scenarios, such as the database not connecting, or the query failing, maybe in multiple peculiar ways, you want to be able to hack your mocked resources to behave just so, for those instances, and that may make them very specific to that particular unit test. But I've not proven that, and I might try to do a more general solution for use in our big system.


I won't promise to do a greater effort with this blog, because it's a promise that I can't keep, but I'll definitely continue thinking about such effort.

Greetings to all the Gopher dudes!

And to SDF too! ;) - OUT