Разработка

Привет, Хабр! На связи Антон Дятлов, инженер по защите информации в Selectel. Хранение конфиденциальных данных в PostgreSQL в открытом виде — мина замедленного действия. Неприятности в будущем становятся неизбежными. Достаточно одной успешной SQL‑инъекции, утечки резервной копии или компрометации доступа к серверу, чтобы вся чувствительная информация — от персональных данных пользователей до API-ключей — оказалась в руках злоумышленников.

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

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

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

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

Статья рассчитана на читателей, которые не являются гуру C++ или знатоками тонкостей языка, но в целом знакомы с языком и его идеями, хотя знание ассемблера x86 не требуется, я буду прикладывать ссылки на примеры кода quickbench, чтобы объяснить, почему даю те или иные советы.

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

Я долгое время занимаюсь построением 3D копий городов в проприетарном игровом движке на основе картографических данных. Суммарно это сложная задача, успех выполнения которой заключется в решении небольшого набора больших проблем. Одной из таких проблем является отрисовка точного ландшафта на основе реальных данных. Далее я постараюсь расказать обо всех R&D этапах и технических особенностях, с которыми пришлось столкнуться, а вконце будет несколько сравнений сгенерированного ландшафта с фотографиями реальных мест.

Предыстория

Захотелось мне как-то перевести управление станком на ПЛИС, а для этого понадобилось ядро процессора. Поиск на opencores не особо помог, x86 лицензированный, ARM лицензированный, NIOS… ну, вы поняли. Если выдумывать свою систему команд, может получиться криво, и главное, где брать компилятор. В общем, всё было сложно, так что на время идею пришлось отложить.
С недавних пор ситуация изменилась, архитектура RISC-V пошла в массы.

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

^{Руководитель: Хочешь техлидить новый проект?}

^{Я: Да, конечно. А что за проект?}

^{Руководитель: Распределённые бэкенды на Go.}

^{Я: Go? Но я же скалист-функциональщик…}

^{Чуть позже}

^{Коллега: Слышал, что ты будешь техлидить другой проект — вы там тоже Scala завозить будете?}

^{Я: Нет, будем писать на Go.}

^{Коллега: Ты что, бросаешь Scala и нашу тусовку?!}

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

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

Мы начинали с обычного ELK-стека, логи приходили на logstash, записывались в Elasticsearch, а пользователи смотрели их в Kibana. Потом в эту схему добавилась Kafka, так как мы понимали, что на пиках нагрузок не успеваем записать все логи в Elasticsearch. Всё это располагалось в одном ЦОДе, а в Kafka была единая очередь. В результате горизонтального масштабирования Elasticsearch разросся до 30+ нод. Данная схема справлялась с нагрузкой в 100 тысяч документов в секунду.

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

Привет, Хабр! На связи Филипп Бочаров, руководитель платформы наблюдаемости и мониторинга для более 400 продуктов экосистемы МТС, и Юлия Тальцкова, ведущий инженер сервиса логирования и кластеров Open Search с более 400 терабайтами логов клиентов. Этот материал написан на основе нашего доклада для конференции Highload++

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

Совсем недавно осознал, что нашему Open Source HW проекту marsohod.org уже пятнадцать лет. С ума сойти можно. Когда время-то пролетело? Как-то даже не верится. Наверное можно попробовать подвести какие-то итоги. Ну или сделать хоть самому себе отчет о проделанной работе..

Я знаю многих программистов и руководителей в IT компаниях, которые недолюбливают математиков и в частности считают их далёкими от жизни идиотами из-за их утверждений в духе "нельзя отсортировать последовательность быстрее, чем за nlogn" -- ведь это очевидным образом неверно, есть же сортировка подсчетом и radix sort. Нюанс в том, что описанное выше -- это распространённая некорректная трактовка одной из ключевых теорем об алгоритмах сортировок, корректное утверждение выглядит так: "не существует алгоритма, который бы гарантированно находил перестановку n элементов, приводящую к возрастающему порядку, быстрее чем за nlogn используя только операции попарного сравнения". В этом утверждении больше слов, оно более сложно в плане когнитивного восприятия, ключевой момент обозначил жирным шрифтом, чувствуете разницу?

В статье хочу рассказать об этой теореме и ещё о двух, на которые я наткнулся когда вел занятия по информатике в 9-11 классах будучи студентом старших курсов. Эти теоремы для меня были удивительным открытием, радовался вне себя когда вывел сам одну из них - её я не встречал ни в одном учебнике по информатике. В последствии все три теоремы были найдены в недрах Кнута, но чёрт побери, их поиск был сложнее, чем вывод!

Если я ещё не убедил Вас прочитать статью, то вот моя последняя попытка: в статье объясню почему пузырёк -- это бесполезная фигня, но внезапно практически также работающая сортировка вставками -- это супер важная сортировка, являющаяся частью std::sort в MSVC, GCC и Clang. Расскажу, каким интересным свойством оптимальности обладает сортировка выбором, являющаяся в теории такой же неэффективной как пузырёк.

Мало какая компания пользуется среди поклонников компьютера ZX Spectrum такой любовью и уважением, как Ultimate Play the Game. За свою недолгую историю она выпустила два с лишним десятка игр, бóльшая часть которых моментально становились бестселлерами. Многие из них мы ставим на «Спектрумы» в Яндекс Музеях. Особенной любовью публики пользуются Jetpac и Knight Lore, причём последняя зачастую заставляет посетителей удивлённо переспрашивать: «А этой игре точно недавно стукнуло 40 лет?»

В шедевры Ultimate Play the Game я начал играть с того момента, как у меня появился ZX Spectrum — то есть с 1991 года. Тогда мало кто знал, откуда появилась эта компания и как она умудрилась наделать такое количество прекрасных игр за столь короткое время.

И вот, спустя много‑много лет, я решил найти ответы на эти вопросы. Для этого я достал с полки все фирменные игры Ultimate, купленные в Великобритании, для удобства скачал их образы из интернета и потратил несколько дней, чтобы как следует в них наиграться. А затем обложился журналами Crash, Your Sinclair и Sinclair User, нашёл в интернете несколько десятков статей про Ultimate Play the Game и её создателей… И погрузился в расследование.

Кто же эти гении, буквально за полтора года прошедшие путь от Jetpac до Knight Lore? И почему информации о создании всех игр Ultimate так мало? Давайте разбираться вместе.

Здравствуйте, друзья!

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

В 2015 Маск убеждал Сэма Альтмана не жалеть никаких денег на найм топовых спецов, чтобы спасти человечество от зловредного супер-ИИ от Google – а сейчас он публично обзывает его «лжецом, жуликом и мошенником». В 2018 Маск оценивал шансы OpenAI на успех как «нулевые» – а теперь он хочет выкупить компанию за $97 млрд. В этом лонгриде мы детально разберемся: как так вышло, что Илон сначала помог запустить самую революционную ИИ-компанию современности, а потом стал главным ее хейтером?