smartango

I am assuming there is only a generation, so I want to order the result from a db table with (id,parent_id) structure implementing the parent-child internal relationship, ie:

 

Table name: catogories

id	parent_id	name
int	int	varchar(100)

 

 

 

So, I found some hint here, and here, but actually I did wrote my solution first using IF in SQL:

SELECT c.*, IF(c.parent_id = 0, c.id*1000, c.parent_id*1000+c.id) as sorter FROM categories as c ORDER BY sorter

And for one generation structure, it works. Results are something like:

results

id	parent_id	name	sorter
1	0	Fruits	1001
3	1	Banana	1003
2	0	Vegetables	2002

 

That look simple enough

 

Note on image source: flickr vivariphotography, CC, commercial use allowed, link

Using Kriskoval‘s q version of promise I was in trouble when I required promises for a browser application based on jQuery (+more). After a while I found it exists promise in jQuery too, and is not so different in use. (ok, Kriskoval would arguments on this, and of course he is right, but it is not so different from a [coder-]user point of view)

function myRequest() {
  var dfd = jQuery.Deferred();
  //call
  yourAsync(par, par, dfd);
  return dfd;
}

 

and then 

 

function yourAsync(par, par, dfd) {
 ///do it
 async(...,function(){
	// callback function ....
        // at the end call
	dfd.resolve();
    });
}

and use it as a promise

myRequest().then(mySecondRequest).then(function(){
   console.log('all done');
   closeThatBlockingWindowNow();
}).fail(function() {
   closeThatBlockingWindowAnywayNow();
});

It also integrate well with the rest of jQuery async call, such as $.ajax:

var req = $.ajax({url:. .., ...}); 
$.when(req).then(function() { .... });

the $.when and deferred object are well documented in jQuery site with examples too

That’s all folks!

Photo credits: Christian Ditaputratama original image: link

What I mean is the autoindent function of some editor that do not understand mixed code language. PHP and Javascript couple is special:

 

<script>
var myJson =
/*<?php if($THIS && $that) { ?>*/
<?php echo json_encode($that); ?>
/*<?php } else { ?>*/
<?php echo json_encode($those); ?>
/*<?php } ?>*/

var isOk = false;
/*<?php if (!$equalthat) { ?>*/
isOk = true;
/*<?php } ?>*/

This is just an example of unclean code I have to understand, but really every editor should understand it as javascript.

The trick is: if you go inside you first close, then open, if you do not go inside, just close the opened comment. For every block. That’s all.

update: too many ‘r’ on title

D: “Model has to be some where, where do I put the model?”

E: “At the top, the model is always at the top most. But I do not like react”

This conversation with https://twitter.com/emanuele_r (https://github.com/lele85 Emanuele Rampichini) take place in late november
during a code retreat, but it was off topic, because I does not put into test React framework.

What make me trouble was the way React component class use properties (this.props in the class) and state (this.state and this.setState() method),
there are no “legal” method to change status of a class from outside that class (of course it is for encapsulation), but
also there is no methods to notify or sending a message to the class (apparently).

I have been busy on php coding, some week ago I found a viable solution, and after using it I think it is time to share.

There are a number of reason to doing so, i.e. http://stackoverflow.com/questions/25336124/reactjs-how-to-modify-child-state-or-props-from-parent/27720180
that was inspiring me, I replyed
http://stackoverflow.com/questions/25336124/reactjs-how-to-modify-child-state-or-props-from-parent/27720180#27720180
why do not use observer pattern?

But wait a moment, observer pattern has the reputation in Javascript as eventemitter, instead of reinvent the wheel I can inherit from
a ready package, say https://github.com/asyncly/EventEmitter2

var EventEmitter = require('./eventemitter2.js');

function Model() {
  EventEmitter.apply(this);
  this.choosen = ''
  this.options = ['a','b','c'];
};

Model.prototype = Object.create(EventEmitter.prototype);
Model.prototype.constructor = Model;

I have not parameter for my model, and there is actually no reason to change event emitter parameter changable from the outside

Then proceed with Model’s methods:

Model.prototype.chooseOption = function(optn) {
  this.choosen = optn;
  this.emit('optionChange')
};

Model.prototype.getOption = function() {
  return this.options;
};

Now use it in the class:

var model = new require('./Model.js')();

