PDI^2

DabbleDB è il progetto sul quale ha lavorato Avi Bryant negli ultimi mesi, e che comincia ad uscire dalla beta. Ovviamente sviluppato con Seaside.

Non mi sento di dire che sia un’applicazione web rivoluzionaria ma è decisamente qualcosa che non mi era ancora capitato di provare.
L’idea è di permettere la creazione di piccole basi di dati in un formato più articolato di un foglio di calcolo.
Una volta creata la proprio applicazione si possono inserire delle nuove viste che sono più o meno tabelle da RDBMS, con la possibilità di stabilire quale sia la vista di default, quali siano le operazioni che sono visibili in primo luogo, come organizzare i campi visibili e in che ordine porre gli elementi.

È poi possibile aggiungere dei filtri o effettuare selezioni/proiezioni etc..

Ogni record, o per dirla meglio ogni oggetto nel db può esere manipolato in modo da aggiungere o rimuovere campi, specificarne la tipologia, es. una select box per campi con scelte limitate o un campo di tipo dabbledb user piuttosto che un campo money o una lista di voci.
Il fatto che si possano importare ed esportare dati in formato CSV, RSS, iCal e PDF rende facilissimo l’uso di DabbleDB con pacchetti di dati già esistenti.

Credo sia notevole il fatto che non si tratti di una tipologia di db che preme sul lato relazionale, quelli che si fa è manipolare oggetti e liste in un modo molto più OO che in un semplice frontend per un rdbms. Direi che il fatto che è stato sviluppato con Smalltalk significhi qualcosa.

L’interfaccia è fantastica a mio parere, l’uso di javascript in genere è pervasivo, ma non irritante, nessun effetto di saltellamenti inutili, scivolate di lato etc.. ma un uso intelligente di finestre modali, effetti onHover ben disposti per permettere una migliore usabilità e c’è una serie di piccoli accorgimenti, che rendono la curva di apprendimento molto più dolce.
Ad esempio, il fatto che i tips che compaiono in automatico contengano tutti un link e che quando si va sul link l’elemento a cui faceva riferimento viene evidenziato, in modo da chiarire di cosa si stesse parlando.

Infine, non mi pare che il tutto sia ancora ben localizzato, anche se si vede che alcuni pezzi importanti (ad esempio la localizzazione per valori monetari, o per il tempo) sono già lì. Per concludere, è possibile scaricarsi un bello zippone di tutto quanto e portarselo a casa come backup quando ci si stufa di lavorare con DabbleDb.

Sono decisamente impressionato, peccato che tra i piani d’acquisto previsti non ce ne sia uno a costo zero.
Ah dimenticavo, andata a vedervi i video

Ovvero, Don Box a proposito delle dichiarazioni di Gosling su ruby:

Ruby has the language thought leadership position and is the competitor I hope AndersH is losing the most sleep over nowadays.
The fact that the “father of Java” is so unconcerned makes me wonder if Schwartz’s first act as the grand poobah at Sun should be to hire Matz?

D’altronde voglio dire, Antonio lavora all’IBM, che è la definizione di enterprise sul dizionario merriam-webster, e lavora con ruby.

Tra l’altro notando che si è beccato un link a tal proposito dal blog di matz , ho avuto l’illuminazione: matz ha un blog da qualcosa come 4 anni, e scrive come un matto. Ruby è una blogged company, Sarà questo il motivo per cui conquisterà il mondo?

Inoltro la domanda , che sarebbe bello ricevesse un sacco di risposte… chi ha avviato o provato ad avviare una nuova società?

Chi di voi ci ha provato? Che risultati ha ottenuto? E quali sono le lezioni apprese?

Rispondete di là, casomai.

Non mi pongo il problema finché non ho tempo di buttare giù quell’idea da 5 dollari che cambierà il mondo, ma nel frattempo potrebbe interessarvi Scale With Rails.

Il sito è markettaro, ma c’è una presentazione sulla scalabilità (che tocca solo marginalmente rails) molto interessante.
In realtà tende a diventare marketing della sun ad un certo punto, ma è gustosa.

Nel frattempo, io mi diverto con nitro.

