irjoe

I always felt like go channels were more of a clever solution than a good one. Goroutines are a pleasure to work with though.

Using document.addEventListener means it will work even if the DOM is updated without having to add new event listeners. If I'm not expecting the DOM to change I would be more inclined to do something like:

  document.querySelectorAll('.menu-wrapper')).forEach(menuWrapper => {
    const button = menuWrapper.querySelector('.menu-opener');
    const content = menuWrapper.querySelector('.menu-content');

    if (!content || !button) {
      return;
    }

    button.addEventListener(() => {
      button.setAttribute('aria-expanded', 'true');
      menu.showPopover();
    });

    content.addEventListener('toggle', e => {
      // reset back to aria-expanded=false on close
      if (e.newState == 'closed') {
        button.setAttribute('aria-expanded', 'false');
      }
    });
  });

I don't recall the exact numbers but I had a very similar experience, scoring very highly on spatial reasoning almost to the detriment of everything else.

I remember a close friend getting frustrated administering a working memory test on me. She couldn't believe how far removed from the norm my working memory capacity was given everything else she knew about me.

I imagine the red blood was very noticeable on the white snow. I might be wrong though.

I assume you're referring to Kowloon Walled City?

I'm not sure that's entirely true in the UK. The Polish plumber taking British jobs is a fairly common trope in far-right discourse. I believe this is prevalent across Western Europe in general.

You can also use anonymous functions if you find the module syntax a little terse or clunky for shell scripting.

    double = fn a -> add.(a, a) end
    double.(4)

    f = fn
      x, y when x > 0 -> x + y
      x, y -> x * y
    end

Would Be Nice Ifs, maybe?

It was already fairly popular in the UK prior to being acquired by Facebook.

I live in a smaller city in the UK so my experience is likely much different from those living in larger cities.

I never wear a helmet when riding a bike and used to commute daily. I've never had an accident involving traffic and have come off my bike less than a handful of times commuting. It seems like the odds of me coming off my bike and hitting my head is very low.

I'm not averse to helmets I just don't think wearing one makes sense for my commute. I'd rather wear a woolen hat. I do wear a helmet when I go rock climbing and would probably wear one if I was commuting in London.

curmudgeon

2. Any advice about automatic whitespace/indentation handling with Emacs?

I use prettier-mode and editorconfig-mode. Everything is formatted on save so works well for me.

There's an inherent difficulty in making difficult things easy. I think we're more likely to improve the ergonomics of writing software rather than make it easier for others to translate business logic into code.

I like to think that making software easier to write will just free up more capital to be spent on other software problems. I haven't seen many software projects where the client doesn't compromise features due to budget or time.

I really wish the GraphQL alias syntax supported something like:

  query {
    users {
      email: contact.email
    }
  }

Interesting. I do the same thing in Elixir where I'll attach an iex session to a Phoenix application so I can interrogate modules and APIs as I'm building them out.

I'm slightly disappointed that it's already something I do day to day. I had hoped that the power of the REPL wasn't overstated.

Is there a simple way to get code I write in a lisp REPL back into my editor? That's the part missing for me and why I usually only use interactive shells (REPL or otherwise) for testing APIs or small pieces of code.

I can't imagine writing a program in its entirety in a REPL.

I've found a fairly workable solution is to have an origin for the API in CloudFront and a behaviour to route /api/* to that origin. Saves any CORS headaches. Obviously this won't work in all cases.

Quite the opposite :) My preference would be to rely on pattern matching (unification) in the function head:

    def transform_data([_|[]]) do: []

You're right, they're not really "early returns" but for me at least they are often in similar fashion to the "early exit" pattern in the article:

    def transform_data(raw_data) when length(raw_data) == 1, do: []
    def transform_data(raw_data) do
        # actual function code goes here
    end

I'm currently writing a lot of Elixir where early returns are a feature of the language (https://hexdocs.pm/elixir/Kernel.html#module-guards).

I also write a lot of JS and tend to use guard clauses fairly liberally. I find they make boundaries (x < 0) much clearer. My functions are also < 10 lines in most cases. For me it leads to less convoluted code but YMMV.