>Sauf que les roues ovales, si un concurent les propose je peut aller les acheter chez lui, et si je veux de roues ovales je vais pas aller acheter une voiture qui a des roues rondes ou carrée.
je serais curieux de savoir quel constructeur automobile accepterai de vendre des roues ovales. Très franchement ;-)
> Le problème c'est si tu dis au mec je peut pas faire un design au pixel près et que ton concurent le fais, eh bien il va aller chez le concurent.
Non, parce que je lui aurais fait (ou tenter) comprendre le pourquoi de la chose. Et si après ça, il comprend toujours pas, ben alors tant pis. C'est signe que de toute façon, lui et moi on va pas s'entendre, et donc vaut mieux arrêter là et répondre à d'autres demandes de client certainement plus intéressantes.
Et puis si je fonde mon activité sous le signe de la qualité, je n'ai pas intérêt à continuer avec ce genre de client, puisqu'alors je trahi mon engagement vis à vis ce que je propose comme prestation.
Et puis, peut être que le client va aller chez la concurrence, mais peut être aussi se rendra-t-il compte que son site n'est pas si top que ça, quand il verra le site de son pote ou de son concurrent s'afficher sans problème dans son iphone au contraire du sien, et pour peut-être pour un montant moindre...
>- tu refuse en disant que non c'est pas comme ça qu'il faut faire, et tu as un ou deux client par ans seulement. Résultats tu prend un autre job à côter pour bouffer.
Pour les mauvais professionnels, oui, c'est comme ça. Pour les bons, non, car ils ont compris ce qu'est le web, et arrive à faire comprendre à leur client ce qu'est le web.
>C'est chiant à faire : oui, mais c'est possible.
Non, c'est de la poudre au yeux. Je te ruine un design soit disant au pixel près quand tu veux.
>Et si tu pense qu'un professionel qui le fait est un mauvais professionel, et bien il doit pas y avoir beaucoup de bons professionels.
Bah oui, c'est ce que j'ai dit. Il n'y a pas beaucoup de bon professionnels en france, parce que peu veulent faire de la qualité, peu arrivent à faire comprendre (ou à faire vouloir comprendre) à leur client ce qu'est un site web de qualité, ce qu'est un vrai site web etc...
Si il n'y avait peu de mauvais professionnel, on serait pas à expliquer aux clients sans arret que le" pixel pret", c'est de l'utopie.
>Faut pas croire que le créateur de site aime faire ce genre de merdes, mais il n'a pas le choix.
On a toujours le choix. Faire de la merde. Ou pas.
> Si tu compare le Web de maintenant à celui d'il y a quelques année, au niveau du respect des standards ça à quand même évolué.
Ça je le reconnais. Et je me bats depuis plusieurs années pour que ça evolue justement. Ce ciombat porte ses fruits, mais manifestement, à la lecture de tes commentaires et d'autres, il faut continuer...
>Mais le marcher des petits écran par exemple est encore trop faible.
Ouai enfin, ça explose quand même hein. Tu es resté bloqué en 2003 ? :-)
> De même les gens qui changent la taille des polices représentent un très faible pourcentage du public.
Tu as des statistiques ? des vraies ? qu'en sais tu ?
Je dirais plutôt le contraire. Quand dans firefox on a changé la manière de zoomer, on a eu des plaintes (ou des remerciements) de toutes part. Preuve que le zoom est bien plus utilisé que tu le crois, mais alors bien plus.
Je ne suis pas handicapé visuellement (quoiqu'une legère myopie), mais ça m'arrive souvent de zoomer, parce que par exemple y a des webdesigners qui trouvent qu'une police de 6pt ça fait super top, que le design est à chier et qu'on voit mal le texte, ou parce que je veux voir les details sur une photo minuscule etc..
>Pour l'instant les client voient pas trop l'intéret de changer leur mode de fonctionement pour un public aussi marginal,
parce qu'ils sont justement mal renseigné, par des (mauvais) professionnels mal renseignés. Ce public dont tu parles est loin d'être marginal. Tout le monde est différent. Tout le monde ont des modes de consultations differents, des écrans differents, des navigateurs différents etc..
> Tu ne lui dit pas comment fabriquer la voiture car c'est son metier (enfin pas le siens mais celui de lamarque) mais tu lui dit à quoi tu veux qu'elle ressemble et ce que tu veux exactement qu'il y ait dedans.
Bah, oui comme pour un site web. Ton client te demande comment il veux que son site ressemble, et ce qu'il veut dedans. Mais c'est comme pour les bagnoles, y a des limites à tes désirs.
Va essayer de demander à avoir des roues ovales parce que tu trouves ça super chouette, ou plus realiste, d'avoir un pare-brise super foncé parce que tu veux pas qu'on te voit, le constructeur/concessionnaire va gentillement t'expliquer que c'est pas possible, à cause de contraintes techniques ou légales. Si il accepte, c'est que c'est un constructeur/concessionnaire verreux et tot ou tard tu te fera avoir (problème mécaniques pour les roues ovales ou accident/amendes à cause du pare brise foncé)
C'est pareil pour un site web HTML/CSS. Y a des contraintes techniques. L'une d'elle est que le design au pixel près est IMPOSSIBLE, parce que c'est pas fait pour. Si tu lui dit "oui oui je le fais", au mieux, tu es un mauvais professionnel parce que tu sais très bien qu'au fond de toi ça va être dur et que ça va de toute façon pas passer dans pas mal de cas. Et au pire, tu es un professionnel malhonnete parce que tu fais croire à ton client que c'est possible et qu'il n'y aura pas de problème, alors que c'est faux. Et du coup, il va croire que ceux qui lui disent que ce n'est pas possible sont des menteurs etc..
bref, des attitudes comme celle que tu décris pourri le milieu professionnel du web, et entretien la mauvaise qualité générale des sites web.
>Quand ton client gagne beaucoup d'argent sur Internet, il serait présomptueux de vouloir lui apprendre son travail.
Gni ?
Si il te demande de faire son site web, c'est que ce n'est pas son travail. Lui son travail, c'est de faire vivre le site (ou pas), point barre.
Et si il prétend savoir que le pixel pres c'est bien, ba désolé, c'est toujours pas son boulot, même si il prétend que ça l'est, parce que dans ce cas cela montre qu'il n'a absolument rien compris à internet.
Et toi, si tu continue à penser que c'est à ton client de te dicter les details techniques, de comment il faut faire son site web : change de metier.
Toi, quand tu va faire reviser ta bagnole, tu vas dire à ton garagiste ce qu'il faut qu'il fasse, et comment il faut qu'il le fasse ? Non hein. Au pire, tu lui indiques qu'il se pourrait qu'il y ait un problème ici ou là parce que tu entend un bruit bizarre, ou des conneries comme ça.
Ben là c'est pareil. C'est pas à ton client de t'expliquer de comment il faut faire ton métier. C'est à toi de lui expliquer les choses, de lui faire comprendre pourquoi tu fais comme ci et comme ça, point. Et ça, c'est vraiment faire preuve de professionnalisme.
Très honnetement, si tu ne sais pas te faire entendre/comprendre, encore une fois, change de métier.
>Et ouais, mais des fois, ya pas grand chose a lire, c'est juste une plaquette publicitaire.
Et ? une plaquette publicitaire peut très bien s'adapter à un contexte de consultation précis. Inutile de vouloir du pixel près sur chaque type de navigateur.
> Mais comment fait pdf pour garder un rendu identique sur toutes les machines du monde si c'est impossible?
Le format PDF impose des dimensions à la page, a des rêgles strictes de présentation. Et pour cause, il est destiné à l'impression !
Le web n'est pas destiné à l'impression. Le web est déstiné à pouvoir être lu dans n'importe quelle circonstance, quel que soit le type de navigateur, le type de périphérique de sortie etc. Bref, une page web a la faculté (si elle n'est pas faite comme on fait du print) de s'adapter à la majorité des circonstances.
Tu parles de pixel. Le pixel n'est qu'une unité. Une indication. Qui est vite convertie par le navigateur. Il suffit que l'utilisateur zoom d'un cran, et ton pixel, tu peux aller l'oublier. Ton pixel n'est plus un pixel. Tout simplement parce que c'est ça le web : pouvoir adapter et transformer une page web en fonction des conditions de lecture et des besoins.
Et c'est d'autant plus vrai que la diversité des modes de consultations explosent, à cause de la diversité des mobiles entre autre.
>Va expliquer ca a ceux qui font des applis web style webmail ou autre, que leurs boutons ne vont pas etre alignes comme ils le veulent et autres joyeusetes.
Si ça ne s'aligne pas comme ils veulent, c'est qu'ils utilisent mal les technos du web. Je n'ai personnellement aucun mal à faire un design, fluide, liquide, qui s'adapte à bon nombre de circonstance, sans avoir à faire des hacks dans tout les sens pour tel ou tel navigateur. Et l'une des raisons du pourquoi je n'ai aucun mal : c'est parce que j'ai accepté l'idée de ne pas avoir un design identique au pixel près dans tous les contextes. (je te jure, une fois qu'on accepte cette idée, tout devient plus simple, puisqu'on s'enlève des tonnes de contraintes inutiles)
Et si tu expliques bien à un client le pourquoi du comment (en gros, les arguments donnés dans le lien que j'ai donné plus haut), il acceptera certainement ce fait, et sera même probablement très content que son site passe sur un maximum de navigateur même si il n'est pas identique au pixel près.
Au passage, ne pas avoir un design identique au pixel près, ça ne veux pas forcément dire un design moche dans telle ou telle situation. Faut juste oublier les habitudes du "print" sur le web.
Et pour finir : très franchement, je n'ai jamais vu d'internaute ouvrir un site sur plusieurs navigateurs en même temps pour vérifier qu'il est identique au pixel prés dans chacun d'eux. L'internaute il en a rien à battre. L'internaute il veut juste que ce soit lisible.
> Donc non il n'y a pas de gain de debit, taille ou qualité a attendre de la part de theora. Theora est un codec somme toute médiocre dont le seul avantage est d'être totalement libre.
c'est probablement le cas aujourd'hui.
Mais il me semble, d'après la news, que le financement de Mozilla est déstiné justement à améliorer tout ça ;-)
> Attends, le monsieur dit qu'il veut que la page rende comme elle doit etre rendre sur tout les navigateurs, ca me semble etre LE precepte de base du web
Absolument pas ! Le web n'est pas un media figé. Donc le "pixel près" est absolument incompatible.
Le principal pour un site web c'est qu'il reste lisible et agréable à lire. Qu'il soit équivalent au pixel près d'un navigateur à un autre, est absolument inutile, et impossible.
Ton discours est digne des soit-disant "web designer" du siècle dernier.
La transition est toute faite : utiliser un element object comme on fait d'habitude, à l'interieur d'un element video. Le navigateur qui ne connait pas video "executera" l'element object, et celui qui connait la balise video, est censé ignoré le contenu de cet element.
<video src="mavideo.ogg">
<p class="avertissement">Pour profiter au maximum de la vidéo et des possibilités de cette page web, vous devriez installer un navigateur récent : Firefox 3.1, Safari, ou Opera.</p>
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash"></embed>
</object>
</video>
Pour en savoir plus http://ljouanneau.com/blog/post/2008/10/16/L-element-video
>ou de réaffecter une partie du personnel à la R&D.
hum... Dans le cas d'une entreprise automobile, j'aurai personnellement du mal à réaffecter tout ces ouvriers de la chaine de fabrication (actuellement les plus touchés par le chomage technique chez Renault) vers de la R&D...
C'est pas que je prend les ouvriers pour des abrutis. Mais pour la majorité d'entre eux, je ne pense pas qu'ils aient les bagages qu'il faut (connaissances, compétences...).
Et puis la R&D, ça coute. Et surtout ça ne rapporte rien directement et à court terme. Donc au niveau financement, c'est très très lourd.
M'enfin c'est toi qui voit. Y en a qui ont essayé. Ils ont eu des problèmes !
> <?=$variable?> marche bien en php, avec l'option "short_open_tag = On".
short_open_tag est deprecié il me semble. Ensuite, personnellement, je trouve que l'usage du <?(php) et ?> apporte de la confusion dans la lecture du source, avec les balises html.
Et globalement, tu tapes sur 3 touches de plus (ouai je chipote :-).
> Avec une coloration syntaxique c'est clair comme de l'eau de roche.
{$personnes|count} listée(s) :
{foreach $personnes as $p}
Nom : {$p->nom}, Age : {$p->age} ans
{/foreach}
avec ou SANS coloration syntaxique, ça reste clair comme de l'eau de roche.
;-)
enfin bon, là on en arrive à des question de gouts et de couleurs...
>Car au final, le mainteneur devra se familiariser avec tout un nouveau jargon, des nouveaux concepts et j'en passe,
Sauf si il connait déjà lesdits frameworks, moteur de templates et cie. Ce qui a de forte chance d'arriver si c'est un framework connu et pas mal utilisé dans l'industrie.
Alors que pour du "simple" code php (qui n'est jamais vraiment simple dès que le site devient conséquent), même clair, structuré et uniforme, bah c'est structuré différement à chaque projet, donc le développeur doit d'abord à chaque fois apprendre comment le site s'articule avant de pouvoir modifier le code metier à maintenir.
Donc, non, un développeur ne se "contente" jamais de maintenir un simple code PHP (sauf pour les sites de 3 pages).
Et le meilleur moyen d'avoir un code maintenable, c'est d'écrire du code selon des normes et des structures reconnus, c'est à dire, utiliser des frameworks, puisque tel est le but des framework: offrir une structuration (troll: ZF mise à part, puisque ZF n'impose pas de structure, et est plus une grosse lib dans laquelle on pioche qu'autre chose).
CQFD.
fais un tour en SSII, en demandant à bosser sur des missions courtes, de manière à travailler sur un maximum de projet, et là tu te rendra compte de l'intérêt des frameworks, et à coup sûr, tu pesteras sur les projets développé sans framework connu. Projets qui sont, forcément, vu que le boulot est toujours pour il y a deux jours, développé à l'arrache, donc souvent difficilement maintenable, alors que pour ceux avec un framework, les développeurs n'ont pas eu à passer du temps à réinventer la roue, et ont pu se concentrer rapidement sur le code métier, et ont donc un code naturellement plus structuré
bon, je dis pas non plus qu'il n'est pas possible de faire du super crad avec un framework, mais c'est déjà moins facile de faire du code crad avec un framework qui impose une structure que dans un projet sans framework.
Pour compléter à propos de jTpl (dont je suis l'auteur :-), j'ai essayé d'avoir les avantages à la fois des templates pur php, et d'un langage de template spécifique, à savoir :
* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}
* sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)
* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées".
il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.
Alors, ubitux trouve que c'est une abération que d'avoir des if/while dans un template, à ceci je lui repondrais :
1) il est lui même en contradiction avec ce qu'il dit, puisqu'il semble être pour utiliser PHP pour les templates, et donc ces templates peuvent contenir des if/while...
2) il y a des moteurs de templates qui obligent à faire les boucles en dehors du template, c'est à dire que dans le template lui même, on définit les "blocs" qui seront itérés, et en dehors du template, en php, on fait les boucles, et on appele des méthodes du moteur de template pour générer les blocs à chaque itération. Je trouve cela complètement ridicule, car dès lors que l'on veuille faire des modifications dans le template, il faut alors modifier en même temps le template ET le code php externe au template. Ce qui limite grandement les modifications, donc la personnalisation des templates
ex, dans le template original, on affiche une liste dans une seule colonne, donc une boucle, et dans notre nouveau theme, on veux que ce soit sur deux colonnes, donc deux boucles, ou alors une seule mais faudrait pouvoir ajouter un test à l'interieur pour savoir si on est arrivé au milieu de la liste pour créer la deuxieme colonne etc..
Avec ce genre de moteur de template, on est donc obligé de modifier le code PHP externe, donc le code de l'appli. Et puis cela veut dire aussi que la couche "vue" est scindée en deux "sous-couche", la logique de construction d'un coté (qui n'empèche pas de mélanger allègrement avec du code métier, ce qui est dommage), le code purement html de l'autre, ce qui n'est vraiment pas terrible, du point de vue de la maintenance et l'évolution.
Je préfère donc de loin, les moteurs de templates qui autorisent les instructions de contrôles if/foreach et cie.
Enfin, avoir une syntaxe un peu spécifique et controllée comme celle de jtpl permet d'une part, de faciliter l'écriture des templates par des webdesigners, mais aussi de permettre à l'application par exemple de proposer à un utilisateur d'uploader un template ou un thème sans compromettre la sécurité de l'application (jTpl a d'ailleurs un mode de fonctionnement avancé pour ce genre de template, apportant encore plus de sécurité)
J'oubliais aussi: comme Smarty, jTpl génère des fichiers PHP à partir des templates et les mets en cache, ce qui évite le parsing du template à chaque utilisation. Donc point de vue performance, la différence est vraiment insignifiante par rapport à un template pure php (il y a en gros un file_exists pour vérifier l'existance du cache, et un simple include du cache).
Autre avantage de jTpl par rapport à smarty : 320 lignes de codes pour le moteur + 520 pour le "compilateur" (non chargée si le cache est ok), commentaires compris, contre plus de 1900+2800 pour smarty ... Les caches d'opcodes apprecieront... (pour un nombre de fonctionnalité à peu près équivalent, quelques features bloatware en moins dans jtpl)
Je connais un site vraiment sympa, qui permet de traduire les extensions XUL (pour firefox ou d'autres logiciels en XUL) : http://babelzilla.org/
Pour traduire, c'est très simple, suffit de s'inscrire et il y a une interface très simple pour traduire toutes les chaînes d'une extension. En gros, un simple formulaire avec un champs pour chaque chaîne. Bref, ça requiert des connaissances techniques peu poussées.
>Et pourquoi en python on ne pourrait pas réindenter avec un éditeur comme c'est fait pour c, java, etc ?
Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un bloc. Donc du coup, un "beautifier" de code serait infoutu de reindenter proprement du code python. Il pourrait tout de même se débrouiller avec la reconnaissance de certains mot clé. ex : tout ce qui se trouve entre deux mots clé def fait forcément partie du def (bon, mes connaissances rudimentaires en python ne me permettent pas de savoir si cette affirmation est vrai, mais tu vois le genre quoi).
le commentaire auquel je répondais ne faisait pas allusion au fait de respecter la licence ou non. mais au fait qu'il y ait des addons proprio et un soft libre.
l'objet de la discussion c'est justement : comment faire de l'argent tout en faisant du libre.
Bref un peu hors sujet ton propos à mon avis, et ne repond pas du tout à ma question...
Non, ils ne sont pas l'auteur de tout le code, et loin de là : c'est une application reposant sur xulrunner, de Mozilla ;-) (interface en XUL/js/CSS, système d'extension de firefox etc..). Sans compter gstreamer, vlc et cie.
Bref, en volume de ligne de code, la part de songbird est petite ;-)
mais ça n'enlève rien au mérite d'avoir développer cette appli, que je trouve bien foutue et beaucoup moins bordélique qu'amarok par ex (je trouve horrible l'interface d'amarok d'un point de vue design, mais aussi ergonomique)
je ne vois pas en quoi c'est une drôle de philosophie.
Si les addons ne te plaisent pas, même d'un point de vue licence, rien ne t'oblige à les utiliser. Et d'un autre coté, le logiciel principal est en GPL, donc libre à quiconque de l'améliorer, de proposer des addons libres etc...
Et ce principe d'addons propriétaire (donc souvent payant) permet de financer le développement du projet. Surtout pour ce type de projet où, coté service, il n'y a pas vraiment de marché... (enfin là, je vois pas...)
À moins que tu ais une bonne idée pour que les développeurs (à plein temps) puisse être payé ? (autrement que par des injections d'argent frais donné par des investisseurs, qui eux attendent quand même un retour sur investissement, et sachant que cet argent ne va pas être donné indéfiniment)
Sérieusement, je suis très intéresse par des solutions pour gagner de l'argent autrement que par des investisseurs et que par du service (qui n'est pas valable pour tout les types de projets). Et bien sûr, par gagner de l'argent, j'entend avoir un vrai salaire (pas les 3 sous que pourrait rapporter la vente de goodies par ex). Et bien sûr (bis), pas dans le monde des bisounours, mais dans la vrai vie, dans notre système économique actuel, et si possible dans le contexte économique et financier actuel.
Pour qu'un virus/autre merde s'exécute sur linux, il faut que l'exécutable (ou script..) ait les droits d'exécution. Or il me semble que ce n'est pas le cas par défaut quand on tente d'ouvrir une piece jointe dans un mail, ou qu'on la sauvegarde sur le disque etc, etc.. Par contre sous windows, si je me trompe toujours pas, si il voit l'extension .exe, il l'executera, il n'y a pas de droits d'exécution...
Bref, sous linux, ça limite quand même les risques de propogations/executions des cochonneries. Bon après, comme il est dit dans le journal, c'est bien souvent l'interface chaise-clavier qui est le problème, et les imbéciles qui forceront l'exécution de ces fichiers ne pourront s'en prendre qu'à eux même.
>outils capables de convertir une base d'un wiki vers un autre
Pour convertir une base entière, je ne sais pas, mais d'une syntaxe à une autre, <pub>j'ai ce qu'il faut : wikirenderer (http://wikirenderer.berlios.de )</pub>
C'est un convertisseur de syntaxe wiki en ce que vous voulez : texte "brut" (sans syntaxe wiki), XHTML, docbook et ou bien sûr une autre syntaxe wiki. Pour cela, il se base sur un ensemble de classes que j'appelles des "rêgles", et qu'il faut développer. Le coeur de wikirenderer s'occupant de parser le contenu et d'effectuer la transformation. Son point fort aussi : il detecte les erreurs de syntaxe, et empèche de générer du contenu invalide par exemple en xhtml. ex, avec une erreur de syntaxe croisée : **bla bla //sdsd**qmlmqsd// . Le code ici est faux, il ne génèrera pas <strong>bla bla<em>sdsd</strong>qmlmqsd</em>, qui est invalide..
Par défaut il supporte une syntaxe bien à lui qu'il converti en XHTML. Mais je l'ai déjà utilisé pour transformer d'une syntaxe à une autre. Par exemple, pour transformer une syntaxe de la V2 à la V3 de wikirenderer. Ou encore du dokuwiki vers docbook (que j'utilise sur le wiki de jelix.org pour générer la version PDF des manuels stockés dans le wiki). Et la je suis en train de faire des rêgles pour transformer l'horrible syntaxe wiki de Trac vers du dokuwiki like (dans le cadre justement d'un export de données).
Le développement des rêgles n'est pas toujours très aisé, c'est pourquoi je vais essayer d'en fournir un maximum dans la version 3.1 à venir (si il y a des volontaires parmis vous... ;-) )
Si on a la rêgle qu'on veut, c'est très très simple à utiliser par contre, et il ne reste alors plus que faire un petit script qui parcourerait une table sql pour mettre à jour les champs wiki.. (ce qui est trivial à faire)
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
>Sauf que les roues ovales, si un concurent les propose je peut aller les acheter chez lui, et si je veux de roues ovales je vais pas aller acheter une voiture qui a des roues rondes ou carrée.
je serais curieux de savoir quel constructeur automobile accepterai de vendre des roues ovales. Très franchement ;-)
> Le problème c'est si tu dis au mec je peut pas faire un design au pixel près et que ton concurent le fais, eh bien il va aller chez le concurent.
Non, parce que je lui aurais fait (ou tenter) comprendre le pourquoi de la chose. Et si après ça, il comprend toujours pas, ben alors tant pis. C'est signe que de toute façon, lui et moi on va pas s'entendre, et donc vaut mieux arrêter là et répondre à d'autres demandes de client certainement plus intéressantes.
Et puis si je fonde mon activité sous le signe de la qualité, je n'ai pas intérêt à continuer avec ce genre de client, puisqu'alors je trahi mon engagement vis à vis ce que je propose comme prestation.
Et puis, peut être que le client va aller chez la concurrence, mais peut être aussi se rendra-t-il compte que son site n'est pas si top que ça, quand il verra le site de son pote ou de son concurrent s'afficher sans problème dans son iphone au contraire du sien, et pour peut-être pour un montant moindre...
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 2.
Pour les mauvais professionnels, oui, c'est comme ça. Pour les bons, non, car ils ont compris ce qu'est le web, et arrive à faire comprendre à leur client ce qu'est le web.
>C'est chiant à faire : oui, mais c'est possible.
Non, c'est de la poudre au yeux. Je te ruine un design soit disant au pixel près quand tu veux.
>Et si tu pense qu'un professionel qui le fait est un mauvais professionel, et bien il doit pas y avoir beaucoup de bons professionels.
Bah oui, c'est ce que j'ai dit. Il n'y a pas beaucoup de bon professionnels en france, parce que peu veulent faire de la qualité, peu arrivent à faire comprendre (ou à faire vouloir comprendre) à leur client ce qu'est un site web de qualité, ce qu'est un vrai site web etc...
Si il n'y avait peu de mauvais professionnel, on serait pas à expliquer aux clients sans arret que le" pixel pret", c'est de l'utopie.
>Faut pas croire que le créateur de site aime faire ce genre de merdes, mais il n'a pas le choix.
On a toujours le choix. Faire de la merde. Ou pas.
> Si tu compare le Web de maintenant à celui d'il y a quelques année, au niveau du respect des standards ça à quand même évolué.
Ça je le reconnais. Et je me bats depuis plusieurs années pour que ça evolue justement. Ce ciombat porte ses fruits, mais manifestement, à la lecture de tes commentaires et d'autres, il faut continuer...
>Mais le marcher des petits écran par exemple est encore trop faible.
Ouai enfin, ça explose quand même hein. Tu es resté bloqué en 2003 ? :-)
> De même les gens qui changent la taille des polices représentent un très faible pourcentage du public.
Tu as des statistiques ? des vraies ? qu'en sais tu ?
Je dirais plutôt le contraire. Quand dans firefox on a changé la manière de zoomer, on a eu des plaintes (ou des remerciements) de toutes part. Preuve que le zoom est bien plus utilisé que tu le crois, mais alors bien plus.
Je ne suis pas handicapé visuellement (quoiqu'une legère myopie), mais ça m'arrive souvent de zoomer, parce que par exemple y a des webdesigners qui trouvent qu'une police de 6pt ça fait super top, que le design est à chier et qu'on voit mal le texte, ou parce que je veux voir les details sur une photo minuscule etc..
>Pour l'instant les client voient pas trop l'intéret de changer leur mode de fonctionement pour un public aussi marginal,
parce qu'ils sont justement mal renseigné, par des (mauvais) professionnels mal renseignés. Ce public dont tu parles est loin d'être marginal. Tout le monde est différent. Tout le monde ont des modes de consultations differents, des écrans differents, des navigateurs différents etc..
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
Bah, oui comme pour un site web. Ton client te demande comment il veux que son site ressemble, et ce qu'il veut dedans. Mais c'est comme pour les bagnoles, y a des limites à tes désirs.
Va essayer de demander à avoir des roues ovales parce que tu trouves ça super chouette, ou plus realiste, d'avoir un pare-brise super foncé parce que tu veux pas qu'on te voit, le constructeur/concessionnaire va gentillement t'expliquer que c'est pas possible, à cause de contraintes techniques ou légales. Si il accepte, c'est que c'est un constructeur/concessionnaire verreux et tot ou tard tu te fera avoir (problème mécaniques pour les roues ovales ou accident/amendes à cause du pare brise foncé)
C'est pareil pour un site web HTML/CSS. Y a des contraintes techniques. L'une d'elle est que le design au pixel près est IMPOSSIBLE, parce que c'est pas fait pour. Si tu lui dit "oui oui je le fais", au mieux, tu es un mauvais professionnel parce que tu sais très bien qu'au fond de toi ça va être dur et que ça va de toute façon pas passer dans pas mal de cas. Et au pire, tu es un professionnel malhonnete parce que tu fais croire à ton client que c'est possible et qu'il n'y aura pas de problème, alors que c'est faux. Et du coup, il va croire que ceux qui lui disent que ce n'est pas possible sont des menteurs etc..
bref, des attitudes comme celle que tu décris pourri le milieu professionnel du web, et entretien la mauvaise qualité générale des sites web.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 4.
Gni ?
Si il te demande de faire son site web, c'est que ce n'est pas son travail. Lui son travail, c'est de faire vivre le site (ou pas), point barre.
Et si il prétend savoir que le pixel pres c'est bien, ba désolé, c'est toujours pas son boulot, même si il prétend que ça l'est, parce que dans ce cas cela montre qu'il n'a absolument rien compris à internet.
Et toi, si tu continue à penser que c'est à ton client de te dicter les details techniques, de comment il faut faire son site web : change de metier.
Toi, quand tu va faire reviser ta bagnole, tu vas dire à ton garagiste ce qu'il faut qu'il fasse, et comment il faut qu'il le fasse ? Non hein. Au pire, tu lui indiques qu'il se pourrait qu'il y ait un problème ici ou là parce que tu entend un bruit bizarre, ou des conneries comme ça.
Ben là c'est pareil. C'est pas à ton client de t'expliquer de comment il faut faire ton métier. C'est à toi de lui expliquer les choses, de lui faire comprendre pourquoi tu fais comme ci et comme ça, point. Et ça, c'est vraiment faire preuve de professionnalisme.
Très honnetement, si tu ne sais pas te faire entendre/comprendre, encore une fois, change de métier.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 10.
Et ? une plaquette publicitaire peut très bien s'adapter à un contexte de consultation précis. Inutile de vouloir du pixel près sur chaque type de navigateur.
> Mais comment fait pdf pour garder un rendu identique sur toutes les machines du monde si c'est impossible?
Le format PDF impose des dimensions à la page, a des rêgles strictes de présentation. Et pour cause, il est destiné à l'impression !
Le web n'est pas destiné à l'impression. Le web est déstiné à pouvoir être lu dans n'importe quelle circonstance, quel que soit le type de navigateur, le type de périphérique de sortie etc. Bref, une page web a la faculté (si elle n'est pas faite comme on fait du print) de s'adapter à la majorité des circonstances.
Tu parles de pixel. Le pixel n'est qu'une unité. Une indication. Qui est vite convertie par le navigateur. Il suffit que l'utilisateur zoom d'un cran, et ton pixel, tu peux aller l'oublier. Ton pixel n'est plus un pixel. Tout simplement parce que c'est ça le web : pouvoir adapter et transformer une page web en fonction des conditions de lecture et des besoins.
Et c'est d'autant plus vrai que la diversité des modes de consultations explosent, à cause de la diversité des mobiles entre autre.
>Va expliquer ca a ceux qui font des applis web style webmail ou autre, que leurs boutons ne vont pas etre alignes comme ils le veulent et autres joyeusetes.
Si ça ne s'aligne pas comme ils veulent, c'est qu'ils utilisent mal les technos du web. Je n'ai personnellement aucun mal à faire un design, fluide, liquide, qui s'adapte à bon nombre de circonstance, sans avoir à faire des hacks dans tout les sens pour tel ou tel navigateur. Et l'une des raisons du pourquoi je n'ai aucun mal : c'est parce que j'ai accepté l'idée de ne pas avoir un design identique au pixel près dans tous les contextes. (je te jure, une fois qu'on accepte cette idée, tout devient plus simple, puisqu'on s'enlève des tonnes de contraintes inutiles)
Et si tu expliques bien à un client le pourquoi du comment (en gros, les arguments donnés dans le lien que j'ai donné plus haut), il acceptera certainement ce fait, et sera même probablement très content que son site passe sur un maximum de navigateur même si il n'est pas identique au pixel près.
Au passage, ne pas avoir un design identique au pixel près, ça ne veux pas forcément dire un design moche dans telle ou telle situation. Faut juste oublier les habitudes du "print" sur le web.
Et pour finir : très franchement, je n'ai jamais vu d'internaute ouvrir un site sur plusieurs navigateurs en même temps pour vérifier qu'il est identique au pixel prés dans chacun d'eux. L'internaute il en a rien à battre. L'internaute il veut juste que ce soit lisible.
[^] # Re: Youtube
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
c'est probablement le cas aujourd'hui.
Mais il me semble, d'après la news, que le financement de Mozilla est déstiné justement à améliorer tout ça ;-)
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 4.
Absolument pas ! Le web n'est pas un media figé. Donc le "pixel près" est absolument incompatible.
Le principal pour un site web c'est qu'il reste lisible et agréable à lire. Qu'il soit équivalent au pixel près d'un navigateur à un autre, est absolument inutile, et impossible.
Ton discours est digne des soit-disant "web designer" du siècle dernier.
Aller, hop, une petite lecture pour que tu ais une autre vision, plus réèlle, du web : http://www.pompage.net/pompe/tao/
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 1.
[^] # Re: Transition
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal 100 000 dollars pour Theora/Vorbis !. Évalué à 9.
<video src="mavideo.ogg">
<p class="avertissement">Pour profiter au maximum de la vidéo et des possibilités de cette page web, vous devriez installer un navigateur récent : Firefox 3.1, Safari, ou Opera.</p>
<object>
<param name="movie" value="flvplayer.swf?file=mavideo.flv"></param>
<embed src="flvplayer.swf?file=mavideo.flv" type="application/x-shockwave-flash"></embed>
</object>
</video>
Pour en savoir plus http://ljouanneau.com/blog/post/2008/10/16/L-element-video
[^] # Re: c'est beau le capitalisme
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal MS va supprimer 5000 postes. Évalué à 1.
hum... Dans le cas d'une entreprise automobile, j'aurai personnellement du mal à réaffecter tout ces ouvriers de la chaine de fabrication (actuellement les plus touchés par le chomage technique chez Renault) vers de la R&D...
C'est pas que je prend les ouvriers pour des abrutis. Mais pour la majorité d'entre eux, je ne pense pas qu'ils aient les bagages qu'il faut (connaissances, compétences...).
Et puis la R&D, ça coute. Et surtout ça ne rapporte rien directement et à court terme. Donc au niveau financement, c'est très très lourd.
M'enfin c'est toi qui voit. Y en a qui ont essayé. Ils ont eu des problèmes !
# le titre
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Carrefour et les licences liées. Évalué à 6.
"vente liée" par contre, ça correspond plus au sujet de ton journal ;-)
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 1.
short_open_tag est deprecié il me semble. Ensuite, personnellement, je trouve que l'usage du <?(php) et ?> apporte de la confusion dans la lecture du source, avec les balises html.
Et globalement, tu tapes sur 3 touches de plus (ouai je chipote :-).
> Avec une coloration syntaxique c'est clair comme de l'eau de roche.
{$personnes|count} listée(s) :
{foreach $personnes as $p}
Nom : {$p->nom}, Age : {$p->age} ans
{/foreach}
avec ou SANS coloration syntaxique, ça reste clair comme de l'eau de roche.
;-)
enfin bon, là on en arrive à des question de gouts et de couleurs...
[^] # Re: Keep It Simple, Stupid
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 1.
Sauf si il connait déjà lesdits frameworks, moteur de templates et cie. Ce qui a de forte chance d'arriver si c'est un framework connu et pas mal utilisé dans l'industrie.
Alors que pour du "simple" code php (qui n'est jamais vraiment simple dès que le site devient conséquent), même clair, structuré et uniforme, bah c'est structuré différement à chaque projet, donc le développeur doit d'abord à chaque fois apprendre comment le site s'articule avant de pouvoir modifier le code metier à maintenir.
Donc, non, un développeur ne se "contente" jamais de maintenir un simple code PHP (sauf pour les sites de 3 pages).
Et le meilleur moyen d'avoir un code maintenable, c'est d'écrire du code selon des normes et des structures reconnus, c'est à dire, utiliser des frameworks, puisque tel est le but des framework: offrir une structuration (troll: ZF mise à part, puisque ZF n'impose pas de structure, et est plus une grosse lib dans laquelle on pioche qu'autre chose).
CQFD.
fais un tour en SSII, en demandant à bosser sur des missions courtes, de manière à travailler sur un maximum de projet, et là tu te rendra compte de l'intérêt des frameworks, et à coup sûr, tu pesteras sur les projets développé sans framework connu. Projets qui sont, forcément, vu que le boulot est toujours pour il y a deux jours, développé à l'arrache, donc souvent difficilement maintenable, alors que pour ceux avec un framework, les développeurs n'ont pas eu à passer du temps à réinventer la roue, et ont pu se concentrer rapidement sur le code métier, et ont donc un code naturellement plus structuré
bon, je dis pas non plus qu'il n'est pas possible de faire du super crad avec un framework, mais c'est déjà moins facile de faire du code crad avec un framework qui impose une structure que dans un projet sans framework.
# Note
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal LinuxFR en rails ?. Évalué à 10.
- vote pour l'achat de 2 serveurs supplémentaires afin de répondre aux exigences du nouveau site en matière de tenu en charge.
(Hein ? comment ça on n'est pas vendredi ? ->[])
[^] # Re: Un moteur de templates est très utile
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal De l'utilité des moteurs de templates en PHP. Évalué à 2.
* faciliter l'écriture. par exemple, remplacer les "<?php echo $variable?>" par une syntaxe plus simple comme {$variable}
* sans toutefois ne pas avoir à reinventer totalement un langage, c'est pourquoi les expressions utilisées sont en php. ex: {$variable.$objet->propriete} qui est équivalent à...<?php echo $variable.$objet->propriete?> tout simplement :-)
* mais en posant des restrictions, pour éviter d'avoir du code métier dans les templates, c'est pourquoi les expressions sont parsées (en utilisant le tokenizer de php ;-) et "filtrées".
il y a des tags typiques comme {foreach}, {for}, {if} et cie, fonctionnant comme en php.
Alors, ubitux trouve que c'est une abération que d'avoir des if/while dans un template, à ceci je lui repondrais :
1) il est lui même en contradiction avec ce qu'il dit, puisqu'il semble être pour utiliser PHP pour les templates, et donc ces templates peuvent contenir des if/while...
2) il y a des moteurs de templates qui obligent à faire les boucles en dehors du template, c'est à dire que dans le template lui même, on définit les "blocs" qui seront itérés, et en dehors du template, en php, on fait les boucles, et on appele des méthodes du moteur de template pour générer les blocs à chaque itération. Je trouve cela complètement ridicule, car dès lors que l'on veuille faire des modifications dans le template, il faut alors modifier en même temps le template ET le code php externe au template. Ce qui limite grandement les modifications, donc la personnalisation des templates
ex, dans le template original, on affiche une liste dans une seule colonne, donc une boucle, et dans notre nouveau theme, on veux que ce soit sur deux colonnes, donc deux boucles, ou alors une seule mais faudrait pouvoir ajouter un test à l'interieur pour savoir si on est arrivé au milieu de la liste pour créer la deuxieme colonne etc..
Avec ce genre de moteur de template, on est donc obligé de modifier le code PHP externe, donc le code de l'appli. Et puis cela veut dire aussi que la couche "vue" est scindée en deux "sous-couche", la logique de construction d'un coté (qui n'empèche pas de mélanger allègrement avec du code métier, ce qui est dommage), le code purement html de l'autre, ce qui n'est vraiment pas terrible, du point de vue de la maintenance et l'évolution.
Je préfère donc de loin, les moteurs de templates qui autorisent les instructions de contrôles if/foreach et cie.
Enfin, avoir une syntaxe un peu spécifique et controllée comme celle de jtpl permet d'une part, de faciliter l'écriture des templates par des webdesigners, mais aussi de permettre à l'application par exemple de proposer à un utilisateur d'uploader un template ou un thème sans compromettre la sécurité de l'application (jTpl a d'ailleurs un mode de fonctionnement avancé pour ce genre de template, apportant encore plus de sécurité)
J'oubliais aussi: comme Smarty, jTpl génère des fichiers PHP à partir des templates et les mets en cache, ce qui évite le parsing du template à chaque utilisation. Donc point de vue performance, la différence est vraiment insignifiante par rapport à un template pure php (il y a en gros un file_exists pour vérifier l'existance du cache, et un simple include du cache).
Autre avantage de jTpl par rapport à smarty : 320 lignes de codes pour le moteur + 520 pour le "compilateur" (non chargée si le cache est ok), commentaires compris, contre plus de 1900+2800 pour smarty ... Les caches d'opcodes apprecieront... (pour un nombre de fonctionnalité à peu près équivalent, quelques features bloatware en moins dans jtpl)
http://jelix.org/articles/fr/manuel-1.1/templates
Teasing: la version 1.0 de jTpl standalone sort très bientôt
# BabelZilla
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Méthodo localisation / Actu Mandriva. Évalué à 2.
Pour traduire, c'est très simple, suffit de s'inscrire et il y a une interface très simple pour traduire toutes les chaînes d'une extension. En gros, un simple formulaire avec un champs pour chaque chaîne. Bref, ça requiert des connaissances techniques peu poussées.
http://www.babelzilla.org/content/view/1/1/
[^] # Re: Gasp ...
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal N'installez pas PHP 5.2.7 !. Évalué à 5.
[^] # Re: Perso
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal EyeOS 1.7.0. Évalué à 4.
Hein ? ah oui mince, cette génèse n'est pas de Dieu... Désolé...
[^] # Re: la vraie nouveauté
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Python 3000 est sorti. Évalué à 3.
Parce qu'il n'y a rien dans la syntaxe python pour déterminer explicitement le début et la fin d'un bloc. Donc du coup, un "beautifier" de code serait infoutu de reindenter proprement du code python. Il pourrait tout de même se débrouiller avec la reconnaissance de certains mot clé. ex : tout ce qui se trouve entre deux mots clé def fait forcément partie du def (bon, mes connaissances rudimentaires en python ne me permettent pas de savoir si cette affirmation est vrai, mais tu vois le genre quoi).
[^] # Re: Philosophie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird et la GPL. Évalué à 1.
[^] # Re: Philosophie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird et la GPL. Évalué à 1.
l'objet de la discussion c'est justement : comment faire de l'argent tout en faisant du libre.
Bref un peu hors sujet ton propos à mon avis, et ne repond pas du tout à ma question...
[^] # Re: exceptions de la GPL
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird et la GPL. Évalué à 1.
Bref, en volume de ligne de code, la part de songbird est petite ;-)
mais ça n'enlève rien au mérite d'avoir développer cette appli, que je trouve bien foutue et beaucoup moins bordélique qu'amarok par ex (je trouve horrible l'interface d'amarok d'un point de vue design, mais aussi ergonomique)
[^] # Re: Philosophie
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal SongBird et la GPL. Évalué à 1.
Si les addons ne te plaisent pas, même d'un point de vue licence, rien ne t'oblige à les utiliser. Et d'un autre coté, le logiciel principal est en GPL, donc libre à quiconque de l'améliorer, de proposer des addons libres etc...
Et ce principe d'addons propriétaire (donc souvent payant) permet de financer le développement du projet. Surtout pour ce type de projet où, coté service, il n'y a pas vraiment de marché... (enfin là, je vois pas...)
À moins que tu ais une bonne idée pour que les développeurs (à plein temps) puisse être payé ? (autrement que par des injections d'argent frais donné par des investisseurs, qui eux attendent quand même un retour sur investissement, et sachant que cet argent ne va pas être donné indéfiniment)
Sérieusement, je suis très intéresse par des solutions pour gagner de l'argent autrement que par des investisseurs et que par du service (qui n'est pas valable pour tout les types de projets). Et bien sûr, par gagner de l'argent, j'entend avoir un vrai salaire (pas les 3 sous que pourrait rapporter la vente de goodies par ex). Et bien sûr (bis), pas dans le monde des bisounours, mais dans la vrai vie, dans notre système économique actuel, et si possible dans le contexte économique et financier actuel.
[^] # Re: /!\ DÉFENSE DE NOURRIR LE TROLL /!\
Posté par Laurent J (site web personnel, Mastodon) . En réponse au journal Maintenant sous MacOS, bientôt sous Linux. Évalué à 7.
Bref, sous linux, ça limite quand même les risques de propogations/executions des cochonneries. Bon après, comme il est dit dans le journal, c'est bien souvent l'interface chaise-clavier qui est le problème, et les imbéciles qui forceront l'exécution de ces fichiers ne pourront s'en prendre qu'à eux même.
[^] # Re: Convertir les données
Posté par Laurent J (site web personnel, Mastodon) . En réponse à la dépêche MindTouch Deki, une plate-forme collaborative. Évalué à 8.
Pour convertir une base entière, je ne sais pas, mais d'une syntaxe à une autre, <pub>j'ai ce qu'il faut : wikirenderer (http://wikirenderer.berlios.de )</pub>
C'est un convertisseur de syntaxe wiki en ce que vous voulez : texte "brut" (sans syntaxe wiki), XHTML, docbook et ou bien sûr une autre syntaxe wiki. Pour cela, il se base sur un ensemble de classes que j'appelles des "rêgles", et qu'il faut développer. Le coeur de wikirenderer s'occupant de parser le contenu et d'effectuer la transformation. Son point fort aussi : il detecte les erreurs de syntaxe, et empèche de générer du contenu invalide par exemple en xhtml. ex, avec une erreur de syntaxe croisée : **bla bla //sdsd**qmlmqsd// . Le code ici est faux, il ne génèrera pas <strong>bla bla<em>sdsd</strong>qmlmqsd</em>, qui est invalide..
Par défaut il supporte une syntaxe bien à lui qu'il converti en XHTML. Mais je l'ai déjà utilisé pour transformer d'une syntaxe à une autre. Par exemple, pour transformer une syntaxe de la V2 à la V3 de wikirenderer. Ou encore du dokuwiki vers docbook (que j'utilise sur le wiki de jelix.org pour générer la version PDF des manuels stockés dans le wiki). Et la je suis en train de faire des rêgles pour transformer l'horrible syntaxe wiki de Trac vers du dokuwiki like (dans le cadre justement d'un export de données).
Le développement des rêgles n'est pas toujours très aisé, c'est pourquoi je vais essayer d'en fournir un maximum dans la version 3.1 à venir (si il y a des volontaires parmis vous... ;-) )
Si on a la rêgle qu'on veut, c'est très très simple à utiliser par contre, et il ne reste alors plus que faire un petit script qui parcourerait une table sql pour mettre à jour les champs wiki.. (ce qui est trivial à faire)