DEV Community: Anders

What is your PageSpeed?

Anders — Mon, 26 Oct 2020 17:05:03 +0000

The recent post about Sonys brand new horribly performing update to their Playstation Store kinda got me thinking, do people even care about the performance of what they produce these days?

I realize that dev.to at least does, that was always an important part of what Ben focused on, especially at the start.

It is also something I tend to spend at least some time on as well, and typically that means I can achieve nice PageSpeed scores. Sadly, one of the things I am working on is built on top of HubSpots CMS, and that in itself means its not really possible to get all the way =/

With that said though, do you care about PageSpeed? If Yes, care to show case some of your work? If No, why not? =)

Help Needed - How long do you think it would take you to complete this work-sample?

Anders — Wed, 23 Sep 2020 18:08:33 +0000

Hi everyone, the company I'm working with has been doing a "simple" work-sample for new recruits for quite some time now, but something we've never quite been able to narrow down is how long it actually takes to do it.

So rather than constrain our estimates to my own (and me actually doing it), and the small set of recruits we've had, I thought I'd try and tap into the Dev.to hive mind if you don't mind...

Link to full size image

To simplify the response gathering process I've created a small survey.

( If you'd rather just write your estimate in a comment below I'll add that to the survey my self and then report back with the aggregate so others may benefit from this as well. )

Thanks in advance for your contributions =)

The Price of Currying

Anders — Fri, 28 Aug 2020 13:32:37 +0000

I stumbled upon this very interesting article on the concept of currying and how to it in practice, I definitely recommend you read it =).

As I am very interested in the performance cost of how we program, I had to explore the impact of using this method/feature or whatever we want to call it, here are my findings.

Test 1 (add)

Curried Version (from the referenced article, using lodash)

function add(a, b, c) {

   return a + b + c;
}

const curryAdd = _.curry(add);

curryAdd(1)(2)(3);

Basic JS Version

function add(a, b, c) {

   return a + b + c;
}

add(1, 2, 3);

And the results are just horrible. Using the curried version here is 99.96% slower, its so slow its almost unfathomable.

Test 2 (isType)

Base Items List for this test (from the referenced article)

const items = [
      { name: "Mango", type: "Fruit" },
      { name: "Tomato", type: "Vegetable" },
      { name: "Strawberry", type: "Fruit" },
      { name: "Potato", type: "Vegetable" },
      { name: "Turnip", type: "Vegetable" },
      { name: "Banana", type: "Fruit" },
      { name: "Carrot", type: "Vegetable" },
    ];

Curried Version (from the referenced article)

const isType = obj => type => obj.type === type;

const isFruit = item => isType(item)("Fruit");
const isVegetable = item => isType(item)("Vegetable");

const fruits = items.filter(isFruit);
const vegetables = items.filter(isVegetable);

Basic JS Version

function isFruit(obj) { return (obj.type == 'Fruit'); }
function isVegetable(obj) { return (obj.type == 'Vegetable'); }

const fruits = items.filter(isFruit);
const vegetables = items.filter(isVegetable);

Performance here is IDENTICAL for both versions which is nice, and expected, since you end up with basically the same thing for .filter to do.

Wrap Up

As is illustrated in the referenced article there are certainly use cases for currying, but do use it with restraint, especially if your code is executed by many many people, or many many times.

All benchmarking done with https://jsbench.me/ in the latest version of Chrome on a Windows PC. Actually declaring the functions was NOT included in the benchmarked code, that happens in the setup stage. That is slower in the curried case for both tests above.

Why do we write JavaScript like this?

Anders — Fri, 21 Aug 2020 12:22:16 +0000

Before we start, I do realize that this may potentially come off as a little harsh or negative, but that is not my intent, I am just curious as to why we’ve ended up writing code this way? All the samples in this article are from this article: https://dev.to/papabearcodes/four-common-javascript-interview-coding-problems-1gdk.

