Ознакомьтесь с нашей политикой обработки персональных данных
  • ↓
  • ↑
  • ⇑
 
Записи с темой: инфотех (список заголовков)
00:38 

Чтение электронных книг - 2.5

или "Dropsync не нужен"

В предыдущей серии ваш покорный слуга описывал свою систему, в которой чтение и архивация небольших заметок (в противовес чтению "больших книг" и книг, сгенерированных из собственных заметок) опирается на .epub и .maff форматы (по сути - зипованные .html) и творческое использование dropbox. Некоторое время назад я отказался от dropsync'а в пользу синхронизации через usb с помощью Unison. Причины, технические подробности, плюсы и минусы перечислены в предыдущей статье.

Вынужденное изгнание и смартфон меняют стереотипы. Смартфон, как "девайс в том числе для чтения" постепенно перетягивает одеяло на себя. Я привык читать с небольших экранов (Palm + WeaselReader), а смартфон (в отличие от более громоздкой читалки) постоянно с собой. Кроме того, появились программы вроде Dimmer'а которые позволяют настраивать яркость и цветовую гамму (например, убирать пресловутый "синий свет") - что сильно сокращает разрыв по разнице в качестве чтения.

Еще у смартфона есть симкарта и (почти всегда) бесплатный gprs-интернет. Сейчас у меня дошли руки до установки dropbox'а (я стараюсь держать на телефоне как можно меньше программ) - и я понял, что мне не нужен не только dropsync (см предыдущую заметку), но скорее всего и синхронизация заметок по шнурку.

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


@темы: dropbox, epub, firefox, foss forever, linux, maff, unison, инфотех, научная организация труда, нот, софт, чтение

11:12 

Not so open source

Отключение служб гугла в Крыму - наглядный пример того, почему нельзя полагаться на корпорации, даже если они обещают бесплатный сыр, что не будут сильно evil. Программное обеспечение должно быть не просто бесплатным, но и свободным - не как пиво, а как GNU GPL. Иначе, какой-нибудь дяденька в лице Главменеджера Корпорации Добра решит в один прекрасный день порулить и лишит вас рабочего инструмента.

Поэтому - Firefox (реакция на скандал со Сноуденом, кстати, была очень характерной), поэтому Libre Office и Linux. И поэтому - по возможности сободная прошивка на андроидофон, плюс использование софта в основном из свободного репозитария F-Droid - там есть практически все, что необходимо для жизни (во всяком случае мне) под андроидом.


лекарство одно - открытые форматы хранения и open source софт. Это требует некоторого ума и некоторого приложения сил (трудности обычно сильно преувеличены), зато потом окупается сторицей - можно быть уверенным, что после "часа $" мои данные не превратятся в труху, а софт - в тыкву.


(c)


@темы: foss forever, интересно_в_основном_мне, инфотех, на злобу дня

12:33 

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

В предыдущей заметке о чтении, я разделил свои материалы для чтения на три основные категории: большие книги, мои собственные заметки (в виде Большого Текстового Файла) и "клипы" или "вырезки" - набор разношерстых 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. Пока писал этот текст, начались веерные отключения света и "автономность" снова стала актуальной. Мы отвыкли мыслить себя в оффлайне, при этом у асинхронного режима (когда определенное время ты в сети, определенное - нет) есть свои преимущества.


@темы: dropbox, epub, firefox, foss forever, linux, maff, unison, инфотех, научная организация труда, нот, софт, чтение, экосистема чтения

13:33 

python в образовательном процессе :)

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

И для равновесия - критические отзывы lqp.

Мое скромное мнение - учить нужно как высокоуровневым языкам, так и низкоуровневым. Но начинать стоит с Питона в школе, а где-то к первому-второму курсу вполне можно давать ассемблер.


@темы: foss forever, future, linux, me, безумствования, дайджест ссылок, заметки пороноега, заметки преподавателя, заметки себе, здравый смысл, идеи, интересно_в_основном_мне, инфотех, кое-что о реальности, мысли, новый мировой порядок, нот, политика, промывание мозгов, системные соображения интересные мне, софт, утреннее, фичи, холодное железо

02:58 

АБТФ, Evernote или "Первая доза бесплатно"

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

Сейчас потихоньку начали просачиваться новости о том, что систему переводят в небесплатный режим и вообще. Что хуже - btsync тоже начал двигаться в сторону коммэрции, хотя с ним есть надежда, что они будут монетизировать только хранилище, а саму утилиту так и продолжат распространять бесплатно. С другой стороны - уже есть Pulse ну и rsync с unison'ом еще никто не отменял.

Словом история повторяется снова и снова.


...подсадить как можно больше пользователей, стать монополистом на рынке и закрыть систему - все равно уже никто и никуда не побежит. Дальше начинается монетизация.


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


"Опыт показывает, что такие учреждения обречены. Совершенство убьет их. Им некуда пустить корни. Они не могут расти, так как уже выросли. Они и цвести не могут, а плодоносить — тем более. Когда мы встречаем такой случай — например, здание ООН, — мы умудренно и печально качаем головой, прикрываем простыней труп и неслышно выходим на воздух"


(c) Сирил Норкот Паркинсон

Пока лекарство одно - открытые форматы хранения и open source софт. Это требует некоторого ума и некоторого приложения сил (трудности обычно сильно преувеличены), зато потом окупается сторицей - можно быть уверенным, что после "часа $" мои данные не превратятся в труху, а софт - в тыкву.


@темы: foss forever, АБТФ, интересно_в_основном_мне, инфотех

14:33 

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

Электронную литературу я читаю давно, если быть точным, начиная с 1999 года. Если не считать Ватолина в 1998-ом году, первой книгой, которую я полностью прочел с компьютера, были "Фальшивые зеркала" Лукьяненко. Специально оставался по вечерам на кафедре и читал - пока не приходило время уезжать на последнем автобусе в Ильичевск. Потом был 286-й компьютер на работе с которого можно было читать в Dos-Navigator'е, потом уже свои домашние машины - тоже с MS Dos и Dos-Navigator'ом в качестве читалки. Palm Zire я взял где-то в начале нулевых. За ним последовал Sony Clie, Amazon Kindle 4 и вот сейчас Nook Simple Touch GlowLight.

В начале нулевых (2001? 2002? 2003? - не суть важно) я определил для себя причины по которым читалка должна быть отдельным от большого компьютера (десктопа или лаптопа) устройством и купил Palm Zire. И остался более, чем доволен. Палм помещался даже в небольшую сумку и его можно было везде носить с собой. Можно читать в транспорте, можно читать в очереди и так далее. В любую читалку помещается целая библиотека, которая в бумажном виде, потребовала бы 120 литрового рюкзака.

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

Все, что прибегает в мою читалку можно разделить на три основные категории.

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


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

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

Еще один параметр - расстановка переносов в тексте, в результате чего книга выглядит плотно и правильно - как типографский текст, а не как документ M$ Word, "выровненный по горизонтали". Эта фича была реализована еще палмовском Weasel Reader'е - который имхо является лучшей читалкой этого класса. И отсутствием этой фичи в свое время жутко раздражал Киндл.

До некоторого времени для меня ключевым оставался момент с чтением djvu/pdf - читалка пришла на смену палму именно по этой причине. На нуке есть OrionViewer, но, работая с Неназываемым, я заметил, что это не так уж необходимо. OCR в последнее время шагнул далеко вперед - сужу по тому, что на Флибусте распознанный скан книги появляется с очень короткой задержкой после того, как в сеть выкладываются сканы. Кроме того, с профессиональной и технической литературой все равно приходится работать на десктопе. Читалка все-таки предназначена больше для линейного (или почти линейного) чтения - увы техническую литературу так не почитаешь. Во всяком случае мои попытки осуществить подобное успехом не увенчались. Где-то мне попадалась рекомендация читать сканированную литературу с планшета, но во времена Неназываемого у меня его не было, а сейчас просто не доходят руки, чтобы попробовать.

