Задать вопрос
SemenFrolov

Semen Frolov

Newbie developer
Лайки

  • Как язык go может быть компилируемым?

    @d-sem
    Go компилируемый потому что он компилируется
    Ответ написан
    3 комментария
    3 комментария

  • Как использовать/прокинуть переменную из lua в конфиге nginx?

    @anikavoi
    Делать надо наоборот:

    в nginx овском конфе:

    set $rr_add_log ''; # this line is required to create $rr_add_log at config time

    в script.lua
    ...
    ngx.var.rr_add_log = "someone"
    ...
    Ответ написан
    Комментировать
    Комментировать

  • Как выполнить поиск с полным совпадением по массиву?

    @bpGusar Автор вопроса
    *spoiler*
    Нашел решение.
    Надо использовать $all вместо $in
    Chats.countDocuments(
  {
    members: {
      $all: ["userIdOne", "userIdTwo"]
    }
  },
  cb
)
    Ответ написан
    Комментировать
    Комментировать

  • Как правильно организовать разработку с использованием docker?

    gecube
    @gecube
    системный администратор, программист... все дела..
    Черновой ответ, потому что у всех детали могут отличаться - делайте как Вам удобнее.

    1. Есть принципиально два подхода. Первый - один репозиторий - один артефакт. Он достаточно удобен, т.к. позволяет раздавать доступы на репозитории разным командам, если они пилят разные модули. Так же это в рамках гита позволяет удобно реализовать разные релизные циклы для разных модулей. С другой стороны - сразу получаете проблему интеграции всех этих репозиториев в единую систему. Обычно решается каким-то мета-репозиторием, который знает как собрать проект из кусочков. Или инклюдит все остальные репозитории как субмодули. Еще если маленьких репозиториев очень много и нужно вносить параллельные изменения в несколько сразу - это очень неудобно для разработчиков. Вторая крайность - это монорепозиторий. Когда ВЕСЬ проект состоит из одного репозитория. Это очень удобно в ситуации, когда у Вас только ОДНА, крайняя версия продукта. Т.к. всегда все собирается из одного коммита и либо все сразу срастается и есть гарантии совместимости всех модулей, либо надо исправлять код ) При этом зачастую приходится очень четко продумывать структуру проекта (например, раскладывать каждый отдельный модуль в отдельный каталог), теряете возможность работы с внешними подрядчиками (придется им заводить отдельные репки + настраивать синхронизацию), делать всякие обертки, чтобы не собирать весь проект, а только изменившиеся части, т.к. сборка всего может быть очень долгой. Но, да, этот подход тоже имеет право на жизнь. Тем более пока не попробуете сами - точно не сможете понять, что лучше
    docker-compose - это хорошо для разработки и моделирования кучки сервисов. Для продакшена не очень хорошо.

    2. Идеально - один контейнер - один сервис. Но для целей разработки можно использовать контейнеры как средство доставки чего бы то ни было и там рождаются кадавры с несколькими сервисами в одном контейнере. Но для продакшена это не очень.

    3. ansible, gitlab-ci

    4. все имеет значение. Зависит от ваших возможностей и задач. Точно стоит избегать всяких OpenVZ, лучше всего деплоится на настоящие виртуальные машины. Как правило они на KVM технологии. По операционной системе - лучше брать то, с чем умеете работать, либо можете привлечь специалистов. Т.е. популярные варианты - centos, ubuntu, debian. Все остальное можно рассмотреть только в случае каких-либо _особых_ требований. Например, очень крутая штука CoreOS, если запускать ТОЛЬКО лишь контейнеры - ничего лишнего, атомарные обновления, но хорошо это работать будет только на виртуалках, а если надо запускаться на железном сервере ? То тут уже нюансы

    5. никак. Она с докерами никак не дружит.

    6. Думать. Проектировать. Очень важно понимать как будет запускаться приложение, сколько будет реплик, как они будут взаимодействовать, делить общие ресурсы (файлы, записи в БД, очереди и пр). Касательно файлов - для докер-контейнеров - чтобы обеспечить их сохранность, все нужное нужно писать либо в bind mount, либо в volume - тогда данные не пропадут при удалении контейнера.

    > Насколько я понимаю, при разворачивании очередного релиза старые контейнеры сносятся и ставятся новые - это так?

    Совсем высокоуровнего - да, так.
    Ответ написан
    4 комментария
    4 комментария

  • Как описать структуру входных данных?

    @ghostiam
    На Go писатель, серверов пинатель.
    resp.Body содержит только байты и ничего более.

    Вы можете в зависимости от статуса ответа сервера resp.Status, выбирать, как вам обрабатывать данные.
    Например, у меня в проектах сделано так:
    Когда статус запроса 200, я декодирую его как обычно.
    Если статус другой, я ожидаю, что он будет содержать другую структуру, в которой будет описание ошибки и пытаюсь его декодировать в эту структуру и возвращаю как ошибку.
    Но если декодирование ошибки не удалось, то я просто возвращаю ошибку, содержащую текст Body.
    Ответ написан
    Комментировать
    Комментировать

  • Как правильно составить регулярное выражение?

  • Как в Mongo сделать выборку данных по одной сущности с оператором ИЛИ?

    @NinjaNickName
    Web разработчик
    Получили награду Х или Награду У

    {$or : [{rewardId : 1}, {rewardId : 2}]}

    и так еще можно
    {rewardId : {$in : [1, 2]}}

    Задача 2: Показать всех пользователей, которые
    1. Получили награду Х или Награду У
    И
    2. Выполнили задание Х или задание У

    {$or : [{rewardId : 1}, {rewardId : 2}],
 $or: [ { taskId : { $eq: 1 } }, { taskId : { $eq: 2} }]
}


    Логические операции, $or, $and, $where, mapReduce

    Сложные запросы можно еще вот так делать:
    db.foo.find({$where : function() { 
  return (this.cost>5 && this.cost<10 )|| (this.is_hidden != 1) || (this.link == this.url);
}})

    Источник
    Ответ написан
    Комментировать
    Комментировать