Newsgroup: it.lavoro.informatica
Titolo: [sondaggio] tipo di tastiera

una curiosità; voi che tipo di tastiera utilizzate?
 
- rigorosamente meccanica
- rigorosamente a membrana
- una vale l'altra
 
io sono per la 1.


A casa meccanica cherry brown, al  lavoro quello che passa il convento.


In azienda utilizzo solo PC Lenovo, i quali sono forniti prevalentemente 
con tastiere di tipo "slim". Una merda assoluta. Quando arrivano, 
invece, con tastiere "old-style" è una festa!
 
-- 
The three most dangerous things in the world are a programmer with a 
soldering iron, a hardware type with a program patch and a user with an 
idea.
 
“Alles hat ein Ende, nur die Wurst hat zwei”


meccanica...aggiungo anche che con il layout UK mi trovo molto meglio a programmare :)

> una curiosità; voi che tipo di tastiera utilizzate?
 
Delle tre meccanica, Cherry brown o blue oppure Outemu pink,
ma l'attuale è una Unicomp/IBM PC122 (battlecruiser) per una
sola ed unica ragione: uso Emacs, dal WM (EXWM) in giù, e
non avendo le dita di un polipo preferisco MOLTI tasti e non
son manco contento di quelli della PC122 perché purtroppo su
USB i tanti sono assai meno... Non sono manco entusiasta dei
buckling spring, talvolta "mancano una battuta", sono un po'
troppo duri e imprecisi, il "colpetto" della molla si sente
sul dito e non è piacevole... Ma i tasti ci sono e non ci sono
firmware e driver assurdi dietro...
 
Un giorno, forse, se avrò molto tempo e più frustrazione di
quella odierna, mi metterò a fare una tastiera personale, ma
come dire non è in agenda, solo wishlist di luuuuuuungo periodo.
 
A membrana posso dire che son stato anni su una SUN Type6 USB e
mi ci son trovato benissimo, ovvero è *possibile* fare delle
tastiere a membrana tutto sommato decenti, non sono di quelli
che vogliono il rumore o altro (anzi il silenziatore non mi
dispiace sugli switch già dichiarati "silent").
 
In sintesi:
 
 - numero congruo di tasti (ovvero tanti, abbiamo il numpad a dx
   4x5 righe almeno, perché non un gemello a sx?) non lavoro in
   un buco Giapponese ho lo spazio che serve almeno per una
   dannata tastiera;
 
 - se è split meglio, ma inessenziale;
 
 - se è meccanica meglio, ma inessenziale, basta che non perda
   battute, non le incroci e via dicendo, cinesata da 5 euro
   style;
 
 - che non costi il 50%+ del desktop (Maltron per dire);
 
 - che non sia piena di firmware+driver del menga;
 
 - backlit non indispensabile ma gradita, sobria e leggera,
   monocromatica (magari con colore a scelta) non stile
   albero di natale RGB, non sono un gamer;
 
 - magari con accessori (lettore di smart card, hub USB,
   opzione PS2 visto che molte mobo ancora lo hanno e
   permette molta più libertà dell'USB) tutto "pluggable"
   stile bay try dei laptop classici/PCMCIA ecc;
 
 - gradita una certa riprogrammabilità, possibilmente tutta
   on-board alla tastiera, possibilmente con un file di testo
   in una flash FAT16 on-board, accessibile con switch fisico
   per montarla (disconnessa, ro, rw), file della forma
   "tasto_NN == scancode".
 
La tastiera serve a produrre, io produco, touch e altro sono
sopratutto per consumare. Purtroppo siamo nella società dei
consumi...
 
-- 
usenet⇒nntp per trovarmi

 - rigorosamente meccanica
 
Io ho questa, con switch optomeccanici: 
 
https://www.amazon.co.uk/Razer-Huntsman-Keyboard-Opto-Mechanical-UK-Layout/dp/B07D21BX4C/ref=sr_1_2?keywords=huntsman&qid=1580896003&sr=8-2
 
 
Pero` ammetto che una delle tastieri migliori che abbia mai usato e` quella del portatile Dell Latitude 7290. 


lo darei quasi per scontato. quando scrivo codice o sono su una console 
imposto il layout en-us, mentre quando scrivo testi switch sul layout it, 
a prescindere dal layout tastiera, tanto ormai la disposizione la so a 
memoria :-)

 - rigorosamente a membrana
 
Ti dirò, il mio discrimine è legato più che altro a tre fattori: semplice, ha un feedback che mi piace e non fa troppo rumore. Il modello che uso circa 10 anni almeno è la Logitech K120. Ne ho provate altre, alla fine sono sempre tornato a casa.
 
