Рефлексия о фронтенде в России за последние 10 лет
Когда я начинала свою карьеру в айти 10 лет назад, фронтенд переживал период бурного роста. Вышел es6 и мы мы массово переходили с библиотечных промисов на нативные и распутывали callback hell.Набирали популярность реактивные фреймворки, мы спорили о сортах реактивности и переписывали старые сайты с jQuery на SPA. Всем срочно понадобились мобильные версии. Всем стала срочно нужна мобильная версия.
Никто толком не понимал, что из этого получится и сколько денег это все в итоге принесет. Но все побежали в эту сторону, боясь отстать и оказаться не у дел. Веб-продукты росли как грибы и никто толком не считал, сколько денег это приносит в моменте — мы инвестировали в будущее. На собеседованиях искали разработчиков, которые умеют глубоко погружаться и строить сложные системы — всем нужно было занять лидерство в этой сфере. К слову, сейчас то же самое мы переживаем в AI.
В пандемию в 2020 популярность веб-приложения пережила еще один бум в связи с переходом всего и всех в онлайн. Я тогда за год увеличила свою зарплату процентов на 40. Не уверена, что моя реальная ценность выросла так же — компании снова активно инвестировали в разработчиков, чтобы не отстать.
А потом начался кризис. И тут резко все начали считать деньги. Оказалось, что многие проекты, в которые долго и упорно инвестировали, не принесли ожидаемой прибыли — и их закрыли. Стало понятно, что код и сложные системы не являются ценностью сами по себе, они ценны, только если закрывают реальную потребность.
Стали говорить, что самое главное — это софт скиллы. Я считаю, что под софт скиллами очень часто понимают бизнесовое видение, которое лично я, например, отношу к хард скиллам. Сейчас самое главное — это не то, насколько сложную систему вы сделали, а то, попали ли вы с ней в бизнес потребность.
Именно поэтому приобрели популярность всякие “конкретные достижения” в резюме. Что толку с того, что вы отрефакторили огромный легаси, если это никому не было нужно? Напишите, насколько быстрее фичи стали катиться. Зачем вы покрыли все тестами, это реально помогло снизить количество багов? Если нет — то ваши тесты бесполезны.
Мало знать технологию, нужно понимать, как именно ее приложить к реальности.
Я думаю, что впереди разработчиков ждет еще большее погружение в доменную область. Код может писать AI, но он не знает, что именно делать. А чтобы в этом разобраться, нужно погрузиться в доменную область. Мы все станем немного продуктовыми менеджерами.
Я часто встречаюсь с позицией, что разработчик не должен думать о бизнесе — его задача сделать то, что принес менеджер. Эта модель устарела. Сегодня бизнес не готов давать шанс продуктам, которые плохо монетизируются. А значит, понимание бизнеса становится частью профессии разработчика.
Когда я начинала свою карьеру в айти 10 лет назад, фронтенд переживал период бурного роста. Вышел es6 и мы мы массово переходили с библиотечных промисов на нативные и распутывали callback hell.Набирали популярность реактивные фреймворки, мы спорили о сортах реактивности и переписывали старые сайты с jQuery на SPA. Всем срочно понадобились мобильные версии. Всем стала срочно нужна мобильная версия.
Никто толком не понимал, что из этого получится и сколько денег это все в итоге принесет. Но все побежали в эту сторону, боясь отстать и оказаться не у дел. Веб-продукты росли как грибы и никто толком не считал, сколько денег это приносит в моменте — мы инвестировали в будущее. На собеседованиях искали разработчиков, которые умеют глубоко погружаться и строить сложные системы — всем нужно было занять лидерство в этой сфере. К слову, сейчас то же самое мы переживаем в AI.
В пандемию в 2020 популярность веб-приложения пережила еще один бум в связи с переходом всего и всех в онлайн. Я тогда за год увеличила свою зарплату процентов на 40. Не уверена, что моя реальная ценность выросла так же — компании снова активно инвестировали в разработчиков, чтобы не отстать.
А потом начался кризис. И тут резко все начали считать деньги. Оказалось, что многие проекты, в которые долго и упорно инвестировали, не принесли ожидаемой прибыли — и их закрыли. Стало понятно, что код и сложные системы не являются ценностью сами по себе, они ценны, только если закрывают реальную потребность.
Стали говорить, что самое главное — это софт скиллы. Я считаю, что под софт скиллами очень часто понимают бизнесовое видение, которое лично я, например, отношу к хард скиллам. Сейчас самое главное — это не то, насколько сложную систему вы сделали, а то, попали ли вы с ней в бизнес потребность.
Именно поэтому приобрели популярность всякие “конкретные достижения” в резюме. Что толку с того, что вы отрефакторили огромный легаси, если это никому не было нужно? Напишите, насколько быстрее фичи стали катиться. Зачем вы покрыли все тестами, это реально помогло снизить количество багов? Если нет — то ваши тесты бесполезны.
Мало знать технологию, нужно понимать, как именно ее приложить к реальности.
Я думаю, что впереди разработчиков ждет еще большее погружение в доменную область. Код может писать AI, но он не знает, что именно делать. А чтобы в этом разобраться, нужно погрузиться в доменную область. Мы все станем немного продуктовыми менеджерами.
Я часто встречаюсь с позицией, что разработчик не должен думать о бизнесе — его задача сделать то, что принес менеджер. Эта модель устарела. Сегодня бизнес не готов давать шанс продуктам, которые плохо монетизируются. А значит, понимание бизнеса становится частью профессии разработчика.
1❤29👍13🔥6🤮5👎4💩3💯1
Говорила про это еще год назад. Сейчас про цифровой след говорят все больше. Когда жизнь каждого из нас оцифрована в виде постов в соцсетях, а фио можно просто погуглить, нанимающие будут использовать этот способ для валидации кандидатов как дешевый и достаточно эффективный. Понятно, что не все кандидаты гуглятся, но со временем таких будет больше и цифровой след будет серьезно увеличивать ваши шансы попасть на работу.
Как говорится, запомните этот твит.
Как говорится, запомните этот твит.
👎7🤮5💩5🔥4❤2👍2😘1
Forwarded from CSS Боль
Цифровой профессиональный след
Яркая новинка HR-сезона 2026 — понятие цифрового профессионального следа. Я начал встречать его упоминания в феврале в HR-каналах и в вакансиях. В чём суть явления?
Эйчары не доверяют опыту, описанному в резюме, или записям в трудовой книжке. Но им надо разбирать отклики от кандидатов, надо на что-то полагаться. Поэтому им нужна хоть какая-то опора.
Цифровой профессиональный след и есть эта опора. По сути, это набор внешних, объективных, достоверных подтверждений (пруфов) либо опыта, либо уровня скилов кандидата. Важно, чтобы кандидат не мог повлиять на этот пруф.
Идеальный пример ЦПС — это доклад на конференции. Описание доклада висит на сайте конференции, и кандидат не может его изменить. По докладу можно понять уровень докладчика, сколько у него лет опыта, где он работал.
Вроде бы идея с цифровым следом здравая. Но есть проблема — хороших источников цифрового следа мало. Что ещё можно исползовать как цифровой след? Накидайте вариантов.
И ещё одна проблема. Теперь каждому разработчику с самого начала карьеры надо вести дневничок и собирать портфолио наград и грамот, как в школе? Вы готовы к этому, дети? Да, капитан!
Яркая новинка HR-сезона 2026 — понятие цифрового профессионального следа. Я начал встречать его упоминания в феврале в HR-каналах и в вакансиях. В чём суть явления?
Эйчары не доверяют опыту, описанному в резюме, или записям в трудовой книжке. Но им надо разбирать отклики от кандидатов, надо на что-то полагаться. Поэтому им нужна хоть какая-то опора.
Цифровой профессиональный след и есть эта опора. По сути, это набор внешних, объективных, достоверных подтверждений (пруфов) либо опыта, либо уровня скилов кандидата. Важно, чтобы кандидат не мог повлиять на этот пруф.
Идеальный пример ЦПС — это доклад на конференции. Описание доклада висит на сайте конференции, и кандидат не может его изменить. По докладу можно понять уровень докладчика, сколько у него лет опыта, где он работал.
Вроде бы идея с цифровым следом здравая. Но есть проблема — хороших источников цифрового следа мало. Что ещё можно исползовать как цифровой след? Накидайте вариантов.
И ещё одна проблема. Теперь каждому разработчику с самого начала карьеры надо вести дневничок и собирать портфолио наград и грамот, как в школе? Вы готовы к этому, дети? Да, капитан!
🤮7👎6❤5💩5👍4🔥4🌚1
Намедни меня упрекнули в том, что на канале слишком много информации о поиске работы и карьере.
Я пришла к выводу, что это звучит справедливо, и подумываю создать отдельный канал про карьеру и поиск работы — в этом останется только про разработку. Но не уверена, что стоит плодить каналы.
Вы как считаете?
Я пришла к выводу, что это звучит справедливо, и подумываю создать отдельный канал про карьеру и поиск работы — в этом останется только про разработку. Но не уверена, что стоит плодить каналы.
Вы как считаете?
❤10💩6🤮5🤡4👍2👎1💯1👻1
🤡13🤮7💩5❤1🍾1
Накрутка опыта и шантаж
На днях телеграмм облетела история анонима, накрутившего опыт при помощи ментора, а потом столкнувшегося с шантажом от этого самого ментора.
Народ в комментариях разделился на две группы: тех, кто надеется, что автора навечно забанят в айти, и тех, кто делает круглые глаза и вопрошает “ачотакова”.
Моя точка зрения проходит между радикальностью первых и поразительной незамутненностью вторых. Мне категорически не нравится накрутка опыта и я считаю, что усилиями блоггеров и менторов, на ней нажившихся, поиск работы для миддлов (а тем более для джунов) стал напоминать борьбу с многоголовой гидрой — ведь теперь им приходится конкурировать не с такими же миддлами, а с сыновьями маминой подруги, у которых в резюме идеально отполированная фантазия. Честные результаты всегда хуже выдуманных сверхдостижений. В итоге честные ребята тоже вынуждены крутить, чтобы не казаться хуже, и весь этот снежный ком лжи набирает обороты, заставляя всех и каждого сомневаться в себе и своем резюме.
Этот театр теней, в котором мы все оказались благодаря массовой накрутке, влияет на каждого из нас. Во фронтенде, по моим ощущениям, крутит каждый второй (среди миддлов — почти все, среди сеньоров существенно меньше, в среднем по больнице каждый второй). В то время как одни начали крутить, наслушавшись сказок про автофильтры и несправедливый найм, другим пришлось крутить, чтобы быть не хуже первых. Теперь уже и не разберешь, кто что первый начал, но большинство миддлов оказались в ситуации, когда кроме них все остальные накрутили — и вынуждены не отставать. Несправедливо наказывать конкретных людей за то, что делают вообще все вокруг.
Если вы оказались в такой же ситуации, как автор, помните — ответственности за накрутку опыта в законе не предусмотрено. Вас не могут за это уволить. Не вы первый, не вы последний. Очень много людей сейчас в такой же ситуации, как вы, и многие из них переживают и боятся быть обнаруженными. Пострадаете вы или нет, во многом зависит от вашего дальнейшего поведения.
Не будьте наивными и не думайте, что ваши коллеги будут в восторге от этой новости. Скорее всего, им не понравится. Сюрприз, но даже сторонники накрутки не любят, когда обманывают их самих. (Вспомните хотя бы вот эту историю, как Клара у Карла украла кораллы, оставаясь, строго говоря, в рамках закона!). Важно понимать, что доверию нанесен ущерб, но увольнять вас — это уже перебор. Я считаю, что в такой ситуации важно извиниться за обман, и объяснить, что вы были вынуждены крутить, так как сейчас этим занимаются все и это де-факто стандарт рынка. Но на все предложения уволиться нужно отвечать категорическим отказом, дополняя его своими фактическими достижениями и закрытыми задачами. Со временем, при условии вашего добросовестного поведения, этот конфликт будет исчерпан.
В комментариях к оригинальному посту проскальзывали советы сослаться на дипфейк, а то и вовсе подделать такие же “доказательства” для коллег, чтобы имитировать массовую рассылку. Не занимайтесь подставами, не закапывайте себя еще глубже. Как минимум, это будет подозрительно, а как максимум, кто-нибудь из сообразительных коллег шустро накидает на вас досудебку за клевету, но будет готов отказаться от претензий, разумеется, не за спасибо. Тогда неприятным разговором вы не отделаетесь.
На днях телеграмм облетела история анонима, накрутившего опыт при помощи ментора, а потом столкнувшегося с шантажом от этого самого ментора.
Народ в комментариях разделился на две группы: тех, кто надеется, что автора навечно забанят в айти, и тех, кто делает круглые глаза и вопрошает “ачотакова”.
Моя точка зрения проходит между радикальностью первых и поразительной незамутненностью вторых. Мне категорически не нравится накрутка опыта и я считаю, что усилиями блоггеров и менторов, на ней нажившихся, поиск работы для миддлов (а тем более для джунов) стал напоминать борьбу с многоголовой гидрой — ведь теперь им приходится конкурировать не с такими же миддлами, а с сыновьями маминой подруги, у которых в резюме идеально отполированная фантазия. Честные результаты всегда хуже выдуманных сверхдостижений. В итоге честные ребята тоже вынуждены крутить, чтобы не казаться хуже, и весь этот снежный ком лжи набирает обороты, заставляя всех и каждого сомневаться в себе и своем резюме.
Этот театр теней, в котором мы все оказались благодаря массовой накрутке, влияет на каждого из нас. Во фронтенде, по моим ощущениям, крутит каждый второй (среди миддлов — почти все, среди сеньоров существенно меньше, в среднем по больнице каждый второй). В то время как одни начали крутить, наслушавшись сказок про автофильтры и несправедливый найм, другим пришлось крутить, чтобы быть не хуже первых. Теперь уже и не разберешь, кто что первый начал, но большинство миддлов оказались в ситуации, когда кроме них все остальные накрутили — и вынуждены не отставать. Несправедливо наказывать конкретных людей за то, что делают вообще все вокруг.
Если вы оказались в такой же ситуации, как автор, помните — ответственности за накрутку опыта в законе не предусмотрено. Вас не могут за это уволить. Не вы первый, не вы последний. Очень много людей сейчас в такой же ситуации, как вы, и многие из них переживают и боятся быть обнаруженными. Пострадаете вы или нет, во многом зависит от вашего дальнейшего поведения.
Не будьте наивными и не думайте, что ваши коллеги будут в восторге от этой новости. Скорее всего, им не понравится. Сюрприз, но даже сторонники накрутки не любят, когда обманывают их самих. (Вспомните хотя бы вот эту историю, как Клара у Карла украла кораллы, оставаясь, строго говоря, в рамках закона!). Важно понимать, что доверию нанесен ущерб, но увольнять вас — это уже перебор. Я считаю, что в такой ситуации важно извиниться за обман, и объяснить, что вы были вынуждены крутить, так как сейчас этим занимаются все и это де-факто стандарт рынка. Но на все предложения уволиться нужно отвечать категорическим отказом, дополняя его своими фактическими достижениями и закрытыми задачами. Со временем, при условии вашего добросовестного поведения, этот конфликт будет исчерпан.
В комментариях к оригинальному посту проскальзывали советы сослаться на дипфейк, а то и вовсе подделать такие же “доказательства” для коллег, чтобы имитировать массовую рассылку. Не занимайтесь подставами, не закапывайте себя еще глубже. Как минимум, это будет подозрительно, а как максимум, кто-нибудь из сообразительных коллег шустро накидает на вас досудебку за клевету, но будет готов отказаться от претензий, разумеется, не за спасибо. Тогда неприятным разговором вы не отделаетесь.
💯28❤17💩11🤡11🤮7🔥4🤔1
Forwarded from CSS Боль
От резюме к доказательному найму
Рынок найма сломан двумя кризисами: экономическим и кризисом доверия. Они наложились друг на друга и бьют даже по сильным специалистам.
Новый дефолт рынка — нулевое доверие к кандидатам. И это надолго.
Резко выросла ценность цифрового профессионального следа — пруфов, которые подтверждают опыт и уровень навыков. Рынок движется к доказательному найму.
У большинства разработчиков таких доказательств нет. А нарабатывать их долго и дорого.
Поэтому появляются форматы, которые дают достоверное подтверждение уровня, сопоставимое по силе с докладом на технической конференции.
Один из таких форматов — чемпионат по вёрстке для мидлов от @htmlacademy. Он изначально строился как доказательный формат и включает:
– сложное задание с высоким потолком скила;
– двухнедельный формат, в котором можно показать свой максимум;
– ручную проверку работ;
– сильных проверяющих — синьоров из бигтеха и крупных продуктовых компаний;
– публикацию результатов в публичном рейтинге качества фронтенд-разработки.
Старт — 30 марта. Если у вас есть коммерческий опыт в разработке, это способ получить публичный пруф своего уровня.
Записаться на чемпионат
Рынок найма сломан двумя кризисами: экономическим и кризисом доверия. Они наложились друг на друга и бьют даже по сильным специалистам.
Новый дефолт рынка — нулевое доверие к кандидатам. И это надолго.
Резко выросла ценность цифрового профессионального следа — пруфов, которые подтверждают опыт и уровень навыков. Рынок движется к доказательному найму.
У большинства разработчиков таких доказательств нет. А нарабатывать их долго и дорого.
Поэтому появляются форматы, которые дают достоверное подтверждение уровня, сопоставимое по силе с докладом на технической конференции.
Один из таких форматов — чемпионат по вёрстке для мидлов от @htmlacademy. Он изначально строился как доказательный формат и включает:
– сложное задание с высоким потолком скила;
– двухнедельный формат, в котором можно показать свой максимум;
– ручную проверку работ;
– сильных проверяющих — синьоров из бигтеха и крупных продуктовых компаний;
– публикацию результатов в публичном рейтинге качества фронтенд-разработки.
Старт — 30 марта. Если у вас есть коммерческий опыт в разработке, это способ получить публичный пруф своего уровня.
Записаться на чемпионат
🤡17💩10🔥5🤮5❤1
Применение теории на практике
Иногда ко мне приходят ребята, которые сталкиваются с проблемами в коде. Буквально: “не знаю, как сделать эту фичу”, “мой код не работает, но я не знаю, почему”. Это обычно называют практикой, но, на мой взгляд, это всё ещё теория — человек не освоил инструмент и не понимает, как получить нужный результат.
Однако бывает и по-другому: инструмент освоен, но используется нецелесообразно. Например, пишутся хрупкие или тривиальные юнит-тесты. Или все подряд функции в компонентах заворачиваются в useCallback. На мой взгляд, это ошибка применения теории на практике.
Чем вообще отличается теория от практики? Я считаю, теория включает в себя освоение принципов работы какого-нибудь инструмента или подхода. Вы изучаете его возможности, логику и принципы. А практика — это приложение этих знаний к реальному бизнес-процессу. Практика обязательно включает в себя выбор инструмента, а для того, чтобы выбрать, надо знать свойства разных подходов. Если у вас есть завод и вы хотите, скажем, понять, делать вам фрезы из стали или из карбида, вам же нужно понимать свойства обоих сплавов? Вот и здесь также: чтобы выбрать инструмент и подход, нужно знать свойства каждого.
〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️
Критерий выбора — целесообразность.
〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️
Это означает, что у вас есть:
1️⃣ Цель (бизнес-задача)
2️⃣ Набор инструментов с известными свойствами
3️⃣ Выбор инструмента, соответствующего цели.
Из этого логически вытекает, что серебряной пули не существует. Одни популярные инструменты не лучше и не хуже сами по себе, в вакууме. Они либо целесообразны, либо нет.
В ближайших постах разберу популярные тезисы вида «X лучше Y» и покажу, в каких условиях выигрывает каждый вариант.
〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️ 〰️
P.S. Внимательные читатели наверняка помнят, что я писала отдельный пост о связи теории и практики, и,вероятно, запутала всех терминологией. Хотела бы уточнить, что в в этих двух постах я использовала термины по-разному: в прошлый раз под “практикой” я подразумевала написание кода, а сегодня — исключительно решение бизнес задач и в дальнейшем планирую придерживаться такой терминологии. Таким образом, если вы пишете туду лист на курсах -- то этот проект корректнее назвать теорией, потому что он не решает реальную бизнес потребность. Наверное, рано или поздно надо будет делать словарь, как в DDD.
Иногда ко мне приходят ребята, которые сталкиваются с проблемами в коде. Буквально: “не знаю, как сделать эту фичу”, “мой код не работает, но я не знаю, почему”. Это обычно называют практикой, но, на мой взгляд, это всё ещё теория — человек не освоил инструмент и не понимает, как получить нужный результат.
Однако бывает и по-другому: инструмент освоен, но используется нецелесообразно. Например, пишутся хрупкие или тривиальные юнит-тесты. Или все подряд функции в компонентах заворачиваются в useCallback. На мой взгляд, это ошибка применения теории на практике.
Чем вообще отличается теория от практики? Я считаю, теория включает в себя освоение принципов работы какого-нибудь инструмента или подхода. Вы изучаете его возможности, логику и принципы. А практика — это приложение этих знаний к реальному бизнес-процессу. Практика обязательно включает в себя выбор инструмента, а для того, чтобы выбрать, надо знать свойства разных подходов. Если у вас есть завод и вы хотите, скажем, понять, делать вам фрезы из стали или из карбида, вам же нужно понимать свойства обоих сплавов? Вот и здесь также: чтобы выбрать инструмент и подход, нужно знать свойства каждого.
Критерий выбора — целесообразность.
Это означает, что у вас есть:
Из этого логически вытекает, что серебряной пули не существует. Одни популярные инструменты не лучше и не хуже сами по себе, в вакууме. Они либо целесообразны, либо нет.
В ближайших постах разберу популярные тезисы вида «X лучше Y» и покажу, в каких условиях выигрывает каждый вариант.
P.S. Внимательные читатели наверняка помнят, что я писала отдельный пост о связи теории и практики, и,вероятно, запутала всех терминологией. Хотела бы уточнить, что в в этих двух постах я использовала термины по-разному: в прошлый раз под “практикой” я подразумевала написание кода, а сегодня — исключительно решение бизнес задач и в дальнейшем планирую придерживаться такой терминологии. Таким образом, если вы пишете туду лист на курсах -- то этот проект корректнее назвать теорией, потому что он не решает реальную бизнес потребность. Наверное, рано или поздно надо будет делать словарь, как в DDD.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍7🔥4🤮4💩3👎2
Женя Кучерявый написал гайд, как программировать без интернета. Эта статья вызывала у меня широкий спектр эмоций, начиная от смеха со слезами и заканчивая ностальгией по университетским годам, когда быстрый интернет в корпусе был скорее исключением, чем правилом (что, впрочем, нас не останавливало). Поскольку сегодня среда, мои чюваки, не могу лишить вас возможности насладиться гайдом!
https://kucheriavyi.ru/articles/coding-without-internet
P.S. Этот пост не предназначен для того, чтобы его восприняли слишком серьезно. Он здесь шутки ради.
https://kucheriavyi.ru/articles/coding-without-internet
P.S. Этот пост не предназначен для того, чтобы его восприняли слишком серьезно. Он здесь шутки ради.
1😁10❤5🔥5🤮5🤡4👎3👍1🌚1
Forwarded from zede code
Ситуация в найме ахтунг. Все и так все понимают.
Но я хочу сделать очередное напоминание. Когда где-то возникает большой спрос, то скаммеры всегда найдутся. Случаи нередкие и происходят уже со знакомыми с определенной частотой
Поэтому напоминание:
НИЧЕГО не ставьте на комп связанное с работой до последнего.
- ни для тестового задания!
- ни для интервью!
- ни для работы в первый день (если работаете неофициально)!
Ни приложения, ни установки "пакетов содержащих апи" НИ ЧЕ ГО.
Если вас вынуждают, то используйте:
- дев окружения: CodeSandbox, Stackblitz и тп
- если все же нужно со своего и хоть какое-то доверие есть, то используйте Dev Container или как самый минимум просто докер
- для выхода на новой работе тоже лучше соблюсти меры предосторожности, особенно если никаких реальных документов вы не заключали. Докер, в идеале отдельная система и отдельный пользователь, чтобы даже в случае проблемы вы не потеряли доступ к устройству и данным.
Также рассказали о новом виде скама с логином в iCloud. Со своего ПК не лезьте и не логиньтесь никуда. Если дают какой-то сервис, то лучше зайти с инкогнито + сгенерировать рандомный пароль (понимаю, что это базовая сейчас рекомендация по безопасности, но пароли многие все еще пишут руками по паттерну).
Но я хочу сделать очередное напоминание. Когда где-то возникает большой спрос, то скаммеры всегда найдутся. Случаи нередкие и происходят уже со знакомыми с определенной частотой
Поэтому напоминание:
НИЧЕГО не ставьте на комп связанное с работой до последнего.
- ни для тестового задания!
- ни для интервью!
- ни для работы в первый день (если работаете неофициально)!
Ни приложения, ни установки "пакетов содержащих апи" НИ ЧЕ ГО.
Если вас вынуждают, то используйте:
- дев окружения: CodeSandbox, Stackblitz и тп
- если все же нужно со своего и хоть какое-то доверие есть, то используйте Dev Container или как самый минимум просто докер
- для выхода на новой работе тоже лучше соблюсти меры предосторожности, особенно если никаких реальных документов вы не заключали. Докер, в идеале отдельная система и отдельный пользователь, чтобы даже в случае проблемы вы не потеряли доступ к устройству и данным.
Также рассказали о новом виде скама с логином в iCloud. Со своего ПК не лезьте и не логиньтесь никуда. Если дают какой-то сервис, то лучше зайти с инкогнито + сгенерировать рандомный пароль (понимаю, что это базовая сейчас рекомендация по безопасности, но пароли многие все еще пишут руками по паттерну).
Telegram
Стародубцев x IT-ХОЗЯЕВА
Очень важная инфа!
У нас в хозяевах @erikcodev рассказал неприятную историю, на которую они наткнулись с другом, ситуация максимально мерзкая, поэтому репощу чтобы вы не встряли.
Как работает скам: пишет типо hr и зовет на собес
в процессе говорит установить…
У нас в хозяевах @erikcodev рассказал неприятную историю, на которую они наткнулись с другом, ситуация максимально мерзкая, поэтому репощу чтобы вы не встряли.
Как работает скам: пишет типо hr и зовет на собес
в процессе говорит установить…
👍18❤8🔥3👎2🤮2💩2🤡1
Начала писать для вас стопку технических постов и пока все лежит в драфтах. Чтобы вы сильно не скучали, приношу вам плейлист стримов где мы с ребятами из @moscowqa обсуждаем #typescript. Я рассказываю про базовую и продвинутую типизацию, немного потрогали загадочный тип never, а также ковариантность и контрвариантность. Все вопросы можете написать прямо сюда, я постараюсь как можно детальнее на все ответить.
❤15🔥6👍4💩2👎1🤮1
А вы тоже иногда путаетесь в куче логов в консоли?
Чтобы облегчить себе жизнь, логи можно раскрашивать. Например, вот так:
Чтобы облегчить себе жизнь, логи можно раскрашивать. Например, вот так:
console.log('%cSESSION_START', 'background-color: red; color: white; padding: 10px 30px');
console.log('%c[User] Get data...', 'color: yellow');
console.log('%c[Products] Я точно не пропущу этот лог', 'font-size: 25px;');
console.log('%cSESSION_END', 'background-color: red; color: black; padding: 10px 30px');
❤20👍11🔥4🤮4🤡3💩2👎1
Императивное vs декларативное программирование
Это — две разные парадигмы программирования. Разберемся, чем они отличаются и когда удобно использовать первую, а когда вторую.
😊 Императивное программирование — это пошаговое описание алгоритма, который должен выполнить компьютер:
В этом нехитром фрагменте кода описан императивный алгоритм получения и вывода в консоль квадрата числа:
1️⃣ Возьми пользовательский ввод
2️⃣ Приведи к числу
3️⃣ Если число валидное, вычисли квадрат и выведи в лог.
😊 Декларативное программирование — это описание желаемого результата. Язык/фреймворк/движок должен сам определить, как его достичь. Например:
В этом фрагменте кода на React мы говорим фреймворку: я хочу получить форму с лейблом, инпутом и кнопкой и еще лог после отрисовки. Мы не указываем фреймворку, как и в какой последовательности он будет создавать html элементы, и даже не можем на это влиять. Мы описываем только то, что хотим получить на выходе.
⚠️ Важно понимать, что под капотом любое декларативное обязательно превращается в императивные инструкции. React код, например, превращается в императивный вызов
🔖 Императивное программирование удобно применять, когда у вас есть конкретный алгоритм или формула получения необходимого результата из входных параметров. Например, вы хотите рассчитать финальную цену продукта исходя из исходной цены и размера скидки. Здесь важно явно управлять логикой вычислений.
🔖 А вот декларативное программирование удобно, когда вы хотите описать что должно быть получено и переложить реализацию на другую систему — библиотеку, фреймворк, модуль кода. При этом следует участь, что разные реализации могут по-разному воспринять вашу декларацию по-разному в зависимости, например, от своей версии =)
Например, вы пишете декларативную разметку HTML (не является языком программирования). Императивный процесс отрисовки страницы переложен на другую программу — браузер. Поскольку HTML сам по себе не содержит инструкций, как рисовать страницу, HTML верстальщику приходится мириться с тем, что каждый браузер отображает страницу немного по-разному :)
🤩 🤩 🤩 🤩 🤩
Подведем итоги.
📌 Императивное программирование удобно, когда вы хотите получить жесткий контроль над процессом выполнения программы.
📌 Декларативное программирование удобно, когда вы хотите снизить сложность участка программы за счет передачи управления в другой модуль/библиотеку/фреймворк/программу.
Это — две разные парадигмы программирования. Разберемся, чем они отличаются и когда удобно использовать первую, а когда вторую.
const input = process.argv[2];
const x = Number(input);
if (!isNaN(x)) {
const y = x * x;
console.log(y);
}
В этом нехитром фрагменте кода описан императивный алгоритм получения и вывода в консоль квадрата числа:
const Panel = () => {
useEffect(() => console.log("Panel rendered"), []);
return (
<form action="/login.php" method="POST">
<label htmlFor="user">Username:</label>
<input type="text" id="user" name="username"/>
<button type="submit">Login</button>
</form>
)
}В этом фрагменте кода на React мы говорим фреймворку: я хочу получить форму с лейблом, инпутом и кнопкой и еще лог после отрисовки. Мы не указываем фреймворку, как и в какой последовательности он будет создавать html элементы, и даже не можем на это влиять. Мы описываем только то, что хотим получить на выходе.
React.createElement(…). Низкоуровнево компьютер вообще не умеет работать с декларативностью, под капотом всегда императивный процесс. Данные и операции сохраняются в виде последовательности битов в памяти, затем компьютер вычисляет (compute) результат операции и записывает данные в соответствующий регистр. Чтобы запустить вычислительный процесс, необходим набор конкретных инструкций. Именно поэтому декларативный код в конце концов превращается в императивный.Например, вы пишете декларативную разметку HTML (не является языком программирования). Императивный процесс отрисовки страницы переложен на другую программу — браузер. Поскольку HTML сам по себе не содержит инструкций, как рисовать страницу, HTML верстальщику приходится мириться с тем, что каждый браузер отображает страницу немного по-разному :)
Подведем итоги.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤8👍6🤮5🔥3💩3👎2
Сегодня на консультации обсуждали резюме.
— Ну, вообще, в этом проекте у меня были вебсокеты, и еще я делал вот такую классную задачу.
— Но почему этого нет в резюме?
— Посмотрел резюме ребят, которые крутят опыт, многие пишут в резюме такого рода задачи и вебсокеты. Поэтому убрал, чтобы не думали, что я тоже накрутил.
Выводы из этой истории делайте сами.
— Ну, вообще, в этом проекте у меня были вебсокеты, и еще я делал вот такую классную задачу.
— Но почему этого нет в резюме?
— Посмотрел резюме ребят, которые крутят опыт, многие пишут в резюме такого рода задачи и вебсокеты. Поэтому убрал, чтобы не думали, что я тоже накрутил.
Выводы из этой истории делайте сами.
😢21🤡14💩5😁3🤮2👎1
Тип-пересечение (Intersection Types)
Тип-пересечение, как следует из названия, соответствует пересечению множеств, которые его образуют. Декларируется при помощи оператора &.
Это видно на картинке: у нас есть два множества, которые пересекаются, и их пересечение образует подмножество. Если два множества не пересекаются, мы все равно можем получить тип-пересечение, но оно будет пустым (never).
Важно понимать, что использование типа-пересечения в коде целесообразно тогда, когда составляющие его типы используются по отдельности. Например:
Типы в коде выше имеют смысл, когда в нашем проекте могут быть заведены товары без цены (например, только поступили на склад и цена еще не определена). Если же в нашей системе товары всегда содержат цены, то в этом случае подобная конструкция типов нам не нужна, целесообразнее использовать вот такой тип:
#typescript
Тип-пересечение, как следует из названия, соответствует пересечению множеств, которые его образуют. Декларируется при помощи оператора &.
type C = A & B
Это видно на картинке: у нас есть два множества, которые пересекаются, и их пересечение образует подмножество. Если два множества не пересекаются, мы все равно можем получить тип-пересечение, но оно будет пустым (never).
type X = string & number // never
Важно понимать, что использование типа-пересечения в коде целесообразно тогда, когда составляющие его типы используются по отдельности. Например:
type Product = { id: number; name: string; }
type Priced = { price: number; }
type PricedProduct = Product & PricedТипы в коде выше имеют смысл, когда в нашем проекте могут быть заведены товары без цены (например, только поступили на склад и цена еще не определена). Если же в нашей системе товары всегда содержат цены, то в этом случае подобная конструкция типов нам не нужна, целесообразнее использовать вот такой тип:
type Product = { id: number; name: string; price: number; }#typescript
👍18🔥8👏4🤮3😭2❤1👎1💩1
Один принцип, который делает разработчика middle+
Заголовок кликбейтный, но я собираюсь его оправдать.
В разработке самое главное понимание касается не того, как написать код, а того, как он должен работать. То есть — нужно понять, как должна работать система в целом и на корнер кейсах, и как она будет развиваться дальше. Чтобы разобраться в сложных кейсах, разработчики обычно смотрят, как сделано в других местах или ориентируются на лучшие практики, но самый правильный путь — понять, какова бизнес цель ваших действий, тогда сразу станет понятно, как следует сделать.
Приведу пример.
Недавно мой менти делал
На вопрос, зачем здесь string, он ответил, что где-то читал, что так лучше.
Давайте подумаем. Мы делаем компонент, который будут использовать другие разработчики нашей системы. В таком случае мы можем потребовать, чтобы строка конвертировалась в число до передачи в компонент. Таким образом мы делаем нашу границу более строгой. Что нам это дает?
1. В Input меньше кода => легче поддержка
2. Меньше потенциальных багов и возможностей ошибиться
3. Унификация кода
Получится, что мы должны затипизировать так:
Если развить эту мысль, то мы можем прийти к выводу, что ограничение длины должно быть обязательным. Например, для расчета ширины. И тогда получится
Следует ли из этого, что нам всегда следует типизировать пропс именно так? Нет. Можно легко найти сценарии, где решение моего менти будет более подходящим. Например, если вы делаете библиотеку для JavaScript-разработчиков. JS не подскажет корректный тип, и им слишком легко ошибиться — с нашей стороны логично будет их подстраховать.
📌 Таким образом, когда вы принимаете решения, ориентируйтесь на целесообразность и бизнес-потребность. Не бывает никакого “хорошего” и “плохого” кода в вакууме, бывает хорошее решение конкретной задачи и плохое.
Заголовок кликбейтный, но я собираюсь его оправдать.
В разработке самое главное понимание касается не того, как написать код, а того, как он должен работать. То есть — нужно понять, как должна работать система в целом и на корнер кейсах, и как она будет развиваться дальше. Чтобы разобраться в сложных кейсах, разработчики обычно смотрят, как сделано в других местах или ориентируются на лучшие практики, но самый правильный путь — понять, какова бизнес цель ваших действий, тогда сразу станет понятно, как следует сделать.
Приведу пример.
Недавно мой менти делал
Input с ограничением длины ввода и задал максимальную длину ввода пропсом max?: number | stringНа вопрос, зачем здесь string, он ответил, что где-то читал, что так лучше.
Давайте подумаем. Мы делаем компонент, который будут использовать другие разработчики нашей системы. В таком случае мы можем потребовать, чтобы строка конвертировалась в число до передачи в компонент. Таким образом мы делаем нашу границу более строгой. Что нам это дает?
1. В Input меньше кода => легче поддержка
2. Меньше потенциальных багов и возможностей ошибиться
3. Унификация кода
Получится, что мы должны затипизировать так:
max?: number. Если развить эту мысль, то мы можем прийти к выводу, что ограничение длины должно быть обязательным. Например, для расчета ширины. И тогда получится
max: number.Следует ли из этого, что нам всегда следует типизировать пропс именно так? Нет. Можно легко найти сценарии, где решение моего менти будет более подходящим. Например, если вы делаете библиотеку для JavaScript-разработчиков. JS не подскажет корректный тип, и им слишком легко ошибиться — с нашей стороны логично будет их подстраховать.
Please open Telegram to view this post
VIEW IN TELEGRAM
1❤15👍12🔥5👎4🥱4🤮3💩2🤔1
Как я на go в продакшн писала
История была год назад. Нашей команде достался проект с жестким дедлайном. Я уже заканчивала фронтенд, а бекендеры все сдвигали свои сроки и, в конце концов, признались, что не успевают — слишком много задач помимо этого проекта. Тогда я сказала, что я все сделаю сама, только дайте доступ. Лид удивился и возразил мне тем, что в моем резюме написано “frontend-разработчик”. Как вы, наверное, помните, мне в целом не очень импонируют все эти надуманные ограничения вроде “фронтендер не может закрывать таски на бекенде”, тем более я не на лиспе писать собралась, а на еще одном c-like языке. Доступ мне дали. Бекенд оказался на go.
В выходные я потыкала курс по базовому синтаксису go на хекслете и почитала книгу, которую мне посоветовала подруга. Работа над проектом началась непросто: я никак не могла скачать корпоративные модули, несмотря на (вроде бы) правильную настройку конфигов и переменных окружения. Пришлось мучать лида (кажется, он был не очень доволен). Мы провозились пару часов, и в конце концов оно как-то заработало (я точно не поняла, что именно помогло с этой проблемой).
После этого меня ждал новый сюрприз: абсолютно пустой readme и огромный makefile с богатым разнообразием команд. Я решила не гадать на кофейной гуще и спросить у лида, как стартануть проект. А никак, — ответил лид, — он локально не запускается, в CI можно стенд собрать. На этом моменте я на все плюнула и пошла в спортзал тягать железки.
День два. Я решила, что даже если я не могу проверить свой код, написать-то я его все равно могу, логично? Начала читать таску и обнаружила, что аналитик любезно все описал, включая таблицы БД, которые нужно добавить/изменить, и какие поля добавить в эндпойнты. Осталось всего лишь перевести это все в код, что, как вы понимаете, изян задача.
Еще несколько дней я убила на миграции и тесты. Стало понятно, почему ребята не парились из-за невозможности локального запуска — тесты и CI/CD проверки хорошо покрывали кодовую базу, и у меня несколько дней реально ушло на то, чтобы добиться прохождения тестов и пайплайна. Попутно я разобралась, как это правильно делать.
По итогу выяснилось, что я использовала неправильные строковые константы для сообщений об ошибках и накосячила в одном месте из-за плохого знания домена (надо было фильтровать сущности по определенному полю, кто ж знал). Но в целом нормально.
Ну а потом я перешла в другую команду и моя славная карьера go-разработчика закончилась. В новой команде я уже больше полугода пишу на Svelte. Позже расскажу, с какими сложностями я столкнулась после того, как перешла с React на Svelte (спойлер: ни с какими, две недели немножко неудобно, а потом привыкаешь).
История была год назад. Нашей команде достался проект с жестким дедлайном. Я уже заканчивала фронтенд, а бекендеры все сдвигали свои сроки и, в конце концов, признались, что не успевают — слишком много задач помимо этого проекта. Тогда я сказала, что я все сделаю сама, только дайте доступ. Лид удивился и возразил мне тем, что в моем резюме написано “frontend-разработчик”. Как вы, наверное, помните, мне в целом не очень импонируют все эти надуманные ограничения вроде “фронтендер не может закрывать таски на бекенде”, тем более я не на лиспе писать собралась, а на еще одном c-like языке. Доступ мне дали. Бекенд оказался на go.
В выходные я потыкала курс по базовому синтаксису go на хекслете и почитала книгу, которую мне посоветовала подруга. Работа над проектом началась непросто: я никак не могла скачать корпоративные модули, несмотря на (вроде бы) правильную настройку конфигов и переменных окружения. Пришлось мучать лида (кажется, он был не очень доволен). Мы провозились пару часов, и в конце концов оно как-то заработало (я точно не поняла, что именно помогло с этой проблемой).
После этого меня ждал новый сюрприз: абсолютно пустой readme и огромный makefile с богатым разнообразием команд. Я решила не гадать на кофейной гуще и спросить у лида, как стартануть проект. А никак, — ответил лид, — он локально не запускается, в CI можно стенд собрать. На этом моменте я на все плюнула и пошла в спортзал тягать железки.
День два. Я решила, что даже если я не могу проверить свой код, написать-то я его все равно могу, логично? Начала читать таску и обнаружила, что аналитик любезно все описал, включая таблицы БД, которые нужно добавить/изменить, и какие поля добавить в эндпойнты. Осталось всего лишь перевести это все в код, что, как вы понимаете, изян задача.
Еще несколько дней я убила на миграции и тесты. Стало понятно, почему ребята не парились из-за невозможности локального запуска — тесты и CI/CD проверки хорошо покрывали кодовую базу, и у меня несколько дней реально ушло на то, чтобы добиться прохождения тестов и пайплайна. Попутно я разобралась, как это правильно делать.
По итогу выяснилось, что я использовала неправильные строковые константы для сообщений об ошибках и накосячила в одном месте из-за плохого знания домена (надо было фильтровать сущности по определенному полю, кто ж знал). Но в целом нормально.
Ну а потом я перешла в другую команду и моя славная карьера go-разработчика закончилась. В новой команде я уже больше полугода пишу на Svelte. Позже расскажу, с какими сложностями я столкнулась после того, как перешла с React на Svelte (спойлер: ни с какими, две недели немножко неудобно, а потом привыкаешь).
3❤29👏8😁8🤣3🔥2🤮1👨💻1
Помните, я писала о том, как делать сопроводительные на hh? В общем, можно больше не тратить на это время, смысл сопроводительных окончательно утрачен.
😁5🤡4🤣1
Forwarded from HR-эксперт
Кхэ-Кхэ ру выкатил обновление для соискателей и представил новую функцию "AI-генерация сопроводительного письма"🤦🏻♂️
Вот теперь точно AI будет отбирать AI... а работать-то кто потом будет?🫣
Вот теперь точно AI будет отбирать AI... а работать-то кто потом будет?🫣
🥴13🤣2👀2