DEV Community: Javier Arroyo

Confirm it... don't analyze that code

Javier Arroyo — Sat, 19 Mar 2022 00:39:22 +0000

Shocker... Interpretation happens before reading, making reading the act of confirming something previously known.

The noggin looks at a word, says hey, I don't have to evaluate what's going on here. I know what it means... and poof, in a near automatic manner, it acknowledges something it already knew. This is not that, I know that. Ha!

That automatic reaction, however, doesn't extend to reading code. Instead, reading code goes through a more complex and extended process. It stores all the bits and pieces, looking up their relationship, then evaluating some meaning until assuring it's got it right.

Being no psychologist, that sort of sounds like coding closer to the act of reading human grammar can be a positive event. Let the brain do less work by being a more articulate coder. No?

Yeah, yeah but. Really, what does that even mean in the context of code, coder, even employer? Is it that if a line of code can "automatic" yield clarity, absolute certainty at minimized times, everyone gains from the efficiency? Because it's easier to read, to change, to modify, to... what?

In layman's terms, reading less means more times spent coding more... a happier boss upon seeing those new features.

Now, How is code even measured in respects to reading? As in, what is read unequivocally means what it says and nothing else. And not while having to read it a few times but, in a glimpse. That at-a-glance should reveal it all, possibly bypassing the need to look any further.

This opens the possibility that not everyone who reads code is at the same skill level, or interested in everything in one shot. Readers are there for all sorts of reasons... of which least, to me, is reading every character in every function all of the time, just to know what something is doing.

Lets do it! The goal? No room for misinterpretation while maximizing comprehension at-a-glance. Ah, another ambiguous adjective: at-a-glance. Let's define that.

at-a-glance: a quick look to identify something. Seconds are the key: 1, 2, maybe 3 seconds. A glimpse is all it takes to fully understand.

Through examples:
OOTB Incident BR "Abort changes on group".

(function executeRule (current, previous /*null when async*/ ) {

    // Add your code here
    var assigned_to = current.assigned_to;
    var assignment_group = current.assignment_group;

    var grp = new GlideRecord('sys_user_grmember');
    grp.addQuery('group.sys_id', assignment_group);
    grp.addQuery('user', assigned_to);
    grp.query();

    if (!grp.hasNext()) {
        gs.addErrorMessage(gs.getMessage("Assigned to user {0} must be member of Assignment group {1} ", [assigned_to.getDisplayValue(), assignment_group.getDisplayValue()]));
        current.setAbortAction(true);
    }

})(current, previous);

The above piece is often considered a bite size, at-a-glance beauty in our space. It's smallish, has okay use of whitespace, doesn't do too much. Good, right? Maybe not so very much good.

Because the goal of reading human grammar is to confirm things already known, the heighten complexity of too many thoughts into one function hinder at-a-glance. This is the time when we begin to reason our way into why such function is easily understood.

That style leaves no choice but to inspect each line individually, deducing meaning along the way until morphing into a collective meaning. This happens, then that, this means that, then that is evaluated, until... got it! What does code do? wait, let me ready quickly again. Just to make sure. Hm.

Let's refactor that a little?

(function executeRule (current, previous /*null when async*/ ) {

    isAssigneeAGroupMember(current)
        ? passThrough(current)
        : showErrorAndAbortOperation(current);


})(current, previous);

Did that make it easier to digest? Does at-a-glance this time yield more meaning, less ambiguity than the first? Or are the 12 lines better than the 3 because the ternary is for "advanced" coders? An IF maybe?

The code shrunk, spotlighting just those parts that are of interest: this vs that. No need to delve into individual lines of code to understand the collective. At the top level nothing else matters. The knowledge that non group members fail the operation is enough. Great! No?

While somewhat more explicit, that last tidbit still leaves unanswered questions. What business case is being solved? There is no clear way to know because the Business Rule name is ambiguous, the code doesn't makes up for it either. Knowing that non group members trigger a failure is okay but, what was solved? Why is that code there?