2. Большой Текстовый Файл, который прекрасно конвертится в книгу - и дает возможность носить с собой свою записную книжку. Я бы даже сказал - свое глобальное хранилище информации. И для palm и для kindle у меня это делалось с помощью скриптов и было чертовски удобно. Поскольку формат Большого Текстового Файла - это фактически markdown, то аналогичным путем в читалку можно было сложить не только личные заметки, но и статьи, книги, методички и лекции - которые я тоже пишу в markdown'е.

3. Вырезки или клипы (как точнее всего перевести с английского clips?). В интернете часто попадаются довольно объемные тексты - не книги, а именно тексты. Я не читаю их в браузере по нескольким причинам.

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

С первыми двумя категориями все более или менее понятно. Книги копируются на читалку не часто, читаются долго и в общем-то не требуют никакого дополнительного процесса. Большой Текстовый Файл - требует скрипта, но обновляется не очень часто.

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

На палме все решалось копированием-вставкой текста заметки в WinMakezTxt - и дальше через HotSync, либо через карточку памяти - на палм.

Для Киндла я быстро отыскал такой замечательный аддон для firefox, как KindleIt. Эта плагинка (а) чистит текст от шелухи вроде боковых менюшек (б) конвертит его в .mobi-файл (в) отправляет файл на почту аккаунта, привязанного к киндлу. Когда киндл заходит в сеть, все что пришло на его почтовый ящик автоматически синхронизируется с читалкой. Очень удобно. С любой машины, где установлена эта плагинка в два клика можно кинуть интересный текст себе в читалку без лишних телодвижений. Второй плюс - это то, что текст читается в родной читалке и к нему можно применить весь набор инструментов перечисленных выше - закладки, копирование цитат, вставка замечаний на полях.

В Нуке дело обстояло сложнее. Я привык к удобству Киндла и хотелось чего-то подобного - чтобы в два клика и с автоматической синхронизацией без танцев с кабелем или тем более с перестановкой карточек. К моему разочарованию выяснилось, что ни один облачный сервис (Dropbox, Google Drive, Яндекс Диск и даже Evernote) для андроида не синхронизируется непосредственно с диском. То есть нет такого, чтобы на диске лежала папка с файлами, автоматически синхронизируемая с облаком. Будь добр - зайди в приложение, ткни в ссылку на файл, а уже после этого он соизволит загрузится. Поскольку я часто читаю где-нибудь в отрыве от вайфая меня это не устраивало. Кроме того постоянно включенный вайфай сажает батарейку, а сама схема "ткнул-скачал-удалил-ткнул-еще-раз" неудобна для большого количества файлов требует множества ненужных и нерациональных пальце- и мыследвижений.

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

Кроме того, работать с заметками в Instafetch было неудобно - не было привычного интерфейса CoolReader - где-то на этой стадии я осознал что для полного счастья мне нужно работать с заметками и клипами так же как и с книгами - закладки, сбор цитат и примечаний, явное представление заметки в файловой системе (сиречь одним .epub-файликом, который удобно перекидывать в разные папки) и так далее. Просто чтение в стиле гугл-ридера меня не устраивало.

Стало понятно, что нужно копать в сторону какого-то расширения, которое бы переводило страницы в epub - а потом уже читать этот epub стандартной читалкой. KindleIt позволяли сохранять страницу в epub, но это было не очень удобно. Немного поискав, я обнаружил grabmybooks - пожалуй лучшее, что можно придумать для такой системы. Это расширение позволяет как сразу складывать на диск отдельные статьи, так и грабить сразу содержимое нескольких табов или нескольких ссылок подряд, причем их можно сохранять как отдельно, так и "пакетно" - создавая книгу в которой главами будут служить отдельные заметки. Возможностей много и они хорошо продуманы. Оставался вопрос - как синхронизировать накопленные заметки с Нуком?

Сначала я пробовал разные вариации на тему соединения через ssh и всяческих unison'ов - есть множество программ которые позволяют это делать. Потом я совершенно случайно наткнулся на Dropsync - приложение которое как раз синхронизировало дисковую папку с Dropbox'ом, причем в оба конца. Это было то, что надо. Lite-версия налагает ограничения "только одна папка" и "файлы не больше 5Мб" - что меня вполне устраивает - клипы-вырезки не превышают этот предел.

В Dropbox я выделил папку nook, которую синхронизирую с папкой news на карточке Нука, grabmybooks тоже настроен на эту папку, как на дефолтную. Теперь с любой машины, на которой я работаю (нетбук, домашний или рабочий десктопы) я могу на интересной статье ткнуть в grabmybooks, сохранить ее в Dropbox/nook и когда читалка подключится к wifi - файлы автоматом попадут в папку news. Эту папку можно "чистить" от лишних файлов как с десктопа, так и с Нука. При необходимости можно кинуть туда и книгу, но обычно книги я скачиваю отдельно. По более позднему опыту (заметка лежала на холде с сентября 2012-го года) книги я тоже кидаю в дропбокс, а потом уже оттуда раскладываю их по папкам читалки.

Еще немного мыслей россыпью.

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

Цитаты и замечания раньше я собирал в файлы и при случае перекидывал их в Большой Текстовый Файл. Сейчас все чаще просто посылаю их себе на почту - в CoolReader это очень удобная и продуманная фича.

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

Размер экрана, шрифты и прочее (за исключением расстановки переносов), с моей точки зрения не имеют особого значения - по моему опыту к любой системе привыкаешь быстро. Текст с крошечного наладонника читается не хуже, чем с E-Ink последней модели - если это увлекательный текст.

Проблемы, которые я еще не решил - это фрагментация и тактильность.

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

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

Так что пожалуй, вопрос, поднятый в Психо-паспорте справедлив, но для отдельных действительно важных книг, которые нужно обдумывать, анализировать и осмыслять. Худл и проходные тексты можно читать и на читалке.

С фрагментацией я столкнулся уже давно и просто не соберусь навести порядок в системах хранения и обработки.

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

Сейчас вопрос усложнился.

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

Можно было просто ограничится тем, что синхронизировать оба книгохранилища, например, через unison, но у этого метода есть несколько недостатков которые прямо вытекают из раздрая в целевых установках.

На читалке хочется иметь книгу с правильным форматированием, содержанием и примечаниями. То есть - в fb2, либо epub. fb2 я отдаю предпочтение, поскольку CoolReader для этого формата делает нормальные сноски, но он не всегда доступен.

На диске я стараюсь держать txt-файлы, поскольку являюсь сторонником широкого использования grep и find. Книги в fb2 и epub, во-первых, не погрепаешь, во-вторых выдрать нужную цитату из них - еще то удовольствие, поскольку штатный FBReader плохо приспособлен для таких вещей. Хотя возможны вариации на тему zcat book.fb2.zip | xsltproc FB2_2_txt.xsl - | less -s или, например zcat book.fb2.zip | xsltproc FB2_2_txt.xsl - | vim - - и здесь нужно будет читать документацию. Использование Calibre в подобных задачах кажется стрельбой по воробьям даже не из пушки, а из большого адронного коллайдера (и вообще Calibre производит на меня именно такое впечатление - хотя сторонним пользователям рекомендую именно ее), хотя... ее ebook-convert справляется хорошо.

Вариантом номер два является держать таки библиотеку в fb2/epub - и натравить на нее какой-нибудь поисковик - например recoll, который очень хорошо с такими форматами справляется. Однако, это опять-таки усложняет систему и оставляет за рамками вопрос выдирания цитат из.

Пока писал текст, пришло в голову, что, возможно хранение страничек в epub'ах - это хороший выход для сохранения на десктопе третьей категории информации. Для меня всегда было проблемой как хранить интернет-тексты - в html? в chm? в maff? в txt? Главным преимуществом epub будет то, что она уже есть - если текст мне нравится он автоматом скидывается в читалку. А уже сохранить и обработать его - это достаточно несложная задача.

Еще один вариант - держать одну библиотеку в fb2/epub и регулярно конвертировать ее в plain text версию - допустим скриптом по крону. Не обязательно всю сразу - только свежие поступления.

В общем тут есть еще двести возможностей. И на этом я завершу пост, поскольку порядок в библиотеке - это уже другая история.


@темы: аффигительно большой файл, АБТФ, linux, нот, научная организация труда, мысли, инфотех, софт, чтение

11:59 

Nevernote

