Чтение электронных книг — 2

[tengu_crow]

В предыдущей заметке о чтении, я разделил свои материалы для чтения на три основные категории: большие книги, мои собственные заметки (в виде Большого Текстового Файла) и "клипы" или "вырезки" - набор разношерстых html-страничек, посты, микротексты, микрозаметки и так далее. Если с большими книгами и большим файлом все было более или менее понятно, то промежуточная категория - заметки, "клипы" и вырезки, была совершенно неопределенной и требовала осмысления.

За прошедший год система чтения изменилась. Многие моменты назрели уже давно, фундаментальным поворотом стал момент, когда я оказался в Метрополии с очень плохим интернетом. Связь через некоторое время наладилась, но момент вынужденной автономности и некоторые исследования, попавшие в мое поле зрения, заставили задуматься.

читать дальше в wordpress'e


1. Закладки в браузере, в роли средства хранения информации, а не в роли опорных ориентиров для серфинга, бесполезны. Когда наступает оффлайн - 8802 закладок (на текущий момент), разумеется, оказываются мертвыми.

Кроме того, во время вынужденной "автономки" мне попалось интересное исследование - человек решил проверить, сколько его закладок времен 1997го живы сейчас или доступны через Wayback Machine. За 17 лет в реальном интернете потеряли актуальность 91% закладок. С помощью Wayback Machine процент потерь сократился до 45%. Я попробовал проделать нечто подобное - и получил примерно те же результаты.

Интернет меняется очень быстро и не стоит на месте. Wayback Machine спасает только частично. Кроме всего прочего, это тоже сетевой сервис, который тоже может "закончится" или "уйти в коммерцию" в неопределенный момент времени.

2. Практическим выводом из (1) стало решение хранить значимую информацию в оффлайне. От специализированного софта типа scrapbook, я решил отказаться, в пользу обычных файлов - сошлюсь на сэра vjoiller'а, который в свою очередь любит цитировать Артура Максимова о том, что файловая система - это лучший (и недооцененный) инструмент для хранения, сортировки и каталогизации информации.

3. В качестве формата хранения я уже давно использую MAFF - Mozilla Archive Format File. Это - стандартизованный формат файла-архива, по существу - zip-файл, внутрь которого складывается страница со всем сопутствующим содержимым - картинками, аудио, скриптами и т.д. и т.п. Их можно открывать через соответствующее расширение firefox, или за неимением такового просто распаковать архив и смотреть файлы любым браузером.

До этого я использовал MAFF-ы время от времени, теперь же перешел к массированному использованию для большой, упорядоченной системы хранения информации. Быстро стало понятно, что хранение страничек в виде файлов на диске, имеет преимущества перед закладками. Из замеченных эффектов - скорость обработки и перетасовки файлов по папкам возрасла на порядок и на ту же величину увеличилась логичность и интуитивность организации папок с архивами. При работе с закладками в браузере, они могут изрядно подтормаживать, а раскладывание файлов по папкам и переименование самих папок "дешево" относительно системных ресурсов. Еще очень упрощается "пропалывание" и "расчистка" стареющего и теряющего актуальность мусора.

Вопросы тэгов и каталогизации решаются раскладкой файлов по иерархическому дереву тем (not -> чтение -> maff-файлы). Дублирование одной заметки в разные темы тоже упрощается - благодаря хард- и софтлинкам. Мой firefox настроен так, что все maff-странички падают в папку maff внутри Dropbox'а, так что все архивы у меня синхронизируются на всех десктопах сразу. И доступны даже тогда, когда сеть отсутствует.

MAFF сохраняет дату и url исходной странички - соответственно всегда видно откуда и что было взято. Плагинка к firefox'у правильно именует сохраняемые файлы (т.е. задает осмысленное имя по заголовку странички - Notes on bookmarks from 1997.html.maff, а не 05dec9f04909d9b6edff.html как это было бы в ранней мозилле). Важно, что это происходит без дополнительных телодвижений с моей стороны. И всегда можно найти требуемую информацию, например, так:

vik@kit:~/zbox/Dropbox/maff$ find . -name "*book*"
./not/закладки/Notes on bookmarks from 1997.html.maff
./not/закладки/Notes on bookmarks from 1997 | Hacker News.html.maff
./doc/pandoc_book
...
./work/qemu/QEMU_FreeDOS - Wikibooks, open books for an open world.maff

MAFF понимает в том числе recoll который я использую в качестве "настольного поисковика", так что вся информация доступна в полнотекстовом поиске в любой момент времени.