The reader has to interpret the why, has to interpret the use case to answer why the code is there. For my taste, it's too implicit. Aha! Comments!? A little documentation will solve that, right? Yeah, now I'm reading both comments, plus the code to verify they match. Then, there is all that noise of comments distracting the eyes. The code doesn't even match the BR name. huh

The use case is there in those 3 lines and once found, it can be used to explicitly reveal what the code solves. We can answer the boss when asked: what "Abort changes on group" does... well... it prevents non group members from processing the record and prompting them of it.

Think of it as a use case:
As a tech, when an assignee changes, and record is submitted, prompt that only group members can be selected, then abort the transaction.

It is as important to quickly digest code as it is to reveal what is being solved. The "what is being solved" is significant because can become the function names that then replaces comments, reduces clutter and ambiguity. They encapsulate use cases into easily consumable little things.

It is only when the name is insufficient to individual readers, that it is necessary to inspect within the functions themselves. This helps by decreasing reading times to what's of importance.

The final at-a-glance for an entry point function in a Business Rules using human-grammar-like is:

(function executeRule (current, previous /*null when async*/ ) {
    preventProcessingForNonGroupMembers(current); //there is that use case from before

})(current, previous);

If what's inside function preventProcessingNonGroupMembers is important, it's the contents of the second code sample... the ternary in the second code sample. And so on. No one function after does more than exactly one thing: the use case it solves.

Style inside each function can vary (function application, composition, temp variables, etc.) but, the point is that as human grammar in code increases, the easier it becomes to interpret with certainty at-a-glance. It's like asking what does a one page of words mean, as opposed to one word.

If the problem is "does the function do what it says it does", then the problem is beyond names...

Happy snowing...

Talking to myself: Reconsidering Scalable Code Design

Javier Arroyo — Sat, 18 Sep 2021 03:15:31 +0000

I’m an amateur Software Engineer interested in design and composition. I once thought to have been mostly interested in JavaScript but, the focus has shifted to design. The composition of code, the relationship between the parts supersedes the desire to work with the latest libraries, or intricate concepts… it is the impact of structure on composition and the effect on human interpretation that seduces whatever is left of my intellect.

That allure has led me to reconsider de facto resistance I offered when introduced to ideas outside of my familiarities. I just couldn’t find value in say, breaking down prose-like code into numerous units of work. How could specific processes be derived from generalizations? Specific by definition means unique, thereby already a whole unit? A thing of its own outside of other unique processes?

It didn’t help that I had been conditioned to accept that “abstractions” (as represented by breaking down large functions into smaller ones) were cause of grave confusion. That too many layers build walls upon understanding software. Why then, would design be best served in tiny pieces? More elastic when broken down into small little what? Sand grains?

Nah, that monolith was well thought out, built from unique requirements into the essence it became.

Then, as I look in front of me, the letters A-Z above the smartboard go from one side to the other. Those, I’m told are the building blocks of written communication. They make up any word combination an English speaker can conceive. I never disagreed, in fact, there is no other way for me to jot down thoughts within my written language. It both empowers and admittedly limits me.

Limits in the sense that each singular letter across the top of a smartboard will be the only way I’ll be able to formulate meaning. Never mind that I won’t even fathom most of all the abstractions that can be built from them. Conversely, empowering in that they are the very tools allowing my thoughts to transform from ethereal to the earthly. I suppose I’m stuck in the middle; I know what I know and outside of… I just don’t.

That is where composing very small, seemingly unimportant, utility functions come into play. Those abstractions that I rejected because of an inability to identify the possibilities that escaped me were telling me to open my mind. Much like written language with its alphabet, code of all lengths has interchangeable building blocks meant to communicate human meaning. It’s not just one way, there are many. Some with basic form like the letters on a toddler’s book, others classics of the English language.

