На связи Владимир Макеев, СЕО Surf. Я активно слежу за развитием ИИ и сам тестирую разные решения для ускорения разработки. И вот, что заметил: вокруг сотни государственных инициатив и прорывных кейсов внедрения ИИ. Есть даже национальная стратегия, которая подразумевает, что уже через 5 лет компании в 95% отраслей должны внедрить ИИ.
Компании думают, что затеряются в веках, если срочно не прикрутят нейросети. А после внедрения ИИ-решений презентуют невероятные бизнес-результаты. Рассказываю, почему всё работает не так, как нам хотелось бы.
Хвалебное видео от Максима Горшенина про успехи GS Croup в импортозамещении послужило наводкой, благодаря которой мы провели вскрытие, и узнали, что в выпускаемых "отечественных" микросхемах Flash памяти GSN2516Y и GSN2517Y используются полупроводниковые кристаллы от серийных иностранных микросхем W25Q16 тайваньской компании WINBOND. Проследив кто потребляет эти псевдоотечественные микросхемы, мы нашли уже "отечественные" счетчики электроэнергии от компании "Энергомера" с рекордными 117 баллами из Реестра российской промышленной продукции. Благодаря этим баллам счетчики выигрывают миллиардные тендеры на государственных закупках. Но в самих счетчиках мы не нашли отечественных микросхем, благодаря которым и должны набираться эти 117 баллов. Основным микроконтроллером и АЦП в счетчиках оказались микросхемы от тайваньской компании VANGO. В след за GS Croup по пути выдачи китайских микросхем за отечественные пошла компания "Интегральные Телематические Решения", нанеся свою маркировку на корпус микросхемы включили их в реестр, хотя на самом деле это микросхемы от все той же китайской VANGO. Вот так заказной хвалебный ролик от главного пиарщика и воспевателя импортозамещения разоблачил его самого и его заказчиков. Так что если Максим кого-то хвалит, то значит дело не чистое и нужно искать. И мы снова нашли...
Diplodoc — опенсорс‑платформа для работы с документацией в парадигме Docs as Code, которая создаётся в Яндексе силами команд Yandex Infrastructure и Yandex Cloud и является частью наших опенсорс‑инструментов. С её помощью мы собираем всю документацию компании. Это суммарно более 300 тысяч статей в более чем 2500 документационных проектов и порядка 6000 запусков Diplodoc CLI каждый день.
На таких объёмах нам важно быть эффективными — умеренно расходовать ресурсы сборочных ферм и при этом собирать проекты как можно быстрее, чтобы документаторы могли увидеть финальный результат без смены контекста на чай.
Со временем, скорость CLI заметно деградировала. С одной стороны, платформа прирастала полезными функциями, это увеличивало время обработки контента, с другой — размер документации вырос и для некоторых продуктов перевалил за тысячу файлов.
Больше всего от растущего времени сборки страдали технические писатели: для просмотра внесенных изменений им требовалось собирать документацию целиком и на больших проектах это стало приводить к ожиданию более 10 минут. С десятками тысяч правок документации ежедневно эти десятки минут складываются в человеко‑месяцы простоя, которые никому не идут на пользу. Поэтому мы приняли решение всё это основательно причесать.
В этой серии статей мы пройдемся по каждому этапу работы V8: лексическому и синтаксическому анализу, построению AST, интерпретации и оптимизациям. Затронем Ignition, Sparkplug, Maglev и Turbofan; разберемся с hidden classes, байт-кодом, и много чем еще. Углубимся во все этапы достаточно, чтобы понимать, за что отвечает каждый из них.
В этой части посмотрим на лексический и синтаксический анализ.
Я уже несколько лет чиню гаджеты — от смартфонов до материнских плат ноутбуков. Это не только экономит бюджет, но и приносит удовольствие от возвращения к жизни старых устройств. Конечно, для того, чтобы ремонт был удачным, кроме опыта, нужны инструменты. Без них починка девайсов превращается в гадание на кофейной гуще.
Этот текст для начинающих любителей электроники. Поделюсь опытом использования трех ключевых приборов в моей мастерской — лабораторного блока питания (ЛБП) DS310S, мультиметра Mestek DM100C и USB-осциллографа Hantek 6022BE. Подробно расскажу, как использую каждый прибор, с реальными примерами из практики. Надеюсь, будет полезно!
Тема подбора персонала для меня, как руководителя, давно в фокусе. Когда формирую команду, смотрю не только на опыт, но и на потенциал, личные качества и готовность к росту. И если быть честным, рынок часто переоценивает важность стажа и недооценивает ценность начинающих специалистов.
В IT есть аксиома: чем опытнее разработчик - тем выше его ставка. Из этого вроде бы логично нанимать только «готовых бойцов». Но это мышление, на мой взгляд, слишком краткосрочно. Джуны не слабое звено - они недооценённые игроки. И вот почему...
Представьте: вы стоите по горло в море текста — полезного и не очень, от души разбавленного водой, может быть написанного сложным языком, — а времени у вас в обрез. Да даже и представлять не надо — знакомая ведь ситуация? Кто из нас ни разу не тонул в этом текстовом океане, ну? Но вместо того, чтобы тонуть, можно научиться ходить по воде — а надёжными проводниками станут нейросети‑суммаризаторы.
Стили и задачи текста бывают разные, и их соотнесением с наиболее сильными сторонами нейросетей мы и займёмся.
Большинство серьезных сбоев в системах хранения данных происходят не из-за глобальных катастроф, а из-за незаметных повторяющихся отказов, на которые никто не рассчитывал: перегруженный контроллер, зависание диска, сбой питания в неподходящий момент. Такие ошибки не поймать быстрыми и однократными тестами. В целом, надежность системы хранения данных невозможно проверить абстрактно — только вживую, на реальном железе, часами, с полным погружением в нагрузку и нестабильность.
Я Наталья Грязнова, ведущий инженер по разработке ПО в YADRO. Моя задача — не просто проверить, что СХД работает, а воспроизвести реальные риски отказа системы и проверить ее на устойчивость: высокая нагрузка, внезапные отказы компонентов системы, нестабильные внешние условия, например перебои в сети. В этом тексте расскажу, как мы тестируем отказоустойчивость СХД TATLIN.UNIFIED: какие сбои моделируем, как устроены автотесты и почему короткие прогоны не справляются с поиском критичных багов.
Привет! Я Максим Мялкин, управляющий партнер и руководитель мобильной разработки в KTS.
Сегодня я хочу поделиться историей моего знакомого и бывшего студента Сергея Ракова. Его карьера сложилась довольно необычным образом: от инженера-конструктора в Богородицке он прошел путь до Android-разработчика в Катаре.
Недавно мы провели с ним интервью и обсудили, тяжело ли ему далась смена профессии, чем занимается его компания и почему для разработки мобильного приложения они выбрали KMP.
Также коснулись темы культурных особенностей. Да, заголовок — не кликбейт, в Катаре по-прежнему существуют телесные наказания. Историю о них мы расскажем в конце; забегая вперед, знакомые Сергея поплатились таким образом за пьяное вождение (осуждаем).
17 лет назад случай выбросил 23-летнюю меня из уютной аспирантско-вузовской среды в корпоративный мир. Первая «большая» работа — компания на 450 человек, матрицы, KPI, планы, жёсткое руководство, неадекватные силам и навыкам задачи, интриги… Было невероятно тяжело. Были оскорбительные письма от начальницы, были слёзы на лестнице, был крик в аптеке: «Дайте что-то от сердца, я задыхаюсь», было заявление об уходе спустя три года этой лютой дедовщины. Спустя три — потому что было страшно уйти, потому что без опыта, потому что казалось, что мир рухнет прямо на голову. Потом всё наладилось, работалось легко, коммуницировалось тяжелее, но в целом движение ровное, не без интереса, чаще всего на двух работах одновременно. Почему-то мне кажется, что сейчас нет таких 23-летних, кто будет мучаться и терпеть. Наши зумеры может и не эрудированнее, но определённо мудрее и по-здоровому эгоистичнее нас. Но грабли-то те же. Поэтому я хочу предложить 10 пунктов, которые помогут молодым сотрудникам адаптироваться.
Всем привет! Меня зовут Алексей, я тимлид команды разработки в SENSE. Как нанимающий специалист, я все чаще сталкиваюсь с кандидатами, которые притворяются разработчиками. Например, приходит человек, у которого в резюме 4 года коммерческого опыта, уверенный стек, проекты интересные. Думаешь: ну вот, наконец, нормальный разговор по делу. Но вместо этого – щелчки клавиатуры за кадром, невнятные паузы, ответы как заученные. А дальше ступор на задачах, а у некоторых «особенно одаренных» в коде «as per OpenAI suggestion».
Сначала я не понимал, что происходит. А потом узнал, что это не случайность, а целая субкультура. Таких людей называют ИТ-волки. Они учатся не программировать, а проходить собеседования – звучать убедительно, продавать себя и брать офферы, даже если за этим нет ничего.
Привет, Хабр! Меня зовут Денис, я один из лидеров направления ВкусВилл Бизнес. Вместе с командой продактов занимаюсь развитием клиентского пути бизнес-клиентов.
Эта статья о том, как мы нашли для себя ещё один способ услышать реальные голоса наших клиентов, чтобы понять, как работает наш продукт в реальной жизни, не опираясь исключительно на метрики. Расскажу, как ИИ помог нам самостоятельно, без разработки увидеть то, что скрывают дашборды.
В контексте компьютеров, обучение — это всего лишь превращение плохих догадок в более качественные. В этом посте мы увидим, что всё начинается с прямой линии: линейная регрессия даёт первую догадку, а градиентный спуск продолжает её улучшать.
Давайте начнём с чего-то близкого нам: цен на недвижимость. Большие дома стоят больше, маленькие — меньше. Подобный паттерн можно заметить даже без анализа: чем больше места, тем дороже.
Если создать график цен, то его форма будет очевидной: идущая вверх нечёткая кривая с долей шума, но вполне определённым трендом.
Взаимное движение цены и размера как будто предсказуемо. Однако оно не ограничено фиксированными шагами или категориями, их масштаб скользит. Дом может стоить 180 тысяч, 305 тысяч или иметь какую-то промежуточную цену.
Теперь представьте, что вы продаёте свой дом. Его площадь 1850 квадратных футов (~172 квадратных метра) — больше среднего, но явно не особняк. Вы видели, почём продаются дома в вашем районе, но цены колеблются. Какой будет справедливая цена?
В мире разработки принятие правильных решений требует взвешенного подхода и понимания — где можно идти на компромиссы, а где необходимо проявить максимальную осторожность. Как управлять проектами, когда данные неполные, приоритеты изменяются, а время ограничено? В этой статье мы рассмотрим шесть тактик, которые помогают сохранять фокус в условиях неопределенности и принимать обоснованные решения, не теряя контроля над процессом. Эти подходы могут стать важным инструментом для каждого технического лидера, который сталкивается с необходимостью принимать ключевые решения в масштабных проектах.
