Есть оптимизации, польза от которых очевидна всегда или почти всегда. Например, не делать лишнюю проверку лучше, чем делать. Не считать два раза одно и то же обычно лучше, чем считать (если только мы не упёрлись в нехватку регистров или имеем другие подобные проблемы на нижнем уровне). Вычислять выражения вне цикла выгоднее, чем в цикле. И так далее.

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

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

Что такое Kubernetes?

- Вы работали с Кафкой?
- Нет, только читали.

За несколько десятилетий развития ИТ систем разработчики накопили огромный опыт хранения и обработки данных. Различные СУБД позволяют с помощью запросов извлекать нужные данные за определенный период и обрабатывать их так как необходимо. Однако, со временем увеличились вычислительные мощности серверов, пропускная способность каналов связи, и соответственно, возникла необходимость обрабатывать бОльшие объемы данных за единицу времени. И тут выяснилось, что при всем многообразии различных решений для хранения данных, отсутствуют решения для обработки непрерывных потоков больших объемов данных. Для решения этой проблемы стали появляться различные системы, такие как системы обмена сообщениями и агрегирования журналов. Но они не могли в полной мере обеспечить нужную производительность на больших, непрерывных потоках данных.

Для решения этой проблемы в LinkedIn решили создать нужное решение что называется с нуля. Разработчики решили отказаться от хранения больших объемов данных, как в реляционных базах данных, хранилищ пар «ключ/значение», поисковых индексов или кэшей, а рассматривать данные как непрерывно развивающийся и постоянно растущий поток и проектировать информационные системы и архитектуру данных — на этой основе. Так появилось решение Apache Kafka, которое изначально использовалось для обеспечения функционирования работающих в реальном масштабе времени приложений и потоков данных социальной сети. Но сейчас это решение используется во многих крупных компаниях. Посмотрим подробнее как оно устроено.

Исследование Statista в России показывает, что около 60% компаний применяют технологию оркестрации контейнеров в рамках своей инфраструктуры. При этом самостоятельная разработка на Open Source для решения этой задачи значительно повышает требования к скиллам команды и характеризуется высокой стоимостью. Другой вариант — облачные PaaS-сервисы, но они зачастую имеют ограниченный набор инструментов, а зарубежные платформы ушли с российского рынка.

Есть ли сегодня в России аналоги западным платформам контейнеризации? Мы решили изучить этот вопрос и пригласили директора по развитию Deckhouse компании «Флант» Артёма Кожокина, чтобы подробно расспросить про их платформу оркестрации контейнеров.

Ниже — ключевые тезисы нашей встречи, а полную расшифровку митапа можно почитать здесь.

Это объект Pizza, там хранится инфа о латте, а заказали его в Restaurant или в Pizzeria? Неудобно? Максимально. Мы читаем код существенно больше, чем пишем. И хочется сразу понимать, что происходит, не играя в квесты «что имел в виду автор», «да как это работает» и «я снова ничего не понял». Без навыка давать хороший нейминг невозможно писать качественный и поддерживаемый код. Про нейминг говорят заодно, в рамках архитектуры и общих инженерных практик. В статье поговорим про него отдельно.

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

2 марта 2022 года Национальный координационный центр по компьютерным инцидентам (НКЦКИ) выпустил бюллетень со списком рекомендаций для противодействия угрозам безопасности информации. В дополнение к бюллетеню опубликованы списки IP адресов и DNS имён для блокировки. В данной статье будет описано как добавить данные списки в pfSense и настроить фильтрацию. Несмотря на то, что прошло достаточно времени с момента публикации списков, они ещё не потеряли своей актуальности, да и при выходе новых эта статья так же будет полезна. В статье не обсуждаются вопросы импортозамещения pfSense и схожие темы. Описано как настроить тем у кого всё работает, и кто не собирается прямо сейчас менять pfSense на другой файрвол. Подразумевается, что читатели обладают достаточным навыком работы с pfSense.

