Google Chrome

Думаю, многие хотя бы раз сталкивались с ситуацией, когда для проекта нужно было реализовать совсем небольшой backend: отправку письма с формы обратной связи, обработку webhook, простое REST API или несколько строк серверной логики. В большинстве случаев первым делом арендуют VPS, настраивают сервер, устанавливают Node.js, nginx, HTTPS и настраивают деплой.

Хотя для подобных задач это зачастую оказывается избыточным.

В таких случаях отличным решением становятся Google Cloud Functions — serverless‑сервис от Google, который позволяет написать небольшую функцию и уже через несколько минут получить готовый публичный HTTP endpoint. Не нужно поднимать собственный сервер, настраивать инфраструктуру или заниматься её поддержкой — достаточно написать код и задеплоить функцию.

В этой статье разберём, как за несколько минут развернуть свою первую Google Cloud Function, настроить автоматический деплой через GitHub Actions и использовать её в качестве простого backend для сайта, Telegram‑бота, webhook или любого другого проекта.

Codex это прекрасно, но лимиты все меньше, а цена все выше. Но ведь под капотом просто gpt-5.5(вот промпт)?

Один диалог слева пишет код, справа другой проверял результат, третий держал контекст, а я в это время мог накидать очередь следующих шагов и уйти пить чай. Если задача закончилась — пусть прилетит сообщение в Telegram.

Так появился экспериментальный Chrome-плагин ChatGPT Multi Pane: GitHub

ПРЕКРАСНОЕ ДАЛЕКО

Мир цифровых технологий постоянно удивляет. Сначала появились супер процессоры с тактовой частотой аж 8 мегагерц (КР1810ВМ86М — до 8 МГц), затем память (К565РУ7 - Клон Intel 41256), удивляющая своими гигантскими объемами в 256 килобай при наборе из 8 штук. Казалось, мир сошел сума и достиг поистине фантастических возможностей. Но это было в далекие 90-е.

Вспоминаю как спустя пару лет впервые запустил установку своей Windows 95 ставя будильник на два часа позже, чтобы не пропустить фееричный запуск окончания установки на моем первом DX386 с 40 мегагерцами в турборежиме. Чуть позже написал своё первое приложение на Turbo Basic, размер которого составлял всего пару десятков килобайт. Славные были времена, ведь мне тогда было около 20-ти лет.

ВСЕ ВЫШЕ И ВЫШЕ

Время шло. Технологический прорыв казалось никак не мог затихнуть. Процессоры, память, интернет, все стремительно развивалось и уже никто не думал об ограничениях. Появились первые мессенджеры. ICQ со своим уникальным "ку-ку" звучал во всех офисах. Помню даже на некоторых фирмах штрафовали своих сотрудников за использовании мессенджера на рабочем компьютере. Появились первые программы по автоматизации финансовой деятельности предприятий. 1С-ку кажется уже знают все. Встроенный язык программирования, да ещё и с русским диалектом. Вау, вот времена наступили. Всё крутиться, сверкает и манит в магазин компьютерной техники прикупить очередную видюху с двумя или даже тремя куллерами. Эх, где же вы мои любимые Trident TVGA или Cirrus Logic с одним мегабайтов видеопамяти?

До сих пор сайты делали для людей: чтобы человек зашёл, посмотрел глазами, нажал кнопку. Но всё чаще на страницы заходят не люди, а ИИ-агенты — боты, которые сами читают сайт и действуют за пользователя: ищут товар, сравнивают, оформляют заказ, записывают на приём. И тут выясняется неприятное: то, что очевидно человеку, агент часто «не видит» — кнопка без подписи, всплывашка про cookie без названия, прыгающая при загрузке вёрстка. Google решил это измерять и встроил в свой бесплатный инструмент проверки сайтов (Lighthouse / PageSpeed Insights) новый раздел — Agentic Browsing. Он отвечает на один вопрос: готов ли ваш сайт к тому, что им будет пользоваться не человек, а ИИ-агент? Многие уже наткнулись на красное «0/3» в этом разделе и заподозрили, что с сайтом что-то серьёзно не так. Спойлер: чаще всего нет — это две-три мелкие и давно знакомые недоработки. Ниже разберём, что именно проверяется, чего пугаться не стоит и что реально стоит починить.

В Lighthouse 13.3 появился Agentic Browsing — pass/fail вместо 0–100. Четыре проверки, отличие от Search Console и что чинить до llms.txt.

Как перестать искать подходящее расширение и написать его самому. Отличия API Firefox и Chrome Extensions.

Всем привет! Меня зовут Александр, я продуктовый инженер в KTS.

Недавно мы разрабатывали AI-копайлот для сервис-деска в виде расширения на Chrome. Копайлот подсказывал оператору ответы для клиента на основе контекста диалога, истории обращений и базы знаний компании. Уже на старте стало понятно, что разработка расширений сильно отличается от привычной фронтенд-разработки.