Любителям блокнотов на заметку. Nevernote в списке альтернативных программ позиционируется, как универсальная замена целой куче софта, вроде бы умеет синхронизацию с Evernote-сервисом и вообще отличается умом и сообразительностью. И симпатичным жирафом на заставке. К тому же, судя по тому, что написана на яве должна быть кроссплатформенной. Не знаю. Не пробовал :)

На первый взгляд выглядит заманчиво для поклонников point-and-click, которым система вроде АБТФ кажется зело сложной. Подозреваю, что благодаря Яве будет тормозить на больших объемах информации (jEdit во всяком случае тормозил), но кого в наши дни мощных машин это останавливает? :)


@темы: инфотех, софт

18:11 

Инфозамок


Сказка о замке

В давние времена жил народ с информационной проблемой. В центре их страны стояло величественное строение. Под его сводами находилась их великая Комната Писаний. В этой комнате находилась куча клочков бумаги, каждый размером с детскую ладонь. Время от времени ученый входил в этот храм, чтобы предложить знание. Совет писцов оценивал, стоящее ли оно. Если да, они вписывали его на один из клочков бумаги и торжественно бросали его наверх кучи.

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



Мы, современные люди, можем понять их проблему: в беспорядочной куче каждый добавляемый клочок хоронил под собой остальные (как на многих рабочих столах). Каждый клочок был отдельным, не связанным с другими и добавление ссылок дало бы мало помощи, когда нахождение клочка занимает месяцы. Если мы используем такую кучу, чтобы хранить информацию, наши обширные, детализированные писания по науке и технике были бы почти бесполезны. Поиски занимали бы годы и целые жизни. Мы, современные люди, имеем простое решение: мы складываем страницы в порядке. Мы помещаем страницу за страницей, чтобы образовалась книга, книгу за книгой, чтобы заполнить полку, и заполняем здание полками, чтобы получить библиотеку. Со страницами все в порядке, мы можем найти их и следовать ссылке более быстро. Если бы те писцы использовали ученых, чтобы сложить клочки по теме, то поиски бы стали легче. Однако, когда у них были стопки по истории, географии и медицине, куда следовало бы положить клочки по исторической географии, географической эпидемиологии и медицинской истории? Куда следовало бы им положить клочки по “Истории распространения Великой Чумы”?

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

Теперь ученые могут соединить “Историю распространения Великой чумы” со связанными клочками по истории, географии и медицине. Они могут добавить все примечания и тексты, которые хотят, связывая их наиболее удобным образом. Они могут добавить клочок со специальным индексом, способный принести в руку все, что в нем перечисляется. Они могут поместить связи куда угодно, куда они хотят, сплетая сеть знания так, чтобы она соответствовала связям в реальном мире. Мы, с нашими инертными кипами бумаги, можем только им завидовать – если бы у нас не было компьютеров.


(c) Эрик Дрекслер



@темы: инфоорганизация, инфотех, цитаты

20:24 

Пространственная память, Рабочие столы и Линуксовый десктоп

Первое время, после переезда под Linux, я использовал его "по-виндовому". У меня редко использовалось больше одного рабочего стола. Большинство приложений варилось в одном котле с доступом по Alt-Tab. И вообще полезность множества рабочих столов теоретически была понятна, но практически я не особо ей пользовался. Впервые о том, как я использую свою систему я задумался прочитав у уважаемого Оллеката о тайловых менеджерах, однако для моих целей они оказались избыточны - как минимум по причине маленького монитора. Потом, листая форумы unixforums.org, я натолкнулся на тему о интерфейсах линукс, в частности - на заметку Федорчука о том, как он использует свою систему.

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

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

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

  • распределение пространства

Как я распределяю свои рабочие столы? После достаточно долгих экспериментов у меня сложилась следующая раскладка:

1 - текстовый редактор (в моем случае - gvim).
2 - терминал (sakura, с включенным внутри нее screen).
3 - firefox и другие браузеры (иногда бывает необходимо использовать midori, например).
4 - файловые менеджеры (nautilus, pcmanfm).
5 - раньше использовался для мультимедии (mplayer, rhythmbox), но сейчас я использую в основном консольный MOC-player и реже - cmus, которые крутятся под screen в терминале. Так что в настоящее время этот стол работает резервным.
6 - "болталки" aka Инстант-менеджеры (pidgin, skype).
7 - почтовый клиент (thunderbird).
8 - резервный стол.

Такая раскладка столов выбрана не случайно. Я перепробовал несколько вариантов. Стало понятно, что на первом рабочем столе должно открываться наиболее часто используемое приложение, на втором - менее часто и так далее.

Чаще всего я пишу-читаю-редактирую текстовые файлы - от программ до собственно текстов. Поэтому вим у меня на первом столе и открыт почти всегда. То же касается терминала - поскольку sakura-screen открыта у меня почти постоянно - я даже перестал в последнее время пользоваться "выпадающей консолью". Само собой - на третьем месте firefox, как инструмент для работы с интернетом. Пиджин и почта умышленно загнаны "на Камчатку" - дабы поменьше отвлекали от рабочего процесса.

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

Переключение по рабочим столам у меня вполне традиционно настроено на сочетание клавиш <Alt+номер стола>, <Win+номер стола>. Так же очень удобное хотя и используемое гораздо реже сочетание <Win+Shift+номер стола>, которое перемещает текущее активное окно на стол с нужным рабочим номером. Относительными перемещениями ("перейти на стол влево-вправо") я не пользуюсь.
  • впечатления от работы

Какие преимущества имеет такая система? Прежде всего - включается и начинает работать пространственная и моторная память. Все лежит на своих местах. Через неделю распределение программ по столам настолько входит в привычку, что выполняешь его не задумываясь. Я точно знаю где при монтировании флэшки окажется открывающееся окно nautilus'а. Четвертый стол, Alt+4.

Руки нажимают нужные кнопки сами, быстрее чем мозг успевает сформулировать что именно нужно сделать. Посмотреть почту? Alt+7. Написать заметку? Alt+1. Посмотреть статью в Википедии? Alt+3. Скопировать ссылку из браузера в текст? Alt+3, Ctrl+l, Ctrl+c, Alt+1, Ctrl+v.

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

Такая система делает ненужной доки (все и так лежит на своих местах) и... панель запуска задач. Некоторое время я по-старинке использовал панель задач в GNOME, потом, когда перешел на OpenBox - тоже по инерции поставил lxpanel. Когда я недавно экспериментировал с настройками системы - случайно отключил ее. К моему удивлению, ее отсутствие почти не отразилось на моей работе с системой - я хорошо помнил где что лежит и переключался на нужные столы даже не видя где они находятся и что в них запущено. Поэкспериментировав, я понял, что могу работать с системой "наощупь" без особой потери темпа. Я понял что панелью задач не пользуюсь и сейча потихоньку перехожу к tint2 в режиме псевдопейджера.

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

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

Как реализовать такой режим работы? OpenBox позволяет такое по дефолту - то есть достаточно открыть ~/.config/openbox/rc.xml и найти и настроить в нем соответствующие разделы.

Пример моего конфига.

...
<applications>
...
<application name="gvim">
<desktop>1</desktop>
<maximized>yes</maximized>
<decor>no</decor>
</application>
<application name="sakura">
<desktop>2</desktop>
<decor>no</decor>
<maximized>yes</maximized>
</application>
<application name="firefox-bin" role="browser">
<desktop>3</desktop>
<maximized>yes</maximized>
</application>
<application name="WinMakezTxT.exe">
<desktop>3</desktop>
</application>
<application name="nautilus">
<desktop>4</desktop>
</application>
<application name="pcmanfm">
<desktop>4</desktop>
</application>
<application name="Pidgin" role="buddy_list">
<desktop>6</desktop>
</application>
<application name="Pidgin" role="conversation">
<desktop>6</desktop>
<maximized>yes</maximized>
</application>
<application name="thunderbird-bin" role="3pane">
<desktop>7</desktop>
<maximized>yes</maximized>
</application>
...
</applications>
...

Некоторые пояснения:

name="gvim" - название-класс-роль приложения

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

