Se vi interessa il servizio ho generato il promo code PHPBLOG50 che potrete utilizzare per registrarvi risparmiando 50$ sulla registrazione annuale o 60$ su quella biennale.

Perchè?

Perchè questo sondaggio? Rispondo subito. Da 5 anni lavoro come dipendente per la stessa azienda come sviluppatore PHP e no, non sto pensando di passare a fare il freelance. La mia è solo curiosità e voglia di tenermi aggiornato su quello che offre il panorama attuale per soluzioni lavorative diverse da quella del sottoscritto. Di tanto in tanto verifico eventuali modifiche alle principali forme di lavoro autonomo (costi, spese, agevolazioni) oltre che societarie.

Cosa ho chiesto?

Innanzitutto ricordo che il questionario chiedeva di indicare la propria esperienza lavorativa (in anni), il costo a giornata (iva esclusa) e se ci si occupa solamente di sviluppo oppure anche di grafica, amministrazione server ed altre attività di contorno. Quest’ultima è stata aggiunta dopo le prime risposte per poter fare una distinzione più semplice tra servizio offerto e prezzo richiesto. Non è stato chiesto di indicare una localizzazione geografica per evitare che qualcuno fosse impaurito dal poter essere identificato facilmente oltre che per lo scarso interesse verso tale dato per i miei fini.

Cosa ho ricavato?

Di seguito alcuni grafici che potranno valere più di mille parole. Non credo abbia senso calcolare medie potendo incrociare i dati su tre valori, ho cercato quindi di rapportarli per capire se c’è qualche andamento particolare in funzione dell’esperienza separando poi i dati in base al servizio offerto (solo sviluppo o anche altro).

Per prima cosa vediamo tutte le risposte divise per tipologia di servizio indipendentemente dall’esperienza indicata.

Sull’asse delle ascisse troviamo il numero di risposte (quindi di freelance) appartenenti ad ogni fascia di prezzo che si trova sull’asse delle ordinate. Nel questionario l’indicazione del prezzo era libera, per comodità ho raggruppato i risultati a fasce per cui chi avesse indicato un valore di 160€ come costo giornaliero rientrerà nella fascia 150-200. Le barre blu rappresentano i totali mentre quelle gialle e arancioni rappresentano rispettivamente chi si occupa di un po’ di tutto e chi di solo sviluppo.

Il secondo grafico riporta i risultati tenendo conto di esperienza e di fasce di prezzo tralasciando quindi il tipo di servizio offerto. Ogni cerchio rappresenta una fascia di esperienza: al centro 1 anno, salendo di uno per ogni scalino fino ad arrivare all’esterno che rappresenta 5 o più anni.

E’ abbastanza visibile la naturale progressione del costo a giornata con l’aumentare dell’esperienza, che è un bene, oltre alla curioso distribuzione per esperienze di 4 e 5 o più anni con una forbice abbastanza ampia che potrebbe essere giustificata dalla posizione geografica del partecipante (e quindi dal mercato a cui si offre). Su questo però si potrebbe parlare parecchio dato che con tutti gli strumenti a disposizione sarebbe “semplice” poter guadagnare di più offrendosi a mercati meno vicini sul territorio (a parità di esperienza).

Il terzo grafico presenta la prima divisione in base al servizio offerto. Abbiamo a che fare con chi si occupa solamente di sviluppo.

Il cerchio bianco indica la mancanza di dati per sviluppatori con 3 anni di esperienza. Anche in questo caso analizzando solo gli sviluppatori “puri” si evince l’andamento crescente del costo giornaliero in funzione dell’esperienza. Resta una certa varianza all’interno delle stesse fasce anche se con un livello minimo più alto.

Chiudiamo con il grafico relativo a chi oltre occuparsi di sviluppo si dedica anche alla grafica, all’amministrazione di server e di altre mansioni inerenti comunque all’ambito web.

Qui si nota piuttosto facilmente il maggior livvellamento verso l’alto già a partire da esperienze di 3 anni.

Concludendo

Il campione analizzato può essere rappresentativo fino ad un certo punto vista la sua numerosità. La cosa difficile è raggiungere gli sviluppatori all’infuori della cerchia di amici/collaboratori dato che non tutti hanno devono essere per forza attivi su vari SN o partecipanti alla community italiana o internazionale di PHP.

Inoltre non essendo specializzato in statistica potrei aver presentato i dati non nel modo migliore per evidenziare particolari salienti. Se ci fosse qualche laureato in statistica all’ascolto (ogni riferimento a persone o cose realmente esistite è puramente casuale) che volesse mettersi a disposizione per analizzare i dati si faccia avanti. Sarò ben felice di condividere quanto raccolto dal sondaggio.

I commenti sono a vostra disposizione!

Sul suo blog Potencier ha espresso un po’ di idee sullo stato attuale dell’arte in termini di template engine paragonando ciò che la rete offre, ha anche pubblicato alcuni test comparativi delle performance dei vari prodotti. Risultato: poco meno di 90 commenti in nemmeno una settimana ed un post in risposta da parte di Eli White che solleva alcuni dubbi. Il cerchio si chiude con la risposta di Potencier in un altro post. Consiglio la lettura dei post e di tutti i commenti visto che ci sono degli spunti davvero interessanti su cui non voglio soffermarmi al momento.

Quello di cui vorrei parlare è ad un livello un po’ più alto: template engine si o no?

Personalmente negli ultimi anni ho sviluppato applicazioni con un framework, sviluppato internamente dall’azienda per cui lavoro, basato su Smarty per la creazione dei template. Da quando ho iniziato ad usare symfony, che ricordo è un MVC, mi sono sempre chiesto se mi mancasse davvero Smarty visto che i template si realizzano direttamente in PHP.

