Как стать автором
Обновить
60
0
Vladimir Kozlovsky @vladkozlovski

Inventor. Rebel. Entrepreneur.

Отправить сообщение
У меня там больше переменных:

ask_sudo_pass=True
remote_user = support
private_key_file=...

Я удалил их, когда заливал на GitHub, потому что это касается только моей конфигурации. Если у кого-нибудь появится необходимость добавить несколько параметров, он просто допишет их в готовый файл.
Если у вас более-менее нормальная компания, то такие решения программисты принимать не будут. Что бы принять решение об использовании той или иной БД, надо учитывать множество факторов. Например:

  • Какую нагрузку вы планируете держать? (нужны тесты производительности в реальных условиях, возможно из прошлого опыта)
  • Будет много записей? Если да, то есть ли место для них? Может нужен движок с компрессией? (нужно иметь представление о существующих движках различных БД и как они работают)
  • У вас 1 или несколько ДЦ? Нужна БД с репликацией «из коробки» или можно настроить с помощью костылей? (нужно иметь представление о методах репликации в различных БД)
  • У вас критичные для записи данные? Нужны транзакции?
  • Вы готовы платить за поддержку БД или надо только из opensource выбирать? (вообще вопрос на уровне начальства)
  • Как эта база вообще работает внутри? Много памяти она жрёт? У вас вообще есть много памяти?
  • У вас HDD или SSD диски?
  • Какая скорость ответа приемлема для вас?
  • Какие запросы вы будете использовать? Можно ли спроектировать эту БД так, что бы они были возможны и эффективны?
  • И ещё 100 вопросов

Команды создаются для того, что бы специалисты из различных областей сотрудничали вместе и принимали более взвешенные решения. Если вам надо принять такого рода решения, то надо пообщаться хотя бы с сис. админом, предъявив ему список требований, возможно с начальством после него. И когда вы примите решение, вы придёте и скажите программисту: используем Mongo, документация у них на сайте. Хорошему программисту этого будет достаточно.

Я бы на месте вашего программиста использовал то, что мне интересно, что бы получить необходимый опыт за ваш счёт (если бы вы мне дали возможность принимать такие решение). И дорогая память, которую будет жрать БД, меня бы вообще не беспокоила, это же деньги компании, а не мои.
Расскажите об этом Стиву Возняку. Отец ему начал рассказывать принципы электротехники, когда он еще не достиг четырех лет.
В данный момент в production мы даже docker-swarm не используем, у нас мало машин пока. Деплоим с помощью ansible, который автоматом запускается после коммита в git репозиторий. Приложения собираем из Dockerfile, да.
Всё никак статью про deploy руки не дойдут написать и рассказать про это. Он и используется у нас для изменения конфигов, конечно.
Гляньте в логи Eve, там должно быть описание ошибки. Скорее всего проблемы с подключением к БД, например пароль неправильный и т.д.
А на чём должен работать перфекционист, как не на маке?

Перфекционизм — это стремление к совершенству. Тот факт, что мы являемся самыми умными существами на планете и остерегаемся во время прогулки только себе подобных, позволяет говорить о том, что мы одна из лучших работ эволюции.

Я не буду рассуждать на тему: правильно/неправильно. Я не разработчик фреймворка и не учавствовал в создании стандартов. Я выражаю лишь своё мнение — я считаю вариант Eve удобнее. Более того, вариант Eve используется в большинстве случаев.

но потом клиента к нему писать придётся самому и работать с особенностями Eve на клиенте — тоже

Тоже самое можно сказать и о вашей спецификации и придерживаться её – сложнее. Хотя бы потому, что она сама на порядок сложнее. По крайней мере для меня.

Для случая просто смены URL я оставляю старый URL, в документации помечаю deprecated, а в следующей версии, когда других изменений уже накопилось много — удаляю.

Ну об этом и речь. Я не буду ничего помечать «deprecated» и удалять в следующей версии. Я просто поменяю URL.

По The OpenAPI Specification (fka The Swagger Specification) строить админку куда легче, чем ходить по всем URL.

Я не такой любитель стандартов и спецификаций. В начале статьи я написал о простоте, мне чем проще, тем лучше.

Я 2.5 года работаю в стартапе без выходных, каждый день по 12-14 часов, иногда и того больше. Работы с каждым днём меньше не становится и если бы я каждый раз тратил на задачу больше времени, чем требуется, хотя бы на чуть-чуть, то стартап закрылся бы уже давно, а я лежал в больнице с переутомлением.

Хуки хуками, а бизнес логику куда девать? Её не существует? Самое первое препятствие — роли пользователей, в частности «владелец» объекта и «менеджер», который имеет доступ в том числе ко всем объектам своих подчинённых (в простом случае).

Стандартная задача, решается легко. Вариантов реализации много, примеры можно найти в официальной документации.
Это решили не в Python Eve. Я часто встречал такое использование и это уже, похоже, внегласное соглашение. Всё, как обычно для простоты использования. Посмотрите на примеры из статьи, которую вы привели в пример:

[
    { "op": "test", "path": "/a/b/c", "value": "foo" },
    { "op": "remove", "path": "/a/b/c" },
    { "op": "add", "path": "/a/b/c", "value": [ "foo", "bar" ] },
    { "op": "replace", "path": "/a/b/c", "value": 42 },
    { "op": "move", "from": "/a/b/c", "path": "/a/b/d" },
    { "op": "copy", "from": "/a/b/d", "path": "/a/b/e" }
]

Так они хотят вносить изменения в 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 и всё будет здорово.

Или вам удобнее модели в Django кодом описывать?
Не только вас. Я даже и не пытался запомнить параметры.

Рад, что статья вам понравилась).
Есть всё, что вы указали и ещё больше. Построен фреймворк на базе Flask, так что вы можете использовать все его возможности. Пример кастомной валидации. Помимо возможностей Flask, вы можете описать логику и привязать к событиям Eve.
Речь идёт о простоте. Кодовую базу Django я бы простой не назвал. Eve построен на Flask, куча плагинов у него тоже есть и с сообществом нет проблем.

С ORM тоже непонятно. Если он мне не нужен? Лично я вообще уже забыл когда мне надо было использовать реляционную БД, а вот репликацию и шардинг я использую почти во всех своих проектах.

Про Yii2 я ничего сказать не могу, PHP руками не трогаю.
Часто задумываюсь об этом, но постоянно ловлю себя на мысли – «кто я такой, что бы учить других жизни?».
Консоль поработила моё сознание уже очень давно. Тут уже ни один плагин не сможет мне помочь.
Есть поддержка SQLAlchemy с помощью плагина.
Всё это очень сложно объяснить «обычным» людям. И ключевая фраза к этому:
Но стоит немного выделиться из массы начинаются проблемы

Большинство людей не имеет с этим проблем, потому что за всю жизнь могут ни разу нигде не выделиться. В итоге получается ситуация, когда за людьми, которые могут применять технические средства защиты, помогают следить те, кто такие средства использовать не хочет.

Например вы не пользуетесь сотовым телефоном, а 20 человек вокруг вас — пользуются. Кто-то фотографируется на вашем фоне, кто-то ведёт с вами беседу, а его телефон слушают. Вы храните свои письма у себя на сервере, а человек, с которым вы переписываетесь, использует gmail. Ну и т.д. Это своего рода нейтрализатор.

Информация

В рейтинге
Не участвует
Дата рождения
Зарегистрирован
Активность