SnippetVamp: parce qu'yen a marre de chercher ses snippets...

Voilà une difficulté que tout codeur doit sans doute rencontrer: regrouper tous ses bouts de codes, fonctions etc au sein d'un seul espace, facile d'accès. 

Comme tout le monde, c'est un problème que j'ai maintes fois tenté de surmonter via des solutions plus ou moins efficaces, du dossier plein de fichiers textes aux applis tierces...

J'en suis venu à me bricoler, comme d'habitude, des applis exprès: j'ai commencé par des versions en VB il y a fortfort longtemps... puis en Delphi... 

Puis j'en ai fait une destinée à être utilisable en ligne et synchronisée localement (via ftpbox par exemple)... Ainsi, on a toujours ses codes sous la main...

Comme les copains m'ont fait l'honneur de s'y intéresser, voici une revue de la version (über) alpha...

 


J'en avais fait une première version, tout à fait fonctionelle et assez stylée, mais au moment de la reprendre pour l'améliorer, j'ai trouvé sa structure trop compliquée et j'ai décidé de reprendre from scratch avec pour objectif une appli en un seul fichier php...

 

 

La première version, jolie mais lourde et sans coloration syntaxique, statut public/privé etc)


 

Cette version 2 est donc reprise à zéro avec un cahier des charges précis: rester KISS, rapide, fonctionnelle, facile à adapter (thème/langue/code), elle doit permettre de diffuser facilement son code...

 

 

Actuellement, cette version alpha en est au stade suivant:

 

 

  • SnippetVamp en lui même tient en une page php de moins de 28ko.
  • J'ai de plus essayé de garder les css le plus light possible (même si je peux mieux faire lors le l'optimisation) et j'ai opté pour jquip (28ko) au lieu de jquery (trop lourd au regard des besoins) et pour highlight.js pour les mêmes raisons.
  • facile à reprendre: le code est assez clair pour être relu et amélioré sans se gratter la tête pendant une heure
  • les snippets ont un statut public/privé (public= acessible par rss, via le site ou un import)
  • les snippets peuvent être embedded via une simple commande $_GET  (inclusion dans un blog par exemple); les snippets embedded ont déjà une coloration syntaxique qu'on peut choisir ou redéfinir via css (dans la config)
  • les textes sont internationalisables (fr/en pour l'instant mais facile à traduire)
  • fonction de tags et de recherche rapide
  • coloration des tags via css pour les tags très utilisés ('php' 'jquery' 'python' par exemple ont une couleur spécifique qui facilite leur repérage)
  • le nuage de tags peut être classé par nombre de snippets ou par ordre alphabétique,
  • l'appli semble déjà assez rapide mais j'ai tout de même ajouté un cache dont le contenu n'est obsolète qu'en cas de modif ou d'ajout par l'admin,
  • compte admin créé simplement lors de la première utilisation,
  • configuration simple via un formulaire autogénéré,
  • page d'accueil listant les derniers snippets
  • design simple et responsive (la taille des fontes est encore à revoir pour les petits écrans, je garde ça pour l'optimisation des css),
  • des flux rss filtrés: comme dans shaarli, vous pouvez récupérer le flux de la page qui vous intéresse: seul le php vous branche ? Utilisez le lien rss de la page obtenue en cliquant sur le tag php... idem pour les recherches.
  • nom du fichier data configurable pour améliorer la sécurité (par défaut snippetvamp.dat)

J'aurais pu inclure le js et les css à l'appli elle-même, mais j'aurais perdu en lisibilité et temps de téléchargement ce que j'aurais gagné en compacité. En conservant un fichier css et des js hors du corps de l'appli, ils sont mis en cache lors de la première utilisation.

La structure actuelle est la suivante:

► SnippetVamp
  • ► styles/ (qui contient le/les style/s d'highlight.js)
  • ► theme/ (le css et le sprite)
  •   - snippetvamp.php
  •   - highlight.js
  •   - jquip-min.js

Lors de la première utilisation, SV créera les fichiers nécessaires à son fonctionnement: pass.php, config.dat et snippetvamp.dat


Sur ma road map, j'ai encore des choses à faire:

  • un vrai débuggage rigoureux,
  • une réorganisation des css pour en facilité la lisibilité et l'adaptation
  • une relecture et une optimisation du code (rationaliser et améliorer ce qui peut sans doute l'être),
  • un bookmarklet qui puisse permettre d'ajouter rapidement un snippet (voire qui permette de parser une page web à la recherche des pre/code)
  • des trucs assez évidents mais qui requièrent un moment d'attention quand même, du genre: si on change le nom du fichier dat, il faut bien le renommer au passage
  • une option de backup de l'appli (ou du fichier dat)
  • la possibilité de cocher plusieurs snippets et de créer un "pack"
  • peut-être une couche de sécurité supplémentaire en cryptant le fichier data.

Quelques screenshots, pour vous faire une idée...


Je créerai sans doute un dépôt GitHub dès que je considèrerai que ça vaut le coup de partager cette appli... Elle sera bien entendu distribuée librement avec ma bénédiction pour la forker à tour de bras

❝ 12 commentaires ❞

1  Tontof le

C'est super intéressant comme projet, j'ai une question qui concerne le fichier de data, pourquoi ne pas utiliser un fichier php comme shaarli ?
Vivement le repo sur git pour pouvoir tester tout ça

 
2  bajazet le

Sympa, j'utilise Codiad pour mes snippets mais c'est chiant. Le concept est sympa, c'est un peu un Shaarli mais pour le code.

 
3  Bronco le

@Bajazet: C'est tout-à-fait l'esprit, en effet


@Tontof: j'ai en effet hésité un moment entre un fichier data ou un fichier php pour le stockage; ce qui m'a fait pencher en faveur du data, ce sont les fonctions qu'Idleman a mises en ligne pour sauver des variables et qui compressent en même temps: après plusieurs tests, c'est rapide et simple à utiliser (http://blog.idleman.fr/?p=1722)
Ceci dit, je suis open aux idées, dans le domaine du stockage, comme dans les autres
Dès que ça me semblera un minimum utilisable, je ferai tourner

 
4  Tontof le

@Bronco: Je ne savais pas ce que tu utilisais comme stockage mais ça revient presque au même. L'avantage avec ton data, c'est qu'il peut être ensuite utilisé par n'importe quel langage comme c'est juste du gzip et du json... C'est peut-être un argument non négligeable. (par contre c'est minimun PHP 5.2 sinon faut fournir json_encode/decode)


Dans shaarli, il y a les serialize/unserialize qui limitent à PHP. Je pense que niveau perf, ça doit être plus efficace par contre avec le data de shaarli, mais c'est moins portable. (Ce serait intéressant de voir ce qu'il en est vraiment)


Sinon, il y a SQLite :-p
http://sebsauvage.net/links/?d7jVxA

 
5  Knah Tsaeb le

J'ai hâte de pouvoir tester ça. Comme je te l'avais dit dans un précédent commentaire, j'ai adapté un Shaarli pour qu'il gère mes snippets (http://shaarlet.knah-tsaeb.org), mais ton SnippetVamp me parait bien plus sympa.


C'est qu'en terme de gestionnaire de snippet, notamment sous Linux, c'est vraiment pauvre. Il y avait le projet d'Idleman (codez) avec un client desktop et une partie serveur, qui était plutôt prometteur, mais le projet à été abandonné.


Alors fait péter un dépôt Git pour qu'on s'amuse un peu (et qu'on te fasse remonter un tas de feature/bug/questions et aussi quelques patchs) .

 
6  Yosko le

Pour le format, je ne peux que plussoyer. Même si de mon côté je suis très partisant de SQLite, la méthode des fichiers plats (json et gzip) est sans doute la meilleure ici, puisqu'il n'y a point de modèle de données complexe.


Avec idleman, sur CodeZ, on avait aussi tablé sur du json (non dézippé au point où on en était), mais je crois me souvenir que c'était repris depuis notre source d'inspi première : CodeX.


Sinon, deux pensées pour ta roadmap :
1- avoir la possibilité de filtre sur 2 (ou plus ?) tags en même temps. Je pense à mon utilisation perso (mais qui pourrait servir aussi pour d'autre) : certains tags désignent le langage, certains tags désignent le type de module, et si on s'en sert pour le boulot, certains tags désignent le projet. Pouvoir filtrer sur au moins 2 d'entre eux serait intéressant je pense
2- Pour le bookmarklet : si l'idée de parser les pre/code est intéressante, ne t'y restreint pas. Nombreuses sont les pages où le code n'est pas dans ces balises.

 
7  Bronco le

@Tontof: En effet, la possibilité de gérer le fichier data via un autre langage par la suite (par exemple pour une appli desktop ) reste très intéressante. De plus, vu le volume à traiter, qui restera sans doute faible comparé à un shaarli, je pense que ça reste un bon choix... à voir à l'avenir et en fonction des perfs de la version utilisable en prod.


@Knah Tsaeb: Le dépôt GitHub est prêt je suis en phase de test pour certaines améliorations/bugs. Je fais péter asap .


@Yosko: SQLite est vraiment attractif et je pense que c'est clairement le format que je retiendrai à l'avenir pour les applis plus complexes ou gourmandes dans le stockage des données ou leur traitement.
1- Cette idée était sur mon cahier des charges au début et je l'avais laissée de côté en me disant que ça constituerait une évolution future: en effet, SnippetVamp était plutôt pour un usage perso au début et je dev surtout en php/js + css... Ta remarque est tout-à-fait pertinente.
2- Le bookmarklet était déjà un projet d'évolution de la première version de SV: comment ça doit être pratique de stocker des bouts de code en un ou deux clics !
Je pense que ce sera aussi une évolution à laquelle je me consacrerai sérieusement quand on aura une version stable et satisfaisante.

 
8  Yosko le

Dernière note sur le bookmarklet (mais tu y as sans doute déjà pensé) : garder, à la manière d'un shaarli, le lien vers la source, à la fois pour des raisons utiles et aussi par respect de parenté :)

 
9  Knah Tsaeb le

J'ai trouvé le dépot git, j'attend qu'il se remplisse maintenant.


"Tu vois, le monde se divise en deux catégories : ceux qui attende les sources d'un projet et ceux qui codent. Toi, tu codes."

 
10  Bronco le

@Yosko: C'est déjà le cas dans l'appli elle-même, tu peux préciser le lien de la source; il est clair que le bookmarklet stockera la page d'origine ;)


@Knah Tsaeb: hinhin fureteur la version dispo sur le dépôt est utilisable en l'état, mais des bugs peuvent subsister et elle est loin de la full featured version
De plus, j'attends d'avoir implémenté certaines fonctions pour procéder à des relectures du code (réorganiser, commenter mieux la version dev, vérifier les traductions, vérifier la sécurité etc)


Je pense que je vais devoir accélérer le mouvement, apparemment il y en a quelques-uns que ça intéresse (merci les gars, ça me touche ;)

 
11  Yosko le

Euh moi aussi j'ai trouvé le dépôt, mais il est vide, non ? ( https://github.com/broncowdd/SnippetVamp )
De toute façon j'attend ta version "officielle" :o)

 
12  ChristineCalvus22 le

Je vous remercie pour cet article, c'est exactement ce que je cherchais !!!

 

Fil RSS des commentaires de cet article

✍ Écrire un commentaire

les commentaires relevant du SPAM seront filtrés et dégagés direct...

Quelle est le sixième caractère du mot mzwj3h1 ?