Technotext

Как-то так получилось, что неожиданно у меня образовалось хобби – делать свои версии ретрокомпьютеров. Т.е. не просто найти схему, сдуть с нее пыль и спаять как это было когда-то придумано, а сделать свой вариант. Но обязательно с настоящим процессором и другими основными микросхемами, а не эмулятор на микроконтроллере.

Замечу, что мне интересен сам процесс сборки. Как-то пользоваться тем, что в итоге получается, я не вижу смысла.

Сегодня будет рассказ про Радио-86РК.

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

Итак, дошла у меня очередь до РК после всяких спектрумов. В свое время он прошел как-то мимо меня. В 86-м году я еще был слишком мал и не читал журнал «Радио», а когда стал постарше, всех домашних восьмибитников уже затмил великий Спектрум.

Делать я решил классическую версию 32кБ, но со следующими особенностями:

• Процессор Z80. Он был у меня в наличии, и плюс к этому он по всем параметрам лучше i8080.

• Выход на монитор VGA 640х480. Никаких телевизоров. 21 век все-таки.

• Память на двух 41464 вместо 8 или 16 К565РУ… Эти (41464) тоже были у меня в наличии. Получается 64кБ, а не 32. Но это не важно.

• Параллельный порт К580ВВ55 только один на клавиатуру – внешних устройств для подключения у меня нет, поэтому второй порт не пригодится.

• Всякую мелкую логику реализовать в ПЛИС.

• Монтаж проводами на макетной плате.

Вот и весь план. Набросал реально в уме эскиз будущей конструкции, заказал макетную плату размером А4 и основные микросхемы.

Всем привет! Меня зовут Станислав Ким, я ML-разработчик в команде качества поиска Ozon. В этой статье расскажу, как мы перешли от ранжирования товаров к ранжированию предложений, внедрили «матрицу памяти» для переноса статистики и получили +0,9% к GMV на пользователя.

Представьте простую ситуацию. Вы — продавец электроники. Выводите на Ozon новую модель робота-пылесоса. Чтобы ворваться на рынок, вы ставите цену на 20% ниже конкурентов и отгружаете партию на ближайший склад, чтобы доставка была «завтра». Логика подсказывает: алгоритмы увидят выгодное предложение (дёшево + быстро), подкинут товар в топ, и продажи взлетят.

Реальность: проходит день, два... а товар висит на 5-й странице выдачи. Потому что для алгоритма ранжирования ваш пылесос — «чистый лист». У него нет истории продаж, нет кликов, нет отзывов. Рядом в топе — конкуренты: они дороже, доставка дольше, но у них есть история: тысячи заказов за прошлый год. Алгоритм «любит» их за накопленную статистику, а ваше выгодное предложение игнорирует — он просто не знает, чего от него ждать. В индустрии эта проблема называется cold start — и с ней сталкиваются все крупные маркетплейсы.

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

Привет! Если вы читаете эту статью, то скорее всего столкнулись с блокировками Telegram или просто хотите обеспечить себе стабильный и безопасный доступ к мессенджеру. Я покажу, как поднять свой собственный MTProto прокси с Fake TLS на любом VPS сервере за 5 минут с помощью готового скрипта.

«We have a phrase inside Intel. We are supposed to be a data driven company and the phrase is, "Don't argue with the emotions, argue with the data."»

Andrew S. Grove, Chairman of the Board, Intel Corporation, August 9, 1998

В июле 2023-го года в «Байкал Электроникс» стартовал проект по разработке собственного AI-процессора. В данной публикации мы хотим рассказать, почему мы выбрали именно архитектуру GPGPU, какими данными при решении мы руководствовались, а во второй части немного рассказать о ходе разработки и поделиться полученным опытом.

Всем привет, меня зовут Володя. Я работаю в Yandex Infrastructure и занимаюсь развитием систем балансировки нагрузки. В статье расскажу, как развивалась наша новая система управления конфигураций с момента её создания в 2018 году, а ещё о том, как мы переходили на новый Data Plane балансировки и какие новые интересные вызовы это породило с точки зрения массовости задач и управления ресурсами. 

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