From 26 English letters, the Oxford English Dictionary has managed to annotate meaning for more than 450,000 words. That’s a lot of words built on the backs of just 26 letters. What would happen, however, if the numbers of letters were decreased? Would that impact the total number of written words? Consider this, how many words can be written with just the vowels? The letters A,E,I,O,U… suppose the permutation is 5 to the fifth power. That’s around 3K entries, and possibly most of them aren’t abstractions of an understood concept.

What does this really have to do with programming? Well, if the goal of articulation, of written expression is achieved by building meaning from the smallest possible unit of grammar, then it reasons that the more general a function, the smaller the function, the more possibilities of being composed into say, a poem, prose, a paragraph, a book, it has. The more chances it has of being included in concepts with concrete meaning.

The reverse appears to be the opposite. That big doesn’t really lead to better, or easier to compose, to manage software. Say there is a function with some 350 lines of code. How many possibilities would that function have of being seamlessly integrated into other processes? Of being re-used elsewhere. Consider this, how compatible is a paragraph about the internal combustion engine with this article? Yet, that combustion engine article is composed from the very same building blocks as this article: letters…

That makes me think that the chances of programming any one complex function that contains unique building blocks is highly unlikely. Perhaps in isolation. At the genesis of a process, the long complex function might be arguably unique yet, soon enough those building blocks, those generalizations that are meant to be used like the letters of the alphabet, will become apparent.

The next step then is to give meaning to those building blocks, to those abstractions. I used to believe that abstractions were a bad thing because they obfuscated meaning. Then, upon reading a collection of letters, it became clear that X amount of letters combined to form meaning didn’t prevent me from understand a complex concept. Their composition didn’t confuse nor make me question why X word became an abstraction, why it came to mean a much larger concept than each of the letters in isolation. No! That abstraction brought meaning, it made words… palpable, relatable, interchangeable… enlightening.

As an example, the noun “programming” is an abstraction of a concept. It gives meaning, not only to the composition of the letters “p,r,o,g,r,a,m,i,n,g” but, also to the context in which the noun is used. It creates a picture of all the possibilities in which the word can be used. I don’t question the validity of the letters “p,r,o,g,r,a,m,i,n,g” as an abstraction of a concept. But, how I questioned building abstractions is still fresh in my mind. I spent too much time closed-in because what I knew of programming kept my from seeing the rest of the vocabulary to enrich my expressions... I have never really built anything unique. I have built unique concepts from the same fabric.

Individually, small functions aren’t really all that useful. However, when composed with one another like letters on a book, they can express it all. Oh how it haunts me that it took this long to see letters in code, the value of the simplest form that too can build innumerable process from just 26 letters, like the alphabet.

Over my shoulder stands each process that was re-invented again and again. Each new use case was accompanied by the same ideology. Believing each to be a unique something. Meanwhile, my codebase grew into this prose-like collection of abstract thoughts as code. In reality, a collection of run-on sentences entangled into nearly indecipherable cohesion that if touched incorrectly, it would crumble.

Over the years, the alphabet continued their silently press against the tip of my fingers from the keyboard. Had I kept my fingers against them just a little longer a-way-long-back-ago, I’m sure it would have told me to consider that back in grade-school the building blocks of written communication were introduced as the a,b,cs...

Build your blocks.

It really was challenging to see.

Working with JournalEntry Fields

Javier Arroyo — Sat, 18 Sep 2021 00:08:37 +0000

Sometimes there is a need to work with JournalEntry fields in script. OOTB the platform offers

//GlideRecord.<fieldName>.getJournalEntry(<numberOfEntries2Fetch>)

var gr = new GlideRecord('incident');
gr.get('<sys_id');

gr.comments.getJournalEntry(-1) //get all comments

The OOTB method can be used to extend functionality when necessary. Say a need arose to get an array of entries, or in json format, or some sort of html. By encapsulating the OOTB method call then, exposing an api, one can:

The Test GlideRecords

var dml = new GlideRecord('dsl');
dml.get('31a60f4bdb2a70109c9268d35b96196e');

