Comment organiser ses dossiers chez l'hébergeur?

Bonjour abeille,

abeille a écrit :
je ne commence pas avant d'avoir eu votre réponse!

Chiche on répond pas et chiche tu fais comme tu dis ?! lol

Greg_Lumiere a écrit :
Bonjour abeille,

Chiche on répond pas et chiche tu fais comme tu dis ?! lol

Finalement j'ai commencé! Et ça va, pour l'instant ça charge assez vite, malgré des pages avec beaucoup de photos.

Salut,
Et tu pourras nous donner l'url pour voir ce que ça donne ?
Modifié par MatthieuR (16 Apr 2016 - 08:57)

Plus sérieusement,

Influence de l'organisation et du nombre des fichiers sur les performances de l'hébergeur
L'organisation de tes fichiers côté hébergeur n'a, à ma connaissance, aucune influence sur les performances de lecture, d'écriture et d'exécution sur un serveur.

Pour percevoir une infime baisse des performances, il faut atteindre plusieurs dizaines (centaines ?) de milliers de fichiers par opération.

Pour te donner une idée, apache + php c'est moins de 15 000 fichiers et c'est du pipi de chat à faire tourner.

L'indice de performance général de ton site web dépend plus du codage en lui-même et des technos utilisées que du nombre et de l'organisation physique de tes répertoires et fichiers sur le serveur.

En ce qui concerne ta façon d'organiser tes fichiers
Rien ne t'empêche de faire un regroupement par "page web" même si ce procédé est peu commun. Afin de rendre légitime ton choix, pose-toi tout de même les questions suivantes :

* A titre d'exemple, peux-tu être absolument certain que la Photo 2 contenue dans la page 2 n'apparaîtra nulle part ailleurs sur le site ?

* Les éléments communs aux pages, tu penses les regrouper selon leur type, leur fonction, leur encodage (théoriquement ils devraient avoir tous le même) ou autre ? A quelle logique cela correspond-il et est-ce la même logique que pour le reste du contenu ? (la réponse doit être oui !)

* Une vache y retrouverait-elle ses veaux ?Et si tu dois refiler les commandes à un tiers... ?

Ce sont là quelques pistes qui me viennent à l'esprit.

Conseils / point de vue personnel
La façon que tu décris est peu commune à mon sens car je n'ai jamais vu en pratique une telle organisation.
D'ailleurs ton schéma serait tout à fait inapplicable chez moi car incompatible avec ma façon de faire mon code.

Afin d'éviter toute redondance, de garder une cohérence inter et intra-fichiers et d'optimiser le processus de maintenance j'ai choisis de séparer mes fichiers selon leur type de contenu.
Ce qui me donne des catégories d'ordre générales (par ex: datas, scripts, graphics, objects etc).
Et à l'intérieur de ces groupes, je sectionne encore si nécessaire (par exemple le groupe Graphics va se décliner en Photos, Css, Icons etc).
Mais je garde à l'esprit de ne pas entrer trop en profondeur dans l'arborescence (2 sous-niveaux maxi par rapport à la racine).
Tout cela je ne le fais pas pour faciliter le travail du serveur mais surtout pour que j'y (je = moi + scripts) retrouve mes petits facilement.
C'est cette forme de hiérarchie ou du moins c'est vers une vision proche de celle-ci que se tournent la plupart des cas croisés en chemin.


Qu'en penses-tu ?



