Le topic de la programmation, string, chaînes, cuir et compagnie

[Sekigo Le Magnifique]

Poi.

Reservé. Merci Sekigo

Tu as reçu le MP ? J'ai rien dans ma liste de messages envoyés. Et y a aucun feedback.

[Tramb]

Très bon jeu, quitte à hors-sujer

[Teocali]

Tu as reçu le MP ? J'ai rien dans ma liste de messages envoyés. Et y a aucun feedback.

Rah le con, j'étais persuadé d'avoir répondu ><. Désolé sekigo. Et encore merci je dl demain.

[deathdigger]

Tu as reçu le MP ? J'ai rien dans ma liste de messages envoyés. Et y a aucun feedback.

T'as filé le jeu à un mec qui code exclusivement en Windev. Tu ne te sens pas sale ?

[Teocali]

Oo
Tu confondrais pas avec un autre ? Je code avec que je veux, monsieur. Et c'est souvent avec les pieds.

[Frypolar]

T'as filé le jeu à un mec qui code exclusivement en Windev. Tu ne te sens pas sale ?

Ah mais c’est pour ça qu’il signait tous ses messages avec son pseudo pendant un temps, il avait le cerveau ravagé

Teocali

[vectra]

Mon prof qui rentre de Saclay après avoir présenté nos travaux (ou ex-travaux en ce qui me concerne).
Visiblement, ils recruteraient bien des gens qui font du GPU, et c'est le deuxième CEA où les gens semblent découvrir la techno.

Ca doit sûrement être bien, mais les CDD dans le public, passé 40 ans, ça fait adolescent qui refuse de vieillir ou un truc du genre

[FB74]

Humble Bundle dédié à la programmation (jeux):
https://www.humblebundle.com/books/c...es-book-bundle

[Teocali]

Ah mais c’est pour ça qu’il signait tous ses messages avec son pseudo pendant un temps, il avait le cerveau ravagé

Teocali

Je t'emmerde, Frypo. Cordialement, mais je t'emmerde.

Et sinon, j'ai jamais developpé en WinDev. Le plus proche que j'ai étais de Windev, c'est gamin quand je me branlais sur des magazines qui avait le même contenu que les pubs windev en plus dénudé.

- - - Mise à jour - - -

Mon prof qui rentre de Saclay après avoir présenté nos travaux (ou ex-travaux en ce qui me concerne).
Visiblement, ils recruteraient bien des gens qui font du GPU, et c'est le deuxième CEA où les gens semblent découvrir la techno.

Ca doit sûrement être bien, mais les CDDtravailler dans le public, passé 40 ans, ça fait adolescent qui refuse de vieillirfeignasse qui refuse de bosser ou un truc du genre

fixed. ³

[Anonyme32145]

[Nilct]

Bonjour,

J'ai besoin d'un coup de pouce pour savoir si ce que j'envisage n'est pas stupide et pour savoir comment faire.
J'ai grosso modo 3 codes (l'un calcule une géométrie, l'autre la mémorise avec un score, le 3ème la visualise):

• A qui fait du calcul intensif (en java pour l'instant, mais par la suite en Go)
• B une BD qui recevra et enregistrera de temps en temps une solution de A (pas encore choisie, le plus léger et simple à déployer est le mieux)
• C qui exploitera les nouvelles données de B et donnera un état d'avancement (je pensais à HTML5)

Pour l'instant c'est en local, mais j'aimerai bien distribuer le tout (plusieurs machines qui font tourner A, une autre pour B et C)

Mon megaproblème c'est que je n'arrive pas à comprendre comment faire communiquer tout ça. JSON pourra me servir pour encapsuler les données (qui ne sont pas volumineuses) mais pour le protocole de communication ?

Je m'y connais bien en algorithmie et bas niveau, mais dès que ça touche au web/client/serveur, je suis une quiche...

Merci d'avance pour toute information qui me mettrait sur le bon chemin.

[Sekigo Le Magnifique]

Tout dépend de B et de la base de données utilisée.
La plupart des BDD embarquent leurs propre protocoles de communication à distance.
Si la sécurité n'est pas une priorité (et plus particulièrement les droits d'accès), tu peux très bien faire communiquer A et C avec B via ce protocole, A et B utilisant donc le client de la BDD. Ainsi, pas besoin d'écrire quoi que ce soit au niveau des envois de données.
Si tu dois t'assurer un contrôle strict sur les données à récupérer, alors tu peux effectivement passer par une api REST (donc http) qui renverra des données en JSON. Mais ce n'est qu'une possibilité parmi une infinité. Tu peux très bien passer par des chaussettes par exemple.

