Тема автономных датчиков, не требующих замены или ручной зарядки элементов питания т.е. обслуживания довольно интересна. Здесь уже публиковались ряд статей на эту тему, что в какой-то мере поспособствовало началу моих экспериментов в этом направлении. Что в итоге у меня получилось, читайте в этой статье…
Всем привет! Меня зовут Артем Ерохин. Я работаю в X5 Tech в направлении продуктивизации ИИ. В прошлом году у меня был доклад про разметку данных с LLM. И я решил преобразовать этот доклад в статью, попутно обновив некоторые цифры и тезисы (такова уж скорость прогресса в этой области).
Всем привет, меня зовут Василий. С 2021 года работаю в роли инженера данных в Х5 Tech, успел за это время познакомиться с несколькими интересными проектами и подходами в области обработки данных, об одном из которых пойдет речь далее.
В этой статье расскажу о том, как можно повысить эффективность хранения данных за счет уменьшения их дублирования.
Разберем, что из себя представляют Slowly Changing Dimensions-2 (далее SCD-2) таблицы и самостоятельно реализуем на PySpark алгоритм сохранения данных в них. Попутно поговорим о том, как находить изменения в любой таблице, даже если отсутствуют поля для выбора изменившихся записей, и научимся получать из созданной SCD-2 таблицы срезы на требуемую дату в прошлом.
В последние десятилетия наблюдается значительное усложнение технологических процессов, на промышленных предприятиях применяется всё более эффективное оборудование, которое требует более внимательного подхода к его диагностике. Следствием этого стало появление отдельного класса промышленных информационных систем – систем параметрической диагностики. Помимо систем параметрической диагностики в последнее время стали появляться Системы Поддержки Принятия Решений, которые, помимо прочих функций, успешно решают задачи диагностики. Пример такой системы мы и рассмотрим в этой статье, ориентированной на технических руководителей и эксплуатирующий персонал промышленных предприятий.
Хабр, привет! Сегодня узнаем, что такое проблема подглядывания и почему она появляется. Реализуем аналог метода Покока и критерий Вальда для последовательного тестирования. Посмотрим, можно ли одновременно подглядывать и контролировать вероятности ошибок при том же размере групп. Обсудим границы применимости последовательного тестирования.
Не так давно в порыве ностальгии я решил установить все игры из своего детства и вспомнить, как это было круто. Для чего же еще нужен современный мощный компьютер, как не для установки третьих героев старых игр.
Первыми пошли Готики — хороши до сих пор (я из тех людей, кто больше любит третью). Потом горячо любимая Neverwinter Nights (в преддверии выхода Baldur's Gate 3), но, к сожалению, сейчас в нее играть было довольно скучно. А следом шел Морровинд — ох уж эта боевая система (miss, miss, miss).
И тут я дошел до одинокого забытого бриллианта. Игра, взбудоражившая умы и сердца подростков так же сильно, как легендарный фильм Ямакаси. После нее все заборы города были измалёваны однотипными надписями дешевой краской. И я про Marc Ecko's Getting Up: Contents Under Pressure.
Мы все знаем, что Hashicorp Vault — это фактический стандарт для хранения секретов, а Kubernetes — для размещения приложений. Но как подружить их вместе? Существует множество инструментов для интеграции Vault с Kubernetes, и каждый из них имеет свои плюсы и минусы. Как выбрать подходящий?
В этой статье, созданной по мотивам выступления на DevOpsConf’25, вы узнаете о самых популярных инструментах доставки секретов из Hashicorp Vault в Kubernetes, таких как External Secrets Operator, Hashicorp Vault Secrets Operator, Hashicorp Vault Agent Injector, Hashicorp Vault CSI Provider, Bank Vaults-Vault Secrets Webhook. Для каждого инструмента будет приведён пример настройки, объяснено, как именно секрет попадает в приложение, а также мы с вами сравним их с точки зрения ротации секретов и удобства использования.
Меня зовут Михаил Кажемский, я Lead DevOps из Hilbert Team. Я в IT уже больше 10 лет и пришёл в DevOps из разработки, поэтому побывал по обе стороны баррикад. Соавтор ряда курсов для инженеров на Яндекс Практикум по направлениям DevOps, Security и Data. Hilbert Team — провайдер IT-решений для крупного и среднего бизнеса в области облачных технологий, DevOps, DevSecOps, DataOps, MLOps и FinOps. Партнёр Yandex Cloud со специализацией Yandex Cloud Professional по направлениям DevOps и Data Platform.
Последние несколько лет, наблюдая за гигантскими сдвигами внутри индустрии видеоигр, у меня в голове крутится одна идея, выразить которую на виртуальной бумаге корректно и однозначно у меня не получалось. Тема спорная, и у многих людей, когда я поднимаю её в разговорах, она вызывает достаточно ожесточённую реакцию: кто-то соглашается и поддерживающе кивает головой, кому-то это просто не кажется важным, другие же с криками бросаются на откровенно чуждую им позицию, не желая выслушивать аргументы.
Поинт мой примерно таков: со смертью (консольных) эксклюзивов пришла медленная смерть домашних консолей, что нанесло серьёзный урон по и без того нестабильной современной видеоигровой индустрии, и последствия чего нам только предстоит увидеть. Многовато слов, кажется, перегружено, но по-другому в формате одного предложения я пока выразить не сумел. И, кажется, я бы мог дальше рассуждать на эту тему сам с собой или с неприветливыми онлайн-комментаторами и собирать годами доказательства для своего тезиса, однако Гейб вместо «HL 3» решил анонсировать другую троицу: новый Steam Controller, Steam Frame и Steam Machine. И, увидев последнюю, я сразу понял — надо действовать. Это устройство было той недостающей деталью, винтиком, который идеально демонстрирует современный ландшафт индустрии видеоигр и отношения между создателями железа/игр и игроками. Но обо всём по порядку.
Тема «эксклюзивов» всегда была предметом большого количества споров и недовольств внутри геймерского сообщества. Сама идея контента, ограниченного рамками одной платформы/семейства устройств, кажется «анти-консьюмерской» по своей природе — и так оно и есть, по крайней мере, на поверхности.
С детства я хотел иметь систему, которая бы охватывала все (или почти все) аспекты моей жизни. И главное — чтобы она тратила минимум моих усилий. Абсолютный минимум. И у меня это получилось.
Я расскажу о системе, к которой шел почти 18 лет, потому что системы GTD для обычных людей у меня не работали. Я пробовал ежедневники, Google Keep, Evernote, Notion, физическую белую доску для маркеров, делал локальный сайт на HTML, писал себе в личные сообщения и в канал в соцсетях и мессенджерах, пока, наконец-то, не дошел до Obsidian.
Картинка: prostooleh, freepik.com
Есть один очень интересный вызов для разработчиков робототехники (или тех, кто хотел бы ими стать), который почему-то на данный момент большинство начинаний обходят стороной — управление массивом приводов. Ещё одна категория людей, кому будет явно интересна эта тема — разработчики мобильных приложений.
Задача эта весьма простая и сложная одновременно, так как массив приводов требуется для создания «управляемых выпуклостей», предназначенных для чтения незрячими людьми…
Остаться в темноте... Это страшно даже представить, а ведь множество людей так и живут, и это для них суровая реальность...
Хорошо, если слух есть, а если его нет... Сложно представить, насколько осложняется коммуникация, когда пропадает зрительная составляющая в мире, где так много информации передаётся в визуальном, в частности текстовом, формате. По сути, человек остаётся изолированным один на один...
Ниже будет некоторый обзор темы, после чего, мы плавно придём к ОЧЕНЬ интересной (на мой взгляд) идее, думаю, что будет интересно!
Сегодня во фронтенде многое кажется очевидным, но когда-то всё приходилось писать вручную, и каждое решение рождалось из конкретной боли разработчиков.
Если разобраться, откуда взялись эти подходы, легче понять логику фреймворков. Мы подготовили практический разбор, который помогает увидеть структуру за интерфейсом: почему фреймворки устроены именно так и что из старых решений до сих пор влияет на код.
В 1994 году, когда вся страна шла вразнос, а парламент стоял обгорелый после обстрела танками, я почему-то решил завязать с торговлей и поступить в МГТУ им. Баумана на кафедру «Ядерные реакторы и энергетические установки» факультета «Энергомашиностроение».
То ли потому, что детство провёл рядом со Смоленской АЭС и нахватался радиоактивных выбросов от советского реактора РБМК-1000. То ли потому, что в подростковом возрасте, будучи выгнанным из 8-го класса школы за асоциальное поведение, я поступил в Брянский машиностроительный техникум. А там один из моих преподавателей хвастался тем, что подавал документы в Бауманку - нет, поступить ему не удалось, но саму попытку он считал большим достижением. Видимо, на неокрепшие мозги 15-летнего ботаника это произвело неизгладимое впечатление. И когда я заработал на дикой торговле времён распада СССР немного денег, я решил, что надо учиться в Бауманке и стать инженегром.
В те голодные времена в университете каждый выживал как мог. Университет платил практически ничего от слова совсем. Одни бросали преподавать и шли работать кому повезло, те по специальности или близко, кому не везло, те работали, где придется. Один из наших преподавателей, подрабатывал торговым представителем и предлагал мне, как способному и перспективному студенту атомщику тоже развозить по магазинам печенье и вафли. Но я к тому времени уже был бывший владелец магазинов, и такой фигней заниматься не хотел. Я хотел быть ученым физиком или хотя бы инженером (Спойлер у меня не получилось, и американская коррупция сделала из инженера физика быдлокодера об этом я писал ранее).
Привет! Меня зовут Фёдор Засечкин. С 2023 года я руковожу группой разработки операционной платформы в Купере. Наша команда отвечает за стабильность и развитие сервисов, которые обеспечивают сборку и доставку заказов, а также найм и выход партнёров в смены.
Последние два года наша ключевая задача — микросервисная трансформация. Мы постепенно распиливаем монолит, перераспределяя нагрузку по сервисам. На сегодня более 1 000 RPS HTTP-трафика уже ушло с монолита; до полного завершения осталось около 30 RPS и часть межсервисных интеграций.
Я решил написать серию статей о том, как мы проходили этот путь: что сработало, какие ошибки допустили и какие решения реально помогли. Этот текст — первый из серии.
Публикация статей меняет статус специалиста, а книга — статус автора статей. Для того, чтобы продолжать профессиональный путь, требуется признание. Оно открывает путь к интересным проектам, новым профессиональным коллективам, к повышению дохода. Но разница между статьей и книгой настолько велика, что далеко не каждый может представить свою фамилию на обложке. Можно ли упростить задачу? Как выглядит процесс издания и что требуется от автора?
Что ж. Попробуем в этом разобраться.
У нас на слуху яркие истории про Apple и Стива Джобса, Microsoft и Билла Гейтса, Intel и Эндрю Гроува, Tesla / SpaceX и Илона Маска, Telegram / ВКонтакте и Павла Дурова, Virgin Group и сэра Ричарда Брэнсона. Но я решил расширить свой кругозор и разобрать кого-нибудь из неизвестного мне списка. Я подумал, что мир музыкального стриминга и кто-нибудь из известных исполнителей прекрасно подойдет для этой цели. Надеюсь, что мой обзор будет вам полезен и пополнит вашу копилку историй о компаниях и лидерах, а также даст почву для размышлений и действий в области строительства непобедимых брендов и компании.
Привет! Меня зовут Александр Фролов, я data scientist отдела машинного обучения в Нетологии. В этой статье я коротко расскажу, откуда взялись LLM, чем они стали сегодня, куда всё идёт и где в этом хаосе найти точку опоры.
Постараюсь обойтись без лишней теории и академического занудства — просто обзор по верхам с точки зрения дата-сайентиста, который строит пайплайны по обработке данных.
Привет, Хабр! Меня зовут Николай, и я ML-инженер в команде контента в Купере,
где уже год занимаюсь задачами автоматчинга. Этот материал — адаптация моего недавнего выступления, на котором я рассказывал, как мы стараемся сэкономить бизнесу время и деньги.
Речь далее пойдет о матчинге товаров в ритейле: от ручного ввода до ML-пайплайнов с эмбеддингами и ранкерами. Если что-то покажется неясным или возникнет желание подискутировать о деталях, велком в комменты.