Per poter creare le proprie applicazioni web è necessario un ambiente di sviluppo che sia il più possibile vicino a quello che sarà la realtà, ovvero il server di esecuzione. Sicuramente applicativi come WAMP (Window + Apache + Mysql + PHP) o MAMP (come il precedente solo che al posto di Windows si utilizza MacOS) hanno fatto la storia, ma è evidente che le loro limitazioni, per chi si spinge solo un po’ più in la sulle risorse di un vero server Linux, si facciano evidenti dove proprio non siano problematiche al punto tale da far perdere preziose ore di lavoro. Anni fa avevo proposto una soluzione con VirtualBox attraverso l’utilizzo delle shared folder. Un buon punto di partenza, visto che il server è un Linux, ma non è detto che le cose non possano andare storte, ad esempio si può inciampare sull’utilizzo di alcune librerie che possono essere differenti, oppure mancare del tutto e trovarsi a correre dietro a problemi inattesi nel momento del rilascio finale, quando il cliente finale magari è li che ti guarda..
La soluzione che propongo oggi è quella di utilizzare direttamente il server di produzione, attraverso una istanza di sviluppo dedicata, che però di fatto girerà laddove dovrà girare alla fine dello sviluppo. Rispetto a 10 anni fa i server oggi costano decisamente meno, la connettività è diventata di discreto livello e si può dire che è disponibile sempre.
Con questa tecnica i PRO sono evidenti, quello che viene sviluppato è certo che se lo vediamo funzionare rimane tale, come accennato sopra, senza vedersi dipendenze di librerie in conflitto o non soddisfatte; potenzialmente si può lavorare su più persone; si può pensare a tecniche di backup o di copia su GIT in modo automatizzato.
Gli svantaggi sono sostanzialmente due, se fate qualcosa di eccessivamente sbagliato potreste mandare in crash il server, quindi anche il sito di produzione; se volete programmare in posti sconnessi (in treno, in uno chalet in mezzo ai monti) questa soluzione non fa per voi.
Per chi utilizza Linux / MacOS.
Per chi utilizza come desktop una distribuzione Linux o MacOS l’utilizzo sarà un po’ più semplice. Nel caso di Ubuntu/Debian si installerà con un semplice
sudo apt-get install sshfsmentre per MacOS dovete fare riferimento al progetto osxfuse.
Meglio utilizzare Brew con il comand brew install sshfs
Una volta ottenuto il nuovo comando da Shell diamo
sshfs nomeutente@server:/path/del/server /path/localeùse utilizzate una chiave RSA non avrete bisogno di inserire la password, viceversa vi verrà chiesta. Alla fine avrete un nuovo “disco” montato sul sistema, che fa riferimento alla cartella remota sul server. Da qui potrete caricare/scaricare i file, oppure utilizzare direttamente il vostro editor di sviluppo preferito, dove le modifiche saranno direttamente visibili sul progetto.
Per chi utilizza Windows.
Sotto Windows le cose sono un po’ più complicate e anche meno performanti rispetto ai cugini. Si dovrà infatti installare due software distinti, il primo è Dokan mentre il secondo è Win-SSHFS.
Una volta installato tutto dobbiamo andare a cercare dentro c:/program files/win-sshfs l’eseguibile, dato che al momento in cui scrivo sotto Windows 10 non viene riportata alcuna voce. Una volta lanciato appare il manager e una icona nella Tray-Bar. Dal manager, in modo abbastanza intuitivo vengono chieste le credenziali del server, la cartella remota da puntare e una lettera di sistema che fungerà come disco esterno, dove appunto vedremo i files e cartelle remote.
L’applicativo è ancora in beta, per cui qualche baco qua è la ce lo dobbiamo aspettare, anche se francamente non ne ho riscontrati. Invece ho notato che le prestazioni sono decisamente inferiori, a volte salvando i file c’è un certo ritardo che i desktop Linux e MacOS non hanno.
Conclusioni.
Come al solito dipende da cosa dovete fare, ma a mio avviso si tratta di una ottima soluzione che permette di demandare il codice direttamente al server, dove magari è già presente un backup che salverà giorno per giorno il lavoro, avrete la certezza che l’esecuzione sia corretta, in molti casi lo sviluppo è possibile “girarlo” in produzione con pochi click perché risiede già sul server. Sotto Windows come accennato non è ancora del tutto maturo e/o affidabile come lo è sotto Linux e MacOS, ma visto l’interesse che gira intorno a questi progetti (win-sshfs non è poi di fatto l’unico) sicuramente il gap verrà chiuso entro un anno o due.