C'est difficile de répondre exactement à la question. Il peut y avoir un millier de raisons de choisir l'une ou l'autre solution.
À titre personnel, je choisirai la première si les machines sont sur le même réseau, avec un contrôle strict des accès à chaque machine. Parce que je n'écrirai jamais un meilleur code que les personnes ayant codé les clients et les protocoles propre à chaque base (pour les trucs les plus mainstream en tout cas), et que le risque d'avoir un trou de sécurité dans mon api REST est plus forte que pécho les mots de passes sur les serveurs ou d'installer un homme du milieu sur mon réseau.
Et que je suis aussi une grosse feignasse qui veut pas me faire chier à implémenter une api REST pour un truc un poil trivial.

[Cwningen]

En HTTP+JSON pour les feignasses, tu dois pouvoir trouver des bibliothèques de JSON RPC qui font le travail.

[Orhin]

Et que je suis aussi une grosse feignasse qui veut pas me faire chier à implémenter une api REST pour un truc un poil trivial.

Non mais une API Rest ça s'implémente plus à la main hein, y'a de très bon générateur de code qui font ça à ta place (pour le front ET le back) à partir d'un simple fichier de spec.
Cadeau : http://swagger.io/

Pour la partie C, le mieux est effectivement de partir sur HTML5/CSS3 + Javascript ou Typescript.
Par contre va falloir utiliser un framework si tu veux pas réinventer la roue en permanence.
Pour ce point c'est surtout une question d'opinion, mais Angular 2 et React sont largement au dessus du lot.

[Sekigo Le Magnifique]

Non mais une API Rest ça s'implémente plus à la main hein, y'a de très bon générateur de code qui font ça à ta place (pour le front ET le back) à partir d'un simple fichier de spec.
Cadeau : http://swagger.io/

Je connaissais pas ce truc.
Mais je viens de checker et de générer un truc. Hormis la surprise de voir que c'est Zalendo qui gère la partie python+flask, j'ai pas trouvé ça fou-fou pour mon utilisation. Parce que le design d'une api, c'est rapide à faire (surtout avec Flask), c'est l'implémentation des récupérations de données et logique qui est relou (et je pensais que swagger allait proposer ça).
Mais je garde le truc sous le coude pour la partie client (à mon boulot, j'ai des tonnes d'apis et y en a aucune qui a de client php "officiels" parce que... la flemme). Peut-être aussi la partie doc.

Je creuse ça quand même, j'ai fait du quick-and-dirty pour tester. Et faut aussi que je check le code, parce que je ne veux pas qu'il envoie le truc sur des serveurs externe sans mon accord explicite (je me méfie des nouveaux services de ce type).

[Nilct]

Merci pour toutes ces pistes !
Je note :

• utiliser les API d'accès à la BD (et donc choisir une BD "compatible" avec Go/JS)
• pour les autres types de communications, regarder du coté de REST.

Je vais regarder swagger après avoir compris ce qu'est "REST". Merci!

[Nattefrost]

Est-ce que les outils genre Swagger sont utilisables sans utiliser d'ORM et donc de models? J'ai dans l'idée qu'ils se basent sur les models pour générer les urls de l'api, me tompe-je ?

Ces temps-ci j'essaie de mettre un max de choses en BDD, qui sert directement du json à la couche http qui le ressert à son tour au client. Mais c'est vrai que jusqu'ici j'ai pas éprouvé le besoin d'automatiser la création de l'API, comme dit Sekigo ça se fait bien avec Flask (ou Sinatra).

[Orhin]

c'est l'implémentation des récupérations de données et logique qui est relou (et je pensais que swagger allait proposer ça).

Y'a quand même une limite à l'automatisation.
La génération de code est surtout intéressante pour les sdks clients, surtout si t'attaques ton API Rest à partir d'un site Angular + une appli native Android + un autre serveur node + etc.

