Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 18
В недостатки нужно еще добавить, что такое имя файла будет нечитабельно во многих файл–менеджерах (будет свернуто).
Ну и лично мне удобнее пользоваться мета-информацией.
Ну и лично мне удобнее пользоваться мета-информацией.
1. Идея в том, что файл-менеджерами пользоваться в таком случае просто нет необходимости. В OS X все видно в окне Spotlight или, например, Alfred:
2. А почему именно удобней пользоваться мета?
2. А почему именно удобней пользоваться мета?
Потому что такие имена файлов мне ни к чему, файлами еще приходится делиться с окружающими.
Да и мета отлично ищется spotlight-ом и иным софтом.
Да и мета отлично ищется spotlight-ом и иным софтом.
вот уже в вашем примере видно, что если параметров будет больше, ну еще парочку добавить, то они и в строку альфреда не влезут. Либо надо добавлять их в конце файла, а не в начале. А еще бывают такие веселые вещи, как максимальная длина пути. Или максимальная длина имени файла, когда начинает пихать различные удобные для поиска вещи в название файла думаешь что это все глупость, и предел тебе не грозит, а потом приходиться идти на уступке, что приводит к общей бессмысленности всей этой затеи. К тому же в метаданные можно много чего записать. Как это делают те же браузеры в маке, например очень удобно искать файлы по тому откуда ты их скачал. ^_^
Да, метаданные не копируются на другие фс, да даже на флешку не перекинешь. Когда то давным давно было у меня светлое желание хранить метаданные в потоках ntfs. Но реальность оказалась уж больно жестокой.
Можно класть метаданные в отдельные файлы, и чтобы софт их считывал, но тоже не лучший вариант, потому что не факт что скопируя у тебя файл пользователь захватит этот файл. И вот тут начинаются уже более хитрые и сложные решения. :(
Да, метаданные не копируются на другие фс, да даже на флешку не перекинешь. Когда то давным давно было у меня светлое желание хранить метаданные в потоках ntfs. Но реальность оказалась уж больно жестокой.
Можно класть метаданные в отдельные файлы, и чтобы софт их считывал, но тоже не лучший вариант, потому что не факт что скопируя у тебя файл пользователь захватит этот файл. И вот тут начинаются уже более хитрые и сложные решения. :(
Практика показывает, что серьезных интерфейсных сложностей нет. Во-первых, параметров редко бывает много. Во-вторых, при поиске через Spotlight доступен предпросмотр. В-третьих, одним кликом открывается все найденное в Finder (там обычно лишь несколько позиций), где видно всю строку.
ну так если бы это были метаданные, то прямо в поиске по спотлайт можно было выбрать, без открытия в файндере. поскольку метаданные не забивили бы обзор, тот же файндер кстати тоже не резиновый, хотя окно пошире открыть, и столбец по максимуму расширить — это вариант, но в целом как то не то. А что делать с этим файлом и этой папкой в дропбоксе, на телефоне, если нужно что то найти? ;) поле с именем файла на телефонах не такое уж и широкое.
где видно всю строкуЗависит от того как настроен Finder. У меня вот он всегда в режиме Icon. И такое имя файла превратиться в непонятный набор символов.
Менять привычки весьма сложно.
Не вижу никакой выгоды от вашего метода.
Искать по метаданным удобнее, хоть spotlight-ом хоть сторонним софтом.
Способы синхронизировать файлы с метаданными существуют. И при этом не надо никак манипулировать с самими файлами.
Но если вы получаете профит от данного метода – это замечательно.
хм, а не подскажете способы синхронизации файлов с метаданными? .ds_store копировать?
.ds_store – это лейоут папки, а не метаданные.
Метаданные синкаются btsync, rsync (с флагом -Е). По крайнее мере у меня синкались.
Хотя я в основном пользуюсь специализированным софтом и синкаю его базу.
Метаданные синкаются btsync, rsync (с флагом -Е). По крайнее мере у меня синкались.
Хотя я в основном пользуюсь специализированным софтом и синкаю его базу.
ну в ds_store иногда часть метаданных пишется. Например комментарии spotlight'а :)
Про то что btsync синхронизует метаданные это интересно, не знал этого. касательно rsync'a честно говоря есть сомнение, если синхронизировать каталог например не с HFS.
А не поделитесь каким софтом, для каких целей и как именно пользуетесь, было бы интересно узнать.
Про то что btsync синхронизует метаданные это интересно, не знал этого. касательно rsync'a честно говоря есть сомнение, если синхронизировать каталог например не с HFS.
А не поделитесь каким софтом, для каких целей и как именно пользуетесь, было бы интересно узнать.
ну в ds_store иногда часть метаданных пишется. Например комментарии spotlight'а :)Честно говоря я не помню, но в любом случае этот файл имеет отношеное только к директории, не к файлам.
Про то что btsync синхронизует метаданные это интересно, не знал этого.Поройтесь у них на форуме, там есть отдельные топики, посвященные этому.
касательно rsync'a честно говоря есть сомнение, если синхронизировать каталог например не с HFSЯ не пробовал синхронизацию с «не HFS».
Ну, например, Dropbox это как–то решил (сомневаюсь, что они пользуются HFS).
И да, Dropbox (как минимум частично) и iCloud также синхронизируют метаданные.
В последнее время практически ничем не пользуюсь, достаточно родного spotlight.
Раньше активно пользовался HoudahSpot и Punakea, в основном для работы с книгами и фото.
Тут есть хоть и устаревший, но неплохой список приложений.
Именуя файлы таким образом вы потратите больше времени чем при обычном поиске/повторном скачивании из интернета.
Если это текстовый/офисный документ тут все очень просто: стандартный локальный поисковик (они сейчас хорошие во всех ОС) или уже grep/find.
Если это медиаконтент — очевидно он будет лежать либо в Downloads, либо в какой-нибудь папке Videos/Movies/Music, причем с датой добавления, есть превьюшки, иногда даже вразумительные имена файлов (что не критично) обычно ищется за пару минут в самом худшем случае.
Если же это скрипт или код — советую использовать git + GitHub/Bitbucket/etc. никогда ничего не потеряется.
Это я молчу про проприетарные штуки как например теги в OSX и разные стандартные медиатеки. Мне кажется все эти проблемы с потерей файлов весьма надуманы и иллюзорны.
Что я упустил? Зачем истязать себя и тратить время?
Если это текстовый/офисный документ тут все очень просто: стандартный локальный поисковик (они сейчас хорошие во всех ОС) или уже grep/find.
Если это медиаконтент — очевидно он будет лежать либо в Downloads, либо в какой-нибудь папке Videos/Movies/Music, причем с датой добавления, есть превьюшки, иногда даже вразумительные имена файлов (что не критично) обычно ищется за пару минут в самом худшем случае.
Если же это скрипт или код — советую использовать git + GitHub/Bitbucket/etc. никогда ничего не потеряется.
Это я молчу про проприетарные штуки как например теги в OSX и разные стандартные медиатеки. Мне кажется все эти проблемы с потерей файлов весьма надуманы и иллюзорны.
Что я упустил? Зачем истязать себя и тратить время?
1. Повторное скачивание из Интернета возможно, если вы знаете точно что вы ищите. А если вам просто нужны стоящие статьи по теме, которые когда-то попались на пути? Можно бесконечно раздувать список ReadLater, а можно просто отнести статью к определенной задаче и сохранить. Собственно, только такие вещи и надо сохранять. Ну, еще и те, что хочется иметь локально.
2. У меня много текстовых документов. Поиском по текстовому содержанию не удается обойтись. Но, вероятно, тут уже у кого как работа устроена.
3. Медиаконтент — в общем согласен. Я его вообще не храню. Бывает, правда, если хороший ролик, просто помечаю webloc-файл определенной эмоцией и сохраняю его. Потом приятно посмотреть что-то давнее, что зацепило.
4. Исходные коды — капля в море.
5. Про теги — в статье сказано.
6. Мне кажется, что главная сложность в непривычности. Это вообще не отнимает время. Файлы все равно именуются и размещаются где-то. Тут просто предлагается это делать системно.
2. У меня много текстовых документов. Поиском по текстовому содержанию не удается обойтись. Но, вероятно, тут уже у кого как работа устроена.
3. Медиаконтент — в общем согласен. Я его вообще не храню. Бывает, правда, если хороший ролик, просто помечаю webloc-файл определенной эмоцией и сохраняю его. Потом приятно посмотреть что-то давнее, что зацепило.
4. Исходные коды — капля в море.
5. Про теги — в статье сказано.
6. Мне кажется, что главная сложность в непривычности. Это вообще не отнимает время. Файлы все равно именуются и размещаются где-то. Тут просто предлагается это делать системно.
Любые файлы, даже названные вот так, надо время от времени пересматривать, что то убирать, что то добавлять, какие то категории поправлять, это будет постоянно происходить. В итоге на поддержание этого всего в актуальном состоянии времени будет уходить много. И все это покроется пылью, когда выяснится что найти все это в поисковике банально быстрее чем на локальной машине. Что приведет к тому что информацию вы сами же и перестанете сохранять. Или именовать, ну и так далее.
Да, любые системы это очень индивидуально, кому то очень удобно работать с Evernote, кто то как не пытается не может с ним работать.
Списки ReadLater бессмысленны если их не чистить, а прочитанное не переносить в какую то систему знаний. Поиск по тексту файла к сожалению не сравнится с тем как ищут поисковики, постоянно совершенствуясь, а также пользователи которые пишут на книги рецензии, оставляют отзывы, и в итоге вероятность найти то что нужно в сети часто опять же оказывается быстрее.
Файлы не должны именоваться, идеальная ФС эта та о которой пользователь не знает. Кстати хранить все в одном каталоге может вызвать некоторые проблемы с производительностью.
Именование по дате? Вот у вас есть файл, вы его сохранили неделю назад с соответствующей датой в имени, затем что то поправили в нем, должна ли дата быть свежей? или старой? А если вы забудете переименовать?
И так про многое можно сказать. Вопрос организации домашней базы знаний только кажется простым, чем дальше в лес тем больше косяков. Множество копий сломано, а никаких идеальных решений нет :( Все субъективно и криво. Вон KDE их Nepomuk лет семь назад запускали, а толку, всем плевать :( Хотя закваска была неплохая, но как раз невозможность обмениваться метаданными между системами и губит все.
Да, любые системы это очень индивидуально, кому то очень удобно работать с Evernote, кто то как не пытается не может с ним работать.
Списки ReadLater бессмысленны если их не чистить, а прочитанное не переносить в какую то систему знаний. Поиск по тексту файла к сожалению не сравнится с тем как ищут поисковики, постоянно совершенствуясь, а также пользователи которые пишут на книги рецензии, оставляют отзывы, и в итоге вероятность найти то что нужно в сети часто опять же оказывается быстрее.
Файлы не должны именоваться, идеальная ФС эта та о которой пользователь не знает. Кстати хранить все в одном каталоге может вызвать некоторые проблемы с производительностью.
Именование по дате? Вот у вас есть файл, вы его сохранили неделю назад с соответствующей датой в имени, затем что то поправили в нем, должна ли дата быть свежей? или старой? А если вы забудете переименовать?
И так про многое можно сказать. Вопрос организации домашней базы знаний только кажется простым, чем дальше в лес тем больше косяков. Множество копий сломано, а никаких идеальных решений нет :( Все субъективно и криво. Вон KDE их Nepomuk лет семь назад запускали, а толку, всем плевать :( Хотя закваска была неплохая, но как раз невозможность обмениваться метаданными между системами и губит все.
Спасибо за обстоятельный комментарий. Я сейчас понимаю, что многие важные вещи не сказал в статье.
1. Эту систему не нужно актуализировать в общем случае. Система на это не провоцирует, скрывая все файлы в общей куче. Изредка, нужно только править обнаруживаемую нецелостность (например, если обнаружили, что у Вас два значения параметра для одного и того же). Но это бывает действительно редко. По опыту двух лет такой работы могу это сказать.
2. Я совершенно согласен с тем, что если что-то можно эффективно найти в гугле, то незачем сохранять. Но это не про предложенный подход. Ибо если незачем сохранять, то никакой подход неактуален.
3. Список ReadLater обычно всегда безгранично разрастается. Это по сути очередной Inbox. Я просто предложил прием держать этот Inbox в состоянии Zero изначально.
4. Хорошо бы, если бы файлы не надо было именовать. Но это невозможно. Например, я хочу иметь возможность отобрать все свои идеи по проекту, которые меня посещали. Если я не маркирую их «o=thought», я их потеряю. А это реально сильно парит.
5. Дату, как и прочее, трогать никогда не приходится. Я ее использую как дату создания содержания впервые, таким образом она неизменной остается.
6. Главная фишка подхода — он предлагает что внести в имя, то есть предлагает ответить на три главных вопроса. Nepomuk, он не про это. Эту главную фишку подхода можно даже использовать с Nepomuk.
7. Проблемы с производительностью действительно могут быть. У меня пока нет. Но это не проблема: можно создать папку на год. Важно, что останется преимущество: вы не осуществляете навигацию по каталогам.
1. Эту систему не нужно актуализировать в общем случае. Система на это не провоцирует, скрывая все файлы в общей куче. Изредка, нужно только править обнаруживаемую нецелостность (например, если обнаружили, что у Вас два значения параметра для одного и того же). Но это бывает действительно редко. По опыту двух лет такой работы могу это сказать.
2. Я совершенно согласен с тем, что если что-то можно эффективно найти в гугле, то незачем сохранять. Но это не про предложенный подход. Ибо если незачем сохранять, то никакой подход неактуален.
3. Список ReadLater обычно всегда безгранично разрастается. Это по сути очередной Inbox. Я просто предложил прием держать этот Inbox в состоянии Zero изначально.
4. Хорошо бы, если бы файлы не надо было именовать. Но это невозможно. Например, я хочу иметь возможность отобрать все свои идеи по проекту, которые меня посещали. Если я не маркирую их «o=thought», я их потеряю. А это реально сильно парит.
5. Дату, как и прочее, трогать никогда не приходится. Я ее использую как дату создания содержания впервые, таким образом она неизменной остается.
6. Главная фишка подхода — он предлагает что внести в имя, то есть предлагает ответить на три главных вопроса. Nepomuk, он не про это. Эту главную фишку подхода можно даже использовать с Nepomuk.
7. Проблемы с производительностью действительно могут быть. У меня пока нет. Но это не проблема: можно создать папку на год. Важно, что останется преимущество: вы не осуществляете навигацию по каталогам.
БЭМ для файлов?
Примерно тоже самое, только применяю к каталогам — а файлы внутри уже по обстановке.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Эффективное управление личными файлами