HDR #5

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

Обновление deadchannel.ru

Внёс давно копившиеся изменения в deadchannel.ru:

1. Обновил СУК.
2. Вернул иконки новостей, в том числе для видеороликов с Vimeo и RuTube.
3. Добавил подписку на новости по электронной почте (для тех, кто не в ладах с RSS).
4. Новости можно постить прямо с главной страницы.
5. Видео можно проигрывать прямо в списке новостей, не нужно открывать новую страницу.
6. Исправлен поиск: больше не нужно вводить запрос два раза.
7. Исправлен RSS с музыкой (больше не попадаются картинки).

О постепенном засорении диска

Недавно только поставил заново систему, а свободного места на диске уже стало заметно меньше. Baobab подсказал, что основной источник мусора — Google Chrome (см. issue 16705) и папка ~/.cache. Я давно на это натыкался, и пытался даже скрипты писать, которые удаляют мусор, но надоело.

Сегодня придумал просто монтировать её в память, как /tmp:

none /home/hex/.cache tmpfs rw,nosuid,noexec,nodev,uid=1000,mode=0700 0 0

Памяти 2ГБ, большая часть всё равно обычно простаивает. Будет польза.

О непрерывной интеграции

Прочитал на хабре "Введение в Continuous Integration". Мне кажется неправильной сама идея коммитить что попало, а потом мастерить роботов, которые будут периодически всё это тестировать и рассказывать о неудачах. Если основная идея в том, чтобы исходный код всегда был работоспособен, такой робот просто бесполезен, и даже чтобы максимально быстро неполадки обнаруживать, будет эффективнее тестировать перед коммитом, а не после.

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

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