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!

Tornando al tema principale vorrei lanciare un contest senza premi per raccogliere le migliori definizioni della figura del sysadmin, lancio il primo sasso per rendere meglio l’idea. Continuate poi nei commenti, il post verrà aggiornato di conseguenza:

• il sysadmin è come lo scarico del cesso: finchè funziona non ti accorgi della sua presenza, ma quando smette di funzionare sei nella merda

Buon divertimento!

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è?

The Myth of the Genius Programmer

Una forma di elitarismo aleggia nell’aria nei progetti di sviluppo collaborativo di software: tutti segretamente vogliono essere visti come dei geni. Nell’ interessante talk di Brian Fitzpatrick e Ben Collins-Sussman, i due sviluppatori cercano di spiegare come evitare questa trappola e come trasformare l’ego personale in crescita personale e collaborazione fruttuosa. Un concetto su cui riflettere è il “be a small fish” che trovate al minuto 19:20. Effettivamente migliorare le proprie skill è molto più facile quando non si è il big fish…

Do You Believe in the Users?

Troppi sviluppatori hanno dimenticato l’antica arte del customer service. Tutti i software hanno utenti, tuttavia molti sviluppatori hanno dimenticato come rispettarli, dargli credibilità o vendere loro software in modo divertente (ma onesto). Il talk focalizza la propria attenzione su temi come il design di software semplice, lo sviluppo rapido e sull’usabilità contro il risparmio sullo sviluppo. Si parla anche dell’importanza di mantenere l’illusione di semplicità di un sistema permettendo però cose più complesse ai power-user.

Concludendo

Risorse del genere dal mio punto di vista sono molto importanti. Avere la possibilità di seguire talk come questi può essere fondamentale quando non ci si può incontrare molto spesso con altri amici/colleghi per fare del lavoro assieme e discutere di problemi un po’ più di alto livello. La pensate così anche voi?

Chi segue l’evoluzione del web e vive di pane e pagine/applicazioni è sicuramente affascinato da chi riesce a creare un qualche prodotto di successo mondiale a tal punto da voler provare a seguire tale strada. Nell’era dei social network esiste un’applicazione per ogni cosa, andare ad attaccare una zona ancora scoperta per essere i primi non è cosa semplice e l’idea dello strumento che cresce da solo e genera contenuti è destinata a restare tale.

L’idea geniale

L’idea geniale non è da tutti, se ci chiudessimo in 50 in una sala per qualche ora a riflettere sul prossimo progetto da realizzare molto probabilmente non si concluderebbe proprio nulla. Inoltre anche se qualche qualcosa dovesse uscirne potrebbe essere quasi impossibile passare alla realizzazione senza ingenti capitali che non sono propri del nostro paese…

Se non arriva che si fa?

Allora che fare? Abbandonare i sogni di gloria? Non proprio. Le proprie forze, la propria professionalità, l’entusiasmo che abbiamo conservato possono tornare utili per creare qualcosa di veramente necessario ed al tempo stesso innovativo a suo modo. “Non hai ancora detto come” starete pensando. Ecco la risposta: non perdere tempo alla ricerca di qualcosa che forse non esiste nemmeno, risolvi un problema che esiste già e che dal tuo punto di vista potrebbe essere gestito meglio.

La soluzione

Il mondo è pieno di problemi e la rete pure. Da quelli semplici a quelli più complessi. Sicuramente nella vita di tutti i giorni, o in particolari periodi di essa che ti fanno conoscere nuovi orizzonti, ti lamenti per qualcosa che non ti piace e che non riesci a sopportare. Molte volte pensi pure “ma è così difficile fare così e così?” oppure “possibile che nessuno conosca l’esistenza di X per gestire questo?“…potremmo aggiungere molte domande ne sono sicuro.

Partendo da una di queste domande è possibile trovare sicuramente la risposta che stiamo cercando e dedicarle le nostre risorse. Non si tratta di creare il nuovo Facebook, ma di risolvere problemi concreti. L’impatto della nostra soluzione dipende dal tipo di problema che risolve e da quanti persone incontrano quello stesso problema.

