Newsgroup: it.lavoro.informatica
Titolo: il codice sorgente dell'app immuni

qui

https://www.corriere.it/tecnologia/20_maggio_25/immuni-pubblicato-codice-sorgente-dell-app-l-icona-ufficiale-001e69fe-9e8f-11ea-aa6b-a30e3049a61e.shtml




e qui:

https://www.repubblica.it/tecnologia/mobile/2020/05/25/news/curonavirus_l_app_immuni_arriva_il_10-15_giorni_pubblicato_il_codice_sorgente-257556465/






sembrano dire che è pubblicato il codice sorgente dell'app.



Io però ai link riportati qui:



https://innovazione.gov.it/source-code-immuni/




per ora grande codice non ne vedo.



Magari qualcuno di voi lo trova.



Ciao,

Marco.



-- 

Questa e-mail è stata controllata per individuare virus con Avast antivirus.

https://www.avast.com/antivirus





Marco. Ma sei sicuro di averci raccontato la verità sul tuo passato da informatico? No perchè il dubbio viene



https://github.com/immuni-app/immuni-app-android/tree/master/app/src



 Magari qualcuno di voi lo trova.



https://github.com/immuni-app



 
https://github.com/immuni-app




Madonnah che cazzimma che hai.


 Marco.





Bisogna compilarselo altrimenti chi lo dice che il binario nello

store e' quello ottenuto dai sorgenti pubblicati?

Ma li hanno pubblicati?



Vabbè chi se ne futte.



un friggo mica con l'acqua, eh.


 per ora grande codice non ne vedo.



su quel link ci ho cliccato ora, possibile che tu non l'abbia visto? sui 

progetti github almeno il minimo sindacale ci sai navigare?






 progetti github almeno il minimo sindacale ci sai navigare?



Mettiamola così: se non avessi scrollato la pagina principale del progetto, i link alle singole versioni non l'avrei visto. A mia parziale scusante, è sera...



Che poi, leggo bene o la versione android è in Kotlin?



-- 

Ciao!

Luca


 Che poi, leggo bene o la versione android è in Kotlin?



kotlin è lo standard dello sviluppo android.



Direi di no.

Ho smesso di fare l'informatico nel 2012 ma, come

ho scritto altre volte, già allora non mettevo

più le mani sul codice da anni. L'ultima volta

che professionalmente ho messo le mani sul codice era il 2005

o 2006.

Credo che  all'epoca github proprio non esistesse e le occasioni

in cui sono andato su github, magari per scaricare qualcosa

per uso personale credo si contino sulle dita delle mani, anzi più 

probabilmente su quelle di una mano sola.

Mi pare relativamente normale essere al di sotto del minimo sindacale.



 Mi pare relativamente normale essere al di sotto del minimo sindacale.



sarebbe normale se non avessi aperto questo thread.

anche la mi mamma è sotto il minimo sindacale di competenze di 

programmazione, ma non va nemmeno a cercare i sorgenti dell'app immuni. 

al massimo le ricette di cucina (e le trova, fra l'altro).



Minchia che casalinghe frustrate tra te e quell'altro, cpascoshi.



cpascoshi: "Marco. Ma sei sicuro di averci raccontato la verità sul tuo

passato da informatico? No perchè il dubbio viene"



Il link era visibilissimo, ok, ma rispondere con un po'

di simpatia? Esempio:



"Il link che cerchi e' infondo alla pagina orbo! :-D"



Uno puo' avere una svista, o no?



Invece no, perche' non ha visto un link si mette in dubbio

il suo passato da informatico, si mette in dubbio che non

sia in grado di fare "il minimo sindacale"



MA VOI SIETE MALATI!!!

CIOCCATE COME DELLE LAME VUOTE!!!



A che razza di frustrazioni siete sottoposti?



Marcoxxx : e tu ti vai anche a giustificare??

Ma mandali affanculo 'sti squilibrati!!!




 Ho smesso di fare l'informatico nel 2012



Ma va? Non lo sapevo.


 Madonnah che cazzimma che hai.



Mi piace moltissimo questo metodo:



     override fun areContentsTheSame(oldPosition: Int, newPosition: 

Int): Boolean {

         return false

     }



https://github.com/immuni-app/immuni-app-android/blob/master/app/src/main/java/it/ministerodellasalute/immuni/ui/home/HomeDiffCallback.kt











 per ora grande codice non ne vedo.



1) Leggere l'articolo.



2) Cliccare sui link qui: "Su GitHub si trova il codice sorgente 

dell’app per Android e per iOS"



3) Accedere quindi alla pagina: 

https://github.com/immuni-app/immuni-app-android




Hai fatto bene a smettere di fare l'informatico.




 Hai fatto bene a smettere di fare l'informatico.



E ti pareva...ci mancavi giusto tu all'appello di cui sopra:

l'analfabeta tuttologo.

Ahh scemooooooooo! :-D




On 26/05/2020 09:05, 4ndre4 wrote:

 > Hai fatto bene a smettere di fare l'informatico.





 Minchia che casalinghe frustrate tra te e quell'altro, cpascoshi.



oh, fermi tutti è arrivato quello simpatico! al mio via fategli 

l'applauso! :-D



(non rompere il cazzo eh, ci ho messo la faccina)


 l'applauso! :-D



Gia` buttato da tempo nel killfile.



In questo caso, come ho gia' scritto altre volte e ribadisco anche in 

questo caso, devo essere d'accordo con lui. E' assolutamente

vero che ho fatto bene a smettere di fare l'informatico.



 vero che ho fatto bene a smettere di fare l'informatico.



Gia`, ma molto probabilmente non per i motivi che pensi tu.







