Archivi tag: php

DB2: Problema di connessione con PHP PDO ODBC

Problema di connessione a DB2 con PHP PDO ODBC
Problema di connessione a DB2 con PHP PDO ODBC

Scenario di partenza

  • Attraverso la CLP di IBM DB2 o di un tool come Toad For DB2, dopo aver catalogato correttamente il database, riesco a connettermi correttamente.
CATALOG TCPIP NODE TEST REMOTE 192.168.0.1 SERVER 50000 REMOTE_INSTANCE DB2 OSTYPE LINUX

CATALOG DATABASE TEST_DB AS TEST_DB AT NODE TEST

CONNECT TO TEST USER db2admin USING db2admin
  • Attraverso PHP PDO ODBC tento di connettermi al database:
$conn = new PDO('odbc:Driver=IBM DB2 ODBC DRIVER - DB2COPY1;Hostname=192.168.0.1;Port=50000;Database=TEST_DB;Protocol=TCPIP;Uid=db2admin;Pwd=db2admin;','db2admin','db2admin');
  • La connessione fallisce e nell’error log del PHP viene riportato il seguente messaggio di errore:
SQLSTATE[HY000] SQLDriverConnect: -1042 [IBM][CLI Driver] SQL1042C  Errore di sistema non previsto.  SQLSTATE=58004

Continua la lettura di DB2: Problema di connessione con PHP PDO ODBC

Perché ASP.NET non è la scelta migliore per realizzare una applicazione Web?

Su internet ci sono centinaia di articoli e di thread nei forum che discutono su qual è il linguaggio migliore per creare applicazioni Web. Sfortunatamente le opinioni riportate sono quasi sempre di carattere promozionale e datate, ovvero analizzano lo stato delle cose com’era parecchi anni fa e non tengono conto delle evoluzioni dei vari linguaggi di programmazione.

In questo articolo vogliamo spiegare perché secondo noi ASP.NET non è il linguaggio migliore da utilizzare per lo sviluppo di un nuovo software Web e per farlo, nel seguito, confronteremo le caratteristiche di ASP.NET con il linguaggio PHP che secondo noi è la scelta migliore. Cercheremo di analizzare i due linguaggi e i due mondi da un punto di vista oggettivo in modo che il lettore possa scegliere la tecnologia che per il suo scopo è più adatta.

Continua la lettura di Perché ASP.NET non è la scelta migliore per realizzare una applicazione Web?

Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC (aggiornamento 2014)

Come installare un ambiente WAMP

La presente guida è la versione aggiornata di quella scritta più di un anno fa Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC.

Questa volta però oltre a descrivere il procedimento di installazione dell’ambiente WAMP abbiamo deciso di fornire due archivi già pronti per chi va di fretta.
Continua la lettura di Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC (aggiornamento 2014)

Quali sono le migliori tecnologie con cui sviluppare software?

Space Shuttle

PHP

Presente da oltre 15 anni e utilizzato da decine di milioni di siti web, PHP è il linguaggio server-side più famoso e utilizzato al mondo.

Più del 77% dei siti web è stato ralizzato utilizzando questo linguaggio.

fonti: W3Techs, BuiltWith. Continua la lettura di Quali sono le migliori tecnologie con cui sviluppare software?

Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC

Questa guida è datata. La versione aggiornata è presente al seguente link: Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC (aggiornamento 2014).

La maggior parte dei siti web oggi in circolazione si basa su una soluzione a stack di software open source nota come LAMP: Linux, Apache, MySQL e PHP (Se al posto di Linux c’è Windows si parlerà di WAMP). Continua la lettura di Come installare un ambiente WAMP (Windows, Apache, MySQL, PHP) sul proprio PC

CodeIgniter vs Yii framework vs CakePHP vs Zend framework vs Symfony vs Kohana vs Akelos vs DooPHP: Quale framework PHP scelgo?

La risposta sintetica è: nessuno, sono tutti la stessa minestra!

Tutti i framework elencati cercano di distinguersi uno dall’altro, ma in realtà sono uno la copia dell’altro. Basta guardare le caratteristiche riportate sui loro siti o la tabella comparativa di wikipedia.

CodeIgniter Yii framework CakePHP Zend framework Symfony Kohana Akelos DooPHP

Riassumendo hanno tutti le solite caratteristiche:

  • paradigma ad oggetti
  • design pattern MVC (Model View Controller)
  • utilizzano sistemi di Object-relational mapping (ORM)
  • Supporto all’i18n (ovvero multilingua)

e le solite non-caratteristiche:

  • facile da usare
  • veloce/performante
  • flessibile
  • stabile, affidabile
  • sicuro
  • interoperabile
  • supportato dalla comunità
  • ben documentato
  • ecc.

Se però analizziamo le caratteristiche pubblicizzate abbiamo quanto segue:

Paradigma ad oggetti OOP

La sezione di wikipedia è più che esplicativa: http://en.wikipedia.org/wiki/Object-oriented_programming#Criticism

Design pattern MVC

Di per sè l’idea è buona, ma unito alla OOP ha l’effetto di aumentare la complessità con una scarsità di benefici.

