Всё вроде должно быть просто

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

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

Многие, возможно, думают, что работа с байт-кодом Java (будь то чтение или, тем более, генерация) — это какая-то особенная магия, доступная только продвинутым разработчикам с особенно крутым опытом. На самом деле, я считаю такую точку зрения ошибочной. JVM устроена гораздо проще, чем CPU; она оперирует такими высокоуровневыми понятиями как классы, интерфейсы, методы, а не просто лопатит байты в памяти. В отличие от CPU, который легко уронить криво сгенерированным машинным кодом, JVM заботливо отверифицирует любой байт-код и в общем не даст выстрелить в ногу.

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

Весь приведённый код доступен в моём репозитории.

Во французском сабреддите я наткнулся на пост с интересной гипотезой:

Чем ближе точка к вокзалу, тем хуже там кебаб.

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

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

Код решения доступен:

* На Гитхабе

* На (временном) запасном аэродроме

* В виде картинки в самой статье.

О чем это, вкратце?

Мне давно хотелось написать систему, которая усиливала бы не споры, а их сходимость к ответу. В которой могли бы участвовать аргументы всех: человека, его гнуснейшего политического оппонента, и искусственного интеллекта со дна датацентра. В которой информация бы не цензурировалась прежде полного её провала улучшить хоть какое‑то предсказание. Систему, где решения вычисляет не имеющий личных интересов НИКТО. Которая могла бы распространяться просто в процессе работы, без опоры на какой‑либо центр.

Три года назад я очертил проблему и мысли по её решению в статье «цифровой вытрезвитель» на Хабре. Сегодня я выкладываю здесь прототип одного из возможных решений под Телеграм.

У нас есть 3 "теории всего" - научная картина мира (все сводится к законам физики), информатика (все сводится к битам) и фундамент математики (все сводится к логике). Именно фундамент математики представляет особый интерес, так как он является фундаментом для двух других фундаментов и имеет глубокий философский смысл. Последние 2 года я сильно им увлекся и проделал довольно большую работу по углубленному изучению теории типов (Calculus of Constructions), и готов поделиться результатами, а также рассказать о девяти направлениях, где можно применить это на практике. Очень многое получилось лучше, чем я планировал. Изначально перспективы были не очень понятными, и поэтому я не рассказывал друзьям и коллегам про мою работу в этом направлении и называл это «Секретный Проект». Но теперь, когда многое прояснилось и получилось, можно поделиться успехом. Собственно, в этой статье я расскажу вам не только про сам фундамент математики, а еще его связь с ежедневной работой программиста, а также с Computer Science/Data Science и AI/ML. Я вам нарисую большую и красивую картину, на которой все понятно и логически следует из маленького набора правил выведений типов (11 штук) и аксиом теории множеств (9 штук).

У нас есть 3 фундамента математики — теория множеств (удобна для человека), теория типов (удобна для компьютера) и теория категорий (не знаю, зачем она вообще нужна). Они примерно одинаковой мощности и одну можно выразить внутри другой. Особый интерс представляет именно теория типов, тк ее довольно легко можно запрограммировать внутри компьютера и использовать как строгий фундамент для других теорий, который не дает совершить ошибку и проверяет каждое ваше действие.

Помните сравнение потребления памяти для асинхронного программирования на популярных языках 2023 года?

Мне стало любопытно, как поменялась ситуация за один год на примере самых новых версий языков.

Давайте снова проведём бенчмарки и изучим результаты!

Базовые distroless-образы GoogleContainerTools часто упоминаются как один из способов создания (более) маленьких, (более) быстрых и (более) безопасных контейнеров. Но что на самом деле они собой представляют? Зачем они нужны? В чем разница между контейнером, созданным на distroless-базе, и контейнером, созданным с нуля? Давайте разберёмся.

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

