Silvio Berlusconi - Wikiquote

  

Sperando di non arrivare dopo la puzza, (ma non mi pare), per i patiti di genere:

>>> import this
The Zen of Python, by Tim Peters

Beautiful is better than ugly.
Explicit is better than implicit.
Simple is better than complex.
Complex is better than complicated.
Flat is better than nested.
Sparse is better than dense.
Readability counts.
Special cases aren't special enough to break the rules.
Although practicality beats purity.
Errors should never pass silently.
Unless explicitly silenced.
In the face of ambiguity, refuse the temptation to guess.
There should be one-- and preferably only one --obvious way to do it.
Although that way may not be obvious at first unless you're Dutch.
Now is better than never.
Although never is often better than *right* now.
If the implementation is hard to explain, it's a bad idea.
If the implementation is easy to explain, it may be a good idea.
Namespaces are one honking great idea -- let's do more of those!
>>>

Alcuni potrebbero vederlo anche come un buon motivo per NON usare python. ;)

(There should be one-- and preferably only one --obvious way to do it. Sic, shame on you).

"In questo libro, le imbarcazioni navigano; le onde ripetono la loro canzone; i vignaioli discendono dalle colline delle Cinque Terre, sulla Riviera genovese; in Provenza e in Grecia si bacchiano le olive; i pescatori tirano le reti sulla laguna di Venezia; i carpentieri costruiscono barche, uguali oggi a quelle di ieri... E ancora una volta, guardandole, ci ritroviamo fuori del tempo." 
(da Fernand Braudel, "Il Mediterraneo")

Poi qualcuno mi chiede perché studio storia e non ingegneria.
La soddisfazione di studiare su un libro che inizia così compensa qualsiasi carenza, o mancanza di utilità pratica. 
Provare per credere.

Io non sono mai stata brava con i cambiamenti.
Mi pesano. Sempre.
Mi pesava anche finire la scuola, in un certo senso. Ogni giugno.
E mi pesava l’idea di partire per le vacanze, di cambiare quella routine che odiavo, mi pesavano le giornate lunghe, il sole, il caldo che non era ancora così caldo.
E mi rallegravo solo alla prima sera in cui mi trovavo costretta ad indossare una felpa, perché fuori l’aria era fresca e il vento sembrava pronto a trascinare con se’ il nuovo autunno, le foglie secche, il grigio e la pioggia.
E quella routine che odiavo.
Io credo di amarla, in fondo.
Perché non sono mai stata brava con i cambiamenti.
E vedere questa camera svuotarsi pian piano di quel poco di mio che le avevo concesso mi fa quasi piacere.
Ho buttato quella lettera che avevo scritto, perché sapevo che non sarebbe mai giunta a destinazione.
Ma c’era un pezzo di quello che sto pensando ora, e non credo di saperlo rendere a parole nuovamente.
Avrei voglia di chiacchierare per ore allo stesso modo in cui scrivo.
E delle stesse cose di cui scrivo.
Avrei voglia di parlare, senza avere la sensazione di non farlo realmente.
Avrei voglia di ripetermi, senza la sensazione di avere già detto.
Parlare, solo quello.
E stare in silenzio, dopo, anche solo per qualche minuto.
Musica.
Tazza di tè, bollente.
E dissolvenza in nero.

Confesso, fare slide non è la mia specialità. Ma devo, e cerco di farle carine, se posso. Mi sono trovato di fronte alla necessità di cambiare un elemento grafico dello sfondo Nella versione inglese è intuitivo View–>Master–>Slide Master Nella versione italiana è un po più oscuro Visualizza–>Sfondo–>Maschera ps mascheraaaa ??????????????????????????

Il mouse di Chuck Norris è Splinter delle Tartarughe Ninja.

Non potrò più guardare mio figlio senza ridere, ora!

Ogni lezione che si rispetti, ogni volume, articolo, prova su strada, che ha a che fare con l'informatica, e in particolare con i linguaggi di programmazione, non può che non passare per l'inevitabile e inelluttabile "Hello World". In questo primo articolo, quindi, il canonico "Hello World", un giro per le directory di Rails, e un tentativo di capire di più del modello MVC.

Anatomia