Из недостатков - Android-версия Firefox пока MAFF не понимает. У нее есть свои средства хранения и чтения, но о них позже. Думаю, что разработчики все наверстают. Так что это не столько недостаток, сколько "хотелка".

Пожалуй, следующий этап - зачистка закладок в firefox. Я планирую оставить только те, которые (а) являются опорными для серфинга или захода на сервисы (б) закладки быстрого поиска (в) закладки-дела (посмотреть, послушать, почитать - у меня например есть прекрасная папка "смотреть долго и нудно").

4. Для чтения с читалки, я продолжаю использовать grubmybooks, однако "быстрый апдейт текущего чтения" через DropSync, оказался неоптимальным и начал утомлять. Упомянутый синк не отличался стабильностью. Синхронизируемые файлы часто теряли время сохранения, что делало бессмысленным сортировку заметок по дате поступления. Синхронизация требовала внимания и заставляла включать голову каждый раз, когда я цеплялся к wifi - "запустится - не запустится", "попросит денег - не попросит денег", "засинхронит - не засинхронит", "оставит дату или не оставит дату" и так далее. К тому же интерфес у этой софтины (во всяком случае в те времена) был на редкость неочевидным и непрозрачным.

Когда с этой софтиной что-то случилось и она перестала синхронизировать папки совсем, я не стал с ней бороться. Оказалось, что без сверхоперативного обновления заметок-клипов вполне можно жить. Отключение даже пошло на пользу - я переключился на чтение "больших книг" и умных вещей "с низким гликемическим индексом умственного переваривания".

Осознав все это, я снес DropSync насовсем вообще и начал обновлять папку с клипами-заметками "по шнурку" через Unison. Убедившись в том, что все работает как надо, я перешел к обновлению и синхронизации всей библиотеку целиком. Сам процесс накопления заметок не изменился. Для сбора заметок я использую grabmybooks, который бросает .epub-файлы в папку в дропбоксе. Благодаря этому все "клипы-вырезки" синхронизируются между моими десктопами - и во-первых, всегда под рукой, во-вторых я могу послать себе заметку для чтения с любого из компьютеров.

Я могу читать их на читалке, либо прямо в браузере - к firefox идет отличный epubreader. К тому же grabmybooks добавляет в заметку url, откуда она была сграблена и дату, так что, как и в случае с .maff-файлами всегда можно дотянуться до оригинала. Это актуально, когда что-то в заметке привлекает мое внимание и я хочу посмотреть на оригинал (и, возможно, сохранить его в maff).

Основная библиотека лежит на главном десктопе, в папке ~/book, которую я синхронизирую с помощью Unison "по шнурку" с папкой в читалке. ~/book/dropbooks - это софтлинк к дропбоксовой папке заметок и он обновляется сразу со всей библиотекой (Unison "знает" что ссылки надо синхронизировать тоже). Так что у меня на нуке всегда свежая папка с "клипами".

5. Все вместе.

Сейчас заметки-клипы хранятся в двух папках - dropbooks и maff, которые синхронизируются дропбоксом.

Общий критерий - epub для чтения и оперативного просмотра повсюду, maff для сохранения "почти точной копии" на десктопе. Что-то интересное попадает сначала в dropbooks в виде epub'а. Если оно оказывается достойным более глубокого изучения (или архивации на будущее) - в maff.

На практике очень быстро выяснилось, множество плюсов такой системы. Я избавился от проприетарной, надоедливой софтины. Начала устаканиваться библиотека - во многом благодаря тому, что изменения и на нуке, и на десктопе синхронизируются практически автоматом и есть возможность организовывать библиотеку как на десктопе, так и на нуке. Это важно, поскольку и там и там я обычно ищу по иерархии папок (почти как на полках в книжном шкафу) и теперь мне не нужно держать в голове два "дерева" папок.

Благодаря общей синхронизации я решил для себя вопрос с архивацией прочитанных заметок - завел в общей библиотечной папке директорию old_drop, куда в папки по датам сохраняю уже неактуальные клипы-заметки. Они не тратят пространства dropbox'а, уводятся из зоны внимания, но в то же время всегда доступны по любому из вариантов поиска - в том числе и recoll'ом

Повысилась оперативность обновления системы - DropSync не всегда хорошо справлялся с синхронизацией, даже при хорошем вайфае, часто ругался на какие-то внутренние разборки с Dropbox, словом требовал присмотра. По сравнению с этим, очень быстрый, прозрачный и практически "бесшовный" процесс синхронизации через Unison (что в командной строке, что через gui-фронтэнд) выглядит волшебством.

