Archivi categoria: Strumenti

Piccole automazioni con Powershell

Molti si chiedono perché esiste Powershell e a che pro bisognerebbe incominciare a usarlo. Me lo sono chiesto anch’io quando un ex collega ha iniziato a introdurlo in azienda preferendolo ad altri linguaggi più o meno di scripting.
Il primo risultato che mi ha restituito Google alla domanda “Why Powershell”: Why Powershell?

Ebbene, anche a non aver bisogno di mandare razzi sulla Luna è uno strumento che è giusto conoscere, specialmente se si lavora con tecnologie Microsoft ma non necessariamente. Un gran bel punto a suo favore è inoltre la facilità con cui si può sviluppare e debuggare uno script utilizzando Visual Studio Code, indipendentemente che ci si trovi su Windows, macOS o Linux. Tra l’altro quando si ha bisogno di automatizzare un qualche processo si finisce per usare quasi sempre le stesse istruzioni combinate in modo diverso, quindi appena se ne hanno alcuni a portata di mano diventa tutto un copia-e-incolla.

Qui sotto un semplice esempio di script Powershell che:

Compila un progetto .NET
Prende soltanto file dll e exe generati e li comprime in un archivio
Legge una stringa dal file .csproj (xml) per utilizzarla come nome del file zip
Prende in ingresso un parametro come argomento dello script (usandolo eventualmente come nome del file zip)
Utilizza un metodo del .NET Framework (System.String.IsNullOrWhiteSpace)

Dubito che qualcuno abbia bisogno di fare le stesse cose e in quest’ordine, ma anche preso a pezzi può comunque tornare utile (a me senza dubbio).

$workingDir = "./"
$projectName = "Dotnet.Project.Test"
$projectDir = "./src/$projectName/"
$csProjectFile = "$($projectDir)$($projectName).csproj"
$buildDir = "$($projectDir)bin/Release"

# args[0]: version
$interactive = $args.Length -eq 0 # if interactive can prompt questions

if ($interactive -eq $true) {
    $versionFromFile = (Select-Xml -Path $csProjectFile -XPath '/Project/PropertyGroup/Version' | Select-Object).Node.InnerText
    $versionToUse = Read-Host -Prompt "Current version is $versionFromFile, write anything if you don't want to use this one"
    if ([string]::IsNullOrWhiteSpace($versionToUse)){
        $versionToUse = $versionFromFile
    }
} else {
    $versionToUse = $args[0]
}

$zipFileName = "$versionToUse.zip"
$zipFile = "$workingDir/$zipFileName"

if (Test-Path $zipFile) {
    if ($interactive -eq $true) {
        $ShouldDeleteZip = Read-Host -Prompt "File $zipFileName already exists. Would you like to delete it now? [y/N]"
        if ($ShouldDeleteZip -eq "y") {
            Remove-Item $zipFile
        } else {
            Read-Host -Prompt "Impossible to continue without removing $zipFileName file, press a key to exit"
            Break
        }
    } else {
        Write-Host "Existing $zipFileName file, deleting it..."
        Remove-Item $zipFile
    }
}

Write-Host "Building $projectName..."

Start-Process -WorkingDirectory $workingDir -Wait -NoNewWindow -FilePath "dotnet" -ArgumentList "build ""$($csProjectFile)"" -c Release"

Write-Host "Compressing archive $zipFileName..."

Get-ChildItem -Path $buildDir |
    Where-Object { $_.Extension -eq '.dll' -Or $_.Extension -eq '.exe' -Or $_.Extension -eq '.config' } |
    Compress-Archive -DestinationPath $zipFile -Update

if (Test-Path $zipFile) {
    Write-Host "File $zipFileName created"
} else {
    Write-Host "An unknown error occurred while compressing the file"
}

Read-Host -Prompt "Press a key to exit..."

Chat (Ro)bots con Microsoft Bot Framework

Lascia una risposta

Da più di un mese volevo scrivere due righe introduttive su come si crea un bot utilizzando il framework Microsoft, e finalmente agli sgoccioli delle vacanze natalizie sono riuscito a raccogliere quel poco di voglia e tempo necessari.

Quella che segue è una rielaborazione – spero semplificata – di ciò che Giulio Santoli e Vito Flavio Lorusso ci hanno mostrato al Bot Revolution Lab dell’ultimo Codemotion di Milano.

Il repository Github: github.com/vflorusso/botrevolution/
Le slides: www.slideshare.net/gjuljo/bot-revolution-lab-at-codemotion-milan-2016

Alternative al framework Microsoft

Chiaramente questa della Microsoft è solo una delle tante opzioni per creare un bot e collegarlo ai canali che ci interessano, e cercando un po’ se ne trovano molte che possono essere migliori per certi aspetti e peggiori per altri.

Facebook messenger
Wit.ai
API.ai
Chatscript
Pandorabots/
Rebot.me
Imperson
… immagino l’elenco possa continuare a lungo

La differenza credo la facciano il motore di comprensione del linguaggio (più o meno imprescindibile), il costo, il linguaggio di sviluppo, la compatibilità con i principali programmi di messaggistica, la modularità di tutte le varie componenti e la facilità di integrazione con api di terze parti. Tra le altre cose al Codemotion la Cisco (uno degli sponsor) ha mostrato Tropo, delle api con cui – pagando un tanto al chilo – si possono aggiungere funzionalità ai propri bot come la possibilità di effettuare chiamate con voce registrata o text-to-speech, di interpretare la voce di chi risponde utilizzando lo speech-to-text, di inviare sms… in sostanza è un mondo in grande evoluzione e con moltissimi contendenti.
Starli a descrivere a grandi linee sarebbe inutile, un po’ perché non li conosco e un po’ perché andrei off-topic, ritorno quindi sul framework Microsoft ipotizzando che sia “il migliore” in circolazione.

Panoramica sugli strumenti utilizzati

Il laboratorio del Codemotion è durato un’ora e mezza, e in questo lasso di tempo siamo partiti da un ambiente più o meno già configurato per lo sviluppo arrivando a collegare vari bot – pubblicati sulla propria macchina – a Skype, Telegram e Slack.
Si sono utilizzati vari strumenti, che conviene introdurre brevemente perché per lo più possono tornare utili a prescindere dai bot.

ngrok

Si pronuncia “en grok” ed è un sistema di tunneling – http ma non solo – utilissimo quando si vuole sviluppare qualcosa localmente rendendolo accessibile temporaneamente dal web ma senza aprire porte su eventuali firewall.
ngrok.com

Bot Builder SDK

L’sdk con cui scrivere il bot, in C# o NodeJS. Sul repository Github ci sono moltissimi esempi in entrambi i linguaggi.
github.com/Microsoft/BotBuilder

Bot Framework Emulator

Un emulatore desktop multipiattaforma con varie funzionalità utili per testare il proprio bot, sia in locale che dopo averlo pubblicato.
docs.botframework.com/en-us/tools/bot-framework-emulator