Pour le côté serveur y'a forcément encore du taf "manuel" à faire.
Mais y'a quand même moyen de gagner du temps avec certains framework (genre https://loopback.io, d'ailleurs il possède aussi un générateur swagger histoire d'utiliser les outils au maximum).

j'ai des tonnes d'apis et y en a aucune qui a de client php "officiels"

De mon point de vue c'est plutôt une bonne chose.

Et faut aussi que je check le code, parce que je ne veux pas qu'il envoie le truc sur des serveurs externe sans mon accord explicite (je me méfie des nouveaux services de ce type).

Perso j'ai jamais aperçu le moindre souci.
Toutes les sources sont sur github de toute façon : https://github.com/swagger-api

Est-ce que les outils genre Swagger sont utilisables sans utiliser d'ORM et donc de models? J'ai dans l'idée qu'ils se basent sur les models pour générer les urls de l'api, me tompe-je ?

Swagger n'impose pas de fonctionnement particulier, tu décris ton API de la façon que tu veux tant qu'elle respecte les specs OpenAPI : https://www.openapis.org/

Mais c'est vrai que jusqu'ici j'ai pas éprouvé le besoin d'automatiser la création de l'API, comme dit Sekigo ça se fait bien avec Flask (ou Sinatra).

L'intérêt des outils comme swagger n'est pas que dans la génération du code.
Ça te permet aussi :
- d'avoir un document de référence pour ton API sur lequel plusieurs personnes peuvent travailler ;
- de générer facilement des bouchons de test avec leur module node ;
- de générer de la doc propre facilment.

[Nattefrost]

Merci, du coup je vais regarder plus en détails .

PS : la spec elle-même est ici , si d'autres cherchent.

[Teocali]

Nilct, pour créer facilement une API reste pour B, jette un oeil sur Spring rest data.
En gros,
: - tu crées des entités avec l'Orm de ton choix
- tu crées tes fait en définissant les méthodes (juste la définition. Spring data se charge de l'implémentation au runtime, en fonction du nom de la méthode). Les méthodes CRUD sont déjà fournies de base.
- tu utilises Spring rest data pour créer ton API rest au runtime.

En gros, si tu as simplement besoin d'un accès CRUD à ta base de données, le seul code que tu auras à écrire c'est celui du domaine, que tu peux même éventuellement générer à partir du modèle DB

[Patate]

Hum je reviens avec une petite question c++ ! J'ai pas mal de warning dans mon projet qui est dû à une librairie extérieure. Il est possible de l'écarté des paramètres de compilations pour n'avoir que les warnings de mon code ? Je suis sous GCC.

[Sekigo Le Magnifique]

Il y a quelques mois, ma boite à réalisé des entretiens pour recruter un nouveau développeur. Une quinzaine de personne ont été auditionnées.
Le test technique consistait à récupérer un xml dans une base de données mysql (via une requête basique SELECT MACHIN FROM TRUC WHERE FIELD = "bidule"), à récupérer le titre dans ce xml (une simple balise sans aucun piège) et à insérer ce titre dans une autre table.
Le test se faisait avec une connexion internet, dans un bureau au calme et avec une demi-heure (flexible).

Aucun n'a réussi à 100%, et les trois quarts n'avaient même pas réussi à passer la première étape.

On a donc pris le mec le plus sympa, faute de mieux.
Et bien, bilan : le mec est très compétant, débrouillard et n'hésite pas à poser des questions après avoir un peu cherché par lui-même.

Comme quoi.

[Anonyme32145]

Les gens avaient quoi comme formation ?
Avec le net c'est chaud de ne pas pouvoir faire l'étape 1

[Teocali]

Il y a quelques mois, ma boite à réalisé des entretiens pour recruter un nouveau développeur. Une quinzaine de personne ont été auditionnées.
Le test technique consistait à récupérer un xml dans une base de données mysql (via une requête basique SELECT MACHIN FROM TRUC WHERE FIELD = "bidule"), à récupérer le titre dans ce xml (une simple balise sans aucun piège) et à insérer ce titre dans une autre table.
Le test se faisait avec une connexion internet, dans un bureau au calme et avec une demi-heure (flexible).

Aucun n'a réussi à 100%, et les trois quarts n'avaient même pas réussi à passer la première étape.

On a donc pris le mec le plus sympa, faute de mieux.
Et bien, bilan : le mec est très compétant, débrouillard et n'hésite pas à poser des questions après avoir un peu cherché par lui-même.

Comme quoi.

Stocker du XMl dans une BDD... Moi, j'aurais foutu le feu au bureau, et j'aurais cherché le mec qui a pondu ça pour lui faire bouffer les touches du clavier une à une, de bas en haut, avec du piment par dessus... :extremiste:

Sinon, plus serieusement, est-ce qu'un techos était impliqué dans la revue des CVs ?

Et accessoirement, les tests techniques en ligne, c'est généralement de la merde, mais je trouve que ceux proposés par codility sont plutot pas mal, aussi bien coté dev que coté recruteur.

[Tramb]

Stocker du XMl dans une BDD... Moi, j'aurais foutu le feu au bureau, et j'aurais cherché le mec qui a pondu ça pour lui faire bouffer les touches du clavier une à une, de bas en haut, avec du piment par dessus... :extremiste:

Ah c'est pour ça qu'on t'explique les bases SQL ça tient pas la perf.
Et qu'on t'explique qu'il faut stocker du JSON dans des bases NoSQL.
Tout se recoupe.

[Sekigo Le Magnifique]

Le test technique, c'est moi qui l'ai fait... 5 minutes avant (je crois que je l'ai fini pendant l'audition du premier candidat). Parce que impossible d'avoir un minimum de temps alloué pour ça la veille (parce que bien entendu, j'ai été prévenu la veille). Je voulais juste faire un truc pour filtrer les mecs qui ne connaissent RIEN à la programmation, et qui légalement autorisé à s'approcher d'un clavier. On en a déjà eu (et l'un d'entre eux est le patron....). Et comme une grosse partie de nos données sont en xmls...
En plus, je leur ai dit qu'il n'y avait pas de piège, je leur ai expliqué qu'il pouvait utiliser une regexp ou tout autre moyen à l'arrache. C'est dans UNE BALISE unique, je leur ai à moitié fourni la réponse.

