Design & Développement web - Le topic des canards qui mangent des cookies

[la_bosse]

Jekyll et pelican font a peu pres la meme chose... je suis plus a l aise en python...

[Thomasorus]

Yep il en existe aussi en JS pour ceux qui veulent. Après tout est une question de préférences.

[tenshu]

Je l'ai fait pour http://fgweekly.com/ et ça déchire bien

En effet.

[Thomasorus]

En effet.
http://static.comicvine.com/uploads/...0949-a9917.jpg

Réduit la luminosité de ton écran.

[tenshu]

Non mais y'en a rien a faire noir sur jaune c'est douloureux.

[Monsieur Odd]

Je suis tombe la dessus : https://www.dreamfactory.com/

C'est pas mal du tout, quelqu'un s'en est deja servi serieusement ?

[Awake]

Je vais bientôt bosser plusieurs mois avec ElasticSearch. Si vous avez des feedbacks ou des infos dessus (même si la doc est assez complète, l'outil est plus abouti que ce que je pensais), je suis preneur !

[Thomasorus]

Non mais y'en a rien a faire noir sur jaune c'est douloureux.

Et encore le premier jaune était bien plus jaune.

[Fastela]

Y'a des gens qui utilisent Jade et/ou Handlebars ici ? Quel est votre avis ?

[Monsieur Odd]

Jade, je m'en servais quand je me cognais des intes, c'est pas mal foutu mais pas spécialement utile.

[zatura]

Y'a des Canards qui connaissent un moyen ergonomique d'intégrer beaucoup de données en provenance d'un fichier excel ?

Je dois l'afficher sous forme de tableau mais le problème c'est qu'il y a énormément de colonnes du coup à part mettre du scroll horizontal dégueulasse je sèche un peu...

Si vous connaissez des librairies JS sympa pouvant rendre le tout un peu plus sympa à regarder ça m'intéresse

[Charmide]

Je vais bientôt bosser plusieurs mois avec ElasticSearch. Si vous avez des feedbacks ou des infos dessus (même si la doc est assez complète, l'outil est plus abouti que ce que je pensais), je suis preneur !

Bonne chance

Pas de conseils généraux particuliers. Au final c'est un outil plutôt sympa à manipuler et qui peut en faire beaucoup, par contre la courbe d'apprentissage est un peu raide au début (même si on peut se passer de la compréhension de beaucoup de choses en première approche). Notamment parce que ça souffre de ce conflit de personnalité entre la base Lucene et le rôle de surcouche moteur de recherche, et l'ambition (achevée) de se suffire comme une base de données indépendante.

Les principaux "gotcha" contre lesquels je te conseille de te prévenir concernent principalement les mappings. Ce sont des pseudo-schéma qui définissent comment sont structurées tes données, que tu peux soit déclarer toi-même, soit laisser ES inférer. Les modifier demandent de détruire la donnée et de la recréer sur un autre index. Flexibilité-level de SQL.
Un truc très con quand tu arrives, qui donne une idée du genre de surprises: si tu lui passes un /user {"email": "TOTO@gmail.com"} et que 30s plus tard tu cherches naïvement à retrouver un /user avec comme email "TOTO@gmail.com", il y a des chances, selon la query que tu utilises, que tu ne le retrouves pas. Pourquoi? Parce que ES tokenize le texte par défaut, vu que c'est son boulot d'origine. Ce que tu as dans la base de données, c'est un email === toto, gmail, com. Ce genre de choses est également décidé via mappings.

[gros_bidule]

Y'a des Canards qui connaissent un moyen ergonomique d'intégrer beaucoup de données en provenance d'un fichier excel ?

Je dois l'afficher sous forme de tableau mais le problème c'est qu'il y a énormément de colonnes du coup à part mettre du scroll horizontal dégueulasse je sèche un peu...

Si vous connaissez des librairies JS sympa pouvant rendre le tout un peu plus sympa à regarder ça m'intéresse

https://d3js.org/ est pas mal pour présenter des données.

[Awake]

Bonne chance

Pas de conseils généraux particuliers. Au final c'est un outil plutôt sympa à manipuler et qui peut en faire beaucoup, par contre la courbe d'apprentissage est un peu raide au début (même si on peut se passer de la compréhension de beaucoup de choses en première approche). Notamment parce que ça souffre de ce conflit de personnalité entre la base Lucene et le rôle de surcouche moteur de recherche, et l'ambition (achevée) de se suffire comme une base de données indépendante.

Les principaux "gotcha" contre lesquels je te conseille de te prévenir concernent principalement les mappings. Ce sont des pseudo-schéma qui définissent comment sont structurées tes données, que tu peux soit déclarer toi-même, soit laisser ES inférer. Les modifier demandent de détruire la donnée et de la recréer sur un autre index. Flexibilité-level de SQL.
Un truc très con quand tu arrives, qui donne une idée du genre de surprises: si tu lui passes un /user {"email": "TOTO@gmail.com"} et que 30s plus tard tu cherches naïvement à retrouver un /user avec comme email "TOTO@gmail.com", il y a des chances, selon la query que tu utilises, que tu ne le retrouves pas. Pourquoi? Parce que ES tokenize le texte par défaut, vu que c'est son boulot d'origine. Ce que tu as dans la base de données, c'est un email === toto, gmail, com. Ce genre de choses est également décidé via mappings.

Oula

Et concrètement, si je veux faire une query sur l'email, pour avoir exactement les résultats sur cet email, et pas ceux qui y ressemble. Une query de base de données et pas de moteur de recherche donc. Je fait comment ?

Merci pour la réponse en tout cas

[Charmide]

No problemo
Concrètement, faut lui balancer un..

{
    "email": {
        "type":     "string",
        "index":    "not_analyzed"
    }
}

.. dans le mapping de l'objet de type "user", avant de créer le premier utilisateur doté d'un email et que ES assigne à ce champ un analyzer par défaut et indexe les objets via les tokens qui en sorte. Parce qu'après, c'est fini.
Sur le papier c'est plutôt simple. Par contre, dans le projet que je pilote par exemple, un objet "user" tu peux en avoir un directement indexé à la racine avec le type "user", un dans un sous champ "owner" dans un objet de type "item", un dans un sous champ "buyer", un dans un champ "users présent" dans un objet "chat", etc. Faut alors préciser pour chacun de ces cas que l'email n'est pas un champ sur lequel on va faire de la recherche textuelle libre. Si tu as besoin de faire une query exacte sur ce champ là, en tout cas. Bref, c'est moche. On en est encore à: 1) mettre aucun caractère spécial quand on peut histoire que le fait que le champ soit analysé ne change rien, 2) consciemment ignorer les nombreux cas où nul part dans l'applicatif on a besoin d'une recherche par match exact.
Toujours pas eu l'occasion de réellement réfléchir au problème et de trouver un moyen intelligent de gérer ça à long terme. Laisser l'applicatif les déterminer et être en capacité de réindexer tout facilement pour changer de mappings dynamiquement, par exemple.
C'est à peine un problème si tu bosses sur un projet à périmètre bien défini et à horizon arrêtée.