Si legge in giro che il cardine di Rails è "convenzione anzichè configurazione". Lo trovo un affascinante principio, e questo comporta che si devono mettere le mani sulle convenzioni di Rails.

Creare un applicazione Rails, nel suo aspetto base, significa aver scritto:

rails <nome applicazione>

Che, come sappiamo, produce tutte le directory che serviranno a Rails, più gli script di generazione dei vari moduli, e altro ancora.

A colpo d'occhio, la directory si presenta così (tutto viene generato dal precedente comando):

:~$ cd DemoRails/
:~/DemoRails$ ls -F
app/         config/  doc/  log/     Rakefile  script/  vendor/
components/  db/      lib/  public/  README    test/

Alcuni di questi file o directory (README, Rakefile) sono dei semplici template, altri file o directory sono il vero core di Rails, e in dettaglio:

• app la dir vera e propria che conterrà la maggior parte del nostro codice. Qui andiamo a inserire i file Model, View e i Controller.
• config contiene i file di configurazione della nostra applicazione, e in particolare le informazioni per la connettività al database.
• doc il posto dove depositare la documentazione della documentazione. Esistono aspetti di autogenerazione da approfondire.
• log dove vengono prodotti i log dell'applicazione.
• script rails deposita qui tutti i vari generatori e utility varie.
• vendor ufficialmente "codice di terze parti". Da approfondire.
• components la documentazione dice "reusable components". Sarà oggetto di un futuro approfondimento.
• db Gli eventuali script di generazione del database.
• lib genericamente parlando, codice condiviso, da approfondire.
• public la parte web dell'applicazione. Semplificando è la parte da cui sembra provenire l'applicazione, contiene gli stylesheet, le immagini, ecc.
• test unit test, e roba analoga. Rails è un framework agile, e ampio spazio viene dato a questo aspetto.

La maggior parte del nostro codice, finirà nella directory app (e test se siete moooolto bravi). la dir app, è così costituita:

:~/DemoRails/app$ ls -F
controllers/  helpers/  models/  views/

MVC

MVC è l'acronimo di Model, View e Controller. MVC è un Design Pattern abbastanza noto, che, in sintesi separa il design di un applicazione in questi tre elementi, dove:

• Il Model è responsabile per lo stato dell'applicazione, e di conseguenza per lo storage dei dati (tipicamente in un db).

• Le View rappresentano le interfacce utente disponibili, spesso collegate a un qualche Data Model.

• I Controller interagiscono con l'applicazione, e fanno da collante tra i due aspetti

L'idea di base è che costringendosi a pensare in questo modo, l'applicazione viene prodotta in modo più efficace, maggiormente mantenibile, e la separazione del codice per funzione e scopo, produce un codice più ordinato e gestibile nel presente e nel futuro. Potete approfondire il modello su questa pagina.

Rails fa grande affidamento su questo design pattern, e quindi le nostre applicazioni saranno un progredire di modelli, viste, controller, fino a completamento del tutto.

Il dietro le quinte di Rails, quindi, è il seguente:

Ogni richiesta del browser, viene passata al router dell'applicazione, che utilizza questa convenzione: la prima parte dell'url viene interpretata come il nome di un controller, la seconda parte come una possibile action (un metodo che deve essere disponibile nel controller), da eseguire.

C'è ancora tanto da dire su come Rails implementa MVC, ma suppongo che dopo un pò la noia prenda il sopravvento, per cui, proviamo a vedere qualcosina in dettaglio.

Hello (at least)

Ogni manuale di programmazione, che si rispetti o meno, propone l'ennesima implementazione di "Hello World". Non posso esimermi da questa tradizione, e utilizzerò questo esempio, per fissare meglio nella mente, la questione esposta poche righe sopra.

Tenendo presente che In un applicazione Rails, gli url vengono mappati su controller e action e Rails utilizza il path per determinare il nome del controller e l'azione da eseguire il nostro primo comando, per far si che la nostra applicazione ci saluti (sic), è quella di definire un controller.

:~/DemoRails$ script/generate controller Saluta
  exists  app/controllers/
  exists  app/helpers/
  create  app/views/saluta
  exists  test/functional/
  create  app/controllers/saluta_controller.rb
  create  test/functional/saluta_controller_test.rb
  create  app/helpers/saluta_helper.rb