Pour le pré-filtrage des CVs, j'ai juste eu le résultat final. J'ai toutefois pu mettre la main sur la liste des CV recalés. Et Oh, Incroyable ! une partie des personnes recalés étaient celle qui demandaient un salaire convenable vis à vis de leurs expériences. On a quand même réussi à avoir du patron de payer convenablement le nouvel embauché, pour éviter qu'il se tire dans trois mois.

Et toutes les personnes avaient fait une école en programmation, avec des tonnes d'acronymes (j'imagine que ça fait bander les patrons). Je n'en ai personnellement pas fait (ma réorientation dans ce secteur est un accident de parcours, dirons-nous), et après mes expériences de recrutements ces dernières années, je suis bien content de ne pas avoir vendu un rein et m’endetter sur 90 ans pour en avoir du mal à coder un hello world.

- - - Mise à jour - - -

Stocker du XMl dans une BDD... Moi, j'aurais foutu le feu au bureau, et j'aurais cherché le mec qui a pondu ça pour lui faire bouffer les touches du clavier une à une, de bas en haut, avec du piment par dessus... :extremiste:

Sinon, plus serieusement, est-ce qu'un techos était impliqué dans la revue des CVs ?

Et accessoirement, les tests techniques en ligne, c'est généralement de la merde, mais je trouve que ceux proposés par codility sont plutot pas mal, aussi bien coté dev que coté recruteur.

Dans notre cas, OSEF.
Les xmls stockés sont juste associés à une clé primaire. On ne cherche jamais dans ces xmls, la base de données est juste un gros contenaire.
Après, j'aurais stocké plutôt ça en clair sur le disque, mais bon, c'est pas moi qui était là au départ. Et je ne trouve pas ça choquant d'avoir ça dans du sql.

[Teocali]

Pour le pré-filtrage des CVs, j'ai juste eu le résultat final. J'ai toutefois pu mettre la main sur la liste des CV recalés. Et Oh, Incroyable ! une partie des personnes recalés étaient celle qui demandaient un salaire convenable vis à vis de leurs expériences. On a quand même réussi à avoir du patron de payer convenablement le nouvel embauché, pour éviter qu'il se tire dans trois mois.

Faut pas s'étonner de récupéprer des singes quand on paye des cacahouètes. A ressortir à ton patron à l'occasion.

