I will no longer be going to IndieWebCamp London.

Recent calls to customer services, rated

Scottish Power – ☆☆☆☆☆

After you’ve waited long enough to get through, it sounds like their call centre has only one phone, and all of the operators are speaking in to it at once. It was next to impossible to struggle through the first round but I did manage to get passed to “the correct” department.

Once through to the department I needed, they proceeded to tell me the problem I had wasn’t a problem, obviously after confirming with a colleague to make it sound more like an official judgement. They then advised I call a National Grid number, which I had done previously, and were the ones who told me to contact my supplier. Yay, loops.

John Lewis – ★★★★★

I connected to someone in like 5 seconds, they confirmed some details, and then they cancelled the part of my order I wanted cancelling. It just worked, what else would you expect?

Virgin Media – ☆☆☆☆★

Connected pretty quickly to an operator after going down a few menus. I did have to start again because I tried going down one alley which asked me to input some characters from my account password (surely they didn’t mean that password).

Then the operator asked me for the first character of my password. When I said I didn’t know they asked for my last bill amount (which I didn’t have to hand so I guessed), and the sort code of the bank account on file (also didn’t have to hand, but I could at least name the bank).

THEY THEN READ MY PASSWORD TO ME AND COMMENTED HOW WEIRD IT WAS, which, obviously, it was randomly generated, but… what. They read me my password after I failed to answer the security questions I was asked. :mindblown:

The rest of the call was what you expect when trying to cancel a service: instead of cancelling they put you on hold to look up the prices of the service you are moving to, then offer discounts, the waiving of fees, and 4 bottles of wine.

Eventually they cancelled, but it could have been a 3 minute call. I should probably knock off another ★ for the password, but they did eventually get what I wanted done.

How to tell if an API is bad

a screenshot of the Tableau REST API documentation

Hey look, they highlighted the part I hate:

Note: After creating the user, you must set a full name, password, and email address for the user with the call to Update User.

I have a feature suggestion, perhaps this is daft, but if I must update a user with information via a different call after creating it, I don’t know, maybe I could just provide that information when creating the user?

To be fair, a nice attempt has been made to build the API around resources, which means it’s a REST API! And that is good. But what would have been nicer would have been considering some use-cases. Why are people going to use the API.

My use case: When a new user comes in, create a Tableau user in a specific group. If the user already exists in Tableau then update with the latest data.

This requires the following API calls:

  1. Sign-in, because the API is secured with a token but you need to get this from a username-password combo…
  2. Check the user exists on the site
  3. Create the user against the site if they don’t exist
  4. Update the user
  5. Create the user against the group (we can let this fail if they are already in the group because we don’t need anything from the result of this call)

Maybe GraphQL will save us all?

my favourite javascript framework is javascript

Sometimes to say that you “wrote” a piece of code feels wrong, it can feel more like you discovered it. Or re-discovered it anyhow, because it probably exists in many other places in slight variations.

function h (tag, attrs = {}, children = []) {
  const el = document.createElement(tag)

  for (const attr in attrs) {
    if (attr.startsWith('on')) {
      el[attr] = e => attrs[attr](el, e)
    } else {
      el.setAttribute(attr, attrs[attr])
    }
  }

  for (const child of children) {
    if (typeof child === 'string') {
      el.appendChild(document.createTextNode(child))
    } else {
      el.appendChild(child)
    }
  }

  return el
}

Which I wrote while updating alexandria as,

It captures what I like about Elm, but in a slightly uglier way.

h('input', {
  class: 'title',
  value: data.title,
  onblur: me => this.setTitle(me.value),
  onkeypress: (me, e) => {
    if (e.keyCode === 13) me.blur()
  }
})

Of course I’m not saying anyone should go out and use this as the core idea of their applications, especially if writing as part of a team. Using something with a bit more structure is obviously needed to prevent large apps becoming soup; this is a 300ish line app that essentially draws a <table>. And I’m pretty sure rebuilding rows when filtering or sorting isn’t the most efficient way of programming against the DOM, though I doubt it is too bad for the size of table I have.

What I’m trying to say is, with all of us only using frameworks we can sometimes forget how nice plain ol’ JavaScript is in the year 2019.

Pretty cool that Jamie is going to be starting a Homebrew Website Club in Nottingham. I will be there.

a picture of a can

I just wanted to share a picture of this can. Isn’t it great? I guess it still doesn’t beat a kwak.