Adesso sono precipitato ma continuo a ricevere parecchie visite, ma la cosa interessante è, come al solito, la statistica dei browser: (le ultime cento e qualcosa, da lloogg.com):

Firefox/2 (76)
Opera/9 (10)
MSIE 7 (9)
Iceweasel/2 (6)
Safari/522 (6)
Safari/419 (5)
Firefox/1 (3)
Safari/523 (1)
MSIE 6 (1)

Basta scegliersi il pubblico adeguato e basta preoccupazioni con Internet Explorer, il suo market share è irrilevante

Il primo è dbext, che in pratica trasforma l’editor in uno strumento per l’interazione con i database, permettendo la scrittura di SQL e l’esecuzione live delle istruzioni, con tanto di autocompletion.
I risultati delle query vengono mostrati in un altro buffer, che è a sua volta editabile. Insomma, è un’alternativa molto interessante rispetto alla solita shell del database da riga di comando, quantomeno perché permette di modificare le query multilinea appena eseguite senza impazzire.
Oltretutto la configurazione interattiva è semplicissima e permettendo di interfacciarsi con praticamente tutto.

Infine, è possibile avere configurazioni multiple e cambiarle durante la sessione di lavoro, una figata.

Il secondo plugin è Project, che in pratica è “la lista dei file come dovrebbe essere“.
Infatti, un progetto altro non è che una fold formattata in un certo modo, ovvero:

nome=/path/project/ filter=\"*.c *.h\"{
 Foo.c
 Foo.h
 Bar.c
 }

su questa fold potete eseguire dei comandi (doppio clic o invio per aprire un file, \r per ricaricare etc), e basta tenere il file con le fold aperto in un buffer per usarlo come lista file del progetto.
Ma non solo: Project permette di avere fold annidate, e se seguite la procedura interattiva di creazione di un progetto vi creerà automaticamente fold per ogni directory ricorsivamente.

Ma siccome un progetto è solo una lista di stringhe in un file, spostandovi nella finestra della lista potrete cancellare o modificare le definizioni, ad esempio rimuovere la cartella dei log che non serve, filtrare i file README o .txt, usare solo i .xml nella cartella exampledocs e così via.

Il terzo plugin è rails.vim. , che fa un sacco di cose fiche, ad esempio fa si che sia possibile eseguire gli script o i task di rake. Ma soprattutto, fa funzionare gf (Goto File) in modo rails-ish.
Il che significa che ad esempio se state modificando routes.rb e c’è una linea come

 map.resource :books

spostando il cursore su books e scrivendo gf automaticamente verrà aperto il controller BookController.
Non solo, offre dei comandi standard per passare ai file correlati, per cui potete saltare con la pressione di tre tasti dal modello allo unit test alle fixture al controller . E ovviamente se usate un mapping custom potete farlo con un tasto solo

A me però anche dopo le ri-modifiche continua a non piacere. Già prima era abbastanza bruttino, e l’estensione per firefox, per quanto potente, era ultralenta.

Per cui sto sperimentando con co.mments.com, che ha un tracking dei commenti molto migliore.

Purtroppo non ha integrazione col browser, il che significa dover cliccare su una bookmarklet per registrare una conversazione e visitare il sito per vedere le novità (o leggere il feed).

Per la prima cosa, non è un vero problema, e anzi, ha dei vantaggi.

La seconda è un po’ scomoda, per cui ho smanettato un po’ e mi son tirato fuori un’estensione per firefox che mostra un’iconcina colorata nella status bar quando ci sono nuovi commenti, e cliccando sulla quale si può andare a vedere il tracking.
Ho smanettato due ore, poi le divinità di javascript mi hanno dato una mano e ho ottenuto una cosa funzionante in 4 minuti netti.

Se volete provarla fate un fischio.

Dannati geek che non siete altro .

Il cherry picking è secondo me la funzionalità più utile che si possa avere in un sistema di controllo di revisione, e come l’esempio ottimale penso sia darcs, anche se credo che ormai altri software possano avvicinarsi come funzionalità (svk, mercurial?)

