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

Ставим нужные пакеты для сборки, включая git:

sudo apt-get build-dep gimp
sudo aptitude install git
sudo aptitude install libtool ruby

Создаём новый пустой каталог (например, /home/user/gimp-build), в котором и будем всё собирать. Выкачиваем для начала гимп и сопутствующие библиотеки из git (довольно длительный процесс, так что запасаемся терпением), команды запускаем внутри каталога /home/user/gimp-build:

git clone git://git.gnome.org/babl
git clone git://git.gnome.org/gegl
git clone git://git.gnome.org/gimp

Включаем микрофон или ещё какой источник звука к линейному/микрофонному входу.

Затем выбираем в alsamixer, например, нужный источник в capture device.

Запускаем собственно программу:

ffmpeg -f alsa -ac 2 -i hw:0 -acodec libmp3lame -ab 32k -ac 2 -f rtp rtp://192.168.1.2:5000

С аргументами можно играться, вещание нормально ловится, задержка минимальная.

vlc -vvv alsa://hw:0,0 --sout '#transcode{acodec=mpga,ab=128,channels=2,samplerate=44100}:std{access=http,mux=ts,dst=192.168.0.100:8080}'

Если вы используете Mercurial, то в списке ресурсов будут раздражающие файлы из каталога .hg. Чтобы их убрать, сначала в списке каталогов проекта выключаем скрытие файлов, начинающихся с точки, кликаем правой кнопкой по папке .hg, выбираем Properties и там включаем крыжик «Derived».

Очередная статья из цикла, посвящённого системам управления проектом (процессом). На этот раз немного структурированного формализма: общий план, сравнения, цели, перспективы. По сути, этот текст — самый первый документ, который пишется перед началом любого проекта. Целью проекта является продукт.

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

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

Если совсем упрощать, этапы жизненного цикла такие:

• сбор требований
• проектирование
• реализация
  • рецензирование кода
  • контроль исполнения задач
• тестирование
• внедрение
• поддержка/сопровождение

Для некоторых этапов есть различные инструментальные средства, например, для автоматизации тестирования есть TestLink, для контроля исполнения задач — разнообразные трекеры, например, Bugzilla, JIRA, Trac; для документирования есть разнообразные WIKI-системы. Есть попытки построить интегрированные решения из нескольких компнентов, например, линейка продуктов компании Atlassian — Confluence, JIRA и другие. Однако полноценного продукта, охватывающего ВСЕ этапы, мне не встречалось вообще.

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

В этой заметке в деталях описывается процесс создания собственного Центра сертификации и последующая генерация сопутствующих файлов: сертификатов, запросов на сертификат и так далее. Считаем, что работаем в терминале на линукс/юникс машине с установленным openssl.

Заметка является вольным переложением на русский язык вот этой статьи.

Базовые команды и некоторые скрипты и конфиги для редактора VIm. Дырявая память заставила это всё написать.

Введение

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

Перевод статьи Сары Шерд «Life Cycle of a Silver Bullet», 2003 г.

«Внимание! Выбросьте из головы другие методы оптимизации — мы открыли самый лучший. С нашим методом уровень качества у вас будет расти, а стоимость и время разработки — падать». Практически любой метод оптимизации провозглашается лучшим способом спасти молодой бизнес от проблем. К сожалению, спустя несколько лет этот же самый метод оказывается уже разгромленным и разнесённым в пух и прах, и заменяется новым. В этой притче рассказывается, как это происходит.