Там счётчик продолбов из-за високосного дня не переполнился ещё? В итоге человечество погибнет кода через 100 лет программисты скайнета ошибутся и ограничения безопасности перестанут работать на 366й день года :)
Не, я имел в виду "всё" одного уровня абстракции. Ну то есть условно код, который по бизнес-логике должен составить запросы в сервис1 и сервис2 и по данным от них либо вызвать одно действие в сервисе3 либо ещё забрать данные из сервиса4 и уже с ними вызвать сервис3.
Клиенты к сервисам естественно отдельные классы/модули. Иногда это можно разделить так, что вначале сделать все внешние запросы и потом вызвать чистую логику принятия решения что отправлять в сервис3. Но если вызов в сервис4 дорогой, то его надо делать только если действительно нужно. А определение нужности уже часть бизнес-логики. И тут либо мокать клиенты к сервисам, получая связанность теста с конкретными деталями взаимодейтсвия с сервисами и меняя его если бизнес логика какой-нибудь FindById сменит на вызов FindByUsername. Либо абстрагировать всех клиентов за специальным интерфейсом созданным специально для этой части бизнес-логики. Тогда бизнес логика вызывает только этот специальный интерфейс, который можно замокать в тестах и изменения лишь особенностей взаимодействия с внешним миром (поменять имплементацию interface.FindUser c client1.FindById на client1.FindByUsername) не приведет к изменениям тестов.
Но пилить отдельный интерфейс для каждого workflow такого вида - выглядит громоздко
Начал сильно обращать на это внимание только после работы с системами типа Temporal/Azure Durable Function где фреймворк форсит тебя разделять decision-making и грязные дествия.
Мысль кажется очевидной когда осознаешь её, но как же в обычных языках типа C#/Java блин проще не задумываясь, в потоке, написать всё в одном классе, максимум в приватные функции выделив обращение во внешний мир. И получить непокрываемую юнит-тестами логику :(
Выносить сайд-эффекты в отдельный класс, прятать за интерфесом, чтобы в тестах замокать. Ещё придумывать какие типы будут в интерфейсе, тупо брать модели из используемого клиента внешнего сервиса из реальной имплементации или создавать отдельные модели и делать конвертацию между ними. Оно в целом недолго делается, но ментально это настолько больше шагов что порой проще сказать "да интеграционными тестаи проверится за компанию". Может есть какой-то более простой рецепт как всё это разделять, который я не вижу?
Ну сами лямбды кстати не сильно дорогие. Dev/QA лабы можно на каждый чих создавать и не париться что деньги будут за время существования браться, как в случае контейнеров. Так что их можно рассматривать как минимум при выборе контейнеры в облаке vs лямбды в том же облаке, когда косты на всё остальное плюс минус будут одинаковыми.
А в чём удобство распределенного монолита? Если разные лямбды ходят в одну базу и используют общий код, то там такое веселье с консистентностью доступа к данным и апдейтов самого кода начинается.
Блин, случаются же тупняки. Я вначале думал что механика сборки качественных предметов работает автоматически в зависимости от качества сырья и что можно будет зациклить сборку предмета с его разборкой и когда-нибуть оттуда будут выходить качественные вещи. А потом оказалось что качественный предмет это по сути отдельный рецепт и ассемблер настроенный на обычный рецепт не подхватит качественные ингридиенты. Из этого я сделал вывод что нужно будет сложную сортировку сырья делать, а до мысли что сырьё можно по самому простому рецепту собирать-разбирать и потом везде использовать не додумался. Ну вот, не зря в дискуссию вступал :) С такого угла возможно для мелкосерийных вещей ещё имеет смысл заморачиваться
Упростить это хорошо, но в принципе отрезать возможности автоматизации в игре про автоматизацию это не упрощение, а вредительство какое-то. С разнесением на планеты тоже получилось не очень: унесли взрывчатку для скал на Вулкан, сделав невозможным нормально отбилдить ситиблоки на Наувис. После этого желание катать ванильный Space Age отпало, пришлось обмазаться модами
Я тут понял что смотрю на это только с точки зрения человека который хочет построить модульную расширяемую базу и побыстрее получить Victory screen. В то время как цель у играющего может быть другой. И вот для каких-нибудь мегабаз на 100500 науки в минуту качество вполне уже может играть роль из-за UPS и всего такого
Учитывая сколько нужно разобрать туррелей чтобы построить хотя бы одну легендарную, проще оставить как есть и позволить дронам отстраивать обычные обратно
Учитывая что это всё было в Space Exploration, и в разработке принимал участие его автор, я очень разочарован что получилось гораздо хуже чем могло бы быть
Да, тут они хорошие места для автоматизации сделали. Видел где-то даже автоматику которая включает маяки для ускорения производства, когда качество уже зароллилось и понижение вероятности качества от модулей скорости уже не влияет.
С другой стороны космическая логистика по сравнению со Space Exploration получилась так себе. Я даже молчу про маленькую грузоподёмность ракеты, она даже в целом выглядит более-менее балансной и достаточной. Но вот невозможность задать из логической сети запросы для космической платформы - это очень грустно. Мне в итоге удалось построить универсальный доставщик через задание запросов в определенных логистических группах и мода на межпланетную передачу сигналов, но мозг пришлось поломать. В целом Space Age выглядит похуже Space Exploration, слишком много проблем поданных в стиле "это не плохой дизайн, а челлендж"
и это требует не только полностью переработать все решения, которые были в ванили
А можно и не перерабатывать. Проходим понемногу Space Age c другом. Решили просто не тратить времени на производство вещей более высогоко качества. По сумме времени, потраченного на проектирование универсального блока производящего любую вещь нужного качества (или N блоков производящих конкретную вещь конкретного качества), и ресурсов, которые затем будут потрачены на их производство, выглядит так что они вообще не стоят того. Альтернатива - за пару секунд ляпнуть ещё несколько ситиблоков для горизонтального масштабирования - экономит куда больше времени
Есть Go, у которого помимо большой официальной имплементации есть TinyGo и любительские имплементации подмножеств языка, которые можно найти на гитхабе
Из неочевидных подводных камней: проверьте максимальные таймауты который разрешает ваш ApiGateway. У нативного амазоновского жётский лимит в 29 секунд и порой то холодный старт подлагал, то внешнее апи медленнее ответило и упс, ваш клиент уже получил gateway timeout.
В том же AWS как вариант можно использовать Application Load Balancer, который не имеет таких лимитов как Api Gateway (как не имеет и его фичей), но при этом вы всё ещё ограничены упомянутым в статье таймаутом на время выполнения функции, что может быть стоппером для fully serverless архитектуры, если вы обращаетесь к какому-нибудь легаси у которого единственный вид взаимодействия - синхронные http вызовы по 30 минут.
Живая иллюстрация той выдуманной истории про Васю, который 4 месяца пилил идеальное приложение, и Поттеринга Петю, который зарелизил говнокод за 2 недели?
Вообще можно провернуть это против OpenAI, сказав что именно поэтому нельзя скрывать от людей промежуточные шаги размышления модели, дабы все могли провалидировать что она не решила вас обманывать
Ну вот я и про конкорд узнал только когда он закрылся. А пиарились бы, то может на распродаже стима я и прикупил бы потыкать. А то valorant на линуксе не запускается, overwatch скатился, а deadlock это дота от первого лица, от шутера особо ничего нет.
Там счётчик продолбов из-за високосного дня не переполнился ещё? В итоге человечество погибнет кода через 100 лет программисты скайнета ошибутся и ограничения безопасности перестанут работать на 366й день года :)
Не, я имел в виду "всё" одного уровня абстракции. Ну то есть условно код, который по бизнес-логике должен составить запросы в сервис1 и сервис2 и по данным от них либо вызвать одно действие в сервисе3 либо ещё забрать данные из сервиса4 и уже с ними вызвать сервис3.
Клиенты к сервисам естественно отдельные классы/модули. Иногда это можно разделить так, что вначале сделать все внешние запросы и потом вызвать чистую логику принятия решения что отправлять в сервис3. Но если вызов в сервис4 дорогой, то его надо делать только если действительно нужно. А определение нужности уже часть бизнес-логики. И тут либо мокать клиенты к сервисам, получая связанность теста с конкретными деталями взаимодейтсвия с сервисами и меняя его если бизнес логика какой-нибудь FindById сменит на вызов FindByUsername. Либо абстрагировать всех клиентов за специальным интерфейсом созданным специально для этой части бизнес-логики. Тогда бизнес логика вызывает только этот специальный интерфейс, который можно замокать в тестах и изменения лишь особенностей взаимодействия с внешним миром (поменять имплементацию interface.FindUser c client1.FindById на client1.FindByUsername) не приведет к изменениям тестов.
Но пилить отдельный интерфейс для каждого workflow такого вида - выглядит громоздко
Начал сильно обращать на это внимание только после работы с системами типа Temporal/Azure Durable Function где фреймворк форсит тебя разделять decision-making и грязные дествия.
Мысль кажется очевидной когда осознаешь её, но как же в обычных языках типа C#/Java блин проще не задумываясь, в потоке, написать всё в одном классе, максимум в приватные функции выделив обращение во внешний мир. И получить непокрываемую юнит-тестами логику :(
Выносить сайд-эффекты в отдельный класс, прятать за интерфесом, чтобы в тестах замокать. Ещё придумывать какие типы будут в интерфейсе, тупо брать модели из используемого клиента внешнего сервиса из реальной имплементации или создавать отдельные модели и делать конвертацию между ними. Оно в целом недолго делается, но ментально это настолько больше шагов что порой проще сказать "да интеграционными тестаи проверится за компанию". Может есть какой-то более простой рецепт как всё это разделять, который я не вижу?
Ну сами лямбды кстати не сильно дорогие. Dev/QA лабы можно на каждый чих создавать и не париться что деньги будут за время существования браться, как в случае контейнеров. Так что их можно рассматривать как минимум при выборе контейнеры в облаке vs лямбды в том же облаке, когда косты на всё остальное плюс минус будут одинаковыми.
А в чём удобство распределенного монолита? Если разные лямбды ходят в одну базу и используют общий код, то там такое веселье с консистентностью доступа к данным и апдейтов самого кода начинается.
Да и кафка может.
Направить домен на сервер нового CDN
Блин, случаются же тупняки. Я вначале думал что механика сборки качественных предметов работает автоматически в зависимости от качества сырья и что можно будет зациклить сборку предмета с его разборкой и когда-нибуть оттуда будут выходить качественные вещи. А потом оказалось что качественный предмет это по сути отдельный рецепт и ассемблер настроенный на обычный рецепт не подхватит качественные ингридиенты. Из этого я сделал вывод что нужно будет сложную сортировку сырья делать, а до мысли что сырьё можно по самому простому рецепту собирать-разбирать и потом везде использовать не додумался. Ну вот, не зря в дискуссию вступал :) С такого угла возможно для мелкосерийных вещей ещё имеет смысл заморачиваться
Упростить это хорошо, но в принципе отрезать возможности автоматизации в игре про автоматизацию это не упрощение, а вредительство какое-то. С разнесением на планеты тоже получилось не очень: унесли взрывчатку для скал на Вулкан, сделав невозможным нормально отбилдить ситиблоки на Наувис. После этого желание катать ванильный Space Age отпало, пришлось обмазаться модами
Я тут понял что смотрю на это только с точки зрения человека который хочет построить модульную расширяемую базу и побыстрее получить Victory screen. В то время как цель у играющего может быть другой. И вот для каких-нибудь мегабаз на 100500 науки в минуту качество вполне уже может играть роль из-за UPS и всего такого
Учитывая сколько нужно разобрать туррелей чтобы построить хотя бы одну легендарную, проще оставить как есть и позволить дронам отстраивать обычные обратно
Учитывая что это всё было в Space Exploration, и в разработке принимал участие его автор, я очень разочарован что получилось гораздо хуже чем могло бы быть
Да, тут они хорошие места для автоматизации сделали. Видел где-то даже автоматику которая включает маяки для ускорения производства, когда качество уже зароллилось и понижение вероятности качества от модулей скорости уже не влияет.
С другой стороны космическая логистика по сравнению со Space Exploration получилась так себе. Я даже молчу про маленькую грузоподёмность ракеты, она даже в целом выглядит более-менее балансной и достаточной. Но вот невозможность задать из логической сети запросы для космической платформы - это очень грустно. Мне в итоге удалось построить универсальный доставщик через задание запросов в определенных логистических группах и мода на межпланетную передачу сигналов, но мозг пришлось поломать. В целом Space Age выглядит похуже Space Exploration, слишком много проблем поданных в стиле "это не плохой дизайн, а челлендж"
А можно и не перерабатывать. Проходим понемногу Space Age c другом. Решили просто не тратить времени на производство вещей более высогоко качества. По сумме времени, потраченного на проектирование универсального блока производящего любую вещь нужного качества (или N блоков производящих конкретную вещь конкретного качества), и ресурсов, которые затем будут потрачены на их производство, выглядит так что они вообще не стоят того. Альтернатива - за пару секунд ляпнуть ещё несколько ситиблоков для горизонтального масштабирования - экономит куда больше времени
А усы, что происхоит с усами ГГ, это вообще феерия
Есть Go, у которого помимо большой официальной имплементации есть TinyGo и любительские имплементации подмножеств языка, которые можно найти на гитхабе
Из неочевидных подводных камней: проверьте максимальные таймауты который разрешает ваш ApiGateway. У нативного амазоновского жётский лимит в 29 секунд и порой то холодный старт подлагал, то внешнее апи медленнее ответило и упс, ваш клиент уже получил gateway timeout.
В том же AWS как вариант можно использовать Application Load Balancer, который не имеет таких лимитов как Api Gateway (как не имеет и его фичей), но при этом вы всё ещё ограничены упомянутым в статье таймаутом на время выполнения функции, что может быть стоппером для fully serverless архитектуры, если вы обращаетесь к какому-нибудь легаси у которого единственный вид взаимодействия - синхронные http вызовы по 30 минут.
Живая иллюстрация той выдуманной истории про Васю, который 4 месяца пилил идеальное приложение, и
ПоттерингаПетю, который зарелизил говнокод за 2 недели?Вообще можно провернуть это против OpenAI, сказав что именно поэтому нельзя скрывать от людей промежуточные шаги размышления модели, дабы все могли провалидировать что она не решила вас обманывать
Ну вот я и про конкорд узнал только когда он закрылся. А пиарились бы, то может на распродаже стима я и прикупил бы потыкать. А то valorant на линуксе не запускается, overwatch скатился, а deadlock это дота от первого лица, от шутера особо ничего нет.