Например, используйте iso-8601 YYYY-MM-DDThh:mm:ss±hh.
OpenAPI поддерживает RFC 3339, section 5.6. Если не нужны специфичные фишки из iso8601 (периоды или интервалы дат, например), то лучше выбрать первый. А тут можно наглядно увидеть разницу https://ijmacd.github.io/rfc3339-iso8601/
Event Sourcing как архитектурный паттерн, Мартин Фаулер описывал лет 20 тому назад. Паттерн это не сама архитектура и не решение. Скорее просто описание принципа, который можно реализовать как угодно и для чего угодно. Например, его можно обнаружить в Redux из JavaScript с плагином time machine (хотя сам по себе редакс скорее не про это).
Возможно дело не в зарплатах. Рейты у них уже на уровне мировых. Люди из Индии на руководящих должностях встречаются уже повсеместно. Управлять персоналом и торговаться они умеют. Но из-за культурных особенностей работать с ними не всегда комфортно. Все становится проще, когда в вашей команде тоже есть кто-то из Индии - между собой им проще договориться. Замкнутый круг.
Что-то вы слишком упрощаете. Git предлагает решения проблемы управления версиями в распределенной системе. Это довольно навороченная тема даже со стороны науки. Передача файлов лишь технический момент.
Студенты уже не в состоянии сами найти какой-нибудь стартовый туториал по Git?
Вы исходите из позиции профессионального разработчика, для которого man rtfm это увлечение и хлеб.
Допускаю, что для каких-то студентов git просто очередная тема - одна из сотен - препятствие перед заветным словом "зачёт", которые проходятся с единственной мыслью "сдать и забыть".
Потом конечно это аукнется, кто пойдет работать по специальности. Но здесь и сейчас: папки, шмапки - какая разница? Важнее планы на вечер и ближайшее выходные.
В команиях из UK продолжительность рабочего дня по 7 часов (35 в неделю) не редкость. После 16:00 на месте уже ни кого не найти, а если пятница то и раньше. Поэтому 4-х дневка по 32ч это не то чтобы большая потеря.
Хотите денег — ищите женщинулюдей. И будте им полезными
Есть продажи как охота или рыбалка. Можете раскидать дешёвый прикорм, чтобы не скакать как заяц по полям за каждым оленем. Но вряд-ли вы станете тратить на это существенные ресурсы (я думаю каждый может легко для себя определить какой из ресурсов является существенным).
Быть полезным в долгую это скорее что-то из области животноводства. Главное четко понимать, что если вы нанимаетесь коровой за еду, то независимо от количества приносимой пользы в виде молока (и не дай бг шкуры или мяса) вряд-ли сможете претендовать на зарплату даже доярки.
Как пользователь, я хочу, чтобы сайт был доступен в 99,999 процентах случаев, когда я пытаюсь зайти на него, чтобы не испытывать разочарования и не искать другой.
Некоторые НФР могут принципиально влиять на решение. Решения с доступностью 99 и 99,999 будут отличаться по сложности и стоимости как самокат и Бентли.
Если оно нефункционально, то почему это должно меня волновать? Я уверен, что автор той книги уже через страницу разъяснил суть, но данный термин всегда казался мне странным. Я предпочитаю считать нефункциональные требования «ограничениями», которые мы накладываем на систему.
Я смотрю на НФР как на то, чем наш продукт отличается от других, за какие качества выберут именно нас. В итоге это то, что приносит дополнительные деньги или наоборот помогает избежать лишних расходов.
Для решения этого вопроса мы внедрили дизайн ML проектов на разных этапах согласования
Расскажите пожалуйста подробнее, какие этапы вы выделили и в общих чертах DoR/DoD на каждом из них. В какой момент заказчик начинает понимать что конкретно он в итоге получит и за какие деньги, а в какой определяются сроки.
Так когда в хаскеле функция не проходит проверку типов, то разработчики идут искать ошибку в своем коде. А когда в питоне происходит то же самое, то они строчат ишью разработчикам тайпчекеров (и кстати нередко в этом действительно есть смысл).
Вообще вы правы - в математике сложение коммутативно по определению. Но напрограммировать плюс можно как угодно. У @Stefanio есть целая статья про это https://habr.com/ru/post/655059/.
Выход из этой ситуации видится только один - определять последнюю актуальную версию в реестре, записывать ее в pyproject.toml, поднимать версию с помощью poetry version
Некоторые неудобства доставляет тот факт, что формат версий в python PEP 440 и SemVer немного отличаются. Ну и не забывать, что из одной версии исходников можно собрать разные билды. Значит у них должны быть разные версии (подмешав например $CI_JOB_ID или datetime).
Вопрос: что криминального, если я хочу на собесе услышать суть данного паттерна и его применение в реальных условиях?
GoF оставили за скобками как минимум две важные темы: нефункциональные требования и композицию паттернов между собой.
NFR принципиально влияют на способ реализации. В зависимости от требований к надёжности, гарантиям доставки, задержкам, throughput, и т.п. ваш pub-sub может быть, как вы заметили и шматок лапшекода внутри одного метода, и DSL с кодогенератором, и ООП с классами как у GoF, и брокер сообщений на кафках в нескольких датацентрах по всему миру. Т.е. без дополнительных вводных делать можно как угодно. И какой тогда правильный ответ?
Что касается композиции, то те же https://typelevel.org/cats/typeclasses.html дают кусочки решения и конкретные правила что, с чем и как соединять, имея в бэкграунде вполне конкретную математику (у вас нет скалы, перепишите на джаваскрипте, будет плюс-минус то же самое), с возможностью статически проверить решение. GoF в этом смысле как художественная литература, дающая лирические советы как делать правильно, но без каких-либо намеков почему именно так правильно и как это на практике проверять.
GoF в свое время предложили классную идею - документировать типовые решения типовых проблем в дизайне ПО. В качестве иллюстраций они взяли примеры из своего опыта разработки текстового редактора.
Но сообщество по большей части пропустило суть мимо ушей, а иллюстрации восприняло как догмы, бросившись как очумелые внедрять где надо и где не надо, спрашивать на собеседованиях и преподавать в ВУЗах. У итоге хорошая идея превратилась в фарс.
К счастью, у GoF появились последователи, применившие подход к своим доменам в книжках: enterprise integration patterns, reactive design patterns, service design patterns, и т.п. - подальше от программирования и ближе к design или архитектуре, где они и должны быть.
В программировании же их место постепенно отгрызает математика (FP, Category theory, ADT и т.п.), дающая более строгии и надёжные гарантии в плане композиции и валидации решений.
Автор пытается привлечь инфантила призом в виде выбора
Автор пытается привлечь инфантила у свой телеграмм-канал. Для этого нужно давать надежду, что там ему помогут и за него все решат, а не само решение. Решения, как такового, в общем-то может и не быть. Вообще, чем дальше человек от решения, чем больше его голова забита надеждами, тем проще его телеграммить.
OpenAPI поддерживает RFC 3339, section 5.6. Если не нужны специфичные фишки из iso8601 (периоды или интервалы дат, например), то лучше выбрать первый. А тут можно наглядно увидеть разницу https://ijmacd.github.io/rfc3339-iso8601/
Тема хорошо проработана в GraphQL. Мы используем большую часть их рекомендаций и для обычного ReST:
https://github.com/graphql/graphql-spec/blob/main/spec/Section%207%20--%20Response.md
https://github.com/graphql/graphql-over-http/blob/main/spec/GraphQLOverHTTP.md.
Event Sourcing как архитектурный паттерн, Мартин Фаулер описывал лет 20 тому назад. Паттерн это не сама архитектура и не решение. Скорее просто описание принципа, который можно реализовать как угодно и для чего угодно. Например, его можно обнаружить в Redux из JavaScript с плагином time machine (хотя сам по себе редакс скорее не про это).
Возможно дело не в зарплатах. Рейты у них уже на уровне мировых. Люди из Индии на руководящих должностях встречаются уже повсеместно. Управлять персоналом и торговаться они умеют. Но из-за культурных особенностей работать с ними не всегда комфортно. Все становится проще, когда в вашей команде тоже есть кто-то из Индии - между собой им проще договориться. Замкнутый круг.
Что-то вы слишком упрощаете. Git предлагает решения проблемы управления версиями в распределенной системе. Это довольно навороченная тема даже со стороны науки. Передача файлов лишь технический момент.
Вы исходите из позиции профессионального разработчика, для которого man rtfm это увлечение и хлеб.
Допускаю, что для каких-то студентов git просто очередная тема - одна из сотен - препятствие перед заветным словом "зачёт", которые проходятся с единственной мыслью "сдать и забыть".
Потом конечно это аукнется, кто пойдет работать по специальности. Но здесь и сейчас: папки, шмапки - какая разница? Важнее планы на вечер и ближайшее выходные.
В команиях из UK продолжительность рабочего дня по 7 часов (35 в неделю) не редкость. После 16:00 на месте уже ни кого не найти, а если пятница то и раньше. Поэтому 4-х дневка по 32ч это не то чтобы большая потеря.
Найдите работу, где не надо отпрашиваться и задача сводится к предыдущей.
Есть продажи как охота или рыбалка. Можете раскидать дешёвый прикорм, чтобы не скакать как заяц по полям за каждым оленем. Но вряд-ли вы станете тратить на это существенные ресурсы (я думаю каждый может легко для себя определить какой из ресурсов является существенным).
Быть полезным в долгую это скорее что-то из области животноводства. Главное четко понимать, что если вы нанимаетесь коровой за еду, то независимо от количества приносимой пользы в виде молока (и не дай бг шкуры или мяса) вряд-ли сможете претендовать на зарплату даже доярки.
Может на гуманитарных факультетах?
Понятно, читеры это те, кто получил преимущество, не заплатив за это владельцам игры. Корпораци теряют
своиденьги.Некоторые НФР могут принципиально влиять на решение. Решения с доступностью 99 и 99,999 будут отличаться по сложности и стоимости как самокат и Бентли.
Я смотрю на НФР как на то, чем наш продукт отличается от других, за какие качества выберут именно нас. В итоге это то, что приносит дополнительные деньги или наоборот помогает избежать лишних расходов.
Расскажите пожалуйста подробнее, какие этапы вы выделили и в общих чертах DoR/DoD на каждом из них. В какой момент заказчик начинает понимать что конкретно он в итоге получит и за какие деньги, а в какой определяются сроки.
Так когда в хаскеле функция не проходит проверку типов, то разработчики идут искать ошибку в своем коде. А когда в питоне происходит то же самое, то они строчат ишью разработчикам тайпчекеров (и кстати нередко в этом действительно есть смысл).
Вообще вы правы - в математике сложение коммутативно по определению. Но напрограммировать плюс можно как угодно. У @Stefanio есть целая статья про это https://habr.com/ru/post/655059/.
Пример некоммутативного сложения в python: "a" + "b" == "ab", "b" + "a" == "ba"
Можно задавать версии тегами git и вести отдельные истории для разных бранчей и MR. В первом приближении отдаётся на откуп https://pypi.org/project/poetry-dynamic-versioning/ или https://gitversion.net/docs/usage/ci.
Некоторые неудобства доставляет тот факт, что формат версий в python PEP 440 и SemVer немного отличаются. Ну и не забывать, что из одной версии исходников можно собрать разные билды. Значит у них должны быть разные версии (подмешав например $CI_JOB_ID или datetime).
GoF оставили за скобками как минимум две важные темы: нефункциональные требования и композицию паттернов между собой.
NFR принципиально влияют на способ реализации. В зависимости от требований к надёжности, гарантиям доставки, задержкам, throughput, и т.п. ваш pub-sub может быть, как вы заметили и шматок лапшекода внутри одного метода, и DSL с кодогенератором, и ООП с классами как у GoF, и брокер сообщений на кафках в нескольких датацентрах по всему миру. Т.е. без дополнительных вводных делать можно как угодно. И какой тогда правильный ответ?
Что касается композиции, то те же https://typelevel.org/cats/typeclasses.html дают кусочки решения и конкретные правила что, с чем и как соединять, имея в бэкграунде вполне конкретную математику (у вас нет скалы, перепишите на джаваскрипте, будет плюс-минус то же самое), с возможностью статически проверить решение. GoF в этом смысле как художественная литература, дающая лирические советы как делать правильно, но без каких-либо намеков почему именно так правильно и как это на практике проверять.
GoF в свое время предложили классную идею - документировать типовые решения типовых проблем в дизайне ПО. В качестве иллюстраций они взяли примеры из своего опыта разработки текстового редактора.
Но сообщество по большей части пропустило суть мимо ушей, а иллюстрации восприняло как догмы, бросившись как очумелые внедрять где надо и где не надо, спрашивать на собеседованиях и преподавать в ВУЗах. У итоге хорошая идея превратилась в фарс.
К счастью, у GoF появились последователи, применившие подход к своим доменам в книжках: enterprise integration patterns, reactive design patterns, service design patterns, и т.п. - подальше от программирования и ближе к design или архитектуре, где они и должны быть.
В программировании же их место постепенно отгрызает математика (FP, Category theory, ADT и т.п.), дающая более строгии и надёжные гарантии в плане композиции и валидации решений.
Автор пытается привлечь инфантила у свой телеграмм-канал. Для этого нужно давать надежду, что там ему помогут и
за неговсе решат, а не само решение. Решения, как такового, в общем-то может и не быть. Вообще, чем дальше человек от решения, чем больше его голова забита надеждами, тем проще его телеграммить.