_OB_APP_TYPE(UTF8_STRING) = "normal"
_OB_APP_CLASS(UTF8_STRING) = "Firefox-bin"
_OB_APP_NAME(UTF8_STRING) = "firefox-bin"
_OB_APP_ROLE(UTF8_STRING) = "browser"

Их можно использовать в качестве имени программы. Как правило имени хватает, но иногда возникает необходимость более точного "наведения на цель" - скажем в Пиджине мне хочется, чтобы окно с диалогами (role="conversation") разворачивалось во весь экран, а список пользователей (role="buddy_list") оставался таким как есть. Поэтому для них есть две отдельные команды.

<desktop>1</desktop> - на каком рабочем столе запускать

<maximized>yes</maximized> - распахнуть на весь стол

<decor>no</decor> - запустить без декораций

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

Клавиши навигации по рабочим столам настраиваются еще проще и в том же rc.xml

...
<keyboard>
...

<keybind key="A-1"> <action name="Desktop"> <desktop>1</desktop> </action> </keybind>
<keybind key="A-2"> <action name="Desktop"> <desktop>2</desktop> </action> </keybind>
<keybind key="A-3"> <action name="Desktop"> <desktop>3</desktop> </action> </keybind>
<keybind key="A-4"> <action name="Desktop"> <desktop>4</desktop> </action> </keybind>
<keybind key="A-5"> <action name="Desktop"> <desktop>5</desktop> </action> </keybind>
<keybind key="A-6"> <action name="Desktop"> <desktop>6</desktop> </action> </keybind>
<keybind key="A-7"> <action name="Desktop"> <desktop>7</desktop> </action> </keybind>
<keybind key="A-8"> <action name="Desktop"> <desktop>8</desktop> </action> </keybind>

<keybind key="W-1"> <action name="Desktop"><desktop>1</desktop></action> </keybind>
<keybind key="W-2"> <action name="Desktop"><desktop>2</desktop></action> </keybind>
<keybind key="W-3"> <action name="Desktop"><desktop>3</desktop></action> </keybind>
<keybind key="W-4"> <action name="Desktop"><desktop>4</desktop></action> </keybind>
<keybind key="W-5"> <action name="Desktop"><desktop>5</desktop></action> </keybind>
<keybind key="W-6"> <action name="Desktop"><desktop>6</desktop></action> </keybind>
<keybind key="W-7"> <action name="Desktop"><desktop>7</desktop></action> </keybind>
<keybind key="W-8"> <action name="Desktop"><desktop>8</desktop></action> </keybind>


<keybind key="W-S-1"> <action name="SendToDesktop"><desktop>1</desktop></action> </keybind>
<keybind key="W-S-2"> <action name="SendToDesktop"><desktop>2</desktop></action> </keybind>
<keybind key="W-S-3"> <action name="SendToDesktop"><desktop>3</desktop></action> </keybind>
<keybind key="W-S-4"> <action name="SendToDesktop"><desktop>4</desktop></action> </keybind>
<keybind key="W-S-5"> <action name="SendToDesktop"><desktop>5</desktop></action> </keybind>
<keybind key="W-S-6"> <action name="SendToDesktop"><desktop>6</desktop></action> </keybind>
<keybind key="W-S-7"> <action name="SendToDesktop"><desktop>7</desktop></action> </keybind>
<keybind key="W-S-8"> <action name="SendToDesktop"><desktop>8</desktop></action> </keybind>
...
</keyboard>
...
  • варианты решений

Разумеется, это не единственное решение. В GNOME, насколько мне известно, подобным образом можно настроить Compiz - но подробно я этот вопрос не исследовал, поскольку в тот момент уже перешел к OpenBox как основной рабочей системе.

Как вариант - можно встроить OpenBox в качестве менеджера окон GNOME (вместо metacity или compiz) и настроить OpenBox так, как указано выше.

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

Часто на форумах рекомендуют использовать для управления окнами утилиту devilspie, но у меня он не работал так, как было мне нужно. Поэтому вместо него на первых порах - когда я еще не добрался до OpenBox я использовал совсем примитивное решение.

Есть утилита wmctrl - она управляет окнами из командной строки. На ее вход можно подать название окна и номер стола, куда его нужно отправить. Я написал скрипт, который растасовывает запущенные приложения по рабочим столам и связал его с кнопкой на панели GNOME. После запуска нужных приложений, я нажимал на эту кнопку и они раскладывались по нужным рабочим столам. Решение неуклюжее, но вполне рабочее.

Выглядит оно примерно так:

#! /bin/sh

# рабстол номер раз - все вимы
wmctrl -r "GVIM" -b add,maximized_vert,maximized_horz
wmctrl -r "GVIM" -t 0

...

# рабстол номер три - файрфокс
wmctrl -r "firefox" -b add,maximized_vert,maximized_horz
wmctrl -r "firefox" -t 2

# рабстол номер семь - почта
wmctrl -r "thunderbird" -b add,maximized_vert,maximized_horz
wmctrl -r "thunderbird" -t 6

...

exit

Каждая команда ориентируется на заголовок окна. Первая из команд разворачивает окно на максимум, вторая - посылает на нужный рабочий стол. Не знаю почему, но wmctrl считает столы с нуля, поэтому если файрфокс отрпавляется на рабочий стол номер три - надо писать wmctrl -r "firefox" -t 2.
  • P.S.

Еще один любопытный момент. Перечитывая этот пост, я заметил, что большинство используемых мной программ - это достаточно мощные системы, каждая из которых завязана на определенный вид работы. То есть, например, файрфокс - сейчас больше чем браузер - это "комбайн" для работы с сетевыми приложениями. Аналогично "комбайнами" можно назвать и vim и screen - с одной стороны у них очень простые механизмы работы, с другой они позволяют накручивать на себя функционал, для реализации которого потребовалось бы множество стороннего софта, сил и средств. Например, при запуске screen у меня в нем автоматически подгружается ttytter (очень удобный twitter-клиент), mocp и htop. И так далее.

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


@темы: linux, openbox, инфотех, научная организация труда, нот, фичи, хаки

12:40 

Безмышинная навигация по Файрфокс и Быстрые Имена

2010-08-27 11:04

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


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


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

Также понял, насколько хорошая штука - быстрые имена. Я уже описывал их и давал ссылку на зело полезную хабрастатью. Смысл состоит в том, чтобы присваивать закладкам быстрые имена. Это не только ускоряет навигацию, но и позволяет осуществлять поиск по самым разным поисковым системам - достаточно прыгнуть в адресную строку (Ctrl+L, а при открытии новой вкладки по Ctrl+T курсор сам туда подставляется) и набрать что-нибудь вроде slov арахнофобия. На slov у меня завязан поисковик по яндекс.словарям (как это сделать см - статью на хабре) в итоге я сразу получаю решение.

Пару месяцев назад, проводя ревизию своих плагинок, я случайно нашел Smart Search, которая использует эти быстрые имена для контекстного поиска (черрртовски удобно). Ну а сейчас я понял, что при таком интенсивном использовании быстрых имен, как у меня держать еще и отдельны search bar особого смысла нет и дополнив список быстрых имен теми поисковиками, что были у меня в search bar'е, убрал его с панели.

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

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

Приложение.

Если кому-то интересен список моих поисковиков (в формате - "короткое слово" - "назначение"):

fli Флибуста
kino КиноПоиск.ru
lurk Lurkmore
malk mp3.alkar.net
me поиск по моему жж
mil ВОЕННАЯ ЛИТЕРАТУРА
sc Scroogle
slov Яндекс.Словари
udic Urban Dictionary
video поиск по локалке
vpl Вплеер.ру
wayback Wayback Machine
wikien Wikipedia_En
wikiru Википедия
w Википедия
y яндекс
поиск по руборде rb
старый libgen lib genesis
старый pro


Линки не привожу, потому, что каждый может подобрать по своему вкусу.

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


@темы: firefox, допиливание, инфотех, научная организация труда

01:35 

Эндорфины и поисковая активность

Эти факты всплыли уже давно - в связи с попавшейся мне на глаза заметкой о дефиците внимания и его тренировке. Заметка не простая, ее автор - один из участников и создателей избирательной компании Обамы (которую в свое время успешно передрали дизайнеры Арсения Яценюка - но это так, к слову).

В статье обильно цитируется Никлас Карр. Которого, я все никак не дочитаю. Главным образом потому, что у нас переведены в основном его старые вещи, а там сплошная очевидность (что было не-очевидно в те времена, когда это писалось). Но речь не об этом. Заинтересовавшись, я заглянул в блог памянутого автора и нашел там заметку, одна из самых первых ссылок в этой заметке ведет на статью в которой описан весьма любопытный момент.

Мы все помним классический опыт с крысами, которым вживляли в мозг электроды, стимуляция которых доставляла удовольствие. Дальше крысе давали кнопку и она давила ее до тех пор, пока не умирала от голода либо жажды. Так вот. Если верить статье Эмили Йоффе - электроды раздражали вовсе не центр удовольствия. А центр поисковой активности. Если говорить образно, то мышь получала больше удовольствия от того, что находила кусочек сыра, а не от того, что его съедала. Т.е. вкус сыра был уже вторичен, а вот процесс поиска и находки - поощрялся порцией эндрофинов.

Заметка заставила задуматься и пересмотреть свой подход к пользованию Сетью.


@темы: инфотех, мысли

00:58 

Все есть в Интернете...

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

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


P.S.

Лисбет Саландер оказалась перед довольно серьезной методологической проблемой. Она была экспертом по сбору информации о ком угодно, но ее отправной точкой всегда являлись имя и персональный идентификационный номер конкретного человека. Если человек присутствовал в компьютерном регистре, а там непременно присутствуют все, то объект быстро попадал в ее паутину. Если человек имел компьютер, подключенный к Интернету, адрес электронной почты и, возможно, даже собственную страницу — а почти все люди, становившиеся объектами ее специфического исследования, таковую имели, — ей не составляло большого труда выведать его самые сокровенные тайны.

Задание от Микаэля Блумквиста требовало действовать противоположным образом. Проще говоря, нужно было идентифицировать четырех человек, исходя из крайне скудных данных о них. Кроме того, эти люди жили несколько десятилетий назад, а следовательно, ни в каком компьютерном регистре их, скорее всего, не было.

Опираясь на дело Ребекки Якобссон, Микаэль выдвинул предположение, что эти люди стали жертвами убийцы. То есть они должны были значиться в разного рода неоконченных полицейских расследованиях. Сведения о том, когда и где эти убийства были совершены, отсутствовали, известно лишь, что трагедии произошли до 1966 года. Ситуация требовала от Лисбет применить какие-то совершенно новые методы поиска.

«И как же мне поступить?» — призадумалась она, а потом включила компьютер, зашла на «www.google.com» и сделала запрос на: (Магда) + (убийство).

Это был самый примитивный из доступных вариантов поиска, но, к своему изумлению, Лисбет сразу получила неплохой результат. Первая же ссылка указывала на программу передач «ТВ Вермланд» [50] из Карлстада, которая представляла отрывок из сериала «Вермландские убийства», демонстрировавшегося в 1999 году. Потом она обнаружила короткую аннотацию в газете «Вермландс фолькблад», в которой говорилось следующее:

> В сериале «Вермландские убийства» очередь дошла до Магды Лувисы Шёберг из Ранмутреска — жертвы жуткого загадочного преступления, которое несколько десятилетий назад занимало умы полиции Карлстада. В апреле 1960 года сорокашестилетнюю жену фермера Лувису Шёберг обнаружили жестоко убитой в собственном хлеву. Журналист Клас Гуннарс описывает последние часы ее жизни и тщетные поиски убийцы. В свое время эта смерть наделала много шума, и высказывалось множество версий в отношении личности преступника. В программе выступит младший родственник жертвы с рассказом о том, как обвинение испортило его жизнь. В 20.00.


(c) Стиг Ларссон
"Девушка с татуировкой дракона"


@темы: инфотех, мысли, цитаты

22:15 

АБТФ: большая и малая карты

Прошло достаточно много времени с тех пор, как я писал про Аффигительно Большой Текстовый Файл. Это не значит, что тема стоит на месте - просто на все не хватает времени.

Основные новости следующие:


  1. Я дополнил навигацию по разделам и теперь могу произвольно выделять-вырезать-копировать-удалять отдельные заметки через d]] y[[ v]] и тому подобные комбинации клавиш.




  2. " --------- jumper ------------
    map ]] /^[#@]
    map [[ ?^[#@]
    " --------- jumper ------------



    Все заголовки у меня начинаются с # в Структуре и с @ в дневниковых заметках. То есть по ]] и [[ можно прыгать от заголовка к заголовку, а скажем по d]] удалить текущую заметку в буфер и вставит ее в каком-нибудь новом месте. Через v]]]]]]d можно скопировать три заметки подряд и так далее. Получилось очень удобно.

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

  4. И главное. Используя вимаутлайнер, я построил на его базе древовидную систему работы с блогом, которую условно назвал Большой и Малой Картами.




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



Идея Карты блога пришла мне в голову, когда я читал старую-старую книгу о юниксе Рассела Сейджа.

У него описывалась утилита, выводящая запущенные процессы в виде дерева. Мне понравилась простота метода которым оно создавалось. В принципе, можно было аналогичным образом составить дерево заголовков моего блога.

Каждый заголовок начинается с "диеза" - #. Количество диезов показывает уровень вложенности. Самый верхний заголовок раздела это:

# Заголовок1


Заголовок второго уровня - это заголовок:

## Заголовок2


И так далее.

Достаточно написать скрипт - на питоне, баше или вообще через sed, который

а) Пройдется по тексту блога и выберет из него все строки, начинающиеся с диеза

б) в собранных строчках поменяет диез на табуляцию.

В итоге из списка:

# заголовок1
...
## подзаголовок11
...
## подзаголовок12
...
# заголовок2
...
## подзаголовок21
...
### подподзаголовок211
...
## подзаголовок22
...
### подподзаголовок221
...


Получим дерево:

   заголовок1
подзаголовок11
подзаголовок12
заголовок2
подзаголовок21
подподзаголовок211
подзаголовок22
подподзаголовок221


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

Карту я получил, но мне хотелось большего. Хотелось, чтобы карта была живой - то есть чтобы заголовки работали в качестве ссылок. И ткнув в заголовок можно было сразу перейти к этому рзделу в блоге. Поискав в документации, я нашел, что если в тексте указано имя файла - можно встав на это имя и набрав gf (go-file) перейти к нужному файлу. А если после имени файла указан номер строки (например main.txt :: 54256) то по gF можно прыгнуть сразу к файлу main.txt на строку 54256.

То, что нужно. Номера строк можно было собрать с помощью скрипта, генерирующего карту. То есть теперь генерация карты происходила так:

а) Просмотреь текст блога. Выбрать из него все строки, начинающиеся с диеза

б) Для каждого найденного заголовка запомнить номер строки, где он был найден

в) в собранных строках поменять диез на табуляцию и дописать к получившейся строке адрес вида ИмяФайла :: НомерСтроки

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

Получилось удобно.

Свой опыт я описал в отдельной заметке.

Но как оказалось это не предел.





заметка из блога: 2010-05-09 01:53

читаю статью про эппловскую записную книжку "Proteus". Наводит на мысли.

1. Сейчас я открываю Вим через апплет на панели Гнома, открывающий main-блог.

Если нужен другой файл - часто открываю тот же main-блог и ухожу к другому файлу через :e . или :e <имя файла>.

Первая мысль - вывести в качестве апплета ссылку на otl-содержание main-файла.

Вторая мысль - сделать особое содержание - включить в заголовок имена друих блогов (smvk.txt, c4.txt, work.txt итд).

Третья мысль. Почему бы не генерить общий index.otl (в нем - первым уровнем имена блогов, дальше - зпаголовки блогов) и открывать именно его. Можно выиграть достаточно много времени на доступ.

При желании можно тем же макаром генерить дневниковые заметки. То есть делать файл flow.otl, куда в порядке дат сводить записи потоков из всех файлов. При желании можно включать либо строку контекста (у автора статьи это очень клевая идея), либо даже всю заметку целиком.(см ниже еще идеи по)




