Ну потому что от балды. Думаю, вы сами понимаете, сколько других слов в словосочетании "дернуть X" вам даст приемлемо применимый к ситуации ассоциативный ряд.
Если мы говорим именно про код, обрабатывающий некий запрос к вебсерверу по некоторому адресу — то это таки эндпоинт. Это однозначно понимают и бэки, и фронты, и русскоязычные разработчики, и англоязычные. Сами по себе handlers (из чего пошла вами любимая русификация) — они в общем-то далеко не везде так называются.
Когда (если) вы переживете правительство РФ — тогда мы сможем полноценно поговорить о вашей версии. А пока это вопрос целеполагания — что вам важнее, быть правым, или быть живым/здоровым? Примерно как с пешеходом, действующим строго в рамках ПДД: он тоже может быть очень даже прав юридически, вот только посмертно.
Я два раза менял симку без изменения данных (один раз по формату, второй раз потому сдохла) именно живя с Альфой, и оба раза мобильный банк мгновенно отваливался, и дальше работал исключительно после визита в отделение, никак иначе.
Создать игру "жизнь"? Вы задачки по проекту точно так же будете ставить?
Справедливости ради, если к такому заданию будет идти ремарка "я знаю, что ТЗ очень расплывчатое, мне хочется посмотреть на то, как вы будете его уточнять" — то я бы к этому отнесся крайне положительно.
Если без такой ремарки — то да, попахивает пренебрежением.
Особенно прикольно, кстати, что дальше по тексту статьи другой из участников жалуется, как ему поставили задание "сделать таймлайн в гуглмапсах". А это как раз тот же подход.
Поддерживаю. Рассказ трагичный, но тем не менее из него отчетливо вырисовываются два момента: герой рассказа пошел в Амазон именно за деньгами. Я отчетливо понимаю мотивацию этого поступка, но я так же и понимаю, что естественное следствие такого решения — необходимость отложить куда-нибудь свою человечность и впахивать.
Герой же выглядит человеком, решившим и денег от души получить, и "человеческого отношения" и вхождения в обстоятельства. Но то и другое вместе — не прокатило.
Я бы сказал, что не "можно", а "нужно".
Вообще по тексту статьи не прослеживается главного — а зачем вообще появился throttle? setState можно фигачить десятками тысяч раз в секунду без каких-либо проблем, это я вам точно говорю. Там тормозить попросту нечему. Что будет тормозить — так это вовсе не setState, а последующий render.
Но да это проблемы архитектурного уровня. Если мы говорим про реальность, а не выдуманный пример — тут надо бы начинать с вопросов типа "вы одним компонентом делаете 2 разные вещи, почему тут не два компонента?"; "задачи вида "получить значение с сервера" должны решаться не компонентами (не презентационным слоем приложения), а стейт-менеджментом, либо же вообще в своем отдельном I/O слое, если у нас проект достаточно масштабен, чтоб его выделить отдельно"; "почему реальность получения значения с сервера замазана гораздо более упрощенной абстракцией, что произойдет, если запрос упадёт, будете вечно показывать Number: undefined?"
Я бы дополнил, что "нормальные бизнес-процессы" — это не то, что можно отлить в граните. Это всё имеет свойство меняться, и довольно быстро. Нормальные бизнес-процессы на протяжении длительного времени бывают только тогда, когда эти процессы непрерывно выстраивают и модифицируют, те самые "люди с софт-скиллами". А иначе их и не будет.
Если вы пришли и можете спокойнейше писать код строго в рамках процессов — это неизбежно означает, что некоторые другие люди в компании тратят очень много сил (а то и нервов) на то, чтоб ваша спокойная жизнь была возможной. Иногда эти усилия — это то, что явно записано в их должностных инструкциях, но чаще всего — нет.
Я, например, некоторое время назад нанимался в Сбер именно через собственный официальный HR сбера (вакансию мне бросили третьи лица, но всё общение шло с собственным HR). Но да, знаю много людей, которые через третьих лиц шли.
Я тоже. Из самого крутого — делал визуальный (и невизуальный, чисто конфигами) конструктор UI, чтоб продукт был гибко настраиваемым либо шарящим в теме (сетевое администрирование) клиентом, либо же собственными конторскими спецами предметной области, без дальнейшего привлечения программистов.
Дальше я по этой теме могу еще минут 10 минимум говорить, там есть что вспомнить, но давайте пример на этом завершим :-)
Далее по списку самого интересного можно еще остановиться на графиках с очень продвинутой автоподстройкой осей (удобные для восприятия периоды времени, правильные множители единиц, кило/мега/итд, подбор количества меток по осям, чтоб не слишком мало и не слишком много, автовыбор между логарифмической и линейной осью, вот это всё); и даже на интеграции ужей с ежами (реакта/ангуляра/вебкомпонент) — но это всё уже несколько менее интересные темы относительно топ-1. В общем, рассказом можно легко занять полсобеседования, при желании.
За 5 секунд на собесе не смогу среди сотен (а то и тысяч) выполненных задач вспомнить крутую и сформулировать что и как я там делал несколько лет назад.
Вспомните заранее. Вопросы подобного вида сейчас, без преувеличения, задают на 8 собеседованиях из 10.
Без подготовки к этому вопросу меня уже на этом этапе отнесут к непрограммистам или плохим программистам.
Скорее к программистам, которые ничего более запоминающегося, чем двиганье кнопочек, не делали. Но в этой секции у меня еще вопросы по плюсам-минусам технологий, и шансов развести на разговор еще предостаточно.
Аналогично — все же открытые, прозрачные, собрались и поставили себе целей на вырост, распределив их по команде как надо.
рассказывать о важных новостях и изменениях в компании или продукте
Я и не знал, что на роль RSS теперь нужно нанимать человека.
поддерживать тиммейтов, если что-то не так
Так они же все как на подбор правильные, что у них может пойти не так? Друг друга поддержат, опять же, зачем для этого человек с отдельной ролью и на отдельную зарплату?
То есть, беря кредит в 10000 руб, я не оцениваю его в золоте или в долларах, а оцениваю в тех же рублях.
Вы его оцениваете в количестве благ, которые вы на эти 10000 рублей возьмете. Скажем, в определенный не очень давний исторический период вас кредит в 10000 рублей бы совершенно не интересовал.
Из статьи прекрасно понятно, как обращаться с тимлидом. Но теперь стало непонятно, а зачем в команде вообще такой тимлид. Если разработчики прекрасны, открыты, последовательны, подготовлены, проактивны, и очень конкретны в общении — то нафига им тимлид? Чтобы что, чтоб приходить зарплату получать?
Нет, насчёт "товара" я в принципе не против, с оговорками. Которые вы собственно и привели. Но там еще и "мерой самих себя", а вот это уже совсем дичь.
Для vscode есть extensions (в основном написанные для Polymer), которые что-то такое делают, только конечно не прямо вот "самостоятельно", а с некоторыми движениями руками (типа там, писать именно через tagged template literal — html`` и тому подобное).
Ну потому что от балды. Думаю, вы сами понимаете, сколько других слов в словосочетании "дернуть X" вам даст приемлемо применимый к ситуации ассоциативный ряд.
Если мы говорим именно про код, обрабатывающий некий запрос к вебсерверу по некоторому адресу — то это таки эндпоинт. Это однозначно понимают и бэки, и фронты, и русскоязычные разработчики, и англоязычные. Сами по себе handlers (из чего пошла вами любимая русификация) — они в общем-то далеко не везде так называются.
От того, что вы замените англицизм взятым довольно таки "от балды" неанглицизмом — кому должно стать лучше, и почему?
Это заявления из серии "курьер может* получать до 100К".
* — работая максимально возможный объем времени в месяц без единого штрафа. Максимально возможный объем времени работодатель не предоставит.
Так я с этим и не спорил, если вы перечитаете мои комментарии.
Когда (если) вы переживете правительство РФ — тогда мы сможем полноценно поговорить о вашей версии. А пока это вопрос целеполагания — что вам важнее, быть правым, или быть живым/здоровым? Примерно как с пешеходом, действующим строго в рамках ПДД: он тоже может быть очень даже прав юридически, вот только посмертно.
Да, если вы отморозите уши — это, разумеется, целиком и полностью вина мамы. Как иначе-то. Уши правда всё равно ваши, вот незадача.
Я два раза менял симку без изменения данных (один раз по формату, второй раз потому сдохла) именно живя с Альфой, и оба раза мобильный банк мгновенно отваливался, и дальше работал исключительно после визита в отделение, никак иначе.
Справедливости ради, если к такому заданию будет идти ремарка "я знаю, что ТЗ очень расплывчатое, мне хочется посмотреть на то, как вы будете его уточнять" — то я бы к этому отнесся крайне положительно.
Если без такой ремарки — то да, попахивает пренебрежением.
Особенно прикольно, кстати, что дальше по тексту статьи другой из участников жалуется, как ему поставили задание "сделать таймлайн в гуглмапсах". А это как раз тот же подход.
Поддерживаю. Рассказ трагичный, но тем не менее из него отчетливо вырисовываются два момента: герой рассказа пошел в Амазон именно за деньгами. Я отчетливо понимаю мотивацию этого поступка, но я так же и понимаю, что естественное следствие такого решения — необходимость отложить куда-нибудь свою человечность и впахивать.
Герой же выглядит человеком, решившим и денег от души получить, и "человеческого отношения" и вхождения в обстоятельства. Но то и другое вместе — не прокатило.
Я бы сказал, что не "можно", а "нужно".
Вообще по тексту статьи не прослеживается главного — а зачем вообще появился throttle? setState можно фигачить десятками тысяч раз в секунду без каких-либо проблем, это я вам точно говорю. Там тормозить попросту нечему. Что будет тормозить — так это вовсе не setState, а последующий render.
Но да это проблемы архитектурного уровня. Если мы говорим про реальность, а не выдуманный пример — тут надо бы начинать с вопросов типа "вы одним компонентом делаете 2 разные вещи, почему тут не два компонента?"; "задачи вида "получить значение с сервера" должны решаться не компонентами (не презентационным слоем приложения), а стейт-менеджментом, либо же вообще в своем отдельном I/O слое, если у нас проект достаточно масштабен, чтоб его выделить отдельно"; "почему реальность получения значения с сервера замазана гораздо более упрощенной абстракцией, что произойдет, если запрос упадёт, будете вечно показывать Number: undefined?"
Я бы дополнил, что "нормальные бизнес-процессы" — это не то, что можно отлить в граните. Это всё имеет свойство меняться, и довольно быстро. Нормальные бизнес-процессы на протяжении длительного времени бывают только тогда, когда эти процессы непрерывно выстраивают и модифицируют, те самые "люди с софт-скиллами". А иначе их и не будет.
Если вы пришли и можете спокойнейше писать код строго в рамках процессов — это неизбежно означает, что некоторые другие люди в компании тратят очень много сил (а то и нервов) на то, чтоб ваша спокойная жизнь была возможной. Иногда эти усилия — это то, что явно записано в их должностных инструкциях, но чаще всего — нет.
Я, например, некоторое время назад нанимался в Сбер именно через собственный официальный HR сбера (вакансию мне бросили третьи лица, но всё общение шло с собственным HR). Но да, знаю много людей, которые через третьих лиц шли.
Гуглдокс? Codesandbox? Фигма? Тысячи их.
"Иначе" обычно думает вовсе не фронтэндер, а владелец сайта.
Я тоже. Из самого крутого — делал визуальный (и невизуальный, чисто конфигами) конструктор UI, чтоб продукт был гибко настраиваемым либо шарящим в теме (сетевое администрирование) клиентом, либо же собственными конторскими спецами предметной области, без дальнейшего привлечения программистов.
Дальше я по этой теме могу еще минут 10 минимум говорить, там есть что вспомнить, но давайте пример на этом завершим :-)
Далее по списку самого интересного можно еще остановиться на графиках с очень продвинутой автоподстройкой осей (удобные для восприятия периоды времени, правильные множители единиц, кило/мега/итд, подбор количества меток по осям, чтоб не слишком мало и не слишком много, автовыбор между логарифмической и линейной осью, вот это всё); и даже на интеграции ужей с ежами (реакта/ангуляра/вебкомпонент) — но это всё уже несколько менее интересные темы относительно топ-1. В общем, рассказом можно легко занять полсобеседования, при желании.
Вспомните заранее. Вопросы подобного вида сейчас, без преувеличения, задают на 8 собеседованиях из 10.
Скорее к программистам, которые ничего более запоминающегося, чем двиганье кнопочек, не делали. Но в этой секции у меня еще вопросы по плюсам-минусам технологий, и шансов развести на разговор еще предостаточно.
Зачем, если у вас и так все ответственные?
Аналогично — все же открытые, прозрачные, собрались и поставили себе целей на вырост, распределив их по команде как надо.
Я и не знал, что на роль RSS теперь нужно нанимать человека.
Так они же все как на подбор правильные, что у них может пойти не так? Друг друга поддержат, опять же, зачем для этого человек с отдельной ролью и на отдельную зарплату?
Срок годности она имеет ровно потому, что просто цифра вас абсолютно не интересует, вне привязки к благам она лишена всякого смысла.
Вы его оцениваете в количестве благ, которые вы на эти 10000 рублей возьмете. Скажем, в определенный не очень давний исторический период вас кредит в 10000 рублей бы совершенно не интересовал.
Из статьи прекрасно понятно, как обращаться с тимлидом. Но теперь стало непонятно, а зачем в команде вообще такой тимлид. Если разработчики прекрасны, открыты, последовательны, подготовлены, проактивны, и очень конкретны в общении — то нафига им тимлид? Чтобы что, чтоб приходить зарплату получать?
Нет, насчёт "товара" я в принципе не против, с оговорками. Которые вы собственно и привели. Но там еще и "мерой самих себя", а вот это уже совсем дичь.
Для vscode есть extensions (в основном написанные для Polymer), которые что-то такое делают, только конечно не прямо вот "самостоятельно", а с некоторыми движениями руками (типа там, писать именно через tagged template literal — html`` и тому подобное).