Comments 68
не все митинги они accept, так что на штрихованных митингах они тоже сидят -просто не послали формальный accept
типичный менеджер всегда посылает accept, но на митинг не приходит, заставляя собравшихся бесцельно ждать полчаса и разбредаться по своим местам. А если приходит — то обсуждает совсем не заявленную повестку.
С митингами по телефону легче, нацепил наушники от телефона и занимаешься своими делами
— Но как же ты разговариваешь, если у тебя мозгов нет?
— Это ничего, я еще и на митингах по телефону участвую!
IMHO, либо свои дела, либо митинг не должны занимать мозг, чтобы их можно было совмещать
— Это ничего, я еще и на митингах по телефону участвую!
IMHO, либо свои дела, либо митинг не должны занимать мозг, чтобы их можно было совмещать
Бывает такое.
Когда зовут на митинг — неизвестно, понадобишься ты или нет. Выясняется, что ты не нужен, уже в процессе, но тебя позвал уважаемый человек, и просто так уже не уйти.
Поэтому занимаешься своими делами, слушая в одно ухо слова-триггеры.
К сожалению, с этим ничего не поделать, но оно и не напрягает.
Когда зовут на митинг — неизвестно, понадобишься ты или нет. Выясняется, что ты не нужен, уже в процессе, но тебя позвал уважаемый человек, и просто так уже не уйти.
Поэтому занимаешься своими делами, слушая в одно ухо слова-триггеры.
К сожалению, с этим ничего не поделать, но оно и не напрягает.
И тем не менее, если так часто делать, то устаешь даже больше, чем если присутствуешь. Нужно же быть готовым что то более менее впопад ляпнуть
Обычный менеджер демонстрирует всем свой календарь, забитый митингами, а также значок «На митинге» в скайпе, чтобы показать всем свою очень большую занятость. Особенно это присуще новоиспеченным менеджерам. Это как копатель траншей показывает всем свои трудовые мозоли.
Но самом деле на митингах менеджеры в основном очень расслаблены, смотрят слайды презентаций и перешучиваются. Это время отдыха от главной работы.
Но самом деле на митингах менеджеры в основном очень расслаблены, смотрят слайды презентаций и перешучиваются. Это время отдыха от главной работы.
Также ЧСВ менеджера помогает наличие своего weekly meeting. Чем больше народу, тем лучше. Если в данную неделю не о чем говорить, то это не повод его отменять
Петя шёл на митинг, а Митя шёл на петтинг.
А что же тогда за главная работа?
Как раз по ощущениям митинги она и есть, распихать потом указания подчинённым занимает гораздо меньше времени, чем по 10 раз пережёвывание одного и того же на митингах,
иногда, слушая как начальник участвует в телефонной конференции, складывается ощущение, что там по большей части имбецилы.
А что же тогда за главная работа?
Как раз по ощущениям митинги она и есть, распихать потом указания подчинённым занимает гораздо меньше времени, чем по 10 раз пережёвывание одного и того же на митингах,
иногда, слушая как начальник участвует в телефонной конференции, складывается ощущение, что там по большей части имбецилы.
Смотрю целый пласт манагеров и не вспоминают. Маленькие лошадки везущие Повозку аутсорса. Где нет места митингам, а все лишь круглосуточная оперативка и метрики, метрики и оперативка. И нелюбовь снизу и презрение сверху. Вот чуть всплакнул и стало легче :) Не ходите програмеры и сисадмины в такие манагеры, а если и соберетесь — то обязательно думайте об этом этапе как о промежточном, только вот куда? Может быть и в сторону митингов по грандиозным обсуждениям грандиозных дел. Ну и к большим деньгам конечно.
UFO just landed and posted this here
Но самом деле на митингах менеджеры в основном очень расслаблены, смотрят слайды презентаций и перешучиваются. Это время отдыха от главной работы.
Чего не скажешь про копателя траншей, у него-то мозоли настоящие
Примерно раз в неделю на Хабре статьи о вреде митингов, в комментариях всеобщий консенсус "митинги не нужны, менеджеры — лошьё", а я вот не пойму никак — а как вы вообще работаете, если вы ничего не обсуждаете? На вас откуда-то сверху сваливаются готовые ТЗ, архитектуры, планы работ? Никогда не бывает ретроспектив, мозговых штурмов и серьезных проблем, требующих обсуждения? Вам вот вообще не о чем поговорить, строго лопату в руки — и вперёд?
серьезных проблем, требующих обсуждения
1% от митингов, то есть я за свою карьеру могу вспомнить и полезные митинги
То есть в вашей жизни было как минимум 100 совещаний, и лишь одно из них было полезным?
Не могли бы вы тогда вкратце рассказать о том, как у вас организованы постановки задач и ретроспективы?
Не могли бы вы тогда вкратце рассказать о том, как у вас организованы постановки задач и ретроспективы?
Могу привести примеры, но я не разработчик, я в IT отделе, так что всяких скрамов, ретроспектив и прочего у нас нет
Ну, под ретроспективой я не только термин из скрам-фреймворка понимаю.
Приведите пример.
Приведите пример.
Типичный митинг. Тема: внедрение spunk для мониторинга. На телефоне 30 чел.
— группа Sybase, какой прогресс?
— эээ. Ну. У нас там был production emergency, мы этим не занимались
— группа Oracle?
— а, сегодня такой то взял day off, а я не знаю
— ладно, перенесем. Sql server? (Тут я просыпаюсь)
— как я и говорил в течение месяца, я жду когда ваша тим поставит heavy forwarder для нас. Как с этим дела?
— эээ. Но на следующей неделе будет
Я: хорошо
Со спланком так прошло 6 мес, потом проект закрыли)
— группа Sybase, какой прогресс?
— эээ. Ну. У нас там был production emergency, мы этим не занимались
— группа Oracle?
— а, сегодня такой то взял day off, а я не знаю
— ладно, перенесем. Sql server? (Тут я просыпаюсь)
— как я и говорил в течение месяца, я жду когда ваша тим поставит heavy forwarder для нас. Как с этим дела?
— эээ. Но на следующей неделе будет
Я: хорошо
Со спланком так прошло 6 мес, потом проект закрыли)
Когда «Splunk» написан как «spunk», то возникают нехорошие подозрения относительно корпоративной культуры вашего менеджмента в отношении мониторинга инфраструктуры )))
По сути вопроса — прекрасный, отличный, очень нужный и полезный митинг! Конечно форма его проведения не слишком неэффективная, но сам по себе митинг превосходен. Он наглядно показывает проблемы в планировании и коммуникации, для чего в том числе и нужны митинги. Вы видите проблему со своей позиции — меня отвлекли, я дал односложные ответы, ничего не произошло, митинги надо запретить. А теперь посмотрите на это со стороны проекта в целом — ух ты, наконец-то мы поняли, что ничего никуда не двигается. Когда это все произошло во второй раз — ух ты, мы ничему не учимся, это тоже важно знать. После полугода подобных митингов можно провести несложный анализ и понять — черт, да мы вообще в принципе неспособны поднимать такие проекты с организационной точки зрения (а возможно и с технической — суть дела до конца не доведена и хз, что бы там было бы). Ой, а мы вообще понимали, зачем это делаем? Ведь если это было нужно, а мы не сделали, то это же плохо, да? Или оно и не нужно было?
Так вот и выявляются проблемы с целеполаганием и планированием. Регулярно и формализованно сообщая об очередном/очередной лаге/лаже мы рано или поздно приходим к пониманию, что в консерватории что-то не так. Это лучше, чем набрать проектов и втихаря что-то лепить, что потом может быть совершенно не востребовано. Как только возникает проект более чем для одной персоны и сколько-нибудь сложный — без интеркома не обойтись.
Касательно формы — ну, да, типичный митинг в процессной конторе, из серии «проверка связи» aka «эй, вы там случаем ничего эдакого не сделали?», я вообще не очень понимаю, где во всем этом руководитель проекта и почему это все так происходит. У ваших on-board должно быть очень много вопросов к менеджменту.
По сути вопроса — прекрасный, отличный, очень нужный и полезный митинг! Конечно форма его проведения не слишком неэффективная, но сам по себе митинг превосходен. Он наглядно показывает проблемы в планировании и коммуникации, для чего в том числе и нужны митинги. Вы видите проблему со своей позиции — меня отвлекли, я дал односложные ответы, ничего не произошло, митинги надо запретить. А теперь посмотрите на это со стороны проекта в целом — ух ты, наконец-то мы поняли, что ничего никуда не двигается. Когда это все произошло во второй раз — ух ты, мы ничему не учимся, это тоже важно знать. После полугода подобных митингов можно провести несложный анализ и понять — черт, да мы вообще в принципе неспособны поднимать такие проекты с организационной точки зрения (а возможно и с технической — суть дела до конца не доведена и хз, что бы там было бы). Ой, а мы вообще понимали, зачем это делаем? Ведь если это было нужно, а мы не сделали, то это же плохо, да? Или оно и не нужно было?
Так вот и выявляются проблемы с целеполаганием и планированием. Регулярно и формализованно сообщая об очередном/очередной лаге/лаже мы рано или поздно приходим к пониманию, что в консерватории что-то не так. Это лучше, чем набрать проектов и втихаря что-то лепить, что потом может быть совершенно не востребовано. Как только возникает проект более чем для одной персоны и сколько-нибудь сложный — без интеркома не обойтись.
Касательно формы — ну, да, типичный митинг в процессной конторе, из серии «проверка связи» aka «эй, вы там случаем ничего эдакого не сделали?», я вообще не очень понимаю, где во всем этом руководитель проекта и почему это все так происходит. У ваших on-board должно быть очень много вопросов к менеджменту.
С телефона еще и не такие слова выходят)))
Вот через пол года как раз уровень повыше и решил, что руководитель этого проекта ничего не способен сделать. И вы правы, наверное потому, что этот менеджер не делал никаких выводов. Так что сделали выводы относительно него.
Однако все эти митинги ломают продуктивное взаимодействие, люди начинают не отвечать на почту, потому что на митинге мы можем обсудить.в итоге layency на любой вопрос/ответ неделя
И вот очередная победа в третьем абзаце — если люди не отвечают на почту и точкой сборки информации служит только митинг, то вопросов к организации становится еще больше!
А вопросы эти не только к руководителю проекта, но и к руководителю руководителя. Берем те же самые неответы на почту — это не только забота руководителя проекта, но и наличие элементарной культуры и модерации. Это также проблема с инструментами — может быть нужен тим-чат? Практически ни в какой компании нельзя просто кинуть человека в котел и сказать «тащи проект, мы верим в тебя». Сделавший так топ-менеджер в этом случае пилит стул под собой тоже.
Полагаю, что у вашей компании есть болезни роста. Это нормально, у нас они тоже есть, хотя ваш текущий этап мы уже прошли.
А вопросы эти не только к руководителю проекта, но и к руководителю руководителя. Берем те же самые неответы на почту — это не только забота руководителя проекта, но и наличие элементарной культуры и модерации. Это также проблема с инструментами — может быть нужен тим-чат? Практически ни в какой компании нельзя просто кинуть человека в котел и сказать «тащи проект, мы верим в тебя». Сделавший так топ-менеджер в этом случае пилит стул под собой тоже.
Полагаю, что у вашей компании есть болезни роста. Это нормально, у нас они тоже есть, хотя ваш текущий этап мы уже прошли.
Когда то, довелось несколько лет работать в компании с плоской моделью управления.
Начальников почти не было, их было один к многим сотням просто рядовых сотрудников.
И вопросы развития и эксплуатации решались мгновенно.
Естественно обсуждали, но это было очень быстро и люди понимали друг друга с полуслова.
Никто не собирал конференции на десятки человек, где по часу мусолили одно и то же.
Сказано, сделано, профит, компанию ставят как пример для подобных, где тоже самое делают в 10 раз большее количество персонала.
Потом компанию реорганизовали, начальников стало на порядки больше и то, что раньше делалось за 1 день, стало делаться за полгода.
Начальников почти не было, их было один к многим сотням просто рядовых сотрудников.
И вопросы развития и эксплуатации решались мгновенно.
Естественно обсуждали, но это было очень быстро и люди понимали друг друга с полуслова.
Никто не собирал конференции на десятки человек, где по часу мусолили одно и то же.
Сказано, сделано, профит, компанию ставят как пример для подобных, где тоже самое делают в 10 раз большее количество персонала.
Потом компанию реорганизовали, начальников стало на порядки больше и то, что раньше делалось за 1 день, стало делаться за полгода.
Воистину так. Регулярно получаю всякие распоряжения. Текста по сути дела — на десять строчек. И три листа согласований. И каждый согласующий должен расписаться.
Так хочется по нормальному это охарактеризовать, но я только что из бана за подобные оценки вылез. Поостерегусь.
Так хочется по нормальному это охарактеризовать, но я только что из бана за подобные оценки вылез. Поостерегусь.
При плоской модели одно плохо, некуда расти карьерно. Так чтобы скачкообразно и должность выше и зарплата намного выше.
Но это для тех кто озабочен карьерой.
Для остальных же всё пришло к тому, что работа просто вязнет как копальхен в болоте в бесконечных согласованиях, регламентах, прикрываниях собственной задницы.
Но это для тех кто озабочен карьерой.
Для остальных же всё пришло к тому, что работа просто вязнет как копальхен в болоте в бесконечных согласованиях, регламентах, прикрываниях собственной задницы.
Для тех кто любит эти игры, придумывают разные цвета штанов: (junior, middle, senior) x (" ", team, project, product) x (lead, manager) уже дает 24 комбинации!
В плоской модели, чтобы тебя послушали нужно реально хорошие аргументы приводить, не получится давить должностью.
Здесь не следует путать. «Митинги — фуфуфу» это одно, а «согласования — фуфуфу» — уже немного другое. Бесконечные согласования не имеют ВООБЩЕ никакого отношения к структуре компании, количеству начальников и количеству совещаний, а только лишь к области деятельности. Согласование в большинстве случаев выполняется в рамках некоей почтовой рассылки и делается не просто так, обычно оно соответствует принятому в вашей отрасли стандарту ведения дел — и не дай вам Бог при аудиторе высказаться про «ненужные согласования». Буквально позавчера аудитор сделал нам вот какое интересное замечание — «отсутствие на валидационном документе визы вашего руководителя является в первую очередь вашей проблемой, вы берете на себя неприемлемую ответственность, когда не возлагаете на него необходимость визировать свою работу». Интересно, да? И это был европейский аудит, если что (разумеется в ISO13485 хватает дури, но это единственный путь на рынок).
Если же ваша область деятельности не связана с какой-либо реальной ответственностью (я сейчас без пафоса, ответственность наступает даже при разработке и производстве пластмассовой машинки за 150 рублей, которую я сыну купил неделю назад), либо вы пока не знаете о том, что она у вас тоже наступает, то конечно можно обойтись без согласований. И нужно без них в этом случае обойтись, потому что они реально тормозят дело (если только стоимость рисков не слишком высока) и формируют субкультуры «людей-акцепторов» и «людей-низачтонеотвечателей».
Если же ваша область деятельности не связана с какой-либо реальной ответственностью (я сейчас без пафоса, ответственность наступает даже при разработке и производстве пластмассовой машинки за 150 рублей, которую я сыну купил неделю назад), либо вы пока не знаете о том, что она у вас тоже наступает, то конечно можно обойтись без согласований. И нужно без них в этом случае обойтись, потому что они реально тормозят дело (если только стоимость рисков не слишком высока) и формируют субкультуры «людей-акцепторов» и «людей-низачтонеотвечателей».
Это очень интересно, потому что у нас например тоже почти плоская модель.
Задам уточняющий вопрос — что вы понимали под понятием «начальник» в рамках вашей компании? Спрашиваю потому, что даже в рамках плоской модели ситуация «один начальник на сто рядовых сотрудников» выглядит дикой. У вас был геймдев или сервис/интеграция КИПиА, что-то такое?
> Никто не собирал конференции на десятки человек, где по часу мусолили одно и то же
Это, знаете, известное натягивание совы на глобус. Я про такие страшные многочасовые «селекторные совещания» тоже слышал и даже в кино видел, но не в жизни. Даже в НИИ у нас такого не было. Даже в университете заседание Ученого Совета таким не было. Что со мной не так? Готов рискнуть репутацией и предположить, что в моем случае люди просто-напросто по делу на эти совещания приходили — чтобы синхронизировать состояние работ и понимания целей (не задач, именно целей), чтобы честно и сжато рассказать об успехах и проблемах (ага ага, этого вот как раз многие митинг-хейтеры очень боятся), чтобы получить новые вводные по внешним событиям.
Задам уточняющий вопрос — что вы понимали под понятием «начальник» в рамках вашей компании? Спрашиваю потому, что даже в рамках плоской модели ситуация «один начальник на сто рядовых сотрудников» выглядит дикой. У вас был геймдев или сервис/интеграция КИПиА, что-то такое?
> Никто не собирал конференции на десятки человек, где по часу мусолили одно и то же
Это, знаете, известное натягивание совы на глобус. Я про такие страшные многочасовые «селекторные совещания» тоже слышал и даже в кино видел, но не в жизни. Даже в НИИ у нас такого не было. Даже в университете заседание Ученого Совета таким не было. Что со мной не так? Готов рискнуть репутацией и предположить, что в моем случае люди просто-напросто по делу на эти совещания приходили — чтобы синхронизировать состояние работ и понимания целей (не задач, именно целей), чтобы честно и сжато рассказать об успехах и проблемах (ага ага, этого вот как раз многие митинг-хейтеры очень боятся), чтобы получить новые вводные по внешним событиям.
У нас офисы по всему миру, поэтому 99% митингов телефонные. Мои коллеги для меня это строчки в аутлуке, не более — я не знаю, как они выглядят. Раньше, до поглощения, я, часто ездил в Америку, а теперь они экономят
Ну так а кто такой «начальник» в вашей модели?
Начальники все время меняются. в прошлом году сменилось 5 человек надо мной. Я кстати, отношусь к двум отделам, так получилось, и у меня два начальника)
Так вот кто это — начальник? Руководители проектов, тимлиды — они входят в эту категорию?
Впрочем я уже кажется понимаю, что у вас скорее процессная модель работы и вашей компании плоская модель попросту не очень подходит. В этой ситуации имеет смысл голосовать ногами, если это не нравится. Главное не убежать в разработку гражданской авионики, там будет еще хуже )))
Впрочем я уже кажется понимаю, что у вас скорее процессная модель работы и вашей компании плоская модель попросту не очень подходит. В этой ситуации имеет смысл голосовать ногами, если это не нравится. Главное не убежать в разработку гражданской авионики, там будет еще хуже )))
Руководители отдела SQL server
с другой есть бизнес, который поглотили, там it отдел был full stack, я к нему тоже отношусь
Да, у вас речь о сугубой вертикали. В процессных компаниях вертикаль обязана быть развитой.
Вообще я сейчас только сообразил, что зря вас насчет начальников допытываю. У меня вопрос был к wlr398, у которого какой-то загадочный один начальник на сто человек, меня вот это вот заинтересовало.
Вообще я сейчас только сообразил, что зря вас насчет начальников допытываю. У меня вопрос был к wlr398, у которого какой-то загадочный один начальник на сто человек, меня вот это вот заинтересовало.
Кстати, плоской модели, у нас 8 уровней. Раньше было 9
Даже в НИИ у нас такого не было
It depends… у нас дружественная лаборатория регулярно устраивает семинары, где после выступления докладчика (на 20-40 минут) и 10 минут нормального обсуждения/дискуссии начинается тягомотина на час с частностями которые ни разу не интересны тем кто пришел. На входе в этот этап надо линять.
Ну так это же вопрос модерации таких семинаров. В какой-то момент модератор (у них же он есть на каждом семинаре, да?) просто говорит «так, вот теперь прошу разбиться на группы по интересам». Если этого не сделать, то эффективность упадет у всех участников. В крайнем случае возможен быстрый референдум — нужно ли что-то еще обсуждать таким составом, или оставим мелкие вопросы секретариату семинара (что-то в таком духе).
Вот если бы оно все решалось на митингах, было бы здорово, но.
Вот примерный план практически всех, за реееедким исключением, митингов в большой американской компании, где я работаю (тайминги от начала митинга):
(0-10) Смолтолк, ждем тех, кто опаздал на митинг потому, что предыдущий затянулся. Митинг, где меньше 5 участников — большая редкость, поэтому обязательно кто-то задержится.
(10-15) Приветствуем опаздавших, решаем технические проблемы, включаем шаринг экрана и т.п.
(15-25) Мы собрались тут затем, чтобы не только смотреть в завтрашний день…
(25-40) Повторение того, что уже обсуждалось, подробное разжевывание темы, бесполезная общая инфа, потому что на митинге присутствует кто-то, кто пропустил хотя бы один из предыдущих по теме.
(40-50) Попытка начать обсуждение и втыкание в первый блокер, за который отвечает кто-то из комнады, представители которой не присутствуют.
(50-конец) Обсуждение того, есть ли тикет для той самой команды, кто за это отвечает и неизменное «надо включить в обсуждение господина N, который в нужной команде кто-то там приблизительно нужны, обычно — менеджер.
И так из раза в раз. А если результат митинга порождает какие то action-item за пределами тестовой среды для разработчиков, то производные митинги плодятся просто в геометрической прогрессии.
Вот примерный план практически всех, за реееедким исключением, митингов в большой американской компании, где я работаю (тайминги от начала митинга):
(0-10) Смолтолк, ждем тех, кто опаздал на митинг потому, что предыдущий затянулся. Митинг, где меньше 5 участников — большая редкость, поэтому обязательно кто-то задержится.
(10-15) Приветствуем опаздавших, решаем технические проблемы, включаем шаринг экрана и т.п.
(15-25) Мы собрались тут затем, чтобы не только смотреть в завтрашний день…
(25-40) Повторение того, что уже обсуждалось, подробное разжевывание темы, бесполезная общая инфа, потому что на митинге присутствует кто-то, кто пропустил хотя бы один из предыдущих по теме.
(40-50) Попытка начать обсуждение и втыкание в первый блокер, за который отвечает кто-то из комнады, представители которой не присутствуют.
(50-конец) Обсуждение того, есть ли тикет для той самой команды, кто за это отвечает и неизменное «надо включить в обсуждение господина N, который в нужной команде кто-то там приблизительно нужны, обычно — менеджер.
И так из раза в раз. А если результат митинга порождает какие то action-item за пределами тестовой среды для разработчиков, то производные митинги плодятся просто в геометрической прогрессии.
Митинг == встреча.
Кейч?
Кейч?
обсуждение передачи данных между компонентами в виде файлов и ожидания их периодической проверкой их наличия.
Прям ох, ибо про меня!
Я хоть и не менеджер, но в плане программирования ментально застрял в 90-х.
Отсюда вопрос — а как это делается в 21-м веке на Си?
Мммм, пайп, сокет, что-то еще из той же серии?
… пайп, сокет… э… )
А можно ткнуть носом еще более явно?
У нас вначале решаются уравнения в одной программе, и данные бросаются на диск, а потом должна запуститься отдельная программа на GPU, соответственно готовность данных проверяется выставленным флагом в файле, т.е. так — по рабоче-крестьянски.
А можно ткнуть носом еще более явно?
У нас вначале решаются уравнения в одной программе, и данные бросаются на диск, а потом должна запуститься отдельная программа на GPU, соответственно готовность данных проверяется выставленным флагом в файле, т.е. так — по рабоче-крестьянски.
Как я понял, в вашем случае «компоненты» — суть отдельные программы. В рантайме соответственно — отдельные процессы. Я может быть глупый, но мне бы в первую очередь пришел в голову именно пайп (http://ru.manpages.org/pipe/2). Это конечно тоже как бы объект файловой системы, но все-таки лучше, чем регулярный файл. Из минусов — синхронизация только путем чтения/записи пайпа, вероятно следовало бы еще процессный семафор завести для полной радости. Если совсем не хочется в файловую систему, то можно перейти на очередь сообщений… Да собственно и шмем на поверхности лежит, я вообще хз зачем эта вся возня с файлами.
Точнее понятно зачем она может быть нужна — если СНАЧАЛА одна программа подготовила данные, а ПОТОМ другая их обрабатывает, но вроде бы у вас шла речь про одновременную работу.
Точнее понятно зачем она может быть нужна — если СНАЧАЛА одна программа подготовила данные, а ПОТОМ другая их обрабатывает, но вроде бы у вас шла речь про одновременную работу.
и шмем на поверхности лежит
А, спасибо!
речь про одновременную работу.
Да — две программы висят одновременно, считает то одна, то другая.
но все-таки лучше, чем регулярный файл.
А все же — чем таки плохи файлы?
Ниже написали — «Это уже 20 лет назад было антипаттерном.»
Это как раз тот случай, что я не понимаю, что чего-то не понимаю. )
Да как бы вам сказать… Я тоже не знаю, почему это антипаттерн. Но я также и не знаю, как вообще это может приходить в голову. У меня логика простая (крестьянская) — если программы работают не одновременно, то нужна долговременная память, а она на любой вычислительной платформе представлена в первую очередь файловой системой (это не обязательно так, но в общем), так что здесь все ясно. Если программы работают одновременно, то мы имеем два одновременно запущенных процесса, для взаимодействия между которыми заботливые люди придумали средства IPC — пайпы, очереди, шмем, сокеты (здесь уже наверное я застрял лет на пятнадцать, потому что с той поры не особо интересуюсь темой, может нынче какие другие новинки, которые вероятно и имел в виду автор).
1) Синхронизация работы с файлами из разных процессов
2) Отсутствие каких либо стандартов по работе с файлами
3) Задержки
4) Очистка файлов после работы
5) Возможность случайно вмешаться работу между приложениями
6) Программы должны быть ТОЛЬКО на одной машине. Не масштабируемое решение.
7) Программы могут общаться только 1 на 1
8) Скорость
… продолжите список
2) Отсутствие каких либо стандартов по работе с файлами
3) Задержки
4) Очистка файлов после работы
5) Возможность случайно вмешаться работу между приложениями
6) Программы должны быть ТОЛЬКО на одной машине. Не масштабируемое решение.
7) Программы могут общаться только 1 на 1
8) Скорость
… продолжите список
В общем надо что-то почитать с примерами. ) 20-ти летнее отставание не преодолеть так быстро )))
Вот есть proga1.exe, есть proga2.exe.
Программа 1 генерит массив данных, как только он будет готов до него надо добраться программе 2.
Вот есть proga1.exe, есть proga2.exe.
Программа 1 генерит массив данных, как только он будет готов до него надо добраться программе 2.
Если это пакетная обработка, утром собрали файлы, вечером посчитали, то не страшно
вы таки будете смеяться, но как минимум одна уважаемая контора (с которой я связан НДА) — до сих пор обменивает информацию между частями своей системы файлами.
Параллельно — дублирует работу в БД (это кто-то из новичков начал писать, чтобы заменить часть логики, однако уволился до того, как дописал). Но главный, рабочий и основной канал обмена — файлы и только файлы. Куча денег, уолл стрит, финансы, биржи и аудит — но…
С другой стороны — у них действительно, режим работы «пакетная обработка, утром собрали файлы, вечером посчитали».
Параллельно — дублирует работу в БД (это кто-то из новичков начал писать, чтобы заменить часть логики, однако уволился до того, как дописал). Но главный, рабочий и основной канал обмена — файлы и только файлы. Куча денег, уолл стрит, финансы, биржи и аудит — но…
С другой стороны — у них действительно, режим работы «пакетная обработка, утром собрали файлы, вечером посчитали».
В таком флоу, как правило кладут в бд, что бы воркеры ночью обработали. Если это большие бинарные данные, то имеет смысл хранить это в nosql бд, или скрыть за микросервисом ну или ходить по ftp или же… хранить в файлах -) Но опять таки — синхронизация, бессердечная тварь…
Ну, вот тут как раз может вкрасться лень и незнание. Я вот поленюсь без особой нужды тащить к себе драйвер какой-нибудь БД, а мои знания в этой области точно устарели минимум лет на десять (ODBC еще применяется, а?). Опять же нужна инфраструктура какая-то в этом случае. Пожалуй я бы здесь применил файлы… Но в задаче описанной выше, где работа одновременная, я бы предпочел либо шмем (парсинг данных и скорость работы будут на высоте), либо сокет (на случай, если захочется потом унести второй обработчик на другую машину).
Интересно узнать, а проблема-то есть? Или единственное, что не нравится, что способ обмена «древний»?
С другой стороны, кто будет спорить, если изменить архитектуру и логику, можно попробовать и другие способы обмена, но я бы задался вопросом, зачем? В чем выгода изменений для бизнес-процесса?
С другой стороны, кто будет спорить, если изменить архитектуру и логику, можно попробовать и другие способы обмена, но я бы задался вопросом, зачем? В чем выгода изменений для бизнес-процесса?
Проблемы скорее всего нет, с другой стороны не очень ясно, как вообще это все родилось. Вангую жуткое легаси из 80-х…
проблемы у них есть, но совсем из другой стороны:
— никто не хочет ее поддерживать (в смысле — заполнять вакансию). Последний из соавторов этой штуки досиживает до пенсии.
— изза достижений прогресса и увеличения сделок за день — место на рабочем диске (там где оно процессит данные за день) заканчивается (хотя если бы оно качало и процессило не по файлу, а по Н записей, то вообще бы не было нужды в этом диске). Два раза уже удваивали объем — но прогресс все равно быстрее.
— никто не хочет ее поддерживать (в смысле — заполнять вакансию). Последний из соавторов этой штуки досиживает до пенсии.
— изза достижений прогресса и увеличения сделок за день — место на рабочем диске (там где оно процессит данные за день) заканчивается (хотя если бы оно качало и процессило не по файлу, а по Н записей, то вообще бы не было нужды в этом диске). Два раза уже удваивали объем — но прогресс все равно быстрее.
Это уже 20 лет назад было антипаттерном.
Классная статья.
А настоящий менеджер всегда "доступен":
"Извините в настоящий момент я занят (на совещании, в командировке, не могу говорить). Ваш звонок очень важен. Мы вам перезвоним/ответим и т.д. "
- “Перемычка” порвалась. Теперь человек стал стопроцентным менеджером.
Sign up to leave a comment.
Слава богу, что я не менеджер