Voila la première fois que je me fais bannir d'un chan irc...
Il y a un début à tout. Je peux comprendre que tu te sentes frustré et incompris, mais il y a bien pire dans la vie et un ban n'est que temporaire.
D'une manière générale il est toujours plus facile d'aller chercher les problèmes chez les autres que chez soi... En l'occurence poster une url sur un chan IRC est souvent mal vu (facilement assimilé à du spam), en particulier quand c'est répété sans raison. Si tu avais un peu expliqué le pourquoi du comment avant de t'empresser de coller ton lien tel un vulgaire spammeur, la réaction des opérateurs du canal aurait sûrement été différente.
NB : Je ne fais pas partie du canal bashfr (que je ne connais meme pas) et ne parle pas en leur nom. Mais en vieux routard de l'IRC, je trouve que tu as bien mérité ce qui t'arrive pour te faire réfléchir. Et qu'on ne t'y reprenne plus, garnement :-)
Merci à l'auteur et tous ceux qui ont contribué à nous apporter une information si claire et détaillée !
Une petite question tout de même : les améliorations apportées dans cette nouvelle mouture produisent donc des binaires plus performants au final pour le même code source, si j'ai bien compris. Mais qu'en est il du temps de compilation lui-même ? Y-a t'il un surcout à ce niveau ?
Sinon, pour quel type de code/projets bénéficiera t-on le plus des améliorations de gcc 4.1 ? Et peut-on redouter des incompatibilités de certains codes sources comme ce fut le cas lors du passage à gcc 4.0 ?
Je penses qu'il faudrait que tu commences par essayer ASP.NET avant de continuer la conversation, au moins on perdrait pas de temps sur des contre-vérités.
Pas de problème, trouve moi un paquet debian de VS.NET et on en reparle :-) Sinon tu m'as parfaitement convaincu d'oublier.
Evidemment paye ta galère :) Faut l'environnement de dev Visual Studio .NET et c'est tout de suite plus rapide. En plus le risque en partant avec un simple éditeur de texte, c'est de coder comme en PHP, cad avec des < % code au milieu du HTML, sans utiliser de code-behind, bref affreux.
Donc si tu n'as pas l'usine à gaz propriétaire visual dupleix pour concevoir tes usines à gaz persos, ça n'apporte rien par rapport à php. Ah si, vu que c'est pas conçu pour, c'est encore moins coder-friendly.
Certes, c'est beaucoup plus compliqué. Mais aussi beaucoup plus puissant.
A démontrer, je ne suis pas convaincu du tout...
Euh, quand t'es en mode release et que tout est compilé, c'est en tout cas plus rapide que du PHP. Enfin c'est difficilement comparable tellement on code pas pareil en PHP qu'en ASP.NET.
Là faut savoir si on parle de rapidité d'éxécution ou de développement. A l'éxécution, .NET compile, ce qui devrait lui fournir un avantage, hors il ne compile que du bytecode parsé et executé par une VM derrière et pas du langage machine natif, en cela comparable à java, référence universelle de la lenteur s'il en est. Gros détour pour revenir au point de départ donc.
Du côté de php, le code est parsé en plusieurs couches et d'abord découpé en opcodes qui peut bénéficier d'un mécanisme optionnel de cache complètement transparent pour le développeur.
Et si on juge le développement, si on égalise les moyens (simple éditeur de texte avancé avec coloration syntaxique pour les deux cas), je crois que le temps de déboguage fera la différence. En ce domaine php est perfectible et il se peut effectivement que .NET se distingue... Mais l'aisance d'apprentissage de PHP et la puissance de certaines fonctions basiques peuvent aussi jouer.
Si on considère le temps de développement en .NET aidé de VS, là, effectivement ce n'est plus comparable. On gagnera beaucoup de temps sur certains points et on en perdra sur d'autres dans les deux cas, les approches étant tout de même très différentes.
Mais c'est des composants : le gros avantages c'est qu'ils sont réutilisables. Quand on y a goûté, difficile de revenir à PHP.
Et inversement, quand on a goûté à la liberté et la flexibilité d'un langage comme PHP, difficile d'aller s'enfermer avec des composants .NET.
Moi j'ai envi de te répondre qu'en PHP tu dois faire des templates pour simuler des contrôles ;)
C'est vrai. Maintenant, il faut aussi relativiser la portée du mot "template" en php : on peut faire du template en restant ultra-simple et accessible à tout codeur meme grand débutant, et en plus tout en gardant des performances maximum (la fonction include() de php est en cela un modèle de puissance et d'utilité uniligne que peu d'autres langages égalent).
Tout l'intérêt est là : le code C# est compilé, tu as donc tous les avantages liés : vérifications de type, débogage, performances, etc.
Et tout le désintérêt aussi : rigidité, opacité, plantabilité, mélange abscons de langages compilé et interprétés dans le même projet...
Si tu veux quelquechose de raisonnablement sûr et qui n'excluera quasiment personne, tu peux tenter cette approche :
- d'un coté, un test CAPTCHA classique avec une image
- de l'autre côté, avec le même code que le CAPTCHA, un fichier sonore mis à disposition généré directement via voiceXML.
- un champ classique pour permettre à l'utilisateur de rentrer le code trouvé par l'un ou l'autre des moyens proposés.
Intérêt de cette approche : Les aveugles ne sont pas exclus, puisqu'il y a le son. Les sourds et malentendants ne sont pas exclus non plus, puisqu'il y a l'image.
Bien sûr, le pauvre type qui est aveugle ET sourd aura bien du mal, mais même sans toi il en aurait déjà de toute manière. Une personne aussi dépendante aura forcément une personne valide pas trop loin d'elle pour l'aider si besoin.
Ca peut être une solution pour toi, si tu n'as pas peur de sortir le bazooka pour avoir un bon niveau de filtrage donc.
Ce que je veux dire, c'est qui ira vérifier ? Et comment ?
Dans le monde du logiciel, il est facile pour un vendeur peu regardant de "s'inspirer" de code GPL pour améliorer son propre produit non-GPL. Or là on parle de spécifications matérielles, et je n'ai pas souvenir de précédent de la GPL appliquée à ce genre de choses, alors je me demande ce qui les empêcherait de le faire...
5) La possibilité pour Intel et AMD d'aller puiser de bonnes idées à peu de frais pour faire évoluer leurs versions du x86. Enfin, s'il y en a à puiser...
Ce n'est pas la seule entrée du système de suivi qui ait été placardisée, et tu le sais sûrement si tu as fermé autant de tickets, tu dois sans doute très bien les connaître.
Je ne sous-entend pas un seul instant que toi ou Pascal n'en faites pas assez, soyons bien clairs là dessus. Mais si vous n'avez pas le temps de traiter tout ce que vous voulez traiter, il y a problème. Soit il faudrait accepter moins de requêtes, quitte à en refuser certaines pertinentes ou les marquer explicitement comme reportées aux calendes grecques, soit il vous faudrait de l'aide. Non ?
Je ne peux qu'être bien d'accord avec toi. Ce système a une utilité certaine.
Attention : les paragraphes qui suivent ne sont pas une attaque en règle.
Mais penses-tu que la réactivité des mainteneurs des linuxfr est satisfaisante en regard de la seule activité sur le système de suivi, comme tu le rappelles, la seule qu'on peut réellement chiffrer ? Car en fait ce système qui a l'avantage de rendre tout traçable a aussi pour caractéristique de rendre le travail des mainteneurs quantifiable. De ce point de vue, êtes vous satisfaits de la quantité et de la pertinence des demandes traitées ? Combien d'items du système de suivi sont toujours ouverts ? Pour quelle raison ceux-ci n'ont ils toujours pas été traités ("faute de temps" et "faute de bras" étant des réponses ponctuelles et non des réponses de fond) ?
Ce journal met en lumière un cas concret. Je crois que ce n'est pas la seule entrée du système de suivi qui ait été boudée/oubliée/enterrée/remisée etc... La question serait de savoir s'il faut aussi créer un journal pour les autres afin d'avoir au moins une réponse du style "on le fait" || "on ne va pas le faire" || "on n'a pas compris, précise"...
Je vais me répéter, mais je ne suis pas en train d'attaquer au lance-flammes ici, nous apprécions tous le temps que vous passez à travailler bénévolement sur ce site pour nous. Je pousse simplement à la remise en question et à la réflexion sur des améliorations possibles.
Tu dis qu'il est impossible de retrouver les bugs/feature requests rapportés dans les journaux. Peut-on alors envisager alors de catégoriser les journaux, au même titre que les forums ou les dépêches, pour régler le problème ? Ou alors, pourquoi ne pas catapulter ce journal dans le forum linuxfr.bug ? (Tiens d'ailleurs, pourquoi l'auteur du journal n'a t-il pas le droit de transformer de lui-même son journal en forum x.y ? et pourquoi l'auteur d'une entrée de forum ne peut-il pas recatégoriser son entrée s'il en ressent le besoin ? l'ergonomie du site sur le choix du forum dans lequel on poste n'étant pas, à mon avis, optimum).
Ca te sauvera la prochaine fois. Il vaut toujours mieux avoir quelques copies (meme inutiles) qui trainent de /etc/X11/xorg.conf que de se faire avoir lors d'une mise à jour.
tu ne peux répondre qu'à 1/20 des offres, celles qui correspondent à ton profil.
Une partie du boulot du chômiste malin dans le domaine (mais ca vaut surement dans tous) consiste à augmenter le plus possible cette proportion. Tant en diversifiant les sources d'annonces qu'en étoffant tes domaines de compétence. En cela, l'anpe peut parfois t'aider (Ils sont plus doués pour ca que pour te trouver un emploi !)
Concerné par la chose et suivant les offres depuis un moment (les curieux regarderont mes journaux), je souhaite compléter ton analyse sur ce point précis. Contrairement à toi je ne dirais pas qu'il y a peu d'offres php. J'en vois plutôt pas mal finalement, notamment sur lolix. La surprise, c'est que ces offres :
- Sont des offres de stage avec expérience : on veut bien t'apprendre à bosser gratuitement en php, en agence, "sur des projets concrets et motivants", surtout si tu sais déjà, mais pas te payer pour.
- Demandent php en compétence annexe d'un poste qui a finalement peu ou rien à voir avec php (Notamment les admins système), parceque ça fait joli, parceque tu seras amené à avoir des interactions avec des devs php, parcequ'on te demande d'administrer des serveurs web... Bref parcequ'on préfère toujours prendre quelqu'un qui en sait trop que pas assez, surtout pour pas plus cher.
- Demandent php en compétence primaire associée à la panoplie habituelle du webmaster (asp, jsp, html, xml, css, js, standards, flash, rédaction, design, mise en page, multimédia... etc), la compétence php étant alors noyée dans la masse et va de soi. Mais c'est celle des trois ou elle est la plus mise en valeur finalement.
NB : on me trouvera bien quelques offres qui sortent de ces 3 catégories, néammoins elles sont plutôt représentatives de l'ensemble des offres liées au langage qu'on trouve actuellement.
Le fait est qu'on réduit souvent PHP à un langage de script de deuxième rang. Regarde les actualités du libre qui passent régulièrement ici : on annonce des bindings de tel logiciel pour "tous les langages de scripts", à savoir python, perl, ruby... mais php jamais (Selenium tiens, dernier exemple en date...).
Aussi, malgré le fait que ce soit tout à fait possible, on ne voit jamais (ou alors à titre exceptionnel pour des cas très particuliers : nanoweb, phind... ) émerger d'application php en dehors du contexte web. Alors que php peut faire de la ligne de commande tout à fait correctement, et même de la GUI.
De l'avoeu même de Rasmus Lerdorf, inventeur du langage, PHP est un langage de glu. C'est amusant de voir qu'on le cantonne à ce rôle également dans les CVs...
Pourtant, la compétence php existe bel et bien, et ne semble pas reconnue à l'heure actuelle en tant que telle par les recruteurs. Personnellement je trouve cela dommage, j'ai du mal à croire qu'il n'y ait pas de besoin...
Je confirme que ça marche très bien pour Paris. Et pour ce qui est du test, qu'ils l'aient fait ou pas, j'aurai râlé très fort si ça ne marchait pas parfaitement :-) Accordons-leur le bénéfice du doute. La personne avec qui j'ai été en contact via e-mail semble très consciente de l'existence des logiciels libres.
Le libre c'est aussi le droit de s'organiser comme on le souhaite.
Ca me rappelle un peu ubuntu et ce qu'on a pu en dire dernièrement, tout ça. Peut-être que ça dérange certains de savoir qu'une entité centrale prend des décisions critiques sur l'avenir du projet, quitte à ne pas chercher un vain consensus pendant plusieurs années...
Si on essaye de voir les choses de manière pragmatique, on met ça dans la balance avec le résultat final : les *ubuntu sont sans conteste parmi les meilleures distributions orientées desktop du moment, et on ne peut pas dissocier les deux. Et au final, la distribution n'en est pas moins libre qu'une autre...
A mon avis il en sera de même avec Xgl : Novell se donne les moyens d'avancer dans son coin sur le projet qui leur tient à coeur, qui est quand même d'envergure assez conséquente, et communique autour des résultats concrets obtenus au final. Eh bien qu'ils continuent, et merci Novell !
[^] # Re: ben moi aussi
Posté par Cali_Mero . En réponse au journal script de "ping" pour technorati et consort. Évalué à 3.
# Ici peut-être ?
Posté par Cali_Mero . En réponse au message Algorithme OGG. Évalué à 4.
Pour info, Ogg n'est qu'un format conteneur, ce qui semble t'intéresser c'est Vorbis (le codec).
Peut-être trouveras-tu ton bonheur par là : http://xiph.org/vorbis/doc/
# Ca fait toujours mal la première fois...
Posté par Cali_Mero . En réponse au journal Y en a marre des imbéciles sur IRC.... Évalué à 5.
Il y a un début à tout. Je peux comprendre que tu te sentes frustré et incompris, mais il y a bien pire dans la vie et un ban n'est que temporaire.
D'une manière générale il est toujours plus facile d'aller chercher les problèmes chez les autres que chez soi... En l'occurence poster une url sur un chan IRC est souvent mal vu (facilement assimilé à du spam), en particulier quand c'est répété sans raison. Si tu avais un peu expliqué le pourquoi du comment avant de t'empresser de coller ton lien tel un vulgaire spammeur, la réaction des opérateurs du canal aurait sûrement été différente.
NB : Je ne fais pas partie du canal bashfr (que je ne connais meme pas) et ne parle pas en leur nom. Mais en vieux routard de l'IRC, je trouve que tu as bien mérité ce qui t'arrive pour te faire réfléchir. Et qu'on ne t'y reprenne plus, garnement :-)
# Ca c'est de la bonne dépêche !
Posté par Cali_Mero . En réponse à la dépêche Sortie de la version 4.1 du compilateur GCC. Évalué à 10.
Une petite question tout de même : les améliorations apportées dans cette nouvelle mouture produisent donc des binaires plus performants au final pour le même code source, si j'ai bien compris. Mais qu'en est il du temps de compilation lui-même ? Y-a t'il un surcout à ce niveau ?
Sinon, pour quel type de code/projets bénéficiera t-on le plus des améliorations de gcc 4.1 ? Et peut-on redouter des incompatibilités de certains codes sources comme ce fut le cas lors du passage à gcc 4.0 ?
[^] # Re: Se faire son opinion
Posté par Cali_Mero . En réponse au journal La censure sur linuxfr. Évalué à 8.
[^] # Re: TImaniac dot net
Posté par Cali_Mero . En réponse au journal Daniel Robbins quitte Microsoft. Évalué à 6.
Pas de problème, trouve moi un paquet debian de VS.NET et on en reparle :-) Sinon tu m'as parfaitement convaincu d'oublier.
[^] # Re: TImaniac dot net
Posté par Cali_Mero . En réponse au journal Daniel Robbins quitte Microsoft. Évalué à 2.
Donc si tu n'as pas l'usine à gaz propriétaire visual dupleix pour concevoir tes usines à gaz persos, ça n'apporte rien par rapport à php. Ah si, vu que c'est pas conçu pour, c'est encore moins coder-friendly.
Certes, c'est beaucoup plus compliqué. Mais aussi beaucoup plus puissant.
A démontrer, je ne suis pas convaincu du tout...
Euh, quand t'es en mode release et que tout est compilé, c'est en tout cas plus rapide que du PHP. Enfin c'est difficilement comparable tellement on code pas pareil en PHP qu'en ASP.NET.
Là faut savoir si on parle de rapidité d'éxécution ou de développement. A l'éxécution, .NET compile, ce qui devrait lui fournir un avantage, hors il ne compile que du bytecode parsé et executé par une VM derrière et pas du langage machine natif, en cela comparable à java, référence universelle de la lenteur s'il en est. Gros détour pour revenir au point de départ donc.
Du côté de php, le code est parsé en plusieurs couches et d'abord découpé en opcodes qui peut bénéficier d'un mécanisme optionnel de cache complètement transparent pour le développeur.
Et si on juge le développement, si on égalise les moyens (simple éditeur de texte avancé avec coloration syntaxique pour les deux cas), je crois que le temps de déboguage fera la différence. En ce domaine php est perfectible et il se peut effectivement que .NET se distingue... Mais l'aisance d'apprentissage de PHP et la puissance de certaines fonctions basiques peuvent aussi jouer.
Si on considère le temps de développement en .NET aidé de VS, là, effectivement ce n'est plus comparable. On gagnera beaucoup de temps sur certains points et on en perdra sur d'autres dans les deux cas, les approches étant tout de même très différentes.
Mais c'est des composants : le gros avantages c'est qu'ils sont réutilisables. Quand on y a goûté, difficile de revenir à PHP.
Et inversement, quand on a goûté à la liberté et la flexibilité d'un langage comme PHP, difficile d'aller s'enfermer avec des composants .NET.
Moi j'ai envi de te répondre qu'en PHP tu dois faire des templates pour simuler des contrôles ;)
C'est vrai. Maintenant, il faut aussi relativiser la portée du mot "template" en php : on peut faire du template en restant ultra-simple et accessible à tout codeur meme grand débutant, et en plus tout en gardant des performances maximum (la fonction include() de php est en cela un modèle de puissance et d'utilité uniligne que peu d'autres langages égalent).
Tout l'intérêt est là : le code C# est compilé, tu as donc tous les avantages liés : vérifications de type, débogage, performances, etc.
Et tout le désintérêt aussi : rigidité, opacité, plantabilité, mélange abscons de langages compilé et interprétés dans le même projet...
# Cumuler les avantages de deux techniques
Posté par Cali_Mero . En réponse au journal des idées pour éviter la création automatique de compte par des bots ?. Évalué à 4.
- d'un coté, un test CAPTCHA classique avec une image
- de l'autre côté, avec le même code que le CAPTCHA, un fichier sonore mis à disposition généré directement via voiceXML.
- un champ classique pour permettre à l'utilisateur de rentrer le code trouvé par l'un ou l'autre des moyens proposés.
Intérêt de cette approche : Les aveugles ne sont pas exclus, puisqu'il y a le son. Les sourds et malentendants ne sont pas exclus non plus, puisqu'il y a l'image.
Bien sûr, le pauvre type qui est aveugle ET sourd aura bien du mal, mais même sans toi il en aurait déjà de toute manière. Une personne aussi dépendante aura forcément une personne valide pas trop loin d'elle pour l'aider si besoin.
Ca peut être une solution pour toi, si tu n'as pas peur de sortir le bazooka pour avoir un bon niveau de filtrage donc.
[^] # Re: Et Robert ?
Posté par Cali_Mero . En réponse au journal Changements dans les pages persos. Évalué à 8.
Voici la même chose en plus réaliste et plus concis:
while(!working){
rtfm();
debug();
}
enjoy();
[^] # Re: C'est bien mais
Posté par Cali_Mero . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 5.
Dans le monde du logiciel, il est facile pour un vendeur peu regardant de "s'inspirer" de code GPL pour améliorer son propre produit non-GPL. Or là on parle de spécifications matérielles, et je n'ai pas souvenir de précédent de la GPL appliquée à ce genre de choses, alors je me demande ce qui les empêcherait de le faire...
[^] # Re: C'est bien mais
Posté par Cali_Mero . En réponse à la dépêche Les UltraSparc sous GPL. Évalué à 3.
# Miss Helium
Posté par Cali_Mero . En réponse au message MP3 en libre diffusion. Évalué à 3.
[^] # Re: A quoi ça sert ?
Posté par Cali_Mero . En réponse à la dépêche NLD 10 le poste du travail de demain par Novell (avec XGL et Compiz). Évalué à 3.
[^] # Re: Faut pas exagérer
Posté par Cali_Mero . En réponse au journal DLFP et l'accessibilité !. Évalué à 5.
Je ne sous-entend pas un seul instant que toi ou Pascal n'en faites pas assez, soyons bien clairs là dessus. Mais si vous n'avez pas le temps de traiter tout ce que vous voulez traiter, il y a problème. Soit il faudrait accepter moins de requêtes, quitte à en refuser certaines pertinentes ou les marquer explicitement comme reportées aux calendes grecques, soit il vous faudrait de l'aide. Non ?
[^] # Re: Faut pas exagérer
Posté par Cali_Mero . En réponse au journal DLFP et l'accessibilité !. Évalué à 2.
Attention : les paragraphes qui suivent ne sont pas une attaque en règle.
Mais penses-tu que la réactivité des mainteneurs des linuxfr est satisfaisante en regard de la seule activité sur le système de suivi, comme tu le rappelles, la seule qu'on peut réellement chiffrer ? Car en fait ce système qui a l'avantage de rendre tout traçable a aussi pour caractéristique de rendre le travail des mainteneurs quantifiable. De ce point de vue, êtes vous satisfaits de la quantité et de la pertinence des demandes traitées ? Combien d'items du système de suivi sont toujours ouverts ? Pour quelle raison ceux-ci n'ont ils toujours pas été traités ("faute de temps" et "faute de bras" étant des réponses ponctuelles et non des réponses de fond) ?
Ce journal met en lumière un cas concret. Je crois que ce n'est pas la seule entrée du système de suivi qui ait été boudée/oubliée/enterrée/remisée etc... La question serait de savoir s'il faut aussi créer un journal pour les autres afin d'avoir au moins une réponse du style "on le fait" || "on ne va pas le faire" || "on n'a pas compris, précise"...
Je vais me répéter, mais je ne suis pas en train d'attaquer au lance-flammes ici, nous apprécions tous le temps que vous passez à travailler bénévolement sur ce site pour nous. Je pousse simplement à la remise en question et à la réflexion sur des améliorations possibles.
Tu dis qu'il est impossible de retrouver les bugs/feature requests rapportés dans les journaux. Peut-on alors envisager alors de catégoriser les journaux, au même titre que les forums ou les dépêches, pour régler le problème ? Ou alors, pourquoi ne pas catapulter ce journal dans le forum linuxfr.bug ? (Tiens d'ailleurs, pourquoi l'auteur du journal n'a t-il pas le droit de transformer de lui-même son journal en forum x.y ? et pourquoi l'auteur d'une entrée de forum ne peut-il pas recatégoriser son entrée s'il en ressent le besoin ? l'ergonomie du site sur le choix du forum dans lequel on poste n'étant pas, à mon avis, optimum).
[^] # Re: Faut pas exagérer
Posté par Cali_Mero . En réponse au journal DLFP et l'accessibilité !. Évalué à 1.
A l'inverse ce journal a permis un grand pas dans le bon sens.
La preuve est faite, le système de suivi est l'endroit ou on laisse mourir les requêtes alors que les journaux sont une ligne chaude directe !
# Toujours faire une copie de sauvegarde de xorg.conf quand tout marche...
Posté par Cali_Mero . En réponse au message Pb avec le serveur X, PLEASE HELP !. Évalué à 2.
[^] # Re: meuh
Posté par Cali_Mero . En réponse au message Recrutement d'un développeur Java. Évalué à 2.
[^] # Re: Ma recherche de boulot
Posté par Cali_Mero . En réponse au journal Les n commandements du chercheur de travail. Évalué à 2.
Une partie du boulot du chômiste malin dans le domaine (mais ca vaut surement dans tous) consiste à augmenter le plus possible cette proportion. Tant en diversifiant les sources d'annonces qu'en étoffant tes domaines de compétence. En cela, l'anpe peut parfois t'aider (Ils sont plus doués pour ca que pour te trouver un emploi !)
# réponse au jeu bonus : wget ?
Posté par Cali_Mero . En réponse au journal Une émission haut de gamme sur les navigateurs. Évalué à 4.
----> []
# En parlant d'offres php...
Posté par Cali_Mero . En réponse au journal Les n commandements du chercheur de travail. Évalué à 6.
- Sont des offres de stage avec expérience : on veut bien t'apprendre à bosser gratuitement en php, en agence, "sur des projets concrets et motivants", surtout si tu sais déjà, mais pas te payer pour.
- Demandent php en compétence annexe d'un poste qui a finalement peu ou rien à voir avec php (Notamment les admins système), parceque ça fait joli, parceque tu seras amené à avoir des interactions avec des devs php, parcequ'on te demande d'administrer des serveurs web... Bref parcequ'on préfère toujours prendre quelqu'un qui en sait trop que pas assez, surtout pour pas plus cher.
- Demandent php en compétence primaire associée à la panoplie habituelle du webmaster (asp, jsp, html, xml, css, js, standards, flash, rédaction, design, mise en page, multimédia... etc), la compétence php étant alors noyée dans la masse et va de soi. Mais c'est celle des trois ou elle est la plus mise en valeur finalement.
NB : on me trouvera bien quelques offres qui sortent de ces 3 catégories, néammoins elles sont plutôt représentatives de l'ensemble des offres liées au langage qu'on trouve actuellement.
Le fait est qu'on réduit souvent PHP à un langage de script de deuxième rang. Regarde les actualités du libre qui passent régulièrement ici : on annonce des bindings de tel logiciel pour "tous les langages de scripts", à savoir python, perl, ruby... mais php jamais (Selenium tiens, dernier exemple en date...).
Aussi, malgré le fait que ce soit tout à fait possible, on ne voit jamais (ou alors à titre exceptionnel pour des cas très particuliers : nanoweb, phind... ) émerger d'application php en dehors du contexte web. Alors que php peut faire de la ligne de commande tout à fait correctement, et même de la GUI.
De l'avoeu même de Rasmus Lerdorf, inventeur du langage, PHP est un langage de glu. C'est amusant de voir qu'on le cantonne à ce rôle également dans les CVs...
Pourtant, la compétence php existe bel et bien, et ne semble pas reconnue à l'heure actuelle en tant que telle par les recruteurs. Personnellement je trouve cela dommage, j'ai du mal à croire qu'il n'y ait pas de besoin...
[^] # Re: En effet
Posté par Cali_Mero . En réponse au journal Credit Agricole en ligne refusera bientôt l'accès aux navigateurs alternatifs. Évalué à 2.
# Tant que ça débouche sur du libre, où est le problème ?
Posté par Cali_Mero . En réponse au journal Quand l'union ne fait pas forcement la force.... Évalué à 5.
Ca me rappelle un peu ubuntu et ce qu'on a pu en dire dernièrement, tout ça. Peut-être que ça dérange certains de savoir qu'une entité centrale prend des décisions critiques sur l'avenir du projet, quitte à ne pas chercher un vain consensus pendant plusieurs années...
Si on essaye de voir les choses de manière pragmatique, on met ça dans la balance avec le résultat final : les *ubuntu sont sans conteste parmi les meilleures distributions orientées desktop du moment, et on ne peut pas dissocier les deux. Et au final, la distribution n'en est pas moins libre qu'une autre...
A mon avis il en sera de même avec Xgl : Novell se donne les moyens d'avancer dans son coin sur le projet qui leur tient à coeur, qui est quand même d'envergure assez conséquente, et communique autour des résultats concrets obtenus au final. Eh bien qu'ils continuent, et merci Novell !
[^] # Re: Le rien qui sauve le monde ...
Posté par Cali_Mero . En réponse au journal Vous aussi, appréciez le Web autrement !. Évalué à 3.
/me, qui aimerait bien décrocher le net d'impôts
[^] # Re: Mon moteur de gallerie
Posté par Cali_Mero . En réponse au journal Mon moteur de galerie. Évalué à 4.
\_o< coin !