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

Всех приветствую! Меня зовут Павел, работаю в компании Lasmart. Одно из направлений деятельности всегда было внедрение и развитие DWH. В какой-то момент задумались о том, чтобы оптимизировать прежде всего свою работу в некоторых аспектах. И первым инструментом сделали генерацию бизнес-описания на основе AI. Назвали Datadesc (data + description). Об этом опыте и пойдет речь в этой статье.

Привет, Хабр! Меня зовут Юрий Леметюйнен. Сейчас в «Лаборатории Касперского» я занимаюсь тестированием железа в процессе разработки KasperskyOS для мобильных устройств.

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

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

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

В своей предыдущей статье я разбирал схему продажи USDT в России, которой мы пользуемся в BotHub. Исходя из вопросов под статьей, сегодня – следующий логический шаг. Как же правильно подать декларацию 3-НДФЛ по криптовалюте, какие документы реально принимает налоговая, какие налоговые режимы легальны, а за какие прилетят доначисления, и как всё пошагово заполнить через ЛК ФНС.

Помните, как мы собирали компьютеры в 2016 году? Берешь четыре ядра от Intel, втыкаешь GTX 1080 (если есть деньги), накидываешь сверху 16 ГБ DDR4 — и вот вам топовая машина, которая годится вообще для всего, включая игры. Да, по нынешним меркам сетап уже несерьезный. Но это лишь оттого, что за прошедшее десятилетие изменились не только требования к железу, но и сама философия ПК. О ней-то сегодня и поговорим.

Современный Deep Learning уперся в производительность вычислений с плавающей точкой (float) и пропускную способность памяти. Мы предлагаем архитектуру «Обратного Хэша», где нейрон — это не сумма произведений, а битовая функция.

Ноль умножений. Ноль сложений. Только логика (XOR), статистика и скорость света.

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

Я Светлана Болсуновская, стратегический коуч-консультант в YADRO с 13-летним опытом в IT, помогаю командам и лидерам развиваться. В статье расскажу, зачем мы занялись темой здоровья команд, почему готовые Agile-опросники нам не подошли и поделюсь чек-листом для самостоятельной диагностики.

Со стороны сертификация ФСТЭК России часто воспринимается как преимущественно бюрократический процесс. Но при более близком знакомстве быстро становится понятно: ключевая сложность не в документах как таковых.

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

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

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

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

В игровой индустрии редки, но не единичны, ситуации, когда одна новая игра устоявшейся серии выходит и переворачивает существующий канон и восприятие франшизы у игроков. Не какое-то ответвление или просто заряженный сиквел, а кардинальный пересмотр старых наработок и переизобретение себя. «Morrowind», «Resident Evil 4» или «GTA III» стали вехами в истории развития видеоигр и в глазах многих являются главными представителями геймплейной формулы соответсвующих серий.

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

Именно так произошло с если не революционной, то безусловно очень важной для всего канона JRPG игрой «Persona 3». Радикальная смена стиля и геймплея, безумный ажиотаж, множество последователей и подражателей — третья «Персона» давно обрела статус «легенды» игростроения. Однако отношение создателей к собственному наследию и путанная ситуация с различными «версиями» одной и той же игры вызывают лишь грусть и заставляют в очередной раз задуматься о проблемах презервации видеоигрового искусства.

Что общего у бактерий в чашке Петри и языковых моделей? Я провел эксперимент: создал популяцию из 200 microGPT и «заразил» их вредоносным паттерном. Через 20 поколений эволюции нейросети научились выживать, но цена этого иммунитета оказалась пугающей. Разбираемся, как работает Alignment Tax на практике и почему «безопасные» модели неизбежно глупеют.

«Внедрили агента — им никто не пользуется». «Сотрудники копируют ответы без проверки — пошли ошибки». «Потратили бюджет на пилот — эффект нулевой».
Знакомо? Исследование Сколково и Redmadrobot показывает: провалы AI-проектов — это не проблема технологии. Это проблема зрелости. Компании покупают трансформацию, когда готовы только к личной эффективности.
Разбираем модель трёх уровней, четыре причины разочарования и главный дефицит рынка — не ML-инженеры, а люди, умеющие ставить задачи.

Это перевод основных тезисов из интервью Ленни Ракитски с Шервиным Ву, ведущим инженером из OpenAI. Оригинал на английском по ссылке.

1. AI пишет почти весь код в OpenAI. 95% инженеров используют Codex, а те, кто реально встраивает эти инструменты в работу, открывают на 70% больше pull requests, чем их коллеги - и разрыв со временем только растет.

2. Роль software engineer смещается от написания кода к управлению флотом AI-агентов. Многие инженеры ведут 10-20 параллельных Codex сессий, больше направляют и ревьюят, чем пишут код руками.

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

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

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

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

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

Спринт против дистанции 

 За последние годы я управлял пятью IT‑командами. У каждой была своя культура - не в ценностях на сайте, а в том, как работает повседневная механика.  

 Видно это в простых вещах: 

• как принимаются решения 

• кто имеет право на ошибку 

• как выглядит давление 

• как команда ведёт себя под нагрузкой  

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

Решения принимаются быстрее. Возражений меньше. Управляемость выше. Это действительно работает как спринт.  

 Но у спринта есть цена. 

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

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

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

Это не спор «жёстко или мягко». Вопрос в другом: какой режим управления выбран и какой ценой готовы платить за этот выбор.  

 Жёсткий режим — ставка на скорость. Мягкий — на устойчивость. Иногда их удаётся смешать, но почти всегда с трением и локальными потерями.  

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

Из статьи click.ru вы узнаете:

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

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

В прошлом году публиковал статью «Как выбрать ITSM/ESM-систему: пошаговая инструкция, ошибки и лучшие практики внедрения на 2026 год»‎. В этом же году продолжаю рассказывать о ITSM/ESM платформах.

В этом материале я хочу сравнить некоторые системы между собой. Сразу сделаю оговорку — несмотря на то, что я являюсь технологическим партнёром SimpleOne, обзор систем объективен. Мне не так важно, какую систему вы выберете — главное, пожалуйста, подойдите к этому серьезно: проанализируйте рынок, свои потребности, запросите референсы и внедрите систему качественно, чтобы она приносила желаемый результат.

Приветствую вас, дорогие читатели! В этой статье мы разберёмся в том, как нам добраться от самого нуля до первого треугольника. Мы будем использовать Vulkan API 1.0, а затем будем переходить к всё более и более новым версиям этого API. Это моя первая авторская статья, поэтому прошу вашей поддержки. Цель данной статьи - разъяснить процесс отрисовки треугольника так, чтобы любой мог не просто нарисовать треугольник, а понять как устроен простейший рендеринг на Vulkan API на примере отрисовки треугольника.