THeK3nger

 

Non era mia intenzione dare questa notizia ma ho visto che è passata quasi inosservata ed è quindi giusto darla.  Anche perché a me è preso un colpo quando durante l’ultimo dist-upgrade ho letto “sidux is dead”.

SIDUX DIVENTA APTOSID. Il team è lo stesso e, al momento anche il logo. Il motivo del cambiamento non mi è ancora ben chiaro ma l’importante è che, in qualunque modo si chiami, alla fine resti sempre la mia distro preferita di sempre.

Ecco spiegato anche perché era da parecchio tempo che non c’erano aggiornamenti importanti dal repo di sidux.

 

Nella quasi totalità dei libri informatici e dei testi introduttivi ai calcolatori elettronici il computer, e in particolare la CPU, viene descritta come un dispositivo analogo al cervello umano, in grado di elaborare e memorizzare dati allo stesso modo in cui il cervello umano elabora e memorizza gli stimoli esterni.

Questa analogia è ottima per dare l’idea di cosa sia un computer ma se scendiamo nei dettagli ci rendiamo conto che il paragone è tutt’altro che preciso. L’architettura del cervello umano e quella di una CPU sono completamente differenti: la prima è estremamente parallelizzata mentre la seconda è praticamente seriale.

Nel cervello ogni cellula celebrale delle decine di miliardi di cellule nel cervello umano lavora quasi in completa autonomia, ogni zona del cervello lavora senza curarsi (o curandosene solo in casi specifici) di cosa fanno le altre zone e anche all’interno di un singolo settore possono svolgere micro-calcoli in contemporanea. Tuttavia le cellule umane sono estremamente lente con velocità dei segnali dell’ordine dei millisecondi.

Le CPU invece, anche nel migliore dei casi, non supera il numero delle 32/64 unità e quindi un grado di parallelizzazione di 32/64, insufficiente a dare un grande vantaggio prestazionale a qualsivoglia algoritmo. Tuttavia una CPU ha segnali che viaggiano quasi alla velocità della luce e il numero spaventoso di miliardi di operazioni al secondo.

È quindi ovvio che nel tentativo dell’ AI di replicare l’intelligenza umana subentrino difficoltà legate proprio alla differenza architetturale del sistema di origine e del sistema di destinazione. Si cerca infatti di replicare in modo efficiente algoritmi che funzionano bene su sistemi “paralleli” su dispositivi “seriali”. E la differenza può essere notevole! È infatti noto che modelli di calcolo equipotenti (come lo sono Cervello e CPU) non sono equivalenti quando subentra il fattore “spazio” e l’ancor più importante fattore “tempo”.

Algoritmi risolvibili in tempo esponenziale su un sistema possono essere risolti in tempo polinomiale su altre architetture e viceversa. Ad esempio la ricerca su un grafo, che viene eseguita scandendo progressivamente ogni singolo nodo, può essere notevolmente migliorata nel caso in cui vengano esplorati decine di milioni di nodi in contemporanea.

Quindi, al di là dei progressi teorici e algoritmici che da qui ai prossimi anni coinvolgeranno l’AI, ci sono progressi tecnologici che coinvolgono la struttura stessa dei calcolatori che potrebbero aprire nuove strade o riaprirne di vecchie (scartate perché poco efficienti su architetture tradizionali).

La creazione di un dispositivo che abbia un livello di parallelizzazione analogo a quello di un cervello umano ma allo stesso tempo conservi la velocità di calcolo di un computer tradizionale sembra ancora al di là delle possibilità tecnologiche umane, ma potrebbe essere un buon punto in cui concentrare la ricerca nel prossimo futuro. Magari sfruttando le nuove scoperte di computer quantistici e di spintronica.

 

Nella scorsa parte abbiamo visto come abilitare l’interfaccia di admin. Abbiamo notato però che non tutto era esattamente come ce lo aspettavamo. Per prima cosa tutte le tabelle terminavano con una fastidiosa “s” dovuta al plurale inglese, secondo, gli oggetti venivano visualizzati con un anonimo “Artista Object”, “Genere Object” e così via.