Все используемые форматы открытые, накопление и обработка информации происходят с одной стороны автоматически, с другой достаточно прозрачно, чтобы не терять контроля за процессом.

Last but not least, такая система вообще не требует вайфая и/или интернета - что очень пригодилось в "автономке". В частности, даже если dropbox не работает - я вполне могу носить архив на флэшке/мобильнике/читалке - и синхронизировать его на месте через тот же unison (вообще на редкость полезный инструмент).

Из дальнейших планов - настроить работу unison через ssh - чтобы добавить гибкости. Принципиально система ограничена 2Гигабайтами дропбокса или 12ю гигабайтами Яндекс.Диска - учитывая 32Гб на карточке Нука (общий объем библиотеки, которую можно на нем хранить), думаю, этот ресурс исчерпает себя очень нескоро. Возможно, хорошие люди доведут до ума syncit или btsync одумается и откроет исходники - тогда появится возможность синхронизировать все по p2p-протоколу, а если я преодолею лень и инерцию и решусь раскошелиться на статический IP - система вообще станет доступна отовсюду.

Система сбора информации в связи с появлением новых инструментов тоже меняется, но о ней чуть позже.

p.s. Пока писал этот текст, начались веерные отключения света и "автономность" снова стала актуальной. Мы отвыкли мыслить себя в оффлайне, при этом у асинхронного режима (когда определенное время ты в сети, определенное - нет) есть свои преимущества.

Comments

[baadoo.livejournal.com]

А что насчёт любви/нелюбви к русским именам файлов?
Мне очень не хватает возможности автоматической транслитерации при сохранении из броузера.

[tengu-crow.livejournal.com]

В моём случае это уже неактульно. Файловая система (ext4) понимает utf8 без проблем. Dropbox и unison - тоже. По русским заголовками очень удобно искать/фильтровать нужное, а вот транслит может создавать проблемы. Тот же Толкачев - он Tolkachev, Tolkatshev или вообще Tolka4eff?

При этом Grubmybooks сохраняет все так, что его понимает и fat32 на sd карточке и андроид система - в смысле ни файловый браузер, ни читалка не спотыкаются.

[baadoo.livejournal.com]

UTF8 - не панацея. Похоже, вы просто не сталкиваетесь со ссылками на русские имена файлов в броузерах. Там сейчас основная засада, которая осталась от русского языка. Множество инструментов генерит подобные ссылки "как написано", а по стандартам в ссылке всё русскоязычное должно преобразовываться в кашу %hex кодирования. В общем, периодически где-то на стыках возникают неудобства, я натыкаюсь.

Вторая проблемка - русские имена файлов и зип. Который не хранит кодировку имён файлов. И пока зипы, сделанные на линуксах, ходят по линуксам - о русские имена файлов внутри никто обычно не спотыкается. Как только встречается переброс архивов между линуксами и виндовсами - часто случается ой. Хотя для зипа на линуксе вроде был патч на эту тему. В любом случае, эта проблема сейчас меньше заметна. Да и волнует меня, честно говоря, слабо. Но, кажется, существует до сих пор.

[tengu-crow.livejournal.com]

У меня проблем не возникает :)



Кроме того, maff вполне себе грамотно сделан :)

vik@firefly:~/zbox/Dropbox/maff/xaoc/meteo$ unzip Метеопост\ -\ Апвеллинг\ в\ Черном\ море.html.maff
Archive: Метеопост - Апвеллинг в Черном море.html.maff
creating: 1414085150639_514/
creating: 1414085150639_514/index_files/
inflating: 1414085150639_514/index_files/uwell.png
inflating: 1414085150639_514/index_files/main.css
inflating: 1414085150639_514/index_files/phone.png
inflating: 1414085150639_514/index_files/watch.js
inflating: 1414085150639_514/index_files/sea-str.png
inflating: 1414085150639_514/index_files/sea-w.png
inflating: 1414085150639_514/index_files/tyalta.gif
inflating: 1414085150639_514/index_files/analytics.js
inflating: 1414085150639_514/index_files/logo.png
inflating: 1414085150639_514/index_files/menu.js
inflating: 1414085150639_514/index_files/upwelling.gif
inflating: 1414085150639_514/index_files/menu.css
inflating: 1414085150639_514/index.html
inflating: 1414085150639_514/index.rdf
vik@firefly:~/zbox/Dropbox/maff/xaoc/meteo$ ls
1414085150639_514 Метеопост - Апвеллинг в Черном море.html.maff
vik@firefly:~/zbox/Dropbox/maff/xaoc/meteo$ ls 1414085150639_514/
index_files index.html index.rdf
vik@firefly:~/zbox/Dropbox/maff/xaoc/meteo$ ls 1414085150639_514/index_files/
analytics.js logo.png main.css menu.css menu.js phone.png sea-str.png sea-w.png tyalta.gif upwelling.gif uwell.png watch.js
vik@firefly:~/zbox/Dropbox/maff/xaoc/meteo$