In conclusione

Il problema ti verrà incontro molto più facilmente dell’idea geniale. Meno ci pensi e meglio è. L’esperienza e la professionalità non se ne vanno e ti aiuteranno a comprendere quale problema risolvere e come. Rilassatevi.

Utilizzando wvdial esistono dei semplici parametri da passare nell’init della connect card per selezionare il comportamento che il modem deve assumere:

• AT_OPSYS=0,2 (solo GPRS)
• AT_OPSYS=1,2 (solo UMTS)
• AT_OPSYS=2,2 (preferenza per GPRS)
• AT_OPSYS=3,2 (preferenza per UMTS)

Detto questo l’init del mio file wvdial.conf è il seguente:

Init1 = ATZ
Init2 = AT_OPSYS=1,2
Init3 = AT+CGDCONT=1,”IP”,”datacard.fastweb.it”,,0,0
Init4 = AT+CSQ

Buona navigazione!

Innanzitutto va detto che Subversion è un version control system open source che si occupa di gestire file e directory e le modifiche che possono subire con il passare del tempo. Questo permette di recuperare una certa versione di un file, seguire l’evoluzione di certi contenuti nel tempo. Praticamente è una piccola macchina del tempo.

Subversion può lavorare in rete permettendo quindi a persone distanti anche migliaia di chilometri di lavorare sugli stessi file dello stesso progetto in modo semplice e sicuro. E’ possibile impostare diversi livelli di accesso a determinati file e directory. L’evoluzione dei dati gestiti da Subversion può essere molto rapida, tuttavia è altrettanto semplice risolvere un problema introdotto da una modifica tornando alla versione precedente del contenuto specifico.

Mi può servire?

Vi starete sicuramente chiedendo se Subversion è lo strumento che fa per voi. Capirlo è molto semplice.

Avete bisogno di archiviare vecchie versioni di file e directory con la possibilità di andare a ripescarle facilmente e di controllare la loro evoluzione nel tempo confrontando le singole modifiche dello stesso file in diverse versioni? Subversion fa per voi.

Avete la necessità di lavorare con altri colleghi sparsi in rete sugli stessi file, tenendo traccia di chi ha fatto una particolare modifica e quando? Subversion è lo strumento che fa per voi.

Vantaggi principali

Il problema principale derivante dal fatto di lavorare in team sullo stesso progetto senza uno strumento di versioning è quello delle sovrascritture dei file e quindi delle modifiche fatte dagli altri. Un’immagine ricavata dalla documentazione di Subversion è più esplicativa di mille parole:

Subversion si basa sul concetto copy-modify-merge e di working copy secondo i quali ogni utente lavora sulla propria copia locale del progetto prima di inviare le proprie modifiche al repository centrale. In questo modo è possibile lavorare in parallelo senza perdere tempo aspettanto l’unlock di un file come accade nel contesto lock-modify-unlock.

Chiaramente lavorando in parallelo sugli stessi file è possibile che si verifichino dei conflitti da risolvere manualmente se alcune modifiche sono in contrasto tra loro. Va anche detto che se il lavoro è ben distribuito non è frequente avere a che fare con dei conflitti da gestire, qualora ce ne fossero il tempo per gestirli sarebbe comunque minore al tempo perso in un sistema basato sui lock.

Concetti molto importanti sono quelli di branch e merge che permettono di avere rami paralleli di sviluppo e strumenti per la gestione semplice dei contenuti comuni oltre a permette di fondere poi i contenuti nuovamente in un unico ramo gestendo eventuli conflitti.

Per chiudere questa presentazione, assolutamente non esaustiva, cito anche il tag che rappresenta una vera e propria snapshot del progetto in un determinato momento. La creazione di un tag è associata molto spesso alla release del prodotto o di certe funzionalità aggiuntive di una certa entità. Puntanto quindi ad una specifica tag potremo ricavare il sistema come era in un determinato momento escludendo tutte le modifiche apportate in seguito.

Vantaggi per i piccoli team o per sviluppatori singoli

