isildur37 a écrit 122 commentaires

Bon résumé d'un "bon site" : rapide, compréhensible, ergonomique.
Les boites comment à revenir sur des sites plus simple pour une raison bête : les smartphones et tablettes. Ceux-ci ont généralement une connexion limitée, et les gens veulent de l'efficacité.
Et des sites qui mettent moins de 10s pour se charger sur un mobile, je n'en connais pas beaucoup. La cause souvent à des images envoyées depuis le serveur, et aux pubs (nécessaires bien souvent pour financer les sites).

Encore une fois, les bonnes pratiques risquent de s'imposer non pas parce qu'elles sont bonnes, mais parce qu'elles sont indispensables pour attirer les client.

C'est l'argument le plus pertinent que j'ai vu aujourd'hui, et là y'a un vrai problème, car les personnes ne s'excluent pas par choix(désactivation du JS pour une raison X ou Y), mais sont exclues par la technologie. La question d'une utilisation pertinente du JS est ici fondamentale.
En général, le JS permet d'ajouter une dynamique, et n'influe pas sur un contenu texte (ou alors, il le récupère et l'affiche dans une balise), le laissant tout à fait lisible par les liseuses.

Il y a des boites qui justement utilisent le JS pour leur rendre accessible le contenu aux malvoyants, couplé avec le CSS pour recréer la structure du texte. Je ne sais pas ce que ça donne, mais ça avait l'air prometteur il y a quelques années.

Effectivement, je ne connaissais pas cette fonctionnalité. Bon, tant qu'on est sur du texte, ça passe. Mais dès qu'on est sur des choses plus complexes (graphique, images), ça devient plus compliqué et lourd (dimensionnement des serveurs pour générer les images, chargement systématique des images pour ceux qui utilisent le JS, …).
Pour ma part, JS fait parti du pack que l'on doit avoir lorsque l'on va sur un site web. Venir sans c'est comme exiger d'avoir une version du site en HTML1 ou HTML2. L'usage qui en est fait parfois est critiquable (rendre des balises ), néanmoins, dès que l'on veut du dynamisme, de l'animation, c'est un outil indispensable.

Enfin, la tendance actuelle tend à considérer le navigateur web comme une machine virtuelle et non plus seulement comme un afficheur. Les "sites" entièrement en JS côté client se multiplient, où c'est le client qui décide quand il va chercher les infos, et lesquelles, comment et où les afficher. Je suis plutôt d'accord avec le fait que ce ne soit plus vraiment un "site", mais une "appli". D'autant plus que ces applis ont un rendu qui est calculé par le code js, et non plus défini statiquement par le serveur. Les gains sont multiples : forte scalabilité (navigation stateless), charge plus faible côté serveur, forte interactivité, au prix d'une consommation de ressources plus élevée côté client.

Et tout le monde hurlait parce que Flash était utilisé massivement. Oui, parce que le public attend un truc "joli". La technique derrière, Mme Michu se fout que ça soit en JS, CSS, ou pure HTML. Et ceux qui commandent des sites web ne veulent plus du site qui a 10 ans. C'est un cercle, à chacun de déterminer s'il est vertueux ou vicieux.
J'aimerai que vous me montriez un proto de site sans JS qui marche aussi bien sur mon smartphone que sur mon écran 23" (et bientôt sur la TV). Et ne me sortez pas qu'il faut faire 3 sites, car pour déterminer le type d'écran, il faudrait de toute façon utiliser du JS…

Ce n'est pas le plus gros souci : l’implémentation CSS2 n'est même pas encore finalisée dans les navigateurs. Et on ajoute CSS3 et HTML5, qui ont une complexité d’implémentation nettement supérieure…
Donc, le temps de standardisation, même s'il fait tâche, n'est pas le plus problématique. Avant que l'on ait quelque chose d'exploitable avec ces technos, sans trucage, compatible sur les principaux navigateurs, on a quelques années devant nous.

Le JS s’exécute à peu près partout de la même manière. On ne peut pas en dire autant de HTML, ou, encore pire de CSS. JS fournit donc bien souvent une solution simple à cet enfer qu'est l'interopérabilité entre les implémentations des standards web.
On n'est pas responsable des personnes qui utilisent IE (par choix personnel, obligation pro, ou même par défaut). Et aucun industriel ne peut se permettre de se passer de 50% des utilisateurs mondiaux. Or, il faut le prendre en compte lorsque l'on code un site pro.

Sur le fond je suis d'accord : pour afficher 3 liens, on ne devrait pas avoir besoin de JS. Mais avec le contexte actuel, c'est irréalisable : hélas, la moindre propriété avancée en CSS3/HTML un peu récente est bien implémentée dans Chrome et Opéra, moins bien dans Firefox, et pas du tout dans IE. Et je ne parle même pas dans des navigateurs tels que lynx, Konkeror et autres joyeusetés…

Enfin, aujourd'hui vous devez en plus gérer du mobile : redimensionnement dynamique en fonction de la taille d'écran, ce qui vous rajoute grosso modo 3 navigateurs supplémentaires à gérer. Et là, sans JS c'est tout simplement impensable…

Je ne suis pas formateur. Je suis dev et je reporte ce que j'ai pu voir (et, parfois dû maintenir et débugger). Quand je cite l'AFPA, c'est parce que j'ai vu le code des devs qui venaient de là bas : fichiers php de 20 Mo, aucune notion de conception objet, php qui "echo" du js au lieu de le mettre proprement dans un fichier séparé. Bref, capable de coder, mais sans aucune connaissance des bonnes pratiques.
Au contraire, je suis pour l'autodidacte (une grande partie de mes connaissances techniques en provient). J'ai appris la guitare également comme cela, et en quelques cours, le prof a corrigé bon nombre de mauvaises pratiques que j'avais adoptées.
Le seul problème c'est qu'il ne faut pas se faire passer pour formateur sans que les connaissances acquises aient été un minimum validées par quelqu'un de reconnu du domaine (expert, formateur, …). Et encore moins vendre des formations là dessus. Où alors au minimum y apporter les réserves indispensables.
Quand je vois des formateur web qui ne savent pas ce qu'est le W3C, j'ai le droit d'avoir quelques doutes sur leurs compétences. Dont bien sûr aucun de leurs sites ne passent aucun des tests W3C…

Les formations dignes de ce nom ne forment pas à ce que vous dîtes.
L'ergo et la SEO sont au contraire au coeur des problématiques auxquelles sont sensibilisés les étudiants. Mais c'est sûr que si vous considérez les initiations dans les maisons de quartier ou celles de l'AFPA comme des formations, effectivement, beaucoup de bêtises grossières sont dîtes ici.
Ensuite, flash : très apprécié des graphistes, car très puissant. Mais depuis qu'Apple ne le prend pas en charge sur iPhone, la techno a fortement périclité (et tant mieux).
Concernant Photoshop (ou Gimp), ce sont des outils incontournables. CSS3 évite l'utilisation catastrophique d'images pour tout et n'importe quoi. Mais cela nécessite là encore un véritable apprentissage théorique. Et une pratique pour savoir ce qui marche, ce qui ne marche pas sur tel ou tel navigateur.

Malheureusement, les adeptes du Do It Yourself ont souvent des recommandations qui ont plusieurs années (mois dans le meilleur des cas) de retard, et s'autoproclament "formateurs". Ils sont aussi souvent assez peu adepte de la remise en question et de l'adaptation.

Donc, couplez ce genre d'incompétent et un marketeux/commercial qui ne veut qu'un site sexy, et vous obtenez des aberrations (ergonomie infecte, temps de chargement trop long, impossible à référencer, non-conformité aux normes W3C basiques).

Naviguer sans JS aujourd'hui, c'est un peu comme naviguer en mode texte, ou naviguer sous IE6 : les sites ne sont plus faits pour cela. On peut le regretter, le contester, mais les choses sont comme cela.
Soyons réalistes, on ne peut concevoir 25 versions d'un même site pour répondre aux demandes de chacun (kikoo, ergonomique, sans JS, IE6 mode…). Et maintenir l'ensemble cohérent et à jour est un casse-tête inimaginable.
L'ergonomie, ça consiste justement à rendre les choses simples pour 99% des personnes.
Si vous voulez que les choses soient possibles sans JS, proposez un framework qui prend en charge la conversion(compatible avec les principaux navigateurs, of course). Et bonne chance pour détecter si le client accepte ou non le JS… Vu que cette fonctionnalité requiert justement l’exécution d'un script JS.

Oui, mais attention aux conditions d'utilisation et de réutilisation du contenu chez les "petits" fournisseurs… Certains ont des clauses aberrantes sur les licences notamment (cession de la propriété du contenu au service, réutilisation sans autorisation).

Il faut bien distinguer "image" et "photo". Par définition, une photo est susceptible de contenir des personnes qui ne sont pas forcément consentantes et qui peuvent se retourner contre vous.

Donc privilégiez l'auto-hébergement (ou utilisez un serveur mutualisé).

Ajoutons que Microsoft s'est cassé les dents avec son Home Server. Ils n'ont pas fait dans la simplicité il est vrai, mais le produit n'a jamais trouvé son marché, malgré les pubs et investissements marketing. Donc le marché est plus probablement une niche pour paranos/bricoleurs (sélectionnez selon le niveau de sécurisation du serveur…). Le quidam lambda n'en voit pas l'intérêt, n'a pas les compétences pour installer apache et sécuriser sa machine: il choisit Dropbox ou Google Drive. Ça marche, partout, c'est magique. Son PC plante, il installe 10 Mo sur le nouveau et ça repart. Si le serveur auto-hébergé plante, c'est des heures de conf, de paramétrage, de mise a jour. Et au mieux, une restauration d'un backup fait il y a quelques semaines.
En terme de sécurisation, les fournisseurs ne sont pas parfaits, mais force est de reconnaitre qu'ils ont une expérience, des compétences et une architecture matérielle et logicielle que n'aura jamais Mme Michu.
C'est un beau jouet pour technophile (j'en suis un), mais le jour où cela sera généralisé, ça sera avec un concept simple et élégant (tant l'utilisation que l'objet/serveur en lui-même).

