typedef

Наверное, искусственному разуму в недрах CiteULike не понравились мои легкомысленные высказывания в его адрес, и он решил мстить… Или просто у разработчиков руки смонтированы в неправильное место? Сейчас разберемся.

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

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

Было особенно обидно, что исчезновение не сопровождалось никакими спецэффектами вроде клубов дыма, воя сирен или хотя бы надписи в профиле «статья такая-то удалена». Я согласен даже на отсутствие объяснения причин (это позволяет предположить, что я чего-то недопонял), но какое-то уведомление должно быть! Нет, раздел «Library» нагло врет: «You haven’t added any articles to your library yet».

Еще одна статья, закинутая в порыве последней надежды, сумела пережить ночь, после чего отправилась вслед за своими почившими товарищами. Черная дыра прям, даже заходить теперь туда страшно. Вдруг и меня засосет? И не останется от меня ничего, только надпись у жены в паспорте: «You haven’t married any man yet». Стивен Кинг отдыхает.

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

Другое преступление, не менее тяжелое, — молчание в экстренной ситуации. Большая удача, что стерлись первые же добавленные статьи. А что если бы я туда напихал 400 статей, а потом некоторые из них взяли бы и исчезли? Я мог не заметить потери важной информации. Замалчивание таких случаев исключает возможность доверия. Подвел сейчас — значит, может подвести и потом.

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

(1 голосов, средний: 5.00 из 5)

 Loading ...

Я довольно продолжительное время носился с идеей написать  программу для управления личной библиотекой научных источников (книг, статей, отчетов и т.д.). Мои потребности были нехитрыми, но одних средств файловой системы явно не хватало.

С одной стороны, в иерархической структуре вроде дерева каталогов расположить все мои источники просто невозможно. Например, гипотетическая статья о моделировании протокола TCP относится сразу к нескольким категориям, скажем, «моделирование» и «TCP». Это теговый подход, и возможность хранить такие пометки и осуществлять по ним поиск уже была бы большим подспорьем. Еще лучше, чтобы система категорий/тегов была иерархической, чтобы можно было пометить статью тегами «моделирование%имитационное моделирование» и «передача данных%сетевые протоколы%стек TCP/IP%TCP». В принципе, это реализуемо с помощью ссылок, но, во-первых, это муторно, а во-вторых, у ссылок предостаточно ограничений. В будущем этим должны будут заниматься теговые ФС, но сейчас этот вариант не подходит.

С другой стороны, помимо семантических меток, прикрепленных к источнику, хотелось бы еще хранить и некоторую дополнительную информацию:

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

К счастью, я не успел начать писать свою программу, когда нашел CiteULike. Это ровно то, о чем я говорил. Даже не буду вдаваться в подробности и описывать фичи. Большая часть из них мне не нужна, а остальное я уже описал выше. Позволю себе только пару оговорок:

• теги таки не иерархические;
• при экспорте в BibTeX добавляются мусорные поля вроде citeulike-article-id и priority, которые, впрочем, несложно вычистить;
• много всякой лишней ерунды, загромождающей интерфейс (явно не обошлось без feature creature);
• существующую локальную библиотеку статей переносить туда придется долго и с трудом; настольная программа могла бы большую часть работы сделать самостоятельно, пройдя по иерархии каталогов и индексируя файлы.

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

UPD: прежде чем пользоваться CiteULike, ознакомьтесь со следующим постом. Редакция изменила свое мнение.

(1 голосов, средний: 5.00 из 5)

 Loading ...

Возникла у меня такая задача: в действиях одной из целей Makefile выбрать из каталога файлы по маске *.eps и скормить их программе epstopdf. Проблема в том, что epstopdf принимает в командной строке только один файл. Нужен цикл. Я нашел два решения.

Первое — использовать шелловский for:

build:
    for epsfile in `ls *.eps`;\
    do\
        epstopdf $$epsfile;\
    done

Здесь две хитрости: экранирование концов строк (потому что for — фактически одна команда) и использование $$ перед именем переменной (потому что иначе она будет считаться макросом Make).

Второй способ использует возможности самого Make:

%.pdf: %.eps
    epstopdf $?
 
build: $(patsubst %.eps, %.pdf, $(wildcard *.eps))

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

