Касаемо первых двух описанных проблем, полностью согласен. Они правда часто встречаются, правда я бы посоветовал для единообразия использовать оформление:
margin: 0rem 0rem;
padding: 0rem 0rem 0rem 0rem;
Имхо так код более читаем, чем с использованием -top, -bottom, -left, -right префиксов. Вместо 2-4 строчек мы всегда имеем одну.
Касаемо последней проблемы, то идея неплохая, но селектор с nth-child(2), имхо лучше не использовать в списках или перечислениях элементов в целом. В примере указан селектор (> :nth-child(2)) и он будет работать спору нет, но что произойдёт, когда количество элементов поменяется? А если нужно будет сделать несколько кнопок с особой иконкой, то нам через запятую перечислять все селекторы? Как по мне в таких случаях лучше использовать первоначальный вариант, но немного изменить его:
Брать человека не знающего SQL, для работы с БД - это уровень фразы "просчитался, но где".) Большинство ORM по умолчанию даже нормальное индексирование не делают, о чём человек, не знающий SQL знать не будет, как и банально не сможет написать специфический функционал.)
ORM по большей части используется для удобства и стандартизации работы с бд, а не ради производительности. Поэтому, как всегда всё сводится к поиску золотой середины под каждый проект в отдельности.
Конечно некоторые фишки js воспринимаю за баги. Тоже замыкание, как по мне больше похоже на баг и со сложным кодом, не представляю, как это дебажить и тем-более покрывать тестами.
Если нужно хранить состояние, лучше класс или объект создам, так будет понятнее, как по мне.
Но опять же замыкание это особенность js и знать о ней минимум стоит.
Почему файтингов мало? Помимо того, что файтинги сейчас это более нисшевый жанр (даже более нисшевый, чем например стратегии), их довольно сложно разрабатывать. В файтингах очень важен баланс и тайминги. Если вы думаете, что это просто реализовать, особенно если проект мультиплеерный, то советую попробовать. С точки зрения геймдева и кода это вполне познавательный и интересный опыт.
Если вкратце, то 2д лучше 3д, из-за особенностей отрисовки анимаций, позиционирования моделей игроков и ещё много чего. Если проект мультиплеерный, то синхронизировать например быстрые удары по таймингам поверьте та ещё задача, особенно с блоками и парированиями. С точки зрения баланса, создать несколько разных персонажей с разными приёмами, но чтобы не было читерских комбинаций и не было полных контр персонажей другим персонажам.
Всё это нс словах звучит просто, но поверьте на деле это далеко не так.
Если честно 4o1- preview версия, по личным ощущениям хуже выдаёт ответы, чем просто 4о. Плюс ещё имеет лимит на запросы, даже в платной версии. Так же хуже решает задачи, т.к. хуже понимает контекст того же кода. Задаёт много лишних вопросов, когда 4о всё понимает с полуслова.
Плюс они в любом случае быстро отсеиваются на реальных задачах. Очень легко распознать человека, который вообще ничего не знает от специалиста, который либо имеет проблемы со скилом, либо просто волнуется. Первый будет делать задачи медленно, но понимать, что от него требуют и как это реализовать. Второй подавно всё знает, просто может совершить ошибки при волнении, но он будет писать код с большим пониманием того, что делает.
Человек, который ничего не знает, пишет код странно, из той же нейронки копирует код не думая, сыпаться на нестандартных, но простых вопросах о своём же коде.
П.С. Касаемо нейросетей, то не знаю как, но я в последнее время часто замечаю, что могу отличить код того же gpt, от кода, написанного человеком. Нейронки имеют свой стиль, что-ли, из-за чего на собесах и в тестовых заданиях легко такой код заметить.
Скорее не HRM системы, а компании часто обращаются к hr агентствам, что хантят специалистов. По идее они и выступают в роли той самой базы, поскольку попав в чс к нескольким подобным агенствам можно себе добровольно закрыть доступ к рынку и проблема в том, что напрямую с компаниями в обход них тоже далеко не всегда связаться не вариант, т.к. они скорее-всего пробьют у тех же агенств информацию. Наверное это и можно назвать чёрной меткой, от которой избавиться довольно сложно.
Дело не в накрутке опыта. Банально любая проблема с работодателем может обернуться в таком случае потерей репутации и имей хоть 30 лет релевантного опыта, никто вас не возьмёт, потому что повесят ярлык проблемного, не продуктивного, не приятного в общении, внешности, характере и т.д. нужное подчеркнуть. Например, если пытаться заграницей искать работу без всех надлежащих документов, то эйчары вешают ярлык от которого не избавиться даже если гражданство страны получить.
Касаемо накрутки опыта, такой бред только на российском рынке встречал. Везде давно смотрят на портфолио, достижения на прошлых работах, плюс реальные рекомендаций (не от друга с левака, а человека с верифицированным аккаунтом и проверкой его слов). Опыт работы, как и разделение по скиллу (на джунов, сеньоров и т.д.), либо вообще не пишутся, либо указываются примерно.
Если честно, грустно, что у одного из самых больших в стране рекрутинговых сервисов, настолько ужасно работают алгоритмы поиска и фильтрации, что кандидатам приходится врать о своём возрасте, желаемой зарплате, ключевых навыках и т.д. ради того, чтобы их резюме просто увидели при отклике... Это плохо, как для эйчаров, так и для кандидатов.
Имхо, конкретно в плане инструментов linkedin будет лучше, хотя в плане ui/ux, hh мне нравится больше.
Чёрная метка? Просто любопытно есть какие-то базы данных, где за плохо пройденный собес могут оставить плохой отзыв? Я тоже против накрутки опыта, но порой на собесах попадаются так же неадекваты, которые в теории могут выдать чёрную метку адекватному программисту? Просто любопытно, как это работает
Согласен полностью и хочу добавить, что бизнесу и пользователям важнее время отображения, а не загрузки данных. Загрузку данных в теории можно исправить на уровне железа и сети, а вот если всё упирается в алгоритмы отображения, то кроме как переписываем кода проблему не решить. Конечно сжатие важно, но его нужно применять с умом и где это действительно нужно, а не ради сохранения 90 килобайт во вред производительности.
Имхо но в первом примере, в первом варианте код лучше выглядит. Во втором варианте есть явные проблемы.
Длинные названия переменных для читаемости тоже плохо. Необязательно каждую переменную в функции называть длинным названием, достаточно написать понятное название самой функции, т.к. всё что внутри неё инкапсулировано и имеет смысл в контексте этой функции.
Второй вариант нарушает принцип функционального программирования. Зачем выносить константы начала и конца недели в глобальную видимость, да ещё и нарушать нотацию js (вроде как) по неймингу, написав их капсом. По факту, второй вариант написан в процедурном стиле. Эти константы можно было перенести в аргументы функции, если их нужно менять или поместить их во внутрь функции.
Касаемо второго примера, то уже многие писали, что есть системные названия хуков. Если они режут глаз, можно их "обернуть" в функции с понятным названием.
Так же касаемо нейминга. useFetch это масло масленное. Есть негласно принятое правило нейминга функций/методов во всех ЯП. Первым в названии идёт глагол, вторым существительное, прилагательное и т.д. Use и fetch это два глагола. Тогда хотя бы надо было назвать функцию useFetching, а лучше назвать её по смыслу того, что делает fetch внутри. Например getUser, если fetch получает данные юзера с бэкенда.
Немного странный аргумент про анимации, мол они замедляют работу программистов, поэтому терминал лучше. Анимации проигрываются за доли секунды, плюс их можно отключить если они мешают. Преимущество терминала перед gui в другом. GUI даёт нам фиксированный функционал, который ещё непонятно, как реализован под капотом. В терминале у нас больше возможностей даже у стандартных команд.
Так же есть много инструментов, которые банально не имеют GUI и доступны только в терминале. Ещё 99% серверов не имеют GUI оболочки и настраиваются только через терминал, например при помощи ssh подключения. Ну и как верно многие писали в комментариях, в терминале проще автоматизировать рутинные задачи при помощи тех же bat, sh и т.д. Думаю поэтому терминал так любят гики.
Да, потому что это не просто строковые литералы, а скорее регионы. Например в UTC +3:00 может быть несколько регионов и проблема в том, что в одном из них может быть перевод на летнее время, а в другом нет. Вообще автор не упомянул о летнем времени, а это очень важный момент.
Касаемо первых двух описанных проблем, полностью согласен. Они правда часто встречаются, правда я бы посоветовал для единообразия использовать оформление:
Имхо так код более читаем, чем с использованием -top, -bottom, -left, -right префиксов. Вместо 2-4 строчек мы всегда имеем одну.
Касаемо последней проблемы, то идея неплохая, но селектор с nth-child(2), имхо лучше не использовать в списках или перечислениях элементов в целом. В примере указан селектор (> :nth-child(2)) и он будет работать спору нет, но что произойдёт, когда количество элементов поменяется? А если нужно будет сделать несколько кнопок с особой иконкой, то нам через запятую перечислять все селекторы? Как по мне в таких случаях лучше использовать первоначальный вариант, но немного изменить его:
Если нам нужно применить специальные стиль при разных вариациях иконок, то этих классов, по идее должно хватить.
Всё это неплохо, но меня только один вопрос волнует. Как можно подсчитать статистически степень вовлечённости работника?
"сотрудники демонстрируют большую вовлеченность (+230%)"
Как это рассчитывается? Почему именно 230%, а не 200 или 250?
"Как бы вы реализовали бесконечный цикл без использования ключевого слова while?"
При помощи go to конечно. 😏
Способов много , но мой любимый способ извратиться, это создать 2 класса с евентами отслеживающими изменения друг друга.
Касаемо кода с минутами, то за такое обильное количество if else if, на собесе точно не похвалят.)
Брать человека не знающего SQL, для работы с БД - это уровень фразы "просчитался, но где".) Большинство ORM по умолчанию даже нормальное индексирование не делают, о чём человек, не знающий SQL знать не будет, как и банально не сможет написать специфический функционал.)
Нет, не в меньшинстве.)
ORM по большей части используется для удобства и стандартизации работы с бд, а не ради производительности. Поэтому, как всегда всё сводится к поиску золотой середины под каждый проект в отдельности.
Хорошая статья.
Конечно некоторые фишки js воспринимаю за баги. Тоже замыкание, как по мне больше похоже на баг и со сложным кодом, не представляю, как это дебажить и тем-более покрывать тестами.
Если нужно хранить состояние, лучше класс или объект создам, так будет понятнее, как по мне.
Но опять же замыкание это особенность js и знать о ней минимум стоит.
Почему файтингов мало? Помимо того, что файтинги сейчас это более нисшевый жанр (даже более нисшевый, чем например стратегии), их довольно сложно разрабатывать. В файтингах очень важен баланс и тайминги. Если вы думаете, что это просто реализовать, особенно если проект мультиплеерный, то советую попробовать. С точки зрения геймдева и кода это вполне познавательный и интересный опыт.
Если вкратце, то 2д лучше 3д, из-за особенностей отрисовки анимаций, позиционирования моделей игроков и ещё много чего. Если проект мультиплеерный, то синхронизировать например быстрые удары по таймингам поверьте та ещё задача, особенно с блоками и парированиями. С точки зрения баланса, создать несколько разных персонажей с разными приёмами, но чтобы не было читерских комбинаций и не было полных контр персонажей другим персонажам.
Всё это нс словах звучит просто, но поверьте на деле это далеко не так.
Если честно 4o1- preview версия, по личным ощущениям хуже выдаёт ответы, чем просто 4о. Плюс ещё имеет лимит на запросы, даже в платной версии. Так же хуже решает задачи, т.к. хуже понимает контекст того же кода. Задаёт много лишних вопросов, когда 4о всё понимает с полуслова.
Плюс они в любом случае быстро отсеиваются на реальных задачах. Очень легко распознать человека, который вообще ничего не знает от специалиста, который либо имеет проблемы со скилом, либо просто волнуется. Первый будет делать задачи медленно, но понимать, что от него требуют и как это реализовать. Второй подавно всё знает, просто может совершить ошибки при волнении, но он будет писать код с большим пониманием того, что делает.
Человек, который ничего не знает, пишет код странно, из той же нейронки копирует код не думая, сыпаться на нестандартных, но простых вопросах о своём же коде.
П.С. Касаемо нейросетей, то не знаю как, но я в последнее время часто замечаю, что могу отличить код того же gpt, от кода, написанного человеком. Нейронки имеют свой стиль, что-ли, из-за чего на собесах и в тестовых заданиях легко такой код заметить.
Скорее не HRM системы, а компании часто обращаются к hr агентствам, что хантят специалистов. По идее они и выступают в роли той самой базы, поскольку попав в чс к нескольким подобным агенствам можно себе добровольно закрыть доступ к рынку и проблема в том, что напрямую с компаниями в обход них тоже далеко не всегда связаться не вариант, т.к. они скорее-всего пробьют у тех же агенств информацию. Наверное это и можно назвать чёрной меткой, от которой избавиться довольно сложно.
Дело не в накрутке опыта. Банально любая проблема с работодателем может обернуться в таком случае потерей репутации и имей хоть 30 лет релевантного опыта, никто вас не возьмёт, потому что повесят ярлык проблемного, не продуктивного, не приятного в общении, внешности, характере и т.д. нужное подчеркнуть. Например, если пытаться заграницей искать работу без всех надлежащих документов, то эйчары вешают ярлык от которого не избавиться даже если гражданство страны получить.
Касаемо накрутки опыта, такой бред только на российском рынке встречал. Везде давно смотрят на портфолио, достижения на прошлых работах, плюс реальные рекомендаций (не от друга с левака, а человека с верифицированным аккаунтом и проверкой его слов). Опыт работы, как и разделение по скиллу (на джунов, сеньоров и т.д.), либо вообще не пишутся, либо указываются примерно.
Если честно, грустно, что у одного из самых больших в стране рекрутинговых сервисов, настолько ужасно работают алгоритмы поиска и фильтрации, что кандидатам приходится врать о своём возрасте, желаемой зарплате, ключевых навыках и т.д. ради того, чтобы их резюме просто увидели при отклике... Это плохо, как для эйчаров, так и для кандидатов.
Имхо, конкретно в плане инструментов linkedin будет лучше, хотя в плане ui/ux, hh мне нравится больше.
Чёрная метка? Просто любопытно есть какие-то базы данных, где за плохо пройденный собес могут оставить плохой отзыв? Я тоже против накрутки опыта, но порой на собесах попадаются так же неадекваты, которые в теории могут выдать чёрную метку адекватному программисту? Просто любопытно, как это работает
Согласен полностью и хочу добавить, что бизнесу и пользователям важнее время отображения, а не загрузки данных. Загрузку данных в теории можно исправить на уровне железа и сети, а вот если всё упирается в алгоритмы отображения, то кроме как переписываем кода проблему не решить. Конечно сжатие важно, но его нужно применять с умом и где это действительно нужно, а не ради сохранения 90 килобайт во вред производительности.
Имхо но в первом примере, в первом варианте код лучше выглядит. Во втором варианте есть явные проблемы.
Длинные названия переменных для читаемости тоже плохо. Необязательно каждую переменную в функции называть длинным названием, достаточно написать понятное название самой функции, т.к. всё что внутри неё инкапсулировано и имеет смысл в контексте этой функции.
Второй вариант нарушает принцип функционального программирования. Зачем выносить константы начала и конца недели в глобальную видимость, да ещё и нарушать нотацию js (вроде как) по неймингу, написав их капсом. По факту, второй вариант написан в процедурном стиле. Эти константы можно было перенести в аргументы функции, если их нужно менять или поместить их во внутрь функции.
Касаемо второго примера, то уже многие писали, что есть системные названия хуков. Если они режут глаз, можно их "обернуть" в функции с понятным названием.
Так же касаемо нейминга. useFetch это масло масленное. Есть негласно принятое правило нейминга функций/методов во всех ЯП. Первым в названии идёт глагол, вторым существительное, прилагательное и т.д. Use и fetch это два глагола. Тогда хотя бы надо было назвать функцию useFetching, а лучше назвать её по смыслу того, что делает fetch внутри. Например getUser, если fetch получает данные юзера с бэкенда.
Немного странный аргумент про анимации, мол они замедляют работу программистов, поэтому терминал лучше. Анимации проигрываются за доли секунды, плюс их можно отключить если они мешают. Преимущество терминала перед gui в другом. GUI даёт нам фиксированный функционал, который ещё непонятно, как реализован под капотом. В терминале у нас больше возможностей даже у стандартных команд.
Так же есть много инструментов, которые банально не имеют GUI и доступны только в терминале. Ещё 99% серверов не имеют GUI оболочки и настраиваются только через терминал, например при помощи ssh подключения. Ну и как верно многие писали в комментариях, в терминале проще автоматизировать рутинные задачи при помощи тех же bat, sh и т.д. Думаю поэтому терминал так любят гики.
Летнее время как будете отслеживать?
Да, потому что это не просто строковые литералы, а скорее регионы. Например в UTC +3:00 может быть несколько регионов и проблема в том, что в одном из них может быть перевод на летнее время, а в другом нет. Вообще автор не упомянул о летнем времени, а это очень важный момент.