Per sistemare questi punti c’è un modo molto semplice.

  • Specificare il metodo __unicode__.
  • Aggiungere l’opzione verbose_name_plural come parametro della classe Meta di ogni oggetto del modello.
  • Impostare LANGUAGE_CODE = 'it-IT' nel file settings.py

Il metodo unicode specifica come verrà visualizzato un oggetto del modello X al posto della dicitura standard “X Object”. Per chi conosce il python è praticamente equivalente a ridefinire il metodo speciale __str__[/cc] di una classe (il metodo [cci]__str__ dei modelli Django chiamano proprio __unicode__).

La classe Meta, invece, è una classe speciale che permette di passare ai modelli delle opzioni particolari. Vedremo altre opzioni nel corso del tutorial. L’opzione che ci interessa ora è verbose_name_plural : se questo valore è None allora viene usato il suffisso “s” come nel caso inglese, altrimenti viene usato il valore della variabile.

Vediamo quindi qualche esempio:

class Artista(models.Model):
    nome = models.CharField(max_length=50)
    cognome = models.CharField(max_length=50)
    ruoli = models.ManyToManyField(Ruolo)

    def __unicode__(self) :
      return u"%s %s" % (self.nome, self.cognome)

    class Meta:
      verbose_name_plural = "Artisti"

Mostro il caso del modello “Artista”. Allo stesso modo intervenite anche su tutti i modelli restanti. Potete vedere il risultato in figura.

Come potete vedere adesso il risultato è molto più accettabile. La prossima volta vedremo come abbozzare un interfaccia pubblica al nostro sito.

 

Quando si sviluppa un applicazione web creare pannelli di admin è solitamente noioso e fastidioso eppure necessario per permettere, ad esempio, al gestore del negozio online che stiamo progettando di aggiungere oggetti al catalogo senza dover conoscere una riga di codice o del funzionamento di un DB. Per fortuna Django ci offre una valida scorciatoia: creare un interfaccia admin con Django ci costa solamente una decina di righe di codice.

Per prima cosa abilitiamo il pannello di admin modificando un paio di righe:

  • Decommentiamo la riga django.contrib.admin di INSTALLED_APPS in settings.py
  • Decommentiamo from django.contrib import admin e admin.autodiscover() da urls.py
  • Decommentiamo (r'^admin/', include(admin.site.urls)), da urlpatterns in settings.py

Per ultimo creiamo ex-novo un file admin.py nella nostra apps con questo contenuto:

from django.contrib import admin
from musicdb.models import *

admin.site.register(Artista)
admin.site.register(Genere)
admin.site.register(Ruolo)
admin.site.register(Gruppo)
admin.site.register(Album)
admin.site.register(Traccia)

Poi avviamo il server e andiamo su

http://localhost:8000/admin/

Per accedere al favoloso pannello di amministratore.

La schermata di login del pannello di admin!

La schermata principale del pannello di amministrazione!

Semplice, facile ma estremamente potente. :)

Tuttavia ci sono ancora alcuni difetti. Ad esempio Django pluralizza le parole aggiungendo il suffisso “s” alla parola come nel caso inglese, cosa che non va bene in italiano; inoltre se apriamo una tabella ci troveremo davanti tanti oggetti anonimi come “Artista object”, “Gruppo object” e così via mentre noi vogliamo che ci indichi, ad esempio, nome e cognome di un artista o il nome del gruppo.

Rimuoveremo tutti questi piccoli difetti la prossima volta con alcune piccole modifiche al modello.

 

Come ogni applicazione che si rispetti, abbiamo bisogno di impostare e generare la struttura dati del nostro programma. La primissima cosa da fare è quella di istruire Django ad utilizzare un database.

Per questa guida sceglieremo PostgreSQL. Per configurarlo potete seguire la guida per installare PostgreSQL.

Una volta installato e configurato il database apriamo il file settings.py e cerchiamo la riga DATABASES e modifichiamola nel modo seguente:

DATABASES = {
    'default': {
        'ENGINE': 'django.db.backends.postgresql_psycopg2',
        'NAME': 'musicdb',
        'USER': 'vostro_nome',
        'PASSWORD': 'password',
        'HOST': '',
        'PORT': '',
    }
}