var incident = new GlideRecord('incident');
incident.get('57af7aec73d423002728660c4cf6a71c');

The test cases

gs.debug(JSON.stringify(JournalEntry(dml)
    .field('notes')
    .toJSON(1)));

/* get the latest entry in JSON format from journal field 'notes' in record GlideRecord<dsl>

-> {"2021-09-16 21:18:43 - System Administrator":"\nnoted"} 
*/

gs.debug(JournalEntry(incident)
    .field('work_notes')
    .toHTML(-1));

/* get all of the entries in "HTML" format from journal field 'work_notes' in record incident

-> "<div>2021-09-16 21:13:03 - System Administrator (Work notes)<br />worked notes<br /><br />2018-12-12 23:30:24 - System Administrator (Work notes)<br />Changed the priority of the Incident<br /><br /></div>"
*/

gs.debug(JournalEntry(incident)
    .field('comments')
    .toArray(2));

/* get latest 2 entries as an array from journal field 'comments' in record incident

-> ["2021-09-16 19:18:52 - System Administrator (Additional comments)\nthis is another comment\r\n\r\n\r\nand another","2021-09-16 12:24:57 - System Administrator (Additional comments)\nBecause we need them",""]
*/

gs.debug(JournalEntry(dml)
    .field('notes')
    .toString(-1));

/* get all entries as a string from journal field 'notes' from GlidRecord<dsl>. Same as OOTB

-> "2021-09-16 21:18:43 - System Administrator (Notes)\nnoted\n\n"
*/

The formatting for each output may be adjusted in the utility that looks like this:

var JournalEntry = function JournalEntry (gr) {
    var data = {
        "gr": gr,
        "fieldName": null,
        "count": -1
    };

    return {
        "field": setFieldName,
        "toHTML": toHtml,
        "toJSON": fromArrayToJSON,
        "toString": toString,
        "toArray": toArray
    };


    /*************************** public members ***********************/

    function toString (count) {
        return _journalFieldEntries(data, count);

    }

    function toArray (count) {
        var ootbEntryDelimiter = '\n\n';

        return _journalFieldEntries(data, count)
            .split(ootbEntryDelimiter);

    }

    function toHtml (count) {
        var anyReturnOrNewLine = /\n|\r/g;
        var brTag = '<br />';

        var entries = _journalFieldEntries(data, count)
            .replace(anyReturnOrNewLine, brTag);

        return _betweenDivTag(entries);

    }

    function fromArrayToJSON (count) {

        return toArray(count)
            .reduce(_toKeyPair(_keyRegex(data.gr)), {});

    }

    function setFieldName (x) {
        data.fieldName = x;

        return this;
    }



    /*************************** private members ***********************/

    function _journalFieldEntries (data, count) {
        var x = count || data.count;

        return data.gr[data.fieldName]
            .getJournalEntry(x);

    }


    function _keyRegex (gr) {
        var fieldLabel = gr.getElement(data.fieldName)
            .getLabel();

        return new RegExp('\\(' + fieldLabel + '\\)', 'i');

    }


    function _toKeyPair (splitPattern) {
        return function applyToKeyPair (reducer, element) {
            var pair = element.split(splitPattern);
            var key = pair[0].trim();

            reducer[key] = pair[1];

            return reducer;
        };
    }


    function _betweenDivTag (value) {
        return "<div>" + value + "</div>";
    }
};

Method "field" specifies from which field in the GR to get entry values.

Methods "toHTML", "toJSON", "toArray" and "toString" are the terminal methods that return journal field entries given an integer value that specifies how many entries to retrieve. -1 being all, and any positive integer to get specific number of entries in date descending order.

Happy SNowing...

ServiceNow - Handling rogue preconditions

Javier Arroyo — Wed, 15 Sep 2021 01:03:03 +0000

This article talks about preemptive methods against overzealous preconditions. Preconditions are conditional (true/false) statements that must evaluate to true to continue code execution. For the purpose of this article I’ll concentrate on those preconditions placed at the top lines of code inside a function that are used to assert the validity of parameters.
Example A:

function sendGiftToOldPeople (age) {
    If (age >= 40) { return; } 
  // if age is not 40, code below this point won’t execute.
}

A use case will be presented, solved the ServiceNow way then, cleaned up to prevent it from becoming a cryptic conglomerate for the next reader to decipher. Because having to interpret code increases the amount of time required to make sense of code, it makes sense to try to reduce code noise anywhere possible to prevent future-self from the rogue precondition jitters.

Just like anything else. Handling preconditions is part of a skillset used within a larger code structure scheme. A scheme aimed at building relatively uniform code everywhere; even if the skillset required to work at different parts of the codebase is different. To get there, well, that’s where the ideas here may help.
Before moving on, a little disclosure. We are at this point of cleaning preconditions because of a lack of oversight. A different view on programming could have prevented this.
On to the example:

A Basketball team has an open position. Tryouts are held, and data collected will be used to determine team invites. The coach gives us the following requirements.

• Must be at least 6’11 (83 inches) tall
• Must be at least 250 lbs (not to be pushed around)
• Must be older than 18
• Must have an outside shot
• Must have quick feet
• Must run at least a 6 second 40 dash
• Must reside within 15 miles of the facility

After each of those conditions is successfully met, an email invitation should be sent out.
Because this is ServiceNow, bang easy job:

function extendInvitationToBasketballPlayer (height, weight, age, hasOutSideShot, hasQuickFeet, fourtyDashTime, distanceFromFacility, address) {

    if (!hasOutSideShot || !hasQuickFeet) {
        return false;
    } //must be able to shoot from outside, and be quick
    if (height < 83 && weight < 250 && age >= 18) {
        return false;
    } //must be at least 83 inches tall, must be at least 250 lbs tall, and must be older then 18

    if (fourtyDashTime < 5000 || distanceFromFacility > 15) { //must be fast and live close enough to facility
        return false;
    }

//everyone else can be invited
    var mail = new Email(address.email);
    mail.body("we invite you to play with us. You are just the right fit. Lets win a championship");
    email.send();

}

After a number of unsuccessful tryouts, it comes to light that key requirements have been missing. No invites have been sent out because of these two new conditions:
• Must have own car
• Must be related to the coach (there is something fishy going on)
Easy-peasy, ServiceNow makes this very easy. Let's revisit the function to append the latest preconditions.

function extendInvitationToBasketballPlayer  (height, weight, age, hasOutSideShot, hasQuickFeet, fourtyDashTime, distanceFromFacility, address, car, relationshipToCoach) {

    if (!hasOutSideShot || !hasQuickFeet) {
        return false;
    } //must be able to shoot from outside, and be quick
    if (height < 83 && weight < 250 && age >= 18) {
        return false;
    } //must be at least 83 inches tall, must be at least 250 lbs tall, and must be older then 18

    if (fourtyDashTime < 5000 || distanceFromFacility > 15) { //must be fast and live close enough to facility
        return false;
    }

    if (car !== null) { //needs a car to drive back and forth to the games
        return false;

    }

    if (['nephew,son,brother'].toLowerCase().indexOf(relationshipToCoach.toLowerCase()) == -1) {
        return false;
    }

//everyone else can be invited
    var mail = new Email(address.email);
    mail.body("we invite you to play with us. You are just the right fit. Lets win a championship");
    email.send();

}

Trivial as they are, organic growth has cluttered things up. The most important parts of the function can’t be spot-lighted in that reading burden.

To keep this post relatively read-able, I won’t labor any further; instead, I will attempt to convert extendInvitationToBasketballPlayer into an executive summary without necessarily going into best practices. I won’t explain much either, the outcome should yield a closer, at-a-glance understanding.
Replacing extendInvitationToBasketballPlayer