LUIS

“Language Understanding Intelligent Service”, ovvero le API Microsoft per la comprensione del linguaggio, utilizzabili in ogni genere di applicazione.
www.luis.ai

Visual Studio Code

Si può utilizzare l’ide o l’editor che si preferisce, ma Visual Studio Code può essere una soluzione ideale sia che si decida di scrivere in Javascript che in C#.
code.visualstudio.com

Preparazione dell’ambiente di sviluppo per l’sdk NodeJS

Per iniziare a sviluppare il proprio bot in locale:

procurarsi una versione aggiornata di NodeJS
Nota: a me la versione 7 diede qualche problema e finii per usare la 6.9.x.
installare il bot framework emulator
scaricare l’eseguibile di ngrok e copiarlo dove rimane più comodo
inizializzare un progetto Node nella cartella di lavoro:
npm init
installare le dipendenze del progetto:
npm install botbuilder restify dotenv-extended --save

Se si vuole chiudere il cerchio andando a pubblicare il proprio bot collegandolo a un sistema di messaggistica:

pubblicare il proprio bot da qualche parte sul cloud (temporaneamente si può usare la propria macchina e ngrok)
farsi un account Microsoft su login.live.com
crearsi un account sui servizi di messaggistica che ci interessano (Slack, Skype, Telegram, …)

Bot Sanculotto – Salut world

L’obiettivo sarebbe stato quello di sviluppare un bot capace di dire all’utente la data o l’ora usando il calendario rivoluzionario/repubblicano francese o l’orologio decimale, con un minimo di capacità di interpretazione della domanda. In corso d’opera però mi sono reso conto che per sviluppare i pezzi che mi mancano ci avrei messo troppo, e che forse in questa prima parte era meglio fare una panoramica del framework, quindi per non fargli dire “Hello world” al momento Sanculotto risponde “Salut” a tutti.

var builder = require('botbuilder');
var restify = require('restify');

var connector = new builder.ChatConnector();
var bot = new builder.UniversalBot(connector);

bot.dialog('/', [
    function(session) {
        session.send('Salut');
    },
]);

/* LISTEN IN THE CHAT CONNECTOR */
var server = restify.createServer();
server.listen(process.env.port || process.env.PORT || 3978, function () {
   console.log('%s listening to %s', server.name, server.url); 
});
server.post('/api/messages', connector.listen());

Questo codice risponde “Salut” a qualunque tipo di messaggio, il resto se mai vedrà la luce lo metterò su Github e cercherò di sfruttarlo per una secondo articoletto.

Test in locale con il framework emulator

Conviene partire dal caso più semplice, sufficiente per sviluppare l’eventuale logica del bot – qui assente – senza stare a scomodare servizi in cloud e sistemi di messaggistica vari.

Configurazione dell’emulatore per rendergli accessibile ngrok

Avvio del bot con “node index.js”, per comodità possiamo usare il terminale integrato in Visual Studio Code

Test con l’emulatore dopo aver specificato l’endpoint locale

Collegamento con account Microsoft e test su Skype

Lo script è come quello di prima con la differenza che questa volta per creare il chat connector dobbiamo usare delle credenziali Microsoft.
Per far questo creiamo nella stessa directory dello script un file .env contenente le credenziali di cui sopra, e nello script le utilizziamo dopo aver caricato il modulo dotenv-extended. Le inseriremo nel file subito dopo aver registrato il bot sul portale della Microsoft.

require('dotenv-extended').load();
// ...
var connector = new builder.ChatConnector({appId: process.env.MICROSOFT_APP_ID, appPassword: process.env.MICROSOFT_APP_PASSWORD});
// ...

MICROSOFT_APP_ID=
MICROSOFT_APP_PASSWORD=

Registrazione del bot sul portale della Microsoft

Lancio di ngrok con ./ngrok http 3978

Un piccolo chiarimento sull’ordine temporale delle operazioni è d’obbligo.
Il portale Microsoft vuole sapere l’endpoint di pubblicazione del nostro bot, che in questo caso è ancora sulla nostra macchina. Sappiamo che la porta è la 3978 perché abbiamo messo in ascolto il nostro server node su quella porta, quindi avviamo ngrok per fare il tunneling http in quella posizione, e copiamo l’indirizzo di forwarding in https sul portale aggiungendo /api/messages perché è quella la nostra root.
A questo punto possiamo generare le credenziali (app-id e password) dal portale e copiarle nel file .env; se tutto è stato configurato correttamente dovrebbe ora essere sufficiente avviare l’applicazione per poter dialogare con il bot dall’interfaccia web del portale Microsoft. Inserendo l’endpoint completo e le credenziali generate sopra sull’emulatore possiamo testare l’applicazione anche con quest’ultimo.

Test dall’interfaccia web del portale Microsoft

Canali disponibili

Una volta registrato sul portale possiamo collegare il nostro bot su tutti i canali che si vuole, la lista è lunga. Naturalmente è necessario avere un account sul sistema di messaggistica che ci interessa, e la procedura di registrazione è diversa per ciascun canale. Quella di Skype chiaramente è la più semplice essendo tutta roba Microsoft, un paio di click e possiamo usarlo per comunicare con Sanculotto.

Test tramite Skype

Nota: ricordiamoci che per la Microsoft l’endpoint del bot è (ancora) l’url generato da ngrok, ed è dinamico. Ogni volta che arrestiamo e riavviamo quest’ultimo dobbiamo quindi andare a sostituire l’url sul portale, almeno finché non pubblichiamo il codice del bot da qualche parte in cloud.

Per concludere

Questa è chiaramente solo un’introduzione al framework, che al primo approccio potrebbe risultare un po’ ostile anche perché abbastanza modulare.
Su Github ci sono molti esempi di bot più o meno complessi, alcuni anche basati su Luis – le api di comprensione del linguaggio – che qui non ho affrontato minimamente un po’ perché meritano un articolo a parte e un po’ perché le ho viste solo cinque minuti più di un mese fa.

Il prossimo passo dovrebbe essere quello di dare a Sanculotto qualche capacità in più, perché al momento il suo rispondere sempre “Salut” a qualunque messaggio lo rende abbastanza poco utile. Conto di farlo nelle prossime due o tre settimane.
A grandi linee penso di pubblicare le api di calcolo del calendario in ASP.NET su Azure perché ho già del codice in c#, e il bot in Javascript sempre su Azure all’interno dello stesso service plan così da minimizzare il traffico tra i due; per l’interpretazione delle richieste in linguaggio naturale c’è Luis, che chiaramente dovrà essere istruito a dovere. In queste ultime quattro righe credo di aver riassunto le potenzialità di questo framework, la cui forza principale è l’enorme ecosistema Microsoft su cui può (ma non necessariamente deve) far affidamento.

Prototipazione (molto) rapida

Lascia una risposta

