Задать вопрос
  • Как лучше организовать структуру сервера на aws с docker контейнерами?

    Yeah
    @Yeah
    Так как в вопросе фигурирует AWS, то и поднимать все нужно с учетом сервисов, которые предоставляет AWS. Никаких трех контейнеров на инстанс!
    Итак, по пунктам:

    1. Для начала поднимаем и настраиваем VPC. Соевую заюзать готовый шаблон для Cloudformation. их можно легко найти на Github
    2. БД - AWS RDS - легко сетапится, можно с репликацией, можно без
    3. для API поднимаем Elastic Beanstalk с load balancer
    4. статику грузим в S3
    5. к S3 со статикой прикручиваем Cloudfront - в качестве CDN, так как раздача статики с S3 дороже, чем с Cloudfront
    6. Настраиваем Route53: корневой домен через ALIAS -> Cloudfront, api.domain.com, через CNAME на URL от Elasticbeanstalk


    Итого: нужен только один докер контейнер - для API.
    Ответ написан
    Комментировать
  • Как правильно обработать исключение?

    @bbkmzzzz
    try:
        es = Elasticsearch(elastic_servers, http_auth=(elastic_user, elastic_password))
        res = es.search(index=indices, body=quer
    except Exception as exc:
        print('ALARM!', exc.args)


    если нужен стек исключения - модуль traceback поможет
    from traceback import format_exc
    ...
    try:
        es = Elasticsearch(elastic_servers, http_auth=(elastic_user, elastic_password))
        res = es.search(index=indices, body=quer
    except:
        print('ALARM!')
        print(format_exc(10)) # 10 - глубина стека
    Ответ написан
    Комментировать
  • Как правильно обработать исключение?

    @Stqs
    senior software developer
    chistya,

    а чо try-except отменили уже?
    Ответ написан
    Комментировать
  • После загрузки кода на продакшен, как всем посетителям очистить кеш?

    sergey-gornostaev
    @sergey-gornostaev Куратор тега Django
    Седой и строгий
    Используйте Django Compressor, он и сжимает автоматически и обеспечивает версионирование.
    Ответ написан
    Комментировать
  • В какой момент вы понимаете, что продукт готов к переходу со стадии бета версии на стадию полноценного монетизируемого продукта?

    @kn0ckn0ck
    Продюсер
    Критерии готовности продукта:
    - [качество] нет ошибок, которые бы мешали использованию продукта
    - [целостность] любой пользователь может пройти от начала до конца, не прибегая к помощи разработчика
    - [обучаемость] приложение понятно настолько, что пришедшие 1000 пользователей не завалят поддержку тупыми/одинаковыми вопросами
    - [нагрузка] приложение выдержит одновременную работу 1000 пользователей (цифра условная)
    - [отслеживаемость] в любой момент вы понимаете где находится пользователь, что не получается, что не работает как задумано, есть возможность связаться с разработчиком и получить адекватный совет по дальнейшим шагам, есть возможность понять почему пользователь вывалился из workflow и возможность связаться с ним.
    Ответ написан
    1 комментарий
  • Можно ли писать на React + JSX без Webpack? В чем минусы?

    @SuperOleg39ru
    Front-end разработчик
    https://codepen.io/anon/pen/EwLLbN

    Минусы - браузеру придется компилировать код на лету, это большая потеря в производительности.

    Писать на JSX позволяет babel, а не webpack, поэтому в примере на codepen добавлен скрипт с babel.
    Ответ написан
    Комментировать
  • Как решать проблему недостаточного менеджмента в небольшой команде веб-разработчиков?

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

    Вообще, менеджмент никогда не является узким местом, в этом участке процесса все происходит достаточно быстро (именно поэтому он один, а вас разработчиков трое). Узкое место - это обычно разработка, тестирование, но никак не подготовка ТЗ или распределение задач. На этапе разработки задач гораздо больше, чем на предыдущих этапах.

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

    Поймите, почему бэклог задач иногда пустой. Сделать это можно при помощи Канбан-доски. Детально распишите все этапы получения результата для вашего клиента, например:
    1. поиск клиента
    2. переговоры
    3. подготовка ТЗ
    4. согласование ТЗ
    5. контракт
    6. план работ
    7. разработка
    8. ...

    Чем больше этапов вы отметите, тем выше вероятность найти реальную причину отсутствия задач на этапе 7.

    Много срочных, но коротких проектов приведут к авралу на месяц, а потом будете простаивать. Нужно распределять нагрузку таким образом, чтобы работа была всегда. Например, найти долгоиграющие проекты, найдите доп. канал задач (upwork, etc). Нужно формировать пайплайн проектов и выстраивать сроки таким образом, чтобы равномерно распределять нагрузку. Подумайте над маркетингом, где брать больше клинетов, чтобы отбросить невыгодные проекты и взяться за те, где вы сможете нормально зарабатывать.
    Ответ написан
    Комментировать
  • Как решать конфликты интересов между клиентами фрилансера?

    GeForester
    @GeForester Автор вопроса
    веб-разработчик
    Спасибо всем за ответы! Было интересно читать вашу дискуссию.

    Я нашел интересные рассуждения на этот счет у Артема Горбунова. Процитирую:

    «Дизайнерская работа априори предполагает циркуляцию идей, шаблонов и приёмов между проектами и клиентами. Если отнять круговорот идей, наша профессия перестанет существовать.

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

    Это накладывает большую ответственность на дизайнера и объясняет клиентские страхи. Возможно, требование НДА означает неприятие клиентом этой реальности, и лучше не работать вместе. Поэтому я честно говорю всё это клиенту, когда заходит разговор о «секретности».

    Мы учимся у клиентов за их счёт. Отблагодарить их мы можем только добросовестной работой и этичным поведением.
    Ответ написан
    Комментировать
  • Где получить опыт для устройства на работу Junior Golang?

    dimonchik2013
    @dimonchik2013
    non progredi est regredi
    есть

    1) пили свой маленький проект
    2) смотри как пишут другие
    Ответ написан
    Комментировать
  • Этапы создания приложения (для не программиста)?

    DmitriyEntelis
    @DmitriyEntelis
    Думаю за деньги
    Евгений, я не хочу Вас огорчить, но как правильно написали выше, идея не стоит ничего

    Если Вы запускаете Ваш проект успешно - через 2, максимум 3 недели начинают появляться его кривые(и не очень кривые) клоны. Почитайте историю призмы из последнего. А там таки есть сложная технология внутри (условный фрилансер Вам это не напишет).

    Что бы выжить и успешно развиться Вам нужно
    а) Иметь не отчуждаемое и не копируемое преимущество. Им может быть технология, им может быть аудитория, им может быть эксклюзивное партнерство с кем то - итд итп. Но без этого - никак.
    b) Иметь четкий план развития хотя бы на пару лет (и не бояться его корректировать)
    Ответ написан
    Комментировать
  • Какие есть обучающие материалы по React на русском?

    @Alex493049469
    Ответ написан
    Комментировать
  • Кто должен составлять документацию ( в компании) на программный продукт?

    eduardtibet
    @eduardtibet
    Technical Writer / Documentation Engineer
    В принципе, коллеги выше уже основную часть сказали. Добавлю от себя:
    1. Концепт системы и ТЗ - Аналитик.
    2. Планы работы и контроль их выполнения - ПМ
    3. Эксплутационная документация (руководства разного типа и вида, FAQ, HOWTO и т.п.) - технический писатель.
    4. API, SDK reference, архитектурные документы - либо технический писатель (если он высокого класса), либо разработчики.
    5. Постановка работ по документированию (типы документов, исполнители, docflow между членами команды и.т.п.) - в больших компаниях технический писатель уровня Lead. В маленьких стартапах - у кого больше опыта.
    6. Тест-планы, тест-кейсы - группы тестирования (либо лид, либо наиболее опытный)

    Для справки предыдущих участником треда: заказчики в 98% случаев НИЧЕГО не делают. Это правда жизни. Т.е. они скажут "хочу это и это", но построить из этих слов грамотную систему - см. п.1
    Ответ написан
    2 комментария
  • Сталкивались ли вы с расчетом дедлайна с учетом доработок?

    На самом деле, доработка - это отдельная задача, которая должно проходить те же этапы, что и предыдущая задача. Поэтому делать такую рекурсивную оценку просто невозможно.
    Оценивать задачи, суть которых неизвестна, просто бессмысленно. Есть только одна возможность назвать при этом адекватный срок - случайно угадать.
    При оценке трудозатрат по подробному ТЗ то и дело возникают ошибки, что уж говорить про сферические доработки в вакууме.
    Если бы мне кто-то предложил такую схему работы, я бы постарался объяснить ее несостоятельность. Если объяснения ни к чему не приведут, я от работы откажусь вне зависимости от соблазнительности задачи или оплаты - слишком велики риски, а виноват в итоге оказывается всегда исполнитель.
    Ответ написан
    1 комментарий
  • Нужно ли быть программистом, чтобы управлять проектами?

    darqsat
    @darqsat
    PM
    Смотря что для вас управление проектами. Чаще всего под "ПМ" видят иллюзию управления. Процесс идет сам по себе, по инцерции, и люди думают, что чем то управляют. Управление такая же тонкая наука как психология. Можно управлять результатом тысячей способов. Уже зависит персонально от человека. Кто то сделает сам, кто то делегирует, кто то наймет, кто то заставит, кто то убедит не делать, кто то отложит и т.п.
    Ответ написан
    Комментировать
  • Создание ИТ бизнеса в современных условиях: возможно ли?

    @RomanPyr
    Ответ простой:
    представьте, что у вы уже начали свой бизнес в IT.
    Вот прям в пятницу вечером всё оформилось и завтра в субботу ваш первый рабочий день "на себя".
    Для большей реалистичности, можете сесть на поезд и уехать на выходные в другой большой город.
    Лучше, если билет для вас купит кто-то другой и передаст непосредственно на вокзале.
    Оставьте все карточки дома и возьмите с собой 0,5-1 тысячи рублей (и это ещё по-доброму).

    Все чувства и переживания, которые вы испытаете по приезду и за время выходных, записывайте.
    В понедельник на работе, вы будете точно знать возможно ли создание бизнеса вами или нет.

    И если всё-таки да, то первое, что вы должны сделать при старте своего бизнеса - это остаться на своей работе, высвобождая время (за счёт личной эффективности или уменьшения зарплаты) на сторонние разработки.
    Ответ написан
    Комментировать