Еще идея по "большому содержанию" - в индекс можно добавить списки файлов (или даже содержание целиком!) из d.txt, out.otl, lab*.txt - разумеется с добавлением путей итд. Там, где это необходимо содержание можно добавлять целиком, а прочее - просто ссылками, дабы не тратить время на.

Имхо статья к этому толкает - универсальный доступ к своим текстам через Большую Карту.





Статья, о которой шла речь оказалась просто кладезью, породившей массу идей.

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

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

Результаты сказались очень быстро. Я заметил, что если раньше большая часть заметок и мыслей ухоила в Дневник (гораздо проще отбить таймстамп и написать заметку, чем вспоминать название заголовка и копаться в дебрях Структуры), то теперь мне стало удобно находить нужные разделы и писать свои идеи сразу по нужному адресу. Раньше идеи скапливались в Дневнике и либо требовали дополнительного разбора, либо вообще оседали в нем насовсем. Теперь все сразу шло по адресу, больше того за разделами стало можно следить "с птичьего полета", не говоря уже о том, что доступ к нужной информации очень ускорился.

Следующим "побочным эффектом" оказалась возможность добавлять в index.otl ссылки на другие текстовые файлы, лежащие где-то в системе. Это было просто сделать - достаточно добавить в скрипт, который генерировал карту, несколько строк, печатающих линки на нужные файлы. Сначала это были линки на текучку - тексты лабораторных и лекций, файлы с расчетами и исходники программ. Потом я добавил ссылку на .vimrc. Потом добавил ссылку на питоновский скрипт, генерирующий карту, чтобы можно было сразу добавлять нужные ссылки. В итоге index.otl из карты блогов вырос в действительно Большую Карту, обеспечивающую оперативный доступ во все ключевые точки системы и не содержащую при этом ничего лишнего.

Линки можно группировать по разделам, выделяя подразделы табами (у меня, например, образовались папки rc, bin, work).

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

Есть еще два глобальных хоткея. F11 вызывает карту в текущее окно (:b index.otl). И F9 который обновляет карту. Можно было бы привязать обновление карты к ее открытию, но практически получилось, что быстрее работать со статическим образом, обновляя его только когда это необходимо.

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

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

Теперь абтф в сочетании с большой и малой картами представляет собой вполне законченную и стройную систему.

Скрипты я привожу ниже и на всякий случай повторяю: система создана с помощь вима и питона, но это потому, что эти инструменты удобны именно для меня. Никто не мешает, например, генерировать карту через bash-, или perl-, или PHP-скрипт.

Большая Карта

z.py - отвечает за генерацию "дерева" Большой Карты




# -*- coding: utf8 -*-

def main():

''' список файлов блога '''
blogolist = ['main.txt',
'c4.txt',
'work.txt',
'turblog.txt',
'cites.txt',
'anotherw.txt',
'smvk.txt']

''' список ссылок на другие файлы системы'''
endlist = [ "rc",
" ~/.vimrc",
" ~/.gvimrc",
" ~/.conkyrc",
" ~/.config/openbox/rc.xml",
" ~/.config/openbox/autostart.sh",
" ~/.config/openbox/menu.xml",
" ~/.vim/syntax/blog_e.vim",
" ~/.vim/syntax/book_e.vim",
"other",
" ../cs_flame/trunk/f.otl",
" /media/SONY",
"z.py",
"zsm.py",
"year.otl",
"dater.otl",
"~/hive/python/lab12.txt",
"~/hive/python/lab11.txt",
"~/hive/myprog/tester/01/questor.py",
"~/hive/myprog/tester/01/tk.py",
"~/hive/myprog/tester/01/.",
"моделайн",
"| vim:foldlevel=0 ar go-=m go-=T go-=r go-=L go-=e tw=72 ts=3 sw=3 fo-=t path+=.,.."]

###################################################################################
# основной блок #
###################################################################################

for blog in blogolist:

tm = blog

# открываем файл и считываем оттуда текст

fh = open(tm,'rb')
line = fh.readlines()
fh.close()

zag = [] # список заголовков
num = [] # номера строк
link = []# сборник линков на заголовки

# проходим по тексту и модифицируем содержимое

for i in range(len(line)):
stroka = line[i]
if stroka[0] == '#':
zag.append(stroka)
num.append(i)


for j in range(len(zag)):
zag[j] = zag[j].replace('#','\t')
link.append(str(zag[j].partition(' ')[0] + '| '+ tm + ' : ' +str(num[j]+1)))

# выдаем в stdout заголовок файла
# print blog
print " "+blog

# выдаем в stdout содержимое
for j in range(len(zag)):
print(zag[j]+'\t'+link[j])
print "\t\tдля записи в журнал:"
print ('\t\t| '+ tm + ' : ' +str(len(line)+1))

if tm == 'main.txt':
endlist.append(tm + ' : ' +str(len(line)+1))


# print "\t\tдля дневниковой записи:"
# print ('\t\t| main.txt : ' +str(len(line)+1))


for i in endlist:
print i

if __name__ == "__main__":
main()





.vimrc - привязки для работы




" вызов Большой Карты по F11
" --------------------------------
map <F11> :b index.otl<CR>

" reindexer
" переиндексирует главное содержание
" --------------------------------
map <F9> :!python z.py > index.otl<CR>

" хоткеи Большой Карты
" --------------------------------
au BufNewFile,BufRead *.otl map <buffer> gf gF
au BufNewFile,BufRead *.otl map <buffer> <CR> gF
au BufNewFile,BufRead index.otl map <buffer> <RightMouse> gF





Малая Карта

Малая карта основана на старом скрипте - собственно в той заметке и объясняется как оно работает.

zsm.py - генерирует Малую Карту




# -*- coding: utf8 -*-

import sys

def main():

name = sys.argv[1:]
tm = str(name[-1])

# открываем файл и считываем оттуда текст

fh = open(tm,'rb')
line = fh.readlines()
fh.close()

zag = [] # список заголовков

# проходим по тексту и модифицируем содержимое

for i in range(len(line)):
stroka = line[i]
if stroka[0] == '#':
zag.append(stroka.replace('#','\t'))

# выдаем в stdout содержимое
for j in zag:
print j,

# дополняем содержимое моделайном
print ('\t\t| '+ tm + ' : ' +str(len(line)+1))
print "| vim:foldlevel=1 ar go-=m go-=T go-=r go-=L go-=e tw=72 ts=3 sw=3 fo-=t path+=.,.."

if __name__ == "__main__":
main()





Привязки для .vimrc




" Малая Карта ---------------------------------------------------
" здесь и далее - МалаяКарта == МК

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

function! SmallMap_Close()
" закрываем окно МК

execute "bd!"
normal zt

" варианты на правое-нижнее открытие меню
"set nosplitright
"set nosplitbelow

endfunction

function! SmallMap()
" проверяется - где находится курсор


" варианты на правое-нижнее открытие меню
"set splitright
"set splitbelow

if bufname("%") == "sm.otl"
" если внутри sm.otl - то файл проматывается на заголовок курсора

" сохраняем значение буфера q

let MainBuf = @"
let TempQ = @q
let @q = ''

" копируем тег в q
"на всякий случай - проверяется открыта ли вкладка
normal zo
"меняем табы на шарпы - так проще чем работать с переменными
execute "s/\t/#/g"
"копируем заголовок в q - без абзаца в конце
normal 0v$h"qy
"меняем шарпы на табы - чтобы вернуть файл к исходной позиции
execute "s/#/\t/g"

" полученный заголовок сохраняем в переменной
let Zagolovok = @q
" восстанавливаем содержимое регистра
let @q = TempQ
let @" = MainBuf

" прыгаем в окно большого файла
execute "normal \<C-W>w"

call cursor(1,1) " переставляет курсор в начало
call search('^'.Zagolovok) " находит заданный заголовок

" откручиваем заголовок в самую верхнюю строку
normal zt

" прыгаем назад в меню
execute "normal \<C-W>w"


else
" если нет - создаем sm.otl и переназначаем Enter и F12

"создаем МК
execute "!python zsm.py % > sm.otl"
"открываем файл МК в боковом сплите (возможны разные варианты)
execute "40vsplit sm.otl"