Dans notre cas, OSEF.
Les xmls stockés sont juste associés à une clé primaire. On ne cherche jamais dans ces xmls, la base de données est juste un gros contenaire.
Après, j'aurais stocké plutôt ça en clair sur le disque, mais bon, c'est pas moi qui était là au départ. Et je ne trouve pas ça choquant d'avoir ça dans du sql.

Bah, je fais mon extremiste, parce que la plupart du temps, c'est une trs mauvaise solutions, mais si comme tu le dis, tu ne cherches jamais dans le xml, pas de réel soucis... a part le jour ou on te demandera de chercher dedans

[elpaulo]

Sekigo Le Magnifique : Les candidats avaient le choix du langage ou vous en avez imposé un ?

[Foudge]

Et toutes les personnes avaient fait une école en programmation, avec des tonnes d'acronymes (j'imagine que ça fait bander les patrons). Je n'en ai personnellement pas fait (ma réorientation dans ce secteur est un accident de parcours, dirons-nous), et après mes expériences de recrutements ces dernières années, je suis bien content de ne pas avoir vendu un rein et m’endetter sur 90 ans pour en avoir du mal à coder un hello world.

Faut surtout pas croire que les études en informatique ne servent à rien et créént que des gars qui ne savent pas faire un hello world. Les bons/motivés/passionnés savaient déjà le faire avant même leurs études, et les "mauvais" (car oui il y en a toujours) ne savaient toujours pas faire un petit programme simple tout seul à la fin de leurs études. Clairement, on ne conservant que les CV réclamant des bas salaires, tu te retrouves avec une forte concentration de tartuffes

Dans notre cas, OSEF.
Les xmls stockés sont juste associés à une clé primaire. On ne cherche jamais dans ces xmls, la base de données est juste un gros contenaire.
Après, j'aurais stocké plutôt ça en clair sur le disque, mais bon, c'est pas moi qui était là au départ. Et je ne trouve pas ça choquant d'avoir ça dans du sql.

Je stocke parfois des petites structures XML dans SQL Server, en particulier avec le Service Broker. Après tout, quand on stocke un NVARCHAR on se fout de savoir sa structure interne, c'est juste une donnée comme une autre qui sera exploitée en dehors de SQL. Ce qui est con je pense ce serait de choisir ce format pour "simuler" des colonnes supplémentaires et/ou exploiter les valeurs contenues dans la structure XML au sein de code SQL. Ceci dit, je ne suis pas un expert en bases de données

[deathdigger]

Il y a quelques mois, ma boite à réalisé des entretiens pour recruter un nouveau développeur. Une quinzaine de personne ont été auditionnées.
Le test technique consistait à récupérer un xml dans une base de données mysql (via une requête basique SELECT MACHIN FROM TRUC WHERE FIELD = "bidule"), à récupérer le titre dans ce xml (une simple balise sans aucun piège) et à insérer ce titre dans une autre table.
Le test se faisait avec une connexion internet, dans un bureau au calme et avec une demi-heure (flexible).

Aucun n'a réussi à 100%, et les trois quarts n'avaient même pas réussi à passer la première étape.

On a donc pris le mec le plus sympa, faute de mieux.
Et bien, bilan : le mec est très compétant, débrouillard et n'hésite pas à poser des questions après avoir un peu cherché par lui-même.

Comme quoi.

En .Net, je te l'aurais fait finger in the noze, et sans aide

Dans une boite, j'ai complétement foiré le test technique. Je faisais du .Net en client lourd principalement et les questions étaient du type :
- Quelles sont les étapes du cycle de vie d'une page ASP (le truc que tu ne peux pas savoir quand tu en as jamais fait)
- En SQL, quelle requête permet de créer une table avec trois champs : une clef numérique auto-incrémentielle, un texte de 30 et une decimale de 2

J'ai totalement foiré le truc, surtout la partie ASP dont je ne connaissais rien. Au moment de parler de SQL, je leur ai expliqué qu'en requêtage courant, je n'avais aucun souci (SELECT/UPDATE/INSERT avec des jointures plus ou moins complexes), mais que pour créer une table, je m'emmerdais pas à écrire une requête, je faisais click-droit->Nouvelle table, etc.
Ça les a fait marré, et ils m'ont gardé (c'est ma boite actuelle où je suis depuis bientôt 3 ans)