insert data. duplicating…
Merci pour cette astuce bien pratique ;)

Effectivement, ça ressemble à un double post. Je n'avais même pas vu l'autre réflexion. Apparemment, je ne suis pas le seul à le penser : héberger soi-même ses données a pour but de les protéger. Si c'est pour les perdre à la première surtension, l'intérêt est très limite pour 90% des données. Le seul intérêt serait pour des données hyper confidentielles (scan de documents officiels). Pour les documents texte ou tableur, les gens préfèrent voire google les analyser plutôt que les perde.
L'idée est bonne, mais la sécurité des données est beaucoup trop faible sur une machine hébergée chez soi.

J'utilise l'auto-hébergement. En tant qu'informaticien, cela ne me pose aucun problème : les logiciels libres répondent à la plupart des besoins. Néanmoins, quelques contraintes évidentes arrivent :

• il faut un pc allumé h24 ou presque
• il faut une damoiselle qui le support (l'utiliser comme lecteur dvd/divx peut aider)
• il ne faut pas avoir peur d'utiliser la ligne de commande (remove(non_geek_user)

Passé ces contraintes fonctionnelles, les contraintes techniques sont elles aussi importantes :

• nécessite d'avoir un débit upload/download suffisant : souvent le débit descendant l'est. Par contre, le débit ascendant via l'ADSL ne suffit clairement pas.
• sécuriser son installation : si l'on héberge soi-même ses données, c'est qu'on ne veut pas les retrouver partout. Sécuriser son serveur est indispensable, et pour l'instant je n'ai rien trouvé de satisfaisant (un mix ufw/fail2ban… c'est mieux que rien mais faiblard…)
• redondance des lignes et des données : 2 connexion c'est le mini (cf panne SFR…) : 60€/mois. Au minimum un raid (0 ou 1, je sais jamais…).

