Julien Roche - Développeur avancé JavaScript, Web et Java

Voici quelques normes ISO à connaître et que vous aurez à faire face dans vos développements. Et quelques liens / outils permettant de s'assurer que nous faisons correctement leurs intégrations Code Pays https://countrycode.org/ est super site qui permet de lister les pays du monde avec leur country code (en mode number et iso): Et par pays, nous pouvons avoir des informations supplémentaires, comme le format téléphone, la position géographique, la time zone, la monnaie, etc: Ce site du coup regroupe les country code: En ISO 3166 name (où un nom est attribué à un pays) En ISO 3166 numeric (où un chiffre numérique est attribué à un pays) En ISO 3166-1 alpha-2 (code en 2 alpha majuscule) En ISO 3166-1 alpha-3 (code en 3 alpha majuscule) Ainsi que les langues. Tout cela est d'ailleurs regroupés dans ce fichier téléchargeable . Code langue / locale Là, nous tombons dans un des plus grands soucis d'un développeur: co...

Il y a désormais quelques mois, j'avais publier un article sur les "awesomes lists":  http://julienroche.blogspot.fr/2015/10/awesome-lists.html Du coup, je fais un nouvel article pour en publier des nouveaux ! Côté NodeJs (encore une fois, merci Sindre Sorhus): NodeJs:  https://github.com/sindresorhus/awesome-nodejs NPM:  Classique:  https://github.com/sindresorhus/awesome-npm "Avancé":  https://github.com/feross/awesome-mad-science Côté JavaScript: JavaScript:  https://github.com/sorrycc/awesome-javascript ES6 tools:  https://github.com/addyosmani/es6-tools Programmation Fonctionnel:  https://github.com/stoeffel/awesome-fp-js Promises:  https://github.com/wbinnssmith/awesome-promises Côté outils / frameworks JavaScripts: Electron:  https://github.com/sindresorhus/awesome-electron React: Le framework:  https://github.com/enaqx/awesome-react Native:  https://github.com/jondot/awesome...

Le précédent article " NodeJs et le bumping: déjà présent ! " avait pour vocation de montrer la commande "npm version" afin de gérer la gestion de version de nos projets NodeJs. Cette fois-ci, j'aimerai montrer un exemple concret d'usage de cette commande et comment l'automatiser. J'ai fait un petit projet, " sequelize-mocking ", permettant de nous faciliter les tests autour de Sequelize . Et du coup, j'en ai profité pour introduire ces nouvelles commandes. Voici un aperçu du "package.json" avant d'expliquer plus en détail ce que je vais faire: { " name " : " sequelize-mocking " , " version " : " 0.1.0 " , " description " : " A Sequelize extension to deal with mocking for tests " , " main " : " .index.js " , " files " : [ " index.js " , " lib " , " npm-shrinkwrap.json " ],...

Indéniablement, NodeJs s'implante dans nos sociétés. Jusqu'à début 2015, nous avions peu de soucis de gestions de versions: les mises à jour apportés en règle générale de petites corrections / améliorations. Donc nous n'avions pas comme sous Android un phénomène de fragmentation à gérer. Et cela aussi bien sur le serveur de production, ou tout simplement pour les développeurs. La fragmentation Depuis 2015, la fusion entre le projet io.js et NodeJs fait que la donne a changé. Très rapidement, depuis la version Node 0.12.X, des évolutions rapides et majeures sont apparus ! Par exemple Node 0.12.X commence à introduire des fonctionnalités ES6, et la version suivante, la 4.X.X introduit elle une très grande partie des dites fonctionnalités ES6. Ce qui amène le développeur à les utiliser et commencer à produire des modules / applications NodeJs en ES6. De même, depuis Node 4.X.X, une refonte de NPM est faite. Et la gestion des modules entre NPM 2 et NPM 3 a fortement...

Ce petit article a pour vocation de permettre de se souvenir comment activer / utiliser le debugging "avancé" de Webstorm. En effet, je fais pas mal de code NodeJs ces derniers temps, et parfois, pour voir comment réagit une portion de code d'un module présent dans le répertoire "node_modules", j'ai envie d'y placer un breakpoint. Et là, parfois, ça passe, parfois ça passe pas :( En règle générale, quand nous lançons un simple script NodeJs en mode debug, il suffit d'utiliser l'action "Force Step Into". Cela permettra dans le cas présent d'entrer dans le module "lodash" présent dans "node_modules". De même, placer un breakpoint dans le module lodash fonctionnera également. Le problème vient surtout quand nous débuggons des tests, et que nous lançons via Mocha: là, ce n'est pas rare que le point d'arrêt soit ignoré, et que nous ne puissons pas entrer dans les portions de codes pré...