JavaScript *

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

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

Давайте посмотрим, как я заморачивался с вещами, которые в итоге только усложнили задачу, и что из этого получилось.

Представьте ситуацию: ваша команда закончила интеграцию с API, все протестировала и подготовила релиз. А тут внезапно серверная команда меняет формат ответа. Фронтенд падает, QA злится, пользователи недовольны. Приходится вручную переписывать валидации, искать баги и терять дни, чтобы всё починить. 

Как автоматически синхронизировать работу между бэкэндом и фронтендом? А между дизайном и фронтендом? Использовать генератор кода валидации! Написание своего решения поможет понять бизнес-логику проекта и создать валидаторы, которые максимально отвечают вашим требованиям. А реализация проще, чем кажется на первый взгляд – покажу это в статье на примере создания кастомного генератора на нашем проекте. 

В первую очередь статья будет полезна фронтенд-разработчикам и командам, работающим над сложными веб-приложениями, особенно тем, кто активно взаимодействует с API, описанными через OpenAPI. 

Внедрение нескольких сервисов с помощью одного токена — достаточно удобная механика в фреймворке Angular. Однако, можно столкнуться с неприятностью, что во всех местах, где нужно получить данный сервис, придётся как-то выбирать нужный инстанс из массива. Кто-то делает это напрямую, через метод массива find, кто-то регистрирует сервис-менеджер, который умеет возвращать нужный инстанс, однако оба варианта рождают неприятный бойлерплейт. В этой статье разберём подход по удобной и продвинутой регистрации multi-сервисов.

Brisa — это современный веб-фреймворк, который сочетает мощь серверного рендеринга и удобство клиентских компонентов. Он позволяет создавать быстрые, легкие и высокопроизводительные веб-приложения, минимизируя объем JavaScript, отправляемого в браузер. Поддержка веб-компонентов, гибкая интернационализация и возможность кроссплатформенной разработки с помощью Tauri делают Brisa универсальным инструментом для веб-разработчиков.

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

Большое количество специалистов в области IT используют переводчики текста в своей работе, и я тому не исключение. Достаточно часто в вакансиях Системного администратора можно встретить требуемый навык - "чтение технической документации на английском языке", но, не всегда такая документация может быть очевидной в полной мере, даже имея базовый уровень английского языка, и как мне кажется, тут нечему стесняется. Для перевода текста чаще всего используется браузер, а также десктопные приложения, я же расскажу про альтернативу таким решениям, для перевода текста прямо в консоли Linux или Windows.

Приходилось ли вам работать с потоками в Node.js?

Когда я впервые столкнулся с потоками, я, мягко говоря, оказался в растерянности. Эта концепция была совершенно новой для меня. Я полагал, что смогу обойтись и без них, но вскоре понял, что в Node.js они повсюду. Даже такие ключевые модули, как fs и http, используют потоки "под капотом". Поэтому мне пришлось погрузиться в изучение этой темы и разобраться в том, как потоки работают.

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

На днях столкнулся с интересным вопросом. Что быстрее element.style.setProperty(свойство, значение)или element.setAttribute('style', 'свойство: значение')? На первый взгляд ответ кажется очевидным. Логика говорит нам, что setProperty должен устанавливать значение сразу в CSSOM, тогда как setAttributeвыставляет сначала атрибут style и уже потом значение атрибута будет разобрано в CSSOM. Таким образом, setProperty должен быть быстрее. Но действительно ли всё так однозначно? Давайте разбираться.

Начнем с того, что немного освежим мат. часть. Мы знаем, что стили описываются с помощью языка CSS. Получив строковое описание стилей на языке CSS, браузер разбирает его и составляет объект CSSOM. Интерфейс этого объекта представлен спецификацией https://www.w3.org/TR/cssom-1. Он следует принципам каскадности и наследования, изложенным в https://www.w3.org/TR/css-cascade-4.

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

Набор свойств для элемента собирается в правила CSSRule. Правила бывают разных типов. Наиболее популярный тип - CSSStyleRule, определяющий свойства элемента. Такое правило начинается с указания одного из валидных селекторов и последующих фигурных скобок с набором свойств и значений <selector>: { ... }Имеются и другие типы правил, например CSSFontFaceRule, описывающий параметры подключаемого шрифта @font-face { ... }, CSSMediaRule - @media { ... } и др. Полный список в спецификации https://www.w3.org/TR/cssom-1/#css-rules.

