Partage de scripts

Bonjour,

Voila cela fait quelques temps que je programme en HTML, CSS, JS. Et je souhaiterai partager des petits script que j'ai fait. Je ne dis pas qu'ils sont parfait mais il peuvent peut etre servir.

Je cherche donc une platform de partage de script, de preference francaise!

Si vous avez des liens je suis preneur.

Merci d'avance

Merci pour ta reponse, du coup il n'existe pas des sites francais pour ca xD

il est commenter en anglais, mais je prefere le poster sur un site francais.

Ben c'est un site français…

Ah tiens, je découvre que CodeS-SourceS a été repris par CCM !

Moi qui croyais que c'était à l'abandon, tout ce groupe-là…

ah ah ah effectement que je suis nouille xD

Merci beaucoup

Coucou,

Sinon tu peux tout simplement mettre tes scripts en forme sur un site internet. Avec le détail de tes démarches.

Il existe de nombreuses bibliothèques sur internet, pour colorer tes syntaxes, exporter tes scripts sur des plateformes de test ou bien même, tu réalises ta propre interface front-office. Ce sera probablement plus intéressent pour la communauté que la seule copie via Github (même si ce n'est pas négligeable).

Quelques bibliothèques :

• High Light JS
• Prism JS
• Rainbow

Pour tester ensuite ton code, un petit eval($('mycode').html()); suffit. Pour le HTML / CSS, je conseille les sites de dépôts où tu peux tester/modifier dans l'interface.

Sites de dépôts + test + fork :

• Codepen
• JSFiddle
• Codecademy

jsbin.com est sympa aussi

@Yarflam : eval est la pire chose à faire en JS…

Il y a des services prévus pour partager du code, pourquoi l'OP devrait perdre du temps à mettre en place sa propre structure ?

Personnellement je suis un grand fan des Gists de github.

@Yarflam : eval est la pire chose à faire en JS…

Je me doutais bien que ça allait râler. Mais dans le fond, quand tu fais un petit bouton avec 'eval' en dessous de ton code, ça ne gêne pas plus que ça.

Il y a des services prévus pour partager du code, pourquoi l'OP devrait perdre du temps à mettre en place sa propre structure ?

Pour répondre à la disponibilité de l'application. Le site peut fermer, changer, perdre des données, changer sa politique (en faisant payer par exemple) etc … En créant sa propre structure, on devient indépendant.

Même base au développement de script. Il existe deux façons de programmer : on importe des bibliothèques de l'extérieur ou on les crée. En les créant on offre plus de performance à nos scripts. Intégration, clarté, vitesse de calcul, correction des bugs. Quand je dis ça, la plupart des programmeurs me disent "Tu préfères réinventer la roue ? Perdre ton temps ?".

Et ma réponse est la suivante : "Je ne perds pas mon temps. J'apprends et je crée !", c'est mon petit plaisir de programmer. Comme une barre de vie, je suis parfois en manque - la programmation est une drogue parmi tant d'autres.

Tu peux développer ?

Oui et non, faut savoir différencier le contexte. Autant, pour apprendre, oui, tu peux t'amuser à recoder ce que tu veux. Mais quand t'as un besoin particulier (une grosse app à maintenir, t'es pas tout seul dessus, … etc), il existe des outils pour faire ce que tu comptes faire.

Certes, ce n'est pas fine-tuned par rapport à tes besoins. Mais, au moins, le truc que t'inclues a de l'expérience. C'est à dire, des bugs que toi tu vois pas au premier abord, eux les ont peut-être eu (car edge-case, … etc) et résolus qui plus est. Bref. Donc ton point autre que "pour apprendre" est faux. Tu trouves un bug dans ce que t'utilises (et c'est open-source ?) ? Contribue plutôt que de faire ton truc dans ton coin.

En les créant on offre plus de performance à nos scripts.

Tu peux développer ?

Avec plaisir.

• Intégration : il arrive parfois qu'une bibliothèque interfère avec une autre. En créant ses bibliothèques, on est certain du contraire.
• Clarté : répartition en module. Au lieu d'importer une dizaine de bibliothèques, l'application apparaît comme une armoire de fonctionnalité. Les fonctions "outils" sont centralisées de tel manière à être réutiliser plusieurs fois.
• Vitesse de calcul : se reporter à l'intégration et à la clarté. Notre script brasse des données pour un but précis. Contrairement au concepteur d'une bibliothèque - il met à profit des milliers de fonctionnalités différentes, d'où tu ne tires qu'une petite partie.
• Correction des bugs : corriger le code de quelqu'un d'autre est extrêmement difficile. Même avec des commentaires. Quand je parle de bugs, ça peut-être un plantage sur une branche de la bibliothèque ou une partie du script très peu optimisé.

Malgré tout, ça reste de la généralisation. Et ça ne m'empêche pas d'importer des librairies génériques, tel que Jquery. C'est un équilibre qu'il faut choisir.

Mais quand t'as un besoin particulier (une grosse app à maintenir, t'es pas tout seul dessus, … etc), il existe des outils pour faire ce que tu comptes faire.