Так что, имхо, проблема надуманная.

[baadoo.livejournal.com]

> Общий критерий - epub для чтения и оперативного просмотра повсюду, maff для сохранения "почти точной копии" на десктопе. Что-то интересное попадает сначала в dropbooks в виде epub'а. Если оно оказывается достойным более глубокого изучения (или архивации на будущее) - в maff.

У меня стандартный формат хранения - html.zip. E-ink читалка и телефон прекрасно их понимают. на дестопе, разумеется, тоже проблем полный ноль. Читалка на андроид-телефоне - AlReader, http://4pda.ru/forum/index.php?showtopic=340035

* Нет повторного сохранения (epub -> maff).
* Кроссплатформенность (потому что читалки обычно без проблем понимают fb2.zip, html.zip и подобное, а вот mht/maff - не факт. И хорошо, если ещё получится как-то научить читалку, что это тоже зип. А не получится - лишние телодвижения по распаковке или переименованию, если там действительно обычный архив, а не что-то очень похожее на zip-архив).

[tengu-crow.livejournal.com]

За AlReader - спасибо. Буду посмотреть в его сторону. Особенно привлекает синхронизация между читалками. Смущает отсутствие лицензии - CoolReader в этом плане лучше, поскольку идет под православной GNU GPL.

> стандартный формат хранения - html.zip

Ы. А как выглядит workflow? Как сохраняется файл? Сначала html, потом зипуется или все по одному клику? Как происходит поиск информации и именование файла? Есть ли система предварительного отсева и система "забывания"? Синхронизируете через облако или?

* это не повторное сохранение, это - фильтрация информации. я с некоторого времени начал анализировать инфопоток и понял, что нужны фильтры, которые бы отсеивали мусор на входе. у меня очень немногое доживает до maff-стадии :)

Пока писал - нашел человека, у которого система организована похожим образом, хотя и на других инструментах:

http://www.jamierubin.net/2014/01/14/going-paperless-my-process-for-keeping-evernote-clutter-free/

* не надо путать maff и mht :)

кроссплатформенность автоматически вытекает из кроссплатформенности firefox и открытости используемых форматов. сейчас специально посмотрел - maff - это честный zip, который понял и андроид и десктоп (windows нет, но наверняка откроется и там).

внутри zip'а - html со всем причитающимся сопровождением (включая аудио и видео), который понял и coolreader, и андроидный firefox, и какой-то андроидный html-просмотрщик.

от обычного html.zip оно отличается наличием дополнительного .rdf-файлика в котором указано откуда и когда была сохранена страничка - такой себе "библиографической справки", которая доступна в firefox по дефолту (при открытии .maff плагинка автоматом показывает в верхней строчке всю справочную информацию). имхо - это гораздо правильнее чем пихать такую справку куда-нибудь в комменты html-файла

[baadoo.livejournal.com]

> За AlReader - спасибо. Буду посмотреть в его сторону. Особенно привлекает синхронизация между читалками. Смущает отсутствие лицензии - CoolReader в этом плане лучше, поскольку идет под православной GNU GPL.

Я спрашивал давно, Алан сказал, что открывать исходники не будет.
Но здесь я реалист. Наличие исходников CoolReader персонально мне ничего не дало. И в будущем скорей всего не даст. Я сам в опенсорс-проектах участвую и других призываю к участию или донейтам - но благодаря этому ещё и прекрасно знаю, что коэффициент конверсии тех, кто из "а вот я бы, если бы" доходит до стадии "я сделал хоть что-то", от нуля практически не отличается. Обычно похожие проекты едут на одном авторе и иногда парочке-другой неравнодушных. Остальным же 10-100к пользователей - что есть исходники, что нет.

[tengu-crow.livejournal.com]

> Наличие исходников CoolReader персонально мне ничего не дало. И в будущем скорей всего не даст

Для меня это некоторая гарантия, что продукт (внезапно) не станет коммерческим и не будет содержать какого-нибудь левого кода.

[baadoo.livejournal.com]

Знакомая точка зрения. К ней я тоже отношусь как к красивой теории :)