Il flusso logico dell’applicazione è sparpagliato in tanti file e utilizzando OOP tipicamente è nascosto dall’ereditarietà tra classi. Invece di leggere il flusso logico di un listato di codice in sequenza bisogna continuamente saltare da un file all’altro. Il risultato è che per aggiungere una funzionalità o modificare un programma che segue questo pattern tipicamente è di più il tempo che si passa a capire come innestarsi nella logica che si vuole modificare rispetto al tempo speso nell’operare la modifica.

Generic Framework build with MVC Pattern + OOP Paradigm

Object-relational mapping (ORM)

Anche in questo caso l’ORM è di fatto un tentativo di soluzione ai problemi introdotti dalla OOP nell’interazione con un DB.

Sicuri contro attacchi SQL Injection e XSS

La tipica frase che si legge è: utilizza il nostro framework e in automatico la tua web application sarà sicura.

Di fatto però questa frase comunica allo sviluppatore un falso senso di sicurezza perché lascia intendere che ci penserà il framework a rendere sicura la web app, ma in realtà ciò non è possibile. Per sua natura stessa infatti la sicurezza è un tema pervasivo di tutta la progettazione, lo sviluppo e il deploy di un applicazione e pertanto le minacce legate alla sicurezza devono essere chiare allo sviluppatore (non si può nascondere la testa sotto la sabbia).

Per di più la maggior parte dei framework sopra esposti non forniscono funzionalità realmente utili come l’escaping di HTML, Javascript ecc.

Conclusione

Il difetto dei web framework è che sono troppo generici, perché vogliono consentire lo sviluppo di qualsiasi applicazione web, ma così facendo aggiungono uno strato di complessità fornendo in cambio funzionalità per lo più generiche.

Nel caso specifico del php inoltre già il linguaggio è pensato per il WEB e di conseguenza già il linguaggio ha tutto quello che serve per lo sviluppo di applicazioni WEB generiche.

Il risultato netto per utilizzare i framework sopra esposti è dover imparare oltre ad un linguaggio di programmazione come il PHP, un paradigma di programmazione OOP, un design pattern MVC e un framework che di fatto non aggiunge nulla, ma aumenta la complessità con tutto quello che ne deriva:

  • programmi più buggati
  • produttività rallentata

Soluzione

L’unica soluzione è non usare un framework generico, ma utilizzarne uno specifico per il tipo di applicazione che si vuole creare.

Noi di Garda Informatica abbiamo creato un nostro framework, specifico per lo sviluppo di applicazioni gestionali web based. La specificità del framework è la chiave per ottenere uno strumento efficiente ed efficace.

Script PHP per l’importazione/esportazione dati del proprio database

bees

Un tipo di soluzione che i nostri clienti ci chiedono spesso è quella di script per l’importazione/esportazione dati da e verso un database.

Lo scenario tipico è quello di un database, magari di un gestionale proprietario closed source, dal quale vanno estratti dei dati oppure sul quale vanno aggiornati dei dati con quelli provenienti da una fonte esterna come per esempio un foglio excel o un altro database.

In questo caso l’esigenza è quella di avere una procedura da lanciare per effettuare questo aggiornamento sia da interfaccia web sia come lavoro schedulabile es.: una volta ogni notte.

Non tutti sanno che il PHP, oltre ad essere il linguaggio web per eccellenza, può essere utilizzato anche per sviluppare script da lanciare a riga di comando.

Naturalmente se il nostro script viene lanciato dal web dovrà produrre un certo output (es. l’html di avanzamento), se invece viene lanciato da riga di comando ne dovrà produrre di diverso tipo (es. semplici righe di testo).

Il modo per capire in quale dei due casi ci troviamo è quello di interrogare la costante predefinita PHP_SAPI la quale contiene la stessa stringa ritornata dalla funzione php_sapi_name.

Se cioè la costante PHP_SAPI è uguale a cli significa che il nostro codice sta girando da command line, in tutti gli altri casi significa che sta girando via web.

Quindi, per esempio, la nostra funzione di output avrà una struttura simile alla seguente:

function output($msg) {
    if (PHP_SAPI === 'cli') {
        echo '<div>' . htmlentities($msg) . '</div>';
    } else {
        error_log($msg);
    }
}

Un altro accorgimento da tenere presente quando si vuole sviluppare un command line script è quello di impostare correttamente il path per le inclusioni dal momento che lo script può essere lanciato in modo assoluto o relativamente alla directory in cui è contenuto.

Il path cioè va impostato come segue nel file di avvio dello script e appena prima che vengano fatte le inclusioni di altri PHP:

define('BASE_PATH', dirname(__FILE__));
set_include_path(get_include_path() . PATH_SEPARATOR . BASE_PATH);

require_once 'lib/my_lib.php';
...

Se ci dimentichiamo di fare ciò non sarà possibile lanciare lo script con path assoluto come nell’esempio seguente:

root@myserver:~> php /var/www/vhosts/miosito.it/scripts/mioscript.php

Infine, trattandosi di uno script che potenzialmente può impiegare diverso tempo per completare il suo lavoro e consumare più memoria di quella che generalmente basta per una pagina web, è bene togliere il limite sul tempo di esecuzione e aumentare la memoria a disposizione:

<?php
/* lo script non ha limiti di tempo per completare la sua esecuzione */
set_time_limit(0);
/* lo script avrà a disposizione fino a 128 MiB */
ini_set('memory_limit', '128M');