К сожалению, сталкивался в своей практике с разработчиками типа 2, которые как раз считали себя очень опытными, а остальных беспечными/несистемными и т.д.
В результате разработка продукта занимала вместо 1 месяца пол-года, на выходе получалось не то, что нужно пользователям, а потом разработчика 1-го типа всё равно всё приходилось переделывать...
В общем, мне ситуация напоминает цитату Дональда Кнута про преждевременную оптимизацию.
Но вообще всё хорошо в меру, и у каждого подхода есть свои достоинства и недостатки. Самое страшное, когда в своём подходе видишь только плюсы, а во всех остальных минусы.
Да, спасибо. Посмотрел туторилс SimPy - я что-то очень похожее переизобрёл) Чучка не читатель, с другой стороны, если бы я знал о наличии такого фреймворка, то не было бы повода поупражняться самому.
В любом случае, спасибо большое, информация об этих фреймворках точно мне пригодится)
Спасибо! А что значит "визуально"? В идеальном будущем добавление/отключение узлов, конечно, хочется сделать по клику. Но сам код обработки реквестов, логику алгоритма вряд ли можно будет "накликать".
Согласен, это мог быть хороший первый вариант. Но я в итоге пошёл другим путём, и вроде похожесть на raft.github.io даёт надежду на то, что путь правильный)
Не совсем вас понял. Граф как набор состояний объектов системы? Такую таблицу строит TLA+, но выглядит не очень интуитивно, если честно. И то, эту таблицу читаешь в статике, по сути дебажишь. Или вы о другом представлении?
В двух словах работа алгоритма. Для каждого слова А в исходной выборке надо получить паттерн для каждого другого слова B, как если бы мы вводили первым слово A, а загадано было бы слово B.
Логично, что паттерны для некоторых слов будут совпадать (особенно, если это все серые). Все паттерны распределеяем по бакетам по количеству. Таким образом, для каждого слова в исходной выборке получаем словарь вида узор: количество повторений. Далее из всех слов выбираем начальным то, у которого узор с максимальным количеством повторений является минимальным среди всех остальных слов, ну, то есть, такой min(max(...)).
Соответственно, именно это начальное слово даже при худшем раскладе максимально уменьшит нам выборку доступных слов. Ну и этот алгоритм повторяется на втором и последующем шагах с учетом уже открытых букв и сильно сократившегося количества доступных слов.
Для https://wordle.belousov.one/ работает за 2-5 попыток, чаще всего 3. Для тинька работает хуже, потому что Тинькофф не случайное слово из условной тысячи выбирает, а загадывает относительно редкие.
Интересно, когда уже наши издательства найдут нормального корректора? Не такая большая книжка, прочитал треть, нашел три смысловые опечатки.
Чтобы не быть голословным: стр. 108.
Клиент записывает в систему элемент данных D1, и запись обра- батывается сервером Sx, у которого теперь есть векторные часы D1[(Sx, 1)].
ДругойклиентсчитываетпоследнююверсиюD1,обновляетеедо D2 и записывает обратно. D2 происходит от элемента D1 и поэтому записывается вместо него. Предполагается, что запись обрабатыва- ется тем же сервером Sx, векторные часы которого теперь выглядят как D2([Sx, 2]).
ЕщеодинклиентсчитываетпоследнююверсиюD2,обновляетеедо D3 и записывает обратно. Предполагается, что запись обрабатыва- ется тем же сервером Sy, векторные часы которого теперь выглядят как D3([Sx, 2], [Sy, 1])).
"Тот же" сервер Sy первый раз упоминается в списке. И таких примеров несколько.
Следующая страница 109-110:
Если номер версии каждого члена векторных часов Y больше или равен номерам версий в X, это означает, что X является наследником Y и, сле- довательно, эти версии не конфликтуют. Например, векторные часы D([s0, 1], [s1, 1])] являются предшественником D([s0, 1], [s1, 2]), поэтому конфликт не записывается.
Здесь перепутаны понятия "наследник" и "предшественник".
Latency даже гугл переводит как "задержка", а не "латентность". (Хотя, справедливости ради, такой термин всё-таки встречается в Википедии.)
Docker compose в вашем примере - это architectural quanta, архитектурный квант.
Цитата из книги
An architectural quantum is an independently deployable component with high functional cohesion, which includes all the structural elements required for the system to function properly. In a monolithic architecture, the quantum is the entire application
То есть, есть разница между архитектурным квантом и монолитом.
Ну и это ответ на второй вопрос
Этот набор скриптов будет модулем или микросервисом?
Сервисы не делятся на два множества: монолиты и микросервисы. Есть много разных видов архитектур, включая big ball of mud (отсутствие архитектуры), монолит, модульный монолит, SOA и т.д.
В зависимости от вашего типа архитектуры набор скриптов может быть и модулем монолита и набором доменных скриптов в SOA и выделенными микросервисами (при условии их отдельного деплоя).
Привет! Технология выпекания на самом деле прописана в стандартах и периодически меняется и улучшается в зависимости от потребности.
Тут проблема в масштабировании. При более 700 точек с различными партнерами могут быть по каким-то причинам выставлены не те настройки, либо по каким-то причинам общие стандарты не подходят, либо же просто человеческий фактор.
Собственно для этого и нужен контроллинг, чтобы отслеживать такие ситуации *по конкретным пиццериям*, разбираться, что не так и помогать партнёру делать качественный продукт.
Мы для себя решили, что метод тоже должен находиться в коде джобы для того, потому что запуски launcher'а не добавишь в Git и теряется информация для аудита, с тем ли методом была запущена джоба.
Бывают такие люди, сам сталкивался. В таком случае помогает задать вопрос себе (да и ему/ей), настолько ли это уникальный человек в компании, что вам необходимо тратить на него время дважды. Потому что первый раз вы уже потратили время, детально всё описывая.
Everything in software architecture is a trade-off.
Любое решение является компромиссом (о чём @komgbu чётко расписал).
Второй закон:
Why is more important than how.
Вопрос "почему" является важнее вопроса "как". Для меня это стало тоже очень ценным подспорьем в спорах с коллегами, которые слишком рано уходят в детали имплементации, не рассматривая картину целиком.
К сожалению, сталкивался в своей практике с разработчиками типа 2, которые как раз считали себя очень опытными, а остальных беспечными/несистемными и т.д.
В результате разработка продукта занимала вместо 1 месяца пол-года, на выходе получалось не то, что нужно пользователям, а потом разработчика 1-го типа всё равно всё приходилось переделывать...
В общем, мне ситуация напоминает цитату Дональда Кнута про преждевременную оптимизацию.
Но вообще всё хорошо в меру, и у каждого подхода есть свои достоинства и недостатки. Самое страшное, когда в своём подходе видишь только плюсы, а во всех остальных минусы.
Это не гуглопереводчик, это хуже.
Даже гуглопереводчик знает, что fabric - это ткань, а не фабрика.
Да, спасибо. Посмотрел туторилс SimPy - я что-то очень похожее переизобрёл) Чучка не читатель, с другой стороны, если бы я знал о наличии такого фреймворка, то не было бы повода поупражняться самому.
В любом случае, спасибо большое, информация об этих фреймворках точно мне пригодится)
Эх, чукча не читатель... SymPy, пишут, библиотека для выполнения символьных вычислений, как будто не очень в тему.
А вот Salabim выглядит очень интересно, спасибо, надо изучить.
Спасибо! А что значит "визуально"? В идеальном будущем добавление/отключение узлов, конечно, хочется сделать по клику. Но сам код обработки реквестов, логику алгоритма вряд ли можно будет "накликать".
Согласен, это мог быть хороший первый вариант. Но я в итоге пошёл другим путём, и вроде похожесть на raft.github.io даёт надежду на то, что путь правильный)
Не совсем вас понял. Граф как набор состояний объектов системы? Такую таблицу строит TLA+, но выглядит не очень интуитивно, если честно. И то, эту таблицу читаешь в статике, по сути дебажишь. Или вы о другом представлении?
В двух словах работа алгоритма. Для каждого слова А в исходной выборке надо получить паттерн для каждого другого слова B, как если бы мы вводили первым слово A, а загадано было бы слово B.
Логично, что паттерны для некоторых слов будут совпадать (особенно, если это все серые). Все паттерны распределеяем по бакетам по количеству. Таким образом, для каждого слова в исходной выборке получаем словарь вида узор: количество повторений. Далее из всех слов выбираем начальным то, у которого узор с максимальным количеством повторений является минимальным среди всех остальных слов, ну, то есть, такой min(max(...)).
Соответственно, именно это начальное слово даже при худшем раскладе максимально уменьшит нам выборку доступных слов. Ну и этот алгоритм повторяется на втором и последующем шагах с учетом уже открытых букв и сильно сократившегося количества доступных слов.
Пару месяцев назад заморочился этой задачей, написал алгоритм на питоне.
https://gist.github.com/xneg/4dc9f82cb1822c1d7aaef27143558658
Для https://wordle.belousov.one/ работает за 2-5 попыток, чаще всего 3. Для тинька работает хуже, потому что Тинькофф не случайное слово из условной тысячи выбирает, а загадывает относительно редкие.
Интересно, когда уже наши издательства найдут нормального корректора? Не такая большая книжка, прочитал треть, нашел три смысловые опечатки.
Чтобы не быть голословным: стр. 108.
Клиент записывает в систему элемент данных D1, и запись обра- батывается сервером Sx, у которого теперь есть векторные часы D1[(Sx, 1)].
ДругойклиентсчитываетпоследнююверсиюD1,обновляетеедо D2 и записывает обратно. D2 происходит от элемента D1 и поэтому записывается вместо него. Предполагается, что запись обрабатыва- ется тем же сервером Sx, векторные часы которого теперь выглядят как D2([Sx, 2]).
ЕщеодинклиентсчитываетпоследнююверсиюD2,обновляетеедо D3 и записывает обратно. Предполагается, что запись обрабатыва- ется тем же сервером Sy, векторные часы которого теперь выглядят как D3([Sx, 2], [Sy, 1])).
"Тот же" сервер Sy первый раз упоминается в списке. И таких примеров несколько.
Следующая страница 109-110:
Здесь перепутаны понятия "наследник" и "предшественник".
Latency даже гугл переводит как "задержка", а не "латентность". (Хотя, справедливости ради, такой термин всё-таки встречается в Википедии.)
Ну, это всё же разные единицы деплоя. У них нет общей памяти, они хостятся в разных процессах.
Отсылаю к книжке https://learning.oreilly.com/library/view/building-evolutionary-architectures/9781491986356/ch04.html#idm45678212630456
Docker compose в вашем примере - это architectural quanta, архитектурный квант.
Цитата из книги
То есть, есть разница между архитектурным квантом и монолитом.
Ну и это ответ на второй вопрос
Сервисы не делятся на два множества: монолиты и микросервисы. Есть много разных видов архитектур, включая big ball of mud (отсутствие архитектуры), монолит, модульный монолит, SOA и т.д.
В зависимости от вашего типа архитектуры набор скриптов может быть и модулем монолита и набором доменных скриптов в SOA и выделенными микросервисами (при условии их отдельного деплоя).
docker compose, в котором есть redis, postgres и рэббит - это монолит?
Вроде в вопросе и содержится ответ) микросервис - это отдельная единица деплоя, а модуль - это часть одной большой единицы деплоя.
Ну, мы стараемся) Но косяки случаются. Дело не только в пропекании, а в том числе, как раскатано тесто, как положили начинку и т.д.
И да, печи не настолько умные, скорее как кофе-машины, их надо уметь настраивать.
Привет! Технология выпекания на самом деле прописана в стандартах и периодически меняется и улучшается в зависимости от потребности.
Тут проблема в масштабировании. При более 700 точек с различными партнерами могут быть по каким-то причинам выставлены не те настройки, либо по каким-то причинам общие стандарты не подходят, либо же просто человеческий фактор.
Собственно для этого и нужен контроллинг, чтобы отслеживать такие ситуации *по конкретным пиццериям*, разбираться, что не так и помогать партнёру делать качественный продукт.
Да, теперь всё понятно)
Спасибо за статью! Наша команда из трех-четырех DE за пару лет пришла к очень похожим принципам.
Есть вопрос про launcher/исполнитель джобов. Из статьи получается, что метод переливки находится не в коде джобы, а является параметром launcher'а.
launcher.run_job(job_name='marts.crm_bill', method='increment')Мы для себя решили, что метод тоже должен находиться в коде джобы для того, потому что запуски launcher'а не добавишь в Git и теряется информация для аудита, с тем ли методом была запущена джоба.
Вы как-то по-другому решаете эту проблему?
Бывают такие люди, сам сталкивался. В таком случае помогает задать вопрос себе (да и ему/ей), настолько ли это уникальный человек в компании, что вам необходимо тратить на него время дважды. Потому что первый раз вы уже потратили время, детально всё описывая.
@komgbu прав, а вот я в статье слегка напутал
В книжке выводится всего два закона архитектуры.
Первый закон:
Everything in software architecture is a trade-off.
Любое решение является компромиссом (о чём @komgbu чётко расписал).
Второй закон:
Why is more important than how.
Вопрос "почему" является важнее вопроса "как". Для меня это стало тоже очень ценным подспорьем в спорах с коллегами, которые слишком рано уходят в детали имплементации, не рассматривая картину целиком.