В итоге код тестов заметно превышает объем основного кода. В приложении тесты чаще падали не потому, что в логике ошибку я допустил. А потому что сами тесты переставали соответствовать новой логике.
Новый параметр на входе функции увеличивает количество тестов в два раза или больше. Зависит от вариаций, которые могут поступить на вход. Если параметр передается дальше в другой компонент, то и там тесты надо усложнять.
Со стороны отдельно метода кажется, что вариаций может быть много, и все надо протестировать. Но если посмотреть со стороны интерфейса пользователя, то набор входных данных может быть ограничен факторами, о которых бекенд разработчик не знает. То есть он будет писать лишние тесты.
При рефакторинге я удалил все юнит-тесты и переключился на интеграционные. Теперь все приложение можно рефакторить сколько угодно. И стек интеграционных тестов и самого приложения можно менять независимо. Лишь бы основной интерфейс оставался рабочим.
Если на проекте нет хорошего ТЗ, и работаете по аджайлу, то заниматься юнит-тестами дорого. Уже после первого тестирования нового функционала, могут решить все переделывать. Каждый спринт будете все тесты переписывать. В таком случае тесты лучше добавлять на устоявшийся функционал, когда думаете, что кто-то может его легко поломать. Так как все нюансы не всегда очевидны.
Плохой REST‑сервис должен хранить состояние. Один из примеров — это сессии.
Спринг из коробки для нового рест-сервиса сделает вам сессии. И если клиент такого сервиса начнет между вызовами сохранять куку и отправлять её, то можно нарваться на интересное поведение.
Недавно нашел ещё одну замену postman - https://github.com/hoppscotch/hoppscotch. Можно установить свое облако on-premise, где хранить командные воркспейсы с коллекциями.
Лучше использовать усиленную неквалифицированную ЭП по соглашению сторон. УКЭП сейчас — это вендорлок от разработчиков средств и дополнительные требования, не влияющие на безопасность.
Начало — много воды, повторов. Текст эмоционален. Страхи и теории заговора. Как будто чью-то речь с разных встреч собрали и перепечатали.
Дальше есть конкретика и конкретные примеры. Из важного для меня:
— Правильно написано про «решение ИИ». Про цифровой и социальный профиль, который можно всесторонне анализировать и отдавать опять же ИИ.
— У владельца сервиса становится больше возможностей скрывать правки и ошибки. Коррупция для которой нужен только админ.
— Про надежность цифровых документов. Надо следить за бэкапами.
— Гражданам нужны дополнительные устройства и их обновление.
— Не отмечено, что на местах не знают как использовать и насколько доверять цифровым документам. Сейчас нотариусы и многие другие уверены, что если срок сертификата ЭП закончился, то все документы им подписанные становятся недействительными, и их надо снова заверять. Практика не наработана. Чтобы не ждать этой практики, надо тщательней прописывать в законе. Вплоть до инструкции, формата и алгоритма.
— В медицинских документах и картах всегда был бардак. Их государство и в бумажном виде собирало и хранило без спроса. И передавало без спроса в тот же военкомат и в школу. При этом нельзя их забрать. Можно только выписку попросить.
— В образовании всегда были эксперименты. Если выдают планшеты, а не требуют покупать, то не все так плохо.
Не нашел важные на мой взгляд моменты:
— Не сказано, что помимо покупки устройств граждан обязывают иметь номер мобильного телефона. Привязывают его везде как пароль. А номер за бездействие отбирается и передается неизвестно кому.
— Пугает злоупотребление простой цифровой подписью в виде кода по СМС. Опять же обязанность иметь и держать запароленным телефон. Не все телефоны можно запаролить. При этом подпись односторонняя. Владелец сервиса со своей стороны никакой подписи не дает. Доказать, что заявление было принято, и договор действует, может не получиться.
— Не сказано про то, что биометрию нельзя использовать как цифровую подпись. И пускать по ней к сервисам. Биометрия — это только доказательство, что конкретное тело есть. Но не доказывает, что гражданин, владеющий этим телом, принял добровольное решение воспользоваться услугой. Скоро получим ситуации, когда родственники парализованного будут отбирать имущество и набирать кредитов ещё до вступления в наследство.
Вторая часть расстроила. Вместо предложений и правок в закон — лозунги.
Брать плату за размещение приложения в магазине и за пользование сервиса оплаты апстора, за другие сервисы (пуши и т.д). Если пользователю удобнее оплатить через апстор, то будет зарабатывать дополнительно. Если пользователю не лень переходить по ссылкам, то не будет.
Если пользователь нашел приложение на сайте разработчика, оплатил там и мог скачать приложение там, то почему маркет вообще что-то должен получать в таком случае?
Quasar навязывает себя как единственное решение для всего приложения. Bootstrap, например, и Quasar оказались несовместимы. Я хотел взять у них только один компонент в свое приложение. Этот компонент на странице вообще не отобразился. Из-за стилей. Quasar использует беспрефиксные стили. Причем такие распространенные как row, column, wrap, content, flex, disabled. Мне пришлось бы убирать Bootstrap и переименовывать общие стили.
Также Quasar добавляется в проект не совсем стандартно, как другие библиотеки. И вообще рекомендует использовать свой CLI.
Ещё минус — это код компонент. Там везде render функция. Для сложных компонент (например календарь) это выглядит ужасно и отбивает желание разбираться и править под себя.
Как правильно создать такой вход на своем сервере?
Обычно сайт запрашивает один из установленных в системе или браузере персональных сертификатов пользователя. Потом на сервере достаем сертификат из запроса и проверяем. Какую роль играет плагин?
Возможно ли доверять сертификату, который был выпущен одним из тысяч УЦ и может быть уже отозван минуту назад?
Технически не мешало. Но в законе есть статья «4.4. Разрешение на обработку фискальных данных» и «4.5. Требования к соискателю разрешения на обработку фискальных данных». Я понимаю, что они относятся к ОФД. Но это выглядит так, будто ФД очень секретные и рассылать их всем подряд теперь нельзя.
Магазин может передавать данные не только к ОФД, но и в сторонний сервис, агрегирующий чеки с нескольких магазинов? Например, для отслеживания покупок, которые делает покупатель в другом магазине, но почему-то не делает у них. Технически, все кассы теперь имеют связь.
Это законно, при условии что покупатель сам привязывает карты лояльности с нескольких магазинов к своему аккаунту в сервисе?
В нормальном языке порядок неважен. Destructuring с объектами работает по именам. Так в JavaScript или Rust. Проблема в языке.
Я проверял это на себе.
В итоге код тестов заметно превышает объем основного кода. В приложении тесты чаще падали не потому, что в логике ошибку я допустил. А потому что сами тесты переставали соответствовать новой логике.
Новый параметр на входе функции увеличивает количество тестов в два раза или больше. Зависит от вариаций, которые могут поступить на вход. Если параметр передается дальше в другой компонент, то и там тесты надо усложнять.
Со стороны отдельно метода кажется, что вариаций может быть много, и все надо протестировать. Но если посмотреть со стороны интерфейса пользователя, то набор входных данных может быть ограничен факторами, о которых бекенд разработчик не знает. То есть он будет писать лишние тесты.
При рефакторинге я удалил все юнит-тесты и переключился на интеграционные. Теперь все приложение можно рефакторить сколько угодно. И стек интеграционных тестов и самого приложения можно менять независимо. Лишь бы основной интерфейс оставался рабочим.
Если на проекте нет хорошего ТЗ, и работаете по аджайлу, то заниматься юнит-тестами дорого. Уже после первого тестирования нового функционала, могут решить все переделывать. Каждый спринт будете все тесты переписывать.
В таком случае тесты лучше добавлять на устоявшийся функционал, когда думаете, что кто-то может его легко поломать. Так как все нюансы не всегда очевидны.
Вы пробовали Typst? Говорят, он удобнее.
Спринг из коробки для нового рест-сервиса сделает вам сессии. И если клиент такого сервиса начнет между вызовами сохранять куку и отправлять её, то можно нарваться на интересное поведение.
Недавно нашел ещё одну замену postman - https://github.com/hoppscotch/hoppscotch. Можно установить свое облако on-premise, где хранить командные воркспейсы с коллекциями.
Алгоритм есть в сертификате. Можно не делать настройку для этого. Возможен ли другой?
Дальше есть конкретика и конкретные примеры. Из важного для меня:
— Правильно написано про «решение ИИ». Про цифровой и социальный профиль, который можно всесторонне анализировать и отдавать опять же ИИ.
— У владельца сервиса становится больше возможностей скрывать правки и ошибки. Коррупция для которой нужен только админ.
— Про надежность цифровых документов. Надо следить за бэкапами.
— Гражданам нужны дополнительные устройства и их обновление.
— Не отмечено, что на местах не знают как использовать и насколько доверять цифровым документам. Сейчас нотариусы и многие другие уверены, что если срок сертификата ЭП закончился, то все документы им подписанные становятся недействительными, и их надо снова заверять. Практика не наработана. Чтобы не ждать этой практики, надо тщательней прописывать в законе. Вплоть до инструкции, формата и алгоритма.
— В медицинских документах и картах всегда был бардак. Их государство и в бумажном виде собирало и хранило без спроса. И передавало без спроса в тот же военкомат и в школу. При этом нельзя их забрать. Можно только выписку попросить.
— В образовании всегда были эксперименты. Если выдают планшеты, а не требуют покупать, то не все так плохо.
Не нашел важные на мой взгляд моменты:
— Не сказано, что помимо покупки устройств граждан обязывают иметь номер мобильного телефона. Привязывают его везде как пароль. А номер за бездействие отбирается и передается неизвестно кому.
— Пугает злоупотребление простой цифровой подписью в виде кода по СМС. Опять же обязанность иметь и держать запароленным телефон. Не все телефоны можно запаролить. При этом подпись односторонняя. Владелец сервиса со своей стороны никакой подписи не дает. Доказать, что заявление было принято, и договор действует, может не получиться.
— Не сказано про то, что биометрию нельзя использовать как цифровую подпись. И пускать по ней к сервисам. Биометрия — это только доказательство, что конкретное тело есть. Но не доказывает, что гражданин, владеющий этим телом, принял добровольное решение воспользоваться услугой. Скоро получим ситуации, когда родственники парализованного будут отбирать имущество и набирать кредитов ещё до вступления в наследство.
Вторая часть расстроила. Вместо предложений и правок в закон — лозунги.
Использую https://docs.rs/log-mdc/0.1.0/log_mdc/ вместе с log4rs. Возможно это то, что вам нужно. Добавляю что-то в контекст
В паттерне прописываю
{X(userId)(anon)}. И любой вызов логгера пишет эту переменную илиanon.Если пользователь нашел приложение на сайте разработчика, оплатил там и мог скачать приложение там, то почему маркет вообще что-то должен получать в таком случае?
Также Quasar добавляется в проект не совсем стандартно, как другие библиотеки. И вообще рекомендует использовать свой CLI.
Ещё минус — это код компонент. Там везде render функция. Для сложных компонент (например календарь) это выглядит ужасно и отбивает желание разбираться и править под себя.
Обычно сайт запрашивает один из установленных в системе или браузере персональных сертификатов пользователя. Потом на сервере достаем сертификат из запроса и проверяем. Какую роль играет плагин?
Возможно ли доверять сертификату, который был выпущен одним из тысяч УЦ и может быть уже отозван минуту назад?
В последнем примере почему вы добавили
const { item } = this;, а не оставили
this.item?
На форуме уже спрашивали про устаревшие ссылки: https://community.oracle.com/thread/4030451. Ответ: не везде обновили.
И в помнике лицензию добавили http://download.oracle.com/maven/com/sleepycat/je/7.4.5/je-7.4.5.pom
В низу страницы http://www.oracle.com/technetwork/database/database-technologies/berkeleydb/learnmore/index.html лицензия новая.
На всё скаченное она должна распространяться.
Это законно, при условии что покупатель сам привязывает карты лояльности с нескольких магазинов к своему аккаунту в сервисе?