пятница, 26 мая 2017 г.

[flame] Егор Бугаенко в DevZen подкасте (послешоу)

Дослушал таки послешоу подкаста DevZen, в котором участвовал Егор Бугаенко. Впечатления сильно двойственные.

Первые минут 40-50 тов.Бугаенко говорил весьма толково. Если убрать излишнюю категоричность и метафоричность, то получается вменяемый рассказ от вменяемого человека о том, в каких условиях ему приходится работать и как он с этим справляется.

В принципе, здесь я услышал то, что и рассчитывал услышать. Стало лучше понятно, что за компания у Бугаенко. Появилось впечатление, что это даже не классический аутсорсинг. Это, скорее, какой-то маленький маркетплейс для фрилансеров. Только особенность этого маркетплейса в том, что он находится под жестким модерированием создателя, т.е. самого Егора Бугаенко. Он приносит на маркетплейс заказы (окучивая потенциальных заказчиков), он же запускает или выгоняет с этого маркеплейса фрилансеров. Но суть, как мне показалось, именно в том, что под Бугаенко есть некая маленькая биржа труда, на которую с одной стороны вываливаются задачи, а с другой пасутся прикормленные и отдрессированные исполнители.

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


А вот то, что началось где-то с 50-й минуты или позже, когда речь пошла о тенденциях, о менеджменте, о будущих продуктах-платформах, как будто совсем другой человек начал говорить. Как будто вместо здравомыслящего практика микрофон взял совершенно упоротый маркетолог. Тут начались такие же подтасовки и передергивания, как и в рассказах Бугаенко про ООП.

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

  • "Не будут нанимать фрилансера с соседней улицы". Речь шла о том, что ситуация меняется и наступает время, когда нанимать будут не по знакомству или по соседству, а исходя из рыночных реалий. Мол, если такой же спец есть в Китае за меньшие деньги, то брать соседа в Сан-Франциско не будут. Отчасти это так, но все не так просто. Даже не будем рассматривать основную причину, т.е. неравенство доходов в разных концах мира. Ситуация станет сильно другой, когда за одну и ту же работу в США и в Малайзии начнут платить сравнимые деньги. Но есть еще такая вещь, как репутация. Нанять фрилансера в Интернете вовсе не значит гарантировать себе результат. По факту может быть такое, что дешевле было бы нанять соседа задорого, но быть уверенным в том, что работа будет сделано качественно и в срок. В принципе, за примерами далеко не нужно ходить. На рынке стоматологических услуг уже не первый десяток лет услуги предлагают и одиночки, и мелкие кабинеты, и небольшие поликлиники и большие клиники. Только вот мы же не бежим к самому дешевому врачу. Или, скажем, если вам приходилось сталкиваться с ремонтом и вы хотели найти хорошего плиточника, вы же не выбирали самое дешевое предложение в газете частных объявлений. Да и сам Бугаенко признался, что клиенты к нему приходят из-за его репутации, хотя услуги его компании, по его же словам, обходятся недешево. Так что этот тезис ну очень спорен. Хотя с тем, что рынок становится глобальным, и что конкурировать нужно будет с поставщиками таких же услуг из разных концов света, спорить не приходится, это уже свершившийся факт;
  • "Над ними стоит менеджмент, который ничего не делает". Речь про то, что работу работают узкие специалисты (вроде программистов или продавцов), а менеджмент просто паразитирует на их работе. Ну тут можно только посочувствовать человеку, который сталкивался только с таким менеджментом. Дебилы, лентяи, карьеристы и просто случайные люди встречаются везде. И среди программистов, и среди менеджеров. Конечно, когда менеджером становиться дебил-карьерист, то последствия могут быть тяжелыми. Но, тем не менее, ни один сложный и большой проект не способен завершиться успешно без менеджмента. Как бы вы лично к менеджменту не относились, это так. Ну и когда вы сами станете менеджерами и начнете нести ответственность за результат, тогда лучше поймете, делает ли менеджер что-нибудь или нет;
  • "Любой менеджмент должен быть заменен тулзами". Речь про то, что различного рода программы и программые системы, завязанные на правильные методологии, способны устранить промежуточное звено в виде менеджмента. Что не так. Если отбросить категорию "менеджеров", которые занимаются только расстановкой точек в MS Project-е и сбором отчетов о ежедневной загруженности, или же являются всего лишь точкой коммуникаций между руководством и исполнителями, то менеджмент -- он же про работу с людьми. Создание условий для людей, учет их мнений и пожеланий, обучение, решение их проблем, предотвращение конфликтов, устранение последствий конфликтов и т.д. Кто-то всерьез хочет переложить работу с людьми на автоматические тулзы? Ну вперед, чё :)

А вообще, есть замечательная книга Игоря Ашманова "Жизнь внутри пузыря". Там есть целая глава про магов. Так вот, когда я слушаю рассказы Бугаенко про ООП или про то, куда должна двигаться методология разработки программных проектов, я вспоминаю этих самых магов из книжки Ашманова. Чего и вам желаю ;)

четверг, 25 мая 2017 г.

[prog] Интересный момент при проектировании round-robin mbox-а.

Работаю над такой штукой для SObjectizer-а как round-robin mbox. Т.е. почтовый ящик, на который могут подписаться N агентов, но доставка сообщений к ним будет осуществляться по очереди, т.е. сперва первому агенту, затем второму, затем третьему и т.д. Эта штука должна быть удобной, например, при реализации балансировки нагрузки, когда требующие обработки сообщения отсылаются в один и тот же mbox, а распределяться они будут при этом на N агентов-воркеров, прозрачным для отправителя образом.

Подобные вещи и раньше можно было делать, но вручную. А теперь есть возможность предоставить round-robin mbox прямо "из коробки".

Однако, в процессе продумывания реализации round-robin mbox-а обнаружилась неожиданная засада. Дело в том, что в mbox-ах есть такая штука, как delivery filters, т.е. фильтры, которые определяют, имеет ли смысл доставлять конкретное сообщение до конкретного получателя.

Например, представим себе, что у нас есть mbox, в который некий агент время от времени отсылает текущие показатели температуры воздуха в комнате. И у нас есть два агента, которые заинтересованы в получении этих сообщений. Один из этих агентов управляет обогревом комнаты и он хочет получать все сообщения (ему нужно понять когда температура снизилась слишком сильно чтобы включить обогрев и нужно понять, когда температура поднялась достаточно высоко, чтобы выключить обогрев). А второй заинтересован только в сообщениях со слишком высокой температурой, дабы инициировать пожарную тревогу. Вот второй агент установит фильтр доставки, в котором будет проверяться значение в сообщении. Если это значение недостаточно высокое, то второму агенту этот экземпляр сообщения доставляться не будет.

Чем же мешают фильтры доставки в round-robin mbox-е?

Как в принципе должен работать round-robin mbox? У него должен быть список подписчиков на каждый тип сообщения. В этом списке должен быть явно отмечен текущий элемент -- тот подписчик, которому должно быть доставлено следующее сообщение. Когда сообщение приходит, оно отсылается этому подписчику, после чего текущим элементом становится следующий подписчик (ну или первый, если мы дошли до конца). Все просто.

Но это мы пока не рассматривали фильтры доставки. В случае с фильтрами доставки мы должны для текущего элемента спросить у его фильтра "А можно ли доставлять сообщение этому подписчику?" Если можно, то все хорошо, работает привычная схема. А вот если фильтр говорит "Нет"? Что делать тогда?

Вырисовываются следующие варианты:

  1. Просто выбросить этот экземпляр сообщения. Т.е. текущему агенту в списке сообщение не доставляется (что естественно, т.к. фильтр запрещает доставку) и не делается попытка доставить сообщение следующему агенту в списке. Текущим становится следующий агент в списке (или первый, если достигли конца списка).
  2. Попытаться выбрать другого получателя. Т.е. сразу перейти к следующему агенту и спросить его фильтр доставки. Потом к следующему и т.д. до тех пор, пока получатель не будет найден. Может быть вообще ничего не найдем, но тогда данный экземпляр сообщения просто выбрасывается.
  3. Тупой запрет на использование фильтров доставки в случае round-robin mbox-а. Тогда проблемы нет в принципе.
  4. Update. Объединить все фильтры доставки в один комбо-фильтр. Когда появляется сообщение, оно сперва пропускается через этот комбо-фильтр (т.е. через все фильтры). И только если комбо-фильтр пропускает сообщение, только тогда оно доставляется текущему получателю.

Лично я пока склоняюсь к первому варианту. Логика такая: round-robin предполагает, что пытаемся доставлять по очереди. Сейчас очередь у агента X. Если X отказывается принимать сообщение, то он все равно свою очередь использовал и для следующего сообщения очередь перейдет к другому получателю.

Вот только не уверен, что это не будет сбивать пользователей с толку. Кто что думает?

После небольшого обсуждения и дополнительного обдумывания появился вариант №4, который сейчас и кажется наиболее уместным: сообщение должно удовлетворять всех получателей и только тогда можно выбрать очередного получателя для сообщения.

Кстати, попутно еще один вопрос: а кроме round-robin еще какие-нибудь политики доставки для N агентов кому-нибудь нужны/интересны?

понедельник, 22 мая 2017 г.

[prog.flame] Егор Бугаенко в DevZen подкасте

Есть в Рунете такой подкаст: DevZen. Я его практически никогда не слушаю. За исключением некоторых отдельных случаев: один раз там обсуждали именно что мой пост в моем блоге, один раз там говорили про модный и молодежный взгляд на ООП вообще и ООП в C++ в частности, один раз обсуждали акторов в C++, один раз послушал фрагмент DevZen с участием Григория Демченко и пара выпусков про Лондон и стартапы. Хотя ссылки, которые там накидывают в комментариях стараюсь просматривать, бо временами встречается интересное.

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

Намедни в DevZen заглянул некто Егор Бугаенко. Я хз кто это такой и чем он знаменит. Но что-то последние пару лет это имя слишком часто всплывает в этих наших Интернетах, дай, думаю, послушаю, приобщусь. Выкроил часок, послушал. Получил некоторое впечатление, которое имеет две или даже три составляющие: