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

**TarteAuxFleurs** · 29/12/2016, 23h55

Coin !
En implémentant l'algoritme de Cohen-Surtherland pour "clipper" des lignes dans des fenêtres, je me suis rendu compte que l'implémentation fournie sur wikipédia ne fonctionne pas dans le cas des lignes horizontales (p0.y = p1.y => lors de la division il y a apparition de NaN)... Vous confirmez que je ne me trompe pas ?
Vous en pensez quoi ?

EDIT : J'ai fini par trouvé, bizaremment écrire le truc sur un forum m'a aider à trouver là où je me plante...

**Nattefrost** · 30/12/2016, 00h11

@gbip c'était quoi? Une histoire de float?

**TarteAuxFleurs** · 30/12/2016, 00h21

Envoyé par Nattefrost

@gbip c'était quoi? Une histoire de float?

Même pas, c'est juste que le code ne rentre pas normalement dans cette partie vu que les points sont à droite ou à gauche de la boîte (ou alors le segment n'a aucune intersection avec la boîte) ! Ici en l'occurence, c'est moi qui avais écris n'importe quoi dans les if (je suis pas en C++ et du coup c'est un peu différent...).

- - - Mise à jour - - -

Mais c'est surtout que dans leur implémentation, il manque des trucs dans les if à mes yeux pour que ça soit clair. Par exemple if(outcode0&outcode1) devrait plutôt être if (outcode0&outcode1 != 0b0000) !

**fraeez** · 30/12/2016, 10h59

Envoyé par 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.

Je me permet de rebondir la dessus car c'est un sujet intéressant. Je travaille pour une petite SSII, utilisant principalement les technos Java, JEE et AngularJS. Depuis quelques temps, nous réfléchissons à des questions types à poser en entretien.
Après réflexion, on est arrivé à la conclusion suivante:
- Les clients posent toujours les même questions en entretien, question qui en général ne garantissent pas le bon niveau du candidat. Je trouve en général leur question peu pertinentes, et très ciblés.
- Faire faire des exercices ne donne de résultat concluant, nous préférons tester le raisonnement et la logique plutôt que de faire faire directement de la pratique au candidat.

Du coup, nous avons commencé à rédiger quelques questions types, qui nous paraissent pertinentes mais cela reste toutefois un exercice compliqué.

Notre but est de tester les jeunes candidats en sortie d'école. Ceux que nous souhaitons recruter doivent avoir les compétences (techniques) suivantes:

- Niveau moyen+ en Java (savoir ce que sont des interfaces, des classes abstraites, de l'héritage, quels sont les opérateurs, les types de variables, leurs différences, les mots clés du langages,...)
- Niveau correct en algo (savoir écrire des algo en réponse à un problème. Etre capable de s'interroger sur les performances et les cas bloquant, bref savoir tester son algo)
- Niveau moyen en JS (bon, la je suis pas spécialiste de JS, donc je ne sais pas vraiment quoi tester)

En bonus:
- Niveau moyen en JEE
- Connaissance de framework Front type Angular, React, Polymer
- Connaissance environnement JS (c-a-d tous les outils décrits ici: https://hackernoon.com/how-it-feels-...6-d3a717dd577f )

Je vous posterais la liste de questions que j'ai rédigé ensuite, mais d'abord j'aimerais vous demander: Si vous deviez recruter un débutant avec le profil décrit ci-dessus, quelles questions lui poseriez vous?

**deathdigger** · 31/12/2016, 19h10

Quels sites tu utilises pour trouver de la doc, des solutions.
Ça permet de savoir si le mec sait chercher et au bon endroit, ce qui représente 80% du temps de dev pour un jeune qui commence (statistique HipsOups sortie de mon cul).

**vectra** · 31/12/2016, 19h37

Envoyé par fraeez

https://hackernoon.com/how-it-feels-...6-d3a717dd577f

C'est à la fois technique et humoristique/sarcastique ?

Y'a une valeur informative indéniable pour moi qui n'y connais rien en Java ni en Web, mais c'est quelque peu difficile à suivre.

**Sahnvour** · 31/12/2016, 19h49

C'est surtout sarcastique oui. Et c'est pour Javascript.

**Tomaka17** · 31/12/2016, 23h12

C'est assez sarcastique, mais ce qui fait peur c'est que tout est vrai et qu'il y a beaucoup de gens à SF qui disent la même chose que la personne en italique dans l'article.

Le dernier truc à la mode par exemple c'est le "serverless".
Je vous laisse trente secondes pour réfléchir à ce que pourrait être une technologie qui s'appelle "serverless".
La réponse, c'est que le serverless consiste à envoyer un logiciel à une entreprise, et celle-ci le fait tourner sur un serveur. Ouai. "Serverless".

Ce n'est absolument pas du tout un concept nouveau, ni même particulièrement intéressant d'ailleurs, mais comme tout cet écosystème se nourrit uniquement de hype hé bien maintenant on a du serverless estampillé partout. Serverless par ci, serverless par là. Tout le monde met "5 ans d'expérience en technologies serverless" sur son CV. Si tu leur demandes ce qu'ils pensent de ce que t'as créé ils te répondent "pfft c'est de la merde, c'est même pas serverless".

**Tramb** · 01/01/2017, 11h15

Ce qui est tellement vrai c'est les mecs du web t'expliquent tellement qu'ils ont les meilleurs méthodes mais année après année, les meilleurs d'entre eux reconvergent vers nos décennies de computer science.
Mais que de temps perdu.

Exemple : l'autre jour, un collègue branché là-dedans me parlait de Immutable JS. Je ne savais pas si je devais rire ou être triste.

**Tomaka17** · 01/01/2017, 16h43

Ce qui est ridicule aussi c'est qu'ils ne vont pas utiliser XML parce que, je cite, "c'est trop compliqué".
Par contre faire du Typescript compilé en JS12 transpilé avec Babel et autres machins, ça ne leur pose pas de problème.
Je suis toujours aujourd'hui convaincu que XSLT+XHTML étaient la bonne solution mais étaient trop en avance sur leur temps.

De même pendant des années ils nous ont fait chier à nous dire que les design tableau c'était mal et qu'idéologiquement il fallait séparer le plus possible le HTML du CSS.
Et depuis quelques mois/années, qu'est ce qu'ils font ? Avec ces histoires de React ils mettent les styles directement dans le code HTML.

Tout ça n'a ni queue ni tête.

**Møgluglu** · 01/01/2017, 16h54

En gros ils se sont rendu compte que le code envoyé au client n'a pas besoin d'être lisible par un humain, et pouvait être différent du code écrit par le programmeur. Ils ont inventé le compilateur pour faire le lien entre les deux. Un "transpiler" c'est ce que le reste du monde appelle un compilateur source-to-source ?

**Orhin** · 01/01/2017, 18h07

Envoyé par Tramb

Ce qui est tellement vrai c'est les mecs du web t'expliquent tellement qu'ils ont les meilleurs méthodes mais année après année, les meilleurs d'entre eux reconvergent vers nos décennies de computer science.
Mais que de temps perdu.

Exemple : l'autre jour, un collègue branché là-dedans me parlait de Immutable JS. Je ne savais pas si je devais rire ou être triste.

Ouais, y'a une capacité à réinventer la roue en permanence qui est assez forte.
Après, y'a quand même pas mal d'innovations qui sont assez intéressantes et non présentes (ou alors depuis peu) dans d'autres langages et/ou paradigmes.

Envoyé par Tomaka17

Ce qui est ridicule aussi c'est qu'ils ne vont pas utiliser XML parce que, je cite, "c'est trop compliqué".
Par contre faire du Typescript compilé en JS12 transpilé avec Babel et autres machins, ça ne leur pose pas de problème.

En même temps d'un point de vue dev, tu t'en fous de la complexité du process de build derrière, t'écris juste ton Typescript et ta chaine d'IC s'occupe du reste.

Envoyé par Tomaka17

Et depuis quelques mois/années, qu'est ce qu'ils font ? Avec ces histoires de React ils mettent les styles directement dans le code HTML.

React =/= l'ensemble du dev web hein.
En Angular tu ne fais absolument pas ça.

Envoyé par Møgluglu

En gros ils se sont rendu compte que le code envoyé au client n'a pas besoin d'être lisible par un humain, et pouvait être différent du code écrit par le programmeur. Ils ont inventé le compilateur pour faire le lien entre les deux. Un "transpiler" c'est ce que le reste du monde appelle un compilateur source-to-source ?

Là tu mélanges pas de mal de choses.

1) Le JS ça ne se compile pas, c'est interprété par ton navigateur (enfin techniquement c'est compilé à la volée par le navigateur, m'enfin on va pas rentrer dans les détails)
2) Mais le code source renvoyé par le serveur est illisible depuis un bail, vu que c'est optimisé/minifié/concaténé dans un nombre réduis de fichier (sans parler des templates HTML qui sont mis en inline dans le JS, etc)
3) Le Typescript est un langage compilé vers le JS vu que les navigateurs ne peuvent l'interpréter
4) Le transpilateur "compile" ton JS version n vers une version n-1 (généralement) pour être sur qu'il soit supporté par la majorité des navigateurs

**Tramb** · 01/01/2017, 18h26

Envoyé par Orhin

Ouais, y'a une capacité à réinventer la roue en permanence qui est assez forte.
Après, y'a quand même pas mal d'innovations qui sont assez intéressantes et non présentes (ou alors depuis peu) dans d'autres langages et/ou paradigmes.

