Похоже, собеседования друг у друга вы бы не прошли 😁
Если серьёзно, очень запутано выглядят утверждения, что dotnet должен являться реализацией ("удовлетворять требованиям") virtual execution system, но при этом не является virtual machine.
Когда-то слышал трактовку, что любая ОС предоставляет даже нативным программам "виртуальную машину" как абстракцию оборудования вообще, как пример - программы работают не с конкретным диском и памятью, а с фс и виртуальной памятью. В такой трактовке почти что угодно можно назвать ВМ.
CLR - это рантайм (gc и прочее), а интерпретации в нём как правило нет (разве что в случаях использования wasm и подобных может быть), байткод компилируется в машинный код перед выполнением, поэтому это не виртуальная машина.
(пришлось выяснять у chatgpt, сам я этот момент как-то пропустил, когда пытался изучать дотнет)
Насколько вообще гемба применима к интеллектуальному труду? Какие-то задержки процесса могут появиться из-за того, что сотрудник думал не в ту сторону; с трудом представляю, как это отслеживать и что тут советовать.
Плюс индекс работает на множество запросов, а представление на сложную выборку нужно отдельное.
Производные данные (представление) могут содержать все требуемые индексы (~по каждому полю), строятся буквально вызовами create or insert ... для каждого события, а потом (или перед вставками) create index ... ; create index ... ; ... Тогда, скорее всего, делать полное чтение событий на каждый новый запрос не придётся.
Сколько будет строится представление в масштабах какого-нибудь твиттера?
Долго. С другой стороны, какая РСУБД используется в масштабах твиттера?
Это же в какой ад превратится код, чего данные практики призваны избегать.
Данные практики повышают производительность и чтения, и записи, имеют очень высокую горизонтальную масштабируемость, но адовость кода также повышается. По сути, если добавлять все эти индексы, обратную совместимость записей, в идеале это будет ре-имплементация функциональности РСУБД типа постгреса, но с нюансами. Нужно иметь весомые причины, чтобы начать реализовывать свой "постгрес". В большинстве случаев лучше взять готовый.
Да, накатывать всю историю. По сути представление - это аналог индекса в реляционной БД (а часто их и содержит, т.к. это хороший инструмент для запросов). Новый индекс можно построить, обработав все данные в таблице. Ну или не строить, а пытаться выцепить что-то из потока полным перебором. И то, и другое - долго.
В той же kafka есть механизм log compaction, который позволяет терять неактуальные события (например, старые значения параметра, когда было установлено новое). Это может ускорять построение/перестройку представлений.
Слышал, что гемба - хорошая практика, но не думал, что для этого нужно стоять над душой отдельного разработчика. Разве подключения к командным дейли митингам/синхро недостаточно, чтобы понять, что происходит?
В event sourcing, если брокер сохранил событие - система считает, что оно было, рано или поздно его эффекты распространятся на все производные БД, а в случае сбоев его можно повторно прочитать из лога событий, и таким образом восстановить состояние БД (это автоматически происходит). Если брокер не сохранил - значит и не было события, и БД его эффектов видеть не может. Обычно используется kafka, которая является не совсем брокером, а распределённым логом событий, своего рода БД, и хранит события "вечно".
По этой идее, даже при сбоях состояние БД должно автоматически синхронизироваться с потоком событий. А если какая-то аномалия (состояние не синхронизировалось правильно) - нужно перезапускать построение БД с начала или со снэпшота.
Где пропало сообщение, где что-то пошло не так - это ищется по логам сервисов, распределённой трассировкой и т.п. сложными способами. Но в этом подходе событие, будучи записанным на диск, не пропадает, а вот его эффекты могут появляться не сразу, и даже иногда временно исчезать (например при перестроении БД после сбоя, при котором БД была утеряна).
Какие-то теоретические соображения... Почти никто не пьёт пиво по 0.5л, коньяк по 0.5л, тем более вино по 0.5л! Градусы на картинке тоже какие-то рандомные, виски и коньяк не сказать чтобы отличаются по крепости.
На практике полезнее мерять алкоголь в шотах (~15-20г спирта) - так можно контролировать опьянение, зная свою дозу. Это куда полезнее, чем механически всосать 0.5 водки, а потом болеть и препараты вспоминать наутро! (но всё же не настолько полезно, как не употреблять алкоголь) И также лучше избегать определённых видов алкоголя, или ограничивать их количество в зависимости от индивидуальной переносимости (например, вино из высокотанинных сортов винограда вкусное, но способствует головной боли, так что его надо пить поменьше).
Частая причина головной боли после алкоголя - обезвоживание, поэтому употребления воды после или в процессе пьянки в принципе может быть достаточно. А баня - сомнительно.
Витамины в норме должны из еды поступать, а не таблетками по случаю алгогольного отравления. И, если вы что-то относительно разнообразное ели в последнее время (кроме водки), с витаминами должно быть всё в норме.
Во вторых внутри них нет языка запросов, чтобы что-то найти в случае ошибки или некорректного поведения в рамках бизнес процесса. То есть нельзя просто взять и вывалить все это юзеру на ui, чтобы он там искал свои загруженные или потерянные заказы.
Типичный случай для применения CQRS - подключаем к потоку событий сервис, который их агрегирует в представление, к которому удобно делать запросы. Например, в реляционную БД.
В итоге я прихожу к другим паттернам - заказы мы складываем в БД, юзеру мы показываем на ui из БД со всякими фильтрами (с использованием языка запросов). Далее заказ у нас имеет статусную модель и конечный автомат. И прежде чем что-то отправлять в брокер сообщений - надо отразить это в БД (transaction outbox).
Event sourcing как раз про то, чтобы сделать первичным источником информации не СУБД, а поток событий. Состояние БД в этом подходе вторично, это некая агрегация потока.
у нас так и вообще, скоро офлайн-магазинчики позакрываются, превратившись в ПВЗ маркетплейсов.
Не только "у нас", это общая тенденция. Слышал, что решение - открывать ПВЗ в тех самых магазинчиках, сохраняя и традиционный магазин, и доступ к маркетплейсам.
еще лет 5 назад, если вы живете не в Москве, а в каком-то региональном городке - купить что-то, что выходит за рамки мышления местных закупщиков, было практически нереально.
Лет 10 назад интернет-торговля уже была достаточно развита, и сети доставки типа boxberry уже были распространены в небольших городах. Но не по 8 ПВЗ на квартал, конечно.
Считает тетка из местного "бутика", что вот такая одежда красивая, а такая нет - и все модницы города будут ходить в одинаковой одежде, потому что другой просто не существует.
Это да, оффлайн-"бутики" моего посёлка почему-то предлагают только одежду вида "нищеброд", недорогую и ужасную внешне и по качеству. А вот строительные - весьма неплохи ассортиментом.
Похоже, собеседования друг у друга вы бы не прошли 😁
Если серьёзно, очень запутано выглядят утверждения, что dotnet должен являться реализацией ("удовлетворять требованиям") virtual execution system, но при этом не является virtual machine.
А дальше приняты рандомные решения, надзиратели ушли, а решения остались.
ChatGPT явно обучался на ответах https://stackoverflow.com/questions/1564348/is-the-clr-a-virtual-machine , а первый запрос был "почему clr - не виртуальная машина?" Ответы на stackoverflow немного расходятся, вероятно из-за определения "виртуальной машины".
Когда-то слышал трактовку, что любая ОС предоставляет даже нативным программам "виртуальную машину" как абстракцию оборудования вообще, как пример - программы работают не с конкретным диском и памятью, а с фс и виртуальной памятью. В такой трактовке почти что угодно можно назвать ВМ.
CLR - это рантайм (gc и прочее), а интерпретации в нём как правило нет (разве что в случаях использования wasm и подобных может быть), байткод компилируется в машинный код перед выполнением, поэтому это не виртуальная машина.
(пришлось выяснять у chatgpt, сам я этот момент как-то пропустил, когда пытался изучать дотнет)
Мм, рекурсивная пьянка...
Насколько вообще гемба применима к интеллектуальному труду? Какие-то задержки процесса могут появиться из-за того, что сотрудник думал не в ту сторону; с трудом представляю, как это отслеживать и что тут советовать.
Производные данные (представление) могут содержать все требуемые индексы (~по каждому полю), строятся буквально вызовами create or insert ... для каждого события, а потом (или перед вставками) create index ... ; create index ... ; ... Тогда, скорее всего, делать полное чтение событий на каждый новый запрос не придётся.
Долго. С другой стороны, какая РСУБД используется в масштабах твиттера?
Данные практики повышают производительность и чтения, и записи, имеют очень высокую горизонтальную масштабируемость, но адовость кода также повышается. По сути, если добавлять все эти индексы, обратную совместимость записей, в идеале это будет ре-имплементация функциональности РСУБД типа постгреса, но с нюансами. Нужно иметь весомые причины, чтобы начать реализовывать свой "постгрес". В большинстве случаев лучше взять готовый.
Да, накатывать всю историю. По сути представление - это аналог индекса в реляционной БД (а часто их и содержит, т.к. это хороший инструмент для запросов). Новый индекс можно построить, обработав все данные в таблице. Ну или не строить, а пытаться выцепить что-то из потока полным перебором. И то, и другое - долго.
В той же kafka есть механизм log compaction, который позволяет терять неактуальные события (например, старые значения параметра, когда было установлено новое). Это может ускорять построение/перестройку представлений.
Слышал, что гемба - хорошая практика, но не думал, что для этого нужно стоять над душой отдельного разработчика. Разве подключения к командным дейли митингам/синхро недостаточно, чтобы понять, что происходит?
Сначала нужно понять раст...
В event sourcing, если брокер сохранил событие - система считает, что оно было, рано или поздно его эффекты распространятся на все производные БД, а в случае сбоев его можно повторно прочитать из лога событий, и таким образом восстановить состояние БД (это автоматически происходит). Если брокер не сохранил - значит и не было события, и БД его эффектов видеть не может. Обычно используется kafka, которая является не совсем брокером, а распределённым логом событий, своего рода БД, и хранит события "вечно".
По этой идее, даже при сбоях состояние БД должно автоматически синхронизироваться с потоком событий. А если какая-то аномалия (состояние не синхронизировалось правильно) - нужно перезапускать построение БД с начала или со снэпшота.
Где пропало сообщение, где что-то пошло не так - это ищется по логам сервисов, распределённой трассировкой и т.п. сложными способами. Но в этом подходе событие, будучи записанным на диск, не пропадает, а вот его эффекты могут появляться не сразу, и даже иногда временно исчезать (например при перестроении БД после сбоя, при котором БД была утеряна).
Версионность/бэкапы, например.
Я как-то хотел сделать табличку "похмелье в зависимости от сорта винограда", но до таблички так и не дошло.
Поискал тоже - в ответе какое-то "не очень опасно, но очень опасно". Проверять я, конечно же, не буду.
Парацетамол+алкоголь - по отдельности не опасны в обычных количествах, а в сочетании убивают печень.
Какие-то теоретические соображения... Почти никто не пьёт пиво по 0.5л, коньяк по 0.5л, тем более вино по 0.5л! Градусы на картинке тоже какие-то рандомные, виски и коньяк не сказать чтобы отличаются по крепости.
На практике полезнее мерять алкоголь в шотах (~15-20г спирта) - так можно контролировать опьянение, зная свою дозу. Это куда полезнее, чем механически всосать 0.5 водки, а потом болеть и препараты вспоминать наутро! (но всё же не настолько полезно, как не употреблять алкоголь) И также лучше избегать определённых видов алкоголя, или ограничивать их количество в зависимости от индивидуальной переносимости (например, вино из высокотанинных сортов винограда вкусное, но способствует головной боли, так что его надо пить поменьше).
Частая причина головной боли после алкоголя - обезвоживание, поэтому употребления воды после или в процессе пьянки в принципе может быть достаточно. А баня - сомнительно.
Витамины в норме должны из еды поступать, а не таблетками по случаю алгогольного отравления. И, если вы что-то относительно разнообразное ели в последнее время (кроме водки), с витаминами должно быть всё в норме.
Типичный случай для применения CQRS - подключаем к потоку событий сервис, который их агрегирует в представление, к которому удобно делать запросы. Например, в реляционную БД.
Event sourcing как раз про то, чтобы сделать первичным источником информации не СУБД, а поток событий. Состояние БД в этом подходе вторично, это некая агрегация потока.
Да, EDA - это сложно.
Не только "у нас", это общая тенденция. Слышал, что решение - открывать ПВЗ в тех самых магазинчиках, сохраняя и традиционный магазин, и доступ к маркетплейсам.
Лет 10 назад интернет-торговля уже была достаточно развита, и сети доставки типа boxberry уже были распространены в небольших городах. Но не по 8 ПВЗ на квартал, конечно.
Это да, оффлайн-"бутики" моего посёлка почему-то предлагают только одежду вида "нищеброд", недорогую и ужасную внешне и по качеству. А вот строительные - весьма неплохи ассортиментом.
В середине 2021 у ИТ-отрасли была репутация, что хоть уборщицей, но в ИТ-конторе - это круто.