Bon, puisque d'autres le font, puisque on a encore besoin de monde ici, et que personne n'avait ralé au dernier journal sur le sujet, voila, on recrute.
Il nous faut des développeurs web, des gens qui savent faire du code correct et sécurisé, qui ont un minimum d'expérience, toussa. Technologies: PHP (4,5), MySQL, XHTML/CSS et plus si affinités. Il nous faut plus d'une personne, donc n'hésitez pas à parler de ca autour de vous même si vous postulez :-)
Ce n'est pas un stage miteux, c'est relativement bien payé, ya moyen d'apprendre beaucoup de choses qu'on voit pas ailleurs, l'ambiance est plutôt geek, on écoute pas forcément la musique diffusée à l'étage du dessous et on est a coté d'un super marchand de glaces, parfait pour l'hiver qui s'annonce donc.
L'url de l'offre (mais vous pouvez ignorer tout le texte sauf l'email si vous avez lu on journal jusqu'ici) : http://fr.lolix.org/search/offre/offre.php3?id=6101
Journal Offre d'emploi Développeur Web (Paris)
11
oct.
2006
# Curiosité...
Posté par Cali_Mero . Évalué à 4.
PS : Je pense que ta tentative de faire connaître cette offre ici et de démolir les idées reçues qu'on pourrait se faire à la lecture de l'annonce est une excellente idée. Je vous souhaite que ça marche.
[^] # Re: Curiosité...
Posté par Mathieu Pillard (site web personnel) . Évalué à 6.
Cela étant dit, il ya plusieurs problèmes:
1. L'image qu'on véhicule, comme tu le soulignes. Je trouve ca completement idiot de s'arreter à ca, le boulot est un défi permanent, c'est rare de pouvoir travailler sur un truc aussi gros/chargé/etc.
2. Je sais pas si ca vient du premier point, mais je trouve qu'on a vraiment peu de candidatures. On a aussi pas eu trop de bol puisque on a eu quelques désistements pour diverses raisons.
3. Dans les candidatures qu'on a eu, yen a quand même qu'on a vraiment pas aimé :-) Quelqu'un qui arrive pour du développement web php/sql et qui ne connait ni mysql_real_escape_string() ni htmlspecialchars(), ca me fait un peu mal, perso...
Enfin, merci pour ton commentaire, je nous souhaite aussi que ca marche parceque sinon je sais plus quoi faire moi :-)
[^] # Re: Curiosité...
Posté par Prae . Évalué à 2.
De ma (toute petite) expérience, j'ai recherché quelques devs pour une partie d'un projet en PHP ces derniers temps.
J'ai finalement abandonné les CV "Développeur PHP": je suis moi-meme dev PHP, mais tous les candidats que j'ai pu rencontrer m'ont fait peur (le must, c'est celui qui savait pas ce que faisait "i++" ...)
Mon conseil Matthieu: Cherche un (ancien) développeur C/C++ qui souhaite faire un peu autre chose durant quelques temps.
Depuis, j'ai pas été décu.
[^] # Re: Curiosité...
Posté par Dinofly (site web personnel) . Évalué à 3.
Parse error: syntax error, unexpected T_INC
$i++ ça marche par contre ;-)
[^] # Re: Curiosité...
Posté par Prae . Évalué à 3.
[^] # Re: Curiosité...
Posté par Nahuel . Évalué à 1.
[^] # Re: Curiosité...
Posté par Nicolas (site web personnel) . Évalué à 4.
J'avais déjà postulé au même genre d'offre il y a un an!
J'avais été surpris par le robot qui m'a répondu lorsque j'ai envoyé mon cv: il m'a tutoyé. Je n'ai pas dit que j'ai été choqué. J'ai passé des dizaines d'entretiens l'année dernière et nombreux sont ceux où le recruteur et moi, nous nous tutoyés; ce que j'ai trouvé plutôt sympa.
Personnellement je n'aurai pas mis de fourchette de salaire. Ce n'est certes pas un stage miteux mais vous ne trouverez pas d'expert php à ce prix là.
[^] # Re: Curiosité...
Posté par romain . Évalué à 1.
[^] # Re: Curiosité...
Posté par Nicolas (site web personnel) . Évalué à 3.
Je ne comprends pas bien ta remarque. C'est ironique ?
La fourchette haute de son offre pourrait à la limite être la fourchette basse d'un expert. Si tu te considères comme expert et que tu es dans cette fourchette, essaie de sonder le marché. Tu te rendras compte que j'ai raison.
Evidemment si la personne qui cherche un emploi est au chomage depuis longtemps ça change la donne. Mais il ne faut pas s'étonner ensuite de la voir partir vers une offre plus alléchante.
Certes il n'y a pas que le salaire qui compte mais pour acheter le beurre pour les épinards ça aide pas mal!
En revanche si derrière l'offre il y a des perspectives d'évolution sérieuses cela peut être intéressant. Je pense par exemple à un poste qui évoluerait avec le temps vers un statut de chef de projet par exemple.
[^] # Re: Curiosité...
Posté par romain . Évalué à 2.
Je suis en bas, alors... il n'y a plus photo.
Précisément, quand en plus il y a plusieurs assiettes.
[^] # Re: Curiosité...
Posté par hervé Couvelard . Évalué à 2.
[^] # Re: Curiosité...
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
D'autres ont été choqué :-)
L'adresse est utilisée aussi pour la radio et compagnie, d'ou le tutoyage. Je crois qu'on l'a viré l'autre jour...
Je ne suis pas responsable de l'offre. Toutefois, ce n'est pas non plus un expert qu'on recherche, juste des développeurs corrects.
[^] # Re: Curiosité...
Posté par hervé Couvelard . Évalué à 1.
1 - tu as un addslashes (ou un magic_quotes_runtime = on dans php.ini) ou un (php_flag magic_quotes_runtime 1 dans le virtualhost apache.)
2 tu encadres tes variables par des ' dans ton sql par ex ' .......AND mavar=\''.$mavariable.'\'.................');
Autre chose, la sécurité dans une application ce n'est pas "juste" quelques recettes de grand mères avec des incantations vaudou à la mode comme mysql_real_escape_string qui DOIT? être utilisée, mais part d'une réfléxion beaucoup plus profonde sur le fonctionnement de l'application et de ses interactions. Le plus Fun (désolé pour le jeu de mots) à propos de cette instruction, c'est la proposition dans le doc de faire un stripslashes avant. Par exemple, il peut y avoir effectivement un htmlspecialchars ou un striptags si c'est pour un forum (pour éviter le javascript voleur de cokkies par exemple).
Sinon pour l'image, je ne serais pas offusqué par les sky-chose, si le projet est interessant.
Pourquoi vous ne proposez pas du télétravail avec une réunion de temps en temps ?
Voila mes réflexions à 2 balles ah si, une dernière, faire de l'objet sur le web est de l'hérésie : il n'y a pas de persistance dans un mode client/serveur deconnecté comme php, tous les objets sont détruits à chaque fin de script et recréés à chaque début.
Le mode objet dans php5 est une décision politique ( destiné à attirer les dev java (et ca marche) et les dev C++) qui ne semble pas partagée par tous dans le haut staff PHP, de là a recruter des C++ qui s'ennuient, je crois que l'on peut perdre un peu des avantages de php, langage non typé, embarqué et non objet.
[^] # Re: Curiosité...
Posté par romain . Évalué à 4.
En l'occurence, un candidat qui me pondrait un code comme :
$q = sprintf( 'INSERT INTO table VALUES( %d, %s )', intval($key), mysql_escape_real_string($valeur) );
me mettrait déjà beaucoup plus à l'aise (c'est clair et lisible tout de suite).
Faire de l'objet n'a pas pour seul but/avantage la persistance des données ; il y a aussi l'architecture de l'application, qui peut être plus lisible lorsque les modules sont encapsulés dans des classes.
Mouais. De mon expérience d'éboueur/accompagnateur d'applications PHP (6 ans), je dois dire que les dévs PHP réticents à l'objet sont ceux qui ont pondu le code le plus crade et le moins organisé/modulaire que j'ai pu voir (je n'aborderais même pas le retard avec lequel la notion de découpage MVC fait son trou chez les devs PHP).
[^] # Re: Curiosité...
Posté par Gabriel Linder . Évalué à 2.
[^] # Re: Curiosité...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 5.
ah... alors un conseil... change de métier... En tout cas, ne postule pas, ça servira à rien :-)
Sauf que les magic_quotes, c'est le mal absolu.
1) C'est déjà vraiment emmerdant si les données que tu reçoit sont déstinées à autre chose que d'être incluse en base de donnée. Faut que tu "désescape". Super les perfs ! (et dieu sait si sur les applis du site en question, les perfs sont indispensables).
2) Si tu as le malheur de migrer ton appli sur un autre serveur qui n'a pas les magic_quotes, pouf, ton appli n'est plus sécure.
3) Si tu utilises d'autres bases, l'échappement n'est pas forcément le même.
4) Bien évidement, une appli bien foutue, professionnelle est découpée en couche. en particulier, ton code métier est dans des fonctions ou classes metiers, qui devraient ignorer la provenance des données et donc les données que tu leur passes ne doivent pas être déjà échappées. (les données peuvent venir des requêtes http, mais pourrait venir d'un script d'import, d'un service web etc...). Donc du coup, les magic_quotes ne permettent pas de faire un code propre.
Euh, tu es sûr de savoir ce que c'est que le sql injection ?
Bref, pour une appli pro un minimum robuste :
1) on désactive les magic-quotes, ou au pire, on test si les magic_quotes sont activées et dans de cas on réalise l'opération inverse.
2) dans les classes métiers (qui sont censées récupérer des données non échappées), on utilise la fonction d'échappement dédiée à la base utilisée. (ce sera pg_escape_string pour postgresql par exemple, ou mysql_escape_string pour mysql etc..)
[^] # Re: Curiosité...
Posté par hervé Couvelard . Évalué à 2.
oui. je sais.
J'ai du mal à comprendre ta démarche intellectuelle, pour moi, une application est detterminée pour un serveur, une configuration, une base de donnée, dans un environnement particulier, surtout si
>(et dieu sait si sur les applis du site en question, les perfs sont
>indispensables).
Plus tu factorises, modularises, mets en classe métier, plus ta performance diminue. Si je voulais faire du MVC, je ne ferais pas de php, il n'a pas été prévu pour ca.
Effectivement, il peut paraître mode et hype de faire des applications multi-plate-forme, multi-base, multi-serveur qui marchent quelque soient les serveurs utilisés, mais ce n'est pas ma tasse de thé. Ma vision est une applis, pour une tache, dans un environnement particulier.
Je ne comprends pas du tout :
>Sauf que les magic_quotes, c'est le mal absolu.
>les magic_quotes ne permettent pas de faire un code propre.
- une applis ne doit pas migrer vers un serveur configuré différemment (on n'est pas au pays de la bidouille)
- une applis ne change pas de base de donnée pour le fun.
Effectivement, si le code-guideline de la maison c'est : multi plateforme, multi base de donnée, multi serveur (pourquoi pas multi-serveur configurations différentes?), configuration la plus large possible,cela change la manière dont est codée l'applis en question.
Quand à ton :
>ah... alors un conseil... change de métier... En tout cas, ne postule
>pas, ça servira à rien :-)
Je suis de bonne humeur et je le prends bien, mais rien que cette remarque me donne pas envie de travailler dans cet environnement, mais cela ne devrait pas m'étonner ce doit être la marque de fabrique de la maison cette certaine arrogance, ou alors la vision parisienne des relations dans le monde du travail :-)
[^] # Re: Curiosité...
Posté par Mathieu Pillard (site web personnel) . Évalué à 2.
1/ addslashes() ne suffit pas toujours. Lis http://shiflett.org/archive/184 par exemple.
2/ tu n'auras pas tout le temps le loisir de travailler sur un serveur que tu controles avec magic_quotes a on
3/ si à l'entretien tu es capable de donner l'argumentation que tu viens de donner, meme si en l'occurence je ne suis pas du tout d'accord, ca sera deja pas mal. Ce n'etait pas le cas des candidats dont je parle....
[^] # Re: Curiosité...
Posté par Nicolas (site web personnel) . Évalué à 2.
Il ne viendrait à l'idée de personne de déployer un binaire sur une machine sans vérifier que les dépendances vis-à-vis des librairies utilisées sont garanties. Pourquoi serait-ce différent pour une application développée avec php ?
Si on essaie de déployer l'application, en revanche on se retrouve confronté à des problématiques toutes autres. Il faut ajouter toute une "couche" pour se rendre plus ou moins indépendant de la configuration du serveur. Dès que l'on fait une application qui est destinée à être déployée, un minimum d'organisation est essentielle. Une approche possible (pas la seule) est de se tourner vers une programmation orientée objet (mvc ?). Quoi qu'il en soit une programmation modulaire s'impose.
Je partage ton avis sur la virulence des propos de Laurent:
C'est une solution possible et uniquement si l'application est destinée à être déployé et que l'on ne maitrise pas la configuration du serveur.
[^] # Re: Curiosité...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Car l'appli evolue. Les besoins évoluent. Aujourd'hui c'est du mysql parce que tu sais que tu aura peu d'utilisateur ou peu d'éxigences. Mais plus tard ? Qui sait si ton site ou ton appli ne connaitra pas un boom ? un succés ? Des demandes d'évolutions importantes ? Et donc changer de base, de config php et autre ? Peut être voudras tu la plugger plus tard sur des services web ou autres ? Donc réutiliser tes objets métiers, ou d'autres parties de l'appli pour d'autres besoins ?
Les objets, la modularité, c'est pas pour se la jouer. C'est pour anticiper sur les évolutions. Èviter de tous réécrire à chaque évolution. Découper pour réaliser plus facilement des tests unitaires (trés important dés qu'une appli devient complexe, pour vérifier qu'il n'y a pas de régressions). Découper pour ne pas avoir à tout modifier. Utiliser des templates par exemple (qu'elles soient en php ou non), c'est un premier découpage. Séparer le code métier du code coordination( en utilisant mvc par ex) en est un autre.
Une appli, surtout complexe, c'est pas du jetable. Faut essayer d'anticiper les évolutions, éviter d'avoir à tout réécrire, parce que ça coute cher. Le seul truc qui fonctionne sur le moyen et long terme, c'est de programmer un minimum modulaire (sans tomber dans l'ultra modulaire, il faut modulariser en fonction de la complexité de l'appli, et de son temps de vie).
je dis pas ça par ce que ça fait "in", mais bien parce que c'est ce que j'ai effectivement remarqué dans tous les developpements professionels que j'ai effectué depuis plusieurs années. Y a qu'à voir le succés et le nombre de nouveau framework ces derniers mois.
PS: je ne travaille pas dans la boite de mat...
[^] # Re: Curiosité...
Posté par maximegb . Évalué à 3.
[^] # Re: Curiosité...
Posté par romain . Évalué à 2.
Et en faire le minimum, oui. Si cela fait ce qu'il faut.
Ce qu'il faut, c'est d'abord une application qui remplit sa fonction. Et souvent, qui puisse vivre, évoluer assez longtemps d'autre part (histoire de ne pas avoir dépenser de l'énergie au départ pour devoir tout recommencer qqs mois après).
Cette dernière condition, si elle est présente, ne s'improvise pas si on veut assurer la qualité du produit à long terme : il faut bien baliser (architecture claire et évolutive, documentation claire et complète) le terrain. Ca se reflète également dans la manière de pondre le code.
Après, c'est une question de contraintes et d'arbitrage.
[^] # Re: Curiosité...
Posté par romain . Évalué à 4.
Ce n'est pas une question de tasse de thé ou de hype.
C'est une question de gestion du cycle de vie total du logiciel. Si ton travail est destiné à être déployé sur un seul serveur, à un seul moment donné, tant mieux, c'est très bien aussi.
Mais certaine application doit avoir un cycle de vie long, où la plateforme sur laquelle elle repose changera régulièrement ; où elle sera déployée par des gens différents, aux compétences différentes, sur des architectures différentes. Si on voit à court terme, et qu'on peut se permettre de tout recoder, ou de patcher à tout va une appli au gré des changements de plateforme, très bien. Si on veut voir à plus long terme et sécuriser le plus possible les patches et les migrations, on prévoit un peu plus l'architecture de l'appli en fonction de ça.
La perte de performance, si elle reste minime par rapport à l'objet de l'application, peut être très bien balancée par le gain en organisation et en abstraction de l'appli. Ce n'est pas pour rien que l'on a plusieurs grosses applis web qui reposent sur différentes bases de données (MySQL, PostgreSQL, Sqlite, BDB, etc.).
La bienvenue dans le monde réel ; le problème n'est pas qu'il ne faut pas faire ça, c'est évident ; le problème, c'est qu'on tombe inévitablement sur cas où ça a été fait ; et où le job est de gérer ce binz. Donc si on peut être proactif... (pour ceux qui suivront inévitablement) ça peut pas être plus mal. Théorie contre pratique.
Il ne s'agit pas de le faire pour le fun, il s'agit de faciliter, de façon stable et certaine, le déploiement sur plusieurs types de plateforme.
C'est bien de ce dont on parle.
Il faut bien voir qu'une application, ce n'est pas seulement des lignes de codes organisées, écrite une seule fois par un seul développeur. Il y a un cycle de vie qui peut être prévu long ou court, il y a des évolutions inévitables si celui-ci est long, et prévoir l'architecture et le développement de l'appli autour de cette idée peut, à terme, apporter de sérieux gains.
[^] # Re: Curiosité...
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
D'ailleurs c'est valable pas qu'en PHP, mais aussi dans tous les autres langages.
[^] # Re: Curiosité...
Posté par hervé Couvelard . Évalué à 3.
>de codes organisées,
Euh... faut pas rigoler qd même, parler de changer de base de donnée, de serveur, d'environnement et cloquer un mysql_escape_string() qui est cloqué à mysql, comment dire...
Si tu veux pouvoir changer de Bdd, il vaut mieux un addshlashes qu'un mysql_escape_sting
Sinon, oui je comprends la problématique recherchée dans ce cas particulier et je ne dis pas que l'une ou l'autre est mieux.
La conception et le pilotage d'un developpement est toujours un compromis entre le modulaire/abstraction/configurabilité/temps de dev/suivi dans le temps/performances brutes.
C'est comme le choix du centre de gravité d'un polygone de sustentation dont on définirait le poid de chaque sommet : c'est mouvant et il n'y a pas de vérité pure, mais que des choix politiques.
Si j'avais codé plus lache et plus portable, certaines de mes applis ne pourraient pas tourner dans des mutualisés privatifs car la charge serveur induite nous placerait "hors norme" (il n'est pas possible de faire du cache car les requettes sont toutes uniques à cause d'une géolocalisation).
Effectivement si demain un autre devrait reprendre certaines applications, il devrait passer un peu de temps à comprendre certains algo et la logique de la chose.
Exploser en plein d'objets différents avec des méthodes privées et publiques, des couches différentes ne donne pas forcement plus de facilité à prendre en main la chose.
Ex : le Gconf de gnome qui reprend dans un seul arbre plein de configurations différentes alors que cela peut_être/est modularisé dans des fichiers de conf distincts. Est-ce que cela fait de gconf un truc moins simple ?
J'ai commencé à coder du php en 1997-1998, et j'ai vu pas mal de chose passer, j'ai également vu pas mal de code, et pas des moindes, le code le plus difficile à percer est souvent le code le plus long, avec des appels dans des appels dans des appels.
Je suis d'accord avec toi, il y a plein de code goret, mais cela ne veut pas dire que ceux qui ne code pas comme toi sont des gorets. :-)
[^] # Re: Curiosité...
Posté par romain . Évalué à 2.
Bah... s'il y a une doc qui explique le tout, c'est déjà ça. Il y a bien évidemment des sections/applications critiques où l'on ne peut faire que du spécifique, mais ce n'est effectivement pas les mêmes contraintes.
On ne se comprends qu'à demi-mot : faire de l'objet, ce n'est pas appliquer toutes les possibilités présentées dans un bouquin sur les technologies objets, ni découper une appli en couches non cohérentes, tordues ou non optimisées pour la performance du code.
Quand ce ne sont pas des includes qui se marchent sur les pieds et remplacent la logique d'appel de fonction (avec toute la gestion impliquée des variables globales qui deviennent dès lors des paramètres potentiels).
Je n'ai jamais dit ça. Chacun son style de code, et tout projet doit avoir le sien.
Il n'empêche qu'un code mal écrit (style, nommage, construction, algorithme, factorisation, tout ça) est très souvent révélateur d'un travail bâclé, mal conçu, tordu. Et la plupart du temps également, le code est buggé, peu fonctionnel ou extensible, voir troué (je n'ai que très rarement vu un code php pratiquement illisible mais révélant un truc bien réfléchi).
Ce qui ne veut pas dire qu'un codeur de type artisan puisse livrer un code très efficace, fonctionnel et illisible. Mais son illisibilité est son pire défaut pour son cycle de vie : on préférera jeter et tout réécrire histoire d'arriver à comprendre si cela fait bien ce que c'est censé faire - ni plus, ni moins (à moins de disposer d'ici là d'un outil de preuve).
# Proposition de fonctionnalités
Posté par jerome (site web personnel) . Évalué à -1.
- correcteur orthoghaphique OBLIGATOIRE, qui fait tout seul les substitutions à la validation des postes ;
- une fonctionnalité pour rageux, histoire de pouvoir poignarder les gens dans la figure over IP ;
- peut être prendre des devs un peu nuls pour laisser des trous de sécurité, assurer un downtime bénéfique pour tout le monde ;
- coder sur autre chose pendant ton temps de travail, ça serait citoyen.
"Lashé vo coms" *GNII*
# Salaire
Posté par Dinofly (site web personnel) . Évalué à 3.
Lorsque j'ai été embauché il y a 2 ans je connaissais beaucoup moins de choses qu'aujourd'hui, mais même en tant que débutant j'ai tout de suite touché un salaire correspondant au haut de la fourchette de l'annonce. Je pense qu'à ce prix tu devras embaucher quelqu'un qui se formera au fur et à mesure, un expert demandera plus.
[^] # Re: Salaire
Posté par Mathieu Pillard (site web personnel) . Évalué à 3.
Note, si tu débutant tu touchais 35k euros, je suis très content pour toi, mais euh, je suis le seul à penser que tu as eu du bol?
Enfin comme dit plus haut, je ne controle pas le texte de l'annonce, et il est fort possible que quelqu'un qui demande un tout autre salaire l'obtienne sans problemes; je pense que je vais demander a ce qu'on vire la fourchette de l'annonce, mais bon...
[^] # Re: Salaire
Posté par locke . Évalué à 2.
[^] # Re: Salaire
Posté par Snarky . Évalué à 4.
[^] # Re: Salaire
Posté par locke . Évalué à 2.
[^] # Re: Salaire
Posté par Nicolas (site web personnel) . Évalué à 0.
[^] # Re: Salaire
Posté par Anonyme . Évalué à 3.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.