Оптимизация сборки — одна из основных прелестей Gentoo, однако все описанное применимо к любому случаю компиляции ПО из исходных кодов. Все параметры сборки в Gentoo задаются в файле make.conf.
По сути нас интересует лишь переменная CFLAGS. CXXFLAGS должна быть равна CXXFLAGS="${CFLAGS}", а в MAKEOPTS лишь указывается число параллельно запускаемых процессов компиляции (обычно задают общее число ядер процессоров + 1).

С чего все начиналось

«Есть 2 типа админов — те, кто ещё не делают бекапы, и те, кто уже делают.»
Будучи первым типом админа, после случайного rm -rf * в директории с проектом, очень печально осознавать, что последняя резервная копия была сделана около полугода назад. Попав в такую ситуацию, я начал поиск простого и не ресурсоемкого средства для резервного копирования информации.
Критерии:
1) Возможность делать бекапы на лету в условиях ограниченных системных ресурсов (например VPS)
2) Возможность нативно удалять устаревшие бекапы
3) Возможность работать с примонтированной файловой системой

Настраивать VDS'ки для выкладки django-проектов довольно утомительно бывает, да и легко что-то забыть (т.к. делаешь это не каждый день). Гораздо лучше, когда этот процесс автоматизирован: с меньшими усилиями можно получить правильно настроенный проект и набор команд для работы с ним.

Существую разные подходы к этому процессу: специфичные для питона (fabric, buildout) или неспецифичные (puppet, Chef, наборы shell-скриптов и т.д.).

Подход fabric — локально выполняемый скрипт ходит по ssh на сервер и выполняет там команды. Этот подход довольно прямолинеен и прост в отладке, тем и хорош (обзор на хабре). Из разнообразных команд fabric постепенно вырисовался велосипед под названием django-fab-deploy. Это набор fabric-скриптов, который умеет настраивать серверы под Debian Lenny или Squeeze, а потом с минимальными усилиями разворачивать там django-проекты и управлять этими проектами в дальнейшем.

С выходом Debian Squeeze взялся за django-fab-deploy посерьезнее, поправил некоторые шероховатости и теперь, думаю, самое время об этом проекте рассказать. У проекта есть документация, тут будет краткий пересказ с лирическими отступлениями.

Ненадолго отставив серию статей о ЯП Ruby в сторону (1, 2, 3, 4, 5, 6, 7, 8, 9, 10), решил презентовать вам новый цикл о фрэймворке Rails. Набравшись некоторого опыта в «обучении» попробую вывести эту серию на уровень качества и продуманности несколько выше, чем прежде.

Целью первой части уроков по Ruby on Rails будет создание некоторого многопользовательского блога (аля Хабр). Также хочется отметить, что для этой первой части желательно иметь познание о Руби хотя бы на уровне трех-четырех капель. Хочется поскорей приступить к кодингу, но начинать все равно придется с теории.

Что такое Ruby on Rails (далее RoR)? Самый распространненый ответ – это базирующийся на ЯП Ruby (далее Руби) фрэймворк, который реализует шаблон (далее паттерн) MVC. Выделим два главных пункта из ответа:

• Это фрэймворк на базе Ruby
• Он реализует паттерн MVC

Разберем каждый отдельно.

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

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

Межпроцессное взаимодействие (Inter-process communication (IPC)) — это набор методов для обмена данными между потоками процессов. Процессы могут быть запущены как на одном и том же компьютере, так и на разных, соединенных сетью. IPC бывают нескольких типов: «сигнал», «сокет», «семафор», «файл», «сообщение»…

В данной статье я хочу рассмотреть всего 3 типа IPC:

1. именованный канал
2. разделенная память
3. семафор

Отступление: данная статья является учебной и расчитана на людей, только еще вступающих на путь системного программирования. Ее главный замысел — познакомиться с различными способами взаимодействия между процессами на POSIX-совместимой ОС.

1. Выучить новый язык программирования

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

Среди языков программирования отличный познавательный эффект и наверстывание опыта дают: Lisp (или Scheme), Форт, PostScript или Factor (стековые языки программирования), Haskell (строго типизированный, чистый функциональный язык) либо OCaml (объектно-ориентированный язык функционального программирования), Пролог (логическое программирование), Erlang (отличные паралельные вычисления).

Давайте каждый попробует ответить на вопрос: как установить apache на сервер? Этот вопрос порождает ещё десяток: какая ОС стоит на сервере, какую версию ставить, где лежат конфиги по-умолчанию и т.д. и т.п.

А теперь давайте попробуем ответить на вопрос: как установить apache на 1000 серверов? Тут, при стандартном подходе, вопросов возникнет ровно в 1000 раз больше. Часть из вас наверняка подумали, что можно написать скрипт на shell/perl/python/ruby, который будет обходить все сервера и устанавливать apache, другая часть подумала о distributed shell'ах (PDsh, dsh, etc), кто-то же подумал монтировать rootfs серверов по NFS.

В ряде случаев выше предложенные варианты решений удовлетворительны, но на практике я нигде не видел полностью гомогенных систем (зачастую, внутри компании можно встретить не только разные версии ОС, но и различные дистрибутивы. Также в России/СНГ очень распространена каша из FreeBSD/Linux в ядре проектов), так что вряд ли за адекватное время будет возможно написать скрипт, который установит и настроит apache на зоопарке в 1000 машин под CentOS, Debian, Ubuntu, FreeBSD всевозможных версий.

По моим наблюдениям, очень мало IT подразделений, даже очень крупных компаниий, используют в своей работе SCM (Software Configuration Management). В этом посте я постараюсь описать все преимущества использования Chef в IT инфраструктуре на простых примерах и больших масштабах.

Если же, после столь короткого вступления, вы не прониклись идеей Chef, да и времени читать длинный технический пост у вас нет, то рекомендую вам пролистать до конца и посмотреть как используем Chef мы, Engine Yard, 37signals и подумать, можете ли вы переложить на него часть своей работы.

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

1) Жонглирование.

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

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

Под катом список хорошей литературы.