Personalmente non ho mai avuto la fortuna di lavorare in grandi team o su progetti molto vasti portati avanti da diverse persone. Questo ha comportato nella maggior parte dei casi che il progetto su cui stessi lavorando fosse tutto mio dall’inizio alla fine o che comunque nessuno avesse bisogno di scrivere codice su un file aperto da me. Anche le abitudini dell’azienda contano e purtroppo dove ho lavorato io nessuno mi ha mai “obbligato” ad usare uno strumento come Subversion.

Tuttavia anche lavorando da solo su un progetto molte volte ho sentito la necessità di poter utilizzare uno strumento di versioning per il semplice fatto di poter “tornare indietro” ed analizzare le modifiche fatte ad un file. Un semplice esempio può esprimere meglio il concetto:

Il cliente chiede di far visualizzare una galleria fotografica in un certo modo piuttosto elaborato rispetto alla versione attuale presente sul suo sito. Sappiamo tutti che il cliente non ha ben chiaro nè cosa vuole nè come dirlo, proprio per questo ci troveremo a sviluppare N versioni della galleria che man mano andranno a sovrascrivere la versione precedente. E’ altresì molto probabile che nessuno faccia una copia di backup di tutte le versioni ma si proceda per iterazioni rilasciando sempre ciò che si modifica.

Ad un certo punto il cliente decide che la versione N-x era quella giusta. Come fare? Senza versioning ci si deve augurare di ricordarsi alla meno peggio ciò che si era fatto (che può essere moooolto distante dalla versione attuale) e riscrivere il codice totalmente da zero. Con il versioning basta cercare la versione corretta del file e recuperarla o analizzare le differenze con la versione attuale per muoversi al meglio.

Altro esempio potrebbe essere quello di dover recuperare quel frammento di codice usato tempo fa e poi dismesso ma che ora serve nuovamente. Non è bello lasciare porzioni di codice commentato nei propri listati in attesa di essere forse riutilizzati, con il versioning si possono eliminare e andare a recuperarli quando e SE serviranno.

Anche la possibilità di sfruttare il branching di un progetto e quindi di portare avanti in modo parallelo lo sviluppo della nuova area del sito o della nuova funzionalità dell’applicazione e lo sviluppo/mantenimento di ciò che già esiste rappresenta un bel vantaggio. Mentre nel trunk continuiamo ad avere una versione completamente funzionante dell’applicazione, su cui eventualmente si eseguono piccoli bug fix o leggere modifiche, nel branch creato è possibile sviluppare in tutta calma le nuove funzionalità (che occupano un arco temporale anche di una certa entità) fino a quando saranno ultimate e fatte ricadere quindi nel trunk.

In questo modo non esistono più attività bloccanti che impediscono di fare altre cose perchè ora il codice “è cambiato”, c’è sempre una versione funzionante da poter utilizzare e su cui poter lavorare senza pensieri.

Concludendo

I progetti più attivi su cui lavoro ho già provveduto ad importarli sull’svn aziendale creato ad hoc. Checkout e commit sono ormai all’ordine del giorno ed i dati delle revisioni possono essere sfruttati per alimentare altre applicazioni come Trac o Redmine che permettono una più facile lettura di questa mole di informazioni. Visto che di questo si potrebbero scrivere altri N post non mi dilungo, se qualcuno è interessato possiamo parlarne nei commenti. I nuovi progetti invece partiranno da svn in modo “nativo” per mia gran gioia.

Tornare indietro? Non se ne parla nemmeno! Mai più senza SVN! E voi come rispondereste?

Venerdì 15

10:00-10:30 Presentazione del GrUSP

10:30-11:30 Filippo De Santis Mocking objects practices for Symfony

11:30-12:30 Fabien Potencier Symfony 2.0

13:30-14:00 Rasmus Lerdorf – Keynote The state of PHP

14:00-15:00 Federico Partenzi Implementare programmazione ad eventi e la coda dei messaggi in PHP

15:30-16:30 Rasmus Lerdorf Simple is Hard!

17:00-18:00 Daniele Diversi vTiger: PHP in una soluzione CRM open-source

18:00-19:00 Giulio De Taddeo PayPal e PHP