Tout ça pour dire que stocker chez soi, ça ne s'improvise pas. De l'auto-hébergement mutualisé peut-être une manière d'apporter les redondances indispensables à moindre cout.

J'ajouterai également 2 fonctionnalités, qui aujourd'hui ne sont pas indispensables mais qui devraient le devenir :

• domotique : avoir la main sur ses installations domestiques à distance (nécessite une VRAIE sécurité pour le coup…).
• appli smartphone : c'est maintenant quasiment obligatoire. A quoi bon avoir un serveur dispo h24 si on ne peut y accéder que lorsque l'on est devant un ordinateur lourd…

Ce qui est assez gênant, c'est la notion d'obligation. Il y a des domaines où il y a du libre mais où son utilisation est trop complexe. Je pense notamment à Open/Libre Office. Je l'ai beaucoup utilisé pour ma licence.
De plus, pas grand chose est dit sur l'utilisation de standards, qui eux forcent à une interopérabilité effective.
Arrivé en master, j'ai vraiment touché ses limites : dès que l'on a besoin de la gestion de quelques chapitres, d'une pagination, d'un index, certes, les fonctions sont dispo, mais trop compliquées à utiliser par rapport à MS office. Du coup, je suis passé sous Latex, impensable pour toute une administration.
Exemple simple : une administration a bossé 20 ans sous excel. Appel d'offre : lire les fichiers historiques. On repart sur du MS Office, parce qu'aucune autre suite ne saurait exécuter les macro VBA. Le portage des macro? Ça coute un bras, rien que pour tester… Loi contournée, CQFD.
Notez aussi que l'open-source ici n'est pas un but mais un moyen : l’État italien est en mauvaise situation financière, et grappille toutes les sources d'économies possibles. L'open-source contribue ici à l'austérité, ce qui est assez paradoxal…