[tengu-crow.livejournal.com]

(пожимая плечами) каждый - кузнец своего счастья.

[baadoo.livejournal.com]

> > стандартный формат хранения - html.zip

> Ы. А как выглядит workflow? Как сохраняется файл? Сначала html, потом зипуется или все по одному клику? Как происходит поиск информации и именование файла? Есть ли система предварительного отсева и система "забывания"? Синхронизируете через облако или?

Очень похоже. Вообще писал об этом не так давно: http://baadoo.livejournal.com/285140.html и по тегу "eink" там можно ещё пару полезных записей по теме найти. Но напишу ещё, более сжато. Самому интересно. А к чёткой идее постоянной готовности к оффлайну я давно пришёл, лет 20-30 назад. Наверное всё-таки где-то в начале 90-х. У нас тогда первые "взрослые" ПК как раз начали появляться. Ну и до этого фидо и usenet свою лепту внесли в понимание, что, как и зачем стоит хранить, систематизировать, и как потом в этом всём искать.

Основной браузер у меня Opera. Она сохраняет `filename.html` + фолдер `filename_files` со всей требухой, внутри в html в конце дописывает коммент с URL-ом исходника. FFox так не умел, про `maff` я не знал до вчерашнего дня.

- Ctrl-S => `~/Downloads/2eink/2014-W51/`
- 2014-W51 (неделя W51) является симлинком на папку в синхронизируемом с телефоном куске Дропбокса.
- `za` (zip all) в папке с оперативным чтивом (W51)

Дропбокс синхронизирую с телефоном не весь, т.к. весь он мне ни на телефоне не нужен, ни по воздуху гонять регулярно всю эти проверку тучи файлов - даром не надо. В дропбоксе у меня не только книги (это раз). И не все книги, которые у меня есть и нужны на десктопах/ноутах, нужны мне на телефоне.

На телефоне Дропсинк настроен на достаточно редкую синхронизацию - раз в 4 часа. Сделано умышленно, раньше было раз в час. Если ухожу - пока одеваюсь, нажимаю на телефоне Dropsync - синхронизировать, предварительно набрав на ноуте `za` (чтобы кучу файлов не гонять). Синхронизирует минуту-две. Если забыл - ничего, засинхронизируется больше файлов, не смертельно. Если буду брать с собой eink - сбрасываю на неё содержимое `2eink`.

Сеансы разгребания у меня обычно дозированы и пытаюсь их более-менее регламентировать и держать под контролем. Почитал RSS, очистил, понаоткрывал табов для почитать - и тут же надо сразу либо просмотерть на ноуте что-то быстрое и лёгкое - проглотить и закрыть, если пригодится - сохранить, если из полезного там крупицы - законспектировать и перенести порцию в вики. Вики у меня раньше жила в WikidPad'е, сейчас - на россыпи Markdown файлов. АБТФ мне неудобен из-за того, что работа с АБФ на мобильных девайсах (а-ля телефон, смартфон, Palm) обычно сопряжена с АБ разочарованием. И синхронизация россыпи из пары тысяч файлов, из которых обычно меняются единицы, для меня привлекательней, чем перегонка 11-мегабайтного файла туда-сюда при каждой правке.

Условно говоря, это фаза "2-минутных" дел. Если дело из инбокса можно сделать меньше, чем за 2 минуты, надо его сделать и забыть, не внося ни в какие тудушки.

Если таб с почитать пережил фазу "новостей" - сохраняю его на "девайс для чтения". Таких на самом деле два, но это мелкое неудобство. На автопилоте накопленное-сброшенное чтиво попадает на телефон (андроид) благодаря дропсинку. Телефон кладётся в карман при любом отрывании от стола (это рефлекс). То есть на кухне при перекусах или готовке, на горшке, в магазине/транспорте/очереди всегда можно просмотреть что-то и удалить после прочтения. Удалил на телефоне - удалится и на дестопе.

[tengu-crow.livejournal.com]

> - Ctrl-S => `~/Downloads/2eink/2014-W51/` - 2014-W51 (неделя W51)
> является симлинком на папку в синхронизируемом с телефоном куске
> Дропбокса. - `za` (zip all) в папке с оперативным чтивом (W51)

Тяжело вникать в чужой процесс :) Я, наверное, туплю, или просто все изложено довольно запутано. Уже хотел спросить - создается ли папка вручную в начале каждой недели, когда нашел в исходном посте скрипт `mkw`. А симлинк создается ручками? А `za` выполняется в папке тоже каждый раз вручную?

