Когда я был начинающим, я мог писать простые приложения на C# и C++. Долго игрался с консольными прогами, пощупал десктопные, и в какой-то момент захотел сделать сайт. Меня ждал большой сюрприз — чтобы делать сайты, одного сишарпа мало. Надо ещё знать жс, хтмл, цсс и прочую фронтовую хрень. Я потратил около недели на эти вещи, и понял — не мое. Я мог написать какой то код на джаваскрипт, но он не содержал типов, и я никак не мог взять в толк — как к этому вообще подходить. Это какое-то игрушечное программирование. Ну и забросил к чертям.

Уже потом, работе на третьей, меня перевели в отдел, где делали веб. Я подумывал уволиться, но мне объяснили — там тайпскрипт, тайпскрипт — это такой сишарп для браузера.

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

Привет, интернет.

Решил написать статью об указателях на методы классов. Недавно мне пришлось столкнуться с тем, как они работают изнутри, когда писал некоторые вещи ориентированные под компилятор. Эти указатели работают не совсем как обычные указатели, не имеют возможности быть приведенными в void, и часто имеют размер больше 8 байт. Информации на эту тему в интернете я нашел относительно немного, потому решил разобраться сам.

Месяц назад я попытался сосчитать, сколько разных инструкций поддерживается современными процессорами, и насчитал 945 в Ice Lake. Комментаторы затронули интересный вопрос: какая часть всего этого разнообразия реально используется компиляторами? Например, некто Pepijn de Vos в 2016 подсчитал, сколько разных инструкций задействовано в бинарниках у него в /usr/bin, и насчитал 411 — т.е. примерно треть всех инструкций x86_64, существовавших на тот момент, не использовались ни в одной из стандартных программ в его ОС. Другая любопытная его находка — что код для x86_64 на треть состоит из инструкций mov. (В общем-то известно, что одних инструкций mov достаточно, чтобы написать любую программу.)

Я решил развить исследование de Vos, взяв в качестве «эталонного кода» компилятор LLVM/Clang. У него сразу несколько преимуществ перед содержимым /usr/bin неназванной версии неназванной ОС:

1. С ним удобно работать: это один огромный бинарник, по размеру сопоставимый со всем содержимым /usr/bin среднестатистического линукса;
2. Он позволяет сравнить разные ISA: на releases.llvm.org/download.html доступны официальные бинарники для x86, ARM, SPARC, MIPS и PowerPC;
3. Он позволяет отследить исторические тренды: официальные бинарники доступны для всех релизов начиная с 2003;
4. Наконец, в исследовании компиляторов логично использовать компилятор и в качестве подопытного объекта :-)

Начну со статистики по мартовскому релизу LLVM 10.0:
В прошлом топике комментаторы упомянули, что самый компактный код у них получается для SPARC. Здесь же видим, что бинарник для AArch64 оказывается на треть меньше что по размеру, что по общему числу инструкций.

А вот распределение по числу инструкций:

Armored Warfare: Проект Армата — бесплатный танковый онлайн-экшн, разрабатываемый Allods Team, игровой студией MY.GAMES. Несмотря на то, что игра сделана на CryEngine, достаточно популярном движке с неплохим realtime render’ом, для нашей игры приходится многое дорабатывать и создавать с нуля. В этой статье я хочу рассказать о том, как мы реализовывали хроматическую аберрацию для вида от первого лица, и что это такое.

Эта статья является переводом поста Chris Hodapp Embedding Haskell: Compilers, and compiling compilers В своём посте автор рассматривает различные подходы к использованию Haskell для написания кода для встраиваемых систем. Предоставим слово автору.

В моем последнем посте упоминалось, что некоторые вещи требуют лучшего объяснения, потому что я всегда пытаюсь объяснить и уточнить.

Этот блог посвящен использованию Haskell со встраиваемыми системами. Что это хотя бы значит? Мы видим пару широких категорий (которые отражают слайды на последней странице, а также наша страница ссылок):

• Полная компиляция: компиляция кода на Haskell для встраиваемого назначения.
• Ограниченная компиляция: компиляция некоторого ограниченного подмножества кода на Haskell для встраиваемого назначения.
• Хостинг EDSL и компилятора: хостинг в Haskell, EDSL и компилятор для встраиваемого назначения.

