OT Programmazione - rolling release

[XWolverineX]

È capitato abbastanza di rado, e l'ultima volta è fallito tutto (ma perché il cliente era un imbecille, non per le nostre API ), per cui non credo di poter dare consigli troppo validi tanto credo dipenda molto dal tipo di applicazione e di target di utilizzo delle API - un conto è se è un progetto pilota per un singolo cliente con API fatte su misura per lui, un altro è se sono Twitter e devo fare API per il pubblico generale. Tu in che caso rientri?

In realtà sono in una categoria a parte visto che l'azienda per cui lavoro (Apiary) sviluppa strumenti per API Design, e non molto tempo fa ho parlato a Londra di cosa c'è di sbagliato nelle metodologie di design correnti. Avrei piacere se potessi vederlo e dirmi se ti trovi con le mie tesi!

[MItaly]

Visto il talk.

Sostanzialmente mi trovo d'accordo su gran parte delle cose, anche se come ho detto ho esperienza della questione fino ad un certo punto. Tipicamente, i servizi/le librerie che scriviamo sono abbastanza ad uso interno, anche se, specialmente per cose a cui stiamo mettendo mano ora, abbiamo N client con visioni abbastanza diverse del problema e che vogliono farsi poco i fatti dell'implementazione, per cui parte dei principi che citi emergono in maniera abbastanza naturale.
Un paio dei prodotti di cui parli mi sembrano interessanti e mi riprometto di darci un'occhiata; le specifiche-markdown magiche e il generatore di mock-server possono essere interessanti per roba a cui stiamo mettendo mano in questo momento.

Solo un paio di considerazioni, la prima di carattere generale: onestamente, è un po' sempre la solita pappa del waterfall vs agile e compagnia, con implicito un po' del discorso del capire le esigenze dell'utente (personas, goals, ...) che si usa (o almeno, si dovrebbe usare) in progettazione GUI; tutto vero e tutto giusto, ma alla fine sono un po' sempre gli stessi concetti che girano da "The Pragmatic Programmer" in poi.

