Offre job dans les technologies Mozilla
Par Laurentj le mercredi, mai 10 2006, 13:43 - Geek-log - Lien permanent
Chez DI, nous recherchons un développeur maîtrisant les technologies Mozilla (XUL, XBL, Javascript, XPCom en C++...). Il participera à la réalisation d'applications sympas, innovantes, ce qui pourrait d'ailleurs l'amener à contribuer au projet Mozilla, offrant donc de belles perspectives. Il rejoindrait une petite équipe de deux personnes, passionnées, expertes, dans une ambiance cool, décontractée et sans prise de tête.
Pour avoir plus de détails, lire l'annonce sur le blog de Daniel.
Commentaires
Impresionnant le lien !
Dans l'annonce : "Vous êtes prêt(e) à rire de tout et n'importe quoi"
Et juste en dessous, le commentaire : "deux petits <CENSURE> qui trouvent amusant de faire de l'humour franchement déplacé sur une offre d'emploi. Désolé, cela ne me fait pas rire DU TOUT !"
être prêt à rire de tout et de n'importe quoi, n'implique pas d'être prêt à rire de remarques d'une bêtise profonde, ou à faire de l'humour con (si on peut appeler ça de l'humour).
Y a l'humour drôle, et l'humour con. En l'occurence dans lesdit commentaires, ce n'était pas un humour drôle.
C'est dommage car je ne connais pas encore beaucoup les techno qui gravitent autour de Mozilla :( Je ne m'y mets que seulement...
Faudrait voir à définir le mot "rire de tout". Moi les conneries pas droles ca me fait rire :-) J'aime pas les blagues droles... :-(
Pour l'anglais, d'après le prof j'ai un niveau "intermediate upper", ca le fait? Je fais des conf call avec des pays étrangers, je ne comprends en moyenne que 2 personnes sur 3. (Yen a toujours un pour avoir un accent pire que la moyenne des ours, qui ne sont pas spécialement connu pour leur compréhensibilité en anglais)
Sinon l'emplacement est idéal pour moi. Ya pas un immeuble près de chez vous à louer ou à vendre que je puisse proposer à ma société ? Boulogne c'est un poil trop loin... Ca me plairait bien de bosser pas loin de chez Mozilla :-)
Parler de C++ dans Mozilla ne me semble pas approprié. C'est plutôt du C/C++, c'est à dire du C avec des classes ou du C++ obsolète pré-standard. C'est d'ailleurs sûrement la cause de toutes ces fuites mémoires, et de la programmation très lourde comme la gestion d'erreur.
Franchement, du C++ sans RTTI, sans templates, sans exceptions et sans la bibliothèque standard, c'est pas super excitant pour quelqu'un qui connait le C++ moderne.
loufoque: tu nous sort un bon gros troll.
Ne t'en deplaises, il y a bien des templates, de l'heritage (multiple même, va donc faire ça en C), tu peux meme activer les rtti ou les exceptions si ça te chante lors de la compil de gecko etc..
Cependant, les spécifités dont tu parles n'ont absolument rien de standard dans la pratique, pas plus que tes soit-disant bibliothèques. Je te rappelle que Gecko a pour objectif d'être multiplateforme, donc est déstiné à être compilé sur des machines diverses avec des compilateurs C++ divers. Pour te donner une idée des problèmes de portabilité : http://www.mozilla.org/hacking/portable-cpp.html
De plus, les RTTI et les exceptions posent des problèmes de perfs pour un projet aussi énorme que Gecko. Des tests ont déjà été fait sur Mozilla avec l'utilisation de rtti et des exceptions, et ce n'était franchement pas encourageant.
Donc exit les exceptions, RTTI, bibliothèque standard &co.
Quant à ton hypothèse sur la cause des fuites mémoires, c'est vraiment n'importe quoi. Des fuites mémoires, tu peux en faire autant en C qu'en C++. C'est juste une question de propreté du code. On peut d'ailleurs être heureux qu'il y ait aussi peu de fuites mémoires sur les millions de lignes de code de Mozilla, et pour ça faut remercier XPCom.
Aucunement.
Le C++ standard et moderne est de loin supérieur au C++ pré-standard, c'est un fait. Sinon le commité de standardisation ne travaillerait plus dessus.
Relis le lien que tu m'as donné (que j'avais bien entendu déjà lu avant).
C'est déconseillé et limité aux trucs les plus basiques. Alors que les templates sont un outil extremement puissant (métaprogrammation etc.), il suffit de regarder certaines bibliothèques de boost pour s'en convaincre.
(boost est un ensemble de bibliothèques C++ de haute qualité dans le style de la bibliothèque standard, et c'est de là qu'émanent la plupart des propositions pour la norme)
Ça n'a rien d'extraordinaire. Et ça se fait simplement en C (avec virtualisation etc.), c'est juste hyper lourd à utiliser.
Elle font partie du standard C++ (normalisé par l'ISO), et ceci depuis sa création en 1998 (le dernier standard date de 2003, et le prochain, qui introduit nombre d'innovations, est prévu pour 2008-2009).
La bibliothèque standard est une bibliothèque... standard. Elle fait aussi partie de la norme.
Et elle fait aussi partie de la liste des trucs à ne pas utiliser dans Mozilla.
Un compilateur C++ se doit de respecter la norme.
Bien sûr, on peut éviter d'utiliser des points particulièrement délicats qu'on sait pas implementés, comme 'export' qui est très critiqué.
Ces directives ne sont pas des directives de portabilité entre des compilateurs C++ divers mais des directives pour rester compatibles avec des compilateurs obsolètes.
Tous les compilateurs C++ actuels (c'est à dire ceux réalisés après 1998) supportent suffisamment bien le C++ standard pour en utiliser toutes les fonctionnalités et pas seulement un sous-ensemble.
Bon déjà les RTTI et les exceptions ça n'a rien à voir.
Les RTTI sont un outil de programmation objet très pratique, et cela demande de concevoir les choses autrement pour pouvoir s'en passer.
Ce n'est pas vraiment lent et cela nécessite une taille d'éxécutable légèrement plus importante. Ça a des conséquences bien moindres que les exceptions en tous cas.
D'ailleurs XPCOM est basé sur un principe semblabe aux RTTI, sauf que ça n'utilise pas les facilités standard mais un truc maison.
Parlons des exceptions.
Le code de Mozilla est extremement lourd et on doit mettre des NS_MACHIN partout en vérifiant et en remontant manuellement les erreurs. Pratique manuelle ennuyeuse où l'on peut aisément se tromper. Quand Firefox crashe, ça vient de là : une gestion d'erreur oubliée. Je ne suis pas certain que les exceptions soient vraiment beaucoup plus coûteuses que ce processus manuel semblable, d'autant plus qu'une exception n'est levée qu'en cas d'erreur, ce qui est a priori n'est pas la plupart du temps. Enfin j'admets que c'est plus lent oui, a priori.
Tu dis que Gecko a été testé avec les exceptions, mais cela aurait nécessité une totale reconception du code. Je doute donc que ces tests aient été faits avec du code bien pensé autour de cette fonctionnalité.
Si tout cela a vraiment été sérieusement profilé et qu'il a déterminé que l'utilisation des exceptions (pour les RTTI j'en doute fortement) avait vraiment un impact néfaste sur les performances, alors il est justifié qu'elles ne soient pas utilisées.
Il n'empêche que le système de gestion d'erreurs dans Mozilla est très chiant, ce qui est la base de mon commentaire précédant : le caractère ennuyeux de travailler avec du code de ce type, pas pratique du tout.
Bien sûr, techniquement, c'est possible d'en faire.
Sauf que dans du bon C++ moderne on utilise très peu de pointeurs (quand on en utilise, pour le polymorphisme par exemple, et on utilise généralement des conteneurs intelligents), on utilise du RAII. Donc pas de fuites, le code se devant d'être exception-safe.
XPCOM utilise du reference counting pour gérer la mémoire de ses objets (ce qui est a priori le seul moyen étant donné qu'un objet XPCOM est censé être une ressource partagée sans objet propriétaire), ce qui fait qu'effectivement ils libèrent toujours la mémoire qu'il leur ait associée. Enfin cela serait le cas si le refcounting était géré automatiquement avec les destructeurs et les constructeurs par copie, mais non c'est manuel apparemment (j'avoue connaître assez peu le code interne de Mozilla, le peu que j'en ai lu m'ayant suffit à m'en désintéresser), donc y'a encore possibilité de se planter.
Et puis tous les objets dans Mozilla ne sont pas des composants XPCOM.
Si le projet Mozilla n'utilise pas ces facilités c'est qu'à l'époque où il a été commencé le C++ standard n'existait pas (il n'existait que l'ARM) et les implémentations de certaines fonctionnalités expérimentales étaient mauvaises.
Ce sont d'ailleurs les raisons avancées dans le document que tu as fourni.
Tout ces arguments (pour et contre) sont bien intéressants, mais dans le cas de Mozilla il n'y a qu'une chose qui compte : Comment continuer à faire évoluer la plate-forme sans y passer 5 ans ? Loufoque, tel est ton challenge : montrer concrètement que l'on peut faire passer le code de Mozilla au Full C++. Et pas sur 2 exemples simplistes, mais par exemple en réécrivant Necko dans ton optique.
Je répète, les templates sont utilisées dans Mozilla. Cf les nsComptr, la lib string etc.. Seulement, il n'y a pas non plus besoin d'utiliser des templates à tout va, donc.. Et d'ailleurs je me demande si l'usage des templates n'est pas incompatible avec le système XPCom... (faire des xpcom à base de template quoi..)
En theorie oui, dans la pratique, non.
Même en utilisant les techniques de bases de C++, il y a des incompatibilités avec des compilateurs modernes parfois pour compiler Mozilla. (j'en ai fait moi même la triste experience, et pourtant avec des versions récentes de gcc sur des machines différentes). Si en plus il faut se payer les incompatibilités inévitables des trucs avançés de C++, vu la taille du code de Mozilla, ce n'est pas jouable.
en theorie, mais dans la pratique, ce n'est pas le cas, surtout sur des machines "exotiques".
s/légèrement/beaucoup . Vu la taille du code de Mozilla, utiliser les RTTI partout augmenterait la taille de l'executable de façon non négligeable. Déjà que certains se plaignent de devoir télécharger 6Mo... Et puis comme tu l'as souligné, le caractère des XPcom fait que c'est pas trés utile.
Faux. En mode débug, si tu utilises correctement les macros (assertion, test de valeurs de retours..), tu peux trés facilement remonter l'erreur puisque tu as une trace dans la console.
Et puis franchement, faire des return NS_XXXX et des NS_ENSURE_SUCCESS(rv,rv), c'est pas plus lourd que d'écrire des instructions throw et faire des try catch partout...
D'ailleurs, d'autres gros projets semblent s'en passer trés bien (dans KDE par exemple, je vois pas beaucoup d'utilisation d'exceptions, voir pas du tout même.. c'est bien qu'il doit y avoir une raison ;-)
Renseigne toi sur la manière dont sont implementés les exceptions...
Tout est profilé, analysé, testé, vérifié, re-verifié, par des personnes différentes dans Mozilla (sans parler des tests effectués par les tinderbox en permanence). Tu crois qu'ils font expres de rendre Gecko lourd, lent et moche comme certains se plaignent ? Et puis bon, les développeurs du core, ce ne sont pas des débutants ni des mauvais hein, plutôt le contraire d'ailleurs.. Les choix qu'ils ont fait n'ont pas été fait au hasard.
c'etait manuel au début. Ça fait longtemps que ce n'est plus le cas grâce aux nsCOMPtr.. Ça fait un baille qu'on n'a plus besoin de s'occuper de gérer ce compteur... nsCOMPtr, c'est magique ;-)
Exactement... Il est possible que des compilateurs se soient améliorés. Cependant, ces recommandations sont d'actualités car :
Le code de Mozilla propose des choses qui remplacent RTTI, les exceptions, et la bibliothèque standard, tout en permettant une bien meilleure portabilité, donc je ne vois pas en quoi c'est un inconvénient. C'est juste une question d'habitude.
Fabrice : bien vu ;-)
Et que ça compile sans problème sur toutes les plateformes supportées
Il faudrait tout reconcevoir, ce qui est une perte de temps considérable vu les gains, qui ne sont même pas perceptibles par les développeurs actuels qui n'ont pas la formation moderne adéquate.
En plus, comme ils sont habitués à ça, le problème est amoindri.
Il faudrait que tu m'expliques comment quelque chose peut faire partie du standard en théorie mais pas en pratique.
C'est quand même assez concrêt un standard.
Mozilla n'a pas la vocation de tourner sur des machines exotiques.
x86, PowerPC, SPARC, HP-UX, AIX et sûrement quelques autres architectures commerciales avec leur Unix dédié.
D'ailleurs la liste des plateformes supportées que tu as fourni le confirme. Il suffit donc de voir le support du C++ de aCC, HP cc et Compaq cc. (puisque GCC on sait déjà)
Une recherche peu appronfondie m'informe qu'ils sont "largement conformes" à ISO/IEC 14882.
Je suis curieux.
Fournis donc des preuves tangibles si tu peux, ça m'intéresse.
Vieille comment ? Mozilla ne supporte plus Mac OS Classic, donc à partir du moment où c'est vieux, qu'il existe des mises à jour, et que le support devient un problème, on peut abandonner les vieilles plateformes.
De toutes façons le compilateur de Solaris c'est GCC.
Tu n'as pas compris de quoi je parlais.
Lorsqu'une exception survient, elle remonte toute seule les différents blocs jusqu'à un bloc try (je crois qu'on appelle ça le bubbling) et passe dans le catch.
Avec la méthode des valeurs de retour, il faut réaliser ce remontage manuellement.
Sauf qu'on ne fait jamais des throw et des try/catch partout, c'est tout l'intérêt du truc.
Pas besoin de gérer toutes les erreurs possibles à chaque appel de fonction, elles pourront être gérées à des blocs supérieurs.
KDE et Qt ne sont pas du C++ moderne non plus.
Avec setjmp et longjmp.
Enfin, si on parle de l'équivalent technique en C.
Sauf que les solutions standard sont meilleures et plus élégantes. C'est l'élite des théoriciens de l'informatique qui ont mis au point ses mécanismes à travers des commités rigoureux.
Mozilla n'est qu'un petit groupe de développeurs, qui certes a de bons éléments, mais son framework n'est pas vraiment existant ni intéressant d'un point de vue théorique, puisqu'il conserve par exemple beaucoup de faiblesses du C. D'ailleurs il est très peu utilisé en dehors des projets Mozilla.
C'est bien là le problème. Le framework a un passé historique. Il faut faire avec. Ou alors trouver des volontaires qui veulent bien refondre des parties de code. En hackant egalement les binding xpcom de manière à propager les exceptions C++ d'un xpcom à un autre, sachant qu'un xpcom n'est pas forcément en C++ ;-)
Tu pointes un autre problème : si tu veux avoir des contributeurs, il ne faut non plus utiliser des trucs de laboratoires (les exceptions, rtti etc étaient des trucs de laboratoire avant que ce soit normalisé et correctement implémenté dans les compilateurs, c'et à dire jusqu'à il y a peu de temps, et en tout cas beaucoup trop tard pour que le projet Mozilla puisse se baser dessus).
C'est quand même assez concrêt un standard.
Par "en pratique", je veux parler des implémentations dans les compilateurs. Aucune implémentation n'est parfaite. D'où les problèmes cross-plateforme qui peuvent apparaître.
être au maximum portable est le but du projet. Et par machines "exotiques" (ou plutôt système exotiques), je parle des hp-ux, beos, amigaos, qnx, freebsd etc..
gcc ou pas. un vieux gcc est un vieux gcc.. Et il y a x version de gcc, incompatibles entre elle bien entendu.. Va donc interroger Paul Rouget à ce sujet, qui a bataillé dur sur des Sun pour compiler des gecko... Si il y avait en plus ces histoires de
merci je connais :-p.
La méthode à la Mozilla et la méthode à la "exception" ont chacune leurs inconvénients et leurs avantages. On ne va pas débattre sur ce sujet indéfiniement. D'ailleurs c'est totalement hors sujet par rapport au billet.
Tu n'aimes pas le framework Mozilla, tant pis pour toi. Ce n'est pas le cas des centaines de contributeurs au projet (si tu appelles ça un petit groupe..). À la limite ton avis sur le framework, on s'en fiche un peu. Tu ne veux pas comprendre qu'il y a un passif et des bonnes raisons de ne pas être un intégriste du C++ sur ce projet. Je ne te retiens pas d'aller voir d'autres projets qui respecterait à la lettre le C++ et d'aller troller ailleurs, merci.
Comme tu y va Laurent....
Je te trouve très dur avec loufoque qui apporte une grosse plus value à ce billet avec tout un tas d'informations techniques sur le C++ moderne (qui d'un point de vue perso m'ont bcp plus), et surtout qui a pris le temps de répondre en argumentant et donnant des exemples concrets.
Tu dis qu'il "ne veux pas comprendre" qu'il existe un passif, mais pourtant rien dans le message ne semble l'affirmer. Il s'est contenté de donner une raison valable pour laquelle l'aventure ne le tenterais pas, sans remettre en cause le résultat auquel l'effort aboutit.
J'imagine que tu aurais très bien pu dire, quelque part, "travailler sur un site bidule.fr, avec du vieux html tout moche non standard.... non merci, ça ne me fait pas envie".
Gérald: disons que Laurent (et certains bloggueurs) ne portent pas Loufoque dans leur coeur.
Je comprends complètement Laurent. Développer avec Mozilla est un vrai plaisir, un fois le principe compris, c'est vraiment un environnement puissant. Après on pourra venir nous voir en disant que XPCom n'exploite pas les dernières nouveautés, ou que ce n'est pas très moderne, mais les faits sont là. XUL ça déboite, associé à la puissance de XPCom, on est capable de développer de manières réellement efficace.
Le fait est que Laurent a une sacré expérience dans le dev Mozilla.
Donc bon, quand un gars vient te ballancer des histoires "XPCom, pas moderne, obsolète pré-standard, pb de fuites mémoires, programmation très lourde", bah ça fait chier. Il y a ceux qui codent et ceux qui parlent. Laurent code :) Et c'est peut être pour ça que Laurent nous parle beaucoup de "pratique".
Alors attention ! On pourrait nous accuser de ne pas supporter les critiques négatives. En fait, mon soucis c'est que Loufoque a déjà fait parlé de lui sur différents blogs, et à force de jouer au con, au bout d'un moment, il n'est plus crédible et passe surtout pour un gros trolleur.
@Paul: Ok.... avec l'historique je comprends mieux la distance affichée de la réaction.
Toujours est-il que je suis content d'avoir lu cet échange somme toute très interressant sur le C++ :-) ça m'a presque donné envie de m'y remettre.
On va me traiter de trolleur fou... Mais je suis assez connu pour ça :-)
Mais à un moment le passif faut l'oublier. Faire table rase et repartir sur des bases saines. Maintenant que Mozilla a fractionné proprement ses applications... Passer à autre chose ce serait bien non ? Histoire de prouver que le projet est pas englué dans des considérations historiques plombantes. Moi je dis que Jelix est né dans un but louable... A cause du passif de Copix. A quand un mozilla-baby en pur C++ ?
C'était mon 1/4 d'heure troll, d'un amateur de C++, qui aime vraiment pas se trainer des boulets C à la patte 'parce que c'est plus rapide, parce que les exceptions c'est lent'.
P.S.: De toute façon... Je ne contribuerai pas à Mozilla, je n'ai ni le temps, ni l'envie de ma lancer dans cette usine à gaz si particulière. J'ai déjà pas mal à faire avec d'autres, alors au pire oubliez ce que j'ai dis... Je me contente d'utiliser firefox :-)
jardin: Mais pourquoi donc ? Quelle raison sérieuse y a t il à refondre Gecko ? En quoi les bases de Gecko ne sont pas saines ?
Arretons de troller, et sortez moi des arguments sérieux sur ce que vous reprochez à Mozilla. Je ne suis pas un dieu du C++, je suis loin de connaître toutes les entrailles de Mozilla, donc je ne peux pas réellement juger de la qualité de son code interne. Par contre, je fais confiance à l'équipe Mozilla pour faire les choses correctement. Donc allez y, critiquez. Vos analyses m'intéresse énormément et intéresseront aussi les développeurs du coeur. Mais je ne jugerais vos critiques crédibles qui si vous essayez de donner un minimum l'impression de savoir de quoi vous parlez.
Je ne connais peut être pas tellement les profondeurs de Mozilla, mais assez pour savoir que ces derniers posts ne sont que des discutions de comptoirs sans interets.
Je vais allez voir dbaron avec vos posts sous les bras, je pense qu'il va bien rigoler :)
Jardin : autant refondre Copix est relativement envisageable. C'est un "petit" projet. Autant refondre gecko est impensable. Le coeur est d'une part relativement complexe (algorithmiquement parlant), mais surtout trés gros. On ne parle pas de quelques milliers de lignes de codes comme dans Copix, mais on compte en millions. À moins d'avoir une centaine de developpeurs à temps plein disponibles (et l'argent qui va avec pour les payer, sachant qu'il faut des experts, pas des débutants, donc cher), et accepter de ne pas sortir de nouvelles versions pendant plusieurs mois.
Rappelle-toi, il y a déjà eu une grosse refonte du moteur (réécriture from scratch en fait), débuté en 1998, aprés l'ouverture du code de Netscape. Il a fallu attendre 5 ans pour avoir enfin un truc stable et relativement performant (sortie de Mozilla 1.0).
Bon courage à ceux qui veulent retenter l'aventure.
En fait, Gecko est l'un des rares projets libre où forker est trés difficile : cela demande beaucoup de temps et une trés grande expertise (donc rare) pour faire des modifications significatives dans le coeur. Les rares personnes qui sont capables de faire ce genre de chose sont... Chez Mozilla Corp. quand je parle de forker gecko, je ne parle pas de fork de Firefox; forker Firefox, c'est à dire forker pour modifier son interface et autres fonctionnalités de "surface" c'est tout à fait envisageable. (cf le navigateur Flock). Mais forker pour modifier le coeur, le moteur de rendu, c'est une autre paire de manche. Cela demande des moyens conséquents.
Et comme dit Paul : même si une refonte était envisageable, il n'est pas sûr que le résultat apporterait une grande plus-value au projet.
Sans compter les problèmes qui peuvent débarquer. Comment par exemple propager une exception survenue dans un XPCOM en C++, dans un XPCOM appelant en javascript, qui lui même serait appelé par un XPCOM en python, qui lui même serait appelé par un XPCOM développé en langage MachinBidule, dans lequel il n'existe pas de système d'exception... Bonjour le code source des bindings chargés de faire la correspondance.. C'est pas infaisable (cela existe de JS vers C++), mais niveau complexité, ça en rajoute...
On se rend compte que le système actuel n'est pas si mauvais que ça, une fois que l'on a étudié le truc et si on tient compte de tous les problèmes sous-jacent à l'utilisation de langages multiples, et de l'aspect multi-plateforme/multi-OS, de cet aspect liaison dynamique à la volée que permet COM et XPCOM...