var MyApp = React.createClass({
   updateSelected: function() {
      var state = this.state
      state.choosen = model.choosen
      this.setState(state)
   },
   componentDidMount: function() {
      model.on('optionChange',this.updateSelected);
   },
   getInitialState:function() {
      return {choosen:model.choosen};
   },
   render: function() {
      return (
            <div>
		<strong>{this.state.choosen}</strong>
		<ExtraComponent name="taskone" model={model} />
            </div>
            );
   }
});

Now, ExtraComponent can use
this.props.model.on(this.props.name + ‘Change’, this.updateState);

in componentDidMount to listen to events from model, and also emit event based in its name, say calling

this.props.model.emitMyEvents(this.props.name)

in updateState:

var ExtraComponent = React.createClass({
   updateState: function() {
      var state = this.state
      state.isSaved = this.props.model.saved()
      this.setState(state)
      this.props.model.emitMyEvents(this.props.name)
   },
   componentDidMount: function() {
      model.on(this.props.name+'Change',this.updateState);
   },
   getInitialState:function() {
      return {choosen:this.props.model.isSaved};
   },
   render: function() {
      var title = this.props.model.getTitle(this.props.name);
      var content = this.props.model.getContent(this.props.name);
      return (
            <div>
		<h3>{title}</h3>
		<p>{content}</p>
            </div>
            );
   }
});

Here there is emitMyEvents(name) and is responsibility of the model to know which events should emit the component named name.

This will work as a agnostic component and its behavior is driven by the model. A good example of such a component is a
collapsing accordion that could be driven from outside and is agnostic of the behaviour of whole application.

Model.prototype.emitMyEvents = function(name) {
   if(name == 'taskone') {
      this.emit('accordionxUnvisible');
      this.emit('accordionTwoUnvisible');
      this.emit('accordionStrangeVisible');
   }
   // other emitions
};

 … maybe emitEventsByName would be more talking method name.

This code works? almost, this is an example, and I have not tested the code, some parts are clearly missing, I am using similar code for an application I am writing now, no problem.

I found this approach is elestic and almost free, it rely on a design pattern and thus is solid.

But there is some point to take care of:

1. passing responsibilities to the outer model
2. making component agnostic require an extra efford: give them a name and implement resposibility migration mechanism

 

Arriva una richiesta, un nuovo lavoro da affrontare, spesso c’è un prodotto di partenza da modificare, a volte il prodotto è vecchio, a volte inizi qualcosa di nuovo ed hai tutto il massimo delle libertà.

Per chi sono questi consigli

Ti trovi spesso nella situazione di dover mettere mano su codice altrui, o stai iniziando un nuovo progetto con le idee un po’ sparpagliate diciamo, cioè senza un piano esattamente coeso ed ordinato. Capita sicuramente di non avere le idee chiare se si va a modificare un codice altrui, spesso si deve agire senza aver colto a pieno la filosofia che sta dietro il codice che si va a modificare, il codice è figlio del tempo e delle mode che sono in voga in quel periodo quindi alcuni costrutti sembrano bizzarri perché, ad esempio, si ha il vizio di usare template definiti tramite variabili quando è di moda farlo, alla stessa maniera di come in cucina si tende mettere lo zenzero dappertutto quando lo zenzero è di moda, oppure il peperoncino nel gelato. Se scrivi (e leggi) codice da un po’ di tempo riuscirai sicuramente a riconoscere la moda e capire più o meno quando è stato scritto il codice, e finirai col pensare a quanto eri stupido a forzare così le scelte, lo siamo tutti, non importa.

Ecco, sicuramente non posso rendere il mondo del software scritto in passato migliore, neanche ordinare le idee confuse che sicuramente avrai all’inizio. Piuttosto traggo ispirazione dal Gioco MU di Douglas Hofstadter, per provare ad uscire dal sistema e guardare me stesso nel fare i soliti errori che fanno perdere tempo.

Ho ottenuto questi 10 consigli utili per un programmatore php/mysql, ma nella modalità e nello spirito probabilmente si applicano anche ad altri framework/toolchain.

1. Fai (e rifai) la lista della spesa