Qualche tempo fa mi è venuta voglia di fare un corso sulla prototipazione rapida di applicazioni che ho trovato su Udacity, ma negli ultimi tempi non mi è servito fare alcun prototipo… finché al lavoro – meno di un mese fa – non abbiamo dovuto cominciare da zero lo sviluppo di una nuova applicazione per Android.

Corso Udacity sulla prototipazione rapida

Ci poteva stare lavorare inizialmente a prototipi per definire l’interfaccia utente, ma per evitare frizioni con i colleghi designer e per “risparmiare tempo” ho preferito evitare. Finché un bel giorno mi arriva la notizia di un tirocinante del quarto superiore in cerca di qualcosa da fare per una settimana, al che gli affido il corso web, l’analisi funzionale dell’applicazione da sviluppare e un blocco note.
Ebbene un ragazzo del quarto superiore totalmente nuovo al mondo della UX design dopo tre giorni mi ritorna con un prototipo di applicazione interattiva disegnata con la matita, e negli ultimi due giorni di test e raffinamenti progressivi ci siamo ritrovati con una bozza da cui prendere spunto fatta da un ragazzo inesperto e apparentemente “inutile”.

Per carità, se non si ha bisogno di progettare un’interfaccia utente innovativa e l’applicazione in oggetto sarà uno strumento di lavoro probabilmente può bastare seguire le linee quida del material design e utilizzare solo componenti standard per ottenere un buon risultato. Ciò non toglie però che per definire l’ordine delle voci di menù, la posizione di campi e pulsanti, l’interattività tra le varie componenti, fa comodo capire come ragionano gli utenti tipo dando loro in mano qualcosa da provare, possibilmente prima di mettersi a sviluppare.

Mockup, wireframe, sketch

Di strumenti per disegnare bozze delle proprie maschere ce ne sono tanti. Tra quelli gratuiti e open-source il migliore che conosco è Pencil, ma per la mia (poca) esperienza all’inizio conviene lavorare di carta e penna, o di tavoletta grafica quando se ne ha una.
Gli strumenti consigliati nel corso

InVision

Secondo me i prototipi sono belli se interattivi. Va bene che tutto fa brodo, e anche delle maschere disegnate su un blocco note e mostrate a un potenziale utente sono ottime per raccogliere informazioni, ma non c’è niente come osservare quell’utente mentre cerca di capire i meccanismi dell’applicazione e come raggiungere i suoi obiettivi. Per fare questo il miglior mezzo che ho trovato finora è InVision, e non a caso lo consigliano sul corso.

I tipi di prototipi disponibili

Aggiunta di hotspot alle proprie bozze

Aggiunta di commenti

Chat di gruppo

Condivisione del prototipo

In questa breve carrellata ho elencato le funzionalità più interessanti secondo me, dalla scelta del tipo di dispositivo alla condivisione del risultato. InVision si può usare partendo da disegni a matita ma anche da prototipi più fedeli fatti con Pencil o altri strumenti simili, e il suo funzionamento è molto intuitivo. Per chi fa il corso su Udacity dovrebbe esserci anche una licenza gratuita di alcuni mesi, ma anche senza di questa i prototipi si possono fare (in numero limitato) e condividere.
Volendo c’è anche un’applicazione in stile Dropbox che aiuta a mantenere sincronizzate le immagini caricate sul prototipo con quelle sul proprio computer, così da poterle modificare più facilmente.

Per smartphone c’è un’applicazione simile chiamata POP che però secondo me è meno comoda e intuitiva. Un’applicazione web si utilizza più facilmente e InVision è difficilmente migliorabile.

Il json-schema: forse non una gran soluzione ma a volte può tornare utile

Lascia una risposta

Sono consapevole che documentare e validare i dati anziché la sorgente che li genera potrebbe non essere l’approccio migliore, di recente mi è però capitato di dover mettere in piedi un backend “estremamente lean” (eufemismo per dire che è tutto basato su un file json), e generare un json-schema per verificarne la correttezza mi è sembrato doveroso…

Ma facciamo un passo indietro: l’applicazione mobile “backend-free”

A tutti quelli che fanno questo mestiere prima o poi vengono idee su possibili applicazioni web/mobile da sviluppare per esigenze personali, come progetto di studio o ancora meglio perché vogliamo vedere se la cosa può prendere campo, ma il tempo libero è poco e lo sviluppo di front-end e back-end può significare una mole di lavoro tale da farci lasciar perdere. Ci sono però casi in cui i dati sono pochi e non troppo preziosi, al che mettere inizialmente un file json su una cartella web può essere sufficiente.
Una soluzione che mi è sembrata molto comoda almeno nella fase di “sondaggio del mercato” è quella di copiare il/i file json su una cartella Dropbox, copiarne il link e utilizzare quello come url del nostro “servizio web dei poveri”. Nota: se utilizzate Dropbox è necessario che l’url sia nella forma https://dl.dropbox.com/..., se al posto del “dl” lasciate “www” al vostro client arriva non il file json ma la pagina html di visualizzazione di Dropbox.
Se Dropbox non vi piace di alternative simili ce ne sono tante, oppure se avete uno spazio web potete usare quello, a me però piace Dropbox anche perché non ho limiti di traffico, posso gestire i dati in vari modi, e il rischio che il server “vada giù” è praticamente nullo.
Detto che una soluzione del genere può andar bene soltanto se l’idea che qualcuno vi copi tutti i dati non vi spaventa, la scomodità maggiore è la totale mancanza di qualcosa che vi faciliti nell’inserimento e la manutenzione dei dati, cosa che può portare a inserire dati in un formato non corretto con inevitabili malfunzionamenti sulla vostra applicazione client. Ecco quindi che entra in scena il json-schema.

Il json-schema, sempre di json si tratta

Iniziamo con il dire che così come l’xml-schema è un xml, il json-schema è un json, e allo stesso modo compilarlo è una scocciatura. Il sito web di riferimento per i json-schema è json-schema.org, sito bruttarello ma pieno di risorse.

Sebbene l’idea di scrivere prima o poi uno schema ce l’avessi avuta fin dall’inizio, mi sono ritrovato a farlo soltanto quando la struttura dati era più o meno formata (seppur con dati mock). Mettersi a scrivere lo schema tenendo di fianco i dati è abbastanza noioso e non è nemmeno facile, infatti sono arrivato a un punto che il linter mi segnalava lo schema come non valido e non sapevo il perché.

Alla fine l’approccio che ho seguito è stato il seguente:

scrittura di un json con almeno qualche elemento completo, così da avere dei dati con tutti i casi particolari
generazione dello schema utilizzando un servizio come jsonschema.net; l’importante è che venga fuori una struttura “abbastanza aderente” a quello che avete in mente
pulizia dello schema dagli artefatti inutili e copia in un linter come jsonschemalint.com insieme ai dati
rifinitura dei dettagli relativi ai tipi, gestioni dei valori null, eventuali regex sulle stringhe; descrizioni sui campi meno chiari
eventuali modifiche ai dati per rendere la struttura più uniforme
se serve che qualcuno poco familiare con il formato json “capisca” i dati può essere utile generarsi una documentazione a partire dallo schema, Docson è semplice da usare e da un buon risultato

