davidbgk
/
larlet-fr-david
보기 1
좋아요 0
포크 0
코드 릴리즈 0 Activity
Repository with sources and generator of https://larlet.fr/david/ https://larlet.fr/david/
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
251 커밋
1 브렌치
트리: 5c0c1e7585
브랜치 태그
${ item.name }
Create branch ${ searchTerm }
from '5c0c1e7585'
${ noResults }
larlet-fr-david/david/blog/2013/outils-conviviaux/comments/20131220-17h10.md

20131220-17h10.md 2.8KB
Raw Normal View 히스토리

Add initial content
4 년 전
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
​
 12345678910111213141516171819202122232425 
  1. author: David Larlet

  2. date: 2013-12-20T17:10Z

  3. 

  4. 

  5. > Tu définis quatre critères pour pouvoir qualifier un outil de convivial. Le premier est qu’il soit disponible sous la forme d’un unique fichier non minifié. Cette dernière contrainte me fait un peu tiquer. Pour de basses questions de performances, l’outil pourrait gagner à avoir son source minifié.

  6. 

  7. Je ne vois pas très bien la contrainte des performances sur un environnement local, en quoi la taille du code risque d'influer sur le chargement de la page ? Ou alors tu parles d'autres performances ? Dommage de perdre la possibilité de voir la source instantanément depuis son navigateur lors d'une inspection du code par exemple.

  8. 

  9. > Est-ce que, comme pour un logiciel dont on distribue le code source et la version compilée, un outil pourrait être convivial s’il est disponible sous la forme d’un fichier unique minifié et sous la forme de plusieurs fichiers sources, lisibles et commentés ?

  10. 

  11. Ce que je pourrais comprendre par contre c'est la flexibilité lors du développement d'avoir le fichier éclaté afin de pouvoir bénéficier de la coloration syntaxique ou d'outils externes. J'ai peur que cela introduise de la complexité par contre, le fait de tout avoir dans le même fichier peut être un indicateur de la taille à ne pas dépasser avant de devenir incompréhensible pour autrui.

  12. 

  13. > Le troisième critère est la centralisation des données. Ce critère ne pourrait-il pas être alternatif avec la possibilité d’exporter les données ? En effet, offrir une possibilité de synchroniser plusieurs instances de l’outil via un serveur impose de se lier à une solution serveur. Le partage de données via import / export, certes moins pratique, offre à mon humble avis, plus de liberté aux utilisateurs.

  14. 

  15. En effet cela pourrait être une alternative tout à fait valable en attendant du pair à pair, j'ai l'impression que l'on n'est plus très loin d'une solution envisageable [à base de WebRTC][1].

  16. 

  17. > Dernier point, le plus important, proposes-tu une certification « outil certifié convivial par `david`bgk` », à apposer sur mon application si j’arrive à remplir tes critères ? Comme les regrettés badges « Valid XHTML 1.0 »

  18. 

  19. Haha, bien sûr avec un lien vers mon validateur et/ou mieux une formation obligatoire qui permet à des tiers d'être certifiés/certifiants moyennant finances. Le tout [sous licence ABRMS][2] bien évidemment.

  20. 

  21. Blague à part, cette définition est vivante, n'hésite pas à l'enrichir de tes propres critères. Pour moi [MDNHub][3] se rapproche beaucoup de ce que j'avais en tête pour définir une application conviviale et sa taille me semble suffisamment raisonnable pour ne pas avoir à la minifier.

  22. 

  23. [1]: http://simplewebrtc.com/

  24. [2]: https://github.com/landondyer/kasm/blob/master/LICENSE

  25. [3]: http://esquisses.clochix.net/2013/12/19/mdnhub/