Бэкенд

Обычно разработчики пользуются локальными IDE вроде VS Code или IDE от JetBrains со своим набором плагинов, настроек и собранным под себя окружением. Иногда — удалённой машиной. Но есть третий вариант, который пока многим непривычен и потому вызывает настороженность, — Cloud IDE, или CDE. 

Закономерно возникают вопросы: а точно ли мои данные в безопасности? Есть ли в CDE все нужные компоненты для полноценной работы или это просто способ быстро заглянуть в код?

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

На сайте в пару тысяч страниц это работает. На сайте с семизначным инвентарём URL — нет. Полный краул упирается в память, диск, сетевые таймауты, rate limit, JavaScript-рендеринг, дубли, параметры, бесконечные фасеты и в то, что через двое суток вы получаете таблицу на миллионы строк, которую всё равно придётся сегментировать с нуля.

Поэтому я начинаю не с краулера. Я начинаю с sitemap.

В статье показываю sitemap-first подход: как скачать sitemap graph, превратить URL в датасет, разобрать слаги на смысловые группы, сматчить паттерны со спросом, найти пустые посадочные, проверить рендеринг и потом подтвердить гипотезы через GSC, Яндекс.Вебмастер, Метрику и серверные логи.

Привет, Хабр! В B2C-продажах — недвижимость, страхование, медицина — каждые 30 секунд задержки с первым звонком стоят процентов конверсии. Покупатель оставляет контакты в момент максимального интереса. Но импульс гаснет быстрее, чем менеджер успевает открыть CRM и набрать номер.

Почта и СМС не спасают: письмо пропустят, сообщение не заменит живого разговора. А ручной перенос данных из квиза в базу и набор номера — это десятки потерянных секунд на каждой заявке.

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

Оказывается, да. Мы сделали сервис, который соединяет квиз, CRM и телефонию в один сценарий. Он принимает вебхук от Марквиз, создает лид в amoCRM и запускает автоматический звонок через МТС Exolve. После разговора сервис получает событие от Exolve и сохраняет результат в CRM.

Block (Square, Cash App, Tidal) рассказала, как у неё устроена разработка: внутренний Builderbot делает 200 000+ операций в день, мержит ~1500 PR в неделю и отвечает за ~15% всех изменений прод-кода. Фон невесёлый — всё это после сокращения ~4000 человек. Разбираю, что реально под капотом (Builderbot — control plane поверх открытого фреймворка Goose: Slack-тред → ветка → PR → CI-петля), и главное — что из этого может украсть обычная команда без своего фреймворка. Острый угол: на масштабе кодинг-агент — это не про модель, а про обвязку (CI, права, аудит, очереди PR), то есть чистый DevOps. Плюс честно про маркетинг в их цифрах и про 4000 человек за кадром.

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

Мы рассмотрим множество пограничных случаев, споткнёмся об маленькие препятствия и обнаружим, что некоторые технически корректные детали не всегда поддерживаются даже в больших системах наподобие Gmail (и, честно говоря, на то есть веские причины).

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

Мы можем легко принять, казалось бы, здравое решение, которое неожиданно вызовет проблемы. Кроме того, многоопытные разработчики (и старые системы) могут иметь ожидания, ранее бывшие корректными, но больше не работающие. Итак, без лишних предисловий, перейдём к вымыслам…

Последнее время я не пишу админ. панель для веб-проектов, а пользуюсь Телеграм-ботом.

Как это обычно происходит. Появляется новый проект. Некий сайт. Затем первая просьба что-нибудь поменять. Потом вторая. Потом оказывается, что нужно написать административную панель.

Административная панель — это как ремонт в квартире. Начинаешь с поклейки обоев, а через месяц меняешь электропроводку.

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

И всё это ради тридцати человек.

Все проще - используйте Telegram как административную панель.

Минимум кода, который за вас напишет Иван Иваныч.

Это вторая публикация на тему практики махоботоводства. В первой были рассмотрены общие вопросы создания ботов в MAX, некоторые отличия Bot API от аналогичного у Telegram и Hello, world на чистом PHP. Здесь начнём освоение обещанной в первой части библиотеки. Чтобы не перегружать сегодняшний материал, рассмотрим установку библиотеки, опишем учебную задачу по отправке запросов через Bot API и разберём выполнение её первой части. Остальное оставим на последующие публикации; пока не знаю, сколько даже их всего будет (если, конечно, успею всё здесь опубликовать, пока всякие злобные не заминусовали карму).

Многозадачность кажется простой темой, пока дело не доходит до Python и GIL. В статье разбирается: чем процесс отличается от программы, зачем нужны потоки, что такое ядро процессора и в чём разница между конкурентностью и параллелизмом. Затем – специфика Python: как GIL влияет на потоки, когда стоит использовать процессы, асинхронность или корутины, и чем они отличаются от green threads. Материал сопровождается схемами, рабочими примерами кода и реальными замерами производительности для CPU-bound и I/O-bound задач, а в конце – практические выводы о том, что и когда выбирать.

Агент не ломает архитектуру. Он заливается в те щели, которые ты ему оставил. Как я перестроил проект на 200К строк, чтобы границы держал линтер и CI, а не слова в CLAUDE.md. С кодом и цифрами до и после.

Почему в гите нет команды git pull --force.... Зачем она могла бы быть полезна? Смотрите:

Существует прекрасная общепринятая схема работы с контролем версий — у каждого разработчика своя копия проекта, коммиты в ветки, мерж, test‑сервер, pre‑prod, CI/CD.

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

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

Приходится работать на общем тестовом сервере, заливать файлы по sFTP и делать коммиты с локалки но как тогда поддерживать актуальность гита на этом самом сервере?

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

Лет двенадцать назад создание большого монолита было обычной практикой. Семь лет назад многие подсели на микросервисную архитектуру. Причем микросервисами часто называли все подряд: и сервисно-ориентированный подход (SOA), и набор крупных сервисов, и распределенный монолит. Главное было быть в тренде.

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

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

Привет, Хабр! Я — Дмитрий Селищев,  в компании «Синимекс» совмещаю роли руководителя подразделения и разработчика баз данных. В этом материале хочу поделиться историей о том, как простые, но не всегда очевидные приемы помогают кардинально ускорить SQL-запросы. Мы поговорим о стандартных конструкциях CASE и FILTER, которые позволяют писать более чистый код и, что важнее, на порядки сокращать время построения сложных отчетов. Давайте на живых примерах посмотрим, как это работает.

Стоит открыть исходники любого современного игрового движка – неважно, это C++-рендер, сделанный на коленке, или какая-нибудь гигантская экосистема вроде Unity или Unreal Engine – вы первым делом натыкаетесь на одни и те же знакомые сущности. Все вокруг живет в Vector3: координаты, направления движения, точки столкновений. Каждая частица указывает, куда она смотрит, с помощью Quaternion. А если требуется что-то покруче – переносить и одновременно крутить объект, то Matrix4x4. Это уже как стандарт де-факто: кто пробовал крутить объекты руками, тот точно переписывал код с этими структурами. Ещё конечно же отдельно существуют лучи, плоскости, сферы, bounding boxes, а между ними тянутся километры функций вроде dot(), cross(), normalize(), lookAt(), inverse(), project() и бесконечных преобразований типов.

Привыкаешь к этому быстро. Нам кажется совершенно естественным тасовать эти типы между собой – уж слишком давно так делается по всей индустрии. Но стоит лишь чуток задуматься, и начинает прорезаться легкий когнитивный диссонанс: выходит, вся наша графика построена на наборах несовместимых между собой математических запчастей. Для одного действия нам нужен один тип данных, для второго – другой, а пересчитать простое столкновение луча со сферой или плоскостью без пятого велосипеда никак не получается. Вроде бы всё работает и даже неплохо работает… Но ощущение конструктора из костылей не отпускает.

И самое интересное заключается в том, что так было не обязательно.

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

Аккуратный Go-сервис на net/http с единственной ручкой /time. Обновляем одну библиотеку через go get, не трогая свой код. После рестарта в сервисе появляется ручка /__injected, которая отдаёт строки из памяти процесса. Мы её не регистрировали — а пакет, который это сделал, формально даже не используется.

Разбираю шаг за шагом, как такое возможно: модель зависимостей Go и коварство //indirect, тихий вход через init(), сканирование кучи и unsafe. Pointer для поиска ServeMux в работающем сервере. И, конечно, как от этого защищаться — от аудита зависимостей до seccomp и read-only ФС.

Весь код — в репозитории, «вредонос» написан в учебных целях. Запускать только в песочнице.

Привет, мой читатель с Хабра!

Знаешь ли ты о том, что такое многопоточное программирование? Если да, то это хорошо! Если же нет, то придётся почитать немного скучноватой теории про такую известную технологию программирования, как многопоточное программирование, а затем мы копнём эту тему глубже…

Всем привет! Мы обновили правила Хабра — эта публикация посвящена их анонсу. Что, зачем, почему — под катом.

Вступление: Финал эксперимента и ответ скептикам. Как мы с ИИ написали Open-Source убийцу SaaS-ботов на 280 000 строк кода, и почему я отдаю его даром.

В своих прошлых статьях я рассказывал, как научился использовать ИИ вместо команды сеньоров («Почему для одних ИИ — гений, а для других — идиот») и почему классическая команда сегодня только тормозит разработку из-за бюрократии и потери контекста («Парадокс инвестиций: Почему $1,000,000 и команда сеньоров убили бы мой стартап»).

В комментариях на меня вылили ушат холодного и вполне обоснованного скепсиса. Мне писали: «Где метрики? Кому нужен твой пет-проект?».

И знаете что? Вы абсолютно правы. ©

Открыто бороться с гигантами индустрии, пытаясь перебить их рекламные бюджеты - это чистое самоубийство для соло-разработчика. У меня нет миллионов на закупку трафика и маркетинг. Именно поэтому я принял единственное доступное мне стратегическое решение: я не буду с ними конкурировать. Я просто убью их бизнес-модель.

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

В прошлый раз я писал про то, что сообщение об ошибке читает уставший человек в два часа ночи. Там была одна простая мысль: ошибка должна сказать, что случилось, почему и что делать дальше. Переписали голое invalid_request в человеческий ответ, и стало лучше.

Вот только «стало лучше» — это ощущение. А ощущение нельзя положить в роадмап (или защитить перед руководством), чтобы сравнить через квартал. Улучшить то, что ты не измеряешь, нельзя: можно только верить, что улучшил.

Давайте сегодня разберёмся, как DX из набора интуиций превратился в измеримую дисциплину: с исследованиями, метриками и цифрами. И как этим пользоваться, не скатываясь в дашборд ради дашборда.