Here’s the patch you need to fix the plugin:

diff -r redmine-mylyn-connector-2.7.5/app/controllers/mylyn_connector/issues_controller.rb redmine-mylyn-connector-2.7.5-patched/app/controllers/mylyn_connector/issues_controller.rb

63c63

< :conditions => ["#{Issue.table_name}.id in (?) and #{Issue.table_name}.updated_on >= ? and " < < Project.visible_by, issues, cond]

---

>       :conditions => ["#{Issue.table_name}.id in (?) and #{Issue.table_name}.updated_on >= ? and " < < Project.visible_condition(User.current), issues, cond]

79c79

<       :conditions => ["#{Issue.table_name}.id in (?) and " < < Project.visible_by, issues]

---

>       :conditions => ["#{Issue.table_name}.id in (?) and " < < Project.visible_condition(User.current), issues]

diff -r redmine-mylyn-connector-2.7.5/app/controllers/mylyn_connector/projects_controller.rb redmine-mylyn-connector-2.7.5-patched/app/controllers/mylyn_connector/projects_controller.rb

16c16

<       :conditions => [ "enabled_modules.name = 'issue_tracking' AND #{Project.visible_by}"])

---

>       :conditions => [ "enabled_modules.name = 'issue_tracking' AND #{Project.visible_condition(User.current)}"])

diff -r redmine-mylyn-connector-2.7.5/app/controllers/mylyn_connector/queries_controller.rb redmine-mylyn-connector-2.7.5-patched/app/controllers/mylyn_connector/queries_controller.rb

18c18

< :conditions => ["(#{Query.table_name}.is_public = ? OR #{Query.table_name}.user_id = ?) AND (project_id IS NULL OR "  < < Project.visible_by << ")", true, User.current.id],

---

>       :conditions => ["(#{Query.table_name}.is_public = ? OR #{Query.table_name}.user_id = ?) AND (project_id IS NULL OR "  < < Project.visible_condition(User.current) << ")", true, User.current.id],

L’installazione è stata effettuata su un server virtuale pulito Ubuntu server 10.04 x86_64. Ho provato ad utilizzare RVM e ruby 1.9.2 ma non ci sono riuscito… Ho quindi utilizzato Ruby Enterprise Edition 1.8.7

Per cominciare ho installato un po’ di pacchetti:

apt-get install build-essential zlib1g-dev tcl-dev libexpat-dev libcurl4-openssl-dev postfix apache2 mysql-server mysql-client apg geoip-bin libgeoip1 libgeoip-dev libaspell-dev aspell sqlite3 libsqlite3-dev imagemagick libpcre3 libpcre3-dev zlib1g zlib1g-dev libyaml-dev libmysqlclient15-dev apache2-dev libonig-dev libmagick++-dev zip unzip memcached git-core git-svn git-doc git-cvs irb sphinxsearch uuid uuid-dev openjdk-6-jre

Ho scaricato e installato ActiveMQ 5.5.0:

wget http://www.powertech.no/apache/dist/activemq/apache-activemq/5.5.0/apache-activemq-5.5.0-bin.tar.gz
sudo -s
tar xzvf apache-activemq-5.5.0-bin.tar.gz -C /usr/local/
echo "export ACTIVEMQ_HOME=/usr/local/apache-activemq-5.5.0" >> /etc/activemq.conf
echo "export JAVA_HOME=/usr/" >> /etc/activemq.conf
dduser --system --no-create-home activemq
chown -R activemq /usr/local/apache-activemq-5.5.0/data

Per lanciare ActiveMQ ho utilizzato questo file, copiato in /etc/init.d:

wget http://www.tommyblue.it/wp-content/uploads/2011/06/activemq.txt
sudo mv activemq.txt /etc/init.d/activemq
sudo chmod +x /atc/init.d/activemq
sudo update-rc.d activemq defaults
sudo service activemq start

A questo punto ho scaricato da qui REE e l’ho installato:

sudo dpkg -i ruby-enterprise_1.8.7-2011.03_amd64_ubuntu10.04.deb

dopodichè ho installato RubyGems. Come dicevo prima non sono riuscito ad utilizzare RVM proprio a causa di problemi con le gemme. Per far funzionare il tutto ho dovuto installare tutte le gemme da root:

wget http://production.cf.rubygems.org/rubygems/rubygems-1.8.5.tgz
tar xzf  rubygems-1.8.5.tgz
cd rubygems-1.8.5/
sudo ruby setup.rb
echo "gem: --no-ri --no-rdoc" > ~/.gemrc

Installato RubyGems bisogna installare le gemme. ATTENZIONE: se fin qui ho più o meno seguito le guide che trovate nella webografia, per le gemme ho fatto tutt’altro. Infatti per far funzionare Gitorious, che è scritto con Rails 2.3.x, non è possibile installare le gemme as is dato che molte sono ormai incompatibili con Rails 2. Meglio far fare tutto a Bundler o specificare gemma per gemma la versione da installare. Quindi prima cloniamo il repository di Gitorious:

sudo -s
git clone git://gitorious.org/gitorious/mainline.git /var/www/gitorious
cd /var/www/gitorious
gem install bundler
bundle install
gem install -b -v 1.1 stomp
gem install rmagick passenger stompserver raspell
gem install -v=0.8.7 rake
passenger-install-apache2-module

Al termine dell’ultimo passaggio creare il file /etc/apache2/mods-available/passenger.load con quanto suggerito dallo script precedente. Nel mio caso:

LoadModule passenger_module /usr/local/lib/ruby/gems/1.8/gems/passenger-3.0.7/ext/apache2/mod_passenger.so
PassengerRoot /usr/local/lib/ruby/gems/1.8/gems/passenger-3.0.7
PassengerRuby /usr/local/bin/ruby

Per attivare il modulo:

a2enmod passenger
a2enmod rewrite
a2enmod ssl
a2enmod expires
service apache2 restart

Ok, adesso ho copiato i necessari script di avvio:

cp /var/www/gitorious/doc/templates/ubuntu/git-daemon /etc/init.d/
cp /var/www/gitorious/doc/templates/ubuntu/git-ultrasphinx /etc/init.d/

In /etc/init.d/git-daemon modificare GIT_DAEMON come segue:

GIT_DAEMON="/usr/bin/local/ruby /var/www/gitorious/script/git-daemon -d"

Creare anche /etc/init.d/stomp:

#!/bin/sh
# Start/stop the stompserver
#
### BEGIN INIT INFO
# Provides:          stomp
# Required-Start:    $local_fs $remote_fs $network $syslog
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      1
# Short-Description: Stomp
# Description:       Stomp
### END INIT INFO   

test -f /usr/local/bin/stompserver || exit 0    

. /lib/lsb/init-functions    

case "$1" in
start)  log_daemon_msg "Starting stompserver" "stompserver"
    start-stop-daemon --start --name stompserver --startas /usr/local/bin/stompserver --background --user git
    log_end_msg $?
    ;;
stop)  log_daemon_msg "Stopping stompserver" "stompserver"
    start-stop-daemon --stop --name stompserver
    log_end_msg $?
    ;;
restart) log_daemon_msg "Restarting stompserver" "stompserver"
    start-stop-daemon --stop --retry 5 --name stompserver
    start-stop-daemon --start --name stompserver --startas /usr/local/bin/stompserver --background --user git
    log_end_msg $?
    ;;
status)
    status_of_proc /usr/local/bin/stompserver stompserver && exit 0 || exit $?
    ;;
*)      log_action_msg "Usage: /etc/init.d/stomp {start|stop|restart|status}"
    exit 2
    ;;
esac
exit 0

e /etc/init.d/git-poller:

#!/bin/sh
# Start/stop the git poller
#
### BEGIN INIT INFO
# Provides:          git-poller
# Required-Start:    stomp
# Required-Stop:
# Default-Start:     2 3 4 5
# Default-Stop:      1
# Short-Description: Gitorious poller
# Description:       Gitorious poller
### END INIT INFO    

/bin/su - git -c "cd /var/www/gitorious;RAILS_ENV=production script/poller $@"

Si possono quindi aggiungere tutti all’avvio:

chmod 755 /etc/init.d/git-ultrasphinx /etc/init.d/git-daemon /etc/init.d/stomp /etc/init.d/git-poller
update-rc.d stomp defaults
update-rc.d git-daemon defaults
update-rc.d git-ultrasphinx defaults
update-rc.d git-poller defaults