Start with reusable utility functions not to have to get away from having to type code best interpreted by a compiler.

 function not (x) {
        return !x;

    }

    function isNothing (x) {
        return typeof x === undefined || x === null;

    }

    function isLessOrEqualThan (x) {
        return function applyLessThan (y) {
            return x <= y;

        };
    }

    function isGreaterOrEqualThan (x) {
        return function applyGreaterThan (y) {
            return x >= y;

        };
    }

Convert all predicates into functions. This is purely to give meaning and gain elasticity. By meaning I mean seeing the business requirement written outright in code.

     function meetsMinimumShootingDistance (invitee) {
        return isGreaterOrEqualThan(invitee.restrictions.MINIMUM_SHOOTING_DISTANCE)(invitee.shootingDistance);

    }

    function hasQuickFeet (invitee) {
        return invitee.hasQuickFeet;

    }

    function meetsMinimumHeightRestriction (invitee) {
        return isGreaterOrEqualThan(invitee.restrictions.MINIMUM_HEIGHT)(invitee.height);

    }

    function meetsMinimumWeightRestriction (invitee) {
        return isGreaterOrEqualThan(invitee.restrictions.MINIMUM_WEIGHT)(invitee.weight);
    }

    function meetsMinimumAgeRestriction (invitee) {
        return isGreaterOrEqualThan(invitee.restrictions.MINIMUM_AGE)(invitee.age);

    }

    function meets40DashRestriction (invitee) {
        return isGreaterOrEqualThan(invitee.restrictions.MINIMUM_40_DASH)(invitee.fourtyDash);

    }

    function isCloseToFacility (invitee) {
        return isLessOrEqualThan(invitee.restrictions.MAXIMUM_DISTANCE_TO_FACILITY)(invitee.address.distanceFromFacility);

    }

    function hasOwnTransportation (invitee) {
        return not(isNothing(invitee.transporationMethod));

    }

    function hasRequiredRelationshipToCoach (invitee) {
        var relationships = invitee.restrictions.REQUIRED_COACH_RELATIONSHIPS;

        var userRelationships = relationships.join(',')
            .toLowerCase()
            .split(',');

        return userRelationships.indexOf(invitee.relationship.toLowerCase()) !== -1;

    }

    function hasAddress (invitee) {
        return not(isNothing(invitee.address));

    }

That's a mouthful of functions. let's see what happens with them.

Not to get sidetracked after the predicates, the most important part of the code needs to be accounted for: sending the invite

    function sendInvitationEmail (invitee) {
        var mail = new Email(invitee.email);
        mail.body("we invite you to play with us. You are just the right fit. Lets win a champtionship");
        email.send();

    }

Now that each independent thought has been articulated, they can used to build a comprehensive idea.
Putting it all together 1:

Step A: Build a function that determines what it means to be extended an invitation. It clumps all the preconditions into a container of their own.

function canBeExtendedAnInvitationToJoinTeam (invitee) {
    return hasAddress(invitee) &&
        hasRequiredRelationshipToCoach(invitee) &&
        hasOwnTransportation(invitee) &&
        isCloseToFacility(invitee) &&
        meets40DashRestriction(invitee) &&
        meetsMinimumAgeRestriction(invitee) &&
        meetsMinimumWeightRestriction(invitee) &&
        meetsMinimumHeightRestriction(invitee) &&
        hasQuickFeet(invitee) &&
        meetsMinimumShootingDistance(invitee);

}

Step B: A low level utility to separate the use of predicates from the behavior that needs to take place when all conditions are satisfied.

function Predicate (predicateFn, onSuccessFn, data) {
    return predicateFn(data) && onSuccessFn(data);

}

Step C: Rebuild original function extendInvitationToBasketballPlayer using the utility function, the container for the predicates, and… sending the email. Please note that I took the liberty to create an object called “invite” from function arguments.

function extendInvitationToBasketBallPlayer (invitee) {
    return Predicate(canBeExtendedAnInvitationToTeam, sendInvitationEmail, invitee);

}

