Ну вот вы самостоятельно в конце статьи и пришли к объяснению того, почему правила все-таки нужны и почему им следуют) Программирование - это не физика, тут все от начала и до конца придумано людьми для людей и потому из любого правила можно найти исключения. Однако гипотетическая компания, в которой правила не соблюдают (потому что 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
С год назад был в деливери на собеседовании и было почти как на картинках: с небенальными вопросами и интересными задачами. Воспоминания остались в целом хорошие, несмотря на то, что не договорились. Могу лишь покритиковать плохую обратную связь. Я бы хотел более развернутой, чем (скорее всего) дежурного ответа про другого кандидата
На своем опыте прочувствовал то, о чем пишет автор статьи. Часто езжу в малознакомые места по Я.Навигатору и когда на трассе собирается пробка, то навигатор предлагает ее объехать по местным дорогам. В результате чего все прилегающие к трассе с пробкой дороги намертво забиваются людьми, съехавшими с трассы. Это вредит как общей скорочти потока, так и (неизмеримо сильнее) тем, кто живет в места скопления объезжающих. Пробка распространяется вширь, а потом все те, кто объезжал, встраиваются в общий поток, замедляя его еще сильнее. Фактически это легализованные обочечники. Особенно ярко это проявляется на Ярославском шоссе. Также замечал на М7 и М9.
Как на такое поведение навигаторов повлиять непонятно. Для себя лично я решил, что если мне предлагают объехать участок длиной пару километров по частному сектору, то я останусь на трассе; при этом понятно, что найдутся те, кто все-таки поедет дворами.
Где-то видел, что для голубой карты достаточно 5 лет работы по специальности, а тут нигде не упомянуто. Врут или просто автор не задавался таким вопросом?
Спорный тезис про врача. Еще пару столетий назад врачи вредили едва ли не больше, чем приносили пользы. Где сейчас были бы врачи без людей других профессий? Где бы они были без ученых, открывших вирусы, рентген, ДНК? Без рабочих промышленности, создающих инструменты для диагностики и проведения операций, без тех же самых IT'шников, которые заставляют работать сложные аппараты и автоматизировать рутинные задачи?
Так бы и носили птичьи маски и пилили конечности, потому что хз, что еще делать с сепсисом от загрязненной раны.
Узнал автора статьи по заголовку в блоке «читают сейчас». С поправкой на эпоху, я бы назвал его труды современной версией «Героя нашего времени». Тексты читаются легко и интересно, с содержаним согласны отнюдь не все, а зеленая молодежь (да, реально знаю таких) хочет быть похожей на героя произведения.
У вас он еще и некорректный, потому что если числа повторяются, список никогда не отсортируется :)
Ну вот вы самостоятельно в конце статьи и пришли к объяснению того, почему правила все-таки нужны и почему им следуют) Программирование - это не физика, тут все от начала и до конца придумано людьми для людей и потому из любого правила можно найти исключения. Однако гипотетическая компания, в которой правила не соблюдают (потому что 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
Как на такое поведение навигаторов повлиять непонятно. Для себя лично я решил, что если мне предлагают объехать участок длиной пару километров по частному сектору, то я останусь на трассе; при этом понятно, что найдутся те, кто все-таки поедет дворами.
Так бы и носили птичьи маски и пилили конечности, потому что хз, что еще делать с сепсисом от загрязненной раны.