Комментарии 8
я получил на почту заявление на отпуск от своего коллеги на один месяц
Это действительно неприятно. Хотя решаемо.
1) Брать расписку, что гребец будет доступен в отпуске 7*24, и особо тяжкие таски будет решать обязан. Ибо месяц отпуска это уж очень много, независимо от обстоятельств. Не согласится - отпуск с последующим увольнением решит проблему. Лично я был в такой ситуации - именно как сотрудник. Пришлось отъехать далеко и на долго. В виду своей ответственности - вопрос о моей доступности даже не поднимался с начальством. Критичные таски мною закрывались удаленно хоть и неопреативно, но относительно вовремя.
2) Делегировать весь код другому коллеге (если последний конечно в наличии). А вообще такие вещи (отпуск на месяц) должны сообщаться заранее, хотя бы за 3 месяца, чтобы можно было всё качественно принять/передать.
Склоняюсь всё-таки к первому варианту.
Ужас какой! Крепостное право же отменили давно, зачем так жестоко? Первый пункт просто жесть какая-то.
Насчёт второго. Мне кажется что переваливание работы с одного на другого пользы всё равно не принесёт. Либо код будет отстой, либо времени на это уйдёт туча, либо коллега будет демотивирован. Так или иначе, результат будет ужасный.
Речь идёт не о переваливании работы "за спасибо", а о делегировании на время длительного отсутствия, разумеется не за бесплатно, иначе, выражаясь вашими словами "результат будет ужасным". Переваливание и делегирование - это разные вещи.
Насколько я знаю, по законодательству, подряд больше 2-х недель отпуска не полагается (не уверен, но всё же), всё что сверху - по договоренности. Поэтому, если Компания пошла на встречу сотруднику, то и сотрудник должен быть лояльным компании. Справедливо, не так ли?
Грамотное делегирование способно закрыть до 90% проблем и тасков, во время отсутствия основного держателя роли. Ключевые позиции, тем более в ИТ, должны быть "redundant". Иначе в последствии вам опять придётся разгребать чужой код по ночам и писать очередную статью о том, как вы "вынесли" пользу из этого.
На счёт крепостного права - да его отменили, но это совсем другое - там человек был рабом 7*24. В вашей же ситуации речь идет только о его доступности для консультации по критичным кейсам. Разница, думаю, очевидна. Свой месяц сотрудник пусть гуляет "на все четыре", но для ежедневного 15-минутного созвона в строго назначенное время будь любезен оставаться доступным. И это абсолютная норма. Не хватит 15-ти минут, увеличьте окно до часа, никто от этого сильно не пострадает. Потом сочтётесь.
С другой стороны, когда ключевой человек отъезжает на месяц, без гарантии доступности - это большой стресс для организации, который в последствии придётся разгребать его коллегам, а ответственность - начальству. Спасибо ему (сотруднику) за это точно никто не скажет, а вот репутация этого сотрудника конкретно пострадает. По крайней мере у меня бы точно конкретно подгорело, если бы условный коллега Иван Пупкин свалил на месяц в кругосветку, а начальство "вежливо" попросило поовертаймить за Ивана "за спасибо", тем более если я слабокомпетентен в его обязанностях. Это и есть переваливание, я через это регулярно проходил. Раз этак на "надцатый" решилось просто - после неоднократных предупреждений помахал дяде ручкой. Дядя еще раз обещал больше так не делать, но было уже поздно, т.к. более сладкий оффер замаячил на горизонте. Но это другая история.
Если уходящий сотрудник не идёт на встречу, и не готов выделить 15 минут своего "драгоценного" отпускного времени, то в будущем, конечно же, стОит подумать о его замене на более лояльного кандидата. Это нелояльный сотрудник, и в дальнейших ситуациях он тоже может подвести.
на Go или, не дай Бог, PHP
А вот тут обидно было)
Обратите внимание на новомодный GraphQL, тут про вопрос единой точкой входа для всех запросов и счета их тяжесть и времени для обработки (тут и схема документаций от и до, и типизация и подписатся на события с сервера можно итд)
Также советую взглянуть на Pydantic как замена механизма сериализации, дык бонусом придёт и аннотаций типов и будет еще проще генерить тесты итд
а чтобы весь этот компот связать с Django есть вдохновленным Fastapi реализация для джанги django-ninja
вдобавок можно глянуть на Prisma и Hasura чтобы еще меньше делать магию руками а использовать чужой труд
Полезные ссылки:
Фрагменты
Django-Ninja
Hasura
Магия документаций и интроспекций
Про GraphQL
Prisma
Обратите внимание на новомодный GraphQL
Я прям ждал этого комментария. Начнём с простого - переписывать все проекты и код на GraphQL, просто потому что он модный - дурная практика. Схему так же придётся передавать, правда есть одно "но". Сейчас мы можем эту схему модифицировать, чтобы определить что нужно или ненужно видеть конкретному пользователю "на лету". С GraphQL мы этого уже не сможем сделать. А если бы и могли, то тут приходит другой момент в виде принципа работы с данными в стиле REST API, который для интеграции даже с bash'ем подходит, в отличии от GraphQL.
Проще говоря, это решение во многом уступит на выходе для наших задач, по сравнению с OpenAPI + DRF, а гемороя прибавит.
Однако, я не хочу чтобы вы думали, будто я против GraphQL. Это вполне себе годное решение для определённых задач и на базе него можно так же реализовать подобное решение. Но конкретно для эволюционного подхода развития проектов с текущими требованиями это не подходит.
Мы же почему хотим сделать NPM пакет с фронтовой частью. Постепенно, мы приведём код там к такому состоянию, что можно будет переписать логику под конкретный способ взаимодействия с большим количеством различных API на разных языках. Например, очень хочется подключить FastAPI+Pydantic, уверен что есть что-то удобное на Golang.
а чтобы весь этот компот связать с Django есть вдохновленным Fastapi реализация для джанги django-ninja
Мсье знает толк в извращениях...
чтобы еще меньше делать магию руками а использовать чужой труд
Я за то, чтобы держать баланс в этом вопросе. Если сейчас мы контролируем эту связку и можем просто форкнуть или помочь какому-то одному из проектов, контролируем зависимости и т.д., то с готовыми проектами всегда беда с поддержкой. Так наша совесть чиста перед заказчиками, что их сервисы с актуальными зависимостями и проверенными пакетами, а что происходит в чужом продукте мы не можем гарантировать им.
Если подвести итог, то вы накинули очень много годных идей, которые можно применить в каком-то другом проекте с подходящими под стек задачами, но нам пока не актуально.
Почитал то, что у вас получилось.
Несомненно, была проделана большая работа, на своей работе делали нечто подобное, использовав cookiecutter. От себя хочу посоветовать пару вещей:
Один сеттингс файл это конечно ужас. Посмотрите в сторону django-split-settings, нам это помогло для разбития конфига на несколько файлов, для читаемости.
Есть некоторые архаичные вещи, такие, как settings.ini, который, как я вижу, совсем не используется. Провести бы рефакторинг всего проекта на поиск таких артефактов.
Взгляните на pre-commit. Позволит вам запускать все линтеры разом, в том числе для js кода, несмотря на то, что библиотека для питона.
В приложении защиты линтеры по вашему желанию. Хотелось бы иметь более гибкий инструмент, чтобы он использовался и вне вашей организации. Пока он заточен именно под неё.
Скорее совет. Вынесите BModel как плагин для джанги, отдельно от создания шаблона. Увеличит заинтересованность сторонних пользователей
Ну и так, пока последнее, я так понял, что BModel это аналог компонента на vuejs, где всё находится в одном месте. Это конечно прикольно, но, имхо, слишком перегружено. Как вы правильно отметили - из за такой высокой абстракции сложно делать что то более настраиваемое. Я бы подумал в эту сторону, как развитие проекта. Например, в сторону DI, как работает сам drf.
Спасибо за развёрнутый комментарий и советы. Приятно получать такие комментарии как и дельные советы.
Руки не доходят. Вообще хочу прям лютую магию сделать на Cython или на крайний случай C-API, с ленивой инициализацией некоторых компонентов. Для некоторых кейсов это было бы очень полезно. Но в целом разбить на части нужно, просто нежно. Думаю так же сделать сам конфиг plug-able, чтобы какие-то части просто менять, а не делать ужасный import.
settings.ini ещё как используется. Может я вас не так понял, но именно им конфиг и настраивается. Если вы про тот, что в корне проекта, то да - его тоже надо доработать и возможно туда default values вынести. Рефакторинг большой я запланировал на следующий мажорный релиз, потому что надо будет убрать ооооочень много legacy.
Зачем? Команда tox в корне проекта прекрасно работает. Кому надо, те могут это сделать. Мы пользы от этого не увидели (хотя бы потому что тесты не сильно быстрые, а грузят проц весьма), потому что у нас всё в CI проверяется и культура выстроена на git flow (сокращённый для этого проекта).
Если вы про сам vstutils, то... Ну как бы мы под себя и делали) А внутри проектов каждый может сделать под себя индивидуально. Шаблоны трудновато поддерживать, но думаю это не такая большая проблема.
А в чём профит? Сам по себе BModel не содержит какой-то полезной функциональности в принципе. Всё живёт в метаклассе, который наверное было бы сложно да и бессмысленно отделять от экосистемы. Да и лично нам станет это труднее поддерживать.
Ну... Наверное сейчас даже правильнее сравнивать vstutils и nuxt (хоть и основан на Vue, но всё же выше уровнем), где компонент это страница. В этом сама философия. Чтобы более гибко делать, мы просто выделили функцию, которая принимает модель и набор метапараметров, которые нужно перегрузить. Так мы решили проблему гибкости. Всё же мы чуть выше по уровню абстракции к DRF, поэтому не уверен, что нам подойдёт на 100%. А вот система плагинов и модулей как в nuxt у нас зашла хорошо и думаю это направление дальше и развивать.
Публикации
История одного CRUD'а