Fail2ban — утилита чрезвычайно полезная во многих случаях. Думаю, многие используют её для того, чтобы в автоматическом режиме блокировать особенно назойливых «посетителей». К сожалению, если входящий поток становится слишком большим, fail2ban теряет все свои полезные свойства, потому что разбор лога безнадёжно отстаёт от реальности.

Лог nginx из 100 тысяч строчек fail2ban при самых простых настройках разбирает порядка 45 секунд. Нехитрыми манипуляциями его можно ускорить раз в 6, но этого оказалось недостаточно. Наивная реализация на аналогичного фильтра на Rust уже обеспечила требуемую производительность, но если уж взялся за оптимизацию, то остановиться трудно.

* только необходимую часть функционала

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

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

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

Одним из наиболее популярных направлений разработки сегодня является веб. И когда нужно разместить свой проект где-нибудь, кроме localhost, многие сталкиваются с трудностями, ведь хостинг должен быть быстрым, удобным и, желательно, бесплатным :)

В этом списке вы найдете 15 бесплатных сервисов, где легко сможете разместить свой проект и не заплатите ни копейки. Погнали!

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

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

Потешу своё геймдизайнерское самолюбие и скажу, что у разработки игр и искусства много общего: ни та, ни другая область в достаточной мере не формализована и не изучена с научной точки зрения. Хотя попытки были: взять, к примеру, труд Иосифа Шиллингера «Математические основы искусств» из первой половины XX века.

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

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

Спойлер: C++ не быстрее и не медленнее и вообще смысл не в этом. Эта статья является продолжением славных традиций развенчания мифов крупных российских компаний о языке Rust. Предыдущая была "Go быстрее Rust, Mail.Ru Group сделала замеры".

Недавно я пытался заманить коллегу, сишника из соседнего отдела, на Тёмную сторону Rust. Но мой разговор с коллегой не задался. Потому что, цитата:

В 2019 году я был на конференции C++ CoreHard, слушал доклад Антона antoshkka Полухина о незаменимом C++. По словам Антона, Rust еще молодой, не очень быстрый и вообще не такой безопасный.

Антон Полухин является представителем России в ISO на международных заседаниях рабочей группы по стандартизации C++, автором нескольких принятых предложений к стандарту языка C++. Антон действительно крутой и авторитетный человек в вопросах по C++. Но доклад содержит несколько серьёзных фактических ошибок в отношении Rust. Давайте их разберём.

Помните, как вы были студентами, и готовились к экзаменам по ночам?

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

Изучите теорию на примерах и закрепите на 13 практических задачах по SQL.

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

Всем привет, меня зовут Лев, я геймдизайнер из WhaleKit. И в этой статье мы разберем две математические концепции: цепи Маркова и случайные блуждания. Сразу замечу, что статья скорее «поп», чем «науч», поэтому часть доказательств выведенных формул будет опущена. После теории мы перейдем к реальным кейсам, где эти инструменты могут пригодиться, например:

 1. Сколько сундуков откроет игрок, если из сундуков могут выпасть еще сундуки;
2. Сколько золота уйдет на прокачку меча, если меч может ломаться;
3. Какая вероятность победить в денежном поединке.

В этом году Oil Rush, нашей первой игре на собственном движке, исполнилось 10 лет. Основной профиль деятельности нашей компании — не совсем игры, но разработка Oil Rush помогла не только продемонстрировать технологию UNIGINE во всей красе, но и сделать ее еще лучше.

Три года, пока создавалась игра — одновременно и мучительное, и увлекательное время. В этой статье мы отобрали 10 вещей, которые стоило бы учитывать во время разработки Oil Rush. Многие из них будут полезны и вам, если вы занимаетесь первым проектом в геймдеве.

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

Потом я завел свои "облака" и хранил код на своем железе и рабочих компьютерах. И наконец появился Github. По началу что-то ещё дублировалось на своих серверах и внешних дисках, но к сегодняшнему дню я на столько привык к сервису Github, все на столько удобно и надёжно, что страх о том что "дискетка" может сломаться постепенно улетучился.

И тут на тебе! Оказывается в любой момент, по не зависимой от меня причине, меня могут отключить от этого технологического чуда! :-)

Речь идёт о игре Speebot, которая была выпущена в Steam в 2017 году.

Я разрабатывал эту игру с января 2016 года в своё свободное время в одиночку. Мною выполнено всё программирование, дизайн игрового процесса, создание графики и музыки. Кроме того, я написал собственный игровой движок с нуля.

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

На самом деле, достаточно лишь команды mov.

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

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

→ Часть 0
→ Часть 1, общие оптимизации

В прошлый раз мы получили ускорение в среднем в 2,5 раза без изменения подхода. В этот раз я покажу, как применять SIMD-подход и получить ускорение еще в 3,5 раза. Конечно, применение SIMD для обработки графики не является ноу-хау, можно даже сказать, что SIMD был придуман для этого. Но на практике очень мало разработчиков используют его даже в задачах обработки изображений. Например, довольно известные и распространенные библиотеки ImageMagick и LibGD написаны без использования SIMD. Отчасти так происходит потому, что SIMD-подход объективно сложнее и не кроссплатформенный, а отчасти потому, что по нему мало информации. Довольно просто найти азы, но мало детальных материалов и разбора реальных задач. От этого на Stack Overflow очень много вопросов буквально о каждой мелочи: как загрузить данные, как распаковать, запаковать. Видно, что всем приходится набивать шишки самостоятельно.

«Мои письма никто не читает.»

«Я уже всё всем написал, а коллеги продолжают спрашивать одно и то же. Бесит.»

И особенно популярное: «Мы ещё неделю назад написали, что удалим эту таблицу из базы, и сказали адаптировать код! Так что мы не виноваты, что сайт (пайплайн, приложение, <подставь своё>) упали.»

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

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

(Ещё одним приятным следствием из умения писать качественные письма стало повышение доверия к нашей команде, которое мы измеряем, регулярно опрашивая наших бизнес-партнёров. Простая и понятная коммуникация — признак заботы о собеседнике.)

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

Вангеры одна из самых почитаемых и технологичных игр своего времени, продолжает жить и развиваться. Благодаря сплоченному сообществу игра получила множество усовершенствований: HD, 60 FPS, новые сетевые режимы и много другое. Vange-rs один из интереснейших проектов по Вангерам. Это rust версия игры, основной изюминкой которой является 3D рендер основанный на wgpu.

Когда я предложил перевести на русский мою последнюю статью Easy Concurrency with Python Shared Objects на английском, поступило предложение "написать в несколько раз короче и понятнее". Просьба более чем обоснована. Поскольку я уже порядка десяти лет пишу многопоточку и БД, то описываемые мной логические связи выглядели самоочевидно, и я ошибочно расчитывал на аудиторию из трех с половиной человек, которые сидят сейчас где-то в яндексе или гугле. Судя по всему, они там и сидят, но тема им не интересна, поскольку в питоне нет настоящих потоков, а значит для этих людей такого языка программирования не существует. Потому я немножко снижаю планку и делаю общий обзор проблематики параллельных вычислений для людей, которые в них разбираются, но не являются экспертами в области.

Из-за чего весь сыр-бор?

С ростом проекта в него приходит постоянно приходит новая аудитория: как матерые игроки, так и новички в жанре. Закинуть всех в один матч можно, но первым будет скучно, а вторым — сложно. В итоге всех можно потерять уже на старте.

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

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