Bisogna creare la configurazione di apache. Gitorious utilizza SSL per il login, quindi i VirtualHost sono 2, io ho creato il file /etc/apache2/sites-available/gitorious:

<VirtualHost *:80>
  ServerName MIODOMINIO
  DocumentRoot /var/www/gitorious/public
</VirtualHost>
<IfModule mod_ssl.c>
  <VirtualHost _default_:443>
    ServerName MIODOMINIO
    DocumentRoot /var/www/gitorious/public
    SSLEngine on
    SSLCertificateFile /etc/ssl/certs/ssl-cert-snakeoil.pem
    SSLCertificateKeyFile /etc/ssl/private/ssl-cert-snakeoil.key
    BrowserMatch ".*MSIE.*" nokeepalive ssl-unclean-shutdown downgrade-1.0 force-response-1.0
  </VirtualHost>
</IfModule>

e quindi l’ho attivato:

a2dissite default
a2ensite gitorious

Torniamo a Gitorious che abbiamo un po’ lasciato indietro. Serve un utente git che sarà il proprietario dell’applicazione:

adduser --system --home /var/www/gitorious/ --no-create-home --group --shell /bin/bash git
chown -R git:git /var/www/gitorious
su - git
cd /var/www/gitorious
mkdir .ssh
touch .ssh/authorized_keys
chmod 700 .ssh
chmod 600 .ssh/authorized_keys
mkdir -p tmp/pids repositories tarballs
cp config/database.sample.yml config/database.yml
cp config/gitorious.sample.yml config/gitorious.yml
cp config/broker.yml.example config/broker.yml

Modificare config/database.yml lasciando soltanto la sezione production e le sue configurazioni. Inserire un utente MySQL con permessi sul database gitorious_production (se non volete creare a mano questo db utilizzate un utente in grado di creare database). Nel file config/gitorious.yml inserite:

production:
  cookie_secret: "FRASESEGRETISSIMAELUNGHISSIMA"
  repository_base_path: "/var/www/gitorious/repositories"
  gitorious_client_port: 80
  gitorious_client_host: gitorious.dw
  gitorious_host: gitorious.dw
  archive_cache_dir: "/var/www/gitorious/tarballs"
  archive_work_dir: "/tmp/tarballs-work"
  hide_http_clone_urls: true
  is_gitorious_dot_org: false

Per il valore di cookie_secret utilizzate l’output del comando apg -m 64.
Ho avuto dei problemi con ActiveSupport, del tipo:

uninitialized constant ActiveSupport::Dependencies::Mutex (NameError)

come suggerito qui li ho superati inserendo require ‘thread’ in config/boot.rb dopo RAILS_ROOT.

A questo punto si può procedere con la migrazione:

su - git
cd /var/www/gitorious
export RAILS_ENV=production
rake db:create
rake db:migrate
rake ultrasphinx:bootstrap

L’ultimo comando dovrebbe restituire un errore ma comunque crea il file di configurazione, che va editato per evitare l’errore. Il file è  config/ultrasphinx/production.conf in cui va sostituito base_tags con tags. Effettuata la sostituizione su può lanciare Sphinx con:

rake ultrasphinx:index RAILS_ENV=production
rake ultrasphinx:daemon:start RAILS_ENV=production

Per l’aggiornamento degli indici ho creato il file /etc/cron.d/ultrasphinx:

* */1 * * *       git     cd /var/www/gitorious && /usr/local/bin/rake ultrasphinx:index RAILS_ENV=production

Prima di accedere a Gitorious bisogna creare l’utente admin lanciando, come git, il comando:

env RAILS_ENV=production ruby script/create_admin

Riavviamo i servizi (ed eventualmente il server per essere sicuri che al riavvio Gitorious funzioni correttamente):

service git-daemon start
service apache2 restart

Colleghiamoci al sito e, se tutto è andato bene, iniziamo ad utilizzare Gitorious!

Resta un’ultima cosa da fare per poter pushare correttamente, ovvero creare un link simbolico al file /var/www/gitorious/script/gitorious in una cartella presente nella PATH dell’utente git, io l’ho creato in /usr/local/bin:

ln -s /var/www/gitorious/script/gitorious /usr/local/bin/

Senza questo passaggio al momento del push ottenevo un singolare quanto criptico errore da git:

bash: gitorious: comando non trovato

Webografia

