Очень редко удается найти человека, который до этого работал с *точно таким же* стеком технологий. Поэтому, практически всегда, ваша компания будет для него чем-то новым. И сразу требовать от него чтобы он разбирался досконально во всех ваших нюансах — не очень правильно. Если вы не готовы учить человека первые два-три месяца, то вы, конечно, можете требовать «все и сразу», но и будьте готовы платить ему в 2 раза больше.
А про код — повторюсь — можете дать задачу на дом. У вас в офисе он будет писать код точно так же — без человека за спиной и самостоятельно как минимум по день-два до очередного ревью.
Я сначала давал задачки на дом, но потом понял что даже они мало что определяют. Маленький кусочек кода ничего не покажет — работать он будет, а в большом проекте налажать может любой, в конце концов.
Почаще ставьте себя на место собеседуемого и смотрите на себя его глазами. Вам бы хотелось вот так сидеть и готовиться услышать вопрос «сколько в этой комнате поместится шариков» или «а ну-ка напишите за три минуты быструю сортировку»?
Ну вот он не написал, ошибся. А вы про себя сидите и думаете: «мда, обмельчала молодежь… Опять я очередного уделал. Какой я крутой!».
Это все, конечно, мое мнение. Возможно, в каких-то компаниях обязателен более строгий отбор, чтоб только «лучшие из лучших, которые помнят все алгоритмы, которые 100% соответствуют нашей вакансии и уже через три дня сделают все хорошо». Ок, возможно.
Задавая «задачки» на собеседованиях интервьюер должен быть готов к тому, что его точно так же могут попросить решить «задачку»:
«Мне бы хотелось представлять с кем я собираюсь работать, поэтому пока я пишу ответ на вашу задачку про потоки, пожалуйста, напишите решение для вот этой задачки». И там тоже может быть все что угодно.
Я ненавижу писать код когда у меня из-за плеча кто-то смотрит. И пусть даже выходит из комнаты, но в таком стрессе человек нормально не реагирует. Если вам нужны программисты, которые будут работать в стрессовых условиях — ну что ж, ваше право. Но я предпочитаю работать спокойно — вот в таких условиях и надо давать задачи. в идеале — дайте задачу на дом, пусть пришлет решение по почте. Пусть поищет на stackoverflow, у друзей, где угодно. Вам же важен результат, а не как он потеет? Сумел найти решение интересующей вас проблемы из вашей области за день-два? Что вам еще надо?
Я на собеседованиях никогда не даю задач на «напишите программу вот на этой бумажке». Пока человек рассказывает о своем опыте — уже можно составить впечатление о задачах, которые он решал. Задайте парочку вопросов по его теме — будет понятно насколько глубоко он «в теме».
Хотите поумничать — спросите парочку общих вопросов из теории типа «что такое нормализация», «когда вы применяете наследование, а когда нет», и тп. Спросите что первым делом он настроит в MySQL когда поставит сервер. Или PostgreSQL.
И все без бумажек, простыми вопросами, ожидая простые ответы.
И он не должен ждать, что вы вдруг прицепитесь: «а у вас не запустится программа! Что тут не так?? А точка с запятой не стоит в конце!!!».
Как человек думает — видно и так. Как он отвечает на вопросы — присмотритесь — так он и будет работать в вашей команде.
Я выбирал людей «под себя» и под команду — сработается ли, будет ли обсуждать проблемы или замкнется и будет молча что-то делать? Будет ли принимать критику и готов ли будет, например, принимать мои замечания? Я сам достаточно авторитарен и приходилось отказываться от людей с опытом, но, по которым было видно, что с ними у меня могут быть конфликты (даже из-за меня).
Да, спасибо за напоминание. Но чем больше я смотрю на это все и перечитываю написанное — все больше мне кажется, что это просто моя рефлексия на прошлое и все проблемы, которые я хотел описать — могут быть решены (и решаются) сейчас уже другими инструментами… По сути статья сводилась в конце к описанию разработки собственного агента, который управлялся распределенной системой из деплоймент-серверов по комбинированной push-pull схеме. Около половины составляли размышления о прошлом, которые мало кому интересны, а также придуманное описание процесса некоей несуществующей компании, для которой был бы полезен мой подход.
Статья, действительно, опоздала года на три. Плодить ненужный контент для интернета я не хочу — его и так много.
Лучше уж я выберу время и напишу о чем-нибудь более полезном.
Да и вообще текст оочень трудно читается — подозрение на машинный перевод и неграмотность писателя.
Не могу пройти мимо «транзакцыонных», а остальные ошибки — бог с ними уж…
Ну и вот такие обороты, пожалуйста, не допускайте?
Если вы думали, странное место для хранения ваших данных был ядерный бункер, то Вы ошибались, подумайте еще раз.
А вообще, спасибо за статью, тема довольно интересная. Отдельное спасибо как читателя за то, что не вставляете в каждый абзац ссылку на сайт своей компании.
Простите, но это лишь то, как конкретно вы представляете себе этот термин. У других представление может отличаться.
Ро́бот (чеш. robot, от robota — подневольный труд]]) — автоматическое устройство. Действуя по заранее заложенной программе и получая информацию о внешнем мире от датчиков (аналогов органов чувств живых организмов), робот самостоятельно осуществляет производственные и иные операции, обычно выполняемые человеком )[1][2]. При этом робот может как и иметь связь с оператором (получать от него команды), так и действовать автономно.
(wikipedia)
Термин «роботы» используют также применительно к некоторым интеллектуальным агентам — программам, примерами которых могут служить, например, боты или поисковые роботы.
Не соглашусь с вами по поводу сложности. Я копался в нем и, в принципе, все довольно внятно.
Для такого большого функционала оно очень грамотно написано — без абстракций было бы много копипасты.
В celery/kombu настраивается все что угодно — вы можете переписать/перегрузить почти любую часть с нужным вам функционалом. Посмотрите только на список брокеров — входной интерфейс один, но работает с совершенно разными движками.
Это уже третья версия же, обычно к такой цифре автор как раз два раза понимает как убрать накопившийся говнокод и сделать «чисто».
А можете найти ссылку на номер бага, о котором вы говорите? Просто интересно посмотреть на комментарии… Автор Ask Solem, вроде, довольно общительный и адекватный, на критику реагирует нормально…
Классический пример: социальная сеть, в которой пользователи загружают картинки в свои профайлы. После загрузки картинки должны быть сконвертированы в один и тот же формат и обрезаны до определенных размеров. После этого они должны появиться в профайле, а всем подписчикам отправлены уведомления по почте. Если делать это синхронно запросом, то сервер может не справиться в пике, да и ждать долго всех операций, а мы не хотим долгие коннекты к серверу держать.
Как решение — мы ставим отдельный сервер (несколько серверов), на которых крутятся celery-воркеры. при загрузке картинки она пишется на временный storage и в очередь celery кладется задача с (user_id, image_name). Юзеру в браузер возвращается «200 OK» и он знает что картинка скоро появится.
Первый освободившийся воркер подхватывает эту задачу и обрабатывает картинку, кладет ее в базу, а потом создает новую задачу в другой очереди на отправку уведомлений (которая может тоже работать довольно долго).
В RabbitMQ такой ситуации бы не возникло — при разрыве соединения с consumer'ом Rabbit автоматически пометит задачи как снова ожидающие в очереди. И используйте ACK_LATE.
RabbitMQ предназначен именно для работы с очередью сообщений, у него внутренний механизм это обеспечивает. Mongo — нет, это просто хранилище. Ей сказали «запиши 1 в колонку» — она и записала. И ее не волнуют ваши очереди-шмочереди. И как поддерживаемый брокер она имеет статус Experimental в celery.
Поэтому мне кажется, что вы зря жалуетесь. Именно из вашего описания RabbitMQ — это то, что вам бы подошло. Он довольно дружелюбен и не так сложен в установке, ИМХО.
Правда, перевод ужасный — возможно, потом в оригинале перечитаю. Ищите хороший перевод!
Ах, люблю я жить в будущем!
А про код — повторюсь — можете дать задачу на дом. У вас в офисе он будет писать код точно так же — без человека за спиной и самостоятельно как минимум по день-два до очередного ревью.
Я сначала давал задачки на дом, но потом понял что даже они мало что определяют. Маленький кусочек кода ничего не покажет — работать он будет, а в большом проекте налажать может любой, в конце концов.
Почаще ставьте себя на место собеседуемого и смотрите на себя его глазами. Вам бы хотелось вот так сидеть и готовиться услышать вопрос «сколько в этой комнате поместится шариков» или «а ну-ка напишите за три минуты быструю сортировку»?
Ну вот он не написал, ошибся. А вы про себя сидите и думаете: «мда, обмельчала молодежь… Опять я очередного уделал. Какой я крутой!».
Это все, конечно, мое мнение. Возможно, в каких-то компаниях обязателен более строгий отбор, чтоб только «лучшие из лучших, которые помнят все алгоритмы, которые 100% соответствуют нашей вакансии и уже через три дня сделают все хорошо». Ок, возможно.
«Мне бы хотелось представлять с кем я собираюсь работать, поэтому пока я пишу ответ на вашу задачку про потоки, пожалуйста, напишите решение для вот этой задачки». И там тоже может быть все что угодно.
Я ненавижу писать код когда у меня из-за плеча кто-то смотрит. И пусть даже выходит из комнаты, но в таком стрессе человек нормально не реагирует. Если вам нужны программисты, которые будут работать в стрессовых условиях — ну что ж, ваше право. Но я предпочитаю работать спокойно — вот в таких условиях и надо давать задачи. в идеале — дайте задачу на дом, пусть пришлет решение по почте. Пусть поищет на stackoverflow, у друзей, где угодно. Вам же важен результат, а не как он потеет? Сумел найти решение интересующей вас проблемы из вашей области за день-два? Что вам еще надо?
Я на собеседованиях никогда не даю задач на «напишите программу вот на этой бумажке». Пока человек рассказывает о своем опыте — уже можно составить впечатление о задачах, которые он решал. Задайте парочку вопросов по его теме — будет понятно насколько глубоко он «в теме».
Хотите поумничать — спросите парочку общих вопросов из теории типа «что такое нормализация», «когда вы применяете наследование, а когда нет», и тп. Спросите что первым делом он настроит в MySQL когда поставит сервер. Или PostgreSQL.
И все без бумажек, простыми вопросами, ожидая простые ответы.
И он не должен ждать, что вы вдруг прицепитесь: «а у вас не запустится программа! Что тут не так?? А точка с запятой не стоит в конце!!!».
Как человек думает — видно и так. Как он отвечает на вопросы — присмотритесь — так он и будет работать в вашей команде.
Я выбирал людей «под себя» и под команду — сработается ли, будет ли обсуждать проблемы или замкнется и будет молча что-то делать? Будет ли принимать критику и готов ли будет, например, принимать мои замечания? Я сам достаточно авторитарен и приходилось отказываться от людей с опытом, но, по которым было видно, что с ними у меня могут быть конфликты (даже из-за меня).
Статья, действительно, опоздала года на три. Плодить ненужный контент для интернета я не хочу — его и так много.
Лучше уж я выберу время и напишу о чем-нибудь более полезном.
<картинка с роботом в коже и с плеткой>
https://ru.wikipedia.org/wiki/Технократия
http://ic.pics.livejournal.com/ibigdan/8161099/4947638/4947638_original.jpg
http://assets.amuniversal.com/b08cd9c058ac0133117d005056a9545d
На злобу дня комикс про Дилберта :)
Не могу пройти мимо «транзакцыонных», а остальные ошибки — бог с ними уж…
Ну и вот такие обороты, пожалуйста, не допускайте?
А вообще, спасибо за статью, тема довольно интересная. Отдельное спасибо как читателя за то, что не вставляете в каждый абзац ссылку на сайт своей компании.
(wikipedia)
(wikipedia)
Для меня это именно роботы.
Для такого большого функционала оно очень грамотно написано — без абстракций было бы много копипасты.
В celery/kombu настраивается все что угодно — вы можете переписать/перегрузить почти любую часть с нужным вам функционалом. Посмотрите только на список брокеров — входной интерфейс один, но работает с совершенно разными движками.
Это уже третья версия же, обычно к такой цифре автор как раз два раза понимает как убрать накопившийся говнокод и сделать «чисто».
А можете найти ссылку на номер бага, о котором вы говорите? Просто интересно посмотреть на комментарии… Автор Ask Solem, вроде, довольно общительный и адекватный, на критику реагирует нормально…
Как решение — мы ставим отдельный сервер (несколько серверов), на которых крутятся celery-воркеры. при загрузке картинки она пишется на временный storage и в очередь celery кладется задача с (user_id, image_name). Юзеру в браузер возвращается «200 OK» и он знает что картинка скоро появится.
Первый освободившийся воркер подхватывает эту задачу и обрабатывает картинку, кладет ее в базу, а потом создает новую задачу в другой очереди на отправку уведомлений (которая может тоже работать довольно долго).
RabbitMQ предназначен именно для работы с очередью сообщений, у него внутренний механизм это обеспечивает. Mongo — нет, это просто хранилище. Ей сказали «запиши 1 в колонку» — она и записала. И ее не волнуют ваши очереди-шмочереди. И как поддерживаемый брокер она имеет статус Experimental в celery.
Поэтому мне кажется, что вы зря жалуетесь. Именно из вашего описания RabbitMQ — это то, что вам бы подошло. Он довольно дружелюбен и не так сложен в установке, ИМХО.
Случиться может всякое. Как, например, с Google Code или с SourceForge.