То есть теперь я вижу ваш процесс так:

- `mkw` в начале недели ("сегодня понедельник, надо запустить mkw")
- ежеденевно или с какой-то периодичностью разбирается RSS
- все сбрасывается через оперу в папку с номером недели в виде .html + внутренности
- с телефоном все синхронится автоматом по дропбоксу
- с читалкой оно синхронится ручками - перекладыванием сначала на большом компе (чтобы не писать десктоп или лаптоп) в папку `2eink`, потом запуском в нем ручками `za`, а оттуда - через шнурок в папку... в какую папку?
- обратная синхронизация идет вручную копированием необходимого из `00-TODO-laptop` и ручным же удалением по памяти удаленных файлов

И вопросы:

mkw делается в одной папке или в нескольких? Если в одной - почему сразу не привязать к ней makedir в скрипте - и не запускать mkw из любой точки? да хоть по крону :) - что-то типа:

mkdir "/home/brest/2eink/`date +%Y-W%V`" -p

И конфликтов будет меньше - например, если mkw запущен где-то не там. Кстати, как вы решаете вопрос повторного ошибочного запуска mkw?

Зачем разделение на номера недель если в конечном счете все все равно чистится и каждая из папок содержит всего несколько файлов в конечном счете? Оно, конечно, дело вкуса, но скажем мне удобнее просто видеть *стек* статей, сортированных по дате создания, который можно отфильтровать по теме или ключевому слову, можно просто просмотреть глазами по диагонали и так далее, а подборка из W21, W22, W23... теряет наглядность.

> Дропбокс синхронизирую с телефоном не весь, т.к. весь он мне ни на
> телефоне не нужен, ни по воздуху гонять регулярно всю эти проверку тучи
> файлов - даром не надо. В дропбоксе у меня не только книги (это раз). И
> не все книги, которые у меня есть и нужны на десктопах/ноутах, нужны
> мне на телефоне.

По-моему это правильный подход. У меня через dropbox идет тоже только оперативная информация. Он у меня работает даже не столько как синхронизатор, сколько сборщик информации.

А на счет тучи файлов - у меня было ровно такое же ощущение, как выяснилось, за счет тормознутости и вялости dropsync'а - шнурок и unison (ну или unison+ssh или btsync) делают это очень быстро для практически любых объемов информации, так что я даже удивляюсь сейчас, когда слышу жалобы на "много файлов", "мегабайты информации" етс.

[tengu-crow.livejournal.com]

> в 4 часа. Сделано умышленно, раньше было раз в час. Если ухожу - пока
> одеваюсь, нажимаю на телефоне Dropsync - синхронизировать,
> предварительно набрав на ноуте `za` (чтобы кучу файлов не гонять).

Не могу понять, зачем это делать руками? Меня бы это раздражало :) Хук, какой-нибудь повесить - по добавлению файла, по подготовке к синку... что-то такое. Крон опять-же.

Для меня такая система выглядит набором из множества лишних телодвижений - именно поэтому я переложил всю работу на правильные форматы и браузер. Все вопросы архивации и именования вообще убраны из поля зрения и решаются сразу в браузере - ctrl+s - и maff ложится туда, куда нужно, "express grub tab" - и .epub падает в папку для чтения. Все зазиповано, проименовано и синхронизированно. Десктопы и ноуты синхронизируют "оперативный сегмент" автоматом по дропбоксу, а как только будет подключен любой мобильный девайс (читалка или телефон, например) и запущен unison - будут засинхронизированы и они - причем в обе стороны (если я что-то удалил или переложил на читалке - изменения попадут сразу повсюду), причем без моего участия.

В этом плане, что maff, что epub - главным свойством имеют не столько сжатие информации, сколько ограничение сущностей - все в одном файле, одной единице хранения. Поэтому, я могу себе позволить тасовать и сортировать все подборки не задумываясь - мне не надо искать "требуху" к перекладываемому файлу. Для оперативного чтения у меня есть стек по дате в общей папке (`fx explorer` отлично ложится на такой подход), для распределения по категориям из стека (того, что выживет) - файловая система с деревом папок по темам.

Плюс, такая инфоединица в моем случае не ограничиваается одной страничкой - как maff, так и gmb позволяют сохранять подборки из страниц. Например, учебник по sed drBatty у меня лежит подборкой из набора файлов, который можно читать как книгу.

А zip-сжатие - это просто приятный бонус ко всему перечисленному. При карточке в 16/32 Мб и *нормальных* инструментах синхронизации можно спокойно носить все с собой даже в неархивированном виде.