Qualche dritta sui json-schema

A questo punto è doveroso un esempio riepilogativo con quasi tutte le funzionalità che sono servite a me, così almeno sapete a cosa andrete incontro…

{
  "data": "2015-12-03T00:00:00",
  "lista": [
    {
      "id": 1,
      "nome": "Articolo 1",
      "email": null,
      "tipo": "tipo1",
      "classe": 1,
      "flag": true,
      "figli": [
        {
          "data": "2015-08-16",
          "note": "blablabla"
        }
      ]
    }
  ]
}

{
  "$schema": "http://json-schema.org/draft-04/schema#",
  "description": "Esempio",
  "type": "object",
  "properties": {
    "data": {
      "description": "Data con formato yyyy-MM-ddTHH:mm:ss",
      "type": "string",
      "pattern": "^[0-9]{4}-[0-9]{2}-[0-9]{2}T[0-9]{2}:[0-9]{2}:[0-9]{2}$"
    },
    "lista": {
      "description": "Lista di oggetti",
      "type": "array",
      "items": {
        "type": "object",
        "properties": {
          "id": {
            "description": "Identificatore univoco",
            "type": "integer"
          },
          "nome": {
            "type": "string"
          },
          "email": {
            "type": ["string", "null"],
            "format": "email"
          },
          "tipo": {
            "description": "Tipologia a scelta tra tre valori",
            "type": "string",
            "enum": ["tipo1", "tipo2", "tipo3"]
          },
          "classe": {
            "description": "Classe con valore numerico da 1 a 5",
            "type": "integer",
            "minimum": 1,
            "maximum": 4,
            "exclusiveMinimum": false,
            "exclusiveMaximum": false
          },
          "flag": {
            "description": "Flag booleano",
            "type": "boolean"
          },
          "figli": {
            "description": "Elenco di oggetti figli",
            "type": "array",
            "minItems": 1,
            "items": {
              "type": "object",
              "properties": {
                "data": {
                  "description": "Data con formato classico yyyy-MM-dd",
                  "type": "string",
                  "format": "date"
                },
                "note": {
                  "type": ["string", "null"]
                }
              },
              "additionalProperties": false,
              "required": ["data"]
            },
            "additionalItems": false
          }
        },
        "additionalProperties": false,
        "required": ["id", "nome", "tipo"]
      },
      "additionalItems": false
    }
  },
  "additionalProperties": false,
  "required": ["data"]
}

Un esempio abbastanza ricco, e che fa capire quanto uno schema possa venire “corposo” anche quando si riferisce a un json quasi insignificante.

