Linux, PHP, MySQL, Windows, C#

Dopo aver sperimentato l’utilizzo di Zend Framework in piccoli progettini, dapprima come framework puro (tipo pear per intenderci) e in un paio di occasioni con l’utilizzo della sua gestione del pattern MVC, mi ero fatto l’idea che:

• Come framework in sé non sia per niente male
• L’implementazione dell’MVC fosse buona, non eccezionale ma buona

Bene, sto lavorando da un paio di settimane su un progetto complesso e sto utilizzando Zend Framework nella sua piena implementazione dell’MVC.
Per cominciare (ma questo lo avevo già deciso sulla base delle precedenti esperienze), ho preferito evitare l’utilizzo di Zend_DB e della modalità che suggerisce la Zend stessa nei suoi tutorial per la gestione del model.
La motivazione era dovuta al fatto che non amavo la libreria in generale, ma soprattutto mi è sempre sembrato che la definizione del model richiedesse un overhead di sviluppo eccessivo.
Morale, il model l’ho gestito con classi scritte da me direttamente e utilizzando il caro, vecchio e affidabile adodb.

Sono però rimasto esterrefatto dalla terribile applicazione del pattern MVC per le seguenti cose, in ordine di gravità:

1. Mischione logico tra View e Controller/BusinessLogic nella definizione delle form (Zend_Form)
2. Assenza di parametri nelle action
3. Action i quali nomi dei metodi devono essere tutti minuscoli, tutti attaccati e con alla fine “Action”

Vado a spiegarmi meglio, per il punto 1:
La Zend suggerisce/propina l’utilizzo di Zend Form. Le Zend form di fatto definiscono i campi del form, le validazioni e via discorrendo. Fin qui direi tutto sommato abbastanza bene, è sufficiente definire una classe ApplicationForm che estenda Zend_Form. All’interno dell’init() si aggiungono tutti i vari elementi con le loro particolarità (ovviamente alcune cose specifiche possono essere inserite sia a livello di metodi aggiuntivi della classe che direttamente da controller).
Peccato però che all’interno di questa definizione di campi, oltre a cose sensate come le validazioni, il required etc… sia necessario inserire label, id, classi css, ovvero tutti aspetti sostanzialmente relativi alla parte di view.
Infatti da controller si istanzia la classe, tipo $form = new ApplicationForm(); e $form si passa alla view direttamente. La view non farà altro che renderizzare la form.
Questo significa che se un grafico/htmlista deve modificare qualcosa NON lo può fare dalla view, ma deve chiedere (o fare direttamente) al programmatore di agire sulla classe ApplicationForm().

@Zend: ma la separazione dei livelli dove la lasciamo?

Al di là di aspetti puristici e filosofici, questo rappresenta UN PROBLEMA CONCRETO.

Punto 2:
Il minimo che potevo aspettarmi (ovviamente lo avevo già notato anche in progetti più piccoli ma davo per scontato esistesse qualche variante per gestirlo) è che i metodi delle action potessero/dovessero essere parametrici.
Invece niente, il metodo detailsAction() che vorrebbe molto probabilmente l’id da cui attingere i dati, non può essere detailsAction($id), ma $id va recuperato in get/post come si fa da 100 anni.
Ho trovato qualche variante in giro di terze parti per avere i parametri nelle action ma a parte che non funzionavano benissimo, mi pare paradossale che un framework di X Mbyte non supporti i parametri nelle action della sua versione dell’MVC.

Punto 3:
Se richiamo ad esempio: http://www.massimo-caselli.com/Article/GetArticleDetails sono costretto a nominare la action in: public function getarticledetailsAction().
E’ il minore dei mali, però insomma anche la leggebilità del codice non è che sia poi una cosa troppo secondaria.

Per farla comunque breve devo dire che in questo caso, Microsoft batte Zend nell’implementazione dell’MVC 10 a 0.

Ho appena installato Skype 5.3 su windows 7 64 bit SP1.
Crashava quasi subito senza colpo ferire.

Se vi capitasse, il problema era collegato al fatto che lo avviavo (come da sempre il 5.1 e 5.2) in compatibility mode.
Basta disattivare l’avvio in modalità compatibile e tutto funziona.
Tra l’altro ora c’è anche l’opzione per non tenerlo inutilmente nella taskbar come da standard a partire da Win 7 dello zio Bill.

Dunque alla fine ho ceduto. Ho sempre evitato come la peste bubbonica Apple e tutti i suoi prodotti. Non tanto per ragioni tecniche, quanto per una questione filosofica: sono sempre stato avverso alla rigida chiusura e smania di controllo di Appe e ai suoi utenti tipici, in genere da me associati allo stereotipo del tecno-fighetto trendy e modaiolo felicissimo di spendere valangate di euri per arricchire il proprio leader carismatico, Steve Jobs, senza porsi alcuna minima domanda su quello che sta acquistando. Tecnicamente ho sempre avuto poco da dire sui loro prodotti, anche perché non conoscevo bene il “dietro le quinte”, in ogni caso avendo usato il Mac OS/X sapevo già che non ha assolutamente niente di più di una installazione Linux (ubuntu o Fedora per esempio) con Gnome o KDE, la differenza vera la fa la reperibilità di software commerciale che sul Mac fiorisce. Anche sulla tanto vantata “facilità d’uso” ci sarebbe MOLTO da dire.. ma quello e’ un altro capitolo. Purtroppo dato che sviluppo applicazioni mobile da molto tempo (prima Java ME, ora Android) sempre più clienti mi chiedono di fare il porting per iOS (iPhone e iPad). Di fronte all’elevato numero di richieste in tal senso mi son deciso – molto a malincuore – a iniziare i primi esperimenti con iPhone.