К сожалению, все это не удастся сократить до такого:

build: $(wildcard *.eps)
    epstopdf $?

Здесь макрос $? развернется в строку, содержащую имена сразу всех EPS-файлов, что противоречит условию.

(1 голосов, средний: 5.00 из 5)

 Loading ...

Любителям посидеть в рабочее время на башоргах и ЖЖ посвящается. Изначальная идея «пинарика» была проста — наглядно продемонстрировать себе, что жизнь, мол, проходит мимо, пора бы уже что-нибудь существенное сделать. Закрашиваешь, закрашиваешь ячейки, и прям видишь, как на глазах сокращается отведенное тебе время.

Ворктрек — производная пинарика. В нем можно еще и пометить каждый день как продуктивный (зелененький) или непродуктивный (красненький). И еще комментарий приписать. Такая штука пинает уже серьезно, с двух ног. Подсознательный эффект поразителен: начинаешь сам с собой устраивать соревнования. Сколько я смогу подряд «зеленых» дней сделать? Слабо неделю без «красных»? Эстеты могут даже организовать свое рабочее время так, чтобы на картинке красными и зелеными клетками написалось какой-нибудь слово. Например, «труд». Или «мир».

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

(2 голосов, средний: 5.00 из 5)

 Loading ...

Без сомнения, Emacs — лучший текстовый редактор  из тех, что мне доводилось видеть. После некоторого периода адаптации и допила производительность труда возрастает фантастически. Но только если выполняются два условия:

1. работа выполняется с отдельными файлами, не объединенными в проект;
2. узким местом производительности является именно ввод или редактирование текста, а не мыслительный процесс.

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

С проектами в Emacs все ужасно. Особенно с программными проектами. Есть мощнейшие режимы и модули, призванные сделать из текстового редактора полноценную IDE — etags, semantic, ecb, cedet, ede… Масса возможностей, множество путей расширения и настройки, но… Довольно быстро понимаешь, что это напоминает попытку Linux пробиться на десктопы домохозяек. Разработчики пыжатся, пытаются реализовать функциональность «больших» IDE, «догнать и перегнать», но выходит, что все это не повышает производительность, а снижает ее.

Я честно больше двух месяцев пытался настроить cedet и ecb под свои нужды, писал свои функции, часами рылся на емаксовых сайтах. Единственный положительный эффект — относительно неплохо выучил elisp, хотя многие сочтут это сомнительным достижением. Короче говоря, для проектов Emacs непригоден.

Поэтому я вернулся в Eclipse. И вскоре обнаружил там вот такое:

И правда, привязка базовых операций как в Emacs! Но моя радость была недолгой: мозг решительно воспротивился использованию привычных, казалось бы, комбинаций, в «некошерной» IDE. Я постоянно нажимал не туда, портил исходники, плевался и ругался. Кроме того, все мои любовно написанные elisp-функции и нестандартные привязки, понятное дело, в Eclipse не перетащишь. Поэтому я вернул все на место.

Теперь работаю в Eclipse. Комфорт разработки заметно вырос.

(Еще не оценили)
 Loading ...

Все началось с того, что я подсел на emacs. Путь юного джедая был долог и тернист, но в конце концов я вынужден был согласиться, что да, иногда emacs оказывается эффективнее, чем другие редакторы и IDE. И что если уж подсел — то все, организм начинает отторгать все остальное. Не иначе как специальный гормон начинает вырабатываться, вызвающий эйфорию при пользовании emacs и депрессию вместе с неконтролируемыми вспышками гнева — во всех остальных случаях. А уж какие ощущения емаксист испытывает при редактировании своего ~/.emacs, не стоит даже и пытаться описывать…

Нет, конечно, с первого раза он мне не понравился. И со второго, и с третьего тоже. Но я был настойчив, потому что хотел убедиться, что все эти странные люди со Столлманом во главе ошибаются. Наивный… Майн готт, я даже нашел людей, которые пользуются emacs в Windows! Теперь я могу их понять. Чем дальше, тем меньше хочется переключаться в другое окно. Нужна оболочка — пожалуйста, M-x shell. Почту почитать — сколько угодно, rmail-mode. С файлами и каталогами поработать — вот, извольте, C-x d. Рисунок нарисовать, PDF посмотреть, по Интернету посерфить… Ах да, в нем еще можно редактировать текст (вот ведь приятная неожиданность)! В результате ловишь себя на мысли, что и Linux в общем-то не очень нужен, и только зря жрет ресурсы.