En tout cas, j'ai eu encore l'occasion de m'en rendre compte depuis mon dernier post, ça marche vachement bien sans beaucoup de travail pour de la recherche en texte et pour des requêtes complexes.
Je cherche des "tuyaux d'arrosage" "neuf" et "rose", je veux que tu me retourne d'abord des tuyaux d'arrosage neuf et rose, ensuite des tuyaux d'arrosage rose, puis neuf, puis des tuyaux d'arrosage non-rose et non-neuf, puis des objets rose ou neuf triés comme tu veux, avec dans chacune de ces catégories un meilleur score (donc une mise en avant) des objets dont le vendeur est sponsorisé. Le tout combiné avec une recherche textuelle entrée par l'utilisateur, avec priorité si il y a un match sur le titre plutôt que la description. Et ce tout en ignorant les mots qui reviennent souvent comme "et" et "ou". Et en étant suffisamment intelligent pour ne pas tripler le score quand l'utilisateur recherche "pouet" et que "pouet" est présent 3 fois dans le titre et la description, mais en le prenant en compte quand même. Et en faisant le café.

[Awake]

Ouais de ce que je vois c'est un excellent moteur de recherche, par contre comme base de documents, pas super-glop. Le gros problème, c'est le que c'est la base de document dont on a besoin sur 95% du projet. Quelle bande de chips les gars qui ont commencé ça avant moi .

