Понял. Просто с моей точки зрения - позиционные параметры вещь хрупкая и к багам ведущая. Но может у вас другой опыт. Я просто всегда на именованных параметрах сидел и хрупкость чисто умозрительно говорю.
Вот это боль моя дырка задница! Как-то делал небольшой русскоязычный язык программирования (скорее даже DSL) и решил, что если уж всё на русском, то должно хватать только русской раскладки. И сразу лишился <>{}[]' и т.д. Прощай сразу всё сиподобное.
Если мы говорим про серверные приложения, то ещё и миграция данных, которая может выполняться в несколько шагов и сборка и разворачивание новой версии перед удалением предыдущей.
Я когда-то собирал руками и обновлял на сервере службу Windows, которая занималась отложенной обработкой данных. Мне не понравилось.
А откуда взялись изначальные определения? Это домыслы или есть фактура?
Я всегда понимал так, CI - мы часто сливаем изменения в общую ветку (интегрируем). Во времена, когда пол года могла идти разработка, а потом месяц интеграция в кодовую базу, это было революционной идеей.
CD - выпуск обновления занимает день работы инженера, а он ещё и косячит. Возможно выпускать релиз по нажатию одной кнопки тоже выглядит как чудо.
А что до выпуска недоделанного продукта, то тут решают не пайплайны, а сама возможность быстро доставить обновление. Это видно под играм. Пока игры были на дисках к багам относились серьёзно, потому что перевыпускать - дорого. Сейчас же игра выходит с багами и это стало нормой. И никакой CI/CD тут не виноват.
Нет, т.к. на вход срока, в которой делаются замены по регуляркам. Ничего не мешает заменить слово "слон" на знак плюс. Где-то слон будет, а где-то нет. Менеджеры такую жесть не творили, но инструмент позволял. Так что считаем в каждое выражение.
У меня есть пример: расчёт цены при разборе прайс-листов. Формула для цены - это результат текстовой обработки на чём-то похожем на регулярки, которые настраивает менеджер для конкретного поставщика. Реальные, какие-то сроки на выход, нужно посчитать. До миллиона выражений за обработку прайса.
если у вас может гонка между операциями, то используем блокировку ресурсов в каком-то виде. и м.б. какой-то оркестратор, чтобы не мучиться с обработкой падений.
Если гонки нет, то читаем состояние и говорим, что на момент операции всё было как надо, а потом оно могло измениться.
Ещё можно взять оркестратор и написать сагу. Т.е. с оптимизмом всё делаем, а если проблема - откатываем.
Сам я пишу бэкенды и не верю в тактический ДДД. Особенно когда есть микросервисы.
Ну типа, у нас есть модуль в виде класса, чтобы потребители не переломали его инварианты. А у меня есть модуль в виде микросервиса, чтобы потребители не переломали его инварианты. Внутри он может быть написан как угодно, если мы можем разобраться с его внутренностями. Ровно как и с внутренностями агрегатов.
А крутым спецам даже тимлид не нужен, они сами справляются. Ладно, тимлид им нужен, чтобы на него спихнуть неинтересную управленческую работу.
У спецов вполне может быть ситуация: "я с вами не согласен, но принимают ваше решение". Ибо они понимают, что рубиться весело, но проект нужно двигать. При этом решение фиксируют в ADR или прочих DR, с альтернативами, рисками и т.п., чтобы в случае чего можно вернуться к вопросу понять почему так решили. Т.е. рубилово - это тоже работа и в результате она имеет артефакт. А не так, что поговорили и забыли.
Я пришёл на проект где толпа джунов не могла зарелизиться, потому что на ревью спорили за стиль форматирования, способ проброса ошибок и т.д. и т.п. За всё спорили. Я своей авторитарной тимлидской рукой сказал "вот так делайте, а если думаете, что нужно по другому, потом обсудим". И разработка пошла. Среднее время прохождения ПР снизилось с 2-х недель до 2-х дней.
Я так же как и автор считаю, что пофиг какой стиль. Главное чтобы был, а там, либо привыкнем, либо передоговоримся.
Эта ссылка есть в посте (:
Понял. Просто с моей точки зрения - позиционные параметры вещь хрупкая и к багам ведущая. Но может у вас другой опыт. Я просто всегда на именованных параметрах сидел и хрупкость чисто умозрительно говорю.
В мире .net есть такая же либа: https://github.com/DapperLib/Dapper
А в truej можно привязывать параметры по именам, а не по позиции?
{} заменили на
цикл началоицикл конец:'(Вот это боль моя дырка задница!
Как-то делал небольшой русскоязычный язык программирования (скорее даже DSL) и решил, что если уж всё на русском, то должно хватать только русской раскладки. И сразу лишился
<>{}[]'и т.д. Прощай сразу всё сиподобное.Если мы говорим про серверные приложения, то ещё и миграция данных, которая может выполняться в несколько шагов и сборка и разворачивание новой версии перед удалением предыдущей.
Я когда-то собирал руками и обновлял на сервере службу Windows, которая занималась отложенной обработкой данных. Мне не понравилось.
А откуда взялись изначальные определения? Это домыслы или есть фактура?
Я всегда понимал так, CI - мы часто сливаем изменения в общую ветку (интегрируем). Во времена, когда пол года могла идти разработка, а потом месяц интеграция в кодовую базу, это было революционной идеей.
CD - выпуск обновления занимает день работы инженера, а он ещё и косячит. Возможно выпускать релиз по нажатию одной кнопки тоже выглядит как чудо.
А что до выпуска недоделанного продукта, то тут решают не пайплайны, а сама возможность быстро доставить обновление. Это видно под играм. Пока игры были на дисках к багам относились серьёзно, потому что перевыпускать - дорого. Сейчас же игра выходит с багами и это стало нормой. И никакой CI/CD тут не виноват.
Не согласен, мы же здесь (:
Это вирусная статься, а автор профессионал!
О да! Искал кто может сделать лестницу, оказалось в моём посёлке аж 5 частных мастерских, счастье то какое! Все агрегаторы, как вы понимаете.
В итоге поиск по карте не имеет смысла.
Так это же в разделе "Яйцеголовые", думаю его ответ по компонентам устроил бы.
Если я правильно понял, у них есть неравномерный спрос и, возможно, генерация. А ещё биржевая цена на ЭЭ в зависимости от спроса и предложения.
Чтобы балансировать всё это нужны маневровые мощности (аля растопили газовую котельную) и аккумуляторы (например, озёра).
Они придумали, как использовать частные автомобили в качестве аккумуляторов. Небольшая денежка для владельцев и они в деле.
Если вернуться к аналогии: ферма не хочет строить склады или держать коров в резерве (ага, они доятся нон-стоп в такой аналогии :).
Нет, т.к. на вход срока, в которой делаются замены по регуляркам. Ничего не мешает заменить слово "слон" на знак плюс. Где-то слон будет, а где-то нет. Менеджеры такую жесть не творили, но инструмент позволял. Так что считаем в каждое выражение.
У меня есть пример: расчёт цены при разборе прайс-листов.
Формула для цены - это результат текстовой обработки на чём-то похожем на регулярки, которые настраивает менеджер для конкретного поставщика. Реальные, какие-то сроки на выход, нужно посчитать. До миллиона выражений за обработку прайса.
100 штук 4-х значных.
Тоже сначала как 100-значные прочитал.
В моём мире так:
если у вас может гонка между операциями, то используем блокировку ресурсов в каком-то виде. и м.б. какой-то оркестратор, чтобы не мучиться с обработкой падений.
Если гонки нет, то читаем состояние и говорим, что на момент операции всё было как надо, а потом оно могло измениться.
Ещё можно взять оркестратор и написать сагу. Т.е. с оптимизмом всё делаем, а если проблема - откатываем.
Сам я пишу бэкенды и не верю в тактический ДДД. Особенно когда есть микросервисы.
Ну типа, у нас есть модуль в виде класса, чтобы потребители не переломали его инварианты. А у меня есть модуль в виде микросервиса, чтобы потребители не переломали его инварианты. Внутри он может быть написан как угодно, если мы можем разобраться с его внутренностями. Ровно как и с внутренностями агрегатов.
могут усложняться. А могут и не усложняться. А что такое улучшаются - вообще большой вопрос.
Но мы точно знаем, что приспосабливаются, ибо неприспособившиеся уже не живут.
А крутым спецам даже тимлид не нужен, они сами справляются. Ладно, тимлид им нужен, чтобы на него спихнуть неинтересную управленческую работу.
У спецов вполне может быть ситуация: "я с вами не согласен, но принимают ваше решение". Ибо они понимают, что рубиться весело, но проект нужно двигать. При этом решение фиксируют в ADR или прочих DR, с альтернативами, рисками и т.п., чтобы в случае чего можно вернуться к вопросу понять почему так решили. Т.е. рубилово - это тоже работа и в результате она имеет артефакт. А не так, что поговорили и забыли.
А теперь история из жизни.
Я пришёл на проект где толпа джунов не могла зарелизиться, потому что на ревью спорили за стиль форматирования, способ проброса ошибок и т.д. и т.п. За всё спорили. Я своей авторитарной тимлидской рукой сказал "вот так делайте, а если думаете, что нужно по другому, потом обсудим". И разработка пошла. Среднее время прохождения ПР снизилось с 2-х недель до 2-х дней.
Я так же как и автор считаю, что пофиг какой стиль. Главное чтобы был, а там, либо привыкнем, либо передоговоримся.
У нас так принято