Это конспект, который я готовил для доклада на конференции, проводившейся местным университетом совместно с нашей LUG. Доклад «для самых маленьких», так что профессионалам просьба не жаловаться на поверхностность и обзорность.
Аудитория
Эта статья расчитана на два вида читателей. Во-первых, это люди, имеющие опыт программирования под MS Windows, но не имеющие такого опыта под GNU/Linux. Во-вторых, это люди, не имеющие опыта программирования вовсе. Однако, я предполагаю, что читатель в общем знаком с общепринятой в программировании терминологией, и ему не нужно объяснять, например, что такое «программа», «функция», «компилятор» или «отладка».
Средства разработки
Я буду рассматривать разработку с использованием тех средств, которые являются наиболее «родными» для GNU/Linux. К ним относятся:
Язык программирования C
Командная оболочка bash
Текстовые редакторы Vim и Emacs
Компилятор GCC
Отладчик GDB
Утилита для сборки проекта GNU make
Система управления версиями Git
Оконная система X11
Выбор именно этих средств не является догмой. Каждое из выше перечисленных средств может быть при желании заменено на другое. Однако, обычно под фразами наподобие «среда разработки Linux» понимается именно этот набор инструментов.
Языки программирования
Наиболее «родным» языком программирования для GNU/Linux является C. Это обусловлено следующими факторами:
GNU/Linux заимствует многие идеи (практически, идеологию) операционной системы UNIX;
Операционная система UNIX была написана на языке C (собственно, этот язык создавался именно для написания этой ОС);
Соответственно, ядро Linux и системное окружение GNU написаны тоже на C.
Ниже я буду рассматривать разработку с использованием языка C. Однако, этот выбор не является догмой. Другими популярными при разработке под GNU/Linux языками являются C++, Python, Perl. Конечно, могут использоваться и любые другие языки.
Среда разработки
В течение последних двух десятилетий очень широкое распространение получили т.н. IDE — интегрированные среды разработки. Такая среда включает в себя текстовый редактор, компилятор, отладчик, средства сборки проекта и мн.др. Такие среды есть и под GNU/Linux (наиболее популярны Eclipse, NetBeans, IDEA, KDevelop, Anjuta). Однако, история разработки под UNIX-подобные системы показывает, что IDE не являются не только единственным, но и наиболее эффективным средством разработки. Практически, правильный ответ на вопрос «какая самая лучшая IDE под GNU/Linux» — это «GNU/Linux это и есть IDE».
Часто можно встретить мнение, что большой проект без IDE разрабатывать невозможно. Это мнение легко опровергается. Первые версии UNIX писались даже не в Vim (его тогда ещё не было), а в Ed. Это так называемый «построчный» текстовый редактор, в котором вы можете редактировать за раз только одну строку текста. Весь файл на экране не отображается. В случае с UNIX по-другому и быть не могло — у разработчиков не было никаких экранов, а общение с системой осуществлялось при помощи телетайпов. Современное ядро Linux пишется в основном в редакторах Emacs и Vim.
Многие утилиты UNIX вызывают «текстовый редактор по умолчанию». Команда, запускающая текстовый редактор по умолчанию, берётся из переменной окружения $EDITOR. Некоторые утилиты смотрят сначала в переменную $VISUAL, и, лишь если она не установлена, в переменную $EDITOR. Это исторически сложившееся поведение: к старым компьютерам зачастую не было подключено никакого дисплея, а только телетайп, поэтому запускать экранный (визуальный) редактор смысла не было. В современных дистрибутивах обычно по умолчанию оказывается EDITOR=vi или EDITOR=nano. Указать использование другого редактора для одной команды можно так:
EDITOR=emacs some-command
Чтобы использовать нужный редактор по умолчанию всегда, нужно добавить в файл ~/.profile строчку типа
export EDITOR=emacs
Исторически сложилось так, ч
Ubuntu — возвращаем F10 в MC (Midnight Commander)
К сожалению, в Ubuntu 11.04 и 11.10 нажатия кнопки F10 перехватываются Unity. Это очень разжражает, так как в Midnight Commander’е эта кнопка часто используется, например, для выхода.
Избавиться о перехватов Unity просто. Для этого надо выполнить следующие действия:
1) Устанавливаем compizconfig-settings-manager:
$ sudo aptitude install compizconfig-settings-manager
2) Далее, запускаем его (в меню приложений находим compizconfig-settings-manager)
3) Вводим в фильтре Unity и находим Ubuntu Unity Plugin:
Автор: AlexWinner
PHP MongoDB — получаем _id только что созданной записи (MongoID)
Ситуация: мы хотим получить _id только что созданной нами записи. То есть, например, мы создали юзера и хотим знать айдишник, который MongoDB присвоила ему. Делается это очень просто:
Добавляем элемент:
$x = array(‘foo’ => ‘bar’);
$c->insert($x);
Проверяем внутренности $x:
var_dump($x);
array(2) {
[«_id»]=>
object(MongoId)#2 (0) {
}
[«foo»]
string(7) «bar»
}
Таким образом, для того, чтобы узнать _id, достаточно вывести $x[‘_id’]
Автор: AlexWinner
linux: flac cue ape разрезание на треки
Часто музыкальные альбомы представляют из себя цельный flac. К нему, как правило, прилагается cue-файл с метаданными, который описывает раскладку треков в нём. Иногда это неудобно: нельзя отделить треки, проблема с проигрывателями (мы же в linux, не так ли;) и т.д. Мы хотим разрезать изначальный музыкальный файл на отдельные flac-треки, чтобы было всё красиво, с метаданными, с тегами. На самом деле cue используется с любыми форматами, а не только с flac. Наша изначальная задача разбивается на две: работа с cue и резка flac/ape/… . Кодировать на выходе будем во flac.
Итак, что нам понадобится.
1) Кодек flac. Свободный. Скорее всего уже есть в системе.
Кодек ape. В разных системах называется: mac (monkey's audio) или monkeys-audio или как-то так. Если нужно резать ape, то нужен.
2) Пакет утилит cuetools для работы с cue sheet.
3) Пакет утилит shntool для резки файлов. В некоторых случая может сам работать с cue, так что cuetools для того, чтобы просто порезать может и не понадобиться.
Далее поток мыслей с реализацией каждой из целей, здесь FILECUE — файл cue, FILEFLAC — файл flac (или ape).
Резка файлов с использованием cuetools и shnsplit
cuebreakpoints FILECUE | shnsplit -o flac FILEFLAC
Итак, cuebreakpoints разбивает исходный cue-файл на длительности и отдаёт цифры на вход shnsplit, который режет flac на куски. Выходной формат указан через «-o flac».
Резка только с помощью shnsplit
shnsplit -o flac -f FILECUE FILEFLAC
Здесь cue sheet задан напрямую параметром «-f». В этих двух последних случаях получаются треки формата flac с именами split-trackXX.flac . Можно с помощью параметра -t указать вид имени получающихся треков, используя метаинформацию, например, в виде XX-ИмяТрека.flac
shnsplit -o flac -f FILECUE -t %n-%t FILEFLAC
Но теги задать при этом нельзя. Печально?
Добавление тегов с помощью cuetools
Используется скрипт cuetag (или cuetag.sh). В случае файлов вида split-trackXX.flac можно схитрить так:
cuetag.sh FILECUE split-track*.flac
Если задать имена выходных файлов другие, то они будут разные и применить cuetag ко всем сразу будет не так просто. Но можно написать скрипт, который будет по одному перебирать, у меня такой был когда-то, но уже неактуально, решил пользоваться готовым.
Готовое решение
Качаем последнюю версию утилиты (скрипта) cue2tracks, всё сделается за нас: кодирует из/в разных форматов, переименовывает, теггирует. Параметры описаны. Используется, например, так:
./cue2tracks -R -c flac -o "%P/%D - %A/%N - %t" FILECUE
Автор: Дмитрий
Mandriva/ROSA 2011 — что можно сделать после установки
Решил вкратце собрать тут ту инфу, что смог собрать, пользуясь свежей Mandriva (которая сегодня зарелизилась) уже месяц. Как всегда, приводимая здесь информация на свой страх и риск. Приведенные советы могут взорвать ваш компьютер, съесть вашего хомяка, начальник лишит вас премии, а лучший друг обидится на вас. Если все это вас не пугает — вперед!
Подготовка технической документации с использованием asciidoc и DocBook
Это мой конспект для выступления на семинаре, проводившемся нашей LUG. См. также презентацию к докладу.
Глава 1. Актуальность, цели и задачи
Вобще говоря, разработка технической документации — это достаточно обширная область. Техническая документация, по идее, прилагается чуть ли не ко всему подряд — инструкция к чайнику, проектная документация к мосту, мануал к программе. Конечно, в разных случаях аудитория у документов разная, разные и цели подготовки документации, а потому используются разные подходы. Я буду говорить в основном о подготовке документации к программным продуктам, хотя практически всё это применимо и к разработке других видов документации (хотя, вероятно, предлагаемой методики недостаточно).
Целью разработки документации к программному продукту является предоставление пользователю достаточно полной информации о продукте в том виде, в котором это удобно пользователю. Отсюда вытекают следующие задачи:
- Полная документация к большому продукту будет большой. Поэтому необходимо обеспечить автору документации простые и удобные средства для её подготовки, стараться не тратить время автора на посторонние вещи типа оформления этой документации или тонкостей xml-разметки;
- Пользователи у продукта, возможно, будут разные, а потому документацию необходимо предоставлять в разных форматах; самые популярные форматы — PDF, HTML и CHM;
- Так как пользователи разные, разной должна быть комплектация документации. В одних случаях нужно только руководство пользователя, в других — только руководство программиста, в третьих — и то, и другое.
Ниже приводится обзор различных технологий, используемых для подготовки технической документации, с оценкой их соответствия поставленным задачам, а затем предлагается собственная методика использования существующих технологий (с использованием свободного ПО).
Глава 2. Обзор технологий
Я начну с краткого обзора технологий, которые применяются для подготовки технической документации. Наиболее известны следующие технологии:
- MS Word и подобные системы;
Системы «единого источника»:
- Help&Manual и аналоги;
- DocBook;
- DITA;
- и другие.
Рассмотрим некоторые из этих технологий несколько подробнее.
Глава 3. Help&Manual
Главным плюсом этой системы часто является то, что она уже внедрена и работает. Также несомненный плюс — это система единого источника, т.е. из одного текста можно получить документ в разных форматах. Особенность этой программы и аналогов: это WISIWYG-системы. Насчёт того, является ли эта особенность плюсом или минусом, по сей день не утихают споры. Плюс WISIWYG-технологий очевиден, он заложен в названии: можно сразу видеть, как будет выглядеть текст в результате. К минусам WISIWYG относят следующие пункты:
- Есть такое высказывание: если система предоставляет возможность что-нибудь настраивать, она, фактически, заставляет вас это настраивать. В данном случае это относится к тому, что автор тратит время не только на написание текста, но и на его оформление, хотя это, по идее, не его задача.
- Такие системы склонны порождать совершенно дикую и нечитаемую разметку при конвертировании в HTML, LaTeX и другие подобные форматы. Например, легко можно получить разметку наподобие:
разметка. Это сказывается, как только появляется необходимость поправить такую разметку «руками». - При работе в таких системах люди склонны использовать не логическую, а физическую разметку (например, помечать кусок текста жирным шрифтом, вместо того чтобы отмечать этот текст как заголовок). Что интересно, большинство таких систем предоставляют возможность использования логической разметки, иногда даже удобную, но по каким-то психологическим соображениям люди не склонны её использовать. Это приводит к проблемам при изменении общего стиля оформления документа, а также зачастую при конвертировании в другие форматы.
В связи с послед