Newsgroup: it.lavoro.informatica
Titolo: RAL Troppo alto - 6a puntata BIS

Puntate precedenti:
1 
https://goo.gl/mwu8fz
 
2 
https://goo.gl/9WxXpP
 
3 
https://goo.gl/0dmEJT
 
4 
https://goo.gl/RORN1p
 
5 
https://goo.gl/AtsfYk
 
5a 
https://goo.gl/aZgA9M
 
6 
https://goo.gl/jX1Yyp
 
 
Alla fine... ho cambiato! E' stato pià facile di quel che credessi con 
la botta di culo della vicinanza che mae non fa.
 
I dettagli per non tediarvi qui: 
https://goo.gl/yRT8HS
 
 
Sul *RAL* (argomento IT anche se poi mi avete aiutato su 1000 aspetti) 
ho proposto (e mi han accettato in TOTO) una scaletta (già 
contrattualizzata):
- 2017: prenderò come adesso ma senza pare variabile e senza bonus
- 2018: prenderò come adesso ma senza pare variabile
- 2019: prenderò come adesso (ma tutto in VERO RAL)
- 2020: prenderò più di adesso
se riuscirò a formare un team di almeno due persone nei primi 5 anni 
prenderò ancora di più (se accadrà oltre i 5 anni ridiscuteremo il 
tutto).
 
In pratica per il 2017 ci perderò qualcosina (sono 4 mesi quindi non 
troppo), nel 2018 dovrei andare quasi in pari (perché non avrò bonus ma 
entreranno come RAL), nel 2019 meglio e dal 2020 molto meglio.
 
-- 
«Non scegliere la strada più comoda, scegli quella giusta.» (Al3xI98O)

 - 2017: prenderò come adesso ma senza pare variabile e senza bonus
 
Cioè prendi il tuo RAL fisso attuale giusto?
Mi spieghi la differenza tra parte variabile e bonus?
 
Ho letto che in pratica avrai ambia scelta in termini tecnici.
Su che strumenti e metodologie stai puntando, se posso chiedere?
 
Ciao
  Francesco

 Su che strumenti e metodologie stai puntando, se posso chiedere?
 
Per adesso ho deciso di andare sulla via tranquilla (anche perché ci 
sono già consegne urgenti :():
- *C#* come linguaggio di sviluppo
- *DevExpress* (han già le licenze quindi mi va bene) come suite di 
"componenti"
- *SQL Server* (e Oracle) come database (banale ma dato che il "mio" 
MES vivrà con un gestionale...)
- *MVVM* "a modo mio" come pattern
- come UI *WPF* per una parte (mi viene utile il databinding per certe 
variazioni volanti che dovrò fare) e *web* (di preciso non ho valutato 
ma sarà una scelta futura)
- per il DAL vorrei usare *Entity* *Framework* ma ci sto pensando 
(certo aiuta per la doppia piattaforma) perché adesso lo uso ma lo vedo 
un po' macchinoso
- *MEF* e *unity* pensavo di no ma mi riservo ancora un po' di analisi
- per la gestione dei sorgenti (se non usano già altro ma non ho 
verificato) all'inizio anche nulla ma poi un *SVN* (tortoise) ci vorrà 
per forza
- come metodologia sono "nativamente" (nel senso che leggendola ho 
trovato che molti punti già li seguivo senza saperlo) vicino 
all'*AGILE* ma più verso il pratico che verso il "didattico"
 
Boh, ti ho scarrellato un po' di cose buttandole lì... vorrei prima del 
21/08 mettere ordine proprio per chiarire il tutto e vedere se tutto 
può funzionare :D


- per la gestione dei sorgenti (se non usano già altro ma non ho 
verificato) all'inizio anche nulla
 
Eh?!
 
- come metodologia sono "nativamente" (nel senso che leggendola ho 
trovato che molti punti già li seguivo senza saperlo) vicino
all'*AGILE* ma più verso il pratico che verso il "didattico" 
 
Cioè non hai mai lavorato in un contesto agile.

 per forza
 
Non avere un gestore dei sorgenti, con l'ampia scelta che si ha nel 
2017, è come spararsi sui piedi...
 
Personalmente preferisco Mercurial rispetto a Git, enbtrambi 
"distribuiti"... ma occorre verificare come sono integrati nel tuo 
ambiente di sviluppo.
 

 vicino all'*AGILE* ma più verso il pratico che verso il "didattico"
 
lol, scusa ma questa fa sorridere.
 
quello che dici non vuol dire nulla. che senso ha dire che sei 
"nativamente" vicino all'agile? i processi agile mica impongono che tu 
faccia cose strane, non pratiche o che non siano dettate dal buonsenso. 
processi come scrum formalizzano le dinamiche gestionali mica entrano nel 
merito dell'operatività pratica.

 ho verificato) all'inizio anche nulla
 
cioè hai consegne urgenti ma decidi che per ora va bene anche nulla, 
annamo bene :)
 
Comunque in bocca al lupo.
-- 
Soprano

 ma occorre verificare come sono integrati nel tuo ambiente di sviluppo
 
Il motivo per cui "inizialmente" aspetto è solo per studiarne alcuni... 
alla fine ho sempre lavorato dove usavano Tortoise...


 annamo bene :)
 
Come ho detto sopra spero che già ce l'abbiano e di usare quello...
Se non avessero nulla... beh dovrei convincere qualcuno (il capo) che 
in 30 anni non ha mai sentito (da nessuno degli sviluppatori presenti) 
di questa necessità... ok tutto ma sono nuovo e un paio di mesi potrei 
prendermeli (anche per valutare soluzioni varie): ti pare così assurdo? 
Devo anche mediare alcune cose...


 Comunque in bocca al lupo.
 
 
Se non hanno nulla saranno molto poco sensibili al tema.
 
Quando un nuovo arrivato vuole cambiare subito tutto porta di solitamente chi viene sostituito è lui.
 
Ciao
   Fracesco

 Eh?!
 
Lol. E poi caso mai SVN :D
 
Cioe' nel 2017 lui utilizzerebbe svn senza avere alcun vincolo legacy 
(come il sottoscritto)?

 alla fine ho sempre lavorato dove usavano Tortoise...
 
SVN, non Tortoise. Manco le basi.


Tortoise e' solo la GUI, e c'e' sia per git che mercurial. Minchia che 
caos che hai in testa.

 Se non avessero nulla... beh dovrei convincere qualcuno[...]i pare così assurdo? 
 
A me pare assurdo che si accetti di andare a lavorare in un posto dove non si usi nessun sistema di controllo versione dei sorgenti. Se non ne hanno mai sentito la necessita` vuol dire che hanno sempre lavorato col culo. Immagino gia` il tipo di resistenza che tu possa trovare in quell'ambiente. Poi, certo, arrivi tu e proponi SVN, nel 2017. Gran passo avanti.

 solitamente chi viene sostituito è lui.
 
Se deve lavorare in team sullo stesso codice non vedo davvero come 
possano farne a meno. Se invece lavora da solo su componenti dove mette 
le mani solo lui ci sta che possa tirare avanti finchè non rilascia la 
prima versione, da lì in poi piuttosto me ne installerei uno sul mio pc 
di lavoro.
-- 
Soprano


Scusa eh, ma vale la pena lavorare in un contesto di peracottari del 
genere secondo te?

 sentito (da nessuno degli sviluppatori presenti) di questa necessità...
 
Senza polemica, mi farebbe davvero piacere sapere come riescono a gestire 
le release, le versioni, gli hot fix e quant'altro. Ho visto usare di 
tutto in questi anni, anche cvs, ma -niente- mai, giuro.
-- 
Soprano

 Cioe' nel 2017 lui utilizzerebbe svn senza avere alcun vincolo legacy 
 
Non si e` neanche guardato attorno per vedere quali altri VCS si usino oggi, anno 2017. 
E pensa che a gente del genere danno persino incarichi di responsabilita`.
 


Rispetto a niente svn è l'eldorado, altro che passo avanti :)
-- 
Soprano


