I’m bulk editing a bunch of KiCad footprints (a.k.a. modules) in a text editor. Said footprints have a
tedit field, which turns out is a hex-coded timestamp. This means to properly edit a KiCad footprint in a text editor, you should update that field when you save it.
A one-liner for producing a hex-coded timestamp in Linux bash is:
printf "%X\n" $(date +%s)
It happens sooner or later to all consulting designers: your client decides not to use your work or — if it’s what they hired you for — take your advice.
First of all, remind yourself that as a design professional you’re not taking anything personally. It might also help to remind yourself that contrary to a lot of narratives, it’s not your job to “make the client happy.” Rather it’s your job to solve your client’s problems as best you can. It’s your client’s prerogative to accept or reject your work. There may be a million reasons for a client not to adopt your solutions or take your advice. Whatever the reason, you cannot afford to take it personally.
Continue reading “Client rejections”
So, let’s get on with it.
In a previous installment, we took a dive into the
this variable and how it behaves in different ES5 situations. In this installment, we’ll do the same but for so-called arrow functions, introduced in ES6.
So far we’ve learned what the relationship is between an object and its constructor’s
prototype and what happens when we change properties set on the
__proto__ property, which is also the constructor’s
undefined. But that’s not what happens.
Continue reading “JS prototypes and property values”
Continue reading “Designing out designers?”
this variable can be a little challenging. A wonderfully concise summary on the issue is found in chuckj’s answer to a StackOverflow question (modified here to account for differences between ECMAScript 5’s strict and non-strict modes):
this can be thought of as an additional parameter to the function that is bound at the call site. If the function is not called as a method then the global object (non-strict mode) or
undefined (strict mode) is passed as
Let’s see what this means (pun intended?) for various scenarios.
It’s common in the web and app development industry for stakeholders to make a distinction between “designers” and “developers”. One of the things I’ve noted about this distinction is that it opens the door to antagonistic perceptions and even behaviors between the two camps. At a conference a few years ago, in the presence of developers expressing disparaging views regarding designers, I suggested that, “Designers are developers.” The deafening silence suggested I had to explain what I meant:
Continue reading “Designers are developers”