Привет, Хабр! Меня зовут Паша, я разработчик Gramax — open source-платформы для управления технической документацией в подходе Docs as Code.
В этой статья я расскажу, как и для чего мы интегрировали Git в браузер, какие технологии использовали и какие технические решения приняли. А если подробнее: почему отказались от IsomorphicGit в пользу libgit2, каким образом мы собрали его под WebAssembly, как он работает с файлами и зачем вообще все это было нужно.
Я потратил месяц на создание веб-сайта в Docker и теперь готов поделиться ужасными историями.
У меня есть проблема.
Мой веб-сайт (на котором была опубликована эта статья) в основном обслуживается одним двоичным файлом Rust. Он стал слишком длинным. Каждый раз, когда мне нужно внести изменение, я должен:
Собрать новую статически компонуемую библиотеку (с --target=x86_64-unknown-linux-musl)
1. Скопировать её на сервер
2. Перезапустить веб-сайт
Ситуация, мягко говоря, неидеальная.
Поэтому мне бы хотелось перейти к развёртыванию веб-сайта при помощи контейнеров (будь то Docker, Kubernetes или что-то иное), в духе подавляющего большинства ПО, разворачиваемого в последний десяток лет.
Единственная проблема заключается в том, что реализовать быстрые сборки Rust с Docker не так уж просто.
React остаётся одним из самых популярных инструментов для фронтенд-разработки. Библиотеки UI-компонентов для React значительно развились, предоставляя разработчикам инструменты для создания современных, эффективных и доступных интерфейсов. В этой статье рассмотрим топовые библиотеки UI-компонентов для React, которые стали популярными в 2025 году, и их ключевые особенности.
Как часто оценка по задаче совпадает с реальными трудозатратами?
Умение точно оценить объём работ спасает от переработок, напряжённой обстановки на проекте, поддерживает доверительные отношения в команде и показывает вас с хорошей стороны перед заказчиком.
Но интуитивные и ставшие традиционными способы оценки задач дают низкую точность. Пора взять на вооружение другой способ, дающий 90+% точность в оценке.
На старте проекта обычно встает вопрос о выборе готовой ui-библиотеки для решения шаблонных задач, таких как создание форм, инпутов, кнопок и других компонентов. Количество готовых ui-библиотек для React так стремительно растет, что уже сложно остановить свой выбор на какой либо из них. Зато в таком разнообразии каждый может найти библиотеку, подходящую под его задачи. В этой статье хочется рассказать о фреймворке Steroids, который разработан и поддерживается в нашей компании.
Изначально мы не планировали создавать фреймворк, а просто собирали удачные решения рутинных задач. Получился набор полезных утилит и мини-библиотек, который позволял нам работать быстрее. Мы постепенно добавляли в него новые элементы, он рос и видоизменялся, и в итоге вырос в полноценный фреймворк Steroids.
Всем привет! Меня зовут Александр Григоренко, я фронтенд-разработчик, и сегодня хочу поговорить о вопросах этики в интерфейсах и ценностях в разработке на примере одного моего недавнего собеседования. Это история о том, почему я отказался внедрять тёмные паттерны и не получил оффер на фронтенд-лида.
Признаемся честно: слово «тестирование» вызывает у многих разработчиков примерно такую же радость, как поход к стоматологу. Большинство морщится и думает: «Опять эти тесты... Лучше бы новую фичу запилил!» И я вас прекрасно понимаю — сам когда-то был в лагере скептиков.
Но после нескольких лет руководства командой фронтенда, десятков ночных дебагов и сотен часов, потраченных на поиск неуловимых багов, я пришёл к неожиданному выводу: качественные юнит-тесты — это не якорь, замедляющий разработку, а реактивный двигатель, ускоряющий её.
В этой статье я расскажу, почему наша команда делает ставку именно на юнит-тесты, и как они могут превратить вашу разработку из хаотичного забега с препятствиями в уверенный марафон с чёткими ориентирами.
Привет, Хабр. На связи Екатерина Саяпина, Product Owner платформы МТС Exolve. В этом материале я расскажу, как автоматически добавить в CRM оптимальное время для общения с клиентами. В рамках этого кейса я покажу настройку нашей платформы и получение информации из нее в Битрикс24.
Потребность поделиться диалогом из ChatGPT рано или поздно возникает. Однако нативного экспорта в удобный формат вроде PDF или Markdown платформа не предлагает. Копипаст — плохое решение: таблицы разваливаются, форматирование кода съезжает, а изображения просто пропадают. Мы решили эту задачу для себя, написав собственный конвертер. Оказалось, что он полезен не только нам.
Так появился pdfchatgpt.com. Принцип простой: копируешь share-ссылку и диалога с ChatGPT, добавляешь pdf в начало ссылки и получаешь готовый файл. Также можно перейти на pdfchatgpt.com и просто вставить ссылку на диалог.
В этой статье — технический разбор нашего решения: от простого скрипта с puppeteer до асинхронной системы с очередями. Делимся опытом для тех, кто решает схожие задачи.
В силу личной специфики (я чаще работаю не над веб-страницами, а над интерфейсами для десктопных и мобильных приложений, которые пишу на HTML/CSS), я долго избегал рабочие процессы сложнее, чем «отредактировал CSS-файл и сохранил его», и открыл для себя CSS-препроцессинг довольно поздно, но… В наши дни он, в общем-то, ничуть не устарел, и актуален не меньше, чем раньше. Так что, если вы пишете CSS (а не генерируете его) для чего угодно (SPA, приложения, лендинги, веб-аппы и т.д.), но до сих пор не пользуетесь LESS или SASS — приглашаю под кат, где я, стараясь не опускаться до уровня «очередной-пересказ-учебника», немного расскажу о принципах LESS, инструментах, его текущем состоянии и поделюсь своими техниками и приёмами (с примерами). А если вы не пишете CSS, но знакомы с традиционными языками программирования, всё равно добро пожаловать: я провожу параллели между ними и LESS, а заодно рассказываю об очень полезных принципах проектирования от Алана Кея.
На Хабре иногда слышны жалобы на деградацию веб-дизайна и интерфейсов для более «примитивных» юзеров, дерьмофикацию хостингов кода, ожирение софта и прочие признаки ухудшения мира. Кажется, что каждый полезный сайт в интернете со временем превращается в шлак с бесконечным скроллингом, дофаминовой иглой и монетизацией.
Но у этой деградации есть естественная причина, и она очень простая. Дело в том, что большинству людей по большому счёту наплевать.
Привет, Хабр! Меня зовут Роман Мельник, я фронтенд-разработчик во «ВКонтакте для Бизнеса». Наша команда создаёт инструменты, которые помогают владельцам сообществ управлять и развивать свои проекты. Сегодня я расскажу про Dependency Injection (DI) через библиотеку Tsyringe.
Почему это важно? Крупные проекты сталкиваются со следующими проблемами: разрастающимся глобальным стором, сложностями тестирования, масштабирования и переиспользования кода. Внедрение зависимостей помогает решить эти вопросы, делая код гибким и управляемым. На практике это выглядит гораздо интереснее. Давайте разберёмся!
Начнём с архитектурных принципов и паттернов.
Однажды я столкнулся с проблемой, когда почти потерял коммерчески успешный пет-проект из-за устаревших резервных копий БД (ещё до того, как он стал коммерчески неуспешным). При этом, даже после частичного восстановления, все-таки потерял ~30% прибыли от проекта, много нервов и времени.
Это подтолкнуло меня на разработку своего открытого инструмента для бекапа PostgreSQL. С разными хранилищами, уведомлениями при сбоях и health check'ом. Собственно, о том, как я потерял деньги и затем разработал проект — хочу рассказать в статье ниже.
Недавно работал над хобби-проектом, который описал в другой своей статье. В процессе его реализации у меня возникло желание чиркануть пару абзацев о том, почему React — отстой, но в итоге я не смог удержаться и решил высказаться по полной…
Так что вот она полноценная статья, ещё больше той, из которой она родилась. Здесь я подробно опишу все проблемы React и поясню, почему это может не быть виной разработчиков.
Сегодня я хочу поделиться с вами решением, которое позволит вам реализовать подписание PDF-документов электронной подписью и их визуализацию прямо на вашем Laravel сервере.
Мы никогда не скрывали, что используем ИИ в своей работе. Более того, считаем, что такие инструменты, как Cursor – это настоящее спасение для разработчиков. Cursor не только ускоряет рутину, но и помогает поддерживать крутое качество кода (если правильно им пользоваться, конечно же), а главное – снимает с команды кучу головной боли, связанной с повторяющимися задачами.
В то же время у нас есть и собственная гордость – open source фреймворк Admiral, которую мы развиваем для быстрой и удобной разработки административных панелей. В нем уже реализовано множество готовых решений: бери нужные, кастомизируй и запускай свой проект без лишних усилий.
Недавно нам пришла идея объединить два продукта. Так мы интегрировали систему правил .cursor/rules прямо в Admiral, чтобы создавать админки можно еще быстрее. Например, теперь не нужно каждый раз перепроверять, правильно ли оформлены CRUD-страницы, корректно ли используются компоненты или соблюдаются стандарты при написании хуков. Все эти моменты изначально заданы в правилах, и Cursor подскажет, если что-то идет не так. Это экономит время, снижает количество ошибок и позволяет сосредоточиться на действительно важных задачах.
В результате, мы не просто оптимизировали и ускорили процесс, а получили готовые инструкции для ИИ при работе с Admiral, которые помогают поддерживать высокое качество кода на всех наших проектах благодаря Cursor. Расскажем, как теперь работает автоматизация и какие преимущества от нашего фреймворка можете получить и вы.
Эта статья описывает изощренную технику обхода Content Security Policy (CSP) на основе nonce-значений через эксплуатацию механизмов кеширования браузера. Автор демонстрирует, как комбинация CSS-инъекций, CSRF-атак и особенностей работы bfcache и дискового кеша может привести к выполнению произвольного JavaScript-кода даже при наличии строгой CSP.
На нескольких проектах я сталкивался с ситуацией, когда есть Kubernetes с разными окружениями типа dev, stage, prod и т. д.
Код сервисов в эти самые окружения попадает в процессе CI/CD: то есть мы мержим какую‑то ветку с разрабатываемой фичей или исправлением бага в ветку, которая «привязана» к окружению и дальше наш код деплоится в кластер. Думаю, для многих — это уже стандартная история.
Давайте представим, что нужно сделать задачу, относящуюся к какому‑нибудь микросервису, эта задача подразумевает запрос по сети к другому микросервису, а тот, в свою очередь, посылает запрос к еще другим микросервисам. Как быть, когда мы хотим, чтобы нам были доступны данные из других микросервисов, чтобы протестировать то, что мы сделали не в тестах с моками, а в условиях, похожих на «боевые». Тут самым очевидным, как мне кажется, является разворачивание локально микросервиса, код которого мы «ковыряем» и проброс портов до целевого микросервиса в dev кластере (или в другом кластере, предназначенным для тестирования), например:
Делюсь опытом как я сделал интерактивную карту Республики Коми: от QGIS и D3.js до графиков и API Wikidata. Карта визуализирует социально‑экономические показатели районов и населённых пунктов, поддерживает масштабирование, позволяет переключать слои, выбирать тёмную и светлую темы, а также получать справочную информацию об объектах.
Мой веб-сайт — это путешествие по волнам памяти. Я не хочу сказать, что нужно прекратить современную веб-разработку. На моём веб-сайте используются технологии, которые в обсуждаемые на нём времена были ещё недоступны. Он работает на мобильных (протестировано в Firefox для Android), отсутствует только фоновое изображение.
Свой первый веб-сайт я создал где-то в начале 2000-х, и как и большинство веб-сайтов того времени, он был очень простым. Это неудивительно, учитывая то, что большинство (включая и меня) писали такие веб-сайты в Блокноте, что накладывало ограничения на сложность. Можно было выбрать или Блокнот, или какой-то из WYSIWYG-редакторов, которые привязывали к себе тем, что сгенерированный ими HTML было бы совершенно невозможно поддерживать без них, а если вносить изменения вручную, то это вполне могло поломать всё в редакторе.
Тогда не было iPhone, почти не было SEO, а JavaScript, как и CSS, использовать было совсем необязательно.
Цветопередача первых ЖК-экранов была плохой, поэтому лучше было выбирать цветовую схему с высокой контрастностью.
Оптимальным разрешением было 1024×768 (или 1280×1024, если вы могли себе это позволить), однако стоило и обеспечить работоспособность размеров окна и панелей в 800×600. Вам же не нужно, чтобы контент выходил за левый или правый край экрана?
