А я вот мемчики зашел посмотреть, а тут тексты на полэкрана каждый. Очень отвлекает!
А по теме переключения - рабочий кабинет и/или рабочая форма. Одел - "пошел на работу". Снял - папа дома. И когда дверь закрыл на ключ - как то и голова переключается с работы на жизнь и наоборот.
«Как я ходил по тонкому льду на тренинге по публичным выступлениям»
Что ходил, написал. А как ходил-то? Так и не написал. :(
Ошибки ТОП-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 просто способ что-либо еще сделать после того как масса тестовых данных попала в базу но перед запуском тестов.
Спасибо так же за общие замечания про тестирование, вот бы все тесто-авторы про это знали! Буду давать своим новичкам это статью для ознакомления! Успехов в тестировании!
...тесты выполнятся последовательно, и, если в них была какая-то взаимосвязь, то она сохранится. Однако, если вы попробуете вызвать тесты в несколько потоков, то последовательность перемешается.
А автору не приходило в голову, что, именно потому, unt-тесты должны быть независимы. Ну или перестаем называть их unit-ами и начинаем лечить сифилис писать независимые unit тесты.
Двадцать тестов, зависимых друг от друга, придётся пройтись по всем, даже есть один из первых тестов упал
Любопытно, как можно продолжать тестировать если стейт ошибочный, или суть не ошибку найти, а тесты запустить?
@wwakabobik, я, к сожалению, не вижу вашей всей схемы тестирования. По тем частям, что описаны, явно видно нарушение базовых подходов к тестированию. Тесты могут быть плохими и при этом хорошо выполнять свою задачу, если сам подход к тестированию соблюдается.
Я никогда не рассматривал выступления как обязанность
Ну, вероятно, это потому, что этого нет в обязанностях. На некоторых должностях это входит в состав деятельности.
А если по делу - выступаю довольно давно, в основном по Европе, но было уже 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-пакет, что уже выбран в проекте.
Не соглашусь про pinia. Она не рекомендовалась а просто была единственным storage для vue3, но потом вышел Vuex4 для vue3 и опять стало опять все хорошо и его можно снова использовать в проектах.
Мне кажется, что пояснять держателям бюджета (людям от бизнеса), что и почему делается через объяснение про "минимизацию зависимостей и максимизацию внутренней связности" одинаково бессмысленно как и про " низкую связанность и высокое зацепление". И то и то для программистов, не для бизнеса. Вот какой "выхлоп" будет - это да, это держателям бюджета нравится. А сейчас, например, в Австрии вообще про минимизацию выхлопов очень хорошо говорить, я про carbon impakt.
Ответ не совсем корректный. У класса словарь не реализован метод __hash__ поэтому объекты не являются хешируемыми в python. Но это происходит вне зависимости от мутабельности объектов этого класса. Другой вопрос - почему этот метод не реализован.
Вопрос первый - почему не сравниваете json структуры? В там есть и параметр сортировки по ключу, и проверка циклических ссылок.
Вопрос второй - тесты с хардкодом ответа в коде, это как бы не очень тесты. Не думали, что этот тест стоило бы переписать? Вам же не равенство константе надо проверять.
А я вот мемчики зашел посмотреть, а тут тексты на полэкрана каждый. Очень отвлекает!
А по теме переключения - рабочий кабинет и/или рабочая форма. Одел - "пошел на работу". Снял - папа дома. И когда дверь закрыл на ключ - как то и голова переключается с работы на жизнь и наоборот.
Что ходил, написал. А как ходил-то? Так и не написал. :(
Сколько конференций посетил как спикер - такого ни разу не видел. Всегда либо крест на полу, где стоять, либо отмечено, где можно находиться. Модератор поставит на место, если выйдешь.
А вот бегать по сцене, это да... этим грешат очень многие, даже известные докладчики.
Ну и кстати, а где самая главная ошибка: "не подготовился"?
@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":
А автору не приходило в голову, что, именно потому, unt-тесты должны быть независимы. Ну или перестаем называть их unit-ами и начинаем
лечить сифилисписать независимые unit тесты.Любопытно, как можно продолжать тестировать если стейт ошибочный, или суть не ошибку найти, а тесты запустить?
@wwakabobik, я, к сожалению, не вижу вашей всей схемы тестирования. По тем частям, что описаны, явно видно нарушение базовых подходов к тестированию. Тесты могут быть плохими и при этом хорошо выполнять свою задачу, если сам подход к тестированию соблюдается.
зачем ты это сказал! И как теперь это развидеть?
Ну, вероятно, это потому, что этого нет в обязанностях. На некоторых должностях это входит в состав деятельности.
А если по делу - выступаю довольно давно, в основном по Европе, но было уже 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-пакет, что уже выбран в проекте.
Не соглашусь про pinia. Она не рекомендовалась а просто была единственным storage для vue3, но потом вышел Vuex4 для vue3 и опять стало опять все хорошо и его можно снова использовать в проектах.
Эти Dolls для наружнего пользования. 😉
Мне кажется, что пояснять держателям бюджета (людям от бизнеса), что и почему делается через объяснение про "минимизацию зависимостей и максимизацию внутренней связности" одинаково бессмысленно как и про " низкую связанность и высокое зацепление". И то и то для программистов, не для бизнеса. Вот какой "выхлоп" будет - это да, это держателям бюджета нравится. А сейчас, например, в Австрии вообще про минимизацию выхлопов очень хорошо говорить, я про carbon impakt.
Ответ не совсем корректный. У класса словарь не реализован метод __hash__ поэтому объекты не являются хешируемыми в python. Но это происходит вне зависимости от мутабельности объектов этого класса. Другой вопрос - почему этот метод не реализован.
это неплохо вы так переизобрели Deep Equality Test for Nested Python Structures которому уже лет 10. Но так в питоне кругом происходит, так что принимается.
Вопрос первый - почему не сравниваете json структуры? В там есть и параметр сортировки по ключу, и проверка циклических ссылок.
Вопрос второй - тесты с хардкодом ответа в коде, это как бы не очень тесты. Не думали, что этот тест стоило бы переписать? Вам же не равенство константе надо проверять.