И всё же каша скорее благо, чем вред. Кого-то может это и правда стимулирует покупать больше (тут вопросу уже к человеку), но мне выгоднее оплатить покупку картой с кашей и получить обратно какую-то часть, чем оплатить ту же сумму и не получить ничего. Жаль, конечно, что вне РФ это не так распространенно и я в среднем получаю в лучшем случае 1% от трат, но даже это лучше, чем 0.
Он не ошибочен, он менее явный. Допустим, вы удалили WRITER из enum класса, при моей реализацией IDE или алембик ругнётся, что в server_defaultпередаётся то, чего нет, в вашем же случае нигде это не подсветится и может быть легко пропущено.
Во-первых, name, а не value, потому что name вернёт "WRITER" (именно строку), когда как value вернёт "писатель". Во-вторых, не будет никакой ошибки, так как по сути ничего не меняется — вы просто более явно передаёте параметр. Вы бы хоть попробовали, прежде чем минус мне лепить.
Не понял, какое имеет отношение ваш пример со схемой Pydantic к server_default, но вместо Config сейчас используется параметр model_config с ConfigDict.
Для использования этого параметра с ENUM, нужно передавать значение в виде текстового выражения с помощью метода text, который импортируется из SQLAlchemy. Значение ENUM указывается в кавычках как текст, например: "WRITER", а не само значение, такое как ProfessionEnum.WRITER. Это необходимо для корректного выполнения запроса на стороне базы данных.
Но ведь можно просто указать ProfessionEnum.WRITER.name .
В остальном достаточно неплохая статья для новичков.
Ну так это уже и есть желание, разве нет? Второй момент: красота — чисто субъективная вещь, так что неплохо бы заказчику какие-то критерии красивости обозначить, чтобы можно было подогнать под них результат. А то ведь логотип вы красивый сделать сможете (по вашему вкусу), только заказчик взглянет и в манере классика изречёт «а по-моему, ты говно». И тогда перед вами встаёт вопрос, хотите вы угодить заказчику или сделать хорошо работу по вашим критериям красоты, или вообще ничего из этого.
В моей технической практике я сначала узнаю, что хочет получить заказчик в результате выполненной работы. И если я вижу, что его идея достижения цели, мягко говоря, абсурдна, то пытаюсь донести до него это, чтобы он понимал, что это его решение может быть проблемой недостижения цели. И только после этого мы обсуждаем варианты реализации. Но опять — заказчик изначально должен понимать, что он хочет, а не «я хочу сделать сервис и получать деньги», а то с таким запросом мы далеко не уедем.
А расскажите, пожалуйста, какие варианты проверок имеются (желательно бесплатные) и как можно самому это дело проверить (то есть в чём заключается процедура проверки)?
Если во время аудита обнаружатся критические ошибки, которые не позволяют интерфейсу выполнять возложенных на него функций, то клиенты почувствуют радость от того, что проблема найдена, подлежит исправлению и можно будет протестировать новую версию и получить новые результаты. А если аудит покажет, что с интерфейсом всё в полном порядке, клиенты почувствуют облегчение, что мест, где нужно искать проблемы, стало на одно меньше.
Уверены? А может в первом случае человек испытает недовольство, потому что фактически ему нужно было подтверждение, что у него всё сделано хорошо, а не реальный поиск проблем? Или во втором случае подумает, что вы недоработали, раз не нашли ни одного изъяна, и тоже расстроится. Люди иррациональны так-то.
Если во время аудита обнаружатся критические ошибки, которые не позволяют интерфейсу выполнять возложенных на него функций, то клиенты почувствуют радость от того, что проблема найдена, подлежит исправлению и можно будет протестировать новую версию и получить новые результаты. А если аудит покажет, что с интерфейсом всё в полном порядке, клиенты почувствуют облегчение, что мест, где нужно искать проблемы, стало на одно меньше.
Уверены? А может в первом случае человек испытает недовольство, потому что фактически ему нужно было подтверждение, что у него всё сделано хорошо, а не реальный поиск проблем? Или во втором случае подумает, что вы недоработали, раз не нашли ни одного изъяна, и тоже расстроится. Люди иррациональны так-то.
Возникло много вопросов по формированию имени ветки и самих веток.
Работаете вы по таске 123, и в рамках этой таски вам нужно внедрить какую-то новую фичу. Создаём ветку feat/123-blah-blah. Фичу закончили, хотите документацию обновить — предлагается создавать ветку doc/123-blah-blah? В ходе работы с документацией понимаем, что нужно кое-где поправить оформление, предлагается создавать отдельную ветку style/123-blah-blah ? Или идти к PM за таской 124-style-blah и создавать уже с новым номером? Пока переделывали стиль, нашли баг и решили пофиксить — возвращаемся в ветку feat или создаём новую fix?
В общем, к чему я это всё — я не вижу смысла дробить ветки по типам, типы у нас уже есть в заголовке коммита. Скакать между ветками — то ещё удовольствие. Да, есть worktree, но если вы хотите складную структуру коммитов, то важно не забывать обновлять каждую из веток. А если ещё и не один работаете в ветках (такое бывает, да), то запутаться в этом многообразии проще некуда. Может я чего-то не понимаю, но выглядит скорее как bad practice.
И всё же каша скорее благо, чем вред. Кого-то может это и правда стимулирует покупать больше (тут вопросу уже к человеку), но мне выгоднее оплатить покупку картой с кашей и получить обратно какую-то часть, чем оплатить ту же сумму и не получить ничего. Жаль, конечно, что вне РФ это не так распространенно и я в среднем получаю в лучшем случае 1% от трат, но даже это лучше, чем 0.
А я уж думал, что взломали.
Он не ошибочен, он менее явный. Допустим, вы удалили WRITER из enum класса, при моей реализацией IDE или алембик ругнётся, что в
server_defaultпередаётся то, чего нет, в вашем же случае нигде это не подсветится и может быть легко пропущено.Во-первых, name, а не value, потому что name вернёт
"WRITER"(именно строку), когда как value вернёт"писатель". Во-вторых, не будет никакой ошибки, так как по сути ничего не меняется — вы просто более явно передаёте параметр. Вы бы хоть попробовали, прежде чем минус мне лепить.Не понял, какое имеет отношение ваш пример со схемой Pydantic к
server_default, но вместоConfigсейчас используется параметрmodel_configсConfigDict.Но ведь можно просто указать
ProfessionEnum.WRITER.name.В остальном достаточно неплохая статья для новичков.
Ну так это уже и есть желание, разве нет? Второй момент: красота — чисто субъективная вещь, так что неплохо бы заказчику какие-то критерии красивости обозначить, чтобы можно было подогнать под них результат. А то ведь логотип вы красивый сделать сможете (по вашему вкусу), только заказчик взглянет и в манере классика изречёт «а по-моему,
тыговно». И тогда перед вами встаёт вопрос, хотите вы угодить заказчику или сделать хорошо работу по вашим критериям красоты, или вообще ничего из этого.В моей технической практике я сначала узнаю, что хочет получить заказчик в результате выполненной работы. И если я вижу, что его идея достижения цели, мягко говоря, абсурдна, то пытаюсь донести до него это, чтобы он понимал, что это его решение может быть проблемой недостижения цели. И только после этого мы обсуждаем варианты реализации. Но опять — заказчик изначально должен понимать, что он хочет, а не «я хочу сделать сервис и получать деньги», а то с таким запросом мы далеко не уедем.
А кто тогда знает и, главное, кто должен знать — не заказчик ли? Как исполнитель удовлетворит потребность заказчика, если она не была озвучена?
Кто определяет, что полезно, а что — нет? И что делать, если конкретно тебе это не полезно?
Насколько знаю, просмотр тытрубы не является нарушением закона. Более того, выезд из страны тоже никто пока не ограничил, так что всё в ваших руках.
Почему были? Университеты стали прятать свои лекции?
Как дела с этим у GitLab и Bitbucket?
Потому что «Назад в будущее».
А расскажите, пожалуйста, какие варианты проверок имеются (желательно бесплатные) и как можно самому это дело проверить (то есть в чём заключается процедура проверки)?
Не понял, а зачем автор ездил в Москву, онлайн сдать нельзя? И сколько стоит попытка, есть ли ограничения?
Крайне не рекомендую множить на 2 виртуальные ядра (в моём случае с EC2), поскольку виртуальная машина перестаёт вывозить.
Кстати, насколько нормально аннотировать
selfв аргументах функции класса? Имею ввиду такой вот случай:Для меня выглядит, как нечто излишнее, ведь мы и так знаем, что скрывает под собой
self.Уверены? А может в первом случае человек испытает недовольство, потому что фактически ему нужно было подтверждение, что у него всё сделано хорошо, а не реальный поиск проблем? Или во втором случае подумает, что вы недоработали, раз не нашли ни одного изъяна, и тоже расстроится. Люди иррациональны так-то.
Уверены? А может в первом случае человек испытает недовольство, потому что фактически ему нужно было подтверждение, что у него всё сделано хорошо, а не реальный поиск проблем? Или во втором случае подумает, что вы недоработали, раз не нашли ни одного изъяна, и тоже расстроится. Люди иррациональны так-то.
Возникло много вопросов по формированию имени ветки и самих веток.
Работаете вы по таске 123, и в рамках этой таски вам нужно внедрить какую-то новую фичу. Создаём ветку
feat/123-blah-blah. Фичу закончили, хотите документацию обновить — предлагается создавать веткуdoc/123-blah-blah? В ходе работы с документацией понимаем, что нужно кое-где поправить оформление, предлагается создавать отдельную веткуstyle/123-blah-blah? Или идти к PM за таской124-style-blahи создавать уже с новым номером? Пока переделывали стиль, нашли баг и решили пофиксить — возвращаемся в веткуfeatили создаём новуюfix?В общем, к чему я это всё — я не вижу смысла дробить ветки по типам, типы у нас уже есть в заголовке коммита. Скакать между ветками — то ещё удовольствие. Да, есть worktree, но если вы хотите складную структуру коммитов, то важно не забывать обновлять каждую из веток. А если ещё и не один работаете в ветках (такое бывает, да), то запутаться в этом многообразии проще некуда. Может я чего-то не понимаю, но выглядит скорее как bad practice.
Я надеюсь, вы видели те гаражи, где они начинали. У некоторых жителей постсоветского пространства квартиры хуже выглядят.