Anche noi abbiamo il vincolo di legacy, ci siamo installati git e 
mirrorato sull'svn aziendale. Non ideale, ma meglio che lavorare 
direttamente su svn. 
-- 
Soprano

 tutto in questi anni, anche cvs, ma -niente- mai, giuro.
 
Che domande! Facendo tar.gz col numero di versione nel nome del file e salvandolo in una directory sul server! Dai, su!!

 Rispetto a niente svn è l'eldorado, altro che passo avanti :)
 
Be`, si`, beati monoculi in terra caecorum, ma sempre monoculi sono :)

 genere secondo te?
 
Se sei un peracottaro - e lui evidentemente lo e` - ha senso.
 


Ci si puo' lavorare con team misto? Io svn e l'altro git (io sceglierei 
mercurial a dire il vero)?

 Se invece lavora da solo [...]
 
...gli farebbe comunque comodo un repository remoto, per esempio uno privato su Bitbucket, se proprio non vuole pagarne uno su GitHub. O magari uno su un server aziendale, se vuol tenere tutto nei confini dell'azienda.
 
 
 
 

 di lavoro.
 
 
Posso parlarti di diverse realtà, non solo nazionali, in ambito Gestionale in cui un gestore di sorgenti non viene usato.
 
Non concordo ma la realtà è spesso più complessa della teoria.
 
Ciao
  Francesco

 Non concordo ma la realtà è spesso più complessa della teoria.
 
Qui non si tratta di complessita', e' semplicemente crassa ignoranza.


Si certo, se chi usa git fa il mirror di svn con git-svn:
https://git-scm.com/docs/git-svn
 
 
Un how-to molto semplice: 
https://gist.github.com/ticean/1556967
 
-- 
Soprano

 di lavoro.
 
Io uso mercurial anche per i miei side project e ne sono super contento.
Non saprei come fare senza.
 

 Posso parlarti di diverse realtà, non solo nazionali, in ambito Gestionale in cui un gestore di sorgenti non viene usato.
 
E quindi? Di quale "teoria" parli? Perche`, dire che oggi non si puo` e non si deve lavorare senza un vcs significa essere dei teorici che ignorano la realta`? E` piuttosto il contrario.

Soprano in data mercoledì, 19/07/2017 ha detto:

Questo posso dirtelo perché l'ho fatto per un po' 2 lavori fa prima di 
introdurre un SVN. Non è complesso anche se macchinosissimo:
1. lavori in locale
2. zippi i sorgenti
3. li carichi sul server in un formato tipo: 
SWPIPPO_Al3xI98O_20170719.zip
4. chi lo userà dopo scaricherà in locale e ripeterà
 
E se lavori insieme? Fai il merge a mano prima di zippare... Su 
progetti piccoli e pochissimi sviluppatori è una merda ma fattibile, 
oltre diventa improponibile.


Soprano in data mercoledì, 19/07/2017 ha detto:

Dove sono adesso si usa SVN e siamo una società grossa, con numeri 
importanti e milioni di righe di codice... perché non dovrebbe andare 
bene SVN? Cmq non mi pongo i problemi delle resistenze: è una società 
piccola e sono arrivato per ricoprire un certo ruolo che farò valere :D


Francesco Da Riva in data mercoledì, 19/07/2017 ha detto:

Sono stato assunto (azzardo mio e loro!) per cambiare le cose, ci 
mancherebbe che non lo facessi o che non me lo facciano fare (non gli 
costo pochissimo...). Ovviamente so come trattare quindi le cose si 
fanno con calma, convincendo, collaborando e valorizzando e non 
obbligando... ho fatto di peggio in aziende più "gnucche" non credo 
sarà un problema.


Soprano in data mercoledì, 19/07/2017 ha detto:

Vedo che hai afferrato :) Per i primi mesi sarò di certo solo e 
produrrò un piccolo step del progetto sul quale lavorerò... nel mentre 
potrò guardarmi intorno e "convincere" l'uso (ma, RIBADISCO, magari mi 
sto facendo seghe mentali e già hanno...). Quasi quasi apro un thread 
dedicato a SVN dato che pare prenda :)


 Non concordo ma la realtà è spesso più complessa della teoria.
 
Ho visto cose in MICROAREA e TEAM SYSTEM che... vabbeh :P


Zarathustra in data mercoledì, 19/07/2017 ha detto:

Mercurial? Onestamente non lo conosco... però mi informerò: ho minimo 1 
mese :D


Soprano in data mercoledì, 19/07/2017 ha detto:

In realtà punterei su GIT onestamente... (lo usa un mio collega per i 
suoi progetti ma devo valutare pro e contro).



Apparte tutto il resto, la cosa che mi lascia più perplesso di questa 
procedura è la mancanza totale di history, non sai chi e quando ha 
aggiunto un pezzo di codice, quando un bug è stato introdotto, niente. 
Lavori al buio.
-- 
Soprano

 Quasi quasi apro un thread dedicato a SVN dato che pare prenda
 
:)
 
Fermatelo.


Non c'e' alcun pro e contro rispetto a svn. SVN e' semplicemente inferiore.

 Lavori al buio.
 
Non lo sai ma puoi risalire a chi è quando... certo è uno schifo e 
magari i trovi 3 o 4 zip scompattati sul desktop e fare winmerge o 
similari per capire le modifiche... anche da solo eviterei ma così era 
(ed erano 4 sviluppatori di cui 2 esterni :O).


 mese :D
 
è un DVCS simile a  git, ma con una sintassi più umana.
Lo usano in diversi ( fra cui Facebook) anche se è più di nicchia rispetto a git.

sono arrivato per ricoprire un certo ruolo che farò valere :D
 
Eh, hai voglia.
 
 
 

 E se lavori insieme? Fai il merge a mano prima di zippare...
 
Bella cagata. Senti a me, datti all'ippica.
 
 

 git.
 
La mia domanda (fatta a me stesso) è: se DAVVERO non avessero nulla mi 
toccherà l'incombenza... quindi, non essendo io certamente un esperto 
SVN, sicuramente privilegerò qualcosa per cui ci sia molto materiale 
sul web... forse git ha una marcia in più su quello?


 Rispetto a niente svn è l'eldorado, altro che passo avanti :)
 
Senza alcun dubbio, io ad esempio (che uso git) non trovo che, al di la
delle differenze inerenti il fatto che svn e' centralizzato mentre git
e' distribuito (tendo a preferire il distribuito) ci siano moltissime
differenze di flow di utilizzo.
Sicuramente in entrambi i casi ho visto git/svn usati molto male, tipo
"lippa per il codice", pull, ripulisco la cacca, commit con messaggino
inutile/insignificante, push.
Forse git pero' ha raggiunto una massa sufficiente da portare molte
persone ad adottare i git/github/gitlab flow con eventuali piattaforme,
e questo e' certamente un gran bene.
 
  ngw


Io non uso SVN credo dal 2008, ma non lo ricordo particolarmente lento o
inefficiente, e le PR sono una feature del servizio di hosting, non del
vcs in se. Non sono al 100% sicuro, ma penso che Bitbucket supporti SVN
e quindi sia possibile usare le PR.
Mai avuto nessun problema con il branching, nel senso che in git i
branch sono lightweight, ma non mi ha mai dato gran problemi.
Di contro, git usa una terminologia quantomeno bizzarra, e non ha un
client decente.
 
  ngw

ngw in data mercoledì, 19/07/2017 ha detto:

Grazie :)


 inefficiente
 
Boh, io lo uso: non è né lento, né crea grossi problemi (qui siamo più 
di 100 sviluppatori su 3 sedi con il trunk di quasi 3 milioni di righe 
e una dozzina di branches) e problemi non ne vedo...
Certo se dovessi scegliere io allora valuterò ma non pretendo certo di 
sapere tutto di tutto :)


 obbligando... 
 
Fino ad un certo punto. Bisogna sapere cosa e` negoziabile e cosa no. E l'uso 
di un vcs non lo e`. Ad un certo punto bisogna saper dire dei no e generare un 
sano conflitto. Ovviamente, tutto questo deve essere sotteso da un'esperienza e 
da una reale capacita` di guidare e cambiare le cose, che temo proprio tu non 
abbia proprio.
 

 costo pochissimo...).
 