Comme quoi ? Ca m'intéresse toujours ce genre de trucs.

**Tomaka17** · 01/01/2017, 18h42

Envoyé par Orhin

React =/= l'ensemble du dev web hein.

Évidemment. Je/On me/se moque en particulier de cet espèce d'écosystème nourri par la hype et qui a tendance à abandonner toute technologies qui a plus de deux ans.

**Møgluglu** · 01/01/2017, 20h55

Envoyé par Orhin

Là tu mélanges pas de mal de choses.

1) Le JS ça ne se compile pas, c'est interprété par ton navigateur (enfin techniquement c'est compilé à la volée par le navigateur, m'enfin on va pas rentrer dans les détails)
2) Mais le code source renvoyé par le serveur est illisible depuis un bail, vu que c'est optimisé/minifié/concaténé dans un nombre réduis de fichier (sans parler des templates HTML qui sont mis en inline dans le JS, etc)
3) Le Typescript est un langage compilé vers le JS vu que les navigateurs ne peuvent l'interpréter
4) Le transpilateur "compile" ton JS version n vers une version n-1 (généralement) pour être sur qu'il soit supporté par la majorité des navigateurs

C'est pas ce que je dis ?

Le Javascript, maintenant c'est le x86 du web, et on a des compilateurs depuis n'importe-quoi (y compris Javascript) vers Javascript. Mais c'est un drôle de langage pour un bytecode.

**Tramb** · 01/01/2017, 21h45