map <buffer> <Return> :call SmallMap()<CR>
" теперь Enter вызывает SmallMap и соответственно проматывает файл
map <buffer> <F12> :call SmallMap_Close()<CR>
" теперь F12 вызывает SmallMap_Close и закрывает файл
endif
endfunction

map <F12> :call SmallMap()<CR>





вот примерно и все что я хотел сказать о Большой и Малой Картах.


@темы: foss forever, me, vim, АБТФ, аффигительно большой файл, заметки себе, идеи, инфотех, мелочи, софт, фичи

21:56 

Пакетная работа с файлами в командной строке. Перекодирование mp3-файлов для изменения битрейта.

Мой yepp-плейер при всем его удобстве (особенно радует его неубиваемость и то, что он работает от батарейки, которую несложно достать в поле) отличается небольшой емкостью - всего 128М. Посему, музыку для него я обычно ужимаю до битрейта в 128 - лучшее качество я все равно не смогу оценить в наушниках, а место можно сэкономить.

Некоторое время я это перекодирование выполнял через пакетную обработку в Audacity, однако перед экзаменом по философии внезапно выяснилось, что Audacity на текущую ось я почему-то не поставил. Зато у меня был lame - который можно использовать для этих целей с соответствующими ключами, например так:

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


lame -h -b 128 --vbr-new music_old.mp3 music_new.mp3


-b 128 - битрейт 128
-h - использовать более медленный но качественно лучший алгоритм сжатия
--vbr-new - задействовать variable bitrate и еще более новый, быстрый и качественный алгоритм сжатия

Все эти ключи (и все остальное) можно посмотреть либо через man lame, либо запустив в комстроке lame --help.

Теперь нужно было сделать пакетную обработку - чтобы не задавать по одной команде на каждый отдельно взятый файл, а перекодировать все одним пакетом. Я воспользовался своей собственной старой заметкой про пакетную обработку djvu и на ее базе задал такую вот строку.

for x in *.mp3; do lame -V0 -h -b 128 --vbr-new $x $x.new; done


В запущенной директории она перебирает все файлы с расширением .mp3 и для каждого из них запускает lame, добавляя к окончанию получившегося файла ".new".

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

Я использовал утилиту rename. Она переименовывает файлы по регулярным выражениям примерно так, как это происходит в vim и sed:

rename 's/старый шаблон/новый шаблон/' *.mp3


Сразу запускать переименование не рекомендую - лучше сначала проверить как оно произойдет. Сделать "тестовый прогон" и убедиться, что не было ошибок. Для чего нужно два ключа:

-v подробно описывать действия
-n ничего не переименовывать - просто показать результат в режиме "пробного просмотра"

Пример:

$ ls *.new

1.mp3.new 2.mp3.new 3.mp3.new

$ rename -v -n 's/mp3.new$/mp3/' *.new

1.mp3.new renamed as 1.mp3
2.mp3.new renamed as 2.mp3
3.mp3.new renamed as 3.mp3


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

$ rename -v -n 's/mp3.new$/mp3/' *.new

1.mp3.new renamed as 1.mp3
2.mp3.new renamed as 2.mp3
3.mp3.new renamed as 3.mp3

$ rename -v 's/mp3.new$/mp3/' *.new
1.mp3.new renamed as 1.mp3
2.mp3.new renamed as 2.mp3
3.mp3.new renamed as 3.mp3

$ ls *.mp3
1.mp3 2.mp3 3.mp3



@темы: bash, foss forever, linux, mp3, ubuntu, инфотех, нот, рецепты, скриптинг, это просто работает

20:20 

user.js

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

Есть другой путь.

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


Все настройки, которые делаются через about:config попадают в prefs.js в профиле, где и хранятся. Сам prefs.js редактировать не рекомендуется - это "оперативный файл", куда множество расширений пишет свою инфу (образно говоря - "реестр файрфокс"). Зато предусмотрен файл user.js - все настройки из которого автоматически перекрывают настройки prefs.js. То есть, если я в этом файле задаю опцию user_pref("browser.startup.page", 0); (показывать пустую страницу в качестве стартовой) - то ее уже никто не перекроет.

После того, как я последний раз переустанавливал профиль - я забрался в prefs.js предыдущего профиля, проанализировал его (там масса всяческих настроек) и выделил те, которые до того я устанавливал вручуную. Сформировал из них user.js и положил к себе в профиль.

С моей точки зрения - алгоритм "посмотреть что лежит в prefs.js и сформировать user.js" - самый оптимальный путь, поскольку эти настройки уже сложились в ходе практики и ничего не нужно придумывать/искать по документации.

Итого. Мой user.js:

# поисковая страница в адресной строке - всегда гугл
## чтобы яндекс или кто-то еще не вздумал туда воткнуть что-то свое
user_pref("keyword.URL", "www.google.com/search?ie=UTF-8&oe=UTF-8&sourcei...");

# шрифты мозиллы

## не разрешать страницам использовать свои шрифты
## user_pref("browser.display.use_document_fonts", 0);

## разрешать страницам использовать свои шрифты
user_pref("browser.display.use_document_fonts", 1);

# мелочи

## если ставится расширение it'all text - использовать gvim для редактирования
## user_pref("extensions.itsalltext.editor", "/usr/bin/gvim");
## если ставится расширение it'all text - использовать самописный gvim-скрипт
## для редактирования
user_pref("extensions.itsalltext.editor", "/home/vik/bin/gvim-silent");

## открывать результаты поиска в новой вкладке
user_pref("browser.search.openintab", true);

## не показывать на запуске стартовую страницу
user_pref("browser.startup.page", 0);

## закрывать огнелис с закрытием последней вкладки
user_pref("browser.tabs.closeWindowWithLastTab", false);

## предупреждать при закрытии
user_pref("browser.tabs.warnOnClose", false);

## домашняя страничка - по совету сэра Хайвея - гуглридер
user_pref("browser.startup.homepage", "www.google.com/reader/view/?tab=my#overview-pag...");
user_pref("browser.throbber.url", "file:///usr/share/ubuntu-artwork/home/index.html");

## перечисление используемых шрифтов и их размеров
## (исключительно для моей системы)
user_pref("font.default.x-western", "sans-serif");
user_pref("font.minimum-size.x-western", 12);
user_pref("font.name.monospace.x-cyrillic", "Terminus");
user_pref("font.name.monospace.x-western", "Droid Sans Mono");
user_pref("font.name.sans-serif.x-cyrillic", "Droid Sans");
user_pref("font.name.sans-serif.x-western", "Liberation Sans");
user_pref("font.name.serif.x-cyrillic", "Liberation Serif");
user_pref("font.name.serif.x-western", "Liberation Serif");
user_pref("font.size.fixed.x-cyrillic", 14);
user_pref("font.size.fixed.x-western", 14);
user_pref("font.size.variable.x-western", 18);


Дополнительная информация:

http://kb.mozillazine.org/User.js_file


@темы: firefox, допиливание, инфотех, научная организация труда

15:37 

Минус Бар

Вчера обновился Яндекс.Бар. Впечатление удручающее - они переставили ссылку с ленты на ссылку на рсс-ы в почте. Что меня разозлило. Да и Фотки (очень удобные в целом) в последнее время глючат етс. Все это привело меня к мысли снести ЯБар и поставить вместо него Гуглобар. Гуглобар поставился, но произвел еще более тягостное впечатление. В частности - сложностями по сохранению настроек етс. етс.

В итоге, после обсуждения с сэром Хайвеем в твиттере, пришел к выводу, что эти бары для моих задач - слишком большие и неуклюжие. Что мне нужно? Онлайновые закладки, онлайновый рсс-ридер (держать на диске рсс слишком уж роскошно + все время возникает проблема синхронизации), возможно онлайноый блокнот. Рсс я перетащил на гуглоридер, почту получаю в основном через тандерберд по IMAPу, твиттер - через пиджин (очень удобно - распробовал это только недавно).

С закладками хитрее.

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


