Uno stato tedesco abbandona Windows per Linux: 25 mila computer di stato passeranno all'OS open-source

[randorama]

Originariamente inviato da zappy

io direi quasi nessuno...
dipenderà dagli ambiti, ma francamente ho visto xls che usino queste funzioni molto ma molto ma molto di rado.

li invidio... a me non bastano più :-\

[zappy]

Originariamente inviato da randorama

li invidio... a me non bastano più :-\

non ho mica capito cosa....

[randorama]

Originariamente inviato da zappy

non ho mica capito cosa....

cerca.vert e pivot; oltre un certo limite diventano troppo pesanti...

[zappy]

Originariamente inviato da randorama

cerca.vert e pivot; oltre un certo limite diventano troppo pesanti...

ok.
mai capitato, ma di quante righe parliamo? 1000? 10000?

[randorama]

Originariamente inviato da zappy

ok.
mai capitato, ma di quante righe parliamo? 1000? 10000?

diciamo che 200.000 righe e una 50na di colonne comincia a essere difficile da gestire...
a quel punto volendo/dovendo gestirle con excel devi inventarti altro

[cdimauro]

Originariamente inviato da jepessen

Nessuna pelle d'oca: avevano uno strumento, lo sapevano utilizzare e hanno provato ad utilizzare le proprie conoscenze per venire incontro ad un requisito.

Excel e' ampiamente utilizzato, piu' o meno correttamente, da diversa gente che lo utilizza come piccolo database personale; ovviamente ha molti limiti, come il fatto che deve caricarsi tutto in RAM, non e' multiutente etc.. Ma se io devo fare un programmino che deve stare su un PC, e che deve elencare e fare ricerche sui libri di una biblioteca, quale sarebbe il vantaggio di installare un database, collegarsi etc, quando basta excel? E' ovvio che un database e' piu' potente, ma occorre anche capire quando la potenza serve oppure no, un po' come quelli che devono per forza usare photoshop al posto, che so, di paint.net quando l'unica cosa che fanno e' ridimensionare immagini.

E' anche vero che se tutto quello che hai in mano e' un martello tutto quello che vedi intorno sono chiodi, il che sta a dire che se sai usare solo uno strumento tenderai ad utilizzare quello anche per cose per la quale non e' adatto, ma fra utilizzare sempre lo strumento adatto ed utilizzare sempre e solo lo stesso strumento, c'e' un immenso mare di possiblita' e compromessi che vanno piu' che bene in determinati contesti, come ad esempio Excel utilizzato come database per gestire piccole quantita' di dati in singoli PC.

Se son piccole cose ci sta ed è molto comodo e veloce.

Ma l'esempio di prima era decisamente più complesso: lì si vede subito a occhio che ti serve non soltanto un database, ma un software gestionale. E' da folli pensare di operare in quel modo con Excel.

Originariamente inviato da zephyr83

non si rendono conto che in realtà così stanno spendendo ancora più soldi o meglio potrebbero risparmiarne tanti investendo un minimo. si perderebbe meno tempo a fare gli ordini e a tenere gli stock aggiornati in tutti i negozi. questi ogni anno pagano un'azienda esterna (fatta di ragazzini sicuramente pagati due soldi) per contare tutta la merce in negozio. prima lo facevamo noi del personale rimanendo tutta la notte, ora gli conviene pagare qualcuno "specializzato" per finire in poche ore.....peccato che il grosso lo facciamo ugualmente noi dipendenti (per sistemare bene tutta la merce e contare scorte e magazzino) e poi alla fine bisogna rifare un ulteriore controllo su alcuni articoli selezionati dove i conti non tornano palesemente.
ovviamente ancora non è disponibile neanche la vendita online o l'ordine dal sito con ritiro in negozio perché con un database fatto in sulla maniera è impossibile da gestire
è una realtà cresciuta troppo che ragiona ancora con una mentalità italiana anni 90!

Assolutamente d'accordo, e mi spiace che siate costretti non soltanto a lavorare così, ma soprattutto con gente che non è in grado di ragionare.

Se hai esperienza di programmazione posso consigliarti soltanto di ritagliarti un po' di tempo per automatizzare una piccola parte alla volta. Ci vorrà del tempo, ma nel lungo periodo dovresti riuscire (magari con l'aiuto di altri colleghi ad automatizzare altre parti) a buttare via quello che avete adesso.

Ho fatto così nella mia precedente azienda italiana, dove non esisteva il concetto di unit testing / TDD. Ho cominciato a costruirmi un test driver, poi un testing framework, e alla fine tutti i miei progetti erano dotati di test suite, e nessuno è mai più venuto a lamentarsi di bug o funzionalità mancanti.