-- 
Ciao!
Luca

 imposto il layout en-us, mentre quando scrivo testi switch sul layout it, 
 
Io mi son talmente abituato che a sto punto uso solo il layout it anche quando programmo, e ultimamente devo usare C#. Alla fine, le combinazioni di tasti ti vengono automatiche.
 
-- 
Ciao!
Luca


essendo spesso su console linux i tasti `~ non sono mappati sebbene 
fondamentali. 


Membrana, adesso una Matias RGB al posto di quella Apple estesa di serie (sono 
praticamente uguali, ma ne volevo una illuminata e col filo).
Questa: 
https://amzn.to/2Dpt5A5
 
 
Mi danno fastidio i tichettii, per cui più silenziosa è, meglio è. Non mi 
piacciono quelle coi "tasti grossi" :-D

 fondamentali.
 
Ah, ecco. Vero quel che dici. In effetti, l'altro non so, la tilda so che è ALT+126; in effetti, se dovessi usarli spesso, probabilmente prenderei addirittura una tastiera US...
 
-- 
Ciao!
Luca
 
 

Ocio, la tilde come le graffe sono alt+sequenza numerica SU WINDOWS,
su GNU/Linux la tilde è insieme al backtick, le graffe sono ai lati
delle tonde, con altge, le quadre sulle tonde con altgr nelle
tastiere italiche, quelle USA (ISO o ANSI) le han su tasti dedicati
in genere.
 
Non c'è una "versione universale" cross-OS...



a me al contrario piace avere un minimo feedback e anche per quello mi 
oriento su quelle meccaniche. trovo confortevole anche che i tasti 
abbiano un minimo di corsa.
poi per esempio il tastierino numerico non ci arrivo proprio ad usarlo 
per cui per me una estesa e' spazio sprecato. 

 Ocio, la tilde come le graffe sono alt+sequenza numerica SU WINDOWS,
 
Lo so. Ma ogni OS ha le sue sequenze di tasti. Io non uso Ubuntu da 6 anni, ma ricordo che pure Ubuntu aveva le sue sequenze. E' che non me le ricordo.
 
Peraltro, non ho mai lavorato con gli Apple; li sarà Mela+<qualchecosa>...
 
-- 
Ciao!
Luca
 

Yep, ma intendevo che le "sequenze" intese in forma numerica sono cosa
di Windows, non comune altrove.


 devo usare C#
 
Quanto mi dispiace!
 


Eddai, non è poi così orrendo! :-D
Certo, non è Python, ma le ultime versioni non sono affatto male.
 
-- 
Ciao!
Luca


Io preferisco di gran lunga C# a Python pensa te :-)
 
Ciao
   Francesco
 


Meccanica retroilluminata, al momento dopo due PESSIMI esemplari cinesi, sono migrato a Logitech G512 SE, ovviamente comprata coi miei soldini...

 Io preferisco di gran lunga C# a Python pensa te :-)
 
Pensa te come state messi.

 Io preferisco di gran lunga C# a Python pensa te :-)
 
Succedeva anche a me. Ma si può guarire. :-DDD
 
-- 
Ciao!
Luca


Lavoro abbondamente con entrambi e prerisco ambiamente l'accoppiata c# .Net Core.
 
Ciao
 
Francesco

 Certo, non è Python, ma le ultime versioni non sono affatto male.
 
Non confrontiamo merda (C#) e cioccolata (Python)!


python e' insuperabile per qualsiasi cosa che sia scriptabile, per il 
resto lascerei perdere.

 resto lascerei perdere.
 
Sintesi eccellente.
 
Ciao
   Francesco
 

 resto lascerei perdere.
 
Ti sei dimenticato il Machine Learning ed un'altra dozzina di ambiti, ma non preoccuparti, quelli che dopo 29 anni continuano a dire che Python e` un linguaggio di scripting, li perdoniamo ;)
 

 Sintesi eccellente.
 
LOL :D

 resto lascerei perdere.
 
Consideri scriptabile un web service?
 
Perché io in questo momento ho tre web services RESTful che girano. E scriverli con Python è di una velocità disarmante (il merito è dei ragazzi che sviluppano CherryPy, non mio).
 
Che poi, mi scappa una domanda - che rivolgo a te e ad Andrea, perché se  ho capito bene avete esperienza sul campo. Ve la faccio perché sono molto incuriosito dal 'grande', anche se forse non lo frequenterò mai. I miei web services, con qualche migliaio di utenti, fanno egregiamente il loro lavoro. Mi sto chiedendo: cosa succederebbe se io ampliassi la platea di utenti di due o tre ordini di grandezza?
La mia domanda: probabilmente crollerebbero miseramente: non solo per una questione di 'ferro che c'è sotto', probabilmente l'architettura dovrebbe essere ben rivista - clusters, load balancers e compagnia cantante - ma perché probabilmente lo strumento Python non sarebbe più adeguato.
 