La risposta non la so ancora dare, posso tuttavia esprimere dei pareri sulle due strade che si possono seguire:

PHP

• creare i template direttamente in PHP evita di aggiungere un ulteriore layer al tutto
• non si deve imparare un altro linguaggio (per semplice che sia)
• permette più libertà (con attenzione)

TEMPLATE ENGINE

• rende più leggibili i template, specialmente quelli più complessi
• rende più accessibili, in termini di manutenzione, i template anche ai non sviluppatori
• aiuta ad essere più aderenti al design pattern MVC

Quello che più è importante secondo me, che si usi PHP od un template engine, è fare in modo che nella vista (V, di MVC) ci si limiti a presentare i dati e non ad elaborarli. PHP è uno strumento potente più del necessario per “mostrare” dei dati, va usato nel modo giusto. Un template engine dal canto suo, più scarno e povero di funzioni, potrebbe aiutare in tal senso a patto che non lo si vada ad estendere con mille plugin sviluppati ad hoc per tutte le occorrenze. A quel punto tanto vale restare con PHP…

E voi come agite? Quali sono le vostre esperienze in merito?

Ringrazio SensioLabs e tutti gli sponsor che hanno reso possibile un simile evento. Invito voi tutti a partecipare visto che il concorso non è finito e che c’è sempre bisogno di aiuto per fare in modo che il core team sia un po’ meno carico di lavoro a ridosso del rilascio di symfony 1.3.

Tuttavia i vari sponsor hanno messo a disposizione parecchi regali, ecco cosa mi sono aggiudicato:

• Libro su Doctrine (che dovevo proprio prendere visto il passaggio da Propel a Doctrine che ho deciso)
  
• USB Fan + Light (ficherrimo)
  
• elephpant (ne ho già 2, ma uno vinto vale di più!)
  

L’iniziativa continua quindi proverò anche questo mese a chiudere un ticket al giorno augurandomi di raggiungere il mio obiettivo: essere a Parigi a febbraio! Il problema sarà rappresentato principalmente dal fatto che la connessione mobile con Fastweb non mi permette di utilizzare svn cosa quasi indispensabile per lavorare comodi tra revision e sorgenti vari…

• Massimiliano Arione
• Davide Borsatto
• Fabrizio Pucci
• Luca Bernardi

Chiedo ai lettori invece di segnalare eventuali errori di battitura in modo da correggerli quanto prima. Ma le novità non sono finite visto che a breve ve ne comunicheremo altre riguardanti il progetto. Restate sintonizzati quindi!

Attualmente il sistema è in beta privata per aver modo di testare in modo approfondito tutte le funzionalità pubblicate da lunedì 3 novembre. Per provare la beta è necessario essere invitati da un utente già registrato, quindi se qualcuno di voi fosse interessato può semplicemente chiedere qui nei commenti di essere invitato provvederò personalmente a fargli pervenire un invito.

Inoltre a chi deciderà di partecipare chiedo di non farsi problemi a contattarmi per eventuali problemi, suggerimenti, consigli. I feedback durante il periodo di beta testing sono fondamentali per lo sviluppo nella giusta direzione di un’applicazione web.

Usiamo un semplice esempio per mostrare la strada sbagliata, che potrebbe sembrare la più logica non conoscendo Propel, e quella giusta. Ipotizziamo di avere una semplice tabella con due soli campi: “nome” e “numero”. Da questa tabella vogliamo estrarre solo i record che hanno un valore di “numero” compreso tra 11 e 20 (con estremi esclusi).

SELECT *
FROM table
WHERE numero > 11 AND numero < 20

La traduzione errata, più istintiva, è qualcosa di simile alla seguente:

$c = new Criteria();
$c->add(TablePeer::NUMERO, 11, Criteria::GREATER_THAN);
$c->add(TablePeer::NUMERO, 20, Criteria::LESS_THAN);
...

dove si pensa che ogni add vada ad aggiungere una condizione conbinandola alle altre con un AND. Tutto questo però è sbagliato visto che aggiungendo in questo modo più condizioni sulla stessa colonna “sovrascrive” le precedenti e lascia utilizzata solo l’ultima. L’ equivalente di:

SELECT *
FROM table
WHERE numero < 20

che di sicuro non è quello che vogliamo. Come fare allora? Bisogna ricorrere all’utilizzo degli oggetti di tipo Criterion usando il metodo Criterion::addAnd():

$c = new Criteria();
$criterion = $c->getNewCriterion(TablePeer::NUMERO, 11, Criteria::GREATER_THAN);
$criterion->addAnd($c->getNewCriterion(TablePeer::NUMERO, 20, Criteria::LESS_THAN));
$c->add($criterion);
...

In questo modo le due condizioni verranno prese in considerazione allo stesso modo e collegate con un AND. Abbiamo ottenuto l’interpretazione corretta. Per lavorare con l’OR basta cambiare il metodo utilizzato da $criterion->addAnd a $criterion->addOr.

Effettivamente le ragioni espresse nell’about del sito ufficiale sono reali: le donne coinvolte nello sviluppo del sotware sono poche, quelle che sviluppanno in PHP solo una piccola frazione. Il sito vuole essere un punto di riferimento per tutte le donne che spesso si trovano da sole (nel senso uniche donne) a conferenze, seminari e incontri vari. C’è da dire che è tutto vero: al PHPDay 2008 non ho ricordi di donne presenti perchè sviluppatrici (e non al seguito del fidanzato/marito).