• http://www.silly-science.co.uk/2010/12/12/installing-gitorious-on-ubuntu-10-04-howto/
• http://www.gitorious.org/gitorious/pages/UbuntuInstallation
• http://cjohansen.no/en/ruby/setting_up_gitorious_on_your_own_server

Distribuisco qui le slides proiettate durante il talk: download

I passaggi sono piuttosto facili:
intanto bisogna collegarsi all’amministrazione di Zimbra e creare un utente nel dominio principale (nel mio caso redmine). Personalmente ho disattivato tutte le opzioni (posta, rubrica, documenti, ecc.) per questo utente, tanto serve solamente per il binding a LDAP.
Una volta creato possiamo provare che questo utente possa fare ricerche nell’albero:

ldapsearch -b ou=people,dc=tommyblue,dc=it -h zimbra.tommyblue.it -p 389 -D uid=redmine,ou=people,dc=tommyblue,dc=it -w s3cr3t uid

Se la ricerca funziona avete finito con Zimbra e potete passare a Redmine. Qui bisogna andare in Autenticazione LDAP e inserire i dati in questo modo:

• Nome: Zimbra (è solo descrittivo)
• Host: zimbra.tommyblue.it (l’host con Zimbra)
• Porta: 389
• Utente: uid=redmine,ou=people,dc=tommyblue,dc=it
• Password: s3cr3t
• DN Base: ou=people,dc=tommyblue,dc=it
• Creazione utente “al volo”: no
• Utente: uid
• Nome: givenName
• Cognome: sn
• Email: mail

Ecco uno screenshot per rendere il tutto più chiaro:

Per finire dovete creare un utente in Redmine selezionando come Modalità di Autenticazione quella appena creata e non quella interna.

Ovviamente è possibile replicare il procedimento per qualunque albero LDAP abbiate a disposizione.

Supponendo che abbiate già installato Rubygems, installare RVM è praticamente immediato:

~# gem install rvm
~# rvm-install

A questo punto si può installare una qualsiasi versione di Ruby con:

~# rvm install 1.9.2-head

e switchare tra le versioni con:

~# rvm use 1.9.2-head
~# ruby -v
ruby 1.9.2dev (2010-05-07 trunk 27656) [x86_64-darwin10.3.0]
~# rvm use default
~# ruby -v
ruby 1.8.7 (2009-06-08 patchlevel 173) [universal-darwin10.0]

Attenzione che ogni nuova installazione ha le sue gemme, quindi sarà necessario installare quelle richieste, nel mio caso, volendo utilizzare Ruby 1.9.2 per provare Rails 3:

~# rvm use 1.9.2-head
~# gem install tzinfo builder memcache-client rack rack-test rack-mount erubis mail text-format thor bundler i18n
~# gem install rails --pre

Leggi anche: Le magie di RVM

Unicorn

L’installazione di Unicorn si fa “di tacco” (per una descrizione più dettagliata leggete il vecchio post), basta un semplice:

gem install unicorn

Per le applicazioni anzichè farle rispondere su socket tcp ho deciso di utilizzare le socket Unix (posiziondole in /tmp), quindi il comando completo (da lanciare dentro la root dell’applicazione Rails) è:

unicorn_rails -D -E production -l /tmp/kickin.kreations.it.sock

ovvero lancio unicorn in modalità demone (-D), con l’environment production (-E production) e sulla socket /tmp/kickin.kreations.it.sock (-l /tmp/kickin.kreations.it.sock). Per la lista completa delle opzioni c’è il solito -h :)

Per rendere tutto automatizzato ho creato (in stile apache2) la cartella /etc/unicorn con dentro le cartelle sites-available e sites-enabled. Il contenuto di /etc/unicorn/sites-available/kickin.kreations.it è:

#!/bin/bash
cd /var/www/tommyblue/kickin.kreations.it
su tommyblue -c "unicorn_rails -D -E production -l /tmp/kickin.kreations.it.sock"

Quindi il file /etc/init.d/unicorn_rails:

#! /bin/sh
PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
DAEMON=/usr/bin/unicorn_rails
NAME=unicorn_rails
DESC=unicorn_rails
SITES=/etc/unicorn/sites-enabled
test -x $DAEMON || exit 0
set -e
start_instances() {
   for i in `ls $sites`; do
   echo -n "Starting $i"
   $SITES/$i
   done
}
case "$1" in
  start)
    start_instances;
    ;;
  stop)
    echo -n "Stopping $DESC: "
    killall $NAME
    ;;
  *)
    N=/etc/init.d/$NAME
    echo "Usage: $N {start|stop}" >&2
    exit 1
    ;;
esac
exit 0

Ed ho quindi aggiunto lo script ai runlevel:

update-rc.d unicorn_rails defaults 99

Adesso ci si può sbizzarrire a lanciare e fermare i siti

Nginx

Installato nginx (apt-get install nginx) si passa a configurarlo. Io ho eliminato il sito di default e ho creato solo i files che mi interessavano (tanto la porta 8080 è chiusa dall’esterno quindi non ho problemi riguardo al visitare siti “imprevisti”). Ecco /etc/nginx/sites-available/kickin.kreations.it:

upstream backend {
  server unix:/tmp/kickin.kreations.it.sock;
}
server {
  listen   8080;
  server_name  kickin.kreations.it;
  access_log  /var/log/nginx/kickin.kreations.it.access.log;
  location / {
    proxy_pass http://backend;
    proxy_redirect off;
    proxy_set_header        Host    $host;
    proxy_set_header        X-Real-IP       $remote_addr;
    proxy_set_header        X-Forwarded-For $proxy_add_x_forwarded_for;
    root   /var/www/nginx-default;
    index  index.html index.htm;
    }
  error_page   500 502 503 504  /50x.html;
  location = /50x.html {
  root   /var/www/nginx-default;
  }
}

Come si vede dalla configurazione il backend utilizzato è la socket unix creata con unicorn e nginx risponde sulla porta 8080. Collegandosi al sito sulla porta 8080 (supponendo che il vostro server abbia tale porta accessibile dall’esterno) potete già constatare la riuscita del deploy. Se poi, diversamente dal mio caso, non avete apache che risponde sulla 80, vi basterà far rispondere nginx su tale porta e il gioco è fatto.

Apache

Se invece è apache che risponde sulla porta 80 è necessario questo ultimo passaggio. Innanzitutto bisogna attivare mod_proxy con:

a2enmod proxy

e quindi effettuare il reload di apache. Quindi si passa alla configurazione del sito, ecco /etc/apache2/sites-available/kickin.kreations.it (ho eliminato le righe non rilevanti):

<VirtualHost *:80>
  ServerName kickin.kreations.it
  ProxyRequests off
  ProxyPreserveHost On
  <Proxy *>
    Order deny,allow
    Allow from all
  </Proxy>
  ProxyPass / http://127.0.0.1:8080/
  ProxyPassReverse / http://127.0.0.1:8080/
</VirtualHost>

Una volta attivato il sito (con a2ensite), http://kickin.kreations.it è disponibile e funzionante!

Conclusioni

Sebbene effettuare il deploy con Unicorn non sia ancorà così agevole (e, a quanto dicono gli sviluppatori, ancora neanche troppo stabile, la versione è la 0.94.0) il risultato è veramente strabiliante. Non ho ancora provato dei test intensivi, ma la sensazione è di applicazioni molto più reattive e addirittura la generazione di un pdf che con Passenger impiegava circa 2 minuti con Unicorn viene generato in una ventina di secondi!

Termino segnalando Rainbows! Unicorn for sleepy apps and slow clients, che proverò a breve :)

Installare Unicorn è semplicissimo, basta un:

gem install unicorn

dopodichè, se si tratta di un’applicazione Rails, basta andare nella RAILS_ROOT e lanciare:

unicorn_rails

Se invece si tratta di un’applicazione non Rails il comando è:

unicorn

In entrambi i casi Unicorn fa il binding della porta 8080 su tutte le interfacce (il comportamento è comunque configurabile).

L’impressione generale è una velocità molto maggiore sia di Webrick che di Passenger. Un confronto al volo su una pagina con un tabellone da un migliaio di righe dice:

Webrick => 6131ms
Unicorn => 5698ms

Quindi circa 8% in meno.

Prossimamente approfondirò l’argomento :-)

Il primo passo è definire la localizzazione di default in conf/environment.rb:

config.i18n.default_locale = :it

