Liste des fonctions de développement souhaitées

De Traduction du Wiki diaspora* (non officiel)
Aller à la navigation Aller à la recherche


»» Obsolète
L'exactitude de cette page peut être compromise en raison d'informations périmées.Veuillez aider à améliorer la page en la mettant à jour d'abord sur le site officiel puis ici. Il peut y avoir des informations supplémentaires sur la page de discussion.


Bookmark.png »» Note

Cette page date de 2013, donc quelqu'un devrait vérifier si la liste contient toujours des points utiles. Si ce n'est pas le cas, elle devrait être soit mise à jour, soit supprimée. Nous avons également une autre liste sur le Développement actuel et futur. (que j'ai partiellement mise à jour) ; peut-être pourraient-elles être fusionnées en une seule liste. --waithamai 06:38, 17 août 2017 (UTC)


Vous trouverez ci-dessous une liste de fonctionnalités pour lesquelles l'équipe principale du projet Diaspora aimerait avoir de l'aide.

Si vous choisissez l'une de ces fonctionnalités, un membre de la team vous aidera à faire fusionner votre pull request. C'est une façon rapide de s'impliquer dans la base du code de Diaspora*.

Les développeurs de la communauté sont plus que bienvenus pour plonger et travailler sur ces éléments à tout moment, veuillez contacter la liste de diffusion à propos de n'importe quel élément de la liste ci-dessous pour lequel vous aimeriez aider. N'hésitez pas non plus à vous joindre à nous et à aider d'autres développeurs sur des projets existants.

Les éléments "En développement" seront liés par un fil de discussion aux groupes Google, afin d'encourager la collaboration et d'éviter la duplication des efforts.

1) Refactor AppConfig et EnviromentConfiguration (en cours).

AppConfig est la classe actuelle qui gère le chargement des paramètres de Diaspora à partir de application.yml. Elle est devenue un peu une bête, se souciant de l'état de démarrage, de la gestion des données, et de quelques aides connexes. Le temps de la nettoyer est venu ! Nous devrions déplacer toute la logique hors de AppConfig, et la laisser être juste une classe SettingsLogic. Ensuite, nous devrions accéder à tout via EnvironmentConfiguration, en déléguant les clés appropriées à AppConfig.

2) Contribuer à faciliter la tâche des autres développeurs

De nombreux projets disposent d'un script qui permet de faire fonctionner facilement un environnement de développement. Il serait génial d'avoir un script qui démarre l'environnement minimum nécessaire pour exécuter toute la suite de tests. Ainsi, il serait facile pour les nouveaux développeurs de cloner le dépôt, d'exécuter le script et de lancer les tests, le tout en une seule fois. Pour commencer, ce qui devrait rendre ce processus transparent pour les trois environnements suivants (nous pourrons ensuite travailler sur quelque chose de plus général : 1) Mac OS X ; 2) développement Ubuntu ; 3) configuration d'une machine virtuelle (nous pouvons héberger la machine finale).

3) Retravailler les fonctionnalités de Cucumber

Vous voyez ça ? Vous voyez maintenant à quel point c'est pire ? Beaucoup de nos cukes sont désordonnés, ce serait génial si quelqu'un avec un grand sens de la clarté du code pouvait refactoriser certaines des fonctionnalités. Si vous voulez aller plus loin, travaillez avec Dennis et identifiez les tests qui seraient mieux dans Jasmine, ou les tests unitaires pour gagner du temps sur la suite également.

4) Refactoriser les contrôleurs

Il y a un tas de choses qu'un développeur Rails expérimenté pourrait faire ici. Utiliser plus de rescue_froms pour réduire les branchements, décomposer les actions vraiment importantes en objets qui sont délégués , ou simplement améliorer et remplir les tests. Ce n'est pas la chose la plus glamour de cette liste, mais ce serait très apprécié.

5) Améliorer l'interface d'administration

