1. 2

    Ho letto parte di “Clean Code”, molto interessante. Ora sto leggendo “Code”, bel libro, ti fa riflettere su cosa sia veramente il codice in generale, ti fa riflettere, bello.

    1. 2

      Devo recuperarli entrambi (come praticamente tutta quella lista, a dire il vero).

    1. 2

      Esperienza diretta: nel mondo delle startup è uso comune partire con un monolite per diverse ragioni:

      • è più semplice e veloce da realizzare
      • è più semplice da gestire in fase di deploy e manutenzione
      • è più semplice avere persone con esperienza su monoliti che su architetture a microservizi

      L’introduzione dei microservizi avviene solitamente in una fase successiva, una volta consolidato il prodotto, nella quale si comincia a smontare pezzo per pezzo il monolite.

      1. 1

        Esatto. Ho lavorato in una startup che sviluppa un’app per smartphone. Quando gli utenti hanno iniziato ad aumentare si è posto il problema di scalare. Hanno assunto consulenti per le varie cose (app frontend/backend/db) e questi hanno sviluppato i mocroservices state-of-the-art insieme agli sviluppatori. Non so dirti il costo complessivo, ma siamo nelle centinaia di migliaia di euro come ordine di grandezza.

        La cosa interessante è che in seguito potendo scalare con relativa facilità hanno iniziato ad offrire il loro backend come servizio per altre app simili o aziende che hanno bisogni simili.

        Inoltre se si presenta un problema puoi assumere un esperto/consulente per un servizio specifico e non serve che questo si tuffi in tutta la codebase.

        1. 1

          Curiosità: non avevate previsto una growth così elevata o non eravate in generale pronti all’inizio a scalare? Motivi di budget/dover entrare il prima possibile sul mercato o ragioni tecniche? Ho sviluppato 3 app Android come consulente esterno e sono entrato in progetti che erano tutti impreparati a scalare e alla fine i costi, secondo me, erano decisamente più alti che nel caso avessero avuto meno foga a rilasciare. Meglio per me eh :)

          1. 1

            Anche avendo il budget non ha senso investire subito tutto in una app costruendo un’infrastruttura per 1M di utenti quando poi magari non hai trazione o ci sono altri problemi o competitor migliori di te. Si parte piccoli e veloci e poi si evolve via via per minimizzare il rischio. Meglio spendere 1 milione per qualcosa che ha dimostrato di avere cash flow, piuttosto che 200k per qualcosa che non hai idea se funzionerà.

            1. 1

              ti rispondo io: come startup devi diminuire al massimo il time to market per evitare/battere competitor, quindi prima si esce con qualcosa meglio è. Le ottimizzazioni vengono solo successivamente

              1. 1

                Come startup hai ragione e lo comprendo, sopratutto quando il burn rate va a ramengo, però in un caso era una azienda medio-grande, per quello chiedevo :D

        1. 2
          • kubernetes
          • Swift
          • riprendere lo studio dell’olandese
          1. 2

            Non male. C’è un link sul filtro che usa?

            1. 4

              Non ho trovato codice, ci sono le formule nel paper, pero’ da quello che ho capito non e’ un filtro per singole immagini. E’ una correzione quantitativa dei pixel values che richiede l’estimazione dei coefficienti di attenuazione dello scattering. Per fare cio’ e’ necessario conoscere la distanza dell’oggetto dalla camera. Questa viene estimata acquisendo molte immagini a distanza diversa e intorno all’oggetto. Viene poi utilizzato un software (che immagino sfrutti tecniche per ‘photogrammetry’) per combinare le immagini e costruire un modello 3D dell’oggetto, da cui viene estimata la distanza dell’oggetto dall’obiettivo. A seguire fanno la regressione per trovare i coefficienti e con questi minimizzano gli effetti di scattering che impattano i valori dei pixel.

                1. 1

                  “Machine learning” l’hanno dovuto infilare a forza nell’abstract altrimenti non gli pubblicavano il paper.