Kurgan-Telecom Ru | Информационные технологии

Google полностью обновила сайт и приложение Gemini. Появился выбор уровня мышления, новый дизайн и модель Flash Lite. Однако у пользователей забрали Thinking модель и сильнее ограничили Pro модель.

В статье разберём, как именно раннер решает, что тест прошёл, почему .then без return выполняется уже после теста, почему try/catch в async‑тесте — частый источник ложного зелёного, что не так с forEach и setTimeout внутри тестов и какие инструменты не дают тесту соврать. Примеры на Jest, но контракт у Mocha, vitest и прочих тот же.

SpaceWeb в этом году исполняется 25 лет. За это время хостинг из ремесла для энтузиастов превратился в инфраструктурную индустрию, а потом начал растворяться в облаке. Что будет дальше — не очевидно даже тем, кто этот рынок строил.

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

Типичная ситуация: вы находите проблему в компании. Понимаете, как её решить. Пишете документ, готовите презентацию, объясняете идею руководителю. Все соглашаются: «Да, звучит разумно». И… ничего не происходит.

Документ лежит в wiki. Архитектура остаётся прежней. Процесс не меняется.

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

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

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

Но со временем стало очевидно: дело почти никогда не в самой идее. Дело в том, как она проживается людьми вокруг — и какую историю про неё в итоге начинают принимать.

Типичная ситуация: вы находите проблему в компании. Понимаете, как её решить. Пишете документ, готовите презентацию, объясняете идею руководителю. Все соглашаются: «Да, звучит разумно». И… ничего не происходит.

Документ лежит в wiki. Архитектура остаётся прежней. Процесс не меняется.

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

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

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

Но со временем стало очевидно: дело почти никогда не в самой идее. Дело в том, как она проживается людьми вокруг — и какую историю про неё в итоге начинают принимать.

Экосистема Flutter совершила один из самых значительных скачков вперед. С выходом Flutter 3.44 команда официально сделала Swift Package Manager (SwiftPM) менеджером зависимостей по умолчанию для iOS и macOS, ознаменовав начало конца эпохи CocoaPods.

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

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

Пока в приложении две роли и три проверки, авторизация умещается в if user.Role == "admin". Но стоит добавить пару ресурсов, ролей и исключений — и условные проверки начинают расползаться по хендлерам, дублироваться и жить своей жизнью.

В этой статье разберём, как навести порядок с помощью Casbin: вынесем правила доступа из кода в конфиг, пройдём путь от простого ACL до RBAC с иерархией ролей, соберём HTTP-сервер на Go с авторизационной middleware и обсудим грабли, на которые легко наступить по дороге.

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

На днях он обратился ко мне с очень интересным вопросом: «Дмитрий, помогите, пожалуйста. Хочу, чтобы любой GPT-чат при запросе “топ-10 компаний, валяющих валенки” (реальный запрос я заменил) выдавал нашу компанию в первой пятёрке».

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

Разработка - это инженерная задача!

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

В моем представлении, разработка программного обеспечения или иных программных решений — это инженерная задача. Когда-то давно один из архитекторов сказал мне: чтобы “кодить”, достаточно средне-специального образования. А вот чтобы разрабатывать ПО, нужно много чего уметь и знать; написание кода — это приятный бонус. Положив руку на сердце, я хочу сказать, что ИИ достаточно хорошо решает задачу написания кода. Только вот он решает не ту задачу.

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

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

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

Новая нейросеть GPT Image 2 генерирует идеальные арты с текстом и ультрареалистичные фото. Узнайте, как пользоваться ИИ в России без VPN. Внутри: полный гайд и 20 готовых промптов с примерами!

12–14 ноября в Санкт-Петербурге пройдет INFOSTART A&PM EVENT 2026 — конференция для аналитиков, руководителей проектов, архитекторов и специалистов по автоматизации на платформе 1С.

Инфостарт открыл прием заявок на выступления. Подать доклад можно до 28 августа.

Главный страх любого инженера ошибка CUDA Out of Memory. Мы выстраиваемся в очереди за H200 на 140 ГБ. Но как только мы спускаемся с уровня Python на уровень написания кастомных ядер, наступает великая ирония. Наша главная цель как оптимизаторов любой ценой избежать обращения к этой самой VRAM. В этой статье мы поговорим о физике видеокарт, "Стене Памяти" и о том, почему настоящие нейросети живут в регистрах, а VRAM это просто холодный склад.

