JavaScript *

Анализ проектов

Заказчик отправил архив с десятками айтишных разработок и попросил в короткие сроки дать по нему заключение: что полезно, а что нет. Какие проекты выбросить, а какие выгодно развивать (с указанием потенциальной прибыли и перечня необходимых работ). С подобной задачей мы в лабе сталкивались не раз, но это была внутренняя кухня. А тут большое количество проектов, которые никто прежде в глаза не видел. Сроки сжатые, вникнуть в детали каждого проекта физически невозможно.

Невыполнимые задачи мы любим больше всего. Структурировали требования к оценке проекта и написали протокол для анализа (https://vsempo.xyz/lab/analpro/index.html). Работает так: загружаете исходные файлы проекта в LLM, загружаете файл протокола и в ответе получаете JSON с полным описанием проекта, багами, технологическим стеком, конкурентными преимуществами, потенциальной прибылью от внедрения, алгоритмом развития и необходимым ресурсам. При желании можно сделать все это пакетно: указываете каталог и получаете набор файлов с результатами.

Но сами по себе JSON-файлы изучать сложно. Поэтому на сдачу написали небольшой вьюер на JS (https://vsempo.xyz/lab/analpro/analproview/index.html). Загружаете в него все файлы JSON с описанием проектов и получаете визуализацию, сводную статистику по всем проектам, возможность изучить детали по каждому проекту и общую стратегию развития. Пока эта система больше напоминает концепт, чем промышленное решение, но для нашей конкретной задачи этого более чем достаточно.

Изначально задача казалось совершенно невыполнимой. А в итоге самую большую трудность вызвало придумать название. С одной стороны, мы написали протокол анализа. Но еще мы написали классическую программу для анализа проектов. Долго не могли решить, какое название выбрать: аналпро или проанал. В итоге остановились на первом варианте. Хотя я был против. Нужно было назвать систему "проанал", а название "аналпро" сохранить для расширенной коммерческой версии.

От TODO-листа к анимационному шедевру

Начал разбираться с Motion для React, но оказалось, что свежих обзорных статей почти нет? В нашей статье полный обзор библиотеки Motion — идеального инструмента для создания современных UI-анимаций. Внутри:

• Разбор ключевых motion-компонентов.

• Практические примеры кода с плавной анимацией TODO-листа.

• Как настроить анимации появления, исчезновения и перетаскивания элементов.

• Советы по оптимизации с LazyMotion и управлению анимациями через хуки.

• Интересные лайфхаки для создания интерактивных интерфейсов без потери производительности.

В статье «Попробовал библиотеку Motion в React: делюсь обзором» есть примеры кода, GIF-анимации и описание хуков, которых, достаточно, чтобы понять Motion, и, возможно, попробовать его руками, сэкономив время на чтении документации.

Поиск скомпрометированных зависимостей через Dependency Track

На днях стало известно о компрометации почти 2-х десятков npm-пакетов (подробнее в этой статье). Зловредный код может похищать криптовалюту. Это не первый раз, когда в зависимости попадает зловред (например, в 2022 году зловред удалял данные).

Один из вариантов поиска наличия скомпрометированных пакетов среди сотен проектов - использование Dependency Track. При этом поиск возможен и в транзитивных зависимостях тоже. На картинке ниже показан процесс. Заходим в раздел "Components", вводим название в формате "pkg:npm/$name$". Далее остаётся отсортировать по версии и найти среди них скомпрометированную (сейчас это легко - нужно смотреть самую старшую версию). Можно поиск производить сразу по конкретной версии. Пример:

pkg:npm/simple-swizzle@0.2.3

Если пакет нашёлся - можно не только узнать в каком именно проекте, но и увидеть где именно в дереве зависимостей проекта используется (нажать на иконку, обведённую красным).

Если знаете альтернативные варианты поиска скомпрометированных пакетов другими средствами - напишите в комментариях.

Подборка обучающих материалов по языкам программирования от Selectel: Go, Python и JavaScript

Привет, Хабр! Несу вам небольшую подборку материалов, которые помогут новичкам лучше разобраться в трех популярных ЯП. Все статьи доступны бесплатно, регистрироваться нигде не нужно, вообще никаких обязательств с вашей стороны. Итак, поехали.

Go

Эти семь статей составляют практический гайд по работе с Go. Вы научитесь писать простые сервисы вроде сокращателя ссылок и использовать этот язык в некоторых рабочих задачах, а еще получите большую подборку материалов для погружения в тему (да, у нас тут подборка в подборке, так уж вышло). На прочтение всех материалов уйдет примерно два часа.

Python

Если самые базовые вещи в Python вы уже освоили, то эта подборка для вас. Вы узнаете, как настраивать инструменты, работать с базами данных, создавать программы с интерфейсом и использовать Python для парсинга. А еще здесь есть несколько интересных задач, чтобы можно было закрепить знания. Всего в подборке девять материалов, примерно на четыре с небольшим часа чтения.

JavaScript

Эту подборку мы с коллегами собрали для тех, кто только делает свой первый шаг в мир JavaScript. В пяти статьях рассказываем, как работать с переменными, типами данных и функциями, а также как строить логику с условными операторами. Практические примеры помогут освоить создание элементов и взаимодействие с ними через JavaScript, а задача в конце — закрепить знания и испытать навыки.

Репозиторий react-bits содержит тысячи анимированных компонентов на React для создания веб-проектов и интерфейсов, а также большое количество элементов — кнопки, карточки, меню, необычные курсоры, анимированные списки и декоративные фишки. Каждый из компонентов можно протестировать в браузере — проверить работу и то, как он будет смотреться в вебе. Элементы интегрируются в проект за один клик.

HR-собеседование: почему не стоит задавать технические вопросы

За эти полгода я прошел больше 100 собеседований, и только на одном техническом интервьюер понял, о чем спрашивает. HR там занимается только React-разработчиками и умеет писать простые приложения.

На остальных собеседованиях меня спрашивали про ООП, связи таблиц в базе данных и типы данных в JS. На первый вопрос я уже могу не помнить ответа, так как пишу на функциях 5 лет. Второй вопрос — вообще не мой конек. Третий — вроде имеет смысл, но что HR этим проверяет? 🤔

HR-собеседование важно, но его цель — не в проверке технических навыков, а в оценке личных качеств. Когда HR начинает спрашивать про фреймворки или синтаксис, это пустая трата времени для всех. 🕐

Почему технические вопросы на HR-этапе — это плохо?

1. HR может неправильно оценить ответ. Если кандидат скажет что-то сложное, HR не поймет, правда это или блеф. Если ответ будет неверным, HR может пропустить хорошего специалиста. 😕

2. Создаётся ложное впечатление о компании. Кандидат думает: «Если HR лезет в технические детали, что будет на реальном собеседовании?» 😲 Это отпугивает сильных разработчиков, которые ценят время. ⏰

3. HR-этап должен фильтровать другое. Мотивация, ожидания по зарплате, готовность к условиям работы (офис, гибрид, удалёнка). Умение коммуницировать, работать в команде, адаптироваться к процессам. 💼

Вывод

HR-собеседование должно помочь кандидату и компании понять, подходят ли они друг другу по культуре, запросам и ценностям, а не проверять знание фреймворков. Оставьте техническую часть технарям. 🛠️

Представлена библиотека красочных анимаций на чистом JS для разных проектов All-in-one animation engine. Все анимации интегрируются за один клик и разобраны по типам: скроллбары, загрузчики, меню, переходы, счётчики или просто стилизованные элементы.

Переписываем примеры из популярных стейт-менеджеров на kr-observable используя только две функции.

вот код, позволяющий создавать экземпляры экземпляров:

const Cstr = function () {
    const Self = function () {};
    Object.setPrototypeOf(Self, this);
    return Self;
};

const item = new Cstr;

console.log('item instanceof Cstr : ', item instanceof Cstr);

const itemInstance = new item;

console.log('itemInstance instanceof item : ', itemInstance instanceof item);

вот Gist где кода больше и лучше, там экземпляры вглубину тоже наследуются, но там намного соложней и очень долго, зато 200 строк console.log'ов :
https://gist.github.com/wentout/8a2631fd5cc5827df5946b9b6598bf99

вот статья про этот код, но там душно, и форточки закрыты:
https://habr.com/ru/articles/939050/

; ^ )

Развлекся и собрал калькулятор окупаемости автоматизации

Ты можешь указать как часто делаешь рутину, сколько на это уходит, а калькулятор расскажет выгодно ли автоматизировать или нет.

Было это так: покекал с залежавшегося выдержанного мема от xkcd про "сколько времени уходит на рутину за 5 лет" и задумался... Понял, что калькулятор окупаемости не помешает.

Ведь автоматизировать надо, когда:

1. Регулярно/часто выполняешь однотипную задачу
2. Каждый раз на эту задачу уходит время (даже если минута)
3. Понимаешь как можно автоматизировать хотя бы часть этой задачи
4. Зависимость от непостоянности человека может навредить
5. Есть готовность поддерживать свою автоматизацию, а не рутину :)

