Les artistes du SdZ

Tous ceux qui sont encore dans le tableau sont qualifiés.

Et sinon, y en déjà eu combien de disqualifiés ??

5 seulement.

Edit : Non rien

Les sujets c'est ce week end??

@ clément_93 : normalement, vendredi ou samedi de la semaine prochaine .

Peut être que tout le monde s'en fout ou n'est pas concerné, mais perso j'aimerais jeter un œil aux solutions
On peut en discuter ici ?
Ou il vaut peut être mieux ouvrir un sujet dans les forums appropriés ?

Aller hop, comme cette partie est finie, je corrige les questions PHP.

La première question, on sait qu'il y a une table php et une colonne mascotte.
On ne sait pas si la colonne mascotte peut être nulle ou pas.
On veut les lignes pour lesquelles la colonne mascotte contient une chaîne, trié dans l'ordre ascendant.

On peut directement jarter la réponse n°2, DSC n'existe pas en SQL, c'est DESC (et même dans ce cas, ça trierait dans l'ordre descendant).
Reste deux réponses possible, analysons les.
Dans la première, on sélectionne toutes les lignes ou mascotte contient une chaîne commençant par W trié dans l'ordre ascendant.
Dans la troisième, on sélectionne toutes les lignes ou mascotte contient une chaîne égale à la chaîne 'W' trié dans l'ordre ascendant.
Dans les deux cas, on récupère bien toutes les lignes ou mascotte contient une chaîne et trié de façon ascendante, les deux réponses sont donc tout à fait valide.
La réponse à fournir était pourtant la première, pourquoi chers organisateurs ?
Si vous vouliez qu'on sélectionne toutes les lignes où la chaîne contenue dans mascotte commençait par une autre chaîne donnée ('W' en l'occurrence), fallait le dire.
Qui plus est, posséder une chaîne dans une colonne, ça veut dire quoi ?
Ceux qui s'y connaissent répondront que ça veut dire que la colonne n'est pas nulle (une chaîne vide, c'est une chaîne quand même !).
La bonne réponse à la question serait donc :
Code : SQL - Afficher / masquer les numéros de ligne
Enfin, pour le coup du LIKE, c'est moche, lent, laid.
Si on considère que la première réponse est la bonne, alors la requête à écrire serait :
Code : SQL - Afficher / masquer les numéros de ligne
(bien plus performant que cet affreux LIKE)

En résumé, cette première question était vraiment très mal posée et plusieurs réponse étaient considérable comme correctes.

Passons à la seconde question. Là, rien de spécial à dire, une seule réponse possible, la troisième est sans conteste la bonne (on se demande un peu ce que vient faire la seconde réponse tant elle est hors sujet mais bon, passons).

Maintenant attaquons la troisième question, celle où on va le plus m'embêter.
La bonne réponse d'après les organisateurs est la première, utiliser la fonction mysql_real_escape_String().
Ah, est-ce que celui qui a posé cette question et dit que cette réponse était la bonne peut me dire ce qu'il se passera si j'envoie une chaîne à PgSQL en utilisant mysql_real_escape_String() pour éviter des injections SQL ?
Eh bien, une injection sera quand même possible. Eh oui, mysql_real_escape_string() échappe les ' en ajoutant un \ devant, or, la norme SQL exige qu'on échappe les ' en les doublant (''). MySQL est gentil et permet d'utiliser des \ pour échapper, mais les autres SGBDR plus respectueux de la norme enverront chier les \'.
Mais maintenant on va me dire "mais on s'en fout ! on utilise MySQL !".
Eh bien non ! La question parle très clairement d'injection SQL, pas d'injection MySQL. Or, pour se prévenir des injections SQL en général, mysql_real_escape_String() est loin d'être efficace, c'est donc la pire des réponses possibles.
Passons maintenant aux deux autres réponses, htmlspecialchars() et htmlentities(). Eh bien, même si ce n'est pas idéal, ces deux fonctions répondent à la question. En effet, si on file la constante ENT_QUOTES en second paramètre, les ' seront convertis en leur équivalent html, ce qui évitera toute injection SQL.
Bien sûr ce n'est pas très élégant, mais ça fonctionnera.
Qui plus est, la question n'est pas assez précise. si on voulait un nombre entier, il suffira d'utiliser intval() ou un cast pour éviter tout risque d'injection. La défense face aux injections SQL dépend donc du type de données qu'on doit utiliser, et comme ce n'est pas précisé, ça laisse un doute de plus ..

En résumé, la réponse considérée comme bonne par les organisateurs est la plus mauvaise des trois, et les deux autres sont correctes.

Voilà pour le PHP

Je plussois `Haku. J'espère que les sujets seront sans failles.

Clair, les questions étaient extrêmenent imprécises
La deuxième aussi, d'ailleurs, c'est très vague (j'ai répondu la jointure, honte à moi :D)

`Haku, tu es l'homme à abattre, le seul qui me fait peur

Bah c'était la jointure.
Sinon pour les questions tous ceux qui ont pas envoyé sont éliminés et les sujets vous les aurez vendredi ou ce week-end.

Juste un truc : ça serait bien si tu éditais le premier post pour supprimer les pré-sélections, parce là, ça fait un peu long

J'allais le faire.

Ah, ben je me suis planté sur la première, enfin je suis passé quand même
Mais je trouve dommage que le jury soit si strict (sur des questions mal posées)

En même temps, c'est un QCM, avec 3 questions, alors, forcément, si on se met a accepter 2 erreurs, ça sert plus à rien

C'est édité.
Pour les questions il y avait du hors-sujet quelques fois mais c'était voulu.
Vous aviez trois choix, il fallait prendre celui qui était le plus correct et qui s'adaptait à la situation et au contexte.
Donc pour les programmeurs plus expérimentés ça peut leur paraître idiote les questions (on vous avait prévenu que c'était facile).

Pour les sujets ce sera autre chose.
Ce sera par ordre de difficulté : le 1er sujet sera moins compliqué que le deuxième et le deuxième moins que la finale.

C'était clairement marqué que c'était un test pour dégager les noobs
J'ai été un maximum objectif en décrivant ce que faisait chaque requête (étant donné que la question était mal posée, autant expliquer toutes les réponses), mais j'ai quand même fait un choix (si j'en avais pas fait je suis sûr que ça aurait compté comme faux)

Je m'attendait à mieux
Surtout que des trucs pour éliminer les noobs, vous pouviez trouver facilement des questions, genre sur les filtres de flux ...
http://fr.php.net/manual/fr/wrappers.php.php

Citation : Craw
Les questions ne m'ont pas parues idiotes, ce sont les réponses soi-disant correctes qui m'ont parues idiotes.
La situation et le contexte sont définis pas les questions, si les questions ne sont pas clairs (et elles étaient loin de l'être), la situation et le contexte ne le sont pas non plus.
Comment peut-on répondre en se basant sur une situation et un contexte flou au possible ?

Et on aura 15 jours, un mois par sujet??

Non le temps dépendra de la complexité des sujets...

Au minimum 15 jours.

Ce sera quels types de sujets ?

Pour le PHP, ce sera plusieurs scripts qui feront un mini système, je n'en dirai pas plus .

Par contre ce serait peut être mieu de donner les sujets dans la semaine plutot que ce week end pour les personnes qui comme moi partiraient en vacances le samedi matin...

C'est pas que l'on ne veuille pas les donner avant, c'est que l'on ne peut pas (on a pleins de trucs à faire avant la sortie des sujets, question d'organisation)

Oui, on donnera les sujets dès que possible, ce n'est plus à débattre.

Et question mapping, sa sera quelle genre de sujet .

Pour tout vous dire, les sujets de C et de Mapping ne sont même pas encore fixés, même nous on ne peut pas vous répondre.

Ok, alors on va s'armer de patience !

c quand qu'on recois les consignes? en MP?

Non tout sera sur le premier post du topic, comme pour les questions.

Copieur de citation.