Если бы в JavaScript действительно работала сборка мусора, большинство npm-модулей удаляли бы сами себя сразу после установки.

main {
  max-width: 38rem;
  padding: 2rem;
  margin: auto;
}

В этой статье я хочу затронуть задачу, с которой вы можете столкнуться на собеседовании на позицию Front-End — создание Image Slider.

За последние 5 месяцев у меня было 15 онсайт собеседований, а также офферы от Google, Roku, Microsoft и других. (Больше информации можно прочитать в моем Telegram-канале)

Вы должны реализовать этот виджет за ~45–50 минут и рассказать об оптимизации. Эту информацию я постараюсь рассказать здесь. Основная цель состоит не в том, чтобы реализовать Image Slider с большим количеством функционала, а в том, чтобы показать, как реализовать и оптимизировать.

• Введение в REST API — RESTful веб-сервисы
• Различия REST и SOAP
• Разработка REST API — что такое Contract First (контракт в первую очередь)?
• Разработка REST API — что такое Code First (код в первую очередь)?
• REST API — Что такое HATEOAS?
• Рекомендации по REST API — примеры проектирования веб-сервисов на Java и Spring

Статья про мемоизацию оказалась объёмной и включает в себя разбор hoc memo, хуки useMemo и useCallback, затрагивает тему useRef. Было принято решение разбить статью на 2 части, в первой части разберем когда нужно и когда ненужно использовать memo, какое у него api, какие проблемы решает. Во второй части разберем хуки useMemo, useCallback, а также некоторые проблемы этих хуков, которые можно решить с помощью useRef.

В прошлых статьях мы разбирали как работать с useState и с useEffect. Знаем: код компонента будет выполняться каждый раз при его обновлении. Отсюда возникает проблема - данные и сложные вычисления будут теряться, также будет происходить лишнее обновление дочерних компонентов. Эти проблемы решает хук useMemo и обертка над ним useCallback, но оба работают в связке с memo hoc.

В этой статье разберем как с помощью useEffect воспроизвести методы жизненного цикла в функциональных компонентах. Поговорим как и когда использовать useEffect и useLayoutEffect. Обсудим особенности отправки запросов из useEffect. Также узнаем почему массив зависимостей необязателен и когда это может пригодиться.

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

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

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

За последние 10 лет я поменял 3 работы, прособеседовался с 10+ компаний на позицию разработчика (software engineer) и вел переписку с HR/рекрутерами из нескольких десятков фирм. По ходу дела заметил, что вопросы, которые я задаю на собеседовании с менеджером/командой или с HR, повторяются, и решил их структурировать. Некоторые из них являются общими, и их может задать кандидат на почти любую вакансию; другие касаются только вакансий для программистов. В этой статье поделюсь с вами наиболее типичными и важными вопросами, которые, на мой взгляд, может задать соискатель потенциальному работодателю.

Меня зовут Николай, я Frontend-разработчик IT-компании Relog. Хочу рассказать о самых распространённых ошибках в вёрстке современных проектов.

Дело в том, что лишь малая часть современных фронтендеров обращает внимание на работу с HTML и CSS, предпочитая готовые решения, вроде UI-библиотек и систем сеток. Но эти решения неидеальные и приходится дописывать обёртки вокруг них, видоизменять код, переписывать стили и совершать прочие действия для соответствия требованиям проекта. Тут-то и начинаются проблемы: вёрстка местами становится избыточной, стили переназначются через important и с каждым релизом проект всё сложней поддерживать. Я уже не говорю об удобстве использования и доступности. Об этом думают вообще в последнюю очередь.

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

В данной статье я хочу предоставить переработанную и упорядоченную выжимку документации по настройке "флагов строгости" tsconfig.json. Статья будет полезна как тем, кто только начинает работать с TypeScript, так и тем кто уже давно работает, но при этом использует конфиг по умолчанию. Для разработчиков, которые хорошо ориентируются в вопросах строгости в TypeScript статья может открыть некоторые тонкости работы флагов и послужить шпаргалкой.

Привет, друзья!

Хочу поделиться с вами решением интересной задачи: записать экран компьютера пользователя.

Общие требования к реализации:

• запись должна состоять из видео и аудио
• у пользователя должна быть возможность просмотра и скачивания записи
• данные должны передаваться и сохраняться на сервере
• запись, сохраняемая на сервере, должна быть приличного качества, но весить мало

Если вам это интересно, прошу следовать за мной.

→ Исходный код проекта

Скриншот:

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

Привет, я Сергей Вахрамов, занимаюсь фронтенд-разработкой на Angular в компании Тинькофф. Во фронтенд-разработку вошел напрямую с тайпскрипта, просто перечитав всю документацию. С того момента и спецификация ECMAScript расширилась, и TypeScript сильно подрос. Казалось бы, почему разработчики могут бояться дженериков, ведь бояться там нечего? Мой опыт общения с джуниор-разработчиками говорит, что во многом ребята не используют обобщенные типы просто потому, что кто-то пустил легенду об их сложности.

Эта статья для тех, кто не использует generic-типы в TypeScript: не знают о них, боятся использовать или используют вместо реальных типов — any.

В данной статье я хочу предоставить переработанную и упорядоченную выжимку документации по настройке tsconfig.json, которая, я уверен, будет полезна тем, кто только начинает свой путь в мире TypeScript или тем, кто до этого момента не нашёл времени и сил, чтобы разобраться в деталях и теперь хочет закрыть этот пробел.

В сети полно обзоров Chrome DevTools, которые демонстрируют многочисленные возможности этого прекрасного инструмента. DevTools настолько большие, что познать их полностью, как мне кажется, уже почти невозможно.

В этой заметке я бы хотел остановиться на различных нюансах, полезных при отладке. Какие-то из них я почерпнул в сети (например в комментариях на Хабре), до каких-то додумался сам. Надеюсь вы найдёте для себя что-нибудь полезное.

Под катом:

— Как отладить popup-ы, которые исчезают при потере фокуса
— Как убить повисший JS-цикл, не убивая вкладку
— Различные нюансы работы с breakpoint-ми
— Методы ведения войны с sourceMaps
— Перехват network-запросов
— Как отладить race-condition
— Почему стоит опасаться галочки "disable cache"
— Что делать если у вас не Hi-DPI экран?

Наткнулся на любопытный материал, в котором автор систематизировал и записал свой опыт инженера-программиста в 20 тезисов. Я работаю в коммерческой разработке ПО больше 25 лет, и этот текст отозвался во мне практически каждой буквой — большинство советов я тоже регулярно практикую, не облекая их в формат ёмких афоризмов. В общем, решил сделать перевод.

Особенно отзываются пункты «стройте компактные системы» и «лучший код — это отсутствие кода». Последний совет я превращаю в цитату из какого-то второсортного фильма про самураев: «Лучшая победа — та, которую ты одержал, не доставая меч из ножен» (думаю, сослуживцы за моей спиной уже закатывают глаза). И, конечно, бесконечные разговоры про легендарных 10x-программистов постоянно хочется прервать советом не связываться с 0,1x-программистами (которые реально существуют, в отличие от 10x).

1. Спать регулярно, ложиться и вставать в одно и то же время — самое важное. 
2. Биоритмы — частично наследуются, частично регулируются стилем жизни. На них можно влиять самому.
3. Нормальное время отхода ко сну около 22:00. Сова и жаворонок — это отклонение на ±1-2 часа. Больше — это нарушение и сдвиг фазы сна, чаще из-за внешних раздражителей.
4. Самая частая причина плохого сна и тяжелого засыпания — неправильный свет.
5. Для сдвига режима на 1 час организму нужен 1 день на адаптацию.
6. Невозможно «доспать» бессонную ночь. Досыпание устраняет только 30% последствий недосыпа.
7. Прежде, чем искать причины плохого сна, исключите психологические проблемы (тревожность, депрессию), нарушения щитовидки, дефицит железа, диабеты, сердечно-сосудистые заболевания и патологию почек и мочеполовой системы.
8. Водителям и пассажирам: 17 часов без сна равны 0,5 промилле, 21 час без сна — 0,8 промилле.
9. В постели без сна больше 15 минут не находиться — совет при бессоннице. 
10. Самые физиологичные будильники — те, что светятся.