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

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

Осторожно, очень много картинок!

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

Сколько родилось отличных проектов open source, потому что у кого‑то руки чесались что‑то попробовать! Именно так было и в случае с Firecracker. В 2014 году компания Amazon запустила AWS Lambda, которую позиционировала как «бессерверную» вычислительную платформу. В AWS Lambda пользователь может задать функцию — скажем, десять строк кода на Python — а Lambda в ответ достроит всю требуемую инфраструктуру, чтобы сработала цепочка: прибывает HTTP‑запрос, вызывается функция, запрос обрабатывается, и, наконец, генерируется ответ.

Чтобы этот сервис работал безопасно и эффективно, Amazon нужно было разработать механизм, который позволял бы с минимальными издержками запускать виртуальные машины. Так появился Firecracker. Это монитор виртуальных машин (VMM), работающий совместно с Linux KVM. Он запросто создаёт «микро-VM» и управляет ими.

Привет, Хабр! Меня зовут Максим Кита, я разработчик баз данных, специализируюсь на анализе, планировании и выполнении запросов, а также на оптимизации производительности.

Я расскажу о высокоуровневой архитектуре ClickHouse, CI/CD, тестировании производительности, интроспекции, абстракциях и алгоритмах и выборе библиотек для высокопроизводительных приложений. Поделюсь ниндзя-техниками, которые помогут ускорить ваши системы. Вы сможете попробовать эти советы и практики на своем проекте и оценить насколько они полезны.

В C++ есть несколько "умных указателей" - std::unique_ptr, std::shared_ptr, std::weak_ptr. Также есть более нестандартные умные указатели, например в boost: intrusive_ptr, local_shared_ptr.

В этой статье мы рассмотрим новый вид умного указателя, который можно назвать static_ptr. Больше всего он похож на std::unique_ptr без динамической аллокации памяти.

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

И уж конечно, никогда при написании a * b мы не задумываемся о том, как реализовано умножение чисел a и b в нашем языке. Какие вообще есть алгоритмы умножения? Это какая-то нетривиальная задача?

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

Эффект иностранного языка при разрешении моральных дилемм заключается в том, что люди дают разные ответы в зависимости от того на каком языке формулируется вопрос. При этом ответ на иностранном языке чаще будет более прагматичным, чем на родном. В общем случае (не только моральных дилемм) использование иностранного языка уменьшает предвзятость (decision bias) при принятии решений. Эффект не зависит от конкретного языка, но по-видимому объясняется эмоциональным дистанцированием (которое уменьшается с ростом уровня владения языком).

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

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

Каков геометрический смысл решения? Какова вероятность придумать нерешаемое уравнение? Как выглядит пространство уравнений, имеющих целочисленные решения? Куда деваются корни квадратного уравнения, когда оно не имеет действительных решений и откуда берутся комплексные корни? Как выглядят квадратные уравнения "на самом деле"?

Сегодня мы узнаем:

- можно ли считать людей, которые инвертируют оси в играх, лицами с нетрадиционной ориентацией;

- что такое фокусное расстояние объектива и для чего оно нужно;

- какой угол обзора надо делать у камер, чтобы монитор выглядел, как окно в виртуальный мир;

- как правильно фотографировать;

- и сделаем простенький симулятор дрифта.

Предисловие

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

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

Давайте же исправим эту вопиющую несправедливость, и прольём свет истины на возможности компилятора по предотвращению ошибок.

Не так давно я захотел написать свой шахматный движок. На удивление в Интернете нашлось не так много хороших статей на эту тему. Были статьи с довольно слабыми программами, многие из которых даже умудрялись пропускать некоторые важные правила. А были статьи с хорошими программами (некоторые из них были даже чуть лучше чем получилось у меня в итоге), но там авторы рассказывали лишь основные идеи, пропуская подробности, из-за чего написать что-то свое по таким статьям было проблематично. Поэтому после написания своей программы, я решил написать статью, дабы облегчить жизнь интересующимся в данной теме. Я не претендую на лучшую шахматную программу или на чистейший код, но эта статья будет хорошим и легким началом для тех, кто хочет написать что-то свое.

Мне всегда нравилась визуальная эстетика дизеринга (dithering, псевдотонирование, псевдосмешение цветов), но я не знал о том, как он применяется. Поэтому я провёл кое-какие изыскания. Эта статья может содержать отголоски ностальгии, но в ней не будет никаких следов Лены.

Однажды много лет назад один немолодой профессор задал мне задачку о перестановке стрелок часов. Точной формулировки за давностию лет я не помню, но поиск в интернете привёл меня к «Занимательной алгебре» Я. И. Перельмана, которая была впервые опубликована в 1933 году:

Возьмём положение стрелок в 12 часов. Если бы в этом положении большая и малая стрелки обменялись местами, они дали бы всё же правильные показания. Но в другие моменты, — например, в 6 часов, — взаимный обмен стрелок привёл бы к абсурду, к положению, какого на правильно идущих часах быть не может: минутная стрелка не может стоять на 6, когда часовая показывает 12. Возникает вопрос: когда и как часто стрелки часов занимают такие положения, что замена одной другою дает новое положение, тоже возможное на правильных часах?

Что любопытно, эта формулировка восходит к книге Александра Мошковского «Альберт Эйнштейн: беседы с Эйнштейном о теории относительности и общей системе мира», опубликованной в 1921 году на немецком языке, и уже в следующем году (!) переведённой на русский язык (и, судя по каталогу РГБ, с тех пор её и не переиздавали; доступен английский перевод).

В процессе изучения разных алгоритмов и структур данных приходит понимание, что не все они применимы в прикладных задачах (в отличие от задач про Васю и Петю/Алису и Боба). Но тот факт, что алгоритм/структура данных не является полезной на практике не означает, что идеи в них содержащиеся не привлекают пытливые умы даже из чистого любопытства. Потому речь пойдёт о красивых (субъективно) и, что важно, простых с точки зрения концепции структурах данных. 

Помните: если что-то не компилируется, это псевдокод. 

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

Что общего у нормального распределения, конечных автоматов, хеш-таблиц, произвольных предикатов, строк, выпуклых оболочек, афинных преобразований, файлов конфигураций и стилей CSS? А что объединяет целые числа, типы в Haskell, произвольные графы, альтернативные функторы, матрицы, регулярные выражения и статистические выборки? Наконец, можно ли как-то связать между собой булеву алгебру, электрические цепи, прямоугольные таблицы, теплоизоляцию труб или зданий и изображения на плоскости? На эти вопросы есть два важных ответа: 1) со всеми этими объектами работают программисты, 2) эти объекты имеют сходную алгебраическую структуру: первые являются моноидами, вторые — полукольцами, третьи — алгебрами де Моргана.

Каждый, кто когда-либо пробовал собрать программу на C/C++ через кросс-компиляцию знает, насколько болезненным может быть этот процесс. Главными причинами столь печального положения вещей являются недружелюбность систем сборки при конфигурации кросс-компиляции, а также запутанность процесса настройки набора утилит (тулчейна).

Одним из основных виновников этих проблем, по моему опыту, является тулчейн GNU — древний мамонт, на котором много десятилетий строится весь мир POSIX. Подобно многим компиляторам былых времён, семейство GCC и binutils никогда не ориентировалось на поддержку множества различных целей сборки в одной установке, и единственным способом хоть как-то добиться желаемого была настройка полной кросс-билд-системы для каждой целевой платформы на каждом хосте.