protéger sqlite3 base de données

petit HS (marketing) sur ton dépôt git

Citation:

---

Envoyé par meslier

mettre l'appli en open

---

Pour faire de l'open source, il faut appâter le chaland (collaborateur) et ici rien n'est fait...
- bottle ? pourquoi utiliser un truc pas standard ? flask me parait proche au niveau code et tout dev web python connait flask (voir django). Si un dev web sur 500 connait bottle, c'est déjà diviser d'office par 500 le nombre de collaborations potentiels...
- le style ! parfois des tabulations ! pour éviter les PR a répétition sur chaque ligne pour un simple espace, voir pep 8...257. Perso, avec un style totalement "libre" je fuis car cela me donne tout de suite une très mauvaise image du développeur (et m'assure d'avoir plus tard des PR compliqués)
- bottle : pourquoi utiliser avec une grosse parcimonie les templates ? ! En serveur web, le seul modèle bien reconnu est MVC et ici rien pour les datas (comme le style, cela fait immédiatement fuir)

Donc, pour moi,
- le style et MVC et un minimum
- les tests ! c'est un must : ici on dit clairement aux autres développeurs que l'on est une personne sérieuse (peut l'être sans)


-------

Et savoir utiliser, comprendre un minimum git est une nécessité : ici, on ressent très bien la personne qui utilise git pour la première fois... (commits: delete fichier, commit le même fichier, delete même fichier, .... ) du coup on n'utilise même plus git, mais on l'utilise comme un simple ftp

Il est vrai que je suis novice. Pas pro, comme je l'ai dit. Candide, quoi ! Et comme je l'ai dit, j'ai déposé mon code parce que scalingo m'y encourageait. Donc, c'est vrai, je ne cherche pas forcément le "chaland". Mais le fait qu'on puisse me donner des conseils, comme là, est très utile. J'utilise Bottle parce que c'est archi simple, donc idéal pour un novice. Mais je songe éventuellement à me mettre à plus courant. Avant cela, je vais aboutir ce projet dans ces conditions, et je ne migrerai vers un autre framework que si le succès de mon blog m'y oblige (je me fais du souci avec le fait que c'est mono-thread. Mais d'après ce que j'ai lu, on peut adosser un programme Bottle sur un serveur sérieux. Si le succès du blog fait que ça rame, là je changerai, soit en adossant sur Apache, soit en traduisant en Django. J'ai vu qu'il y avait un cours sérieux sur OC.

Qu'est-ce que tu appelles le style ? Par exemple le fait que je cause pas anglais ? Là encore, il faut comprendre le paradoxe de ma mise en open à moi ! Scalingo me l'a demandé, et j'ai trouvé que c'était bien d'avoir des conseils (d'ailleurs, je suis servi !). Je ne cherche pas forcément de collaborateurs. Mais songe qu'avec un novice qui mérite autant de reproches, il faut être plus pédagogique ! Par exemple, je pige pas ce que c'est que les PR.

"parfois des tabulations ! pour éviter les PR a répétition sur chaque ligne pour un simple espace"

Je pige pas de quoi tu parles ! Moi, il faut partir de zéro ! Est-ce que tu parles de ma fonction tabul ? C'est pour que le code html soit bien lisible. Sans elle, y avait aucune indentation, trouver un bug c'était mission impossible. Tout a été réglé avec. Toutes mes pages html sont écrites automatiquement, avec un programme de saisie du texte et des images qui est indépendant (en gros, tout ce qui est dans le dossier html avec des noms en clairs), et par l'appli elle-même (formulaires, et textes postés par les visiteurs, avec un nom aléatoire, je crois qu'il n'y en a pas pour l'instant, j'ai viré tous les essais que j'avais faits.)

J'utilise très peu de templates, il est vrai. D'une part ça porte à zéro à peu près le temps d'écriture de code html, et d'autre part, toujours pareil, je connais pas tout. Par exemple, Y a une fonction Template() dont je me sers pas, vu que j'en ai pas besoin. J'en suis resté aux premiers tutos que j'ai trouvés, et j'ai eu fort à faire pour venir à bout du cahier des charges que j'avais adopté.