Ecco, secondo la tua esperienza, dove ci si dovrebbe rivolgere?
 
-- 
Ciao!
Luca

    Francesco
 
Che condivido... beh, mica tanto!
 
Io ho visto creare robe decisamente ampie, in Python. E pure io ho scritto diversa robetta interessante. Certo, non ti so dire di ambiti a carico elevato (non ne ho esperienza, io sono arrivato max a un migliaio di utenti, vedi l'altra domanda) ma li ho il sospetto che pure C# e .NET potrebbero avere qualche difficoltà.
 
-- 
Ciao!
Luca

 La mia domanda: probabilmente crollerebbero miseramente
 
E perche` mai? Perche` mai Python non sarebbe piu` adeguato? Non e` questione di linguaggio di programmazione, ma di architettura del sistema e infrastruttura che lo supporti. Se hai una MSA (Microservice Architecture), costruirai i tuoi servizi in maniera granulare, li scalerai indipendentemente l'uno dall'altro (a seconda del carico: per esempio le letture potrebbero essere piu` frequenti delle scritture), probabilmente andrai di cloud-native, li dockerizzerai, e li farai maneggiare da quei gran giocatori di Tetris che sono orchestrators del calibro di Kubernetes. Certo che avrai bisogno di un cluster, ma con le cloud computing frameworks di oggi e` un gioco da ragazzi. Ovviamente, se costruisci un sistema del genere, dovrai stare a attento ad "osservare" tutto l'osservabile, tracciare, e configurare il sistema in maniera tale da gestire problemi critici (per esempio, alcuni usano almeno 3 availability zones su AWS per garantirsi high availability). Cosa fare o non fare dipende strettamente dal sistema specifico che si vuol implementare, ma il linguaggio in se` conta poco.


ma che cavolo vai dicendo? LB e compagnia cantante normalmente non dipendono dal linguaggio o piattaforma. Se aumenta il carico aggungi server dietro ad un LB e dovrebbe reggere. 
 
Piu' che altro la variabile e' stateless o meno (cioe' con o senza sessione HTTP). Quella si che puo' complicare la faccendo tra sticky session, session draining ecc...normalmente cmq i servizi REST sono stateless e quindi il LB puo' andare a battere dove gli pare.

 Piu' che altro la variabile e' stateless o meno 
 
Un servizio RESTful, per definizione, è stateless.
 
-- 
Ciao!
Luca

 E perche` mai? Perche` mai Python non sarebbe piu` adeguato? Non e` questione di linguaggio di programmazione, ma di architettura del sistema e infrastruttura che lo supporti. Se hai una MSA (Microservice Architecture), costruirai i tuoi servizi in maniera granulare, li scalerai indipendentemente l'uno dall'altro (a seconda del carico: per esempio le letture potrebbero essere piu` frequenti delle scritture), probabilmente andrai di cloud-native, li dockerizzerai, e li farai maneggiare da quei gran giocatori di Tetris che sono orchestrators del calibro di Kubernetes. Certo che avrai bisogno di un cluster, ma con le cloud computing frameworks di oggi e` un gioco da ragazzi. Ovviamente, se costruisci un sistema del genere, dovrai stare a attento ad "osservare" tutto l'osservabile, tracciare, e configurare il sistema in maniera tale da gestire problemi critici (per esempio, alcuni usano almeno 3 availability zones su AWS per garantirsi high availability). Cosa fare o non fare dipende strettamente dal sistema specifico che si vuol implementare, ma il linguaggio in se` conta poco.
 
Lo posso ridire, in modo da vedere se ho capito?
In sostanza, divide et impera: gestisci l'aumentare della complessità NON pensando agli strumenti che stai usando ma eventualmente suddividendo i compiti su più agenti specifici. In effetti, detto così, è perfino banale (questo mi spaventa, mi sa che non ho capito qualcosa... :-D )
 
--
Ciao (e grazie)!
Luca

 
 
si ma definizioni a parte, nulla ti vieta di prendere un servizio REST e passarci un cookie di sessione.

perfino banale
 
Banale il cazzo. Ti ci voglio vedere a mettere in piedi tutto quello :)

 Un servizio RESTful, per definizione, è stateless.
 
Diciamo che svilupparli stateless e` la best practice, ma tecnicamente nulla ti vieta di renderli stateful.


Banale... ok, ho usato il termine sbagliato. Se capisco bene, lo sviluppo del singolo componente, dividendo la cosa si semplifica: il motivo è che sposti la complessità alla architettura generale (e, ne convengo, il vero casino è li, e mi domando se bastano a quel punto le competenze di un povero sviluppatore di campagna ;-) ).
 
Rispondo anche all'altra cosa. Io tendo a essere abbastanza formale. REST è stateless proprio per definizione. Poi so anch'io che si può ibridare in molti modi, e in un paio di casi l'ho fatto anch'io, solo che a quel punto faccio fatica a definirlo REST puro (lo chiamiamo REST allargato?).
 
-- 
Ciao!
Luca

Il giorno venerdì 7 febbraio 2020 14:30:52 UTC+1, 4ndre4 ha scritto:

infatti, ma allora perche' lo fate? :)

 infatti, ma allora perche' lo fate? :)
 
Perche`, tu fai solo cose banali?
 

 Rispondo anche all'altra cosa. Io tendo a essere abbastanza formale. REST è stateless proprio per definizione. 
 
E` vero, e infatti non lo sto negando affatto. Ti sto dicendo che e` tecnicamente possibile renderli stateful (cosa che va evitata, ovviamente).
Con REST sei veramente stateless se adotti qualcosa come HATEOAS, cosa che il 90% dei servizi non fa, purtroppo, lasciando al client il controllo. 


ma infatti anche usare le librerie di ml vuol dire scrivere script o poco 
piu'. poi per carita' e' general purpose e volendo ci si puo' fare tutto.

 Ecco, secondo la tua esperienza, dove ci si dovrebbe rivolgere?
 
oggi come oggi? docker e kubernetes, poi scali a piacimento.

  
 
Giusto per metterci d'accordo: sto parlando dei tempi di sviluppo, non di esecuzione. Non conosco bene né Java né Javascript. In C#, che pure ha fatto dei passi in avanti giganteschi, i tempi sono un po' più lunghi.
 
-- 
Ciao!
Luca

 Giusto per metterci d'accordo: sto parlando dei tempi di sviluppo
 
I tempi di sviluppo dipendono da quanto bene conosci la tecnologia con cui sviluppi. 
Facciamo a gara, tu con Python, io con Java?


io come ho detto non conosco c# e .net core, ma in java il bootstrapping 
di un servizio web è roba veramente di minuti:
 
https://quarkus.io/
 
https://start.spring.io/
 
https://www.jhipster.tech/
 
 
poi bisogna anche metterci d'accordo su cosa si intende veramente per 
"tempi di sviluppo" ovvero dove vogliamo mettere la linea del traguardo, 
il tempo per sviluppare un crud non mi pare un test molto significativo. 

 Facciamo a gara, tu con Python, io con Java?
 
Lo sai che sarebbe davvero una cosa interessante?
Nel senso: correva l'anno 1999 quando io ho lasciato Java per altri lidi. Mi immagino che, essendo trascorse nel frattempo, in senso informatico, due ere geologiche, mi aspetto che il Java attuale sia solo un lontano parente di quello dell'epoca. Mi aspetto, insomma, almeno la stessa evoluzione che c'è stata in altri ambiti. 
 
-- 
Ciao!
Luca
 
 

On Saturday, 8 February 2020 17:39:51 UTC, 
menego...@gmail.com
  wrote:
 
[...]
Mi immagino che, essendo trascorse nel frattempo, in senso informatico, due ere geologiche, mi aspetto che il Java attuale
 
Dipende che intendi per "Java attuale". Java ha un intero ecosistema attorno. Non sono solo i linguaggi ad evolvere. Oggi Spring Boot domina e sviluppare un servizio REST e` una cosa banalissima. Non ti serve neanche aprire il browser e andare su 
start.spring.io
, ce l'hai gia` integrato in IntelliJ IDEA. Per non parlare di tutta la roba inclusa in Spring Cloud.
 
Un'ottima libro sull'argomento e` questo: 
https://books.google.co.uk/books/about/Cloud_Native_Java.html?id=fZAwDwAAQBAJ&printsec=frontcover&source=kp_read_button&redir_esc=y#v=onepage&q&f=false
 
 

 allargato?).
 
chiamalo pure pastrocchio. a parte che stateless è nella definizione 
stessa di servizio rest, ma anche nel caso del servizio potrebbero esserci 
n istanze in esecuzione e questo vuol dire che lo stato deve essere 
distribuito in modo transazionale a tutte le istanze. più è alto n e più 
questo ha un costo. in altre parole: non è scalabile.

 sviluppare
 
Mah. Non ne sarei cosi` convinto. Per me e` piu` facile progettare un sistema quando i confini tecnici corrispondo ai confini funzionali, come da domain-driven design (cerco di usare confine per "boundary" per evitare il solito scemo che se ne viene fuori con un "ma usiamo l'italiano!").
 
Per esempio, se sai che due monoliti nel tuo sistema dovranno implementare gli stessi algoritmi per il calcolo delle tasse, dovrai cominciare a chiederti come evitare ripetizioni di codice, se separare certe funzionalita` in librerie, condividerle, ecc... Se pensi, invece, ad un "Tax Service", astrarre dai dettagli diventa piu` semplice. 
 
La complessita` di un sistema a microservices, comunque, e` proprio quella: saper capire dov'e` il confine funzionale tra servizi e cosa significhi esattamente "micro" nel proprio contesto. 
 
Se poi per semplicita` di sviluppo intendiamo anche semplicita` di estensione e manutenzione, i microservizi battono i monoliti dieci a zero, ovviamente. A scapito della complessita` operazionale. Chiaro che bisogna fare service discovery, loggare, osservare, tracciare, ma i tool a supporto ci sono (service mesh, etc..).

 - rigorosamente a membrana
 
Io uso quella meccanica, di Commodore 64. Lascio ai Spectrumisti il
"divertimento" con la tastiera di gomma. :-)

 credo che tu sia fuori strada. 
 
E' molto probabile. Ma ne sono consapevole. E' per questo che vi ho invocato.
 
Anzi, approfitto per ringraziare entrambi.
 
-- 
Ciao!
Luca

 significhi esattamente "micro" nel proprio contesto.
 
la complessità viene subito dopo: una volta definito il confine 
funzionale dei servizi "taxservice" e "personservice" come la mettiamo 
quando nel primo ho bisogno dei dati dei contribuenti che sono nel 
dominio del secondo? la soluzione non è di immediata comprensione 
(volendo evitare dipendenze fra servizi) ma soprattutto vale l'obiezione 
che in un monolite i due servizi accedono alla stessa base dati quindi il 
problema non sussiste. 

 problema non sussiste.
 
In un monolite, non esistono "i due servizi".
 

 In un monolite, non esistono "i due servizi".
 
vabbeh esistono due endpoint che da fuori sono due servizi. non 
sottilizziamo...

 sottilizziamo...
 
Non sto sottolizzando, e` questione di terminologia. Puoi pensarla come vuoi ma se mi parli di aree funzionali diverse, a me viene piu` facile mapparle su due servizi separati diversi che non due layers all'interno di un monolite.
 

 "come" dipende dal problema specifico che si sta cercando di risolvere.
 
aggiungendo un chiaro elemento di complessità. è innegabile che se i due 
servizi... pardon, endopint, accedessero alla stessa base dati e fossero 
sulla stessa code base verrebbe tutto gratuito.

 
 
mi piacerebbe averne una come quella dei primi IBM AT, molto clicckosa, 
perň temo che dopo due minuti avrei tutti quanti contro per il rumore
 
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........


Esatto. Non a caso gente come Fowler (ma non solo) consiglia di partire sempre dal buon vecchio monolito e virare sui microservice solo se e quando diventa assolutamente necessario. E fracamente non si puo' nemmeno obiettare "si ma tu fai banalita'" perche' con il monolith si puo' andare parecchio lontano. 
 
E' vero che gli strumenti di monitoring, deployment, coding, ecc sono notevolmente migliorati (e forse proprio grazie all'adozione su grande scala dei microservice, che quindi per questo sono stati una gran buona cosa). Tuttavia credo questa legge rimanga vera: "First Law of Distributed Object Design: "don't distribute your objects"".
 
Che poi ci siano casi in cui sia meglio adottare un'architettura differente, questo non lo nega nessuno. La domanda vera e': quanto spesso e' realmente necessario farlo, considerando le applicazioni che normalmente si fanno? Temo 
 molto meno di quanto lo si stia facendo ora (e non sono il solo a dirlo).

 è un problema non banale la cui soluzione comunque aumenta la complessità.
 
Pensavo ti riferissi ad un altro problema. Il taxservice riceve dei dati ma poi come li legge? Cioe' ad un certo punto avra' bisogno di convertire i dati (es. json) che riceve su qualche oggetto suo. Ecco che qui devi decidere: condivido delle classi (rendendo i due servizi in parte dipendenti l'uno dall'altro) oppure lo duplico?

 sulla stessa code base verrebbe tutto gratuito.
 
Verrebbe tutto gratuito ma non sarebbe una PROGETTAZIONE piu` semplice. Il "chiaro elemento di complessita`" c'e` ma PROGETTARE a microservizi e` piu` semplice che non farlo per monoliti, se non altro perche` la separazione dei concern e` piu` chiara.
 

 Che poi ci siano casi in cui sia meglio adottare un'architettura differente, questo non lo nega nessuno. La domanda vera e': quanto spesso e' realmente necessario farlo, considerando le applicazioni che normalmente si fanno?
 
Che cosa significa "normalmente"? Quel che e` normale per te, potrebbe non esserlo per me. La direzione che sta prendendo lo sviluppo del software su larga scala oggi e` quella che ho descritto nel primo paragrafo. Se tu resti indietro, o se, semplicemente, nel tuo caso tutto quello non fa testo, non te ne uscire con un "eh, ma a chi serve fare roba cosi` complessa??". Non servira` a te. Ad altri si`.

 Pensavo ti riferissi ad un altro problema. Il taxservice riceve dei dati ma poi come li legge? Cioe' ad un certo punto avra' bisogno di convertire i dati (es. json) che riceve su qualche oggetto suo. Ecco che qui devi decidere: condivido delle classi (rendendo i due servizi in parte dipendenti l'uno dall'altro) oppure lo duplico?
 
Non condividi proprio niente. I due servizi hanno life cycles differenti.
 


e infatti e' la best practice, che cmq porta ad avere duplicazione almeno sui DTO.
 
Questo problema non esiste con un monolith.

 separazione dei concern e` piu` chiara.
 
davvero mi spiace ma non ti seguo. con cognizione di causa ripeto 
progettare a microservizi è decisamente piu' complesso e la rete è piena 
di articoli che mettono in guardia sulle difficoltà sia di progettazione 
che realizzazione, e relative derive. se con una architettura monolitica 
si rischia la cosiddetta "big ball of mud" una architettura a microservizi 
la deriva piu' comune è quella di un distributed monolith ovvero un "huge 
ball of mud". 

 progettare a microservizi è decisamente piu' complesso
 
La rete e` piena di articoli che dicono tutto e il contrario di tutto. Oltretutto gli articoli sono sempre contingenti al tempo in cui appaiono. La verita` e` che la direzione dello sviluppo software, oggi, almeno in certe organizzazioni "grandi", e` verso architetture a microservizi. E` un fatto. Il motivo e` anche perche`, a livello infrastrutturale, farlo e` molto piu` semplice che in passato.

 Questo problema non esiste con un monolith.
 
I problemi esistono se li consideri tali. Senno` non esistono.
 

 Che cosa significa "normalmente"? Quel che e` normale per te, potrebbe non esserlo per me. La direzione che sta prendendo lo sviluppo del software su larga scala oggi e` quella che ho descritto nel primo paragrafo. Se tu resti indietro, o se, semplicemente, nel tuo caso tutto quello non fa testo, non te ne uscire con un "eh, ma a chi serve fare roba cosi` complessa??". Non servira` a te. Ad altri si`.
 
Eh, su larga scala. Hai numeri per dire che la stragrande maggioranza dei progetti ha milioni di utenti, un codebase su cui mettono le mani centinaia di persone, e la necessita' del business di andare live piu' volte al giorno?  Perche' la mia esperienza dice di no.
 
Poi se lo discono anche altri, che per lavoro hanno a che fare con moltissimi clienti direi che e' difficile credere il contrario:
 
https://changelog.com/posts/monoliths-are-the-future
 


Insisto, se modifichi il modo in cui viene spedito un dato (ad esempio lo sposti da un servizio all'altro) e questo dato viene letto da decine di servizi *potresti* dover mettre mano e rilasciare in contemporanea decine di servizi. Oppure consentire piu' versioni allo stesso tempo.
 
Con il monolito, cambi la dichiarazione, ricompili, testi e rilasci.

 
 
lol ho riletto meglio, non lo dice lui ma "many of my colleagues" :)
 
Rimane il fatto che in molti (maggioranza dei suoi contatti addirittura) consigliano di iniziare con il monolito, e lui stesso non ha ancora un'idea precisa.
 
Sinceramente seguendolo su twitter mi ero fatto l'impressione che caldeggiasse al 100% proprio questa idea, ma potrei essermi sbagliato.

 Insisto, se modifichi il modo in cui viene spedito un dato (ad esempio lo sposti da un servizio all'altro) e questo dato viene letto da decine di servizi
 
Hai chiaramente un problema di design del tuo sistema. Non e` che con un monolite risolvi i problemi di design eh? Hai un chiaro falso senso di sicurezza.


https://changelog.com/posts/monoliths-are-the-future
 
 
LOL :) Capisco che la tentazione di trollare, a questo punto, e` forte :)

 Rimane il fatto che in molti (maggioranza dei suoi contatti addirittura) 
 
E il fatto che aggiunga "it is by no means unanimous." e che linki a questo: 
https://martinfowler.com/articles/dont-start-monolith.html
 ovviamente lo ignori... come ignori che scriva "Although the evidence is sparse, I feel that you shouldn't start with microservices unless you have reasonable experience of building a microservices system in the team."
 
Confirmation bias? :)

 LOL :) Capisco che la tentazione di trollare, a questo punto, e` forte :)
 
Allora continuo :) 
 
Guarda, in realta' e' chiaro che non c'e' un precetto, e ognuno dice la sua, anche perche' tutto dipende dal contesto ovviamente. Questo implica che non si puo' dire monolith first sempre, e neppure msa first come fai tu. Voglio dire nessuna di queste due posizione e' consolidata.
 
Questo e' un articolo segnalato dal Fowler stesso, quindi immagino si trovi d'accordo: 
https://martinfowler.com/articles/dont-start-monolith.html
 
 
Il titolo sembra darti ragione in pieno, pero' se leggi prima di tutto e' evidente che per Sam Newman va benissimo partire dal monolith. Anzi, 
"I remain convinced that it is much easier to partition an existing, "brownfield" system than to do so up front with a new, greenfield system." 
 
E su questo infatti l'autore dell'articolo *non* e' d'accordo. 
 
Secondo ripete la leggina di Fowler, che tu proprio non vuoi passare, ma che lui fa intendere si applica anche ai MSA: 
 
"you shouldn’t introduce the complexity of additional distribution into your system if you don’t have a very good reason for doing so."
 
e qui si parla di microservice, non di altro. Poi continua dicendo che il monolith e' cmq difficile da gestire e far evolvere in maniera pulita. E infatti lui ha decisamente un bias verso MSA first.
 
Terzo linka un articolo di Fowler con il seguente testo:
 
"So my primary guideline would be don't even consider microservices unless you have a system that's too complex to manage as a monolith."
 
E ancora:
 
"The complexity that drives us to microservices can come from many sources including dealing with large teams [2], multi-tenancy, supporting many user interaction models, allowing different business functions to evolve independently, and scaling. But the biggest factor is that of sheer size - people finding they have a monolith that's too big to modify and deploy."
 
Quindi, e' come dicevo: se non hai una situazione del genere, probabilmente e' meglio se non parti MSA. 
 
Insomma, la situazione non e' affatto ovvia e la tua posizione e' una posizione personale.

Consentitemi un OT, "visto da fuori" (admin): non ho mai visto in anni
software "gestionale"/"commerciale" che non sia puro ammasso di
spazzatura. Alcuni (pochi) cominciano bene ma poi passano di mano,
evolvono di corsa, aggiungono pezze e tacconi e diventano mostri,
altri partono già male.
 
Il punto è che oggi si richiedono tempi e persone inadeguati alle
tecnologie presenti. Se avessimo portato avanti Plan 9, forse, si
potrebbe andare a certe velocità e con certi team di sviluppo,
altrimenti è mera follia. Non diversa da quella che si vedeva
nell'edilizia degli anni '60, nell'automotive odierno e in un mare
di altri settori.
 
Questo per dire che NON IMPORTA come si sviluppa. Si vuole cose che
non si dovrebbero fare, in tempi troppo stretti, con uno sviluppo
troppo sballato. Qualsiasi artificio si introduca per riuscire a
"farlo" poco importa, funzionerà bene o meno, ma non può compensare
il vizio di fondo.
 
Anche il linguaggio che discutevate prima importa poco: non è colpa
di Java se il suo utilizzatore medio ciuccia il mondo dal nexus e
crea mostri ingestibili, non è merito di Python se il liceale medio
riesce a scriverci una webapp che sta in piedi e dopo un po' diventa
Youtube. Il linguaggio fa la sua parte, ma il problema sta in chi lo
usa o in chi glielo fa usare a un certo modo.
 
-- 
usenet⇒nntp per trovarmi

 posizione personale.
 
è partito tutto da una affermazione banale, cioè che realizzare una 
architettura a microservizi comporta un grado di complessità superiore 
rispetto ad un monolite, che per confutarla è partita una serie 
inspiegabile di arrampicature sugli specchi. inspiegabile perché non nega 
che una msa sia più manutenibile, più elegante, più scalabile, più quello 
che ti pare. solo più complessa. e più complessa all'atto pratico vuol 
dire che non può essere adatta per tutte le stagioni, perché se gli 
svantaggi introdotti dalla maggiore complessità superano i vantaggi da 
che mondo è mondo la soluzione si scarta. è stupido scartare a priori una 
soluzione perché più complessa ma è altrettanto stupido scartare a priori 
l'alternativa quando non ci sono i presupposti per farlo. non 
necessariamente un monolite diventa un "big ball of mud" come non 
necessariamente una suddivisione granulare porta effettivi vantaggi. la 
ddd la si può applicare anche in un software monolitico, per dire.
 

 CherryPy
 
Posso chiederti perchè proprio CherryPy e non roba più moderna tipo Flask?

 Posso chiederti perchè proprio CherryPy e non roba più moderna tipo Flask?
 
Perché conosco bene CherryPy, perché dovevo andare in produzione in fretta.
Che poi... più moderno. E' un progetto che inizia qualche anno più tardi, vero, ma CherryPy è evoluto: l'ultima release è di novembre dello scorso anno. Comunque sto dando un occhio anche a Flask, ma è ancora in fase di studio.
 
-- 
Ciao!
Luca

 Che poi... più moderno. E' un progetto che inizia qualche anno più tardi, vero, ma CherryPy è evoluto: l'ultima release è di novembre dello scorso anno. Comunque sto dando un occhio anche a Flask, ma è ancora in fase di studio.
 
Come server WSGI che cosa usi per servire le applicazioni CherryPy? Tornado?

 Come server WSGI che cosa usi per servire le applicazioni CherryPy? Tornado?
 
Uso quello integrato in CherryPy. Finora non ho avuto bisogno di altro.
 
-- 
Ciao!
Luca
 
 

 crea mostri ingestibili
 
LOL :)

 che mondo è mondo la soluzione si scarta. 
 
Che non e` il caso delle MSA.

 Insomma, la situazione non e' affatto ovvia e la tua posizione e' una posizione personale.
 
La situazione ovvia e` che sei un troll e che ti piace trollare.

 che una MSA sia operativamente piu` complessa da gestire di un monolite,
 
e allora perché t'infervori? stai tranquillo e vedrai che nessuno si farà 
male.

 
 
La mitica Model M viene ancora prodotta dalla Unicomp.
 
 
-- 
Sardonico

 parte dipendenti l'uno dall'altro) oppure lo duplico?
 
in generale stabilisci un "contratto" che il producer deve rispettare, che 
non necessariamente è un duplicato esatto. un consumer può mappare solo i 
campi che gli interessano ignorando il resto. 
è comunque un altro motivo per evitare di chiamare direttamente un 
servizio da un altro servizio: in questo modo infatti se devi cambiare 
una api per esigenze applicative non lo puoi fare a meno di avere un 
impatto su tutto il resto. in genere le comunicazioni fra microservizi 
avvengono con protocolli diversi e dedicati allo scopo. un problema di 
questo tipo io lo risolvo con il taxservice che ha nel suo db una replica 
dell'anagrafica contribuenti e il personservice che distribuisce i dati 
tramite una coda kafka, senza conoscere chi sono e quanti sono i 
destinatari (chiunque sottoscrive la coda). anche qui c'è il problema del 
dto "duplicato" ma è già più gestibile perché si tratta di un protocollo 
dedicato alla sincronizzazione.
 
 

 
 
bello, ma vogliono $bigsum$, temo che la famiglia non approverebbe la spesa
 
-- 
/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\
-=- -=- -=- -=- -=- -=- -=- -=- - -=-
........... [ al lavoro ] ...........

 spesa
 
mi pare venga sui 100$, no? 

Hum, ho recentemente comprato una PC122 e se vedo quanto costano le
meccaniche classiche, comprensive di firmware spazzatura imbullonati
e saldati nel ferro... Non mi pare costino care...
 
