Esiste: un modo standardizzato di documentare una struttura di file system

Al lavoro, mi occupo di mantenere l'organizzazione di molti dati diversi su un file system standard. Parte di ciò sta arrivando a una classificazione ragionevole (per somiglianza, necessità, accesso in lettura / scrittura, ecc.), Ma la parte più grande lo sta effettivamente documentando: quali documenti / file / media dovrebbero andare dove, cosa non dovrebbe essere in questa directory, "per qualcosa di leggermente diverso, vedi ../../other-dir", ecc.

Al momento, ho documentato questo usando un file readmein chiaro in ogni directory che voglio documentare. Se qualcuno non è sicuro di cosa si debba trovare in una directory, legge quel file.

Funziona bene, ma mi sembra strano che io abbia questa soluzione personalizzata primitiva a un problema che ogni manutentore di una struttura di directory non banale deve sperimentare. Ogni azienda che ho conosciuto, ad esempio, ha una sorta di file system condiviso in cui la terminologia concordata per la categorizzazione è importante. In base alla mia esperienza, le persone devono solo imparare cosa è ciò che provano e provano errori e sperimentazioni.

Quindi permettimi di proporre una soluzione migliore, e spero che tu possa dirmi se esiste. Qualsiasi directory su qualsiasi filesystem può avere un file di testo in chiaro nascosto chiamato .readme. I suoi contenuti sono in linguaggio umano descrittivo. Utilizza alcuni markup come Markdown, con poco più di collegamenti ipertestuali grassetto, corsivo e (relativi) ad altre directory. Ora un browser di file abilitato opportunamente controllerà un file chiamato .readmeogni volta che visualizza una directory. Se esiste, i suoi contenuti vengono analizzati e visualizzati in un riquadro discreto vicino al widget del percorso di directory. È possibile fare clic su qualsiasi collegamento al suo interno e l'utente verrà portato nella directory di destinazione di quel collegamento.

Penso che lo sforzo di attuare un simile standard ripagherà molte volte i guadagni di usabilità. Ad esempio, avremmo plugin per Nautilus, Konqueror, ecc. Potrebbe essere usato per visualizzare le informazioni della directory negli elenchi di file standard forniti dai server web. E così via.

Quindi, domanda: esiste una cosa del genere? In caso contrario, perché no? La gente pensa che sia un'idea utile?

Per quanto ne so non esiste uno standard. Ecco alcune idee della mia esperienza.

Installalo, non cambiarlo mai

Questo è dove la maggior parte delle aziende falliscono. Niente è peggio di una struttura del file system in continua evoluzione. Se non è possibile mantenerlo costante, un file system puro è solo il contenitore sbagliato per organizzare le tue informazioni. Utilizzare un database o un sistema di gestione dei contenuti.

Utilizzare nomi di directory descrittivi e coerenti

Nessuno ha il tempo di leggere un .filingfile o altro. Se i nomi delle tue directory non si spiegano da soli, probabilmente ti perderai comunque.

Scrivi una documentazione per la tua struttura di directory

Scrivi un documento in cui spieghi il ruolo di ogni directory. Fai molti esempi. Rendilo disponibile a chiunque debba lavorare con la tua struttura, ma non credere che nessuno lo leggerà. Dovrebbe essere più simile a una Bibbia per te. Non è facile trovare un esempio per un simile documento, perché ovviamente le aziende non li pubblicano. Un esempio del software open source è il Filesystem Hierarchy Standard .

Se questo suona un po 'negativo, lo è. Non ho mai visto un repository non banale basato su un file system con più di cinque utenti che lavorano a lungo termine in pratica. Il problema è che, indipendentemente dalle categorie che imposterai, le persone avranno idee completamente diverse su di esse. Quindi, per rispondere finalmente alle tue domande:

Esiste una cosa del genere?

No, non la penso così.

In caso contrario, perché no?

Secondo me: per una piccola gerarchia statica con pochi utenti è eccessivo. Per una grande gerarchia che cambia con molti utenti non funzionerà perché l'idea delle categorie (= directory, cartella) non si ridimensiona.

La gente pensa che sia un'idea utile?

Hm, è un'idea interessante. Per vedere se le persone lo useranno, qualcuno deve implementarlo. Invece di un .filingfile è possibile archiviare tali informazioni in un flusso di dati alternativo (sì, anche le cartelle possono avere ADS). È possibile utilizzare attributi estesi su Linux e OSX. Il problema più grande sarebbe probabilmente quello di patchare i browser dei file.

il wasabi vale la pena provare. Alla radice del progetto, la fonte in testo semplice fungerà da solida panoramica del progetto e puoi lanciare lo stesso documento in un browser per ottenere risultati più elaborati.

Certo, non è una soluzione basata su filesystem, ma fino a quando tutti i filesystem in circolazione non supportano qualcosa di comune, wasabi (o la tua implementazione) potrebbe essere l'opzione migliore.

La tua idea ha qualche merito, ma temo che quando hai bisogno di qualcosa del genere significhi davvero che hai bisogno di qualcosa di più strutturato. Cioè un CMS, forse solo leggero, ma sicuramente qualcosa di più di un semplice file testuale.

Soprattutto se si desidera limitare la scrittura (o persino l'accesso) a documenti specifici (e quindi alle relative cartelle) ad alcuni sottogruppi della base utenti.

Non specifichi il tuo sistema operativo, ma esistono prodotti eccellenti (e gratuiti) come Alfresco che potrebbero servirti meglio della tua configurazione attuale.

Ecco un'idea. Scrivi uno script che ponga all'utente varie domande sul file e / o esegua una corrispondenza nel contenuto del file stesso, quindi consiglia l'ubicazione in cui inserire il file o inserendolo. Lo script può essere semplice o complesso come lo desideri.

Lo script funge da sistema di gestione dei file, sistema di supporto alle decisioni e documentazione vivente della gerarchia dei filesystem. Il Linux Filesystem Hierarchy Standard è un po 'un mito se ci pensate, perché c'è una grande varianza tra le distro. Tuttavia, la maggior parte degli utenti Linux / Unix non deve effettivamente conoscere la gerarchia del filesystem in quanto esiste un software installato nel sistema che gestisce la gerarchia in modo standardizzato (gestore pacchetti, strumento di configurazione, ecc.). Vari framework di applicazioni creano anche script per gestire le sue directory, ad esempio django ha comandi di gestione per creare un nuovo progetto, o un nuovo modulo di app, o schiacciare i file di migrazione, ecc.

Ciò ha l'ulteriore vantaggio che lo script può creare vari collegamenti simbolici se il file deve essere cercato in più di un modo, ad esempio un indice basato sull'autore del file o sulla data di creazione o su qualunque regola di business tu abbia. È possibile simulare la codifica con collegamenti simbolici. Un tag è un semplice collegamento simbolico da una tagsdirectory, quindi tags/mytag/myfilepuò essere un collegamento simbolico a actual/myfile.

Inoltre sarà anche possibile modificare la struttura della gerarchia del filesystem senza cambiare l'interfaccia utente.

Un filesystem è un database. Non un database relazionale, ma un database gerarchico. Pensaci come se gestissi un database, non vuoi davvero che le persone debbano imparare la struttura relazionale, ma piuttosto vuoi che l'applicazione si presenti all'utente come varie attività che devono fare (ad esempio stai facendo un mensile Rapporto XYZ, ottimo, quindi inseriscilo in questa cartella e crea questo link simbolico, quindi dovrai modificare un altro file per registrare che hai fatto il rapporto per questo mese, ecc.).