Привет! Меня зовут Никита, и я тружусь в команде фронтенда платформы в Ozon. Платформа поставляет инструменты для создания и поддержки JS-проектов. В компании в настоящее время более 500 таких проектов. Мы прилагаем максимум усилий, чтобы разработчикам всех проектов было одинаково приятно работать с нашими инструментами.

Также мы предоставляем инструменты для создания JS-библиотек. И в этой статье я расскажу о том, как мы советуем создавать npm-пакеты. Отмечу, что это не касается UIKit-пакетов, — для них требуется довольно специфичный инструментарий, который заслуживает отдельной статьи.

Недавно у нас проходила актуализация инструментов, которая включала обновление версий Node, TypeScript и прочего. И мы обнаружили, что сейчас правильно упаковать библиотеку ой как нелегко, особенно с началом активной фазы по отказу от CommonJS. В идеале очень хочется иметь инструмент, который бы просто работал. В open-source есть парочка вариантов (unbuild, pkgroll, dnt), но выбрать подходящий мы пока не смогли. А написать свой — довольно трудоёмкая задача. В будущем мы обязательно обзаведёмся таким инструментом, а пока просто погрузились в тему и подготовили для наших разработчиков рекомендованные сетапы, которыми сейчас поделимся и с вами.

Начнем с небольшой истории. Как-то раз я с размахом накинулся на проект — в духе нынешних фреймворков всё было обложено компонентами, декларативный стиль царил, все шло идеально… ну почти. Дошел я, значит, до нужды контролировать DOM-узлы напрямую. И что вы думаете? Прямого доступа нет, React закрыл от меня этот мир, сидит и ухмыляется: мол, мы тут за производительность боремся, зачем тебе что-то трогать руками?

Но мы не из тех, кто сдаётся, верно? React предлагает своё решение — рефы, и именно о них сегодня пойдет речь.

Как избежать типичные ошибки при внедрении микрофронтов и какие инструменты упрощают жизнь разработчикам.

Рассмотрим плохие примеры разделение кода приложения, т.е. когда "архитектор" или лид проекта, не умеют микрофронты готовить. А разработчикам нужно с этим жить.

Ты приходишь в новую компанию, всё кажется крутым: светлый офис, дружелюбная команда, проекты мечты. И тут начинается...

Сборник фронтендерских болей.

Почитав эту статью: https://habr.com/ru/articles/684858 (особенно заинтересовали Waypoints) и обзаведясь коптером DJI, пришел к выводу - да, классно, здорово, но не удобно. Если стоит задача облететь и снять видео поля площадью пару десятков гектаров, то ставить ручками точки маршрута не очень удобно. Занимает много времени.
///

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

Предположим, что у нас есть приложение Next.js, данные которого хранятся в Postgres, и мы хотим запустить его в продакшн, но не хотим использовать готовую инфраструктуру Vercel. Что делать? Создать собственную инфраструктуру. К счастью, сделать это не так уж и сложно.

Основные элементы нашей системы:

• приложение, демонстрирующее несколько мощных возможностей Next.js 15
• база данных Postgres для хранения списка задач, создаваемых/удаляемых в приложении
• задача Cron для удаления из БД всех задач каждые 10 мин
• приложение, БД и задача Cron функционируют в контейнерах Docker
• контейнеры запускаются с помощью Docker Compose на облачном сервере Ubuntu
• сервер Nginx для перенаправления запросов HTTP (обратного проксирования)
• домен, привязанный к серверу
• Certbot для получения сертификата SSL из Let's Encrypt и его установки для домена

Демо приложения.

Интересно? Тогда прошу под кат.

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

Теперь к теме: Копаясь в недрах BAS я столкнулся с такой ситуацией, что многие разработчики, которые занимаются разработкой скриптов по BAS (смешно получилось — разработчики занимаются разработкой) идеализируют распознавание капчи кликами.

