Newsgroup: it.lavoro.informatica
Titolo: Scusate ma in ottica aziendale

chi stabilisce le librerie da usare.
oppure lo sviluppatore a capocchia sceglie quelle che piacciono di piu.
 
Esempio
 
import java.text.SimpleDateFormat;
import java.util.Calendar;
import java.util.Date;
import org.apache.commons.lang.time.DateUtils;
 
ovvero 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
a capocchia o c'è una logica ?
 
 
 
 
-- 
Non mi fido di una cosa che sanguina per cinque giorni e non muore.
( Mr. Garrison )

 a capocchia o c'è una logica ?
 
quelle non sono 4 librerie, ma 4 classi!
 


e poi se anche fossero librerie non ha nessuna importanza,
quelle istruzioni sono semplici dichiarazioni per poter
utilizzare nomi corti invece di nomi lunghi.
 
 
 

 a capocchia o c'è una logica ?
 
Cazzate a parte che scrivi: il programmatore decide.
 
-- 
Al3xI98O
«L'importante non è cadere, ma sapersi rialzare»

 ovvero 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
ovvero 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
gia in 4 che si sono misurati su chi ce l'aveva piu lungo, e questo solo 
per trattare una data, figuriamoci per trattare cose piu serie.


 utilizzare nomi corti invece di nomi lunghi.
 
come ho gia detto piu volte i programmatori java non capiscono un cazzo, 
gli devi spiegare le cose 4 volte, gli mancano proprio le basi, 
altrimenti una rispostaa come la tua non sarebbe mai stata scritta


 trattare una data, figuriamoci per trattare cose piu serie.
 
Giuro che prima o poi capirò quel che scrivi


 
 
 
ma non ho capito, questo lo dici in generale o soltanto riferito
alla gestione delle date?
 

 «L'importante non è cadere, ma sapersi rialzare»
 
beh dipende da azienda e da che applicativo è, ci sono programmatori anche che sviluppano solo moduli e quindi sono vincolati su certe scelte.

 gli devi spiegare le cose 4 volte, gli mancano proprio le basi, 
[cut]
 
Hai ragione, una cosa però  l'ho capita : 'te ne devi anna affancuuuuulo'.
 
ps: Sono un programmatore giava
 
 

 ha scritto:

Sicuramente si riferiva al fatto che il programmatore ha libero
arbitrio su tutto il codice, quindi anche negli import di librerie.
 
 

 che sviluppano solo moduli e quindi sono vincolati su certe scelte.
 
Diciamola così: il programmatore decide in base all'ambiente in cui sta 
lavorando. Ovviamente se lavoro in un progetto dove si usa A userò A... 
decido io nel senso che non ho (e non ho mi nè visto nè sentito) guide 
che mi indicano cosa usare...
 
Poi nel 99% dei casi fai proprio come vuoi: ho lavorato su sw 
gestionali "grossi" e si apiva benissimo che moduli diversi erano fatti 
da persone diverse proprio per quello che usavano...


 arbitrio su tutto il codice, quindi anche negli import di librerie.
 
Esattamente. Ovviamente col limite di essere "compatibile" con lavoro 
preesistente e/o altre persone del team e/o interazioni varie.


kojak in data mercoledì, 16/12/2015 ha detto:

Che scrive cazzate in maniera generale :D Sulle date l'ho preso come 
esempio generale della libera scelta del programmatore ovviamente col 
limite di essere "compatibile" con lavoro preesistente e/o altre 
persone del team e/o interazioni varie.
 


 diverse proprio per quello che usavano...
 
Non pensi che sia una follia questa cosa????
 

 kojak  ha scritto:

ma cosa dici??
Non è affatto vero.
 
Il programmatore non ha affatto libero arbitrio sul codice.
Nel senso, solitamente viene chiesto di usare determinate librerie,
di rispettare determinati standard.
Poi ovviamente questo non significa che debba scrivere il codice
sotto dettatura, è chiaro che un minimo di libero arbitrio c'è,
ma nella maggiorparte dei progetti vi sono comunque degli standard
da rispettare nell'implementazione del codice.
 
Non so su che progetti lavori tu, ma su quelli che sviluppo io
è così.

 da persone diverse proprio per quello che usavano...
 
Beh ma ad esempio per loggare ognuno sceglie la propria libreria di logging o centralizzate la cosa (e quindi il programmatore si deve adeguare alla scelta)?
 

 è così.
 
Per evitare ulteriori flame, se non ti fidi di quello che ho
scritto, spero che ti fiderai di ciò:
 
"Dentro i confini del computer, sei tu il creatore. Controlli   almeno
potenzialmente   tutto ciò che vi succede. Se sei abbastanza bravo, puoi essere
un dio. Su piccola scala."
 
Linus Torvalds
 
 

 ha scritto:

Ma non devi dirlo a lui, devi dirlo a chi ha "gestito" quei sw gestionali
"grossi" ;-)
 
 

 a capocchia o c'è una logica ?
