По данным сразу нескольких вышедших в 2025 году отчётов исследователей, объём генерируемого ботами трафика в интернете впервые превысил человеческий. Боты теперь составляют более половины интернета, из них 3/4 — вредоносные.
В этой статье я хочу поделиться своим опытом настройки WSL для комфортной разработки, а также размышлениями о том, почему такой подход оказался для меня оптимальным. На это влияет несколько факторов.
Во-первых, иногда требуется специфический софт, который доступен только под Windows. Да, в других ОС могут быть аналоги, но зачастую они менее удобны или требуют дополнительной настройки.
Во-вторых, для разных проектов нужно разное окружение. WSL позволяет легко изолировать среды разработки, настраивая их под конкретные задачи или группы проектов. Это гораздо удобнее, чем держать несколько физических машин или постоянно переустанавливать систему.
Наконец, есть и субъективный фактор — привычка. Я с самого начала работал с Windows, и, несмотря на все преимущества Linux, полностью перестроить рабочий процесс оказалось сложно. WSL в этом плане — идеальный компромисс: Linux-окружение под рукой, но без необходимости отказываться от удобств Windows.
Ранее на Piccalilli Сэм Роуз поделился реальными примерами использования вспомогательных типов (utility types) TypeScript. Сегодня я хочу продолжить эту тему и поделиться несколькими продвинутыми возможностями TypeScript для работы с типами, которые, на мой взгляд, особенно полезны и применимы в реальных проектах.
Цель этой статьи — дать общее представление о каждой из возможностей, а также привести пример ее использования, чтобы вы могли лучше ориентироваться в том, какие инструменты можно использовать при создании типов.
Если вы когда-нибудь, запуская рабочую станцию с операционной системой Windows, обнаруживали, что ваш Full HD монитор показывает лишь изображение с разрешением не более 1024x768 и определяется как «Стандартный не Plug-n-Play монитор», и по какой-то причине вы не имеете возможности переключить монитор на другой видеовход, не поленитесь заглянуть под кат, где я растолкую, как «временно» выкрутиться минимальными усилиями.
Ещё несколько лет назад принципы SOLID были неотъемлемой частью собеседований для разработчиков любого уровня. Вопросы вроде «Расскажите, что означает каждая буква в SOLID» звучали так же часто, как «Что такое замыкание в JavaScript?». Это считалось своеобразной классикой, обязательной для понимания любого уважающего себя программиста.
Однако в последнее время, особенно во фронтенд-разработке и в мире React, акцент на SOLID заметно снизился и, например, вопросы о нем на собеседованиях встречаются всё реже. В первую очередь, это связано с переходом к функциональному стилю программирования, широким использованием хуков и отказом от классовых компонентов, что отодвигает принципы ООП на второй план.
Тем не менее, я убеждён, что принципы SOLID по-прежнему актуальны и полезны, даже в контексте функционального подхода. JavaScript и React не запрещают применять лучшие практики из ООП — наоборот, они предоставляют гибкость для использования различных парадигм.
В этой статье я хочу поделиться своим взглядом на то, как каждый из принципов SOLID может быть применен в разработке React-приложений. Здесь не будет революционных идей, особенно для опытных разработчиков, но, возможно, эта информация окажется полезной для начинающих разработчиков, стремящихся писать более качественный и поддерживаемый код.
Как известно, у Solid довольно скудная экосистема, поэтому для сложных проектов я беру React+MobX. Однако недавно подвернулся небольшой mobile-only проект, в котором разве что маскированные инпуты и кастомные селекты, которых для Solid предостаточно. При этом требования к размеру выходных файлов и перфомансу были высокие.
Очевидным решением посчитал взять Solid, заодно и сравнить его по всем параметрам (размер, перфоманс, возможности реактивности, удобство настройки) в реальном проекте. Никаких синтетических тестов с рендерингом больших таблиц и хранением в сторе нескольких мегабайт данных не будет, зато приведу замеры из реального приложения. Бонусом — репозиторий с универсальной архитектурой для Solid+Preact+React, где замена фреймворка (набора стейт‑менеджер + рендеринг UI) производится одной строчкой кода.
Я давний пользователь GitHub. Можно сказать, что на моих глазах он вырос из самобытного GIT-хостинга до внушительной экосистемы для разработчиков под патронажем само́й Microsoft, и по факту стал индустриальным стандартом.
Со временем я стал задаваться вопросом — можем ли мы в своей стране своими силами создать аналогичную экосистему? В которой нет проблем с платежами, не удаляют репозитории и аккаунты из-за поездки в Крым, где российские компании заказчики не опасаются хостить свои коммерческие проекты. В 2023 году я попробовал GitFlic, но не смог им пользоваться из-за нестабильной работы репозиториев. В 2025 году я решил попробовать GitVerse. Проекту уже больше года, и, скорее всего, он созрел для реального применения. В первую очередь меня интересует, есть ли у GitVerse потенциал стать не просто надёжным хостингом для GIT-репозиториев, а развиться в мощную экосистему, не просто повторить функционал GitHub в масштабе 1:43, а реализовать новое поколение индустриальных стандартов для совместного творчества разработчиков и других IT-специалистов.
Покрытие UI-тестами — вещь, о которой все говорят, но почти никто не измеряет. А если и измеряет, то по старинке, через Excel, TMS или на глаз. Это как считать шаги, не надевая шагомер.
ui-coverage-scenario-tool — это как шагомер, но для UI-тестов. Он показывает, с чем именно взаимодействуют ваши тесты, что осталось в тени, и главное — делает это автоматически. Без ручного труда, без вымышленных цифр, без «по ощущениям».
Это не очередной инструмент ради красивого дашборда. Это инструмент, который ставит зеркало перед вашим UI-покрытием — и показывает, есть ли там что-то, кроме отражения.
Привет, друзья!
В этой серии статей мы разбираем структуры данных и алгоритмы, представленные в этом замечательном репозитории. Это одиннадцатая часть серии.
Сегодня мы рассмотрим несколько простых, но интересных алгоритмов машинного обучения, а также один весьма любопытный статистический алгоритм.
Код, представленный в этой и других статьях серии, можно найти в этом репозитории.
Интересно? Тогда прошу под кат.
Привет, Хабр (и просто случайные читатели, зашедшие сюда в поисках истины или интересной статейки на пару минут)!
Так вышло, что последние полгода я провёл в тесных объятиях «Личного кабинета сотрудника» на Элементе — новом языке программирования от 1С. За это время я успел его изучить, полюбить, возненавидеть, снова полюбить и, наконец, написать эту статью, чтобы поделиться своими впечатлениями, страданиями и неожиданными открытиями.
Особенности Fast Data Grid:
— Невероятно быстрый
— Многопоточный
— Всего 523 строчки кода
— Нет зависимостей
— Vanilla JavaScript
Попробуйте скролл и поиск по 1 000 000 строк — Fast Data Grid.
В статье расскажу про работу с потоками.
До недавнего времени программный доступ к куки в браузере осуществлялся через API document.cookie — простой строковый геттер/сеттер. Для получения одного файла куки приходилось разбирать всю строку вручную и преобразовывать ее в удобный формат. А чтобы записать куки, нужно было сначала сформировать структурированные данные, затем сериализовать их в строку и только после этого присвоить значение document.cookie. Разработчики часто используют популярные библиотеки, например js-cookie, которые делают работу с куки гораздо удобнее.
19 марта 2025 года вышла стабильная версия Valibot — библиотеки для валидации данных в JavaScript/TypeScript. Разработанная как альтернатива популярному Zod, она сочетает минималистичный дизайн с мощными возможностями.
В этой статье мы сравним Valibot и Zod по трём ключевым параметрам: синтаксису API, размеру библиотеки и скорости работы. Вы узнаете, чем эти решения отличаются друг от друга и почему стоит использовать специализированные инструменты валидации входящих данных.
Привет всем! Меня зовут Антон Галич, я фронтенд-инженер в департаменте разработки Analytics Platform в Авито. В этой статье я рассказываю историю о том, как мы перевели аналитику для внутренних сервисов компании на нашу собственную платформу, отказавшись от стороннего решения Amplitude.
JetBrains зарелизил новую версию своего AI-ассистента и вместе с ним Junie - автономного нейросетевого агента-программиста, которому можно поручать небольшие рабочие задачи.
Буквально вчера я получил к нему доступ и не смог не воспользоваться возможностью. Я даже не представлял...
"JavaScript отстой, потому что '0' == 0!"
Да, эта часть JavaScript действительно ужасна, но сегодня в любом проекте есть линтер, который тут же заворчит на вас за такой код.
Вместо этого я хочу поговорить о более странных особенностях JavaScript — о таких, которые гораздо более коварные, чем эта ☝️ - о вещах, которые вы не найдете ни на r/ProgrammerHumor, ни в обычном учебнике по JavaScript.
Все эти странности могут возникнуть в любом окружении JavaScript/ECMAScript (будь то браузер, Node.js и т.д.), с режимом use strict или без него. (А если вы работаете над легаси-проектами без строгого режима, вам следует срочно подумать о смене работодателя).
В этой статье мы проведём подробный анализ современных практик frontend-разработки, сравним состояние React и Vue 5 лет назад и на текущий момент, а также попробуем спрогнозировать их перспективность в обозримом будущем с учётом развития LLM моделей и AI агентов. Посмотрим их экосистемы (Next.js и Nuxt, Redux и Pinia), использование в бэкенде, популярность решений в энтерпрайзе, а так же понимание разработчиками и LLM моделями.
Привет.
Представьте: вы запилили нейросеть, которая определяет котиков на фото с точностью 99.9% (оставшиеся 0.1% — это когда хомяк притворяется котом). Воодушевлённый результатом, бежите к руководству — а там оказывается, что:
