• Выбор СУБД для веб-сервиса на Erlang?

    @b0beR
    Еще рекомендую как вариант рассмотреть mongoDB. Очень удобное и быстрое хранилище. У нас вполне успешно работало в связке с Erlang'ом в одном проекте. И, кстати, недавно вышел официальный erlang-драйвер от разработчиков mongoDB.
    Ответ написан
  • СПб, ночное кафе/интернет-кафе/кофейня с Wi-Fi?

    @b0beR
    Ну я, например, иногда работаю в «Кофе Хауз». Они по всему городу на каждом углу, там приличный кофе, всегда есть wi-fi и розетки. Адреса можете посмотреть у них на сайте.
    Ответ написан
  • Как правильно ориганизовать комментарии при использовании Mongo DB?

    @b0beR
    Я считаю, что лучше всего хранить комментарии и информацию о пользователях отдельно. Соответственно каждому комментарию прописывать ObjectID автора (ну или просто id числом). Куча запросов в данном случае совершенно не нужна. Нужно всего лишь после получения списка комментариев пройти по ним и сложить все id авторов в массив, после чего сделать ОДИН запрос, и получить всех авторов (естественно только те поля которые нужны). Примерно так:
    authors = db.users.find({"_id": {"$in": authors_ids_array}}, {«nickname»: 1, «photo»: 1});
    Собственно запрос по индексированному полю будет моментален, даже при большом количестве запрашиваемых пользователей. После этого соотнести комментарии с полученными пользователями я думаю уже проблем не составит :)
    Отдельно по поводу хранения самих комментариев. Тут есть 2 варианта.
    Если вам нужна будет возможность довольно часто делать выборку всех комментариев определенного автора, то под комментарии лучше всего создать отдельную коллекцию (то есть хранить каждый комментарий в отдельном документе), с индексированными полями author_id и topic_id. Но в таком случае количество документов в коллекции может вырасти до огромных масштабов.
    Если же таких запросов не будет, либо они будут довольно редкими, то быстрее и удобнее хранить все комментарии определенного материала массивом в документе этого самого материала, и тогда не нужно будет обращаться к другой коллекции при получении материала и его комментариев. Запрос всех комментариев определенного автора в таком случае тоже возможен, хотя и будет несколько медленнее.
    Ответ написан
  • Nginx возвращает 403, при том, что index имеется?

    @b0beR
    И все таки вероятнее всего не выставлены права на одну из родительских папок
    Если хотя бы к одной из них у пользователя, от имени которого запущен nginx, нет прав на чтение, то будет 403.
    Ответ написан
  • Программирование в метро

    @b0beR
    Когда я работал в офисе, у меня на дорогу уходило минут 40, либо на маршрутке, либо на метро. Если едешь в час пик, то пытаться поработать в дороге бесполезно. Но вот если народу в транспорте немного, то мне вполне удавалось попрограммировать минут 30 из этих сорока.
    P.S. Ноут — MacBook White 13'
    Ответ написан
  • Простой и надежный менеджер паролей

    @b0beR
    Отличный вариант 1password. Он и отдельным приложением, и плагины для браузеров. Есть под разные платформы. Пользуюсь уже давно, впечатления только хорошие.
    Ответ написан
  • Git deploy. Много разработчиков против одного сайта с админкой

    @b0beR
    Я считаю, что наиболее удобный способ использовать post-receive хуки в центральном репозитарии гита (если таковой имеется), либо (если проект хостится на гитхабе) использовать post-receive url. При этом в деплой должны попадать изменения, залитые в одну конкретную ветку гита (для тестовой версии это чаще всего ветка develop).

    Опять же, если над сайтом работает несколько человек, проблем не возникает, так как каждый сначала сам делает merge своих изменений в develop, после чего push ветки develop в центральный репозитарий.

    Файлы, которые меняются из админки, не должны быть в репозитарии (логично добавить их в .gitignore) Если же предполагается, что в репозитарии должны лежать изначальные версии этих файлов, а затем они могут правиться из админки (не очень хорошая практика), то логичнее будет вместо например файла translation.xml добавить в репозитарий файл translation.tpl.xml, и уже в самом скрипте деплоя (который вызывается из хука), копировать этот файл в настоящий translation.xml. Если же он был изменен из админки, то это уже ваша проблема, как обрабатывать такие конфликты. В нормально спроектированной системе такого быть не должно.

    Вообще, очень удобно сочетать такую систему деплоя с использованием git flow. Тогда в ветку develop будет попадать только код, готовый к тестированию (и соответственно сразу выкладываться на тест), а в master будет мерджиться только production-ready код из ветки develop (если все сделать грамотно, то из master'а можно автоматом выкладывать на релиз, главное чтобы туда никто кроме руководителя проекта не пушил)

    P.S. Если интересно, могу написать статью про использование git flow совместно с post-receive URL гитхаба для выкладывания тестовой версии.
    Ответ написан