Author Archives: admin

Come Configurare Apache per l’Invio delle Mail

14 Apr, 2018
admin
No Comments

Dunque, se siete arrivati su questa pagina, state sicuramente progettando o comunque vi sarà già capitato, di imbattervi nella creazione di uno script di invio email in automatico… Inviare automaticamente email con php è possibile grazie alla funzione nativa mail descritta abbondantemente nella guida ufficiale del php e utilizzata da tutti gli script di più alto livello presenti in rete.

Potrebbe capitarvi che PHP non sia correttamente configurato per l’invio delle email e che quindi tutti i tentativi di eseguire il vostro script correttamente, falliscano miseramente e senza darvi troppe spiegazioni. Questo perchè PHP di default ,non effettua la configurazione del “modulo” sendmail, necessario per l’invio dell’email da PHP.

Eccovi una breve descrizione di come configurare il server web Apache per l’invio di email dagli script php sviluppati localmente, l’approccio di risoluzione è il medesimo sia che ci si trovi in ambienti Windows che Linux/Unix.

Per tutti gli utenti linux/unix effettuare una ricerca del comando sendmail:

luca@lincelnx:~$ locate /sendmail
/home/luca/.ies4linux/ie6/drive_c/windows/system32/sendmail.dll
/usr/lib/sendmail
/usr/sbin/sendmail
/usr/share/gnome-pilot/conduits/sendmail.conduit
/usr/share/man/man8/sendmail.8.gz
/usr/share/perl5/Mail/Mailer/sendmail.pm

Prendiamo come buoni tutti i risultati contenuti nelle cartelle dove risiedono i binari

/usr/sbin o usr/bin (varia da sistema a sistema)

Gli utenti di Microsoft Windows non devono effettuare questo passaggio in quanto l’invio di email avviene grazie alla configurazione integrata di So/Outlook e account utente.

Individuare il file php.ini e aprirlo per modificarne la configurazione.

Per gli utenti Linux/Unix individuare con una ricerca testuale il sendmail_path e settarlo correttamente e in modo esteso es:

; For Unix only. You may supply arguments as well (default: “sendmail -t -i”).
sendmail_path = /usr/sbin/sendmail

Per gli utenti Windows settare il proprio account locale di posta elettronica in modo che php riesca a utilizzarlo per l’invio delle email.

[mail function]
; For Win32 only.
SMTP = localhost
smtp_port = 25

; For Win32 only.
sendmail_from = luca@webeng.it

Salvare il file, riavviare Apache ed effettuare un test del vostro script di invio.

Spero vi sia stato utile.

Aspect Oriented Come Paradigma di Sviluppo Software

14 Feb, 2018
admin
No Comments

Nel mondo dello sviluppo software la programmazione orientata agli oggetti è un paradigma di programmazione introdotto alla fine degli anni ‘60 con il Simula e seguito negli anni ‘70 da Smalltalk. In seguito è diventato il paradigma dominante ed oggi i linguaggi più usati che supportano l’Object Oriented sono C++, Java, Delphi, Python, C#, Perl.

I due più conosciuti ambienti di sviluppo, Java e .NET, si fondano proprio sul paradigma ad oggetti.

Tutto ciò però non significa che non sia possibile andare oltre l’oggetto e le sue regole di vita, dall’incapsulamento all’ereditarietà, dal polimorfismo all’implementazione di interfacce. In questo articolo voglio infatti parlare di un altro tipo di paradigma che in realtà non è propriamente “altro” rispetto alla Programmazione Object Oriented, diciamo che ne estende alcuni concetti osservando la problematica dello sviluppo software da un altro punto di vista.

Bisogna ora focalizzare l’attenzione su due termini piuttosto generali: “aspetti” e “questioni”. Soffermiamoci sul secondo termine: le questioni. Ora come termine italiano dice poco, in realtà in inglese si parla di “concerns” che è una parola difficilmente traducibile mantenendo inalterato il concetto proprio. Il verbo inglese “to concern” (concernere) significa – appunto – “qualcosa che riguarda qualcos’altro”, se vogliamo riportare tutto nell’ambito dello sviluppo software, possiamo pensare al codice che stiamo scrivendo come a quel qualcosa che riguarda l’esecuzione di alcune funzionalità richieste.