Краткое содержание: Текст для сайта можно полностью поручить нейросети, и никто этого не заметит. Ключ в правильном подходе: анализ конкурентов, подбор LSI-запросов, структурированный промпт и финальная доработка. На практике такие тексты ранжируются ничуть не хуже, чем написанные человеком. А мой текст про новогодний маникюр 2025 стабильно висел в топе Гугла весь декабрь.

В английском алфавите 26 букв. С учётом заглавных букв (+26) и цифр (+10) получается 62 символа. Это значит, что для взлома пароля длиной n символов, состоящего только из букв и цифр, злоумышленник должен перебрать комбинаций. Мы привыкли думать в терминах степеней десятки, поэтому, чтобы выразить это число как , воспользуемся формулой

Для пароля длиной символов , то есть вариантов перебора. В году примерно секунд. Для перебора с частотой один вариант в секунду потребуется 30 миллиардов лет. Ну или давайте более наукообразно: если ваш пароль будут ломать с частотой раз в секунду в течение вашей жизни, а вы с момента создания пароля и до гробовой доски хотите прожить 100 лет, то вероятность, что вас таки взломают равна . Кажется, этого более чем достаточно. Но не для сайта Expedia.com. Они считают, что пароль nr75eJ2GBp недостаточно надежный.

Что же они хотят? Минимум 12 символов с использованием специальных символов (+23 символа, итого 85). Получаем

Ещё раз напомню, что - это показатель десятки. Тогда -- это примерно 5 * 10^ 15 лет. 5 квадриллионов лет, если делать попытки раз в секунду. Я даже слова такого не знал. Давайте шутки ради поставим пароль VladimirPutin1952#. У таких серьёзных парней он точно не пройдёт.

Ах нет... сайт expedia доволен. Считает, что очень хороший, надёжный пароль. Этот пароль кстати проходит на всех сервисах, где я его опробовал, а не только на экспедии.

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

В этой части разберём как из кубиков с буквами О, П, Ж и А while true do end

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

Привет, Хабр! Меня зовут Кирилл Маканков, я iOS-разработчик в ПСБ.  

Сегодня хочу поговорить про особенности реализации MVVM. Не с практической, а с теоретической стороны. С практической стороны этот архитектурный шаблон давно уже изучен вдоль и поперёк. А вот теоретических исследований, особенно применимых к Swift (и в общем, и к SwiftUI в частности), не так уж и много. Давайте вместе попробуем закрыть этот пробел и обосновать с теоретической точки зрения те или иные вариации реализаций в нашей ежедневной работе. Мобильным разработчикам на ObjC, Java и Kotlin данное исследование и обсуждение тоже будет полезно. Присоединяйтесь!

Если вы уже хорошо знакомы с MVVM, то в конце приведен опрос об используемой лично вами реализации. Давайте вместе определим, какая из реализаций самая популярная.

Привет! Меня зовут Антон Фролов — я ведущий менеджер продукта в Content AI. В этой статье расскажу, как мы превратили корпоративный поисковый портал Intelligent Search в платформу для создания цифровых ассистентов с поддержкой LLM.

Если у вас уже есть прототип ассистента на базе open-source компонентов, платформа может помочь оперативно разработать решение production-уровня для автоматизации различных процессов с внутренними документами.

У вас есть GitHub ? Ставите Stars ?
Используя эту информацию можно многое про вас рассказать.

В статье вы прочитаете как обучить эмбединги для 300к GitHub репозиториев и как их можно подгрузить прямо в браузере используя WASM для создания рекомендаций.

Идея статьи родилась после прочтения многочисленных источников в интернете по барьерам и моделям памяти.Так же, был просмотрены соответствующие видео с разъяснением. Много где в целом всё достаточно хорошо разжевано. Статья не претендует на исчерпывающий материал. Скорее, это обзорное описание на тему модели памяти в связке с RISC-V. Не рассчитана на entry level, рекомендуется сперва почитать что нибудь вводное.

