DEV Community: George Jempty

Why can't AUTOMATIC post throttling be instituted for new accounts

George Jempty — Mon, 11 May 2020 11:44:52 +0000

I hadn't posted anything in 3 months until today, AND IT WAS THE SAME THING ALL OVER AGAIN. When I was posting more regularly about 3-6 months ago, more than once I complained about new users spamming tags such as Vue or PHP with dozens of submissions within days of joining the site.

So I post something in the Go tag this morning, then navigate to the tag for the page, and somebody who joined the site less than a week ago is spamming the tag, including several posts in just the past 24 hours.

It is not fair to others to have their content pushed down. I brought up the need for automatic throttling a few months ago, I even offered to help, but that didn't get prioritized.

Until it does get prioritized, I'll hardly considering using this platform any more.

First SO Go Question 😜

George Jempty — Mon, 11 May 2020 11:27:48 +0000

Have been working with Go for a few weeks now and have finally posted a question to Stack-overflow. I've got a work around but would like to know a better way:

https://stackoverflow.com/questions/61728420/would-like-to-work-with-same-file-content-passed-to-library-without-opening-fil (without opening file twice)

Two ways to determine if any arrays in an object has an entry

George Jempty — Mon, 03 Feb 2020 15:55:26 +0000

let pendingAdditions = {
  hospitals: ['Silencio Hospital','St Judes'],
  licenses: ['poe-tic license'],
  medschools: []
}

let somePendingAdditions = Object.values(pendingAdditions).some(arr => arr.length);
console.log(somePendingAdditions); // true
somePendingAdditions = 
    Boolean(Array.prototype.concat.apply([], Object.values(pendingAdditions)).length);
console.log(somePendingAdditions); // true

Pitfalls regarding the second approach noted at: https://stackoverflow.com/questions/60042666/how-to-determine-if-any-arrays-in-an-object-has-an-entry/

Javascript: When Less is More

George Jempty — Tue, 14 Jan 2020 01:53:24 +0000

NOTE: I have added the regex tag based on help I got on Stackoverflow in the few hours since writing this, please see my comment, the first, below (I didn't think it warranted a whole separate sequel/post). Regex's could well be "The King of Less is More" 👑

ALSO ADDING VUE TAG: I since realized that a post of mine from a week ago regarding nesting Vue methods also falls into the "less is more" category. See https://dev.to/dexygen/grouping-related-methods-together-in-an-object-in-vue-1ie0 or for the tl;dr just go here: https://stackoverflow.com/a/59614452/34806

In 2017 when my title was Application Developer IV I stumbled across some code written by an Application Developer III (so I was one level senior and I think it was the kind of place that tied those titles to your pay grade) such as the following:

if (foo === 'bar') {
  return true;
}
else {
  return false;
}

It had been probably a decade since I'd ever written anything like that, I hope he brought other redeeming qualities to the table, because if he did that with any regularity, I was certainly at least 2 levels senior to him, in my opinion. Of course that should be re-written in the following "less is more" fashion:

return foo === 'bar';

A related example is as follows. You might be returning a particular value from within an if statement, and if the condition is not met, you otherwise return false. Here's the first potentially unnecessarily long way:

if (foobarbaz) {
   return foo === 'bar';
}
else {
   return false;
}

Unless you need to do some processing within the else block, it isn't strictly necessary and you could write it like as follows:

if (foobarbaz) {
   return foo === 'bar';
}

return false;

Indeed I started writing code such as the above just this morning. However, unless you are explicitly testing the return value with ===false, even return false is unnecessary, as a function will otherwise implicitly return the falsy undefined, in which case we could potentially tighten up the code even further with the following as the last statement of a function:

if (foobarbaz) return foo === 'bar;

For the current user story I'm working on I've probably written a couple of things in a "less is more" fashion, but the following didn't start out that way but rather as your typical if/else construct, not unlike the code I disparaged above 😜 By the way, below is how I tend to write legible ternary statements if they become too long, but maybe because it's spread over more lines you don't think this is a case of "less is more"? Except that it's one statement, and the "lines of code" (LOC) metric is, in my opinion, ridiculous. In fact, particularly when I'm maintaining code, I'm usually shrinking the size of the code base, yet I digress; rather the point is, the following is arguably better than using if/else's:

toggleShowAttachmentsPanel() {
  // Keep panel open as long as there are attachments
  this.attachments.showPanel = this.attachments.showPanel ? 
    this.attachments.selected.length !== 0 
    : 
    true;
}

Also note that, since this is not your typical toggle function
(showPanel = !showPanel) I added a comment.

One last example, I don't know what the alternative might be as I've been doing this for so long, in fact since implementing something akin to Promise.all at the beginning of last decade. And in fact I was doing something similar to back then, making XHR calls in a loop. We've mostly been using axios.all for this, but this was trickier in that they weren't distinct calls to separate endpoints, but rather consecutive calls to the same endpoint, with different parameters on each call, and I just didn't have the time to figure out how to make that work (I've been on this story over the course of parts of 2 sprints 😢) and we already had some existing jQuery code that I was converting that did the same thing in a loop, so I took the path of least resistance.

