#JavaScript

232 tweets

Replying to @coderbyheart

About the process: we are looking for people who love to make technology more
accessible, through great examples and documentation. That's why we try to
figure out your skills as a cloud engineer by checking for your #JavaScript and
#TypeScript skills in a coding challenge.

I got bitten today by a nasty #JavaScript thing:

const handler = async () => { try { return request(); } catch (err) { // I
wanted to handle request errors here // but since request returns a promise //
they won't get caught } };

I will be speaking next month @codetalkshh
(Oct 18-19th) about #JavaScript and #IoT, and I am donating a complimentary
ticket (worth €480) for a member of an underrepresented group. DM me with a
short intro if you are and can make it to the conference. I will decide
tomorrow.

Lets say you want to ensure that a dozen+ #JavaScript repositories follow the
same conventions for

  • settings in package.json (license, publishConfig, ..., scripts, deps)
  • .editorconfig
  • commitlint settings
  • tsconfig / tslint.json
  • README badges

How would you automate that?

I'm really happy to be speaking @ndc_conferences in June in Oslo.

I'll show how easy it is, to build a secure #IoT product prototype using
#JavaScript and the @Espruino Wifi.

This will be my first conference as a speaker in the Nordics.
Embedded Photo

So, quick poll on #JavaScript throw: should you always throw an instance of
Error(), or is it ok to throw anything?

I'm also happy to hear your reasoning for the choice.

Meanwhile I have come to the conclusion that this syntax for binding arguments
in #JavaScript

const f1 = f.bind(undefined, arg) f1(); // const f = arg => {}

is inferior to

const f1 = f(arg) f1(); // const f = arg => () => {}

Here is my #JavaScript 🔧 best practice tip of the day 📆: Do not execute code
in a module without being called. Bootstrapping/configuring of modules must be
done in one place 📍 not all around the app 🌐.