Java - leggere tutti i file di una directory e scriverne il contenuto su file

Stessa identica cosa dello script in perl solo in java. Ho usato delle librerie esterne (per il log) e qualche classe in piu' (di utilita' etc).

Se non avete voglia di rileggervi i requisiti erano questi: La richiesta e' questa: leggere un x numero di files (non specificato) la cui estensione non e' nota e buttare tutto su un unico file. Inoltre e' richiesto di non metterci troppo tempo negli sviluppi e non c'e' richiesta di raffinatezze grafiche o robe cosi' (aka seghe mentali).

Di conseguenza ho eliminato del tutto l'interazione con l'utente (salvo un file di log)

---

---

Tre packages. Forse possono sembrare un eccesso per un progetto cosi' piccolo, ma fidatevi non e' cosi'. Avere una buona organizzazione mentale, e' fondamentale per tenere in ordine nei progetti, e questo e' indifferente che il progetto abbia 3 classi o 3000. Deve essere un processo automatico. Cosi' come i commenti. I packages:

• file: contiene le classi che si occupano dei file, in questo caso chi legge/scrive
• main: contiene la classe che esegue materialmente il codice (il main)
• util: contiene le classi di utilita'

La Classe FileManager

Si occupa di leggere e scrivere i file, ha 4 metodi:

• getListFile(file): che restituisce tutto quello che contiene la directory passata come parametro
• readFile(File): legge il contenuto di un file e lo restituisce sotto forma di lista di stringhe
• writeFile (String, List): legge il contenuto di una lista di file (passata come parametro e li scrive in un nuovo file (il cui nome e' passato come parametro)
• write(BufferedWriter, List): usa un buffered writer passato come parametro per scrivere la lista passata (questo consente di scrivere piu' file in un unico stream e chiudere suddetto stream solo alla fine

La Classe EntryPoint

C'e' poco da dire, prende il path locale e lo passa al file manager, inoltre logga (come info) i vari file scritti e gli eventuali errori (come error) usando gli appositi metodi della classe LoggingUtil

La Classe LoggingUtil

ha 3 metodi statici.

• getLogger(): per avere un'istanza del logger - se il log e' null lo istanzia perima di restituirlo
• info(String): scrive la stringa come info
• error(String, Throwable): scrive un error con il messaggio e lo stacktrace

A proposito di getLogger(): usa un basic configurator per prendere caricare il file log4j.properties, e' necessario usare un file appender da dare in pasto al log, altrimenti non avrete alcun file.

La Classe Utility

Non c'e' molto perche' non mi serviva molto, ho due metodi

• formatDate(Date, String): formatta la data in stringa usando il pattern specificato
• getActualTime(): prende la data attuale e formatta prendendo solo ora minuti e secondi separati da :

Il progetto Java e' piu' complesso, a parita' di risultato, e anche piu' pesante in termini di dimensioni (400KB rispetto ai 2 del perl) e anche di prestazioni. Ma ha il vantaggio che quasi tutti hanno una JRE installata e ha la possibilita' di crescere se viene creata un'interfaccina in swing per chiedere quali file mergiare e dove salvare il file mergiato (e come chiamarlo). Ma questo viene meno ai principi di semplicita' e velocita' di svilluppo che erano stati richiesti.

Perl - leggere tutti i file di una directory e scriverne il contenuto su file

---

Oggi niente Java, oggi perl. (Si non vi preoccupate l'ho fatto anche in java, solo che mi ispirava farlo anche in perl, visto che manipolare file e' la sua specialita' per cui vi propongo prima questo e poi quello).

La richiesta e' questa: leggere un x numero di files (non specificato) la cui estensione non e' nota e buttare tutto su un unico file. Inoltre e' richiesto di non metterci troppo tempo negli sviluppi e non c'e' richiesta di raffinatezze grafiche o robe cosi' (aka seghe mentali).

Di conseguenza ho deciso di ignorare totalmente l'input utente, lo script prende in considerazione la directory dalla quale viene eseguito, legge tutti i file ad eccezione di quelli che finiscono in jar, log, perl e che cominciano per "mergedFile" (che e' quello di output) e scrive tutto in un file che si chiama mergedFile_data(ora).txt. Inoltre produce un file che si chiama mergedFileLog_data(ora).log dove scrive i vari file letti (giusto per avere un riscontro di averli letti tutti)

---

Un po' di dettagli:

use Cwd; Cwd e' una libreria per ottenere il path corrente e poi lo infilo in $dir my $dir = getcwd

@months = qw( Gen Feb Mar Apr MaG Giu Log Ago Set Ott Nov Dic ); creo un array col nome dei mesi nel mio caso in italiano... my ($sec,$min,$hour,$mday,$mon,$year,$wday,$yday,$isdst) = localtime(); inizializzo un po'di variabili da localtime

my $file_to_write = "mergedFile_$year$months[$mon]$mday($hour$min).txt"; my $log_to_write = "mergedFileLog_$year$months[$mon]$mday($hour$min).log"; creo altre due variabili una per il file da scrivere e una per il log

#apro la directory da leggere opendir(DIR, $dir) or die $!; #apro il file da scrivere (in append) open(my $fh, '>>', $file_to_write) or die "Could not open file '$file_to_write' $!"; #apro il log da scrivere (sempre in append) open(my $log, '>>', $log_to_write) or die "Could not open file '$log_to_write' $!"; apro il tutto (o muori)

nel doppio ciclo scansiono la directory corrente per ogni file while (my $file = readdir(DIR))
salto se non e' un file next unless (-f "$dir/$file");
salto se inizia per mergedFile o finisce per jar, log o pl
next if ($file =~ m/^\mergedFile/ || $file =~ m/\.jar/ || $file =~ m/\.log/ || $file =~ m/\.pl/);

scrivo sul log il file che sto leggendo e lo apro say $log "leggendo: $file\n"; open (INPUT, $file) || next print "can't open $file: $!";

while (< INPUT >) { chomp; # appendo $_ sul file say $fh "$_"; } leggo il file e lo scrivo sull'altro

Se vi interessa eseguire perl:

• Su linux e' nativo
• Su windows potete scaricare strawberry perl da qui

Se vi interessa un editor perl (oltre a npp o gedit che vanno benissimo) potete usare PADRE

Adolf Heusinger e il nwo

---

Non metto link per non regalare visibilita' alla pagina. E' proprio vero che come dice BUTAC moltissimi non si prendono nemmeno la briga di andare a verificare le fonti e condividono cosi' senza pensare. Infatti sarebbe bastata una velocissima ricerca con gurgle o su kiwipedia (tra l'altro linkata dalla bufala) per vedere che non e' esattamente come ce la raccontano.

Infatti le notizie riportate sono vere, nel senso Heusinger era nello staff di hitler e a fine carriera e' stato nominato presidente del Comitato militare della NATO a Washington (cito sempre kiwipedia). Ma Heusinger non era nelle SS ma nella Wehrmacht In secundis ha partecipato all'organizzazione dell'attentato a Hitler (vi erano prove di contatti tra Heusinger e molti dei congiurati) Terzo ha testimoniato a norimberga.

Non facciamo di tutta l'erba un fascio, non basta essere tedesco o militare per essere automatimente un nazista, Rommel non lo era (si rifiuto' sempre di consegnare i prigionieri di guerra ebrei come avrebbe voluto hitler), Stauffenberg non lo era.

Il post "bufaloso" vuole farvi trarre delle conclusione errate (cioe' che a capo della NATO ci siano dei nazisti), ma come abbiamo visto basta indagare 5 minuti per scoprire che c'e' poco da indignarsi, Heusinger era tutto tranne che nazi.

Alla prossima!

Twitter rimuoversi dalle liste

fonte immagine

---

Twitter ha introdotto le liste
il problema e' che non sei tu che ti aggiungi ad una lista esistente (es. le community) ma e' il creatore della lista che ci aggiunge la gente.

Quindi io posso creare una lista "pedofili riuniti" o "stupratori di capre in via frattina" e aggiungerci tutta la gente che mi passa per la mente (anche chi non sto seguendo) e non e' esattamente bello...

Quello che mi sarei aspettato sarebbe stato esattamente l'opposto, che uno crea una lista un gruppo o una community e poi chi vuole si aggiunge. Fattosta' che adesso ti sei ritrovato in una lista e non ne vuoi fare parte. Come si fa ad uscirne? Ari-molto-simpaticamente twitter non offre strumenti per uscire da una lista. La soluzione pero' e' molto semplice, come suggerisce askaaronlee ovvero bloccare l'utente che vi ha inserito nella sua lista (se poi volete lo potete anche risbloccare, io li lascio bloccati solo per il fatto che mi hanno messo in una lista senza il mio consenso) e vi trovate automaticamente fuori dalla lista. Et voila'!

Alla prossima!

Java leggere formattazione da database

fonte immagine

---

Capita in Java, di dover generare dei file, ovviamente ogni file generato deve avere delle specifiche, per esempio un csv, nonostante la "c" stia per "comma" (ovvero virgola) puo' avere come separatore di campo qualsiasi carattere, idem per il fine riga. Puo' essere accapo (\n), ; etc.

Questo non e' un problema se scrivete direttamente nel codice, il che non e' un problema se le specifiche non cambiano mai. Siccome le specifiche cambiano, e le mamme invecchiano, e' bene parametrizzare questi valori e pescarli da qualche parte.

Questo qualche parte puo' essere un file o un database, il problema che si presenta e' lo stesso. Ovvero che java non riconosce o lo "\" e quello che lo segue come un terminatore di riga, ma lo tratta come se fosse un letterale (quindi \\n p.es). Anche se provate in unicode il problema rimane esattamente lo stesso (visto che c'e' \ davanti...).

La soluzione ce la offre Apache con StringEscapeUtils scaricabile da qui con il metodo statico StringEscapeUtils.unescapeJava(String) il quale ci restituisce la stringa "escapata" per java. La classe ne contiene altri ovviamente sia di escape che unescape, per csv, html, sql, xml etc...

Alla prossima!

Java metodi che restituiscono piu' oggetti

C'e' un buon motivo per cui un metodo dovrebbe restituire UN solo tipo. Ma potreste trovarvi nella situazione di dover mettere le mani su un metodo fatto da qualcun altro, p.es che inserisce una riga a db e restituisce una ricevuta (e la usa per mandarla a frontend). Voi dovete fare delle modifiche e prendervi che ne so l'id della riga inserita.

Hibernate avrebbe un comportamento carino, cioe' i metodi save/updaterestituiscono l'id inserito/updatato il metodo save restituisce l'id della riga inserita. Ma il vostro metodo restituisce qualcos'altro e quel qualcosa serve.

a) andate a db e vi rifate una query con tutti gli altri dati e pregate che sia proprio quella che vi serve (in piu' avete il rallentamento dovuto al fatto di riandare a db per niente)

b) modificate il metodo in modo da restituire una mappa: in questo modo non avete bisogno di andare a db una volta di troppo, siete sicuri che quell'id e' proprio quello che volete, non aggiungete rallentamenti e avete tutto quello che vi serve. Ovviamente nei commenti specificate quali chiavi avete usato per mettere cosa, in modo che il povero cogl programmatore che viene dopo sapra' come ripescarseli. Ovviamente avete come effetto collaterale che tutte le chiamate a quel metodo andranno modificate.

c) create un terzo metodo che restituisce una mappa: vantaggi gli stessi di sopra con in piu' il fatto di non dovere modificare tutti i punti del codice ma solo quello dove vi serve a voi.

Telecamere nelle scuole - perche' non servono

fonte immagine

Ennesimo caso di una maestra che picchiava i bambini. E' successo a Pisa stavolta e la maestra e' stata arrestata (notizia da Il tirreno). Il caso e' deplorevole e non dovrebbe mai succedere. Parlo da genitore, e probabilmente se succedesse a me sarei il primo ad andare a dare fuoco alla maestra, perche' i piu' deboli non si toccano.

Ma non e' questo il senso del post. Come al solito c'e' chi sull'onda dell'emozione propone le telecamere nelle scuole. Io sono contro e vi spiego il perche' sono giunto a questa conclusione ragionando.

Punto primo: le telecamere non sono un deterrente

Le banche hanno le telecamere eppure vengono rapinate lo stesso. Anzi i rapinatori lo sanno e si coprono il volto. Risultato? Le rapine vengono fatte lo stesso e i rapinatori non li identifichi ugualmente. Quindi le telecamere servono a prevenire i furti?
NO.

Punto secondo: i costi

Questa fonte ne riporta c.ca 29000 tra pubbliche e private in tutta Italia. Prendiamolo per buono. Calcoliamo che per "coprire" una scuola ci vogliono 10 telecamere (e son poche). Una telecamera da videosorveglianza costa c.ca 180€ (ma puo' arrivare fino a 700, ma prendiamo il prezzo piu' basso). Per coprire quelle 29000 scuole servirebero 290000 telecamere. Moltiplicato per i 180€ a telecamera fa 52'000'000€ CINQUANTADUE milioni di euro.

Ora da noi le scuole non hanno nemmeno i soldi per comprare le salviette per pulirsi la bocca quando i bambini vanno a mensa. Siamo sicuri di voler spendere cinquanta milioni di euro per qualcosa che non serve da deterrente?

Punto terzo: la giustizia funziona lo stesso senza, anzi meglio

Se nonostante che le telecamere non ci siano nelle scuole questi casi vengono fuori lo stesso, vuol dire che le forze dell'ordine riescono lo stesso a fare il loro dovere. Anzi ci riescono meglio per il semplice fatto che, una volta ottenuto il mandato dal Giudice, possono piazzare delle telecamere nascoste. Il fatto che l'indagato non sia consapevole che ci sono fa si' che si comporti naturalmente e possa venire "inchiodato" dalla testimonianza video. Se sapesse di essere sorvegliato semplicemente fingerebbe davanti alle telecamere, per poi "sfogarsi" dove le telecamere non possono vederlo e quindi addirittura sarebbe peggio.

Punto quinto: il numero di reati rispetto al numero di scuole

Abbiamo detto che le scuole sono c.ca 29000, mentre il numero di reati e' esiguo.

Conclusioni

Ribadisco picchiare i bambini e' una cosa che fa incazzare non ci sono mezzi termini. Il problema e' che non dobbiamo farci prendere dall'ira nel prendere certe decisioni. Dobbiamo analizzarle a mente fredda. Chiedere un provvedimento come le telecamere in ogni scuola sarebbe uno spreco assurdo di soldi, soldi che potrebbero essere spesi per esempio in pennarelli e tutte le altre cose che noi genitori dobbiamo continuamente portare affinche' i nostri figli possano fare lezione. Non servirebbe ad evitare i reati, anzi aiuterebbe questi delinquenti perche' consapevoli della presenza delle telecamere saprebbero come premunirsi.

Rimanete lucidi. Alla prossima!