Journal Offre d'emploi Développeur Web (Paris)

Posté par (page perso) .
Tags : aucun
0
11
oct.
2006
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
  • # Curiosité...

    Posté par . Évalué à  4 .

    Ca fait un moment qu'elle est là cette offre. Vous avez tant de mal que ça à recruter ? Les candidatures passées dont tu parlais dans un précédent journal n'ont pas donné satisfaction ?

    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 (page perso) . Évalué à  6 .

      Tout d'abord, ca ne fait que peu de temps qu'on recrute vraiment sérieusement même si l'annonce date. Et on recherche vraiment beaucoup de monde :-)

      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 (page perso) . Évalué à  2 .

        > 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...

        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 . Évalué à  1 .

        Dommage que ce soit dans une ville aussi pourris que paris ;)
      • [^] # Re: Curiosité...

        Posté par (page perso) . Évalué à  4 .

        Tout d'abord, ca ne fait que peu de temps qu'on recrute vraiment sérieusement même si l'annonce date. Et on recherche vraiment beaucoup de monde :-)


        J'avais déjà postulé au même genre d'offre il y a un an!

        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.


        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.

        Ce n'est pas un stage miteux, c'est relativement bien payé,...


        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 . Évalué à  1 .

          Ce n'est certes pas un stage miteux mais vous ne trouverez pas d'expert php à ce prix là.
          Damned, faut que je change de job !
          • [^] # Re: Curiosité...

            Posté par (page perso) . Évalué à  3 .

            Damned, faut que je change de job !


            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 . Évalué à  2 .

              Je ne comprends pas bien ta remarque. C'est ironique ?
              Que nenni, c'est très sérieux. Outre la compétence PHP que j'exerce, mon salaire est nettement en dessous du marché dans ce cas. :-(

              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.
              Je suis en bas, alors... il n'y a plus photo.

              Certes il n'y a pas que le salaire qui compte mais pour acheter le beurre pour les épinards ça aide pas mal!
              Précisément, quand en plus il y a plusieurs assiettes.
          • [^] # Re: Curiosité...

            Posté par (page perso) . Évalué à  2 .

            ben poste, ils sont top cool..
        • [^] # Re: Curiosité...

          Posté par (page perso) . Évalué à  2 .


          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.


          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...


          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à.


          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 (page perso) . Évalué à  1 .

        Ben, moi si lors de l'entretien on m'avais parlé de mysql_real_escape_string(), pour "protéger" les requêtes mysql, j'aurais pas aimé, parce que je ne suis pas persuadé que cela serve à grand chose SI
        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 . Évalué à  4 .

          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.)
          Qu'il est pourtant recommandé de laisser à Off (recommandation du même ordre que celle relative au register_globals : pousser le dév à savoir un peu plus ce qu'il fait, et configurer son soft en fonction, sans toucher à la config globale du serveur).

          2 - tu encadres tes variables par des ' dans ton sql par ex ' .......AND mavar=\''.$mavariable.'\'.................');
          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).

          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.
          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.

          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,
          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 . Évalué à  2 .

            Je suis réticent à l'objet dans le web, et çà ne m'empêche pas de faire du code modulaire, réutilisable et accessoirement lisible. Bon ok c'est en C (des CGI), mais en PHP çà change pas tellement (sur le principe, évidemment).
        • [^] # Re: Curiosité...

          Posté par (page perso) . Évalué à  5 .

          parce que je ne suis pas persuadé que cela serve à grand chose


          ah... alors un conseil... change de métier... En tout cas, ne postule pas, ça servira à rien :-)

          - 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.)


          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.


          tu encadres tes variables par des ' dans ton sql par ex ' .......AND mavar=\''.$mavariable.'\'.................');


          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 (page perso) . Évalué à  2 .

            >Euh, tu es sûr de savoir ce que c'est que le sql injection ?
            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 (page perso) . Évalué à  2 .

              Je n'ai pas le temps de m'amuser a répondre a tout ton post, mais:
              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 (page perso) . Évalué à  2 .

              Je trouvais ton premier message sur la gestion des slashs (addslashes, mysql_real_escape_string, ...) pour le moins étrange. Maintenant je comprends mieux et je suis d'accord avec toi. Mais tes arguments ne sont valables que pour une application dont on maitrise l'environnement (serveur, navigateur, ...).

              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:

              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..)


              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 (page perso) . Évalué à  2 .

              non, on ne developpe pas une appli pour une config donnée, dans un environnement donné, rêgle général.

              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 . Évalué à  3 .

                Une autre stratégie de développement de logiciel est au contraire d'en faire le minimum : http://c2.com/cgi/wiki?DoTheSimplestThingThatCouldPossiblyWo(...)
                • [^] # Re: Curiosité...

                  Posté par . Évalué à  2 .

                  Ca n'a rien d'incompatible : prévoir une architecture simple et évolutive d'une appli ne signifie pas faire une usine à gaz avec plein de features inutiles.

                  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 . Évalué à  4 .

              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.
              Le php n'a pas plus, ni moins été prévu pour ça que Java ou ruby. Ce sont des frameworks (maison, ou généralistes) qui construisent sur le langage. Et un découpage simple MVC mais utile en PHP, ça se fait facilement. Evidemment, il ne faut pas attendre du PHP ce qu'on fait avec du Java...

              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.
              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.).

              - une applis ne doit pas migrer vers un serveur configuré différemment (on n'est pas au pays de la bidouille)
              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.

              - une applis ne change pas de base de donnée pour le fun.
              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.

              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.
              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 (page perso) . Évalué à  2 .

                Je crois que tu as expliqué la problèmatique bien mieux que moi :-)

                D'ailleurs c'est valable pas qu'en PHP, mais aussi dans tous les autres langages.
              • [^] # Re: Curiosité...

                Posté par (page perso) . Évalué à  3 .

                >Il faut bien voir qu'une application, ce n'est pas seulement des lignes
                >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 . Évalué à  2 .

                  Si tu veux pouvoir changer de Bdd, il vaut mieux un addshlashes qu'un mysql_escape_sting
                  Suis plus partisan d'un vrai modèle d'abstraction de la couche db. Mais après, on rentre dans des querelles de chapelle. :-)

                  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.
                  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.

                  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.
                  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.

                  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.
                  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 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. :-)
                  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 (page perso) . Évalué à  -1 .

    Alors, si tu fais partie de l'équipe de dév des skyblogs, j'étouffe ma haine et force mon commentaire vers un certain constructivisme pour te proproser quelques pistes de dév :
    - 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 (page perso) . Évalué à  3 .

    Je suis dev web depuis 2 ans et je connais parfaitement tout ce qui est requis par l'annonce (sauf SVN, je n'ai utilisé que CVS).
    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 (page perso) . Évalué à  3 .

      Mon probleme c'est qu'on recherche plusieurs développeurs, pas forcement experts, mais surtout on a pas le temps de les former. On a déjà fait ca, il est évident que personne n'est entré chez nous avec tout ce qu'il sait maintenant, mais bon la on a pas les ressources pour faire ca actuellement.

      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 . Évalué à  2 .

        Je suis rentré comme dev mysql-php à 35000, 5 ans après je suis à 43000 ; A l'époque j'étais chomeur et loin d'être un expert.
        • [^] # Re: Salaire

          Posté par (page perso) . Évalué à  4 .

          Punaise ! On peut gagner autant dans le dev php/mysql ! J'aurais jamais cru >_<....
          • [^] # Re: Salaire

            Posté par . Évalué à  2 .

            En dessous d'une certaine rémunération c'est peu serré pour un developpeurs php/mysql qui vit en region parisienne et qui a des projets tu ne trouves pas ?
          • [^] # Re: Salaire

            Posté par (page perso) . Évalué à  0 .

            locke ne l'a pas précisé mais ce genre de salaire s'obtient la plupart du temps en dehors d'une société de services.
          • [^] # Re: Salaire

            Posté par (page perso) . Évalué à  3 .

            Ben php/mysql ca veut pas forcement dire faire des truc du genre site perso basiques, meme si beaucoup de gens l'utilisent pour ca.

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.