Разработка

Продолжая тему, затронутую в статье об искусственном интеллекте и здравом смысле, хочу затронуть два принципиальных, но зачастую упускаемых из виду отличия мозга от искусственной нейронной сети. Во-первых, нейронная сеть состоит исключительно из «нейронов», а мозг – из нейронов и глиальных клеток. Оставлю здесь ссылку на интересную обзорную статью о глии, которую написала на Хабре уважаемая Василиса Белокопытова @vasilisa_b. До недавнего времени считалось, что глиальные клетки играют в мозге сугубо вспомогательную роль и функционально подобны оболочке проводов, передающих сигнал. Однако свежие исследования, в том числе, с применением искусственных нейронных сетей, привлекают всё более серьёзное внимание к астроцитам. Это небольшие звёздчатые клетки в составе глии. Они взаимодействуют как с нейронами, так и с синапсами, и вопрос о том, могут ли они передавать нейронные импульсы, рассматривался на сайте N+1 ещё около двух лет назад. Подробнее об этом — под катом.

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

Делали ли вы электронную визу в Индию? А, может, в Южную Корею? Или подавались на лотерею Green Card в США? Если да, то вы точно знаете, что для заявки на все эти документы надо прикрепить фотографию определённого размера с целым набором требований...

А такое ну просто необходимо автоматизировать!

И, как можно догадаться, сайтов для автоматизации фотографий на документы просто куча. Только вот есть одна проблема: все эти сайты хотят много денег - от 5 до 12 долларов за приведение фото к нужным требованиям.

Терпеть такое я, конечно же, не стал и написал своего бота в Телеграме, который делает это всё бесплатно.

Подробности под катом!

Как говорил Альберт Эйнштейн, «наиболее необъяснимое во Вселенной – это то, что она объяснима». Но что делает Вселенную познаваемой? Почему работает научный метод? Как вообще прямоходящие кожаные мешки с обезьяньим мозгом могут что-либо узнать о физической реальности, если они всю жизнь проводят в виртуальной реальности своего сознания? Ведь всё, что нам известно о мире – продукты нашего разума. Не означает ли это, что мы никогда не сможем узнать, какова реальность на самом деле? Что мы вообще знаем, если Вселенная на 95% состоит из неведомых тёмных субстанций? Откуда мы знаем, что законы физики универсальны и постижимы человеческим разумом? Где гарантия, что законы физики изотропны в пространстве и однородны во времени? Может, они варьируются от места к месту, изменялись в прошлом или изменятся в будущем? Существует ли вычислительно более мощный компьютер, чем машина Тьюринга? Вычислима ли каждая физическая система? Является ли сама Вселенная вычислительной машиной? Каковы фундаментальные физические и логические ограничения на то, что может быть вычислено и постигнуто? Есть ли вычислительный барьер, который невозможно преодолеть, независимо от того, насколько далеко и какими способами развиваются компьютеры? Или новые типы оборудования, основанные на квантовых, релятивистских или квантово-гравитационных явлениях, могут привести к принципиально новым вычислительным парадигмам и сделать невычислимое вычислимым? В этой статье мы погрузимся в глубины теоретической информатики, чтобы выяснить, каковы фундаментальные пределы вычислимости и возможны ли в нашей Вселенной гиперкомпьютеры.

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

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

Мы побывали на презентации «Алиса, что нового?», на которой Яндекс представил новые нейросетевые функции. Показали универсальную нейросеть Алиса AI, которая доступна не только в чате, но и в браузере, и скоро появится в носимых устройствах. В этой статье рассказываем обо всех анонсах.

Помню, как на собеседовании в одну крупную компанию мне задали вопрос: "Чем отличается observability от monitoring?" Я уверенно ответил что-то про "три столпа" и "unknown unknowns". Интервьюер кивнул, но потом спросил: "А зачем платить $100k в год за Datadog, если можно поставить бесплатный Prometheus?"

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

Поводом для написания этой заметки стало обсуждение на недавнем отраслевом мероприятии задач мультимодерации контента: как быстро и надёжно находить «взрослые» сцены в длинных видео и автоматически подсвечивать фрагменты для ручной проверки. Похожие кейсы регулярно встречаются и в открытых соревнованиях по ИИ (например, в подборке задач Wink AI Challenge на Codenrock).

Знаете, что я делал вчера с 10 до 12 утра? Деплоил новую версию на production. Вручную. На 15 серверов. По SSH. В 2024 году. И это не самое грустное. Самое грустное — что я делаю это каждую неделю. И каждый раз обещаю себе, что вот на следующей неделе точно автоматизирую. Но следующая неделя наступает, и я снова сижу и копипащу команды в терминал.

Если вы узнали себя — добро пожаловать в клуб анонимных toil-оголиков. Давайте поговорим о том, почему мы все еще делаем руками то, что должны были автоматизировать еще вчера.

