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

Вчера был мой последний день в Positive Technologies.

Утащил к себе в блог, чтобы не пропало. Очень уж меня эта картинка задела. Нашёл тут.

1 декабря 2011 года моя жизнь в очередной раз изменилась - я официально стал московским гастарбайтером.

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

Предложения начали поступать довольно быстро (работы много, а работников мало). Одной из первых была компания Positive Technologies (их предложние я в последствии и принял).

Я не стал ждать весны, а набрав список приглашений на собеседование, поехал в Москву.

Первое собеседование - Positive Technologies, не столько из-за того, что они одни из первых на меня вышли, сколько меня привлекала возможность сменить предметную область с веба на что-то другое. По итогам собеседования, которое, как мне казалось, я провалил (и не зря), я получил предложение, с оговоркой, что мне нужно будет многому научиться.

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

Пребывыя в сомнениях, позвонил жене - посоветоваться, идти ли мне в PT. Ответ был прост: "Ну ты же хочешь". В тот момент решение было принято и я отказался от остальных приглашений на собеседования.

1 декабря я вышел на работу.

Теперь я много пишу на Python'e и совсем чуть-чуть на С++ (исчезающе мало). Разрабатываю систему скриптования для MaxPatrol. И мне это нравится.

Разрабатываем интранет-систему. Есть сервер, за ним сидит оператор. Есть куча клиентов, за ними сидят обычные люди. Нужно наладить между ними видео-чат. На всех машинах стоит линукс.

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

• RED5 + flash. Поставили, настроили, написали даже своё приложение

  для RED5. Запустили. Не влазим по ресурсам, так как флеш на линуксе жрёт немеряно ресурсов.

• VLC. Делаем трансляцию потокового видео при помощи VLC, показываем

  собеседника им же. VLC запускаем как веб-сервер, когда приходит время показывать - дёргаем его сервер и передаём ему линк на видео. Снова не влазим по ресурсам, так как VLC при трансляции жрёт кучу памяти (вероятно, что из-за утечек).

• ffmpeg, ffserver, VLC. Едем дальше :) На этот раз трансляцию делаем

  при помощи ffmpeg + ffserver, а смотрим на собеседника при помощи vlc, который также запускаем как сервер. Из всех форматов более-менее безглючную работу показал RealMedia. Одна проблема - огромная задержка при передачи данных. Т.е. собеседник услышит мои слова на пару секунд позже, чем я их произнёс. Пока что это считаем вариантом для релиза.

В качестве эксперимента начал тесты erlyvideo. По описанию вещь просто замечательная :)

В работе программиста есть такая штука как сроки разработки, которые нужно определить заранее, и которые нужно выдерживать. Проблема планирования сроков есть у всех. У кого-то получается вложиться в срок, у кого-то нет. Часто планы меняются, но это не отменяет процесса планирования. И от программиста всегда хотят услышать заветные цифры, когда ж он сделает работу. Хотят все: заказчики, менеджеры, технические директора, в общем - начальство.

Выдать правдивые сроки, которые можно выдержать - самое сложное, потому что каждый проект - это что-то новое. Либо новые технологии, либо новая предметная область, либо алгоритмы, либо... Да мало ли этих "либо".

Для того, чтобы получить адекватную оценку работы я стал использовать разбиение на очень подробные задачи, вплоть до вызова функций.

Например, нужно написать редактор карт помещений на Flash для какой-нибудь системы наблюдения. Тогда я сажусь и пишу:

• Шаблон приложения. 2 часа.
• Загрузка картинок с сервера. 4 часа.
• Загрузка данных о наблюдаемых объектах. 3 часа.
• Создание картинок для наблюдаемых объектов. 2 часа на каждую разновидность. 5 разновидностей. Итого 10 часов.
• Интеграция с HTML. 4 часа.
• JavaScript-интерфейс для вызовы функция A, B и C. 6 часов, по два на каждый метод.
• Ну и так далее.
• ...
• Анимация объектов. НЕТ ОЦЕНКИ. Нужны исследования. 4 часа.

Преимущества такого подхода:

• очень мала вероятность обмануть себя самого и поставить маленький срок, которого не хватит;
• у руководства нет манёвра для сокращения сроков, потому что расписана каждая задача, даже исследования неизвестных частей;
• если сроки всё же сократят без объективных причин, а просто потому что так захотелось, то это уже не будет проблемой разработчика
• такой план - более подходящий плацдарм для обсуждения проекта, чем "я сделаю всё за месяц", так как "всё" понятие расплывчатое;
• такая подробная подготовка покажет и руководству и заказчику, что вы вникаете в работу и знаете, с какой стороны к ней подступиться.

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