Newsgroup: it.lavoro.informatica
Titolo: miglior tecnologia IT (no linguaggi di programmazione)

messa così sembra un domanda stupida. Lo è. Ma sono alla stretta finale 
per un colloquio di lavoro. 
E' il terzo appuntamento e dovrò fare una presentazione dove illustro per 
circa 20 minuti una tecnologia a piacere, dopo di che si apre la parte "Q. 
& A."... quindi sarebbe anche furbo scegliere qualcosa dove me la cavo più 
o meno bene. 
 
Per esempio, avrei voluto scegliere "microservices, kubernetes e docker" 
ma ho solo 3 giorni di tempo e temo che nella sezione Q&A potrei finire 
per essere massacrato a sangue  
 
 
Suggerimenti, idee? sparate la qualunque ad alzo zero..  
 
p.s.: sono devops e i linguaggi di programmazione hanno una rilevanza 
secondaria nel mio lavoro. Se conosco un linguaggio di programmazione mi 
dicono solo grazie e mi danno una pacca sulla spalla :) 
 
-- 
Massimiliano Adamo

 circa 20 minuti una tecnologia a piacere, dopo di che si apre la parte
 
Cioe`, stai chiedendo ad altri di dirti quale tecnologia conosci cosi` bene da poter tenere una presentazione di 20 minuti con tanto di Q&A. Secondo me, per esempio, parlare del sistema di propulsione dello Shuttle sarebbe veramente cool.
 


Vai di "internet of things", è un argomento che acchiappa.
 
-- 
Soprano

 per essere massacrato a sangue
 
Quoterei Soprano...
 
-- 
Al3xI98O
«L'importante non è cadere, ma sapersi rialzare»


Che de' un "devops" ?
 
 

 Che de' un "devops" ?
 
Devoti Opus Sancti

 Suggerimenti, idee? sparate la qualunque ad alzo zero..
 
Si di decidere da solo. Non si capisce cosa potresti ottenere da persone 
che non conoscono le tue competenze.
 
Per quanto riguarda l'essere fatto a pezzi su microservices etc, forse 
non e' detto che per passare il colloquio tu debba rispondre a tutto 
perfettamente. Se un argomento e' ostico ci sta che se ne padroneggi una 
parte. Ovvero e' possibile che siano abbastanza intelligenti da capire 
che il saper tutto di una menata non e' per forza meglio di sapere 
abbastanza di un argomento complesso.

 Che de' un "devops" ?
 
http://lmgtfy.com/?q=devops
 
 
Benvenuto nel 2016.
 

 perfettamente.
 
Infatti. Lo scopo di un colloquio del genere non e` certamente valutare la sua competenza tecnica su tali argomenti. Se lo hanno strutturato come presentazione di 20 minuti e` evidente che e` per valutare i communication skills e quanto e` capace di presentare le sue idee in maniera coincisa ed efficace. L'importante non sara` neanche saper rispondere a tutte le domande, ma vedere come se la cava sotto stress - per esempio con domande particolarmente complesse, e alle quali non e` detto che bisogna saper rispondere. Ovviamente, se sapessero che si e` appena rivolto ad un gruppo per chiedere consiglio su cosa dire, lo boccerebbero al volo, ma noi questo segreto non lo riveleremo mai.


La ricerca indicata l'avevo gia' avviata
I principi enunciati mi sembravano talmente ovvi e banali da pensare 
"..ma ci sara' sicuramente qualcos'altro, di innovativo, di importante.."
Invece e' tutto li
Aria fritta
 
 

 Devoti Opus Sancti
 
LOL
 
 

 rispondere. Ovviamente, se sapessero che si e` appena rivolto ad un gruppo 
CUT
 
"ad un gruppo" LOL 
 
 

 "ad un gruppo" LOL
 
Quale parte di "group" in "newsgroup" non ti e` chiara, ciccino? Te la spiego, sai?
 

 Aria fritta
 
Avevi chiesto cos'e` un devops. Della tua critica non credo freghi niente a nessuno.
 

 Avevi chiesto cos'e` un devops. Della tua critica non credo freghi niente a nessuno.
 
Tu 'credi' che non freghi niente a nessuno
Ammazza, e chi saresti per dirlo?
 
 
 
 

 Ammazza, e chi saresti per dirlo?
 
Uno a cui non frega niente di quello che tu pensi sia DevOps. Diciamo che l'argomento "sempre la solita roba, e` aria fritta", usato tipicamente da qualche trombone dell'informatica che non vuol neanche sforzarsi di capire come funzioni il nuovo, non e` proprio un argomento cogente, che porti la gente a farsi qualche domanda. Se hai critiche da fare a DevOps falle in maniera organica, intelligente, e costruttiva. Altrimenti stare zitti non e` peccato mortale ;)
 

 Uno a cui non frega niente di quello che tu pensi sia DevOps. Diciamo che l'argomento "sempre la solita roba, e` aria fritta", usato tipicamente da qualche trombone dell'informatica che non vuol neanche sforzarsi di capire come funzioni il nuovo, non e` proprio un argomento cogente, che porti la gente a farsi qualche domanda. Se hai critiche da fare a DevOps falle in maniera organica, intelligente, e costruttiva. Altrimenti stare zitti non e` peccato mortale ;)
 
Ora capisco, sei uno di quelli che usa 'tipicamente' questo e 
quest'altro, capisco e cerchero' di adattarmi al tuo livello
Certo che se e' necessario formalizzare le metodologie per realizzare 
dei sistemi che risolvano problemi a chi dovra' usarli, invece che 
crearne di nuovi, e' TIPICAMENTE un chiaro indicatore del fatto che si 
sta lavorando alla cazzo di cane
Come dire ad un muratore "..da adesso per fare un muro devi usare il 
piombo altrimenti non verra' realizzato a regola d'arte e poi il cliente 
ce lo contesta, spendi un po' di tempo in piu' ma lo tiri su dritto.."
 
 
 
 
 
 

 sta lavorando alla cazzo di cane
 
E` una supercazzola? E` davvero un peccato che, prima di tirare fuori una nuova metodologia di lavoro, il mondo informatico non ti telefoni per sapere cosa ne pensi. Lavoreremmo tutti meglio con il placet di "RobertoA" - lui si` che sa cosa e` valido e cosa no. Ripeto che di quello che pensi tu di DevOps non frega una ceppa a nessuno. Semmai conferma che non sapevi cosa DevOps fosse, e sei pronto a buttare merda sull'ennesima pratica informatica a cui fai resistenza perche` ancorato alla tua calda zona di comfort. D'altronde, si stava meglio quando si stava peggio, i treni arrivavano in orario, la bicicletta e` un aggeggio demoniaco, e nessuno vorra` avere un telefono in casa.

 Suggerimenti, idee? sparate la qualunque ad alzo zero..  
 
Alla fine? Cosa hai scelto? Quando hai la "discussione"?
 
-- 
Al3xI98O

 D'altronde, si stava meglio quando si stava peggio, i treni arrivavano in
orario, la bicicletta e` un aggeggio demoniaco, e nessuno vorra` avere un
telefono in casa.
 
Peccato per te che c'erano programmatori come Antony Crowther
che da *solo* riusciva in un weekend a produrre un videogame
che poi sul mercato aveva successo e vendeva a palate. Da *solo*, eh, mica
perdeva tempo a chiedere al collega di banco in pair programming
se era giusto prima di committare fare un unit test prima di
fare un debug prima di fare [riempire con altre cazzatine
informatiche da fighetti]...
 
 

ciccio in data venerdì, 12/08/2016 ha detto:

Non concordo sul "si stava meglio quando si stava peggio" ma è indubbio 
che ai tempi IO facevo una banale anagrafica in una giornata (stando 
largo) mentre ora UNO BRAVO ci mette 3 giorni :)
 
Non tornarei cmq indietro...
 
-- 
Al3xI98O

On Friday, 12 August 2016 10:10:30 UTC+1, ciccio  wrote:
 
