Aléatoire 'concerne' les dossiers et les fichiers '.keep'

J'apprends les rails.

Quelque part le long de la ligne, j'ai remarqué que des dossiers et des fichiers apparemment aléatoires apparaissent dans le répertoire de mon application rails. Dans certains dossiers, il y a un concernsdossier contenant un .keepfichier. Le .keepfichier semble vide. Dans les autres dossiers, il n'y a pas de concernsdossier mais un .keepfichier vide est présent.

Quelqu'un sait-il quel est le problème avec ces fichiers / dossiers?

.keepLes fichiers sont des fichiers de 0 octet qui sont là pour empêcher les dossiers vides d'être ignorés par toutes sortes de processus. Pas d'inquiétudes à avoir.

Les fichiers .keep sont particulièrement utiles lorsque vous souhaitez valider des répertoires vides avec git.

Fait amusant, le nom .keepou .gitkeepn'a pas de sens. vous pouvez appeler le fichier .foopour le même effet, c'est simplement une convention lisible.

Les .keepfichiers sont également là pour faciliter le portage d'un vcs à un autre, empêchant la suppression de répertoires importants lorsque vous annulez la fusion de quelque chose qui rendrait ces répertoires vides.

Par exemple, considérons un script qui tente d' cd diraccéder à un répertoire non suivi par git.

C'est un paradigme de conception de logiciel qui cherche à réduire le nombre de décisions que les développeurs doivent prendre, en gagnant en simplicité, mais sans nécessairement perdre en flexibilité.

Concerns est un concept simple mais puissant. Il existe pour la réutilisabilité du code. Fondamentalement, l'idée est d'extraire des morceaux de code communs et / ou spécifiques au contexte afin de nettoyer les modèles et d'éviter qu'ils deviennent trop gros et ingérables.

Je voudrais spécifier explicitement que vous devez utiliser des objets de service pour fournir des fonctionnalités qui ne concernent pas l'objet spécifique. Par exemple, une organisation a de nombreux utilisateurs. L'administrateur de l'organisation doit maintenant exporter un fichier CSV de tous les utilisateurs de cette organisation. Ce code peut être placé dans le modèle d'organisation, mais comme ce n'est pas la responsabilité de l'objet d'organisation, ce code doit être placé dans une classe où vous passez simplement l'objet d'organisation et il renvoie le CSV de tous les utilisateurs.

 class Services::GenerateCsv
     def self.get_users org
         #add logic the fetch users for the org and generate the CSV and return the CSV data
     end
 end

Chaque fois que vous avez besoin de la génération CSV, vous pouvez placer cette logique dans la classe ci-dessus. Cette approche maintient l'objet (dans ce cas, le modèle d'organisation) propre du code qui ne devrait pas être de sa responsabilité. Un principe général que je suis: si le code modifie l'objet self, déplacez le code vers un objet de service.

Remarque: votre question concernait des préoccupations, mais j'ai pensé à ajouter des éléments supplémentaires que je suis pour garder la base de code propre et gérable car cela pourrait aider d'autres programmeurs. Cette approche ci-dessus est discutable.