raas, rounding as a service: l'api de broma que arrodoneix números

raas vol dir rounding as a service. és una api que fa una sola cosa, arrodonir números, i que es ven com si fos infraestructura crítica. té tres plans de pagament i un nom registrat per a cada mètode, i cada resposta et diu quanta precisió has perdut.
el 2 de març la vaig penjar a linkedin, escrita com un llançament b2b de debò, i va tenir 419 impressions i 4 reaccions. després la vaig penjar a reddit, on va passar de 440.000 visualitzacions i va ser el post més vist d'aquell dia a la portada de r/programmerhumor.
la broma ha de semblar un producte
la regla era que la pàgina, llegida en diagonal, passés per una saas qualsevol. el titular diu "enterprise-grade decimal management". a sota hi ha les tres insígnies de sempre: "99.999% uptime sla", "soc 2 type ii" i < 0.3ms latency. cap de les tres és certa, i la tercera la desmenteix la mateixa api.
els preus segueixen el mateix patró. el pla gratuït inclou "community support (reddit)". el pro costa 49 dòlars al mes i ofereix "priority latency (+40ms faster)". l'enterprise en costa 99 i inclou una "rounding insurance policy" i desplegament on-premise. sota els tres plans, en lletra petita: "all plans include 256-bit aes encryption for your decimals. because security." el botó "schedule a demo" porta a un rick roll.
els tres mètodes són tres funcions de la llibreria estàndard de javascript amb un nom registrat:
| paràmetre | nom al producte | pla | què fa |
|---|---|---|---|
settle | Gravitational Decimal Settling (GDS)™ | gratuït | Math.floor |
elevate | Aspirational Decimal Elevation (ADE)™ | pro | Math.ceil |
smart | Smart Rounding™ | enterprise | Math.round |
la gràcia és la distància entre la frase i el codi. la web descriu smart rounding com a "ai-adjacent proximity snapping" que avalua algorítmicament el delta del teu decimal respecte als enters veïns. és Math.round.
l'api funciona de debò
una landing de broma la pot fer qualsevol. el que fa que aguanti és que, quan algú copia l'exemple de la portada i el prova, li respon una api de veritat, amb el mateix to. el nucli són set línies:
if (methodParam === "smart") {
result = Math.round(num);
} else if (methodParam === "elevate") {
result = Math.ceil(num);
} else {
result = Math.floor(num);
}
la resta és embolcall. la primera versió ja arrodonia exactament igual. tota la broma hi va entrar després en un sol commit, que va fer passar la ruta de 87 a 116 línies, i cap de les línies noves arrodoneix res. la resposta que surt al readme és aquesta:
{
"status": "success",
"data": { "original_value": 4.82, "rounded_value": 5, "precision_loss": 0.18 },
"metadata": {
"algorithm_used": "Smart Rounding™",
"computation_time_ms": 112.45,
"is_integer": true
}
}
precision_loss és la diferència entre el número que envies i el que et torna, perquè sàpigues quanta informació has destruït. is_integer és true perquè el resultat surt de Math.floor, Math.ceil o Math.round. només és false en un cas. si envies Infinity, l'api respon "status": "success" amb tots els valors a null, perquè json no té manera d'escriure infinit.
computation_time_ms és el camp que més m'agrada. la portada promet menys de 0,3 ms, i l'api hi suma entre 40 i 120 ms inventats:
const fakeLatency = Math.random() * 80 + 40;
els errors també formen part del producte. cadascun fa servir el codi http que toca, amb un missatge corporatiu:
appleobananatornen un 418 i'm a teapot: "cannot apply mathematical truncation to fruit." el 418 ve de l'rfc 2324, la broma de l'1 d'abril de 1998 sobre cafeteres. una pera, en canvi, no compta com a fruita i torna un 422.- qualsevol altra cosa que no sigui un número torna un 422 unprocessable entity, que et demana "a compliant 'number' query parameter".
- un mètode que no existeix torna un 400: "is not a recognized corporate rounding strategy".
- un mètode d'un pla superior al teu torna un 402 payment required: "the 'smart' algorithm is locked behind a higher paywall." l'estàndard http fa dècades que té el 402 reservat per a ús futur. aquí serveix per al que diu el nom.
el repositori també és part de la broma
el readme té les insígnies d'un projecte seriós: build passing, 99.999% d'uptime, una sèrie a de 14 milions de dòlars i 8.432 dependències. només s'hi accepten pull requests de "developers with at least 15 years of experience in decimal mitigation". al final hi ha una nota per a l'equip: "please stop committing the .env file. dave, this is your last warning."
el .env, evidentment, és al repositori. el commit que l'afegeix també treu del .gitignore la línia .env* que create-next-app hi posa per defecte. per poder pujar el fitxer, primer vaig haver de desfer la protecció contra pujar-lo. a dins hi ha:
- una
REDIS_CACHE_URLamb el comentari "used for caching the number 4". ENABLE_QUANTUM_FLOORING=false, perquè "it was occasionally rounding 2 down to 1".- una base de dades que es diu
fractional_reserve_db, on es guarden "the decimals we shave off from the free tier users".
la mateixa broma a reddit i a linkedin
el primer post a linkedin el vaig escriure amb el to dels llançaments de linkedin: "estem delegant tasques hipercomplexes a la ia, però seguim gestionant els nostres propis decimals localment? és una bogeria." 419 impressions, 4 reaccions. a reddit, la mateixa sàtira va passar de 440.000 visualitzacions.
no tinc dades per saber per què. el que sí que veig és una diferència de context. a linkedin, una paròdia d'un post de llançament b2b es llegeix com un post de llançament b2b més, perquè s'assembla massa a la resta del feed. a r/programmerhumor, abans de llegir res ja saps que és una broma, i qui la llegeix sap què fa Math.round.
l'altra dada és la del segon post. el 9 de març vaig tornar a linkedin a explicar què havia passat a reddit, i va tenir 783 impressions, gairebé el doble que el primer. a linkedin va funcionar més explicar l'èxit de la broma que la broma mateixa.
a github, el repositori té 21 estrelles i cap fork. l'api, mentrestant, continua responent que no pot truncar fruita.