Потратил месяц на автоматизацию и ускорение деплоя в staging.
Теперь деплой занимает 30 секунд вместо 5 минут.
Окупится через... 2 года 😭
(с) DevOps в курилке

7 полезных плагинов для фронтенд-разработки в VS Code!

Сегодня хочу поделиться с вами списком полезных плагинов для Visual Studio Code, которые упростят вашу работу и повысят производительность.

1. ESLint — находит ошибки и баги в JS/TS коде. Незаменим для профессиональной разработки. 🛠

2. Prettier — автоматически форматирует код по стандартам. Никаких споров о стилях! 📊

3. Code Spell Checker — ищет опечатки в коде и комментариях. Больше никаких ошибок из-за опечаток! Для русского языка нужно установить дополнительный плагин Russian - Code Spell Checker 🔍

4. DotENV — подсветка синтаксиса для .env файлов. Переменные окружения больше не путаются! 📦

5. GitLens — показывает, кто и когда менял каждую строку кода. Незаменим для работы в команде.

6. NPM outdated — показывает устаревшие зависимости в проекте. Не пропустите важные обновления! ⏳

7. SonarQube — анализирует качество кода, ищет уязвимости. 🔐

Установите эти плагины и сделайте свою работу ещё эффективнее! 💻

Делимся расписанием бесплатных вебинаров на следующую неделю:

🎬 19 августа в 16:00 (Мск) «Как ускорить работу с данными в 3 раза? Основы ДБТ за час» — вебинар про DBT, его возможности, принципы работы и способы с его помощью сделать свою деятельность эффективнее.

🎬 21 августа в 16:00 (Мск) «От идеи до продакшена: какой Kafka-клиент упростит вам жизнь?» — практический вебинар: какие высокоуровневые клиенты Kafka выбрать для Spring Boot, .NET и NestJS. Разберём ключевые отличия, реальные примеры использования и лучшие практики.

🎬 22 августа в 18:00 (Мск) «Как LDA и ARTM могут изменить подход к анализу текстовых данных» — вебинар по тематическому моделированию с LDA и ARTM, примеры на Python и практические кейсы.

Увидимся на вебинарах!

Жёсткая структура React-компонентов

При работе над React-приложениями я часто сталкиваюсь с тем, что мои коллеги смешивают в одном файле и JSX, и CSS-in-JS стили, и логику, и типы компонента. Работать с таким месивом очень сложно. Даже если настаивать на выделении логики, стилей и типов в отдельные файлы, это то делается, то нет. Для введения жёсткой структуры компонентов мною была написана простейшая библиотека react-component-structure.

https://github.com/sergeyshpadyrev/react-component-structure

Работает она простейшим образом. Любой компонент необходимо разделить на три хука и файл с типами:

-| Component
    -| index.ts
    -| logic.ts
    -| render.tsx
    -| style.ts
    -| types.ts

В файле logic.ts мы пишем хук useLogic - контроллер компонента, включающий в себя всю его бизнес-логику - все хуки useCallback, useEffect, useMemo и подобные. В этом хуке у нас есть доступ к props компонента.

import { useCallback, useState } from 'react';
import type { Props } from './types';

const useLogic = (props: Props) => {
    const [count, setCount] = useState(props.defaultCount);

    const onClickMinus = useCallback(() => setCount((c) => c - 1), []);
    const onClickPlus = useCallback(() => setCount((c) => c + 1), []);

    return {
        count,
        onClickMinus,
        onClickPlus,
    };
};

