DDL триггеры будут в FB3

По сути теперь можно вешать события и всяческие проверки(в том числе и стиля!) на изменение метаданных.

create trigger trig_ddl_sp before create procedure
as
begin
    if (rdb$get_context('DDL_TRIGGER', 'OBJECT_NAME') not starting 'SP_') then
        exception e_invalid_sp_name;
end

Подробнее:
http://firebird.svn.sourceforge.net/viewvc/firebird/firebird/trunk/doc/sql.extensions/README.ddl_triggers.txt?revision=51203

Памятка по вопросам на собеседование

Когда-то делал нечто похожее, тем более под каждое собеседование свой набор вопросов. Но в общем случае может пригодится.
http://nmihouse.com/?p=31

На что тратится наше время :)

Интересное IT-мероприятие от Виктории Придатко

http://hr-maverick.blogspot.com/2010/12/15-it.html

В очень простом и демократичном формате, вечерком, в офисе Циклума рассказали о своей практике два человека.

Один из докладов - о том, как работают с распределенной командой:

• Четкий, фулл-тайм график, синхронизированный со всеми. С 11 до 20.
• Обязательные совещания КАЖДЫЙ _вечер_. [пока еще не встретилось описание успешной ораспределенной команды без них].
• Не нанимают людей с детьми - считают что с работой это не совместимо
• Отдают предпочтение работавшим в оперсорсе, и табу на работу с фрилансерами. Пытаются работать только с лучшими.
• Слабые девелоперы тянут производительность _всей команды_ вниз (?)
• Исповедуют "меритократию" - на тех. уровне должна быть иерархия авторитетов, демократия не работает. Кто-то должен иметь возможность принять окончательное решение.
• Активно используют механизм burn-down диаграмм. Горизонт планирования до месяца, обычно меньше. Попробовали на три - фейл.

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

Второй доклад более прагматичный и механический, про Зарплаты в ИТ, но через призму аутсорса:

• По статистике при переходе подъем ЗП обычно 25%
• У человека прыгающего по компаниям зп растет быстрее, чем у эволюционно растущего на одном месте
• Если использовать бонусы, то не менее половины зп, иначе они не работаю/мотивируют (?)
•  Составляющие пересмотра зп:
   - инфляционная (для $ сейчас 5%)
   - рыночная
• Частота перемотра до мидла - раз в 2-6 месяцев, для мидлов-синьоров - раз в год
• Один из способов обсуждения повышения - спросить у человека как он видит составляющие своей зп, и за что он хочет повышения в данном случае.
• "шантаж уходом" - работает один раз, потом нужно увольнять(если конечно предыдущие пункты исполняются) (хотя на это звучали возражения)
• Безпроцентный кредит - эффективный механизм мотивации. После его выплаты у сотрудника создается иллюзия повышения зп.

UPD
Вот еще одна подборочка - http://sergtk-it.blogspot.com/2010/12/it.html
Интересно, но многие вещи мы восприняли совершенно по разному :-/

UPD2 
Презентации http://hr-maverick.blogspot.com/2010/12/15.html

"...и ждем, что они друг с другом договорятся. Они не договорятся."

Интересное интервью и цитата из него:
 
http://experience.openquality.ru/elena-sagalaeva-interview/

Елена, сможете ли вы рассказать о наиболее значимой ошибке, которую вам доводилось видеть в проектах?
Самые суровые проблемы возникают из-за неверно принятых решений, не из-за того, что программист где-то плюс с минусом перепутал. И из-за попыток решить технические проблемы политическими методами. Или вот, например, ставим работать программистов, которые друг друга не знают. Не назначаем среди них главного и ждем, что они друг с другом договорятся. Они не договорятся. Это классическая запланированная катастрофа, я несколько раз такое наблюдала.

Высоконагруженные системы

Встретилась хорошая подборка статей про высоконагруженные системы -  http://www.insight-it.ru/highload/. Конечно очень обзорно, но есть очень интересные моменты. Рекомендую.

PS
Интересно, а что можно считать критерием сложности проекта? Ведь высокая нагрузка - это только одна сторона медали.

Про git на "Инструменты Agile"

Небольшая подборка выступлений по практическому использованию инструментов разработки в agile-командах (Yandex, Softline...) http://lib.custis.ru/Agile-tools-2010

И собственно цитата всего поста:

«GIT - инструмент для богов». «…После того, как мы убедились, что не все люди боги…»