Daily по-русски - "планёрка". На планёрке не тратят время на то, что и так идёт хорошо, а обсуждают решения краткосрочных проблем. Выступают те, у кого эти проблемы есть или кто видит, что они они есть.
Если нужно решить проблему одноразово, то очередная модель сможет помочь, видимо. Если анализ кода включен в цепочку разработки, то проблема недетерминированности встанет в полный рост. С тем же успехом можно пытаться заменять компилятор и получать всякий раз разные результаты даже на одном и том же наборе исходников. А ведь исходники активно меняются. Также ключевым показателем будет процент ложных срабатываний, требующий участия оператора
Всё "из коробки" без дополнительных настроек, кодовая база небольшая около 100К строк, тесты делали 4 года назад. Цена разнилась, соответственно: 100 долл/год за лицензию у Сонара и до 10К у PVS
Насчет Swift ничего сказать не могу, но для Си++ SonarQube никоим образом не тянет на топовой анализатор, несмотря на генерацию массы подсказок. PVS Studio в наших тестах оказался на голову выше.
Каковы комплексные результаты сравнения со статическими анализаторами кода? Или цель была заменить классический алгоритм нейросетевым и посмотреть, что получится?
Как насчет спорта? Футбольная, волейбольная и теннисная команды - это три большие разницы. Должны ли девопс, поддержка и разработка строиться по одной модели?
Шутка не в точности распознавания, а в том, что интерфейс с кнопками гораздо человечнее. Но есть и второе видео для русскокультурных кодов "женщину вынули - автомат засунули".
Кто-то уже давал ссылку на видео голосового интерфейса лифта, одиннадцатый этаж и двух англоговорящих? Ну, а голосовые меню в поддержке по телефону - это просто ад doom всегда с прохождением уровней, но без оружия.
ООП не религия, а просто более эффективный способ структуризации и повторного использования кода, чем процедурный подход. На небольших объёмах кода эффект может быть малозаметен.
Я с вами согласен с одной поправкой на размер кодовой базы. Для встраиваемых систем она, как правила, невелика 10-100К строк кода на Си. По мере приближения к 1М становится выгодной организация кода в ООП-стиле. Кстати, накладные расходы по использованию Си++ и виртуализации не более 5-10%, мы тестировали на довольно типовом проекте эмулятора, когда новый проц гоняет старый микрокод.
Ну, и принципы SOLID они, скорее, не ООП, а здравый смысл. В Си тоже приходится передавать функциям разные типы через void*, просто в ++ этим занят компилятор.
Да, я именно "коробочные" продукты имел в виду (мало- или крупнотиражные). "Типовой" означает некую стандартную поставку, которую уже на месте подгоняют под заказчика.
Сагу можно рассматривать, как оптимистическую двухфазную фиксацию. Вообще все эти "паттерны" сводятся к двум давно известным: двухфазная фиксация и репликация транзакций
Нельзя ли выделить среди компаний т.н. вендоров (продуктовые) и технологические, т.е. не основанные на услугах или занятые внутренней автоматизацией бизнеса, а продающие тиражируемые продукты и технологии?
Open-Closed Principle изначально (лихие 1990-е) был про наследование реализации, а не интерфейсов. В типовом тиражируемом энтерпрайз-продукте продуманный и вылизанный "стандартный" класс открывается разработчикам-"конфигураторам", которые создают свои подклассы под требования конечных клиентов.
Моя цель - не спор и придирки по мелочам, наоборот, вам - благодарность за полезный обзор, который можно дополнить.
Кластерные индексы реализовала не MS, а Sybase, откуда они 30+ лет назад переехали в MSSQL. Эта опция стоит по умолчанию для всех первичных ключей. "Проблемы" с записью могут возникать при непоследовательных значениях ключей, но в реальности в 90 % будет автоинкрементный целочисленный тип. Для GUID в версии 2008 даже ввели newsequentialid. В других случаях может поможет fillfactor. Пишу "проблемы" в кавычках, потому что даже на строковых случайных значениях отставание от целочисленных порядка 30% (тест проводил для версии 2000)
Выигрыш в том, что данные лежат там же, где индекс, и нет дополнительных операций. Лет 10 назад в ФБ группе я уже постил результаты выборки строк таблицы по ключу, тогда они различались в 2 раза в пользу MS. Сейчас сходу найти не могу, повторять же нет смысла.
Я понимаю, что можно и отключить сильную сторону у "оппонента", но не уверен, что нужно это делать, тем более, что хинты в постгрес если и завезут, то очень не скоро по религиозным соображениям, а в SQL Server такое временное отключение можно прописать в запросе, не делая глобальных изменений на уровне всей БД, как это принято в постгресе.
Специально еще раз посмотрел на CLUSTER в постгресе. Это просто физическая сортировка таблицы, которую нужно принудительно повторять после каждой модификации данных. "Clustering is a one-time operation". То есть никаких кластерных индексов в постгресе до сих пор нет, и сравнивать с кластерными индексами в SQL Server просто некорректно.
Простейший CRUD-тест произвольной выборки по ключу из постгреса и SQL Server, думаю, вы и сами сможете соорудить минут за 15. Было бы желание. Всякие ORM только и заняты, что извлекают по ключу объекты из БД.
Перечитал текст, не увидел места, где "Акела промахнулся", это непринципиально, под "спотыканием на ровном месте" я вспоминаю, например, многим неизвестную необходимость полуручного обновления статистики при обработке в БД сложных данных, запуском после каждых 1000 документов.
Зато я вижу, что вы сознательно ограничили параллелизм в запросах SQL Server. Не уверен, что это правильный подход, зная, что параллелизм в Постгресе, мягко говоря, находится на начальной стадии, хотя и появился в версии 12.
По поводу кластерных ключей/индексов, почему никакого интереса? Ускорение на CRUD операциях в 1,5-2 раза, использование в аналитике также даёт преимущества, хотя там уже можно строить read-only постгресовские аналоги
Не вижу ссылки на источник :)
Daily по-русски - "планёрка". На планёрке не тратят время на то, что и так идёт хорошо, а обсуждают решения краткосрочных проблем. Выступают те, у кого эти проблемы есть или кто видит, что они они есть.
Если нужно решить проблему одноразово, то очередная модель сможет помочь, видимо. Если анализ кода включен в цепочку разработки, то проблема недетерминированности встанет в полный рост. С тем же успехом можно пытаться заменять компилятор и получать всякий раз разные результаты даже на одном и том же наборе исходников. А ведь исходники активно меняются. Также ключевым показателем будет процент ложных срабатываний, требующий участия оператора
Всё "из коробки" без дополнительных настроек, кодовая база небольшая около 100К строк, тесты делали 4 года назад. Цена разнилась, соответственно: 100 долл/год за лицензию у Сонара и до 10К у PVS
Насчет Swift ничего сказать не могу, но для Си++ SonarQube никоим образом не тянет на топовой анализатор, несмотря на генерацию массы подсказок. PVS Studio в наших тестах оказался на голову выше.
Каковы комплексные результаты сравнения со статическими анализаторами кода? Или цель была заменить классический алгоритм нейросетевым и посмотреть, что получится?
Как насчет спорта? Футбольная, волейбольная и теннисная команды - это три большие разницы. Должны ли девопс, поддержка и разработка строиться по одной модели?
Шутка не в точности распознавания, а в том, что интерфейс с кнопками гораздо человечнее. Но есть и второе видео для русскокультурных кодов "женщину вынули - автомат засунули".
Кто-то уже давал ссылку на видео голосового интерфейса лифта, одиннадцатый этаж и двух англоговорящих? Ну, а голосовые меню в поддержке по телефону - это просто
адdoom всегда с прохождением уровней, но без оружия.ООП не религия, а просто более эффективный способ структуризации и повторного использования кода, чем процедурный подход. На небольших объёмах кода эффект может быть малозаметен.
Я с вами согласен с одной поправкой на размер кодовой базы. Для встраиваемых систем она, как правила, невелика 10-100К строк кода на Си. По мере приближения к 1М становится выгодной организация кода в ООП-стиле. Кстати, накладные расходы по использованию Си++ и виртуализации не более 5-10%, мы тестировали на довольно типовом проекте эмулятора, когда новый проц гоняет старый микрокод.
Ну, и принципы SOLID они, скорее, не ООП, а здравый смысл. В Си тоже приходится передавать функциям разные типы через void*, просто в ++ этим занят компилятор.
Да, я именно "коробочные" продукты имел в виду (мало- или крупнотиражные). "Типовой" означает некую стандартную поставку, которую уже на месте подгоняют под заказчика.
Сагу можно рассматривать, как оптимистическую двухфазную фиксацию. Вообще все эти "паттерны" сводятся к двум давно известным: двухфазная фиксация и репликация транзакций
Нельзя ли выделить среди компаний т.н. вендоров (продуктовые) и технологические, т.е. не основанные на услугах или занятые внутренней автоматизацией бизнеса, а продающие тиражируемые продукты и технологии?
Почему сразу не создать тикет с формулировкой задач? Если это по каким-то причинам невозможно сделать, значит дискуссия была пустой
https://habr.com/ru/companies/postgrespro/articles/862480/comments/#comment_27737494
Open-Closed Principle изначально (лихие 1990-е) был про наследование реализации, а не интерфейсов. В типовом тиражируемом энтерпрайз-продукте продуманный и вылизанный "стандартный" класс открывается разработчикам-"конфигураторам", которые создают свои подклассы под требования конечных клиентов.
Моя цель - не спор и придирки по мелочам, наоборот, вам - благодарность за полезный обзор, который можно дополнить.
Кластерные индексы реализовала не MS, а Sybase, откуда они 30+ лет назад переехали в MSSQL. Эта опция стоит по умолчанию для всех первичных ключей. "Проблемы" с записью могут возникать при непоследовательных значениях ключей, но в реальности в 90 % будет автоинкрементный целочисленный тип. Для GUID в версии 2008 даже ввели newsequentialid. В других случаях может поможет fillfactor. Пишу "проблемы" в кавычках, потому что даже на строковых случайных значениях отставание от целочисленных порядка 30% (тест проводил для версии 2000)
Выигрыш в том, что данные лежат там же, где индекс, и нет дополнительных операций. Лет 10 назад в ФБ группе я уже постил результаты выборки строк таблицы по ключу, тогда они различались в 2 раза в пользу MS. Сейчас сходу найти не могу, повторять же нет смысла.
Скажу больше, MSSQL быстрее Redis на таких операциях: https://blog.arbinada.com/category/01707-sql-server-vs-redis.html
Я понимаю, что можно и отключить сильную сторону у "оппонента", но не уверен, что нужно это делать, тем более, что хинты в постгрес если и завезут, то очень не скоро по религиозным соображениям, а в SQL Server такое временное отключение можно прописать в запросе, не делая глобальных изменений на уровне всей БД, как это принято в постгресе.
Специально еще раз посмотрел на CLUSTER в постгресе. Это просто физическая сортировка таблицы, которую нужно принудительно повторять после каждой модификации данных. "Clustering is a one-time operation". То есть никаких кластерных индексов в постгресе до сих пор нет, и сравнивать с кластерными индексами в SQL Server просто некорректно.
Простейший CRUD-тест произвольной выборки по ключу из постгреса и SQL Server, думаю, вы и сами сможете соорудить минут за 15. Было бы желание. Всякие ORM только и заняты, что извлекают по ключу объекты из БД.
Перечитал текст, не увидел места, где "Акела промахнулся", это непринципиально, под "спотыканием на ровном месте" я вспоминаю, например, многим неизвестную необходимость полуручного обновления статистики при обработке в БД сложных данных, запуском после каждых 1000 документов.
Зато я вижу, что вы сознательно ограничили параллелизм в запросах SQL Server. Не уверен, что это правильный подход, зная, что параллелизм в Постгресе, мягко говоря, находится на начальной стадии, хотя и появился в версии 12.
По поводу кластерных ключей/индексов, почему никакого интереса? Ускорение на CRUD операциях в 1,5-2 раза, использование в аналитике также даёт преимущества, хотя там уже можно строить read-only постгресовские аналоги