Основная сложность была не столько в реализации конкретных фич, сколько в архитектуре: где должен жить тот или иной код, как организовать взаимодействие между частями расширения и как не заложить проблемы на будущее. Дополнительно добавились нюансы интеграции в страницу и ограничения, связанные с публикацией в Chrome Web Store.

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

Сразу задам фрейм: в статье речь пойдет именно о расширениях для Chrome (Manifest V3), хотя многие подходы будут применимы и к другим браузерам на базе Chromium.

Разбираю базовые техники OSINT для новичков: как проверять телефон, email, домен, компанию и изображения через поисковики, реестры, веб-архивы и открытые сервисы.

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

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

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

Готовые мобильные симуляторы это не закрывали: они хорошо делают своё дело, но не дают посмотреть адаптив прямо на вкладке, поверх десктопа. Я сделал свой инструмент — и в статье разбираю, как это устроено технически.

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

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

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

Работая с GitLab каждый день, повторяешь кучу одинаковых действий которые хотелось бы делать быстрее чем позволяет UI. Надоело, запилил Chrome-расширение.

В статье рассказываю как устроено внутри: авторизация через session cookies без токенов, цепочки действий в background worker, борьба с постоянно меняющимся DOM GitLab (Vue-миграция между версиями сломала все селекторы несколько раз).

Из фич: кнопки на MR странице (rebase, bump версии, auto-merge, ship), Jira-сайдбар прямо в GitLab, бейджи размера/конфликтов/тредов на списке MR, cherry-pick в несколько веток, command palette.

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

Да, вы всё поняли верно. If site == X, do Y.

Особого обращения заслужили TikTok, Netflix, Instagram* и даже SeatGuru.

Так поступают Safari и Firefox. Но не Chrome.

И это говорит нам кое о чём любопытном.

Если вам любопытно, исходный код выложен на Github. Это буквально проверки доменов, встроенные в движки рендеринга браузеров и гласящие: «если пользователь находится на этом домене, рендери вот это иначе» или «если он на этом домене, обрабатывай этот вызов API по-другому». Это не баг, а фича, выпускаемая для миллиардов устройств.

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

Kufar.by - это примерно как avito.ru, только в Беларуси. После очередного “улучшения” там стало невозможно выбирать авто и недвижимость: цены показываются только в белорусских рублях, хотя рынок всегда будет в долларах (боже, храни Америку). Поэтому я сделал небольшой Chrome Extension, который добавляет рядом ориентировочную цену в долларах. Пока только для авто и недвиги. И да, по ощущениям, ЛПРы, которые это выкатывали, никогда не покупали ни то ни другое на своём сайте.

Почему SVG, который работает в Chrome, часто становится статичным или ломается во Flutter? Разбираю проблему animated SVG, SMIL, CSS keyframes, path morphing, фильтров и рассказываю, как из этой боли появился full_svg_flutter — SVG-рендерер для Flutter с более браузерным подходом к рендерингу.

Устали от блокировок CloudFlare и капч? Показываю библиотеку rtfox-browser — готовое решение для автоматизации Chrome с прокси и решением капчи «из коробки». Установка, настройка, примеры кода и создание своих солверов.

Автор: Дмитрий Сосунов совместно с Claude
Уровень: для тех кто не программист, но не боится терминала
Время: один вечер
Результат: иконка в строке меню Mac → нажал Запустить → говоришь в Claude

Я давно пользуюсь FVD Speed Dial как основной экспресс‑панелью. Однажды после перенастройки сети (VPN, прокси, DNS) заметил неприятный эффект: любое слово, набранное в строке поиска новой вкладки, всегда улетало в Yahoo. Никаких настроек выбора поисковика в интерфейсе расширения не было — только встроенное поле, жёстко завязанное на внутреннюю логику FVD.

Системный поисковик Chrome я менял, но это никак не влияло на поведение FVD Speed Dial: расширение упрямо перенаправляло все запросы в Yahoo.

Каждый день мы делимся ссылками в мессенджерах, копируем их из браузера или кликаем по ним. И почти всегда к реальному адресу прилипает хвост из UTM-меток, fbclid, gclid и прочего мусора, которым маркетологи и платформы помечают наш трафик.

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

Недавно я завершил работу над расширением ZeroTail и хочу поделиться несколькими неочевидными подводными камнями, с которыми столкнулся при реализации авто-очистки URL.

Шутка в тему по памяти не помню откуда:

- Слушай, а можно как-нибудь дома накачать интернет, а потом по дороге его использовать?

Да, заголовок желтушный. Но какие времена, такие и потребности.

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

Но есть та часть ресурсов в Интернет, которые можно предварительно скачать и использовать также как и оригинал.