Веб-разработка *

Всем доброго времени суток. Давно я что-то ничего не писал, и вот созрел. Предлагаю сегодня поговорить о ui-системе. Зачем она нужна, когда она нужна, что дает, какие минусы имеет и вообще стоит ли ввязываться в это блуд.  Я часто слышу на разных конференциях, что панацея от всех болезней в бизнесе  —  это наличие дизайн-системы (ui-системы). Что, как только вы достигаете ее, то сроки сокращаются в 100500 раз. Что разработчики не хотят открутить голову дизайнерам, и, наоборот, что качество продукта возноситься до небес, и еще много всего восхитительного об этой сущности. Но так ли все это ? Или это просто розовые очки, которые застилают глаза всех причастных к созданию ui-системы в компании и побочка от постоянных нервных срывов, скандалов, поиска компромиссов и просто выгорания? В этой статье я постарался разобраться, а стоит ли игра свеч или как в анекдоте про нюансы. 

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

UI - kit — это полный набор элементов и компонентов, необходимый для сборки большого однородного продукта. Он включает различные кнопки, иконки, поля для ввода данных и т. д. и позволяет сохранять узнаваемость продукта и доверие пользователей. Так мне сказал поисковик, я спорить не стал.

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

Хабр, я снова пришёл к вам с практическими советами про доступность вместе с Ильёй. Мы показываем, как HTML и CSS могут улучшить или ухудшить её. Напоминаю, что Илья — мой незрячий знакомый, который помогает мне найти наши косяки в вёрстке.

Сегодня мы рассмотрим следующие аспекты:

• Почему в наших дизайн-системах и библиотеках есть сломанные нестандартные радиокнопки;
• Мой способ отказаться от ссылки для изображения с сохранением интерактивности;
• Дублирование стилей при наведении для фокуса вводит меня в ступор;
• Можно ли скрыть кнопку с помощью атрибута disabled от скринридера.

Давайте начнём!

Зачастую full stack (и не только) проекты создаются без функциональных тестов.

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

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

Проблема сложности тестов в подобной ситуации кроется в том, что на этапе проектирования продукта никто не думал о его тестировании и необходимости сделать его пригодным для тестирования (автоматического).

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

В этой части статьи я на примере покажу, как можно спроектировать простое веб-приложение, используя функциональное тестирование, и имплементировать веб-приложение.

Рассмотрим структуру плагинов, основные объекты, используемые при их разработке, хуки этих объектов и их виды.

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

React 19 на подходе. Команда React анонсировала предрелизную версию React 19 в апреле. Это крупное обновление принесет с собой ряд улучшений и новых паттернов, нацеленных на повышение производительности, удобство использования и опыта разработки.

Многие из этих возможностей были представлены в экспериментальном режиме в React 18, но в React 19 они станут стабильными. Давайте подготовимся к этому обновлению.

В мире разработки ПО поддержка высокого уровня наблюдаемости (observability) для приложений с архитектурой, управляемой событиями (event-driven architecture, EDA) стало критически важным. Сложность таких систем, связанных с обработкой огромных объемов данных в режиме реального времени, требует надежных инструментов для мониторинга, отладки и анализа. Однако традиционные методы, использующие логи и метрики, часто оказываются недостаточными, когда необходимо глубоко понять взаимодействие между различными компонентами системы и выявить узкие места.

Именно с этой проблемой мы столкнулись в нашей команде, поэтому я, Дмитрий Титаренко (QA-инженер в компании TAGES), решил поделится найденным решением в статье на Хабр. Надеюсь, что будет полезно!

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

В прошлом непрерывное интеграционное тестирование было с нами не всегда, в отличие от обычного тестирования. По моим наблюдениям, CI — это результат того, что тестирование всё больше ускоряется. Разберёмся, как это произошло и как тестирование будет ускоряться дальше.

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

Кому предложат ЗП 200-, а кому 400+? Собеседование расставит всё на свои места.

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

Случается, ты просыпаешься и осознаешь: так больше продолжаться не может и нужно что‑то менять. Разные кодовые базы, избыточное легаси и нестабильность мешают пользователям получать удовольствие от общения в твоем приложении. И эта мысль подводит тебя к развилке: один путь ведет к сложному и долгому рефакторингу легаси за почти 10 лет, второй к не менее долгому, а, порой, более сложному процессу переписывания с 0. Но какой бы путь ты ни выбрал, в любом случае начинаешь испытывать азарт — предстоит большая Задача (именно с большой буквы).

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

Привет, Хабр. Я продолжаю делиться «косяками» CSS, которые могут сбить нас с толку. Мне не нравится, что многие плюются от него. Конечно, не без оснований. Я их понимаю, потому что тоже плевался.

Только мне нравится CSS. Хоть и потратил множество часов на изучение неочевидных моментов, я не хочу, чтобы у языка была слава «костыля». Подумав, как помочь другим меньше мучиться, я собираю и объясняю неочевидности CSS.

До лета 2023 года перед разработчиками Точка.Нетворк стояла проблема: CJM становился сложным, и это затрудняло работу над продуктом. В итоге мы придумали решение — полностью отказались от веба и сосредоточили развитие платформы только в Mini Apps от Телеграма. Без этого было бы невозможно развивать продукт дальше.

В статье расскажу, как и почему мы отказались от веб-версии Точка.Нетворк — локального сообщества предпринимателей — и переместились в Телеграм.

Что мы поняли, запустив простой конвертер картинок за 1 месяц в США. И как заработали 100 000 рублей за первые 3 месяца, хотя вокруг куча бесплатных аналогов.

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

Перед чтением данной статьи, настоятельно рекомендую ознакомиться с данной статьей, по теме kafka (Kafka за 20 минут. Ментальная модель и как с ней работать)

Пример реализации можно найти тут...

Рассказываю что можно сделать на одном только голом JDK. Это старое и ныне почти забытое искусство разработки без внешних библиотек и фреймворков. Работать будем «как в былинные времена» — киркой и лопатой голыми руками и немного мозгом.

Привет, Хабр!

Идея статьи появилась, когда я начал повсюду замечать якобы подтверждения мифа, что «программирование — это просто»‬‬.

В новостях «восьмилетняя девочка, которая второй раз в жизни занимается программированием, наклепала чат-бота за 45 минут»‬ (ага, да!).

Курсы предлагают мне за 10 месяцев с нуля стать миддл+ (ага, да!).

Но я-то знаю, как оно на самом деле. Мы, программисты, обычно решаем проблемы и двигаемся дальше, но я решил запротоколировать всё как есть, и в течение пары месяцев скрупулёзно записывал всю ту хрень, что происходила со мной и моими коллегами, чтобы показать программирование без прикрас. Поехали!

Окончание статьи по быстрой разработке гипермедиа-ориентированного веб-приложения с HTMX 2.0.

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

В статье будет использоваться библиотека Htmx.js вместе с устаревшей серверной платформой ASP.NET MVC 5.

Продолжение статьи по быстрой разработке гипермедиа-ориентированного веб-приложения с HTMX 2.0.

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

В статье будет использоваться библиотека Htmx.js вместе с устаревшей серверной платформой ASP.NET MVC 5.

Разработчики часто воспринимают трассировку как нечто загадочное, и OpenTelemetry — не исключение. Она может казаться еще более сложной из‑за множества новых концепций, с которыми сталкиваешься в базовых примерах.

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

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

На самом деле, трассировка гораздо проще, чем кажется.