OT Programmazione - rolling release

[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.

[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]

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.

[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]

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.

[LuciferSam86]

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

antani con scappellamento a sinistra per 2

[Scara95]

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

antani con scappellamento a sinistra per 2

Se n'era parlato tempo fa.

[MItaly]

ci avevo anche scritto il fibonacci:

blinda la supercazzola Necchi fibonacci con l'Alfio Necchi o scherziamo?
    voglio il barilotto, Necchi
    che cos'è l'Alfio?
        minore o uguale di 0:
            avvertite don ulrico
        o magari minore di 3:
            barilotto come se fosse 1
        o tarapia tapioco:
            barilotto come se fosse brematurata la supercazzola fibonacci con l'Alfio meno 2 o scherziamo? più brematurata la supercazzola fibonacci con l'Alfio meno 1 o scherziamo?
    e velocità di esecuzione
    vaffanzum il barilotto!

Lei ha clacsonato
    voglio antani, Necchi come se fosse 12
    voglio il vicesindaco, Necchi come se fosse brematurata la supercazzola fibonacci con antani o scherziamo?
    vicesindaco a posterdati
    vaffanzum 0!

[M.A.W. 1968]

Oggi è il bicentenario della nascita di Ada Lovelace, madrina dell'informatica e prima programmatrice della storia, nonostante qualche tentativo revisionistico.
Se a qualcuno interessa, ho scritto qualche riga in proposito, proponendo dei validi riferimenti biografici ma anche utili informazioni sul linguaggio Ada, la sua storia e il suo attuale utilizzo perché troppo spesso si leggono cose raccapriccianti su tale linguaggio, evidentemente sconosciuto nel mainstream e ben poco trattato anche a livello didattico.

[MItaly]

Ogni mattina int, double e size_t si svegliano, vanno a comprare il giornale e leggono le notizie della giornata. Alla fine, int e double controllano l'oroscopo; size_t invece no. Perché?

(il primo che la capisce è autorizzato a picchiarmi )