First I set a variable equal to the length of the array I'd be iterating over:

// will get decremented until reaching 0 when this.sendEmail() will be called
let attachmentUploadsPending = this.attachments.selected.length;

Again, notice the comment; I think it makes it easier to understand how I then perform a "count-down" from that value within axios.then: I use logical not (!) against the value returned by the prefix form of the decrement operator (--) (https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Operators/Arithmetic_Operators#Decrement), logical not of course returning true for 0, since 0 is falsy.

if (!--attachmentUploadsPending) this.sendEmail();

I hope I haven't rambled on too much, ironically that would go against the "less is more" principle. But bedtime is fast approaching, and as Mark Twain is accredited to have said/written: "I didn't have time to write a short letter, so I wrote a long one instead.": https://www.goodreads.com/quotes/21422-i-didn-t-have-time-to-write-a-short-letter-so

Find the Easter Egg in my Resume's "Summary/Skills" Header Section

George Jempty — Mon, 13 Jan 2020 00:06:03 +0000

Implementing Javascript Objects with Multi-part Keys

George Jempty — Fri, 10 Jan 2020 12:13:01 +0000

If you've done Javascript development for any period of time, you've likely encountered a situation where you've wanted the key for an object to be composed of multiple values. I've googled for relevant Javascript examples but they all seem to come up with associating multiple values with one key, that's not what I mean.

Rather, perhaps you want to compose an Object key from the values "foo" and "bar". A naive approach might be to concatenate the values with a delimiter unlikely to appear in the string, for instance the tilde, in which case you might create the key: "foo~bar".

Depending on the data though there could be the possibility that one of the values needed for the key could contain the delimiter you have chosen, and this will make it difficult to use the object's keys for some subsequent purpose, e.g if you thought you'd have a two-part key, and split it on the delimiter, you could end up with more than two values. Luckily there is another solution...

Put the values for the multi-part key into an array, then call JSON.stringify on it, and use the result for the array key:

const key = JSON.stringify(['foo','bar']); // '["foo","bar"]'

If you don't care about the order and want to treat ['bar', 'foo'] the same way as ['foo', 'bar'], sort the array you pass to JSON.stringify: ['foo','bar'].sort()

See the following answer I posted on StackOverflow this morning using this technique: https://stackoverflow.com/a/59680851/34806

2020 Things Every Dev Must Know for 2020

George Jempty — Thu, 09 Jan 2020 19:44:59 +0000

The same 2020 things you should have known on Dec. 31 2019

Grouping Related Methods Together in an Object in Vue

George Jempty — Tue, 07 Jan 2020 18:00:28 +0000

tl;dr: https://stackoverflow.com/a/59614452/34806

When first working with AngularJS about 6 years ago I was a bit distrurbed by the the lack of organization allowed within $scope --- both attributes and methods could be added anywhere in any order. So I asked the following question on stackoverflow: https://stackoverflow.com/q/21285627/34806

In reply I not only got validation for my design, but also informed of an important, if esoteric reason, for why my idea was a good one in a way I'd not even thought of. When I moved to Vue years later, this was one of the improvements that I recognized: data was in data and methods in methods

Sometimes though you might like to further organize your Vue methods. For instance, if all handlers could reside within an on object, then it would be a matter of looping over them to nullify them in a beforeDestroy/destroyed hook lifecycle method (but be careful as noted here: https://dev.to/dexygen/linus-borg-s-nor-other-expert-s-advice-not-to-be-followed-blindly-1712)

There are a number of attempts at solving this given at: https://stackoverflow.com/questions/36108953/is-it-possible-to-nest-methods-in-vue-js-in-order-to-group-related-methods/ but IMO not of them is particularly clean. My idea is to not add this object containing methods, to methods, but rather, to declare them in the created hook:

created() {
  this.on = {
    test: () => {console.log(this)}
  }
  this.on.test();
}

See this codepen https://codepen.io/dexygen/pen/povpxqy and open developer tools to see what gets logged.

Where can I find a list of all dev.to's tags

George Jempty — Mon, 06 Jan 2020 02:01:47 +0000

Maybe I'm over-looking something obvious, but when I search I only find the page with the top 100 tags (https://dev.to/tags) but I'm wondering where I can find all the tags, thanks

dev.to posts tagged 'beginners' considered harmful

George Jempty — Tue, 31 Dec 2019 22:26:59 +0000

About 10 years ago I made my transition from full-stack web developer (though the term wasn't in use at the time) to front-end-focused. I had no prior ExtJS experience but was hired on the strength of my Javascript experience in general.

Prior to my first day I bought a book on ExtJS. I could not have succeeded at that position the way I did if not for the book, but still it contained at least one glaring mistake -- it referred to the configuration object literal used to create an ExtJS instance, as JSON.

What's the harm? Well to this date you will see questions on StackOverflow where the uninitiated think any old Javascript object is JSON and can't understand why parsing a string representation of the same fails.

Just within the past 7 days I started writing on dev.to again, after a hiatus stretching back to February. One of the more recent posts has to do with not blindly following the suggestions of known experts: https://dev.to/dexygen/linus-borg-s-nor-other-expert-s-advice-not-to-be-followed-blindly-1712

Well I'm seeing content in dev.to's beginners tag that is far more egregiously wrong than that ExtJS book about JSON, or LinusBorg about removing event listeners in Vue.js instances' destroyed hooks. Remember beginners, anybody can post anything on dev.to and unlike books for instance, it is not curated. Therefore I implore you, everything that you read targeting beginners on this platform, do so with a critical eye -- don't simply trust it to be correct.

Interestingly it is ironic that, the beginners being targeted are at the "don't know but know that they don't know" stage of their accrual of expertise, and that is why they are reading these articles, to try to learn more. But as long as the beginner's content is not curated (and I have now come to believe that it absolutely should be), you will have content authored by those who "don't know, and don't know that they don't know", which is at the previous, initial, stage.

There's even a term for "don't know and don't know that they don't know", Dunning-Kruger effect: https://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect

The last two stages are "know but don't know that you know" and "know and know that you know". I like to think that depending on the technology involved I'm at the 2nd, 3rd or 4th step. Or that if I am at the 1st step, I can at least be disabused of my ignorance through logical argument. I suspect however that those suffering from the Dunning-Kruger effect probably cannot be persuaded.

Yet I digress. My main point is, to reiterate, that beginners need to read everything critically; research what you read and/or seek out clarification from other seeming experts.

Hexadecimal addition in a MAC address context

George Jempty — Sun, 29 Dec 2019 17:56:19 +0000

I don't answer a lot of StackOverflow questions any more, they are mostly so specialized, or when they are something I can answer a lot of the time while I'm composing my answer, two or three new answers are posted all similar to my intended answer. On the other hand sometimes when I truly do want to answer I cannot do so at that very moment, for I'm at work, or, as was the case last night, was out with my wife for the evening with only my tablet which IMO is hardly sufficient for writing a properly tested SO answer with, though your experience may be different.

In any case, I often mark such questions as favorites and then review later at a more convenient time, which is what I did with last night's. I won't go into the details here, it's all in the StackOverflow post, so the link follows. My answer doesn't do a lot that's different from the others though, biased as I am, I like to think of it as a clean synthesis of those ideas that uses some more modern Javascript techniques than the others.

https://stackoverflow.com/questions/59515305/incrementing-hexadecimal-string-from-mac-address/59521438#59521438

Actually for the sake of being more complete and not forcing readers to follow the above link, here's my code, though you may still need to refer to the question for the requirements.

const macAddrs = [
  '84:1D:A2:B9:A3:D0',
  '84:1D:A2:B9:A3:99',
  '84:1D:A2:B9:A3:AF',
  '84:1D:A2:B9:A3:FF'
];

const addrsIncr = macAddrs.map(addr => {
  let addrPrefix = addr.slice(0, 15); // everything up to and including last colon
  let modulusIncrLastOctet = (parseInt(addr.slice(15), 16) + 1) % 256; // converts FF to 01
  return addrPrefix + modulusIncrLastOctet.toString(16).padStart(2, 0).toUpperCase();
});

LinusBorg's (nor Other Expert's) Advice Not to be Followed Blindly

George Jempty — Thu, 26 Dec 2019 23:04:34 +0000

I started working with Vue.js in 2017, and based on the profile I used at the time I see I posted thrice during my first 2 months. And LinusBorg (https://forum.vuejs.org/u/linusborg/summary), a core Vue.js team member, responded every time.

Ironically though, I never gleaned anything Vue-specific from his responses to apply to my problems, but rather, unknown to him, he turned out to be my "rubber duck" (https://en.wikipedia.org/wiki/Rubber_duck_debugging). He still helped me, it's just that in the end my issues never really were Vue-specific.

I was new to Vue at the time and other members already on the team when I joined had a bit of a head-start on me. Those other team members conveyed that it was best practice to remove event listeners in the beforeDestroy or destroyed life-cycle hooks, so we adopted that technique.

Months later though when I was mired in defect-remediation 95% of the time due to a business decision to change the back-end but shorten the deadline, one defect kept me busy for an entire day give or take, until I traced it back to event listeners being removed. The issue was that we had multiple components of a particular type on the page, and they could be added and removed, but when any single one of them got removed, the event listeners were removed for all of them :(

Within the last week while googling I found the following post of LinusBorg's on the Vue forum (https://forum.vuejs.org/t/adding-eventlistener-on-mounted/3337/3) wherein he stated, in 2016, that "you should simply use the destroyed() hook to remove the listener when the component is destroyed". Which made me wonder if my team members had possibly seen this?

So be careful about removing those event listeners in your beforeDestroy/destroyed hooks. And also when following expert advice, do so with a critical eye.