Эффективность дронов резко повысится, если предположить, что дрон доставляет посылки не индивидуально, а в постаматы, сразу кучкой. Тогда и грузоподъемность в 10 кг может быть использована полностью и сама логистика станет проще. Но тут появляется задача с размещением постаматов...
Недавно как раз задумывался над выбором продукта из приведенных в статье.
Мне бы, как потенциальному пользователю были бы интересны именно детали применимости продуктов для конкретных задач. У вас есть немного про это в "Лучше всего подходит для " - но как же там мало информации для принятия решения... Глядя на описание я так и не могу выбрать продукт, который мне нужен.
Было бы здорово хотя бы понимать, что такое "Быстрое развертывание, меньшие команды или проекты ". "Меньшие команды или проекты" - имеется ввиду, что с конфигами нужно работать в 1 лицо, потому, что там есть проблемы в совместном использовании и самих конфигов не должно быть более нескольких штук? Тогда сколько конкретно и что будет, если проект выйдет за эти ограничения - понимаете мои затруднения?
Вспомнилась старая статья по этим продуктам: https://habr.com/ru/companies/jugru/articles/416763/. Статья довольно сильно устарела, но там мне понравился сам подход к сравнению продуктов, хотя и по ней сделать осознанный выбор очень тяжело...
Хороший специалист всегда держит в голове цели проекта и не даёт обещаний, которые им не соответствуют.
Любой каприз за Ваши деньги (деньги Заказчика).
Наличие ресурсов для разработки на этапе сбора требований не важно. Когда станет понятно, что и сколько - вот тогда и будет ресурс.
Полезно напоминать себе, что каждый проект уникален: пробуйте новые подходы, меняйте инструменты и открывайте для себя новые возможности даже в знакомых областях. Бизнес-аналитику очень важно быть гибким и любознательным. Сфера развивается быстро — то, что работало ещё вчера, может навредить новому проекту сегодня.
Быть гибким и любознательным - это одно, а вот в каждом новом проекте тащить в проект какое-то новое СПО или прыгать по разным инструментам - это несерьезно - вы ведь не один в команде, да?
Вы должны не только понять, чего хочет заказчик, но и предложить альтернативные решения, обсудить плюсы и минусы.
Альтернативные решения - это и есть градация от "Хочу чтобы все" за "очень дорого" до "автоматизируем только это и это" за "дешево". Тут Заказчик выбирает для своего кошелька и наличия времени до дедлайна.
Еще несколько моментов, которые можно было бы подсветить:
Целевая длительность боя - грубо говоря за сколько ударов может умереть противник, сопоставимого с пользователем уровня - за 1-2 или за 20-30 (включая промахи).
Противодействие рутине - какие способы будут применены для предоставления пользователю нового опыта, скажем, при росте его уровня.
Балансировка архетипов (возможно - синергия архетипов) - у вас ведь не будет безликий солдат - наверняка будут и воины ближнего боя и лучники и маги и у каждого из них свои плюсы и минусы.
Была такая проблема - отрывало водостоки подвижкой снега с крыши. Решил проблему тем, что водостоки сдвинул немного вниз. Теперь снег идет над ними, правда при сильных ливнях струи воды, разогнавшись со ската, тоже идут мимо... Теоретически можно заморочиться летней/зимней позицией, но лень было...
Вот ведь, мне казалось, что влияние игрока на поле боя было во всех играх, которые я видел. Но раз это не на виду, то вот несколько:
Prime World: Defenders 2
Deathtrap
Element TD 2
серия GemCraft
На примере последней - при посредственной графике там очень простая и одновременно мощная тактическая система боя, которая вовлекает игрока в бой очень сильно при том, что самого аватара игрока на поле боя нет.
Для игрока есть возможность
бустить баши, давая им дополнительные способности (мощный выстрел, луч и др.).
переносить камни - фактически перемещать оборону по карте в то место, где она более востребована.
морозить, проклинать монстров.
уничтожать камни, вызывая сильные взрывы.
взаимодействовать с окружением на карте - уничтожать дома, бакены, дающие буст монстрам, норы монстров, усиливать волны, ускорять волны и многое другое.
строить на карте не только башни, но и стены и другие объекты. Сами другие объекты, есть как доступные для строительства, так и нет. Эти объекты в свою очередь могут бустить рядом стоящие башни или иметь другие эффекты. Некоторые объекты пассивные, другие необходимо зарядить, выполнив отпределенные условия, третьи развиваемые и в них необходимо вкладывать ресурсы.
выполнять некие задания, которые нужно выполнить на карте.
В общем, нужно посмотреть самому...
Еще один момент - у вас есть типы урона, а будут ли у вас долговременные эффекты в зависимости от типа урона (огонь - поджигает, холод - замедляет/замораживает)?
Для этого жанра просто строительства башен недостаточно.
must have является возможность влияние игрока на бой (точечные удары, буст башен, дебафы врагов и т.д.). Сами башни в этом случае служат необходимой базой, а действия игрока - тем самым, что делает игру...
Правда мне интересны не сами новинки, а вопрос "На сколько подешевеют существующие карты?" - например, обычный и игровой вариант 4070. Ибо цены на них просто неадекватные. Но это станет понятно через некоторое время...
Три полноценных совмещённых санузла при 3- х спальнях‑ это современный тренд в современном «комфортном» домостроении
Что, простите? Современный тренд - это теплый сортир в доме против сортира "до витру" в конце огорода. Никто в здравом уме не будет расходовать и так небольшую площадь на 3 туалета при том, что все это "богатство" ограничено еще и объемом септика.
создана двунаправленная логическая репликация таблиц, позволяющая синхронизировать изменения в двух таблицах на разных серверах. Добавленные в PostgreSQL 16 возможности репликации позволяют создавать конфигурации с несколькими активными серверами (режим active-active), на которых одновременно можно выполнять операции INSERT, UPDATE, DELETE;
Если там нет какого-либо списка ограничений на сами таблицы, индексы и данные, то выглядит очень интересно...
но воздержались от обнародования полной модели именно из-за этих опасений
Ну да, конечно! Фарш провернуть обратно не получится. Эта функция или подобная с 220 млрд изображений улиц будет сначала для узкого круга по секрету, потом платно, а потом для всех... Просто думать нужно, что и где выкладываешь...
Когда на одном из собеседований по контрольному примеру я привел результат, отличный от ожидаемого, мне указали, что я решил его неверно. Я проверил решение и не нашел ошибки, после чего мы вместе со спецом компании проверили "эталонное" решение от работодателя и нашли ошибку в нем.
В результате - отказ. Написал просьбу прислать комментарий и к моему удивлению получил ответ, в нем было написано как раз что-то вроде такого: overskill - мы считаем, что вы быстро уволитесь от нас так как квалификация выше, чем требуется...
Обычно на канале есть пяток пользователь, которые постоянно оффтопят, засоряя этот канал своим словоблудием - я бы хотел просто не видеть сообщений от таких пользователей.
Таким образом мне не хватает личного белого/черного списка пользователей на канале, которым я хотел бы управлять как простой участник канала.
"мы и в быту видим вещи, которые есть не просто композиция независимых частей, а нечто большее" - как пример история про носки, когда при надевание первого на правую ногу, второй автоматически становится левым :)
Вот что может делать системный аналитик на джуниорской позиции:
Вносить изменения, не меняющие существенно бизнес-процессы и функциональность систем.
Устранять локальные инциденты, исправление которых не требует существенного изменения функций и логики работы системы.
Консультировать пользователей по работе с функциями системы и заинтересованных лиц по требованиям к этим функциям.
Разрабатывать документацию, описывающую работу функций системы.
Очень и очень спорно, если только вся ваша система не состоит из нескольких функций. Возможно подобный опыт получился на примере одного работодателя.
Джуниор может изучать всю систему и делать отдельные слабосвязанные функции под руководством наставника. И его даже близко нельзя подпускать к консультациям и разработке документации функций, которые он изучил поверхностно или не изучил вовсе.
Вносить изменения в бизнес-процессы должен бизнес аналитик, а не системный. И опять, чтобы изменить бизнес-процесс, нужно понимать требования от Заказчика, архитектуру приложения, связанность между СПО и модулями, которые затронуты этим процессом, структуру сущностей, сообщений, вплоть до "неформальной политики" с Заказчиком, когда что-то делается неоптимально потому, что так нужно Заказчику...
Некоторые из этих моментов джуниору знать не только не обязательно, но и вредно - от джуниора требуется научиться делать постановки, соответствующие требованиям и понятные разработчикам, используя определенные приемы и методики.
Эффективность дронов резко повысится, если предположить, что дрон доставляет посылки не индивидуально, а в постаматы, сразу кучкой. Тогда и грузоподъемность в 10 кг может быть использована полностью и сама логистика станет проще. Но тут появляется задача с размещением постаматов...
Недавно как раз задумывался над выбором продукта из приведенных в статье.
Мне бы, как потенциальному пользователю были бы интересны именно детали применимости продуктов для конкретных задач. У вас есть немного про это в "Лучше всего подходит для " - но как же там мало информации для принятия решения... Глядя на описание я так и не могу выбрать продукт, который мне нужен.
Было бы здорово хотя бы понимать, что такое "Быстрое развертывание, меньшие команды или проекты ". "Меньшие команды или проекты" - имеется ввиду, что с конфигами нужно работать в 1 лицо, потому, что там есть проблемы в совместном использовании и самих конфигов не должно быть более нескольких штук? Тогда сколько конкретно и что будет, если проект выйдет за эти ограничения - понимаете мои затруднения?
Вспомнилась старая статья по этим продуктам: https://habr.com/ru/companies/jugru/articles/416763/. Статья довольно сильно устарела, но там мне понравился сам подход к сравнению продуктов, хотя и по ней сделать осознанный выбор очень тяжело...
1-5 - да, только это обычно делается для привычных БД, по которым экспертиза уже есть.
6 может и не влиять ни на что. Если (к примеру) по требованиям подходит только Ceph, то экспертизу придется нарабатывать.
7 - тут да, вопросов нет. Если проект серьезный, то для всего ПО нужно будет делать обоснование выбора.
Любой каприз за Ваши деньги (деньги Заказчика).
Наличие ресурсов для разработки на этапе сбора требований не важно. Когда станет понятно, что и сколько - вот тогда и будет ресурс.
Быть гибким и любознательным - это одно, а вот в каждом новом проекте тащить в проект какое-то новое СПО или прыгать по разным инструментам - это несерьезно - вы ведь не один в команде, да?
Альтернативные решения - это и есть градация от "Хочу чтобы все" за "очень дорого" до "автоматизируем только это и это" за "дешево". Тут Заказчик выбирает для своего кошелька и наличия времени до дедлайна.
Еще несколько моментов, которые можно было бы подсветить:
Целевая длительность боя - грубо говоря за сколько ударов может умереть противник, сопоставимого с пользователем уровня - за 1-2 или за 20-30 (включая промахи).
Противодействие рутине - какие способы будут применены для предоставления пользователю нового опыта, скажем, при росте его уровня.
Балансировка архетипов (возможно - синергия архетипов) - у вас ведь не будет безликий солдат - наверняка будут и воины ближнего боя и лучники и маги и у каждого из них свои плюсы и минусы.
Подскажите, плиз - описали язык предметной области, а интеграция как происходит в проект? На примере самого простого примера (см. https://www.jetbrains.com/help/mps/shapes-an-introductory-mps-tutorial.html#goal) - могу ли я на вход дать текст вида:
Painting Test
circle x: 10 y: 10 radius: 30 Color: red
square x: 100 y: 200 size: 50 Color: green
чтобы получить картинку?
Была такая проблема - отрывало водостоки подвижкой снега с крыши. Решил проблему тем, что водостоки сдвинул немного вниз. Теперь снег идет над ними, правда при сильных ливнях струи воды, разогнавшись со ската, тоже идут мимо... Теоретически можно заморочиться летней/зимней позицией, но лень было...
Вот ведь, мне казалось, что влияние игрока на поле боя было во всех играх, которые я видел. Но раз это не на виду, то вот несколько:
Prime World: Defenders 2
Deathtrap
Element TD 2
серия GemCraft
На примере последней - при посредственной графике там очень простая и одновременно мощная тактическая система боя, которая вовлекает игрока в бой очень сильно при том, что самого аватара игрока на поле боя нет.
Для игрока есть возможность
бустить баши, давая им дополнительные способности (мощный выстрел, луч и др.).
переносить камни - фактически перемещать оборону по карте в то место, где она более востребована.
морозить, проклинать монстров.
уничтожать камни, вызывая сильные взрывы.
взаимодействовать с окружением на карте - уничтожать дома, бакены, дающие буст монстрам, норы монстров, усиливать волны, ускорять волны и многое другое.
строить на карте не только башни, но и стены и другие объекты. Сами другие объекты, есть как доступные для строительства, так и нет. Эти объекты в свою очередь могут бустить рядом стоящие башни или иметь другие эффекты. Некоторые объекты пассивные, другие необходимо зарядить, выполнив отпределенные условия, третьи развиваемые и в них необходимо вкладывать ресурсы.
выполнять некие задания, которые нужно выполнить на карте.
В общем, нужно посмотреть самому...
Еще один момент - у вас есть типы урона, а будут ли у вас долговременные эффекты в зависимости от типа урона (огонь - поджигает, холод - замедляет/замораживает)?
Для этого жанра просто строительства башен недостаточно.
must have является возможность влияние игрока на бой (точечные удары, буст башен, дебафы врагов и т.д.). Сами башни в этом случае служат необходимой базой, а действия игрока - тем самым, что делает игру...
Отличная новость.
Правда мне интересны не сами новинки, а вопрос "На сколько подешевеют существующие карты?" - например, обычный и игровой вариант 4070. Ибо цены на них просто неадекватные. Но это станет понятно через некоторое время...
Что, простите? Современный тренд - это теплый сортир в доме против сортира "до витру" в конце огорода. Никто в здравом уме не будет расходовать и так небольшую площадь на 3 туалета при том, что все это "богатство" ограничено еще и объемом септика.
Если там нет какого-либо списка ограничений на сами таблицы, индексы и данные, то выглядит очень интересно...
Ну да, конечно! Фарш провернуть обратно не получится. Эта функция или подобная с 220 млрд изображений улиц будет сначала для узкого круга по секрету, потом платно, а потом для всех... Просто думать нужно, что и где выкладываешь...
А есть еще вариант с overskill.
Когда на одном из собеседований по контрольному примеру я привел результат, отличный от ожидаемого, мне указали, что я решил его неверно. Я проверил решение и не нашел ошибки, после чего мы вместе со спецом компании проверили "эталонное" решение от работодателя и нашли ошибку в нем.
В результате - отказ. Написал просьбу прислать комментарий и к моему удивлению получил ответ, в нем было написано как раз что-то вроде такого: overskill - мы считаем, что вы быстро уволитесь от нас так как квалификация выше, чем требуется...
Обычно на канале есть пяток пользователь, которые постоянно оффтопят, засоряя этот канал своим словоблудием - я бы хотел просто не видеть сообщений от таких пользователей.
Таким образом мне не хватает личного белого/черного списка пользователей на канале, которым я хотел бы управлять как простой участник канала.
"мы и в быту видим вещи, которые есть не просто композиция независимых частей, а нечто большее" - как пример история про носки, когда при надевание первого на правую ногу, второй автоматически становится левым :)
UnEpic (https://store.steampowered.com/app/233980/UnEpic/)
Эффективные менеджеры похоже пытаются монетизировать популярность. Это уже не первое спорное решение, и скорее всего не последнее...
Желтоватенький заголовок. Звучит так, что эта вода уничтожается... Лучше бы написали, что "для 10 ответов нужен 1 литр воды для охлаждения ЦОД".
Вносить изменения, не меняющие существенно бизнес-процессы и функциональность систем.
Устранять локальные инциденты, исправление которых не требует существенного изменения функций и логики работы системы.
Консультировать пользователей по работе с функциями системы и заинтересованных лиц по требованиям к этим функциям.
Разрабатывать документацию, описывающую работу функций системы.
Очень и очень спорно, если только вся ваша система не состоит из нескольких функций. Возможно подобный опыт получился на примере одного работодателя.
Джуниор может изучать всю систему и делать отдельные слабосвязанные функции под руководством наставника. И его даже близко нельзя подпускать к консультациям и разработке документации функций, которые он изучил поверхностно или не изучил вовсе.
Вносить изменения в бизнес-процессы должен бизнес аналитик, а не системный. И опять, чтобы изменить бизнес-процесс, нужно понимать требования от Заказчика, архитектуру приложения, связанность между СПО и модулями, которые затронуты этим процессом, структуру сущностей, сообщений, вплоть до "неформальной политики" с Заказчиком, когда что-то делается неоптимально потому, что так нужно Заказчику...
Некоторые из этих моментов джуниору знать не только не обязательно, но и вредно - от джуниора требуется научиться делать постановки, соответствующие требованиям и понятные разработчикам, используя определенные приемы и методики.