Так получилось, что я очень люблю использовать SQLite СУБД.

Программируя на ассемблере, я иногда нуждаюсь в полноценной СУБД. Мои программы редко превышают в размере несколько сотен килобайт. Понятно, что использовать с ним СУБД в несколько сотен мегабайт по меньшей мере просто смешно, а в конце концов, очень неудобно – сразу возрастают требования к оборудованию и сложности установки и настройки, а в итоге уменьшается надежность всей системы.

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

К примеру, я использовал SQLite в моем движке форума AsmBB о котором уже писал на Хабре. (Кстати, после этого он так и не упал).

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

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

Быстрый поиск по Интернету показал, что есть несколько расширений SQLite для шифрования БД. К сожалению, официальное расширение SEE несвободно и вообще продается за деньги.

Но, конечно, свято место пусто не бывает и я сразу наткнулся на расширение SQLeet. И в нем мне понравилось буквально все.

В качестве предисловия оговорюсь, что на Хабре я впервые, решил представить свою дебют на этой платформе, так сказать. Речь здесь не пойдёт о рисовании картин с использованием AI и графических паттернов. Скорее наоборот, превращение классического изобразительного исксства в многочисленную последовательность нейронных сетей в итоговым кодом в заключительном виде. Расскажу предысторию. В начале этого года, случайным образом, попало в моё поле зрения одно заманчивое словосочетание - digital art. И так как я в теме crypto уже давненько, я не смел не поинтересоваться, каким образом искусство (будь то живопись или музыка) коррелирует с криптой, и как это происходит (и для чего))) на просторах блокчейна. В итоге ознакомления с этой идеей, и не только идеей, но и инфраструктурой NFT (Non-Fungible-Token, невзаимозаменяемый цифровой актив), я с радостью обнаружил что уже хочу создать что-то подобное, но в своём, авторском исполнении. Парой слов опишу, что зверёк по имени НФТ это хэшированное изображение в любом формате,  записанное в сети блокчейн в формате, являющегося аналогом ERC-721 в сети Ethereum (для тех кто ещё не в курсе темы). Задуманному быть конечно, но сказать легко, а вот сделать - труднее. Особенно, когда делаешь что-то впервые. Начал я с изучения подобных платформ на просторах всемирной паутины, начиная с крупнейших маркетплейсов opensea.io, makersplace.com,  и не очень крупных, pixeos.art, ghostmarket.io и много много других.

Кроме маркетплейсов, я обнаружил чисто minting-платформы, как правило тематические, т.е. они занимаются только созданием NFT карточек и как-правило одного направления. Криптокотики всякие (с них всё и началось!), Криптопанки и прочая фауна. Нашлось кроме всего пару аутсайдеров, которые вовсе создавали неформатные NFT, с прицелом на автоматическое масштабирование за счёт пользователей, к примеру на одной из платформ за NFT контент принимаются уникальные ссылки в интернете, на другой - регистрируются домены, а заодно и снимок с NFT. Не буду сильно углубляться в обозревание ежедневно растущего формата цифровых активов NFT, а лучше наконец-то перейду к своей задумке.

• работает даже тогда, когда компьютер выключен (но электропитание подаётся);
• имеет доступ ко всему содержимому оперативной памяти компьютера;
• имеет внеполосный доступ к сетевому интерфейсу.

На новом рабочем месте меня посадили за ПК, оборудованный процессором Ryzen 2600 и видеокартой Radeon RX 580. Попробовав обучать нейронные сети на процессоре, я понял, что это не дело: уж слишком медленным был процесс. После недолгих поисков я узнал, что существует как минимум 2 способа запуска современных библиотек машинного обучения на видеокартах Radeon: PlaidML и ROCm. Я попробовал оба и хочу поделиться результатами.

▍Как все начиналось

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

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

• Я держу гит-репозиторий локально у себя на компе
• Все пароли защищены GPG шифрованием, поэтому даже при получении SSH-доступа к моему компьютеру утечка не повлияет на безопасность