Я работаю в коммерческой разработке с 2011 года. С конца 2012 занимаюсь разработкой под iOS. Свою первую техническую статью я написал на Хабре в начале 2017 года про подход к локализации мобильных приложений. Потом выпустил ещё несколько статей по iOS-разработке на Хабре и в конце 2017 года я перешёл в новую компанию и решил вести блог про solution architecture https://medium.com/@nvashanin, где начал описывать общие концепты, обязанности архитектора, его скилл-сет и т.д. К лету 2020 года количество просмотров моих статей перевалило за 800 тысяч, а количество времени, которое люди потратили на прочтение — больше 6 млн минут, или около 12 лет чистого времени. Флагманская статья была переведена другими людьми на разные языки: например, польский или испанский.

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

Десять лет назад был анонсирован systemd, который устроил революцию в управлении системой дистрибутивов Linux, тем самым разделив пользователей Linux на несколько лагерей. Качество и природа дебатов не сильно улучшилась со времён пламенных войн 2012-2014 годов, и systemd всё ещё остаётся не до конца понятым и изученным инструментом и с технической, и с общественной стороны, несмотря на пристальное внимание к нему сообщества.

Это пост не совсем о том, как пользоваться systemd. Тут, скорее, будет говориться об истории его возникновения, о его компонентах в целом, и о том, как понять систему, которая начиналось как просто PID 1 и стала тем, что я бы назвал middleware современного дистрибутива Linux.

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

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

Но прежде чем начать речь о systemd, хочу рассказать об init.

В данной статье я хочу рассказать о небольшом и забавном проекте выходного дня по передаче файлов через анимированные QR коды. Проект написан на Go, с использованием Gomobile и Gopherjs – последний для веб-приложения для автоматического замера скорости передачи данных. Если вам интересна идея передачи данных через визуальные коды, разработка веб-приложений не на JS или настоящая кроссплатформенность Go — велкам под кат.

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


Рисунок 1. Небольшая модификация канонической решётки Фибоначчи может привести к улучшению расстояния упаковки (максимального расстояния между ближайшими соседями) на 8,3%.

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

Я начал собирать рабочую станцию под задачи машинного обучения. Поставил в неё, кроме прочего, отличный процессор, много памяти, достойную видеокарту. Практически все мои задачи я решал в Ubuntu. Правда, для работы с текстами мне нужен был Microsoft Office. Онлайновый Office тогда ещё не появился, и, давайте называть вещи своими именами, LibreOffice — это просто ужас какой-то. Для меня решением стала двойная загрузка в конфигурации Ubuntu — Windows 10. Мне невероятно понравилось то ощущение свободы, которое испытываешь, переходя с ОС от Apple на Ubuntu. А возможности, которые открываются перед тем, кто сам собирает свой компьютер, практически бесконечны.



Двойная загрузка в течение долгого времени полностью меня устраивала. А когда я миллион раз ей воспользовался, появилась технология WSL (Windows Subsystem for Linux, подсистема Windows для Linux). Когда это случилось, я начал решать некоторые свои Linux-задачи в Windows. Правда, даже так, многого для полноценной работы мне ещё не хватало. Но теперь, с выходом WSL 2, у меня возникает такое ощущение, что новая версия WSL способна кардинальным образом изменить ситуацию. Сегодня я предлагаю поговорить о том, как, с помощью WSL 2, перенести задачи по разработке программ из Linux в Windows 10. Я расскажу о новых возможностях WSL 2, и о том, что можно ожидать от этой подсистемы в будущем.

Введение

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



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

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

Статья 2012 года

Видеоигры сейчас один из самых прибыльных видов развлечений в Америке, а также один из самых подростковых, глупых и не «нагружающих» мозг. Серьезно? По крайней мере, так считает Джонатан Блоу. Он — самый жесткий критик игровой индустрии и ее самый ценный разработчик, который стремится изменить наше представление об играх и сторителлинге. Следующим релизом, The Witness, Блоу может укрепить свое наследие или закончить карьеру. Может ли истинное искусство процветать в индустрии с многомиллиардным доходом от лазерных пушек и плотоядных пришельцев?



Как и многие состоятельные люди, Джонатан Блоу хорошо помнит момент, когда он стал богатым. В то время, в конце 2008 года, он был в минусе на 40 000 $ и жил в скромной квартире в Сан- Франциско, более трех лет тщательно оттачивая свою видеоигру, Braid — в жанре платформер-головоломка с возможностью изменения масштаба времени. (как если бы, Super Mario Bros. встретился с Борхесом), в которую Блоу влил еще 200 000 $. Хотя Braid был выпущена и разрекламирована прессой, на августовском сервисе Microsoft’s Xbox Live Arcade, Блоу не увидел ни цента от игры, пока в один осенний день он не сел в кафе in the city’s Mission district.



«Я открыл свой веб-браузер и, святые угодники, теперь я богат», — вспоминает он. «На моем банковском счете было много нулей».

