qubyte

I rolled my own static site generator for very little effort. As it stands, the generator (which isn't public so you'll have to take my word on it) is ~100sloc plus templates, CSS, etc. The process has been interesting and educational, and I recommend it on those grounds. Adding and modifying features is very easy since it's so little code to work with. Currently:

- posts are rendered from markdown with syntax highlighting for code

- safe links to other domains (noopener and _blank)

- bundled CSS, which look good (or as bad) on mobile

- a PWA (the service worker is the only JS run client-side)

- pre-populated links out to twitter (with a card) and mastodon with tags drawn from markdown metadata

- HTTPS using a letsencrypt cert and a one-liner in cron.daily to update it when close to expiry

- a smallish nginx config focussed on security to serve files

Much of the generator is just glue code around some good modules. Some important things like safe links were hacked together by me.

(if you're interested, https://qubyte.codes, but I need to post more often)

I wrote a docker-wrapped script to create keys and certificates for use with HTTPS for development. These are configured with algorithms which modern browsers won't complain about. It also allows alternate domains.

https://hub.docker.com/r/qubyte/cert-creator/

The "headshots" idea seems to be optimised for the listening habits of the author of this post. Not every artist (and almost none in my library) is a singular person. For that matter, I don't really care what the artist looks like. I'm more likely to recognise a logo when available, or an album cover failing that.

I absolutely agree. Reducing consumption is a win on pretty much every front. Another thing to do is diversify what is eaten. Have some (sustainably sourced) fish or shell fish a couple of days a week.

Not if we're talking about advances in textured vegetable protein. When I read "fake meat" I take it to mean that it's not animal derived. Otherwise it'd just be meat.

Weird things can happen with event emitters mixed up with promises too. I wrote a short piece with an example:

https://qubyte.codes/blog/promises-and-nodejs-event-emitters...

(The title is a bit overstated, since it's really about the specific example of unhandled error emissions in a promise chain.)

Regardless of the merits or problems of either post, a lesson is to be careful around promises when errors are involved.

This lets me do side-by-side full screen on a mac, which the full website can't do (not responsive so I can't make it narrow enough) and the mac app won't. The previous mobile site was nearly good enough, but required refreshing for new tweets. Very happy that this is available.

I was raised and schooled as a Catholic in the UK, and while that's nowhere near as malign as the religious groups mentioned in this article, the final paragraph really resonated with me. It wasn't until university that anyone questioned my beliefs. I patiently heard each argument out and responded with logical gymnastics (I now classify myself as a theological noncognitivist). It was only when a difficult event happened in my life that I began to really question my beliefs and they crumbled (a traumatic experience in itself).

The author is spot on when they say that there's nothing you can do to convince these people. The beliefs are so closely held that changing them has to come from the believer.

I like the emphasis this article places on testing. Languages which emphasise testing or make testing easy are my favourites to code in. For example, JS being dynamic and having mature testing and assertion libraries lowers the barrier to getting stuff tested, Go has testing in its standard library, and Rust has amazing support for tests (including testing examples in comments) both in the language and from Cargo.

Perhaps it is more important to provide tooling and libraries for testing a language than it is to provide new features in the language proper to avoid foot-guns. It's much harder to back out of the latter.

wrt Japanese, get comfortable with the difference between transitive and intransitive verbs. Verbs in English are often both (ambitransitive) and that makes you (or maybe it's just me) unaware of the difference. It took me more time than I care to specify to sort that out in my head!

And be confident! Japanese people are generally supportive and will appreciate your effort to use the language, no matter how successful it is.

I agree with you in part. Babel is not something I'm fond of (I can't seem to wrap my brain around phabricator as an issue tracker).

In fairness though, you can configure babel to use native generators if you intend to only support platforms which implement them. However, generators have also not been well supported for very long: http://kangax.github.io/compat-table/es6/#test-generators

Oh interesting. That is a better fit, yes.

Ditto on all counts.

I've only recently become aware that the way I experience or remember the world is in any way unusual. I'd always thought that mental imagery was a metaphor for something or hyperbole. It also explains why my memory seems deficient. I've no problems with facts, but I have no memory of being a participant in events.

Contrary to the article, I have no problem recognising people. It's like I keep a hash of faces. If I close my eyes I'll have no idea what the person in front of me looks like.

The whole thing has me slightly sad.

git-time-machine is a very interesting find. Thanks!

Thanks! I just took a quick look at https://docs.npmjs.com/files/package.json

If I remember in the morning, I'll send them a PR to update their docs.

It really depends what's in the .npmrc. For example, you might have one containing only a setting to use absolute versions when installing packages and saving them. It's also worth noting that it's a good idea (although I always forget) to use the files field of package.json to act as a whitelist.

Edit: the author notes that these are excluded by npm anyway these days. The documentation does not reflect this.

Since it's the first and only release so far in 4.x.y, I got away with `nvm install 4`. ;)

Ah, you're suggesting that the shims use long-polling. I don't think that's the case though. If I understand the library correctly, it really is keeping a connection open, so it's really very similar to the way EventSource works.

Addition: Verified. It doesn't disconnect between events (not long-polling).

I'm not sure I'm following you. How does this differ from native EventSource?

The issue with maximum open connections will go away with HTTP/2, and you can get around it today using SPDY since both multiplex connections to a domain.

SSE is easy to shim! We use: https://github.com/Yaffle/EventSource/

I found engineering around the lack of this feature very upserting.

I'll get my coat.

I was surprised that only two thirds of people ever experience deva vu. I experience it a couple of times a week and usually say something when I do if someone is around. Nobody ever mentioned that they didn't know what it felt like. Perhaps it's time for a poll.

Further, it's worth putting the components on npm individually and retaining 101, but making it depend on those modules (so it's really just a wrapper). This is what lodash should do imo. Lodash has the separate bits on npm, but lodash itself does not depend on them, which is a little weird.

You should probably test your site in Firefox. It looks like a disaster.

Amazingly, I was at the asyncjs.com presentation on these and related topics by that author just yesterday! Excellent stuff.

I really like this idea. I also really like the nav column.

I wouldn't fret too much about it.

I'll get my coat...

I've attempted to use atom full time a few times. Each time it's eventually slowed to a crawl, and switching tabs takes seconds. I really want to like it, but it's just not as fast as sublime (yet).

P.S. see option 3 in that presentation.