Dove vostro_nome e password sono l’username e la password che avete impostato nella fase di configurazione del database. Inoltre dovete creare preventivamente un database di nome “musicdb”. Per completezza spieghiamo tutti i parametri:

  • ENGINE è il modulo di django di backend che si interfaccia con lo specifico database. Scegliamo quello del nostro database.
  • NAME è il nome del database o del file nel caso di SQLite.
  • USER è il nome utente per l’accesso al db (non serve nel caso di SQLite).
  • PASSWORD è la password di accesso.
  • HOST e PORT sono i dati che indicano la posizione e la porta di accesso a db nel caso il database non sia sulla stessa macchina del server.

Assicuratevi anche che sia installato il pacchetto:

python-psycopg2

Necessario per far interfacciare python al DB.

A questo punto non ci resta che creare lo schema del database. Per fare ciò apriamo il file models.py e inseriamo una cosa del tipo:

from django.db import models

# Create your models here.
class Ruolo(models.Model) :
    descrizione = models.CharField(max_length=30)

class Artista(models.Model):
    nome = models.CharField(max_length=50)
    cognome = models.CharField(max_length=50)
    ruoli = models.ManyToManyField(Ruolo)

class Gruppo(models.Model):
    nome = models.CharField(max_length=50)
    membri = models.ManyToManyField(Artista)

class Genere(models.Model):
    descrizione = models.CharField(max_length=30)

class Traccia(models.Model):
    nome = models.CharField(max_length=50)
    durata = models.TimeField()

class Album(models.Model):
    nome = models.CharField(max_length=50)
    gruppo = models.ForeignKey(Gruppo)
    genere = models.ForeignKey(Genere)
    data = models.DateField()
    tracce = models.ManyToManyField(Traccia)

Questo file specifica la struttura delle tabelle del database. Tutto senza scrivere una sola riga di SQL. Vediamo un po il significato di alcuni campi:

  • CharField è un campo di testo semplice. Il parametro max_length specifica il numero massimo di caratteri memorizzabili nel campo.
  • ForeignKey specifica un collegamento uno-a-molti verso un altra tabella. Ad esempio un Album ha un unico Gruppo che lo suona ma un Gruppo può avere uno o più Album nella propria discografia.
  • DateField specifica una data.
  • TimeField specifica un tempo.
  • ManyToMany specifica un collegamento molti-a-molti verso un altra tabella. Ad esempio un Gruppo può avere uno o più Artisti che ne fanno parte, ma un Artista può partecipare a uno o più gruppi.

Ora, rendiamo questo modello un database vero e proprio con il comando:

python manage.py syncdb

Se tutto è andato a buon fine e il modello è valido ci verrà chiesto se vogliamo creare una zona del database per gli utenti. Diciamo di si. Ci verrà chiesto di creare il super-user, creiamolo indicando un nome e la password.

A questo punto possiamo provare il nostro database.

Apriamo la shell di django con

python manage.py shell

E all’interno digitiamo:

from musicdb.models import *
freddie = Autore(nome="Freddie, cognome="Mercury")
freddie.save()

Con pgAdmin3 possiamo facilmente vedere che il cantante è stato aggiunto nella giusta tabella.

Ebbene si. Freddie c'è.

 

Continuiamo il nostro tutorial che ci porterà a implementare una semplice applicazione web per gestire la nostra collezione musicale.

Ora che la base funziona dobbiamo iniziare a scrivere qualcosa di più complesso che una misera pagina di default. A questo scopo ci servono le viste. Le viste non sono altro che quella parte di programma che si occupa di recuperare tutte le informazioni necessarie alla visualizzazione della pagina che poi verranno passate ad un template in modo da essere trasformate in pagine web a tutti gli effetti. Solitamente le viste interrogano un database per recuperare i dati, questa volta invece cominceremo da una semplice vista di test.

La prima cosa da fare è creare una nuova applicazione che chiameremo musicdb in quanto sarà il centro vero e proprio della web application. Un sito complesso è solitamente composto da una o più applicazioni collegate fra loro. Piccoli siti, come quello che stiamo per fare, utilizzano solo un applicazione. Per fare questo, all’interno della cartella principale del sito, digitiamo:

django-admin startapp musicdb

Questo creerà un ulteriore cartella che contiene altri 4 file.

  • __init__.py Sempre il solito file init.
  • models.py Contiene i “modelli” ovvero la struttura del database espressa in python tramite le API di Django.
  • tests.py Contiene dei test per valutare la correttezza di query, associazioni, modelli e viste.
  • views.py Contiene le viste, ovvero quelle funzioni che si occupano di processare le richieste dell’utente generando dei contenuti (tramite i template) che verranno poi inviati al browser.

La seconda cosa da fare è aggiungere la nostra applicazione alle applicazioni del sito. Andiamo nel file “settings.py” e aggiungete ‘musicdb’ alle applicazioni in questo modo:

INSTALLED_APPS = (
    'django.contrib.auth',
    'django.contrib.contenttypes',
    'django.contrib.sessions',
    'django.contrib.sites',
    'django.contrib.messages',
    # Uncomment the next line to enable the admin:
    # 'django.contrib.admin',
    'musicdb',
)

Poi dobbiamo scrivere una vista di prova. Andiamo nel file “views.py” dell’applicazione musicdb e inseriamo il seguente codice:

from django.http import HttpResponse

def view_test(request) :
    return HttpResponse("
<h1>Ciao! Questa è la tua applicazione!</h1>
"
)

Ora, dobbiamo solo collegare un URL a questa vista e quindi andiamo nel file “urls.py” e modifichiamo “urlpatterns” in questo modo:

urlpatterns = patterns('',
    # Example:
    # (r'^musicz/', include('musicz.foo.urls')),

    # Uncomment the admin/doc line below and add 'django.contrib.admindocs'
    # to INSTALLED_APPS to enable admin documentation:
    # (r'^admin/doc/', include('django.contrib.admindocs.urls')),

    # Uncomment the next line to enable the admin:
    # (r'^admin/', include(admin.site.urls)),
    ( r'^test/$', "musicdb.views.view_test"),
)

Il primo elemento della tupla è una espressione regolare che serve ad intercettare l’url e a indirizzarlo alla funzione indicata come secondo elemento della tupla.

A questo punto non ci resta che testare tutto. Avviamo il server (python manage.py runserver) e andiamo all’indirizzo http://localhost:8000/test/. Quello che ci troviamo davanti dovrebbe essere una pagina come quella in figura.

Che bello! Funziona!

 

Vi propongo passo passo un tutorial che ci porterà a realizzare una pagina web dinamica contenente informazioni sulla nostra collezione musicale. In questo modo potrete vedere come prende forma un progetto utilizzando quella meraviglia tecnologica che è Django. Gli unici requisiti sono la conoscenza del Python nella sua forma base (for, if, classi, funzioni, tuple, liste e dizionari). Non ci resta che iniziare a impostare la cartella del progetto e verificare che tutto funzioni.

La prima cosa da fare è andare in una cartella e digitare:

django-admin startproject musicz

Verrà creata una cartella di nome musicz che contiene 4 file.

  • __init__.py è il file che indica all’interprete python di trattare la cartella come un package. Il file è solitamente vuoto e vuoto deve solitamente rimanere.
  • manage.py è un file di servizio che vi offre un interfaccia molto comoda ad alcune “utility” di Django. Ne faremo largamente uso da ora in avanti.
  • setting.py è il file che contiene tutti i settaggi che faremo all’applicazione.
  • urls.py è il file che contiene la specifica mappatura degli urls verso le funzioni del programma.

La cartella contenente i nostri 4 file.

Se tutto è stato fatto correttamente vi basterà digitare

python manage.py runserver

Per avviare il web-server di prova. A questo punto non vi resta che andare all’indirizzo http://localhost:8000/ per vedere un rassicurante messaggio da parte di Django.

Django ci dice che va tutto ok!

 

Come ben sapete sto approfondendo il mio rapporto con Django e, come tutti per tutti framework per applicazioni Web, è fondamentale interagire con un database. Così ho deciso di installarmi in locale un database e, tanto per provare cose nuove, ho deciso di non usare MySQL ma provare PostegreSQL.

A dire la verità la scelta va oltre il semplice diletto. Conoscerete senz’altro le vicissitudini che affliggono MySQL dopo l’acquisizione di Sun da parte di Oracle (già sviluppatore di un noto database). Il futuro di MySQL è quindi incerto e il suo fork comunitario MariaDB, creato dallo stesso programmatore originario di MySQL, sembra ancora lontano dall’avere una comunity stabile e progetti futuri soddisfacenti.

Esiste però un alternativa piuttosto famosa anche se non ha mai avuto la stessa diffusione del suo diretto concorrente: PostgreSQL. Questo db non ha un azienda alle spalle ed è quasi esclusivamente frutto della comunità cosa che comunque ci fa ben sperare che non faccia mai la fine del collega. Inoltre vanta una serie di features che non mi risulta siano presenti in MySQL (ma potrei sempre sbagliarmi) e, soprattutto, risulta più performante se associato a Django.

Detto questo, ci sono tutti i presupposti per provarlo. Il processo di installazione è del tutto automatico, tuttavia, ci sono alcuni passaggi che mi hanno fatto perdere parecchi minuti perché poco chiari. Ed è proprio su quelli che mi concentrerò.

Innanzitutto installiamo il programma:

$ apt-get install postgre

Questo comando installerà automaticamente l’ultima versione stabile del DB (attualmente la 8.4). L’imminente versione 9.0 è anch’essa presente nei repo di Debian Sid tuttavia non installa a causa di una mancata dipendenza.

Una volta installato dobbiamo infilare una serie di comandi che non vi sarebbero mai venuti in mente:

$ su
Password:
# su postgres

Questo vi permetterà di accedere all’utente amministratore di PostgreSQL. Una volta che siamo loggati dobbiamo abilitare il nostro utente “normale” alla modifica del db. Per fare questo dobbiamo creare un utente per il database (che prendono il nome di ruoli).

$ createuser -P
Enter name of role to add: thek3nger
Enter password for new role:
Enter it again:
Shall the new role be a superuser? (y/n) y
CREATE ROLE

Ovviamente al posto di “thek3nger” metterete, per semplicità, il nome utente che usate per accedere al vostro sistema.

A questo punto il vostro utente avrà pieno controllo del db e potete farci quello che vi pare. Vi consiglio inoltre un utility grafica per accedere al db:

apt-get install pgadmin3

Così potete evitare di dover imparare a memoria tutti i comandi SQL di PostgreSQL.

 

L’attesa per KDE 4.5 si fa sempre più spasmodica. A mio avviso siamo ad un giro di boa nella storia della release più infamata del panorama open-source. KDE, come sapete, ha la nomea di essere instabile eppure posso assicurarvi che non l’ho mai vista crashare su distro serie (Sidux), certo che se valutate KDE su Kubuntu allora ve la cercate. :D

Tornando alla nuova release le novità non sono molte, tuttavia molte delle features precedenti vengono rafforzate, stabilizzate e migliorate dal punto di vista dell’usabilità. È il caso del System Setting, il “pannello di controllo” di KDE, che perde le tab in modo da avere tutti i comandi in un unica schermata, senza però perdere in chiarezza. Anche il gestore attività è notevolmente cambiato, molto più pratico ed usabile. Oppure le nuove notifiche, molto più ordinate e meno invasive.

Ma quella che a mio avviso è il vero progresso, la punta di diamante del nuovo KDE 4.5 è l’integrazione, ormai quasi completa, fra le varie applicazioni Nepomuk e Akonadi.

Akonadi è un server che si occupa di gestire le informazioni dei programmi PIM (email, appuntamenti, contatti, ecc) in modo centralizzato e veloce. Questo significa che tutte le applicazioni come KMail, KOrganizer e via discorrendo, possiedono un unica infrastruttura dati accessibile da qualunque altro programma. Proprio questo permette a Nepomuk, il servizio di indicizzazione di KDE, di indicizzare oltre ai file anche email, appuntamenti, allegati, contatti, e molto altro anche grazie all’uso di tag. Queste ricerche possono essere fatte sfruttando Krunner come se si stesse lanciando una qualunque applicazione.

È il primo grande esempio di desktop semantico. La possibilità di accedere con un paio di comando a qualunque risorsa all’interno del pc è divenuta quasi realtà.

Un altra grande novità, a mio avviso, è il netto miglioramento della suite KOffice che, anche grazie ai pesanti investimenti di Nokia, è ormai una suite moderna, funzionale e dall’interfaccia utente molto ingegnosa. Molti passi in avanti devono essere fatti ma la versione 2.2 può cominciare senza dubbio ad essere un sostituto di OpenOffice, almeno per chi non ha grosse pretese.

KDE 4.5 può quindi essere l’ottimo punto di partenza per chi vuole provare KDE sfidando le malelingue che vogliono (ingiustamente) KDE instabile e macchinoso. Tutto questo in attesa di vedere la riscrittura di KWin con le nuove OpenGL che ci attende nella 4.6 e 4.7. È qualcosa che vi consiglio di tenere d’occhio. ;)

KDE 4.5 sarà disponibile nella prossima release di Kubuntu e OpenSuse mentre per chi utilizza Sidux, molto probabilmente si vedrà qualcosa verso settembre sempre che i pacchettizzatori non mi sorprendano con una release a tempo di record.

PS riguardo al flame: Per chi non lo sapesse quando nel titolo di un post scrivo “Flame” solitamente non rispondo ai commenti. Lo faccio perché un flame è un argomento fazioso (sia da parte mia che da parte di chi commenta) e quindi è solitamente inutile discutere e trasformare i commenti del blog in una bolgia. Tuttavia li leggo sempre tutti e ho notato che molti sono d’accordo con me e questo mi fa sentire meno solo. :D

 

Ok. Questo è un post inutile e probabilmente fazioso. Ma ho bisogno di un piccolo sfogo. In questi mesi giro pigramente per il web informandomi sui vari portatili perché ho intenzione, più prima che poi, di sostituire il laptop che oggi giace sepolto nella polvere.

Nel far questo mi sono fatto prendere dalla curiosità e dopo tanto tempo ho deciso di riguardare l’offerta della Apple. Questo perché, sebbene penso che tutti gli altri prodotti della Apple siano buoni solo per riempire le fondamenta delle case popolari, quando si parla di PC, alla fin fine si tratta di un opzione non troppo malvagia (tenendo presente che nel resto dei pc c’è Windows.. è come sparare ai pesci in un barile).