Le principe du NoSQL c'est justement de relâcher cette contrainte habituelle des bases de données relationnelles qu'est le contrôle absolu des données.
La scalabilité ce n'est pas juste répartir ce qui se calculait sur un serveur. C'est beaucoup plus compliqué que cela. Déjà, quand on développe une appli parallèle, il est souvent assez complexe de savoir précisément ce qui se passe sur chacun des thread/process. Donc quand on applique ce principe à une appli, ça devient d'autant plus compliqué…
Donc, quand on veut scaler réellement, effectivement, il y a une complexité, mais qui pour le moment existe dans tous les logiciels que j'ai pu tester :s

Effectivement, point sur lequel j'avais des doutes depuis le début pour Diaspora : un Facebook libre ne marchera jamais, car ça existe déjà, ça marche, et tous les "amis" sont déjà dessus.
Si quelqu'un veut un réseau social libre et décentralisé, il NE faut PAS copier facebook (je sais de quoi je parle, je bosse chez le 2eme réseau social français…). Il faut quelque chose de plus, de mieux pensé, de plus utile, ou de plus pratique pour l'utilisateur final. L'archi, c'est bien, mais l'utilisateur lambda s'en contrefout. Ce qu'il veut c'est un service.
Là on touche aux limites (des partisants) du libre : il faut s'ouvrir à ceux qui n'en ont rien à faire de la licence, écouter ce qu'ils veulent, et sortir de nos beaux diagrammes UML/ histoires de licence. Un projet pensé pour l'utilisateur marchera, libre ou non.
Si Linux a aussi bien marché, c'est grâce à la philosophie de Linus et à l'ordre de ses priorités:
1) je veux que ça marche
2) je veux que ça soit fiable
3) je veux que ça soit libre.
Hurd, basé sur la philo Stallman, qui prend l'ordre exactement inverse, piétine depuis bientôt 25 ans… Il faut être pragmatique si on veut qu'un projet marche, et c'est vital pour l'informatique "sociale" qui perce depuis quelques années. Le libre est archi présent dans les architectures, totalement absent en front…

Twitter rejoint la Linux Foundation la semaine même ou il ferme tout accès à ses données, et pas seulement pour des concurrents. Il était déjà un contributeur régulier à Linux, le mouvement est donc principalement symbolique. Par contre ses API qui se ferment, elles posent de sérieuses questions.

Pour Diaspora, c'est regrettable, mais le modèle décentralisé ne peut pas décoller tant que le débit est asymétrique entre upload et download : dès que vous postez des fichiers lourds (images, musiques), cela se sent immédiatement. Et Facebook ayant une force marketing et une forte image de marque, le match était plié d'avance : viser le grand public sans marketing, c'est illusoire…

Plutôt d'accord avec le fond : on respecte la sécurité ou on vire. Néanmoins, j'ajouterai 3 bémols :
_ l'app store n'est pas blindé, loin de là.
_ Apple ne s'applique pas les mêmes règles que celles qu'il applique aux devs. Ca pose un réel problème d'équité.
_ pas de possibilité laissée à l'utilisateur de choisir un autre market en connaissance de cause.

Google s'oriente vers la même politique pour Android, avec les mêmes limitations.

Les millions d'euros couvrent 2 choses : le marketting et le travail des devs. Dans le libre, le marketting n'est pas indispensable. Il ne reste que le temps passé en développement, qui lui est dépensé de toute manière. Mais quand Activision met pendant 2 ans 150 devs sur un projet, le temps passé n'est pas faisable pour une communauté libre , même avec 150 contributeurs réguliers (ce qui est déjà relativement rare). Donc étant donné que dans un projet libre de jeu les devs sont rarement rémunérés…

De plus le fait qu'il s'agisse d'un jeu (donc, aucune contribution dans le cadre d'une entreprise), limite encore davantage le temps que peut y consacrer un dev.

C'est pour moi l'une des limites du libre : sur de gros projets non professionnels, le temps de développement nécessaire pour lutter contre les alternatives propriétaires exclut quasiment cette possibilité. Le jeu est peut-être l'une des illustrations de cette limitation.