Over the past several years I’ve been reading a lot of articles here on Dev.to and I just keep coming across JavaScript that looks like this:

const isPalindrome = string => {
  let revString = [...string].reverse().join('')

  const palindromeCheck = () => string === revString ?  true : false

  return palindromeCheck()
}

And I can’t help but wonder, why do people prefer writing code like this. It makes use of a lot of built in functions, lambdas and what not, but it's also perhaps a little more difficult to read than you’d like, and if you think about what it's actually doing, it's not very efficient.

Let’s break this one down:

We use the spread [...string] function to make the string into an array of characters (memory allocation), we then reverse that array (hopefully this at least is done in place by the compiler, but I doubt it), lastly we join that back up into a new string (memory allocation).

Second we declare a sub function that basically just performs a single comparison, this literally seems to have absolutely no purpose whatsoever.

I’d personally write the thing something like this:

function isPalindrome(s) {

  for (var i = 0; i < s.length / 2; ++i) {

    if (s[i] != s[s.length - 1 - i]) {

      return false;
    }
  }

  return true;
}

Certainly a few more lines, and very “old looking” perhaps, but I am old ; ). Thing is though, this runs faster (albeit slightly), and in my mind at least is also easier to read and understand. But maybe I’m just crazy.

This example also sticks out, from the same article:

const sum = (...args) => [...args].reduce((acc, num) => acc + num, 0)

Granted, it is actually preceded by a more readable alternative first, that again avoids the things that I just think you should always avoid, poor readability.

function sum() {
  let total = 0

  for (let num of arguments) {
    total += num
  }
  return total
}

There is no way you’d ask yourself how that works.

However that example uses the “of” operator on the arguments array, a “new” fun feature. Sadly, performance is affected, using jsbench.me to compare the two the one line version is massively faster, the second version is reported as 92% slower than the first. This probably doesn’t matter for a function that runs once or twice but if we keep following this kind of pattern of blatant disregard for performance we will get into a lot of trouble eventually (Some may even say we are already, I may be one of those people ; ).

I did my own take as well, old school javascript again:

function sum() {

  var sum = 0;

  for (var i = 0; i < arguments.length; ++i) {        

    sum += arguments[i];
  }

  return sum;
}

Super simple, also as it turns out, super fast, our old one line champ is reported as being 74% slower than this above function.

Rounding up, let’s take a third function:

const captilizeAllWords = sentence => {
  if (typeof sentence !== "string") return sentence

  return sentence.split(' ')
    .map(word => word.charAt(0).toUpperCase() + word.slice(1))
    .join(' ')
}

Split, Map, Slice, Join.. so many array operations in action here. Let’s try a more basic approach:

function captilizeAllWords(s) {

  var capitalize = true;
  var returnValue = '';

  for (var i = 0; i < s.length; ++i) {

    var c = s[i];

    if (c == ' ') { 

      capitalize = true; 

    } else if (capitalize) {

      c = c.toUpperCase();
      capitalize = false;
    }

    returnValue += c;
  }

  return returnValue;
}

This is a much more explicit take. Again it’s slightly longer. And again it's faster. JSBench reports the first variant as 33% slower here. An additional benefit of this solution, if you actually wanted to do this for things after a tab or new line, that doesn’t really take much thinking of code to achieve.

That does it for this old developer ranting about new stuff style article, hopefully this can lead to some healthy discussion if nothing else =).

Eat your vegetables, make your code readable, and don't forget to BENCHMARK!

Dev to QA ratio

Anders — Thu, 11 Apr 2019 18:58:06 +0000

Hi there,

I've been pondering the composition of my team as of late and wanted to try and gather some insights from the larger Dev community. We're currently rolling with a 3:1 dev to QA ratio, something which I feel is waaay too high.

What is your team composition like?

I made a short Survey which I'd love it if you could contribute to, I'll post back the results here if there is enough submissions:
https://aweform.com/view/444075205812289537/dev-to-qa-ratio-survey/