Навряд ли кому то необходимо детальное знание внутренней архитектуры процессора на уровне RTL (register-transfer level), как и глубокого понимания принципов модели памяти, согласованности. Да и обычно вся эта информация берется из соответствующей литературе от производителя, других книгах по оптимизации. Предполагаю, что авторы в том или ином виде могу знать более глубокие вещи, чем представлены в открытых источниках. Возможно, они работали в компании производителя (Intel, например), общение, конференции, сообщества.

Но может ли быть источник лучший, чем исходники CPU? Навряд ли. Вы не найдете в открытом доступе исходники процессоров Intel, AMD и любых других. ARM за это денежки получает, продавая права на архитектуру и готовые спроектированные блоки. А вот для RISC-V такой источник есть - исходники полноценного суперскалярного out-of-order процессора от Berkley.

Не так давно был разработан язык Chisel на замену Verilog и аналогов. Он на базе Scala. А, так как это Scala, мы можем использовать IDE и внятную навигацию по исходникам. Но в исходники просто так не пойдешь, сперва надо приобрести необходимые фундаментальные знания, чтобы понимать в целом что такое разработка на уровне RTL. Неплохо бы разобраться с Verilog и с базовыми понятиями - всякие там защелки, регистры, мультиплексоры и тп. Это я и решил сделать и начал с книги “Паттерсон, Хеннесси: Архитектура компьютера и проектирование компьютерных систем”. Она безумно крутая и очень понятная. Затем прочитал несколько книг по FPGA и Verilog и даже купил учебную FPGA плату, но руки до неё так и не дошли. Это позволило сформировать для себя какую то необходимую картину того, как функционирует CPU, как происходит проектирование микроконтроллеров. 

40 000+ записей без пагинации, 200 OK вместо 400 Bad Request, SQL-запросы в ответах клиенту. Собрал 10 ошибок API из реальных проектов: монолитов, микросервисов, стартапах и энтерпрайза.

Современная левая философия о современных корпоративных практиках

Когда вы, как разработчик, слышите о "миссии" компании, а ваш внутренний детектор (или, как сказал бы Маркс, "ваше классовое чутье") кричит "bullshit", вы абсолютно правы. С точки зрения современной левой критической теории, "корпоративная миссия" - это не просто ложь, это инструмент идеологического контроля.

Прежде чем дать слово нашим современникам, вспомним набившего оскомину старика. Есть экономический базис (то, как мы производим вещи и зарабатываем деньги) и идеологическая надстройка (культура, законы, "ценности"). Единственная реальная цель любой корпорации - накопление капитала и извлечение прибавочной стоимости из вашего труда. Точка.

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

У нас были две сотни брокеров, шесть тысяч топиков, клиенты на четырех языках программирования, миллионы сообщений в секунду и целое море различных паттернов использования Kafka. А также жесткие требования по latency, тонна SLA и желание сделать гибкую систему аутентификации и авторизации для сервисов. Не то, чтобы все это было категорически необходимо для начала этой истории, но если уж начал рассказывать про асинхронные взаимодействия, то иди в этом до конца.

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

Если вам интересно распутать клубок асинхронного взаимодействия тысяч продюссеров и консьюмеров, узнать, где документация Kafka нас обманывает, а librdkafka и Confluent.Kafka не могут договориться, и как один потерянный пакет может привести к Permission denied, добро пожаловать под хабракат. Эта история для тех, кто догадался, что недостаточно было «просто включить флажок в конфиге».

Привет, Хабр! Меня зовут Виктор Корейша и я — руководитель направления Managed Services в Ozon. Я и моя команда, в том числе, отвечаем за всю инфраструктуру асинхронного взаимодействия между сервисами, которую строим на базе Kafka. А ещё я ведущий подкастов «Кода кода» и «Три тимлида заходят в бар».

Эта статья написана по мотивам моего доклада для DevOps Conf 2025. Расскажу нашу историю про внедрение авторизации и аутентификации в Kafka. Инженеры по эксплуатации найдут в ней обзор решений реализации SASL-сервера, разработчики — историю о конфликтах в production-ready клиентах, архитекторы — любопытные кейсы взаимодействия высоконагруженных систем, ну а менеджеры — эпос о внедрении технически сложных изменений в больших компаниях.