En plus je boss sur un projet qui va évoluer avec le temps, donc il va falloir reindexer les bases par moment. On se demande toujours comment on fera en prod (on m'a parlé d'une histoire d'alias).

7 mois ça va être long

[TKN Jez]

Y'a des canards lyonnais qui connaissent Smile sur Lyon? :smile: (fait chier que ce smiley ait disparu, je l'aimais bien et il était de circonstance )

[Omaley]

Bonjours a tous, je code actuellement un module pour Prestashop et je suis a l'etape ou je dois pouvoir lire/modifier les cookies rapidement sauf qu'a chaque fois je dois retourner dans les paramètres de mon navigateur pour les voir.

Existe t'il un outil qui permet de lire les cookies stocké en local ?

[TKN Jez]

Si t'utilises chrome, cookie inspector est ton copain (il ajoute un onglet dans la console de débug direct pour que tu puisses éditer les cookies). Je pense que tu peux trouver des outils externes, mais perso je préfère tout centraliser dans mon navigateur (je pense qu'il doit exister le même type d'extension pr FF si tu préfère le panda roux :3)

Et pour ma question précédente, personne?

[Omaley]

Rapide et précis, merci

[TKN Jez]

De rien

[Monsieur Odd]

Putain je viens de finir un projet en MVC form scratch, 5 jours de taf.

Ne le faite pas, c'est chiant comme la mort.

Mais maintenant j'ai mon framework a moi.

[Awake]

Quelle drôle d'idée

Avec les milliards de frameworks MVC en PHP, t'en as pas trouvé un qui te plaît ?

Ou mieux, Symfony :lourd:

Je veux bien voir le code si tu l'a mis sur un repo publique

[Monsieur Odd]

C'est pour le taf, je le foutrai sur github une fois qu'il ne servira plus. (dans deux semaines quoi).

Framework c'est peut etre un peu trop pompeux. Faudrait que j'en rajoute pas mal, mais comme base de travail pour des mini apps ca va me servir je pense.

[Teocali]

question conne pour les canards qui bouffent du front end : vous me conseillerez quel techno pour une UI orienté composant coté client ? Sachant que la partie serveur sera géré par une API Rest. Pas besoin de Node.JS, donc.

A la base, j'étais parti pour du React, mais ça l'air d'être un bordel sans nom a utiliser sans Node.JS

[gros_bidule]

AngularJS est pas mal, mais c'est un gros morceau.
Mais je ne comprends pas pourquoi tu parles de NodeJS. Tu n'as pas besoin de NodeJS pour faire du frontend. A la limite si tu veux manager ton projet avec des trucs comme grunt, bower et tout et tout, mais ça s'arrête là (et ton utilisation de NodeJS se limitera à des "npm install coincoin"). Ton site tournera sans NodeJS.

[Teocali]

Bon, alors, faut bien capter que je suis une (très) grosse bite en frontend. Enfin, non, pas une bite, mais violemment outdated.
En gros, pour le moment, j'ai vraiment l'impression que tous les tutoriels que je parcours partent du principe que tu vas packager et faire tourner ton application dans nodeJS. Et ça, non, on veut vraiment pas.
Mais je suis petit à petit en train de débroussailler tout ce bordel. je crois que je vais partir sur du npm pour la gestion des dépendances, et sur du browserify pour packager tout ça gentiment coté client.


Mais bordel, je suis à 100% d'accord avec Sam quand il parle du JS et de la dette technique. C'est simple, j'ai l'impression d'être revenu aux balbutiements des gestionnaires de package en Java (maven 1, pour les vieux d'la vieille). Vivement que ça se calme et que des solutions "leader" émergent de tout ce bordel. Pour dire, y'a 5 minutes, J'en étais à deux doigts de pas me faire chier et d'écrire pour interface graphique client en JSP, histoire de plus me faire chier...

Et pour revenir à Angular, on hésitait, mais avec la version 2 qui pointe le bout de son nez, on est vraiment pas chaud. Sans compter que le site qu'on developpe maintenant sera sans doute scratché et réécrit quand on aura réussi à faire monter un vrai frontend dans la barque, on se demande si ça vaut le coup de s'investir la dedans...

[gros_bidule]

Haa yes, sûr que c'est pas la joie en ce moment côté frontend, il faut être courageux pour maitriser des technos qui seront boudées l'an prochain, en plus d'encore et toujours tourner sur du fichu JS .
Où qu'il est l'équivalent de Spring ?

[Sekigo Le Magnifique]