export default useLogic;

В файле styles.ts мы помещаем хук useStyle со стилями нашего компонента. Тут мы можем использовать inline-стили, CSS-in-JS или Tailwind. В этом хуке у нас есть доступ к props нашего компонента и к его контроллеру.

import type { Props } from './types';
import useLogic from './logic';
import { useMemo } from 'react';

const useStyle = (props: Props, logic: ReturnType<typeof useLogic>) =>
    useMemo(
        () => ({
            counter: {
                fontSize: logic.count + 10,
            },
            title: {
                color: props.color,
            },
        }),
        [logic.count, props.color],
    );

export default useStyle;

В файле render.tsx мы помещаем хук useRender с JSX, то бишь отображение компонента. В этом хуке у нас есть доступ и к props компонента, и к его контроллеру logic, и к стилям.

import type { Props } from './types';
import type useLogic from './logic';
import type useStyle from './style';

const useRender = (props: Props, logic: ReturnType<typeof useLogic>, style: ReturnType<typeof useStyle>) => {
    return (
        <div>
            <div style={style.title}>Hello {props.greeting}!</div>
            <div style={style.counter}>Count: {logic.count}</div>
            <div onClick={logic.onClickMinus}>Decrease</div>
            <div onClick={logic.onClickPlus}>Increase</div>
        </div>
    );
};

export default useRender;

В index.ts файле мы соединяем все три хука с помощью функции createComponent:

import { createComponent } from 'react-component-structure';

import useLogic from './logic';
import useRender from './render';
import useStyle from './style';

const Component = createComponent({ useLogic, useRender, useStyle });

export default Component;

И в файле types.ts мы объявляем тип для props компонента:

export interface Props {
    color: string;
    defaultCount: number;
    greeting: string;
}

Если у компонента нет props, то можно объявить их так:

export type Props = unknown

При использовании каждый компонент нашего приложения имеет чёткую структуру, состоящую из файлов контроллера, отображения, стилей и типов. Это разделение подобно разделению на HTML (отображение), CSS (стили) и JavaScript (контроллер) в ванильных JS-приложениях.

Если подход и библиотека вам понравились, поставьте репозиторию звезду на гитхабе. Надеюсь этот подход будет вам полезен.

Unit-тесты во фронтенде: развеиваем мифы

После статьи о навыках джуниоров многие не согласились с моей оценкой unit-тестов. Давайте посмотрим, где они действительно полезны, а где создают иллюзию ценности.

Если вы начинающий разработчик, вас наверняка убеждали:
«Без unit-тестов никуда! Всё должно быть покрыто тестами!»
Но так ли это на самом деле?

Где unit-тесты полезны:

• Бизнес-логика и утилиты (форматирование данных, расчёты)

• Кастомные хуки (управление состоянием, формы)

• Критичные функции (редкий зверь во фронтенде)

Где они бесполезны (и даже вредны):

• UI-компоненты (скриншотные тесты часто ломаются из-за изменений вёрстки)

• API с моками (моки не показывают реальное поведение сервера)

• Тестирование библиотек (проверяете чужой код)

Что использовать вместо?

1. Интеграционные тесты — проверяют реальные сценарии

2. Zod для валидации API — предотвращает ошибки из-за неожиданных данных

3. Ручные проверки — быстрее и точнее, чем скриншотные тесты

Для джуниора unit-тесты — не приоритет. Важнее:

• Глубокое изучение фреймворка

• Умение работать с API

• Навык чтения и отладки кода

Не стоит тратить время на «тесты ради тестов». Сосредоточьтесь на том, что действительно поможет в работе.

Чек-лист для эффективного технического интервью

1. Подготовка: что сделать перед собеседованием

• Определите 3 главных навыка, необходимых для вакансии. Например: «Оптимизация React», «Работа с легаси-кодом (React классы)», «Работа с Redux».

• Подготовьте реальные задачи из вашего проекта, а не абстрактные алгоритмы.

• Четко опишите стек технологий и проблемы проекта, чтобы кандидат понимал контекст.

Пример: «У нас проект на React 16.8. Остались классовые компоненты, которые нужно переписать на хуки, и мы используем классический Redux».

2. Структура собеседования