Altra cosa: ok il design orientato al consumer della API e non costringere il client a sapere dettagli di implementazione assurdamente precisi (arrivare a leakare i nomi delle tabelle è inscusabile), ma come tutte le astrazioni, inevitabilmente c'è un leak dell'implementazione, se non altro a livello di performance. L'esempio che facevi dello sviluppatore lato client che vuole avere tutto in un'unica richiesta ovviamente regge finché i dati sono gestibili in un'unica richiesta - in altre parole, se ci si inizia a spingere un pelo più in là le API devono comunque tenere conto dei constraint tecnici. A quel punto credo che la soluzione giusta sia fare le API a due livelli, con il livello basso e complicato per quelli a cui servono API ad alte prestazioni e/o per casi d'uso complicati, e quella "facilona" per tutti gli altri (possibilmente una costruita sull'altra).

[MItaly]

Annuncio di servizio: finora ogni tanto facevo un reset completo del thread OT togliendo il pinning dal thread vecchio e mettendolo sul nuovo, ora proverei a passare in "modalità rolling": ogni tanto sposto i post vecchi del thread in un thread separato, mettendo nella nuova testa del thread un link a dove trovare i messaggi vecchi. L'idea è che resti una specie di lista linkata di chunk di dimensioni ragionevoli (tipo std::deque ), lasciando sempre nel thread corrente un po' di contesto, in modo che la discussione possa proseguire senza "hard reset" forzati.

[XWolverineX]

Innanzitutto grazie per averlo guardato, spero ti abbia dato per lo meno dei nuovi input.

Visto il talk.
abbiamo N client con visioni abbastanza diverse del problema e che vogliono farsi poco i fatti dell'implementazione, per cui parte dei principi che citi emergono in maniera abbastanza naturale.

Interessante. Avresti mica voglia di espandere il discorso? Utilizzate qualche metodologia particolare per disaccoppiare i dettagli di implementazione dai client? Hypermedia, per esempio?

Un paio dei prodotti di cui parli mi sembrano interessanti e mi riprometto di darci un'occhiata; le specifiche-markdown magiche e il generatore di mock-server possono essere interessanti per roba a cui stiamo mettendo mano in questo momento.

Mi fa piacere. Possiamo anche continuare la cosa in privato se hai bisogno di aiuto o cose varie.

Solo un paio di considerazioni, la prima di carattere generale: onestamente, è un po' sempre la solita pappa del waterfall vs agile e compagnia, con implicito un po' del discorso del capire le esigenze dell'utente (personas, goals, ...) che si usa (o almeno, si dovrebbe usare) in progettazione GUI; tutto vero e tutto giusto, ma alla fine sono un po' sempre gli stessi concetti che girano da "The Pragmatic Programmer" in poi.

Concordo in pieno. Purtroppo la mia presentazione era totalmente differente. Quando poi mi sono reso conto (al primo giorno) del livello medio dello sviluppatore presente alla conferenza (tanti ragazzini alle prime esperienze che già possono permettersi di spendere 800 pound per una conferenza...), ho dovuto fare una forte virata e partire dai concetti base, scontati per persone con un pò più di esperienza. Posso andare oltre, te lo posso assicurare

Altra cosa: ok il design orientato al consumer della API e non costringere il client a sapere dettagli di implementazione assurdamente precisi (arrivare a leakare i nomi delle tabelle è inscusabile), ma come tutte le astrazioni, inevitabilmente c'è un leak dell'implementazione, se non altro a livello di performance. L'esempio che facevi dello sviluppatore lato client che vuole avere tutto in un'unica richiesta ovviamente regge finché i dati sono gestibili in un'unica richiesta - in altre parole, se ci si inizia a spingere un pelo più in là le API devono comunque tenere conto dei constraint tecnici. A quel punto credo che la soluzione giusta sia fare le API a due livelli, con il livello basso e complicato per quelli a cui servono API ad alte prestazioni e/o per casi d'uso complicati, e quella "facilona" per tutti gli altri (possibilmente una costruita sull'altra).

Chiaro, lo fanno tanti altri, React in primis (anche se non si tratta di WebApi). La domanda (tagliata in parte), era più che altro a una ripresa del concetto che avevo espresso prima: se nell'API che sto esponendo la mia entità di base è Coffee, mi aspetto di poter fare diverse operazioni su di esso con una singola chiamata, e non spezzettandole in 8 chiamate perchè nella mia base di dati l'entità è divisa in tale modo.

L'idea che ho cercato di trasmettere è che a mio parere, quando si espone un'API, si sta scrivendo software su un layer diverso da quello che fa girare generalmente il software di base.
Molto spesso invece i programmatori, quando ricevono la richiesta Ehi, ci serve una API, al 90% prendono quello che hanno nel backend, lo collegano in qualche modo e sparano cannonate di JSON, senza preoccuparsi dell'utilizzatore finale.

Dall'altro lato ci sono invece prodotti totalmente API based (ove il client stesso usa le API), che sarebbe l'approccio ideale. Vedi Parse, Stripe, alcune parti di Azure e così via.

Un saluto,
V.

[Scara95]

Credo di capicchiare... in realtà quindi le funzioni come sintassi tendono più verso l'idea degli operatori (unari e binari)... sostanzialmente è tutto un gioco di notazione infissa (vs prefissa => LISP, postfissa => FORTH, Postscript & co., prefissa in generale e infissa solo per alcuni operatori => più o meno tutto il resto).

Sì e no

[fermat]

ciao!

girovagando mi sono imbattuto in groovy.
ho letto un pò di esempi che mostrano le differenze con java, e sembrerebbe interessante.
qualcuno di voi lo hai mai usato / testato??

[MItaly]

Interessante. Avresti mica voglia di espandere il discorso? Utilizzate qualche metodologia particolare per disaccoppiare i dettagli di implementazione dai client? Hypermedia, per esempio?

Non mi riferivo a nulla di particolarmente formale, diciamo che è più che altro emersa la necessità di disaccoppiare certi dettagli di implementazione da come i client effettivamente vogliono usare i dati, anche perché certi dettagli implementativi sono effettivamente orrendi. Il problema però è che al contrario ogni tanto emergono richieste per cui sarebbe necessario entrare nel merito di come è effettivamente l'implementazione per poter realizzare soluzioni decentemente efficienti (paradossalmente, di recente è saltata fuori la richiesta di aggiungere una certa informazione in un nostro formato file, cosa che è banale nel formato file in sé, ma è un pasticcio per come è stata esposta l'API ).

Mi fa piacere. Possiamo anche continuare la cosa in privato se hai bisogno di aiuto o cose varie.

Ti faccio sapere appena ho un attimo per guardarci bene, è un periodo che siamo tutti un po' di corsa dietro altre cose.

L'idea che ho cercato di trasmettere è che a mio parere, quando si espone un'API, si sta scrivendo software su un layer diverso da quello che fa girare generalmente il software di base.
Molto spesso invece i programmatori, quando ricevono la richiesta Ehi, ci serve una API, al 90% prendono quello che hanno nel backend, lo collegano in qualche modo e sparano cannonate di JSON, senza preoccuparsi dell'utilizzatore finale.

Sì ecco, però lì il problema è di altro tipo, è come quelli che fanno l'export XML con un unico tag, CDATA e giù il binario del formato proprietario in base64.

Dall'altro lato ci sono invece prodotti totalmente API based (ove il client stesso usa le API), che sarebbe l'approccio ideale. Vedi Parse, Stripe, alcune parti di Azure e così via.

Ecco l'idea nostra per i nostri prodotti ora vorrebbe essere quella - le API partono per essere a nostro uso interno, poi se si intende vendere l'accesso a terzi si vedrà; che io sappia è quello che è successo con Amazon AWS (e altri loro prodotti partiti per uso interno). Va anche detto che il nostro è un ambito un po' particolare e relativamente chiuso, non credo ci sia un fiorente mercato di ISV che scrivono plug-in per macchine per taglio a lama - piuttosto, quello che effettivamente capita è che clienti piuttosto grossi facciano partire progetti ad-hoc con noi per collegare per scopi specifici il loro software con il nostro.

[MItaly]

ciao!

girovagando mi sono imbattuto in groovy.
ho letto un pò di esempi che mostrano le differenze con java, e sembrerebbe interessante.
qualcuno di voi lo hai mai usato / testato??

Mai usato, avevo letto un po' di Scala ma mi aveva lasciato perplesso su diverse cose. Magari ci do un'occhiata, sembra interessante per diversi aspetti.

[M.A.W. 1968]

quel linguaggio è derivato da apl, il quale è ancora utilizzato e le uniche implementazioni degne di nota sono commerciali e costose.

Ribadisco quanto già richiamato qui nel vecchio thread. Da noi, come in numerose altre multinazionali, J e APL vengono regolarmente usati per dimostrazioni formali e verifiche, come parte integrante delle toolchains del processo di specifica e verifica formale dei software e dei sistemi per le applicazioni più critiche (vedi punto 3).

Come ho spesso ricordato, J è in effetti uno dei miei linguaggi preferiti in assoluto, vista anche la mia formazione.

D'altro canto, contrariamente a quanto troppi sembrano ritenere, lo stesso si applica a molti altri linguaggi, in particolare ad Ada: da poco rinormato, vivo e vegeto nell'ambiente dei sistemi critici e relativa contrattistica, con decine di nuovi progetti istituzionali ogni anno e un fiorente mercato di tools, interpreti bomb-proof e RTOS con runtime Ada certificato per gli usi più critici, alcuni dei quali sono noti perfino nel mainstream.

Dato che quest'anno ricorre il bicentenario della nascita della Lovelace, mi pare doppiamente il caso di sottolinearlo, viste le troppe amenità che si leggono in giro sulla questione...

[LuciferSam86]

Altro che Java, python , Rust, ecc... questo è il linguaggio del futuro e buon

antani con scappellamento a sinistra per 2