Госпди! Действительно, когда-то очень давно в основу была взята великолепная, прекрасная и неповторимая джанга! От которой осталось мало чего общего с её текущей версией. Да и с той, которая взята за основу.
При чем тут фичи баз данных, если как орм алхимия более гибкая и функциональная? В т.ч. построитель запросов. И это факт. Да, джанговская орм простая и удобная и с этим никто не спорит. Почему я должен Django REST Framework делать на SQLAlchemy? O_o И это как-то характеризует SQLAlchemy? А минус в карму за то, что кто-то со мной просто не согласен?
Всё вширь и вширь. Ни ORM, ни шаблонизатор по-прежнему не дотягивают до аналогичных решений в проектах Flask (Jinja2, SQLAlchemy). Кстати, асинхронные проекты flask'у подобные уже давно прекрасно существуют и развиваются.
Ну да, можно купить футболку, где они выложены на асфальте поверх стрёмного покрывала, а можно прийти в бутик, где каждая футболка как произведение искусства. Вам футболку или красивый магазин? Также и с интернет-магазином. "Красивый шаблон" это красивая подача товара. Дизайн (UI) также говорит об подходе компании к своему делу, о её уровне и самобытности. Не будет компания с большой буквы иметь убогий дизайн своего магазина. Можно купить товар и на укозе, где будет всё просто, понятно и удобно. Но я выберу магазин, который еще имеет свою концепцию и брендинг, который не возможен без "красивого самописного шаблона". Как минимум, с приятным дизайном приятней покупки делать. И да, цмски универсальны и за уши натянуты под конкретную направленность магазина. С ними, в большинстве случаев, нет толкового UX. Я не хочу сказать, что UI важнее UX. Нет. Они важны одинаково.
Какой тогда смысл в джанге? Оторвать от неё куски и лишится всех её плюшек? Взять фреймворк, чтобы там почти всё поменять? Мне, видимо, этого не понять. Я лучше возьму предназначенный для этого фласк или другой микрофреймворк.
С 14го года не интересовался джангой, она всё также вширь и вширь? Всё больше и больше батареек? А шаблонизатор всё также отстаёт в несколько раз от jinja2 по всем параметрам? ORM думаю тоже не приблизился к уровню SQLAlchemy?
Это формальная параллельность или псевдо-параллелизм. Даже множество запущенных процессов с одноядерным процессором концептуально не отменяет параллелизм. А вот асинхронность (acyncio) никак не параллелизм. Дело в переводе, в оригинальной статье (да и в офф документации) acyncio описан как concurrency. А конкурентность и параллельность это разные вещи. Можно почитать: https://m.habrahabr.ru/company/piter/blog/274569
Зачем для простых запросов тянуть библиотеку requests, основанную на другой сторонней библиотеке urllib3, которая, в свою очередь, является надстройкой над стандартными средствами python. Чем стандартный urllib не устроил?
Вон Rovio создали 51 игру, а выстрелила только 52ая — «Angry Birds». И на рекламу ничего не потратили. Сработало сарафанное радио. Главное игра какая...
Или я вас не пойму, или вы запутались.
Сессионный токен это просто идентификатор без полезной нагрузки, просто случайно сгенерированная строка. Такой токен нет особого смысла держать в веб-хранилище. Он передается на сервер через куки, а потом сравнивается с имеющимися токенами в БД.
Токен JWT это зашифрованные данные. Они могут занимать большой размер и поэтому в куки могут не поместится, тут на помощь приходит веб-хранилище. Поскольку доступ к этому хранилищу осуществляется через js, то такой подход актуален, в основном, для SPA.
Госпди! Действительно, когда-то очень давно в основу была взята великолепная, прекрасная и неповторимая джанга! От которой осталось мало чего общего с её текущей версией. Да и с той, которая взята за основу.
При чем тут фичи баз данных, если как орм алхимия более гибкая и функциональная? В т.ч. построитель запросов. И это факт. Да, джанговская орм простая и удобная и с этим никто не спорит. Почему я должен Django REST Framework делать на SQLAlchemy? O_o И это как-то характеризует SQLAlchemy? А минус в карму за то, что кто-то со мной просто не согласен?
Всё вширь и вширь. Ни ORM, ни шаблонизатор по-прежнему не дотягивают до аналогичных решений в проектах Flask (Jinja2, SQLAlchemy). Кстати, асинхронные проекты flask'у подобные уже давно прекрасно существуют и развиваются.
Судя по всему, детерминированность подходящий термин.
"Внедрение SQL — это когда вы пишете SQL-запросы напрямую, а не с помощью ORM"
… а не с помощью параметризованных запросов.
Ну да, можно купить футболку, где они выложены на асфальте поверх стрёмного покрывала, а можно прийти в бутик, где каждая футболка как произведение искусства. Вам футболку или красивый магазин? Также и с интернет-магазином. "Красивый шаблон" это красивая подача товара. Дизайн (UI) также говорит об подходе компании к своему делу, о её уровне и самобытности. Не будет компания с большой буквы иметь убогий дизайн своего магазина. Можно купить товар и на укозе, где будет всё просто, понятно и удобно. Но я выберу магазин, который еще имеет свою концепцию и брендинг, который не возможен без "красивого самописного шаблона". Как минимум, с приятным дизайном приятней покупки делать. И да, цмски универсальны и за уши натянуты под конкретную направленность магазина. С ними, в большинстве случаев, нет толкового UX. Я не хочу сказать, что UI важнее UX. Нет. Они важны одинаково.
Какой тогда смысл в джанге? Оторвать от неё куски и лишится всех её плюшек? Взять фреймворк, чтобы там почти всё поменять? Мне, видимо, этого не понять. Я лучше возьму предназначенный для этого фласк или другой микрофреймворк.
С 14го года не интересовался джангой, она всё также вширь и вширь? Всё больше и больше батареек? А шаблонизатор всё также отстаёт в несколько раз от jinja2 по всем параметрам? ORM думаю тоже не приблизился к уровню SQLAlchemy?
Это формальная параллельность или псевдо-параллелизм. Даже множество запущенных процессов с одноядерным процессором концептуально не отменяет параллелизм. А вот асинхронность (acyncio) никак не параллелизм. Дело в переводе, в оригинальной статье (да и в офф документации) acyncio описан как concurrency. А конкурентность и параллельность это разные вещи. Можно почитать: https://m.habrahabr.ru/company/piter/blog/274569
asyncio это не "параллельная обработка"
Post.query.join(followers, (followers.c.followed_id == Post.user_id)).filter(followers.c.follower_id == self.id).order_by(Post.timestamp.desc())»
Ммм как же я люблю ORM…
Говорить это плохо только из-за того что это вам не нравится… Ладно бы в комментарии, но статья… Называть это очевидным и понятным для большинства...
"Я нашел много доводов в пользу и во вред таких приемов" Рассказали бы о найденых доводах что ли.
"У людей возникает вопрос на подсознательном уровне: «А не пытаются ли мной манипулировать?»" Практика показывает обратное.
"Задайте себе вопрос: «А как бы я отреагировал на эту штуку?»" Очень плохой совет, в маркетинге субъективные впечатления лучше оставить при себе.
Зачем для простых запросов тянуть библиотеку requests, основанную на другой сторонней библиотеке urllib3, которая, в свою очередь, является надстройкой над стандартными средствами python. Чем стандартный urllib не устроил?
Простите, а зачем "сайты на питоне" оформлять как "самодостаточные пакеты" и загружать на PyPl?
"Во-первых, говорят, что создавать больше процессов, чем ядер в процессоре, бесполезно."
С чего бы это? Вы же не асинхронное приложение пишите. А операции IO прекрасный кандидат для многопоточного приложения.
А через сколько запросов вы перезагружаете воркеры?
Вон Rovio создали 51 игру, а выстрелила только 52ая — «Angry Birds». И на рекламу ничего не потратили. Сработало сарафанное радио. Главное игра какая...
Забыли Бизли "Подробный справочник" 4-ое издание
Или я вас не пойму, или вы запутались.
Сессионный токен это просто идентификатор без полезной нагрузки, просто случайно сгенерированная строка. Такой токен нет особого смысла держать в веб-хранилище. Он передается на сервер через куки, а потом сравнивается с имеющимися токенами в БД.
Токен JWT это зашифрованные данные. Они могут занимать большой размер и поэтому в куки могут не поместится, тут на помощь приходит веб-хранилище. Поскольку доступ к этому хранилищу осуществляется через js, то такой подход актуален, в основном, для SPA.