Questo non è sempre detto: il mio vecchio capo (arrivato con contratto da dirigente, macchina aziendale, etc.) è stato costretto a lasciare dopo poco tempo perchè non gli veniva lasciato fare quello che voleva sia a livello organizzativo che su quello tecnico. Purtroppo a volte si trovano delle realtà in cui andare ad alterare certi equilibri e a toccare certi personaggi crea esclusivamente problemi. 
Fai attenzione...

 client decente.
 
Mah, questo e` opinabile. La terminologia e` piu` o meno la stessa degli altri sistemi. In quanto al client, io uso tutto integrato in IntelliJ IDEA e funziona perfettamente (anche GitFlow ha un plugin per IDEA che funziona egregiamente).
 
 
 

 crea esclusivamente problemi.  Fai attenzione...
 
Onestamente? Sono stato preso per essere a capo (sotto ad un PM) di un 
nuovo ramo aziendale e per (cito testuale) "far fare un salto di 
qualità all'azienda" (dal punto di vista mio, ovviamente).
Non farò l'errore di "stare zitto e buono", non esiste al mondo. 
Certamente non prenderò nulla di petto e userò tutta la mia capacità di 
convincere e motivare (soprattutto).
 
Ah, se l'uso di un banale SVN viene visto come "alterare certi 
equilibri" hanno proprio preso la persona sbagliata :D


 sempre "subito" l'uso di SVN.
 
E quindi? Che obiezione sarebbe? Resta il fatto che le tue conoscenze sono molto indietro.
 
 

 convincere e motivare (soprattutto).
 
Ha ha ha ha ha...

Zarathustra in data mercoledì, 19/07/2017 ha detto:

Ah scusa, forse non è chiara una cosa: qualsiasi cosa "farò" NON andrà 
a toccare il pregresso dato che il mio lavoro sarà nuovo e da zero 
(quindi, per assurdo, i vecchi sviluppatori potranno NON usare nulla se 
così sono abituati e "noi" usare GIT o similari :)). Il bello di 
formare il gruppo da zero è proprio quello: non posso avere atriti col 
preesistente perché non esiste (lo stesso PM mio capo diretto è lì da 3 
mesi per capirci...).


 > e quindi sia possibile usare le PR.
 
Ho saltato la questione delle PR. Si`, e` vero, sono una feature del servizio di hosting, ma che io sappia non c'e` un servizio di hosting per SVN che ti consenta di farlo. Comunque, come dicevi anche tu, apprezzo tutto l'ecosistema attorno a git e i vari"flow" che si possono adottare.

 branch sono lightweight, ma non mi ha mai dato gran problemi.
 