Bontà del framework, con l'apposito generatore, abbiamo già un numero cospicuo di file. Il nostro controller, e l'appena generato saluta_controller.rb nella dir app/controllers. Esso si presenta così:

:~/DemoRails/app/controllers$ cat saluta_controller.rb 
class SalutaController < ApplicationController
end

Poichè siamo in un framework (e basato su un linguaggio) pesantemente a oggetti, quello che abbiamo ottenuto è una classe che eredita da ApplicationController (che fa parte delle classi di Rails), e pronta per la sola nostra personalizzazione.

Poichè il semplice controller da solo è inutile, dovremmo definire l'action (la seconda parte dell'url), ovvero il metodo della nostra classe, affinchè la nostra richiesta possa essere portata a termine.

La tentazione potrebbe essere quella di definire un metodo che stampa a video "Hello World". Tentazione (in parte) sbagliata. Il controller interagisce con l'applicazione, eventualmente attraverso uno o più Model e attraverso le View che sono l'interfaccia utente.

Sicchè, noi dobbiamo solo "definire" il nostro metodo (o action) e passare poi alla vista. Il nostro controller quindi viene così modificato.

:~/DemoRails/app/controllers$ cat saluta_controller.rb 
class SalutaController < ApplicationController
  def hello
  end
end

Prima di passare alla vista, controllo i risultati dei progressi fin qui. Rammento che webrick è comodo per sviluppare, perchè ogni modifica viene presa "al volo" (finchè si è in development mode).

Da notare due cose. La semplice invocazione dell'url:

http://localhost:3000/saluta/

produce questo output:

Unknown action

No action responded to index

Mentre l'invocazione dell'url:

http://localhost:3000/saluta/hello

produce:

Template is missing

Missing template script/../config/../app/views/saluta/hello.rhtml

Questo dovrebbe suggerire come le cose stanno funzionando, in modo forse più chiaro che non tutte le chiacchere di prima. Per ottenere quindi il nostro "Hello World" dobbiamo semplicemente modificare la vista (View) base che è stata generata in fase di creazione del controller, ovvero, creare il template che lo stesso errore ci suggerisce.

:~/DemoRails/app/views/saluta$ cat hello.rhtml
<html>
  <head>
    <title>Amusing (and boring) Hello, in Rails</title>
  </head>
  <body>
    <h1>Hello World!</h1>
    <p>Even in Rails!</p>
  </body>
</html>

Semplice html, quindi. L'estensione rhtml, non deve spaventare. Permette di fondere porzioni di codice ruby, all'html (alla php, per capirci).

Se ricarico il mio browser ottengo il tanto agognato saluto (e senza riavviare niente. Rails in modalità development, come ho detto, recepisce al volo le modifiche).

Giusto per dare un ultimo tocco, e intuire qualche aspetto in più (fin qui, una pagina html, non è molto), aggiungiamo un elemento di interazione tra controller e vista per capire come sono collegati i due.

Nella nostra view, aggiungiamo quanto segue:

<p>Sono le <%= @time %></p>

Due parole qui; i <% %> e <%= %> sono il modo rhtml di includere codice ruby. Abbiamo quindi chiesto di utilizzare una variabile di istanza che andremo a definire direttamente nel nostro controller, semplicemente aggiungendo

@time = Time.now

Nella nostra action hello (del nostro controller).

I nostri file sono quindi, ora

:~/DemoRails/app/controllers$ cat saluta_controller.rb
class SalutaController < ApplicationController
  def hello
    @time = Time.now
  end
end

e

:~/DemoRails/app/views/saluta$ cat hello.rhtml
<html>
  <head>
    <title>Amusing (and boring) Hello, in Rails</title>
  </head>
  <body>
    <h1>Hello World!</h1>
    <p>Even in Rails!</p>
    <p>Sono le <%= @time %></p>
  </body>
</html>

Il tutto produce:

Hello World!

Even in Rails!

Sono le Sun Mar 05 13:01:49 CET 2006

sempre al nostro url http://localhost:3000/saluta/hello.

conclusioni

Ci sono diversi aspetti che non sono stati volutamente approfonditi. Questa "lesson", serve per dare un idea generale del modello MVC, e di "dove scrivo cosa", che poi è la parte meno "evidente" di Rails.