Я мало пользовался им для Python, но много использовал для Java, и на качество сгенерированного кода пожаловаться не могу. Собственно, он генерируется на этапе сборки, его не нужно читать, он валидный и работает - остается только использовать. Бывало, что классы модели получались странными, но связано это было с кривизной спецификации (исправлялась спецификация - выпрямлялись и модели). Ну и для случая, когда генератор чего-то не делает или делает не так, как было нужно, всегда есть возможность исправить шаблоны.
Без генератора писать код API-клиента в случае большого API (большой, это десятки разделов/подмодулей и сотни endpoint'ов, например, как у Amazon Ads) идея безумная.
Так же есть очень хороший подход specification first, когда все контракты заранее известны, а код вторичен. Меняем спеку - меняется код, не наоборот. И из спеки автоматом получаем документацию и набор тестов.
Если есть спецификация API в формате OpenAPI, гораздо проще сгенерировать обертку для всего сразу с помощью OpenApiGenerator (для очень большого количества языков, не только Python). Также, для своего API, можно и контроллер для серверного кода сделать.
"более 6 лет опыта в сложной нише ремонтов в Москве, работал с миллионными бюджетами и прошёл много курсов" -- ожидал узнать про строительно-ремонтный фриланс в Москве с милионными бюджетами. Эх, какое разочарование :)
Еще как может. У меня дважды было, что ни с того, ни с сего, в разговор в машине вдруг встревала Алиса, комментируя только что произнесенную кем-то фразу. При этом Алисы на телефоне отдельно у меня не установлено, только как голос в Яндекс.Навигаторе, причем в эти моменты был активирован другой голос (кота Гурме).
Неявное изменение состояний объектов — один из источников ошибок (на Python, кстати, на эти грабли еще проще наступить, т.к. все поля класса открыты), которого лучше всё же избегать, по-моему мнению. По крайней мере важно разделять неизменные объекты и изменяемые. Когда делается гибкая архитектура с «мягкими» правилами (которые нужно соблюдать по факту использования, но не по факту определения), обязательно найдется код, который сделает это недостаточно корректно.
Не хочу критиковать архитектуру Symphony, т.к. толком с ней не знаком, но когда используется общий принцип/вызов передачи сообщений для совершенно различных операций над объектами (как, например, прокинуть какие-то параметры через универсальный изменяемый объект-событие), затрудняется еще и поиск кода, который такие изменения делает (т.к. все участники делают однотипные вызовы с примерно похожими параметрами). И одно дело, если это что-то вроде протокола шины обмена сообщениями (который сверху обернут в более высокоуровневый протокол с методами/функциями, названия которых говорят о совершаемом действии), и другое, если это основной способ общения между объектами в архитектуре приложения. Я сейчас такую проблему вижу в Django Channels — фреймворке-надстройке над Django, который добавляет в него асинхронности (слишком просто всё делать через channel.send(message), к счастью, содержимое message никто не меняет).
В общем, всё сложно, и особенно сложно сделать всё хорошо :)
Я мало пользовался им для Python, но много использовал для Java, и на качество сгенерированного кода пожаловаться не могу. Собственно, он генерируется на этапе сборки, его не нужно читать, он валидный и работает - остается только использовать. Бывало, что классы модели получались странными, но связано это было с кривизной спецификации (исправлялась спецификация - выпрямлялись и модели). Ну и для случая, когда генератор чего-то не делает или делает не так, как было нужно, всегда есть возможность исправить шаблоны.
Без генератора писать код API-клиента в случае большого API (большой, это десятки разделов/подмодулей и сотни endpoint'ов, например, как у Amazon Ads) идея безумная.
Так же есть очень хороший подход specification first, когда все контракты заранее известны, а код вторичен. Меняем спеку - меняется код, не наоборот. И из спеки автоматом получаем документацию и набор тестов.
Если есть спецификация API в формате OpenAPI, гораздо проще сгенерировать обертку для всего сразу с помощью OpenApiGenerator (для очень большого количества языков, не только Python). Также, для своего API, можно и контроллер для серверного кода сделать.
Beko WKM 7322
Вспомнил моего тренера в университете, который на сдаче нормативов на подтягивание говорил каждому второму: "Такой большой, а кисти слабые!". :)
Недавно покупал новый (электрический) чайник, и сформулировал следующий набор критериев для выбора:
Полностью металлическая внутренняя поверхность без стыков из хорошей нержавейки (чтобы не варилась пластмасса).
Широко открывающаяся крышка (чтобы легко было наливать воду и мыть от накипи).
С защитой от сухого включения.
С внешним защитным корпусом (чтобы никто не обжёгся).
П. 1 требует, чтобы обзорного окна для уровня воды не было, но п. 3 делает это ограничение не существенным.
П. 2 предполагает боковую ручку.
В итоге, нашел лишь один вариант, который бы включал все четыре и при этом не стоил, как ракета.
Могут быть степени и разновидности, в зависимости от классификаций -- https://ru.wikipedia.org/wiki/Синдром_дефицита_внимания_и_гиперактивности
Это зависит от книги, зависит от времени, на которое вас прервали, но также зависит от степени СДВГ :)
"более 6 лет опыта в сложной нише ремонтов в Москве, работал с миллионными бюджетами и прошёл много курсов" -- ожидал узнать про строительно-ремонтный фриланс в Москве с милионными бюджетами. Эх, какое разочарование :)
Невероятная красота! Спасибо.
По каким координатам такая красота?
Спасибо за фотографии в начале статьи - отлично видно, как всё отражается в глянцевом экране, на таком только в темной комнате работать.
Это было в приложении под андроид, браузер запущен не был.
Еще как может. У меня дважды было, что ни с того, ни с сего, в разговор в машине вдруг встревала Алиса, комментируя только что произнесенную кем-то фразу. При этом Алисы на телефоне отдельно у меня не установлено, только как голос в Яндекс.Навигаторе, причем в эти моменты был активирован другой голос (кота Гурме).
Они смогли найти цвет, который не используется ни одним из производителей инструмента. Но что это за цвет?!! :_(
Лучшее правило, которое пока еще ни разу не подводило за 15 лет фриланса - не работать с российскими компаниями.
Это гениально, бро!
Не хочу критиковать архитектуру Symphony, т.к. толком с ней не знаком, но когда используется общий принцип/вызов передачи сообщений для совершенно различных операций над объектами (как, например, прокинуть какие-то параметры через универсальный изменяемый объект-событие), затрудняется еще и поиск кода, который такие изменения делает (т.к. все участники делают однотипные вызовы с примерно похожими параметрами). И одно дело, если это что-то вроде протокола шины обмена сообщениями (который сверху обернут в более высокоуровневый протокол с методами/функциями, названия которых говорят о совершаемом действии), и другое, если это основной способ общения между объектами в архитектуре приложения. Я сейчас такую проблему вижу в Django Channels — фреймворке-надстройке над Django, который добавляет в него асинхронности (слишком просто всё делать через channel.send(message), к счастью, содержимое message никто не меняет).
В общем, всё сложно, и особенно сложно сделать всё хорошо :)
Спасибо за разговор.