Задать вопрос
  • На чём лучше прокачивать архитектурный навык разработки моделей предметной области и принципов DDD вообще?

    XAKEPEHOK
    @XAKEPEHOK
    Посмотрите записи вебинаров Дмитрия Елисеева, "Интенсив ООП" - очень рекомендую
    www.elisdn.ru/oop-week
    Ответ написан
    Комментировать
  • Тайм-трекер, максимально похожий на тайм-трекер UpWork?

    maxaus
    @maxaus
    Вошёл вайти и пока не вышел
    TopTracker можете попробовать, вроде описанное умеет и бесплатен.
    Ответ написан
    1 комментарий
  • В каких случаях вы использовали Redis?

    @chronic86
    Ruby on Rails junior
    1. Хранилище сессий и профилей пользователей;
    2. Сервер очередей, плюс держим в уме механизм publish/subscribe;
    3. Полноценная замена Memcached, притом в случае с Redis мы получим репликацию, более длинные ключи и значения, возможность восстановления кэша с диска и тп;
    4. Место для хранения количества пользователей онлайн, кодов капч, различных флагов, саджестов поисковых запросов;
    5. СУБД для небольших приложений — сокращалок ссылок, имиджбордов, возможно даже блогов;
    6. Роль «словаря» в шардинге, то есть сервер, который знает, какие шарды на каких серверах искать;
    7. Хранилище промежуточных результатов вычислений при обработке больших объемов данных;


    eax.me/redis
    Ответ написан
    Комментировать
  • Как контролировать работу удаленного программиста?

    customtema
    @customtema
    arint.ru
    Для начала, не надо было пытаться так экономить. Судя по тому, что на решение задачи тратятся месяцы - вы искали самого дешевого программиста, и с вами согласился сотрудничать новичок. Он сейчас скорее всего жалеет о том, что с вами связался. Простите, но вы сами виноваты. Семь шапок из одной овцы не выкроишь никак.

    Любая задача решается не более, чем за одну неделю. Подавляющее большинство программ выпускаются в бету за 2-3 месяца. Если дольше - нужно бить тревогу. Или неправильное планирование, или проблемы в команде.

    Мониторить просто - по списку задач в трекере и/или по коммитам. Не нужно ожидать, что разработчик будет выдавать какой-то прогресс ежедневно. Программирование - это не линейный процесс. Можно день-два протупить, а потом за десять минут сделать - такое происходит постоянно. Удобными для всех будут ежеденедельные итерации. Например, каждый понедельник проверять прогресс за неделю, и при необходимости, скорректировать его.

    Не выносите разработчику мозги длинными беседами. У программистов мозг несколько иначе устроен, и длинными беседами вы ему мозг выносите. После чего ему работать сложно - таким образом вы сами создаете проблемы. Пишите вопросы текстом, и делайте это не чаще, чем один раз в неделю. Накапливайте вопросы, прежде чем отправить их письмом. Если вы нашли ответ на вопрос самостоятельно - удалите его из списка. Проверьте, нет ли ответов на вопросы в интернете.

    Это удивительно, но многие, будто конченные олигофрены, не понимают, что консультации отнимают и силы, и время. И именно поэтому должны быть регламентированы.

    С консультациями, как с сексом. Хотите, чтобы было качественно? Тогда нужно хорошо подготовиться. И вести себя прилично. Всегда. Хотите хорошие ответы? Продумайте свои вопросы.

    В состоянии потока любая хрень может отвлечь и нарушить рабочее состояние. Особенно - вопросы. Особенно - глупые вопросы. Глупые не с вашей точки зрения, а с точки зрения разработчика. Программист работает циклами по 2-4 часа. Если нарушить цикл (например, задав глупый вопрос или позвонив по телефону) - теряется ПОЛОВИНА ДНЯ.

    Поэтому мое второе замечание - проверьте, а не мешаете ли вы ему работать?
    Ответ написан
    3 комментария