Однако, на этом сходство Блоу со средним миллионером заканчивается, потому, что в отличие от большинства богатых людей, он, кажется, слегка раздражен воспоминанием о том, как разбогател. Когда Блоу сказал мне во время типично метафизического разговора в парке возле его офиса в Беркли, что его неожиданность оказалась «абсурдной», он не имел в виду это в причудливом смысле «Можете ли вы поверить в мою удачу?» он имел в виду это в философском, разочарованно-горьком смысле глубоко ироничной шутки Провидения.

"Кто ни разу не ошибался в индексировании цикла, пусть первый бросит в деструкторе исключение."

— Древняя мудрость

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

В конце концов, это просто некрасиво.

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

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

Так как же писать красивый, понятный, эффективный код, а также иметь возможность параллелить большие вычисления лёгким движением пальцев по клавиатуре?

Сегодня, когда всё популярнее становится трассировка лучей (ray tracing) выполняемая из «глаза» камеры, этот урок нужно усвоить заново: код становится лучше, а жизнь — проще, если центр пикселя находится в координате (0,5; 0.5). Если вы уверены, что делаете всё правильно, то продолжайте в том же духе, для вас в статье нет ничего нового. Прочитайте лучше вот это.

Смысл размещения центра пикселя в (0,5; 0,5) впервые объяснила (по крайней мере, мне) милая короткая статья Пола Хекберта «Что такое координаты пикселя?» из книги 1990 года Graphics Gems, стр. 246-248.

Сегодня эту статью найти трудновато, поэтому вкратце изложу её суть. Допустим, у нас есть экран с шириной и высотой 1000. Давайте рассмотрим только ось X. Может возникнуть искушение назначить 0,0 центром самого левого пикселя в строке, 1,0 — центром следующего, и так далее. Можно даже использовать округление, при котором координаты с плавающей запятой 73,6 и 74,4 переносятся в центр 74,0.

Однако над этим стоит поразмыслить. При таком сопоставлении левый край будет находиться в координате -0,5, а правый — в 999,5. С такой системой неудобно работать. Хуже того, если к значениям координат пикселей применяются различные операторы наподобие abs() или mod(), то такое сопоставление может привести к незначительным погрешностям на краях.

Проще работать с интервалом от 0,0 до 1000,0, в котором центр каждого пикселя имеет дробную часть 0,5. Например, тогда целочисленный пиксель 43 будет иметь красивый интервал значений значений входящих в него субпикселей от 43,0 до 43,99999. Вот чертёж из статьи Пола:

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

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

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

Долгое время Rust позиционировался исключительно как язык для системного программирования. Попытки использовать Rust для высокоуровневых прикладных задач зачастую вызывали усмешку у значительной части сообщества: зачем использовать инструмент в том качестве, на которое он не рассчитан? Какая польза от возни с типами и анализатором заимствований (borrow checker), если есть Python и Java со сборкой мусора? Но другая часть сообщества всегда видела потенциал Rust именно как языка прикладного, и даже находила его удобным в использовании для быстрого прототипирования — во многом благодаря его особенностям, а не вопреки им.

Когда Дудь выпустил ролик про долину, я очень сильно расстроился. Я ещё не знал, про что он конкретно, но мозг моментально нарисовал: манерные успешные успехи говорят про преодолевание, дух предпринимательства, поднятые миллионы баксов, и как сильно их говноприложенька влияет на мир.

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

Мои новостные ленты были завалены обсуждениями, восхищением и критикой выпуска. Каждый раз читая что-то об этом, я испытывал непонятную почти физическую боль. Ну хорошо, главный журналист страны рассказал про мою индустрию, но рассказал не так, как хочу я. С этим можно жить. Да, со всей своей преисполненностью и трушной технарскостью, я все ещё маленький завистливый чмошник. Я тоже хочу сидеть в кофейне в Пало-Альто и смотреть, как мне выписывают чек на пять миллионов долларов. Но смотрите, я вырос в России и давно научился не обращать внимания на свою патологическую зависть. Мне давно не бывает от нее больно.

Бомбанул я точно не от зависти — и я долго не знал, почему.

Вот как извлечь из него максимум.


^{Изображение: Люси Гутьеррес}

«Неправда, что ты больше никому не нужен».

Эти слова исходили от пожилой женщины, сидящей позади меня на позднем вечернем рейсе из Лос-Анджелеса в Вашингтон. В самолете было темно и тихо. Мужчина, которого я счел за ее мужа, почти беззвучно пробормотал в ответ что-то вроде «Лучше бы я был мертв».

И снова женщина: «О, прекрати это говорить».

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

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

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

Привет, Хабр!

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