В стартапе можно\нужно быстро кодить и подзабивать на тесты. В банке никто не позволит творить отсебятину.
Но в целом, идея "сделать быстро" а потом улучшать вполне здравая (минуя банки, конечно). Сюда ещё можно добавить, что технологии быстро развиваются. Я за последние 20 лет сменил операционку, несколько языков, фреймворков, баз данных и подходов к разработке.
20 лет назад написали бы отдельную функцию is_unique_email(check_mail).
10 лет назад вынесли бы в Сервисный слой, ну, чтобы Пользователи отдельно - котлеты отдельно.
Сейчас даже развесистой и основательной статьи недостаточно, чтобы понять что, куда и зачем. Причём кол-во кода начинает стремительно увеличивать энтропию Вселенной, которая и без того велика.
Не делать CRUD вообще. Этот набор букв - вырожденный случай. В реальном мире у вас не CRUD, а что угодно - начиная от только R и заканчивая десятками действий на сущность.
Как добавление\редактирование карточки товара противоречит какой либо архитектуре?
Сгребая всё под термин update мы теряем самое главное - то ради чего писался код, бизнес value конкретной единицы.
ООП заставляет нас больше холиварить, чем заниматься написанием структурированного кода. Делать ли CRUD отдельным слоем, или как в Django делать Модель на основе данных? Вы предлагаете Классовый подход сервисного слоя. Я бы сделал набор простых функций...
Про CatServiceImpl в комментах, наверняка, уже выразились. Все эти примеры с Животными и Фигурами для объяснения ООП довольно коварны своей очевидной простотой. В реалиях будут Message, MessageService, MessageProvider, где придётся выбирать что и когда возвращать (данные или объекты, делать их ленивыми или нет, асинхронность там...)
В итоге, мы делаем всё за ради полиморфизма:
for animal in animals:
animal.move()
animal.make_sound()
Хотя Питон, будучи динамическим языком, позволяет и так делать вызовы из объектов, если нужные методы присутствуют. Если нам так нравится java-подход, зачем вообще брать python?
Есть прекрасное видео https://www.youtube.com/watch?v=t-IUY6QrJyU - The Problem with The Problem (Screencast) - это David Beazley, который по Питону несколько книг выпустил. Он показывает, как мы можем закопаться в деталях, даже не начав решать задачу.
Более того, не всегда и не всем нужны SPA. Всем, конечно, понравились переходы без перезагрузки. Но ведь можно использовать библиотеки, вроде barba.js
Но сейчас устоялись практики, что фронт - это обязательно js-first. И простой интернет-магазин начинает состоять из тьмы компонентов: давайте загрузим 2 мб скриптов, чтобы показать карточку товара.
Более того, слышал тезис, что если с бека отдаёшь html - то ты дед и всё делаешь не так. Мол, потому что на курсах фронтэдеров готовят на всяких react\vue\angular и в обычный html уже никто и не умеет.
Корпус должен быть сильно продуваемым (сверзху вентиляторы на выдув), да и всё равно видюшка дует прямо в кулер проца. Так что часто надо ставить водянку на проц. Да и все равно вентили на 3090 будут шуметь, дабы отвести сво 400Вт тепла. Мне, например не сильна важно, за сколько там условный whisper сделает транскрибацию - за 2 мин или за 2.5 минут - зато тише.
Правильно ли я понимаю, что задача Джаспера рисовать веб не на канвасе, а именно отдавать html? При этом Дарт компилится в JS?
Выглядит громоздко. И если взять пример со стилезацией на Бульме - всё становится ещё тяжелее. И не очень понятно, как делать вёрстку - все эти медиа-запросы, 1 колонка на мобильном, 3 на десктопе...
Хотя, может если сделать библиотеку адаптированных компонентов - может и получится.
Надеюсь, что после прочтения статьи принципы SOLID стали для вас такими же очевидными, как для Роберта С. Мартина.
Нет. Вообще нет. Дядюшка Боб молодец: напихал в Джаву абстракций в 2000-х годах и свалил писать на Clojure. А люди всё продолжают слепо перетаскивать из Джавы на все остальные языки.
cd venv/lib/python3.9/site-packages/django/
grep -lir "from abs import"
И ничего не найдено, хотя там есть Абстрактные классы. Вот этот from abs - он не выглядит python way. Слишком много Абстракций начинают усложнять понимание, что в свою очередь начинает противоречить KISS. Плюс в питоне можно вот так сделать class MyModelAdmin(AdminImageMixin, admin.ModelAdmin), а в java множественное наследование запрещено. Вот тут даже интерфейса не надо
""" Демонстрируем Инъекцию Зависимостей """
class EmailNotifier:
""" Отправим через E-mail """
def send(self, to, message):
print(f"Notify {to} by mail. {message}")
class SmsNotifier:
""" Отправим в Telegramm """
def send(self, to, message):
print(f"Notify {to} by sms. {message}")
def notify_user_by_email(to, message):
""" Тут функция зависит от настроек почтового сервера """
by_email = EmailNotifier()
by_email.send(to, message)
def notify_user_di(to, message, notifier):
""" Инъекция notifier. Главное, чтобы у notifier был метод send() А там хоть email, хоть MailChimp """
notifier.send(to, message)
if __name__ == "__main__":
# Вот такие красавцы
user_list = [
{"name": "Bob", "phone": "+7-903", "email": "uncle.bob@gmail.com"},
{"name": "Mike", "phone": "", "email": "mechanic@yahoo.com"},
{"name": "Jeff", "phone": "+7-926", "email":""},
]
for user in user_list:
if user["phone"]:
""" Отправляем в телефон """
notify_user_di(user["phone"], "Welcome home!", SmsNotifier())
if user["email"]:
""" На email """
notify_user_di(user["email"], "Welcome home!", EmailNotifier())
Понятно, что js нужен. Для анимаций берём gsap, 3djs для графиков, для 3Д - three.js и так далее. Не сам ведь Реакт или Вю делают анимацию. Большинство того, что делают на популярных фрон-фреймворках - это не приложение, а обычный сайт c бесшовными переходами. Кстати, barba.js.org просто и красиво это делает.
Речь про использование какого-нить htmx.org - большинство вещей рендерится на сервере и подменяется целиком или кусочками. Просто гоняете не json а куски html.
Но согласен, какую-нить систему для Трейдинга или банковское приложение удобнее делать используя js-frontend. Но ему и индексация не нужна обычно - все закрыто авторизацией.
Возможность избежать JS, конечно выглядит заманчивой. Но полностью отказаться от него сложно, потому как Листалки нужны, Анимации gsap, Графики динамические. Мы ж не будем переписывать - а просто возмём готовое.
Хотя возможность не использовать Реакт - безусловное добро!
Выглядит интересно. Но не могу понять, в чём изюминка. У ребят на js и так тьма своих фреймворков. Может, рассматривать как дополнение к python? Синтаксис у Нима схож, быстрый...
В стартапе можно\нужно быстро кодить и подзабивать на тесты. В банке никто не позволит творить отсебятину.
Но в целом, идея "сделать быстро" а потом улучшать вполне здравая (минуя банки, конечно). Сюда ещё можно добавить, что технологии быстро развиваются. Я за последние 20 лет сменил операционку, несколько языков, фреймворков, баз данных и подходов к разработке.
Хорошая статья. Но мы же понимаем, что не дизайнеры в массе своей виноваты. Просто и они тоже являются участниками процесса продаж.
> Сравните это с ресурсами, реально обеспокоенными производительностью — Po...
Забавно, что они отправляют петрабайты видео, но минимизируют js... Avito - слыхали?
20 лет назад написали бы отдельную функцию is_unique_email(check_mail).
10 лет назад вынесли бы в Сервисный слой, ну, чтобы Пользователи отдельно - котлеты отдельно.
Сейчас даже развесистой и основательной статьи недостаточно, чтобы понять что, куда и зачем. Причём кол-во кода начинает стремительно увеличивать энтропию Вселенной, которая и без того велика.
Кто вообще писал про транзакции и их update?
А ответ на самый главный вопрос — 42!
Как добавление\редактирование карточки товара противоречит какой либо архитектуре?
Вот тут я вообще не понял. Поясните, плиз...
ООП заставляет нас больше холиварить, чем заниматься написанием структурированного кода. Делать ли CRUD отдельным слоем, или как в Django делать Модель на основе данных? Вы предлагаете Классовый подход сервисного слоя. Я бы сделал набор простых функций...
Про CatServiceImpl в комментах, наверняка, уже выразились. Все эти примеры с Животными и Фигурами для объяснения ООП довольно коварны своей очевидной простотой. В реалиях будут Message, MessageService, MessageProvider, где придётся выбирать что и когда возвращать (данные или объекты, делать их ленивыми или нет, асинхронность там...)
В итоге, мы делаем всё за ради полиморфизма:
Хотя Питон, будучи динамическим языком, позволяет и так делать вызовы из объектов, если нужные методы присутствуют. Если нам так нравится java-подход, зачем вообще брать python?
Есть прекрасное видео https://www.youtube.com/watch?v=t-IUY6QrJyU - The Problem with The Problem (Screencast) - это David Beazley, который по Питону несколько книг выпустил. Он показывает, как мы можем закопаться в деталях, даже не начав решать задачу.
И спасибо за статью!
Более того, не всегда и не всем нужны SPA. Всем, конечно, понравились переходы без перезагрузки. Но ведь можно использовать библиотеки, вроде barba.js
Но сейчас устоялись практики, что фронт - это обязательно js-first. И простой интернет-магазин начинает состоять из тьмы компонентов: давайте загрузим 2 мб скриптов, чтобы показать карточку товара.
Более того, слышал тезис, что если с бека отдаёшь html - то ты дед и всё делаешь не так. Мол, потому что на курсах фронтэдеров готовят на всяких react\vue\angular и в обычный html уже никто и не умеет.
Это шииииикарно! Спасибо за интересную статью с примерами и объяснением.
Корпус должен быть сильно продуваемым (сверзху вентиляторы на выдув), да и всё равно видюшка дует прямо в кулер проца. Так что часто надо ставить водянку на проц. Да и все равно вентили на 3090 будут шуметь, дабы отвести сво 400Вт тепла. Мне, например не сильна важно, за сколько там условный whisper сделает транскрибацию - за 2 мин или за 2.5 минут - зато тише.
Полезное исследование. Я даже свою 3060 переодически ограничиваю по ТДП. А тут столько мощи при 250 Вт. Тоже задумался о 3090.
Зачем писать о том, в чём слабо разбираешься - вообще не понятно.
Причины не 3, а ровно одна - цепляет или нет. Хочется - или нет. Нравится - или нет.
Правильно ли я понимаю, что задача Джаспера рисовать веб не на канвасе, а именно отдавать html? При этом Дарт компилится в JS?
Выглядит громоздко. И если взять пример со стилезацией на Бульме - всё становится ещё тяжелее. И не очень понятно, как делать вёрстку - все эти медиа-запросы, 1 колонка на мобильном, 3 на десктопе...
Хотя, может если сделать библиотеку адаптированных компонентов - может и получится.
Нет. Вообще нет. Дядюшка Боб молодец: напихал в Джаву абстракций в 2000-х годах и свалил писать на Clojure. А люди всё продолжают слепо перетаскивать из Джавы на все остальные языки.
И ничего не найдено, хотя там есть Абстрактные классы. Вот этот from abs - он не выглядит python way. Слишком много Абстракций начинают усложнять понимание, что в свою очередь начинает противоречить KISS. Плюс в питоне можно вот так сделать class MyModelAdmin(AdminImageMixin, admin.ModelAdmin), а в java множественное наследование запрещено. Вот тут даже интерфейса не надо
Понятно, что js нужен. Для анимаций берём gsap, 3djs для графиков, для 3Д - three.js и так далее. Не сам ведь Реакт или Вю делают анимацию. Большинство того, что делают на популярных фрон-фреймворках - это не приложение, а обычный сайт c бесшовными переходами. Кстати, barba.js.org просто и красиво это делает.
Речь про использование какого-нить htmx.org - большинство вещей рендерится на сервере и подменяется целиком или кусочками. Просто гоняете не json а куски html.
Но согласен, какую-нить систему для Трейдинга или банковское приложение удобнее делать используя js-frontend. Но ему и индексация не нужна обычно - все закрыто авторизацией.
Возможность избежать JS, конечно выглядит заманчивой. Но полностью отказаться от него сложно, потому как Листалки нужны, Анимации gsap, Графики динамические. Мы ж не будем переписывать - а просто возмём готовое.
Хотя возможность не использовать Реакт - безусловное добро!
Выглядит интересно. Но не могу понять, в чём изюминка. У ребят на js и так тьма своих фреймворков. Может, рассматривать как дополнение к python? Синтаксис у Нима схож, быстрый...
Неужто написать простой html сложнее, чем поставить ноду, фреймворк и вот это всё? Интернет стал быстро расти именно потому что html прост и понятен.