Ci stiamo appunto avvicinando alla questione. Il nostro programma ha quindi dei requisiti funzionali, deve fare qualcosa, in realtà spesso deve fare molte cose; tutte queste cose, se le si guardano bene, possono però essere raggruppate in varie categorie, ognuna di queste categorie può essere vista come una “macro-questione”, cioè una macro-funzionalità.

Questo è il primo passo da cui è nato tutto: cercare di vedere un programma come un contenitore di questioni (o caratteristiche, funzionalità, comportamenti) ognuna delle quali ben definibile e quindi ben separate l’una dall’altra. Questa separazione delle questioni (SOC, Separation of Concerns in inglese) è nata come risposta alla manutenibilità di un programma: se fosse possibile separare nettamente i vari comportamenti di un programma, diventa più facile poi intervenire su un singolo comportamento.

Banale tutto ciò: sono almeno 30 anni che si sviluppa software in questo modo. In realtà non è così banale in certi particolari ambiti: non sempre suddividere i comportamenti di un programma tramite l’uso di oggetti è possibile; ci sono alcuni di questi comportamenti che hanno bisogno di particolari accorgimenti per potere essere definiti e separati da tutto il resto.

Prima di procedere ad un esempio vediamo il secondo termine: aspetto. In realtà bisognerebbe ripetere quanto detto sopra per spiegare anche questo termine. Il motivo di averlo usato deriva dal fatto che il paradigma di sviluppo di cui stiamo parlando si chiama AOP: Aspect Oriented Programming (Programmazione Orientata agli Aspetti) ed è quel paradigma di sviluppo che tende a separare le “questioni” non tramite oggetti, bensì tramite aspetti.

Facciamo un esempio: classicamente l’esempio che si fa quando si parla di AOP è la transazione. Una delle questioni che spesso devono risolvere i programmi che scriviamo è quello di tenere traccia delle transazioni (ad esempio su base di dati) ognuna composta da una serie di operazioni atomiche che però devono essere annullate tornando allo stato precedente se solo una di queste fallisce facendo fallire a sua volta la transazione stessa. Se ci fate caso spesso si parla di aspetto transazionale, indicando con questo il fatto che esiste un ben preciso ambito di operatività del programma che deve gestire le transazioni.

Se l’obiettivo è quello di separare questa funzionalità da tutto il resto in modo che sia facilmente mantenibile ci si accorge che non è poi così immediato. In un’architettura classica in cui abbiamo tutta una serie di oggetti di business che si occupano di tutte le operazioni a livello di DB, facilmente potrebbero essere coinvolti decine di questi oggetti, ognuno tramite la sua operazione particolare. La tanto decantata manutenibilità dell’aspetto transazionale va a farsi benedire: la transazione è spalmata su tutti questi oggetti e verificare dove ad esempio si celasse un bug diventa un’impresa veramente ardua.

Ma si potrebbe fare un altro classico esempio, quello del logging: durante la vita di un programma c’è quasi sempre bisogno di fare un log, ma le fonti di log sono gli oggetti stessi, quindi la funzionalità di logging delle nostra applicazione viene spalmata su tutte le classi che abbiamo realizzato. Modificare in un secondo momento le modalità di log di un’applicazione significherebbe modificare molte classi. Esistono oggi vari framework che facilitano lo sviluppo delle sopracitate funzionalità (facendo riferimento al logging per esempio come non citare Log4j).

Questi esempi servono ad illustrare come alcune questioni (ed ecco che ritorna questo termine) centrali delle nostre applicazioni, spesso per loro natura sono spalmate su tutta l’applicazione, e cercare di separarle in un ben preciso ambito non è così facile: ognuno degli oggetti coinvolti deve, nei propri metodi, contenere codice in grado di gestire il suddetto problema; si viene così a creare, nella stesura del codice, una ridondanza non necessaria. Inoltre gli oggetti modificati a tale scopo diventano più complessi e quindi diminuisce la manutenibilità del programma.

Quindi parliamo di AOP. L’Aspect Oriented Programming nasce con lo scopo di risolvere problemi di questo tipo. Gli aspetti modellano le problematiche trasversali agli oggetti stessi, ossia compiti che nell’ OOP tradizionale sono difficilmente modellabili. Ma AOP non deve essere utilizzato come il prezzemolo una volta che se ne diventa pratici, come in tutte le cose il troppo stroppia e va sempre valutato bene quando usarlo o meno.