Originariamente inviato da zappy

ho visto che è usato come scripting di automazione in diversi applicativi, per cui, si, prima o poi cercherò di impararlo meglio.
cmq non mi pare che esista niente di simile come completezza, facilità, possibilità di creare facilmente GUI come VBA.

Con VBA è comodo perché è tutto ben integrato.

Se vuoi provare, per Python esistono diversi toolkit grafici: c'è l'imbarazzo della scelta. Molto usato è PyQT, che è un wrapper per le Qt, oppure PySide (sempre un wrapper per QT), ma ormai tutto è confluito in Qt for Python.

Comunque spendici un po' di tempo per imparare Python, perché ormai te lo ritrovi ovunque. E vedrai che ti piacerà pure, una volta che c'avrai fatto la mano.

Originariamente inviato da randorama

diciamo che 200.000 righe e una 50na di colonne comincia a essere difficile da gestire...
a quel punto volendo/dovendo gestirle con excel devi inventarti altro

Database: senzadubbiamente!

Avendo anche una 50ina di colonne, avrai il tuo bel da fare anche a normalizzare il database, creando le apposite tabelle e loro relazioni.

Non mi sembra un progetto banale, insomma.

Ma senz'altro Excel NON è lo strumento adatto.

[randorama]

Originariamente inviato da cdimauro

Se son piccole cose ci sta ed è molto comodo e veloce.

Ma l'esempio di prima era decisamente più complesso: lì si vede subito a occhio che ti serve non soltanto un database, ma un software gestionale. E' da folli pensare di operare in quel modo con Excel.

Assolutamente d'accordo, e mi spiace che siate costretti non soltanto a lavorare così, ma soprattutto con gente che non è in grado di ragionare.

Se hai esperienza di programmazione posso consigliarti soltanto di ritagliarti un po' di tempo per automatizzare una piccola parte alla volta. Ci vorrà del tempo, ma nel lungo periodo dovresti riuscire (magari con l'aiuto di altri colleghi ad automatizzare altre parti) a buttare via quello che avete adesso.

Ho fatto così nella mia precedente azienda italiana, dove non esisteva il concetto di unit testing / TDD. Ho cominciato a costruirmi un test driver, poi un testing framework, e alla fine tutti i miei progetti erano dotati di test suite, e nessuno è mai più venuto a lamentarsi di bug o funzionalità mancanti.

Con VBA è comodo perché è tutto ben integrato.

Se vuoi provare, per Python esistono diversi toolkit grafici: c'è l'imbarazzo della scelta. Molto usato è PyQT, che è un wrapper per le Qt, oppure PySide (sempre un wrapper per QT), ma ormai tutto è confluito in Qt for Python.

Comunque spendici un po' di tempo per imparare Python, perché ormai te lo ritrovi ovunque. E vedrai che ti piacerà pure, una volta che c'avrai fatto la mano.

Database: senzadubbiamente!

Avendo anche una 50ina di colonne, avrai il tuo bel da fare anche a normalizzare il database, creando le apposite tabelle e loro relazioni.

Non mi sembra un progetto banale, insomma.

Ma senz'altro Excel NON è lo strumento adatto.

il database sotto è su un sql server e ha (centinaia di) tabelle con qualche decina di milioni di righe sotto.
il "coso da 200.000 righe" è il risultato minimo che è stato richiesto dal committente.
diciamo che il cerca.vert diventa troppo pesante e bisogna inventarsi qualcosa d'altro

[andy45]

Originariamente inviato da randorama

il database sotto è su un sql server e ha (centinaia di) tabelle con qualche decina di milioni di righe sotto.
il "coso da 200.000 righe" è il risultato minimo che è stato richiesto dal committente.
diciamo che il cerca.vert diventa troppo pesante e bisogna inventarsi qualcosa d'altro

Da matematico ignorante in programmazione di database e simili direi che la strada migliore è quella di ridurre il problema, se il database è diviso in sezioni richiami ogni volta solo la parte che ti serve e vai a modificare solo quella...in modo da richiamare solo porzioni, così da limitare l'uso della memoria il più possibile.
Per deformazione professionale farei tutto in C/C++, da riga di comando, insomma niente interfaccia grafica, sprechi memoria e basta.

[randorama]

Originariamente inviato da andy45

Da matematico ignorante in programmazione di database e simili direi che la strada migliore è quella di ridurre il problema, se il database è diviso in sezioni richiami ogni volta solo la parte che ti serve e vai a modificare solo quella...in modo da richiamare solo porzioni, così da limitare l'uso della memoria il più possibile.
Per deformazione professionale farei tutto in C/C++, da riga di comando, insomma niente interfaccia grafica, sprechi memoria e basta.

be... devi anche metterti nei panni dell'utenza, che è la più variegata possibile. (e che in alcuni casi la pivot non la fare)
poi è abbastanza evidente che (spero) ognuno si ritaglia la sua fetta di righe e di colonne e si lavora quella.
oh.. io lego l'asino dove vuole il padrone

[andy45]

Originariamente inviato da randorama

be... devi anche metterti nei panni dell'utenza, che è la più variegata possibile. (e che in alcuni casi la pivot non la fare)
poi è abbastanza evidente che (spero) ognuno si ritaglia la sua fetta di righe e di colonne e si lavora quella.
oh.. io lego l'asino dove vuole il padrone

Si si per carità, sennò poi chi li sente .

[zappy]

Originariamente inviato da randorama

diciamo che 200.000 righe e una 50na di colonne comincia a essere difficile da gestire...
a quel punto volendo/dovendo gestirle con excel devi inventarti altro

e io che mi ricordavo che excel si fermasse a 64000 e rotti...
Si vede che l'hanno "allungato" in qualche release
hmm si, in effetti non sembra il territorio in cui dà il meglio...

Originariamente inviato da cdimauro

Se vuoi provare, per Python esistono diversi toolkit grafici: c'è l'imbarazzo della scelta. Molto usato è PyQT, che è un wrapper per le Qt, oppure PySide (sempre un wrapper per QT), ma ormai tutto è confluito in Qt for Python.

Comunque spendici un po' di tempo per imparare Python, perché ormai te lo ritrovi ovunque. E vedrai che ti piacerà pure, una volta che c'avrai fatto la mano.

in effetti lo vedo spesso associato a roba fatta in Qt...
grazie x info

[randorama]

Originariamente inviato da zappy

e io che mi ricordavo che excel si fermasse a 64000 e rotti...
Si vede che l'hanno "allungato" in qualche release

da quando si è passati a xlsx le righe sono diventate 2^20 e e le colonne 2^14

poi va da sè che se ti allarghi in una dimensione non puoi farlo nell'altro.

come dice il mio collega
"bambino alto e magro va bene, basso e grasso va bene, alto e grasso NON va bene"

[zappy]

Originariamente inviato da randorama

da quando si è passati a xlsx le righe sono diventate 2^20 e e le colonne 2^14

poi va da sè che se ti allarghi in una dimensione non puoi farlo nell'altro.

come dice il mio collega
"bambino alto e magro va bene, basso e grasso va bene, alto e grasso NON va bene"

ah, quindi da oltre 10 anni... sono aggiornatissimo

ps: spero che il tuo collega non abbia figli e/o non si occupi del loro menu

[WOPR@Norad]

Originariamente inviato da cdimauro

E lo si fa.

Mai sentito parlare di ingegneria inversa e patch di binari?

L'uso di ingegneria inversa e disassemblatori, a parte non essere sempre permesso dalla licenza d'uso, è qualcosa di molto più complicato e che si usa solo se non ci sono alternative.
Per darti un paragone di ordine pratico, la differenza che c'è tra analizzare un sorgente e fare ingegneria inversa è come quella che ci sarebbe organizzando un viaggio leggendo una guida lonely planet e parlando con il cane dell'autore della guida.

[cdimauro]

Originariamente inviato da WOPR@Norad

L'uso di ingegneria inversa e disassemblatori, a parte non essere sempre permesso dalla licenza d'uso, è qualcosa di molto più complicato e che si usa solo se non ci sono alternative.
Per darti un paragone di ordine pratico, la differenza che c'è tra analizzare un sorgente e fare ingegneria inversa è come quella che ci sarebbe organizzando un viaggio leggendo una guida lonely planet e parlando con il cane dell'autore della guida.

So benissimo cos'è e i costi (ho fatto anch'io ingegneria inversa diversi anni fa).

Ciò non di meno, e come già detto, lo si fa lo stesso: come pensi vengano trovate tante falle nei binari di applicazioni closed? E come pensi vengano crackati i software e, in particolare, i giochi?

[zappy]

Again.
Linux + LO + altri sw (postali, active dir e telefonia IP) migrano all'open source
https://blog.documentfoundation.org/...o-libreoffice/
https://www.schleswig-holstein.de/DE...eitsplatz.html

anche per questo motivo
https://www.dday.it/redazione/48732/...-microsoft-365


ps: hwup sta proprio sul pezzo...