• Как снять риски переманивания разработчика на T&M и аутстафф?

    @Arik
    стул, веревка... а если серьезно, то ответы в вашем вопросе. Если все так плохо, то нужно менять что-то, если не все так плохо, значит есть где еще хуже, а значит оттуда самим переманивать? Да и с топовых компаний бывает знатно бегут несмотря на высокие ЗП. Не смотрите на это как на что-то плохое, смотрите свои выгоды с такого кочевания специалистов
    Ответ написан
    5 комментариев
  • Не устанавливается npm install canvas - требует скачать и установить библиотеку вручную?

    Krasnodar_etc
    @Krasnodar_etc
    avito front
    Там же на главной страничке гитхаба приведены команды для каждой ОС. Если у вас windows на хосте, что маловероятно, то да, шаги для установки приведены по вашей ссылке. Но даже для винды есть package managers (Chocolatey, например).
    Ответ написан
    3 комментария
  • Не устанавливается npm install canvas - требует скачать и установить библиотеку вручную?

    Mirun
    @Mirun
    ~ Привет ~
    npm canvas install -s ( Флаг сохраняет скачиваемые файлы и сохраняются обычно в users/user на основном диске по умолчанию и просто извлеките данный модуль )
    Ответ написан
    Комментировать
  • Как оценивать сроки?

    saboteur_kiev
    @saboteur_kiev
    software engineer
    Если вы знакомы с проектом и разобрали что за баг, то оценить время на его устранение не проблема.
    Если вы не знаете что это за баг, то это еще не баг а production issue, и происходит его investigation до того момента, пока вы не придумаете временный workaround, чтобы пользователи могли работать, потом вы найдете root issue, заведете баг и уже тогда оцените время на его исправление.

    В общем для любого senior разработчика эти вопросы должны быть понятны и ясны. Менеджер не программист и не должен им быть, но разработка крупного продукта должна каким-то образом регламентироваться. Иначе зачем платить программисту зарплату, если он не знает год он будет устранять баг или день? Как тот, кто платит вам деньги, сможет понять а хватит ли у него денег, чтобы вы ему продукт вообще написали, если оценить длительность работы нельзя?

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

    Agile в этом плане удобен не только тем, что можно накидать себе задач на 2-3 недели и их решать, а тем, что каждые 2-3 недели можно посмотреть назад, и понять насколько хорошо ты оценил свои естимейты, и нужно ли в следующем спринте увеличивать или наоборот уменьшать время. И так каждый спринт - смотришь и улучшаешь навыки планирования и эффективность работы.
    Ответ написан
    10 комментариев
  • Это функция или объект?

    @askhat
    function Name() {} это определение функции. По соглашению, функции начинающиеся с заглавной буквы, являются конструкторами объектов.
    Ответ написан
    Комментировать
  • Стоит ли хранить frontend 3 внешне похожих проектов в 1 репозитории и как с этим жить?

    Robur
    @Robur
    Знаю больше чем это необходимо
    положите все общее в отдельный пакет, пилите там все и расшарьте между проектами.
    Пакет можно хоть как организовать - от npm и bower до своего велосипеда
    Ответ написан
    Комментировать
  • Какой backend лучше всего использовать с React.js/Redux?

    @askhat
    Нет никакой разницы какой именно (подозреваю фреймворк) вы выберете. Главное чтобы протокол мог использоваться из браузера, а вы хорошо разбирались в выбранной технологии.
    Ответ написан
    3 комментария
  • Зачем в докерфайл добавлять VOLUME /tmp?

    chupasaurus
    @chupasaurus
    Сею рефлекторное, злое, временное
    Команда VOLUME нужна, чтобы изменяемые данные, появляющиеся во время жизни, хранились на хосте отдельно от файловой системы контейнера, могли быть обработаны/переиспользованы после его удаления и администрируемы через Docker API.
    Ответ написан
    Комментировать
  • Почему сервер на Docker иногда даёт 504 ошибку?

    @vitaly_il1
    DevOps Consulting
    Как и с обычным сервером, контейнер имеет ограничения по производительности.
    Так что посмотрите логи контейнера, возможно дело в конфигурации апп. сервере, возможно, в ресурсах - CPU/RAM.
    В первом случае помогут настройки, во втором - можно увеличить ресурсы контейнера или поднять несколько контейнеров с loadbalancer.
    Ответ написан
  • Почему сервер на Docker иногда даёт 504 ошибку?

    tumbler
    @tumbler Куратор тега Python
    бекенд-разработчик на python
    504 обычно означает что кончились воркеры. Что логично при большом числе параллельных запросов
    Ответ написан
    Комментировать
  • Как подключиться к VPS на UBUNTU 18.04 из под Windows 10?

    CityCat4
    @CityCat4
    Внимание! Изменился адрес почты!
    Никаких "рабочих столов" на бубунте на VPS быть не должно. openssh там уже есть и даже наверняка запущен, на винде хорошо работает XShell (бесплатно для домашнего или некоммерческого применения), есть бесплатный putty.
    Ответ написан
    2 комментария
  • Как установить Ssl сертификат на чистую ubuntu 18 минимальными усилиями?

    CityCat4
    @CityCat4 Куратор тега Цифровые сертификаты
    Внимание! Изменился адрес почты!
    cp certfile.crt /etc/ssl/certs
    cp certfile.key /etc/ssl/private
    cd /etc/ssl/certs
    ln -s certfile.crt `openssl x509 -hash -noout -in certfile.crt`.0
    Ответ написан
    8 комментариев
  • Какие языки программирования лучше всего оплачиваются в России, США и Европе?

    @mamontm
    Оплачиваются не языки программирование.

    Оплачивается умение ими пользоваться.

    Есть буквально одно исключение - Cobol.
    Это один из старейших языков программирования, на котором начали писать еще тогда когда ваши родители еще не родились.
    Приходится иметь дело с очень древними программами, причем выполняющими весьма ответственные вещи, где высока цена ошибки (первыми, кто мог позволить себе компьютеры был очень крупный бизнес)

    о наблюдениям сервиса «Мой круг» в России последние пару лет по зарплатам лидируют...

    Вы неверно интерпретируйте данные.

    Просто ряд языков чаще используется в недорогих простых проектах. Что не отменяет их же использование в дорогих проектах. Но искажает понятие "средняя зарплата".

    Плюс недорогих проектов всегда намного больше. Что еще более искажает понятие "средняя зарплата".

    Ну то есть математически-формально всё так как описано в обзоре зарплат.

    Но вас же интересует, поди, сколько лично вы будете зарабатывать, если смените язык?
    А ваш заработок связан вовсе не с языком - а с тем, что вы в этом случае будете и с другим работодателем работать и опыта постепенно набераетесь.

    Причём если Scala и Elixir два года назад по зарплатам опережали прочие языки с сильным отрывом и за последние годы выросли по зарплате несильно, то Go и Objective-C за эти же два года совершили сильный отрыв от остальных языков и догнали Scala и Elixir

    Все упомянутые нельзя назвать распространенными на простых (то бишь на дешевых) проектах.

    P.S.:
    Узнаю типичный страх начинающего новичка (и типичное заблуждения уже начавшего новичка, который уже успел разочароваться в том, что ему не предлагают сходу 100 500 миллионов баков в месяц, как об этом все трубят) -

    "Я выучу не тот язык и карьера будет погублена"
    "Я выучу тот язык и карьера пойдет вверх".

    Язык не важен - достаточно выбрать любой язык из мейнстрима, чтобы просто на нем было можно найти работу (или, если вы в маленьком населенном пункте и будете работать не удаленно - тогда выбор языков вообще мал).

    Важно ваше умение программировать. А это понимание/знание - алгоритмов, парадигм, концепций, паттернов.

    Эти вещи из языка в язык повторяются.
    Трудно выучить только первый.

    Сменить язык программисту с опытом - не сложно.
    Ответ написан
    8 комментариев
  • Какие книги посоветуете для будущего Team Lead'a?

    @asd111
    1. Менеджемент по Scrum - спринты, распределение задач, планирование и т.п.
    2. Конфликтология.
    Ответ написан
    Комментировать
  • От какой ветки нужно ветвить фиче-бранчи для разработки?

    @Vitsliputsli
    Есть разные варианты даже в git-flow. В вашем случае, с учётом того, что вы делаете фичи, а затем выбираете, что пойдет в релиз (не очень понятно как вы формируете спринт при этом), ветка develop вам по-сути не нужна. Ветка develop предназначена для интеграции разных фич и проверки их совместной работы, в вашем случае это откладывается до финального тестирования релиза. Такой путь даёт гибкости, но может увеличить время финального тестирования, оправдан для несложных проектов и/или проектов с действительно слабым зацеплением, но даже в этом случае требуется постоянный контроль со стороны тимлида.
    Ответ написан
    4 комментария
  • От какой ветки нужно ветвить фиче-бранчи для разработки?

    dmitriylanets
    @dmitriylanets
    веб-разработчик
    второй вариант, при первом работа ведется с хотфиксами
    Ответ написан
    Комментировать
  • Фронтенд и бекенд в разных репозиториях или в одном?

    wapster92
    @wapster92
    Если используется angular, уже подразумевается, что он общается с сервером через api, лучше два разных. Если проекты не большие то как сказали выше можно и в одном.
    Ответ написан
    Комментировать
  • От какой ветки нужно ветвить фиче-бранчи для разработки?

    Wolfnsex
    @Wolfnsex
    Если не хочешь быть первым - не вставай в очередь!
    Поделитесь опытом, какой способ вы используете для своей разработки?
    Лично мы используем такой способ:
    1. Есть мастер ветка, туда попадает только полностью оттестированный код (обратите внимание - не в конце какого-то спринта; не после того, как на горе рак свистнет; а после прохождения всех этапов тестирования)
    2. Есть dev-ветка, ею заведует старший разработчик и по мере необходимости "подливает" туда фиче-ветки.
    3. Есть много фич-веток, в которых работают отдельно взятые личности, при этом откуда они будут брать кодовую базу для доработки - их личная трагедия. Если при слиянии возникают конфликты - есть старший разработчик, если ему что-то непонятно - есть авторы кода, которых можно позвать и спросить "какого тут происходит?".

    Лучшая формула работы, из моего личного опыта - это "думать головой", а не слепо следовать какому-то набору правил.
    Ответ написан
    Комментировать
  • Фронтенд и бекенд в разных репозиториях или в одном?

    @mrisid
    Для маленьких проектов можно в 1 папку всё кидать но тогда ты можешь запутаться в BackEnd и FrontEnd,по этому посоветовал бы отсортировать,не знаю как тебе но у меня лично глаз радуется когда не надо путать где BackEnd а где FrontEnd,если ты ещё работаешь один то можно не запариваться,но группой вы будете иногда путать где что лежит и что к чему,если файлов у вас много то лучше конечно отсортируйте, если файлов мало то страшного в этом ничего нет :)
    Ответ написан
    1 комментарий