Questo post si basa sul piccolo lavoro fatto la volta scorsa per creare special case nei metodi .
Avendo a disposizione quello strumento posso affrontare una delle Grandi Domande: mi conviene fare refactoring per rendere il codice più facilmente testabile se posso evitarlo?

Nel dettaglio: ho uno script che prende in automatico dei dati da risorse su web, e poi fa un grafico con i cambiamenti, insomma una scopiazzatura di EhList, fatta per giocare con le api di Yahoo! SiteExplorer in ruby

Poiché i servizi sono tutti differenti esiste un metodo specifico per accedere ad ognuno di essi, catturato nell’esistenza di una classe Provider e di varie sottoclassi, ognuna con una descrizione, un metodo specifico per recuperare le informazioni remote ed eventuali altre cose.

Un esempio di provider è:

class YahooProvider < Provider
  DESC=\"Yahoo SE inbound links\"
  APPID=\"myAppId\"
  URL=\"url yahoo SE?query=%s&appid=%s\"
  def initialize(name)
    text=open(URL%[name,APPID]).read
    @result=Mapping.xml2obj(text)
  end
  def results_size
    @result.xmlattr_totalResultsAvailable
  end
end

se state imprecando contro di me perché non chiudo la connessione aperta con open() potete calmarvi, lo script completa le operazioni in meno di un minuto e si chiude, il che fa si che le risorse vengano comunque recuperate.

Ora: come testare questo provider? In particolare, come testare l’operazione di parsing dell’xml?
La cosa più ovvia è passargli dei dati preconfezionati, magari presi da un’esecuzione precedente dello script, e verificare che li interpreti correttamente.
Solo che è il metodo initialize ad eseguire sia la letttura dei dati che il parsing.
La soluzione che permette di testare meglio tutto ciò è di spostare queste funzionalità in un altro posto per poterle testare in isolamento, con una cosa come questa:

  def read_data()
    open(URL%[name,APPID]).read
  end
  def parse(xml)
    Mapping.xml2obj(xml)
  end
  def initialize(name)
    testo=read_data()
    @result= parse(testo)
  end

Se è vero che questo approccio introduce una certa flessibilità è anche vero che si tratta di una flessibilità non necessaria, o meglio di una fattorizzazione del codice in più parti che però non è utile in quanto non userò mai una delle funzionalità separatamente dall’altra.
Insomma, sto facendo una cosa di cui non ho bisogno solo per far felici i test, che non è una cosa terribile, ma la eviterei.

Ma, se siete arrivati a leggere fin qui probabilmente sapete già cosa possiamo fare in questo caso:

require 'stringio'
special Kernel, \"open\" do
  StringIO.new(\"xml di prova\")
end
	
assert_equal valore_atteso, YahooProvider.new(url).results_size

è un hack, e non è molto nella filosofia di come dovrebbero essere i test probabilmente..
ma funziona e non aggiunge complicazioni al codice originale.
La domanda è: cosa è giusto fare? E’ giusto perseguire un approccio alla scrittura di test che è tipico in altri ambienti anche se in questo caso ne posso fare a meno sfruttando le potenzialità di ruby?

Infine, se vi state chiedendo che cosa significhi la frase relativa ad open() nel titolo, sappiate che stavo pensando che sarebbe molto carino poter usare qualcosa come
open(”mock://foo”), ed in realtà è possibile farlo con open-uri.rb, magari in futuro ne parlerò. Però non è builtin, uffa

Che devo dire, seguite le indicazioni su motoricerca per provare la nuova beta del servizio email di yahoo. Le indicazioni non sono proprio esatte ma si riesce ad andare avanti comunque.

Sto abusando della mia casella di posta al momento, e devo dire che quelli di Y! hanno fatto un bel lavoro, l’applicazione sembra davvero quasi desktop, anche se sinceramente la responsività in alcuni momenti è subottimale, ma si vede che c’è un grosso lavoro dietro.
Piccolo dettaglio: se provate ad accedere con una risoluzione di 800x600 vi viene detto di aumentarla sennò fa schifo

Ci sono molte cosine carine, ad esempio un accesso molto più semplice agli header e l’immediatezza nel creare nuovi folder, che però non mi sewmbrano virtuali come credevo, però devo verificare.

C’è l’integrazione con RSS in stile thunderbird e l’accesso diretto a Yahoo! 360, che mi sembrano utili, mentre l’integrazione con alcune delle vecchie funzionalità sembra abbastanza inesistente, ad esempio il blocco appunti è ancora nella vecchia interfaccia, così come molte altre cose.
Ma d’altronde sono in beta

Via pandemia.

Sono costretto a fare un ennesimo post riassuntivo di un sacco di cose, almeno finché non attivo Il Mio Tumbleblog™ (pensa alla mesticanza).
Se qualcuno mi regala un piano di hosting la pianto di fare questi link dump, prometto.

• Riprende la bellissima serie delle storie dall’alveare su K5. La mente collettiva delle api è una di quelle cose che se sei un filo aperto ti affascinano per forza. Specie se cominci a pensare che anche una città o una nazione o un pianeta hanno una loro mente, di cui noi poveri neuroni mobili non siamo coscienti. Ovviamente tema sfruttato ad oltranza (”Godel Escher Bach” ed il formicaio, Equal Rites e Lo Sciame con mente dal sapore metallico, il quarto libro del ciclo della Fondazione in cui il protagonista visualizza la Galassia come una forma di vita etc..)
• Insomma, pare sia aperta la Google Summer of Code, per chi vuole proporre qualcosa. Guardate che un mentor può essere anche un individuo, forza proponete qualcosa!
• A proposito della SOC, parlavo a xerox del fatto che sarebbe una cosa figa scrivere una libreria per risolvere problemi di constraint satisfaction in haskell durante l’estate, ma che io non sono minimamente in grado di farlo. Lui mi ha dato da leggere You and Your Research
• Invece a proposito di Pratchett, ho letto l’ultima uscita di tea libri, Uomini d’Arme (Man at Arms) che è abbastanza fiacco. In un momento di sconforto però mi è ricapitato tra le mani Monstruos Regiment che invece è un capolavoro ed è, AFAIK, l’unico:
  • libro di guerra fantasy
  • fantasy con violenze domestiche e personaggi traumatizzati (non l’unico con violenze, se non ricordo male c’era uno stupro nel ciclo di Thomas Covenant L’incredulo
  • racconto in cui sono presenti troll ed algoritmi di compressione delle immagini
• il documento “You and Your Research” mi ha anche fatto finalmente comprendere cosa cavolo intendesse Edison quando disse che il genio è all’1% ispirazione ed al 99% traspirazione.
• il biclazio organizza un paio di corsi per fine aprile e primi di maggio, per chi intende aprire un’impresa ma non sa bene come. Non ho la minima idea se qualcosa del genre possa essere utile, ma non si sa mai.
• Via clipperz ho scoperto il bellissimo sito messo su dall’NSA (quelli che fannno strane cose con i codici) per avvicinare i bambini alla crittografia. Cercherò di sottoporlo alle mie cuginette.
• via bluevolvox scopro il perché mi piacciono gli angoli arrotondati
• Volete farvi un piccolo grafico? Nuovo simpatico servizio: Charts@ kekova

Oh, finito, adesso si che mi sento leggero.

Lo ammetto, anche io nel millennio scorso ho imparato tanto con la roba trovata su HTML.it
Poi quel poco che avevo appreso l’ho dimenticato, ma ricordo che quando capitai lì pensai che cacchio, era fatto proprio bene quel coso.

Il nuovo design, invece, non mi piace. In ordine sparso alcuni dei motivi:

• a 800x600 devo fare scroll orizzontale
• 14 tab in alto sono decisamente troppi per me
• “più visti” alla fine della pagina? dovrebbe essere una cosa che mi invita a cliccarci, no?
• neanche lo scatolotto principale entra in 800 px orizontali
• la barra di navigazione che cambia con i tab, ok. Ma cambia ora si, poi no , poi si poi per i seguenti tre tab no, poi si..
• credo di cogliere la colorazione del menu sulla sinistra, relativo ai siti tematici.. ma ci son troppi verdi mi pare.. e poi è troppo lunga la lista, l’ho sempre pensato

non si può mettere tutto in una pagina, imo. Tutti i link alle sezioni, gli occhielli degli articoli recenti, le intestazioni di quelli popolari, le ultime dai forum, svariate pubblicità, i link esterni, i link ai sotto siti, al feed alla ricerca, i link sui corsi, allo speciale, alle newsletter..

• forse è una mia impressione, ma non c’è un po’ di inconsistenza tra le varie parti della pagina? Da una parte div che si coloran con l’hover, da una parte no, da una parte menu in un modo da una parte in un altro.. boh..
• l’immagine nell’intestazione non è un link alla home page, il che mi disturba in qualche modo..

Certo, pensando che io non son neanche capace di mettere due tag “Hx” in fila non dovrei sta qua a lamentarmi..

avendo finalmente un filo di tempo libero, vorrei parlare di un interessante problemino di approccio agli Unit Test.

Ma al momento questo margine è troppo piccolo, quindi per ora mi limito a lasciarvi ponderare questo spezzone di codice:

  def special(mod, meth,*args, &block)
   prev = mod.instance_method(meth)
   mod.send :define_method, meth do |*a|
      if args == a
        block.call(*a)
      else
       prev.bind(mod).call(*a)
      end
   end
 end

i test sono in fondo al post.

In pratica è un modo particolarmente stupido ed inefficiente di definire degli special case nel comportamento di un metodo.

I metodi così definiti sono in qualche modo simili a dei multimetodi mooolto depotenziati e che non interagiscono con l’ereditarietà, il che fa si che si possano facilmente incrementare le prestazioni mettendo le varie versioni speciali in un Hash.
In questo modo, invece di avere l’overhead di chiamate a funzione ricorsive si avrebbe solo il costo dell’accesso per recuperare la versione corretta.

Ovviamente c’è poi il fattore di dove mettere questo hash.. insomma in realtà si tratta di un problemino interessante che vi consiglio di affrontare, magari come kata per esercitarvi con ruby.

Sul wiki di ruby italia potete vedere le soluzioni ad un problema analogo, quello di scrivere una funzione memoize che trasformi un metodo qualunque in uno memoizzato, ovvero uno che calcoli il risultato per un certo set di argomenti una sola volta, anche a fronte di numerose chiamate.

Per sapere cosa c’entri tutto questo con i test dovete aspettare che abbia di nuovo un attimo di tempo, intanto pensateci su, i test contengono degli hint

	
if __FILE__ == $0
  require 'test/unit'
  class TC_Special < Test::Unit::TestCase
    def test_one_mod
      special(Kernel,  pen, \"speciale\") {\"atteso\"}
      assert_equal \"atteso\", open(\"speciale\")
      assert_raise(Errno::ENOENT){open \"\"}
    end
	
    def test_many_mod
      for i in %w(primo secondo terzo) do
        special(Kernel,  pen, i) {i}
      end
      for i in %w(primo terzo secondo)
        assert_equal i, open(i)
      end
      assert_raise(Errno::ENOENT){open \"\"}
    end
	
    def test_one_class
      person=Struct.new :name
      special(person, :name=, \"01\") {raise}
      assert_raises(RuntimeError) { person.new.name= \"01\"}
    end
  end
end

via greenkey scopro il blog Il Vero Programmatore, una raccolta di battute sulla falsariga di quelle su chuck norris, rocco siffredi etc, ovviamente ispirato al testo antichissimo con lo stesso nome.

Va detto che greenkey ha messo il link al testo moderno, quello in cui i veri programmatori programmano in C, ma che io ricordi l’originale era quello, in cui i veri programmatori manipolavano liste in FORTRAN.

E poi mi capitano queste due battute nel blog suddetto:

La casa del Mangiatore di Quiche è orientata a sud. La casa del Vero Programmatore è orientata agli oggetti.

e

Il Vero Programmatore si dichiara alla donna che ama dicendo “private Object VeroProgrammatore;”

Caro Lettore, spero tu riesca a cogliere la sottile ironia.