Crunchez vos adresses URL
|
Calculez la conso électrique de votre PC
|
Hébergez vos photos
Page 146 sur 152 PremièrePremière ... 4696136138139140141142143144145146147148149150151152 DernièreDernière
Affichage des résultats 4 351 à 4 380 sur 4541
  1. #4351
    Jekyll et pelican font a peu pres la meme chose... je suis plus a l aise en python...

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

  3. #4353
    Citation Envoyé par Thomasorus Voir le message
    Je l'ai fait pour http://fgweekly.com/ et ça déchire bien
    En effet.



  4. #4354


    Réduit la luminosité de ton écran.

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

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

    C'est pas mal du tout, quelqu'un s'en est deja servi serieusement ?
    Terne lune, molles cordes et MORTLE KUNFU.

  7. #4357
    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 !

  8. #4358
    Citation Envoyé par tenshu Voir le message
    Non mais y'en a rien a faire noir sur jaune c'est douloureux.
    Et encore le premier jaune était bien plus jaune.

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

  10. #4360
    Jade, je m'en servais quand je me cognais des intes, c'est pas mal foutu mais pas spécialement utile.
    Terne lune, molles cordes et MORTLE KUNFU.

  11. #4361
    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

  12. #4362
    Citation Envoyé par hijopr Voir le message
    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.

  13. #4363
    Citation Envoyé par zatura Voir le message
    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.

  14. #4364
    Citation Envoyé par Charmide Voir le message
    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

  15. #4365
    No problemo
    Concrètement, faut lui balancer un..

    Code:
    {
        "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é.

  16. #4366
    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

  17. #4367
    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 )

  18. #4368
    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 ?
    Winter is Coming

  19. #4369
    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?

  20. #4370
    Rapide et précis, merci
    Winter is Coming

  21. #4371

  22. #4372
    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.
    Terne lune, molles cordes et MORTLE KUNFU.

  23. #4373
    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

  24. #4374
    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.
    Terne lune, molles cordes et MORTLE KUNFU.

  25. #4375
    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
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  26. #4376
    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.

  27. #4377
    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...
    Ce qu'il faut savoir, c'est qu'on ment beaucoup aux minmatars, surtout lorsqu'ils posent des questions du style: "t'es sûr que ça vole, ce truc ?" Cooking Momo, le 30/08/09

  28. #4378
    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 ?

  29. #4379
    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.
    J'ai raison et vous avez tort.

  30. #4380
    Citation Envoyé par Teocali Voir le message
    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.

Page 146 sur 152 PremièrePremière ... 4696136138139140141142143144145146147148149150151152 DernièreDernière

Règles de messages

  • Vous ne pouvez pas créer de nouvelles discussions
  • Vous ne pouvez pas envoyer des réponses
  • Vous ne pouvez pas envoyer des pièces jointes
  • Vous ne pouvez pas modifier vos messages
  •