Reprise du message précédent :

https://babeljs.io avec Gulp chez nous

Question du dimanche.
 
existe-t-il une source fiable concernant les "naming conventions" pour ce qui est du nom des dossiers dans un serveur web.
 
Il est clair pour tout le monde que :
 
js est le nom du dossier qui va contenir les fichiers en javascript
css est le nom du dossier pour les css
img --> les images
includes --> les includes
vendor --> les 3rd parties librairies
 
Mais concernant les fichiers de traitements pour une action déclenchée par la validation d'un formulaire ?
 
J'ai tendance à utiliser "treatments", certains utilisent juste "do", quel serait le nom standard pour cela ?  

Côté serveur, soit tu fais pareil soit tu te restreints à ce que supporte node —harmony ou [io](https://iojs.org/en/es6.html) (le fork de node avec un v8 plus à jour)

 
merci
 
dire que les gens se foutaient de la gueule de java parce que pour pouvoir pisser, il te fallait un pom.xml de 100 lignes...le tooling JS s'approche de Java tout court

 
Ouais enfin on en est loin là hein (surtout qu'ici c'est pour profiter d'ES6 ) Et merci, pas de XML !

c'est pas complètement faux. Le pack de base d'un projet maintenant c'est

• guld/grunt pour automatiser le build
• bower/webpack/browserfiy pour automatiser les dépéndances client et le packaging
• gitignore pour la gestion de source
• package.json pour les outils nécessaire au build
• editorconfig pour avoir une mise en page cohérenete sur les différentes navigateurs
• readme.md pour avoir une jolie page sur github
• jshint pour avoir des règles cohérentes de mise en forme

Le tout sans le moindre XML

Et je n'ai pas encore parlé de tests ou de serveur

Mais c'est vrai que ca a un impact très positif sur la productivité quand même, et surtout un impact très positif sur la maintenabilité à long terme
J'ai mis en ligne le site de com/doc mobops, vous en pensez quoi ?( du basique bootstrap monté en vitesse)

Je sais pas si c'est ma connexion, j'ai pas pris le temps de vérifier mais les images me semblent super lourdes

 
La largeur de ton conteneur est de 1170 px, mais les images du carousel sont en 3000*2000px pur certaines, et sont lourdes a charger.

 
capture1.jpg
 
Dimensions3000 × 2003
File size3.3 MB
 
Ouch  

oups, j'ai complètement craqué, je corrige ça de suite

 
Idem ici.

Dans la doc, il y a la coquille habituelle : "déconnection"
 
Sinon, pas mal, BS classique, mais pas fan de l'ombre autour des scrshots.

• Les marques, soit tu les capitalises correctement soit tu les capitalises pas du tout Donc iPhone/iPad si Windows/Mac/Linux, sinon iphone. Mais pas Iphone.
• Ya un point qui se ballade tout seul avant le pinning du machin
• Les noms de section ressortent pas dans le texte explicatif, genre Allez dans ma page -> quel tapage? -> Allez dans "Ma page"
• de petits gifs animés/vidéos mp4/webp (et des images plus petites) pourraient être pratiques pour les opérations avec 2-3 sections
• Spacing après un point dans ops en cours, la légende couleur est dispo dans l'application?
• Faudrait anonymiser/flouter les screens, j'ai l'impression que ce sont des vrais (en tout cas le premier pompier que j'ai cherché je l'ai trouvé)
• Faut passer à iojs
• le texte en blanc sur les photos blanche (page d'accueil) c'est meh
• le fichier s'appelle connexion.png mais la section connection
• si c'est pas encore fait, vois pour passer des screenshots applicatifs en PNG8 (via ImageAlpha ou équivalent)

 
ni vu ni connu au milieu des autres points

 
C'est pas mal, juste 2 remarques vues vite fait :
 

 
Decoller le menu du haut, ou alors virer le border-radius sur le haut
 
 

 
Couleur de fond de l'image != couleur de fond du conteneur, ca fait bizarre
-> border : 1px solid #EEEEEE; ou adaptation du fond de l'image

J'ai pas pu m'en empêcher quand j'ai vue la chiée d'icônes sur la page À Propos

Manque l'accent dans le titre d'ailleurs, flo850 il sait pas écrire la france

je corrige tout ça dans l'apres midi

Je vois rien de choquant
 
Attention hein, quand il met un « / » c'est un « ou » pas un « et »

Ça fait au moins 7 fichiers dans autant de formats différents comme base de projet, avant même de parler de tests ou déploiement. Ce qui irait s'il n'y avait pas 3 fichiers différents pour "le build".

Et a la fois chaque fichier a un rôle précis

Le seul pénible est le fichier de build(grunt/gulp), forcément spécifique au projet

Le reste rentre dans deux categlries

assurer des guideline de présentation de code (editorconfig), de structure(jshint) , de ce qu'on commit ou pas (gitignore)

Dépendances : package.JSON, bower.JSON : ces fichiers se construisent tous seuls lors de l'ajout d'une dépendance, a moins que le but du projet soit de publier un package, auquel cas il faut ajouter une description et un email

Chaque fichier à un rôle précis oui, c'est pas une bouillie infâme qui n'a pas de sens ni tout mélangé.

Ce départ te permet d'être scalable jusqu'au coding style de nouveaux collaborateurs, je trouve que c'est pas cher payé par rapport aux avantages !

 
je dis pas que c'est con ou inutile, mais ça me fait juste marrer de voir les gens qui vendent la mouvance JS comme un anti-language-corporate finir par reprendre exactement les mêmes pratiques
 
c'est un peu comme...heu...une startup qui chie sur les rôles de support et finit par embaucher une RH après des problèmes de harcèlements / pratiques de promotions controversées.

Certains esprits mal placés appellent ça la maturité

edit : en tout cas j'ai jamais trouvé JS anti corporate (mais je suis pas les hipster du code ), par contre perso j'aime pas ni Java ni le XML

Tu ne regardes vraiment que la surface sur ce coup :  les différences sont assez notables, même si de nombreuses idées se retrouvent des qu'on passe a l'industrialisation, quel que soit le langage

ET COMME JE PREFERE AVOIR DES FICHEIRS  DE CONF PLUTOT QU UN PUTAIN DE CLASSPATH DE MES COUILLES
EDIT : ET SANS XML

Putain, mais qu'on m'abatte tous les clients qui demandent du WP + framework Genesis + un child Theme à la con + un visual composer
MAIS TUEZ LES

 
client de type agence ?
 
c'est vraiment spécifique comme demande ^^

Quelqu'un a déjà travaillé avec chartist.js http://gionkunz.github.io/chartist-js/ ?

Agence de com', oui.
C'est pas spécifique, c'est nul à chier, j'ai refusé.

ça vaut quoi Genesis ? moi j'utilise un theme starter (Roots qui est maintenant Sage depuis peu)

Si t'aimes bien faire un templating avec une simple ligne de code "genesis();", ouais sbien.

 
Il est dans ma liste de lib de charts à tester
 
D'ailleurs j'en ai noté plusieurs : https://github.com/vatesfr/xo-web/issues/200
 
Le point éliminatoire ça sera l'intégration dans Angular et Browserify.

T'as qu'un dev (cf ton estimation sur highcharts) ?
On avait Open sourcé ça dans mon ancienne boîte pour Highcharts : http://highcharttable.org/ Je m'en sers régulièrement pour grapher

Ca reste moins dégueulasse que le templating de WP

J'ai du mal à comprendre ce concept de « nombre de dev » pour une lib, mais oui, on va pas se disperser, c'est principalement une personne qui va faire les graphs.

edit : j'ajoute ton lien dans les trucs à regarder

Vous aimez angular mais pas typescript alors vous allez detester angular 2: http://blogs.msdn.com/b/typescript [...] cript.aspx

 
Qu'angular2 soit codé en et supporte typescript ca t'obligeras pas pour autant a en faire, tu peux très bien continuer a coder en ES5/6 si tu veux.
 

 
J'imagine que tu ne contribues pas / ne lis pas le code source

Pleins d'annonces et d'avancement chez la concurrence.
 
Ember.js 2.0 annoncé pour le 12 juin. Et c'est code en JS et il n'y a pas besoin de réécrire entièrement son application.
 
La rumeur voudrait en SV que les gens se posent des questions sur la non adoption en interne chez Google, qui serait déjà plus investi dans Polymer.