О, прикольно. Спасибо@Dmitry_Dor, я чёт раньше не задумывался, что очередную статью пишу в ворде и не публикую тут, потому что избегаю мороки с редактором...
По моей ссылке на PyCon надо не читать, а смотреть про то, как чел рассказывает и показывает что врожденный pickle не работает при передаче fc между процессами, и какой костыль они соорудили в библиотеке dill, чтобы сделать это возможным.
В стилистике fc написан FastAPI, благодаря чему он не работает в интеграционных тестах с использованием multiprocessing и авторам Fastapi понадобилось соорудить целый доп класс для тестов. дискуссия по этому поводу тут: https://github.com/fastapi/fastapi/discussions/10213
@Kanut не думаю, что покупали. Когда я работал в "Medical observations data-lake" мы данные передавали, и сами запрашивали. Для медицинской сферы есть доступ к условно обезличенным бесплатным датасетам очень высокого качества, без аугментаций. Условно обезличенные потому, что там только имени/адреса нет... но тоже восстанавливаемо при небольших усилиях.
Не стоит использовать function composition. Они не обрабатываются стандартным pickle и потому не могут быть переданы на выполнение в соседний поток или процесс. Больше тут: The Ghosts of Distant Objects | PyCon Lithuania 2024 https://pycon.lt/2024/talks/YUXXZS
Подкину идею, зачем может пригодиться API gateway: для обеспечения стабильной работы сервисов при добавлении версионирования RestAPI. Внутри у вас стандартные api/v1/service, api/v2/service... внешний url api/service + version in headers.
Ну и, конечно, незаменимая штука для обработки ошибок. В случае, когда api/v100500/service выдаст 404, api-geteway может попробовать исправить ошибку и попробовать что то вернуть пользователю.
Кстати, в конечном итоге создание API gateway - это вынесение задачи роутинга в отдельный сервис и все. Не важно, монолит это или много микросервисов.
Можно, конечно, AI использовать, но можно и vue-i18n-extract поставить, который создает файлы методом статического анализа, поскольку $t(message) уже определены. В этом плане я больше доверяю функции, чем AI генератору текста.
Файлы на перевод мы отдаем переводчикам, у них свои AI на переводы, и свои промпты, более заточенные на перевод.
А вот сборку мест с непереведенными статическими текстами можно запросить: "проверь код на наличие статических текстов, которые видны или будут показаны пользователю пока приложение работает...<желаемое действие>".
Cуть в том, что часто глаз "замыливается" и в проекте с 2500 файлов компонентов нет-нет да и проскочит статика, не помеченная на перевод, т.е. не завернутая в $t(). Тут AI действительно хороший помощник.
P.s. тут на хабре есть гениальная статья о локализации. Там говорят, что кроме текстов, надо еще и картинки переводить/адаптировать. Я с этим очень согласен, но до заказа перерисовки картинок наш проект еще не дорос.
А я вот мемчики зашел посмотреть, а тут тексты на полэкрана каждый. Очень отвлекает!
А по теме переключения - рабочий кабинет и/или рабочая форма. Одел - "пошел на работу". Снял - папа дома. И когда дверь закрыл на ключ - как то и голова переключается с работы на жизнь и наоборот.
«Как я ходил по тонкому льду на тренинге по публичным выступлениям»
Что ходил, написал. А как ходил-то? Так и не написал. :(
Ошибки ТОП-3: Войти и встать неправильно - забиться в угол.
Сколько конференций посетил как спикер - такого ни разу не видел. Всегда либо крест на полу, где стоять, либо отмечено, где можно находиться. Модератор поставит на место, если выйдешь.
А вот бегать по сцене, это да... этим грешат очень многие, даже известные докладчики.
Ну и кстати, а где самая главная ошибка: "не подготовился"?
@TheScienceVictor200 - спасибо, кое что взял. Скорее из первой статьи, чем отсюда, но, все равно, спасибо.
Мне как поклоннику OOP в Python интересно, это действительно наше будущее - понимание как использовать нейронки вкупе с непониманием как создать инстанс простого класса в Python: я про def create_modelи etc...
решил адаптировать и интегрировать наиболее полезные и востребованные решения основываясь на своем опыте работы с Django.
Я уж настроился... и тут, неожиданно:
Админ-панель. Для удобного управления данными мы интегрировали Flask-Admin
а чего так то? :(
P.s. Лайкнул, потому как сам использую подобные идеи. Рекомендую подглядеть, как в Django сделали async as_view(), и еще можно подглядеть, как реализован CBV в упомянутых FastApi-Utils
лучшее, что я читал написанное именно в django стилистике - Django Design Patterns and Best Practices: Ravindran, Arun. Популярная же Two scoops намного менее Django-way книжка. Мне даже с автором удалось пообщаться лично в этом году, но это не делает ее лучше.
SVG это статик файл, пока ты его не меняешь динамически. Но как только ты сохранишь SVG как шаблон(template) с разметкой, куда ты вставляешь динамические данные и, вуаля, уже другая задача. Правда шаблоны тоже стоит хранить статикой. :)
Поскольку SVG это векторный формат, то я храню данные для объектов (class Flowable) которые рендерю через reportlab в SVG.
Со стат файлами надо работать через веб сервер. Да и хранить поближе к клиенту на CDN. Этого в статье нет. Но это стоит знать и использовать.
А по поводу практик - в проде чего только не бывает. Например код python хранят в базе и запускают по запросу через eval/exec. Или в Yaml только настройки, а потом стартуют автогенерацию кода согласно настройкам. Страшные вещи...
@Maxim_from_HW Огромное спасибо за очень взвешенную статью. Несравнимо лучше https://habr.com/ru/articles/837630/.
Чуток споткнулся о ваш собственный testcase, особенно когда в django есть "TestCase", "TransactionTestCase", "SimpleTestCase", "LiveServerTestCase", а так же не документированный SeleniumTestCase. Но видать так было проще.
Ну и объяснение отличия setUpTestData() и def setUpClass() не верное. Первое вызывается внутри второго, после проверок готовности базы данных и загрузки фикстур. (row 1466 django\test\testcases.py). в итоге setUpTestData просто способ что-либо еще сделать после того как масса тестовых данных попала в базу но перед запуском тестов.
Спасибо так же за общие замечания про тестирование, вот бы все тесто-авторы про это знали! Буду давать своим новичкам это статью для ознакомления! Успехов в тестировании!
Я никогда не рассматривал выступления как обязанность
Ну, вероятно, это потому, что этого нет в обязанностях. На некоторых должностях это входит в состав деятельности.
А если по делу - выступаю довольно давно, в основном по Европе, но было уже 2 доклада в Индии. По опыту могу сказать, что никакой программный комитет нормальной конференции не "подсказывает, в какую сторону развить идею". Доклад либо одобрен либо нет.
Если у спикера есть сомнения в своем докладе, который УЖЕ одобрен, он может запросить помощь ментора, так я помогал некоторым начинающим спикерам для подготовки к DjangoCon EU или EuroPython и сам запрашивал помощь для доклада в DjangoCon US и PyCon DE
Так вот, если тема неинтересна голосующему коммьюнити или не входит в список одобренных тем планируемой конференции, то не важно, насколько отстоялось в голове или bullshit-test успешен. Тема так и останется в списке тем, никогда не ставших докладами. Обычно, конкуренция на доклады около 7-12 докладов на один тайм слот.
В качестве основной рекомендации: для тренировки своих спикерских навыков или проверки интересности темы - на конференциях есть lighning-talks. И везде, где это возможно, надо в lighning-talks участвовать: сфейлить невозможно, потому что ни у кого в зале нет ожиданий, зал поддержит, если что-то пойдет криво, и реакция зала - отличный тест для проверки актуальности темы.
Судя по комментариям, разработчики frontend на хабре более молодые и резкие :)
А по делу - не важно, framework ли или набор скриптов выбран как инструмент, но его НАДО использовать если он упрощает и/или организует мою работу и позволяет выполнить мои задачи быстрее и легче.
Я попробовал много предлагаемых пакетов. Основными были Jquery, React, Vue но не потому, что я не знаю остальные, а потому, что на тех проектах, где я работал, это уже было.
Два года назад на Vue конгрессе я познакомился с Deno.Fresh и это удивительно, как быстро он мне зашел сам по себе. Например до этого я пробовал $mol, прости господи. И это была $боль. А тут pReact, реактовый или vue подход при создании "островов" на выбор, и плюс простой интерфейс для backend части. Пару найденных мною isuue поправили за несколько недель.
В общем, для экспериментов я сейчас играю в deno.fresh. А для работы использую тот фреймворк/js-пакет, что уже выбран в проекте.
О, прикольно. Спасибо @Dmitry_Dor, я чёт раньше не задумывался, что очередную статью пишу в ворде и не публикую тут, потому что избегаю мороки с редактором...
@zoldaten, спасибо за вопрос. На всякий случай уточню, что мой предыдущий комментарий относится к этому моменту статьи:
Я встречал, как вложенные функции в одну функцию называют functions composition (fc). (без пруфа)
Читать про вложенные функции можно, например, тут https://realpython.com/inner-functions-what-are-they-good-for/#creating-python-inner-functions. правда там обертку для вложенных функций никак не называют.
Описание проблемы "запикливания" функций, содержащих вложенные функции, можно найти тут: https://stackoverflow.com/questions/72766345/attributeerror-cant-pickle-local-object-in-multiprocessing, первый ответ про "pickle can only serialize top-module level functions in general".
По моей ссылке на PyCon надо не читать, а смотреть про то, как чел рассказывает и показывает что врожденный pickle не работает при передаче fc между процессами, и какой костыль они соорудили в библиотеке dill, чтобы сделать это возможным.
В стилистике fc написан FastAPI, благодаря чему он не работает в интеграционных тестах с использованием multiprocessing и авторам Fastapi понадобилось соорудить целый доп класс для тестов. дискуссия по этому поводу тут: https://github.com/fastapi/fastapi/discussions/10213
@Kanut не думаю, что покупали. Когда я работал в "Medical observations data-lake" мы данные передавали, и сами запрашивали. Для медицинской сферы есть доступ к условно обезличенным бесплатным датасетам очень высокого качества, без аугментаций. Условно обезличенные потому, что там только имени/адреса нет... но тоже восстанавливаемо при небольших усилиях.
Не стоит использовать function composition. Они не обрабатываются стандартным pickle и потому не могут быть переданы на выполнение в соседний поток или процесс. Больше тут: The Ghosts of Distant Objects | PyCon Lithuania 2024 https://pycon.lt/2024/talks/YUXXZS
Подкину идею, зачем может пригодиться API gateway: для обеспечения стабильной работы сервисов при добавлении версионирования RestAPI. Внутри у вас стандартные api/v1/service, api/v2/service... внешний url api/service + version in headers.
Ну и, конечно, незаменимая штука для обработки ошибок. В случае, когда api/v100500/service выдаст 404, api-geteway может попробовать исправить ошибку и попробовать что то вернуть пользователю.
Кстати, в конечном итоге создание API gateway - это вынесение задачи роутинга в отдельный сервис и все. Не важно, монолит это или много микросервисов.
Можно, конечно, AI использовать, но можно и vue-i18n-extract поставить, который создает файлы методом статического анализа, поскольку
$t(message)уже определены. В этом плане я больше доверяю функции, чем AI генератору текста.Файлы на перевод мы отдаем переводчикам, у них свои AI на переводы, и свои промпты, более заточенные на перевод.
А вот сборку мест с непереведенными статическими текстами можно запросить: "проверь код на наличие статических текстов, которые видны или будут показаны пользователю пока приложение работает...<желаемое действие>".
Cуть в том, что часто глаз "замыливается" и в проекте с 2500 файлов компонентов нет-нет да и проскочит статика, не помеченная на перевод, т.е. не завернутая в
$t(). Тут AI действительно хороший помощник.P.s. тут на хабре есть гениальная статья о локализации. Там говорят, что кроме текстов, надо еще и картинки переводить/адаптировать. Я с этим очень согласен, но до заказа перерисовки картинок наш проект еще не дорос.
@gmtd Успехов с переводами :)
А я вот мемчики зашел посмотреть, а тут тексты на полэкрана каждый. Очень отвлекает!
А по теме переключения - рабочий кабинет и/или рабочая форма. Одел - "пошел на работу". Снял - папа дома. И когда дверь закрыл на ключ - как то и голова переключается с работы на жизнь и наоборот.
Что ходил, написал. А как ходил-то? Так и не написал. :(
Сколько конференций посетил как спикер - такого ни разу не видел. Всегда либо крест на полу, где стоять, либо отмечено, где можно находиться. Модератор поставит на место, если выйдешь.
А вот бегать по сцене, это да... этим грешат очень многие, даже известные докладчики.
Ну и кстати, а где самая главная ошибка: "не подготовился"?
@TheScienceVictor200 - спасибо, кое что взял. Скорее из первой статьи, чем отсюда, но, все равно, спасибо.
Мне как поклоннику OOP в Python интересно, это действительно наше будущее - понимание как использовать нейронки вкупе с непониманием как создать инстанс простого класса в Python: я про
def create_modelи etc...А ссылку на репозиторий религия не позволяет разместить или что? https://github.com/AbbasIsaev/django-comинтерейс приятный mand
Интерфейс приятный, но выбор команд странный, и, если есть IDE, что мешало установить plugin “Django Commands” выполняющий то же самое?
Всегда пожалуйста. Самый большой косяк Django admin я правлю тут - https://dev.to/danilovmy/how-to-solve-the-singleton-problem-in-django-modeladmin-g42
ну и там же другие фичи типа autocomplete, inlines, nested inlines. Ну или пригодится вся серия моих докладов Hidden gems in django admin (гуглить)
@hphphpклассный тонкий троллинг. можно ли поставить проект Strawberry на Raspberry. Заценил!
Я уж настроился... и тут, неожиданно:
а чего так то? :(
P.s. Лайкнул, потому как сам использую подобные идеи. Рекомендую подглядеть, как в Django сделали async as_view(), и еще можно подглядеть, как реализован CBV в упомянутых FastApi-Utils
лучшее, что я читал написанное именно в django стилистике - Django Design Patterns and Best Practices: Ravindran, Arun. Популярная же Two scoops намного менее Django-way книжка. Мне даже с автором удалось пообщаться лично в этом году, но это не делает ее лучше.
SVG это статик файл, пока ты его не меняешь динамически. Но как только ты сохранишь SVG как шаблон(template) с разметкой, куда ты вставляешь динамические данные и, вуаля, уже другая задача. Правда шаблоны тоже стоит хранить статикой. :)
Поскольку SVG это векторный формат, то я храню данные для объектов (class Flowable) которые рендерю через reportlab в SVG.
Со стат файлами надо работать через веб сервер. Да и хранить поближе к клиенту на CDN. Этого в статье нет. Но это стоит знать и использовать.
А по поводу практик - в проде чего только не бывает. Например код python хранят в базе и запускают по запросу через eval/exec. Или в Yaml только настройки, а потом стартуют автогенерацию кода согласно настройкам. Страшные вещи...
Странно, что в статье про Django 5 очень поверхностно используется само Django. Вероятно в этом причина непопулярности и предыдущих статей.
Что автору можно улучшить, чтобы он сам смог понять, оценить и полюбить философию этого фреймворка.
Про objects.aget уже написали. Стоит научиться пользоваться. doc
Так же полезно почитать про фикстуры вместо создания самопальной функции заполнения базы данными. doc
Стоит так же научиться запускать функции проекта через менеджмент-команды, а не через shell. doc
Стоит все же научиться использовать async GCBV вместо FBV. doc
Учимся всегда включать объявление doctype в начало HTML. Doc, например, тут.
Для асинхронного проекта с forloop в шаблоне идем читать про рендер шаблона по частям через
StreamingHttpResponse. docВсе что стоит в href заворачиваем фильтром |slugify, просто потому что. doc
Вероятно, что через некоторое время захочется выбросить gunicorn и начать запускать через uvicorn. Предлагаю сделать это с самого начала. doc
Ну и напоследок, @yakvenalex, стоит научиться уважать читателей и размещать ссылки на репозиторий напрямую, а не через телеграм.
@Maxim_from_HW Огромное спасибо за очень взвешенную статью. Несравнимо лучше https://habr.com/ru/articles/837630/.
Чуток споткнулся о ваш собственный testcase, особенно когда в django есть "TestCase", "TransactionTestCase", "SimpleTestCase", "LiveServerTestCase", а так же не документированный SeleniumTestCase. Но видать так было проще.
Ну и объяснение отличия setUpTestData() и def setUpClass() не верное. Первое вызывается внутри второго, после проверок готовности базы данных и загрузки фикстур. (row 1466 django\test\testcases.py). в итоге setUpTestData просто способ что-либо еще сделать после того как масса тестовых данных попала в базу но перед запуском тестов.
Спасибо так же за общие замечания про тестирование, вот бы все тесто-авторы про это знали! Буду давать своим новичкам это статью для ознакомления! Успехов в тестировании!
@Ellowtech что-то форматирование кода совсем уехало. Это Хабр тупит или я? Очень хотел бы дочитать всю серию.
На вопрос, что не так: в хабре, в блоках кода я вижу для слова "def":
зачем ты это сказал! И как теперь это развидеть?
Ну, вероятно, это потому, что этого нет в обязанностях. На некоторых должностях это входит в состав деятельности.
А если по делу - выступаю довольно давно, в основном по Европе, но было уже 2 доклада в Индии. По опыту могу сказать, что никакой программный комитет нормальной конференции не "подсказывает, в какую сторону развить идею". Доклад либо одобрен либо нет.
Если у спикера есть сомнения в своем докладе, который УЖЕ одобрен, он может запросить помощь ментора, так я помогал некоторым начинающим спикерам для подготовки к DjangoCon EU или EuroPython и сам запрашивал помощь для доклада в DjangoCon US и PyCon DE
Так вот, если тема неинтересна голосующему коммьюнити или не входит в список одобренных тем планируемой конференции, то не важно, насколько отстоялось в голове или bullshit-test успешен. Тема так и останется в списке тем, никогда не ставших докладами. Обычно, конкуренция на доклады около 7-12 докладов на один тайм слот.
В качестве основной рекомендации: для тренировки своих спикерских навыков или проверки интересности темы - на конференциях есть lighning-talks. И везде, где это возможно, надо в lighning-talks участвовать: сфейлить невозможно, потому что ни у кого в зале нет ожиданий, зал поддержит, если что-то пойдет криво, и реакция зала - отличный тест для проверки актуальности темы.
Судя по комментариям, разработчики frontend на хабре более молодые и резкие :)
А по делу - не важно, framework ли или набор скриптов выбран как инструмент, но его НАДО использовать если он упрощает и/или организует мою работу и позволяет выполнить мои задачи быстрее и легче.
Я попробовал много предлагаемых пакетов. Основными были Jquery, React, Vue но не потому, что я не знаю остальные, а потому, что на тех проектах, где я работал, это уже было.
Два года назад на Vue конгрессе я познакомился с Deno.Fresh и это удивительно, как быстро он мне зашел сам по себе. Например до этого я пробовал $mol, прости господи. И это была $боль. А тут pReact, реактовый или vue подход при создании "островов" на выбор, и плюс простой интерфейс для backend части. Пару найденных мною isuue поправили за несколько недель.
В общем, для экспериментов я сейчас играю в deno.fresh. А для работы использую тот фреймворк/js-пакет, что уже выбран в проекте.