(reprise du message précédent)
J'aime bien comprendre comment les choses marchent et ce que je fais.
Si on utilise un framework ou un CMS, alors on n'a pas le même contrôle ni la même comprhéension sur le code de l'outil en question.
Quand j'utilise un CMS ou un framework, j'ai juste l'impression d'utiliser une boîte noire. Tant que ça fait ce qu'on veut que ça fasse c'est cool. Mais quand ça ne fait plus exactement ce qu'on veut, soit parce que ça n'a pas été prévu, soit parce que ce n'est plus maintenu, soit parce qu'il y a un bug, on n'a plus qu'à pleurer ou changer d'outil.
A ce stade, mieux vaut soulver le capot d'un système qu'on connaît parce qu'on l'a conçu soi-même, que de partir en terre plus ou moins inconnue. Le temps qu'il faudra pour remédier au problème sera bien plus court.
L'avantage de construire ses propres outils, c'est qu'on sait exactement comment ils marchent. Et si on tombe sur un os, on n'est pas complètement désemparé; au contraire on sait exactement où chercher, ou du moins par où commencer pour avancer.
Je te rassure, je ne fais pas tout moi-même non plus. Quand c'est un truc bien fait et qui fait exactement ce que je veux, je prends le temps d'apprendre comment il fonctionne et je l'utilise, jusqu'à ce que je me heurte à ses limites.
Sinon, si on poursuivais la logique jusqu'au bout, alors je serais en train de réinventer le php, réécrire apache ou même carrément le noyau linux. Je n'ai quand même pas cette prétention, il ne faut pas déconner.
Fort hereusement, en tout cas en ce qui concerne les deux derniers, je n'en ai pas (encore) trouvé les limites.
Non; il se trouve seulement qu'on connaît beaucoup mieux ce qu'on a créé soi-même, et qu'on est du coup potentiellement beaucoup plus prompt à résoudre les problèmes et à évoluer.
Tiens, je vais te donner un exemple concret. IL y a quelques années, j'avais choisi d'utiliser un certain panel pour gérer mon serveur: les domaines, le DNS, les comptes mail, le FTP, etc.
Je n'avais pas envie de me casser la tête à configurer tout ça manuellement moi-même, donc j'ai installé ce panel. Au début, tout fonctionnait pour le mieux dans le meilleur des mondes, ce panel était très bien à l'époque.
Il se trouve déjà depuis un bon moment maintenant, que le panel en question n'est plus maintenu. La migration vers debian 7 a déjà été très compliquée et je n'ose même pas penser au moment où il faudra passer à la 8.
Des erreurs incongrues apparaissent çà et là de plus en plus souvent à mesure que le système est mis à jour. ET récemment, j'ai pu constater que le webmail inclus ne supporte pas l'UTF-8 et du coup ça pose des problèmes pour des utilisateurs russes. Dans l'idéal il faudrait patcher le machin, écrit dans un php d'il y a 10 ans, ou trouver un autre panel.
A ce stade, si j'avais appris à gérer en détail la configuration des DNS, mails, FTP, etc. sous linux et pris le temps de coder un panel moi-même :
1 - Je ne serais pas obligé da'ttendre un patch qui ne viendra jamais puisque le projet a clairement été abandonné par ses auteurs
2 - Puisque ça aurait été mon code, j'aurais trouvé pas trop difficilement d'où viennent ces erreurs et j'aurais fait les corrections moi-même en sachant ce que je fais sans aucun risque de mettre le boxon ailleurs
3 - Je ne serais pas coincé en attendant de trouver un autre panel à jour qui offre les mêmes fonctionnalités
En un mot, je suis devenu dépendant de ce panel; et maintenant, c'est difficile d'en changer, ou de s'en passer, sans investir un temps important; ou alors je n'évolue plus et je garde debian 7 pour les 5 ou 10 prochaines années.
OK il y a encore des mecs qui travaillent sur des mainframes IBM des années 1970... mais dans notre monde hyperconnecté d'aujourd'hui, ne pas évoluer c'est mourir à petit feu.
Bon, pas grave, c'est pour un serveur perso; mais j'imagine le pétrin dans lequel une boîte pourrait se trouver.
Donc, j'en conclus que c'est choisir de gagner du temps maintenant pour potentiellement le payer plus tard
Techniquement, le HTML et le CSs sont des langages de description, pas de programmation.
Donc d'après cette définition, celui qui ne fait ni javascript ni programmation côté serveur ne fait pas vraiment du développement, non.
Mais bon, ce n'est qu'une définition... et puis de toute façon le front-end est aussi important que le back-end; que ce soit parce que ça ne marche pas ou parce que ce n'est pas ergonomique, un utilisateur qui est parti, il est parti.
a écrit :
Donc si on utilise un framework ou un CMS pour developper, on ne fait pas du développement propre. C'est quoi exactement ta définition du "développement propre" ? Parce que ta remarque n'est pas seulement fausse, elle est aussi méprisante et prétentieuse.
J'aime bien comprendre comment les choses marchent et ce que je fais.
Si on utilise un framework ou un CMS, alors on n'a pas le même contrôle ni la même comprhéension sur le code de l'outil en question.
Quand j'utilise un CMS ou un framework, j'ai juste l'impression d'utiliser une boîte noire. Tant que ça fait ce qu'on veut que ça fasse c'est cool. Mais quand ça ne fait plus exactement ce qu'on veut, soit parce que ça n'a pas été prévu, soit parce que ce n'est plus maintenu, soit parce qu'il y a un bug, on n'a plus qu'à pleurer ou changer d'outil.
A ce stade, mieux vaut soulver le capot d'un système qu'on connaît parce qu'on l'a conçu soi-même, que de partir en terre plus ou moins inconnue. Le temps qu'il faudra pour remédier au problème sera bien plus court.
L'avantage de construire ses propres outils, c'est qu'on sait exactement comment ils marchent. Et si on tombe sur un os, on n'est pas complètement désemparé; au contraire on sait exactement où chercher, ou du moins par où commencer pour avancer.
Je te rassure, je ne fais pas tout moi-même non plus. Quand c'est un truc bien fait et qui fait exactement ce que je veux, je prends le temps d'apprendre comment il fonctionne et je l'utilise, jusqu'à ce que je me heurte à ses limites.
Sinon, si on poursuivais la logique jusqu'au bout, alors je serais en train de réinventer le php, réécrire apache ou même carrément le noyau linux. Je n'ai quand même pas cette prétention, il ne faut pas déconner.
Fort hereusement, en tout cas en ce qui concerne les deux derniers, je n'en ai pas (encore) trouvé les limites.
a écrit :
Si pour toi, la qualité du code c'est coder à la main en mode "artisan", je pense que tu t'es trompé de branche parce que tu n'as pas compris pourquoi l'informatique a été créée et developpée.
Non; il se trouve seulement qu'on connaît beaucoup mieux ce qu'on a créé soi-même, et qu'on est du coup potentiellement beaucoup plus prompt à résoudre les problèmes et à évoluer.
Tiens, je vais te donner un exemple concret. IL y a quelques années, j'avais choisi d'utiliser un certain panel pour gérer mon serveur: les domaines, le DNS, les comptes mail, le FTP, etc.
Je n'avais pas envie de me casser la tête à configurer tout ça manuellement moi-même, donc j'ai installé ce panel. Au début, tout fonctionnait pour le mieux dans le meilleur des mondes, ce panel était très bien à l'époque.
Il se trouve déjà depuis un bon moment maintenant, que le panel en question n'est plus maintenu. La migration vers debian 7 a déjà été très compliquée et je n'ose même pas penser au moment où il faudra passer à la 8.
Des erreurs incongrues apparaissent çà et là de plus en plus souvent à mesure que le système est mis à jour. ET récemment, j'ai pu constater que le webmail inclus ne supporte pas l'UTF-8 et du coup ça pose des problèmes pour des utilisateurs russes. Dans l'idéal il faudrait patcher le machin, écrit dans un php d'il y a 10 ans, ou trouver un autre panel.
A ce stade, si j'avais appris à gérer en détail la configuration des DNS, mails, FTP, etc. sous linux et pris le temps de coder un panel moi-même :
1 - Je ne serais pas obligé da'ttendre un patch qui ne viendra jamais puisque le projet a clairement été abandonné par ses auteurs
2 - Puisque ça aurait été mon code, j'aurais trouvé pas trop difficilement d'où viennent ces erreurs et j'aurais fait les corrections moi-même en sachant ce que je fais sans aucun risque de mettre le boxon ailleurs
3 - Je ne serais pas coincé en attendant de trouver un autre panel à jour qui offre les mêmes fonctionnalités
En un mot, je suis devenu dépendant de ce panel; et maintenant, c'est difficile d'en changer, ou de s'en passer, sans investir un temps important; ou alors je n'évolue plus et je garde debian 7 pour les 5 ou 10 prochaines années.
OK il y a encore des mecs qui travaillent sur des mainframes IBM des années 1970... mais dans notre monde hyperconnecté d'aujourd'hui, ne pas évoluer c'est mourir à petit feu.
Bon, pas grave, c'est pour un serveur perso; mais j'imagine le pétrin dans lequel une boîte pourrait se trouver.
Donc, j'en conclus que c'est choisir de gagner du temps maintenant pour potentiellement le payer plus tard
a écrit :
Le développement Web n'est pas du software ? C'est quoi alors ? Du jardinage ?
a écrit :
Euh non, ce n'est pas du software. Et le CSS, c'est de la programmation pour toi ?
Techniquement, le HTML et le CSs sont des langages de description, pas de programmation.
Donc d'après cette définition, celui qui ne fait ni javascript ni programmation côté serveur ne fait pas vraiment du développement, non.
Mais bon, ce n'est qu'une définition... et puis de toute façon le front-end est aussi important que le back-end; que ce soit parce que ça ne marche pas ou parce que ce n'est pas ergonomique, un utilisateur qui est parti, il est parti.
Des milliards d'outils : des soft wisiwyg, des CMS, des frameworks, des templates. Chacun choisi ses outils en fonction de son niveau, de ses compétences, de ses préférences ou affinités.
?
=> c'est comme un ébéniste qui aurait son échoppe au milieu d'un ikéa ou d'un magasin carrefour. Chacun fait ce qu'il veut bien entendu..., c'est pratique, joli, ça mange pas de pain mais qu'on ne vienne pas après dire que le web s'uniformise, qu'il y a un manque de diversité et de fun, que le métier se décrédibilise et que l'usage des thèmes pour les clients devient la pratique de base... a force de ne pas montrer l'exemple.