Nous avons déjà l'administration de rails en cours d'exécution. Elle pourrait encore avoir besoin de quelques ajustements de configuration. Nous pourrions faire quelques pages statiques, et déplacer certaines de nos fonctionnalités personnalisées vers le côté rails_admin des choses. D'autres idées concernent le webfingering basique d'autres outils de développement de pods, l'affichage de la liste des pods connectés, et l'ajout de liens vers des choses comme le statut de resque, etc etc.

6) Personnalisation des pods (en cours)

Nous discutons de la façon de transformer certaines variables en chaînes de caractères afin de faciliter la personnalisation des pods pour les podmins sans avoir besoin de bifurquer du code principal. C'est un excellent point de départ pour déterminer comment personnaliser davantage un pod.

7) Enregistrer les dimensions de l'image avec chaque fichier image

Besoin de mettre à jour Carrier-Wave, et d'inclure un hack dans le wiki Carrier-Wave.

8) Corriger les retards de traitement d'image BS

Lié au numéro 7. Demandez à Max pour plus d'informations.

9) Courriel de bienvenue

Après l'inscription d'un utilisateur, envoyez-lui un e-mail contenant des informations utiles.

10) Nettoyer le dossier des images (en cours)

Il y a beaucoup d'images inutilisées là-dedans dont nous n'avons pas besoin, donc c'est un peu un gaspillage d'espace.

11) Améliorations de Carrier-Wave

Faire en sorte que Carrier-Wave télécharge vers un répertoire /tmp pour les tests, et nettoie quand c'est fait.

12) Améliorer le site mobile '(FAIT)

Actuellement, notre site mobile est relativement simpliste, et pourrait être modifié pour être plus accessible. Une discussion doit avoir lieu pour déterminer quelles nouvelles fonctionnalités seraient souhaitables.

13) Ajouter des tests à cette demande de pull

Ceci nous a été fourni par un utilisateur. Il s'agit d'une correction relativement simple, mais le contributeur n'a pas été en mesure d'écrire des tests pour celle-ci. Aidons cette personne et faisons en sorte que cela puisse être intégré !

14) Documenter le code.

Documentez le code existant et pensez également à documenter votre code autant que vous le pouvez lorsque vous nous envoyez une demande de modification. Cela aide les autres qui forkent le dépôt à le comprendre et à travailler dessus.

Nouvelles choses à faire

Ces choses devaient être réparées sur place. A partir d'une conversation entre @raven24 et @maxwell

Evil query …. utilise les scope_operators de Makrio (à propos, la quantité de commentaires de code en ligne n'est probablement pas assez - TOO DAMN HIGH# - Je pense que nous devons vraiment faire en sorte que la réflexion se fasse à la source, une rdoc pour (la plupart) du code pourrait être utile pour les nouveaux développeurs...) mettre un peu de sagesse SQL là-dedans.

→ donc, peut-être qu'une présentation des parties de la requête diabolique pourrait être utile (bientôt).

Batch utilise plus find_each -> éventuellement avec le commutateur Resque/Sidekiq - boucle de réception - boucle d'émission.

Dé-fuckifiez-les - n'essayez pas d'utiliser plus de magie que ce que nous pouvons réellement gérer. Mieux vaut un code plus verbeux qu'un désordre qui cause des problèmes - découplez-les complètement de l'état de la fédération. déplacez la fédération vers json ? Peut-être recommencer ? thème général essayer de penser à des phases discrètes ? - Découpler la mise en page de la base de données de la sérialisation des objets de la structure des messages du protocole. - être libéral dans la création de classes ruby multiples - sérialiser vers un présentateur en mémoire, qui décharge vers un objet ORM - permettre à l'état de la base de données d'atteindre à travers les objets en mémoire.

  1. recevoir le message
  2. valider l'enveloppe, analyser le json, mettre dans la file d'attente =&gt ; retourner la réponse actuelle ...

Traitement en arrière-plan Resque => Sidekiq advantage: threads au lieu de processus, moins de mémoire, plus amusant travail potentiel pour les jeunes développeurs, API similaire.

Mise à jour de Rails - gems - sécurité !