• Как избежать конфликтов в git?

    Не ты должен решать, разработчик перед тем как сделать пул реквест должен сделать в своей ветке
    git fetch
    git rebase origin/master

    и после этого решить все конфликты а только потом
    git push
    Единственный выход для минимизации конфликтов - бить файл на кусочки.

    Если человек работает в форке, то ему нужно сначала стянуть изменения себе в мастер с основного репозитория
    Ответ написан
  • Почему многие дизайнеры делают ОГРОМНЫМИ элементы дизайна?

    mixail_fet
    @mixail_fet Куратор тега Дизайн
    Дизайнер веб-интерфейсов
    Так как являюсь представителем вида животных, именуемыми дизайнерами, объясню свою точку зрения.

    1. Хороший дизайнер проверит отображение своего макета на разных разрешениях экрана - это значит, что его макет будет отрисован для FullHD, HD, планшетов и телефонов.

    2. Часто, большие картинки делаются в целях маркетинга, в том случае, если в ходе исследования была поставлена задача продавать с помощью фотографий.

    3. Чтобы не отвлекать пользователя разной информацией, в лендингах подача информации делится на экраны, одна тема - один экран, именно поэтому, некоторые дизайнеры любят рисовать один блок равным целому экрану ноутбука.

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

    Несколько удачных примеров, когда продает картинка:

    Пример 1
    5df8cad3865a8244824208.jpeg

    Пример 2
    5df8cada7c4d4399154721.jpeg

    Пример 3
    5df8cade47863702836645.jpeg

    Пример 4
    5df8cae1ec8dc688996511.jpeg

    Пример 5
    5df8cae570801301689307.jpeg

    Пример 6
    5df8cae8e45e9303368259.jpeg

    Пример 7
    5df8caec51ee0986201410.jpeg
    Ответ написан
  • Удаленщики развиваются медленнее?

    mazhekin
    @mazhekin
    Frontend, Backend Web Developer
    По своему опыту могу сказать, что при переходе на удалённую работу(10 лет) из офиса(7 лет) мое развитие и производительность увеличились в разы.
    1) В офисе ты можешь ничего не делать, а просто показывать лицо и с умным видом рассуждать о полиморфизме. На удалёнке тебя никто не видит, а видят только твои результаты- это обязывает шевелиться быстрее и только по делу.
    2) В офисе ты слишком призязан к месту и организации, зачастую тебя берут на какой нибудь вырост, а в последствии могут дать поддерживать старую программку на фортране или на бейсике, или сунут печатать документы и рисовать рисунки и т.п. и ничего не скажешь. На удалёнке тебе легко поменять проект, если закончились твои задачи, ты смотришь на работу не как на что-то вечное и стабильное, а как на проект, на который тебя взяли из-за определенных скиллов, под конкретные задачи и от тебя ждут конкретные результаты.
    3) В офисе тебя отвлекают разговорами, совещаниями, теннисом и т.п., купят тот стул и комп, который купят, а не который ты хочешь, на удаленке у тебя отдельная комната - как минимум, кресло и мощный игровой ноут (легко поднимающий виртуальные машины или докер-контейнеры), которые ты сам себе выбрал.
    4) Да, экономия на времени, дороге, спорте, месте жительства само собой.
    5) В офисе обучение предлагается/навязывается, но так как вроде положение там стабильное то и оно не так и хочется прям учится, на удалёнке ты понимаешь что это твое конкурентное преимущество и без обучения никак, ты ищешь, анализируешь, что в тренде и больше востребовано, и подгоняешь свои скилы под общие требования рынка, а не конкретной организации.
    6) в офисе не особо поднимают тебе зарплаты типа никуда не денешься, а попросить неудобно, на удалёнке ты с каждым новым проектом пересматриваешь свою цену и приобретенный опыт. (ну хотя здесь немного вру, в офисе повышали нормально, после удачных релизов )

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

    И да... в офисе, мне сказали сразу, что тебя наняли решать задачи, а не отвлекать коллег, так что на то, что там кто-то делиться опытом, мне наверно не повезло.
    Ответ написан
  • Удаленщики развиваются медленнее?

    Adamos
    @Adamos
    Развитие специалиста определяется решаемыми им задачами, а не местонахождением опоры под его задницей.
    Ответ написан
  • Как вы планируете свой рабочий день, чтобы не выгорать?

    Robur
    @Robur
    Знаю больше чем это необходимо
    Интенсивной работы в день 5-6 часов максимум. Больше - только на ограниченное время, с обязательной компенсацией отдыхом. В офисе 9-18 работают в целом так же, кулер, поболтать, что-то обсудить 10 раз в день, почитать статьи. По моим личным ощущениям на удаленке работа интенсивнее, даже с учетом меньшего количества часов. Поэтому работаю по часам и на ставке больше чем в офисе на 8 часовом рабочем дне.
    Пробовал помодоро - не зашло.
    Бывает что накапливается и какие-то дни работа вообще не идет - даю себе отдохнуть, могу поработать часа два-три.
    Что-то новое изучаю иногда в формате перерывов - поработал - почитал. Так как график и учет времени гибкий, это не считается рабочим временем, и совесть не мучает. Могу посередине дня отдохнуть пару часов если совсем не идет, или сходить прогуляться или еще что.
    Свои проекты сначала пилил "по вечерам и выходным", особенно когда работал 9-18 потом понял что так не пойдет, на долгий срок это провальный подход, поэтому сейчас больше работаю как часть рабочего времени. Уменьшаю основную работу (при этом естественно уменьшается доход).

    Самое главное - правильно оценить свои силы и исходя из этого решать сколько куда их потратить. Может у вас сил хватит и на работу и на проекты и на хобби и еще перед сном почитать - без проблем, делайте все это. А если их не хватает даже на 8 часовой рабочий день - стоит это признать и не пытаться себя нагрузить сверх меры, получите новый срыв. Или отказаться от чего-то или искать другие способы кроме как "работать больше". Тут главное быть честным с собой и не "добавлять себе очки".

    В целом выгорание не зависит от объема работы - объем работы влияет на усталость, на выгорание влияет нервное напряжение и оно может быть и при 2 часах работы в день а может и не быть при 10.
    Если у вас реально начинается истощение - то определитесь это усталость или выгорание, если усталость - то организовать рабочее время и контролировать нагрузку, может даже в ущерб доходу, свое состояние очень важно.
    Если выгорание - то надо искать причины, если их не устранить - то ничего не поможет.

    Если вы уже один раз проходили через все это - ищите общее, анализируйте и поймите что вы сейчас делаете так же как и тогда и что надо поменять.
    Ответ написан
  • Есть ли альтернатива upwork?

    @zavodp
    На русскоязычных биржах сейчас полный демпинг?


    Как человек, время от времени нанимающий, скажу, что проблема что на наших что на иноязычных биржах ровно одна:

    Полным полно никчёмного шлака на дешевых работах.
    И крайне занятые высококвалифицированных специалисты на дорогих работах.

    Демпинга в высококвалифицированных работах нет, там спецов недостаток.
    Демпингуют только низкоквалифицированные - их слишком много.
    Ответ написан
  • Что сейчас востребовано на фрилансе?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    На фрилансе востребованы люди, способные самостоятельно проанализировать заказы и сделать выводы.
    Ответ написан
  • Собственные проекты. Стоит ли доводить до идеала?

    dollar
    @dollar
    Не совсем понятно, какую цель вы преследуете. Исходя из вашего слова "профитнее" (т.е. по-русски "выгоднее") её можно трактовать по-разному.

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

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

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

    4) Наконец, если вы хотите заниматься буквально саморазвитием, то есть повышать качество кода и снижать количество багов в нем, то нужно заморочиться конкретно на этом. Опять же, игры здесь ни при чем. Нужно наводить порядок в голове, приучать себя к хорошему оформлению кода и т.д. Опыт, конечно, тоже идет в плюс, но тупо опыта не достаточно. А точных рецептов здесь нет. Начать можно даже с гугления наивной фразы "как писать код без ошибок", а дальше как пойдет, это долгий путь. Но сразу скажу, что это имеет мало отношения к коммерческой выгоде. То есть даже если вы участвуете в ААА-проекте, где отсутствие багов критично, никто не пустит ваш код в продакшн сразу после написания. Ошибаются все, даже профи.

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

    @abberati
    frontend-разработчик
    Стейт менеджер нужен для консистентного управления состоянием приложения, внезапно.
    Если вы не пользуетесь менеджером состояния в реакт-приложении, то либо используете контекст (вот хорошее объяснение, почему на проде так делать не нужно), либо пишете заведомо неподдерживаемое приложение. Ну или ваше приложение — это игра в крестики-нолики с двумя полями в стейте корневого компонента.

    Большие приложения нельзя писать без стейт-менеджера — это выльется в огромную неподдерживаемую кучу спагетти.
    Ответ написан
  • Куда податься с такими навыками?

    Jump
    @Jump
    Системный администратор со стажем.
    По определённым семейным обстоятельствам не могу перебраться в крупный город
    Я бы даже если обстоятелства позволяли ни за что бы не перебрался. Если есть возможность жить за пределами крупного города - это же отлично!
    и устроиться в крупную компанию
    На крупных компаниях свет клином не сошелся. Это только если карьеру собрались делать - тогда да.

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

    А работать на фрилансе конкурируя с людьми, готовыми делать интернет-магазин за 5 тыс руб - уже нет никаких сил...
    А в чем проблема то? Почему не можете конкурировать?
    Магазины всякие нужны - и за 5 и за 50 и за 500тыс.
    Хотите делайте за 5, умеете лучше - делайте за 50.
    В общем учитесь делать магазины за 5тыс. это вполне выгодно.
    Ответ написан
  • Насколько сейчас востребованы программисты микроконтроллеров?

    Сейчас бум развития IoT - а он подразумевает микроконтроллеры везде и различного назначения програмное обеспечение в них. Но программист микроконтроллеров не может быть только программистом - он должен разбираться и в железе чтобы умело оперировать компонентами.
    Ответ написан
  • Чем руководствоваться при выборе, вынести ли "подкомпонент" react в компонент или поместить в функцию внутри компонента?

    rockon404
    @rockon404 Куратор тега React
    Frontend Developer
    вопросов о выносе SubmitButton в отдельный компонент не возникает.

    SubmitButton выносить в отдельный компонент не надо. В большинстве случаев хватает использования обычной кнопки вашего приложения.
    <Button onClick={handleSubmit}>Submit</Button>

    Чем руководствоваться при выборе, вынести ли «подкомпонент» react в компонент или поместить в функцию внутри компонента?


    Компонент это сущность, если часть древа можно описать как сущность, то логичней ее вынести в компонент. Особенно если она будет в последствии переиспользована. Например:
    ListItem, Preloader, Layout, Modal, Container, FormControl, etc.

    Если часть древа описывается задачей(например renderRows, renderItem, etc) и ее надо меморизировать, или она используется под условным рендерингом и для отрисовки необходимы дополнительные вычисления, то ее часто логично вынести в отдельный рендер метод, не нагромождая кодовую базу дополнительными компонентами.
    Колбеки паттерна render-props так же имеет смысл выносить в отдельные render-методы.
    Ответ написан
  • Что не так с резюме?

    DevMan
    @DevMan Куратор тега Карьера
    что вы читали/учили никому не интересно. всем интересно сможете ли вы решать их задачи.

    ваше резюме должно пестрить не перечнем знаний, а практическим опытом "решал то и то, при помощи этого и того".
    Ответ написан
  • Каковы зарплаты junior frontend разработчика?

    @Stergy
    Как по мне все довольно индивидуально, у меня опыт 1 год и 3 месяца.
    Начинал практически с нуля.
    Мои зарплаты по месяцам если интересно.
    1й-3й месяц работы 10к рублей в месяц - знания нулевые, в основном учил основы
    после 3 месяцев сменил работу, ибо устали меня учить и получалось так себе, решил уйти + это была удаленка, прибавляй все сопутсвтующие сложности
    3й месяц - 1 год работы устроился в офис стажером, зп $200 - $800 (варировалась т.к. была почасовка и зп менялось в зависиомости от отработанных часов)
    После года - новая работа, работаю с июля(уже 3 месяца) Зп в районе $2000.
    Опять же уровень свой оцениваю - как низкий, серьезный буст по зарплате в моей ситуации происходит только при смене работы. В рамках одной работы больше чем на 1,5$ в час за раз не повышали.
    Вот как-то так, отвечая на ваш вопрос, что сейчас что год назад я джун. Но за год я вырос значительно, но весь рост все равно в рамках джуна. Поэтому нужно учитывать какого джуна ищут и что хотят видеть. Вряд ли абсолютному новичку дадут сразу 80к рублей, думаю для этого все же нужно немного повариться за меньшую зп.
    Ответ написан
  • Как сделать грамотное столкновение объектов?

    hzzzzl
    @hzzzzl
    for (var i = 0; i < this.food.length; i++) {
      const {x: x1, y: y1} = this.position
      const r1 = this.cell_radius
      const {x: x2, y: y2} = this.food[i]
      const r2 = this.food_size
    
      const distance = Math.sqrt( (x1 - x2)*(x1 - x2) + (y1 - y2)*(y1 - y2) )
      const intersects = distance <= r1 + r2
    
      if(intersects) {
        console.log('I EAT', this.food[i])
      }
    }
    Ответ написан
  • Почему свойство current моего ref равно null?

    rockon404
    @rockon404 Куратор тега React
    Frontend Developer
    Во время вызова render, элементы еще не созданы и не добавлены в DOM, соответственно ref равен null. Вы можете получить ref после монтирования:
    class B extends React.Component {
      componentDidMount() {
        console.log(this.props.anchorRef);
      }
    }


    В вашем случае правильней использовать useRef, так как в отличии от вызова createRef, он при перерисовках возвращает один и тот же объект. Вызов createRef, в свою очередь, каждый раз возвращает новый.
    function A {
      const anchorRef = useRef<HTMLDivElement>(null);
      // ...
    }
    Ответ написан
  • Как правильно выучивать материал?

    sergey-gornostaev
    @sergey-gornostaev
    Седой и строгий
    Беру учебник, читаю полностью, попутно экспериментирую с примерами из книги. После прочтения пытаюсь набомбить пет-проект с использованием изученных технологий. Если где-то застреваю, перечитываю соответствующие главы, лезу в официальную документацию, гуглю.

    ещё вот у меня бывает ,что я иногда в некоторых оператарах путаюсь и немного туплю ,пройдет ли это и через сколько пройдет , и как ускорить это понимание?

    Уйдёт с практикой. Через сколько - это зависит от ваших индивидуальных способностей к обучению и интенсивности прикладываемых усилий.
    Ответ написан
  • Эту "нехорошую вещь" под названием классы обязательно проходить?

    Moskus
    @Moskus
    Обязательно - для чего? Если для зачёта - спросите своего преподавателя. Если чтобы научиться программировать - нет, "проходить" не нужно, нужно понять. Впрочем, если это вызывает у вас такую бурную реакцию, то, может, стоит подыскать занятие попроще, а не издеваться над собой? Или вы из тех, кто думает, что повторив упражнения, можно научиться чему угодно?
    Ответ написан
  • Как вы учите новое?

    Beshere
    @Beshere
    Инженер-программист
    С пет-проектами, конечно, хорошо, но может выйти сплошная копипаста со stackoverflow. Поэтому я начинаю с другого.

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

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

    В итоге остаётся куча шпаргалок, кое-какие знания и навык нарабатывается. Тут уже можно и пет-проект лепить.
    Ответ написан