Solipsista atipico. Questa è forse la definizione migliore per
il proprietario di questo blog, Davide Casali aka Folletto Malefico "@.
Programmatore,
grafico,
fotografo.
Scrittore, disegnatore, creativo. Utopista, osservatore.
Sbaglia come tutti, ma ama correggersi.
E' Interaction Designer & Architecture Designer, lavora in maison,the
e segue alcuni progetti nel suo tempo libero.
E' laureato magistrale in Teoria e Tecnologia della Comunicazione
e si interessa di psicologia sociale applicata alle tecnologie.
Il nuovo documento è “Motivational Design: una metodologia per il social network design“, sempre per mano mia e di Gianandrea Giacoma.
In questa nuova versione non ci siamo ovviamente limitati a fare una semplice fusione dei due testi, ma abbiamo anche chiarito alcuni passaggi più complessi, questo grazie a tutti i commenti e le critiche costruttive che abbiamo ricevuto in questi mesi. In più, abbiamo anche arricchito i primi due capitoli con un bel numero di esempi.
Il documento come sempre è scaricabile liberamente e pubblicato sotto licenza Creative Commons by-sa 2.5 (ita):
Per il futuro sappiate che c’è una versione successiva già in cantiere – ci sono ancora delle parti che vogliamo chiarire e alcune rifiniture da fare – e anche alcune sintesi: ci rendiamo conto che un testo di oltre 70 pagine non è affrontabile alla leggera.
Se avete commenti, critiche o curiosità segnalatecele pure, come sempre avete fatto, grazie!
In partenza per Frontiers of Interaction V di lunedì prossimo (a Roma), vi segnalo la presenza su YouTube di un interessante documentario su IDEO, anche se piuttosto datato ha comunque spunti utili (via Konigi):
Ho colto l’occasione della presentazione fatta a BetterSoftware con Gianandrea Giacoma (qui in italiano) per tradurla in inglese (grazie a Sara per la revisione), in modo da iniziare a creare un minimo di discussione anche nell’ambito internazionale. Il titolo è cambiato: da Design Motivazionale (De.Mo.) ora utilizzeremo Motivational Design (Mo.De.), non volevo cambiare la sigla ma alla fine era meglio che travisare troppo il significato nella traduzione.
Nella presentazione sono evidenziati i quattro elementi chiave (Functional Needs, Social Usability, Relational Motivations, Circadian Activity Flow), con anche un buon numero di esempi. Se ci fossero dubbi potete naturalmente leggere il paper, in italiano, oppure fare domande sotto: ci sono delle parti che sono molto criptiche e che ovviamente necessiterebbero la presenza di un supporto vocale.
The Master in the art of living
makes little distinction between his work and his play,
his labor and his leisure,
his mind and his body,
his education and his recreation,
his love and his religion.
He hardly knows which is which.
He simply pursues his vision of excellence
in whatever he does,
leaving others to decide whether he is working or playing.
To him he is always doing both.
— Lawrence Pearsall Jacks (1932) Education through Recreation
Volevo segnalare, se capitasse che qualcuno passi per Firenze, che sarò presente alla conferenza Better Software e terrò una sessione con Gianandrea Giacoma intorno alle 12:00 del 6 maggio, il primo giorno.
Il tema è quello del Design Motivazionale. Visti gli obbiettivi della conferenza abbiamo deciso di tenere un approccio un poco più divulgativo, cercando di spiegare gli elementi centrali della nostra metodologia (bisogni funzionali, usabilità sociale, motivazione relazionale, flusso di attività circadiano) in modo da portare avanti il difficile tema della divulgazione umanistica in ambito IT e porre allo stesso tempo una serie di elementi utili e concreti per chiunque sviluppi o progetti oggetti con elementi dotati di interattività sociale.
A riguardo del nostro intervento siamo anche stati contattati dal gentile Maurizio Boscarol di Usabile.it, che ha pubblicato una intervista proprio su come il nostro metodo si applica alle attuali prassi di design… più qualche domanda interessante sulla disciplina e sugli sviluppi futuri.
In alcuni passaggi sono stato forse un po’ eccessivo per motivi retorici, fatemi nel caso sapere.
Nei giorni scorsi su una presentazione piuttosto ben fatta ho trovato quattro leggi citate nel contesto di Scrum:
Ziv’s law: specifications will never be fully understood.
Humphrey’s law: the user will never know what they want until after the system is in production (maybe not even then)
Wegner’s lemma: an interactive system can never be fully specified nor can it ever be fully tested. This is the software analogy to Godel’s theorem.
Langdon’s lemma: software evolves more rapidly as it approaches chaotic regions (taking care not to spill over into chaos)
Queste sembrano prese da un post iniziale di Sutherland (o da una mailing list, entrambi del 2007), uno dei firmatari dell’Agile Manifesto, ma non sembra possibile capire chi siano Ziv, Humphrey, Wegner e Langdon a cui le leggi fanno riferimento. Qualcuno ne sa di più?
Nel mentre che sistemavo il problemino dell’altro giorno, buttavo giù anche due righe di PHP per automatizzare il processo di verifica. Dopo aver scritto il post in merito a quanto era successo, alcuni amici mi hanno contattato per sapere come verificare se anche il loro sito era stato colpito.
Ci sarebbero ancora un po’ di finiture da aggiungere, ma non credo sia un oggetto così utile da richiedere un eccessivo lavoro. Però già così potrebbe essere interessante, quindi insomma… fatemi sapere.
Intorno al 22 di marzo pare che qualcuno sia riuscito ad entrare in alcuni dei miei domini (incluso questo blog) ed installare dei simpatici script. Sono state fatte alcune cose:
Hanno sparso per i filesystem dei file con nomi “simili” a quelli esistenti (xml.php, stream.php, …) che però avrebbero consentito l’upload e la modifica remota dei file da parte di chiunque avesse un cookie specifico (gli script sono c99 e r57shell).
Hanno editato alcuni file aggiungendo link di spam nei template (curiosamente, anche file di codice mio completamente custom, son andati a cercarsi il template).
Hanno editato wp-settings.php delle installazioni di WordPress (indipendentemente dalla versione presente) con un codice eval() scritto oltre il normale spazio visivo di un editor testuale (per intenderci, una riga che inizia con molti spazi). L’eval in questione iniettava un redirect 301 (permanent) verso un sito solo per i crawler dei motori di ricerca.
Hanno editato .htaccess delle installazioni di WordPress aggiungendo molte righe vuote ed in fondo un altro redirect analogo al precedente: solo per i crawler (redirect su bablo.me.uk).
Mi sono accorto della penetrazione un paio di giorni fa, a causa di un netto calo delle visite (sceso circa dell’80%). Visite che prima arrivavano sostanzialmente da Google. Ero sparito dalle classifiche su Google (folletto, intense minimalism, davide casali solitamente mi trovavano in prima pagina), pur rimanendo nell’indice. Ho aperto un topic sull’assistenza di Google Webmaster Tools (e ricevuto i consigli in privato di un paio di persone, grazie) e un googler alla fine mi ha segnalato la discrepanza: Googlebot vedeva un redirect 301 verso un altro sito.
Un hack piuttosto furbo.
Per verificare questa situazione potete usare dei siti (1, 2; specificando “Googlebot”) oppure un comando da linea di comando Mac o Linux (curl):
Provato se guardando solo Googlebot non risulta di suo evidente, basta provare anche con un user agent normale e poi con Googlebot in modo da notare le discrepanze.
Per trovare le modifiche ho fatto affidamento a due tools fin da subito: la data di modifica del file e SVN, con il quale installo quasi sempre le mie versioni di WordPress e simili.
La cosa curiosa in assoluto è stata però che la modifica ai file wp-settings.php non mi veniva segnalata da “svn status”. O mi è sfuggito qualcosa nelle varie verifiche che stavo facendo, oppure non so. Quando ho copiato in locale la cartella per fare ulteriori verifiche, TextMate invece ha trovato che il file era modificato.
Se qualcuno volesse visionare i files e il codice utilizzato per l’attacco e le modifiche ho salvato quasi tutto. Fatemi sapere (un commento con la mail è sufficiente).
Capitasse nuovamente, o capitasse a voi, ecco in sintesi le verifiche che ho fatto:
Verificare la modifica su GoogleBot (con curl, wget o analogo web).
Verificare la bash history se avete una login via SSH.
Verificare .htaccess, wp-config,php, wp-settings.php e i template (i file più frequentemente attaccati).
Utilizzare svn per verificare le modifiche fatte (svn status).
Utilizzare le date di modifica dei file per vedere se è stato modificato qualcosa (ls -la)
Verificare la differenza del codice rispetto ai backup.
Per quanto volendo si potrebbe semplicemente ripristinare la situazione da un backup, questi controlli permettono di capire con maggiore precisione cosa sia successo.
La domanda a questo punto è: da dove sono entrati?
Difficile dirlo. Questo blog ha l’ultima versione di WordPress installata. Di routine ho cambiato tutte le password adiacenti agli account che sono stati toccati, ma credo che l’attacco sia stato fatto tramite alcune vulnerabilità esistenti su xmlrpc.php di WordPress: sono stati sistemati sulle ultime versioni ma… avevo alcune versioni vecchie installate.
Qui nasce un dubbio: io quelle versioni di WordPress non posso aggiornarle, si riferiscono a vecchie edizioni e vorrei tenerle per motivi storici. Ho disattivato il disattivabile (fra cui un bel delete di xmlrpc.php) controllando alcune vulnerabilità segnalate, ma… come fare? Il problema è abbastanza rilevante: non è possibile aggiornare quelle versioni, perché utilizzano codice e componenti ad-hoc e aggiornarle equivarrebbe a rimuoverle. Qualcuno ha idee? Tutto quello che mi viene in mente richiederebbe una manutenzione abbastanza eccessiva (aggiornare tutto, fare un plugin di “lockdown”, staticizzare il sito, …).
WordPress Portal è un plugin/library per WordPress che ho realizzato per semplificarmi la realizzazione di theme complesse e certe tipologie di plugin. Può essere utilizzato in due modi:
Come libreria. Si può aggiungere a qualunque theme o plugin e si ottengono una serie di funzionalità addizionali: creazione di The Loops customizzati, iterazione semplificata sugli attachment, recupero dei term (tags o categories), creazione di pagine virtuali e alcune semplificazioni come una funzione per prelevare il contenuto di una pagina.
Come plugin. Aggiunto come plugin permette di inserire dei widget nella sidebar che sono in grado di visualizzare gli ultimi ‘n’ posts da una categoria specifica (e tutte le sotto-categorie). Funzionalità molto comoda per creare pagine ricche di contenuti (come homepages, dashboard o pagine di atterraggio intermedie).
Su questo blog ne ho già parlato qualche volta di questo plugin, infatti è una libreria che mi accompagna da tempo e sviluppo in parallelo ai miei progetti. Personalmente ne faccio un uso abbastanza intensivo e in questo modo ho una ottima riusabilità del codice, oltre ad una maggiore velocità nella realizzazione di template complessi (vedi ad esempio Good50×70 che ne fa uso dal 2007).
WordPress Portal è pubblicata, con documentazione ed esempi, sul mio sito parallelo di sviluppo Argilla. La libreria è un unico file, per semplificare aggiornamento e portabilità.
E’ pubblicata sotto licenza GPL, quindi potete farne l’uso che preferite. Ovviamente se avete feedback, integrazioni, patch o consigli, sono i benvenuti.
Qualche tempo fa incontrai CocoaMySQL, un software per Mac opensource che permetteva di modificare i database MySQL da una comoda interfaccia nativa. Molto bellino anche se un po’ da rifinire.
Io però utilizzo come hosting DreamHost che applica delle policy sui database che sono anche sensate: sono inaccessibili dall’esterno (salvo modifiche esplicite della configurazione).
Così, quando qualche tempo fa ho scoperto che CocoaMySQL si è evoluto in Sequel Pro (potere dell’opensource) risolvendo anche un po’ dei miei crucci sul programma, ho deciso di trovare una soluzione che non implicasse l’abbassamento di sicurezza sul database.
La soluzione si è rivelata essere quella di creare un tunnel SSH e ho scoperto essere una operazione più semplice di quanto pensassi. Si risolve tutto in una sola riga di comando da Terminal (bash):
Questa riga apre la connessione al server “example.net” con il nome utente SSH “user”. E fin qui è il comando SSH normale per connettersi: crea il canale SSH.
Il tunnel è realizzato dal parametro “-L” che specifica di aprire la porta locale “8806″ e connettersi tramite il canale SSH al server “sql.example.net” alla porta “3306″, ovvero la porta di MySQL.
Infine, i parametri finali: “-C” specifica di comprimere i dati (ottimizza la banda) mentre “-N” specifica che non saranno mandati comandi al sistema remoto (in altri termini, voglio solo il tunnel e non anche la normale connessione SSH). Volendo c’è anche il parametro “-f” che crea il tunnel in background (io preferisco non farlo in modo da ricordarmi di chiuderlo appena finito di usarlo).
Quindi si passa dal computer locale, porta “8806″ attraverso la connessione SSH per raggiungere il server sql.example.net alla porta “3306″:
Il tunnel così creato di fatto risulta essere visivamente una finestra Terminal che sembra bloccata dopo aver chiesto la password. In realtà non è bloccata: c’è il tunnel. Se si termina l’esecusione (Ctrl-C) il tunnel viene chiuso.
A questo punto basta connettersi via Sequel Pro specificando “127.0.0.1” come server (non “localhost”, che invece userebbe i socket Unix) e come porta quella appena creata dal tunnel, “8806″. Il nome utente e la password sono quelle del database al quale ci si connette.