Si c'est pour un truc temporaire et pas trop important, tu peux toujours utiliser ce bon vieux jquery pour les api rest + les autres trucs qu'il propose, knockout pour les composants (il a des défauts, mais l'apprentissage de la bibliothèque est vraiment bien foutu, et pour un truc simple, ses avantages dépassent ses inconvénients) et requireJS pour la gestion des modules (c.a.d. le découpage en plusieurs fichiers js).

Si c'est pour un truc plus complexe, partir sur du angular 1. C'est chiant à apprendre, mais la façon de structurer ne dépaysera pas un dev back.

De toute manière, en JS, quoi que tu choisisses, ce sera un mauvais choix.

[Charmide]

question conne pour les canards qui bouffent du front end : vous me conseillerez quel techno pour une UI orienté composant coté client ? Sachant que la partie serveur sera géré par une API Rest. Pas besoin de Node.JS, donc.

A la base, j'étais parti pour du React, mais ça l'air d'être un bordel sans nom a utiliser sans Node.JS

React c'est très bien pour ça. Tous les autres facteurs égaux, notamment tes connaissances pré-existantes, autant apprendre ça.
Angular 2 est plus expérimental mais c'est ma perception qu'il est utilisable maintenant. Ca n'a plus grand chose à voir avec la version 1 (en bien, et c'est plutôt courageux).
Angular 1 c'est très bien, ça a été ta "solution leader" pendant 5 ans, mais c'est certainement pas "orienté composant". J'ai du mal à voir l'intérêt de commencer par ça aujourd'hui si tu ne t'y connais pas déjà (auquel cas y'a peu de raison de se mettre à changer pour l'instant), mis-à-part si t'es dans une agence et que t'as envie de recruter plus facilement.

Pas besoin de node a priori effectivement, si ce n'est généralement pour l'environnement de dev (faire tourner un serveur local qui live reload et fait quelques autres trucs, ça passe par node directement, ou gulp ou grunt - idem pour de la précompilation ou de la mise en bundle).
En React en particulier, fais gaffe à bien choisir la façon dont tu commences à construire le projet. Je te conseille vraiment de partir du truc le plus minime possible. Typiquement, t'auras des tas de tutos/guides/intro/boilerplates React qui vont te placer un backend en node avec de l'isomorphisme quand tu en as rien à cirer, plus résoudre 30 tonnes de trucs dont tu n'as rien à faire.
Partir sur npm+browserify comme tu le racontes, même en quasi vanilla, ça me paraît bien.

La bonne nouvelle qui est certainement pas très intuitif quand tout le monde gueule sur la ~jungle des frameworks~ et qu'on aurait 20394 solutions concurrentes parallèles, c'est que la tendance générale suivie par absolument tout le monde, c'est la simplification et la modularité.
Angular 1 c'était une brique MVC qui voulait s'occuper de tout, sa dominance a lancé une contre-révolution plus modulaire. Knockout c'était l'un des premier d'ailleurs, de mémoire c'est très Angular 1 light.
React c'est du fat mais ça ne s'occupe que de la Vue, avec le découplage maximum avec la logique que tu peux avoir en front, et même les side effects style appels serveurs, clic de l'utilisateurs, etc. (là où Angular 1 c'est la fête aux bindings et donc au couplage).
D'un point de vue un peu plus théorique, la philosophie de React et dans une certaine mesure d'Angular 2 et des autres trucs avec le vent dans le dos, ce sont des préceptes du fonctionnel: la vue est une fonction pure de l'état de l'application. Ce que tu vois sur ton écran est immutable.

Selon la taille de ton projet, le contexte, si tu comptes faire du front pour les 10 prochaines années, ta tendance hipster, ton amour de la réinvention, et d'autres trucs, je te conseille soit de partir sur du React, soit sur des technos plus légères (Knockout peut en être une, Vue en est une autre, Mithril a bonne rep, etc.).
Pour garder l'esprit sain et en particulier si t'as habitué à des languages pastropnaze, je conseille d'écrire en ecma script édition 2065 et de transpiler. C'est transparent avec du browerify ou du webpack.
Et de pas intégrer jquery juste pour faires des appels HTTP

Et non, JS c'est pas systématiquement de la merde si tu fais des choix intelligent, peu importe ton choix de framework ou si tu t'amuses à manipuler le DOM à la main.