Linkedin писали русские
Перевод: https://www.linkedin.com/pulse/observe-dont-just-see-sergey-derevyago-cbj7f
Ватсон: Я думаю, мои глаза не хуже ваших.
Холмс: Да, это так. Но вы смотрите и не видите...
Сколько лет вы уже смотрите на эту картинку?
Нет, там не аудио компонент. А простое понятное русское слово...
С днём программиста!
От TODO-листа к анимационному шедевру
Начал разбираться с Motion для React, но оказалось, что свежих обзорных статей почти нет? В нашей статье полный обзор библиотеки Motion — идеального инструмента для создания современных UI-анимаций. Внутри:
Разбор ключевых motion-компонентов.
Практические примеры кода с плавной анимацией TODO-листа.
Как настроить анимации появления, исчезновения и перетаскивания элементов.
Советы по оптимизации с LazyMotion и управлению анимациями через хуки.
Интересные лайфхаки для создания интерактивных интерфейсов без потери производительности.
В статье «Попробовал библиотеку Motion в React: делюсь обзором» есть примеры кода, GIF-анимации и описание хуков, которых, достаточно, чтобы понять Motion, и, возможно, попробовать его руками, сэкономив время на чтении документации.
В видео поговорим про то, как отключить табы в vscode, и как навигироваться по файлам без них. Отформатируем визуальное отображение одного оставшегося таба. А еще бонусом расскажу про Cooklang – язык для кулинарии и разметки рецептов.
Какие способы навигации удобнее табов? Будем использовать cmd+p для Command Pallete, cmd+d для Open Recent, alt+<right> и alt+<left> для навигации по позициям курсора в разных файлах.
Конфиг выпуска:
{
"workbench.editor.showTabs": "single",
"workbench.editor.showIcons": false,
"workbench.editor.labelFormat": "medium",
"breadcrumbs.enabled": false,
}Горячие клавиши:
{
{
"key": "alt+left",
"command": "workbench.action.navigateBack"
},
{
"key": "ctrl+-",
"command": "-workbench.action.navigateBack"
},
{
"key": "alt+right",
"command": "workbench.action.navigateForward"
},
{
"key": "ctrl+shift+-",
"command": "-workbench.action.navigateForward"
},
{
"key": "cmd+d",
"command": "workbench.action.quickOpenPreviousRecentlyUsedEditorInGroup",
"when": "!activeEditorGroupEmpty"
},
{
"key": "ctrl+tab",
"command": "-workbench.action.quickOpenPreviousRecentlyUsedEditorInGroup",
"when": "!activeEditorGroupEmpty"
},
}Полный конфиг: https://github.com/sobolevn/dotfiles
В открытом репозитории «A to Z Resources for Students» представлены ресурсы для обучения Python, PHP, Ruby, C++, C#, Machine Learning и нейросетями, а также всё про разработку на Android и много материалов про Frontend и Backend.
На днях посмотрел два видео по рынку ИТ, в том числе с фокусом на российский сегмент (раз и два).
За завесой рассказов про ИИ, vibe coding, T-shape, динамику Восточной Европы и прочим анализом в тени остался, на мой взгляд, самый важный вопрос, на который можно ответить "да" или "нет".
Способен ли "вкатун" - человек без коммерческого опыта, выучивший ответы для прохождения собеседования - удовлетворять потребностям компании, куда его наняли?
То есть достаточно ли для компании того, что задачи будут выполняться человеком, который на ходу будет находить способы их решения, не важно какие и как.
Приносит ли такой сотрудник по факту больше пользы, чем вреда, и стоит ли он своих денег.
Если да, то ваши годы опыта, полученные в бою знания, институтская теория больше не стоят примерно ничего, кто бы что ни говорил, вы стоите в общей очереди со всеми.
Они могут дать вам только полезные знакомства, и вы обойдете сам процесс найма.
Поэтому работникам придется адаптироваться, находя новые подходы к прохождению собесов, или менять профессию.
Если нет, то компаниям срочно надо менять подходы к найму, о чем было сказано многократно, а текущие тенденции временные и будут сглажены самим рынком.
А как думаете вы?
После прочтения статьи Меня сократили из Т-Банка, и я полгода искал работу в IT захотелось поделиться своим взглядом на ситуацию.
Согласен с автором, что тренды меняются.
На смену периоду массовой удалёнки приходит эпоха гибридных решений. Требование Uber о работе в офисе три дня в неделю или решение МТС запретить удалёнку из-за рубежа — яркие примеры общей тенденции. Мне кажется, гибридный формат является наиболее сбалансированным ответом на этот запрос рынка, позволяя совмещать преимущества обоих форматов.
Как показывают обсуждения (например Рынок жестче, планка — выше: как проходят технические собеседования в 2025 году), рынок требует от специалистов всё большего, и ключ к успешному трудоустройству — в совпадении ожиданий по трём пунктам: задачи, условия и оплата.
В нашей компании («Росшоколад») мы используем разные форматы в зависимости от задач конкретной команды. Например, для одной из позиций в Санкт-Петербурге (Frontend/Fullstack) мы ищем специалиста именно на гибрид — считаем, что для этого проекта это будет наиболее эффективно.
Интересно узнать у вас:
Какой формат работы преобладает в вашей компании?
Замечаете ли вы сдвиг в сторону гибрида или возврата в офис?
(Если кого-то заинтересует наша вакансия в Питере, пишите в ТГ).
В продолжение темы серверного HTML рендеринга на Kotlin.
Если вы не читали статью, кратко напомню о чём речь: я написал небольшой можно сказать фреймворк для генерации HTML на стороне сервера на Kotlin. И поддержку строготипизированных routes для удобного создания ендпоинтов, ссылок на них и форм. Теперь Spring Views можно создавать на Kotlin и по крайней мере в моих проектах (а один из них очень большой - сотни отдельных страниц и десятки виджетов) это дало мне огромное удобство, уверенность, безопасность, рефакторо-пригодность, простое версионирование и переиспользование кода, например, теперь я точно не сделаю опечатку в URI или имени параметра и не смогу передать неверный тип данных на endpoint.
Одна из проблем которые до недавнего времени была в связи с использованием данного фреймворка - это CSS-стили. Приходилось либо инлайнить стили непосредственно для HTML элемента, либо мейнтейнить огромный (или несколько поменьше) CSS файл без возможности внятно следить за старыми более неиспользуемыми классами и селекторами. Кто создавал большие CSS файлы знает о чём я говорю - со временем количество классов накапливается и вычистить их не задев чего-то всё ещё нужного очень сложно. Вот так приходилось работать с CSS стилями раньше:
DIV("css-class-name") {...}
// или
DIV {
style("color: red;")
+"Hello World"
}В принципе жить можно, но хотелось чего-нибудь:
что-то на подобии Styled-Components из ReactJS, но так же на Kotlin
по возможности поддержку JVM hot-reload в режиме отладки
как следствие кода на Kotlin - иметь возможность всегда отслеживать зависимости и удалять более неиспользующиеся CSS-правила.
Долго думал как это получше сделать, и пока что первая версия получила вот такой синтаксис:
@Component // Spring @Component
object MyCssClass : CssClass({
style = "color: black;"
hover = """
color: red;
text-decoration: underline;
"""
})
...
A(MyCssClass) {
href(SomeUsefulRoute(param = 1))
+"Click me"
}То есть объявляем object который будет нести информацию о CSS свойствах элемента. И далее просто используем его в тех же местах где раньше можно было указать css-class-name. CssClass поддерживает массу "псевдоклассов" типа hover, active, firstOfType, before, after и так далее, так же можно добавлять media брейкпоинты и всякие другие штуки. Вот более насыщенный пример:
@Component
object Container : CssClass({
style = "padding: 25px;"
hover = "background: #eee;"
add(">a", "color: green;")
add(">a:hover", "text-decoration: underline;")
media("max-width: 991px") {
style = "padding: 10px;"
}
})
Вы наверняка заметили двойные скобочки ({...}) - в конструктор я передаю функцию-инициализатор стилей. Это нужно для того, чтобы в дебаг режиме JVM можно было на лету менять свойства CSS класса без перезапуска приложения: код который генерирует сам css-файл может быть запущен в режиме dev-mode, когда на каждый запрос файла будут выполнены все функции-инициализаторы ещё раз и файл будет собран заново.
Если по какой-то причине вам не нравится object - можно просто объявить class и использовать его:
@Component
class Container : CssClass({...})
...
DIV(Container::class) { ... }Теперь в проекте порядок с CSS стилями - нет давно умерших, всегда можно найти точки использования, стили лежат рядом с виджетами и т.п.
Смотрите исходники тут. Фидбэк приветствуется, всем хорошего дня.
Репозиторий react-bits содержит тысячи анимированных компонентов на React для создания веб-проектов и интерфейсов, а также большое количество элементов — кнопки, карточки, меню, необычные курсоры, анимированные списки и декоративные фишки. Каждый из компонентов можно протестировать в браузере — проверить работу и то, как он будет смотреться в вебе. Элементы интегрируются в проект за один клик.
HR-собеседование: почему не стоит задавать технические вопросы
За эти полгода я прошел больше 100 собеседований, и только на одном техническом интервьюер понял, о чем спрашивает. HR там занимается только React-разработчиками и умеет писать простые приложения.
На остальных собеседованиях меня спрашивали про ООП, связи таблиц в базе данных и типы данных в JS. На первый вопрос я уже могу не помнить ответа, так как пишу на функциях 5 лет. Второй вопрос — вообще не мой конек. Третий — вроде имеет смысл, но что HR этим проверяет? 🤔
HR-собеседование важно, но его цель — не в проверке технических навыков, а в оценке личных качеств. Когда HR начинает спрашивать про фреймворки или синтаксис, это пустая трата времени для всех. 🕐
Почему технические вопросы на HR-этапе — это плохо?
HR может неправильно оценить ответ. Если кандидат скажет что-то сложное, HR не поймет, правда это или блеф. Если ответ будет неверным, HR может пропустить хорошего специалиста. 😕
Создаётся ложное впечатление о компании. Кандидат думает: «Если HR лезет в технические детали, что будет на реальном собеседовании?» 😲 Это отпугивает сильных разработчиков, которые ценят время. ⏰
HR-этап должен фильтровать другое. Мотивация, ожидания по зарплате, готовность к условиям работы (офис, гибрид, удалёнка). Умение коммуницировать, работать в команде, адаптироваться к процессам. 💼
Вывод
HR-собеседование должно помочь кандидату и компании понять, подходят ли они друг другу по культуре, запросам и ценностям, а не проверять знание фреймворков. Оставьте техническую часть технарям. 🛠️
Представлена библиотека красочных анимаций на чистом JS для разных проектов All-in-one animation engine. Все анимации интегрируются за один клик и разобраны по типам: скроллбары, загрузчики, меню, переходы, счётчики или просто стилизованные элементы.
WT Yandex map items v.2.1.0 модуль для Joomla.
Выводит материалы Joomla в виде меток на Яндекс.Карты. Используется API 3.0.
v.2.1.0. Что нового?
Сохранение последнего вида карты.
Добавлены новые опции, позволяющие как для одного экземпляра модуля, так и для всех сохранять на устройстве пользователя последний использованный центр (координаты) и масштаб (zoom) карты. Это позволит открыть карту в том же месте после обновления страницы или при повторном открытии браузера.
Определение местоположения пользователя.
Модуль может определять местоположение пользователя и центрировать карту на нём. При одновременном использовании с функцией сохранения последнего вида карты определение геопозиции будет срабатывать только в первый раз. В дальнейшем, если обнаружены сохранённые данные центра и масштаба - будут использоваться они.
CSS классы для маркеров карты.
Всем маркерам карты добавлен CSS-класс wt-yandex-map-items-marker. Для просмотренных маркеров (по которым кликали) добавляется CSS-класс wt-yandex-map-items-marker-viewed, что позволит выделять просмотренные маркеры с помощью стилей в CSS-файлах вашего шаблона. Также для контейнеров маркеров ymaps на карте добавлены data-атрибуты: data-module-id - id модуля и data-marker-id - id маркера.
Обработка GET-параметров в URL.
Карта может реагировать на GET-параметры в url:
map[zoom] - устанавливает параметр масштаба.
map[center_latitude] и map[center_longitude] - широта и долгота центра карты.
map[marker_id] - id маркера, на котором центрируется карта. Таким образом вы можете создавать ссылку на карту с указанием конкретного маркера, на котором карта сфокусируется после загрузки маркеров. Например, https://site.ru/map?map[marker_id]=18465. Или же ссылку с указанием конкретных координат: https://site.ru/map?map[zoom]=16&map[center_latitude]=51.529706&map[center_longitude]=46.033922
Удивляюсь вот чему — облачные провайдеры ИИ / создатели моделей и агентов вроде OpenAI, Anthropic, Perplexity — тратят многие миллиарды долларов на создание и обучение своих моделей, одно только "железо" стоит миллиарды и требует постоянного обновления... Лучшие умы планеты, которых переханчивают в Meta за сотни миллионов долларов создают невероятные модели. Сотни разметчиков размечают данные, лучшие девопсы раскатывают десятки тысяч серверов, чтобы всё работало быстро и стабильно.
При этом desktop-приложения (да и мобильные тоже) у всех них — просто слёзы (я активно использую LLM и ИИ-агенты и у меня подписки на десятки сервисов, есть уже статистика). Такое наверное хороший студент может написать за месяц, но только лучше.
Как вообще такое может быть?...
Можно было бы очень долго перечислять конкретные недостатки: отсутствие возможности сохранить файл в perplexity (нужно выделять копировать текст целиком), невозможность удобно скопировать текст почти везде (то MD-форматирование теряется, то реализовно неудобно), сильно ограниченный функционал "проектов" в OpenAI (ими нельзя поделиться, по ним нельзя искать итп) и так далее.
Как так получается у них — я не понимаю)
7 полезных плагинов для фронтенд-разработки в VS Code!
Сегодня хочу поделиться с вами списком полезных плагинов для Visual Studio Code, которые упростят вашу работу и повысят производительность.
ESLint — находит ошибки и баги в JS/TS коде. Незаменим для профессиональной разработки. 🛠
Prettier — автоматически форматирует код по стандартам. Никаких споров о стилях! 📊
Code Spell Checker — ищет опечатки в коде и комментариях. Больше никаких ошибок из-за опечаток! Для русского языка нужно установить дополнительный плагин Russian - Code Spell Checker 🔍
DotENV — подсветка синтаксиса для .env файлов. Переменные окружения больше не путаются! 📦
GitLens — показывает, кто и когда менял каждую строку кода. Незаменим для работы в команде.
NPM outdated — показывает устаревшие зависимости в проекте. Не пропустите важные обновления! ⏳
SonarQube — анализирует качество кода, ищет уязвимости. 🔐
Установите эти плагины и сделайте свою работу ещё эффективнее! 💻
Сделал для Хабра чорный минималистичный широкий userstyle, возможно вам тоже понравится
https://gitlab.com/vitaly-zdanevich-styles/habr
Жёсткая структура 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 с моками (моки не показывают реальное поведение сервера)
Тестирование библиотек (проверяете чужой код)
Что использовать вместо?
Интеграционные тесты — проверяют реальные сценарии
Zod для валидации API — предотвращает ошибки из-за неожиданных данных
Ручные проверки — быстрее и точнее, чем скриншотные тесты
Для джуниора unit-тесты — не приоритет. Важнее:
Глубокое изучение фреймворка
Умение работать с API
Навык чтения и отладки кода
Не стоит тратить время на «тесты ради тестов». Сосредоточьтесь на том, что действительно поможет в работе.
«То, для чего Cи недостаточно хорош»: МойОфис выпустил трёхтомник по Lua
Lua — актуальный и востребованный в разработке язык программирования, но литературы на русском языке про него по-прежнему немного. Мы решили это исправить и выпускаем трёхтомник, в котором собрали всё, что нужно знать о Lua, и показали, как именно он работает на примере редакторов МойОфис — от основ синтаксиса до создания надстроек и автоматизации обработки электронных документов.
«Lua предлагает то, для чего Си недостаточно хорош: достаточную удалённость от аппаратного обеспечения, динамические структуры, отсутствие избыточности и лёгкость тестирования и отладки. С самого начала Lua создавался для реальных сценариев взаимодействия с хост-программами, такими как МойОфис, и предлагает инструменты для опытных программистов, чтобы проявить свои творческие способности», — Роберту Иерузалимски, один из основных создателей языка программирования Lua.
Первый том — уже третье переиздание классической книги Роберту. Предыдущие два издания также вышли в свет при поддержке МойОфис.
Второй и третий тома — первый выпуск учебников Дмитрия Шульгина, старшего тренера по продуктам Учебного центра МойОфис («Хаб Знаний МойОфис»), посвященных созданию макрокоманд и надстроек в наших текстовых и табличных редакторах.
В них вы найдёте:
что такое макросы и надстройки, как устроена автоматизация в МойОфис и зачем все это нужно (к слову, о разработке макросов мы подробно писали здесь);
основы Lua — от переменных и типов данных до пользовательских функций;
примеры работы со списками, листами, ячейками, а также задания для закрепления материала;
примеры создания надстроек для ускорения и автоматизации операций: от вставки изображений и рецензирования до печати и локализации интерфейса.
Каждая глава сочетает теорию, рекомендации и практические задания, которые можно выполнить прямо в наших редакторах.
Книга подойдёт как опытным разработчикам, так и новичкам в Lua и автоматизации. А если хотите глубже погрузиться в тему — присоединяйтесь к нашим курсам по Lua.
Чек-лист для эффективного технического интервью
1. Подготовка: что сделать перед собеседованием
Определите 3 главных навыка, необходимых для вакансии. Например: «Оптимизация React», «Работа с легаси-кодом (React классы)», «Работа с Redux».
Подготовьте реальные задачи из вашего проекта, а не абстрактные алгоритмы.
Четко опишите стек технологий и проблемы проекта, чтобы кандидат понимал контекст.
Пример: «У нас проект на React 16.8. Остались классовые компоненты, которые нужно переписать на хуки, и мы используем классический Redux».
2. Структура собеседования
А. Вводная часть (5-10 минут)
Представьтесь и расскажите о проекте простым и понятным языком.
Спросите кандидата, есть ли у него опыт работы над подобными задачами.
Б. Проверка навыков (30-50 минут)
Практическая задача (5-10 минут)
Дайте кандидату упрощенную версию реальной проблемы. Например: «Нужно переписать классовый компонент на хуки и подключить его к Redux, а затем оптимизировать рендер».
Позвольте кандидату воспользоваться интернетом для поиска информации. Главное, чтобы он показал процесс решения задачи, а не просто копировал ответ.
Гибкие вопросы (5-10 минут)
В процессе выполнения задачи или после ее завершения (на мой взгляд, лучше после) задавайте вопросы, которые помогут вам лучше понять подход кандидата.
Пример: «Вы использовали кеширование. Расскажите подробнее, как это поможет нашему проекту?»
Финальное обсуждение задачи (10-15 минут)
Обсудите решение задачи целиком, что получилось, а что можно улучшить.
Если все навыки не уместились в одну задачу, вернитесь к шагу 1.
В. Заключение (5-10 минут)
Дайте кандидату возможность задать вопросы о проекте.
Объясните, какие будут следующие шаги, чтобы не оставлять его в подвешенном состоянии.
3. Критерии оценки
Оценивайте кандидата по конкретным показателям, а не по субъективным впечатлениям:
Понимание проблемы — видит ли кандидат суть задачи?
Процесс решения — как ищет ответ, какие вопросы задает?
Качество кода — читаемость, оптимизация.
Коммуникация — может ли кандидат объяснить свои решения?
Пример оценки:
✅ «Правильно переписал с классов на хуки и подключил Redux» — отличный кандидат!
⚠️ «Правильно настроил кеширование, но забыл useCallback в одном месте» — нужно обсудить детали.
❌ «Не смог объяснить, почему компонент ререндерится» — потенциальные риски для проекта.
Подобную сводку по собеседованию можно отправить в качестве обратной связи, чтобы кандидат получил полезные комментарии и знал, над чем ему стоит поработать.