Я думаю в пятом пункте речь о том, что РБД реализуют наиболее удачное сочетание гарантий и ограничений по-умолчанию, включая такие гарантии, существование которых интуитивно допускается слишком многими разработчиками.
Например, многие привыкли, что БД должна поддерживать транзакционное изменение нескольких элементов данных сразу, и только потом узнают горькую правду о выбранной ими документно-ориентированной СУБД.
А вообще, это так не работает. Если архитектура призвана жрать много электричества, её будут ставить туда, где можно жрать много, и ничего за это не будет.
В телефонах ARM потому что её можно подключить к аккумулятору, и она всегда будет там лучше, чем x86.
Раз вы задаёте этот вопрос, значит вы используете подход "отдельная директория для public хедеров", как и в этой статье. Ну т.е. когда все публичные заголовочные файлы физически перемещаются в отдельную директорию.
В их папках обычно не создаётся CMakeLists просто потому, что с ними особо нечего делать, кроме как скопировать на этапе install (лично я советую делать это и на этапе сборки, особенно если есть генерируемые хедеры, и использовать их ТОЛЬКО из build-директории, а не из source-директории, но это вопрос отдельный). Раньше копировали как могли, потому что довольно давно существующее свойство таргета PUBLIC_HEADER не сохраняет структуру директорий для публичных хедеров, и потому им проще не пользоваться вовсе.
НО! В версии 3.23 наконец приехал стандартный механизм, который реально работает для публичных хедеров - file sets. Единственный на данный момент поддерживаемый тип file set-а это как раз HEADERS. Для этого типа даже автоматически изменяется INCLUDE_DIRECTORIES таргета. Ну и самое главное - при install(TARGETS)сохраняется относительная структура файлов и директорий - как раз то, что обычно нужно для публичных хедеров.
Есть ещё холиварный вопрос - использовать ли директиву file(GLOB) или все файлы всегда перечислять в CMakeLists. Лично я пользуюсь глобом, но у него много противников.
Кстати, почему include, а не add_subdirectory? С инклудом у вас же не будет зеркалироваться структура дерева исходников в билд-дерево.
установка разных конфигураций (static/shared, Debug/Release/..) в разные директории (тогда ничего специального делать не нужно)
Мне кажется это самый разумный и единственный работающий подход. Спасибо Conan-у за то, что именно такой путь они и выбрали, по сути стандартизировав сборку в разных конфигурациях. Все остальные велосипеды жутко усложняет работу.
Тот же GenerateExportHeader генерирует экспортный хедер, который вполне готов к использованию и в STATIC-варианте. В случае размещения только одной конфигурации в одной директории, никакие дополнительные ухищрения не нужны.
Кстати, поддержка мультиконфигурационности в самом CMake - тоже не сахар. Она сделана по сути только для нескольких генераторов, причём прежде всего для IDE вроде Visual Studio, и сильно усложняет код скриптов кучей одинаковых переменных, но для разных конфигураций. Мне кажется гораздо правильнее реализовать такое по append-принципу "несколько прогонов cmake-скрипта -> один солюшен/проектный файл", чтобы новые конфигурации просто "дописывались" в уже сгенерированный проект. Но имеем что имеем.
Спасибо за статью! Отсутствие best practices в документации самого CMake - это, пожалуй, его главная проблема сегодня. Даже синтаксис - и тот можно стерпеть.
А в том, что у них самооценка ниже плинтуса. Потухшие глаза и явное нежелание как-то напрягаться.
Мне кажется здесь нарушена логическая цепочка. Почему, на ваш взгляд, если у человека занижена самооценка, он не желает напрягаться? Разве не наоборот?
Почему спрашиваю: вы установили входной фильтр, а такое решение не может быть необдуманным. А я к сожалению не смог нарисовать портрет человека, который должен идти мимо ещё на этапе фильтрации соискателей в форме поиска.
После прочтения таких статей, ради самоуспокоения всегда напоминаю себе о том, как возросли наши требования как пользователей:
все разучились управлять информацией. Никто больше не ценит простые инструменты, вроде иерархической файловой системы в целях создания порядка. Тех, кто раскладывает музыку во FLAC-е по сотням папочек, считают душными дедами. Все пользуются поиском на стриминговых сервисах.
ладно, не все разучились. Кто-то не умел с самого начала, и вряд ли бы научился. Ведь мы пригласили пользоваться информационными технологиями своих родителей, своих друзей. Им нужны более интуитивные интерфейсы, анимации, подсказки.
теперь мы рассчитываем на информационные технологии ГОРАЗДО сильнее, чем ранее. Многие уже забыли, что такое BSOD и фарш на файловой системе просто при наборе текста в Word. Согласитесь, даже ненавистная Винда сегодня куда более стабильная, чем её древние предки 95/98/Me.
многие вещи, вроде уже упомянутого Юникода, воспринимаются как должное. А за это тоже нужно платить сложностью. Тот же протокол TLS, который по меркам 90-х - супернавороченная вещь уровня дорогущего банковского ПО. А сейчас мы боимся даже картинку скачать по HTTP, вдруг куки/токены угонят.
Ну т.е. если подумать, у софта было достаточно причин стать сложнее.
Конечно, ситуация с JS, вебом и этими вашими Электронами - это другое (c). Это просто одна немаленькая корпорация выиграла битву за программную платформу, и мы пожинаем плоды этой победы. Надеюсь WebAssembly когда-нибудь свергнет JS с должности платформы, "под которую лучше писать по-умолчанию, чтобы дотянуться до максимального числа пользователей". Мне кажется, это самое большое легаси во всём IT на данный момент.
Добавлю ещё про ключик Update Build Revision: HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR . Оттуда как раз можно получить второе число из OS Build, которое как раз и выдаётся командой ver. Это же число видно и в окне System > About в панели управления.
Instra сегодня сделала рассылку о своём решении по поводу текущих событий. Выдержка по существу:
Please note the following:
We will no longer be accepting new registrations and inbound transfers of .RU Domains.
Existing customers will be able to continue to auto-renew their existing .RU domains when they expire, subject to any changes in sanctions and our ability to maintain supply. We will inform you if in future we can no longer process renewals. Early renewals or multi-year renewals will not be accepted. Please make sure to set those domains you wish to be renewed to renew at expiration.
Windows Containers, на использование которых можно и Docker переключить (если конечно он у вас запущен на той версии винды, которая уже поддерживает контейнеры).
Конечно отсутствие строгой типизации не приводит к реальным багам. Отсутствие строгой типизации ПОЗВОЛЯЕТ программисту добавлять новые баги.
Во-первых, я думаю вы понимаете, что если у вас есть JSDoc и тесты, то статическая типизация у вас УЖЕ есть, только неявно и контроллируется она вручную. То, что вы умеете и можете это делать средставами, удобными именно вам, не значит что ваше решение объективно лучшее.
Во-вторых, ошибки на этапе компиляции — это, пожалуй, объективно полезно. Да, вы можете сказать, что тесты вы запускаете также в процессе сборки проекта и можно сказать что это эквивалентное средство. Но если я могу достичь аналогичного результата с помощью информации, которая обрабатывается И компиляторо И программистом одинаково (синтаксис строго-типизированного языка), зачем мне эту информацию разделять между документацией для разоработчика (JSDoc) и тестами?
В третьих, я думаю тесты — это замечательная вещь, которой можно и нужно покрыть всё, что НЕ УДАЛОСЬ покрыть более продвинутыми проверками, такими как типизация (и прочие виды проверок в compile-time). Иными словами, я считаю мы должны идти от тестов к более специализированным и строгим средствам верификации, а не наоборот.
Давать программисту сначала свободу в виде динамической типизации всех переменных и значений, а потом в большинстве случаев эту свободу «забирать», ограничивая тестами РЕАЛЬНЫЕ ветви исполнения кода и РЕАЛЬНЫЕ типы данных, которые код может обработать — это неэффективно. А в реальном коде именно так и будет происходить — не так уже часто нужен действительно «полностью динамический» тип (top-type или any).
И да, я до сих пор не понимаю как форсировать контракты в большой команде разработчиков на динамическом языке. В каждой функции проверять, передали ли туда данные нужного типа и бросать исключение?
Во-первых, генерируемая коллекция может быть бесконечной. Во-вторых, функция с yield return это сопрограмма, и компилятор сгенерит её конечный автомат за вас.
Надо же, такая холиварная статья, а никто не вспомнил про фичу TypeScript 2. Возможно, пора набраться смелости и пойти на аналогичный шаг и в C# — добавить в компилятор режим, в котором будет использоваться более строгое подмножество языка. Не могу сказать, насколько это выполнимо в принципе, но было бы весьма заманчиво.
Казалось бы, что могло подвинуть реляционные БД с постамента наиболее популярной модели хранения данных? Кто бы мог подумать 10-15 лет назад, что в половине новых проектов будут пихать реляционные данные в Монгу, и ночами реализовывать контроль целостности и некое подобие транзакций, ссылаясь на «возможности масштабирования и доступности». При том, что в 80% этих проектов никогда не понадобится репликация больше чем на пару серверов.
Люди в слове «NoSQL» получили отмазку от изучения теории и практики РБД: появилась причина назвать реляционные базы неповоротливым старьём, и не изучать их больше, а быстренько веъхать в более простые документные базы и быть, так сказать, готовым к бою. Но далеко не каждый понимал, что ему придётся заново пройти весь путь.
Есть немало языков, которые стоит изучить (не обязательно использовать в разработке, но изучить). Есть и немало языков, которые лучше бы вообще не появлялись. Когда C++ разработчик предлагает попробовать Rust потому, что видит в нём устоявшиеся практики по управлению временем жизни объектов (передача владения и пр.) в кристаллизованом виде — это профессионализм (разумеется, вкупе со здоровой оценкой состояния инструментов для языка). Когда C++ «разработчик» предлагает попробовать Rust только потому, что Плюсы он так и не осилил в необходимом объеме — это лень и невежество.
Я убежден, что разработчики сегодня слишком ленивы и невежественны.
Я думаю в пятом пункте речь о том, что РБД реализуют наиболее удачное сочетание гарантий и ограничений по-умолчанию, включая такие гарантии, существование которых интуитивно допускается слишком многими разработчиками.
Например, многие привыкли, что БД должна поддерживать транзакционное изменение нескольких элементов данных сразу, и только потом узнают горькую правду о выбранной ими документно-ориентированной СУБД.
VB6, о, моя молодость. Как гляну на иконку окна, так сразу... (роняет скупую слезу)
https://www.asus.com/ru/Mobile/Phones/ZenFone/ZenFone_2_ZE551ML/
А вообще, это так не работает. Если архитектура призвана жрать много электричества, её будут ставить туда, где можно жрать много, и ничего за это не будет.
В телефонах ARM потому что её можно подключить к аккумулятору, и она всегда будет там лучше, чем x86.
Раз вы задаёте этот вопрос, значит вы используете подход "отдельная директория для public хедеров", как и в этой статье. Ну т.е. когда все публичные заголовочные файлы физически перемещаются в отдельную директорию.
В их папках обычно не создаётся CMakeLists просто потому, что с ними особо нечего делать, кроме как скопировать на этапе install (лично я советую делать это и на этапе сборки, особенно если есть генерируемые хедеры, и использовать их ТОЛЬКО из build-директории, а не из source-директории, но это вопрос отдельный). Раньше копировали как могли, потому что довольно давно существующее свойство таргета
PUBLIC_HEADERне сохраняет структуру директорий для публичных хедеров, и потому им проще не пользоваться вовсе.НО! В версии 3.23 наконец приехал стандартный механизм, который реально работает для публичных хедеров - file sets. Единственный на данный момент поддерживаемый тип file set-а это как раз
HEADERS. Для этого типа даже автоматически изменяетсяINCLUDE_DIRECTORIESтаргета. Ну и самое главное - приinstall(TARGETS)сохраняется относительная структура файлов и директорий - как раз то, что обычно нужно для публичных хедеров.target_sourcesпредпочтительнее, просто он появился относительно недавно (по меркам CMake) и мало кто его ещё использует. https://crascit.com/2016/01/31/enhanced-source-file-handling-with-target_sources/Есть ещё холиварный вопрос - использовать ли директиву file(GLOB) или все файлы всегда перечислять в CMakeLists. Лично я пользуюсь глобом, но у него много противников.
Кстати, почему
include, а неadd_subdirectory? С инклудом у вас же не будет зеркалироваться структура дерева исходников в билд-дерево.Мне кажется это самый разумный и единственный работающий подход. Спасибо Conan-у за то, что именно такой путь они и выбрали, по сути стандартизировав сборку в разных конфигурациях. Все остальные велосипеды жутко усложняет работу.
Тот же GenerateExportHeader генерирует экспортный хедер, который вполне готов к использованию и в STATIC-варианте. В случае размещения только одной конфигурации в одной директории, никакие дополнительные ухищрения не нужны.
Кстати, поддержка мультиконфигурационности в самом CMake - тоже не сахар. Она сделана по сути только для нескольких генераторов, причём прежде всего для IDE вроде Visual Studio, и сильно усложняет код скриптов кучей одинаковых переменных, но для разных конфигураций. Мне кажется гораздо правильнее реализовать такое по append-принципу "несколько прогонов cmake-скрипта -> один солюшен/проектный файл", чтобы новые конфигурации просто "дописывались" в уже сгенерированный проект. Но имеем что имеем.
Спасибо за статью! Отсутствие best practices в документации самого CMake - это, пожалуй, его главная проблема сегодня. Даже синтаксис - и тот можно стерпеть.
Можно купить подписку на 365 в розничной продаже.
Спасибо за статью.
Мне кажется здесь нарушена логическая цепочка. Почему, на ваш взгляд, если у человека занижена самооценка, он не желает напрягаться? Разве не наоборот?
Почему спрашиваю: вы установили входной фильтр, а такое решение не может быть необдуманным. А я к сожалению не смог нарисовать портрет человека, который должен идти мимо ещё на этапе фильтрации соискателей в форме поиска.
После прочтения таких статей, ради самоуспокоения всегда напоминаю себе о том, как возросли наши требования как пользователей:
все разучились управлять информацией. Никто больше не ценит простые инструменты, вроде иерархической файловой системы в целях создания порядка. Тех, кто раскладывает музыку во FLAC-е по сотням папочек, считают душными дедами. Все пользуются поиском на стриминговых сервисах.
ладно, не все разучились. Кто-то не умел с самого начала, и вряд ли бы научился. Ведь мы пригласили пользоваться информационными технологиями своих родителей, своих друзей. Им нужны более интуитивные интерфейсы, анимации, подсказки.
теперь мы рассчитываем на информационные технологии ГОРАЗДО сильнее, чем ранее. Многие уже забыли, что такое BSOD и фарш на файловой системе просто при наборе текста в Word. Согласитесь, даже ненавистная Винда сегодня куда более стабильная, чем её древние предки 95/98/Me.
многие вещи, вроде уже упомянутого Юникода, воспринимаются как должное. А за это тоже нужно платить сложностью. Тот же протокол TLS, который по меркам 90-х - супернавороченная вещь уровня дорогущего банковского ПО. А сейчас мы боимся даже картинку скачать по HTTP, вдруг куки/токены угонят.
Ну т.е. если подумать, у софта было достаточно причин стать сложнее.
Конечно, ситуация с JS, вебом и этими вашими Электронами - это другое (c). Это просто одна немаленькая корпорация выиграла битву за программную платформу, и мы пожинаем плоды этой победы. Надеюсь WebAssembly когда-нибудь свергнет JS с должности платформы, "под которую лучше писать по-умолчанию, чтобы дотянуться до максимального числа пользователей". Мне кажется, это самое большое легаси во всём IT на данный момент.
Добавлю ещё про ключик Update Build Revision:
HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\UBR. Оттуда как раз можно получить второе число из OS Build, которое как раз и выдаётся командойver. Это же число видно и в окне System > About в панели управления.Используем вот такую штуку года где-то с 2018-го:
применяется например вот так:
Качество кода выросло очень заметно.
Instra сегодня сделала рассылку о своём решении по поводу текущих событий. Выдержка по существу:
Это издёвка?
Во-первых, я думаю вы понимаете, что если у вас есть JSDoc и тесты, то статическая типизация у вас УЖЕ есть, только неявно и контроллируется она вручную. То, что вы умеете и можете это делать средставами, удобными именно вам, не значит что ваше решение объективно лучшее.
Во-вторых, ошибки на этапе компиляции — это, пожалуй, объективно полезно. Да, вы можете сказать, что тесты вы запускаете также в процессе сборки проекта и можно сказать что это эквивалентное средство. Но если я могу достичь аналогичного результата с помощью информации, которая обрабатывается И компиляторо И программистом одинаково (синтаксис строго-типизированного языка), зачем мне эту информацию разделять между документацией для разоработчика (JSDoc) и тестами?
В третьих, я думаю тесты — это замечательная вещь, которой можно и нужно покрыть всё, что НЕ УДАЛОСЬ покрыть более продвинутыми проверками, такими как типизация (и прочие виды проверок в compile-time). Иными словами, я считаю мы должны идти от тестов к более специализированным и строгим средствам верификации, а не наоборот.
Давать программисту сначала свободу в виде динамической типизации всех переменных и значений, а потом в большинстве случаев эту свободу «забирать», ограничивая тестами РЕАЛЬНЫЕ ветви исполнения кода и РЕАЛЬНЫЕ типы данных, которые код может обработать — это неэффективно. А в реальном коде именно так и будет происходить — не так уже часто нужен действительно «полностью динамический» тип (top-type или any).
И да, я до сих пор не понимаю как форсировать контракты в большой команде разработчиков на динамическом языке. В каждой функции проверять, передали ли туда данные нужного типа и бросать исключение?
Как говорил Хоар про null-ы у указателей — ошибка на миллиард.
Казалось бы, что могло подвинуть реляционные БД с постамента наиболее популярной модели хранения данных? Кто бы мог подумать 10-15 лет назад, что в половине новых проектов будут пихать реляционные данные в Монгу, и ночами реализовывать контроль целостности и некое подобие транзакций, ссылаясь на «возможности масштабирования и доступности». При том, что в 80% этих проектов никогда не понадобится репликация больше чем на пару серверов.
Люди в слове «NoSQL» получили отмазку от изучения теории и практики РБД: появилась причина назвать реляционные базы неповоротливым старьём, и не изучать их больше, а быстренько веъхать в более простые документные базы и быть, так сказать, готовым к бою. Но далеко не каждый понимал, что ему придётся заново пройти весь путь.
Есть немало языков, которые стоит изучить (не обязательно использовать в разработке, но изучить). Есть и немало языков, которые лучше бы вообще не появлялись. Когда C++ разработчик предлагает попробовать Rust потому, что видит в нём устоявшиеся практики по управлению временем жизни объектов (передача владения и пр.) в кристаллизованом виде — это профессионализм (разумеется, вкупе со здоровой оценкой состояния инструментов для языка). Когда C++ «разработчик» предлагает попробовать Rust только потому, что Плюсы он так и не осилил в необходимом объеме — это лень и невежество.
Я убежден, что разработчики сегодня слишком ленивы и невежественны.
Автору спасибо за перевод!