Все потоки

Всем привет! Меня зовут Герман Кравец, я больше десяти лет в IT. В МойОфис работаю руководителем группы Календаря в отделе разработки Mailion — это наша отказоустойчивая корпоративная почта для крупного бизнеса.

В этой статье расскажу, как мы с командой искали новое решение для нашего API Gateway: зачем вообще понадобилось его менять, с какими проблемами столкнулись и как проходили все этапы — от первых «что-то идёт не так» до финального рефакторинга и запуска нового Gateway в прод.

Будет немного боли, немного архитектуры и чуть-чуть магии. Если вам интересно, как решать нетривиальные задачи в продуктовой разработке, где стоит использовать готовые решения, а где всё писать вручную, или просто хочется узнать, как мы сократили простои на регрессе с 4–6 часов до пары минут, — добро пожаловать под кат!

Привет, Хабр. Меня зовут Мария Рылик, я — старший контент-менеджер группы управления пользовательским опытом веб-поддержки «Лаборатории Касперского». И полтора года назад я столкнулась с распространенной в техписовских кругах проблемой: децентрализованной базой знаний. Чтобы найти инфу по работе с конкретным продуктом, приходилось по крупицам искать ее в разных статьях, в большинстве своем имеющих мало общего с конкретной задачей, которую я пыталась решить.

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

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

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

Привет! Меня зовут Александр, я ведущий разработчик VK Tech в команде, которая занимается сервисом Kubernetes в нашем публичном облаке. Все чаще провайдеры отказываются от модели, где пользователь получает полный контроль над кластером и всеми управляющими компонентами, в пользу управляемых (managed) решений. В такой архитектуре вы остаетесь администратором внутри своего кластера — создаете неймспейсы, деплоите приложения, настраиваете RBAC, — но инфраструктура, control plane и системные компоненты полностью управляются провайдером и скрыты от глаз пользователя. 

В начале декабря наша команда выпустила новый сервис managed-k8s, в котором как раз реализован такой подход. Я расскажу вам про то, как выглядит наш Kubernetes с точки зрения архитектуры и каким образом Gatekeeper делает архитектуру безопасной.

В прошлой статье мы рассказывали о GigaAM — семействе открытых акустических моделей для русского языка и их дообученных вариантах под распознавание речи и эмоций. Сейчас мы представляем GigaAM-v3 — новую версию модели, которая ещё сильнее поднимает планку качества open source-моделей распознавания речи (Automatic Speech Recognition, ASR) на русском языке: поддерживает новые домены и end-to-end нормализацию текста.

Приветствуем, коллеги.

Расскажем вам о нашей долгожданной новинке – «Python для инженерных задач». Эту книгу написал уважаемый Евгений Ильин @jenyay, кандидат технических наук, преподаватель Московского Авиационного Института. В основу книги легли его университетские наработки, объём более чем внушительный – 672 страницы. Тем не менее, поскольку эта книга ориентирована на самую широкую аудиторию инженеров, мы решили выпустить её в серии «Самоучитель», из которой вам также может быть известен знаменитый «Компас-3D  V 23» Анатолия Герасимова.

Привет, меня зовут Артур, и я Unity-разработчик в компании «Альтернатива Гейм». 

В мире геймдева часто кажется, что создание карт — это удел художников и левел-дизайнеров: расставил ассеты, настроил свет, и готово. 

Но что если ваша игра должна работать на двух абсолютно разных клиентах — устаревшем WebGL 1 и современном Unity для консолей — при этом оставаясь одной и той же игрой? Здесь заканчивается чистое искусство и начинается настоящая программистская магия.

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

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

Но можно остановиться и передать повторяющуюся работу тому, кто не забудет и не промахнётся. Нас спасёт автоматизация!

Сегодня расскажем о том, как автоматизировать рутинные задачи на Linux-сервере при помощи cron и немного с помощью скриптов.

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

В итоге именно они — а не рациональность — нередко определяют поведение пользователя и влияют на ключевые метрики продукта: от конверсии и CTR до CSAT и удержания.

В этой статье мы рассмотрели travel-tech через призму поведенческой психологии и собрали распространённые когнитивные эффекты, которые встречаются на пути пользователя — от поиска направления до посадки в самолёт. Рассказали:

• как эти эффекты проявляются в реальных сценариях; 

• как их диагностировать с помощью данных и исследований; 

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

Будет полезно всем, кто работает с продуктовыми метриками, интерфейсами, исследованиями, или в целом стремится узнать больше о психологии пользователя онлайн-сервисов. 

Компьютерное зрение больше не живёт отдельно от языковых моделей: визуальные энкодеры, контрастивные лоссы и cross-attention становятся стандартной «обвязкой» вокруг LLM, которые учатся понимать изображения, видео и сложные сцены. В статье разбираются основные архитектуры визуально-языковых моделей, подходы к обучению на парах «изображение–текст», переход к динамическому разрешению и сжатию видеотокенов — то, как классическое CV переупаковывается в мультимодальные системы нового поколения.