[...]
Imbecillotto, dovresti aver capito da tempo che meno parli di programmazione, meglio e` per te. Tutti gli altri qui dentro l'hanno compreso. Finisci, prima o poi, per fare figuracce. Del fatto che i tuoi amichetti riuscissero a scrivere un videogame in un weekend non credo gliene fotta niente a nessuno. Quelle che per te sono "cazzatine informatiche da fighetti" sono le moderne metodologie, pratiche, tecniche e tecnologie di sviluppo di software di larga scala. Peccato per te, che non capisci un cazzo di come si sviluppa seriamente il software.
 

 largo) mentre ora UNO BRAVO ci mette 3 giorni :)
 
LOL :) Non sei in grado di comprendere neanche un banale errore di logica in una frase, figuriamoci se riesci a scrivere software che funziona.
 

 LOL :) Non sei in grado di comprendere neanche un banale errore di logica in una frase, figuriamoci se riesci a scrivere software che funziona.
 
L'ha capito. C'e' voluto un anno e 500 messaggi, ma l'ha capito.
 
-- 
L'importante non e' essere brutti, ma piacere

 L'ha capito. C'e' voluto un anno e 500 messaggi, ma l'ha capito.
 
Oddio ma che vite di merda che fate... non ci crederete ma sono davvero 
triste per voi... vabbeh, cavoli vostri ad un certo punto se ve la 
cercate.
 
-- 
Al3xI98O


premesso che le metodologie dallo scrum al tdd, dal pair programming 
all'extreme programming, ecc.. sono ottime cose e rendono il software 
più sicuro e scritto bene
 
pensi seriamente che google, facebook, twitter, airbnb,  o altri big del 
web all'inizio della loro avventura si siano messi davvero a fare i 
certosini con le metodologie ?
 
ti ricordo che FB o google sono stati creati da ragazzi poco più che 
ventenni e manco laureati o con conoscenze approfondite di quelle 
metodologie.
 
hanno avuto un idea, validata, tonnellate di codice scritto sicuramente 
alla c.... di cane per far uscire il prima possibile il prodotto.
 
hanno sicuramente azzeccato il time-to-market, la novità (oddio nessuno 
dei due erano novità, ma in qualche modo  diverse rispetto alla 
concorrenza).
 
oggi che sono realtà affermate e consolidate sul mercato mettono in 
pratica le metodologie descritte.
 
 
Ciao

 certosini con le metodologie ?
 
Cosa c'entra con quel che ho scritto? Chi se ne frega di come certi sistemi sono nati? Chi se ne frega se erano due ragazzini in un garage o tre nerd in una stanza d'albergo? Chi se ne fotte se si erano o meno messi a fare i "certosini"? Qual e` l'utilita` di un argomento del genere? 
Oggi esistono metodologie di sviluppo del software. Punto. Usarle non significa mettersi a fare i "certosini"; significa scrivere il software come si deve. Lo sviluppo software e` una disciplina che si e` evoluta nel tempo esattamente come molte altre discipline ingegneristiche, maturando best practice, design pattern, tecniche, tecnologie e metodologie varie. Oggi e` impensabile pensare di scrivere software commerciale, di larga scala, ignorando gli strumenti piu` comuni (come gli unit test, per esempio, che uno come ciccio non sa neanche dove stanno di casa perche` "io faccio debug a mano"). Sarei veramente curioso di sottoporre i software di qualcuno a tool come SonarQube o Fortify e vedere quali chicche vengono fuori.

 sono davvero triste per voi...
 
Vedi che non l'ha capito?
 


Ok
--
L'importante non e' fregarsene, ma far finta di niente.

 metodologie.
 
Guarda che le metodologie non servono mica per avviare un'idea 
imprenditoriale. Non e' che con il TDD scopri l'algoritmo di Dijkstra, 
scrivi un paper scientifico, o ti instilla una nuova idea per una 
startup sconvolgente.
 
Servono per scrivere software manutenibile nel tempo. Il fatto che FB, 
passata la fase di incubazione in scantinato, abbia dovuto fare uso di 
tale metodologie (guarda a caso Kent Beck lavora in FB proprio per 
questo), e' la dimostrazione di quello che dicevo sopra.

 abbastanza di un argomento complesso.
 
si... ma la presentazione deve essere fra l'altro congruente. Se non 
conosco bene l'argomento rischio di scrivere castronerie. 
 
 
-- 
Massimiliano Adamo


ho fatto un confronto tra alcuni SCM (software configuration management). 
In particolare una comparazione tra Puppet, Ansible e Saltstack e gli 
eventuali vantaggi (IMO inesistenti) di una migrazione da B ad A e 
viceversa. 
 
La cosa più importante è che ce l'ho fatto :)
 
 
-- 
Massimiliano Adamo

 Shuttle sarebbe veramente cool.
 
mi serviva una spinta, del tipo "potresti parlare di A, che oggi fa figo 
ed è parecchio interessante". 
Al contempo deve essere una cosa che non avrei dovuto studiare da zero, 
per evitare trabocchetti nella sessione Q&A. Tutto qui. 
 
p.s.: non era del tutto quel che ho scritto; ovvero i linguaggi di 
programmazione sono un po' importanti, anche per i devops. Ad un test 
tecnico mi hanno chiesto di scrivere l'algoritmo per risolvere la serie di 
fibonacci nel linguaggio che preferivo. 
 
-- 
Massimiliano Adamo


Si, in effetti e' un vero peccato, ma meglio cosi', non sarebbe 
piacevole spendere tempo per discutere su queste cose
Poi meglio che non telefoni nessuno, arrivano gia' molte chiamate da 
evadere, grazie comunque per l'idea
Non so se tutti lavorerebbero meglio col mio benestare
Sicuramente so cosa e' valido per le mie attivita', e ritornando al 
punto della questione DevOps, sicuramente non e' una metodologia per me 
interessante, semplicemente perche' la scala dimensionale dei prodotti 
realizzati consente un rapporto diretto e costante con chi dovra' usarli
Se poi pensi che quanto espresso nel post precedente voglia dire 
'smerdare' l'ennesima pratica informatica, vuol dire che non sai manco 
leggere, o peggio ancora leggi e non comprendi, o peggio dei peggi leggi 
e comprendi ma vai avanti solo per puntiglio
Sintetizzo cosi' ti sara' piu' chiaro: se trovi sia stato utile adottare 
la metodologia DevOps, significa che finora hai lavorato alla minchia di 
bassotto, senza coordinazione tra quanto fatto e quanto richiesto.
Questo significa che tale metodologia e' sicuramente utile, per te e per 
quanti altri abbiano problemi di coordinamento
Pensi davvero che per il fatto che qualcuno opera in un certo modo, 
tutto l'universo debba adeguarsi?
 

 bassotto, senza coordinazione tra quanto fatto e quanto richiesto.
 
Ti ripeto che non frega una ceppa a nessuno delle tue considerazioni, sopratutto quando e` piu` che palese che di DevOps non ci hai capito una mazza. Un parere e` apprezzabile quando proviene da qualcuno che conosce la materia che sta giudicando. Guarda, ci vuole un bel coraggio da parte tua nel rimproverare agli altri di non aver capito quel che scrivi, quando tu continui a smerdare DevOps non avendo capito ne` cosa sia, ne` perche` si sia sentito il bisogno di formalizzare questa cultura della collaborazione tra sviluppatori e non sviluppatori. Il fatto che tu pensi che DevOps sia una pratica adottabile dal singolo sviluppatore - al pari di scegliere quale tool di strumento usare - la dice lunga su quanto tu ci abbia capito dell'intera questione. 
 
E continui a parlare.

 tutto l'universo debba adeguarsi?
 
PS: ennesimo strawman argument. Io non ho mai affermato che tutto l'universo debba adeguarsi a DevOps (anche se e` un modo di lavorare che ha prodotto e produce ottimi risultati). Sto rimproverando *a te* di parlare senza conoscere. E` diverso.
 


Veramente continuo a scrivere, non a parlare
"..che non frega una ceppa a nessuno.."  per la seconda volta, e tu chi 
saresti per dirlo? Hai fatto un sondaggio? Interviste? Qualcuno te lo ha 
detto/scritto?
Lo dicevo che sei uno di quelli che usa il 'tipicamente' ( "..da bravo 
ignorantone tipico..") gia' questo basterebbe a valutare con precisione 
l'utilita' dei tuoi interventi
Inoltre non sto rimproverando 'gli altri', mi sto rivolgendo unicamente 
al mio interlocutore
Per ultimo, se qua' dentro c'e' qualcuno che possa ergersi a "paron del 
niusgrup" si faccia avanti e sommessamente ritireremo le parole 
giudicate offensive
Esso basta pero', non c'ho tutto il tuo tempo a star qua a scrivere su 
ste minchiate
 
 
 

 niusgrup" 
 
Bla bla bla... chiacchiere. Parla di certi argomenti quando sai.

On Tuesday, 16 August 2016 11:57:55 UTC+1, RobertoA  wrote:
 
[...]
Tieni, ti do un paio di link:
 
https://en.wikipedia.org/wiki/DevOps
 
http://devops.com/
 
 
E impara che, prima le cose le si studia, e sopratutto le si applica, e poi ci si erge a opinionisti. Il **TIPICO** atteggiamenti di molti chiacchieroni di i.l.i e` di buttare merda su un po' tutto cio` che non conoscono, anche perche` non lo hanno mai usato. Tu sei un po' come ciccio, che butta merda sugli unit test senza averne mai scritto uno, o quell'altro imbecille trevigiani che sparlava di test JavaScript senza sapere neanche cosa fossero. PRIMA studiate, DOPO parlate. Che` gli arrampicamenti sugli specchi servono solo a rendervi piu` ridicoli di quanto non siate.

 La cosa più importante è che ce l'ho fatto :)
 