AOP cerca di risolvere le problematiche di cui sopra tramite appunto gli aspetti (l’aspetto della gestione delle transazioni, l’aspetto del logging, ma anche l’aspetto della gestione della sicurezza, ecc.): il modello utilizzato è quello dei “punti di connessione” (o JPM: Join Point Model). Questo modello definisce tre concetti:

i punti di connessione (Join Points) ossia i punti del codice dove l’aspetto in oggetto interagisce con il resto del programma, cioè dove l’aspetto viene richiamato ed applicato;
una metodologia per selezionare una serie di punti di connessione: in generale una sorta di motore di query che permetta di specificare dei criteri per selezionare solo una parte di tutti i punti di connessione specifici dell’aspetto in oggetto; l’insieme dei punti di connessione risultanti dalla query viene chiamato “pointcut” (difficilmente traducibile, letteralmente sarebbe “punto di taglio”);
un modo per incidere sul comportamento del programma una volta richiamato l’aspetto: questo è il fine ultimo di AOP e cioè poter influenzare il programma di base a seconda delle condizioni. In genere questa interazione dell’aspetto sul programma viene detto “advice”, traducibile con “notifica” o più letteralmente “avviso”.
Il fine ultimo di AOP (quindi di ogni framework che offre AOP) è quello di offrire un metodo per iniettare i vari advice, propri di ogni aspetto, nel programma di base tramite i punti di connessione; tutto ciò ovviamente al fine di poter influire sul comportamento del programma di base (questo metodo viene detto “weaving” che potremmo tradurre come “intrecciatura”, quindi AOP offre il metodo di intrecciare gli aspetti con il programma di base). I vari framework che offrono AOP si differenziano soprattutto sulle modalità di implementazione pratica del weaving sollevando a volte dubbi sul fatto che sia veramente AOP e non piuttosto un surrogato.

Il risultato di AOP, se prendiamo gli esempi proposti prima, è quello di poter definire dei “moduli” (gli aspetti) di logging o di gestione della security, e di iniettarli nel programma di base tramite alcuni punti di connessione, in modo da poter influenzare l’esecuzione di quest’ultimo. Poter definire dei moduli in qualche modo separati aumenta notevolmente la manutenibilità di questi perché evita che questi vengano spalmati sull’intera applicazione, ma va anche nella direzione di una maggiore separazione in componenti.

Un programma aspect-oriented quindi, è costituito essenzialmente da due insiemi di costrutti: gli aspetti e gli oggetti. Gli aspetti sono delle entità esterne agli oggetti che osservano il flusso del programma generato dalle interazioni tra oggetti, modificandolo quando opportuno o aggiungendo nuove funzionalità. Se paragonassimo gli oggetti a degli attori, potremmo dire che gli aspetti sono degli spettatori, cioè delle entità che osservano le azioni in corso nel programma senza esservi direttamente coinvolti, ma degli spettatori un pò particolari, visto che in determinate circostanze salgono sul palcoscenico e partecipano alla rappresentazione.

In definitiva l’AOP complementa l’OOP iniettando codice in punti ben precisi di un’applicazione per aggiungere comportamenti addizionali ad un oggetto in modo dinamico: gli advice possono essere applicati prima, dopo e intorno al joinpoint, e a volte è anche possibile “decorare” un oggetto con azioni a run-time senza impatti per l’oggetto decorato. Il bello di tutto questo è che il sistema alterato con gli Aspect è totalmente inconsapevole della loro esistenza: un comportamento del genere ricorda molto ciò che fanno i virus: inseriscono tra le istruzioni di una applicazione un’istruzione di salto alla prima linea di se stessi, ed alla fine mettono un altro salto al punto del codice che avevano interrotto; in questo modo nessuno può accorgersi di nulla ma il comportamento del programma è così alterato. Ovviamente tutto ciò fa capire quanto sia potente la programmazione Aspect Oriented, e come bisogna saperla dosare ed utilizzare per non combinare disastri nelle applicazioni.

Ma non è tutto oro quel che luccica: se AOP rende più semplice l’architettura e la strutturazione di un’applicazione, di contro può rendere il debug un vero inferno in quanto a run-time può diventare molto difficile seguire la sequenza delle istruzioni quando i punti di connessione diventano molto numerosi.

Programmazione – Singleton Design Pattern

14 Dec, 2017
admin
No Comments

Il Singleton fa parte della famiglia dei pattern creazionali e ha, come principale scopo, quello di garantire che una determinata classe venga istanzanziata una e una sola volta, fornendo così ai client un punto di accesso globale ai suoi metodi e attributi.