> Синхронизирует минуту-две. Если забыл - ничего, засинхронизируется больше
> файлов, не смертельно. Если буду брать с собой eink - сбрасываю на неё
> содержимое `2eink`.

Руками? А почему не rsync-ом или тем же унисоном?

> россыпи Markdown файлов. АБТФ мне неудобен из-за того, что работа с АБФ на
> мобильных девайсах (а-ля телефон, смартфон, Palm) обычно сопряжена с АБ
> разочарованием. И синхронизация россыпи из пары тысяч файлов, из
> которых обычно меняются единицы, для меня привлекательней, чем перегонка
> 11-мегабайтного файла туда-сюда при каждой правке

А зачем? Независимо от того много файлов или мало - вы же должны быть в курсе, что есть такая штука, как система контроля версий с дельтами, которая заточена специально под такие юзкейсы. А бэкапы личных заметок у вас как организованы, кстати?

> Если таб с почитать пережил фазу "новостей" - сохраняю его на "девайс
> для чтения". Таких на самом деле два, но это мелкое неудобство.

То есть, если я правильно разобрался, система централизованная, с упором на одну машину? И разбор-чтение файлов идет условно "по расписанию"?

> рефлекс). То есть на кухне при перекусах или готовке, на горшке, в
> магазине/транспорте/очереди всегда можно просмотреть что-то и удалить
> после прочтения. Удалил на телефоне - удалится и на дестопе.

Ну да. Только у меня это не только для телефона работает. У меня вся система сохраняет целостность “оперативного сегмента" в автоматическом режиме - либо через dropbox (интернет и инструменты есть), либо через unison (оффлайн, инструментов нет). Unison хорош тем, что позволяет организовать перенос информации на любых системах - хоть на флэшке - и не требует вообще ничего на втором конце синхронизации. При этом синхронизация может работать в несколько сторон и - что самое главное - не требует включать голову.

[baadoo.livejournal.com]

Хм. Узнал об ограничении ЖЖ на длину коммента :)


Если ухожу/уезжаю подальше - часто беру eink читалку (PB360+), туда папку 2eink синхронзирую вручную, через шнурок. Решения для имеющегося там в наличии WiFi не нашёл, ручная переброска не напрягает. Могло быть лучше, но и так неплохо.

Читаемое-разгребаемое на eink-е либо читается и грохается (синхронизация грохнутого вручную по возвращении - обычно всего несколько файлов удалить надо, и их прекрасно помнишь, задача необременительная), либо перекладывается на читалке в папку `00-TODO-laptop`. Там несколько подпапок - сохранить, законспектировать и unreadable (бывает такое, что на ч/б eink читается плохо или не читается).

Поскольку сеансы такого разбора новостей и чтива пытаюсь сгрупировать, то обычно нет проблем зайти в папку `2eink/W51` и ввести там команду `za` (zip all) - она у меня пакует пары `.html` + `_files` в html.zip и грохает исходники. Таким образом уменьшается кол-во синхронизируемых файлов и устраняется куча ручной работы по упаковке.

В целом, я думаю, понятно. Роль мобильных девайсов - мобильные разгребатели оперативного чтива. Ну или книжки или что-то более обстоятельное.

А более глобально цепочка выглядит так:

- browser
- ~/Downloads/2eink
- чтение-разгребание-удаление "на ходу"
- ~/TODO

А из туду уже - или в идеи и работу, или сохранять AS IS, или конспектировать, или просмотреть на десктопе линки или сделать быстрее то, что на дестопе сделать проще.

[tengu-crow.livejournal.com]

> Если ухожу/уезжаю подальше - часто беру eink читалку (PB360+), туда папку
> 2eink синхронзирую вручную, через шнурок. Решения для имеющегося там в
> наличии WiFi не нашёл, ручная переброска не напрягает.

Собственно, я о том же. В шнурке нет ничего плохого, больше того, устройства все равно надо подключать - как минимум для зарядки. Почему не использовать удобный момент? Плюс синхронизация через шнурок (bluetooth, wifi, ssh-канал "поверх всего этого") будет явно быстрее за счет локальности и отсутствия необходимости гонять информацию к дядям на сервер.

>Читаемое-разгребаемое на eink-е либо читается и грохается (синхронизация
>грохнутого вручную по возвращении - обычно всего несколько файлов
>удалить надо, и их прекрасно помнишь, задача необременительная),