А. Вводная часть (5-10 минут)

• Представьтесь и расскажите о проекте простым и понятным языком.

• Спросите кандидата, есть ли у него опыт работы над подобными задачами.

Б. Проверка навыков (30-50 минут)

1. Практическая задача (5-10 минут)

   • Дайте кандидату упрощенную версию реальной проблемы. Например: «Нужно переписать классовый компонент на хуки и подключить его к Redux, а затем оптимизировать рендер».

   • Позвольте кандидату воспользоваться интернетом для поиска информации. Главное, чтобы он показал процесс решения задачи, а не просто копировал ответ.

2. Гибкие вопросы (5-10 минут)

   • В процессе выполнения задачи или после ее завершения (на мой взгляд, лучше после) задавайте вопросы, которые помогут вам лучше понять подход кандидата.

   Пример: «Вы использовали кеширование. Расскажите подробнее, как это поможет нашему проекту?»

3. Финальное обсуждение задачи (10-15 минут)

   • Обсудите решение задачи целиком, что получилось, а что можно улучшить.

4. Если все навыки не уместились в одну задачу, вернитесь к шагу 1.

В. Заключение (5-10 минут)

• Дайте кандидату возможность задать вопросы о проекте.

• Объясните, какие будут следующие шаги, чтобы не оставлять его в подвешенном состоянии.

3. Критерии оценки

Оценивайте кандидата по конкретным показателям, а не по субъективным впечатлениям:

1. Понимание проблемы — видит ли кандидат суть задачи?

2. Процесс решения — как ищет ответ, какие вопросы задает?

3. Качество кода — читаемость, оптимизация.

4. Коммуникация — может ли кандидат объяснить свои решения?

Пример оценки:

• ✅ «Правильно переписал с классов на хуки и подключил Redux» — отличный кандидат!

• ⚠️ «Правильно настроил кеширование, но забыл useCallback в одном месте» — нужно обсудить детали.

• ❌ «Не смог объяснить, почему компонент ререндерится» — потенциальные риски для проекта.

Подобную сводку по собеседованию можно отправить в качестве обратной связи, чтобы кандидат получил полезные комментарии и знал, над чем ему стоит поработать.

Что такое мнемотехники и как их использовать программистам

Мнемотехника — это ряд приёмов и методов, облегчающих запоминание и воспроизведение информации за счёт использования ассоциаций, образов, рифм, логических связей. «Каждый охотник желает знать, где сидит фазан» для запоминания последовательности цветов в радуге — типичный пример мнемотехники.

Как это относится к IT-специальностям? Также, как и к любому другому обучению новому. Возьмём для примера изучение языку JavaScript, где будущему программисту нужно понять, чем отличаются методы call, apply и bind. 

Для запоминания можно использовать мнемотехники:

• Call. Коля звонит другу напрямую — передаёт параметры через запятую: call (a, b).

• Apply. Аня присылает список задач — параметры передаются массивом: apply ([a, b]).

• Bind. Бен привязывает себя к таске — создаёт новую функцию с привязанным контекстом, которую можно вызывать позже.

На первый взгляд такие ассоциации могут показаться абсурдными, но это работает, потому что человек создаёт образы с действиями и именами, а не борется с терминами.

Популярные мнемотехнические приёмы

1. Дворец памяти. Мысленно разместите информацию в хорошо знакомом месте: например, на пути от дома до ближайшего магазина. Когда она вам понадобится, просто отправьтесь на воображаемую прогулку по этому маршруту. 

2. Аббревиатуры и акронимы. Составьте из первых букв слов новые слова или фразы. Именно благодаря этой мнемотехнике программисты могут припомнить, что такое KISS, SOLID и DRY.

3. Рифмы и ритмы. Зарифмуйте информацию в стишок, можно самый примитивный. Как пример, стих для запоминания числа Пи (π = 3,1415926): «Чтобы нам не ошибиться, надо правильно прочесть: три, четырнадцать, пятнадцать, девяносто два и шесть».

4. Образные связки. Соедините элементы в единый яркий образ. Допустим, французское слово pomme — «яблоко» — можно связать с таким образом: на помятом яблоке сидит крошечный гном с флагом Франции.

→ Подробнее рассказываем о теме в блоге на сайте.

