Если у вас в программе захардкожен доступ по конкретному полю мапы
У меня – не захардкожен. Ибо я мапы использую по прямому назначению – ни в коем случае не как замену фиксированным структурам. Если ещё точнее – мои программисты так делают, а я только отслеживаю, чтобы не хулиганили 🙂
Вы пропустили тот здоровенный кусок в тексте, в котором я говорил про теги, да?
Не пропустил, но как и, подозреваю, большинство читателей, я не имею никакого отношения к эрлангу, и скорее всего, никогда иметь не буду.
Ну так в нормальных языках доступ к полям мапы так и осуществляется, привет.
Вы что-то путаете. Map во всех её разновидностях – структура ключ-значение, которая заполняется в рантайме и на этапе компиляции/статического анализа не проверяема.
зачем нам лишняя когнитивная нагрузка в виде объектов?
Нам нужно уменьшение когнитивной нагрузки и автоматическая верификация кода. Например, если у меня есть класс
User {int id; String name;}
то опечатка user.mane будет обнаружена ещё при написании кода, средствами IDE. В то время как если это мапа, то user['mane'] IDE проглотит не задумываясь. А ещё хуже, если кто-то сделает такую опечатку в данных самого юзера – и этот объект пойдёт гулять по коду, который ждёт поле name.
Иными словами, объекты с методами и инкапсуляцией — лишняя и ненужная абстракция
Семантическая прозрачность весьма важна при написании кода. Если я вижу, что на вход поступает именно юзер, а не набитая неизвестно чем мапа, мне нужно гораздо меньше думать.
Затем, что внутри системы происходит обработка данных – соответственно, либо эти JSONы меняются, либо порождают другие. В любом случае результат отличается от исходных данных и после преобразования а JSON требует валидации в точке использования.
идеальное нативное представление языка именно такое: списки, мапы и примитивы.
JSON не является ни тем, ни другим, ни третьим – это просто строка. Соответственно:
Если делать что-то ненужное (как, например, создавать какие-то там объекты вместо готовых
Если обмен данных между модулями системы построен на передаче JSON, никаких готовых объектов нет – есть их строковое представление, которое нужно преобразовывать туда и обратно. Именно это и есть ненужная работа.
Строгая типизация — это то немногое, что функциональщики смогли продать объективистам.
Дочитал до этого места и несколько подвис. Вообще-то ООП – это изначально именно про типы, ничего тут "продавать" не нужно, и никакая функциональщина вообще ни при чём. Объектные языки с динамической типизацией – строго говоря, отход от канона и довольно серьёзный компромисс.
В конце концов, мы же как-то обходимся джейсоном для передачи «объектов» туда-сюда?
Обходимся – если других вариантов нет. А вот проектировать систему, повсюду гоняющую внутри туда-сюда JSONы я бы точно не стал. Хотя бы потому, что их нужно валидировать передкаждымиспользованием. Полноценно так валидировать: структуру, соответствие типов каждого поля, всё вот это вот. И конечно, каждый раз эти данные преобразовывать в нативное представление языка – дабы ими было можно как-то манипулировать. А потом обратно в JSON – чтобы передать дальше или вернуть результат. Что сразу привносит совершенно чудовищные накладные расходы, да и код прилично замусоривает.
Я в своё время отказался строить ядро системы на стороннем фреймворке по трём причинам:
Много лишнего. Универсальные фреймворки пытаются удовлетворить всех и каждого, в результате приходится тянуть в проект массу фич, которые никогда не будут использоваться.
Скорость. В значительной степени следствие предыдущего пункта: универсальность тянет за собой множество слоёв абстракций, что с высокой вероятностью приведёт к снижению производительности в высоконагруженных системах (у меня как раз такая).
Безопасность. При всём том, что над ней работают профессионалы высокого класса, атаки на популярные фреймворки разрабатывают профессионалы ничуть не худшие, потом эксплойты быстро становятся общедоступными и активно используются. Постоянно фиксирую попытки проникновения через известные уязвимости – которые благодаря использованию кастомного решения ни к чему не приводят.
Пока (15+ лет) не пожалел – всё работает, требует минимального обслуживания, производительность удовлетворительная, безопасность тоже.
Но разумеется, такой подход целесообразен только в больших, долгосрочных проектах.
Так я вроде не Вам отвечал. И когда писал, рассчитывал на ответ (если он будет) по обсуждаемой теме. Которой и призываю придерживаться – по-моему, как раз уведение дискуссии в сторону и есть не лучший стиль.
Не понял, при чём тут это вообще. Речь была о том, что требование повсеместной асинхронности API скорее приведёт к деградации производительности, нежели к её повышению – не говоря уж о том, что во многих случаях это тупо неудобно. По этому вопросу есть, что возразить?
Какая разница? Там или тут, требование делать API исключительно асинхронным подразумевает появление запросов для считывания результата. Соответственно, как минимум удвоение их количества. И кстати уж, не припомню, чтобы в статье оговаривались рамки применимости публичный/внутренний.
так и представил матюки фронтэндера, когда я ему предложу для проверки того, что смена имени юзера прошла успешно, вызывать еще один метод в цикле, пока он не вернет "успешно"....
Да, мне тоже глаз резануло. Асинхрон хорош в сочетании с реактивностью, или когда ответ вообще не интересен (логи, статистика...). А позиционировать решение, подразумевающее как минимум двукратное (а то и трёх-пятикратное) увеличение количества запросов, как средство повышения производительности системы – ну как минимум, спорно.
Тем не менее, присутствие этой информации для конкретного приложения дает понять, что оно установлено
Ага, только для того, что эту информацию прочитать, нужно залезть в .arb этого приложения – что довольно проблематично, не зная заранее, что оно установлено.
Паранойя – штука полезная, но прежде, чем публиковать такие пугалки, хорошо бы хоть на базовом уровне понимать, о чём пишешь.
Я не специалист в разработке для Android, но насколько понимаю, фильтр ACTION_MAIN в показанной выше конфигурации разрешает просматривать все установленные приложения, которые, если упростить, имеют доступ к экрану.
Вот очень заметно, что не специалист 😁
MAIN means that this activity is the entry point of the application, i.e. when you launch the application, this activity is created.
Это просто информация о точке входа в данное приложение для лаунчера, всё.
Тут согласен. Но тогда и статья должна быть совсем о другом: Микросервисы как лекарство от склероза и разгильдяйства. Дарю название. Однако:
Как только команда, разрабатывающая "монолит", начинает придерживаться принципов хорошего проектирования, она получает все описанные в статье преимущества МС без необходимости усложнения инфраструктуры;
Если трансформировать пропагандируемый свидетелями МС подход "один микросервис – одна команда" в "один бизнес-модуль – одна команда", то неожиданно получится ровно тот же уровень декомпозиции: каждая команда пишет своё, руководствуясь только спецификацией и не оглядываясь на других. Правда, так очень редко делают – просто в силу нерациональности. Гораздо эффективнее иметь некое общее ядро, а не заставлять каждую команду реализовывать одно и то же по-своему.
Необходима чёткая декомпозиция системы на модули с отдельными бизнес-областями.
Простите, очевидно, подразумевается, что в "монолите" это не нужно? Я бы поспорил. А как только мы грамотно поделили "монолит" (кавычки не случайны) на бизнес-сущности, взаимодействующие через стандартизованные интерфейсы – сразу появляются и возможности независимой разработки, изолированного внесения изменений, бесшовного (за счёт изменения конфигов) подключения специфичных для конкретного заказчика модулей и вообще буквально все те плюшки, которыми так гордятся МС. При отсутствии необходимости городить сложную инфраструктуру оркестрации внутрисистемного взаимодействия.
Не нужно сравнивать МС с плохо спроектированными "монолитами" – сравнивайте с хорошими. И может быть, тогда всё будет выглядеть менее благостно.
Электроника сейчас весьма дешёвая и доступная. Не может зарядка стоить дороже аккумулятора.
Боюсь, Вы не вполне представляете себе, о чём речь. То, что я видел, было силовым агрегатом размером чуть ли не полметра по каждой стороне и весом килограмм 30-40. Поставить себе такое могут именно что "отдельные любители", независимо от эффективности.
У меня – не захардкожен. Ибо я мапы использую по прямому назначению – ни в коем случае не как замену фиксированным структурам. Если ещё точнее – мои программисты так делают, а я только отслеживаю, чтобы не хулиганили 🙂
Не пропустил, но как и, подозреваю, большинство читателей, я не имею никакого отношения к эрлангу, и скорее всего, никогда иметь не буду.
Вы что-то путаете. Map во всех её разновидностях – структура ключ-значение, которая заполняется в рантайме и на этапе компиляции/статического анализа не проверяема.
Нам нужно уменьшение когнитивной нагрузки и автоматическая верификация кода. Например, если у меня есть класс
то опечатка
user.maneбудет обнаружена ещё при написании кода, средствами IDE. В то время как если это мапа, тоuser['mane']IDE проглотит не задумываясь. А ещё хуже, если кто-то сделает такую опечатку в данных самого юзера – и этот объект пойдёт гулять по коду, который ждёт полеname.Семантическая прозрачность весьма важна при написании кода. Если я вижу, что на вход поступает именно юзер, а не набитая неизвестно чем мапа, мне нужно гораздо меньше думать.
Затем, что внутри системы происходит обработка данных – соответственно, либо эти JSONы меняются, либо порождают другие. В любом случае результат отличается от исходных данных и после преобразования а JSON требует валидации в точке использования.
JSON не является ни тем, ни другим, ни третьим – это просто строка. Соответственно:
Если обмен данных между модулями системы построен на передаче JSON, никаких готовых объектов нет – есть их строковое представление, которое нужно преобразовывать туда и обратно. Именно это и есть ненужная работа.
А что мешает его получить?
Есть подтверждающие это метрики? За КМР не скажу, не пользовался, но у флаттера нет проблем со скоростью – благо он компилится в нативный код.
Конкретно, с какими?
Дочитал до этого места и несколько подвис. Вообще-то ООП – это изначально именно про типы, ничего тут "продавать" не нужно, и никакая функциональщина вообще ни при чём. Объектные языки с динамической типизацией – строго говоря, отход от канона и довольно серьёзный компромисс.
Обходимся – если других вариантов нет. А вот проектировать систему, повсюду гоняющую внутри туда-сюда JSONы я бы точно не стал. Хотя бы потому, что их нужно валидировать перед каждым использованием. Полноценно так валидировать: структуру, соответствие типов каждого поля, всё вот это вот. И конечно, каждый раз эти данные преобразовывать в нативное представление языка – дабы ими было можно как-то манипулировать. А потом обратно в JSON – чтобы передать дальше или вернуть результат. Что сразу привносит совершенно чудовищные накладные расходы, да и код прилично замусоривает.
Я в своё время отказался строить ядро системы на стороннем фреймворке по трём причинам:
Много лишнего. Универсальные фреймворки пытаются удовлетворить всех и каждого, в результате приходится тянуть в проект массу фич, которые никогда не будут использоваться.
Скорость. В значительной степени следствие предыдущего пункта: универсальность тянет за собой множество слоёв абстракций, что с высокой вероятностью приведёт к снижению производительности в высоконагруженных системах (у меня как раз такая).
Безопасность. При всём том, что над ней работают профессионалы высокого класса, атаки на популярные фреймворки разрабатывают профессионалы ничуть не худшие, потом эксплойты быстро становятся общедоступными и активно используются. Постоянно фиксирую попытки проникновения через известные уязвимости – которые благодаря использованию кастомного решения ни к чему не приводят.
Пока (15+ лет) не пожалел – всё работает, требует минимального обслуживания, производительность удовлетворительная, безопасность тоже.
Но разумеется, такой подход целесообразен только в больших, долгосрочных проектах.
Так я вроде не Вам отвечал. И когда писал, рассчитывал на ответ (если он будет) по обсуждаемой теме. Которой и призываю придерживаться – по-моему, как раз уведение дискуссии в сторону и есть не лучший стиль.
Не понял, при чём тут это вообще. Речь была о том, что требование повсеместной асинхронности API скорее приведёт к деградации производительности, нежели к её повышению – не говоря уж о том, что во многих случаях это тупо неудобно. По этому вопросу есть, что возразить?
Какая разница? Там или тут, требование делать API исключительно асинхронным подразумевает появление запросов для считывания результата. Соответственно, как минимум удвоение их количества. И кстати уж, не припомню, чтобы в статье оговаривались рамки применимости публичный/внутренний.
Да, мне тоже глаз резануло. Асинхрон хорош в сочетании с реактивностью, или когда ответ вообще не интересен (логи, статистика...). А позиционировать решение, подразумевающее как минимум двукратное (а то и трёх-пятикратное) увеличение количества запросов, как средство повышения производительности системы – ну как минимум, спорно.
Ага, только для того, что эту информацию прочитать, нужно залезть в .arb этого приложения – что довольно проблематично, не зная заранее, что оно установлено.
Паранойя – штука полезная, но прежде, чем публиковать такие пугалки, хорошо бы хоть на базовом уровне понимать, о чём пишешь.
Вот очень заметно, что не специалист 😁
Это просто информация о точке входа в данное приложение для лаунчера, всё.
<grammar-nazi
API – он. Как кофе.
grammar-nazi/>
Тут согласен. Но тогда и статья должна быть совсем о другом: Микросервисы как лекарство от склероза и разгильдяйства. Дарю название. Однако:
Как только команда, разрабатывающая "монолит", начинает придерживаться принципов хорошего проектирования, она получает все описанные в статье преимущества МС без необходимости усложнения инфраструктуры;
Если трансформировать пропагандируемый свидетелями МС подход "один микросервис – одна команда" в "один бизнес-модуль – одна команда", то неожиданно получится ровно тот же уровень декомпозиции: каждая команда пишет своё, руководствуясь только спецификацией и не оглядываясь на других. Правда, так очень редко делают – просто в силу нерациональности. Гораздо эффективнее иметь некое общее ядро, а не заставлять каждую команду реализовывать одно и то же по-своему.
Простите, очевидно, подразумевается, что в "монолите" это не нужно? Я бы поспорил. А как только мы грамотно поделили "монолит" (кавычки не случайны) на бизнес-сущности, взаимодействующие через стандартизованные интерфейсы – сразу появляются и возможности независимой разработки, изолированного внесения изменений, бесшовного (за счёт изменения конфигов) подключения специфичных для конкретного заказчика модулей и вообще буквально все те плюшки, которыми так гордятся МС. При отсутствии необходимости городить сложную инфраструктуру оркестрации внутрисистемного взаимодействия.
Не нужно сравнивать МС с плохо спроектированными "монолитами" – сравнивайте с хорошими. И может быть, тогда всё будет выглядеть менее благостно.
Особо пикантно получить такие сведения от @TinyElectronicFriends 😁
Боюсь, Вы не вполне представляете себе, о чём речь. То, что я видел, было силовым агрегатом размером чуть ли не полметра по каждой стороне и весом килограмм 30-40. Поставить себе такое могут именно что "отдельные любители", независимо от эффективности.