R-O-T-F-L



Ciao,

Marco



PS:



hint:

Questo e' un newsgroup frequentato da ....

  (indicare la caratteristica che accomuna chi frequenta il ng)



io ho postato il link per .....

(indicare i motivi per cui uno posta qualcosa su questo ng)



 (indicare i motivi per cui uno posta qualcosa su questo ng)



"...che` non sapevi trovarlo da solo".






 (indicare i motivi per cui uno posta qualcosa su questo ng)



scusa, ma gli hint sono per te o per me?


 vero che ho fatto bene a smettere di fare l'informatico.





L'importante e' stare meglio. Non so se sia l'informatica

ma qui gente che non sta bene non manca.


 Ho smesso di fare l'informatico nel 2012 



e ce lo dici sono ora?



è dal 2005 che lo dice.


 Mi piace moltissimo



vedendolo ho avuto quella sensazione di non so che, di framewoek, di stile programmatorio alla robert martin...



https://developer.android.com/reference/androidx/recyclerview/widget/DiffUtil.ItemCallback#areContentsTheSame(T,%20T)



 L'importante e' stare meglio. 



oh ma pure non cacare il cazzo guarda che ha la sua funzione, eh.



Se ti può consolare il mio ultimo anno da informatico

(e in particolare gli ultimi  mesi) sono stati ben

peggiori rispetto qui.



Ciao,

Marco



 peggiori rispetto qui.



Come ultimo anno da informatico? Ma perche`, non fai piu` l'informatico?





DA ALLORA FA LO STRIPMAN AGLI ADDII AL NUBILATO



Non ho ne' l'età ne' il fisico per farlo,

ma sarebbe sicuramente molto più divertente

che fare l'informatico.



 che fare l'informatico.



Molto piu` divertente *per te*.





Quanto devi essere frustrato e scemo per scrivere queste risposte...



Adesso hai capito il perché delle 3 "x" (mica una!) nel suo Nick ... ;)



M.


 



quindi sei pure ginofobico, oltre che idiota!






 



e che stile di programmazione ha Robert Martin?


 e che stile di programmazione ha Robert Martin?



terribile. dopo aver letto quelle robe tipo il sieve in agileblablabla o clean code, non ricordo, guardai fitnesse. 



i suoi show invece sono divertenti. e ripetitivi.


 terribile



guarda. aperto al volo dopo anni il suo blog:



"

Why did I need the design change? Because I was not mocking and creating fake data. My functions just read from the repo files directly. There was no way to pass them fake data. The design change I needed to make was precisely the same as the design change that I’d have needed for mocking and fake data.

"



https://blog.cleancoder.com/uncle-bob/2020/05/27/ReplDrivenDesign.html




ovvero secondo lui il fatto che ha appena mancato di separation of concerns (acquisire dati vs processare dati), mischiato I/O side-effects con pure data transformation, è da imputare a quanto dice...



a me sembrano i ramblings forzati di una specie di wannabe che vuole vendermi per forza qualcosa (oggi tdd, ieri erano uml/c++ strettamente "oop"/blablabla).


 ovvero secondo lui il fatto che ha appena mancato di separation of concerns (acquisire dati vs processare dati)



Hummm... non credo sia cio` a cui si riferisca. Dice che le sue funzioni 

leggevano direttamente i dati dell repo e non c'era modo di "mockare" 

dei dati fittizi per testare edge conditions (che probabilmente si sono 

presentati nei dati dei giorni seguenti). Io sono d'accordo con lui che 

TDD avrebbe probabilmente evitato il problema.


Condivido tutto quello che ha scritto in quel post. Che tra l'altro mi sembra abbastanza ovvio (hai ragione che si ripete). 

Ma non ho capito cosa gli contesti.


 Ma non ho capito cosa gli contesti. 



gli contesto il suo eterno dogmatismo, che qui si manifesta nel non saper usare il Read-Eval-Print Loop e nel non saper disegnare una function che trasforma dei dati. oltretutto non conosco cosa s'intenda per "REPL Driven Design" nella community di clojure ma sono pronto a scommettere che non è quanto da lui capito e riportato, soprattutto sulla sua (voluta e evidente) omissione del testing per tirare acqua al suo businness di scrittore/consulente esperto di tdd.



in ogni caso parliamo di uno che pubblica libri con detro: 



https://github.com/ludwiggj/CleanCode/tree/master/src/clean/code/chapter04





 Hummm... non credo sia cio` a cui si riferisca. 



io penso di si, visto che REPL e "design in the small" (ovvero concernente il livello delle functions) predatano di molto il tdd, e non mi spiego come un esperto come lui abbia potuto disegnare una function che non gli permetta di passare gli input voluti per testarne il funzionamento. 



"My functions just read from the repo files directly." è inequivocabile: nella REPL, ha iniziato a scrivere una function che legge i dati della pull e, complice l'immediatezza dell'ambiente e di clojure/lisp, ha iniziato a processarli/trasformarli contestualmente.



se uno segue quanto dice, si deduce che se gli levi il tdd non sa più scrivere software. da cui segue: chissà _come_ scriveva software prima della pubblicazione del libro di Beck? beh, domanda retorica - vendeva libri su UML: da un estremo all'altro delle classifiche di vendita.


 se uno segue quanto dice, si deduce che se gli levi il tdd non sa più scrivere software



No, credo che il significato sia un altro: se gli levi TDD, gli levi uno 

strumento utile ad evitare facili bug, cosa che un approccio basato su 

REPL evidentemente non gli ha consentito. Lui era partito con TDD, poi 

passando a REPL Driven Design era comunque riuscito ad implementare quel 

che gli serviva, ma si e` poi reso conto che non aveva quel safety net 

