И что весьма печалит, компания, пытаясь заработать репутацию на ИТ-ресурсе, публикует в переводах местами, прямо скажем, ахинею. Не отдав на вычитку профессионалам. В итоге — репутация только падает.
Ну еще в голову приходит, где это могло бы быть полезно. Если у вас несколько единообразных интерфейсов у разных каналов (например мобилки iOS, Android). Тогда сценарии тестирования может быть одним (на Akita), а реализация под канал разная.
Насколько я понимаю, перед тем как xml будет подписан к нему применяются разные трансформации, и уже результат подается на вход подписания.
Если одна и та же трансформация, но из разных версий, дает разные результаты, то встает вопрос, как третья сторона будет доказывать или опровергать корректность подписи? Экспериментировать с доступными версиями трансформатора?
Gradle, как Maven, сам по себе требует изоляции в CI, иначе вы становитесь зависимы от версии стоящей на CI узле (ну или машине разработчика).
gradlew (mvnw)… же…
хотя зависимость от окружения все равно в тяжелых случаях остается.
да и не в тяжелых, те же url'ы до maven-репозитариев (у суровых контор все закрыто)
А до поездки какова была модель ребенок — родитель — гаджет в вашей семье?
Может быть (может быть! я не знаю) точка приложения усилий должна быть не в поездке, один раз, а дома, и регулярно?
Надо различать в принципе мутное ТЗ, когда действительно выгодоприобретатель не знает чего хочет. Да, такое бывает. Но недолго, т.к. рынок возвращает прагматичность очень быстро.
И случай, когда в принципе есть неопределенность, и сегодня ты решения принимаешь в одних условиях. А завтра ты быстро переобуваешься, потому что условия изменились.
У статьи у очень ценные комментарии. ;) Классика случая, когда бизнес хочет, а ИТ не может.
И про мотивацию, и про архитектуру, и про кто кому чего должен, и про хорошее тз ;)
Вопрос не в том, нужно ли ограничивать электронные гаджеты в жизни ребенка.
А в том, что ты, как родитель, можешь предложить своему ребенку в качестве альтернативы гаджету?
И тут неожиданно выяснится, что большинство родителей альтернативу предложить не могут.
Т.к. сериальчики, свои гаджеты, и прочие радости современного мира. Жопу оторвать лень, а виноват конечно Гугл и Эппл. Ну и школа… ;)
Вот вы уходите от ответа, хотя он очень важен.
Если вам нужно протестировать поведение Thread.sleep, вопросов нет. Так и надо делать.
Если вы доверяете Thread.sleep, и вам нужно проверить реализацию вашего класса, в котором каким-то образом обыграны настройки расписания, то вам нужно тестировать параметры, передаваемые в Thread.sleep, и которые генерируются из настроек расписания (т.е. протестировать тот код, который написали лично вы). В этом случае, опять же оборачиваете Thread.sleep в отдельный метод, и мокаете его в тестах. Если не убедил, представьте что вместо Thread.sleep, у вас Files.readAllBytes, или new Random().nextInt.
Используя простейший подход из примера выше и подменив System.currentTimeMillis(), можно проверить корректность сообщения и только. Но чтобы протестировать корректность расписания, придётся ждать целый день.
Посыл правильный, реализация куда-то в сторону уехала.
Верно отмечено, тестировать нужно корректность расписания. Оборачиваем System.currentTimeMillis() в отдельный метод в нашем классе, и мокаем его (наш метод) в тестах с любой логикой, которой нужно для тестов.
Что не умоляет (наверно) возможностей time-test, в тех случаях, когда System.currentTimeMillis() зовется где-то в недрах внешней библиотеки, которую сложно отмокать.
Лучше бы структурировали по характистикам:
— с поддержкой честного ACID, и без оного
— с поддержкой in-memory, и без оного
— с поддержкой шардинга, и без оного
— структуры (реляционные, графы, key-value, timeseries)
— с поддержкой constraints во всех проявлениях, и без оного
— c поддержкой бизнес-логики во всех проявлениях внутри бд, и без оного
— наверно можно еще продолжить
Это только то, что интересно разработчику. И не касались инструментов.
А есть еще operation staff. Есть бизнеса…
Вопрос про другое. Утверждалось, что EV-сертификаты нужны веб-ресурсам, обрабатывающим финансовые операции.
Представим, условный Вася хочет купить через интернет нечто. Его перенаправляют с магазина на сайта процессинга. И тут Вася не видит EV-плашки, и думает: «да ну его, даже EV-сертификата нет, пойду поищу другой магазин с нормальным процессингом с нормальным EV-сертификатом». Это так работает?
Или, открываешь ты свой процессинг, и тут тебе регулятор выкатывает простыню законов и правил, и один из пунктов про наличие ev-сертификата. Это так работает?
Основа любой платежной системы, умное слово, клиринг. Вокруг клиринга собственно и строится весь бизнес платежных систем. В функциях контракта про клиринг как-то забыли.
Все же я считаю, что тендер это не самый лучший способ выбрать подрядчика на разработку сайта. Веб сайт продукт не стандартный, как “щебень м1200” и сравнивать его по цене, как это зачастую делается — в корне не верно. Надеюсь эта статья поможет навести порядок.
Ключевая фраза.
Все остальное — это советы для тех, кто работает в гос секторе (и его аналогах), где формат тендера закреплен законом, и с этим надо как-то жить.
Ну еще в голову приходит, где это могло бы быть полезно. Если у вас несколько единообразных интерфейсов у разных каналов (например мобилки iOS, Android). Тогда сценарии тестирования может быть одним (на Akita), а реализация под канал разная.
Если одна и та же трансформация, но из разных версий, дает разные результаты, то встает вопрос, как третья сторона будет доказывать или опровергать корректность подписи? Экспериментировать с доступными версиями трансформатора?
Вот это кстати, полная засада.
Реализация трансформатора не должна меняться.
Каждая релизная версия трансформатора должна иметь уникальное имя.
Если эти два требования не соблюдаются — то можно ЭЦП не использовать, он не выполняет своей функции.
gradlew (mvnw)… же…
хотя зависимость от окружения все равно в тяжелых случаях остается.
да и не в тяжелых, те же url'ы до maven-репозитариев (у суровых контор все закрыто)
Может быть (может быть! я не знаю) точка приложения усилий должна быть не в поездке, один раз, а дома, и регулярно?
И случай, когда в принципе есть неопределенность, и сегодня ты решения принимаешь в одних условиях. А завтра ты быстро переобуваешься, потому что условия изменились.
И про мотивацию, и про архитектуру, и про кто кому чего должен, и про хорошее тз ;)
А в том, что ты, как родитель, можешь предложить своему ребенку в качестве альтернативы гаджету?
И тут неожиданно выяснится, что большинство родителей альтернативу предложить не могут.
Т.к. сериальчики, свои гаджеты, и прочие радости современного мира. Жопу оторвать лень, а виноват конечно Гугл и Эппл. Ну и школа… ;)
Если вам нужно протестировать поведение Thread.sleep, вопросов нет. Так и надо делать.
Если вы доверяете Thread.sleep, и вам нужно проверить реализацию вашего класса, в котором каким-то образом обыграны настройки расписания, то вам нужно тестировать параметры, передаваемые в Thread.sleep, и которые генерируются из настроек расписания (т.е. протестировать тот код, который написали лично вы). В этом случае, опять же оборачиваете Thread.sleep в отдельный метод, и мокаете его в тестах. Если не убедил, представьте что вместо Thread.sleep, у вас Files.readAllBytes, или new Random().nextInt.
Посыл правильный, реализация куда-то в сторону уехала.
Верно отмечено, тестировать нужно корректность расписания. Оборачиваем System.currentTimeMillis() в отдельный метод в нашем классе, и мокаем его (наш метод) в тестах с любой логикой, которой нужно для тестов.
Что не умоляет (наверно) возможностей time-test, в тех случаях, когда System.currentTimeMillis() зовется где-то в недрах внешней библиотеки, которую сложно отмокать.
— с поддержкой честного ACID, и без оного
— с поддержкой in-memory, и без оного
— с поддержкой шардинга, и без оного
— структуры (реляционные, графы, key-value, timeseries)
— с поддержкой constraints во всех проявлениях, и без оного
— c поддержкой бизнес-логики во всех проявлениях внутри бд, и без оного
— наверно можно еще продолжить
Это только то, что интересно разработчику. И не касались инструментов.
А есть еще operation staff. Есть бизнеса…
Представим, условный Вася хочет купить через интернет нечто. Его перенаправляют с магазина на сайта процессинга. И тут Вася не видит EV-плашки, и думает: «да ну его, даже EV-сертификата нет, пойду поищу другой магазин с нормальным процессингом с нормальным EV-сертификатом». Это так работает?
Или, открываешь ты свой процессинг, и тут тебе регулятор выкатывает простыню законов и правил, и один из пунктов про наличие ev-сертификата. Это так работает?
Чем регламентируется, что нужны веб-ресурсам, обрабатывающим финансовые операции?
Ключевая фраза.
Все остальное — это советы для тех, кто работает в гос секторе (и его аналогах), где формат тендера закреплен законом, и с этим надо как-то жить.
У меня вот тоже в башке полный переворот произошел. И это была не техническая литература…