Столкнувшись много раз подряд с тем, что найти что-то толковое довольно непросто, я решил попробовать распутать это узел и предложить для русскоязычных читателей свой справочник классных библиотек на С++. Я исходил из этого источника. Это очень многогранный и объемный список библиотек языка С++, но, скажем так, у меня были к нему вопросы. Потому я сделал перевод, затем значительно улучшил его в плане содержания (далее объясню, как, почему и зачем). На выходе получилось около 1000 библиотек. Как в сказке). Они, конечно, не покрывают все возможные задачи и предметные области, но поверьте, они затрагивают действительно многое.

Всем привет! На связи Олег Сапрыкин, технический директор по инфраструктуре и тимлид DevOps-команд во «Фланте». В марте 2024 года мы с Андреем Радыгиным (ex-главный архитектор по внедрению Deckhouse) выступили на конференции DevOpsConf. Эта статья — текстовый вариант нашего доклада о развитии и нашем опыте использования Stateful в Kubernetes.

Мы рассказали, как оценивать Stateful-компонент, прежде чем запускать его в Kubernetes, показали нюансы работы с такими приложениями, а также поделились особенностями конфигурирования и опытом использования некоторых Stateful-операторов — ClickHouse, Redis, Kafka, PostgreSQL и MySQL.

Изучение внутреннего устройства приложений, созданных с использованием нативной опережающей компиляции (AOT).

Hello world!

Представляю вашему вниманию бонусную часть практического руководства по Rust.

• Первая часть
• Вторая часть
• Третья часть
• Четвертая часть

Другой формат, который может показаться вам более удобным.

Руководство основано на Comprehensive Rust — руководстве по Rust от команды Android в Google и рассчитано на людей, которые уверенно владеют любым современным языком программирования. Еще раз: это руководство не рассчитано на тех, кто только начинает кодить 😉

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

Меня увлекла тема отказоустойчивости, а конкретно - отказоустойчивой работы с файлами. В этой статье я попытался соединить все полученные знания:

Кто участвует в процессе записи

Ошибки, которые могут произойти

Что от нас зависит, а что нет

И самое главное - как это этого защититься

В прошлых двух частях мы ознакомились с синтаксической моделью F#-кода и с инструментами для неё. Объёмный пример туда уже не влез, но необходимость в нём осталась. Так родились ещё две заключительные части цикла. Их объединяет общий проект, но в остальном они представляют собой сборную солянку фактов, практик и наблюдений, которые было бы трудно разместить в каталогизированной документации.

Мы возьмём сугубо игровую задачу с понятным результатом и на её примере узнаем:

• на какие ноды AST стоит обратить внимание в первую очередь;
• где Fantomas-у нельзя доверять;
• где можно хакать;
• где лучше придерживаться пуризма;
• и как на F# можно строить Fluent API.

В этой части мы сосредоточимся на общей организации генератора, входных данных и основных элементах AST. В следующей сделаем то же самое, но на более сложном уровне, сместив повествование в сторону устройства Fluent API.

Hello world!

Представляю вашему вниманию первую часть практического руководства по Rust.

• Вторая часть
• Третья часть
• Четвертая часть
• Бонус

Другой формат, который может показаться вам более удобным.

Руководство основано на Comprehensive Rust — руководстве по Rust от команды Android в Google и рассчитано на людей, которые уверенно владеют любым современным языком программирования. Еще раз: это руководство не рассчитано на тех, кто только начинает кодить 😉

Да вымереть не могут.

Откуда это всё пошло? Чем так условные «программисты» не угодили? И почему именно программисты?

Ваш покорный слуга работал с MSSQL с версии 6.5, но в качестве экзотики застал версии 6.0 и 4.2. Да, я супер стар!

Но осталось ли в MS SQL что-либо с тех времен?

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

Ещё один способ играть в старые игры на современном железе. Шок от первого использования PCeM v17. И то, как он вернул радостные ощущения от игры с настоящим «Voodoo» без NGlide Wrapper.

Как и всегда, полно дилетантства, непрофессионализма и прочей ереси.