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

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

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

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

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

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

У меня есть свой взгляд на эту тему — все-таки 12 лет в роли CMO Битрикс24, где партнерская сеть насчитывает более 10 тысяч компаний, дает определенную пищу для размышлений. Но в этот раз я решила пойти другим путем и спросить самих интеграторов: а что им нужно, чтобы принять решение о работе с вендором?

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

Мы сделали серию интервью с интеграторами и с удовольствием делимся ею с вами. Надеемся, будет полезно.

Первый разговор — с Марией Бар-Бирюковой, директором департамента e-commerce ГК «КОРУС Консалтинг». 

Codex хорош, пока не приходится в пятый раз объяснять ему одни и те же правила проекта: где проверки прав, как запускать тесты, почему не надо тащить старые alias-модули и что мы уже решали в прошлом чате.

Поэтому я сделал Hermes Codex Plugin — плагин, который хранит правила, summaries и прошлые решения в SQLite, ищет их через FTS5 и подкладывает Codex только маленький релевантный кусок контекста.

Запустил openai/gpt-oss-20b в варианте MXFP4 GGUF на обычном ноутбуке без дискретной видеокарты: только CPU, встроенная Radeon 780M и общая оперативная память.

Тест проводился на ASUS Vivobook S 16 M3607HA: Ryzen 7 260, Radeon 780M, 32 GB DDR5 5600, Windows 11 и LM Studio 0.4.16-1 x64. Модель ноутбука указываю не ради привязки статьи к конкретному устройству, а для воспроизводимости. В таких тестах важны не только CPU и RAM, но и охлаждение, лимиты питания и shared memory у встроенной графики.

Главный вопрос был практический: можно ли реально пользоваться локальной 20B-моделью на ноутбуке с 32 GB RAM, если отдельной видеокарты нет?

Сразу оговорюсь это не научный benchmark, а пользовательский case study на конкретном железе. Проверял скорость, расход RAM/CPU/GPU, поведение при разных лимитах контекста и качество ответов на технических prompt сценариях.

На связи Сергей Смирнов, AI-инженер и основатель LLMStart.ru. Сегодня разбираем, как написать биллинг для продакшн ИИ-агента.

Когда ваш ИИ-бот начинает отвечать клиентам в B2B-сегменте, каждый его ответ стоит токенов. Чтобы экономика продукта сходилась, расходы на LLM нужно жестко контролировать и тарифицировать. Кажется, что достаточно просто прикрутить калькулятор, но на деле всё сложнее: один HTTP-запрос может дергать до пяти разных нейросетей, и не все они идут через стандартный граф фреймворка.

В новой статье на Хабре рассказываю: — Почему считать деньги по чатам — это путь к хаосу. — Зачем мы изобрели «микрокредиты» вместо наивных токенов. — Как протащить контекст биллинга через пять LLM-вызовов в одном запросе с помощью магии ContextVar + Mixin.

Разбор для тех, кто делает multi-tenant LLM-сервисы и уперся в ограничения готовых прокси-решений.

Привет, Хабр! Меня зовут Виталий, я занимаюсь развитием Венчурной студии РСХБ и проектами для молодых ИТ-специалистов в команде РСХБ.Цифра. В этой статье расскажу о том, как мы в банке придумали сделать полноценную мобильную игру и зачем вообще финансовой организации понадобился такой, на первый взгляд, нетипичный продукт.

Обычно, когда речь заходит о корпоративной безопасности, все спорят про настройку VPN, межсетевые экраны, выбор EDR‑систем и Zero Trust. Сам кабель при этом воспринимается как нечто стерильное и надежное по умолчанию. Но что, если забытая Ethernet‑розетка в переговорной — это идеальная точка входа, полностью обходящая внешний периметр? Как работают пассивные сетевые TAP‑врезки, не имеющие IP‑адреса и невидимые для IDS? И почему ваша операционная система доверяет копеечному USB‑шнурку больше, чем вам самим?

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

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

Построили двухконтурную систему: офлайн-обучение на XGBoost и CatBoost — и лeгкий онлайн-инференс через Flask.

Вместо одного .fit() с дефолтным лоссом внедрили K‑method — асимметричную функцию потерь. Теперь модель «боится» недолить жидкость сильнее, чем перелить, потому что в реальности эти ошибки стоят по-разному.

CatBoost лучше по удобству работы с «сырыми» категориями, XGBoost потребовал кастомного кодирования, но дал сравнимые метрики.

На малых данных (~350 строк) случайное разбиение творит хаос: метрики скачут от сида к сиду. Поэтому отбираем топ‑20 лучших random_state, а гиперпараметры усредняем частотным методом.

Весь пайплайн — от подбора параметров до прогона K‑сетки — завернули в Airflow ради повторяемости, а все эксперименты и логи складываем в MLflow.

Мы, devrel-ы, привыкли, что удивлять и креативить — это наша работа, поэтому к чужим приглашениям часто относимся со сдержанным профессиональным прищуром. Однако когда я получила пригласительное письмо на 20-й День рождения Хабра с темой «Дача 2.0», внутри что-то щёлкнуло раньше, чем я успела включить своего внутреннего скептика: я поняла, что точно не пропущу это событие.