Sabato 16

10:00-10:30 Francesco Fullone PHP per il mondo enterprise

10:30-15:30 Francesco Trucchia Spaghetti code refactoring

14:30-15:30 Jacopo Romei Sue me, sue you blues – Preventivi e contratti nei processi agili

16:00-17:00 Jonathan Wage Sympal: The flexible Symfony CMS

17:00-18:00 CMS communities in Italia

Sabato dovrò abbandonare prematuramente il workshop di Francesco Trucchia per seguire quello di Jacopo Romei che ritengo interessantissimo nell’ottica di completare lo scenario relativo ai processi agili. Ora che ho acquisito le regole principali per l’approccio agile ai progetti ho proprio bisogno di vedere come si comportano i preventivi ed i contratti per poter applicare al meglio la metodologia senza i vincoli di una mentalità troppo rigida e waterfall…

E tu cosa seguirai al PHPDay 2009? Se ci sarai batti un colpo!

Se trovate qualche strafalcione o cose che avreste tradotto diversamente od in modo più elegante fate un fischio ho già un paio di appunti da parte. A breve invierò un aggiornamento al gestore del sito.

Per le mie prove, prima di ricevere il case con il PicoPSU incluso (con tutti i connettori esatti), utilizzavo un vecchio alimentatore ATX con connettore a 20 pin recuperato dal mio vecchio pc (che in origine montava un P3 ed ora un Celeron2). La Intel® D945GCLF2 ha il connettore a 24pin ed in più ha pure il connettore P4 separato. Il problema era quindi duplice:

• mancavano pin sul connettore principale (i 4 finali 11-12 e 23-24 sulla mappatura)
• mancava completamente il connettore P4

Come fare quindi?

Il primo problema si risolve molto facimente visto che il connettore 20 pin è solamente stato esteso da quello a 24 pin introdotto dall’ATX12V 2.0, quindi potete connettere senza paura il connettore 20 pin del vostro alimentatore alla scheda madre (24 pin) senza il terrore di far esplodere tutto. Restano liberi gli ultimi 4 pin, non potete nemmeno sbagliare l’inserimento perchè il connettore è appositamente realizzato per entrare in una sola posizione (escludendo l’utilizzo della mazzetta da 15kg).

Ma a cosa servono allora quei 4 pin in più?

Servono principalmente per il supporto di hardware che richiede alte potenze, come era per il passaggio da P3 a P4. Tendenzialmente su una scheda madre mini-itx studiata per consumare poco e spesso utilizzata per realizzare prodotti appunto a basso consumo non servirebbero, tuttavia ormai tutti gli alimentatori nuovi che trovate in giro non pongono questo problema. Se proprio volete usare un alimentatore “vecchio” con pochi euro trovare gli adattatori già pronti per passare da 20 a 24 pin, spenderete ancora meno se avete un po’ di feeling con l’elettronica/elettrotecnica e vi farete i cablaggi da soli.

E cosa facciamo con il connettore P4 separato?

Questo anche nei miei test è stato indispensabile per far funzionare correttamente la scheda. Chiaramente non avendo a disposizione il connettore da cannibalizzare su un altro alimentatore (anche bruciato, servirebbe solo il pezzetto di plastica con i fili) mi sono arrangiato utilizzando degli spezzoni di filo recuperati nella borsa degli attrezzi.

Il collegamento è molto semplice e presuppone di utilizzare un molex 4pin (quelli dei lettori cdrom per intenderci) come sorgente e seguire la mappatura del connettore 4 pin MOLEX 39-01-2040 connector. Il collegamento è volante, lo sconsiglio quindi ai deboli di cuore e non mi assumo nessuna responsabilità se accidentalmente date un colpo a qualche filo facendolo uscire dal connettore e facendo appoggiare dove non dovrebbe.

Anche per questo, se non vi sentite troppo sicuri, con pochi euro potete acquistare un adattatore già pronto da molex a P4 che richiederà quindi di essere solamente connesso (anche qui senza possibilità di errore).

Capito tutto?

Se vi restano dei dubbi non avete che da chiedere, sono qui a disposizione!