campo data di primo livello: classica regex definita con l’attributo pattern, in cui però non si possono usare i classici segnaposto \d, \s
campo lista di primo livello: array di oggetti, attenzione perché questo è il modo in cui si gestiscono “oggetti uniformi” (caso tipico secondo me), si possono gestire anche oggetti diversi ciascuno in una posizione dell’array
campo email di secondo livello: stringa ma che accetta anche valori null, il formato dell’email viene validato con l’attributo format anziché con una regex (altri formati ammessi sono date, time, date-time
campo tipo di secondo livello: enum, ovvero stringa ma che può assumere solo determinati valori
campo classe di secondo livello: valore intero con limiti max e min

Da notare come il valore null debba essere inserito esplicitamente tra i tipi ammessi nonostante il campo che accetta null non sia specificato nell’elenco dei campi required.

Conclusioni

Come dicevo all’inizio la scrittura di un json-schema secondo me dovrebbe e potrebbe essere evitata definendo e documentando opportunamente le api che generano i dati. In alcuni casi è comunque uno strumento che può tornarci utile: non solo può aiutare nei casi limite come quello di un’applicazione nello stadio iniziale con dati gestiti in modo minimale, ma anche quando i dati sono in possesso di soggetti terzi che non ne hanno particolare cura o che non ci forniscono appropriata documentazione l’idea di generarci uno schema può aiutarci a evitare spiacevoli inconvenienti, anche perché nessuno ci vieta di utilizzarlo nei nostri test di integrazione, per la serie “fidarsi è bene…”.

Da Appcelerator Studio a Atom: passaggio abbastanza indolore

Lascia una risposta

Chi sviluppa con Titanium sa che in questo mondo – che poi è solo un sottoinsieme del mondo Javascript – c’è chi utilizza la command line e l’editor/ide di preferenza, e chi preferisce rimanere al calduccio utilizzando tutti e solo gli strumenti messi a disposizione da dalla casa-madre Appcelerator, ovvero Appcelerator Studio.
Appcelerator Studio in se non sarebbe troppo male, il problema è che una versione modificata (e neanche troppo bene) di Eclipse si porta quindi dietro la sua estensibilità ma anche la sua pesantezza. In più a volte ti si blocca mentre stai facendo operazioni banali come aggiungendo stringhe al file strings.xml costringendoti a buttare giù tutto e facendoti perdere del lavoro (le bestemmie che ho tirato giù a causa di questo problema sono veramente tante).
A volte succede anche che l’integrazione con gli stessi servizi di Appcelerator smettano di funzionare, ed è noto come la recente impossibilità di fare build su iOS abbia seminato il caos e costretto molti a un utilizzo più consapevole della CLI.

Sublime? No, Atom

Buona parte dei migliori sviluppatori che conosco, e che hanno a che fare con Titanium, si affidano a Sublime Text, un editor (termine riduttivo) veramente veloce e ben fatto. Per Sublime ci sono plugin di ogni genere, e Titanium non fa eccezione:
https://github.com/AoDev/ti-alloy-in-sublime-text-2
https://github.com/MattTuttle/sublime-ti-build
A me però non va di pagare per utilizzare un editor non open-source, e il simpatico messaggio che compare sempre più spesso con cui invitano ad acquistare una licenza mi da abbastanza fastidio.

Chi non usa Sublime ha due grosse alternative: Atom e Visual Studio Code. L’editor di Microsoft (ancora in preview) è molto bello e funziona bene specialmente con linguaggi della galassia Microsoft (vedi Typescript), ma per il resto forse gli è preferibile Atom, giunto da poco alla versione 1.0 e con una miriade di plugins che aumentano e migliorano giorno dopo giorno.

Configurare Atom con il minimo necessario per sviluppare con Titanium

Scelta fatta. Per programmare in Javascript potenzialmente basterebbe un blocco note, e per fare le build con Titanium c’è la CLI, però magari utilizzare qualche aiuto potrebbe non essere una cattiva idea.
Per avere un minimo di auto-completamento ho installato questo plugin che funziona bene:
https://atom.io/packages/titanium-alloy
che ha anche un’integrazione con hyperclick:
https://atom.io/packages/hyperclick

Auto-completamenti e auto-formattazioni non mi hanno mai fatto impazzire, ma un check statico del codice in tempo reale che segnali eventuali imprecisioni ma anche errori e pratiche di cattiva programmazione mi è sempre piaciuto averlo, e su Appcelerator Studio i linter latitano o funzionano male. Un linter è prezioso nel mondo javascript specialmente quando si lavora in squadra, perché sebbene in questi casi si tenda a scrivere in modo simile spesso non lo si fa abbastanza.

In Atom non solo si può installare ESLint, ma si può creare un file di configurazione del linter per ogni progetto.
https://atom.io/packages/linter
https://atom.io/packages/linter-eslint

{
	"globals": {
		"Ti": false,
		"Titanium": false,
		"Alloy": false,
		"$": false,
		"_": false,
		"L": false,
		"arguments": false,
		"require": false,
		"module": false,
		"exports": true,
		"OS_ANDROID": false,
		"OS_IOS": false,
		"ENV_PRODUCTION": false,
		"ENV_DEV": false,
		"setInterval": false,
		"clearInterval": false,
		"setTimeout": false,
		"clearTimeout": false,
		"alert": false,
		"describe": false,
		"it": false,
		"beforeEach": false,
		"afterEach": false
	},
	"rules": {
		"strict": [2, "never"],
		"new-cap": [2, {"capIsNewExceptions": ["L"]}],
		"no-trailing-spaces": [1, { "skipBlankLines": true }],
		"space-infix-ops": [1, {"int32Hint": false}],
		"comma-spacing": [1, {"before": false, "after": true}],
		"key-spacing": [1, {"beforeColon": false, "afterColon": true}],
		"semi-spacing": [1, {"before": false, "after": true}],
		"dot-notation": 1,
		"no-underscore-dangle": 1,
		"no-unused-vars": 1,
		"no-multi-spaces": 1,
		"quotes": [1, "double"],
		"eol-last": 0,
		"no-alert": 0
	}
}

In “globals” si elencano le variabili globali, specificando anche se possono essere assegnate oppure no.
In “rules” si specificano le regole di validazione, indicando se eventuali infrazioni vanno segnalate in rosso come errori (con il 2) o in giallo come warnings (con l’1). Lo 0 le disabilita.
Qui sono elencate tutte le regole di validazione di ESLint.

Altri plugins utili per Atom

Di estensioni ce ne sono una marea, e ognuno ha le sue esigenze, ma finora che mi sono piaciute ce ne sono due in particolare.
Un terminale integrato:
https://atom.io/packages/Termrk
E un project-manager che facilita il passaggio da un progetto all’altro:
https://atom.io/packages/project-manager

Titanium CLI

Come tutti sanno dalla CLI si può fare tutto quello che si fa con Appcelerator Studio. In teoria.
Una cosa che da quanto ne so funziona su Studio ma non sulla CLI è il LiveView, o almeno a me funziona solo su Studio, quando funziona.

Per fare le build io nella mia quasi totale incapacità di scrivere per bash mi sono creato questo script, semplice ma abbastanza efficace. Non è gestito il –liveview perché tanto non funziona.

# The platform: ios or android
PLATFORM=$1
if [ "$PLATFORM" == "" ]; then
	PLATFORM="android"
fi

# The target: device, simulator (ios) or emulator (android)
TARGET=$2
if [ "$TARGET" == "" ]; then
	TARGET="device"
fi

# Y for choosing destination, N for the default
CHOICE=$3
if [ "$CHOICE" == "" ]; then
	CHOICE="N"
fi

if [ "$CHOICE" == "Y" ]; then
	appc ti build --platform $PLATFORM --log-level debug --target $TARGET --skip-js-minify --device-id
else
	appc ti build --platform $PLATFORM --log-level debug --target $TARGET --skip-js-minify
fi

Per fare i deploy (ipa e apk) invece mi sono fatto questo script, forse anche più brutto del precedente:

SRC_PROJECT_NAME="My Project"
DEST_FILE_NAME="MyProject"
OUTPUT_DIR=~/Documents/$DEST_FILE_NAME
ANDROID_OUTPUT_DIR=build/android/bin
IOS_DIST_NAME="My company"
IOS_DIST_UUID="................"

mkdir -p $OUTPUT_DIR

appc ti build --platform ios --build-only --force --log-level info --device-family ipad --target dist-adhoc --distribution-name $IOS_DIST_NAME --pp-uuid $IOS_DIST_UUID --output-dir $OUTPUT_DIR
mv $OUTPUT_DIR"/$SRC_PROJECT_NAME.ipa" $OUTPUT_DIR"/$DEST_FILE_NAME.ipa"

appc ti build --platform android --build-only --force --log-level info
cp $ANDROID_OUTPUT_DIR"/$SRC_PROJECT_NAME.apk" $OUTPUT_DIR"/$DEST_FILE_NAME.apk"

Conclusioni

Appcelerator sembra sulla via del tramonto, opinione diffusa anche nella community. L’aumento di stabilità su Android negli ultimi mesi/anni è evidente e le prestazioni non sono malaccio, ma l’esperienza di sviluppo è pessima rispetto ad altre piattaforme, e il quasi totale abbandono della “gratuità” di sei mesi fa le hanno fatto fare dei passi indietro tra le preferenze degli sviluppatori.
Forse si riprenderanno o forse no, resta il fatto che iniziare a utilizzare con profitto strumenti più generici e utilizzabili anche in altri ambiti può non essere una cattiva idea.
Magari dobbiamo continuare a usare l’SDK di Titanium sui nostri progetti, ma fortunatamente (ancora) nessuno ci obbliga a utilizzare tutti gli strumenti di sviluppo di Appcelerator.

Non potete considerarvi veri uomini se non vi piace il vi(m)

Lascia una risposta

A chi fa questo mestiere prima o poi capita di doversi collegare con un server su cui non si ha a disposizione un’interfaccia grafica (o semplicemente non la si può usare), magari per correggere al volo un bug grave su un sito pubblicato, e non sempre si può usare WinSCP o copiarsi i file via ssh utilizzando FileZilla e poi ricopiarli sul server, anche perché si rischia di incasinare i permessi dei file e di creare problemi ben più gravi.

Nei sistemi Unix-like – oggigiorno Linux e OSX se non si è dei sistemisti esperti o non si lavora in ambienti strani – a volte è disponibile nano, che tutto sommato è “abbastanza user-friendly” ma potrebbe non essere stato installato e potremmo non avere i permessi per poterlo installare.

GNU nano editor, troppo lusso in alcuni casi

Un’alternativa che c’è sempre o quasi è il VI(M), un po’ ostile e apparentemente scarsissimo di funzionalità, ma adorato da molti guru e forse a ragione.
Quasi sempre è già installato VIM (VI iMproved), ed eseguendo il comando vi nomefile viene aperto proprio il vim, ma i due si somigliano e la maggior parte dei comandi sono uguali.
Nei giorni scorsi in azienda hanno proposto agli interessati un corso interno per migliorare le nostre competenze in ambiente Linux, e uno degli argomenti era proprio vim, quindi mi segno qui i comandi che mi sono sembrati più utili.

Breve prontuario per novizi

Di comandi ce ne sono una marea, e se siete uno sviluppatore che intende usarlo nel lavoro di tutti i giorni forse vi conviene studiarveli per sfruttare appieno la sua potenza. Per le persone normali invece dovrebbe bastare questo piccolo vademecum, anche perché la stessa cosa si può fare combinando vari comandi, quindi non serve saperli tutti (al massimo si va più lenti).

Parametri di avvio

-v : modalità vi (senza funzionalità aggiuntive di vim)
-d : modalità differenze (vi -d file1 file2)
-M : modalità sola lettura, se avete paura (a ragione) di fare danni

Se si è presi dal panico

ESC : esce dalla modalità attuale (molto utile premerlo a ripetizione se si è in stato di panico)
:q! : esce senza salvare (altra sequenza molto importante se non si sa bene cosa si è fatto)
u : undo (annulla)
ctrl+r : redo (ri-esegue eventuali modifiche annullate)

Modalità

ESC : esce dalla modalità attuale
i : modalità inserimento
o : aggiunge una riga dopo quella attuale e vi entra in modalità inserimento
r : in inserimento, ma con sostituzione del carattere su cui si è

Movimento

h j k l: sinistra, giù, su, destra (comodo se si vuole fare tutto con una mano, ma di solito anche le frecce funzionano)
0 : inizio della riga corrente
$ : fine della riga corrente (non a caso il dollaro viene usato per rappresentare i fine linea)
:num_riga : si sposta sulla riga specificata
G : si sposta sull’ultima riga

Funzioni di uscita e salvataggio

:q : esce
:wq : esce salvando
:q! : esce senza salvare
:w : salva

Funzioni di copia-taglia-incolla

y : copia la riga corrente
d d (doppia d veloce) : taglia la riga corrente
num_righe d d : taglia il numero di righe specificate numero di righe seguite da doppio “d”
p : incolla

Ricerca e sostituzione

/string : ricerca la stringa “string” (con il tasto n ci si può spostare sui successivi, con N sui precedenti)
:%s/string1/string2/g : sostituisce “string1” con “string2”

Comandi informativi

:set list : visualizza tabulazioni e caratteri di fine linea (:set nolist per annullare la visualizzazione)
:f : visualizza nome del file e posizione all’interno del file (numero di riga, di colonna e percentuale)

Conclusioni

Essendo vim un editor tutto basato su comandi da tastiera richiede una buona memoria e molta pratica per essere utilizzato con un’adeguata velocità, ma fortunatamente insieme al vim c’è sempre installato anche vimtutor, una “guida testuale interattiva” fatta per esercitarsi con i comandi più utili di vim.

vim tutor

Sarà brutto, sarà ostile, ma sviluppatori e sistemisti non possono non conoscere un po’ un editor sempre disponibile e tutto sommato potente come vi(m), quindi è imperativo imparare almeno una decina dei comandi più utili e provare a usarli quando se ne ha l’occasione… se non altro nella selva di editor e ide che nascono e muoiono alla velocità della luce questo sta in piedi da quasi quarant’anni e non sente nemmeno il peso della vecchiaia.

Tempo di migrazioni: trasformare un repository da svn a git

Lascia una risposta

Un paio di giorni fa ho finalmente deciso di buttare a mare un vecchio repository svn per abbracciare git anche nell’ultimo progetto dove non lo utilizzavo, ecco quindi un sintetico tutorial su come trasformare un repository svn in repository git. Da parte mia ho seguito il tutorial di Atlassian, che però è abbastanza lungo e non tutti i passi erano necessari al mio scopo: trasformare un repository svn in repository git, una volta e per sempre, abbandonando poi il vecchio repository ma mantenendo tutto lo storico e gli utenti del vecchio repository.

Lo strumento

Di modi per fare questa trasformazione ce ne saranno parecchi, io ho usato il svn-migration-scripts.jar messo a disposizione da Atlassian, un classico eseguibile Java.
Scaricatelo e mettetelo nella home o dove preferite, ma tenente presente che i comandi seguenti sono stati scritti avendo il jar nella home dell’utente.

La preparazione

Detto che una migrazione andrebbe fatta in un momento idoneo possibilmente durante il quale il repository origine rimarrà inalterato, che dovrebbe essere eseguita da chi di dovere, e che se si vuole velocizzare le operazioni bisognerebbe lavorare sulla stessa macchina del repository svn o quantomeno nella stessa lan, ipotizziamo che sia tutto a posto e iniziamo.

Per prima cosa bisogna verificare le precondizioni, ovvero accertarsi che sul sistema ci sia tutto il necessario per eseguire la conversione.
Eseguendo il jar con il parametro “verify” viene controllato il sistema con stampa a video delle eventuali mancanze.
java -jar ~/svn-migration-scripts.jar verify
Se state eseguendo la migrazione su un Mac bisogna prima creare e montare un disco case-sensitive, sul quale sarà creato il nuovo repository:
java -jar ~/svn-migration-scripts.jar create-disk-image 5 GitMigration
L’esecuzione di questo comando crea un disco chiamato “GitMigration”

Mapping degli utenti

Nel vecchio repository i commit erano associati a utenti identificati da un nome, ma su git gli utenti sono identificati da nome e email. Andiamo quindi a creare – dentro il disco virtuale creato al passo precedente – un file authors.txt contenente il mapping tra vecchi e nuovi utenti.
cd GitMigration
java -jar ~/svn-migration-scripts.jar authors svn://repository_url/repository_name > authors.txt
Questo crea un file di mapping contente sulla sinistra i nomi degli utenti presenti sul vecchio sistema, e sulla destra i nomi e le email da usare sul nuovo sistema. Naturalmente quelli di destinazione sono solo ipotesi, e infatti le email sono di pura invenzione (le email sono tutte nella forma “username@mycompany.com”). Andiamo quindi a sostituire le email e se vogliamo i nomi degli utenti, salviamo e passiamo al punto successivo.

Clonazione del repository

È finalmente giunto il momento della trasformazione… ma qui lo script di Atlassian ci abbandona e il git inizia a farla da padrone.
Se il repository svn di partenza ha una struttura standard, con un “trunk” contenente il codice del ramo principale, una cartella “tags” contenente tutti i tags e così via possiamo lanciare il comando seguente, con parametro “stdlayout”.
git svn clone --stdlayout --authors-file=authors.txt svn://repository_url/repository_name new_repository_name
Se al contrario abbiamo una struttura non così standard possiamo andare a specificare dove devono essere letti i dati relativi a trunk, branches e tags. Nel mio caso il trunk non era presente perché i sorgenti del ramo principale erano semplicemente in una cartella nella root del repository, quindi non ho potuto usare il parametro “–stdlayout” e ho dovuto specificare le destinazioni delle varie cartelle.
git svn clone --trunk=/folderName --branches=/branches --tags=/tags --authors-file=authors.txt svn://repository_url/repository_name new_repository_name

La trasformazione generalmente richiede alcuni minuti, pochi se avete solo qualche centinaio di commit e siete in lan (o meglio ancora sulla stessa macchina del repository), molti di più se state lavorando con un repository enorme che risiede dall’altra parte del mondo.
Al termine dell’esecuzione nel disco virtuale “GitMigration” comparirà il neonato repository git, ovvero una cartella contenente i sorgenti e tutti i dati necessari a git (la cartella nascosta .git).

Pulizia del repository git

Il repository git creato al passo precedente è ancora “collegato” a svn, infatti l’origin punta al vecchio repository e tutto è “costruito” in modo da poter continuare a centralizzare i commit sul vecchio repository.
Se il nostro obiettivo è quello di tagliare i ponti con il passato, abbandonare svn e creare un nuovo origin git, quello che dobbiamo fare ora è lanciare lo script necessario per trasformare branches e tags nel classico formato git.
java -Dfile.encoding=utf-8 -jar ~/svn-migration-scripts.jar clean-git --force

Creazione di un nuovo origin

La trasformazione è ormai compiuta e non ha più senso mantenere nel nuovo repository un riferimento al vecchio repository svn, conviene quindi eliminare l’origin e crearne uno nuovo.
Andiamo quindi a creare sul server più adatto a mantenere una copia dei nostri sorgenti un repository git.
Spostiamoci sul server, creiamo una cartella repository_name.git, settiamone i permessi/gruppi/proprietario, e inizializziamo il repository con il comando git init --bare repository_name.git.
A questo punto non resta altro da fare che modificare l’origin del repository git sostituendo l’url del vecchio repository svn con quello del repository remoto appena creato (utilizzando il protocollo che riteniamo più adatto, nel mio caso l’ssh), eseguire il primo push e il gioco è fatto.

Come server dei sorgenti nessuno ci vieta di utilizzare servizi web come BitBucket o GitHub, ma se il cloud vi fa paura un server linux in locale va benissimo, anche perché essendo git un sistema decentralizzato e distribuito eventuali problemi al server non sarebbero la fine del mondo.

Se al termine qualcosa non vi torna (ad esempio non riuscite a togliere il vecchio origin come è successo a me) un nuovo clone del repository remoto non guasta, anche per verificare che sul server sia tutto a posto.

Conclusioni

Nessuno ci obbliga a sostituire il sistema che usiamo per fare il versioning dei nostri progetti, ma se inizierete a usare git vedrete che il gioco vale la candela e presto o tardi ne sentirete la mancanza quando dovrete tornare all’svn o peggio a sistemi ancora più vecchi. Si può decidere di trasformare il repository in git continuando a mantenere svn sul server, ma secondo me se si decide di cambiare conviene farlo in modo netto, e con i semplici passi che ho elencato la transizione dovrebbe essere veloce e indolore.

Quando tutto sembra perduto: git reflog

Lascia una risposta

Un paio di giorni fa ho avuto modo di usare una delle funzioni più belle di git, e siccome non tutti la conoscono credo sia il caso di celebrarla un po’ perché mi ha salvato qualche ora di lavoro.
Piccola premessa: ho iniziato a mettere le mani su un progetto mai visto prima e il log di git era abbastanza ordinato, quindi per fare la mia parte ho fatto un branch per la funzione che dovevo aggiungere e avevo intenzione di fare un merge e push sull’origin al termine della modifica. Non sono ancora un utilizzatore di git esperto, quindi a volte faccio delle cavolate…

Ipotizziamo di avere un progetto già avviato con alcuni commit (nel mio esempio uno), e di voler aggiungere una funzionalità. Come consigliato dal galateo facciamo un nuovo branch, ci spostiamo su di esso, facciamo dei commit (possibilmente autoconsistenti e che non rompano niente) e concludiamo la modifica.

Arriva il momento di fare il merge. Ipotizziamo di aver sbagliato qualcosa, magari perché stiamo usando un tool grafico poco chiaro, e ci ritroviamo con un po’ di leggerezza a cancellare il branch con un bel "git branch -D nomebranch".
Apparentemente tutto il nostro lavoro è andato perduto e lo scoramento ci assale mentre dalla nostra bocca esce un fiume di bestemmie e parole sconce.

Quando tutto sembra perduto ci ricordiamo di aver letto che con git non si perde mai niente, perché all’occorrenza esiste anche un log parallelo al principale a cui poter attingere nei momenti di difficoltà: il reflog.
Digitiamo "git reflog" e vediamo con nostro grande sollievo che i nostri commit fatti sul branch andato perso sono ancora tutti lì in memoria, e volendo possiamo recuperarli.
Un "git reset --hard HEAD@{index}" e come per magia ritroviamo nel nostro log principale tutti i commit che erano presenti nel branch tagliato per errore.

Siccome siamo precisi a questo punto non possiamo non domandarci “Ma i commit non li avevo fatti un un branch secondario? Come mai me li ritrovo sul master?”.
Infatti il reset hard fatto poc’anzi salva i commit ma li mette nel master perché non sono collegati ad alcun ramo, volendo si può far eseguire il ripristino su un ramo secondario, magari chiamandolo con il nome di quello tagliato erroneamente: "git branch nomeramo HEAD@{index}"

La storia è importante e non va mai dimenticata. Git lo sa, e con il reflog ci fornisce uno strumento salvifico da utilizzare nei momenti più difficili.

Titanium Studio e GIT, integrato (a volte) è meglio

Lascia una risposta

Sviluppatori: ognuno con le sue convinzioni e il suo credo

Gli sviluppatori mobile con Titanium si dividono in due scuole di pensiero: chi utilizza Titanium Studio e chi preferisce usare un ide meno pompato e la console. Io appartengo ancora alla prima categoria, principalmente perché mi districo male tra molte finestre e preferisco avere sempre tutto sotto controllo mentre lavoro. L’idea di passare a Sublime o Atom in combinazione eventuale con strumenti esterni mi ha tentato, ma ancora non ho raccolto gli stimoli sufficienti.

Il problema è che Titanium non è il solo strumento che contribuisca a dividerci in caste, perché anche GIT non scherza. I puristi conoscono tutti i comandi con relativi parametri a memoria e utilizzano soltanto la console, i pigri/smemorati come me si affidano a strumenti un po’ più “smart” e ricorrono alla console solo in casi di emergenza o come esercizio di memoria. Personalmente io uso alternativamente la console, il plugin integrato nell’ide e SourceTree, un gestore di repository GIT veramente ben fatto.

SourceTree, e GIT non sarà più così ostico

La I di IDE sta per “Integrated”…

Fatte queste distinzioni è ora di arrivare al dunque: perché questo articolo? Il punto è che non sarebbe male utilizzare nel proprio ambiente di sviluppo un plugin che ci aiuti ad avere sempre sotto controllo tutte le modifiche fatte ai nostri sorgenti. Eclipse ha degli showview integrati (History e Synchronize) con cui poter vedere lo storico e lo stato attuale delle modifiche, ma in Titanium questi non funzionano con GIT. Infatti l’ide Titanium Studio ha un suo plugin per GIT (com.aptana.git), che però si integra malissimo con Eclipse e secondo me è praticamente inutile.

Come guardare il dettaglio dei plugin installati

Aptana Git, per la serie: meglio soli che mal accompagnati

L’amato/odiato Eclipse ha un suo plugin per gestire decentemente il repository GIT (EGit), ma non viene fornito con Titanium Studio e fa a cazzotti con quello installato di default.
Il mio consiglio è quindi quello di disabilitare il plugin di Aptana e utilizzare EGit, e ora vi mostro come fare.

Installazione e utilizzo di EGit su Titanium Studio

Punto 1: Per prima cosa conviene dire a Eclipse di non utilizzare più il plugin di Aptana per gestire i nuovi progetti GIT aggiunti nel workspace. Questa cosa la si fa dalla pagina delle preferenze di Eclipse.

Disabilitazione di Aptana Git per i nuovi progetti

Punto 2: Se volete usare su Eclipse un plugin non fornito di default (in questo caso EGit) bisogna installarcelo. La procedura è sempre la stessa e ne avevo parlato in modo un po’ più dettagliato su un precedente articolo (a proposito di SVN su Eclipse).

Installazione di EGit

Punto 3: Nel caso abbiate già dei progetti che utilizzano GIT come VCS all’interno del vostro workspace questi continueranno a usare il vecchio plugin. Scollegateli da esso e fate in modo che usino il nuovo plugin.

Disconnessione di progetti esistenti da Aptana Git

Connessione di EGit ai progetti git precedentemente scollegati da Aptana Git

Il Synchronize di Eclipse, uno dei miei strumenti preferiti del mio IDE preferito

Eclipse ha molte funzioni, ma una delle mie preferite e indipendenti dal VCS utilizzato (GIT, SVN, …) è la view Synchronize, che mostra l’elenco dei file modificati rispetto al repository (e all’origin nel caso del GIT) e da la possibilità di modificarli facilmente con una finestra di comparazione. Funzione fondamentale in un ambiente di sviluppo integrato degno di questo nome.

Conclusioni

Si può usare un ide o qualunque editor di testo in combinazione con tool esterni, l’importante è avere sempre sotto mano tutte le funzioni di cui si ha bisogno. Titanium Studio per usare un eufemismo non è che sia proprio performante, ma è basato su quel mostro di configurabilità ed estendibilità che è Eclipse, conviene quindi sfruttare al meglio le sue peculiarità installando all’occorrenza ciò che manca.

Il passato che avanza: SVN su Eclipse

Lascia una risposta

Articolo forse un po’ anacronistico, ma tutte le volte che devo collegarmi a un repository SVN con Eclipse o uno dei suoi tanti figli (come ad esempio Titanium Studio), non mi ricordo mai di preciso dove trovare l’apposito plugin.

Detto che nel 2015 è possibile e forse doveroso trasferire i propri sorgenti su un VCS distribuito in stile GIT, anziché continuare a tenerli su un sistema centralizzato, è anche vero che in alcuni casi questo passaggio non si può fare.
Di client SVN ce ne sono tanti, per Windows uno dei più diffusi è TortoiseSVN, ma parlando di plugin per Eclipse (che non ha un client SVN integrato) la strada è più o meno obbligata.

L’installazione di plugin su Eclipse

Senza andarsi a sporcare le mani con file e directory di Eclipse, ci sono due modi per installare dei plugin dall’interno di Eclipse: il menù “Install New Software” e il vicino “Eclipse Marketplace”.

Il menù help con le voci per l’installazione di plugin

Il Marketplace – presente sulle versioni standard di Eclipse – è il modo più semplice per trovare plugin sicuramente funzionanti e di buon livello, ma purtroppo non è sempre presente in Eclipse. Infatti in alcune versioni modificate (vedi Titanium Studio) questa voce di menù non c’è proprio. Se siamo in uno di questi casi o se il plugin che ci interessa non è disponibile sul Marketplace, si può ricorrere al più spartano “Install new software”.

Maschera di installazione di plugin su Titanium Studio, identica nell’Eclipse standard

Il funzionamento è abbastanza ovvio, su “Name” si inserisce un nome identificativo della risorsa, su “Location” l’url al quale si trova il plugin.
Una volta registrata la location, nella maschera sottostante rimane da mettere le spunte sui componenti (eventuali) che si desidera installare e confermare l’installazione.

Installazione di Polarion Subversive

Il client SVN installabile su Eclipse che la fa da padrona è il Subversive SVN. Scaricabile dal Marketplace, è però disponibile anche per l’installazione manuale.
Nella pagina qui sopra ci sono tutti i link necessari, ma per farvela più semplice le cose che dovete installare sono due:
http://download.eclipse.org/technology/subversive/2.0/update-site/ – [required] Subversive plug-in
http://community.polarion.com/projects/subversive/download/eclipse/4.0/update-site/ – [required] Subversive SVN Connectors

Le cose che dovreste avere installate a questo punto per far funzionare SVN

Il connettore da usare dipende dal server, nel dubbio installateli tutti. Si può scegliere quale utilizzare anche successivamente.

Selezione del connettore da utilizzare

Primi passi con il plugin

Siamo nel 2015, GIT esiste da un pezzo, e creare nuovi repository SVN equivale a incastrarsi le palle nel cassetto. Quindi se siete arrivati in questo punto probabilmente vi interessa solo collegarvi a repository già esistenti.
Aggiungete quindi la view “SVN Repositories” da qualche parte sul vostro Eclipse (Window -> Show View -> Other -> SVN -> SVN Repositories), e registrate una “repository location”.

Maschera per la registrazione di un repository già esistente

A questo punto selezionate all’interno del repository ciò che vi interessa (generalmente un progetto) e fatene il checkout.
Essendo il progetto pieno di cartelline nascoste .svn, Eclipse capisce che si tratta di un lavoro sotto SVN e nella voce di menù “Team” aggiunge tutti gli strumenti propri di SVN.

Per finire

Se non avete mai usato SVN e non avete ancora messo i vostri sorgenti sotto controllo di versione ignorate tutto quanto letto fin qui e studiatevi direttamente GIT.