CHE SCHIFEZZA!!!!!!!

Non ho parole, davvero. Steve Jobs parlava a ruota libera contro Java (“pesante”, “datato” e che non “usa più nessuno” – a parte google ovviamente che su Java ha basato Android e sta polverizzando iPhone nelle percentuali di crescita >:-) ). Di fronte a tali invettive di Steve Jobs mi aspettavo chissà quali meravigliose innovazioni nello sviluppo, un paradiso terrestre della programmazione, uno scrigno delle meraviglie che aspettava solo di riflettere su me, povero programmatore, tutte le beatitudini del software Apple. Poi ho visto l’Objective C. E sto ancora vomitando.

E già perché Mac OS/X e iPhone derivano da un’altra invenzione di Steve Jobs, Nextstep, un framework GUI a oggetti sviluppato ai tempi di Next, un’azienda fondata dallo stesso Jobs tra fine anni ’80 e inizi anni ’90 quando era fuoriuscito da Apple. Il linguaggio che stava alla base di Nextstep, e oggi di Cocoa, il toolkit grafico di Mac OS/X e iOS, era l’Objective C. l’Objective C e’ una estensione a oggetti del C, sviluppato a metà anni ’80, che appiccica a forza al povero linguaggio C alcuni concetti presi dal linguaggio a oggetti per eccellenza, Smalltalk. Il risultato è una porcheria senza precedenti. Se nel 2011 volete scrivere software per Mac OS/X o iOS dovete ricorrere a un linguaggio in puro stile anni ’80:  niente namespace (o package), puntatori a manetta, gestione manuale della memoria (il garbage collector lo stanno ancora aspettando), e una sintassi VERAMENTE obbrobriosa!!!

Una chicca: per dichiarare un metodo con più parametri, bisogna mettere i nomi dei parametri MA ANCHE dei pezzi di stringa arbitrari chiamati “selettori”, servono perché dietro le quinte im “metodi” delle classi Objective C diventano funzioni C e senza questi pezzi di stringa NON POTREBBE RISOLVERE UNICAMENTE IL NOME DEL METODO quando sono presenti signature diverse (per esempio, int pippo(int a) e int pippo( int a, char*b) diverrebbero entrambi “pippo” ) !!! Quindi raffrontando con Java, il metodo

void pippo(int a,double b,String c);

diventa

-(void)pippo:(int)a stringarbitraria1:(double)b stringarbitraria2:(NSString *)c ;

E questo sarebbe un linguaggio??? Per non parlare della sintassi per chiamare un metodo, anzi per “mandare un messaggio a un metodo”, che è, se possibile, un’indecenza ancora maggiore. Supposto che il “pippo” di prima sia un metodo di “miaclasse” la sintassi sarebbe, posto che a=5, b=6.3 e c=”testo”

[miaclasse pippo:5 stringarbitraria1:6.3 stringarbitraria2:@"testo"];

Se questo ancora non vi sconvolge, posso anche dirvi che le proprietà di una classe (cioè le variabili di istanza) possono essere public, private o protected, ma NON I METODI!!! E come fate se volete mettere un metodo privato? NON lo dichiarate nella interface della classe ma lo scrivete nella implementazione!!! E se qualcuno però sa che quel metodo esiste può chiamarlo lo stesso… Non mi sento di sviscerare vere e proprie istigazioni a delinquere come le categories, la repulsione e’ troppa.

Per non parlare delle limitazioni assurde rispetto ad Android. Per esempio, con quest’ultimo e’ possibile intercettare i messaggi SMS in arrivo, grazie a questo ci ho scritto delle routine con autenticazione 1-time pad spettacolari, oppure e’ possibile interagire con le inbox/outbox di sistema (ho scritto una applicazione SMS custom che scrive nella outbox i messaggi inviati e si integra perfettamente col sistema). Con iPhone, ciccia: gli SMS non possono essere letti , intercettati, o salvati nella outbox, psosono solo essere inviati facendo apparire la maschera di incio di sistema precompilando SOLO IL NUMERO DEL DESTINATARIO. Per non parlare delle restrizioni dentro cui gira l’applicazione, può accedere solo alla sua directory, non può comunicare con altre applicazioni, non può condividere file, il multitasking e’ fortemente limitato, e via limitando.

Di fronte a tutto questo posso solo dire che finora avevo fatto benissimo a evitarli come la peste, tutto questo fa sembrare la programmazione in Java ME come una delizia per la mente…