вспомните каким болезненным был переход от газового освещения к электрическому
Как вы задрали с подобными аналогиями, которые, если на секундочку задуматься, вообще мимо кассы) то переход от телег с машинам, то от газа к электричеству - эти переходы действительно вывели жизнь людей на новый уровень: с ними молоко доедет свежим из куда более далёких ферм, а людям больше не нужно жечь что-то в доме(в смысле чтобы горело) для освещения вечером, об освещении огромных помещений вообще речи не идёт. А что сопоставимого дала технология, вокруг которой вы и вам подобные так носитесь? Я даже не прошу сопоставимого по показателю цена/качество - все мы знаем, в какие безумные деньги это встаёт человечеству, про экологию тоже уже не рассказал только ленивый. Просто качество, которое всерьёз изменит уровень жизни человечества в лучшую сторону. Написание кривых приложений, которые никому не нужны, сложно назвать таковым)
Не трудно заметить, что все новые отрасли проходят схожий путь – будь то земледелие, машиностроение или ИТ
Ага, только почти везде за автоматизацией в отрасти стоят люди, которые если что - залезут руками внутрь и всё исправят) вы же никуда залезть руками в принципе не можете, нет таких навыков - только абстракции, ваши слова
То есть вот так взять и снизить энергопотребление в тысячу раз? жаль, что ни для чего иного так ещё не сделали - для всех тех вещей, от которых мы на самом деле зависим ежедневно. Но для чатботов конечно же ничего не "исключает возможность в дальнейшем снизить его энергетическую стоимость", потому что вам хочется в это верить)
Да, уязвимость критическая, но сколько таких уязвимостей может скрываться в React
Стоит называть вещи своими именами, новомодные серверные компоненты - это скорее про Next и прочие SSR, но не про сам React, потому что в базовом SPA этих проблем нет и быть не может по определению
Так TS это буквально JS, только с типизацией и прочими удобностями, стандарт в веб-разработке. Тут кстати уже пытались превозносить GO на фоне JS, но что-то не вывезли ответов на простые вопросы)
В любой компании время от времени случается одна и та же сцена. Квартальный план срывается, выручка по ключевому продукту просела, отделы спорят между собой, в отчётах нет единой картины. В какой-то момент все разворачиваются к человеку, который должен сказать: «делаем вот так».
А так случается разве зачастую не из-за предыдущих решений того же руководителя? Я работал в холдинге, где было много самостоятельных продуктов, и на протяжении нескольких лет считалось что наш - сверхприбыльный. Менеджеры получали крутые премии за такие прибыли, штат раздувался, на 2 фронта было 9 бэкендеров, правда на помощь первым потом подтянули ещё 2 с аутсорса. Требовались всё новые и новые фичи, а главное быстро - продукт практически локомотив! Но в один момент выяснилось, что прибыли на самом деле не было, вообще. На деле обнаружился огромный убыток, в несколько миллиардов. Как там всё это время считали показатели и откуда брались деньги на премии\штат - даже не представляю, но что-то мне подсказывает, что грамотный руководитель с критическим мышлением должен был это предотвратить. Не случилось) зато потом да, кулаком по столу, "теперь делаем так!" - когда жопа пришла из-за собственной безалаберности, что ещё остаётся-то
Зарплата решает только при прочих равных. В компанию с офисом в Москве/Питере будет стремиться куда как больше народу, чем в компанию из Новосибирска, даже если з/п будут сопоставимы. Локация решает.
эм...удалёнка? или имеется в виду, что человеку из Владивостока будет важно, чтобы офис у компании был в Москве/Питере?
Только вот это вполне себе факт. Вы называете иллюзией 800 отликов за день на открытую вакансию? Само собой не все они релевантны, и пассажиров там большинство - но отклики есть, они точно не иллюзорны
Вот вы зацепились за эту фразу, аж в двух местах процитировали) сейчас многие "немногие" технически подкованные легко напишут вам почти что угодно. Обещается, что и неподкованные будут писать, так что повторю вопрос, ответа на который вы стараетесь избежать - почему созданное вами приложение\сайт за пару дней не утонет среди тысяч подобных, сделанных за пару дней? В чём вообще будет его ценность и даже смысл установки для другого пользователя, если любая домохозяйка, как выше фантазируют, сделает себе своё? Кто будет их покупать?
В упрощённом виде React-компонент перерисовывается, когда:
обновился state внутри компонента;
пришли новые props;
перерендерился родитель (и по цепочке — дочерние компоненты тоже);
изменилось значение Context у Provider (и обновились подписчики).
Дилетантство. Как компонент узнает, что у него изменились пропсы, если не был вызван его ререндер по трём другим причинам? Положите пропсы в какой-нибудь let/ref, а потом поменяйте их - ничего не случится
действительно ода имени самого себя вперемешку с благодарностями жене. банальные вещи, в духе перехода от одного работодателя к другому, преподносятся как риск, вызов, "ставка на красное". прям накал страстей) на пустом месте
Тема алиасов не раскрыта. Сомневаюсь, что вам достаточно заменить git checkout на git co и на этом боль окончена) во всех местах, где я работал, ветки с фичами обычно назывались как-то в духе "feature/*какой-то внутренний префикс*-*номер задачи*", к примеру feature/VIT-223. А релизные ветки при этом что-то в духе release/*номер релиза*, вот и получается, что вы сэкономили только на введении команды checkout, а всё остальное вам каждый раз нужно вводить, желательно безошибочно. Будто только полдела сделано.
Для себя, как раз после какой-то ошибки в имени ветки, сделал алиасы, которые позволяют создавать ветку только по её номеру, и таскаю теперь из проекта в проект:
git config --global alias.new '!f() { if [[ "$1" =~ ^[0-9]+$ ]]; then git checkout -b feature/VIT-$1; elif [[ "$1" == r/* ]]; then git checkout -b release/${1#r/}; else echo "❌ Неверный формат. Используй: <число> или r/<версия>"; return 1; fi; }; f'
git new - создание новой, фичёвой или релизной ветки:
git new 2048 → feature/VIT-2048
git new r/1.90.0 → release/1.90.0
git config --global alias.go '!f() { if [[ "$1" =~ ^[0-9]+$ ]]; then branch="feature/VIT-$1"; elif [[ "$1" == r/* ]]; then branch="release/${1#r/}"; elif [[ "$1" == master ]]; then branch="master"; else echo "❌ Неверный формат. Используй: <число>, r/<версия> или master"; return 1; fi; if git show-ref --verify --quiet "refs/heads/$branch"; then git checkout "$branch"; elif git show-ref --verify --quiet "refs/remotes/origin/$branch"; then echo "➡️ Ветка $branch найдена на origin — подтягиваем..."; git switch "$branch"; else echo "⚠️ Ветка $branch не найдена ни локально, ни на origin"; return 1; fi; }; f'
git go - переключение на ветку по номеру:
git go 1133 → feature/VIT-1133
git go r/1.80.0 → release/1.80.0
git go master → master
Всё это само собой тонко настраивается. Команды для создания алиасов ввёл одной строкой, потому что терминал требует их в таком виде.
Я фактов здесь обнаружил, только новые ничем не подкреплённые утверждения. Факты - это хотя бы какие-то примеры, если уж цифр не смогли найти.
Найм новичков отсутствовал почти всегда, 5 лет назад я сам пробивался через копеечные стажёрки - а что поделать) другой вопрос, что нынешним новичкам стажёрки за 30к не интересны, им сразу 150к подавай, а то зря два месяца язык учили что ли
Вы всё равно должны помнить, где нужен ?., а где нет
Вам это подскажет TS прямо в IDE. В вашем примере если name является обязательным аргументом там, куда передаётся, без ?. у name ТС начнёт ругаться на то, что константа может быть undefined
Поддержу. Go не знаю, и мне вот вообще не понятно, как объявить к примеру юзера, возраст которого опционален - то есть, по заветам JS, number или undefined. Go в данном случае всё равно установит возраст 0 по умолчанию? Как тогда отличить пользователя, который возраст никогда не указывал, от того, возраст которого действительно(и внезапно) 0?
Как вы задрали с подобными аналогиями, которые, если на секундочку задуматься, вообще мимо кассы) то переход от телег с машинам, то от газа к электричеству - эти переходы действительно вывели жизнь людей на новый уровень: с ними молоко доедет свежим из куда более далёких ферм, а людям больше не нужно жечь что-то в доме(в смысле чтобы горело) для освещения вечером, об освещении огромных помещений вообще речи не идёт. А что сопоставимого дала технология, вокруг которой вы и вам подобные так носитесь? Я даже не прошу сопоставимого по показателю цена/качество - все мы знаем, в какие безумные деньги это встаёт человечеству, про экологию тоже уже не рассказал только ленивый. Просто качество, которое всерьёз изменит уровень жизни человечества в лучшую сторону. Написание кривых приложений, которые никому не нужны, сложно назвать таковым)
Ага, только почти везде за автоматизацией в отрасти стоят люди, которые если что - залезут руками внутрь и всё исправят) вы же никуда залезть руками в принципе не можете, нет таких навыков - только абстракции, ваши слова
То есть вот так взять и снизить энергопотребление в тысячу раз? жаль, что ни для чего иного так ещё не сделали - для всех тех вещей, от которых мы на самом деле зависим ежедневно. Но для чатботов конечно же ничего не "исключает возможность в дальнейшем снизить его энергетическую стоимость", потому что вам хочется в это верить)
Стоит называть вещи своими именами, новомодные серверные компоненты - это скорее про Next и прочие SSR, но не про сам React, потому что в базовом SPA этих проблем нет и быть не может по определению
Так TS это буквально JS, только с типизацией и прочими удобностями, стандарт в веб-разработке. Тут кстати уже пытались превозносить GO на фоне JS, но что-то не вывезли ответов на простые вопросы)
А так случается разве зачастую не из-за предыдущих решений того же руководителя? Я работал в холдинге, где было много самостоятельных продуктов, и на протяжении нескольких лет считалось что наш - сверхприбыльный. Менеджеры получали крутые премии за такие прибыли, штат раздувался, на 2 фронта было 9 бэкендеров, правда на помощь первым потом подтянули ещё 2 с аутсорса. Требовались всё новые и новые фичи, а главное быстро - продукт практически локомотив! Но в один момент выяснилось, что прибыли на самом деле не было, вообще. На деле обнаружился огромный убыток, в несколько миллиардов. Как там всё это время считали показатели и откуда брались деньги на премии\штат - даже не представляю, но что-то мне подсказывает, что грамотный руководитель с критическим мышлением должен был это предотвратить. Не случилось) зато потом да, кулаком по столу, "теперь делаем так!" - когда жопа пришла из-за собственной безалаберности, что ещё остаётся-то
который почему-то на моём опыте почти всегда не мешает компании оставить в штате пассажира, дважды приходил на замену такому, отработавшему пару лет
эм...удалёнка? или имеется в виду, что человеку из Владивостока будет важно, чтобы офис у компании был в Москве/Питере?
Только вот это вполне себе факт. Вы называете иллюзией 800 отликов за день на открытую вакансию? Само собой не все они релевантны, и пассажиров там большинство - но отклики есть, они точно не иллюзорны
Вот вы зацепились за эту фразу, аж в двух местах процитировали) сейчас многие "немногие" технически подкованные легко напишут вам почти что угодно. Обещается, что и неподкованные будут писать, так что повторю вопрос, ответа на который вы стараетесь избежать - почему созданное вами приложение\сайт за пару дней не утонет среди тысяч подобных, сделанных за пару дней? В чём вообще будет его ценность и даже смысл установки для другого пользователя, если любая домохозяйка, как выше фантазируют, сделает себе своё? Кто будет их покупать?
Дилетантство. Как компонент узнает, что у него изменились пропсы, если не был вызван его ререндер по трём другим причинам? Положите пропсы в какой-нибудь let/ref, а потом поменяйте их - ничего не случится
действительно ода имени самого себя вперемешку с благодарностями жене. банальные вещи, в духе перехода от одного работодателя к другому, преподносятся как риск, вызов, "ставка на красное". прям накал страстей) на пустом месте
Тема алиасов не раскрыта. Сомневаюсь, что вам достаточно заменить git checkout на git co и на этом боль окончена) во всех местах, где я работал, ветки с фичами обычно назывались как-то в духе "feature/*какой-то внутренний префикс*-*номер задачи*", к примеру feature/VIT-223. А релизные ветки при этом что-то в духе release/*номер релиза*, вот и получается, что вы сэкономили только на введении команды checkout, а всё остальное вам каждый раз нужно вводить, желательно безошибочно. Будто только полдела сделано.
Для себя, как раз после какой-то ошибки в имени ветки, сделал алиасы, которые позволяют создавать ветку только по её номеру, и таскаю теперь из проекта в проект:
git new - создание новой, фичёвой или релизной ветки:
git new 2048 → feature/VIT-2048
git new r/1.90.0 → release/1.90.0
git go - переключение на ветку по номеру:
git go 1133 → feature/VIT-1133
git go r/1.80.0 → release/1.80.0
git go master → master
Всё это само собой тонко настраивается. Команды для создания алиасов ввёл одной строкой, потому что терминал требует их в таком виде.
Автору, у вас что-то с кавычками случилось в
С удовольствием читаю такие вот погружения в язык/движок, спасибо!)
Как на создание объекта там, где в JS справился бы примитив)
Я фактов здесь обнаружил, только новые ничем не подкреплённые утверждения. Факты - это хотя бы какие-то примеры, если уж цифр не смогли найти.
Найм новичков отсутствовал почти всегда, 5 лет назад я сам пробивался через копеечные стажёрки - а что поделать) другой вопрос, что нынешним новичкам стажёрки за 30к не интересны, им сразу 150к подавай, а то зря два месяца язык учили что ли
И вы конечно готовы подтвердить свой вымысел фактами?)
вы сейчас всерьёз утверждаете, что откликаться на всё подряд, не имея даже смежных навыков - это нормально, так и надо делать?
Вам это подскажет TS прямо в IDE. В вашем примере если
nameявляется обязательным аргументом там, куда передаётся, без?.уnameТС начнёт ругаться на то, что константа может быть undefinedТот фак, что
рассказывает про VR, вас не смутил?
Поддержу. Go не знаю, и мне вот вообще не понятно, как объявить к примеру юзера, возраст которого опционален - то есть, по заветам JS, number или undefined. Go в данном случае всё равно установит возраст 0 по умолчанию? Как тогда отличить пользователя, который возраст никогда не указывал, от того, возраст которого действительно(и внезапно) 0?