По моему скромному опыту в спортивном программировании большинство задач «синтетические задачи с подставой», то есть важное - правильно понять постановку, увидеть граничные случаи и ограничения (они тоже часто часть задачи). То есть правильно сразу отбросить кривые варианты решения и чисто запрограммировать ожидаемое организаторами решение
А потом LG объявит о присоединении к санкциям за.... Да не важно за что - хоть за запрет неправильной стрижки котиков, и умный дом по подписке превратится в тыкву.
Подписка приемлема только для того от чего легко отказаться, использовать её в областях где нужна стабильность и предсказуемость это верх инфантильности
Думаю, речь шла о двойной зарплате рабочего, а не айтишника. ПыСы - зарплата хорошего слесаря/сварщика/токаря ненамного меньше зарплаты среднего регионального IT.
Попробуйте отказаться от мантры что разработчики это священные коровы которых обижать (и уж тем более наказывать) нельзя. Человек должен отвечать за свои слова. Тогда в описании второго случая внезапно второе предложение исчезает, а результат получается
Юридически это выглядит так - есл иводитель не согласен с инспектором, то инспектор оформляет протокол о нарушении, этот протокол передается в суд и открывается административное производство, назначается дата и время судебного заседания, овтетчик может приложить дополнительные материалы к делу, судья выносит решение, если ответчик не согласен с решением судьи, оно может быть обжаловано в стандартном установленом законом порядке.
То есть инспектор не может просто взять и выписать штраф без согласия нарушителя. Это незаконно.
Но для упрощения процедур если нарушитель согласен, то инспектор оформляет не протокол а постановление о нарушении, и тогда админстративное производство не начинается и всё проходит в упрощеном порядке. Но даже тогда такое постановление можно обжаловать в ГИБДД (я неправильно понял инспектора и это вообще был не я) и тогда процесс возвращается на штатный длинный маршрут (административное производство)
Не-а. Сотрудник ГИБДД может составить протокол о нарушении, но решение будет выносить судья (если водитель не согласен с определением нарушения сотрудником ГИБДД).
Но и злоупотреблять классами там, где достаточно простого хэша, или структуры — тоже.
Крайне сомнительный совет. Если у вас есть некоторая сущность с вполне себе определенными полями, её практически однозначно нужно выводить в класс, хотя бы ради того, чтобы потом не пытаться понять "а какие именно ключи содержатся в этом хэше в этом месте".
Задача хэша - именно хранить хэш-таблицу "ключ-значение" а не упорядоченную структуру фиксированного типа, поэтому если где-то для хранения экземпляра доменной модели используется хэш, это сразу сигнал того, что вероятно тут где-то откровенный мисдизайн
Ну и логичное следствие, что хранить мапинги типа логин -> User в хэше - нормально и правильно. А за хранить поля юзера в хэш-таблице как в примере - сразу бить по рукам.
P.S.: структура как "чуть более организованый хэш" тоже не слишком хорошая идея.
Ну да, а еще можно добраться до локальных переменных вызывающего кода через stack frame, и вообще даже сдуру известно что сломать. Но это надо делать специально, и тут уж ССЗБ уровня "а еще я могу используя указатель на объект по смещению прочесть VMT и напрямую вызвать методы"
Если вы о части модуля persistence, то её не нужно тестировать. В ней нет нетривиальной бизнес-логики, зачем там тесты?
У вас есть некий метод, который возвращает что-то.
Значит, у вас должен быть тест который проверяет корректность поведения.
И стек вызова этого кода заходит в ваш модуль persistence.
Это означает, что для прохождения юнит-теста и доказательства работы вашего кода, вы должны засетапить источник данных и залить в него эталонные данные, чтобы впоследствии получить результат на основании этих данных и сверить фактический ответ с ожидаемым.
Это не обсуждается, ибо это просто базовое требование.
А теперь просто говорим "наш продукт работает с базой в MSSQL и MongoDB". И всё - теперь вы для юнит-тестов должны притащить MSSQL и монгу. Можно конечно сказать "ой да мы это интеграционными тестами проверим" - но как правило каждый раз когда такое говорится это всё уходит в вечный техдолг.
Зачем?
Зачем что?
Зачем натягивать функции поверх глобальных объектов?
Ну затем, что у вас нет контекста приложения в явном виде.
Где лежит ваша сессия к базе, чтобы её можно было проверить и при необходимости реконнектнуть? Ну конечно, в persistence._SESSION или чем-то подобном. Где лежат маппинги классов к таблицам? Ой да это мы вообще, скопировали пример из документации (но на самом деле тоже в какой-то глобальной переменной). И вот ваш код зависит от кучи глобальных объектов и набит сайдэффектами.
Зачем натягивать поверх синглетонов?
Ну вот вы написали "тривиальных функций" в persistence. А теперь поступило требование заказчика - не SQL'ный бакэнд (вот у него такая техническая политика, у него всё в тарантуле лежит). И теперь у вас две реализации persistence, одна через ORM а другая через API (ибо нет тарантула в вашем ORM). И как вы будете выбирать бакэнд?
И вы начинаете приседать с бубном - вы пишете persistece_sql и persistence_nosql, и собственно ваш persistence перерождается - в нем вы загружаете один из реальных модулей и все ваши функции просто проксируются на загруженный модуль.
Но потом в процесс врывается статический линтер, который требует от вас задекларировать все сигнатуры превентивно (да-да, в динамически загруженном юните символ с точки зрентия статического анализа то Any) и вы наконец-то отказываетесь от модулей и пишете реализации в классах и называете их "драйверами". Но опять же - поскольку контекста приложения как сущности у вас нет, вы создаете совместно используемый глобальный репозиторий ваших объектов. А так как вы уже наваяли в куче мест походов в модель через функции - вы переписываете все функции чтобы они ходили на ваш глобальный статический репозиторий.
Само наличие модуля persistence и есть проблема. Вот смотрите - вам нужно оттестировать функцию get_users_list. Какие есть варианты?
Первый - создать тестовую базу, сконфигурировать ваш модуль так чтобы он на неё смотрел и прогнать тест. Минусы - а если база это «чуть больше чем sql” - например какая нибудь nosql, то вам нужно для теста сконфигурировать еще и сервис БД.
Второй вариант - вы мокаете функции модуля persistence. Но потом вы меняете какую - нибудь функцию, например поменяв семантику параметра - но ваши тесты не ломаются потому что ходят на моки которые реализуют старую семантику, а код ломается потому полагается на старую семантику а реализация использует новую.
А задача сделать несколько бакэндов, например sql и nosql превращается либо в пляски с бубном вокруг динамической загрузки модулей в рантайме, либо в натягивание статиков поверх синглетона реального бакэнда
И более того, такие же настройки вам предстоит делать перед любым тестом, который хоть как то обращается к вашим функциям которые ходят в базу. А если вы для облегчения жизни решите мокать свои функции - то однажды потом, сломав свои функции, вы не сломаете тесты которые на них опирались - ведь вы используете моки, а они то как раз сохранили старое поведение.
Не знаю почему, но это очень напоминает незабвенный пост Бармина про установку SCO Unix
А разве такой есть? Вроде бы были Северный Ледовитый и Атлантический, или в географии тоже появились небинарные сущности?
WebAuthn?! Еще один шаг в правильном направлении. Лучше поздно чем никогда
По моему скромному опыту в спортивном программировании большинство задач «синтетические задачи с подставой», то есть важное - правильно понять постановку, увидеть граничные случаи и ограничения (они тоже часто часть задачи). То есть правильно сразу отбросить кривые варианты решения и чисто запрограммировать ожидаемое организаторами решение
Вы заменили не "системный вызов", вы подменили библиотечный символ (функцию read в данном случае).
Это вообще ни в коем случае не одно и то же.
Системный вызов никуда не делся, он реализован в ядре.
Ой, кажется trusted computing начал показывать свои зубки? Как же так, нам ведь про такое не говорили. Хотя погодите...
А потом LG объявит о присоединении к санкциям за.... Да не важно за что - хоть за запрет неправильной стрижки котиков, и умный дом по подписке превратится в тыкву.
Подписка приемлема только для того от чего легко отказаться, использовать её в областях где нужна стабильность и предсказуемость это верх инфантильности
А можно было просто написать - "применяйте хэш-индексы там где нужен поиск по ключу, он очень хорош в этом, а для всего остального он не подходит"
Думаю, речь шла о двойной зарплате рабочего, а не айтишника. ПыСы - зарплата хорошего слесаря/сварщика/токаря ненамного меньше зарплаты среднего регионального IT.
Попробуйте отказаться от мантры что разработчики это священные коровы которых обижать (и уж тем более наказывать) нельзя. Человек должен отвечать за свои слова. Тогда в описании второго случая внезапно второе предложение исчезает, а результат получается
Подозреваю, что тарантул условно "тогда" и "сейчас" очень сильно отличался по набору фич.
Юридически это выглядит так - есл иводитель не согласен с инспектором, то инспектор оформляет протокол о нарушении, этот протокол передается в суд и открывается административное производство, назначается дата и время судебного заседания, овтетчик может приложить дополнительные материалы к делу, судья выносит решение, если ответчик не согласен с решением судьи, оно может быть обжаловано в стандартном установленом законом порядке.
То есть инспектор не может просто взять и выписать штраф без согласия нарушителя. Это незаконно.
Но для упрощения процедур если нарушитель согласен, то инспектор оформляет не протокол а постановление о нарушении, и тогда админстративное производство не начинается и всё проходит в упрощеном порядке. Но даже тогда такое постановление можно обжаловать в ГИБДД (я неправильно понял инспектора и это вообще был не я) и тогда процесс возвращается на штатный длинный маршрут (административное производство)
Не-а. Сотрудник ГИБДД может составить протокол о нарушении, но решение будет выносить судья (если водитель не согласен с определением нарушения сотрудником ГИБДД).
Крайне сомнительный совет. Если у вас есть некоторая сущность с вполне себе определенными полями, её практически однозначно нужно выводить в класс, хотя бы ради того, чтобы потом не пытаться понять "а какие именно ключи содержатся в этом хэше в этом месте".
Задача хэша - именно хранить хэш-таблицу "ключ-значение" а не упорядоченную структуру фиксированного типа, поэтому если где-то для хранения экземпляра доменной модели используется хэш, это сразу сигнал того, что вероятно тут где-то откровенный мисдизайн
Ну и логичное следствие, что хранить мапинги типа логин -> User в хэше - нормально и правильно. А за хранить поля юзера в хэш-таблице как в примере - сразу бить по рукам.
P.S.: структура как "чуть более организованый хэш" тоже не слишком хорошая идея.
Не ip а ip4?
Ну да, а еще можно добраться до локальных переменных вызывающего кода через stack frame, и вообще даже сдуру известно что сломать. Но это надо делать специально, и тут уж ССЗБ уровня "а еще я могу используя указатель на объект по смещению прочесть VMT и напрямую вызвать методы"
Но есть name mangling через префикс двойного подчеркивания, типа __myattr
У вас есть некий метод, который возвращает что-то.
Значит, у вас должен быть тест который проверяет корректность поведения.
И стек вызова этого кода заходит в ваш модуль persistence.
Это означает, что для прохождения юнит-теста и доказательства работы вашего кода, вы должны засетапить источник данных и залить в него эталонные данные, чтобы впоследствии получить результат на основании этих данных и сверить фактический ответ с ожидаемым.
Это не обсуждается, ибо это просто базовое требование.
А теперь просто говорим "наш продукт работает с базой в MSSQL и MongoDB". И всё - теперь вы для юнит-тестов должны притащить MSSQL и монгу. Можно конечно сказать "ой да мы это интеграционными тестами проверим" - но как правило каждый раз когда такое говорится это всё уходит в вечный техдолг.
Зачем что?
Зачем натягивать функции поверх глобальных объектов?
Ну затем, что у вас нет контекста приложения в явном виде.
Где лежит ваша сессия к базе, чтобы её можно было проверить и при необходимости реконнектнуть? Ну конечно, в persistence._SESSION или чем-то подобном. Где лежат маппинги классов к таблицам? Ой да это мы вообще, скопировали пример из документации (но на самом деле тоже в какой-то глобальной переменной). И вот ваш код зависит от кучи глобальных объектов и набит сайдэффектами.
Зачем натягивать поверх синглетонов?
Ну вот вы написали "тривиальных функций" в persistence. А теперь поступило требование заказчика - не SQL'ный бакэнд (вот у него такая техническая политика, у него всё в тарантуле лежит). И теперь у вас две реализации persistence, одна через ORM а другая через API (ибо нет тарантула в вашем ORM). И как вы будете выбирать бакэнд?
И вы начинаете приседать с бубном - вы пишете persistece_sql и persistence_nosql, и собственно ваш persistence перерождается - в нем вы загружаете один из реальных модулей и все ваши функции просто проксируются на загруженный модуль.
Но потом в процесс врывается статический линтер, который требует от вас задекларировать все сигнатуры превентивно (да-да, в динамически загруженном юните символ с точки зрентия статического анализа то Any) и вы наконец-то отказываетесь от модулей и пишете реализации в классах и называете их "драйверами". Но опять же - поскольку контекста приложения как сущности у вас нет, вы создаете совместно используемый глобальный репозиторий ваших объектов. А так как вы уже наваяли в куче мест походов в модель через функции - вы переписываете все функции чтобы они ходили на ваш глобальный статический репозиторий.
Вполне типовые грабли.
Само наличие модуля persistence и есть проблема. Вот смотрите - вам нужно оттестировать функцию get_users_list. Какие есть варианты?
Первый - создать тестовую базу, сконфигурировать ваш модуль так чтобы он на неё смотрел и прогнать тест. Минусы - а если база это «чуть больше чем sql” - например какая нибудь nosql, то вам нужно для теста сконфигурировать еще и сервис БД.
Второй вариант - вы мокаете функции модуля persistence. Но потом вы меняете какую - нибудь функцию, например поменяв семантику параметра - но ваши тесты не ломаются потому что ходят на моки которые реализуют старую семантику, а код ломается потому полагается на старую семантику а реализация использует новую.
А задача сделать несколько бакэндов, например sql и nosql превращается либо в пляски с бубном вокруг динамической загрузки модулей в рантайме, либо в натягивание статиков поверх синглетона реального бакэнда
И более того, такие же настройки вам предстоит делать перед любым тестом, который хоть как то обращается к вашим функциям которые ходят в базу. А если вы для облегчения жизни решите мокать свои функции - то однажды потом, сломав свои функции, вы не сломаете тесты которые на них опирались - ведь вы используете моки, а они то как раз сохранили старое поведение.