che TDD ti consente di avere, nel momento in cui vuoi fare un 

refactoring del software. Penso abbia ragione.




 quel safety net che TDD ti consente di avere



ma la safety net è propria dei tests e del testing, e non prerogativa esclusiva di tdd o altra metodologia simile. nessuno gli ha vietato di fare design come si deve. il suo solito concludere "tdd > rdd/whateva" s'è fatto stantio.



Kent Beck al posto suo avrebbe semplicemente scritto "ho sbagliato design!" e senza tante manfrine e guerre di sigle.


 altro: se gli levi TDD, gli levi uno 

strumento



e se invece il significato fosse che tutto questo concentrarsi sul tdd lo ha fatto regredire in quanto a capacità di design? casi artificiali e volutamente forzati come questo e i tdd kata, i sudoku di Jeffries etc. confermano l'opposto di quello che pensano questi autori. tdd sta per "test-driven development", giusto? non avere un design per la function critica del tuo programmino, non è questione di tdd o rdd. è semplicemente mancanza di design, andiamo.


 community di clojure



in 2 minuti: nel post precedente a quello, cita tale Stuart Holloway di Clojure. Holloway e RDD mi danno al volo





https://vimeo.com/223309989




"

And there are several advantages to this. One of them is: you have this immediate interaction. REPL development is faster than test driven development. Full stop. It is. It just is. If you like test driven development because of the rapid feedback loop, REPL driven development is a faster feedback loop, because you do not have to write the test part. You can try things out.



Now this does not mean you should stop doing TDD, or stop writing tests, because tests have other advantages. Tests can be run again later. So there are reasons to do it. But if you are just talking about the feedback loop, you can really not beat the REPL.

"



non avevo dubbi.


 ma la safety net è propria dei tests e del testing, e non prerogativa esclusiva di tdd o altra metodologia simile



Ma certo, ci sono milioni di modi diversi di fare le stesse cose. Quel 

che lui sta dicendo e` che interrompendo l'uso di TDD, nel suo caso, 

passando a REPL Driven Design, ha perso i vantaggi di TDD. Poi e` chiaro 

che avrebbe potuto scrivere i test comunque ma io, per esempio, la 

differenza nella qualita` dei test tra chi scrive TDD e non-TDD la vedo.


 e se invece il significato fosse che tutto questo concentrarsi sul tdd lo ha fatto regredire in quanto a capacità di design?



Non credo proprio. TDD a mio parere, e sulla base della mia esperienza, 

e` un ottimo modo di progettare il software. Molti chiamano TDD 

Test-Driven-Design piu` che Test-Driven-Development:



"To my mind, TDD (and its more-refined cousins BDD and ATDD) are not 

testing methodologies at all. They're design methodologies. In fact, 

let's just call it Test-Driven Design to eliminate the confusion."

https://www.drdobbs.com/architecture-and-design/test-driven-design/240168102




Ed e` vero, perche` io vedo come il codice sviluppato con TDD e` 

qualitativamente migliore delle sue alternative.


you like test driven development because of the rapid feedback loop, REPL driven development is a faster feedback loop, because you do not have to write the test part.



Eh, ma come loro dicono, solo se tutto cio` che ti interessa e` il 

"feedback loop". Quel che interessa maggiormente quando si applica TDD, 

pero`, non e` soltanto il feedback loop, ma la qualita` del codice 

prodotto e dei test.



Da quel che so lui e' abbastanza nuovo al mondo Clojure e functional programming. Chiaro che quando sei fuori dal tuo brodo tendi ad andare in confusione e a lasciarti prendere la mano.



In ogni caso lui ha solo fatto notare che in retrospettiva avesse continuato con il TDD quell'errore non l'avrebbe fatto. Neppure in un contesto a lui non familiare come questo.


 Da quel che so lui e' abbastanza nuovo al mondo Clojure e functional programming



Io ho visto usare REPL Driven Design in un meet up. Effettivamente e` un 

bel modo di lavorare, ma i test risultanti in Clojure mi sembravano 

molto ostici.


 



Ma vi leggete?

Non ci vuole tanto ad essere meglio di voi.

Perchè qui non si tratta di "simpatia", che propriamente

citata e un passo avanti, ma di semplice saper interloquire

senza buttarla subito in rissa. Frustrati!


 Frustrati! 



"Si frusti Lei, pervertito!" cit.



forse perche' erano costruiti bottom-up? Usando la repl mi sa che viene naturale quello stile.


 forse perche' erano costruiti bottom-up? Usando la repl mi sa che viene naturale quello stile.



