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

24 сентября в 11:00 МСК проведем бесплатный вебинар о том, как контролировать фактическое использование лицензий 1С, находить свободный резерв и принимать обоснованные решения о закупках.

Программа вебинара и регистрация

TL;DR. Собрал воркфлоу на языковой модели, который раз в сутки обходит 34 страницы условий у 12 российских банков, сравнивает их со вчерашним снимком и публикует сводку изменений с ссылкой на источник в каждой строке, а при изменении цены пишет разбор с расчётом. Модель вызывается в четырёх точках и ни в одной не решает, что делать дальше. Цитаты, числа и статистика проверяются кодом. Каждый выпуск оценивается по 14 бинарным проверкам, метрики публичные. Стоит от 3 центов до 70 в день. Ниже устройство, проверки, evals и что он нашёл за первую неделю.

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

Что общего у раздувшегося индекса, неудачно нарезанных микросервисов и лишнего std::move? Все они выглядят безобидно, пока не доходят до продакшена. В этом дайджесте собрали 13 разборов бэкенд-задач, в которых детали решают всё.

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

На тот момент я уже работал с Power BI и DataLens, а рабочую версию управленческой аналитики мы развернули на сервере в Visiology. Прототип показали руководству и получили согласование на дальнейшее развитие. То есть на уровне первой демонстрации всё получилось: данные загрузились, дашборды открылись, показатели можно было обсуждать уже не на словах.

Если смотреть только на этот момент, систему можно считать выбранной успешно.

В моём тренажёре памяти и фокуса некоторые пользователи не понимали даже, как запустить тренировку. Я решил, что нужно больше объяснений, и сделал целую «Академию». Теперь люди пролистывали теорию и уходили, не добравшись до практики.

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

…а не по пинку от внешних расследователей, как это было последние разы (в эпизодах с роем агентов на немецкой вики и со взломом RubyGems). Заодно OpenAI раскрыли шесть новых примеров странного поведения своих моделей, разберем в этом материале кратко самое интересное.

Серьезное хранилище резервных копий не просто дедуплицирует данные и не теряет все при вылете одного диска — оно как минимум состоит из двух нод на случай, если одна сломается. Серьезное хранилище умеет делать снапшоты, чтобы злоумышленник не испортил всё, получив доступ к файловым шарам. У такого хранилища есть дедупликация на клиенте. А еще действительно серьезное хранилище умеет реплицировать данные на другую систему. Без всех этих опций индустрия просто не рассмотрит такое Purpose Built Backup Appliance как достойного кандидата занять вакантное место в стойке.

Под катом я расскажу о репликации в TATLIN.BACKUP: зачем нужно, как работает, какие особенности есть.

Спросил у Claude Code «Ответь одним словом: работает». Двадцать девять символов. На сервер ушло 305 042 байта — 113 460 токенов, ответ из четырёх.

Поставил между агентом и сервером прокси на сорок строк Python и разобрал тело запроса по частям. Системный промпт — четыре процента. Восемьдесят пять процентов — описания 137 инструментов, из которых 107 принёс один MCP-сервер, которым я в этой сессии не пользовался. Ещё 29 тысяч символов добавил хук плагина. И на каждый ход уходит второй запрос, о котором я не просил.

То же самое проделал с Codex CLI: 29 килобайт, 9 817 токенов, а системный промпт при этом такой же длины. Дальше — таблица, что убирается флагами (один MCP-сервер стоил 52 тысячи токенов на запрос), что это значит для окна и кэша, и скрипт, чтобы посмотреть свой первый запрос.

Через несколько дней Apple начнёт отгружать Mac mini на M6 и M5 Pro и Mac Studio на M5 Max и M5 Ultra. Замеров локальных моделей на них ещё ни у кого нет, а прикинуть скорость можно уже сейчас. В прошлой статье я замерил шесть моделей на базовом M4 и вывел правило через полосу памяти с КПД 0.83, которое сошлось с замером в пределах двух процентов. Здесь применяю его к новым чипам и публикую цифры до того, как железо приехало. Потом замерю и покажу, где ошибся.

Коротко. M6 для локальных моделей не апгрейд, прирост 25 до 40 процентов и тот же потолок 8B. M5 Pro первый mini, где 32B работает на рабочей скорости. M5 Max меняет класс, 70B на 13 токенах в секунду. Отдельно про ловушки младших конфигураций, у M6 с 16 ГБ и M5 Max с 36 ГБ полоса памяти заметно ниже.

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

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

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

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

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