Deux solutions s'offrent à toi. Utiliser des bibliothèques ou recomposer un script avec des modules. En recréant le script à partir de modules, tu optimises ton code :

• Un module = un besoin, tu utilises 100% de l'application.
• Décomposition possible. Si une partie de ton code part en couille, pas de problème ! Tu répares le module défectueux.
• Lecture optimisé, peu de ligne -> réparation des bugs.

Personnellement, j'utilise la méthode des modules. Ça marche très bien. D'ailleurs je compte développer un framework pour améliorer la gestion de mes modules - faudra que je réfléchisse à la conception.

Intégration : faux-argument.

Dans toute technologie digne de ce nom on fait appel à des systèmes de gestion voire d'injection de dépendances, afin d'isoler les bibliothèques qu'on utilise. Une bibliothèque peut égaler utiliser un namespace, un package, …

Même en Javascript aujourd'hui, pourtant autrefois le roi du "je colle tout dans la window en variable globale, advienne que pourra", on dispose d'outils de gestion de dépendances type requirejs.

Qui plus est, en créant ses propres bibliothèques, non documentées, on a 100 fois plus de chance de rentrer en conflit avec, soi une autre bibliothèque, soit du code écrit par quelqu'un d'autre qui participe à ton projet.

Clarté

En quoi l'utilisation de bibliothèques t'empêche de répartir ton code en modules, tu m'expliques ?

Au sein même de certaines bibliothèques on trouve des modules. Vu que tu sembles parler beaucoup de Javascript, je t'engage à regarder AngularJS et ses différents modules.

Quant aux fonctions outils, mais qu'est-ce-qui t'empêche de le faire quand tu utilises une bibliothèque, voire de créer une surcouche à ladite bibliothèque ??

Vitesse de calcul

Alors là, non, très clairement. Tu connais le Javascript ? Essaie de faire plus optimisé et générique que la méthode each d'underscorejs (ou celle d'angular). Tu n'écriras à mon avis jamais de code mieux optimisé que celui d'une bibliothèque open source à laquelle ont contribué des dizaines de personne spécialistes sur le sujet.

Correction de bugs

La plupart des lib sont aujourd'hui open source. Si tu trouves un bug tu peux au moins le signaler aux développeurs, au mieux le corriger et leur soumettre un correctif.

En outre, tu bénéficies des gens qui utilisent AUSSI la même bibliothèque que toi, le fait qu'elle est donc indirectement testée par des milliers d'utilisateur.

Qui plus est, je serais curieux de savoir quelle procédure de tests tu emploies pour écrire des tests automatisés pour tes propres modules, puisque tu n'utilises pas de bibliothèque.

Une bibliothèque, ça s'utilise correctement, par pour tout et rien ni n'importe quand ou n'importe comment.

Ca s'utilise quand on en a besoin et dans ces conditions, la réutilisabilité et la maintenabilité du code est bien plus importante qu'un petit module écrit dans son coin et testé à la main.