Даже рядовые пользователи интернета имеют некое понимание о том, что из себя представляет личное хранилище данных, особенно в дополнении к принципу общего, совместно управляемого хранилища.
Все вышеперечисленное не является устаревшими и уж тем более проблемными элементами игр. Все зависит от реализации, если оно реализовано хорошо и интегрировано в игру то и проблем с ними не возникнет. Исключения разве что микротранзакции.
Если в резюме нет упоминания масштаба проекта (количество пользователей, размер команды, бюджет, сложность архитектуры) и вашей роли в принятии ключевых решений, рекрутер просто не увидит в вас Senior.
Я открою Вам секрет но большинство программистов вне зависимости от грейда крайне редко имеют доступ к таким данным как "бюджет". "количество пользователей" тоже сомнительный показатель, имеющий такое свойство как изменение, да и в некоторых сферах их в принципе сложно измерить, а показатели "размер команды" и "сложность архитектуры" это больше техническая часть и нужна в первую очередь для технического интервью ну или уже с непосредственным начальником.
Масштаб: «Проект с миллионами MAU», «команда из десяти разработчиков», «обработка терабайтов данных».
Ваш вклад: «Влиял на выбор архитектуры», «менторил трех Junior-разработчиков», «инициировал внедрение новой технологии, что привело к значительному эффекту».
И до и после изменения это просто словесная вода. "инициировал внедрение новой технологии, что привело к значительному эффекту" к значительному отрицательному или положительному эффекту, и в чем он заключается? Примерно такие мысли возникнут у среднестатистического человека.
Исследования показывают: рекрутер тратит 6-10 секунд на первое сканирование.
А чего не на миллисекунды перейти? Так еще быстрее будет.
Не тратьте месяцы на то, что ChatGPT делает за 5 минут (например, unit-тесты).
Но не доверяйте слепо — учитесь проверять его решения. (vibe coding = зло)
Не тратьте месяцы на изучение того что делает ChatGPT за 5 минут, но в следующем же пункте Вы говорите что надо его проверять но чтобы его проверить надо потратить месяцы на изучение чего-то чтобы в этом хорошо разбираться. Оба пункта противоречат друг другу.
Надеюсь что проблему когда иногда при открытии терминала (именно табы терминала а не всего приложения) невозможно написать буквы в верхнем регистре вылечат. Сейчас оно лечиться закрытием и открытием заново табы но как говорить осадочек остается.
Запомните одну простую истину: рекрутер тратит на первое сканирование вашего резюме от 15 до 30 секунд
Проблема такого подхода в том что если даже весь этот миллион человек пошлют миллион идеальных резюме, Вашу работу (которая и заключается в чтении резюме) это никак не поменяет, потому что в таком случае Вам придется искать другие надуманные причины почему большая часть резюме отправятся "в мусорку", потому что Ваша задача сократить число резюме а не увеличивать. С какой целью Вы написали статью?
Это — прямой сигнал о вашей небрежности. Если вы не можете потратить 10 минут, чтобы вычитать документ, который должен продать вас за несколько сотен тысяч в месяц, то как вы будете писать чистый и поддерживаемый код?
Боюсь что данный пассаж работает и в обратную сторону и вполне может звучать так "если Вы не можете потратить 10 минут на вдумчивое чтение резюме то значит Вы плохой рекрутер?"
Все. За 10 секунд рекрутер понял, кто вы, что умеете и чего хотите. Можно читать дальше.
Если я составил резюме (даже однотипное) и отправил его Вам на конкретную вакансию то мне казалось что априори понятно кто я (претендент на вакансию) и чего я хочу (получить эту вакансию) а что я умею можно обобщенно почитать в резюме. Чтобы мне рассказать что я делал на текущей работе надо больше двух предложений поэтому я напишу очень широкими мазками что я делал что сводит на нет смысл Вашего утверждения т.е. люди будут писать опять же шаблонные предложения.
Со второй частью не совсем соглашусь - чем специфичней технология, тем больше рисков. Не найти разработчиков, кто бы согласился с этим работать. Какие-то баги, которые всплывают в самые неподходящие моменты, а создатель библиотеки уже давно забил на свое детище. Отсутствие или неполная документация. Все это сильно влияет на стоимость решения и его поддержки.
Этими симптомами страдают все технологии даже те которые сегодня на хайпе завтра могут пасть в забвение, такое происходит постоянно. К тому же как именно пользуются библиотеками и фреймворками это тоже лютая специфика на конкретном проекте. Например я работал на трех проектах с Vue и казалось бы одна библиотека и все должно быть одинаково но нет каждый проект сделан по своему со своими приколами и своими фишками а текущий проект в котором я участвую вообще на Vue3 где все очень сильно поменялось в самом фреймворке.
И всё это прекрасно работает в случае простых приложений, но можете себе представить кошмар с обслуживанием, возникающий при создании крупных программ. И винить нужно не jQuery, а аппетиты современных пользователей, которым повсюду требовалась эта интерактивность. В итоге разработчики были вынуждены продолжать использовать jQuery, несмотря на то, что этот инструмент перестал быть удачным выбором для текущих задач.
Могу сказать как человек который начал участвовать в проектах с очень толстым фронтом даже еще до появления jQuery (когда он вышел он прям таки нехило помог нашему тогдашнему проекту монстру с которым мы работали стать кроссбраузерным и слезть с иглы ie6) что реализовать проекты любой сложности можно на чем угодно, главное это прямые руки и склонность команды к борьбе с техническим долгом. А тем более сейчас когда технологий навалили в фронтэнд так много что можно выбирать и это не выбор только из большой тройки, библиотек/фреймворков/встроенный решений полно.
В офисе мы с коллегами обсуждали код, дискутировали, да просто трещали о жизни, а дома единственным собеседником была бедная Матильда, которая ничего в этом не понимает.
Да вот только обсуждают код намного реже (крайне реже) чем трещат о жизни, и более того и то и другое частенько делают тогда когда ты сидишь рядом и тебе приходиться слушать эти обсуждения хотя по факту надо работу работать.
Проблема вайкодинга это деградация компетенций. По принципу "не надо ничего знать ИИ агент сам все знает и сделает хорошо" мы далеко не уедем. Что будет если возникнет проблема которую ИИ агент не сможет решить?
Хорошо я особо не представляю чем занимается эта компания, на сайте написано много слов из которых смысл (само собой лично для меня) не прослеживается. Если у Вас есть время просветите.
Плюс, у некоторый компаний написано "Цифровые активы"
Хорошо поясните что входит в определение "Цифровые активы" ? Ну ладно со сбером окей а что с Т-банк и Wildberries?
Как так вышло, что еще 10 лет назад можно было один раз встретиться с представителем компании и на следующий день уже выходить в команду, а сегодня найм растягивается на недели и включает много этапов.
Еще 15 лет назад в одной из статей крупные западные компании публично признались, что не умеют нанимать: людей выбирают очень медленно и не всегда эффективно.
И это в идущих друг за другом абзацах. Тут наверно надо определиться с временным периодом.
Есть процесс называемый трансляцией (я его назвал сборкой, сути это не меняет). Это преобразование кода на одном языке в другой (Go в машкод, C# в MSIL, TS в JS), принципиальной разницы в этом нет. Если в MSIL, есть типы, то в машкоде их нет, как и в JS. Разработка в JS, это конечно не тоже самое, что в машкоде, но принцип тот же.
Если на Go, DLL вызывается неправильно происходить SEGFAUL, что более страшно, чем плохо написанные .d.ts. Вы так же можете нарваться на такие же проблемы.
Зачем Вы мне это пишите уже сколько раз? Я Вам уже написал что сравнивать это бессмысленно. По Вашей логике корректное сравнение будет сборка спичек в коробок и сборка камешков на песке в пирамидку это же тоже сборка и сути не меняет, значит ее можно сравнить с сборкой Go в машинные коды и Ts в JS и чего угодно правильно? Я уже написал Вам что в браузере (а я пишу только о нем) иной метод распространения кода. Было бы корректное сравнение если бы Вы писали на Go++ с каким-то там новым крутым синтаксисом который бы транспилировался в Go а потом компилировался в машинные коды на каждом клиенте. Мой аргумент что TypeScript не поддерживается браузером, Ваш аргумент ну есть же трансляция это же ведь сборка а раз это сборка то значит это также как и везде, вот только зачем Вы сравниваете с чем-то другим? Если вспомнить о том что TS не первый кто пытался (до него были CoffeScript и Dart и где они сейчас?) а также то что TS разрабатывается компанией которая очень любить уничтожать свои же технологии в один день.
Один прекрасно настроенный Vite все решает, или Bun для консольных приложений.
Для того чтобы его запустить надо поставить node, затем затащить зависимости через npm. Или просто писать код сразу в блокноте и он сразу заработает после сохранения файла и это работает везде. Вот допустим Вы "собрали" свой TS файлик который содержит 5 строк кода и задеплоили на сайт, пользователь открывает сайт а у него падает в этом файле на 12 строке кода, Ваши действия? Vite решит эту проблему?
Вот эта причина:
Не везде и не для всего это проблема актуальна, до появления TypeScript-а писался код и все было нормально.
А что касается полифилов:
Я у Вас что-то спрашивал про полифилы? Нет не спрашивал
TS в плане поддержки "старья" ничем не отличается от других технологий.
Это потому что этим ребятам пришлось создавать все с нуля силами волонтеров. Если бы был открыт компилятор Delphi то они справились намного быстрее и была бы 100% совместимость с Delphi в компилируемых единицах.
В Go есть процесс сборки, в C# есть процесс сборки
Вот только в случае TS нет никакой "сборки", они просто генерит такой же код с некоторыми изменениями чтобы работало в JS потому что браузер не понимает TS. Вы сравниваете разные вещи. Цель создания TS это просто попытка решения проблемы слабой типизации языка JavaScript вызывающей падения в рантайме чтобы можно было отловить их на компайл тайм. Именно эту проблему решает TS засчёт обязательного требования по указанию всех типов параметров и созданию интерфейсов, все остальное это некоторое количество сахарка. Но JS все еще остается динамическим языком со слабой типизацией и в отличии от Go/C# и прочих языков которые компилируют в бинарный код, код на JS так и остается кодом на JS в котором можно вытворять все что угодно в рантайме. Преимущества типизации ts имеют смысл когда Вы пишите код для backend-а. На фронте я хз что Вы делаете что Вам так сильно нужна типизация.
Проблемы в том, что бы использовать TS из-за того, что его не поддерживает браузер нет.
Проблема заключается в обмазыванием тонной тулинга просто для того чтобы сделать такой же код который просто можно написать и он просто будет сразу работать. Если транспилировать TS с последним стандартом то различий в результирующем файле будет не так и много помимо сахарка самого ts. А давайте еще тонну транспиляторов напишем которые кучу сахарка и приемов добавят? Вот только смысл во всем этом если на выходе все равно будет старый добрый JavaScript и возможности всех эти языков будут ограничены возможностями JavaScript. Как по мне жду когда в WASM-е добавиться доступ к WebAPI и DOM вот тогда фронтовый код вполне можно будет писать на языках не требующих что-то исправлять транспиляторами, неисключено что js может сильно подвинуться каким-нибудь rust-ом или go.
Нет ни единой причины не использовать TypeScript в браузере, да посредством сборки, но сути дела это не меняет. Если не согласны приведите контрпример.
Нет это Вы предъявите мне причины почему я должен использовать TypeScript, потому что это Вы утверждаете что я должен на нем писать. Я не утверждал что надо на чем-то писать и если я пишу на чем-то еще то "являюсь извращенцем".
Внезапно оказывается, что даже если собирать нативный бинарник, он может не запуститься на голой ОС из-за отсутствия библиотек. И надо либо ставить библиотеки, либо раздувать бинарник. То же самое в JS-мире -- хочешь поддержку старых браузеров, раздувай бандл полифилами.
Вероятно потому что TypeScript это не целый новый язык а просто надстройка добавляющая статическую типизацию (ну по крайней мере делающая вид) и еще пару фишек а также продвинутый тайчекер основанный на этой информации.
Почему не использовать публикацию в NativeAot? Тогда зависимость от рантайма не понадобиться.
Все вышеперечисленное не является устаревшими и уж тем более проблемными элементами игр. Все зависит от реализации, если оно реализовано хорошо и интегрировано в игру то и проблем с ними не возникнет. Исключения разве что микротранзакции.
Я открою Вам секрет но большинство программистов вне зависимости от грейда крайне редко имеют доступ к таким данным как "бюджет". "количество пользователей" тоже сомнительный показатель, имеющий такое свойство как изменение, да и в некоторых сферах их в принципе сложно измерить, а показатели "размер команды" и "сложность архитектуры" это больше техническая часть и нужна в первую очередь для технического интервью ну или уже с непосредственным начальником.
И до и после изменения это просто словесная вода. "инициировал внедрение новой технологии, что привело к значительному эффекту" к значительному отрицательному или положительному эффекту, и в чем он заключается? Примерно такие мысли возникнут у среднестатистического человека.
А чего не на миллисекунды перейти? Так еще быстрее будет.
Из Вашей же статьи, оказывается знать надо много, и самое главное понимать то ли тестируют тесты и вообще нужны ли они.
Не тратьте месяцы на изучение того что делает ChatGPT за 5 минут, но в следующем же пункте Вы говорите что надо его проверять но чтобы его проверить надо потратить месяцы на изучение чего-то чтобы в этом хорошо разбираться. Оба пункта противоречат друг другу.
Не знал о таком "хаке", попробую спасибо за наводку
Надеюсь что проблему когда иногда при открытии терминала (именно табы терминала а не всего приложения) невозможно написать буквы в верхнем регистре вылечат. Сейчас оно лечиться закрытием и открытием заново табы но как говорить осадочек остается.
Проблема такого подхода в том что если даже весь этот миллион человек пошлют миллион идеальных резюме, Вашу работу (которая и заключается в чтении резюме) это никак не поменяет, потому что в таком случае Вам придется искать другие надуманные причины почему большая часть резюме отправятся "в мусорку", потому что Ваша задача сократить число резюме а не увеличивать. С какой целью Вы написали статью?
Боюсь что данный пассаж работает и в обратную сторону и вполне может звучать так "если Вы не можете потратить 10 минут на вдумчивое чтение резюме то значит Вы плохой рекрутер?"
Если я составил резюме (даже однотипное) и отправил его Вам на конкретную вакансию то мне казалось что априори понятно кто я (претендент на вакансию) и чего я хочу (получить эту вакансию) а что я умею можно обобщенно почитать в резюме. Чтобы мне рассказать что я делал на текущей работе надо больше двух предложений поэтому я напишу очень широкими мазками что я делал что сводит на нет смысл Вашего утверждения т.е. люди будут писать опять же шаблонные предложения.
Этими симптомами страдают все технологии даже те которые сегодня на хайпе завтра могут пасть в забвение, такое происходит постоянно. К тому же как именно пользуются библиотеками и фреймворками это тоже лютая специфика на конкретном проекте. Например я работал на трех проектах с Vue и казалось бы одна библиотека и все должно быть одинаково но нет каждый проект сделан по своему со своими приколами и своими фишками а текущий проект в котором я участвую вообще на Vue3 где все очень сильно поменялось в самом фреймворке.
Могу сказать как человек который начал участвовать в проектах с очень толстым фронтом даже еще до появления jQuery (когда он вышел он прям таки нехило помог нашему тогдашнему проекту монстру с которым мы работали стать кроссбраузерным и слезть с иглы ie6) что реализовать проекты любой сложности можно на чем угодно, главное это прямые руки и склонность команды к борьбе с техническим долгом. А тем более сейчас когда технологий навалили в фронтэнд так много что можно выбирать и это не выбор только из большой тройки, библиотек/фреймворков/встроенный решений полно.
Да вот только обсуждают код намного реже (крайне реже) чем трещат о жизни, и более того и то и другое частенько делают тогда когда ты сидишь рядом и тебе приходиться слушать эти обсуждения хотя по факту надо работу работать.
Проблема вайкодинга это деградация компетенций. По принципу "не надо ничего знать ИИ агент сам все знает и сделает хорошо" мы далеко не уедем. Что будет если возникнет проблема которую ИИ агент не сможет решить?
Хорошо я особо не представляю чем занимается эта компания, на сайте написано много слов из которых смысл (само собой лично для меня) не прослеживается. Если у Вас есть время просветите.
Хорошо поясните что входит в определение "Цифровые активы" ? Ну ладно со сбером окей а что с Т-банк и Wildberries?
Из предложенного списка только Яндекс и VK являются IT компаниями. Или теперь IT компанией считается любая у которой есть в штате програмисты?
И это в идущих друг за другом абзацах. Тут наверно надо определиться с временным периодом.
Зачем Вы мне это пишите уже сколько раз? Я Вам уже написал что сравнивать это бессмысленно. По Вашей логике корректное сравнение будет сборка спичек в коробок и сборка камешков на песке в пирамидку это же тоже сборка и сути не меняет, значит ее можно сравнить с сборкой Go в машинные коды и Ts в JS и чего угодно правильно? Я уже написал Вам что в браузере (а я пишу только о нем) иной метод распространения кода. Было бы корректное сравнение если бы Вы писали на Go++ с каким-то там новым крутым синтаксисом который бы транспилировался в Go а потом компилировался в машинные коды на каждом клиенте. Мой аргумент что TypeScript не поддерживается браузером, Ваш аргумент ну есть же трансляция это же ведь сборка а раз это сборка то значит это также как и везде, вот только зачем Вы сравниваете с чем-то другим? Если вспомнить о том что TS не первый кто пытался (до него были CoffeScript и Dart и где они сейчас?) а также то что TS разрабатывается компанией которая очень любить уничтожать свои же технологии в один день.
Для того чтобы его запустить надо поставить node, затем затащить зависимости через npm. Или просто писать код сразу в блокноте и он сразу заработает после сохранения файла и это работает везде. Вот допустим Вы "собрали" свой TS файлик который содержит 5 строк кода и задеплоили на сайт, пользователь открывает сайт а у него падает в этом файле на 12 строке кода, Ваши действия? Vite решит эту проблему?
Не везде и не для всего это проблема актуальна, до появления TypeScript-а писался код и все было нормально.
Я у Вас что-то спрашивал про полифилы? Нет не спрашивал
"JS в плане поддержки" вот так надо написать.
Это потому что этим ребятам пришлось создавать все с нуля силами волонтеров. Если бы был открыт компилятор Delphi то они справились намного быстрее и была бы 100% совместимость с Delphi в компилируемых единицах.
Вот только в случае TS нет никакой "сборки", они просто генерит такой же код с некоторыми изменениями чтобы работало в JS потому что браузер не понимает TS. Вы сравниваете разные вещи. Цель создания TS это просто попытка решения проблемы слабой типизации языка JavaScript вызывающей падения в рантайме чтобы можно было отловить их на компайл тайм. Именно эту проблему решает TS засчёт обязательного требования по указанию всех типов параметров и созданию интерфейсов, все остальное это некоторое количество сахарка. Но JS все еще остается динамическим языком со слабой типизацией и в отличии от Go/C# и прочих языков которые компилируют в бинарный код, код на JS так и остается кодом на JS в котором можно вытворять все что угодно в рантайме. Преимущества типизации ts имеют смысл когда Вы пишите код для backend-а. На фронте я хз что Вы делаете что Вам так сильно нужна типизация.
Проблема заключается в обмазыванием тонной тулинга просто для того чтобы сделать такой же код который просто можно написать и он просто будет сразу работать. Если транспилировать TS с последним стандартом то различий в результирующем файле будет не так и много помимо сахарка самого ts. А давайте еще тонну транспиляторов напишем которые кучу сахарка и приемов добавят? Вот только смысл во всем этом если на выходе все равно будет старый добрый JavaScript и возможности всех эти языков будут ограничены возможностями JavaScript. Как по мне жду когда в WASM-е добавиться доступ к WebAPI и DOM вот тогда фронтовый код вполне можно будет писать на языках не требующих что-то исправлять транспиляторами, неисключено что js может сильно подвинуться каким-нибудь rust-ом или go.
Нет это Вы предъявите мне причины почему я должен использовать TypeScript, потому что это Вы утверждаете что я должен на нем писать. Я не утверждал что надо на чем-то писать и если я пишу на чем-то еще то "являюсь извращенцем".
Как это относиться к сабжу про TS?
Вероятно потому что TypeScript это не целый новый язык а просто надстройка добавляющая статическую типизацию (ну по крайней мере делающая вид) и еще пару фишек а также продвинутый тайчекер основанный на этой информации.