Se poi mi dici che potrebbero costare meno, beh, questo è un altro
discorso, ma sono, purtroppo di nicchia, oggi i più sono dei
consumatori di contenuti la cui tastiera potrebbe pure essere un
tastierino da gaming, quindi chi vuole una tastiera degna di questo
nome, ancorché di qualità non proprio eccelsa ne proprio eccelse
finiture e scelte tecniche... Beh si paga.
 
Le Unicomp van insieme alla Typematrix e molte altre "tastiere da
lavoro", costano si il doppio di una vecchia SUN type 6, ma la SUN
purtroppo è morta e come qualità della tastiera non era migliore...
Considera poi che potenzialmente ti dura una vita, non si sono fw o
altro, solo meccanismi elettromeccanici i cui ricambi si trovano da
decenni e immagino si troveranno ancora per parecchio tempo a venire.
 
Aggiungici che grazie alla disposizione "parabolica" dei tasti puoi
spostare i keycaps su *ogni* posizione della tastiera essendo tutti
alti uguali, non stile profilo Cherry, beh, 'somma ti puoi fare una
dvorak o colemak al volo, il resto puoi farlo via software se vuoi
cose più complicate...


 diversa robetta interessante. Certo, non ti so dire di ambiti a carico elevato 
 
Chiedere ad Alex Martelli come mai Google lo tiene "sequestrato" da 15 anni:
http://www.aleax.it/curric_it.txt
 
 
-- 
Sans