Ретро умирают одинаково: жалобная книга вместо разговора, сорок минут на один спор, экшен-айтемы в никуда. Разбираю тайминг на 45 минут, четыре формата (Start Stop Continue, Mad Sad Glad, 4L, Sailboat) — что писать в каждую колонку и когда какой брать, — и правила, которые держат ретро живым. Во второй части — как устроена моя бесплатная доска для ретро: стек, где хостится, шифрование карточек и что происходит с данными.

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

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

Со вторым проектом я решил поменять порядок работы. Не начинать с большого roadmap и каталога возможностей, а сначала сформулировать одно повторяемое действие, которое можно проверить. Так появился Prosnix — Telegram Mini App для личных экспериментов после пробуждения.

Это не история успешного запуска. Пользователей пилота и подтверждённых результатов пока нет. Это история о том, как попытка сделать более узкий MVP изменила мои технические решения — и почему даже одна простая продуктовая метрика потребовала state machine, нескольких версий и отдельного отношения к исходным данным.

Внешний API возвращает данные в своей модели. Названия полей, вложенные объекты, изображения, цены и правила пагинации принадлежат provider. UI приложения обычно работает с другой моделью. Если компонент читает event._embedded.venues[0].city.name напрямую, структура внешнего ответа распространяется по интерфейсу. Изменение API затрагивает карточки, detail page, search, metadata и тесты.

В App Router внешний запрос можно выполнять на сервере. Server Components работают с fetch, а серверный код не попадает в клиентский bundle. API key при такой схеме остаётся вне браузера. Документация Next.js описывает server-side data fetching для App Router. В учебном проекте EventMap внешний источник событий проходит через server API слой.

Генератор учебных заданий положил «маши…ый» в правильную корзину, а проверка переложила слово в неправильную. При этом модель-арбитр в своём же объяснении написала «машинный». Разбираем по сохранённым ответам три сбоя проверяющей модели: что пошло не так в процессе, что поменяли в коде и чего эти правки не доказывают.

Я отвечаю за маркетинг в B2B ИТ: серверы и системы хранения данных для корпоративных заказчиков. Закупка идёт через тендерные процедуры, цикл сделки измеряется месяцами, чек измеряется миллионами. В начале августа я разбирал два рекламных кабинета в Яндекс Директе, которые до меня вели несколько лет.

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

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

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

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

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

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

Теперь у него есть результат, который подкрепляет эту позицию.

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

Всем привет! Меня зовут Дмитрий, я разработчик дизайн‑системы на Android в компании Домклик. В этой статье расскажу, как нам удалось возродить проект дизайн‑системы и успешно внедрить его в наше приложение Домклик.

И хотя речь пойдёт о разработке на стеке Jetpack Compose для платформы Android , большинство мыслей и рекомендаций не привязаны к конкретной платформе и технологии.

Привет, Хабр! Я Алексей Новаков, ведущий инженер данных в Рунити. Сегодня разберемся, зачем Lakehouse понадобился streaming, почему одного Iceberg для этого не всегда хватает и как Iceberg и Paimon могут жить рядом в одном конвейере.

Если сильно упростить, классический Lakehouse решает понятную задачу: берем дешевое объектное хранилище и добавляем поверх него то, чего не хватало обычному Data Lake — транзакции, schema evolution, snapshots, SQL, update/delete отдельных строк и одновременное чтение и запись.

Но дальше возникает следующий вопрос: что делать, если аналитика должна видеть не вчерашние или часовые данные, а состояние, которое обновляется постоянно?

Именно здесь Lakehouse начинает превращаться в Streaming Lakehouse — или Streamhouse.

«Без труда не вытащишь и рыбку из пруда», как гласит известная пословица, и это в полной мере можно сказать насчёт природных ресурсов: как правило, их добыча сопряжена с определёнными трудностями, ввиду чего частенько возникает ситуация из другой пословицы: «видит око, да зуб неймёт»…

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

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

Привет! Меня зовут Анастасия и я проектный менеджер и scrum-мастер в Окко. Проектным менеджментом я занимаюсь около семи лет: успела поработать с hardware проектами, CRM-системами, мобильной разработкой, ритейлом.

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

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

В этой статье расскажу, что изменилось в моей работе после появления роли Scrum Master, что оказалось самым неожиданным открытием и почему из всех Scrum-ритуалов именно ретроспектива стала самым ценным инструментом?