Chi mi segue su Google+ o Twitter sa già tutta la storia. Per chi invece non lo fa eccola qui.
Un paio di settimane fa stavo pensando a quale progetto portare per l’esame di Machine Learning. Dopo aver scartato un po’ di idee perché troppo banali e altre perché troppo complesse mi si è accesa la lampadina. Ho pensato di progettare un intelligenza artificiale per il gioco della dama in grado di apprendere con l’esperienza.
L’ultima release di Eclipse (la Indigo) è favolosa. A prima vista non sembra molto diversa dalle precedenti ma la reattività e la stabilità è notevolmente aumentata. Funziona così bene che ho ricominciato ad usarla dimenticandomi dei problemi che mi aveva dato Helios.
La prima cosa che ho cercato era l’integrazione con Git (si, sono innamorato).
Bene, la ricerca è stata breve e il risultato è molto soddisfacente: EGit. L’ultima versione di Eclipse include questo plugin nella vasta gamma dei plugin scaricabili.
Con questo articolo tocchiamo il culmine di Lua. Scopriremo come implementare il paradigma ad oggetti in un linguaggio non Object Oriented come Lua. Scopriremo quindi come questo paradigma manuale lasci una personalizzazione enorme nel comportamento degli oggetti e nella definizione delle classi.
La notizie e le informazioni in internet vanno sempre verificate. Molte cose infatti si tramandano di bocca in bocca (o di tastiera in tastiera) fino a confondersi. Le senti ripetere talmente tante volte che alla fine te ne convinci e le accetti acriticamente.
Arriva poi il giorno che ti informi e scopri che le cose non sono proprio così o che, in fondo, sono molto più complesse. Fra questo ricade anche l’asserzione Android è scritto in Java.
Lo sviluppo di Lua procede lento ma costante. Ieri è stata infatti rilasciata la Beta di Lua 5.2. La nuova versione del linguaggio introduce, come è solito, grandi cambiamenti e una manciata di incompatibilità con le precedenti versioni. Vediamone alcune (la lista completa la trovate qui)
Fra le parole più abusate su internet un posto d’onore va a programmatore (o developer e varianti). Forse secondo solo a “H4ck3r”. In ogni caso, programmatore fa fico, creare programmi e dire alla gente “questo l’ho fatto io” non ha prezzo.
Ma la realtà è ben diversa. Spesso molti di questi individui sono programmAttori e nulla più. Molti conoscono la programmazione sciamanica, l’arte di scrivere mantra tantrici su dei file .c o .py e passarli ad un compilatore per ottenere qualcosa in cambio. Questa non è programmazione, almeno non al suo livello più nobile. Il web è pieno di questi arroganti developer. Vediamo come disinnescarli.
L’uso della logica come tentativo di emulare il ragionamento umano è un arte antica. Già Aristotele nel IV secolo A.C., spinto dal suo enorme desiderio di razionalizzare il mondo, si era spinto fino al punto di cercare di meccanizzare il pensiero umano. Aristotele ci provò con i sillogismi che definiva come “un discorso nel quale, supposta la verità di alcune cose, si deduce la necessaria verità di una conclusione diversa dai presupposti”.
Verso la fine del 1200, il filosofo catalano Ramon Llull passò gran parte del suo tempo nel tentativo di creare macchine in grado di generare automaticamente ragionamenti utili (Ars generalis ultima). Sebbene il suo scopo fosse un po’ ardito (Ramon tentava di dimostrare la supremazia del Cristianesimo sull’Islam e l’Ebraismo facendo derivare automaticamente la dottrina Cristiana a partire da alcuni principi di base) la mole di tecniche di calcolo e di ragionamento create dal filosofo catalano fu decisamente elevata per l’epoca.
Tuttavia sia Aristotele che Lull che tutti gli altri che ci hanno provato nei secoli a venire (e ci provano tutt’ora) hanno fallito: i loro metodi si sono sempre trovati davanti al problema di non essere scalabili alla complessità del mondo reale. Apparve chiaro, insomma, che l’uomo non è una raffinata macchina risolutiva di formule logiche o, almeno, non solo.
Nulla è più importante di quello che è racchiuso nelle parentesi graffe. Se dovessi scegliere una frase per descrivere Lua sceglierei proprio questa. Volevo parlarvi di come utilizzare il paradigma a oggetti con Lua ma, rileggendo vari appunti, mi sono accorto che non posso assolutamente tralasciare una parte vitale del linguaggio: le tabelle.
Se in Lisp il tipo di dato base del linguaggio è la lista, se in Python è l’oggetto in Lua è la tabella. Non esiste nessun’altra struttura dati in Lua all’infuori della tabella: niente array, niente vettori, niente liste, solo ed esclusivamente tabelle.
Forse non ce n’era bisogno ma ho sentito la necessità di rinnovare la grafica di SlashCode lanciando la versione 3.0. Ho scelto di semplificare un po’ la grafica, modernizzare il template e rendere il tutto un po’ più minimal. Spero sia tutto di vostro gradimento.
Ma non è finito quì. Sto cercando di riorganizzare le varie categorie, le pagine e le sezioni di SlashCode. Un lavoro noioso ma necessario per adattare l’albero delle categorie ai nuovi argomenti che sto trattando.
Insomma, spero vi piaccia e vi invito a inviarmi dei feedback per migliorare ancora di più SlashCode. Grazie a tutti quelli che supportano questo sito con le loro visite.
C’è un principio molto noto dell’informatica che spesso viene dimenticato dagli sviluppatori tutti. Tale principio recita più o meno così: se una cosa è a 3 schermate di distanza allora non esiste. È un principio basilare nell’usabilità del computer per l’utente medio: se una cosa necessita di più di 3-4 click e si trova oltre i 3 passaggi allora, indipendentemente da quanto sia importante, per l’utente finale, non esiste.
Al riguardo ci sono un po’ di considerazioni da fare.
Perché viene dimenticata?
Il motivo è semplice: i programmi vengono scritti dai programmatori. Non è un gioco di parole, è la verità. Ai programmatori piace la soluzione arguta, l’opzione contorta, l’arzighigolo programmativo. Non possono farci nulla, è più forte di loro. Non di rado quando parli dell’usabilità d’uso di un programma con un programmatore ricevi come risposta cose tipo “vabbè è semplice. Basta che aggiungi /percorso/assurdo nella variabile ENV e avvii il programma con nomeprogramma -opzione1 -opzione2 -opzionen=boh e ottieni quello che vuoi!”. E tutto ciò è normale: se non gli piacessero le cose complicate non sarebbero programmatori.
Tutti se le dimenticano?
No. Ovviamente in molti programmi ci sono persone incaricate appositamente di frenare l’indole complicatrice degli sviluppatori. Ma allora perché troviamo ancora questi grossolani errori? Alcune volte per disattenzione e altrettante per malafede. Un esempio? Le impostazioni della privacy di Facebook. Quanti click servono per arrivarci? Sono tre per visualizzarle e 4 + n per modificarle a piacimento, tutto questo attraversando 2 schermate e un menù piuttosto dimenticato.
Solo malafede?
No. A volte nascondere una possibilità oltre la soglia dei 3-4 passaggi è una “features” che permette allo sviluppatore di evitare la scrittura di complicati meccanismi di blocco, criptaggio, ecc, contando sui grandi numeri.
Un esempio è dato da un applicazione Android per impostare lo sfondo del terminale. L’applicazione da accesso a una sterminata galleria di sfondi ma, ovviamente, non da la possibilità diretta di scaricare tali sfondi. Il motivo è che, giustamente, lo sviluppatore vuole che tu apra il programma ogni volta che vuoi cambiare sfondo: se te li facesse scaricare facilmente l’utente se ne scaricherebbe 30 nel giro di due minuti e poi si dimenticherebbe dell’applicazione!
Tuttavia per impostare uno sfondo è necessario scaricare l’immagine. Come fa il programma? La scarica e la imposta. Quando cambiate sfondo, cancella la precedente e la sostituisce con la nuova.
Ora capirete che è ancora teoricamente possibile scaricarsi 30 sfondi e buttare l’applicazione, basta copiarsi in una cartella l’immagine scaricata ogni volta che il programma la scarica. Ma quanti passaggi necessita? Troppi. Non tanti, ma troppi, più di 3-4. E così statisticamente il 99% delle persone utilizzerà il programma nel modo voluto dallo sviluppatore nonostante sia teoricamente fare diversamente.
Altri esempi?
Google. Fate una ricerca su Google e notate a che pagina desistete dalla ricerca. Sono quasi sicuro che smettete di cercare entro la 3° 4° pagina, se arrivate a 6 siete parecchio insistenti, a 10 significa che siete disperati (come io quando cerco tutorial su roba strana).
Se il vostro blog cade oltre la 4° pagina non esistete. È come se fosse alla pagina 100 mila.
Quindi?
Quindi pensateci. Tutto qui. Se programmate qualsiasi cosa che non sia destinata ad altri programmatori, fate caso a non collocare nulla oltre la soglia dei 4 click/schermate. I vostri utenti ne gioveranno e voi pure.
| © 2008-2012 SlashCode | Suffusion theme by Sayontan Sinha |
Recent Comments