Но падаван вырос, и настало ему время заняться поддержкой многострадальной отечественной науки. Наука у нас в стране, говоря откровенно, каким-то парадоксальным образом существует отдельно от занимающихся ею ученых, в своеобразной параллельной реальности. Оцените: ВАКовский журнал требует предоставлять публикации в формате Word, и чтоб не более 5 страниц. Вместе с иллюстрациями и библиографией. Видели когда-нибудь нормальную научную статью из 5 страниц? Найдете — покажите мне. А уж статей, качественно сверстанных в Word, — днем с огнем; большинство просто не в курсе про такую вещь, как стили.  Но я на поводу у толпы не иду и как правильный апологет CS все пишу исключительно в (La)TeX. Потом как-нибудь через ODF и MathML сконвертирую, если припрет.

Но что-то меня сегодня понесло на отвлеченные темы болтать, пора бы перейти к делу. Так вот, поскольку emacs теперь мой дом родной, то AUCTeX — просто-таки домашние тапочки, основная работа происходит именно в нем. Но какой же научный текст без библиографии? Вот и пришлось искать некий редактор BibTeX-файлов, встроенный в emacs (кто не в курсе, про что вообще речь и зачем он нужен, почитайте обзор BibTeX от Дебианщика). Таковым редактором оказался ebib. Это не режим никакой, а полноценное elisp-приложение, вроде Gnus.

ebib прост, как пятак. Для начала в ~/.emacs записываем строчку:

(autoload 'ebib "ebib" "Ebib, a BibTeX database manager." t)

Теперь запускаем его по M-x ebib, видим два буфера: верхний (индексный, index buffer) и нижний (буфер записи, entry buffer). В индексном буфере отображается список ключей всех записей в bib-базе. При выборе одного из ключей в буфере записи отображаются поля, описывающие соответствующий библиографический источник.

Я не буду подробно и по шагам описывать, как именно пользоваться ebib — дело нехитрое. Лучше приведу небольшой набор наиболее полезных привязок:

• o —открыть (создать) bib-файл;
• q —выйти из ebib совсем (в индексном буфере) или завершить редактирование записи (в буфере записи);
• z — отправить ebib на задний план, без закрытия файла (вернуть обратно опять по M-x ebib);
• a — добавить запись;
• e — редактировать запись (в индексном буфере) или поле (в буфере записи);
• E —изменить ключ записи;
• C-x b —завершить редактирование многострочного поля;
• c, x, y —copy, cut, yank;
• s — сохранить файл;
• w — сохранить файл в другое место;
• / — поиск в базе по регулярному выражению;
• P — сформировать файл с таблицей всех записей в базе (мегаудобная штука!).

Теперь о самом главном — об интеграции с LaTeX-mode. Это происходит с двух сторон. Если мы редактируем tex-файл (то есть, находимся в LaTeX-mode), то в нашем распоряжении есть две замечательные функции:

• ebib-insert-bibtex-key — в позицию курсора вставляется ссылка на источник, ключ которого мы зададим в минибуфере (при этом работает автодополнение!);
• ebib-entry-summary — отобразить информацию о цитате, на которой находится курсор.

По умолчанию эти функции не закреплены за клавиатурными комбинациями, поэтому рекомундую сразу дописать в ~/.emacs следующее:

(add-hook 'LaTeX-mode-hook #'(lambda () (local-set-key "\C-cb" 'ebib-insert-bibtex-key)))
(add-hook 'LaTeX-mode-hook #'(lambda () (local-set-key "\C-cs" 'ebib-entry-summary)))

Разумеется, для корректной работы на заднем плане в это время должен работать ebib. Если же мы находимся в индексном буфере ebib’a, то можем выбрать ключ и нажать p (push), вставив тем самым цитату в некоторый другой буфер. Это хорошо тем, что перед глазами сразу вся база, и не нужно мучительно вспоминать имена ключей.

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

(Еще не оценили)

 Loading ...