Ora che sono ben chiari i vantaggi di una struttura del genere è giunto il momento di capire quale sia la miglior strada da seguire per mettere effettivamente a disposizione del cliente questi strumenti. Servizi managed o fai da te? Rispondere non è facile, credo ci siano molti aspetti da valutare prima di potersi schierare da una o dall’altra parte.

Ciò che riporterò di seguito sono una serie di considerazioni che spero mi aiutino a decidere al meglio.

Fai da te

Si ipotizza dunque di creare e gestire il servizio completo in proprio. Di cosa abbiamo bisogno?

• web server pubblico (per Redmine, Trac…)
• svn server
• backup
• connettività

Il primo è un semplice server web (LAMP) che installato a dovere si occupa di rendere pubblico il punto d’accesso del sistema di ticketing. Tale server dev’essere esposto al web quindi c’è bisogno di un ip pubblico (possibilmente statico) da utilizzare, inoltre avendo bisogno di accedere al server svn (che ipotizziamo essere nella LAN dell’ufficio) si capisce subito che i due devono poter comunicare tra loro. Ipoteticamente potrebbero anche essere rappresentati da una stessa macchina, la scelta dipende poi dalla disponibilità di risorse e da quanto si voglia spostare verso l’esterno i propri dati.

Infatti se per lo strumento di ticketing non credo ci si possano porre molte domande riguardo alla sicurezza (sistema web based che contiene un numero limitato di informazioni) è guardando all’svn (collegato al primo) che sorgono i primi dubbi. Quanto è pericoloso esporre il codice sorgente di tutti i propri progetti in una configurazione del genere? Nonostante si attuino tutte le best-practice per la gestione del servizio: autenticazioni, https, accesso in sola lettura dalla macchina web del ticketing, firewall decente per bloccare tutte le connessioni non necessarie…

Backup è un altro punto importante da non sottovalutare. Svn non è uno strumento di backup, si occupa di versioning ed in quanto tale la replicazione dei dati in caso di necessità deve essere gestita altrove. Ecco quindi che nasce una nuova attività da gestire oltre a quelle sopra elencate. Ma siamo sviluppatori ed i guadagni arrivano con il software o con i sistemi che dobbiamo gestire per lavorare?

Connettività indispensabile per erogare il servizio in modo continuativo ai clienti con una certa qualità. Spesso le offerte adsl aziendali lasciano molto a desiderare. Che sia davvero consigliabile intraprendere questo cammino?

Fai da te con deroga

Ipotizzando di avere un datacenter a disposizione, una colocation, un cage da qualche parte insomma che evita il problema della connettività e della sicurezza se vogliamo della lan aziendale come cambia la situazione? Resta ancora aperto il discorso della gestione dei sistemi che richiedono un minimo di manutenzione per quanto riguarda gli aggiornamente di sicurezza come minimo dei S.O. e dei software utilizzati. Inoltre non va trascurato il costo annuale di avere 1-2 server impegnati per tali compiti con N Gb di spazio disco occupati e tutte le altre risorse a contorno.

Servizio managed

Ok decidiamo di tenere “in casa” (o meglio “in ufficio”) meno cose possibili. Concentrandoci sul fatto che il core-business è realizzare software e non gestire sistemi. Ipotizziamo di appoggiarci ad un servizio tipo Assembla (per citare forse il più popolare?) che offre tutto ciò di cui abbiamo bisogno a prezzi che variano in base alle nostre richieste: repository, ticketing, collaborazione e strumenti di management. Si paga e si utilizza. Sicuramente fino ad una certa dimensione, sia in termini di numerosità che di spazio occupato dai progetti, questa pare essere la soluzione più economica.

I progetti risiedono fisicamente in una nuova posizione. Il cliente ha un suo posto dove richiedere nuove feature, verificare l’avanzamento dei lavori, consultare il wiki e condividere documenti. Gli sviluppatori utilizzano il repository per lavorare all’applicazione eseguendo i check out verso il server di sviluppo ed i commit (check in) verso il repository stesso dopo aver testato le modifiche introdotte. Chi di dovere potrà verificare i tempi da fatturare, le richieste già chiuse e quelle ancora in lavorazione.

Molti dei dubbi derivanti dalla configurazione precedente non esistono più, tuttavia ne resta uno bello grosso: c’è da fidarsi a caricare tutti i propri sorgenti su sistemi di terze parti?

Concludendo

Io un’idea me la sono fatta e credo si sia capito da ciò che ho scritto. Tuttavia mi farebbe piacere leggere eventuali consigli da parte di chi ha già attraversato questa fase e, perchè no, sentire eventuali valutazioni in merito fatte a suo tempo. I commenti sono aperti!

Sono davvero felice di vedere questo traguardo raggiunto, il coronamento di tanto lavoro offerto da alcune persone in via del tutto volontaria e gratuita solo per il bene della comunità. Orgoglio di vedere il proprio nome tra i traduttori e gioia di ricevere una copia omaggio da parte di Sensio. Correte a comprarlo!

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…

Sviluppatore

