Runtime связывание, интерфейсы, шаблоны и все как принято
Само связывание осуществляется в runtime, но все поставляемые зависимости описываются в статике. Слава богу, хотя бы без XML.
А боль получилась такая - везде используются интерфейсы, реализации которых не всегда очевидны ибо есть несколько реализаций. К тому же, легкость внедрения зависимостей привела к тому, что практически нет классов без зависимостей (в том или ином количестве).
В результате, это привело к тому, что читая текст программы ты никогда не можешь точно угадать, что именно стоит за тем или иным вызовом метода. Помогает только запуск отладчика, но это не точно, потому что для тестов есть отдельный набор зависимостей.
Про успешную компиляцию, но неуспешный запуск (не забываем про runtime связывание) я просто не буду писать. Привык и научился исправлять.
Тестирование такого кода - это отдельная песня... Я иногда начинаю завидовать бурлакам на Волге... некоторые участки кода не покрыты тестами просто потому, что это невозможно сделать (ну или стоимость написания такого теста превышает допустимые затраты).
Это легкое описание той головной боли, которая получена благодаря Dependency Injection. И да, DI никак не помогает упростить написание логики приложения.
PS имел счастье почитать код, до внедрения механизма DI... читал код и плакал - все понятно, логично и надёжно. Нет, вот так - НАДЕЖНО!
Получается, на уже инициализированном PROD-терминале запустить криптопроцессор в мокап-режиме не выйдет? А сменить профиль можно только при помощи KIT 43C?
Да, именно так.
А что за версия SDK, интересно?
Уже точно не помню. В комплекте было несколько PDF, причем копаться в них надо было самому. Потом французы начали перенос информации из этих PDF в CHM файлы. Сейчас, может и нет никаких PDF.
VAR - это сокращение от Value Added Reseller. То есть компания, которая будет продавать терминал с добавленной стоимостью (как правило ПО). В документации на SDK этого никогда и не было.
А где хранятся эти ключи?
Этот ключ выдается отдельным файлом :) и у каждого VAR он свой. Он загружается в терминал во время инициализации. Где уж там он храниться - не знаю. И конечно, ключей VAR никогда не было в составе SDK.
В поставке SDK есть несколько PDF, которые надо вдумчиво читать. Согласен, что изложенное в них можно понять только после трех... а то и четырех прочтений - такой там стиль изложения.
Unauthorized... Дело в том, что терминалы Telium 1/2 персонализируются в два этапа: сначала прошивается профиль VAR (в нем есть криптоключ, которым потом проверяется подпись приложения), а потом инициализируется криптопроцессор (с помощью прошитого ранее ключа из профиля VAR). Получается, что в терминале есть два компонента, у которых должны быть одинаковые ключи для проверки подписи.
Когда на готовый PROD терминал накатывается MOCKUP прошивка, то получается конфликт - операционная система использует одну крипто-подпись, а криптографический процессор требует крипто-подпись от PROD. И при проверке этого у терминала сносит башню - вроде все должно быть одиннаковое, а оно разное. При обратном движение - получаем такую же ситуацию: ОС стала PROD, а криптопроцессор остался MOCKUP. Результат тот же.
Сменить инициализацию криптопроцессора можно ТОЛЬКО с помощью KIT-а (номер не помню).
На самом деле MOCKUP - это профиль специального VAR, для разработчиков.
Правила очень простые:
PROD не трогать никогда. Если потрогали - то приложить к иконе (то есть к KIT-у)
MockUp терминал можно делать только из чистого терминала (без загруженного VAR профиля)
в MockUp режиме ничего не отключается. Этот режим отличается только тем, что криптографические ключи, используемые для подписи ПО, заранее известны.
Перевести в MockUp можно только "чистый" терминал, в который не был инсталлирован профиль разработчика ПО (ну или VAR, как он раньше назывался). Кроме заливки MockUp ОС надо еще правильно инициализировать криптопроцессор.
Ключи IngeTrust никогда не удаляются из терминала (ну кроме случая срабатывания защиты от вскрытия аппарата).
Для улучшения "обзорности" хорошо бы добавить описание криптопроцессора (что это и с чем его кушают). Это самая мякотка терминала - а про неё ни слова. Как и про крипто-схемы.
Чего-то не увидел упоминания главной особенности std::vector.
Реализация std::vector гарантирует, что его элементы лежат в непрерывном блоке памяти. Это прописано в стандарте. Отсюда и копирование элементов, если существующего буфера не достаточно для добавления нового элемента.
Если почитать про функцию realloc, то в документации написано: если блок не может быть увеличен, то происходит выделение нового блока и копирование данных в него из старого.
Вектор из С++ все лишь добавляет использования конструктора копирования (ну или перемещения).
Вакансия: водитель.
Требования: профессиональные навыки в управлении легковыми и грузовыми автомобилями, троллейбусами, трамваями, поездами метрополитена и фуникулера, экскаваторами и бульдозерами, спецмашинами на гусеничном ходу, боевыми машинами пехоты и современными легкими/средними танками, находящимисяна вооружении стран СНГ и НАТО.
Навыки раллийного и экстремального вождения обязательны. Опыт управления болидами «Формулы-1» — приветствуется. Знания и опыт ремонта поршневых и роторных двигателей, автоматических и ручных трансмиссий, систем зажигания, антиблокировочных систем, навигационных систем и автомобильных аудиосистем ведущих поизводителей — обязательны. Опыт проведения кузовных и окрасочных работ — приветствуется. Претенденты должны иметь сертификаты Mercedes, BMW, а также справки об участии в крупных международных ралли не более чем двухлетней давности.
Зарплата: испытательный срок 1-3 месяца, зарплата по результатам собеседования.
тратили бы вы пару часов на оптимизацию, которая не сэкономит эту самую пару часов времени железа за всё суммарное время эксплуатации софтины?
При такой постановке вопроса — ответ нет.
многие сильно недооценивают влияние CRTP на код и сильно переоценивают его влияние на перф.
О чем я и говорю — "трезво взвешивать выгоду"
Проблема в том, что абстрактный программист Петя уже не сможет разобраться, что там написал Вася, и перепишет с нуля. И если Петя тоже начинающий, мы получаем цикл.
Мне уже надоел аргумент о не квалифицированном программисте (специалисте, технике, сантехнике, электрике и так далее). Этот аргумент сродни переходу на личности. Я бы не хотел вести дискуссию в таком русле.
Программирование требует самоотдачи и постоянного повышения квалификации (как и любой другой вид деятельности впрочем) и постоянно говорить и неком "Васе" или "Пете", которые не разобравшись перепишут с нуля как минимум не логично. Как минимум потому, что порог входа в программирование существенно выше и требует определенного склада ума.
Инженерный же подход требует найти компромисс из доступного и требуемого для решения конкретной задачи. И надо понимать, что иногда код живет гораздо дольше времени потраченного на его написание и оптимизацию (как по скорости исполнения, так и по легкости чтения). Зная плюсы и минусы CRTP инженер-программист может самостоятельно принять решение о применимости данного подхода для данной задачи. И никак по другому.
Мой изначальный посыл был лишь об одном свойстве CRTP — проверке интерфейса наследуемого класса на этапе компиляции. Как по мне, так это однозначный плюс.
Читаемость или не читаемость — это слишком индивидуальная оценка…
а вот оценка быстродействия и экономия памяти — это вполне себе измеримая характеристика.
Просто надо понимать что даёт CRTP и трезво взвешивать выгоду, которую можно от него получить.
В моей практике даже начинающие программисты довольно быстро вникали в суть CRTP и начинали его использовать (иногда не там, где нужно).
А вот с чистыми виртуальными методами согласен полностью. Более того сам использую в практике. Причем, делаю их protected и публичный метод для вызова. Такой прием используется для разделения определения интерфейса (публичные методы в базовом классе) и реализации (virtual protected методы в наследниках).
В такой связке и override не очень нужен.
Но если есть возможность (читай потребность) использовать CRTP — использую всегда.
Конечно, такой подход уберет часть головной боли.
Но фокус состоит в том, что если бы не DI - то у меня вообще не было бы головной боли.
Если честно, то по прошествии нескольких лет я вообще считаю механизм DI вредным. Именно из-за таких головных болей...
Итак по порядку:
Java + Guice
Runtime связывание, интерфейсы, шаблоны и все как принято
Само связывание осуществляется в runtime, но все поставляемые зависимости описываются в статике. Слава богу, хотя бы без XML.
А боль получилась такая - везде используются интерфейсы, реализации которых не всегда очевидны ибо есть несколько реализаций. К тому же, легкость внедрения зависимостей привела к тому, что практически нет классов без зависимостей (в том или ином количестве).
В результате, это привело к тому, что читая текст программы ты никогда не можешь точно угадать, что именно стоит за тем или иным вызовом метода. Помогает только запуск отладчика, но это не точно, потому что для тестов есть отдельный набор зависимостей.
Про успешную компиляцию, но неуспешный запуск (не забываем про runtime связывание) я просто не буду писать. Привык и научился исправлять.
Тестирование такого кода - это отдельная песня... Я иногда начинаю завидовать бурлакам на Волге... некоторые участки кода не покрыты тестами просто потому, что это невозможно сделать (ну или стоимость написания такого теста превышает допустимые затраты).
Это легкое описание той головной боли, которая получена благодаря Dependency Injection. И да, DI никак не помогает упростить написание логики приложения.
PS имел счастье почитать код, до внедрения механизма DI... читал код и плакал - все понятно, логично и надёжно. Нет, вот так - НАДЕЖНО!
После 6 лет сопровождения проекта с использованием Dependency Injection скажу только одно - прежде чем вводить их в проект ПОДУМАЙТЕ и откажитесь!
Голосую за Сапера!
Посмотрите на ютубе канал автора @SergeyDorosh
Вам будет очень любопытно.
в 2012
Теперь надо проверить функционирование крипто-процессора.
У меня очень большие сомнения, что хотя бы одна операция на нём сработает.
Да, это именно оно. Номер в квадратных скобках - это и есть номер VAR профиля.
Да, именно так.
Уже точно не помню. В комплекте было несколько PDF, причем копаться в них надо было самому. Потом французы начали перенос информации из этих PDF в CHM файлы. Сейчас, может и нет никаких PDF.
VAR - это сокращение от Value Added Reseller. То есть компания, которая будет продавать терминал с добавленной стоимостью (как правило ПО). В документации на SDK этого никогда и не было.
Этот ключ выдается отдельным файлом :) и у каждого VAR он свой. Он загружается в терминал во время инициализации. Где уж там он храниться - не знаю.
И конечно, ключей VAR никогда не было в составе SDK.
В поставке SDK есть несколько PDF, которые надо вдумчиво читать. Согласен, что изложенное в них можно понять только после трех... а то и четырех прочтений - такой там стиль изложения.
Unauthorized...
Дело в том, что терминалы Telium 1/2 персонализируются в два этапа: сначала прошивается профиль VAR (в нем есть криптоключ, которым потом проверяется подпись приложения), а потом инициализируется криптопроцессор (с помощью прошитого ранее ключа из профиля VAR). Получается, что в терминале есть два компонента, у которых должны быть одинаковые ключи для проверки подписи.
Когда на готовый PROD терминал накатывается MOCKUP прошивка, то получается конфликт - операционная система использует одну крипто-подпись, а криптографический процессор требует крипто-подпись от PROD. И при проверке этого у терминала сносит башню - вроде все должно быть одиннаковое, а оно разное.
При обратном движение - получаем такую же ситуацию: ОС стала PROD, а криптопроцессор остался MOCKUP. Результат тот же.
Сменить инициализацию криптопроцессора можно ТОЛЬКО с помощью KIT-а (номер не помню).
На самом деле MOCKUP - это профиль специального VAR, для разработчиков.
Правила очень простые:
PROD не трогать никогда. Если потрогали - то приложить к иконе (то есть к KIT-у)
MockUp терминал можно делать только из чистого терминала (без загруженного VAR профиля)
Замеченные неточности:
в MockUp режиме ничего не отключается. Этот режим отличается только тем, что криптографические ключи, используемые для подписи ПО, заранее известны.
Перевести в MockUp можно только "чистый" терминал, в который не был инсталлирован профиль разработчика ПО (ну или VAR, как он раньше назывался). Кроме заливки MockUp ОС надо еще правильно инициализировать криптопроцессор.
Ключи IngeTrust никогда не удаляются из терминала (ну кроме случая срабатывания защиты от вскрытия аппарата).
Для улучшения "обзорности" хорошо бы добавить описание криптопроцессора (что это и с чем его кушают). Это самая мякотка терминала - а про неё ни слова. Как и про крипто-схемы.
Чего-то не увидел упоминания главной особенности std::vector.
Реализация std::vector гарантирует, что его элементы лежат в непрерывном блоке памяти. Это прописано в стандарте. Отсюда и копирование элементов, если существующего буфера не достаточно для добавления нового элемента.
Если почитать про функцию realloc, то в документации написано: если блок не может быть увеличен, то происходит выделение нового блока и копирование данных в него из старого.
Вектор из С++ все лишь добавляет использования конструктора копирования (ну или перемещения).
и как результаты?
Просто оставлю тут это:
Жалоба от производителя оборудования на то, что в Linux нет драйвера для этого оборудования.
Странно, но мне кажется, что всё в ваших руках.
Вот хороший образец для подражания https://www.youtube.com/watch?v=yy3zUi45SiI
Мой опыт говорит о другом.
Так мы с этого и начали.
Чтобы виртуальные методы проверялись, нужно либо использовать чистые виртуальные методы, либо использовать ключевое слово override.
CRTP не требует ни того, ни другого.
P.S. Это не призыв использовать CRTP вместо виртуальных методов. Это просто констатация факта.
При такой постановке вопроса — ответ нет.
О чем я и говорю — "трезво взвешивать выгоду"
Мне уже надоел аргумент о не квалифицированном программисте (специалисте, технике, сантехнике, электрике и так далее). Этот аргумент сродни переходу на личности. Я бы не хотел вести дискуссию в таком русле.
Программирование требует самоотдачи и постоянного повышения квалификации (как и любой другой вид деятельности впрочем) и постоянно говорить и неком "Васе" или "Пете", которые не разобравшись перепишут с нуля как минимум не логично. Как минимум потому, что порог входа в программирование существенно выше и требует определенного склада ума.
Инженерный же подход требует найти компромисс из доступного и требуемого для решения конкретной задачи. И надо понимать, что иногда код живет гораздо дольше времени потраченного на его написание и оптимизацию (как по скорости исполнения, так и по легкости чтения). Зная плюсы и минусы CRTP инженер-программист может самостоятельно принять решение о применимости данного подхода для данной задачи. И никак по другому.
Мой изначальный посыл был лишь об одном свойстве CRTP — проверке интерфейса наследуемого класса на этапе компиляции. Как по мне, так это однозначный плюс.
Читаемость или не читаемость — это слишком индивидуальная оценка…
а вот оценка быстродействия и экономия памяти — это вполне себе измеримая характеристика.
Просто надо понимать что даёт CRTP и трезво взвешивать выгоду, которую можно от него получить.
В моей практике даже начинающие программисты довольно быстро вникали в суть CRTP и начинали его использовать (иногда не там, где нужно).
Ах если бы override был везде...
А вот с чистыми виртуальными методами согласен полностью. Более того сам использую в практике. Причем, делаю их protected и публичный метод для вызова. Такой прием используется для разделения определения интерфейса (публичные методы в базовом классе) и реализации (virtual protected методы в наследниках).
В такой связке и override не очень нужен.
Но если есть возможность (читай потребность) использовать CRTP — использую всегда.