martedì 24 febbraio 2015

Regole del blog


Rispetto

  • Rispetto: questa è la parola chiave. Rispettare gli altri e le loro idee.
  • opinione e dato di fatto: un'opinione e' qualcosa di indimostrabile (es. il rosso è meglio del verde). Un dato di fatto e' qualcosa di incontrovertibile e dimostrato/dimostrabile (es l'acqua è composta da due molecole di idrogeno e una di ossigeno). Nel primo caso si rispetto per tutti, nel secondo rispetto per solo cio' che e' vero e dimostrato/dimostrabile tale.
  • Le affermazioni richiedono prove e/o fonti: A meno che non sia un qualcosa di comunemente accettato (v. l'esempio dell'acqua precedente).
  • L'onere della prova spetta sempre a chi fa l'affermazione: se non è possibile dimostrarne la falsità (tipo dimostrare la falsita' delle scie comiche) allora la teoria non è verificabile. Per essere verificabile una teoria deve essere falsificabile (ovvero devo poter dimostrare che e' falsa). Quindi se affermo che la sostanza X ha un certo effetto, al momento del test questa sostanza o ha quell'effetto o non lo ha. Quindi o è vera o è falsa...
  • Offese gratuite: non verranno tollerate da nessuno
  • Minacce: idem con segnalazione alla Postale
  • Se non vi piace un argomento: non siete obbligati a leggere, se discutete civilmente e quello che dite e' vero non verrete mai bannati, ma se proprio non vi piace quello che penso (es. windows e' una m...a e i capi progetto andrebbero crocifissi come pubblico monito) andate pure da un'altra parte, internet e' tanto grande...
  • Niente spam: la pubblicita' non interessa a nessuno, tantomeno a me. Se volete pubblicizzare il vostro sito o il vostro $MERDAVIGLIOSO prodotto esistono tanti altri modi e tanti altri posti. Sicuramente non qui.
  • Divertitevi: e non prendetevi(/mi) troppo sul serio...

lunedì 16 febbraio 2015

Code re-abuse

Il titolo è preso di qui

Il riutilizzo del codice non è una cosa sbagliata di per sé, purché venga fatto sotto certe condizioni. La prima della quale è che si usano i metodi degli oggetti e non si fa copia_e_incolla. In questo modo si centralizzano le funzioni delle quali si ha più bisogno, si facilità la manutenzione (la correzione di un bug si propaga immediatamente) nonché la riusabilità e la manutenibilità (se uso nomi significativi ho alte probabilità di trovare il punto di codice che fa quello che sto cercando). Il secondo caso invece propaga bug e rende dificile/impossibile manutenere il codice perché ci sono n punti da correggere (dove n è il numero di volte che questa funzione viene usata, e quindi più è usata più casino diventa).

ovviamente se devo creare un progetto ex-novo non posso usare gli oggetti dell'altro progetto a meno di non linkarlo come dipendenza (oppure di usarlo come libreria). Cosa che sconsiglio caldamente in quanto di solito l'altro progetto fa tutt'altro. Quindi o si crea una libreria (.jar) con le funzionalità che servono, e si mantiene aggiornata quella, oppure si prendono le classi che ci servono e si reimportano nel progetto nuovo.

La prima soluzione è applicabile se le classi fanno tutto quello che ci serve e solo quello. Ma se devono fare anche altro o cose diverse, quesa soluzione non è immediatamente applicabile.

Sorvoliamo sul fatto che il progetto sl quale sto lavorando è scritto abbondantemente alla ca%%@ in quanto il sedicente programmatore deve aver letto questo, inoltre si è pure impegnato per fare peggio, ma se inizio ad elencare tutto quello che è stato fatto di sbagliato non ne usciamo piu'.

Comunque sia cos'ha fatto il nostro? Ha preso tutte le classi del progetto vecchio (si TUTTE!!!) e le ha infilate nel progetto nuovo (anche quelle che non servivano a niente). Poi ha riutilizzato gli oggetti senza cambiarne il nome quindi ti ritrovi ad avere classi e metodi con nomi assolutamente non significativi...Riuso del codice o riabuso del codice?

venerdì 13 febbraio 2015

Java calcolo di fattoriale

Definizione di fattoriale

Allora innanzitutto cosa vuol dire n! (n fattoriale)?
vuol dire n * n -1 * n -2 ... * 1

Ci sono due modi di calcolarlo:

  • Ricorsivamente
  • Iterativamente

Iterativamente

In soldoni si decrementa il parametro finché non vale 1. Ovviamente la condizone del ciclo è su quel parametro (è buona norma di programmazione che non esistano cicli infiniti e di conseguenza che sia la condizione del ciclo a determinare la sua terminazione, e non attraverso un if/break* che tra l'altro è indice di pessima programmazione, così come l'abuso di continue, ma ne parlerò un'altra volta).
*Il break su cicli infiniti, non il break in se', che in determinate circostanze e' giusto utilizzare

Ricorsivamente

La cosa più interessante è un metodo ricorsivo, ovvero un metodo che invoca se stesso fino a quando non raggiunge uno schema predefinito che ne determina il ritorno. In questo caso la condizione è che il parametro valga 1. Se il parametro non vale uno si invoca il metodo passandogli come parametro quello ricevuto decrementato di uno.

martedì 3 febbraio 2015

Phishing - ti piace vincere facile?


Le tecniche di phishing diventano sempre più sofisticate, poi ogni tanto ti imbatti in cose così amatoriali da fare quasi sorridere...

Per carita' nulla da eccepire sullo stile, e' quasi uguale a quello di google, peccato che:

  1. Google non invii comunicazioni riguardo a mail danneggiate (ma manco gli altri mail provider)
  2. Il mittente non sia nemmeno appartenente ad un dominio google (cavolo si possono falsificare lo sapevi?)
  3. i vari link non puntano a mail.google.com (si può effettuare il mascheramento dell'url non sapevi nemmeno quello?)

In questo caso bastava pochissima attenzione, comunque come al solito mai fidarsi di una mail anche se sembra attendibile, mai fidarsi di un link in una mail e soprattutto se volete verificare che il vostro account sia apposto, andate sul browser e digitate a mano l'indirizzo...