Продолжаю серию подборок неочевидных ресурсов. Недавно рассказывал про 15 онлайн-сервисов, которые должен знать каждый сисадмин. Сегодня собрал инструменты для случаев, когда dig, mtr и traceroute недостаточно, но ставить софт не очень хочется. Под катом — подборка для сетевиков.

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

Но у нас есть решение! В этой статье я расскажу, как мы в Sber AI обучили специализированного LLM-судью (LLM-as-a-Judge) Pollux для оценки русскоязычных LLM. Мы выложили его в открытый доступ и вы можете встроить его в свой продукт уже сегодня.

Привет, это Всеволод Иванов и Артём Икчурин из Yandex Infrastructure — в нашей инфраструктурной команде Cloud Storage Services мы занимаемся разработкой хранилищ, которые внутри компании используются самыми разными сервисами. В Яндексе есть несколько систем хранения для разных задач, в том числе объектное хранилище для неструктурированных данных.

Несколько лет назад мы искали способы ограничить нагрузку на внутренний сервис S3 — так появилось наше собственное решение Yet Another Rate Limiter, или YARL, о котором мы уже писали на Хабре. Сегодня расскажем, как развивается наш лимитер. Так что если вам интересны высокие нагрузки, рекомендуем ознакомиться с предыдущей статьёй и затем вместе с нами отправиться под кат за продолжением.

Привет, дорогой Хабр.

Итак, в 2019 году ВОЗ внесла данный сабж в Международную классификацию болезней как синдром с тремя диагностическими признаками. Но - не классифицируется как медицинское состояние.

Т.е., больничного листа с диагнозом “выгорание” в природе пока не существует. Наука пока не определилась, куда это класть - к расстройствам адаптации, к аффективным нарушениям или выделить отдельно. Ну и пока не договорилась - официально вас как бы и нет. 

А тем временем - 58% российских сотрудников, по данным SuperJob (это такой портал для поиска работы) за сентябрь 2025-го, столкнулись с выгоранием. 

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

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

— строить Iceberg-таблицы SCD-2 с помощью Trino, SQL и Python;

— попутно освоим прекрасные функции merge, MD5 и другие полезные инструменты;

— напишем свой собственный оператор для Airflow для автоматизации ETL-процесса.

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

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

1. В компании Х у нас было 4 человека, которые ещё до эпохи ChatGPT с нуля за несколько месяцев собрали полноценный AI-стек:
— fine-tune собственных LLM на своих датасетах
— свой TTS/STT на своих датасетах
— генерацию лиц и deepfake
— MLOps-инфраструктуру и пайплайны

Каждое направление делал один сильный senior. ML команда из 4х человек, которая деливерит не прототипчики с AI, а такой уровень, где люди не верили, что говорят с моделью — думали, что это живой человек.

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

2. Теперь компания Y: AI-продукт уровня "обёртка над ChatGPT" команда из 15 человек уровня джун-миддл запускала около года. Потом ещё полгода доводила до нормального качества.

Сравним экономику:

Вариант 1:
4 senior’а х $8k х 4 месяца
≈ $128k до запуска

Вариант 2:
15 человек x $3k x 15 месяцев
≈ $675k до конкурентного качества продукта

Разница бюджета в 5 раз, разница в скорости запуска в 4 раза в пользу сеньёров.

Маленькая сильная команда:
— вышла на рынок быстрее
— строила собственные технологии
— накапливала engineering leverage
— могла быстро pivot’иться при необходимости

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

Какие выводы:

1. Лично я верю в сеньёров и быстрые запуски. Причём раньше 1 сильный инженер мог заменить 2–3 средних, а сейчас с помощью ИИ вполне может дать ещё больший эффект.

2. Больше людей не значит быстрее. Скорее наоборот: выше уровень сотрудников — выше скорость принятия решений и разработки — выше ROI — больше пространства для инноваций и поиска точек роста бизнеса.

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

Если не согласны — с удовольствием подискутирую.