Technotext

С Новым годом, дорогие друзья! Не знаем, как у вас, но у нашей команды на столах мы насчитали: салаты с майонезом, Наполеон и хачапури из слоёного теста на маргарине, сыры всех видов и марок, включая плавленые и лёгкие, тарталетки на спреде и песочные пирожные на сливочном масле, заводской хлеб и выпечку всех видов, конфеты, вафли, а ещё бутерброды с икрой, на которые было намазано ТОЧНО сливочное масло, из‑под коровы, забранное у хозяйки не в очень аккуратной упаковке, а в пергаменте в мятом и не особо эстетичном, но вкусном комке. А остальное — НЕ ТОЧНО? Что с мифами о пальмовом жире в начале 2026 года? Разбираемся с аппетитом.

Психика – довольно парадоксальная вещь, которая подчиняется иной логике, нежели к которой мы привыкли. Несмотря на то, что главная функция психики – это обеспечение выживания индивида, на основе «субъективного отражения объективной реальности», иногда она работает против этой цели. И я говорю сейчас не про экстремальные варианты, вроде появления сверхидеи о питании солнечным светом и не про религиозные суициды во благо вечной жизни. Нет, я говорю об… учёбе, саморазвитии и познании мира.

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

Я достаточно давно изучаю особенности психики и личности как IT-специалистов, так и людей «от головы» в целом. И про особенности их личности писал ряд статей (часть 1, часть 2, часть 3, часть 4). Но сейчас, когда выборка стала больше и количество наблюдений кратно возросло, мне хочется копнуть чуть глубже и посмотреть не просто на личностные особенности, а на механизмы формирования этих особенностей у людей, обладающих эрудицией, интеллектом и способностью к абстрактному мышлению на более высоком уровне, чем в «среднем по больнице».

Первой игровой консолью моего детства, как и у многих моих сверстников, была “Денди”. Несмотря на то, что я был слишком мал, тем не менее запомнил, как с энтузиазмом старался победить противников в файтинге Yie Ar Kung‑Fu или педантично собирал, как мы их называли, “кучки” в игре Lode Runner, даже и не подозревая, что на самом деле это был золотой песок. Но в более осознанном возрасте на смену 8 битной консоли ко мне пришла Sega Mega Drive. Конечно, же на тот момент оригинальных 16‑битных консолей практически ни у кого не было, но мы об этом даже и не догадывались – для нас эти приставки были самыми что ни на есть официальными.

Является ли DES группой? В статье [2] было показано, что DES не является группой. Остановимся более подробно на вероятностном тесте MCT(meet-in-the-middle closure test), предложенном в [2] и основанном на атаке meet in the middle, и вычислим вероятность нахождения совпадения.

Как собрать домашний кластер виртуализации с нуля и зачем это вообще нужно? Автор делится личным опытом: от первых экспериментов с контейнерами и осознания их ограничений до построения полноценной инфраструктуры на мини-ПК.

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

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

Причем, если для подсчета ссылок в рантайме, решения существуют, то контроль переполнения стека невозможно сделать не только во время анализа исходного текста программы, но это практически невозможно и во время выполнения приложения! Ведь ошибка переполнение стека (stack overflow) - это всегда фатально, так как не существует способа поймать и обработать эту ошибку изнутри выполняемой программы, чтобы потом продолжить её выполнение как ни в чем не бывало.

Существует ли хотя бы теоретическая возможность защититься от ошибок переполнения стека и сделать из нее обычную ошибку (исключение), которую можно поймать (обработать) в самом приложении, чтобы была возможность продолжить выполнение программы без боязни последующей ошибки сегментации (segmentation fault) или повреждения стека (stack smashing)?

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

«Хочешь заценить какую-нибудь новую игру? Ну так скачай её по радио!»
Звучит как бред сумасшедшего, не так ли? Но ещё почти полвека назад это было реальностью!

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

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

— А по точкам вот прям вообще не подойдет?
— Не, ну, конечно, на крайняк подойдет, но хочу чтобы было по кривой. Да и на прошлой игре где я работал такое было, почему у нас нет?

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

Всем привет! Меня зовут Женя, я руководитель отдела разработки «Аккаунт» в мобильном приложении для продавцов платформы Ozon Seller. Поделюсь нашим опытом работы над улучшением скорости сборки Android-проекта.

Скорость сборки проекта напрямую влияет на time to market продукта и (внезапно) удовольствие от процесса разработки. Если каких-то 50 лет назад время компиляции могло доходить до нескольких дней, и это считалось нормальным, то сейчас даже лишняя пара минут сборки проекта в Android Studio может заставить понервничать. Чтобы сберечь здоровье себе и CI, скорости сборки проекта нужно уделять внимание. Нетерпеливые читатели могут сразу посмотреть итоговую таблицу с результатами в конце статьи.

『Совесть — не ослик: и не такое вывезет.』
_(с) Р. Суржиков, Полари_

『Халдер, проверь, что умеет сир Поросёнок.』
_(с) Д. Мартин, ПЛИО_

Статья будет особенно интересна филологам, которые знают, что научных материалов в Интернете по измерению лексического разнообразия текста не так много, а в Рунете единицы и часто поверхностные.

Преамбула

Видел некоторые баталии в комментариях от читателей на профильных ресурсах: частое сравнение между собой двух высокооценённых циклов в жанре эпическое фэнтези/средневековье — «ПЛИО» VS «Полари». Сходства и различия сводились к тематике, эпохе, локациям, чертам действующих лиц, слогу и другим очевидным и/или нетривиальным литературным приёмам и ходам. В этой статье добавлю контраста на художку и с математической точки зрения.