Non ricordo i dettagli al momento (e` stato un bel po' di tempo fa). So 

solo che avevo chiesto al tale se fosse possibile vedere codice un po' 

piu` realistico dell'esempio giocattolo mostrato, perche` gia` quello a 

me sembrava abbastanza ostico da comprendere. Mi sarebbe piaciuto vedere 

qualcosa di piu` vicino al codice di produzione. Era un meet-up pero` 

quindi la cosa e` finita li`. Forse pero` l'osticita` era piu` dovuta a 

Clojure che a REPL di per se`. E` che i test mi sembravano molto 

difficili da interpretare e, dal mio punto di vista, se il codice di 

test e` difficilmente leggibile, c'e` qualcosa di fondamentalmente 

sbagliato. O si sta testando troppo o lo si sta testando male.




 a Clojure che a REPL di per se`.



oppure all'ambiente image-based dinamico, che è l'opposto di quello classico in C/Java. registrare e organizzare i tests creati mentre programmi "live" un sistema lisp può variare da sistema a sistema e da persona a persona. dipende da chi hai incontrato






 naturale quello stile. 



anche la loro organizzazione - magari il tipo aveva un suo package per registrare e condurre i tests o usava quello di Clojure che non conosco, invece del classico sistema tipo Junit intendo.

in un sistema "live" lisp cambiano molte cose. 


 registrare e organizzare i tests creati mentre programmi "live" un sistema lisp 





Bello! C'e` un sistema del genere oggi? Hai link?


 Bello! C'e` un sistema del genere oggi? Hai link? 



qui c'è uno minimale da cui partire

https://github.com/cognitect-labs/transcriptor/blob/master/README.md


https://oli.me.uk/an-introduction-to-transcriptor/




e guardarsi bene tutti i punti di aggancio che il linguaggio offre, ad es. nel caso di Martin che non sapeva come fare mock a posteriori poteva tornare utile la macro with-redefs.



"REPL-oriented programming"

https://books.google.it/books?id=nZTvSa4KqfQC&pg=PA393&lpg=PA393&dq=repl-oriented+programming&source=bl&ots=0X4kAP5Kuj&sig=ACfU3U1wYJIq5Hz991r4UpfQEzwaP_zYqg&hl=it&sa=X&ved=2ahUKEwjSxPCytOjpAhUpmIsKHQ6EDB0Q6AEwDnoECAMQAQ#v=onepage&q=repl-oriented%20programming&f=false






Grazie!


 Grazie! 



mah insomma poca roba, l'ecosistema clojure è ricchissimo ma non lo conosco. avevo avuto un'offerta di lavoro per impararlo al volo su data analysis e mi pento di non aver accettato.


 la differenza nella qualita` dei test tra chi scrive TDD e non-TDD la 

vedo



L' utenza potenziale si caratterizza per la ricognizione del bisogno 

emergente e della domanda non soddisfatta senza precostituzione delle 

risposte non assumendo mai come implicito nei tempi brevi, anzi brevissimi 

la trasparenza di ogni atto decisionale.



Inoltre, la valenza epidemiologica riconduce a sintesi la puntuale 

corrispondenza tra obbiettivi e risorse attraverso i meccanismi della 

partecipazione sostanziando e vitalizzando in un ottica preventiva e non 

più curativa la ridefinizione di una nuova figura professionale.





n.b. 
http://www.sandrodiremigio.com/giochi/generatore_frasi_senza_senso.htm




-- 

/-\ /\/\ /\/\ /-\ /\/\ /\/\ /-\ T /-\

-=- -=- -=- -=- -=- -=- -=- -=- - -=-

........... [ al lavoro ] ...........


 n.b. 
http://www.sandrodiremigio.com/giochi/generatore_frasi_senza_senso.htm




Tranquillo, il tuo e` il livello di coglionaggine che mi aspetto dal troll incompetente medio di ili. Il fatto che tu non riesca a comprendere quel che ho scritto, e cioe` che il software che venga fuori dall'applicazione di TDD abbia, a mio parere, una migliore modularita` e test piu` chiari e informativi di uno in cui TDD non venga applicato, non mi meraviglia. D'altronde, il tuo contributo qui dentro non va molto oltre al contare quanti messaggi ognuno scriva.


 



come si fa a sapere che quello è veramente il sorgente completo? se ad 

es. hanno messo una funzione segreta nell'eseguibile, ma non l'hanno 

messa nel sorgente!



grazie


 messa nel sorgente! 



adesso passa qualche genio e ti chiede se sei ingeniere laurato. con lode eh


 messa nel sorgente!



EEEH????



Scusa, ma se hai il sorgente,non puoi crearti tu l'APK (o quel che l'è per iOS) una volta verificato e vivere tranquillo?



-- 

Ciao!

Luca



Credo si riferisse alla versione negli store per tutti,

non se non ci sia una soluzione per specialisti del settore.






 non se non ci sia una soluzione per specialisti del settore.



Io ragiono al contrario. Non ti fidi? C'è in GitHub il codice sorgente: te lo scarichi e te lo compili. Non sei capace? ti associ con un gruppo di altre persone e lo fai fare - pagando - a un esperto di tua fiducia.



Nota che sto parlando di come funziona l'open source, non Immuni in particolare...



-- 

Ciao!

Luca





Non mi pare che il tuo ragionamento sia un contrario del mio.

Si, funziona cosi' l'open source. Io pero' parlavo di come funziona

per la stragrande maggioranza delle persone che nulla sanno di

codice sorgente, opensource, github, tarapiatapioca ecc...


 codice sorgente, opensource, github 



Ed è giusto che sia così. Tuttavia volendo hanno gli strumenti per porre rimedio alle loro paure, se vogliono. 



Poi, che vuoi, se non va bene l'app a codice chiuso (e qui io sono d'accordo), se non va bene manco quella a codice aperto, cosa va bene???

Io resto dell'idea che l'OS sia una gran bella pensata e garanzia, soprattutto per queste situazioni.



-- 

Ciao!

Luca




 oltre al contare quanti messaggi ognuno scriva.



Invece il tuo...

Testa di minchia.



-- 

Cio' che si vede, e'.




 messa nel sorgente!



a questo serve il coinvolgimento dei privati. più soggetti diversi 

vigilano, con interessi diversi, meno probabile è il complotto per un 

gioco sporco. 


 sorgente, opensource, github, tarapiatapioca ecc...



la stragrande maggioranza delle persone deve ovviamente fidarsi. ma non 

ciecamente: i sorgenti aperti danno garanzia che non ci sia un solo 

soggetto che li controlla, ma anche altri soggetti con interessi diversi. 

nel caso specifico ad esempio c'era un esercito di esperti pronti a fare 

le pulci ai sorgenti. 





Anche io apprezzo l'OS e trovo sensato che l'app Immuni lo sia.



Non me ne occupo, ma penso che un po' su tutte le piattaforme

ci siano tecniche efficaci per monitorare cosa fa un programma,

anche senza sorgenti.



Certo che se poi fossero tutti d'accordo, da chi scrive l'app e chi

produce il ferro, allora si complicherebbe ulteriormente...



Eh si, questo e' un gran bene, ma appunto, si parlava del binario

che ti ammolla lo store...


On 10/06/2020 16:00, rootkit wrote:




 produce il ferro, allora si complicherebbe ulteriormente...



più soggetti partecipano ad una cospirazione e più questa è inattuabile o 

comunque destinata a venire alla luce in tempi brevi.

è stata persino formulata una equazione: 

https://journals.plos.org/plosone/article?id=10.1371/journal.pone.0147905




Allora basta agire da soli e potremmo avere le migliori

probabilità di realizzare con successo una cospirazione!!!



Vado a cospirare tutto solo ssssshhhhh.... :-D




 complicherebbe ulteriormente... 



intendi comprese pure le backbones su cui viaggia il traffico etc. in modo che se fai sniffing ti ritorna alterato peggio di una honeypot...? 



benvenuto in the matrix allora



ma in questo caso il rischio non potrebbe essere al contrario?

ovvero i sorgenti aperti agevolano gli hackers che potrebbero

ad esempio generare falsi contatti con falsi contagi













non ha senso per 2 motivi: 1) sul repository ci sono i sorgenti ma 

ovviamente non i secret per cominicare col backend 2) comunicare la 

positività non lo fa l'app ma l'operatore sanitario a cui devi dare un 

codice generato dall'app medesima. 





e cosa risolvo? la mia app immuni compilata da me potrebbe benissimo 

essere diversa da quela scaricabile pubblicamente!



io ho capito il contrario, è l'operatore sanitario che ti da un codice 

da inserire nell'app, qualora ti abbia trovato positivo.


 la stragrande maggioranza delle persone deve ovviamente fidarsi. 



non si può fare il reverse engineering sulla app e vedere da lì il codice?


 Io ragiono al contrario. Non ti fidi? C'è in GitHub il codice sorgente: te lo scarichi e te lo compili.



e non ho risolto nulla, perchè la mia app potrebbe essere diversa da 

quella che scaricano dallo store e installano.



quindi io avrei la versione pulita ( che non funziona comunque, non si 

connette al backend), ma gli altri ?



i codici in ballo sono due:



l'ID temporaneo, generato dall'app, varia spesso e viene scambiato 

tramite Bluetooth con i dispositivi vicini, praticamente la 

registrazione dei contatti.



il codice di autorizzazione, fornito dagli operatori sanitari quando il 

soggetto che ha scaricato l’app risulta positivo al virus. Da quanto ho

capito questo serve per fare l'upload dei contatti avuti -che, ne 

deduco- fino a quel momento sono rimasti in pancia all'app










 



leggo eh!



"Quando uno dei soggetti che ha scaricato l’app risulta positivo al 

virus, gli operatori sanitari gli forniscono un codice di autorizzazione 

con il quale questi può scaricare su un server ministeriale il proprio 

codice anonimo (questo avviene nel modello decentralizzato che sarà la 

versione definitiva di Immuni. In quello precedente, usato finora nelle 

beta dell’app, il paziente carica la lista dei codici con cui è stato in 

contatto nei giorni precedenti)."



l'ossimoro "scaricare su un server" lo interpreto come upload


 da inserire nell'app, qualora ti abbia trovato positivo.



l'ho installata e posso garantirti è come dico io.


 leggo eh!



ho installato l'app. il giro è: tu devi dare all'operatore un codice 

generato dall'app, l'operatore inserisce l'autorizzazione per quel codice 

dopodiché puoi prosegure con il caricamento dati.

quindi non ha senso parlare di falsi positivi: l'app può caricare il 

codice solo se viene autorizzata da un operatore e l'operatore ti 

autorizza solo se sei veramente positivo.




 un tuo database con un tuo account, ma non puoi far niente.



o meglio, per dirla in modo più corretto: su quel database firebase solo 

quell'app firmata da loro può accedere, se non hai il loro certificato tu 

non ci puoi accedere.





sicuramente c'è chi l'ha fatto. ma qui si parlava della maggioranza di 

persone che non ha skill per farlo.



chiaro!



tornando a bomba, open source una sega,

hanno reso pubblico del codice sorgente che loro

dicono essere quello dell'app e in effetti se compilato

genera una app graficamente uguale, ma che non fa niente

mentre quella scaricata dallo store rimane blindata.






 deduco- fino a quel momento sono rimasti in pancia all'app



non è così. nel caso di positivo occorre fornire un codice generato 

dall'app all'operatore, il quale autorizza il dispositivo e a quel punto 

l'app può caricare i dati. ma quello che viene caricato è la segnalazione 

che quel codice è positivo, non i contatti che rimangono sempre nella 

pancia delle app. saranno gli altri che, una volta che ti sei segnalato 

positivo, verificheranno con i dati in pancia se sono venuti a contatto 

con te.




 blindata.



non ho capito, pretendevi di avere accesso ai dati?





Non fantasticavo a questi livelli. :-)


 essere diversa da quela scaricabile pubblicamente!



Semplice: se hai paura dei 'poteri forti', ti puoi prenderti il codice sorgente, lo controlli o lo fai controllare, lo compili o lo fai compilare e la paura passa.



-- 

Ciao!

Luca


 non ho capito, pretendevi di avere accesso ai dati?



Beh, non direttamente, ma trasparenza vorrebbe che, in qualche modo, io sia in grado, avendo i sorgenti, di generare un'app funzionante esattamente come se... Non so, magari richiedendo qualche certificato, qualche chiave di sicurezza, roba così.



-- 

Ciao!

Luca


 mentre quella scaricata dallo store rimane blindata.



Usano le reproducibile build: puoi fare il controllo eccome.



Ciao

  Francesco


 qualche chiave di sicurezza, roba così.



certo. e magari customizzarti anche l'app in modo da raccogliere più info 

di contatto (che so, la posizione esatta, scattare foto o registrare 

suoni) per risalire a *chi* sono i positivi una volta che ricevi i dati. 

in barba a tutte le menate sulla privacy.


 certo. e magari customizzarti anche l'app in modo da raccogliere più info 



'sagerato...

Ciò che interessa a me è ovviamente che l'app che installo corrisponda esattamente ai sorgenti che vedo. Se no, che senso ha aver la cosa open?



-- 

Ciao!

Luca


 esattamente ai sorgenti che vedo. Se no, che senso ha aver la cosa open?



i sorgenti sono una cosa, i dati sono un'altra. se è questo quello che 

vuoi compilando quei sorgenti puoi confrontare l'apk ottenuto con quello 

distribuito. solo che mandando in esecuzione sul device il tuo compilato 

non può sostituirsi all'app distribuita perché non è firmata con lo 

stesso certificato. mi sembra ovvio sia così. 


 Ciò che interessa a me è ovviamente che l'app che installo corrisponda esattamente ai sorgenti che vedo. Se no, che senso ha aver la cosa open?



https://github.com/immuni-app/immuni-app-android/blob/development/README.md




"Checking the build

In addition to making the code open-source, we wish to help people verify that builds published on the App Store are coming from a specific commit of this repository. Please refer to the Immuni Technology Description for a complete overview of the goals and status of this effort.



Currently, we have a working open continuous integration for building the client. Here is the full specification. When it comes to reproducible builds, we will instead open an issue explaining what we have done so far and any missing steps."




 Usano le reproducibile build: puoi fare il controllo eccome.



Nope.



Come dicono loro stessi 

(
https://github.com/immuni-app/immuni-documentation/blob/master/Technology%20Description.md#reproducible-builds
): 





Per iOS:



"We have been working on this problem, also leveraging Telegram’s great 

work, but we have not yet found a satisfactory solution."



Per Android:



"The reproducibility of Android builds is affected by similar problems 

as on iOS" [...] "At present, we have managed to match different builds 

of the same commit successfully, but for a few files. However, we 

recognise that more work needs to be done to achieve a complete 

solution, and we are eager to collaborate with experts in relevant 

fields to improve the process."




 Nope.



Grazie Andrea.



Ciao

  Francesco


 al mondo Clojure e functional programming. 



decisamente, e manco a farlo apposta ho letto questo semplice pezzo di Michael Feathers dove tocca proprio il punto che evidenziavo come chiaro errore di Martin:



"

So many of the techniques around gaining testability involve parameterizing classes and methods so that all of the inputs and outputs are explicit and mockable under test. You don’t have an embedded call to, say, the file system in a class. You pass in a reference to that capability as a constructor or method argument. This makes an OO system, broadly functional. That is, to say, it is honest. You can look at the signatures and see what is possible.

"



https://michaelfeathers.silvrback.com/functional-code-is-honest-code




https://www.reddit.com/r/programming/comments/h7t2s5/functional_code_is_honest_code/




il thread manca di centrare l'ovvio e il giuato ed è al solito ricco delle solite cretinaggini, ma vabbè nulla di nuovo.


 So many of the techniques around gaining testability involve parameterizing classes and methods so that all of the inputs and outputs are explicit and mockable under test.



Ma questo lo sa anche Martin. Il punto e` che TDD ti porta naturalmente 

a quel modo di scrivere il software. Non e` che tu non lo possa fare in 

altro modo, ovviamente. E` solo che con TDD, e` una conseguenza 

naturale. Credo che fosse questo il senso delle parole di Martin.


 Ma questo lo sa anche Martin



ma il punto è tutto lì. Feathers ha capito che partendo da un design tipico/proprio della programmazione funzionale, ottiene di più: "interfaces are explicit", e la function che ha in input la pull dei dati e li restituisce trasformati non l'avrebbe sbagliata, RDD o meno. Feathers è parecchio avanti a Martin in tutto (tutto quello che conta davvero informaticamente intendo, non marketing personale, presentazioni e intrattenimento, editoria etc.).



unica nota: è sbagliato quanto dice su effects systems e monadic - lo scoprirà in futuro approfondendo. del resto è in gamba: anni fa fece una presentazione in cui mostrava come, in un linguaggio come Ruby o Python, faceva precedere le functions da commenti dove descriveva il typing della signature della function stessa... meravigliandosi poi che sembrasse haskell, e che il suo codice migliorava. io l'ho fatto per anni nei linguaggi untyped dove i termini erano di un singolo tipo ricorsivo perchè era ovvio e utile, mentre lui dice d'esserci arrivato per intuizione. beh molto interessante, rispetto al post "RDD? Sempre e solo TDD (e comprate le miei lezioni podcasts!)"


 



beh se uno come Martin, che scemo non e', non riesce ad abbracciare la programmazione funzionale facilmente, che speranze ci sono per il resto del pianeta? A me Clojure piace un casino, sintassi e semplicita' d'uso. Poi pero' ti accorgi di essere in una community incomprensibile, a meno di non essere nato programmatore funzionale. Tool e librerie ostiche, teoria (monadi eccetera) che boh non capiro' mai a meno di spenderci mesi (e di cui non afferro l'utilita' cmq), librerie criptiche scritte da gente che sembrano geni ma di cui non capisci nulla. Guarda il progettino che hai suggerito scritto da Stuart Halloway (nome di peso tra l'altro), non l'ho scaricato e provato d'accordo, ma io dalla README non capisco che cazzo faccia. Poi alla fine trovi



(+ 1 2)

(check! #{3})  ;; duh

This is ugly by design, as an inducement to test properties instead of specifics.



che e' filosifia? e mi viene da mandarlo a caccare. 

Vi capirete voi pero' immagino :D


, che speranze ci sono per il resto del pianeta? 



la programmazione funzionale sta solo rifacendo capolino. Le idee sono 

vecchie come il cucco. D'altronde, in linguaggi come Java, che non e` di 

certo nato funzionale, certi paradigmi funzionali sono stati adottati da 

tempo e ormai fanno parte (o dovrebbero far parte) del bagaglio di 

conoscenze di un qualunque sviluppatore Java. Anche in JS, per esempio, 

il functional programming e` presente pesantemente.



 >A me Clojure piace un casino, sintassi e semplicita' d'uso. Poi pero' 

ti accorgi di essere in una community incomprensibile, a meno di non 

essere nato programmatore funzionale. Tool e librerie ostiche, teoria 

(monadi eccetera) che boh non capiro' mai a meno di spenderci mesi (e di 

cui non afferro l'utilita' cmq),



E` qualcosa che sicuramente usi gia` in Java: 

https://nazarii.bardiuk.com/posts/java-monad.html


Ti basta aver usato Optional o flatMap.








 il functional programming e` presente pesantemente.



sì ma sono tutti multiparadigma. per scrivere i test ad esempio si fa 

ampio uso di programmazione imperativa e/o a oggetti. dovessi scrivere un 

test per un linguaggio puramente funzionale io non saprei come fare.

ma è sicuramente un limite mio.


 



per fortuna attorno al 2010 ho cominciato a studiare Clojure e ad utilizzarlo per progettini o piccole utilities. Al momento non lo sto piu' usando,  pero' devo dire che e' stato un ottimo investimento perche' mi ha aperto le porte alla programmazione funzionale. Diciamo che Stream, Optional, map, flatmap, strutture dati immutabili, eccetera mi sono venute quasi gratis grazie a quegli studi.



dovrebbe essere la cosa piu' facile del mondo in teoria, proprio perche' funzionale. 

In pratica sei abituato ad uno stile talmente diverso che non sai da che dove partire.



In piu' i tool non sono al livello dei linguaggi piu' popolari e anche le librerie di test non sono eleganti come Mockito tanto per dire.



La comunita' e' cosi': sembra che molte cose che si sono consolidate come necessarie nel mondo OOP (tdd, mock, etc) a loro non gliene possa fregare di meno. Guarda la libreria clojure transcriptor:



https://github.com/cognitect-labs/transcriptor




l'autore ti assicuro e' uno notevole. Ebbene non c'e' mezzo test nel progetto. Boh :D


 mi sono venute quasi gratis grazie a quegli studi.



io feci la stessa cosa studiando scala che fra l'altro implementa anche 

il pattern matching che a java manca come l'aria sulla luna.




 Vi capirete voi pero' immagino :D 



con la community Clojure per la verità non tanto.


 forse perchè pensi ai tests sempre come manuali e non cogli il suo incitamento verso altro? 



sicuramente non ho colto (nonostante sappia piu' o meno cos'e' spec), ma il punto e' proprio quello: si e' spesa mezza riga per far capire ad un non supermegaespertodilinguaggifunzionali per far capire cosa fa, l'importanza che ha, la filosofia che ci sta dietro? 



A me pare di no, perche' evidentemente e' tutto ovvio (per alcuni).


 transcriptor: 



non ci sono perchè quelle quattro function sono saltate fuori parlando di RDD l'altra volta. se invece guardi check, spec, deftest & co. che ti indicavo trovi tutto.



su tdd e mock: hai mai ragionato sul fatto che prendere codice Java "tipico" creato con tdd/mocking/etc. non fa altro che creare (quanto più possibile) metodi e interazioni tra questi che _corrispondono_ a functions pure con interfacce chiare e testabili? 



oop + tdd + mock + di + altro = reinventare functional programming. 

è davvero inequivocabile alla fine


 saprei come fare. ma è sicuramente un limite mio.



partiresti dal type systems, creando inizialmente delle invarianti che rendono impresentabili e inattuabili staticamente le situazioni che le violano. questo in un type system meno espressivo (Java, C++, Python, ...) non è fattibile.

poi proseguiresti creando altre invarianti che le functions dovrebbero rispettare "universalmente": non scriveresti una espressione logica sulla base di valori ben definiti, ma proprietà che sulla base del type system saranno da guida sl sistema di testing per generare da solo i casi di test (property-based testing in Quickcheck ad es.).



l'unione di tutta una serie di meccanismi ulteriori del linguaggio (es. tyoe inference "vera", pattern matvhing esaustivo, convogliare le functions verso il total functional programming, etc.) farebbero si che i tuoi programmi potrebbero addirittura salvarti da situazioni e condizioni a cui non pensavi nemmeno, finanche provando staticamente condizioni di non terminazione!



in pratica ti sto descrivendo quello che chiamiamo "type-driven development". 




 io feci la stessa cosa studiando scala



un ambiente terribilmente dispersivo. volevano traghettare le persone verso l'FP ma di fatto è un linguaggio più interessante per i già esperti che vogliono sperimentare astrazioni complicate (il type system è molto potente e complesso). sconsigliato



scala era, anzi è, orientato alla programmazione reattiva e concorrente 

in questo senso fa uso di costrutti funzionali, immutabilità, etc... 

almeno al tempo (parlo anch'io del 2010 o giù di lì) più che alla fp 

puntavano proprio a questo. c'erano gli actors nativi nel linguaggio e 

anche delle librerie molto potenti (akka). però in se il linguaggio non è 

che lo adorassi, mi piaceva l'idea del multiparadigma ma anche su questo 

sono nati linguaggi decisamente più organici e semplici.


On Tue, 16 Jun 2020 07:14:28 -0700, cpascoshi wrote:






 funzionali



si ma nelle intenzioni nasce proprio per fondere FP e OOP, il resto è arrivato dopo. lo stesso actor model non era la prima scelta di Odersky, che pubblicava già su modelli e implementazioni basate sulle petri net. alla fine più che come laboratorio per modelli di concorrenza e altro s'è ritrovato ad essere usato per esplorare FP su astrazioni di livello superiore higher-kinded types.


 e implementazioni basate sulle petri net. 



sai che non mi ricordo se è effettivamente così? non sono sicuro, è un linguaggio di cui ricordo poco perchè non m'è mai interessato molto.


 
https://www.repubblica.it/tecnologia/mobile/2020/05/25/news/curonavirus_l_app_immuni_arriva_il_10-15_giorni_pubblicato_il_codice_sorgente-257556465/






In ogni caso, a quanto pare non tutti ritengono che

la tracciabilita' basata su app sia cosi' "efficace",

pur ritenendo che la tracciabilita' sia importante

(dicono che sarebbe piu' utile avere un'anagrafica dei positivi,

con "geaolocalizzazione" di dove "svolgono la loro degenza", piuttosto

che testare contatti molto occasionali.

Cioe' sarebbe più utile sapere dove abitano i positivi accertati

e  se nei loro dintorni si stiano sviluppando eventuali focolai,

piuttosto che andare a vedere tutti quelli con cui un positivo è stato 

30 secondi a contatto in un bar che ha frequentato prima

si sapere di essere positivo.

Questo anche sulla base del fatto

che se si trovano centinaia di migliaia di potenziali infetti,

poi non ci si sono comunque i mezzi per tracciarli tutti

[da quello che dicono, pare che la probabilita' di contagio

sia molto piu' elevata in caso di contatto prolungato

che non in caso di contatto molto breve. Se ho capito

bene, questo accade perche' con un contatto molto breve

e' abbastanza difficile che si accumuli una quantita' di virus

tale da dare origine ad una carica virale sufficiente a infettare

qualcuno, mentre in caso di contatto prolungato,

soprattutto in luoghi chiusi, si possono accumulare

piu' facilmente quantita' di virus sufficienti a  dare

origine ad una infezione])



Ne hanno parlato un medico e un economista qui:



https://www.youtube.com/watch?v=VNRUufEKKRo




dal minuto 19.50 al minuto 29 circa





Ciao,

Marco.



-- 

Questa e-mail è stata controllata per individuare virus con Avast antivirus.

https://www.avast.com/antivirus





 Cioe' sarebbe più utile sapere dove abitano i positivi accertati > e  se nei loro dintorni si stiano sviluppando eventuali focolai,



Mi sembra una sciocchezza. Un positivo, accertato oggi, puo` essersi 

mosso a chilometri di distanza ieri e aver infettato altri. Una volta 

che risulta positivo, presumibilmente is autoisolera`, quindi monitorare 

cio` che gli accade intorno, da quel momento in poi, ha poco senso.




 non essere nato programmatore funzionale.



sarebbe interessante capire precisamente perchè. in fondo la storia ci dice che i programmatori provenienti dalla programmazione procedurale ci hanno messo solo alcuni decenni a capire come programnare object-oriented, ragion per cui io dico che il problema non è funzionale o meno: è il diverso.


On 18/06/2020 13:42, cpascoshi wrote:



 >

ci hanno messo solo alcuni decenni a capire come programnare object-oriented



...e hanno combinato un disastro :D



https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7



 ...e hanno combinato un disastro :D 



Uff un articolo inutilmente lungo. bastava una delle tante come:



"What is Object-Oriented Programming?"



a) "Object-Oriented Programming is programming using inheritance." - Stroustrup, 1991



b) "Object Oriented Programming without Inheritance" - Stroustrup, 2015



e si capiva uguale. e poi le conclusioni su FP salvatore del mondo sono sbagliate, in tipico stile divulgativo. mah


 
https://medium.com/better-programming/object-oriented-programming-the-trillion-dollar-disaster-92a4b666c7c7




anche questa:



"

Some might disagree with me, but the truth is that modern Java/C# OOP has never been properly designed. It never came out of a proper research institution (in contrast with Haskell/FP). Lambda calculus offers a complete theoretical foundation for Functional Programming. OOP has nothing to match that.

"



queste sono le cretinate per darsi un tono che allontanano gli addetti ai lavori dalla teoria necessaria e utile.


 anche questa:



no, non ci siamo. più leggo più escono 'scemitàggini'.



"Mutability is Inherent to OOP"



no, per nulla (vd. Cardelli, Abadi, Rémy, Cook, 

...). questo tipo ripete a pappagallo il sentito dire in giro. insopportabile oh