Я тоже на личном опыте заметил: негатив — сильное чувство. Несколько раз за комментарий ставили минус в карму сразу на Хабр, Мегамозг, Geektimes и сам комментарий. Думаю, с чувством обиды, что минус можно поставить только один.
ask_sudo_pass=True
remote_user = support
private_key_file=...
Я удалил их, когда заливал на GitHub, потому что это касается только моей конфигурации. Если у кого-нибудь появится необходимость добавить несколько параметров, он просто допишет их в готовый файл.
Если у вас более-менее нормальная компания, то такие решения программисты принимать не будут. Что бы принять решение об использовании той или иной БД, надо учитывать множество факторов. Например:
Какую нагрузку вы планируете держать? (нужны тесты производительности в реальных условиях, возможно из прошлого опыта)
Будет много записей? Если да, то есть ли место для них? Может нужен движок с компрессией? (нужно иметь представление о существующих движках различных БД и как они работают)
У вас 1 или несколько ДЦ? Нужна БД с репликацией «из коробки» или можно настроить с помощью костылей? (нужно иметь представление о методах репликации в различных БД)
У вас критичные для записи данные? Нужны транзакции?
Вы готовы платить за поддержку БД или надо только из opensource выбирать? (вообще вопрос на уровне начальства)
Как эта база вообще работает внутри? Много памяти она жрёт? У вас вообще есть много памяти?
У вас HDD или SSD диски?
Какая скорость ответа приемлема для вас?
Какие запросы вы будете использовать? Можно ли спроектировать эту БД так, что бы они были возможны и эффективны?
И ещё 100 вопросов
Команды создаются для того, что бы специалисты из различных областей сотрудничали вместе и принимали более взвешенные решения. Если вам надо принять такого рода решения, то надо пообщаться хотя бы с сис. админом, предъявив ему список требований, возможно с начальством после него. И когда вы примите решение, вы придёте и скажите программисту: используем Mongo, документация у них на сайте. Хорошему программисту этого будет достаточно.
Я бы на месте вашего программиста использовал то, что мне интересно, что бы получить необходимый опыт за ваш счёт (если бы вы мне дали возможность принимать такие решение). И дорогая память, которую будет жрать БД, меня бы вообще не беспокоила, это же деньги компании, а не мои.
В данный момент в production мы даже docker-swarm не используем, у нас мало машин пока. Деплоим с помощью ansible, который автоматом запускается после коммита в git репозиторий. Приложения собираем из Dockerfile, да.
А на чём должен работать перфекционист, как не на маке?
Перфекционизм — это стремление к совершенству. Тот факт, что мы являемся самыми умными существами на планете и остерегаемся во время прогулки только себе подобных, позволяет говорить о том, что мы одна из лучших работ эволюции.
Я не буду рассуждать на тему: правильно/неправильно. Я не разработчик фреймворка и не учавствовал в создании стандартов. Я выражаю лишь своё мнение — я считаю вариант Eve удобнее. Более того, вариант Eve используется в большинстве случаев.
но потом клиента к нему писать придётся самому и работать с особенностями Eve на клиенте — тоже
Тоже самое можно сказать и о вашей спецификации и придерживаться её – сложнее. Хотя бы потому, что она сама на порядок сложнее. По крайней мере для меня.
Для случая просто смены URL я оставляю старый URL, в документации помечаю deprecated, а в следующей версии, когда других изменений уже накопилось много — удаляю.
Ну об этом и речь. Я не буду ничего помечать «deprecated» и удалять в следующей версии. Я просто поменяю URL.
По The OpenAPI Specification (fka The Swagger Specification) строить админку куда легче, чем ходить по всем URL.
Я не такой любитель стандартов и спецификаций. В начале статьи я написал о простоте, мне чем проще, тем лучше.
Я 2.5 года работаю в стартапе без выходных, каждый день по 12-14 часов, иногда и того больше. Работы с каждым днём меньше не становится и если бы я каждый раз тратил на задачу больше времени, чем требуется, хотя бы на чуть-чуть, то стартап закрылся бы уже давно, а я лежал в больнице с переутомлением.
Хуки хуками, а бизнес логику куда девать? Её не существует? Самое первое препятствие — роли пользователей, в частности «владелец» объекта и «менеджер», который имеет доступ в том числе ко всем объектам своих подчинённых (в простом случае).
Стандартная задача, решается легко. Вариантов реализации много, примеры можно найти в официальной документации.
Это решили не в Python Eve. Я часто встречал такое использование и это уже, похоже, внегласное соглашение. Всё, как обычно для простоты использования. Посмотрите на примеры из статьи, которую вы привели в пример:
Так они хотят вносить изменения в JSON. Для XML предлагают вообще XML Path использовать. Но мне надо просто изменить значение, я не хочу ничего знать об XML Patch. Завтра вам понадобится использовать какой-нибудь другой формат данных, например YAML и надо будет придумать свой велосипед. Это если закрыть глаза на то, что составление такого запроса на порядок сложнее и не упростит реализацию мобильного клиента. А парсинг таких запросов на сервере, их валидация и обработка буду занимать больше времени.
У меня был опыт разработки WebDAV, в котором используется много стандартов. Также имел опыт создания CalDAV и CardDAV, которые являются дополнениями к WebDAV и могу вам сказать следующее: никто и никогда полностью не соблюдает стандарты, в особенности, когда они сложны. Реализация более-менее функционального сервиса WebDAV превращается в большую кучу патчей для всех распространённых клиентов.
Если вы попробуете использовать штатный WebDAV клиент Windows/OS X, то вряд ли найдёте хотя бы несколько серверов, с которыми у вас не будет проблем. Про CalDAV/CardDAV клиентов я промолчу. А ведь всё описано стандартами.
В общем сделали так, как более логично. Правильно это или нет, решать не мне. Но я бы поступил так же.
(люди решили почему-то, что обязательно нужно иметь ссылки в API, но API используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составить ссылки самостоятельно, в отличие от «кликающего пользователя»).
Они всегда будут принимать решение на основании содержимого ответа. HATEOAS даёт возможность не плодить v1/v2/v3/v1000, для случаев, когда там просто изменился один URL. Можно «хардокить» везде ссылки и пересобирать мобильные приложение и фронтенд каждый раз, если так удобнее.
Если говорить о каком-нибудь инструменте автоматического генерирования админки, то без HATEOAS там вообще обойтись не получится.
Кстати, интерфейсы взаимодействия в Eve меня пугают — JSON в GET параметрах выглядит странно
Не буду отрицать.
Всё это дело работает до поры до времени, пока у вас какой-нибудь хитрый случай не вылезет, где простым SELECT/UPDATE не отделаешься и начнётся «сладкая жизнь».
Вы документацию читали? Есть "хуки" на каждое событие, если их их мало, то есть все возможности Flask. Вы же сами дальше пишите, что Flask используете.
Давно работаю с Eve и такого рода проблем точно не встречал.
Это ещё не говоря о том, что dict с конфигом разрастается в реальном проекте мама не горюй и подстветка синтаксиса такому коду уже не поможет.
Есть альтернативные, более короткие, варианты описания моделей? Большой конфиг, разделите его на модели, модели опишите в YAML и всё будет здорово.
Есть всё, что вы указали и ещё больше. Построен фреймворк на базе Flask, так что вы можете использовать все его возможности. Пример кастомной валидации. Помимо возможностей Flask, вы можете описать логику и привязать к событиям Eve.
Речь идёт о простоте. Кодовую базу Django я бы простой не назвал. Eve построен на Flask, куча плагинов у него тоже есть и с сообществом нет проблем.
С ORM тоже непонятно. Если он мне не нужен? Лично я вообще уже забыл когда мне надо было использовать реляционную БД, а вот репликацию и шардинг я использую почти во всех своих проектах.
Про Yii2 я ничего сказать не могу, PHP руками не трогаю.
А плюс — это просто плюс в комментарий.
Я удалил их, когда заливал на GitHub, потому что это касается только моей конфигурации. Если у кого-нибудь появится необходимость добавить несколько параметров, он просто допишет их в готовый файл.
Команды создаются для того, что бы специалисты из различных областей сотрудничали вместе и принимали более взвешенные решения. Если вам надо принять такого рода решения, то надо пообщаться хотя бы с сис. админом, предъявив ему список требований, возможно с начальством после него. И когда вы примите решение, вы придёте и скажите программисту: используем Mongo, документация у них на сайте. Хорошему программисту этого будет достаточно.
Я бы на месте вашего программиста использовал то, что мне интересно, что бы получить необходимый опыт за ваш счёт (если бы вы мне дали возможность принимать такие решение). И дорогая память, которую будет жрать БД, меня бы вообще не беспокоила, это же деньги компании, а не мои.
Перфекционизм — это стремление к совершенству. Тот факт, что мы являемся самыми умными существами на планете и остерегаемся во время прогулки только себе подобных, позволяет говорить о том, что мы одна из лучших работ эволюции.
Тоже самое можно сказать и о вашей спецификации и придерживаться её – сложнее. Хотя бы потому, что она сама на порядок сложнее. По крайней мере для меня.
Ну об этом и речь. Я не буду ничего помечать «deprecated» и удалять в следующей версии. Я просто поменяю URL.
Я не такой любитель стандартов и спецификаций. В начале статьи я написал о простоте, мне чем проще, тем лучше.
Я 2.5 года работаю в стартапе без выходных, каждый день по 12-14 часов, иногда и того больше. Работы с каждым днём меньше не становится и если бы я каждый раз тратил на задачу больше времени, чем требуется, хотя бы на чуть-чуть, то стартап закрылся бы уже давно, а я лежал в больнице с переутомлением.
Стандартная задача, решается легко. Вариантов реализации много, примеры можно найти в официальной документации.
Так они хотят вносить изменения в JSON. Для XML предлагают вообще XML Path использовать. Но мне надо просто изменить значение, я не хочу ничего знать об XML Patch. Завтра вам понадобится использовать какой-нибудь другой формат данных, например YAML и надо будет придумать свой велосипед. Это если закрыть глаза на то, что составление такого запроса на порядок сложнее и не упростит реализацию мобильного клиента. А парсинг таких запросов на сервере, их валидация и обработка буду занимать больше времени.
У меня был опыт разработки WebDAV, в котором используется много стандартов. Также имел опыт создания CalDAV и CardDAV, которые являются дополнениями к WebDAV и могу вам сказать следующее: никто и никогда полностью не соблюдает стандарты, в особенности, когда они сложны. Реализация более-менее функционального сервиса WebDAV превращается в большую кучу патчей для всех распространённых клиентов.
Если вы попробуете использовать штатный WebDAV клиент Windows/OS X, то вряд ли найдёте хотя бы несколько серверов, с которыми у вас не будет проблем. Про CalDAV/CardDAV клиентов я промолчу. А ведь всё описано стандартами.
В общем сделали так, как более логично. Правильно это или нет, решать не мне. Но я бы поступил так же.
Стандарты это круто, пока следуют им другие.
Они всегда будут принимать решение на основании содержимого ответа. HATEOAS даёт возможность не плодить v1/v2/v3/v1000, для случаев, когда там просто изменился один URL. Можно «хардокить» везде ссылки и пересобирать мобильные приложение и фронтенд каждый раз, если так удобнее.
Если говорить о каком-нибудь инструменте автоматического генерирования админки, то без HATEOAS там вообще обойтись не получится.
Не буду отрицать.
Вы документацию читали? Есть "хуки" на каждое событие, если их их мало, то есть все возможности Flask. Вы же сами дальше пишите, что Flask используете.
Давно работаю с Eve и такого рода проблем точно не встречал.
Есть альтернативные, более короткие, варианты описания моделей? Большой конфиг, разделите его на модели, модели опишите в YAML и всё будет здорово.
Или вам удобнее модели в Django кодом описывать?
Рад, что статья вам понравилась).
С ORM тоже непонятно. Если он мне не нужен? Лично я вообще уже забыл когда мне надо было использовать реляционную БД, а вот репликацию и шардинг я использую почти во всех своих проектах.
Про Yii2 я ничего сказать не могу, PHP руками не трогаю.