Ottimo!
 
-- 
Al3xI98O

 Urca, capisco di più l'arabo :P
 
Tranquillo, non ci meraviglia.
 


Certo pero' che sei un cagacazzo...
:-D

 Sarei veramente curioso di sottoporre i software di qualcuno a tool come SonarQube o Fortify e vedere quali chicche vengono fuori.
 
Noi qui si scrive software alla pene di segugio. :-D
 
Tuttavia io ho un'altra forma mentis e m'interesso...
cortesemente, sapresti darmi una una breve
descrizione di SonarQube e Fortify, con un confronto
con prodotti come quelli di Parasoft e/o di
programmingresearch.com
? (se li conosci)
Intendo in particolare su codice C/C++ che sono le
tecnologia che m'interessano.
 
Ok: puoi postarmi i link alle home page e dirmi RTFM. :-)
Pero' sono prodotti molto complessi e se hai esperienza diretta
di analisi statica e dinamica con questi strumenti
sicuramente, anche in poche righe, potresti darmi informazioni
difficili da estrapolare pur leggendo un sacco di roba a casa di
ciascun "oste" alla ricerca del vino piu' buono o delle
differenze salienti, anche macroscopiche.
 
Se ne hai il tempo e la voglia ti ringrazio.
 


 
 
SonarQube lo usiamo noi per analizzare il codice java.
 