Autant le libre pour poste de travail/ serveur a un réel avenir à mon sens, autant dans le domaine du jeu vidéo je suis dubitatif. Etant amateur de FPS et de stratégie, j'ai essayé Tremolus, OpenArena. Je n'ai fait qu'essayer. Les jeux sont nettement moins beaux graphiquement, nettement moins immersifs, et je n'ai trouvé aucun réel apport dans le gameplay. J'aime également la stratégie, mais là encore, le proprio surclasse largement le libre (X3, Homeworld, …).

Je pense que le problème est inhérent à la complexité du jeu vidéo : il faudrait fédérer une énorme communauté aux compétences extrêmement variées pour lutter contre les grands du domaine : en allant du moteur jusqu'à la réalisation d'images et de sons.

Le système de forks évoqué ici rend la tache encore plus ardue : un développeur de moins dans une équipe de taille réduite oblige à faire des coupes franches, ce qui provoque ensuite une hémorragie (découragement, mauvaise ambiance). Même s'il n'est qu'une conséquence de problème antérieurs, il aggrave les conséquences.

Concernant les aberrations de gestion des librairies, là il y a une bonne habitude à prendre dès le début. Le problème n'est pas que le fork utilise une librairie donnée, mais plutôt que le jeu originel ne se base pas sur une librairie standard. Attribuer cette habitude au monde propriétaire/ Windows est ici probablement de mauvaise foi : quand on développe avec le framework .NET, on évolue en même temps que celui-ci, on n'oblige pas le client à avoir une version spécifique de la librairie, et ce depuis au moins 5-6 bonnes années maintenant. De plus, la nécessité de permettre le jeu sous plusieurs plateformes logicielles(car la plupart des joueurs sont sous Windows) rends très complexe un certain nombre d'optimisations. Les maintenir au fur et à mesure de l'évolution des librairies sous différents système est un casse-tête qui explique probablement à lui seul la non-évolution des dépendances liées à un jeu.

Pour ma part, si je garde encore un Windows, c'est essentiellement pour pouvoir continuer à jouer à des jeux récents, immersifs. Si une véritable alternative libre apparaissait (et à mon avis il y a des créneaux, notamment dans le MMO ou la STR, ou les graphismes sont moins importants que le gameplay), je switcherai volontiers sous Linux en totalité. Mais pour l'instant, force est de constater que les alternatives libres sont soit un gros cran en dessous des propriétaires (FPS) soit sont quasiment inexistante (stratégie spatiale par exemple…). Donc en l'état actuel, parler de "jeu libre" en alternative aux blockbusters ne me semble pas être très pertinent. Les placer à côté en disant "il existe cela" est déjà très optimiste.

Bien, vous faites parti des 1% de libristes. Dîtes-le à Asus, qui vous dira en résumé "allez voir ailleurs". Ne perdons pas de vue que pour eux le "libre" est une niche, pas un marché de masse…
Pour ce qui est de Microsoft, je pense que leurs avocats ont bien mieux verrouillé que cela les contrats.
Le problème ici vient de Intel, pas d'Asus (dont le boulot n'est pas de savoir si le driver pour le GPU est libre, mais d'assembler une machine et de la vendre).

Modèles sur lesquels ils paient moins cher ladite licence… si il ne le vendent qu'avec du Windows. Ils ne vont pas risquer de perdre 1€/vente sur les fleurons de leurs gammes…

Effectivement, après vérification, je viens de me rendre compte qu'ils sont pour la plupart en 64 bit (y compris le mien, que je pensais être limité au 32…). Donc effectivement, un pilote 64 serait le bienvenu…

L'information est pertinente, mais je trouve l'orientation qu'a l'article non-pertinente : dénoncer Asus parce qu'il n'a fait qu'une partie du chemin alors qu'aucun autre constructeur ne l'a fait hormis Dell à ma connaissance. J'aurai davantage approuvé un article disant "geste insuffisant" plutôt que "offre viciée".
Ce type de plateforme est le standard intel. On peut dire "Asus aurait pu mettre une carte avec un pilote libre". Certes, mais ça ajoute un coût de conception. Asus trempe donc le pied dans l'eau pour voir si elle est bonne. Ce genre d'article risque de lui montrer que l'eau est glacée…
A mon humble avis, ce n'est pas en boycottant ce type d'offre qu'on offrira un véritable marché au libre sur les postes client.