Время от времени мне нужно выполнить примитивный сценарий в терминале, но каждый раз это заканчивается очередным гуглежом «bash iterate each file» или «bash file has string». А что если скрипты в терминале можно было бы писать прямо как поток декларативных мыслей?
Год назад запуск модели на 35 миллиардов параметров подразумевал облако, очередь на GPU, и счёт от провайдера в конце месяца. Сегодня я покажу, как мы сделали это на одной потребительской видеокарте AMD за $500 — без ROCm, без CUDA, без MLX, одним бинарником на Zig.
Это пост про ZINC — inference engine, который мы строим с нуля под железо, которое люди реально покупают. Не как proof of concept, а как рабочий инструмент с OpenAI-совместимым API, потоковой генерацией и встроенным чатом.
Когда ваше приложение состоит из нескольких сервисов, например бэкенда, БД и кэша, невольно возникает вопрос — а как гарантировать, что они запустятся в правильно порядке и вообще увидят друг друга? В Docker это решается с помощью depends_on, тут ничего нового. А вот в Podman подход немного другой. Ну кто бы сомневался!
3-я статья из цикла туториалов о том, как можно кастомизировать свой бизнес-портал в Битрикс24.
Сегодня рассказываем о плюсах воспроизводимого окружения для разработки. Такую среду можно переносить между машинами разработчиков и деплоить на сервер, при этом работать у всех всё будет одинаково.
В качестве практической части выполним деплой нашей переносимой среды на VPS, чтобы посмотреть, как именно происходит перенос всех зависимостей и насколько это сложно сделать с помощью AI-агентов.
Каждый, кто хоть раз заглядывал на Hacker News или r/ItRunsDoom, знает традицию: DOOM должен работать на всём. PDF-файлы, SQL-запросы, кишечные бактерии, тест на беременность - список бесконечен, и каждый новый порт абсурднее предыдущего
Но я задался вопросом: а можно ли запустить DOOM внутри шрифта?
Оказалось, что можно. И вот как.
Книга «Искусство визуализации в бизнесе» — это второе издание известного практического руководства по визуализации данных, в свою очередь выросшего из авторского проекта FlowingData.com. В отличие от академических книг по статистике данных (с наводящими зубную боль сложными графиками) или дизайнерских альбомов с красивыми иллюстрациями, здесь акцент сделан на рабочем процессе, от поиска данных до готовой визуализации, пригодной для бизнес-отчета, презентации перед инвесторами или аналитической записки руководителю.
Это не столько книга про то, «как построить график», — скорее системный гайд для аналитика, дизайнера или маркетолога по превращению данных в картину, понятную для бизнес-пользователей. Автор последовательно проводит читателя через весь цикл — сбор данных, очистку, анализ, выбор формы визуализации и финальный дизайн.
Привет, Хабр. Меня зовут Марат Мустафин, я архитектор стрима 1С в МТС. В крупных компаниях сегодня модно измерять технологическую зрелость команд по единым чек-листам и общим методологиям. Из-за этого команды 1С каждый раз оказываются в проигрышной позиции.
Реальные достижения — отказоустойчивые кластеры, еженедельные релизы через CI/CD, мониторинг бизнес-логики в Grafana — растворяются в общих формулировках вроде «У вас есть автоматизация тестирования?». А специфичные для платформы практики, такие как работа с хранилищем через gitsync, нагрузочное тестирование типовых операций, управление техническим долгом в конфигурации, просто не попадают в поле зрения.
В итоге сильная 1С-команда может получить средний балл, потому что ее инструменты незнакомы валидаторам оценки, а слабая — завышенный, потому что формально использует Jira. Под катом расскажу, почему общие модели зрелости плохо работают для 1С и какую модель оценки я предлагаю сообществу — с конкретными капабилити, практиками и открытыми инструментами.
С этой проблемой столкнулась и команда 1С в МТС. Корпоративная модель зрелости у нас есть, мы по ней проходим оценку и никуда от нее не деваемся. Но каждый раз при прохождении я видел одно и то же: реальные инженерные достижения команды не укладываются в общие формулировки, а специфичные для платформы практики просто выпадают из оценки.
Это натолкнуло меня на мысль: сообществу 1С нужен собственный инструмент — не замена корпоративным стандартам, а дополнение, которое говорит на языке платформы. Так появилась двухуровневая модель оценки для команд 1С, в которой важен не факт наличия процессов, а то, как именно они устроены и насколько осмысленно применяются. Она позволяет оценивать не только соответствие чек-листу, но и глубину инженерной культуры.
Я решил продолжить обзор bladeRF 2.0 micro xA9 через рассмотрение списка проектов, которые наиболее ярким образом демонстрируют возможности данного SDR в реальных применениях. Многие из этих вариантов прямо или косвенно базируются и обусловлены возможностями данного SDR. Перебирая все упоминания проектов с поддержкой bladeRF, я пришел к выводу, что bladeRF 2.0 micro xA9 лучше всего раскрывается там, где нужны не просто прием и декодирование, а широкий захват, передача, full duplex, MIMO, FPGA и кастомные GNU Radio/Soapy/libbladeRF сценарии. Самые сильные и практически ценные направления рассмотрим ниже. Но обо всем по порядку.
Всем заинтересовавшимся — добро пожаловать под кат =)
Когда цифровой продукт выходит на международный рынок, перевод интерфейса становится одной из ключевых задач для команды разработки. Казалось бы, всё просто: передал фразы переводчикам — получил обратно тексты на нужных языках и заработал новую аудиторию в других странах. Но в реальности обеспечение качественной локализации — это настоящий квест: теряющиеся ключи, винегрет из языков на одной странице, накопление невидимого долга и многочасовая рутина, выбивающая команду из рабочего потока.
Нам казалось, что в диспетчерской Яндекс Go всё под контролем. Потом мы запустили аналитический скрипт и выяснили, что 37% интерфейса частично не переведено и пользователи за рубежом видят винегрет из родного языка и дефолтного английского.
Я Ира Туманова, разработчик интерфейсов Яндекс Go. В этой статье расскажу про эволюцию контроля переводов: от ручного труда до автоматизации жизненного цикла ключей. Вы поймёте, почему важно не только настроить работу с переводами на старте проекта, но и отслеживать её качество на всех этапах, а также узнаете, какие маленькие хитрости способны избавить команду от внезапных «переводческих завалов».
Недавно пришло осознание, что до текущего момента большую часть своей жизни я посвятил учебе. Школа, бакалавриат, магистратура, адаптация в 2-х компаниях, курсы, книги, лекции на ютубчике. Говоря в цифрах, это заняло почти 20 лет, а если еще добавить период от рождения до школы, ведь там мы тоже учимся — говорить, ходить, взаимодействовать с окружающим миром, то вообще получается, все 26 лет своей жизни я учился.
И-и-и, знаешь, я ничего не помню :-) Ладно, что-то всё-таки помню, недаром говорят, что образование — это то, что остается после того, когда забываешь всё, но, в школьные годы я закончил музыкалку, а сейчас не могу сыграть ни одного произведения. Каждый год я берусь за изучение английского, но для понимания английской речи этих порывов не хватает. Подобных примеров я могу много привести.
Для меня эта тема очень важна, я очень много размышлял, читал и смотрел на эту тему, и вот сейчас хочу поделиться тем, к чему пришел.
Хабр, привет! Меня зовут Сергей Куриленко, я ML-разработчик, соавтор курса «Нейросети для работы» и ревьюер на курсе «Нейросети для бизнеса» в Яндекс Практикуме.
За последний год я не раз сталкивался с ситуацией: человек осваивает вайбкодинг и создаёт проекты с невероятной скоростью — а потом обнаруживает, что всё это время строил не карьеру, а карточный домик. Сценарий настолько типовой, что я решил оформить его в жанре вредных советов — чтобы было весело читать и неловко узнавать.
Когда мне пришла идея написать эту статью, я предполагала, что это будет хроника ошибок, от которых мы бы хотели предостеречь техническое сообщество: как мы наивно полагались на «синтетику», а «видовое многообразие» сервисов раскрыло нам глаза.
Но по мере подготовки материала пришло осознание, что проблема не в том, что мы ошиблись в методике, а в том, что для core-системы, пропускающей сотни тысяч разнородных запросов в секунду, достичь точного воспроизведения боевой нагрузки практически невозможно.
Под катом рассказ о том, как мы двигались от упрощенных моделей к глубокому изучению специфики поведения системы, а по пути осознали, что нужно не выбирать между крайностями, а комбинировать подходы и учитывать риски.
Миссия «Артемида‑2» НАСА прошла все основные испытания с момента запуска 1 апреля, причём ракета, космический корабль и экипаж продемонстрировали результаты, превосходящие самые смелые ожидания инженеров.
Первые шесть дней миссии показали, что капсула «Орион» работает в соответствии с проектом, причём впервые на борту присутствуют люди — то, что не мог доказать ни один симулятор.
Однако, пожалуй, её величайшим достижением стали действия экипажа «Артемиды», которые вселили надежду, придали импульс развитию и вселили оптимизм в мир, который, похоже, отчаянно нуждается в вдохновении.
Но остаётся более важный вопрос: действительно ли посадка на Луну к 2028 году, как того хотят НАСА и президент США Трамп, является достижимой целью?
Итак, что мы имеем в моменте
Люди зачем-то общаются с чат-ботами, по собственной воле, менеджеры пытаются заменить программистов, а топ-менеджеры так вообще видят скорое наступление AGI.
Поскольку слепо доверять продавцам лопат глупо, попробуем по фактам и аргументам разобраться что же поменялось в мире.
Умные машины — неумелые пользователи?
Мы все слышали о «ИИ-деградации мозга», «ИИ-психозе» и «ИИ-помоях». Если вы проводите время онлайн, совершенно очевидно, что сочетание соцсетей и ИИ не особо полезно для нейронов. О чём говорят гораздо реже — это влияние использования ИИ на работе, хотя оно потенциально ещё более значимо.
К счастью, эта тема начинает попадать в заголовки. Но большинство публикаций не объясняют почему использование ИИ на работе может быть проблематичным и совершенно упускают тот факт, что нас предупреждали об этих рисках с самого начала.
Добро пожаловать в мир деквалификации через ИИ.
Kubernetes часто называют сложной системой, в которой легко запутаться. Control Plane, etcd, scheduler, worker nodes — когда сталкиваешься с этим в первый раз, кажется, что разобраться невозможно. Но на самом деле за громкими названиями скрываются простые и логичные компоненты.
Мы подготовили простую теоретическую подводку и ранбук по запуску своего кластера с нуля. Материал подойдёт всем, кто хоть немного знаком с контейнерами и хочет понять, что происходит после команды kubectl apply. Никакой магии — только архитектура, жизненные циклы, живые примеры и пара схем для наглядности.
В марте специалисты киберразведки PT ESC зафиксировали активность группировки Rare Werewolf (Rezet, Librarian Ghouls). На этот раз был обнаружен архив data.zip, содержащий следующую структуру файлов.
Под катом разбор вредоносных файлов, их структуры и назначения.
«Каково это — когда хвост оказывается между ног?» — вопрос, который однажды задали Веронике Картрайт. Актриса приехала на съёмки «Чужого» играть Рипли, а получила Ламберт — «вечно ноющую» и обречённую. Как Хичкок учил её готовить стейк, зачем Ридли Скотт заставил бить Уивер по лицу и почему смерть Ламберт снимали… без самой Ламберт? Вся закулисная драма, брызги крови и один очень неловкий хвост — в этой заметке.
Open source модель для генерации музыки, которая на бенчмарке SongEval обходит Suno v5. Работает локально от 4 ГБ VRAM, генерирует полный трек за 2 секунды на A100. Разбираю архитектуру LM + DiT: почему разделение планирования и синтеза даёт такой результат, что реально работает, а что авторы сами называют проблемами.
Привет, Хабр!
Запрос работает 30 секунд. Вы смотрите на него, всё вроде ок: JOIN по индексированным полям, WHERE по дате, LIMIT 100. Должен летать, но что-то не летает. Добавляете индекс наугад — не помогает. Переписываете подзапрос в CTE и стало ещё хуже.
Проблема не в запросе, а в в том, что вы не смотрели в план выполнения. EXPLAIN ANALYZE показывает не что вы написали, а что PostgreSQL делает: какие индексы использует (и использует ли вообще), в каком порядке соединяет таблицы, где тратит время, сколько строк ожидал и сколько получил.