Вероятно надо пояснить — речь идет про картинные и визуальные капчи (те, где нужно выбирать изображения на экране или кликать по картинкам (иконкам) в нужном порядке. Примеры картинных и визуальных капч — reCAPTCHA V2, hCaptcha, GeeTest CAPTCHA, Rotate CAPTCHA.

Так вот, эти капчи можно решить двумя способами — метод токенов и метод кликов. 

Когда автор Адди Османи написал первую версию книги Learning JavaScript Design Patterns в 2012 году, JavaScript еще начинал завоевывать популярность как язык для создания сложных веб-приложений. С тех пор JavaScript претерпел значительные изменения и превратился в один из самых популярных языков программирования, используемый для разработки от простых скриптов до сложных веб-приложений. Если вы совершенствуетесь в JavaScript — не пропустите второе издание этой книги в переводе от издательства БХВ Петербург.

Здравствуйте. Сегодня обсудим безопасность, безопасную разработку и как получать документы, подтверждающие, что ваш продукт безопасен. Возникает резонный вопрос: зачем это вообще нужно? Ну, так как текущие реалии диктуют свои условия. И речь даже не о сложившейся геополитической ситуации в мире. А о том, что все больше и больше желающих получить то, что им не принадлежит. Будь то персональные данные, деньги, имущество, аккаунты игр (да-да, это тоже стоит денег), и в общем всё, что не прибито гвоздями.

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

Следует помнить, что не всем подходит просто сказать: “У нас всё безопасно. Доверяйте нам!” Может, кому-то открою тайну, но бизнес так не работает. Бизнес хочет подтверждения безопасности. А это значит, получения сертификата соответствия в надлежащих органах, что само по себе отдельный вид девиации, но об этом позже.

Тема большая, неоднозначная. Постараюсь захватить как можно меньше от других частей систем (бек, тестирования, БД и т.д.). Но напоминаю, что безопасность — это комплексное мероприятие, в чем вы убедитесь позже, а сейчас по пунктам.

🛠️ Почему мы выбрали gRPC вместо tRPC

При разработке крупных приложений на основе Domain Driven Design переход от монолита к микросервисам требует сохранения принципов ООП для поддержки кода. gRPC предоставляет ряд преимуществ перед tRPC: возможность использования Golang для высоконагруженных компонентов, отказ от паттерна роутера в пользу прямых вызовов микросервисов, эффективную статическую типизацию через интерфейсы, децентрализованную архитектуру с возможностью частичного перезапуска микросервисов и автоматический мап методов классов без boilerplate кода.

Телеграм сейчас является основным источником контента для многих. У Хабра тоже есть канал t.me/habr_com, его читает более 100 000 подписчиков. Кроме этого, о технологиях есть тысячи других каналов. Сколько их? Какая у них аудитория? Где найти данные? Разберемся в статье.

Стало интересно сделать анализ всех телеграм каналов: подписчики, рейтинги, частота статей, процент репостов, процент рекламы и т.д., поэтому посмотрел как можно достать данные. Забегая вперёд, скажу что собрал датасет со всеми телеграм каналами, в том числе и каналы с одним подписчиком. Их около 2 млн по всем гео. Какого-то сервиса, где можно сразу быстро и просто взять все каналы и набор метрик по ним, я не нашел, поэтому посмотрел что есть из готовых данных.

Существуют агрегаторы данных телеграм типа tgstat (https://tgstat.ru/). Один из способов - парсинг данных агрегаторов. Варианты с ботами, виртуальными аккаунтами показались более затратными, поэтому парсил несколько агрегаторов.

Итак, посмотрел ряд агрегаторов, взял на пробу три датасемпла. Самым адекватным показался семпл tgstat, поэтому, остановился на нем. В сервисе надо регистрироваться по телеграм аккаунту. Контент динамический, то есть, подгружается по клику. В парсинге всех данных не было смысла - важно было посмотреть что получится на семплах. Спарсил несколько категорий RU домена.

Сегодня расскажу про tech каналы с этой страницы (https://tgstat.ru/tech). Это каналы категориии 'Технологии', Россия. Периодически читаю каналы этой категории, ну и канал Хабра там есть. Поэтому, реллевантно будет здесь расказать именно о технологических каналах.

Почему я не готовлюсь к алгоритмическому интервью

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

Для работы с проектами существует куча редакторов кода и IDE (VSCode, NeoVim, SublimeText, WebStorm и т.д.). В данный момент наиболее популярны VSCode и Webstorm и у каждого есть свои плюсы и минусы. Webstorm является примером прекрасного IDE от компании JetBrains, где многие вспомогательные модули идут “из коробки”. К сожалению, сейчас нет возможности легально получить доступ к этому продукту гражданам России, поэтому многим приходится искать альтернативу. Такой альтернативой вполне может стать Visual Studio Code от компании Microsoft, который имеет открытую кодовую базу, полностью бесплатный и гибко настраиваемый под ваши нужды. В данной статье мы рассмотрим пример настройки рабочего пространства VSCode для комфортной работы с нашими проектами. Я покажу вам, какими расширениями я пользуюсь для лучшего удобства и продуктивности. Эти расширения я использую давно и они хорошо зарекомендовали себя, но возможно некоторые из них могут не подойти под ваш стиль работы и написания кода. Итак, начнем!