Intanto le librerie utilizzate nel tuo esempio non sono 4 ma solo 2, di 
cui una (rt.jar) non la si puo' evitare perche' fa parte del runtime java.
La libreria commons-lang.jar e' abbastanza comune, utilizzarla o meno ha 
come unico scopo quello di non riscoprire ogni volta l'acqua calda. Tra 
l'altro essendo protetta dalla licenza Apache, non pone nemmeno limiti 
di utilizzo.
In definitiva, la tua domanda e' mal posta e fa trasparire l'ignoranza 
in materia di chi la pone, se mai ce ne fosse stato bisogno.
 
Mi rendo anche conto che essendo che in cobol le date, intese come tipo 
dati, non esistono, ti puo' essere sembrato strano. Ma in realta' 
trattare le date e' un'operazione complessa, proprio per i multiformi 
aspetti che una data puo' assumere. Ad esempio, trattare una data 
gregoriana e una data lunisolare (come nel calendario ebraico) 
riconducendole ad un unico orario definito nello spazio, nel tempo e 
nella storia con implicazioni culturali, in cobol potrebbe essere 
parecchio complesso (valuto non meno di 10000 righe di codice), in java 
c'e' appunto il tipo Calendar, che riduce i gradi di liberta' 
semplificando enormemente i conti limitando il codice a poche righe.
 