ИИ давно обещает ускорить работу разработчиков — но что, если в реальных условиях он делает обратное? Команда исследователей провела рандомизированное контролируемое испытание с опытными контрибьюторами крупных open source проектов, чтобы понять, как современные инструменты вроде Cursor и Claude влияют на скорость и качество разработки. Результат оказался неожиданным: при работе с ИИ программисты тратили больше времени, хотя были уверены, что работают быстрее. Разбираемся, почему эффект ускорения может быть иллюзией, и какие факторы превращают помощника в тормоз.

Всем привет! Я Алексей Босенко, DevOps-инженер в компании KTS. В этой статье я покажу, как комплексно настроить быструю и эффективную сборку проектов в Kubernetes с использованием BuildKit, которая учитывает не только производительность, но и стоимость ресурсов.

Под этой громкой фразой я подразумеваю целый комплекс решений: как создать и настроить экономичный кластер Kubernetes для сборок (ведь цена вопроса всегда важна), как настроить GitLab Runners и как сделать эффективное масштабирование сборок. Особый акцент будет на том, почему мы выбрали BuildKit, какие варианты использования он предлагает, и как непосредственно настроить один из них.

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

Привет! Я Максим Кузьмин, старший инженер по автоматизации в команде Т-Путешествий. Строю и развиваю процессы автоматизации и разрабатываю инструменты тестирования.

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

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

Команда проекта Valhalla выпустила early-access сборку JDK с полной реализацией JEP 401 — value-классы и объекты теперь можно попробовать в действии! В новом переводе от команды Spring АйО — примеры использования, объяснение концепции, сравнение производительности с обычными объектами и практические советы для разработчиков.

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

Привет Хабр! Меня зовут Алексей и я занимаюсь беспроводными технологиями. На написание этой статьи меня сподвиг комментарий уважаемого @NightFlight который обратил внимание, что многие пользователи ориентируют антенны у роутеров по типу ориентации «заячьи уши» \/ так, как это делали для комнатных телевизионных антенн. В этой статье вспомню немного теории, расскажу о разных типах антенн, поляризации, и о том как лучше ориентировать антенны у бытовых роутеров в зависимости от их количества и как ориентация может повлиять на beamforming.

Правильная ориентация антенн Wi-Fi роутера может существенно улучшить качество беспроводного соединения, увеличить скорость передачи данных и расширить зону покрытия сети. Согласно моим тестам, оптимизация расположения антенн способна повысить скорость соединения на 50-300%, а в некоторых случаях улучшить уровень сигнала на 2-4 дБ, что критически важно для устройств, находящихся на границе зоны покрытия. При неправильной ориентации, особенно при несовпадении поляризации передающей и приемной антенн, потери сигнала могут достигать 20 дБ, что фактически делает соединение невозможным.

С выходом интерфейса SD Express всё больше производителей начинают использовать его в своих устройствах. Nintendo Switch 2 — не исключение. Этот интерфейс позволяет запускать игры прямо с карты памяти за счёт значительно возросшей пропускной способности — спасибо PCIe. Но интересен он не только геймерам.

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

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

Кхм. Громковатый заголовок, но я всё объясню.

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

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

Поэтому вот такая картина потребления памяти меня до недавних пор особо не смущала:

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

На старте мы использовали внешнее решение, чтобы быстро запустить процесс монетизации. Но со временем, когда стор вырос и количество интеграций увеличилось, стало очевидно: для гибкости, скорости и контроля нам нужно собственное решение. Так в RuStore появилась идея создать Pay SDK — платёжного решения, которое мы спроектировали с нуля под реальные задачи российских разработчиков и наших пользователей.

Меня зовут Алексей Мольков, я менеджер продукта в RuStore. В этом посте расскажу, как мы пришли к решению написать свой SDK, какие вызовы прошли по пути и какие преимущества уже видят команды, которые его используют.

Представьте: обычный вторник, и вдруг в корпоративном чате паника — CRM лежит, бухгалтерия не может отправить платежи, сайт не открывается. Где-то в серверной тихо погас светодиод на ключевом коммутаторе. Или, что хуже — весь ЦОД оказался в зоне коммунальной аварии. 

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

Сегодня поговорим о том, как превратить точку отказа в отказоустойчивую систему на примере российского NGFW-решения UserGate. Разберем не только техническую сторону (протокол VRRP, режимы Active/Passive и Active/Active, синхронизацию сессий), но и практические моменты: сколько это стоит, как долго настраивать, какие подводные камни ждут на каждом этапе.

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

Тема безопасного и эргономичного взаимодействия между Rust и C/C++ была популярна на конференции RustConf 2025, состоявшейся в Сиэтле, штат Вашингтон. Чендлер Каррут выступил с презентацией, в которой представил различные способы взаимодействия между Rust и Carbon — экспериментальным языком, который можно условно обозначить как «(C++)++». Он резюмировал, что, пусть возможности стыковки Rust с другими языками со временем расширяются, в обозримом будущем не стоит ожидать, что будет полноценно решена проблема его взаимодействия с C++. Поэтому как раз появляется ниша для Carbon, который может предложить иной подход для постепенного совершенствования существующих проектов на C++. Вот слайды к его презентации — для тех, кто хотел бы изучить код его примеров более подробно.