Обновлён бесплатный учебник по JavaScript. Проект полностью на русском языке. Там собрано всё: от основ синтаксиса до замыканий и ООП, событий, промисов и других сложных концепций. В каждой главе десятки примеров кода — не понять материал просто невозможно. Есть много задач и контрольных как после глав, так и после больших разделов.

SOLID как священная корова? 🤔
Я думал, что пост о «фальшивых сеньорах» пройдёт спокойно — ну, очередной крик души о собеседованиях. 😅 Но нет! Хабровчане увидели слово «SOLID» и решили, что это вызов их святыне. Хотя я ничего плохого про него не сказал — просто отметил, что в React 2025 спрашивают про него по инерции. 😕

Где магия, а где фарс? ✨
Комментатор с саркастичным «быдлокод» (спасибо за реакцию, коллега!) будто подтвердил мою мысль: SOLID — это не религия, а инструмент. 🛠
SRP (Single Responsibility) в React — это о компонентах. Но если ваш «компонент формы» содержит логику, стили, валидацию и даже полёт на Марс, это не нарушение SOLID’а, а просто плохой код. 🌙
DIP (Dependency Inversion) в мире хуков и Context API чаще выглядит как «передать пропс» или «создать useClient», чем как «абстрактный фабричный фасад». 🧩
LSP (Liskov Substitution) в функциональном программировании? Его там просто нет. Или вы верите, что Button и IconButton должны наследоваться от AbstractClickable? 🤔

Если кандидат не может объяснить даже это, а только бормочет о «SOLID — это про ответственность» и использует ChatGPT, это не про принципы, а про некомпетентность. 🙅‍♂️

Про GPT и кандидатов-попугаев 🦜
«Чатжпт вам расскажет» — именно! Но если человек не может пересказать своими словами, он не понимает. А если не понимает, как он будет применять это на практике? 😵

Вывод 📜
SOLID — это хорошо. Плохо — догматично использовать его без понимания, где он нужен, а где создаёт лишние сложности. 🚫

🤡 «Фальшивые сеньоры»: как меня пытались обмануть кандидаты

Кандидат с «идеальной памятью»

Сидит передо мной разработчик. Отвечает на вопросы... странно:

Простые вещи вроде «что такое замыкание» — щёлкает как орешки.

Сложные вопросы — делает паузу на 15 секунд... и выдаёт академический ответ.

Решил проверить на практике:

✅ Теория — 10 из 10

❓ Практика — 6 из 10: простые и типовые задачи легко, рефакторинг с адской болью

❌ Объяснить, что и для чего делал — 0 из 10. Поддержать диалог, хоть как-то отойти от шаблонов — это всё не про таких кандидатов.

Напоминает студента, который выучил билеты, но не понимает предмет. Скорее всего, ему кто-то подсказывал, или он просто зазубрил типовые ответы.

«SOLID? Ну это когда ответственно»

Обычно я не люблю спрашивать про SOLID (кому вообще это нужно в React в 2025?). Но тут поведение кандидата было подозрительным — решил проверить.

Диалог:

— Расскажи про SOLID

— Это принцип единственной ответственности!

— Я жду продолжения

— Всё...

— Больше ничего не помнишь?

— Ну это основная часть....💥

Тут всё еще грустнее, видимо, GPT просто выкинул перед кандидатом 5 принципов без пояснения, что все 5 принципов образуют SOLID.

Так к чему это я:

Иногда люди кажутся хорошими специалистами, но их знания поверхностны. Они не могут объяснить свои действия, поддержать разговор или предложить что-то новое. Такие люди могут подвести в важный момент. Важно отличать настоящих профессионалов от тех, кто только красиво отвечает на вопросы, чтобы собрать сильную команду для решения сложных задач.

Представлен открытый проект ccprompts – это коллекция из 70 команд Claude Code для рабочих процессов разработки программного обеспечения. Команды включают проверку безопасности и могут использоваться непосредственно с Claude Code или адаптироваться для конкретных задач.

Примечание разработчика: Этот репозиторий находится в стадии активной разработки. Команды могут содержать ошибки, между версиями могут происходить критические изменения, а структура может меняться. Используйте с осторожностью в производственной среде.