sicuramente era un limite operativo mio, ma a me il fatto di fare il 
checkout/merge direttamente nella working copy qualche problemuccio me 
l'ha dato, tipo sputtanare diverse mie ore di lavoro. mentre con un 
repository distribuito se ti arriva un'onda di merda ti metti in salvo 
facile. 
da quando siamo passati a git certi tipi di bug, nati da conflitti 
risolti (si fa per dire) alla cazzo, sono praticamente scomparsi. 

 Mah, questo e` opinabile. La terminologia e` piu` o meno la stessa degli altri sistemi. In quanto al client, io uso tutto integrato in IntelliJ IDEA e funziona perfettamente (anche GitFlow ha un plugin per IDEA che funziona egregiamente).
 
Beh, git e' partito per gestire progetti a basso livello, in modo da
permettere agli utenti piu' avanzati di fare i peggiori hack
dell'universo. Non e' un male di per se, ma sicuramente ha un costo su
tutti gli utenti che per volere o capacita' non sono tanto avanzati. Per
esempio, il client da linea di comando sembra disegnato da un
tossicomane. Ad esempio, il client da linea di comando di Mercurial e'
sensibilmente migliore.
Io non uso IDE e vado da cli, non so quanto mi sarebbe utile un client
grafico (su linux poi... metti che c'e', o non me lo portano o e' su
electron) pero' quelli che ho visto di Git sono un casino, a partire da
quello per github.
 
  ngw
 


Si quello e' una conseguenza dell'essere distribuito.
Quello che si dice dei branch svn e' che sono molto lenti, almeno questo
e' cio' che ho sentito io.
 
  ngw
 

 mesi per capirci...).
Solo un consiglio: occhio a non finire per essere visto come un corpo estraneo dal resto dell'azienda.
 
Mi sembri abbastanza scafato da saperlo.
 
Ciao
  Francesco

 convincere e motivare (soprattutto).
 
Il mio ex capo era uno che gestiva un team di 40/50 persone in più sedi, uno tecnicamente con le palle. 
è venuto nella mia ex azienda a seguito di un po' di riorganizzazioni aziendali (la sede dove era lui ha chiuso e non gli andava di spostarsi di 500 km) e con tutti i presupposti per "rivoltare l'azienda come un calzino" , "fare il salto di qualità", "organizzare i processi", etc.
 
All'inizio ci ha provato ed aveva portato anche buoni spunti.
Dopo pochi mesi, però, si è accorto di avere le mani legate perchè uno dei soci dell'azienda (quello che sembrava più smart e amichevole) era un coglione: imponeva anche in maniera violenta scelte tecniche e organizzative completamente assurde, difendeva a spada tratta la persona più ottusa, incompetente e odiata da tutti in azienda (uno che ha fatto scappare 2 sviluppatori che lavoravano con lui nel giro di 3 anni, a uno ha fatto venire un infarto e a un altro una mini depressione).
Alla fine il mio ex capo ha chiesto e ottenuto di fare un part time e di andare a fare il professore alle medie, dileguandosi sempre di più.
 
Non si sa mai a cosa si va incontro quando si cambia azienda :(

 electron)
 
Io non ho questo problema perche` uso IDEA che e` x-platform; esattamente lo stesso su Windows/Linux/OSX. 

 mesi per capirci...).
 
mah.
 
lasciami indovinare: questa azienda ha già un gestionale in cobol o qualche altra tecnologia vetusta, e stanno mettendo su un team per il classico rifacimento in tecnologie attuali.
 
ho azzeccato?
 
si spiegherebbero molte cose, dai vecchi sviluppatori che non saranno toccati dai cambiamenti al "salto di qualità" riposto su nuovi assunti che, diciamolo in franchezza, di qualità del processo di produzione software mostra di saperne poco.
 
il rischio in questi casi non è tanto quello ambientale, quanto quello del buco nell'acqua. nel giro di due/tre anni potrebbe venir fuori il problema dei costi non correttamente valutati; solitamente queste aziende hanno una percezione falsata dalla vecchia gestione, oggettivamente più elementare, e si imbarcano in queste avventure in modo sprovveduto. starei in guardia da questo.
 

 Non si sa mai a cosa si va incontro quando si cambia azienda :(
 
Sinceramente? Amen se così fosse. Ho cambiato lavoro n volte (E voi lo 
sapete bene) quindi nel caso peggiore mi faccio un po' di tempo dietro 
casa e poi vedo: solo a luglio 2017 ho trovato 2 lavori (1 accettato e 
1 ovviamente no, e poi c'è quello che ho ora) quindi... Ma sono 
convinto che non sarà minimanete come è successo al tuo "capo" proprio 
perché la realtà è a milioni di km di distanza :)


 Mi sembri abbastanza scafato da saperlo.
 
Ne ho viste e ho esperienza ma la cagata è sempre dietro l'angolo: 
occhi aperti sempre! :)


 questo.
 
Cmq non è quello il lavoro che farò dato che non c'è un vecchio e un 
nuovo ma 2 rami sw aziendali esistenti e 1 che sarà nuovo (in sinergia 
pesante col primo e in teoria poco col secondo).