The above is much cleaner but, because it’s a m-nary method I’m now stuck having to remember parameter order and their meaning.

Cleanup method 2
Step A. Another utility to handle the predicates. This one is going to be more involved because a small API will be exposed to see if less ambiguity can be attained.

function Predicate (data) {

    var predicates = [];

    return {
        check: check,
        onSuccess: onSuccess
    };

    function check (predicate) {
        predicates.push(predicate);

        return this;
    }

    function onSuccess (callback) {

        var totalTruthy = _countTrutyPredicates(_sum, predicates, data);
        return _wereAllPredicatesSuccessful(predicates, totalTruthy) ? callback(data) : null;

    }

    function _sum (data) {
        return function applySum (reducer, fn) {
            return reducer += fn(data);
        };
    }

    function _countTrutyPredicates (reducerCallback, preds, data) {
        return preds.reduce(reducerCallback(data), 0);

    }

    function _wereAllPredicatesSuccessful (preds, truthyCount) {
        return preds.length === truthyCount;

    }
}

Step B: Rebuild original function extendInvitationToBasketballPlayer using The new Predicate utility. This time each predicate will be listed individually.

function extendInvitationToBasketballPlayer (invitee) {
    return Predicate(invitee)
        .check(hasAddress)
        .check(hasRequiredRelationshipToCoach)
        .check(hasOwnTransportation)
        .check(isCloseToFacility)
        .check(isCloseToFacility)
        .check(meets40DashRestriction)
        .check(meetsMinimumAgeRestriction)
        .check(meetsMinimumWeightRestriction)
        .check(hasQuickFeet)
        .check(meetsMinimumShootingDistance)
        .onSuccess(sendInvitationEmail);

}

Another option is to re-use the existing container for the predicates as such:

function extendInvitationToBasketBallPlayer (invitee) {
    return Predicate(invitee)
        .check(canBeExtendedAnInvitationToTeam)
        .onSuccess(sendInvitationEmail);

}

Hopefully this looks prettier than having all the preconditions lexically placed inside a fuction.
Cleanup Method 3:
The same idea but, this time passing the predicates as the initial parameter

function Predicate(predicates) {

    var successful = false;
    var data;
    var funs = Array.prototype.slice.call(arguments);

    return {
        check: test,
        onSuccess: onSuccess
    };

    function onSuccess(fn) {
        return successful && fn(data);

    }

    function test(value) {
        successful = _areAllPredicatesTrue(_filterByTruePredicates(_applyPredicateTestToData(value)));
        data = value;

        return this;
    }

    function _filterByTruePredicates(isTrueFn) {
        return funs.filter(isTrueFn);

    }

    function _areAllPredicatesTrue(result) {
        return result.length === funs.length;

    }

    function _applyPredicateTestToData(data) {
        return function test(fn) {
            return fn(data);

        };

    }

}

With the new Predicate built, it’s time to give it a go

function extendInvitationToBasketballPlayer (invitee) {
    var predicate = Predicate(hasAddress, hasRequiredRelationshipToCoach, hasOwnTransportation, isCloseToFacility, meets40DashRestriction, meetsMinimumAgeRestriction, meetsMinimumWeightRestriction, meetsMinimumHeightRestriction, hasQuickFeet, meetsMinimumShootingDistance);

    return predicate
        .check(attendee)
        .onSuccess(sendInvitationEmail);

}

function extendInvitationToBasketBallPlayer (invitee) {

    return Predicate(canBeExtendedAnInvitationToTeam)
        .check(attendee)
        .onSuccess(sendInvitationEmail);

}

While I’ve left other strategies unexplored, I hope the ones here help the next time a bunch of predicates clutter your code.
Whichever way is chosen, keep in mind that functions tend to grow organically in the absence of conventions. It is a good practice to nip this stuff upon seeing it, rather than letting it linger. By being diligent, a codebase will slowly gain a common structure that is flexible and easy to navigate.

ServiceNow Cross-Scope Access to Private Members