Merci pour ton intérêt, et tes conseils, mais adapte-les à mon niveau, que je les comprenne ! Tu parles de mauvaise image, c'est juste un niveau d'amateur. Je suis amateur. Ça veut pas seulement dire que mon niveau est pas top, ça veut aussi dire que j'aime, que j'adore ça. Que je programme pour mon plaisir, en plus de l'utilité. Je bosse sans impératif de rentabilité. J'adore pondre un algo en réponse à tel ou tel besoin, au point même que des fois, je programme ce qui existe peut-être déjà !

Pour résumer : il faut être pédago et patient avec moi ! Et je suis preneur de reproches quand je les comprends ! Et faut accepter mon "style", puisque de toute façon, je ne cherche pas à recruter du monde.

PS : j'ai résolu le principal problème évoqué dans ce fil, en incluant le mot de passe dans un fichier .env, sur tes conseils ! Je dois demain inaugurer le gitignore pour y placer ce fichier .env, ainsi que la base de données elle-même, et aussi un journal auquel je ne pensais plus, mais qui lui aussi ne doit pas être exposé. Et j'ai haché les mots de passe utilisateur.

Qu'est-ce qu'on est bavard sur ce fil !

Bonne soirée, et encore merci.

Citation:

---

Envoyé par meslier

je suis preneur de reproches

---

Il n'y a aucun reproches :D, j'ai été aussi un débutant. Je n'ai parlé que de marketing open source : Si on désire un partage avec d'autres devs

style
C'est uniquement la présentation du code
pour un code perso, pas forcément utile, mais pour un travail en groupe (société, club, opensource), on doit tous adopter le même style/présentation pour faciliter la lecture aux autres.
j'ai donné 2 références pep 8 (original) et pep 257 (fortement conseillé mais pas obligatoire). Existe des outils (intégrés dans les éditeurs spécifiques à python: black,autopep8,...) pour nous rappeler les règles, voir-même formater automatiquement notre code suivant ces règles.
Mon exemple était: utiliser parfois des espaces et parfois des tabulations pour faire des indentations (block: if, for, def...)

PR
c'est Pull Request : un autre développeur envoi une modification à ton dépôt git (modification qui peut-être un caractère comme 30 lignes)
Git, c'est un autre monde et, une usine à gaz


templates (MVC / Modèle Vue Contrôleur)
Dans ton code tu mélanges "tout" dans une seule fonction (exemple outils.py# publication()), normalement c'est:
- fonction pour requete au serveur (get Datas)
- fonction traite le résultat
- fonction: on injecte le résultat dans un template (la Vue)

les moteurs de templates ont un langage pour traiter nos données "brutes" avec des bouches FOR et des IF
avoir des fonctions setup.py#choisirCritere() ou setup.py#formulaireRechercheEditionSuppression(), listeMiniatures() ... c'est typiquement ce que fait un moteur de template
Ton code ... ce mélange, c'est typiquement ce que l'on faisait il y a 20 ans avec php (mais php était à l'origine un moteur de template!)

---------
Si ce code est "uniquement pour toi", il n'y a aucunement mort d'homme, juste des choses peuvent être améliorées (dans le temps) prochainement, il faut que tu regardes du coté de MVC ;)

C'est sûr que j'ai des tas de choses à apprendre. Pour l'instant, je souhaite surtout débuguer et optimiser ce que j'ai fait dans l'architecture actuelle. Ça marche pas mal, en fait. Le tout est assez simple, et à ses débuts tout au moins, concernera peu de monde, car mes thèmes ne sont pas commerciaux. C'est pourquoi je pense pouvoir gérer les imperfections architecturales.
Cependant, comme j'ai en tête des tas d'extensions, surtout dans le domaine de l'enseignement des maths, l'implémentation de jeux à plusieurs, etc., il est possible dans l'avenir que la complexité grandissante me contraigne à repenser cette architecture. Mais je n'en suis pas là pour l'instant.

Le mot "reproche" était pas bien choisi. "critique" convient mieux !

Citation:

---

Envoyé par meslier

il est possible dans l'avenir que la complexité grandissante me contraigne à repenser cette architecture

---

Ici, l'architecture est "ce qu'il ne faut pas faire", donc si tu comptes encore investir du temps (pas mal de temps) sur ce projet, il ne faut pas remettre au lendemain (sinon c'est avoir gaspillé beaucoup de temps pour rien)