UE social network vietati ai minori di 16 anni - BUFALA

fonte immagine

---

Leggo stamani la notizia che l'U.E. vorrebbe proibire social network & co. ai minori di 16 anni.

Non entro nel merito della questione eta' (oltretutto e' pure una bufala), non e' questo il punto. Gia' adesso i social network americani (facebook - eta' minima) devono imporre un'eta' minima di 13 anni. Com'e' altresi' un dato di fatto che molti utenti hanno meno di quest'eta'.

Il fatto e' che questi limiti lasciano un po' il tempo che trovano per due semplicissimi punti:

Punto uno: territorialita':

Il social network rispetta le Leggi vigenti nel Paese dove ha la sede, molti social network sono americani ed e' per questo che impongono un'eta' minima di 13 anni. Quindi un'eventuale normativa europea non avrebbe impatto su un social network "estero". E' il concetto di territorialita', valgono le Leggi dello Stato dove l'azienda risiede...

Punto due: autocertificazione:

Non c'e' una verifica, l'utente autocertifica di avere piu' di 13 (16, 18, 21, millemila) anni. Come si puo' intuire, e' facile mentire in un caso o nell'altro. Non cambierebbe niente... Chi si vuole iscrivere non ha altro che da fare $ANNO_CORRENTE - $ETA'_RICHIESTA_PER_ISCRIVERSI (o farlo fare alla calcolatrice di windows) e mettere una spunta ed il giochino e' fatto...

Quindi come abbiamo visto sopra il divieto non e' affatto obbligatorio ne' potrebbe esserlo visto che l'UE non ha giurisdizione al di fuori dell'UE, e per il poco che ne so gli stati membri devono recepirne le normative affinche' queste entrino in vigore (quindi anche se fosse, dovrebbe esistere un social network con la sede in uno Stato membro, e questo dovrebbe recepire la normativa UE prima che questa entri in vigore), e terzo com'e' aggirare la limitazione dei 13 anni e' altrettanto facile aggirare quella dei 16...

Per tanto l'unica difesa valida sono i genitori che controllino ma sopratutto educhino i figli ad un comportamento responsabile. Come insegnate a vostro figlio ad attraversare la strada, che e' pericoloso e ci sono le macchine, allo stesso modo dovete educarli all'utilizzo di internet. A non divulgare dati personali a nessuno, che e' facilissimo falsificare la propria identita', che come non bisogna parlare con sconosciuti "fisici" non bisogna nemmeno parlare con sconosciuti virtuali.

Per approfondire: vi rimando a due articoli del buon Paolo Attivissimo:

• sexting e minori, facile finire nei guai
• Le guide ad Internet della Prevenzione Svizzera della Criminalita'

Alla prossima!

antibufala fast: bollo alle bici

l'articolo e' stato riscritto dopo la pubblicazione iniziale

Il popolo della rete indignato perche' il senatore filippi vuole mettere il bollo alle bici. Ma come al solito il senso comune difficilmente capisce quello che e' vero, ma solo quello che gli interessa capire.

Infatti la richiesta originale del senatore e' un po' diversa.

Il testo originale del ddl #1638 e' qui. La modifica voluta dal sen. Filippi e' questa aggiunta (grassetti miei) un’idonea tariffa per i proprietari: 1) delle motoslitte, disciplinandone le caratteristiche costruttive e funzionali, nonché la circolazione con un apposito contrassegno identificativo, documenti di circolazione e di guida e l’assicurazione per la responsabilità civile verso terzi; 2) delle biciclette e dei veicoli a pedali adibiti al trasporto, pubblico e privato, di merci e di persone [...]

Quindi almeno a me, che pure non sono un burocratese, mi pare chiaro che dal testo della Legge si vogliano si' tassare le bici ma solo quelle adibite al trasporto di merci e di persone.

Poi che tassare le bici sia una manovra scema e anti-ecologica e' verissimo, ma se bisogna dirla tutta bisogna dire che Filippi non ha proposto di tassarle tutte, ma solo alcune. Anche se avrebbe fatto meglio a lasciare perdere...

Perche' il complottismo lunare e' una stronzata galattica

fonte immagine

---

Prova 1:

Brevissima lezione di storia per contestualizzare il momento in cui avvennero: piena guerra fredda. Gli USA e l'URSS si fronteggiavano in tutti i modi possibile, e anche se non arrivarono mai allo scontro diretto si fecero guerra "di traverso" (corea & co). Quindi se ci fosse stata la possibilta' di sputtanare la credibilita' dell'avversario agli occhi del mondo l'avrebbero fatto, e come se l'avrebbero fatto.

Prova 2:

Non c'erano solo i russi ma non so quante migliaia di astronomi in tutto il mondo, se l'apollo non fosse mai andato sullo spazio (o se avesse fatto un giretto senza passare dalla luna) se ne sarebbero accorti tutti non solo i russi...

Prova 3:

E' impossibile tenere nascosto un complotto. Qualcuno prima o poi parla (vedi Snowden) - ne parlo qui

Prova 4:

Le prove sono talmente tante e talmente evidenti che sarebbe stato impossibile fabbricarle tutte.

Prova 5 quella finale:

I campioni prelevati dagli astronauti non hanno origine terrestre (sono fatte di materiale che non si trova qui sulla terra). Quindi qualcuno e' andato materialmente su a raccoglierle. Mi scuso se il link e' in inglese, ma la en.wiki e' molto piu' affidabile della nostrana.

Repubblica passepartout

Chi glielo dice a Repubblica che si scrive Passepartout?

HIbernate criteria - mini tutorial

Questo post non vuole essere esaustivo nei confronti dei criteria, vuole essere una mini-guida per chi si approccia per la prima volta a questo strumento.

La creazione di un criteria

Hibernate gestisce autonomamente il criterio di sessione e transazionalita' (quindi effettua suo sponte commit&rollback). Per utilizzare i criteria quindi avete bisogno che il vostro ambiente vi fornisca una sessione (di hibernate). Un Criteria si crea chiedendolo all'istanza della sessione che avete in mano e invocando il metodo "createCriteria" e passandogli come parametro la classe dell'entity sulla quale volete effettuare query.

Il metodo list()

Una volta fatto questo potete iniziare a fare query su quella tabella. Se volete tutti gli elementi potete fermarvi qui ed invocare direttamente il metodo list() del criteria. Questo metodo restituisce una List di Object per cui o fate un cast o la lasciate cosi' com'e'. Questo metodo si invoca quando il criteria (e quindi la query) puo' restituire piu' di un oggetto.

Il metodo uniqueResult()

Se invece siete sicuri che il risultato sara' unico (p.e. una count o state andando per id) allora c.uniqueResult() e' quello che fa per voi. Restituisce un object quindi dovrete fare un cast per ottenere la vostra entity.

Aggiungere condizioni

Se non si potessero aggiungere condizioni i criteria servirebbero a ben poco, no? Ecco che la classe Restrictions viene in nostro aiuto. invocando il metodo add del criteria da voi creato potete passargli una Restriction in maniera statica (quindi Restrictions.qualcosa). Che sara' eq se volete l'uguaglianza, analogamente lt/gt se minore/maggiore stretto e le/ge se <= / >= divertitevi ad esplorare tutte le possibilita' di Restrictions ce ne sono un sacco (in + lista etc).

Projections

Analogamente il metodo setProjections del criteria vi permette di aggiungere una "proiezione" - ovvero di modificare la select. Analogamente alle restrictions tutto quello che vi serve e' nella classe Projections. Per esempio .rowCount() vi restituira' un unico risultato contentente un numero con il totale delle righe per quella tabella .property(String property Name) vi permette di effettuare la select di un'unica colonna e cosi' via

La comodita' dei criteria

Rispetto ad altri strumenti (come la Query di hibernate) il criteria ha di comodo che genera automaticamente la query necessaria ad estrarre i dati e quindi il codice e' molto piu' compatto e leggibile, soprattutto se non sappiamo se i parametri del metodo ci verranno passati tutti. Un semplice if ci permette di aggiungere al criteria la restriction solo se il parametro e' valorizzato (evitando per esempio il doppio if delle query, uno per mettere la condizione e uno per valorizzare il parametro). Inoltre riducendo la quantita' di codice scritte minimizza il rischio di errori. Hibernate (e non solo i criteria) trasforma il tipo di dato su db in quello dell'entity. Quindi se su db c'e' un varchar (ma con un numero dentro) perche' il dba non e' un dba voi potete dichiararlo come Integer/Long/che vi pare e hibernate ve lo trasformera'. Analogamente potete farci una count o una sum. Inoltre usando criteria/hql che vengono convertiti da hibernate nel dialetto del db che si sta usando, rende il codice indipendente dal database, permettendo di cambiare db se necessario, semplicemente aggiornando il file persistence.xml

Non e' tutto oro quello che luccica

Per contro non hai il controllo diretto di quello che il framework sta facendo, a volte gli errori possono non essere significativi (ho avuto di recente un "where condition not found where expected" dovuto ad un (ok erano due!) nome di colonna sbagliato nell'entity - ma me ne sono accorto soltanto quando ho modificato il metodo per far eseguire ad hibernate una query sql e poi trasformare il result set derivante in entity. Inoltre ci sono cose che hibernate non gestisce bene (una per tutte le union). O le select di un substring ('pippo' = substring(x,y) di una certa colonna).

Come gia' detto questo articolo non e' per niente esaustivo, e' un primo approccio (veloce) ai criteria. Quando ho tempo approfondiro'

Alla prossima!

Laika eroe spaziale

---

Questo lo screenshot di un link che circola su facebook.

Laika e' stato il primo essere vivente ad andare nello spazio. Non era mai stato fatto prima. Non c'erano dati sui quali fare studi, non c'erano campioni. Non c'era niente. Era stato lanciato un satellite (lo Sputnik) ma non era vivo.

Sinceramente mi sembra naturale che sia stata scelta una cavia prima di mandare un essere umano. Forse all'autore dell'articolo no, e avrebbe preferito essere mandato lui (o chiunque consideri un animale piu' importante di un essere umano). Ma checche' ne pensino gli animalisti l'uomo non e' un semplice animale. Nessun animale sa parlare o pensare o esprimere concetti complessi. Magari loro non si sentono superiori, ma lo siamo. Nessun animale progetta e costruisce macchinari complessi, nessun animale accende il fuoco o cucina.

Usare una cavia, per quanto brutto possa essere uccidedere un animale innocente, e' necessario. Serve per vedere se una certa cosa e' fattibile, serve per avere dei dati e dei campioni di studio. Vi propongo un ottimo articolo di Medbunker a riguardo della sperimentazione animale - leggetelo.

L'esplorazione spaziale non serve solo per vantarsi davanti agli altri Paesi (ed effettivamente con lo sputnik e il lunik l'URSS acquisi' effettivamente un bel po' di prestigio), ma tutte le ricerche che servono per mandare l'uomo nello spazio hanno poi ripercussioni sulla vita sulla terra. Servono inoltre ad avere delle conoscenze dirette del cosmo. Servono a farci sentire piccoli

fonte immagine

---

Servono a darci la giusta misura di quello che siamo. Servono a farci capire che la Terra e' un'isola nel cosmo, e quindi checche' ne dicano gli animalisti/ambientalisti l'esplorazione spaziale giova alla loro causa, perche' aiutano le persone a rendersi conto che la Terra e' l'unica che abbiamo e che se la distruggiamo non ci rimane nient'altro.

Quindi Laika e' un martire, avrebbe preferito vivere? Sicuramente. Era innocente? Senza dubbio. Ma il suo sacrificio e' servito per fare un passo avanti. Laika e' morta perche' noi potessimo vivere meglio. Grazie al sacrificio di Laika l'umanita' ha imparato qualcosa di piu' sull'esplorazione spaziale. Orribile ma necessario.

Sinceramente trovo molto piu' "disumano" l'atteggiamento di chi preferisce sacrificare un essere umano ad un animale.

Se volete approfondire: a che serve andare nello spazio di Paolo Attivissimo

Alla prossima!

java quando usare un pojo e quando le entity

Premessa: stiamo parlando di un contesto in cui c'e' un framework di persistenza nel mezzo se si usa sql e result set il discorso perde di validita'.

Premessa 2: per qualche ragione non c'e' una relazione tra gli oggetti che ficchiamo nel bean

La entity ha il vantaggio di tirare l'oggetto fuori dal db in maniera relativamente veloce ma dall'altro lato se devo visualizzare dati provenienti da piu' entity peggiorano la leggibilita' del codice.

Un pojo ha il vantaggio che tutti i dati vengono da lui ma deve essere "trasformato" e quindi richiede dell'elaborazione in piu'.

Se si tratta di poche righe puo' valerne anche la pena ma se son tante il tempo richiesto per trasformarle in pojo puo' essere tanto.

Come regola generale e' sempre bene limitare il numero di dati da "trasportare" quindi cercando di forzare l'utente ad immettere dei parametri di ricerca
ma se le righe continuano ad essere tante usero' le entity per dare una panoramica generale per poi costruire un pojo nel momento un cui l'utente clicca per accedere al dettaglio...

[Aggiornamento 13/10/2017]

Il discorso di cui sopra e' tutto molto bello, ma non tiene conto di un fatto: hibernate fa un fottutissimo accesso al db ogni qualvolta si fa una set/get/new di una entity questo produce: a) un overhead clamoroso di accessi al db non necessari (il dato ce l'hai gia' oppure non e' detto che se fai il set tu lo voglia salvare davvero in quel preciso istante) b) hibernate gestisce con una $PARTE_POCO_NOBILE gli accessi concorrenti, per cui o ti usi una sequence (o un altro dato univoco) oppure se usi il generic generator e due persone in contemporenea creano una nuova entity avranno lo stesso id con una conseguente primary key violation e non e' esattamente bello.

Quindi se avete un hibernate "vecchio" cazzi vostri e vi dovete gestire il mapping su un pojo a manina, se avete un hibernate piu' nuovo (o JPA) se lo puppa lui con il mapping ma in soldoni mai mai MAI lavorare con le entity...