Простите, а почему в конкурсе статей про open source заняла первое место статья про генарцию кода. При чем проект выложен под лицензией, которая явно не может считаться свободной
А как происходит поиск функции foo по имени? Правильно ли я понимаю, что любой разработчик библиотеки, поставляющей объект x может в некий (глобальный?) неймспейс добавить реализацию функции foo?
Ну допустим мы придумали простой способ помечать, что она кидает исключение. Проблема решена? Или все таки вы настаиваете что для пробросе ошибки наверх (что происходит чаще чем обработка) обязательно нужен бойлерплейт
Работал я как-то на заводе (прошивки писал) и тут приходит к нам ведущий инженер: "Вы же программисты? Помогите листогибочный станок запрограммировать". Программирование станка заключалось в вводе нескольких последовательностей чисел чтобы задать отступы и углы.
Были ли у нее тесты? Что она думает об управлении памятью в с++? Сколько сегофолтов она умела словить? Статическая типизация это хорошо, но это не панацея, она лишь помогает быстрее находить определнный класс ошибок.
У меня был код на питоне, который раблта час. Я переписал его на питоне и он стал работать 1 секунду. Ну серьёзно, проблема могла быть вообще не в языке, а например в сложности алгоритма. При этом не спорю, на куче задач Раст будет действительно рвать питон.
Питон хорош тем, что он не требует что все было написано на питоне. Огромное количество инструментов, которые используют питонисты написаны совсем не на питоне. Питон нужен чтобы писать высокоуровнеаую логику. В этом его сила
А я не понял как вы из количества строк получили скорость разработки? Допустим я 6.5 часов думаю над кодом и 1.5 часа пишу. Если мы меняем язык (java -> python), то думать остается столько же, а писать меньше. То есть из 8 часов на джаве получаем 7 часов на питоне. Числа говно, просто из головы взяты, но если вы оцениваете скорость разработки на основе скорости написания букв, пожалуйста приведите ваши числа.
Для справки, если реально учитываем скорость набора, то при длине 100 символов в каждой строке (оценка сверху, в реальности много строк короче) и 200 знаков в минуту (средняя скорость набора согласно гуглу без учета автодополнения), мы получаем что небольшой проект размером 10к строк можно написать за 10 дней. В реальности он может писаться несколько месяцев.
Я очень люблю питон и считаю, что программа на нем действительно может выглядеть компактее и выразительнее, чем на дажве. Но! Если сравнивать реальные проекты, компактность кода там достигается как раз счет того, что вы говорите - в жертву было принесено всё что угодно: читаемость, декомпозиция, структуры данных
Почему вы сравниваете размер хэлловорлдов, а не реального кода? Так никто не пишет
import json
with open('data.json') as file:
data = json.load(file)
print(data['key']) # Доступ к данным
В реальном коде это будет функция, которую вызывают из другого кода. А то и класс. Но даже без этого, код за пределами "показать как могу" будет скорее походить на
import json
def main():
with open('data.json') as file:
data = json.load(file
print(data['key']) # Доступ к данным
if __name__ == "__main__":
main()
Примере с CSV код на джаве на самом деле не парсит CSV, а только наивно делит по запятым. В реальности значение ячейки может содержать запятую и с этом случае берется в кавычки.
В примере с сортировкой на джаве делается in-place, а в питоне через дополнительные списки В случае с HTTP вы для питона взяли стороннуюю библиотеку, а для джавы - нет. Взяли бы тогда уж urllib.request. Либо попробуйте для разнообразия туда добавить типизацию данных и сравнить, например, мой dataclass-rest и retrofit.
Для асинхронной обработки вы использовали разную модель многозадачности. Корректнее было взятьThreadPoolExecutor.
Я не уверен насчет обработки иключений в джаве, очень много визуального мусора потому что в джаве вы добавили обработку checked исключений, а в питоне оставили программе падать. В реальном коде, вероятно вы бы и в питоне стали их обрабатывать, или дали джава фреймворку ловить всё (сорри, с джавой не работал, там же фреймворк может сам ловить Exсeption и кидать 500?)
Мне кажется Mediatr называть реализацией паттерна медиатор не вполне корректно. Это все таки центральная шина, которая требует отправитель затачивать под нее и делать встраиваемые обработчики. В то время как классический медиатор просто про наличие источников событий и использование медиатора как их обработчика, делающего полезную работу.
Чистая архитектура - это в первую очередь книжка про SOLID, доугие принципы и чуточку про слои. При чем там говорится что слои надо делать исходя из потребностей проекта. Так что формальное следование ей в целом очень сомнительно, только если читать часть, игнорируя остальное.
Мейн - это не файл и не функция в контексте ЧА. Это отдельный компонент, который занимается настройкой и запуском остального кода.
Если же мы зависимости кладём где-то среди вьюх, у нас появляется две причины редактировать вьюхи: изменение логики представления и изменения компоновки приложения. Логично выделить зависимости отдельно. Окей, теперь у нас вьюхи не содержат кода компоновки, но зависят от него. Если это делать аккуратно, наверно все будет окей, но часто я вижу что такие функции create_db начинают использовать глобальные переменные вроде настроек и сессий. Это стреляет во-первых из-за порядка инициализации (в тестах мы можем хотеть настройки задать после импорта), а во-вторых, из-за связи некоторых таких ресурсов с асинкио лупом. Поэтому если мы и делаем такие зависимости, они ни в коем случае не должны оперировать глобальными переменными. Остальные проявления в виде завязки на реализацию скорее всего не выстрелят, но я предпочитаю вьюхи отделять от остальной инфраструктуры, чтобы они вообще не знали ни о чем кроме интеракторов и может быть каких-то DAO для запросов чтения. Так же, тут есть проблемы что в fastapi при всем преимуществах его механик Depends слабая система управления скоупами, я тут предпочитаю самописный свой контейнер, но это уже совсем другая тема
а Depends(get_user_uow) в итоге вызывает конкретную реализацию из infrastructure.
не надо так делать, просто делайте Depends() или с указанием заглушки, а в dependency_overrides пихайте как его создавать. Или можно взять внещний ioc-контейнер, чтобы отделить от возни с парсингом запроса
Всё остальное — дело конкретной реализации (aiohttp, httpx и т.п.).
почему у вас в интерфейсе появились детали реализации? интерфейс нужен для абстрагирования
Это как раз общая настройка: определяю один раз и использую в main.py. Лучше так, чем размазывать частные конфигурации по слоям.
ну вот сами сказали - один раз настроили и используется в мейн. Это часть мейна, а никакая не "общая часть".
Это утиль, не часть архитектуры
архитектура описывает вообще всё приложение, утили вписываются в него. ваша утиль пересекает несколько архитектурных слоев. Это может быть ок, но тогда мы должны аккуратненько её отложить в сторону и выстроить вокруг неё заборчик. Условно - сделать модульный монолит.
Можете предложить свой вариант. И я не говорю, что её много. Просто она может существовать.
мой вариант: в каждом конкретном случае решать куда положить тот или иной кусок кода и назвать модуль согласно тому что там и за что оно отвечает, а не utils.
Во-первых, не вижу этого в лицензии
Во-вторых, это типичная дискриминация
В-третьих, это привязка к стороннему проприетарному сервису, что явно противоречит принципам свободного ПО
Простите, а почему в конкурсе статей про open source заняла первое место статья про генарцию кода. При чем проект выложен под лицензией, которая явно не может считаться свободной
Если там действительно задача уровня докторской, то валидация может и дни занять, а то и недели.
А как происходит поиск функции foo по имени? Правильно ли я понимаю, что любой разработчик библиотеки, поставляющей объект x может в некий (глобальный?) неймспейс добавить реализацию функции foo?
Это такая же проблема как то, что возврат error не прервёт её. Если надо, оно решается точечно, но в целом можно считать фичей/подходом
Ну допустим мы придумали простой способ помечать, что она кидает исключение. Проблема решена? Или все таки вы настаиваете что для пробросе ошибки наверх (что происходит чаще чем обработка) обязательно нужен бойлерплейт
Работал я как-то на заводе (прошивки писал) и тут приходит к нам ведущий инженер: "Вы же программисты? Помогите листогибочный станок запрограммировать". Программирование станка заключалось в вводе нескольких последовательностей чисел чтобы задать отступы и углы.
brainfuck - это язык программирования
А что там раздирать если у нас тезис "в три раза меньше строк" превратился в "разработка в 3 раза быстрее" и дальше в зарплату
Были ли у нее тесты? Что она думает об управлении памятью в с++? Сколько сегофолтов она умела словить? Статическая типизация это хорошо, но это не панацея, она лишь помогает быстрее находить определнный класс ошибок.
У меня был код на питоне, который раблта час. Я переписал его на питоне и он стал работать 1 секунду. Ну серьёзно, проблема могла быть вообще не в языке, а например в сложности алгоритма. При этом не спорю, на куче задач Раст будет действительно рвать питон.
Питон хорош тем, что он не требует что все было написано на питоне. Огромное количество инструментов, которые используют питонисты написаны совсем не на питоне. Питон нужен чтобы писать высокоуровнеаую логику. В этом его сила
А я не понял как вы из количества строк получили скорость разработки? Допустим я 6.5 часов думаю над кодом и 1.5 часа пишу. Если мы меняем язык (java -> python), то думать остается столько же, а писать меньше. То есть из 8 часов на джаве получаем 7 часов на питоне. Числа говно, просто из головы взяты, но если вы оцениваете скорость разработки на основе скорости написания букв, пожалуйста приведите ваши числа.
Для справки, если реально учитываем скорость набора, то при длине 100 символов в каждой строке (оценка сверху, в реальности много строк короче) и 200 знаков в минуту (средняя скорость набора согласно гуглу без учета автодополнения), мы получаем что небольшой проект размером 10к строк можно написать за 10 дней. В реальности он может писаться несколько месяцев.
Я очень люблю питон и считаю, что программа на нем действительно может выглядеть компактее и выразительнее, чем на дажве. Но! Если сравнивать реальные проекты, компактность кода там достигается как раз счет того, что вы говорите - в жертву было принесено всё что угодно: читаемость, декомпозиция, структуры данных
Почему вы сравниваете размер хэлловорлдов, а не реального кода? Так никто не пишет
В реальном коде это будет функция, которую вызывают из другого кода. А то и класс. Но даже без этого, код за пределами "показать как могу" будет скорее походить на
Примере с CSV код на джаве на самом деле не парсит CSV, а только наивно делит по запятым. В реальности значение ячейки может содержать запятую и с этом случае берется в кавычки.
В примере с сортировкой на джаве делается in-place, а в питоне через дополнительные списки
В случае с HTTP вы для питона взяли стороннуюю библиотеку, а для джавы - нет. Взяли бы тогда уж urllib.request. Либо попробуйте для разнообразия туда добавить типизацию данных и сравнить, например, мой dataclass-rest и retrofit.
Для асинхронной обработки вы использовали разную модель многозадачности. Корректнее было взятьThreadPoolExecutor.
Я не уверен насчет обработки иключений в джаве, очень много визуального мусора потому что в джаве вы добавили обработку checked исключений, а в питоне оставили программе падать. В реальном коде, вероятно вы бы и в питоне стали их обрабатывать, или дали джава фреймворку ловить всё (сорри, с джавой не работал, там же фреймворк может сам ловить Exсeption и кидать 500?)
Мне кажется Mediatr называть реализацией паттерна медиатор не вполне корректно. Это все таки центральная шина, которая требует отправитель затачивать под нее и делать встраиваемые обработчики. В то время как классический медиатор просто про наличие источников событий и использование медиатора как их обработчика, делающего полезную работу.
Чистая архитектура - это в первую очередь книжка про SOLID, доугие принципы и чуточку про слои. При чем там говорится что слои надо делать исходя из потребностей проекта. Так что формальное следование ей в целом очень сомнительно, только если читать часть, игнорируя остальное.
Мейн - это не файл и не функция в контексте ЧА. Это отдельный компонент, который занимается настройкой и запуском остального кода.
Если же мы зависимости кладём где-то среди вьюх, у нас появляется две причины редактировать вьюхи: изменение логики представления и изменения компоновки приложения. Логично выделить зависимости отдельно. Окей, теперь у нас вьюхи не содержат кода компоновки, но зависят от него. Если это делать аккуратно, наверно все будет окей, но часто я вижу что такие функции create_db начинают использовать глобальные переменные вроде настроек и сессий. Это стреляет во-первых из-за порядка инициализации (в тестах мы можем хотеть настройки задать после импорта), а во-вторых, из-за связи некоторых таких ресурсов с асинкио лупом. Поэтому если мы и делаем такие зависимости, они ни в коем случае не должны оперировать глобальными переменными. Остальные проявления в виде завязки на реализацию скорее всего не выстрелят, но я предпочитаю вьюхи отделять от остальной инфраструктуры, чтобы они вообще не знали ни о чем кроме интеракторов и может быть каких-то DAO для запросов чтения. Так же, тут есть проблемы что в fastapi при всем преимуществах его механик Depends слабая система управления скоупами, я тут предпочитаю самописный свой контейнер, но это уже совсем другая тема
Текущий нарушает S в слове SRP - отвечает не за представление, а ещё и за связывание компонентов.
не надо так делать, просто делайте Depends() или с указанием заглушки, а в dependency_overrides пихайте как его создавать. Или можно взять внещний ioc-контейнер, чтобы отделить от возни с парсингом запроса
верно говорите, сборка зависимостей идет в "main", который знает обо всех частях приложения
почему у вас в интерфейсе появились детали реализации? интерфейс нужен для абстрагирования
ну вот сами сказали - один раз настроили и используется в мейн. Это часть мейна, а никакая не "общая часть".
архитектура описывает вообще всё приложение, утили вписываются в него. ваша утиль пересекает несколько архитектурных слоев. Это может быть ок, но тогда мы должны аккуратненько её отложить в сторону и выстроить вокруг неё заборчик. Условно - сделать модульный монолит.
мой вариант: в каждом конкретном случае решать куда положить тот или иной кусок кода и назвать модуль согласно тому что там и за что оно отвечает, а не utils.