PS : Le savais-tu ? : il est de convention de tout rédiger en anglais en webdev (commentaires, noms de fichiers, identifiants, class, ids, et j'en passe) et ce quelque-soit le langage.
Modifié par Greg_Lumiere (16 Apr 2016 - 09:01)

D'ailleurs tout ceci amène la réflexion selon laquelle on peut se demander qu'est-ce qui influence la vitesse de chargement d'une page si ce n'est pas sa position physique sur le DD ?

Le poids :
Évidement le premier critère. Un gros fichier mettra plus de temps qu'un petit fichier. Vous l'avez tous constatés en téléchargeant des films (de vacance).

Une réaction logique face à ce cas serait alors de découper ce gros ficher en plusieurs plus petits mais ferait-on vraiment une affaire en terme de rapidité ?

Là c'est moins sûr car la vitesse d'affichage dépend aussi de la rapidité à effectuer un cycle de connexion.

Alors qu'est-ce que j'appelle un cycle de connexion ? Une connexion peut se résumer en 3 temps : j’envoie une requête au serveur, j'attends sa réponse et j'achemine la réponse.
Sur ces 3 temps, techniquement il y a ouverture d'un socket, transmission d'un ordre d'exécution au serveur, récupération et transmission de la réponse puis fermeture du socket.

Ces opérations se répètent à chaque fichier. En ne tenant pas compte du poids d'un fichier dans la transaction, on a tous constater quelques secondes de latences pour télécharger un fichier texte d'1ko. Ces quelques secondes sont dus au protocole de communication.

C'est pourquoi multiplier les petits fichiers n'est pas une bonne affaire en terme de vitesse de chargements.


Il est souvent préconisé d'ailleurs de regrouper ses fonctions, ses classes, faire des sprites (etc) lors de la mise en production.
Modifié par Greg_Lumiere (16 Apr 2016 - 09:15)

Adio Matthieu

MatthieuR a écrit :
Salut,
Et tu pourras nous donner l'url pour voir ce que ça donne ?

Oui, bien sûr, cette semaine si tout va bien: "les mensonges de la science"!!

Adio Greg, merci pour ta très longue explication, cela clarifie certains élements.

Greg_Lumiere a écrit :
C'est pourquoi multiplier les petits fichiers n'est pas une bonne affaire en terme de vitesse de chargements.

Voila!
Je traduis mon site aussi en Espagnol et donc j'avais placé toutes les images dans un deuxième fichier *espagne". Mais je crois que c'est pas très bon comme méthode!

+SITE
	France
		accueil
		contact
		Dossier 1
			photo A
			photo B
			photo C
		Dossier 2
		Dossier 3
	Espagne[
		Indice
		Contacto
		registro 1
			photo A
			photo B
			photo C
		registro 2
		registro 3

Modifié par abeille (16 Apr 2016 - 10:50)

abeille a écrit :

Je traduis mon site aussi en Espagnol et donc j'avais placé toutes les images dans un deuxième fichier *espagne". Mais je crois que c'est pas très bon comme méthode!

Tu te réponds à toi même.

Pourquoi traduire ton arborescence selon la langue d'affichage ?

Tu constates que selon ton point de vue on se retrouve face à des éléments redondants.

Voici comment je procède dans ton cas de figure :

/datas/ <= contient les datas selon la langue
/datas/homepage_fr.data <= que ce soit du json, xml ou autre, à toi de voir
/datas/homepage_es.data
/datas/page_2_fr.data
/datas/page_2_es.data
/datas/Header_fr.data <= header commun à mes pages
/datas/Header_es.data
/datas/etc etc etc
Edit : Valable dans le cas du stockage des informations sous forme de fichier.
Dans le cas de l'utilisation d'une base de donnée, ces informations seront enregistrées dans la base de donnée et non ici. Ce dossier n'aurait alors dans ce cas pas lieu d'être.

/content/ <= va contenu l'architecture de mes pages
/content/homepage.php
/content/page_2.php
etc etc

/objects/
/objects/header.php
/objects/footer.php
etc

/graphics/
/graphics/photos/
/graphics/photos/theme-categorie-genre-identifiant unique.jpg
Par exemple : rivieres-france-rhin-001.jpg

/graphics/style/
/graphics/style/style.css

/graphics/icons/
/graphics/icons/arrow-a.png
/graphics/icons/check-sign.png
etc



Bien sûr à adapter selon tes besoins.
Modifié par Greg_Lumiere (16 Apr 2016 - 11:10)

Sur le choix des noms de fichiers à adopter :

Adopter une convention de nommage stricte !



Je pense que c'est le meilleur conseil que tu puisse recevoir,.

Greg_Lumiere a écrit :
Alors qu'est-ce que j'appelle un cycle de connexion ? Une connexion peut se résumer en 3 temps : j’envoie une requête au serveur, j'attends sa réponse et j'achemine la réponse.
Sur ces 3 temps, techniquement il y a ouverture d'un socket, transmission d'un ordre d'exécution au serveur, récupération et transmission de la réponse puis fermeture du socket.
Ces opérations se répètent à chaque fichier. En ne tenant pas compte du poids d'un fichier dans la transaction, on a tous constater quelques secondes de latences pour télécharger un fichier texte d'1ko. Ces quelques secondes sont dus au protocole de communication.

C'est parfois pire que ça...
Le processus ci-dessus ne concerne qu'un accès direct à la ressource.
Dans certains cas, il y a aller retour entre serveur web et navigateur, par exemple :
- lorsqu'une demande d'authentification est exprimée par le serveur (HTTP 403)
- lorsqu'il y a redirection (HTTP 301 / 302)
On peut considérer par ailleurs que le passage au travers de différents proxies augmente le temps de latence, soit par nature, soit parce que ces proxies exécutent un traitement sur la ressource qu'ils voient passer.
Concernant les performances d'affichage de la page HTML une fois reçue par le navigateur, il ne faut pas oublier non plus que la façon dont les sélecteurs ont été définis dans la feuille de style peut induire un temps d'analyse (parsing) plus ou moins élevé.
Il en va de même de la structure HTML qui doit être au minimum optimisée, c'est à dire ne pas contenir de SPAN / DIV, etc. vides... ce que l'on constate souvent sur les pages.
Pris séparément, ces temps d'analyse sont négligeables. Mis bout à bout, ils détériorent toutefois un peu plus le processus d'acquisition / affichage de la ressource demandée par l'utilisateur.

Greg_Lumiere a écrit :
PS : Le savais-tu ? : il est de convention de tout rédiger en anglais en webdev (commentaires, noms de fichiers, identifiants, class, ids, et j'en passe) et ce quelque-soit le langage.

Euh... non, là faut arrêter de juger "english first".
Si le site web n'est destiné à être maintenu que par un Français ou une équipe de Français, il n'y a strictement aucune obligation d'utiliser le british language pour concevoir les pages HTML.
La même problématique se pose en matière de développement Java, C# ou autres.
A moins de devoir partager le code avec des équipes internationales, l'utilisation de l'anglais n'apporte absolument rien de significatif, bien au contraire.

sepecat a écrit :

Euh... non, là faut arrêter de juger "english first".

Si si je t'assure. Il ne s'agit pas là d'une obligation mais d'une recommandation d'un commun accord et d'ordre général

sepecat a écrit :

Si le site web n'est destiné à être maintenu que par un Français ou une équipe de Français, il n'y a strictement aucune obligation d'utiliser le british language pour concevoir les pages HTML.

Si tant est que tu puisses en être sûr, je suis tout à fait d'accord.

Autrement sur le sujet de fond, je suis d'accord avec tes remarques. Je tendais à simplifier et réduire le champs de vision sur la transaction d'un flux. On pourrait d'ailleurs considérer les limitations physiques liées aux différentes machines et encore bien d'autre paramètres sur lesquels le développeur n'aura pas forcément la main.

D'ailleurs si je pouvais remettre la main sur l'article qu'à une époque m'en avait apprit beaucoup sur les flux je n'hésiterais pas à venir y poster le lien. Un sujet passionnant ! (même s'il y a de quoi attraper des migraines )

sepecat a écrit :

Euh... non, là faut arrêter de juger "english first".
Si le site web n'est destiné à être maintenu que par un Français ou une équipe de Français, il n'y a strictement aucune obligation d'utiliser le british language pour concevoir les pages HTML.
La même problématique se pose en matière de développement Java, C# ou autres.
A moins de devoir partager le code avec des équipes internationales, l'utilisation de l'anglais n'apporte absolument rien de significatif, bien au contraire.

Oui, je suis bien d'accord avec toi.
Et surtout quand on a des classes avec des noms bien précis, par exemple "encart_texte_accueil", c'est pas bien pratique en anglais.

Mais bon...ce n'est pas bien important tout ça.
Je me demande comment codent les arabes, les russes, les japonais?
Modifié par abeille (16 Apr 2016 - 12:35)

Greg_Lumiere a écrit :
Si si je t'assure. Il ne s'agit pas là d'une obligation mais d'une recommandation d'un commun accord et d'ordre généralSi tant est que tu puisses en être sûr, je suis tout à fait d'accord.

Faut se méfier des recommandations...
Si je prends pour référence le domaine de l'aérien, que je connais un peu et où l'anglais est plus que préconisé, plusieurs études ont démontré que l'incompréhension entres équipages / tours de contrôle, y compris lorsque l'anglais était la langue native des intervenants, était à l'origine d'un nombre significatif d'incidents / accidents (un incident qui finit mal ).
La langue anglaise est concise, certes, mais cela a un effet pervers lorsque les sons émis sont très proches et peuvent être mal interprétés.
Plus d'infos sur le sujet dans cet article.
Ceci dit, en code source il est rare que l'on s'exprime à voix haute .
Mais la tendance actuelle qui veut que l'anglais c'est "in" et le français c'est "out" relève plutôt d'un effet moutonnier. Dans un monde dit "globalisé", il est de bon ton de s'évertuer à ne pas paraître ringard vis à vis des autres.
Pour conclure sur ce point, je bosse dans une banque avec un réseau international très développé et des équipes de développement situées à Singapour ou en Inde.
Autant dire que l'anglais est courant dans nos bureaux.
Pour autant, bonjour les conférences téléphoniques avec les Indiens ou les british. Même si on est censés utiliser le même langage, les accents locaux rendent l'exercice parfoirs ardu, même pour des responsables de filières rompus à cet exercice.
Modifié par sepecat (16 Apr 2016 - 13:00)

sepecat a écrit :

Si je prends pour référence le domaine de l'aérien, que je connais un peu et où l'anglais est plus que préconisé, plusieurs études ont démontré que l'incompréhension entres équipages / tours de contrôle, y compris lorsque l'anglais était la langue native des intervenants, était à l'origine d'un nombre significatif d'incidents / accidents (un incident qui finit mal ).

Et donc ils auraient du parler en français comme ça personne n'aurait rien compris.

abeille a écrit :
Je me demande comment codent les arabes, les russes, les japonais?

Les codes sources auxquels j'ai eu l'occasion d'avoir accès étaient pour la grande majorité soit en anglais uniquement soit en langue natale sous-titrée en anglais.

sepecat a écrit :
Ben non... il existe des langues "neutres" (cf. esperanto).

Je ne pense pas qu'apprendre l'Esperanto puisse-t-être LA solution.
Les natifs représentent, selon l'article, un millier d'âmes.
Il me paraît plus logique de s'entendre sur la langue la plus communément utilisée dans notre réseau de communication.

Ce n'est pas que je sois pro-anglicismes, je tient à la langue française et ses particularités mais l'un ne peut-il pas coexister avec l'autre ?

Il est vrai qu'à l'oral les accents fortement marqués peuvent être des freins à la compréhension. Sur ce point je pense que c'est aux collaborateurs de faire l'effort de parler un anglais académique et non uniquement balancer leurs phrases à peines mâchées (ça me rappelle quelqu'un ça ).
Et bien souvent c'est même ceux qui ne sont pas natifs anglophones qui parlent le mieux.

Peut-être une question d'effort, qu'en pensez-vous ?


PS: la question n'est pas d'être "in/out". Ce concept m'est étranger.
Modifié par Greg_Lumiere (16 Apr 2016 - 15:42)