Le stringhe di localizzazione vengono caricate da appositi file yaml nella cartella conf/locales/, quindi, utilizzando la lingua italiana, dobbiamo creare il file conf/locales/it.yml in questo modo:

it:
    hello_world: "Ciao Mondo!"

e analogamente il file con le traduzioni per ogni lingua che vogliamo.

Adesso le stringhe che devono essere localizzate sono fondamentalmente di due tipi:

1. Le stringhe nelle viste
2. Le stringhe che vengono visualizzate nelle viste ma sono generate al di fuori di esse, ad esempio i flash nei controller
   

Ecco come localizzare le stringhe nelle viste:

<%=t "hello_world" %>

Ovvero si utilizza un nuovo tag di stampa il cui contenuto è il placeholder che dovrà essere sostituito. Se invece ci troviamo in una situazione del genere:

<%= link_to "Hello, World!", "/somewhere" %>

la soluzione è quella di ricorrere direttamente alla classe I18n:

<%= link_to I18n.t('hello_world'), "/somewhere" %>

In questo stesso modo si possono localizzare tutte le stringhe al di fuori delle viste, ovvero il caso 2 nella lista precedente:

class ExampleController < ApplicationController
  def index
    flash[:notice] = I18n.t('hello_world')
  end
end

A questo punto manca solo un modo per modificare la localizzazione al volo.
La variabile che contiene la localizzazione attiva è I18n.locale ed è quindi necessario modificarla quando si vuole cambiare localizzazione.
Un esempio per farlo è utilizzare un apposito metodo in app/controllers/application_controller.rb:

class ApplicationController < ActionController::Base
  before_filter :set_locale
  private
    def set_locale
      I18n.locale = params[:locale] unless params[:locale].nil?
    end
end

In questo modo basta un qualsiasi link col parametro locale (ad esempio /example/index?locale=en) per modificare la lingua.

Un difetto di questa procedura è che ogni link deve contenere il parametro locale, altrimenti viene caricata la lingua di default. Una soluzione può essere quella di mettere in sessione l’ultima lingua indicata e quindi caricare la lingua dalla sessione ad ogni pagina. Il metodo può inoltre essere modificato per verificare che la localizzazione effettivamente esista.

def set_locale
  # Set session[:locale] if params[:locale] exists and is an available localization
  unless params[:locale].nil?
    session[:locale] = params[:locale] if I18n.available_locales.include? params[:locale].to_sym
  end
  # Set the locale if previously set in the session, otherwise use the default one
  I18n.locale = session[:locale] unless session[:locale].nil?
end

Una bottoniera carina per gestire il cambio di lingua può essere fatta inserendo nel layout questo codice:

<div id="flags">
   <a href="?locale=it"<%= " class=\"active\"" if I18n.locale.to_s == "it"%>><img src="/images/flags/it_IT.gif" alt="Italiano" title="Italiano"></a>
   <a href="?locale=en"<%= " class=\"active\"" if I18n.locale.to_s == "en"%>><img src="/images/flags/en_EN.gif" alt="English" title="English"></a>
 </div>

nel foglio di stile questo codice:

div#flags {
 margin: 10px;
}
div#flags a img {
 padding: 4px;
}
div#flags a.active img{
 background-image: url('/images/active_flag.png');
 background-repeat: no-repeat;
 background-position: center center;
}

ed utilizzando queste immagini:

Il risultato è questo, con la lingua attiva contornata da un alone celeste:

È sufficiente cliccare su una bandiera per attivare una diversa lingua. Su Deviant Art trovate decine di flags pack, sbizzarritevi :)

Quindi: se Ruby On Rails subito dopo il deploy con Phusion Passenger (aka mod_rails) vi saluta con un bel

Error message:
    No such file or directory - /nonexistent
Exception class:
    Errno::ENOENT

basta impostare www-data come proprietario di config/environment.rb:

chown www-data ./config/environment.rb

ps. Se mancano delle ‘r’ o delle ‘i’ è colpa di questa tastiera del cacchio, non comprate mai Kraun!!!!

Ricordiamoci di scongelare l’applicazione se lo fosse:

Iniziamo guardando le possibili opzioni di aggiornamento disponibili andando nella propria applicazione e lanciando:

L’output dovrebbe più o meno essere questo:

A questo punto basta eseguire in sequenza questi comandi e il gioco è fatto!