В феврале 2024 года американская ContextLogic объявила, что продаёт маркетплейс Wish сингапурскому холдингу Qoo10 за 173 млн долларов. Цифра выглядит обычной для сделок такого рода, пока не вспомнить, что десятью годами раньше Wish был самым скачиваемым шоппинг-приложением планеты, оценивался в 14 млрд долларов и официально отказался от предложений о покупке от Amazon и Alibaba по 10 млрд каждое. Цена сделки оказалась на 99% ниже пиковой оценки — фактически от компании, претендовавшей на роль следующего Walmart, остался только торговый знак, переходящий из рук в руки.

Как выкатить собственный движок JavaScript

Привет, Хаброжители! Мы подготовили для вас перевод статьи, в которой автор делится опытом создания собственного движка JavaScript с нуля.

Автор на языке Go с нуля создаёт простой движок JavaScript. В статье пошагово разобраны ключевые этапы: от лексического анализа и построения AST до реализации вычислителя и встроенных функций (print, fetch, JSON). Отличный материал, чтобы понять, как код на JS превращается в работающие инструкции.

Каждый раз, когда нужно передать кому-то файл или пароль, выбор бесит: WeTransfer и аналоги видят всё, почта и телеграм хранят файл в плейнтексте вечно, PrivateBin только для текста. Хотелось простого: бросил файл, получил ссылку, а сервер физически не может его прочитать. И чтобы сервер был мой. Так появился share·me, self-hosted сервис, который шифрует файлы и текст прямо в браузере (AES-256-GCM), а ключ кладёт в URL-фрагмент, который браузер никогда не отправляет на сервер. Внутри: Rust/axum, Next.js, потоковое шифрование больших файлов и пара граблей, на которых я споткнулся.

10 новых российских продуктов для цифровизации работы клубов и сообществ, умного поиска с ИИ для интернет-магазинов, установления прямых контактов с клиентами, анализа и управления корпоративными знаниями, мягкой нейрокоррекции для детей и взрослых и многого другого. Битва за «Продукт недели» началась!

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

Платёж не прошёл. Отключить пользователя сразу или подождать? Если подождать, то сколько и на каких условиях? Разбираем механику grace-периода изнутри: состояния подписки, поведение доступа для B2C и B2B, цепочку уведомлений и технические подводные камни.

Давно хотелось влезть в тему генерации видео, но всё не доходили руки. А поскольку мне сильно не нравится современная мультипликация по сравнению с советской (в советской мультипликации, как по мне, были куда лучше и спокойнее образы и краски — смотреть их намного приятнее), то решил начать пробовать генерацию именно с мультиков.

Нашел простенькую сказку — «Колосок» — и стал искать, как в целом можно генерировать видео-контент своими руками.

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

Anti-corruption layer в учебниках выглядит как одна аккуратная коробка между чужой системой и вашей: всё чужое остаётся снаружи, внутрь проходит только то, что уже переведено на язык вашего домена. Граница ровная, как по линейке. Почти за год, что мы вытесняли 10-летний Rails-монолит на .NET, такой ровной границы я не увидел ни разу – ни у себя, ни, кажется, у кого-то ещё на живом проекте.

Понятно это стало в первую же неделю. Мы открыли таблицу exercises и нашли в одной JSONB-колонке 14 разных форм одного типа задания, слепленных за 10 лет. Смаппить это в новые DTO как есть – и новая модель отрастит ровно ту же форму, что у Rails. “Нужен ACL”, подумали мы. Только, как выяснилось на практике, не один.

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

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

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

В прошлой статье про ГИГАХРУЩ мы показали игру как живой weird-проект: браузерный survival horror / ARPG без движка, ассетов и спокойной жизни.

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

Разберем, как ГИГАХРУЩ устроен под бетоном: один активный клеточный этаж, typed arrays, плоские сущности, WebGL raycasting, A-Life, самосбор как мутация мира, сохранение, ограничения и MESH PASS как render-only объем поверх клеточной симуляции.

В предыдущей части цикла разобрали 13 таблиц REDB: как устроены objects, values, structures, как RTTI-хранение значений отличается от старого EAV-паттерна, зачем нужен scheme_metadata_cache. Если не читали — начните с неё, без понимания схемы дальше тяжело.

В этой статье — то, что обычно идёт следующим вопросом: «А индексы где? У вас же значения всех полей лежат в одной таблице. Любой WHERE — это Seq Scan по миллионам строк».

Это статья 1.1, а не 2 — потому что она прямое продолжение разговора про физическое хранение. Глубокое погружение в C# — это статьи 3-5 цикла: Code-first схемы (SyncSchemeAsync<T>), CRUD (SaveAsync/LoadAsync), LINQ-транслятор. Здесь разговор остаётся в плоскости БД и DDL.

Цифры, на которые опираемся, — с реального прода: TSUM, логистическая система, обслуживает движение грузовиков и заказов через РЦ.

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

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

Для тех, кто спешит: быстрая шпаргалка