Nel complesso trovo che sia un prodotto abbastanza buono, anche se
a volte, a mio avviso, è un po' pignolo.
 
Comunque ti indirizza nella direzione di scrivere classi che
siano il meno complesse possibile, ossia che non abbiano un numero
di metodi troppo elevato e non abbiano metodi di eccessiva
complessità.
Per ottenere questo risultato, si rende dunque necessario
distribuire la business logic su più metodi per classe, e
su più classi, che in effetti è il modo corretto di programmare
ad oggetti.
 
 
Noi abbiamo dei parametri massimali di complessità e minimali
di copertura da rispettare, e non è raro che si debba
modificare del codice java che funziona correttamente soltanto
perché non rispetta del tutto i parametri.
 
 
Naturalmente da un lato hai il vantaggio di avere codice di
maggior qualità, ma dall'altro hai lo svantaggio di avere
tempi di sviluppo più lunghi.

 tempi di sviluppo più lunghi.
 
Gia', questo e' il piu' palese trade-off ma d'altra parte per certi
settori e' richiesta l'aderenza ad alcuni di questi "standard" o
"vademecum". Non e' il mio caso, tuttavia sono interessanti da
leggere. Questi vademecum, vedi quello "JOINT STRIKE FIGHTER" o/e
il MISRA sono composti da millemila regolette che sono
inpossibili da tenere presenti a mente si scrive io codice,
da cui la necessita' di automatizare la verifica dell'aderenza.
Quello di Parasoft l'ho usato: fa impressione, permette di verificare
a scelta secondo i due citati sopra, i suggerimenti dei Mayers
e altro, oltre che analisi a runtime. Credo che ci si possa
"certificare" un software con quello. Mi chiedevo se SonarQube
fosse su quei livelli o se comunque potendo dire "e' 0 problemi
con SonarQube" possa avere un qualche valore di mercato al di fuori
del "reparto sviluppo" perche' i pacchetti commerciali sono notevoli
ma anche belli costosi.
 
 

 ad oggetti.
 
Mah. Dubito fortemente che questo modo di procedere possa portare 
risultati buoni. E' vero che il risultato deve essere quello, ma non ci 
arrivi solo perche' c'e' un tool che ti dice questa classe ha troppi metodi.
Se non segui cose come TDD finisci semplicemente per create classi per 
spostare metodi e "diluire" il codice. Il che non ha nulla a che fare 
con i principi di programmazione SOLID ad esempio.
E' il come il problema, e senza una guida come quella citata sopra 
finirai per fare un bel papocchio ugualmente.