Javier Arroyo — Sat, 20 Mar 2021 03:54:09 +0000

TL;TR
Export/Import a Script Include from/to scopes to achieve cross-scope access of private Script Includes without having to change their Accessibility to "All application scopes".

Origin of this post
A cross-scope accessibility question about executing private members of one scope from inside another was raised in sndev.slack.com #codereview channel. The desire wasn't as much as to call a single script include, but to be able to call any script include without having to edit its accessibility rights. Leave OOB artifacts intact yet, still be able to use them from other scopes.

When a private Script Include is called from outside its scope, “Evaluator: java.lang.SecurityException: [Method Name] is not allowed in scoped applications” is thrown. For those working in Scopes, it becomes terribly irritating and limiting. It's either edit OOTB artifacts, or throw a hail-marry with extension points. These is no mechanism to "wholesale" use private script includes from any scope. Should there be? That can be a good debate.

I do not clearly recall who raised the question, my apologies if mistaken. It could have been Tim Woodruff. He sought a proven and tested method to bypass platform restrictions (naughty boy).

While I have never experienced any cross-scope security restrictions from any of the strategies I’ve built through the years, it doesn’t necessarily mean that the approaches were/are viable. Public scrutiny is most welcomed.

The SecurityException is raised when executing a Script Include that has outside the containing scope.

The private script include below is an example of a script that will generate a SecurityException; notice field Accessible from is set to This application scope only.

Side stepping the exception, from where to derived the solution
Early on when the platform introduced scopes and applications, the strategy of "Jump" Scripts to expose private members outside a scope was also born. Methods inside the "Jump" script delegated to to private Script Includes inside the same scope. The platform indirectly advertised the solution to cross-scope security exceptions. It really doesn't care how a private member is executed as long as its done so through a public member belonging to the same scope.

This meant that exporting a public SI with a more suitable delegation strategy would allow execution of private members to other scopes. The restriction remains that the caller must be public and part of the source scope but, the open door is enough. All that's needed is little digging in.

Side note
If you are going to use the approaches shown here, also use some sort of governance for object composition to track who is using what.

My provided approach in sndev Slack
From the source scope, export a utility function that when supplied arguments will call a private, or not, Script Include.

Script Include ExportGlobalAccess has field Accessible from set to All application scopes. It is an IIFE that returns a curried function. During the first execution it's supplied 2 arguments; the script include name, and the script include parameter. It's second execution needs to be supplied with the method name in the script include and the argument to use. This fancier "jump" script has room for improvement; such as support for n-ary, and non-constuctor functions. But, it's a way to call any OOTB Script Include from any scope.

To use it from a target scope

global.ExportGlobalAccess(‘SIName’,’SIParam’)(‘SIMethodName’,’SIMethodParam’)

An import SI to decrease verbosity and introduce flexibility is always helpful. All it does is call the exports Script Include from the target scope. Such as:
Importing global.ExportGlobalAccess example

Using the shortcut SI from the target scope looks like this

GlobalScope(‘SIName’,’SIParam’)(‘SIMethodName’,’SIMethodParam’);

Second Approach
Instead of a exporting a utility function from the source scope, “Register” script includes to be mixed into a "public" API.

The “registration” mechanism is a sys_property 😊 to store the names of the script includes to export as a comma delimited string.

Then some script includes purely for POC

The Exports Script Include
Uses the sys_property to determine which SIs to include in the API.

The output of Exports:

{ foo: function (value){}, bar: function (value){}, baz: function (value){} }

When more names are added to the sys_properties, they'll show up in the exported API.

Next. Imports the exports SI into a target scope

Usage:
Call the functions directly, or in a pipe.

gs.debug( pipe([ImportsMess.foo, ImportsMess.bar, ImportsMess.baz])('javier'));

Output:

Summary:
By exporting a Script Include from a source scope then importing it to another scope, private members can be executed cross scope. Those displayed in this article are not the only strategies available, it is entire up to the implementer.

Happy Snowing