Это его последний срок, а VAT сложен в администрировании. Возможность его введения обсуждается давно, в том числе проводится ревью в книге из моего комментария выше, но основное препятствие - как раз сложность.
Не совсем понял, как усложнение задачи ведёт к её решению? Как можно апеллировать к НДФЛ Швеции, если в ЕС есть страны с 10% НДФЛ, а в США штаты с ~50%.
Давайте проведём простой мысленный эксперимент. Представьте, что Трамп ввёл не пошлины, а НДС. То есть технически, все импортируемые в США товары стали на 20% дороже. По вашему мнению, причин для возмущения нет, ведь для НДС работает "правило шведского НДФЛ". Тогда почему возмущаются пошлинами в таком же размере, ведь математически расходы идентичны?
Мне кажется, что через НДФЛ вы встали на дискурс потребителя. И с этой точки зрения НДС - это всегда зло, поскольку он его основной плательщик. Но этот налог стимулирует экспорт и защищает от импорта. Он выгоден для тех, кто создаёт максимальную добавленную стоимость на своей территории, то есть для производства. Вы не платите НДС при экспорте, но зачитываете входящий НДС затраченный на производство экспортируемых продуктов.
Трамп непосредственно артикулирует к внешнеторговому балансу и хочет из страны-потребителя сделать страну-производителя. Оперативно ввести VAT он не может, поэтому приходиться его симулировать через тарифную политику, как в мысленном эксперименте выше.
Я полагаю а тезисе про НДС речь идёт и о том, что для конечного потребителя в США европейские машины не облагаются, в то время как Американские в Европе - да.
Мне кажется это вы перепутали "эволюцию" и "теорию эволюции Дарвина". На всякий случай напомню, что речь шла о "человеке, который будет уметь отбрасывать информационный шум и не вестись на простые ответы без самостоятельного вхождения в контекст". Вы уверены, что для этого нужны генетические мутации?
Увы и ах, большинство ВУЗов на самом деле полностью игнорируют вопросы композиции приложений. Учать обжигать кирпичи, но не складывать из них постройки.
Как можно всерьёз воспринимать статью про SOLID, в которой слово тест упоминается... ноль раз? Даже такой маленький штрих уже кричит, что может быть больше одной реализации IOrderCalculator. Более того, в TDD вы скорее всего начнёте с интерфейса, его моков и тестов ещё задолго до реализации. Аналогично ни слова по DI/IoC-контейнеры как мощные инструменты по организации слабосвязных сложных приложений.
Очевидно, что SOLID, как и подавляющее большинство существующих концепций, не идеален. Но если отбросить очевидные агрументы о том, что любой инструмент надо применять с умом, остаётся сплошная вкусовщина. Постоянная отсылка к какому-то мифическому "контексту", но ни одного примера, где следование принципам SOLID несёт очевидный вред. Фактически вся контраргументация сводится к небольшому росту количества кода. Но и это ничем не обосновано. Я могу с лёгкостью привести пример как, скажем, атомизация (SRP, ISP) классического паттерна репозиторий приводит напротив к росту повторного использования, обобщений и как итог - существенному сокращению объёма кода.
Как итог, на одну чашу весов кладётся копеечная экономия на определении интерфейсов, а с другой - качественная дизайнерская работа над определением этих самых интерфейсов, из которых потом растёт API. А в чём аргумент? Начать использовать интерфейсы, когда уже серьёзно припрёт? Где та тонкая грань, когда можно переходить на нормальный дизайн? Может в статье есть метрики, как сильно описание интерфейсов усложняет жизнь?
Поддерживаю предыдущих ораторов. Сравнивать OLAP-колумнары, учитывая огромногое количество специфики, с OLTP и in memory… Автор попробовал бы поддать RPS на Clockhouse или DuckDB и сравнил бы с Redis. А почему бы и нет…
CentOS уже давно не за кем не следует, ибо закончила свой путь в 2021. В качестве альтернатив RedHat выступают AlmaLinux, RockyLinux. CentOS Stream идёт как тестовая платформа для RedHat, Fedora Server - ещё более актуальные версии и, конечно, самый свежак - Fedora Server Rawhide.
Я об этом сам случайно узнал от Миловидова в последнем Release Call 24.8. В документации или других источниках до данного момента не попадалось. Попробовал провести простой тест агрегирующей проекции в ReplacingMergeTree и всё печально... агрегат продолжает агрегировать полностью игнорируя факт replace'а))
Спасибо за статью! У проекций есть проблема с консистентностью при использовании Replacing/Collapsing/AggregatingMergeTree. В 24.8 пофиксили… ну так себе фикс, можно поставить на автоматический ребилд парта.
ну да, а миграции и генерация sql куда из orm делись? и какая разница, когда код для базы генерируется во время компиляции или во время исполнения. от этого функциональностью orm это быть не перестает.
Вы такой смысл вкладываете в определение Object Relational Mapper (ORM)? Беру вашу "функциональность orm", ищу в Википедии, на четырёх знакомых мне языках... не нахожу. В самом популярном ORM для .NET (Dapper)? Нет! Беру второй по пополуряности - EF, у них эта функциональность есть, но они открещиваются. Говорят что "data access technology" и мооооогут использоваться как ORM, даже перечисляя что они под этим подразумевают. Без труда могу ещё немало примеров примеров привести. Я даже в Google Scholar заглянул, думал может там какое веяние. Так где мне найти это новое определение ORM, чтобы какой-то смысл в нашем разговоре вообще был?
то есть качество того, что он генерирует не оценить. придется верить на слово.
С верой в генерацию LINQ-to-SQL - к Microsoft. Откройте для себя метод ToQueryString. Можете у них провести и ревью Blazor. Его мы сейчас ещё активней используем для генерации SQL. А всевозможные обвязки мы пишем также как и вы свой "никто не мешает использовать в приложении raw sql", в качество которого мне остаётся только верить.
мы видимо разные абзацы читаем
Вы не можете по своей ссылке в первом абзаце найти слово "орм" во фразе:
Да это и современные орм умеют делать полностью прозрачно. Некоторые даже могут обновлять данные не выбирая их на клиента, там где сценарий позволяет.
Спасибо за дискуссию, но на этом её стоит завершить.
Тогда это как раз получается orm, который умеет компилироваться в хранимки. Если не секрет, что за продукт?
ORM работает только когда маппит объекты в параметры хранимки и возвращённые ими рекордсеты обратно в объекты. Билд-тайм генерация хранимок со всеми теми обвзяками, которые я озвучил и деплойментом никаким боком к ORM не относится. Продукт внутренний.
Там не было ни слова про orm, никто не мешает использовать в приложении raw sql.
Прочитайте первый же абзац по своей же аргументационной ссылке. Он там на 2/3 посвящён ORM.
Что мне делать с агрументом "никто не мешает"? Если вы работаете в команде и у вас есть нормальные DBA/DBD, то они вам помешают. Поскольку у них нет ни малейшего желания продираться через заросли бэкенд-кода. Если вы работаете в одиночку, то никто не мешает затащить в код, скажем, HTML, CSS, JS заодно. И в целом использовать любые, самые худшие практики.
Генерируется код хранимок или хранимки из linq вызываются?
Генерируется код хранимок, добавляя по пути всевозможные обвязки (валидация, авторизация, профайлинг, трейсинг и прочие "separated concerns" в зависимости от ситуации).
Как уже отмечали, это не относится к теме использования или не использования хранимок.
Ссылка на комментарий, где вся аналитика сводится к функции max(...)? Это шутка? Замените max(…) на max(…) OVER (PARTITION BY ...), посмотрите как в наиболее популярных ORM это будет выглядеть и ваша карета превращается в тыкву, поскольку вы либо мешаете SQL с кодом ORM, получая уродство. Либо тащите весь рекордстет, чтобы его партиционировать руками и вернуть на порядки меньше строчек. Уродство плюс сильный оверхед по ресурсам. Я уж не говорю, как это любят СУБД-блокировочники. Это и есть то, о чём я говорил.
Аргумент в том треде - антипаттерн по своей природе. Какие-то "современные ORM" имеют какие-то "дополнительные функции". Какие ORM? Какие функции? Почему ORM должны иметь эти функции? ORM - это маппинг по определению. Точка. Как только кто-то начинает на него возлагать больше функций нужно сразу задаться вопросом, а где предел? Вы хотите в каждую ORM на каждом языке программирования втащить пародию на SQL?
Хранимые процедуры замечательно тестируются, отлично оптимизируются. В задачах, для которых они предназначены, нет ни одного ЯВУ, который был бы более выразителен. Добавляют ещё один уровень безопасности, полностью скрывая реальные структуры данных, полиморфны, можно легко добавить трейсинг, профайлинг и т.п., прекрасно мигрируют на другую СУБД даже без ребилда и деплоя приложений, можно без труда реализовать поддержку множества СУБД, классно помогают в скейлинге/миграции схемы когда нужно осуществить плавную трансформацию в фоне петабайтов данных и временно спрятать её за вызовом хранимки. У нас замечательно и из Linq генерируются хранимки. А вот за что точно надо отрывать руки - это когда противники хранимок гоняют гигабайты данных туда-сюда, пропуская их через лес уродливого кода, для работы в таком ключе вообще не приспособленного))
Констрейнты, которыми вы так кичитесь, относятся преимущественно к 2D и решаются накатыванием плагина вроде CAD Sketcher. Просто 2D в CGI обычно развивалось по остаточному принципу. А вот зависимостей более высокого уровня вроде арматур, ригов, геометрических нод и в целом программного API для их написания вроде Constrains API (https://docs.blender.org/api/current/bpy.types.Constraint.html) днём с огнём не найдёшь. Я один раз пытался написать кастомный констрейнт для AutoCad и жто была адская боль. А про CADы начального уровня и уж тем более бесплатные я вообще молчу. Сделайте в каком-нибудь TinkerCAD цепь для велика с передачами вроде такой https://www.youtube.com/shorts/U4WEt8BqniQ и после этого будете щеки раздувать. Давайте лучше челлендж устроим. Вы мне задачку для Blender, я вам для... что вы там используете? Ворованный AutoCAD/SolidWorks?
Текущий проект на 300М пользователей, порядка 50М финансовых транзакций ежедневно, тысячи юнит-тестов, е2e, включая горячо любимые стейкхолдерами executable specifications на Gherkin. Тестеров нет вообще, техническая команда 3.5 землекопа. Каждый раз читая критику тестирования всё пытаюсь понять, что мы делаем не так.
Вы же понимаете о каком рынке идёт речь в статье или автоматический рефлекс на слово "конструктор"? 90% сидит на ломаном 3DStudio MAX или SketchUp разного уровня купленности, они даже относительные эконом-варианты по подписке вроде Fusion 360 или Shapr3D редко рассматривают.
Строительные компании которые могут себе позволить купить AutoCad, Revit and Co и погрузить своих сотрудников в сладостный мир BIM на месяцы и годы - единицы. Даже с такими, казалось бы, примитивными вещами как корпусная мебель люди идут не в САПР, а возьмут Pro100... и ведь работает. К слову, очень часто слышал подобные комментарии от людей, сидящих на ломаном SolidWorks.
Реалии этого мира в том, что приходит очередной опытный конструктор и от сложности модели даже простой квартиры со всем нюансами покрытий, коммуникаций, мебели и т.п. он просто плывёт.
И вот на этом рынке Blender с каждым днём выглядит всё интереснее. Его проблема исключительно в образовательных материалах и наработках, а не возможностях. Поэтому через вас и проходили результаты низкого качества и поэтому подобные книги возможны и важны. Например, констрейнты есть, а роликов с их применением в ютубе - 0.1%.
Я одному стартапу сейчас помогаю с разработкой библиотеки "geometry nodes" для конструирования мебели. Это парадигма в которой вы работаете практически с бизнес-моделью, которая математически переводится в 3D-объекты и операции. Отсюда математическая же точность, потрясающий коэффициент повторного использования, в результате которой я могу получит как качественный рендеринг (включая анимацию дверей с включением подсветки и т.п.), так и полную карту раскроя, смету и т.п. И всё это через встроенный Python общается с Web API, загружая/отправляя данные на сервер.
Так что пока одни надувают щёки, другие спокойно переводят STL экспортированные из Blender на 3D-принтерах, CNC-фрезерах в реальные продукты))
И соглашусь с вашим тезисом про "Всё в одном". Даже если инструмент слабоват в решении конструкторских задач, но вы его используете постоянно для других (сводите домашние видео, делаете презентации и прочий сторителлинг, изучаете программирование, GFX, дизайните одежду, применений миллион), то получите позитивный эффект от этого кумулятивного опыта.
Это его последний срок, а VAT сложен в администрировании. Возможность его введения обсуждается давно, в том числе проводится ревью в книге из моего комментария выше, но основное препятствие - как раз сложность.
Не совсем понял, как усложнение задачи ведёт к её решению? Как можно апеллировать к НДФЛ Швеции, если в ЕС есть страны с 10% НДФЛ, а в США штаты с ~50%.
Давайте проведём простой мысленный эксперимент. Представьте, что Трамп ввёл не пошлины, а НДС. То есть технически, все импортируемые в США товары стали на 20% дороже. По вашему мнению, причин для возмущения нет, ведь для НДС работает "правило шведского НДФЛ". Тогда почему возмущаются пошлинами в таком же размере, ведь математически расходы идентичны?
Мне кажется, что через НДФЛ вы встали на дискурс потребителя. И с этой точки зрения НДС - это всегда зло, поскольку он его основной плательщик. Но этот налог стимулирует экспорт и защищает от импорта. Он выгоден для тех, кто создаёт максимальную добавленную стоимость на своей территории, то есть для производства. Вы не платите НДС при экспорте, но зачитываете входящий НДС затраченный на производство экспортируемых продуктов.
Трамп непосредственно артикулирует к внешнеторговому балансу и хочет из страны-потребителя сделать страну-производителя. Оперативно ввести VAT он не может, поэтому приходиться его симулировать через тарифную политику, как в мысленном эксперименте выше.
Дебаты на эту тему уже давно идут. Можно заглянуть, например, в кэмбриджский учебник Amazon.com: Value Added Tax: A Comparative Approach
Я полагаю а тезисе про НДС речь идёт и о том, что для конечного потребителя в США европейские машины не облагаются, в то время как Американские в Европе - да.
Мне кажется это вы перепутали "эволюцию" и "теорию эволюции Дарвина". На всякий случай напомню, что речь шла о "человеке, который будет уметь отбрасывать информационный шум и не вестись на простые ответы без самостоятельного вхождения в контекст". Вы уверены, что для этого нужны генетические мутации?
На примере исследований нейропластичности мозга и устройств вроде BrainPort, нужно намного меньше 50 лет, чтобы человек научился видеть языком.
Увы и ах, большинство ВУЗов на самом деле полностью игнорируют вопросы композиции приложений. Учать обжигать кирпичи, но не складывать из них постройки.
Как можно всерьёз воспринимать статью про SOLID, в которой слово тест упоминается... ноль раз? Даже такой маленький штрих уже кричит, что может быть больше одной реализации IOrderCalculator. Более того, в TDD вы скорее всего начнёте с интерфейса, его моков и тестов ещё задолго до реализации. Аналогично ни слова по DI/IoC-контейнеры как мощные инструменты по организации слабосвязных сложных приложений.
Очевидно, что SOLID, как и подавляющее большинство существующих концепций, не идеален. Но если отбросить очевидные агрументы о том, что любой инструмент надо применять с умом, остаётся сплошная вкусовщина. Постоянная отсылка к какому-то мифическому "контексту", но ни одного примера, где следование принципам SOLID несёт очевидный вред. Фактически вся контраргументация сводится к небольшому росту количества кода. Но и это ничем не обосновано. Я могу с лёгкостью привести пример как, скажем, атомизация (SRP, ISP) классического паттерна репозиторий приводит напротив к росту повторного использования, обобщений и как итог - существенному сокращению объёма кода.
Как итог, на одну чашу весов кладётся копеечная экономия на определении интерфейсов, а с другой - качественная дизайнерская работа над определением этих самых интерфейсов, из которых потом растёт API. А в чём аргумент? Начать использовать интерфейсы, когда уже серьёзно припрёт? Где та тонкая грань, когда можно переходить на нормальный дизайн? Может в статье есть метрики, как сильно описание интерфейсов усложняет жизнь?
Поддерживаю предыдущих ораторов. Сравнивать OLAP-колумнары, учитывая огромногое количество специфики, с OLTP и in memory… Автор попробовал бы поддать RPS на Clockhouse или DuckDB и сравнил бы с Redis. А почему бы и нет…
CentOS уже давно не за кем не следует, ибо закончила свой путь в 2021. В качестве альтернатив RedHat выступают AlmaLinux, RockyLinux. CentOS Stream идёт как тестовая платформа для RedHat, Fedora Server - ещё более актуальные версии и, конечно, самый свежак - Fedora Server Rawhide.
Я об этом сам случайно узнал от Миловидова в последнем Release Call 24.8. В документации или других источниках до данного момента не попадалось. Попробовал провести простой тест агрегирующей проекции в ReplacingMergeTree и всё печально... агрегат продолжает агрегировать полностью игнорируя факт replace'а))
Спасибо за статью! У проекций есть проблема с консистентностью при использовании Replacing/Collapsing/AggregatingMergeTree. В 24.8 пофиксили… ну так себе фикс, можно поставить на автоматический ребилд парта.
Вы такой смысл вкладываете в определение Object Relational Mapper (ORM)? Беру вашу "функциональность orm", ищу в Википедии, на четырёх знакомых мне языках... не нахожу. В самом популярном ORM для .NET (Dapper)? Нет! Беру второй по пополуряности - EF, у них эта функциональность есть, но они открещиваются. Говорят что "data access technology" и мооооогут использоваться как ORM, даже перечисляя что они под этим подразумевают. Без труда могу ещё немало примеров примеров привести. Я даже в Google Scholar заглянул, думал может там какое веяние. Так где мне найти это новое определение ORM, чтобы какой-то смысл в нашем разговоре вообще был?
С верой в генерацию LINQ-to-SQL - к Microsoft. Откройте для себя метод ToQueryString. Можете у них провести и ревью Blazor. Его мы сейчас ещё активней используем для генерации SQL. А всевозможные обвязки мы пишем также как и вы свой "никто не мешает использовать в приложении raw sql", в качество которого мне остаётся только верить.
Вы не можете по своей ссылке в первом абзаце найти слово "орм" во фразе:
Спасибо за дискуссию, но на этом её стоит завершить.
ORM работает только когда маппит объекты в параметры хранимки и возвращённые ими рекордсеты обратно в объекты. Билд-тайм генерация хранимок со всеми теми обвзяками, которые я озвучил и деплойментом никаким боком к ORM не относится. Продукт внутренний.
Прочитайте первый же абзац по своей же аргументационной ссылке. Он там на 2/3 посвящён ORM.
Что мне делать с агрументом "никто не мешает"? Если вы работаете в команде и у вас есть нормальные DBA/DBD, то они вам помешают. Поскольку у них нет ни малейшего желания продираться через заросли бэкенд-кода. Если вы работаете в одиночку, то никто не мешает затащить в код, скажем, HTML, CSS, JS заодно. И в целом использовать любые, самые худшие практики.
Генерируется код хранимок, добавляя по пути всевозможные обвязки (валидация, авторизация, профайлинг, трейсинг и прочие "separated concerns" в зависимости от ситуации).
Ссылка на комментарий, где вся аналитика сводится к функции max(...)? Это шутка? Замените max(…) на max(…) OVER (PARTITION BY ...), посмотрите как в наиболее популярных ORM это будет выглядеть и ваша карета превращается в тыкву, поскольку вы либо мешаете SQL с кодом ORM, получая уродство. Либо тащите весь рекордстет, чтобы его партиционировать руками и вернуть на порядки меньше строчек. Уродство плюс сильный оверхед по ресурсам. Я уж не говорю, как это любят СУБД-блокировочники. Это и есть то, о чём я говорил.
Аргумент в том треде - антипаттерн по своей природе. Какие-то "современные ORM" имеют какие-то "дополнительные функции". Какие ORM? Какие функции? Почему ORM должны иметь эти функции? ORM - это маппинг по определению. Точка. Как только кто-то начинает на него возлагать больше функций нужно сразу задаться вопросом, а где предел? Вы хотите в каждую ORM на каждом языке программирования втащить пародию на SQL?
Хранимые процедуры замечательно тестируются, отлично оптимизируются. В задачах, для которых они предназначены, нет ни одного ЯВУ, который был бы более выразителен. Добавляют ещё один уровень безопасности, полностью скрывая реальные структуры данных, полиморфны, можно легко добавить трейсинг, профайлинг и т.п., прекрасно мигрируют на другую СУБД даже без ребилда и деплоя приложений, можно без труда реализовать поддержку множества СУБД, классно помогают в скейлинге/миграции схемы когда нужно осуществить плавную трансформацию в фоне петабайтов данных и временно спрятать её за вызовом хранимки. У нас замечательно и из Linq генерируются хранимки. А вот за что точно надо отрывать руки - это когда противники хранимок гоняют гигабайты данных туда-сюда, пропуская их через лес уродливого кода, для работы в таком ключе вообще не приспособленного))
Пока доказано только то, что привести пример констрейнта вы не можете, озвучить название "нормапьного када" не можете.
Констрейнты, которыми вы так кичитесь, относятся преимущественно к 2D и решаются накатыванием плагина вроде CAD Sketcher. Просто 2D в CGI обычно развивалось по остаточному принципу. А вот зависимостей более высокого уровня вроде арматур, ригов, геометрических нод и в целом программного API для их написания вроде Constrains API (https://docs.blender.org/api/current/bpy.types.Constraint.html) днём с огнём не найдёшь. Я один раз пытался написать кастомный констрейнт для AutoCad и жто была адская боль. А про CADы начального уровня и уж тем более бесплатные я вообще молчу. Сделайте в каком-нибудь TinkerCAD цепь для велика с передачами вроде такой https://www.youtube.com/shorts/U4WEt8BqniQ и после этого будете щеки раздувать. Давайте лучше челлендж устроим. Вы мне задачку для Blender, я вам для... что вы там используете? Ворованный AutoCAD/SolidWorks?
Для дев-среды весьма логично. Интеграционные тесты могут и несколько кластеров на одной машине поднимать.
Текущий проект на 300М пользователей, порядка 50М финансовых транзакций ежедневно, тысячи юнит-тестов, е2e, включая горячо любимые стейкхолдерами executable specifications на Gherkin. Тестеров нет вообще, техническая команда 3.5 землекопа. Каждый раз читая критику тестирования всё пытаюсь понять, что мы делаем не так.
Вы же понимаете о каком рынке идёт речь в статье или автоматический рефлекс на слово "конструктор"? 90% сидит на ломаном 3DStudio MAX или SketchUp разного уровня купленности, они даже относительные эконом-варианты по подписке вроде Fusion 360 или Shapr3D редко рассматривают.
Строительные компании которые могут себе позволить купить AutoCad, Revit and Co и погрузить своих сотрудников в сладостный мир BIM на месяцы и годы - единицы. Даже с такими, казалось бы, примитивными вещами как корпусная мебель люди идут не в САПР, а возьмут Pro100... и ведь работает. К слову, очень часто слышал подобные комментарии от людей, сидящих на ломаном SolidWorks.
Реалии этого мира в том, что приходит очередной опытный конструктор и от сложности модели даже простой квартиры со всем нюансами покрытий, коммуникаций, мебели и т.п. он просто плывёт.
И вот на этом рынке Blender с каждым днём выглядит всё интереснее. Его проблема исключительно в образовательных материалах и наработках, а не возможностях. Поэтому через вас и проходили результаты низкого качества и поэтому подобные книги возможны и важны. Например, констрейнты есть, а роликов с их применением в ютубе - 0.1%.
Я одному стартапу сейчас помогаю с разработкой библиотеки "geometry nodes" для конструирования мебели. Это парадигма в которой вы работаете практически с бизнес-моделью, которая математически переводится в 3D-объекты и операции. Отсюда математическая же точность, потрясающий коэффициент повторного использования, в результате которой я могу получит как качественный рендеринг (включая анимацию дверей с включением подсветки и т.п.), так и полную карту раскроя, смету и т.п. И всё это через встроенный Python общается с Web API, загружая/отправляя данные на сервер.
Так что пока одни надувают щёки, другие спокойно переводят STL экспортированные из Blender на 3D-принтерах, CNC-фрезерах в реальные продукты))
И соглашусь с вашим тезисом про "Всё в одном". Даже если инструмент слабоват в решении конструкторских задач, но вы его используете постоянно для других (сводите домашние видео, делаете презентации и прочий сторителлинг, изучаете программирование, GFX, дизайните одежду, применений миллион), то получите позитивный эффект от этого кумулятивного опыта.