Tra il codice e la realtà

Se l’XML non vi è mai piaciuto e JSON non vi sembra una soluzione adeguata, Protobuf potrebbe essere la soluzione che aspettavate.

L’idea interessante è quella di generare delle classi (ad esempio in C++) che forniscono un accesso estremamente comodo attraverso setters e getters (anche se io avrei fatto una scelta diversa) e integrazione con le funzionalità del linguaggio (come gli stream di IO) e contemporaneamente estremamente efficiente in termini di parsing (realizzato infatti ad hoc per il singolo schema)  e memorizzazione (direttamente in strutture del linguaggio).

Da molti punti di vista un approccio di questo tipo è la soluzione ottimale nel caso in cui si abbia a che fare con dati con una struttura omogenea e nota a priori, la cui manipolazione ha un peso significativo per l’efficienza del sistema nel complesso.

Non sono un fan dell’XML, ma non posso non notare che una soluzione del genere è implementabile anche con XML (e viene nei fatti usata da tempo ad esempio da gSOAP), ma non con JSON che manca di uno standard di definizione degli schemi. Rispetto a XML però non so dire quali siano i vantaggi: semplicità nella generazione delle classi nel linguaggio scelto ? Efficienza nella rappresentazione dei dati (utile ad esempio per ridurre la banda in caso di trasmissione) ? Efficienza comunque nel parsing (anche se ad hoc per schema) ? Non saprei, presto per dirlo, ma se dovesse servirmi qualcosa del genere, darò sicuramente un’occhiata più approfondita a questa libreria.

Servizio lanciato da DZone, Refcardz è in pratica una raccolta di pratici riferimenti su temi specifici (da Spring a GWT, dal formato Atom alla costruzione dei plug-in di eclipse).

Mi ha fatto pensare ad una sorta di bignami dell’era digitale…. ti chiedi se possa servire davvero a qualcosa. Mah forse per certi argomenti estremamente specifici, tipo “Shortcuts in NetBeans 6.1″, potrebbe avere un senso…. per il resto non mi pare.

Spesso le tabelle sono molto utili per rappresentare in modo visuale delle informazioni complesse, ma rappresentabili in qualche modo su un piano (bidimensionali) e discritizzate. Ovviamente la discretizzazione dev’essere sufficiente a focalizzare il significato delle grandezze, ma tale da non comprometterne il significato. E quasi sempre la vera difficoltà è scegliere il piano di rappresentazione e l’entità della discretizzazione.

Le competenze di un programmatore sono una di quelle cose che (per eccesso di complessità) si rischia di considerare non formalizzabili in una qualche forma rigorosa… ed in buona misura sono convinto che così sia. Non per questo non è apprezzabile lo sforzo di qualcuno che prova a determinare un piano e una discretizzazione per il problema in esame. Con l’obiezione che ha troppi valori (sia in x che in y), alcune idee mi sembrano interessanti.