Делишес (как и гуглозакладки) меня не устроил главным образом своим механизмом сортировки по тегам. Теги, при всей их прелести и вкусности, лично мне неудобны. Мне нужны папки, желательно с возможностью вкладывать их друг в друга. Я заметил, что если работаю с иерархей, то (а) не трачу времени на вспоминание нужных тегов - поиск нужного места в иерархии выполняется руками почти без участия головы, (б) намного облегчается очистка накопившегося мусора, (в) мусор почти перестает накапливаться. В то время как система тегов провоцирует меня на накопление огромных объемов информации - "пусть лежит, если что найду по тегу".

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

Отсутствие практически бесполезного (Я|Гугло)Бара экономит место и не тормозит лису. Тоже касается сортировки, очистки и использования закладок. Синхронизация выполняется тогда, когда этого хочу я, а не в самый неподходящий момент. С учетом TinyMenu - у меня вообще почти не видно инструментов на панели. Зато сделал видимой панель закладок и разложил их по всей длине в папках - "просмотреть", "документация", "онлайновые конвертеры" и все такое прочее.

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

Также по ходу дела чищу все ненужное. В частности LjAddons отправляются в топку, поскольку нормально не работают, а большую часть их функционала у меня выполняет раздел с текстовыми примитивами (скопировать их оттуда гораздо проще, чем каждый раз прописывать в настройках LjAddons).

P.S. Перечитывая заметку понял, насколько хорошо она перекликается с настроением сэра АнВелкома :)


@темы: букмаркерство, инфотех, научная организация труда, нот, файрфокс, фичи, хаки

14:20 

Метаинформация и теги

2010-04-27 00:15

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

Это проясняет сразу несколько вещей

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



  1. Метаинформация (МИ) - это не сам объект. Это - "досье" на него.

  2. Каждый тип объектов (музыка, видео, текст, картинки) требует своей системы системы организации МИ - своих тегов, имен, программ, заточенных на работу именно с этим типом объектов.


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

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

    В теории можно завести универсальный справочник на все виды оружия с общим шаблоном сразу. Но никто так не делает. Зато есть справочники по танкам, самолетам, кораблям и стрелковому оружию. Вполне компактные и удобные. А графа "Водоизмещение" будет глупо смотреться в УниверсальномСправочникеВсегоОружия по отношению к АК47 или М16. Как и "Калибр" и "Емкость магазина" по отношению к авианосцу "Дж.Буш".


  4. Для аудио и видео такие системы уже есть - freedb и imdb. Что уже снижает объем работы в разы. Софт уже давно сведен в репозитории и ставится-обновляется-настраивается (хвала apt и dpkg) автоматом. Самый близкий пример - это ритмбокс, который сам подхватывает музыкальные файлы и раскладывает их по альбомам-рейтингу-рейтингу-пользователя и всему такому прочему по ходу дела расставляя пропущенные теги. Лично для меня такая система избыточна, но это детали :)



  5. Для фото услиями гугла (пикаса) и софта типа F-Spot такие системы уже создаются ("что-где-когда-кто").

    Тексты лучше всего сортировать полнотекстовым поиском (см Раскина).

    Для видео пока такая система избыточна. Однако, наверняка есть видеокомбайны со своими библиотеками, позволяющими разложить фильм по нужным параметрам.

    Что остается для организации?

    Мелочи. В моей системе - это карты, манга, диктофонные записи и сканированные книги. Тема на подумать.

  6. К вышеописанному нужна взможность создавать тематические выборки по своему усмотрению. А вот тут хорошо работают симлинки - они позволяют собирать все необходимые файлы в папки-проекты, сочетая в одной сборке все виды информации. Это должно быть что-то похожее на виртуальные папки-запросы в Thunderbird. То есть чтобы по теме "Т-34" можно было получить сразу нужные тексты, список аудиолекций, видео с этим танком и подборку фотографий.




@темы: идеи, инфотех, метаинформация, научная организация труда, нот, софт

13:42 

Тэги или папки?

Тэги или папки?

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

Civan, A., W. Jones, et al. (2008). Better to Organize Personal Information by Folders Or by Tags?: The Devil Is in the Details. 68th Annual Meeting of the American Society for Information Science and Technology (ASIST 2008), Columbus, OH.[1]
[1] Supported by an award from Google

Исследование темы юзабилити - что лучше для хранения информации - папки или теги?

Основные выводы (для памяти):


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

  • Теги хороши для поиска информации по ассоциативным связям (типа сделать "поиск решетом" по нескольким фильтрам).

  • Человек организует информацию намного богаче, чем это может быть представлено в терминах папок и/или тегов. Когда испытуемых просили сделать набросок инфосистемы от руки - схема получалась намного богаче.




@темы: интересно_в_основном_мне, инфоорганизация, инфотех, мелочи, научная организация труда, научная организация труда заметки себе, нот, фичи

21:21 

Djvu в Linux: how-to

Когда я переходил на linux - я выделил для себя несколько ключевых приложений, которые мне были нужны для нормального рабочего процесса и прямых аналогов, которых я не находил (точнее не находил аналогов, устраивающих меня).

Мне нужна была своя система хранения данных (что решилось с помощью АБТФ и vim), свой каталоггер (до недавнего времени я пользовался Cathy в связке с wine, но теперь у меня есть быстрый и дешевый самописный каталоггер), чайный таймер (он был сделан первым делом), и еще несколько мелочей. Отдельным пунктом стоял вопрос о преобразовании сканов в djvu-формат. Читаю я много, кое-что сканирую, кое-что храню на диске. Мне нужен был хороший djvu-просмотрщик (он нашелся почти сразу) и... софт, позволяющий обрабатывать сканы и генерировать djvu-файлы. А вот этот пункт выглядел загадочно. Однако, все оказалось проще, чем я думал :)

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



Отличное руководство есть здесь.

Я дополнил его генерацией tiff -> jpg и все отлично сработало.

В целом процесс выглядит так:

  1. Получаем сканы (фотографии)

  2. Доводим сканы до ума с помощью scantailor. Программа намного более продвинутая, чем все, что мне встречалось до того - она превзошла даже scankromsator, которым я пользовался под M$Windows.

  3. Сохраненные файлы конвертируем в отдельные djvu-странички, а потом объединяем их в один файл.


Конвертация идет через пакет djvulibre - конкретно его утилита c44 делает из jpg-ов дежавюки с заданным разрешением (и прочими параметрами), а djvm собирает их в один файл.

Если конвертить все из папки с jpg то можно сделать цикл, который прогонит сразу все jpg-и и сделает из них комплект djvu-ков с аналогичным названием.
for x in *.JPG; do c44 -dpi 300 $x; done

Дальше остается их склеить в один файл.
djvm -c ../ship.djvu *.djvu

У меня произошел нюанс. Мои страницы дневника были сосканированы в tiff, который не понравился c44. Я дополнительно переконвертил их с помощью утилиты convert из пакета ImageMagic.
for x in *.tiff; do convert $x $x.jpg; done



@темы: djvu, foss forever, linux, ubuntu, инфотех, нот, рецепты, это просто работает

14:08 

Информационные технологии с точки зрения военного

На http://www.globalsecurity.org лежит любопытный документ - COMMANDING A DIGITAL BRIGADE COMBAT TEAM: TACTICS, TECHNIQUES AND PROCEDURES. В нем полковник Рик Линч, который внедрял цифровые технологии в командовании "цифровой бригадой" в 4-й пехотной дивизии США, суммирует свой опыт и наблюдения. Кроме прочего там есть любопытный раздел, который называется "Myths of Digital Technology" - "Мифы Цифровых Технологий".

Там есть чудная цитата: "Remember -- it isn't IF the technology will fail you but WHEN". На русский навскидку это можно перевести примерно так: "Запомните - вопрос не в том МОЖЕТ ЛИ технология подвести вас, а в том, КОГДА это произойдет".


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

Это не значит стать технофобом. Это значит - понимать рамки возможностей современных технологий и смотреть на них трезво, а не через розовые очки рекламы.

P.S. Общий вывод этого документа тоже радует. Job One - Задача Номер Один - это владение тем, что есть в наличии - технологиями, программами, навыками. Важно не то, насколько продвинута технология, а то насколько ее освоил человек. Нож в руках профи опаснее винтовки в руках новичка.



@темы: здравый смысл, инфотех, линк, мысли, научная организация труда, нот, цитаты

Ворон. Ночной ворон

главная