This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2019-09-02
Channels
- # announcements (21)
- # bangalore-clj (1)
- # beginners (122)
- # calva (29)
- # cider (9)
- # cljdoc (1)
- # cljs-dev (7)
- # cljsrn (1)
- # clojure (84)
- # clojure-dev (11)
- # clojure-europe (2)
- # clojure-houston (2)
- # clojure-italy (31)
- # clojure-nl (5)
- # clojure-uk (37)
- # clojuredesign-podcast (3)
- # clojurescript (14)
- # cursive (66)
- # data-science (5)
- # datavis (1)
- # datomic (6)
- # fulcro (16)
- # graphql (4)
- # jobs (2)
- # music (1)
- # off-topic (20)
- # pedestal (1)
- # re-frame (2)
- # reagent (2)
- # shadow-cljs (155)
- # spacemacs (5)
- # tools-deps (5)
- # vim (8)
- # yada (1)
Buondì
Buon Settembre!
Una delle ragioni (quando mi chiedono) del perche’ mi piace Clojure e’ che mi spinge a leggere papers e libri grazie ai continui riferimenti in chat, articoli, mailing lists etc.
Ovviamente non e’ l’unico linguaggio con questa caratteristica :) ma e’ uno di quelli che mi da lavoro…
Mi ricordo che con Java arrivavo al massimo a citare GoF o Smalltalk. OOP taglia fuori parecchi concetti matematici (tipici del funzionale o sistemi tipati avanzati). Di conseguenza permette una larga fetta di sviluppatori di fregarsene allegramente di tutto cio’ che e’ avvenuto prima. Ovvero si stanno a reinventare la ruota sgonfia (questa e’ di Alan Kay).
hehe si siamo in tanti ma loro piu' il triplo almeno
Anche noi abbiamo circa un servizio per engineer, penso sia il rapporto ideale (assumendo che si lavora almeno in due su ogni servizio)
mah alla fine questi servizi comunicano tra di loro e difficilmente fai una qualsiasi feature senza andare a usarne piu' di uno
noi abbiamo un rapporto decisamente piu' basso, e gia' sembrano troppi
Si certo, la tentazione di rifattorizzare tutto in un monolite ogni tanto viene anche a me 😄
Pensavo che la grandezza di un microservice dovrebbe essere direttamente proporzionale alla facilita’ con cui li crei e li deploy. Piu’ e’ semplice gestire l’infrastruttura (ad es. 1 config file ed 1 riga di bash) piu’ ha senso farne tanti e piccoli (30-50 LOC). E la grandezza del microservice medio e’ inversamente proporzionale all’investimento in devops.
Tipici fattori sono la necessita’ di accomodare differenti scalabilita’ delle parti del business o usare il best tool for the job (== large business)
non e' che serve un monolite, abbiamo services che fanno una cosa sola
ma che magari sono comunque 3k linee di codice
ma quindi sono uno dei pochi che se ne e’ sempre fregato di crearsi una reputazione su stackoverflow?
Hehe perché?
Anche io non ho fatto quasi niente
Un po' di risposte su Python una vita da
ci pensavo mentre leggevo una critica https://arp242.net/stackoverflow.html che parla di come stia “morendo”