Пока кто-то играл в «REvil», кто-то играл в безобидные «симуляторы хакерства». Хакер — очень популярный сеттинг в играх. Во многих играх, к примеру, Watch Dogs 2, System Shock 2, Deus Ex: Human Revolution, Cyberpunk 2077, есть тематика хакерства. Но эти игры дают искаженное представление: кто загадочный и что-то тыкает в компьютере, тот и хакер.



Ниже моя подборка с разными играми про хакерство, я разделяю их на:

• те, которые реально прокачивают какие-то скиллы в сфере информационной безопасности, включают какой-то образовательный контент для начинающих (5 игр);
• те, которые симулируют атмосферу хакерства и какие-то процессы в упрощенном виде (9 игр);
• те, которые просто симулируют атмосферу хакерства и загадочности (5 игр);
• фан на тему около хакерства (3 игры).

Еще я веду канал в Telegram: GameDEVils, делюсь там клевыми материалами (про геймдизайн, разработку и историю игр).

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

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

Возьмите лист бумаги и карандаш. Если не сильно уверены в своих силах, то ещё и резинку, чтобы править схему. Более продвинутые читатели могут обратиться к профессиональным инструментам для проектирования архитектуры в электронном виде.

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

Теперь нарисуйте под каждым нарисованным сверху субъектом прямоугольник с названием UI или API — это интерфейсы, к которым будет обращаться пользователь или внешняя управляющая система. Иногда UI тоже может обращаться к API. Объедините все прямоугольники с UI одним контуром и обзовите слоем представления. Объедините все прямоугольники с API и обзовите слоем сервисов.

Для систем, нарисованных снизу, укажите компоненты, которые будут отвечать за доступ к этим системам. Объедините все эти компоненты одним контуром и обзовите слоем доступа к данным.

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

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

Вы получили логическую архитектуру приложения. Разбросайте слои по серверам — получите физическую архитектуру.

Теперь вам остаётся детально проработать каждый маленький квадратик.

Маленький практический пример запрячу под кат.

Bash-скрипты: начало
Bash-скрипты, часть 2: циклы
Bash-скрипты, часть 3: параметры и ключи командной строки
Bash-скрипты, часть 4: ввод и вывод
Bash-скрипты, часть 5: сигналы, фоновые задачи, управление сценариями
Bash-скрипты, часть 6: функции и разработка библиотек
Bash-скрипты, часть 7: sed и обработка текстов
Bash-скрипты, часть 8: язык обработки данных awk
Bash-скрипты, часть 9: регулярные выражения
Bash-скрипты, часть 10: практические примеры
Bash-скрипты, часть 11: expect и автоматизация интерактивных утилит

Сегодня поговорим о bash-скриптах. Это — сценарии командной строки, написанные для оболочки bash. Существуют и другие оболочки, например — zsh, tcsh, ksh, но мы сосредоточимся на bash. Этот материал предназначен для всех желающих, единственное условие — умение работать в командной строке Linux.

Чем различается скрипт и программа? Вовсе не используемым языком или наличием интерфейса.

Главная разница — в наличии у программы обширнейшей оболочки, не связанной «содержимым» программы. В зависимости от платформы, это могут быть страницы руководства, поддержка нескольких языков, наличие функционала по установке/удалению, исполнение соглашений об интерфейсе (командной строки, или иных средств взаимодействия), интерфейсы в общем реестре и т.д… Программа должна уметь работать в любой документированной среде, предусматривать различные ситуации (круче всего с этим у программ под unix, которые используют ./configure для определения, собственно, где они, что можно, а что нельзя на этой (очередной) платформе).

Скрипт же, в строго обратном смысле: он предназначен для решения конкретной проблемы «здесь и сейчас». Никто не ожидает от скрипта, который отсылает статистику, способности делать это одновременно на solaris'е, freeBSD и windows embedded standard с cygwin'ом на борту.

По математико-программистким представлениям, между скриптами администрирования и программами нет разницы. Они работают по одинаковым принципам, вообще говоря, выполняют почти одно и то же.

Разница между скриптом и программой — административная.

Предисловие

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

Что это

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

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

Инфраструктура системы пакетов для Python долго подвергалась критике как от разработчиков, так и от системных администраторов. Долгое время даже само комьюнити не могло прийти к соглашению, какие именно инструменты использовать в каждом конкретном случае. Уже существуют distutils, setuptools, distribute, distutils2 в качестве базовых механизмов распространения и virtualenv, buildout, easy_install и pip в качестве высокоуровневых инструментов управления всем этим беспорядком.

До setuptools основным форматом распространения были исходные файлы или некоторые бинарные MSI-дистрибутивы для Windows. Под Linux были изначально сломанный bdist_dumb и bdist_rpm, который работал только на системах, основанных на Red Hat. Но даже bdist_rpm работал недостаточно хорошо для того, чтобы люди начали его использовать.

Несколько лет назад PJE попытался исправить эту проблему, предоставив смесь из setuptools и pkg_resources для улучшения distutils и добавления метаданных в Python-пакеты. В дополнение к этому он написал утилиту easy_install для их установки. По причине отсутствия формата распространения, поддерживающего метаданные, был предоставлен формат 'яиц' [egg].

Python eggs – обычные zip-архивы, содержащие python-пакет и необходимые метаданные. Хотя многие люди, вероятно, никогда намеренно не собирали egg'и, их формат метаданных до сих пор жив-здоров. И все разворачивают свои проекты с использованием setuptools.

К сожалению, некоторое время спустя сообщество разделилось, и часть его провозгласила смерть бинарных форматов и 'яиц' в частности. После этого pip, замена easy_install, перестал принимать egg-формат.