C'est quand même hyper malin et efficace un bytecode en texte. Hum.
(eval '(js))

Bonne analogie avec le x86 : en effet, ça mériterait un ARM du web pour un ISA moins psychotique

**Tomaka17** · 01/01/2017, 21h57

D'ailleurs j'ai été un peu déçu par WebAssembly récemment, car ils ne vont pas rajouter le support pour les APIs du web et le DOM tout de suite.
Autrement dit dans un premier temps wasm sera juste une extension du Javascript, une sorte de possibilité en plus pour quand tu veux quelque chose qui tourne vite, et non pas une alternative.

- - - Mise à jour - - -

Cela dit je ne suis pas contre un futur où les scripts wasm seraient directement servis par le serveur à la place du HTML et où il n'y aurait pas de DOM du tout.

**deathdigger** · 02/01/2017, 17h32

Quelqu'un a déjà bossé avec des pdfs ?
J'ai une merde d'orientation de pdf, et je n'arrive pas à m'en sortir

En gros, j'ai un PDF qui apparait comme en paysage (avec les readers) alors qu'il est en portrait (quand on le lit avec pdfSharp), et derrière ça me fout la grouille. Je ne peux pas bêtement le pivoter, parce que sinon le plan est tronqué (et définir une orientation paysage ne change rien). Si je regarde ce que me dit cpdf, un fichier bon ressemble à ça :

Code:

//La source est un logiciel
Page 1:
Label: 1
MediaBox: 0.000000 0.000000 612.000000 792.000000
CropBox: 0.000000 0.000000 612.000000 792.000000
BleedBox: 
TrimBox: 
ArtBox: 
Rotation: 90

Le mauvais sort ça :

Code:

//La source est un scanner Canon
Page 1:
Label: 
MediaBox: 0.000000 0.000000 792.000000 612.000000
CropBox: 
BleedBox: 
TrimBox: 
ArtBox: 
Rotation: 0

Quelqu'un saurait comment "extraire" le contenu avec pdfSharp et le coller dans une nouvelle page ?

**Mayalabielle** · 08/01/2017, 18h01

Envoyé par PolluXxX

Tiens, je profite de la sortie de Go 1.2 pour savoir si y'a des amateurs du golang dans l'assemblée ?

Z'en pensez quoi ?

J'arrive un peu après la bataille. Pour moi, Golang est un langage orienté "get shits done". J'ai testé pas mal de langages (que je vais essayer d'énumérer dans le bon ordre) :

- C
- Perl
- Python
- Lua
- Rust
- Ruby (négligeable)
- Golang
- Haskell

Aujourd'hui, si on me donne un programme à écrire il y a de fortes chances que je selectionne Golang, les raisons sont, pour moi, les suivantes :

- syntaxe claire et précise, très proche du C
- la concurrence : les goroutines (assimilable à des threads) et les channels (qui permettent de communiquer des informations entres les goroutines)
- go vet (linter officiel pour golang)
- les tests unitaires et go test
- le :=
- les interfaces, c'est le côté "POO" de golang, très minimaliste, ça me convient parfaitement.
- l'utilisation d'un bon vieux makefile, que je connais parfaitement bien, pour builder des projets.
- l'ensemble de packages non "officiels" qu'on peut récupérer facilement avec un go get github.com/projectname/project
- le sentiment que tu peux vraiment "facilement" ranger ton code très proprement, avec un code métier relativement bien isolé.

**Møgluglu** · 08/01/2017, 18h54

Envoyé par Mayalabielle

les goroutines

Ah les gons.

**Patate** · 08/01/2017, 21h08

Tiens du coup tu as choisis quoi comme poste/taf ?

**war-p** · 08/01/2017, 22h36

Envoyé par Mayalabielle

J'arrive un peu après la bataille. Pour moi, Golang est un langage orienté "get shits done". J'ai testé pas mal de langages (que je vais essayer d'énumérer dans le bon ordre) :

- C
- Perl
- Python
- Lua
- Rust
- Ruby (négligeable)
- Golang
- Haskell

Aujourd'hui, si on me donne un programme à écrire il y a de fortes chances que je selectionne Golang, les raisons sont, pour moi, les suivantes :

- syntaxe claire et précise, très proche du C
- la concurrence : les goroutines (assimilable à des threads) et les channels (qui permettent de communiquer des informations entres les goroutines)
- go vet (linter officiel pour golang)
- les tests unitaires et go test
- le :=
- les interfaces, c'est le côté "POO" de golang, très minimaliste, ça me convient parfaitement.
- l'utilisation d'un bon vieux makefile, que je connais parfaitement bien, pour builder des projets.
- l'ensemble de packages non "officiels" qu'on peut récupérer facilement avec un go get github.com/projectname/project
- le sentiment que tu peux vraiment "facilement" ranger ton code très proprement, avec un code métier relativement bien isolé.

Généricité ?

**vectra** · 08/01/2017, 22h46

Edition de softs scientifiques divers pour une boîte à Labège. En qualité de consultant marchand de viande, évidemment...

**rOut** · 08/01/2017, 22h47

@Vectra

GG

**vectra** · 08/01/2017, 22h59

J'étais déçu d'avoir gauffré un entretien pour un poste du même genre chez Thalès Services, mais au final je me suis débrouillé ailleurs.
On verra sur la durée mais c'est plutôt sympa, et sur Toulouse qui plus est.

**William Vaurien** · 10/01/2017, 11h07

Envoyé par Mayalabielle

J'arrive un peu après la bataille. Pour moi, Golang est un langage orienté "get shits done". J'ai testé pas mal de langages (que je vais essayer d'énumérer dans le bon ordre) :
on peut récupérer facilement avec un go get github.com/projectname/project

En fait c'est le langage de l'inspecteur gadget ?

**fraeez** · 10/01/2017, 17h31

Envoyé par fraeez

Si vous deviez recruter un débutant avec le profil décrit ci-dessus, quelles questions lui poseriez vous?

Envoyé par deathdigger

Quels sites tu utilises pour trouver de la doc, des solutions.
Ça permet de savoir si le mec sait chercher et au bon endroit, ce qui représente 80% du temps de dev pour un jeune qui commence (statistique HipsOups sortie de mon cul).

Yep, en effet c'est une bonne question. Plus largement on pourrait demander comment le dev aborde un problème dont il ne connait pas de solutions.

Envoyé par vectra

C'est à la fois technique et humoristique/sarcastique ?

Y'a une valeur informative indéniable pour moi qui n'y connais rien en Java ni en Web, mais c'est quelque peu difficile à suivre.

L'écosystème d'un projet JavaScript aujourd'hui est complètement affolant. Quand j'ai commencé à faire du front, je savais à peine utiliser JavaScript et j'ai du directement comprendre et utiliser les trouzmilles frameworks / pre-compilateur / transpilateur / ordonnanceur et autres joyeusetés... J'étais complètement paumé. Bon, maintenant avec un peu plus de recul j'appréhende mieux tout ça, mais ça reste pas évident en tant que débutant qui n'avait fait que du back Java.

Et du coup, pour les autres dev Front, si vous deviez recruter un dev Front débutant, quelles questions lui poseriez vous?

**Maomam** · 10/01/2017, 17h41

Dites les experts, je commence un nouveau taff en avril et même si ce n'est pas du dév, j'aimerais bien me remettre au point avant d'embaucher.
Vous me conseillez quoi pour reprendre au propre le javascript et le php ? Je me "débrouille" dans ces deux langages mais j'aimerais avoir une base plus solide ?

3 mois c'est court, mais je compte pas m'arrêter là.

Merci !

**vectra** · 10/01/2017, 23h16

OpenClassrooms, c'est pas fantastique, mais tu peux déjà mettre le pied à l'étrier avec ça. Et c'est abordable (ex site du zéro).

**Anonyme32145** · 11/01/2017, 01h08

Pour le JS t'as Freecodecamp.

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

Outils de la discussion

Règles de messages