E' come dici tu senz'altro, ma nella fattispecie, le date (tanto per 
tornare alle argomentazioni dell'op), mi sembra non ci siano tanti 
standard diversi da rispettare.

 è così.
 
uhm, altri tipi?


ciccio in data mercoledì, 16/12/2015 ha detto:

Quoto in pieno!


FP in data mercoledì, 16/12/2015 ha detto:

DECISAMENTE sì. Ecco perchè ho precisato "nei limiti di bla bla bla"


Diego in data mercoledì, 16/12/2015 ha detto:

SE esiste si usa la stessa (ma questo a prescindere) se non esiste 
scelgo io (*) quale e come usare.
 
(*) di norma ci si confronta in realtà...


ciccio in data mercoledì, 16/12/2015 ha detto:

Mah... "ho visto cose..."


 semplificando enormemente i conti limitando il codice a poche righe.
 
ma ,lo vedi che sei un saccente di merda?
In informatica si usano solo 2 calendari, il gregoriano e il giuliano, 
quello ebraico al quale tu ti riferisci viene usato solo in ambito 
religioso o teologico. La formulazione di quel calendario non passerà 
mai tra i byte di un computer.
SEI PROPRIO UN SACCENTE DI MERDA.
DIO CI LIBERI DAI SACCENTI! CAZZO!


 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
comunque su questo concetto nessuno ha sviluppato una discussione, il 
che dimostra che non avete la piu pallida idea di cosa sia sviluppoare 
bene, rispettando logiche aziendali.
ma la cosa assunrda è che nemmeno vi fermate a riflerre che esistono 
librerie ridondanti e che probabilmente nessuna delle 4 ha uno sviluppo 
completo in grado di coprire tutte le casistiche in un trattamento date.


 mai tra i byte di un computer.
Hai detto la tua ennesima cazzata, da superficiale supponente quale sei.
Come se l'informatica trattasse solo di bolle e fatture.
Inoltre se parlo di "orario definito nello spazio, nel tempo e nella 
storia con implicazioni culturali" intendo che anche nei casi piu' 
semplici, anche utilizzando il calendario gregoriano, lo stesso orario, 
inteso come istante nel tempo, in due fusi orari distinti viene 
rappresentato con due date diverse, e con i tuoi PIC 9(7) COMP-3 col 
cazzo che indichi una data certa.
Ti posso garantire che chi tratta su mercati internazionali, includendo 
quello cinese, col cazzo che fa capire le date gregoriane ai cinesi.
 

Delta11 in data mercoledì, 16/12/2015 ha detto:
 
MA non te ne eri andato alle 14.06?



sono d'accordo, infatti la mia obiezione non è sulle date,
ma sull'approccio lavorativo in generale, che non è affatto
vero che il programmatore può fare quel cavolo che gli pare,
perché così traspariva dal post di ciccio.

 In informatica si usano solo 2 calendari, il gregoriano e il giuliano
 
Quindi una libreria che supporta un calendario alternativo è di per sè considerata un paradosso dell'informatica?
 

 a capocchia o c'è una logica ?
 
in ambito Java accade spesso di trovare classi da packages
diversi che fanno più o meno le stesse cose e ognuno può
scegliere se usarle e quali usare oppure se nessuna di queste
lo soddisfa, scriverne di proprie. Questione di mentalità!
 
Ma tu coglione non puoi capire... ho visto un programmatore COBOL
tenere segretissima una ridicola routine per stampare gli importi
in lettere... una discreta testa di cazzo! Forse eri proprio tu!
 
 
 


 
 
Sono 4 classi non librerie.
Le prime 3 sono di sistema ed i progettisti hanno preferito fare 3 
classi invece che una
Avranno avuto le loro ragioni.
La 4 è di apache fundation, qui chissà perchè avranno voluto farsi una loro.
Ma nel mondo open è cosi,quanti framework esistono per gestire 
particolari funzionalità,classi che non fanno parte della lib std?
Basti pensare ai framework per gestire GUI in C++ (ce ne sono a decine) 
o per l'accesso ai database.
 
 
 


Come al solito la tua superficialita' corredata da un quantitativo 
industriale d'ignoranza non ha pari. Ho il sospetto che l'unica 
accezione che conosci del verbo riflettere si quella riferita agli 
specchi (di fatto non sai neanche scriverlo bene, usi "riflerre").
Secondo te da 4 include (che non sono 4 librerie) si puo' capire quale 
sia l'ambito e se ci sia qualche ridondanza?
Poi spiegami qual e' la logica aziendale secondo la quale una data 
espressa in qualsiasi parte del mondo debba essere considerata allo 
stesso modo.
Mi viene il dubbio che tu non abbia mai comprato un biglietto aereo, 
dove le date di arrivo e di partenza sono espresse nell'orario locale 
dei relativi luoghi di arrivo e di partenza. E ti posso garantire che 
non c'e' compagnia aerea che non utilizzi un computer per fare i biglietti.
 

 perché così traspariva dal post di ciccio.
 
Diciamo che all'interno di un dominio di opzioni è giusto che il 
programmatore si muova come meglio crede... a volte ho potuto scegliere 
pure il linguaggio in cui fare alcuni programmi. Ovvio che se scrivo un 
modulo all'interno di un altro programma userò strumenti già in essere 
ma mai nessuno mi ha "obbligato" a farlo: risulta naturale.
 
In esempio decido io se usare un for o un while, se usare un int, un 
bool, un enum o cos'altro per gestire alcuni tipi di dato... spesso 
anche se mostrare alcuni dati all'utente con list o combo...


 mai tra i byte di un computer.
Tutto cio' che segue sono classi java, e come tali passano *solo* tra i 
byte di un computer (esen):
IslamicCalendar is a subclass of Calendar that that implements the 
Islamic *civil and religious* calendars.
ChineseCalendar is a concrete subclass of Calendar that implements a 
traditional Chinese calendar.
DangiCalendar is a concrete subclass of Calendar that implements a 
traditional Korean calendar.
HebrewCalendar is a subclass of Calendar that that implements the 
traditional Hebrew calendar.
CopticCalendar implements the Coptic calendar system.
IndianCalendar is a subclass of GregorianCalendar that numbers years 
since the birth of the Buddha.
etc.etc.

 standard diversi da rispettare.
 
ci sarebbe una libreria esterna (joda) decisamente più pratica e che
è molto utilizzata al posto della gestione date delle api java, ma non
vorrei mi andasse in paranoia l'op.
 
ad ogni modo nei progetti che io gestisco non è che chiunque può aggiungere
dipendenze a suo piacimento...
 

rootkit in data mercoledì, 16/12/2015 ha detto:

Ecco sulle dipendenze già merita un discorso a parte rispetto alla 
libertà di movimento... ma di norma se ne parla e se c'è un 
responsabile o anche solo sviluppatore senior avrà diritto di "veto". 
Io son sempre stato il "capo" (anche quando non sarei dovuto esserlo) 
ma non ho mai limitato il lavoro dei "sottoposti": certo che non 
pootevano dirmi "adesso uso DevExpress" perchè è un po' esagerato :D



Effettivamente.
A tal proposito, se guardi in un altro post, ho citato classi calendar 
che vengono da icu (International Components for Unicode) che e' una 
libreria che mi ritrovo spesso in certi prodotti che mi capita di 
utilizzare (quindi il problema delle dipendenze da aggiungere non si 
pone proprio), ad esempio DB2, Lotus, Websphere, Tivoli, Rational, AIX, 
i/OS, z/OS, ioC, Android. Senza contare i vari wrapper (tra cui anche 
python, perl e php)


AH AH AH AH AH AH NO NON ERO IO
quella routine è da pirla tenerla segreta è riportata su qualsiasi 
manuale di cobol AH AH AH AH
 
HAI RAGIONE SONO UN COGLIONE!


 
 
 
sì, questo certamente, ma da qui a dire che il programmatore
ha libero arbitrio su tutto ce ne passa...
 

 ha libero arbitrio su tutto ce ne passa...
 
Come hai visto di libertà ne ho sempre avuta :)



Vabbe'. Ciccio ha riportato, una citazione di Linus Torvalds, forse a 
sproposito in quanto non mi risulta che LT lavori in "ottica aziendale" 
o lo abbia mai fatto.
In seconda battuta, spesso si fa fatica, almeno io, a capire i post di 
Ciccio, figurati se si puo' capire cosa ne possa trasparire!
:-))

 ovvero 4 librerie per trattare una data quando ne basterebbe una fatta bene
 
Hai toccato purtroppo un tasto dolente di Java: la gestione delle date. 
Ma per fortuna Java 8 viene in soccorso:
http://www.oracle.com/technetwork/articles/java/jf14-date-time-2125367.html
 
 

 :-))
 
;-))
 
 

 ha scritto:

Molto interessante.
 
 
 

 "Una parola è troppa e due sono poche" [cit.]
CVD