2020-05-13 at

You're looking for advice on building a marketing platform for F&B businesses?

/Q&A in a forum/

Just got back to a desk. Had to go register for a new water meter just now LMAO. Let me try and answer your concern directly ... hmm.
You want [F&B businesses] to use a [marketing platform] to gain [membership] from their [customers]. 
We need to take this apart a bit ... 

  1. Do F&B businesses want to be associated with platforms? Would platforms have a negative or positive perceived value to an F&B business - negative meaning that even if you paid the F&B business, they wouldn't want to be associated with a platform? This is up to you to research. 
  2. Do F&B businesses want members? I rarely hear these two words in the same sentence. 
  3. Do you think your concept of membership benefits the platform more or the F&B business? What is the end game for the platform? What is the end game for the F&B business? 
I'll give you an example that has come up in conversation recently. Let's take UberEats and similar businesses as an example. For every food vendor that UberEats signs up, they get closer to their end game of running a monopoly in the horizontal of online order origination between eaters and vendors of food. However, no matter how many items a vendor of food sells on UberEats, they will never achieve a monopoly in any horizontal, or vertical whatsoever. The incremental benefits are severely asymmetrical in such a case. 

How would you build a platform, which enables an F&B business to become a monopoly (in any subspace)?

Go for it!

2020-05-12 at

Hard Choices and Censorship (in JavaScript)

I think I'm ready to lay down some rules, a sort of style guide, for this framework I'm writing for Node-on-Lambda.

* How to Deploy Functions in this Software Framework *

-   ALWAYS use arrow function expressions (AFEs), UNLESS there is a specific 
    need to refer to a function as `this` from within its own body ... and to
    a less significant degree, if you need the function's `arguments` array.
    Heuristics: prefer terseness; explicitly state intentions.

-   ALWAYS use async functions, UNLESS there is a specific advantage to force 
    synchronous responses. Heuristic: prefer decoupling.
    
-   Use generator functions ONLY when there is a specific need for such
    functionality. (Note added for completeness. Did we miss any other type of 
    function?)

* How to Deploy Promises in this Software Framework *

-   ALWAYS use the following taxonomy:

    (   Promise ( 
            ( fulfillFn, rejectFn ) => {}   // an `executor`
            
        ).then(
            onFulfilled ( value )   => {},  // a Promise is `settled`1
            onRejected  ( reason )  => {}   // a Promise is `settled`2
            
        ).catch(                            // sugared  .then()
            onRejected  ( reason )  => {}
            
        ).finally(
            regardless  ()          => {}   //  No argument is ever passed.
        )
    ) 
    
-   Do NOT use:     `resolve`   in place of     `fulfill`
                    `resolved`  in place of     `settled`
                    `result`    in place of     `value`
                    `error`     in place of     `reason`

    Heuristic: prefer standards (the etymology is complex; I have a slide).

-   ALWAYS enter both arguments of Executors, and .then(), EVEN IF one argument
    will not be used. For minimal line noise, consider using `_`, `f`, `r`, 
    `onF`, `onR`. Heuristic: terseness; explicitly deny options.

-   ALWAYS use `await`, and therefore `try { await } catch (e) { handler }`
    UNLESS some of the above is more succinct. Heuristics: terseness; explicitly
    state intentions.