Потом прошло еще немного времени, и отказ от бинарных пакетов стал доставлять неудобства. Люди всё больше и больше стали деплоить на облачные сервера, а необходимость перекомпиляции C-шных библиотек на каждой машине не слишком радует. Так как 'яйца' на тот момент были малопонятны (я так полагаю), их переделали в новых PEP-ах, и назвали 'колёсами' [wheels].

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

Давая пользователям доступ к установочным файлам программ, компании неизбежно раскрывают свои профессиональные секреты и наработки, и ничто не останавливает злобонравных конкурентов от беззастенчивого копирования и воровства чужих алгоритмов. Обратим внимание и на другой пример, это важные обновления (патчи), исправляющие ошибки в операционных системах. Почти мгновенно очередное обновление анализируется хакерами, они выявляют проблему которую это обновление чинит, и атакуют несчастных, не успевших вовремя обновиться, пользователей.
Эти две ситуации связывает одна фундаментальная проблема, а именно: написанная человеком программа может быть человеком же и понята, проанализирована, разобрана. А что если существовал бы алгоритм, который бы мог до неузнаваемости, необратимо переделать программу при этом сохраняя ее функциональность? Так чтобы программу совершенно невозможно было бы понять, но при этом она работала бы ничуть не хуже исходной? Такой алгоритм и называется «обфусцирующий» или «обфускатор».

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

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



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

Автор материала, перевод которого мы сегодня публикуем, собирается продемонстрировать подобное «превращение» на примере классической задачи «Fizz Buzz Test». Эта задача заключается в том, чтобы вывести список чисел от 1 до 100, заменив некоторые из них особыми строками. Так, если число кратно 3 — вместо него нужно вывести строку Fizz, если число кратно 5 — строку Buzz, а если соблюдаются оба этих условия — FizzBuzz.

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

scope: начинающие системные администраторы, помощники системных администраторов и т.д. Опытным администраторам, а так же тем, кто имеет вполне конкретную специализацию будет если и интересно, то бесполезно.

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

Какие бывают системные администраторы?

Оригинал: Starting out on Game Programming

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

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

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

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



Для использования физических видеоадаптеров в виртуальных средах мы выбрали технологию RemoteFX vGPU, которая поддерживается гипервизором Microsoft. При этом на хосте должны быть установлены процессоры с поддержкой SLAT (EPT от Intel или NPT/RVI от AMD), а также соответствующие требованиям создателей Hyper-V видеокарты. Ни в коем случае не стоит сравнивать это решение с настольными адаптерами в физических машинах, которые обычно показывают лучшую производительность при работе с графикой. В нашем тестировании vGPU будет конкурировать с центральным процессором виртуального сервера — вполне логично для вычислительных задач. Отметим также, что помимо RemoteFX существуют и другие сходные технологии, например NVIDIA Virtual GPU — она позволяет передавать графические команды каждой виртуальной машины напрямую в адаптер без трансляции их гипервизором. 

Представляю вашему вниманию перевод статьи Beau Carnes How Recursion Works — explained with flowcharts and a video.

«Для того чтобы понять рекурсию, надо сначала понять рекурсию»

Рекурсию порой сложно понять, особенно новичкам в программировании. Если говорить просто, то рекурсия – это функция, которая сама вызывает себя. Но давайте попробую объяснить на примере.

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

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

Есть два основных подхода в создании алгоритма для решения данной проблемы: итеративный и рекурсивный. Вот блок-схемы этих подходов:

Какой подход для Вас проще?

Дональд Кнут — учёный в области информатики, который настолько заботится о правильности своих книг, что предлагает один шестнадцатеричный доллар ($2,56, 0x$1,00) за любую найденную «ошибку», где ошибкой считается всё, что «технически, исторически, типографически или политически неправильно». Я очень хотел получить чек от Кнута, поэтому решил поискать ошибки в его выдающемся труде «Искусство программирования» (TAOCP). Удалось найти три. Верный слову, Кнут прислал чек на 0x$3,00.



Как видите, это не настоящий чек. Раньше Кнут отправлял реальные чеки, но прекратил в 2008 году из-за безудержного мошенничества. Теперь он рассылает «личные депозитные сертификаты» в банке Сан-Серрифф (BoSS). Он говорит, что готов выслать реальные деньги в случае необходимости, но, похоже, это слишком хлопотно.

Зачем и для кого статья?

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

Здесь не будет пересказа манов (документации), и статья никак не отменяет и не заменяет их чтение. Вместо этого я расскажу о главных вещах (командах, приемах и принципах), которые надо осознать с самого начала работы в unix shell-е, чтобы работа происходила эффективно и приятно.

Статья касается полноценных unix-подобных окружений, с полнофункциональным шеллом (предпочтительно zsh или bash)и достаточно широким набором стандартных программ.

Давным-давно я написал статью на Хабр с названием «Интенсивность важнее тщательности» про то, что лучше увеличить количество попыток сделать что-то, чем продолжительность одной попытки. Теперь я хочу дополнить эту мысль.



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

Блоки информации (chunks)

Чтобы свободно пользоваться новыми знаниями, к ним нужно привыкнуть. А привычка, как известно, дело времени. В книге Learning How to Learn (или на замечательном курсе на Coursera) блоки информации называются chunks, и в курсе рассказывается про их формирование. На это уходит время, которое на практике нельзя существенно ускорить.

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

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

Часть 6. Sharpen

В этой части мы подробнее рассмотрим ещё один эффект постобработки из The Witcher 3 — Sharpen.

Sharpening делает изображение на выходе немного чётче. Этот эффект известен нам по Photoshop и другим графическим редакторам.

В The Witcher 3 у sharpening есть две опции: low и high. О разнице между ними я расскажу ниже, а пока давайте взглянем на скриншоты:


Опция «Low» — до


Опция «Low» — после