Как преподаватель, могу сказать, что студентам непросто бывает привести базу данных к какому‑то осмысленному виду (не говоря уже про третью нормальную форму). Во‑первых, нередко «всё связано со всем», во‑вторых, в мало‑мальски сложной (в смысле, комплексной) задаче бывает трудно правильно спроектировать таблицы (то есть определить, какие таблицы должны быть в базе, как они должны быть связаны друг с другом, где и какая информация должна в них храниться). Помогает ли им в этом теория? И да, и нет. Дело в том, что нормализация данных говорит о желаемом виде каждой таблицы, и, преобразуя отдельно взятую таблицу к нормальной форме, мы также что‑то делаем со всей базой данных (добавляем новые таблицы, перемещаем между ними поля, и так далее) — это как сборка кубика Рубика. Второй проблемой здесь является то, что даже база данных, состоящая из единственной таблицы, не приведенной к первой нормальной форме, внезапно, тоже будет работать — криво‑косо, но будет! Теория — штука хорошая, но кое‑чего ей не хватает, а именно — задания точки отсчёта. Ведь для того, чтобы пройти к библиотеке третьей нормальной форме, для начала нужно понимать, где мы находимся.

Помните, как в Корпорации Монстров страшилы добывали энергию из криков детей? Они готовились, чтобы быть пострашнее и собирать побольше энергии: репетировали жуткие звуки, подбирали реквизит, узнавали страхи ребёнка. В общем, настраивали параметры запугивания :) В мире баз данных у параметров конфигурации аналогичная роль: чем точнее настройка, тем выше производительность системы. Однако не все параметры везде работают с одинаковым эффектом (как не все монстры одинаково страшны для всех детей): какой-нибудь параметр идеален для одного профиля нагрузки, но не даёт того же результата для другого.

Администраторы БД часто ломают голову, как подобрать оптимальные настройки под задачи СУБД. И чтобы помочь им разобраться, мы обратились к опыту Майка Вазовски — тренера легендарного монстра Салли. Вдохновились секретами его тренировок и разработали утилиту Pangolin Tuner — аналог Вазовски для настройки параметров конфигурации. 

Я Кристина Демидович, DevOps-инженер в СберТехе, занимаюсь автоматизацией в команде СУБД Pangolin — это целевая СУБД в Сбере и не только. В этой статье покажу на примерах, как всё работает. Прошу под кат.

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

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

В этой статье описано наше исследование длиною в год,  из которого вы узнаете, почему PostgreSQL(и любое другое приложение) может падать из-за бага в ядре Linux, причём тут XFS и почему очистка памяти может быть не так полезна, как вы о ней думали.

Надругательство над C#, C++ и HLSL, игрища с булками и буферами, тройная полиглотность, SIMD, пепекторы, DirectX, экономия 800 Тб ОЗУ, новая парадигма программирования, многопроцессность, быстрая степень и многое другое.

В этой части я расскажу, как делал софт на собственном фреймворке, который управляет ядерной подсветкой и механической видеостеной.

Представляем наш синтез для языков России и СНГ. В этот раз получилось покрыть 20 языков, всего 95 голосов. От старой демки этот релиз отличается следующим:

Модель поддерживает SSML;

Модель стала быстрее ещё на 20-25% (она и так была супер быстрой);

С живыми дикторами были подписаны договоры на запись их голоса;

Запись велась в максимально высоком из практически доступного качестве;

Для ряда языков опубликованы модели простановки ударений и / или словари с ударениями в рамках silero-stress;

К модели синтеза применены все оптимизации, как к нашей прошлой публичной модели;

Для демки мы брали шумные публичные данные низкого качества. В этот раз всё хорошо - как следствие существенно выросло качество синтеза.

Люди с самых древних времён интересовались тремя главными вопросами мироздания: почему горит огонь, какой формы земля и мёртв ли Хабр. На последний я постараюсь ответить. И если коротко - я понятия не имею. Быстрый сбор статистики и интерпретация результатов растянулась в несколько раз, ведь чем дальше тем становится всё больше и больше вопросов. А искать ответы - вообще и близко не моё любимое занятие, поэтому все данные будут опубликованы для открытого доступа и возможно кто-то сможет уменьшить количество этих чертовски важных вопросов.

Всем привет! Последние несколько месяцев я работаю над пет-проектом — интерактивной образовательной платформой для изучения Web Audio API и принципов обработки и синтеза цифрового звука. На платформе пользователи смогут решать задачи, программируя на JavaScript прямо в браузере. Эти программы выполняются в изолированной среде — песочнице, где пользовательский код не может повлиять на работу самой платформы.

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

Альберт Эйнштейн, критикуя принцип неопределённости Гейзенберга, произносит знаменитую фразу: «Бог не играет в кости!». На что Нильс Бор, участник дискуссии, с юмором отвечает: «Эйнштейн, не учите Бога, что ему делать».

Я в IT довольно давно, как в том меме — мне этот мир абсолютно понятен. Но сейчас происходит какая‑то ерунда, учитывая разные обстоятельства в мире, считаю так делать крайне тупо. Не то, что бы я хотел пожаловаться, и увольнения, «оптимизации», «трансформации» были всегда. Это все бизнес и к нему нечего предъявить. Разные ситуевины бывают. Но я бы хотел как‑то вставить свое мнение по теме.

Годами, если вы хотите попасть в какую‑то крутую компанию, вам нужно было и до сих пор это «нормальная» практика устраивать десятки этапов собеседований. Без проблем я принимаю эту игру. Нам же важно найти того самого рок звезду, который будет решать поставленные перед ним задачи. Типо как в магазине выбираем принтер, правда сдать его обратно через 3 месяца нельзя. Листик с него вышел — значит все, поиспользовал, живи с ним дальше.