In pratica, immaginate una situazione del genere:

• alice pubblica il software XYZ
• bob scarica XYZ
• bob modifica helo.c (azione 1)
• bob rinomina helo.c in hello.c (azione 2)
• bob modifica quit.h (azione 3)
• bob invia l’intero pacco di cambiamenti ad alice

Ora: alice guarda la patch e decide che il cambiamento di nome è in realtà errato (il file deve veramente chiamarsi helo.c) ma vuole comunque importare le modifiche per quit.h.
Il cherry picking è proprio questo: alcuni cambiamenti sono indipendenti, ed è possibile scegliere selettivamente di importarne solo alcuni e ignorare il resto.

Volendo, alice può importare il solo cambiamento 1, e ignorare 2 e 3.
Se invece decide di importare 2 il sistema la costringe ad importare anche 1, in quanto c’è effettivamente dipendenza tra i due.

darcs rende l’operazione incredibilmente semplice, mostrando le varie patch indipendenti e permettendo di selezionarle singolarmente, a gruppi interdipendenti, tutte insieme o escludendono specificamente alcune (e nel caso, non mostrando le altre che ne dipendono).

Ovviamente questo sistema è tanto più utile quanto più lo sviluppo è decentralizzato, ma anche nell’ambito di SVN sarebbe utilissimo. Non rimane che attendere

In tal caso, il mio approccio funzionante è stato:

1. scrivete about:config nella barra degli indirizzi
2. cliccate col destro nella lista delle voci e selezionate New->String
3. create una nuova voce general.useragent.override
4. assegnategli il valore che volete
5. verificate che sia in uso scrivendo nella barra degli indirizzi about: e controllando l’ultima riga, “build identifier”

Ok, è una piccola cosa, ma mooolto utile

Anzitutto, fa un sacco di cose: gestione del caching, compressione, load balancing etc. Ma vabè, sono cose abbastanza standard.

Una cosa più carina è l’utilizzo di un linguaggio per la configurazione che viene effettivamente compilato e linkato con il programma, in modo da massimizzare le prestazioni, e da queste parti certe cose le apprezziamo.

Ma il vero motivo per cui il progetto si merita un link è per le Notes from the Architect, ovvero un testo che spiega quali siano le differenze di progettazione tra Varnish e altri software analoghi (in particolare l’autore usa Squid come esempio).

Il tipo, oltre ad essere l’autore della beerware license comunemente usata, è un programmatore di lunga data, si è scritto una sua malloc(), e ha trafficato a lungo nel kernel di freebsd, quindi assumiamo sia una persona vagamente competente.

Cosa si dice nelle note architetturali?
Il testo è interessante, perché sostiene che molti dei programmi attuali sono scritti in uno stile obsoleto che aveva senso 30 anni fa ma che ora fa più danni che bene
Ad esempio, i software non fanno affidamento sulle VM dei sistemi operativi moderni, e cercano di gestire da se la paginazione su disco della cache, creando un overhead notevole senza alcun guadagno, dato che i kernel sono perfettamente in grado di capire cosa swappare e cosa no (e le cpu supportano in hardware certe cose da una vita).
Inoltre, i sistemi SMP/SMT moderni e le ampie cache on die impongono uno stile di programmazione differente dai vecchi 386, che non viene sfruttato, e spesso neanche gestito, da certi software.

Insomma, dateci una letta. Certo, non c’è neanche un benchmark quindi potrebbe essere tutta fuffa, ma d’altronde, anche i benchmark sono fuffa, no?

Per maggiori info vi rimando all’articolo su openid.it, posso solo dirvi che funziona da paura, ma non va benissimo con gli account GTalk (per colpa del relaying party, non per l’estensione).

Semplice e geniale, installato di default nella prossima ubuntu.

Frugando in apt mi è venuto fuori questo geany, che è un mini-ide basato su gtk2, molto leggero ma abbastanza ben fatto, per quel che ho visto, con code folding, un minimo di autocompletion, syntax highlight, console degli errori di compilazione.. Bravi, 7++