Show more

Can any of you recommend a good source that explains destructuring in ES6? I think I'm having more trouble with the syntax than the concept. However, it's possible I'm not grokking the concept as well and that's why the quirks of the syntax feel arbitrary.

Can any of you recommend a good source that explains destructuring in ES6? I think I'm having more trouble with the syntax than the concept. However, it's possible I'm not grokking the concept as well and that's why the quirks of the syntax feel arbitrary.

It turns out I had somehow picked up the concept of functional programming without knowing what it was called, and in pretty much every new section there's a bit that makes me go "oh so that's what that is/how that works/why that doesn't work"

Now freeCodeCamp has split up the JS teaching section into Basic, JavaScript, ES6, Regular Expressions, Debugging
Basic Data Structures, Object Oriented Programming, and Functional Programming. Projects and more advanced challenges are interspersed. I'm going back through and filling in what I missed.

The freeCodeCamp curriculum really beefed up their JavaScript section. It was a bit circle-circle-owl when I did it - by which I mean you get basic ES5 concepts and then here's some algorithm challenges, good luck!

Which was very frustrating and difficult and I definitely missed some foundational concepts learning that way.

As part of my JS review I'm reminded about how silly some of the built-in function names are. Like Array.unshift() adds an item to the front of the array. WTF. I mean you get used to it if you're using it all the time. After a three month break, the ridiculousness becomes super obvious though.

It also makes me think that most people and programs teaching programming don't actually base their curriculum enough on cognitive science, and that's why learning programming is so hard. It's not intrinsically harder than learning a human language or calculus. But we teach it very poorly.

I'm reviewing my JavaScript and general programming concepts for a technical interview and the lecture gave me some ideas about how to do my review and made me wish I had known more about this stuff when I was first learning JavaScript.

Lecture, with slides, from a recent Write the Docs meetup
Human Learning: How we Learn, Why it Matters

Useful if you're trying to learn something, or to teach people something. Based on scientific study of cognition and learning rather than popular but disproven myths like "learning styles".

"We already have nice things, and other reasons not to write in-house ops tools"

(good article by a v smart acquaintance of mine about why you shouldn't home-cook your ops tools, which reminded me of the earlier musing about what I see as drawbacks of a headless CMS)

when I first ran D&D, my grandmother, who had bought fully into the IT'S SATANISM hype, insisted on sitting and watching the first session

about an hour in, she threw her hands up and yelled 'THIS IS JUST MATH' and stormed off

It's not that I need better hobbies. It's that this should probably be my job. I mean, maybe not Mastodon user docs specifically.

I started writing up the things I find frustrating about doing new things on Mastodon so it appears I'm about to recreationally write user documentation out of anger again.

Are we calling it a toot-storm when I write 5 toots that should have been a blog post?

Honestly though, I'm still not convinced a headless CMS is that much better than writing some additional custom templates for a CMS with templates.

I'm probably missing some important use cases, so I can be persuaded.

Probably. A little voice is saying that headless CMS is the same impulse as "Why don't we just code our own version, inhouse" which is almost always a wasteful idea.

With a headless CMS, your data is structured but you assume no particular display. So if suddenly everyone has smartwatches and you need to display your website in a 10x10cm square, no problem, you write a new custom template. No need to migrate CMS's which is basically *the worst*

There are some obvious drawbacks. You have to build your own display layer. What a pain! That probably makes it unsuitable for a lot of folks and most small businesses.

OTOH the big drawback of predefined templates is that they assume certain displays. So if you bought a CMS that just assumes everyone has a desktop and laptop and suddenly half your traffic is smartphones, oh boy.

A headless CMS is basically a CMS without a built-in display layer. Instead of the data getting spit out into pre-defined templates, it's put out through an API. Why might you want something like that?

Last week I learned about the concept of a "headless CMS" and although they've been around for a few years and I've used CMS's for decades, it was completely new to me.

I went for a walk to Tank Hill (named after a water tank I think) and saw some hawks swooping about. Good Sunday afternoon.

Show more
Mastodon for Tech Folks

This Mastodon instance is for people interested in technology. Discussions aren't limited to technology, because tech folks shouldn't be limited to technology either!

We adhere to an adapted version of the TootCat Code of Conduct and follow the Toot Café list of blocked instances. Ash is the admin and is supported by Fuzzface, Brian!, and Daniel Glus as moderators.

Hosting costs are largely covered by our generous supporters on Patreon – thanks for all the help!