Вот это не мой случай. Во-первых, всегда есть риск что-нибудь зевнуть и приходится тратить ресурс внимания на штуки, с которыми компьютер справится заведомо лучше, во-вторых, раз есть софт для таких целей - почему им не воспользоваться? unison или rsync? Или такие штуки, как git-annex, git-media, git-fat. Boar в конце-концов. Annex я бы непременно использовал, но у меня рабочий инструмент не гит, а hg.

Я вот в полной мере оценил достоинства библиотеки, в которой распределённо синхронизируются целевые сегменты - возможность оперативно работать из любой точки доступа независимо от интернета и внешних сервисов разгружает голову и способствует лучшей организации хранения. Я могу заниматься чтением и обработкой независимо от контекста - и независимо от контекста, все изменения будут распространяться на всю систему. Но это отдельная тема :)

Плюс я могу себе позволить такую роскошь, как "серая зона памяти" - архив на терабайтовом диске, куда удаляется неактуальная информация. По которой все равно доступен полнотекстовый поиск, поиск по именам и дате - чего вполне достаточно, если внезапно возникает необходимость что-то поднять из архивов.

Не говоря уже про устойчивость и прозрачность такой системы - у меня выход из строя любой из машин не влечет потерь информации.

[baadoo.livejournal.com]

> это не повторное сохранение, это - фильтрация информации

Я думаю, это всё же повторное сохранение в другом формате: найти адрес, открыть, пересохранить в нужном формате.

У меня эта задача фильтрации на eink-е происходит, например. И я просто перекладываю достойный сохранения архив в папку `TODO-laptop/save/что-то-там`, а на десктопе/лаптопе просто перебрасываю в постоянное хранилище. Т.е. я обычно и задачу каталогизации сразу на пляже решаю, а дома тупо перебрасываю всё готовое.

Принцип минимизации повторных действий. Чтобы не делать даже такую мелочёвку повторно.

[tengu-crow.livejournal.com]

> Я думаю, это всё же повторное сохранение в другом формате: найти адрес, открыть, пересохранить в нужном формате.

Я не думаю, я знаю :) Это ведь мой рабочий процесс, а не ваш :) В моем случае это близко к Late Binding так как оно описано у Лайона Кимбро.

А как выглядит внутренность недельного архива? Сколько у вас таких архивов? Как вы ищете нужную тему, если возникает необходимость повтороного возврата к? В стиле "что-то такое я читал некоторое время назад... где-то в архивах оно лежит".

[baadoo.livejournal.com]

Это не архив, это оперативная разгребалка. Если там что-то остаётся и накапливается по прошествии 2-3-4 недель - значит, это информационное переедание и надо принимать меры.

[tengu-crow.livejournal.com]

Я правильно понял, что в конце цепочки - конспекты и неструктурированное хранилище?

[baadoo.livejournal.com]

В конце хранилище на файловой системе и вики (на наборе Markdown файлов).

[baadoo.livejournal.com]

Ещё подброшу информацию про Wallabag (бывший Poche). Это серверный инструмент генерации EPUB. Можно либо заморочиться и себе поставить, либо использовать бесплатный https://www.framabag.org/
Я не заморачивался, а для экспериментов зарегистрирвоался на Framabag.

http://rb.labtodo.com/links/?QgnokA
https://github.com/wallabag/wallabag
https://www.framabag.org/

Если сравнивать с генератором epub из файрфокса - решение более универсальное, т.к. получить EPUB можно и с телефона, десктоп для генерации не нужен. Из минусов - изредка попадаются ситуации, когда их оптимизация по оставлению только контента даёт сбой и обрезает лишнего. Честно признаться, довольно редко попадал в такую ситуацию - и тогда можно открыть Framabag и пометить документ (пересохранив в html.zip), либо в случае оффлайна - я просто перекладываю документ в папку `00-TODO/unreadable`.

[tengu-crow.livejournal.com]

Ага. Спасибо. Будет на что посмотреть, когда и если grubmybooks перестанет работать :) Оптимизация - это такая штука - grub тоже иногда на этом спотыкается.

А вот завязка на внешний сервис с некоторого времени вызывает у меня паранойю - сервис может не работать, может быть заddos'ен, может быть отключен на время блэкаута, может ударится в коммэрцию и энтерпрайзинг - поэтому я стараюсь избегать завязывания рабочих цепочек на что-то внешнее, что я не контролирую.

[baadoo.livejournal.com]

Там нет завязки на внешний сервис. Можно всё себе поставить. Готовый сервис - это для ленивых. Я не знал, буду ли пользоваться (и скорее нет, чем да), поэтому мне готовый был удобней для попробовать.