smartango

There are two things that, IMHO, make code cleaner when using Promises Idioma:

1. use an unique object argument (and its attributes as you would use argument legacy)
2. return resolve with the object given as argument augmented by attribute of the action executed by the function

i.e., say I want to ask db for data about a person, I define the method (function) that got an object {person: {personstruct}} and return the augmented object {person:{personstruct}, contactdata: {contactdatastruct}}

 

function addContactData(o){
   return new Promise(function(resolve,reject) {
     //check existense of attributes, reject with reason
     mysql.query({sql:"select * from cdata where pid=?",values:[o.person.pid]},function(err,rows) {
       if(err) {
          o.err = err.toString();
          reject(o);
       } else {
          if(rows.length>0) {
            o.contactdata = rows[0];
          } else {
            o.contactdata = null;
          }
          resolve(o);
       }
     });
   });
}

 That could look not very optimized but it is a practice that make things look cleaner and consistent. Pros:

1. testing is simply composable, just pass some good object and test if it augments: there is an idioma testing
2. you have no surprise
3. you have not to deal with “how do I access previous promise result in a .then() chain” problem, where Bergi show some drawback with this solution, that really are worth paying for the cleaness

Also object is passed by reference, and test on required attributes is a matter of enstabilish a protocol, like attrlist with type required.

Note: image source http://www.geograph.org.uk/photo/1804846 chain at the launch of SS Great Eastern (sailing ship), Isle of Dogs, England

E quando poi si parla di algoritmi di cifratura simmetrici, si dice che c’è bisogno dello scambio sicuro
della chiave di decodifica, e, i più, a questo punto si tacciono.

E tra i più c’ero anch’io.

Di fatto lo scambio sicuro della chiave può essere fatto su di un canale differe, ad esempio tramite un database, ad esempio si può scambiare un messaggio tra 2 attori che non si fidano l’un dell’altro dividendolo in 2 parti: identificazione (da verificare), messaggio oscurato (cifrato).

Infatti in molti casi può non essere così importante la segretezza del messaggio, ma esserlo l’autenticità del mittente.

In un semplice schema, se da una parte c’è un canale sicuro asincrono, come ad esempio è un database, e da un altra si invia un messaggio verso un servizio che ha accesso a questo database, il detto servizio è in grado di controllare l’autenticità del messaggio semplicemente decifrandolo utilizzando la chiave segreta presente (o deducibile da qualche dato) nel db.

Ecco, trovo sia abbastanza buona come idea, il fatto è che gli algoritmi di cifratura a chiave simmetrica, se usati tramite le funzioni mcrypt_* di PHP sono piuttosto delicati, e ce poco che sia trasparente.

Le cose che bisogna sapere sono:

1. la cifratura AES è anche detta RIJNDAEL, ovvero Java dice AES, php dice RIJNDAEL, ma è lo stesso.
2. AES è un algoritmo di cifratura a blocchi, con ciò che ne consegue: un blocco ha una lunghezza fissa.
3. ECB è un modo sbagliato di fare le cose, infatti non prevede di sporcare i blocco da cifrare con i dati del blocco precedente.
4. CBC (o altri metodi che prevedono l’uso del blocco precedente) pretende un initialization vector, che è un blocco creato a caso (random) di dati affinche si possa usare come blocco sporcatore. Esso verra messo all’inizio del messaggio cifrato (verrà messo in chiaro), cosicché il ricevente possa raccapezzarcisi.
5. È un algoritmo a blocchi, quindi il messaggio deve stare precisamente in una lunghezza multipla della lunghezza del blocco, ovvero PKCS padding è appunto il metodo col quale si aggiungono i dati mancanti.
6. Non è strano che venga aggiunto un blocco intero quando la lunghezza dell’input è esattamente un multiplo del blocco, infatti il blocco di padding tipicamente contiene, codificato per ogni sottoblocco (byte), la lunghezza dei dati di padding: [messaggio][padding] … dove [padding] = 0x04,0x04,0x04,0x04 , vale a dire leggendo l’ultimo byte so quanti byte scartare. Quindi una parte di padding DEVE esistere sempre. I blocchi sono di lunghezza 16 bytes (o 32 bytes per RIJNDAEL 256), 8 bits sono sufficienti a rapresentarli
7. Per effetto della vettore iniziale, scelto spesso in modo casuale, lo stesso testo, codificato con la stessa chiave produce una stringa differente, OGNI VOLTA. Ossia encrypt(‘stringa’) != encrypt(‘stringa’)

È anche possibile quindi passare dei dati nel primo blocco, quello fittizio, sempre facendo attenzione di non passare
dati sensibili, e comunque di non superare i 128 bit, ossia i 16 bytes a disposizione.

Ora Steven Holder ha rilasciato questo pacchetto: https://github.com/stevenholder/PHP-Java-AES-Encrypt

Purtroppo sul padding c’era un bug (di cui il punto 6), inoltre a me sembrava migliore instanziare un oggetto (con la chiave passata nel cotruttore) e poi chiare encrypt o decrypt, la chiave è l’hash md5 di una stringa, perché md5 ha esattamente lunghezza 16 bytes, ossia 128 bit. Qui https://github.com/danielecr/aes128encrypter c’è anche l’implementazione node relativa, e strutturalmente equivalente (classe instanziata e encrypt, decrypt).

 Tool online per la codifica https://www.tools4noobs.com/online_tools/encrypt/

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!