Tuttavia noto con disgusto che ancora non si è posto un limite alla pratica vergognosa del sovrapprezzo.

MacBook Pro:

Schermo 15”
Intel Core i5 da 2,4 GHz
4GB di memoria
disco rigido da 320 GB

Prezzo: 1749€

Dell Studio 15

Schermo da 15”
Intel Core i5 da 2,4 GHz
4GB d memoria
disco rigido da 320 GB

Prezzo: 739€

E le altre caratteristiche sono praticamente simili.

Ora non voglio sentire ragioni perché per me non esiste nessun motivo che possa valere un sovrapprezzo di 1010€. Perché è una cifra astronomica, è quasi lo stipendio medio di un operaio, e per chi conosce o ha conosciuto cosa significa non avere soldi, passare problemi finanziari e doversi appoggiare alla carità di amici e familiari si farebbe tagliare le mani piuttosto che scialacquare tanti soldi per uno status symbol.

È una cosa che il mio cervello rigetta, è un lusso che non posso concedermi nemmeno nei miei sogni più lubrichi. Se invece voi ve lo potete permettere vi invito a ripensarci. Quei 1010 euro che avete risparmiato, se proprio ci tenete a spenderli, dateli in beneficenza, finanziate progetti open, comprate un computer a chi non se lo può permettere o qualunque altra cosa.

C’è tanta gente al mondo che ha molto più bisogno di soldi di Steve.

© 2008-2012 SlashCode Suffusion theme by Sayontan Sinha