So, I finished the first 3 volumes of Neong Genesis Evangelion, and it ended
before Asuka showed up.. I went online and spent more money than I want to admit
on the next books.. Unfortunately, it looks like volume 14 is not available in
English, hopefully it will be!
Watched it this evening, not sure what to make of it. Fascinating for sure.
There is very little dialog in the movie, lots of knowing and saying stares
that I find difficult to decode. The cinematography is excellent, the ending
is sudden and startling, leaving everything to the imagination of the viewer.
What I took from it, was a sensation of stillness in motion, of existence and
not much else. It showed some perspective of life in a time, a time that might
have been, and a life that some might have lived. Moving through the country,
maybe it is a metaphor for moving through life.. The destination is known and
unimportant, what happens one the way is what's important.
I've not gotten nearly enough of it during the past week. Yesterday got too
late due to me finishing the NGE manga. I'm exhausted and don't want to think
or do anything, just to experience and idly think.. Idle thought is important
to me, but ideally, it should be mixed with activity, and most ideally, that
action should be some result of the idle thought.
No work done on the server class . Thing is, writing a gopher server is really
simple.. Almost so much so, that a server library seems unneeded.. And yet,
there are a few things that could be done.. I'm thinking.. This library should
be not for writing generic map-based servers, that's been done, and works well.
I want this library to allow people two write gopherholes that mix dynamic and
static content where desired, in a way that is very convenient. Since the menu
format is already fixed, I'd like it to be easy to create good-looking, dynamic
menus with the library. But I've just not gotten around to designing good
classes for menu entries and a good API for defining handlers. But it will be
somewhat express inspired.
I've understood them, even how they can be exploited to implemented fairly
low-overhead await functionality, but I don't think that is something to strive
for, the increase in overhead is real, and even though I want to say it's an
elegant hack, and someone has been very clever for coming up with it.. It's
rough and abusive, maybe await is as well. The decision to be async has been
made, and it does hurt a bit when you have a sequence of statements dependent
on async data and the result from the previous statement, but this helps to
identify design issues or at least, actual, real, bottlenecks. Maybe you really
do need to fetch several small pieces of data from different places, well,
maybe you can get them delivered at once, or maybe you can think harder about
what can be done in sync, because, network is slow! The pyramid of doom is
buried in syntactic sugar, but the real evils of it live on, disguised in a
thin veil of simplicity. Look your killer callback pyramids in the eye, and
rewrite them, not to look less like pyramids of doom, but to BE less like them.
When you're writing node applications for use in Docker, and, likely, under any
kind of process management, remember to subscribe to the "SIGTERM" event on
process, so that you can shut down the service. This makes stop and restart a
lot quicker, so that Docker does not have to wait 10 seconds for it to stop.
is what I will do now.
May the weekend come
to grace and save
us all.
... OUT