Sai scrivere codice, è il tuo lavoro. Dai vita ad un tuo progetto o ne trovi uno interessante notando che è sviluppato nel tuo linguaggio preferito. Sei a cavallo le tue qualità possono essere molto utili a tale progetto.

HTML & CSS & Design

Molti progetti a cui pensiamo sono progetti web, essenda tali si presuppone che esista una qualche interfaccia per l’utente di importanza rilevante. Proprio negli ultimi tempi analizzando lo stato dell’arte per un particolare tipo di applicazioni mi sono accorto che i progetti individuati lasciavano molto a desiderare su questo aspetto. Non è facile per chi non lo fa per vocazione o per lavoro riuscire a realizzare un prodotto curando tutti i suoi aspetti, io stesso non ho nè la voglia nè la fantasia di realizzare interfacce d’effetto per quello che produco. Mi limito ad offrire qualcosa di semplice e pulito, se viene richiesto qualcosa di più cerco di farlo fare a chi lo sa fare bene. Se sei uno di questi hai già capito come puoi contribuire.

Supporto

Non sei un tecnico ma conosci bene un prodotto e le sue funzionalità. Hai anche una certa esperienza nel suo utilizzo. Chi meglio di te può aiutare i nuovi utilizzatori rispondendo a diverse domande sulle mailing list o sui forum pieni zeppi di dubbi e problemi? Aiutare un nuovo utente che non riesce ad installare o a far partire il prodotto significa non far perdere al progetto stesso un utente che altrimenti potrebbe andare in giro dicendo che “prodotto xyz fa pena perchè nemmeno si installa”…

Documentazione

Non ha tempo per i forum e le mailing list non ti piacciono. Conosci però qualche lingua straniera e ti piace scrivere e fare traduzioni. La documentazione è fondamentale e poterla rendere accessibile anche a chi purtroppo non mastica troppo bene le lingue straniere (inglese su tutte) è fondamentale. Personalmente ho partecipato e parteciperò alla traduzione italiana di molta documentazione relativa a symfony. Non serve essere dei gran tecnici.

Testing e bug report

Da tutto quello che hai letto non trovi il modo di posizionarti tra le precedenti. Vuoi solo utilizzare il prodotto ma vorresti anche dare un piccolo contributo. Partecipa alle fasi di testing e anche dopo il rilascio fai in modo di segnalare prontamente eventuali problemi che incontri documentandoli in modo completo e facendo arrivare tali informazioni a chi si dedica allo sviluppo. Nessuno scrive codice senza bug, segnalarli è cosa sempre gradita.

In linea di massima queste sono le strade principali, volete aggiungerne altre?

Qualcosa da mostrare

Ogni giorno scrivo parecchie righe di codice per sviluppare i progetti dell’azienda per cui lavoro, migliaia di righe al mese, decine di migliaia se non centinaia di righe l’anno. Eppure tutto questo codice prodotto non lo posso, giustamente, mostrare ad altri per dimostrare le mie qualità di sviluppatore visto che appartiene all’azienda e non è buona cosa distribuirlo a destra ed a manca.

Pensate ad esempio alla necessità di mostrare del proprio codice ad un possibile datore di lavoro o a qualcuno che chiede la vostra collaborazione per un progetto. Attualmente io, come forse molti altri, sarei abbastanza in difficoltà avendo ben poco codice serio a disposizione. Qualcuno potrebbe obiettare che la situazione italiana è talmente ridicola a tal punto che nessuno chiede codice ad un colloquio, tuttavia mi pare che le cose stiano cambiando grazie a molte nuove giovani aziende che cercano di portare una ventata di novità in un settore che deve continuamente rinnovarsi per andare avanti.

Proprio in questo periodo mi sto muovendo per realizzare una piccola applicazione open source, oltre che per passione, anche per iniziare a creare un portfolio serio. Inoltre creare qualcosa può sempre essere il punto di partenza per alcune opportunità che ci si deve creare…

Assecondare la curiosità

Lavorare a qualche progetto in orario extra lavorativo permette di dedicarsi ad approfondire uno strumento / linguaggio / tema che vi ha incuriosito e di cui pensate possa essere utile sapere di più. Se programmare è una passione prima che un lavoro non pesa sicuramente farlo anche dopo il lavoro, è come raccogliere francobolli o fare modellismo. Non credete?

Se qualcosa vi stuzzica la curiosità fate in modo di assencodarla, scoprire sempre nuove cose permette di mantenere l’entusiasmo anche quando non è proprio facile continuare o avete a che fare con progetti poco stimolanti.

Ottenere vantaggi

Provare a percorrere nuove strade, testare nuovi strumenti, non è sicuramente una perdita di tempo. Tutto quello che imparate può tornare utile nel lavoro di tutti i giorni o per progetti personali futuri. Inoltre partecipare in modo attivo ad un progetto permette di entrare in contatto con molte persone interessanti da cui si può sempre imparare qualcosa oltre a potersi confrontare su molti aspetti del nostro lavoro.

E tu cosa ne pensi? Partecipi a qualche progetto open source? Vuoi condividere qui i tuoi perchè?