La sua applicabilità è circoscritta a tutte quelle circostanze in cui serve disporre di un oggetto comune accessibile in contesti (scope) diversi. La conseguenza immediata dell’applicazione del pattern è quella di predisporre un unico costruttore privato che impedisca l’istanziazione diretta della classe, ma piuttosto, lasciare che questo avvenga tramite un metodo getter che funzionando in modalità lazy restituisca un istanza della stessa mediante l’utilizzo di un attributo privato interno alla classe.

Programmazione – Builder Design Pattern

14 Oct, 2017
admin
No Comments

Il Builder, ovvero il “costruttore” (da non confondersi con il metodo), è uno dei principali design pattern formalizzati dalla gang of four e si occupa di separare la costruzione di un oggetto dalla sua rappresentazione, in modo che il processo di costruzione degli oggetti sia in grado di creare molteplici rappresentazioni dello stesso.

Lo scopo dell’applicazione del design pattern Builder, è principalmente quello di separare il processo di creazione di un oggetto complesso dal flusso applicativo del client. Seguendo questa logica, si realizza una doppia astrazione: da una parte si rende indipendente il flusso di creazione e controllo di un oggetto dal client, dall’altra, l’algoritmo per la creazione di un oggetto è indipendente dalle varie parti che lo costituiscono e da come esse vengono assemblate.

Il design pattern Builder si rende applicabile quando
è necessario costruire un oggetto step by step
è auspicabile isolare il processo di creazione e rappresentazione di un oggetto
è necessario monitorare le fasi del processo di creazione
Queste sono le principali conseguenze dell’applicazioni del pattern:

Isolamento delle classi che costituiscono le parti (step): come già detto in precedenza, seguendo questo pattern, si isolano e si rendono indipendenti dall’algoritmo di creazione dell’oggetto, le classi deputate all’implementazione delle parti che lo costituiranno.
Separazione della logica di creazione degli oggetti dall’applicazione: è lo scopo principale del pattern.

Passando attraverso il Director, verrà richiamato il Builder, l’interfaccia deputata ad assemblare le varie parti dell’oggetto da creare la quale, a sua volta, delegherà al ConcreteBuilder il lavoro vero e proprio, definendolo nei suoi aspetti e tenendone traccia. Il Product, l’oggetto finale che verrà costruito, conterrà al suo interno le classi che costituiscono le parti che lo compongono.

Come Collegare Pc al Proiettore

14 Aug, 2017
admin
No Comments

Quanti di voi necessitano di presentare il proprio lavoro, presentazioni, documenti e filmati ad una videoconferenza o semplicemente ad una lezione formativa? Bene in questa guida spiegheremo come collegare facilmente il nostro Notebook o Personal Computer ad un videoproiettore senza l’aiuto di un assistente tecnico.

La prima cosa da fare è posizionare il telo per la proiezione su una parete, o semplicemente scegliere una parete bianca dove posizionerai frontalmente il tuo proiettore. Bisogna posizionare il proiettore su una superficie piana regolando i bene i supporti posti inferiormente, in modo che sia in equilibrio e l’immagine non venga proiettata storta. Calcola bene le distanze tra la posizione del proiettore, Notebook e la parete.

Infatti il più delle volte ci si insorge in una situazione in cui l’immagine del nostro proiettore è troppo grande e non rientrerà nel telo, o il cavetto per collegarlo al Notebook è troppo corto per raggiungerlo nella sua postazione.Generalmente i proiettori utilizzano cavi VGA e DVI, basterà semplicemente controllare il nostro Pc se possiede una di queste due porte e collegarlo al proiettore mediante il cavo in dotazione. Ovviamente i proiettori possono offrire anche altri tipi di connettività. Per dettagli è possibile vedere questa guida sul proiettore su Sceltatech.com.

Una volta fatto questo, accendere il video proiettore e iniziare a regolare l’immagine, se necessario (fuoco,dimensione,colori,luminosità). Successivamente, bisogna impostare dal nostro PC il segnale video da proiettare. Per gli utenti windows, bisognerà aprire il pannello di controllo e scrivere nella barra di ricerca “Proiettore”, scegliere quindi “Connetti ad un proiettore”. Vedrete tante finestrelle, “Duplica”, “Estendi”, “Solo proiettore”, “Solo Computer”. Scegli l’opzione “Solo proiettore”, fatto ciò l’immagine presente nel vostro PC sarà proiettata dal videoproiettore.