Сейчас в Legal AI доминирует довольно наивная идея: если большая языковая модель уже умеет писать приличный юридический текст, значит осталось только дать ей корпус судебных актов, прикрутить чат и получить "цифрового юриста" То есть будто бы право - это просто очень длинный prompt.

Проблема в том, что суд - не текстовый жанр. Суд - это система.

И как только вы выходите за пределы задач вроде "суммаризируй решение", "достань нормы" или “набросай черновик ходатайства”, выясняется неприятная вещь: LLM неплохо работает как интерфейс, но очень слабо подходит на роль самой архитектуры. Она умеет красиво объяснять. Но плохо заменяет процессную модель, вероятностный движок, слой маршрутизации и проверку ограничений.

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

Еще в конце 1960-х исследователи моделировали прохождение felony defendants через судебную систему округа Колумбия, а в 1973 году уже описывали преимущественно алгебраический подход к симуляции legal systems для совместной работы инженеров и юристов, в том числе на материале судов Индианы. С инженерной точки зрения это важно не как исторический курьез, а как ранняя попытка честно ответить на вопрос: что именно мы автоматизируем в праве - текст, решение или саму систему.

Ниже несколько простых, но, как кажется, важных идей по прочтении двух статей полувековой давности - Simulation Applied to a Court System (Jean G. Taylor, Joseph A. Navarro, Robert H. Cohen, 1968) и An algebraic method for simulating legal systems (Michael K. Sain, Eugene W. Henry, John J. Uhran, 1973).

Меня зовут Аскольд Романов, я руковожу продуктовой командой в Яндекс Образовании. Сегодня я хочу поделиться историей своего проекта K2-18. Это опенсорс‑инструмент, который трансформирует учебный текст в семантический граф знаний с образовательными метриками. Я назвал его в честь экзопланеты, в атмосфере которой (предположительно) нашли водяной пар: тоже история про извлечение скрытой структуры из наблюдаемых данных. В этой статье — как устроен инструмент, какие решения за ним стоят и что с этим графом можно делать.

Моя основная задача в Образовании — внедрение AI‑технологий в образовательные процессы, и K2-18 вырос из этой работы напрямую. Мне нужно было решить конкретную задачу: как превратить учебный контент в структуру, с которой LLM сможет эффективно работать для построения различных образовательных сценариев.

Идея родилась не на пустом месте. Я закончил ВМиК МГУ и аспирантуру там же с научным фокусом на компьютерной лингвистике. Сейчас, когда LLM научились читать текст, понимать его структуру и контекст, оказалось, что знания, опыт и контекст текущей работы позволяют решить эту задачу системно. 

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

Сироп агавы, эритрит, стевия, мальтит и ещё десяток сахарозаменителей — что из этого действительно работает? Что выбрать, если у вас диабет или вы хотите отказаться от сахара? И правда ли шоколадка «Sugar-free» действительно без сахара и углеводов?

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

У меня двадцать лет в IT. Большую часть этого времени я проектировал и эксплуатировал инфраструктуру на PostgreSQL. Сейчас работаю архитектором: Go, Python, Postgres, Redis, ClickHouse, мониторинг на десятки тысяч баз. До этого писал на Ruby, пробовал Rust. Классический бэкенд-инженер со всеми вытекающими привычками: императивный код, мутабельное состояние, постоянные if err != nil { return err }.

А потом я начал писать бэкенд на Gleam — молодом функциональном языке на BEAM (Erlang VM), который появился в стабильной версии только в 2024 году. Навык ещё в разработке, но бэкенд уже работает, и я не жалею. Путь был... познавательным.

Эта статья — не туториал и не рекламный буклет. Это честный рассказ о том, почему я выбрал Gleam, какие шишки набил, что мне понравилось настолько, что я не хочу возвращаться, и что до сих пор бесит.