La chiamo così questa pratica che ultimamente mi salva da alcuni imprevisti. Devi determinare gli strumenti di cui hai bisogno e le azioni, il codice, i task che dovrai portare a termine. Fa la lista di questo, e aggiornala man mano che se ne presenta la necessità. Ogni volta che fai un ragionamento scrivilo. Non si ragiona con la testa tra le nuvole, si ragiona con le dita sulla tastiera (o se vuoi, con la penna sul foglio, o il pennarello sulla lavagna). Va divisa per passi sequenziali, come nella programmazione imperativa, poi sull’ordine si può soprassedere, senza stare a formalizzare ogni volta, bisogna essere snelli, basta un appunto veloce. Se ci sono cicli la cosa potrebbe essere preoccupante, a differenza della programmazione imperativa qui si sta facendo una lista di passi, girare attorno non è un buon segno, ma potrebbe essere sensato a volte. Fare comunque attenzione ai cicli.

Forse riconosci kanban (http://kanbanblog.com/explained/), infondo è quello, diciamo che io mi trovo meglio con un file di testo e appiccicare per l’ufficio tutti quei post-it mi rende la vita incasinata, poi magari porto avanti diversi progetti, bisognerebbe fare una stanza per ogni progetto da riempire con i relativi post-it. A volte mi capita di usare una lavagna per disegnare ad esempio. Siccome ho bisogno di disegnare altro faccio una foto alla lavagna, applico un filtro edge e uso l’immagine come parte del blueprint del progetto. Questo mi permette di:

• avere un ufficio ordinato
• i progetti catalogati in cartelle
• seguire più progetti
• lavorare a distanza condividendo blueprint e schizzi

L’eventuale svantaggio è il non avere tutto davanti agli occhi. Riguardo a questo per ora uso 2 monitor ed è abbastanza per sviluppare software, eventualmente ne andrebbe aggiunto un terzo per avere la lista sotto gli occhi. Con i tool giusti si riesce ad ottenere lo stesso risultato dello spostamento dei post-it, ma credo sia più importante seguire la metodologia riguardo a PENDING-DOING-DONE, piuttosto che la sua forma implementata in post-it.

2. Hai bisogno di Git

Ok, forse preferisci, mercurial? bitkeeper? bazaar? subversion? ci siamo capiti un Source Control Version, non importa se pensi che la cosa duri poco, è un piccolo task, e quindi non farai errori … ma dai.

Seriamente usa git anche se devi scrivere dei documenti, usa git anche per la lista della spesa, usa git per qualsiasi cosa, fai commit ad ogni modifica funzionante, o anche più, anche per file di testo e commenti come la lista della spesa.

3. Affronta le paure non aggirarle

Di cosa parlo? Paure durante la programmazione? Diciamo di tutti quei lavori che stufano e che pesano e si rimandano e non si vogliono fare. La paura è quella di superare il limite, per me è quello dell’avere a che fare con la definizione di un db e un dbms, anzi più dbms da tenere allineati tra la macchina di test e la macchina produttiva. Fa la lista della spesa, i passi da compiere e falli, senza paura.

Altre paure sono ad esempio quella di toccare il codice, magari del codice altrui che sai che funziona. http://www.hanselman.com/blog/FearDrivenDevelopmentFDD.aspx qui se ne parla e si parla anche della paura di perdere il lavoro, per questa bisogna chiarire i problemi ed affrontarli sempre apertamente col commitente o capo che sia, non importa perdere un lavoro che sottintende uno stress continuo per qualcosa di non chiarito, durante il lavoro si avrà la pressione continua che abbasserà la produttività e finisce che quel lavoro costerà a te più di qualsiasi valutazione pessimistica tu abbia fatto. Il lavoro deve essere guidato dalla passione, non dalla paura: cambia committente.

4. Concediti l’ignoranza. Ragiona temporalmente

Stai facendo la lista della spesa, hai considerato che dovrai affrontare alcune cose odiose, ma ancora non sai tutto. Non puoi saperlo in anticipo, lascia un’area di ignoranza, riconoscila e non cercare di avere una definizione definitiva dall’inizio.

L’esempio tipico è quello della definizione della struttura della base di dati, a meno che non utilizzi mongodb (e potrebbe anche essere un path per lo sviluppo per poi passare ad un relazionale …). La struttura dei dati di solito non è determinata dall’inizio, perché si comincia col definire una serie di test da soddisfare, le classi e così via. Io di solito parto da problemi concettuali cardinali attorno ai quali ho concepito la soluzione, ma dei quali non sono certo riguardo la facilità di implementazione, scrivo appunto la classe, il test relativo e risolvo man mano i problemi funzionali, quindi non la definizione della struttura dei dati. Per me il db schema cambia, allora scelgo strumenti che rendono il cambiamento semplice e veloce. Considero mysql:

1. mysql-workbench: permette di creare tabelle ed estrarre la definizione in modo semplice, molto meglio di phpmyadmin perché usabile via tastiera, il cambiamento di una struttura può essere eseguito o simulato cioè generando solo l’alter da una versione alla successiva (Database -> Compare Schemas…). Basta salvare l’sql degli alter e può essere usato per avanzare la versione dello schema in un sito di test o anche in produzione ogni volta che si effettua il deploy
2. http://www.adminer.org/ sembra avere abbastanza feature, non so andrebbe provato
3. https://github.com/victorstanciu/dbv non è esattamente qualcosa di leggero, usarlo potrebbe voler dire rivedere tutta l’organizzazione del codice e c’è poco di programmabile, sembra
4. https://github.com/doctrine/dbal Doctrine Abstraction Layer, perché doctrine2 lo utilizza per gestire i db e fa già qualcosa di molto simile a mysql-workbench riguardo a compare schema, ma c’è bisogno di un minimo di lavoro iniziale, diciamo cominciando con la documentazione, http://doctrine-dbal.readthedocs.org/en/latest/reference/schema-representation.html, ma una volta fatto questo lavoro si può avere in mano uno strumento piuttosto versatile nel ciclo: devel, test, deploy QA, test, deploy Production, quando ci si inseriscono upgrade del db poterle automatizzare e gestire semplicemente da file .yml è un vantaggio temporale spesso importante.
5. Take it easy: mysqldump. Sicuramente un tool da linea di comando è quello che un programmatore preferisce, lo puoi mettere dappertutto, anche nello script di deploy, esempio:

mysqldump -udbuser -pdbpass -d test `cat data/tablelist.txt` > data/dbdef.sql

esporta la struttura delle tabelle elencate in data/tablelist.txt (una per riga) contenute nel database `test` accedendovi tramite utente ‘dbuser’ identificato con ‘dbpass’, la definizione (-d vuol dire solo struttura) viene messa in dbdef.sql. Questo è qualcosa di versatile da poter mettere all’interno di uno script da eseguirsi al momento del commit, o prima, comunque meno macchinoso di dover eseguire l’operazione tramite workbench, o peggio phpmyadmin, e comunque versatile abbastanza da poter scegliere le sole tabelle interessate.

Tutte queste considerazioni sugli strumenti vanno anche in un’altra dimensione, cioè come si può andare verso la complessità e completezza di un tool, o verso la semplicità e versatilità, di quanto questo possa significare più tempo iniziale di setup e meno durante l’utilizzo. Sostanzialmente va valutato cosa è più soggetto al cambiamento, e per questo può essere speso più tempo per l’ottimizzazione: definire la struttura del db è un ciclo, non lo metterei neanche nella lista della spesa.

 

5. Give it 5 minutes

(Jason Fried’s post) Capire le soluzioni degli altri, cercare di carpirne le motivazioni che hanno portato a quelle soluzioni. Spesso gli strumenti disponibili abbracciano e risolvono tutta la problematica affrontandola da un punto di vista più inclusivo. Mentre l’esigenza specifica che si ha non ha bisogno di tenere conto di tutti gli aspetti della problematica, è naturale che ci si scocci a dover leggere tutta la documentazione per qualcosa di cui non si ha bisogno. Durante lo sviluppo del progetto se ne avrà bisogno. Dagli quei 5 minuti, dagli ragione a chi ha ideato lo strumento e capisci la problematica in toto. A tutto c’è un limite, ovviamente, ma avere una visione ampia dei vari aspetti del deploy & delivering tornerà utile se si hanno altre esigenze nel progetto che si sta affrontando, ed anche nei progetti futuri.

6. Le costanti non hanno senso

Hai presente quella pratica di definire delle costanti all’inizio del codice. È un idiozia.

Non puoi mischiare codice e costanti quando le costanti dipendono dalla configurazione, e la configurazione dipende dalla macchina, ed esiste anche il concetto di deploy, cioè ci sono 2 macchine differenti. Se le costanti sono mescolate al codice dovrai complicare il deploy facendo script da eseguirsi sulla macchina target per modificare quelle costanti.

D’altra parte potresti usare un file separato, ma sempre nel linguaggio utilizzato, cioè usare le define.
Vediamo come organizzaresti il codice (caso php):

• configurazione db (file .ini)
• file .php con define’s
• file .php con codice

E così il deploy:

• impacchetta il codice .php, ma escludendo i .php contenenti define’s
• impacchetta i .php dei define’s e i file .ini
• così hai 2 file da deployare e spacchettare a piacimento (supponendo la stessa base dir, hai lo stesso target di directories).

Pro e contro dei file con define:

• devi usare require, require causa un fatal error ed è visibile se l’output a video è attivato nella macchina target (non lo è se la macchina è in produzione)
• è .php, puoi avere la voglia di ficcarci dentro del codice, puoi farlo, questa è una boiata se ci pensi (ci pensi?)
• è .php quindi è caricato dall’interprete php scritto in C, al posto della funzione parse_ini, che certamente è scritta anch’essa in C, però nella tua testa esplicita i concetti di caricamento e parsing. (Ehi! sono le stesse operazioni!)

Di queste quali sono i pro??
No amico, le costanti non hanno senso. Usa file di configurazione, che siano ini, yaml, json, etc. basta che non ti venga voglia di mischiarci codice.

7. Usa l’ultima tecnologia

Se sulla macchina target c’è PHP 5.3, allora puoi usare il namespace, se c’è il 5.4 allora puoi usare this nelle closure, e via dicendo. Non c’è motivo di privarsi di funzionalità pensando ad un backport, non succede che si torni indietro, casomai si va avanti. Stai aggiornato sempre all’ultima tecnologia utilizzabile, all’ultima best practice, all’ultima metodologia. Non importa, puoi sempre usare roba vecchia perché non la dimenticherai così facilmente.

Usa PHPUnit per i test e composer per prendere pezzi già pronti, per questi tool infondo non importa che non siano nel server, e non c’è motivo di rinunciarci.

8. Test, test, test

Lo traduco: provare, provare, provare, e poi provare, provare, provare … Ricordi sicuramente Amanda Sandrelli in Non ci resta che piangere, quello è il TDD anticipiato nel 1984 da Troisi e Benigni, ma sono stati compresi solo molto più tardi. Test vuol dire scrivere, scrivere codice, scrivere casi studio. Testing vuol dire creare uno script di prova per verificare che l’allocazione di una sprintf sia corretta, anche per controllare il dubbio più banale è meglio scrivere codice e vedere se funziona come ci si aspetta, piuttosto che leggersi documentazione sparpagliata tra sito istituzionale, commenti e blogosphere. Test vuol dire reingegnerizzare, rivedere l’organizzazione del codice, rivedere il progetto, rivedere lo schema del db. Tutta la discussione del dotarsi di strumenti adatti al cambiamento è nell’ottica del poter provare, provare, provare. E poi provare, provare, provare, provare, provare.. e poi ci si riesce bene anche 2, 3 volte, tanto per concludere la citazione.

9. Esci dal sistema, e osservati

Guarda quello che stai facendo, dove stai perdendo tempo. Non dare per scontato che ci voglia necessariamente tutto quel tempo, prova a pensare alla strada più breve. Ho letto pochi giorni fa un articolo interessantissimo, https://medium.com/@lauraklein/your-job-is-not-to-write-code-d002609b117a, your job is not writing code, il tuo lavoro non è scrivere codice, ma soddisfare i bisogni dell’utente, anche se in pratica per farlo devi scrivere codice, ma quello non è il tuo lavoro, è il modo col quale raggiungi lo scopo. Quindi scrivi meno codice e soddisfa meglio gli utilizzatori. Non inseguire sofismi, ortodossie architetturali, o anche metodologiche, non essere così pedante riguardo al TDD, BDD e via dicendo. In generale se qualcosa ti fa perdere molto tempo forse lo stai facendo nel modo sbagliato. Esci dal sistema, guardati individua le regole che stai seguendo e se ti fanno perdere tempo, se necessario cambiale.

(immagine proveniente da http://www.zz7.it/esperienze-extracorporee-la-donna-che-usci-dal-suo-corpo-7336/ )

10. Non aspettarti che tutto fili come dovrebbe

Ad esempio io non ho un decimo consiglio da mettere, però ho letto che fare liste è qualcosa che fa salire nei risultati delle ricerche, e ho letto inoltre che 10 è il numero magico che ha migliori performance. Quindi se non trovi questo consiglio utile è normale. Non tutti i consigli sono utili nella tua situazione, e non lo sono certamente per tutte le situazioni, io ho cercato di raccogliere quelli che a grandi linee sono considerazioni che valgono per me.

E comunque sia qualcosa andrà male, o meglio andrà come non ti aspetti. Non puoi evitare di aspettarti qualcosa, né pretendere che le cose vadano secondo le previsioni. È un po’ più complesso del gioco MU.

Conclusioni

Programmare è un gioco bellissimo quando hai 13 anni. Quello che ti affascina è far funzionare delle cose, automatizzarle, in breve fare la magia. La magia, come quella del pacman che risponde ai comandi del joystick, ma ha una logica, anche il fantasmini che si muovono cercando di mangiarti, hanno una logica. È affascinante come la logica può mangiare un pupazzetto. La logica prestabilita può portare a risultati inattesi, persino inattesi dallo stesso programmatore. Avere in mano uno strumento così potente è fantastico. A volte le cose non vanno bene, o non sono andate bene, e potresti pensare che tutto è noioso e inaccettabile. Non perdere l’entusiasmo. Trova il modo di tornare ad avere quel potere, non accettare compiti ripetitivi, non l’hai mai cercato e ora non l’accettare. E crea la magia per gli utenti, e ricorda, nella magia vera il trucco non si vede!

Ho il sospetto che l’entuasiasmo si perda dietro al voler dimostrare di essere bravi, che purtroppo si scontra col programmare proprio perché è un’attività che ti mette continuamente di fronte alle tue mancanze, ai tuoi difetti, permettendoti di migliorare. L’elemento sempre presente durante la programmazione è la propria ignoranza e incapacità, ma questo non lo puoi certo scrivere nel curriculum, bisogna dividere i 2 aspetti: l’attività quotidiana e l’autopromozione. È accettabile essere crittico riguardo la propria attività se sei un programmatore. Devi farti pagare. Parla piuttosto dei risultati prodotti, non di metodologie. Le metodologie sono l’ultima cosa di cui parlare per l’autopromozione. Ma sono piuttosto importanti se vuoi arrivare ad un prodotto, ad un risultato.

E tu …

Se vuoi puoi condividere questo articolo. Forse troverai questi consigli banali, superficiali e poco formalizzati, forse ce ne sono altri da aggiungere. Non so

In a world where Bash shell is under attack I attach a short shell script that make me waste less time in upload/commit/test loop:

#! /bin/sh

LIST=`find . -name '*.php'`
for  x in $LIST; do
    OUTPUT=`php -l $x`
    A=$?
    if [ $A -ne 0 ]; then
	echo "ERROR ON " $x "with " $OUTPUT;
    fi
done

simple enough as running

./php-lint.sh

on a git repository, do not traverse all tree but just the changed files, and launch just before commit the script

#! /bin/sh

LIST=`git diff --name-only |grep 'php$'`
for  x in $LIST; do
    OUTPUT=`php -l $x`
    A=$?
    if [ $A -ne 0 ]; then
	echo "ERROR ON " $x "with " $OUTPUT;
    fi
done

Or add it as .git/hooks/pre-commit code:

#!/bin/sh

ERRORS=0
LIST=`git diff --name-only | grep 'php$'`
for  x in $LIST; do
    OUTPUT=`php -l $x`
    A=$?
    if [ $A -ne 0 ]; then
	echo "ERROR ON " $x "with " $OUTPUT;
	ERRORS=1
    fi
done

if [ $ERRORS -ne 0 ]; then
   exit 1
fi

exit 0

(and use ‘git commit’ before committing changes).

It is the simpliest statical analisys, the syntax check, but It save enough time for me

Emacs Lisp Package Archiver, simply a way to install emacs lisp script on emacs without wasting time on download, put where it could be loaded, load it …

It just install the package and let you use it. Command is M-x package-install RET [and choose the package].

It will install the package in the ~/.emacs.d/ELPA folder.

http://www.emacswiki.org/emacs/ELPA

Some usefull php el editing packages:

https://github.com/arnested/php-extras some usefull extras, and completion integration

http://company-mode.github.io/ company mode: a drop down completition for function you are writing or via direct call

auto-complete auto completition (on C-M-i)

 

Speed up php writing with emacs!

24 Settembre 2014

I formati per lo scambio dei dati sono semantici? Certamente: esprimono dei concetti e le relazioni tra questi concetti.

Principali formati: XML e JSON.

Significato

La semantica di un XML è data, in qualche misura, dalla posizione nell’albero sintattico  di una entità, dal nome di questa entità, dai suoi attributi, e a volte dai nodi dello stesso livello. Ovvero:

Significato di un valore si deduce da:

1. nome entità
2. nome attributo/i
3. valore degli attributi/o dell’entità
4. valore di un entità presente nell’albero sintattico allo stesso livello.

La semantica di un JSON è solitamente deducibile dal nome della proprietà dell’oggetto rappresentato, oltre che dalla posizione in cui si trova l’oggetto all’interno dell’albero sintattico. Cioè

Significato di valore si deduce da:

1. Nome proprietà
2. Significato dell’oggetto contenente quella proprietà

e così ricorsivamente si definisce ha il significato di un valore come la concatenazione di significati dei nodi antenati nell’albero JSON.

Struttura e validazione: lo schema

Oltre a questo ci sono, o meglio ci dovrebbero essere, delle limitazioni sui tipi che un valore può assumere e sulla struttura che l’informazione può assumere.

Questo è vero per l’XML, cioè per l’XML non solo sono stati definiti dei linguaggi grazie ai quali si può definire la struttura e i tipi di dato al quale lo stream deve aderire, ma nell’xml stesso che contiene i dati si può indicare una risorsa web dove poter prendere la definizione di queste limitazioni. Si dice che l’XML è valido se aderisce alla definizione indicata in se stesso. Sono stati definiti diversi formati per definrie la struttura e i tipi di dato ammissibili:

1. W3C XML Schema (o XSD)
2. RELAX NG (XML syntax)
3. RELAX NG compact syntax
4. XML 1.0 DTDs

Penso di averli elencati in ordine di importanza, almeno per me, l’xsd definition è quella che generalmente viene fornita quasi sempre, e c’è in giro un gran numero di validatori per riconoscere se un xml è conforme. La DTD è stata la prima formalizzazione di un data type, non molto fortunata perché utilizzava un formato a parte e non un xml valido. Appunto il vantaggio della XSD è quello di poter essere trattato dallo stesso parser xml. RELAX NG è supportato da un discreto numero di validatori, ma secondo me non ha nessun vantaggio se non quello di aver traghettato verso l’affermazione dell’XSD come standard.

Non è vero per il formato JSON dove tutto è libero, ammeno che non ci si avvalga di progetti attualmente poco considerati:

1. http://json-schema.org/ e il progetto https://github.com/json-schema/json-schema
2. http://www.jsonschema.net/

iniziative apparentemente scorrelate, ma fanno effettivamente riferimento ad una bozza per la standardizzazione http://tools.ietf.org/html/draft-zyp-json-schema-04 (la quarta revisione è del 31 gennaio 2013). Il documento IETF nella terza revisione portava questo titolo “A JSON Media Type for Describing the Structure and Meaning of JSON Documents“, mentre nella quarta revisione un più scarno “JSON Schema: core definitions and terminology“. Il titolo della terza revisione da peso all’aspetto semantico dello schema, cioè dice, già dal titolo, che json schema da significato al dato in formato JSON.

Validazione come type checking

D’altra parte JSON è un acronimo che sta per JavaScript Object Notation, inoltre un validatore di formato JSON è in qualche maniera un validatore di oggetto javascript, e un validatore di oggetto altro non è che uno strumento di type checking all’interno del linguaggio javascript, linguaggio molto fluido e lascamente tipizzato. Qualcosa che fa la validazione di un oggetto è tcomb:

https://github.com/gcanti/tcomb

Il vantaggio di tcomb rispetto a json schema è l’essere tipizzato in modo molto vicino alla tipizzazione Javascript, anche se questo dal punto di vista del gruppo IETF è considerato uno svantaggio, in realtà un aspetto importante è l’introduzione di enum, un concetto del tutto analogo è nel xsd per xml e permette di dare delle restrinzioni precise ai dati.

Lo svantaggio è che la definizione di un tipo di dato non è essa stessa un JSON, ma a questo credo si possa ovviare con qualche adattamento.

Scambio dati o “advanced programming interface”

Internet e servizi, servizi ed interfacce tramite i quali usufruirne. https://www.mashape.com/ è un servizio dove poter registrare la propria API e monetizzare il servizio offerto. Tipicamente il formato col quale ci si intefaccia ad un servizio sta diventando via via sempre più JSON+OAuth e sempre meno XML/SOAP. Il formato è sicuramente più semplice e leggibile, inoltre è facilmente interpretabile, ma lo svantaggio è non avere una definizione di schema altrettanto espressiva quanto lo è XSD. La documentazione viene fornita in formati non fortemente strutturati, mentre xsd permette di generare la documentazione all’interno della definizione stessa dello schema utilizzando elementi opportuni che non fanno parte della definizione (annotazioni), generando quindi un ipertesto che documenta la definizione di schema stessa.

È possible fare la stessa cosa col JSON? http://jsonapi.org/ questo fa qualcosa a riguardo, sembra.

Ma come convertire da XML a JSON?

usando questi 7 pattern: http://www.xml.com/pub/a/2006/05/31/converting-between-xml-and-json.html ?

Come convertire da JSON a XML

Ci sono diversi approcci

• http://apisjson.org/ applicare delle trasformazioni a la XSLT

JSON e RDF

è possibile esprimere relazioni tra dati in formato json: http://en.wikipedia.org/wiki/JSON-LD

Ma è possibile fare le query usando SPARQL su un db di JSON-LD, sembra http://lists.w3.org/Archives/Public/public-linked-json/2012Jul/0043.html che sia stato almeno discusso

Cosa è SPARQL

PREFIX foaf: <http://xmlns.com/foaf/0.1/>
    SELECT *
    WHERE {
        ?x foaf:name "Gregg Kellogg";
             foaf:knows ?y .
       ?y foaf:name ?n .
    }

Un linguaggio per fare deduzioni a partire da una base di conoscenza espressa con un linguaggio semantico (un linguaggio formale che esprime la conoscenza). Quella sopra ad esempio restituisce tutte le conoscenze (knows) di Gregg Kellogg.

E sarebbe figo avere la stessa cosa senza scrivere in XML ma in JSON. Sì sarebbe figo.

RDF e RDFa

RDF è definito in XML, mentre RDFa utilizza i namespaces per integrare informazioni semantiche all’interno dell’albero XML (che può essere xhtml, appunto una pagina web)

JSON-LD

JSON Linked Data è un formato per la rappresentazione di triple basato su JSON invece che RDF o RDFa. Esenoio di integrazione in una pagina web:

<script type="application/ld+json">
{
  "@context": "http://json-ld.org/contexts/person.jsonld",
  "@id": "http://dbpedia.org/resource/John_Lennon",
  "name": "John Lennon",
  "born": "1940-10-09",
  "spouse": "http://dbpedia.org/resource/Cynthia_Lennon"
}
</script>

questo per esprimere il corrispondente microdata (rif. http://www.w3.org/TR/json-ld/ sez. 6.20)

API per gestire le conoscenze

Per OWL c’è https://github.com/owlcs/owlapi per un programmatore è utilissima questa presentazione: http://owlapi.sourceforge.net/owled2011_tutorial.pdf

Mentre è possibile fare delle query con SPARQL tramite Hydra http://www.hydra-cg.com/ . Ed Hydra funziona sia con rdf sia con JSON-LD

Come pubblicare una propria API

Come rendere pubblica una API JSON? usando uno standard http://apisjson.org/

Tools JSON

la risorsa definitiva: http://jsonauts.github.io/

Per il front-end, interessante i template http://www.jsonml.org/

Per fine http://www.programmableweb.com/ ha un blog molto aggiornato sul semantic web e costruzione di API

Instead of reply to these reasons:

http://www.phpclasses.org/blog/post/237-7-Reasons-Why-TDD-Failed-to-become-Mainstream.html

I prefer to find what make testing hard: mock object, the missing part!

All these arguments seems to fail to understand that TDD is not just testing, it is to guarantee SOLID principle of object oriented design

Liskov substitution, Interface segretation, Dependency inversion, and also single responsibility and open/close principles are very explicit if you want to do TDD in a simple way: write mock object and separate everything

Working with Javascript NodeJS (but also with php and lambda expressions) write a mock object does not require a specific library or tool, just write the object in JSON format and pass it to the object to test.

Say you want to test an object an know if it correctly insert a row in the db:

var dbMock = {
   inserted:false,
   insertedData: '';
   insert: function(object) {
     this.insertedData = object.data;
     this.inserted = true;
   },
   lookup: function(id) {
     return {id:id,field1: 'example content'};
   }
};

var objectToTest = new ClassType(dbMock);

objectToTest.DoSomeTask(parameters);
expect.equals(dbMock.inserted,true);
expect.equals(dbMock.insertedData,'my expectation for data');

and pass it to the object to test.

That force you to write clean code. Just that.

I personally prefer jasmine-node.

The same apply to PHP, trust me!