Тут еще сильно зависит от того, что такой массив должен уметь. Вот например в php используется описанная в начале этой статьи схема со связанными списками для коллизий, но при этом хэш-таблица умеет понимать, что она "честный" индексированный массив и тогда все работает совсем по другому, ключи записываются вообще без применения хэш-функции. А все потому, что там массивы и мапы - это два в одном
Тут есть еще такой момент, что света нашего Солнца растениям слишком много и они прямо-таки вынуждены часть света отражать, а часть игнорировать, чтобы избежать перегрева. В гипотетической ситуации, в которой жизнь зародилась на краю зоны Златовласки, эффективность процесса целиком была бы сильно выше, потому что пришлось бы ловить каждую крупинку света
Конкретно пример с iPhone-Айфон решается через использование фонетического анализатора. Это тоже не панацея, он тоже ошибается, но с простыми кейсами позволяет справиться без ручного прописывания синонимов.
Также синонимы можно сделать костыльно (этот пусть тоже проходили), закидывая в документы в какое-нибудь поле а-ля synonyms список того, по чему он тоже должен находиться. Это довольно плохой путь, потому что если их много, обилие ключевых слов ломает TF/IDF алгоритмы. У нас в какой-то момент с этим произошла проблема, когда контент-редакторы стали заниматься "SEO-оптимизацией" поиска через наваливание синонимов товарам, которые хотели поднять повыше. Пришлось бить по рукам
Для системы поиска плюсов как таковых нет. Сущности отдельно обновлять мы умели уже с монолитом, а полный пролив данных гораздо удобнее делать из одного источника.
Что это дает проекту в целом и компании - совсем другая история и она сильно выходит за рамки этой темы. Там есть и плюсы и минусы и тех и других достаточно много. У меня кстати есть на эту тему немного холиварный доклад с одной региональной конференции
А вот и ответ коллег подоспел. В корзине пишут вес брутто, чтобы клиент понимал общий вес доставки. Это особенно хорошо заметно, если что-нибудь в стекле положить в корзину, там раза в два может вес расходиться с весом продукта. С молоком просто неудачный пример, потому что уменьшение упаковки всех уже достало :)
Ну вот вы самостоятельно в конце статьи и пришли к объяснению того, почему правила все-таки нужны и почему им следуют) Программирование - это не физика, тут все от начала и до конца придумано людьми для людей и потому из любого правила можно найти исключения. Однако гипотетическая компания, в которой правила не соблюдают (потому что DRY не всегда работает) будет крайне неэффективна. Каждое решение будут обсуждать. Как по мне, лучше смириться с тем, что некоторая часть задач делается планово неоптимально, но зато работа ведется единообразно и предсказуемо. Да, разумеется, часть правил будут грубо нарушаться, когда возникает острая необходимость. Это можно сравнить с законами в государстве (кстати, внезапно, совершенно в любом, а не только в "недемократическом") - они постулируются как обязательные, но когда очень надо, само правительство их и нарушает. И так получается все равно лучше, чем тотальное беззаконие.
Всегда приятно прочесть статью про реальный сектор. Как глоток свежего воздуха, спасибо! Пока читал, возник вопрос: внутрь Земли тоже нельзя заглянуть, но тем не менее ученые достоверно знают ее строение: где какие слои, какие жидкие, какие металлические, тк изучают недра сейсмическими методами. Не было мысли "прозванивать" печь и смотреть на то как меняются характеристики сигнала?
Недавно была целая встреча, посвященная этой теме в контексте PHP. Как раз разбирали разные подходы к организации файлов в проекте и провели дискуссию об их качествах. Если кому интересно, то вот видео: youtu.be/mZeQ-MGTsJk
Для себя сделал вывод, что package-by-feature хорошо подойдет для работы с большими монолитами, где много доменов. Вместе с тем, микросервис, у которого домен один наверное проще будет написать по «стандартной» схеме.
Собственно доведенная до абсолюта схема с разделением по доменам, позволяет одним легким движением вырезать домен в отдельный микросервис и поменять реализацию интерфейсов по взаимодействию с ним на сетевое общение. И это плюс, потому что из монолита, структурированного по package-by-type сложно вырезать сервис, если его функциональность размазана по всему проекту.
Ожидал аналитики со статистикой, CR вакансий с зарплатой / без и тому подобного. А в итоге плохо отформатированный поток рассуждений с абзацами как в "Войне и Мире". И странные расчеты с синьорами за 800 рублей в час.
И да, по форме я со статьей согласен; проблема есть. Вот только все это можно было написать короче и проще. Это частный случай асимметрии информации: компании рассчитывают, что издержки от отпугивания некоторых кандидатов окажутся ниже выгод в виде экономии на ФОТ. Понять так это или нет невозможно, когда в качестве измерения приводятся сугубо умозрительные расчеты, где абстрактные часы собеседований умножаются на абстрактные 800 руб/час. Поэтому ценность аналитики в статье очень сомнительна.
Тем более удивительно, что статья залайкана. Видимо просто у многих горит от того как выглядит рынок вакансий.
Ох уже эти парсеры. В свое время особо рьяным роботам в ответе на HTTP запрос возвращали предложение обратиться с официальным запросом на email@company.com и получить регулярно обновляющийся полный товарный фид в формате XML. Но нет, гораздо интереснее ломиться с нагрузкой в 10х от пиковой пользовательской и вычитывать все из большой HTML портянки... Вот уж действительно, не ищем легких путей.
А разве по атрибутам не бывает фильтрации? В своем опыте столкнулись с тем, что 80% сведений о товаре пришлось держать в главном индексе, потому что по всем ним может быть применен фильтр. Там фильтры настраиваются в админке в разрезе каждой категории и у каждого свойства есть "презумпция виновности"
Аналогичную проблему решали с помощью создания "справочных" индексов. В мастер документах ссылались на id справочной сущности.
Только не делали именно как в статье, справочные индексы были загружены в память, контроль целостности ссылок был не на уровне БД, а в коде. Учитывая то, что Elastic использовался как slave хранилище, проблем не было никаких, все летало. Имхо, сама фича реализована в елке "шоб було" и в рамках идеологии инструмента не нужна.
Вообще резистентность для бактерии стоит очень дорого. Это более плотные оболочки, повышенное «энергопотребление» и тому подобное. Такие бактерии будут выбиты своими обычными собратьями в момент, потому что они крайне неэффективны и заточены под конкретную проблему.
Представьте, что вам надо сделать машину для Венеры. Там жарко, там кислота. Ваша машина будет очень тяжелой, с тремя слоями защиты, с титановыми колесами, замкнутой системой жизнеобеспечения и специальным покрытием. Никакая другая по Венере не поедет. Но на Земле такие продаваться не будут совсем, потому что она слишком дорогая и избыточная.
Популярное заблуждение, что мы выводим сверхбактерии, которые лучше обычных во всем. Не, мы выводим вот таких мутировавших неэффективных хтонических чудовищ, которые бы никогда не выжили в обычном мире и моментально выбьются более эффективными формами как только давление среды ослабнет. Бояться эпидемии таких бактерий наверное чрезмерно. А вот стать рандомной жертвой супербактерии — обидно, да
Дополняя ваш комментарий, могу сказать, что можно установить плагин EA Extended в шторме и он будет подсвечивать коллбеки, которые можно безопасно сделать статическими.
В Symfony такое, как правильно заметили выше, удобно делать через ParamConverter, типизируя в контроллере аргументы нужными Dto и регистрируя в системе ParamConverter, обрабатывающий нужный тип данных.
А в качестве непосредственно движка сериализации могу предложить jms serializer. У него довольно большой оверхед, но при этом он умеет работать с вложенными объектами, коллекциями и с его помощью можно сделать множество интересных штук: например частичная сериализация объекта, реализация своих движков (по умолчанию работает с json и xml, мы делали еще и csv) и так далее. Лучше сразу смотреть в документацию — www.jmsyst.com/libs/serializer
Тут еще сильно зависит от того, что такой массив должен уметь. Вот например в php используется описанная в начале этой статьи схема со связанными списками для коллизий, но при этом хэш-таблица умеет понимать, что она "честный" индексированный массив и тогда все работает совсем по другому, ключи записываются вообще без применения хэш-функции.
А все потому, что там массивы и мапы - это два в одном
Тут есть еще такой момент, что света нашего Солнца растениям слишком много и они прямо-таки вынуждены часть света отражать, а часть игнорировать, чтобы избежать перегрева. В гипотетической ситуации, в которой жизнь зародилась на краю зоны Златовласки, эффективность процесса целиком была бы сильно выше, потому что пришлось бы ловить каждую крупинку света
Конкретно пример с iPhone-Айфон решается через использование фонетического анализатора. Это тоже не панацея, он тоже ошибается, но с простыми кейсами позволяет справиться без ручного прописывания синонимов.
Что до синонимов, они есть в базовой коробке, можно подложить на VM с эластиком файл со списком синонимов и сослаться на него в настройках. Вот тут описано https://www.elastic.co/guide/en/elasticsearch/reference/current/analysis-synonym-tokenfilter.html#_solr_synonyms
Также синонимы можно сделать костыльно (этот пусть тоже проходили), закидывая в документы в какое-нибудь поле а-ля synonyms список того, по чему он тоже должен находиться. Это довольно плохой путь, потому что если их много, обилие ключевых слов ломает TF/IDF алгоритмы. У нас в какой-то момент с этим произошла проблема, когда контент-редакторы стали заниматься "SEO-оптимизацией" поиска через наваливание синонимов товарам, которые хотели поднять повыше. Пришлось бить по рукам
Для системы поиска плюсов как таковых нет. Сущности отдельно обновлять мы умели уже с монолитом, а полный пролив данных гораздо удобнее делать из одного источника.
Что это дает проекту в целом и компании - совсем другая история и она сильно выходит за рамки этой темы. Там есть и плюсы и минусы и тех и других достаточно много.
У меня кстати есть на эту тему немного холиварный доклад с одной региональной конференции
А вот и ответ коллег подоспел. В корзине пишут вес брутто, чтобы клиент понимал общий вес доставки. Это особенно хорошо заметно, если что-нибудь в стекле положить в корзину, там раза в два может вес расходиться с весом продукта.
С молоком просто неудачный пример, потому что уменьшение упаковки всех уже достало :)
Вообще там цена стоит "р/шт", а не "р/кг". Но да, странно, что в корзине выводится килограмм. Посмотрим, спасибо за внимательность!
У вас он еще и некорректный, потому что если числа повторяются, список никогда не отсортируется :)
Ну вот вы самостоятельно в конце статьи и пришли к объяснению того, почему правила все-таки нужны и почему им следуют) Программирование - это не физика, тут все от начала и до конца придумано людьми для людей и потому из любого правила можно найти исключения. Однако гипотетическая компания, в которой правила не соблюдают (потому что DRY не всегда работает) будет крайне неэффективна. Каждое решение будут обсуждать.
Как по мне, лучше смириться с тем, что некоторая часть задач делается планово неоптимально, но зато работа ведется единообразно и предсказуемо. Да, разумеется, часть правил будут грубо нарушаться, когда возникает острая необходимость. Это можно сравнить с законами в государстве (кстати, внезапно, совершенно в любом, а не только в "недемократическом") - они постулируются как обязательные, но когда очень надо, само правительство их и нарушает. И так получается все равно лучше, чем тотальное беззаконие.
Спасибо за подробный ответ. Буду ждать новых публикаций!
Всегда приятно прочесть статью про реальный сектор. Как глоток свежего воздуха, спасибо!
Пока читал, возник вопрос: внутрь Земли тоже нельзя заглянуть, но тем не менее ученые достоверно знают ее строение: где какие слои, какие жидкие, какие металлические, тк изучают недра сейсмическими методами. Не было мысли "прозванивать" печь и смотреть на то как меняются характеристики сигнала?
Для себя сделал вывод, что package-by-feature хорошо подойдет для работы с большими монолитами, где много доменов. Вместе с тем, микросервис, у которого домен один наверное проще будет написать по «стандартной» схеме.
Собственно доведенная до абсолюта схема с разделением по доменам, позволяет одним легким движением вырезать домен в отдельный микросервис и поменять реализацию интерфейсов по взаимодействию с ним на сетевое общение. И это плюс, потому что из монолита, структурированного по package-by-type сложно вырезать сервис, если его функциональность размазана по всему проекту.
Одно время на ТЖ жаловались, что дневники трат оккупировали IT специалисты. Видимо их оттуда повыгоняли и приходится писать тут
Ожидал аналитики со статистикой, CR вакансий с зарплатой / без и тому подобного. А в итоге плохо отформатированный поток рассуждений с абзацами как в "Войне и Мире". И странные расчеты с синьорами за 800 рублей в час.
И да, по форме я со статьей согласен; проблема есть. Вот только все это можно было написать короче и проще. Это частный случай асимметрии информации: компании рассчитывают, что издержки от отпугивания некоторых кандидатов окажутся ниже выгод в виде экономии на ФОТ. Понять так это или нет невозможно, когда в качестве измерения приводятся сугубо умозрительные расчеты, где абстрактные часы собеседований умножаются на абстрактные 800 руб/час. Поэтому ценность аналитики в статье очень сомнительна.
Тем более удивительно, что статья залайкана. Видимо просто у многих горит от того как выглядит рынок вакансий.
Ох уже эти парсеры. В свое время особо рьяным роботам в ответе на HTTP запрос возвращали предложение обратиться с официальным запросом на email@company.com и получить регулярно обновляющийся полный товарный фид в формате XML. Но нет, гораздо интереснее ломиться с нагрузкой в 10х от пиковой пользовательской и вычитывать все из большой HTML портянки...
Вот уж действительно, не ищем легких путей.
>> на лету актуализируем цены товаров
Значит ли это, что теоретически при сортировке по цене порядок может сбиться на стадии актуализации?
А разве по атрибутам не бывает фильтрации? В своем опыте столкнулись с тем, что 80% сведений о товаре пришлось держать в главном индексе, потому что по всем ним может быть применен фильтр. Там фильтры настраиваются в админке в разрезе каждой категории и у каждого свойства есть "презумпция виновности"
Аналогичную проблему решали с помощью создания "справочных" индексов. В мастер документах ссылались на id справочной сущности.
Только не делали именно как в статье, справочные индексы были загружены в память, контроль целостности ссылок был не на уровне БД, а в коде. Учитывая то, что Elastic использовался как slave хранилище, проблем не было никаких, все летало. Имхо, сама фича реализована в елке "шоб було" и в рамках идеологии инструмента не нужна.
Представьте, что вам надо сделать машину для Венеры. Там жарко, там кислота. Ваша машина будет очень тяжелой, с тремя слоями защиты, с титановыми колесами, замкнутой системой жизнеобеспечения и специальным покрытием. Никакая другая по Венере не поедет. Но на Земле такие продаваться не будут совсем, потому что она слишком дорогая и избыточная.
Популярное заблуждение, что мы выводим сверхбактерии, которые лучше обычных во всем. Не, мы выводим вот таких мутировавших неэффективных хтонических чудовищ, которые бы никогда не выжили в обычном мире и моментально выбьются более эффективными формами как только давление среды ослабнет. Бояться эпидемии таких бактерий наверное чрезмерно. А вот стать рандомной жертвой супербактерии — обидно, да
А в качестве непосредственно движка сериализации могу предложить jms serializer. У него довольно большой оверхед, но при этом он умеет работать с вложенными объектами, коллекциями и с его помощью можно сделать множество интересных штук: например частичная сериализация объекта, реализация своих движков (по умолчанию работает с json и xml, мы делали еще и csv) и так далее. Лучше сразу смотреть в документацию — www.jmsyst.com/libs/serializer