ООП сложен. Сложен в понимании и проектировании. Вот эти интерфейсы и абстрактные классы, с кошками и утками, которые двигаются но не все плавают... Размазывание логики по классам и файлам, где есть this.value=value; и метод calculate(); Просто когда Вы пишете на Java или C# - у Вас нет выбора.
Кому-то ультимативный подход "всё есть объект" не нравится. И так появился Kotlin. Другие отказались от классического наследования и появился Rust и Go.
Нет, не будут ждать. Nginx получит новый запрос, из пула web-воркеров выделится свободный процесс, отработает запрос и отдаст обратно.
Более того, отресайзить картинку локально будет быстрее, чем отправить её в удалённый сервис, подождать, загрузить обратно и сохранить. И это потребует не только процессорного времени, но и сети и дополнительного трафика. Тестировать всё это сложнее, а получить Too Many Requests или 502 ошибку очень легко.
При типовой нагрузке в 100 RPS один ресайз картинки в секунду ничего не усложнит - это быстрая операция. Если добавлений много, то запись (куда картинка добавляется) не активна, админу показывается свёрстанный вариант, и только потом кнопка Опубликовать. Так, например, на drive2 делается. И никаких затыков.
При конвертации видео - там да, надо фоновым процессом, ибо операция длинная по времени.
Наличие платного тарифа предполагает ограничение бесплатного. Сервер-то надо оплачивать. Да и вообще не понятно, зачем использовать удалённый сервис для такой простой задачи? Коннект может отвалиться, апи поменяться, изменятся условия... Ладно, там переводчик языковой. Но тут-то pillow + sorl.thumbnail или imagekit - и это всё уже есть готовое.
Посмотрите, как написаны штатные (ImageField) и нештатные (как пример, ResizedImageField) - они сами берут на себя ответственность за обработку картинок. Простая мысль: Модель "Компания" должна отвечать за Компанию. Т.е. сделать self.slug = slugify(self.name) - уместно, поскольку это относится к Компании. А обработку картинок надо выносить. Вы же не будете писать 1-3-5 методов, если помимо лого будут ещё картинки загружаться.
Батарейки работают. Смотрите зависимости. Большинство используют Pillow для картинок. Если Pillow умеет сохранять в webp - и их потомки тоже умеют.
Нет. Не не так. Картинка не будет подгружаться целиком.
Тут при первом обращении сделается превью (ресайз, кроп, все дела), сохраниться на диск (в папку cache). Потом именно этот файл будет отдаваться по этому запросу.
Отложенная задача - нет возможности сразу посмотреть результат. В одном случае Вы загрузили большую картинку 3000х4000, django ресайзнула её до 1500х2000. И клиент\администратор сразу видит результат. А если процесс обработки отложен на 10 мин? Что там получится? А администратор уже следующую карточку товара пишет...
Как то с ребенком занимались визуальным программированием для лего mindstorm. Простые вещи — да, наглядно. Любое усложнение алгоритма — ад. Никогда больше!
Идея здравая (избавиться от лишней философии). Но институт - место довольно инерционное. Если бекенд ещё худо-бедно устаканился, то фронт - настоящие безумие: смена парадигм в реакте, вю тоже поменялся с КомпозишнАПИ. МодульФедерейшеном можно не только детей пугать, но и взрослых. ИТ довольно подвижный сектор - в юности нам давали паскаль и бейсик. Где они сейчас? Хорошо, если сейчас в институте дают ПХП и jQuery. За мою жизнь только Си и С++ более-менее остались в ходу.
Это математику преподавали тучу лет - всё отточили в процессе. А тут разброд и шатание. Помните, когда все поголовно бросились в ООП? Джаву придумали (ненавижу её всеми фибрами души из-за web-apps). Потом решили, что можно и простых функций добавить - и вот есть Котлин. Перл взлетел на заре веба, и так же канул в лету.
Я к тому, что не так просто выбрать стек технологий, чтобы было и устойчиво, и модерново.
NoCode - как швейцарский нож: всё есть, компактно, симпатично, но все пользуются нормальными отвёртками, ножами и прочим инструментом.
У меня вопрос больше стратегический. Написали быстро прототип, используя кубики конструктора. Нужен свой кубик - ждём, пока его сделают, или сами пишем код. Получается, надо знать экосистему Конструктора, и заодно и Кодировать (например, js, css, html, react). Получается, чтобы развивать прототип, надо уметь кодить.
И давайте на чистоту, сами принципы программирования несложные: циклы, условные переходы, переменные-массивы-структуры. Ну заменили мы условие IF на визуальный кубик - мы же не упростили логику, она осталась. Так же как ORM не отменяет требований к знаниям того, как работает база данных и SQL.
Чем NoCode отличается от использования всяких фреймворков и UI китов? Точно так же набрали компонент и связываем их. Чуть сложнее на старте - гораздо гибче и производительнее в будущем.
ООП сложен. Сложен в понимании и проектировании. Вот эти интерфейсы и абстрактные классы, с кошками и утками, которые двигаются но не все плавают... Размазывание логики по классам и файлам, где есть this.value=value; и метод calculate(); Просто когда Вы пишете на Java или C# - у Вас нет выбора.
Кому-то ультимативный подход "всё есть объект" не нравится. И так появился Kotlin. Другие отказались от классического наследования и появился Rust и Go.
Нет, не будут ждать. Nginx получит новый запрос, из пула web-воркеров выделится свободный процесс, отработает запрос и отдаст обратно.
Более того, отресайзить картинку локально будет быстрее, чем отправить её в удалённый сервис, подождать, загрузить обратно и сохранить. И это потребует не только процессорного времени, но и сети и дополнительного трафика. Тестировать всё это сложнее, а получить Too Many Requests или 502 ошибку очень легко.
Django и так умеет хранить картинки на другом сервере.
И это Ваш Апи может не меняться. Чужой - может отвалиться, поменяться, закрыться. Не понимаю, зачем закладывать в систему лишний риск.
При типовой нагрузке в 100 RPS один ресайз картинки в секунду ничего не усложнит - это быстрая операция. Если добавлений много, то запись (куда картинка добавляется) не активна, админу показывается свёрстанный вариант, и только потом кнопка Опубликовать. Так, например, на drive2 делается. И никаких затыков.
При конвертации видео - там да, надо фоновым процессом, ибо операция длинная по времени.
Наличие платного тарифа предполагает ограничение бесплатного. Сервер-то надо оплачивать. Да и вообще не понятно, зачем использовать удалённый сервис для такой простой задачи? Коннект может отвалиться, апи поменяться, изменятся условия... Ладно, там переводчик языковой. Но тут-то pillow + sorl.thumbnail или imagekit - и это всё уже есть готовое.
А смысл платить $499 в год за функционал, который можно получить локально абсолютно бесплатно, используя тот же pillow + ffmpeg?
Посмотрите, как написаны штатные (ImageField) и нештатные (как пример, ResizedImageField) - они сами берут на себя ответственность за обработку картинок. Простая мысль: Модель "Компания" должна отвечать за Компанию. Т.е. сделать self.slug = slugify(self.name) - уместно, поскольку это относится к Компании. А обработку картинок надо выносить. Вы же не будете писать 1-3-5 методов, если помимо лого будут ещё картинки загружаться.
Батарейки работают. Смотрите зависимости. Большинство используют Pillow для картинок. Если Pillow умеет сохранять в webp - и их потомки тоже умеют.
Нет. Не не так. Картинка не будет подгружаться целиком.
{% thumbnail obj.image "400x400" crop="center" quality=95 as pixthumb %}
<img ... src="{{ pixthumb }}">
{% endthumbnail %}
Тут при первом обращении сделается превью (ресайз, кроп, все дела), сохраниться на диск (в папку cache). Потом именно этот файл будет отдаваться по этому запросу.
Проверьте - сами увидите.
Отложенная задача - нет возможности сразу посмотреть результат. В одном случае Вы загрузили большую картинку 3000х4000, django ресайзнула её до 1500х2000. И клиент\администратор сразу видит результат. А если процесс обработки отложен на 10 мин? Что там получится? А администратор уже следующую карточку товара пишет...
Писать код ресайза в save() -- сомнительная идея.
Батарейка django_resized позволяет ресайзить большие картинки при загрузке:
image = ResizedImageField(size=[100, 100], crop=['top', 'left'], upload_to='whatever', force_format='PNG', scale=0.5)
Принудительно кропить при загрузке -- обрежете голову. Уж лучше потом в шаблонах использовать sorl.thumbnail
А, вот оно как. Не знал. Спасибо за пояснение!
Это хорошая новость. А что для интерфейса будете использовать?
Как то с ребенком занимались визуальным программированием для лего mindstorm. Простые вещи — да, наглядно. Любое усложнение алгоритма — ад. Никогда больше!
Шикарная статья, спасибо! Хабр торт!
Идея здравая (избавиться от лишней философии). Но институт - место довольно инерционное. Если бекенд ещё худо-бедно устаканился, то фронт - настоящие безумие: смена парадигм в реакте, вю тоже поменялся с КомпозишнАПИ. МодульФедерейшеном можно не только детей пугать, но и взрослых. ИТ довольно подвижный сектор - в юности нам давали паскаль и бейсик. Где они сейчас? Хорошо, если сейчас в институте дают ПХП и jQuery. За мою жизнь только Си и С++ более-менее остались в ходу.
Это математику преподавали тучу лет - всё отточили в процессе. А тут разброд и шатание. Помните, когда все поголовно бросились в ООП? Джаву придумали (ненавижу её всеми фибрами души из-за web-apps). Потом решили, что можно и простых функций добавить - и вот есть Котлин. Перл взлетел на заре веба, и так же канул в лету.
Я к тому, что не так просто выбрать стек технологий, чтобы было и устойчиво, и модерново.
Flutter хотя бы компилит в a-la натив, пусть и используя свой GUI-движок. Котлин тоже компилит в байт код, как и Java.
А RN делает код, который запускает web-view, который запускает JS run-time совместно с JIT, и у нас 1 гб для мессенджера. Супер!
А, ну так вызов нативной api-шной кнопки через bridge всё же не полность. нативное приложение.
NoCode - как швейцарский нож: всё есть, компактно, симпатично, но все пользуются нормальными отвёртками, ножами и прочим инструментом.
У меня вопрос больше стратегический. Написали быстро прототип, используя кубики конструктора. Нужен свой кубик - ждём, пока его сделают, или сами пишем код. Получается, надо знать экосистему Конструктора, и заодно и Кодировать (например, js, css, html, react). Получается, чтобы развивать прототип, надо уметь кодить.
И давайте на чистоту, сами принципы программирования несложные: циклы, условные переходы, переменные-массивы-структуры. Ну заменили мы условие IF на визуальный кубик - мы же не упростили логику, она осталась. Так же как ORM не отменяет требований к знаниям того, как работает база данных и SQL.
Чем NoCode отличается от использования всяких фреймворков и UI китов? Точно так же набрали компонент и связываем их. Чуть сложнее на старте - гораздо гибче и производительнее в будущем.
Как это? С какого момента RN стал компилировать в натив?
А мне понравилось. Просто, понятно, легко подправить под себя. Можно поворчать на отсутствие doc-string, но в принципе, и так всё понятно. Спасибо!
Хорошие примеры с миграциями. Они часто могут подкинуть сюрпризов, да!