В своей повседневной жизни мы, как правило, пользуемся только самыми примитивными функциями Windows по работе с данными. Мы создаём документы, копируем файлы, переименовываем каталоги и делаем множество других операций, доступных на расстоянии пары кликов в стандартном интерфейсе Windows.

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

В этой статье мы поговорим о таком функционале Windows, как виртуальные жёсткие диски, ссылки, точки повторной обработки (reparse points), расширенные атрибуты (extended attributes), альтернативные потоки (alternative data streams), теневые копии (volume shadow copy) и кое-чем ещё.

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

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

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

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

Программирование, да и вообще в целом ИТ — это всегда про компромиссы. Выигрывая в чём-то одном, мы обязательно проигрываем в чём-то другом. Не существует той самой «серебряной пули», то есть инструмента, решающего абсолютно все задачи. Также не бывает и идеального языка программирования. Но что если я скажу вам, что существует почти идеальный язык? И это Rust. Далее я постараюсь обосновать свои доводы, чтобы в глазах читателей на казаться слепым крабом фанатом очередной хайповой технологии.

За свой почти 14-летний путь в ИТ я успел профессионально поработать на нескольких языках программирования: PHP, Ruby, JS/TS, также мне доводилось «потрогать» Python, Go, даже Clojure и Haskell. Каждый имеет свои недостатки: у PHP — кривая архитектура, у Ruby — медленная работа, у функциональных языков — недостаток библиотек и обучающих материалов. При разработке на них каждый раз приходится идти на уступки и выбирать между изящным синтаксисом, скоростью работы и написанием «велосипедов» на каждый чих. В Rust всё обстоит совсем иначе и вот почему.

Вы тоже думали, что в Anthropic сидят небожители, которые пишут идеальный код с помощью секретных версий Claude 5.0? Похоже, нет.

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

На днях компания выпустила крутой разбор — как AI трансформирует их внутреннюю культуру. Там есть всё: от признаний в некомпетентности до споров о том, умирает ли профессия.

Я разобрал ключевые тезисы исследования, чтобы понять: мы наблюдаем эволюцию разработчика или его превращение в оператора кнопки «Сделать красиво»?

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

Это можно сравнить с тем, как если бы вы, постоянно, каждую секунду, открывали и закрывали входную дверь в квартиру, непрерывно проверяя, не пришёл ли кто-нибудь? 

Согласитесь, что мы так не делаем, так как это было бы нерационально.

Забавно, но, уже достаточно давно, я отслеживаю один любопытный феномен, который я для себя назвал «interrupt-интерфейс человеческой психики»...

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

Раньше для такого требовались: стейт‑машина с полудюжиной состояний, очереди и воркеры, обработчики на каждое событие и блокировки от race conditions. Теперь всё это описано в одной функции, которая вообще выглядит как псевдокод. 

Магия? Нет, Temporal. 

С тех пор как мы перенесли процессинг на Temporal, разработка существенно упростилась. Пользователь оплачивает заказ, ресторан его подтверждает и готовит, курьер забирает и привозит — ровно это и отражено в коде. Ну разве не прелесть?

Начало 18-го века, Пётр I строит флот. И тут к нему является крестьянин из Подмосковья с предложением, которое звучит как авантюра: сделать судно, что «будет ходить в воде потаённо» и сможет проходить под днищами кораблей.

Причём автор идеи — человек без образования и чинов.

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

Спойлер: идея не сработала.

Но история всё равно крутая.

Шутки, мемы, картинки от нейросетей — тему про Долину подхватили даже крупные компании.

Но вот нюанс, о котором не говорил еще никто: имя «Лариса Долина» — это оказывается официально зарегистрированный в Роспатенте товарный знак.

За каждое нарушение прав на товарный знак по закону можно взыскать компенсацию до 5 000 000 рублей. А с 3 января 2026 года эта планка вырастет до 10 000 000 рублей.

Казалось бы, это абсурд — взыскивать деньги за шутки в интернете. А само решение по квартире вам как?

Я юрист по интеллектуальным правам. Товарные знаки, патенты и авторские права — это моя профессия.

Как думаете, сколько еще квартир сможет купить Долина на сумму взысканных компенсаций?

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

Еще лет 10 назад iPhone в корпоративной среде воспринимали примерно как электрокары Тесла. Да, красиво, да, статусно, но как с этим жить – решительно непонятно. Особенно людям, которые дальше Windows и Outlook вообще никогда не выглядывали. Но мир поменялся, айтишники забыли, как патчить KDE2 под FreeBSD, а iPhone научились нормально работать с MDM. Однако остался вопрос: насколько все это применимо к реальной жизни, особенно в наших широтах, где к эппловским девайсам отношение стало, мягко говоря, настороженным?