JavaScript прошел долгий путь с тех пор, как я знал его как букву «D» в DHTML. Для всех, кто, как я, не хотел использовать новейший синтаксис, который может потребовать полифиллов или транспилятора, я написал эту шпаргалку, чтобы вы познакомились со всеми достоинствами, которые широко поддерживаются в современных браузерах.

Содержание

• Array functions
• const/let
• Nullish coalescing ?? and Optional chaining?.. operators
• Async/Await
• Стрелочные функции ()=>{}
• for...of
• for await...of
• Classes
• get/set
• function default parameters
• function named parameters
• function rest… parameter
• Destructuring
• Shorthand functions aka Methods
• Promise.all
• Template literals
• Proxy
• Module import/export
• Читать ещё

(Исправления по качеству перевода, пожалуйста, присылайте в личку)

Автор статьи разбирает на примерах Async/Await в JavaScript. В целом, Async/Await — удобный способ написания асинхронного кода. До появления этой возможности подобный код писали с использованием коллбэков и промисов. Автор оригинальной статьи раскрывает преимущества Async/Await, разбирая различные примеры.

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

К примеру, по итогам пентеста в одной компании мы пришли к выводу, что все доступные машины в домене были не ниже Windows10/Windows Server2016, и на них стояли все самые свежие патчи. Сеть регулярно сканировалась, машины хардились. Все пользователи сидели через токены и не знали свои «20-символьные пароли». Вроде все хорошо, но протокол IPv6 не был отключен. Схема захвата домена выглядела так:

mitm6 -> ntlmrelay -> атака через делегирование -> получен хеш пароля локального администратора -> получен хеш пароля администратора домена.

К сожалению, такие популярные сертификации, как OSCP, GPEN или CEH, не учат проведению тестирования на проникновение Active Directory.

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

Итак, для демонстрации используем ноутбук на Kali Linux 2019 и поднятые на нем виртуальные хосты на VMware. Представим, что главная цель пентеста — получить права администратора домена, а в качестве вводных данных у нас есть доступ в корпоративную сеть компании по ethernet. Чтобы начать тестировать домен, нам понадобится учетная запись.

Пару месяцев назад мне наконец пришлось признать, что я недостаточно умён, чтобы пройти некоторые уровни головоломки Snakebird. Единственным способом вернуть себе часть самоуважения было написание солвера. Так я мог бы притвориться, что создать программу для решения головоломки — это почти то же самое, что и решить её самому. Код получившейся программы на C++ выложен на Github. Основная часть рассматриваемого в статье кода реализована в search.h и compress.h. В этом посте я в основном буду рассказывать об оптимизации поиска в ширину, который бы потребовал 50-100 ГБ памяти, чтобы он уместился в 4 ГБ.

Позже я напишу ещё один пост, в котором будет описана специфика игры. В этом посте вам нужно знать, что мне не удалось найти никаких хороших альтернатив грубому перебору (brute force), потому что ни один из привычных трюков не сработал. В игре множество состояний, потому что есть куча подвижных или толкаемых объектов, при этом важна форма некоторых из них, которая может меняться со временем. Не было никакой пригодной консервативной эвристики для алгоритмов наподобие A*, позволяющих сузить пространство поиска. Граф поиска был ориентированным и заданным неявно, поэтому одновременный поиск в прямом и обратном направлении оказался невозможным. Единственный ход мог изменить состояние множеством несвязанных друг с другом способов, поэтому не могло пригодиться ничего наподобие хеширования Зобриста.

Приблизительные подсчёты показали, что в самой большой головоломке после устранения всех симметричных положений будет порядка 10 миллиардов состояний. Даже после упаковки описания состояний с максимальной плотностью размер состояния составлял 8-10 байт. При 100 ГБ памяти задача оказалась бы тривиальной, но не для моей домашней машины с 16 ГБ памяти. А поскольку Chrome нужно из них 12 ГБ, мой настоящий запас памяти ближе к 4 ГБ. Всё, что будет превышать этот объём, придётся сохранять на диск (старый и ржавый винчестер).

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

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

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

Когда вы приобретаете сервер VPS с 256MB или 512MB оперативной памяти на борту и лишь часть мощности процессора, то использовать для таких сервисов как MySQL/PHP/Apache настройки по умолчанию является очень плохой идеей. В настоящее время у меня запущено 3 сайта на самом дешевом тарифном плане с 512MB RAM/1 CPU. Не уверен полностью, но посещаемость составляет порядка 5-10 тысяч посетителей в день. Далее я хочу поделиться инструкцией как оптимизировать LAMP используя всего лишь 512 MB и при этом не уходя в swap. Обычно при такой настройки используется 256 – 378Mb памяти и все работает довольно быстро.

Определяем доступную память и активность swap.

Перед началом оптимизации давайте взглянем на количество используемой памяти. Для этого необходимо выполнить следующую команду:

$ free -m

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

$ ps -eo pmem,pcpu,rss,vsize,args | sort -k 1 -r | less

Настраиваем LAMP сервер для потребления малого количества оперативной памяти. Останавливаем, отключаем ненужные сервисы

Первый и очевидный вопрос, который необходимо задать — это «какие сервисы мне не нужны в использовании?». Недавно, я обнаружил очень удобную утилиту для управления сервисами. Она называется "sysv-rc-conf" и управляет сервисами при помощи псевдографики и флажками. Выгдялит вот так:

Здесь представлен список сервисов, которые я изменил.

• Postfix. Этот сервис позволяет отправлять и получать почтовые email сообщения для домена. Я использую для этих целей Google Apps для отправки почты и mailchimp для новостных подписчиков. Таким образом я остановил и отключил этот сервис.
• Bind9. Он нужен для управления DNS записями Вашего домена. Его можно отключить, так как все DNS записи хранятся у хостера.
• SSHD. Имеются и другие реализации, которые используют гораздо меньше памяти, но они не поддерживают sftp, поэтому данный сервис я оставил без изменений.

Не запускайте X-сервер, выключите все ненужные сервисы и настройте Apache, MySQL, PHP только с базовой необходимой функциональностью.

Вслед за инструкцией по публикации приложения в App Store выкладываем внутренний свод правил Лайв Тайпинг по публикации приложений в Google Play, составленный отделом менеджеров при активном участии тимлида отдела Android-разработки Александра Мирко. Вне зависимости от того, насколько ты крутой и опытный проджект-менеджер, всегда есть шанс забыть что-нибудь. Эта инструкция призвана облегчить вам жизнь.

Итак, что нужно сделать PM`y в ходе публикации:

1. Создать аккаунт в Google Play Developer Console для заказчика, если у заказчика такового нет, или предложить произвести публикацию с нашего аккаунта.
2. Оформить privacy policy.
3. Подготовить маркетинговые материалы (иконка, скриншоты, APK, баннер, текст, проморолик).
4. Обеспечить сборку наличием сертификата цифровой подписи.
5. Настроить оплату за пользование приложения.
6. Отправить сборку в Google Play.

Все подробности — под катом.

UPD от 25.04.2017: добавлены разделы про альфа- и бета-тестирование и поэтапное внедрение, дополнены разделы «Обеспечение сборки наличием цифровой подписи» и «Технические требования к apk-файлу», сделано замечание про ASO и внесены косметические правки.

Что такое хук?
Что такое хук функций и для чего он нужен? В переводе с английского «hook» — ловушка. Поэтому о назначении хуков функции в Windows можно догадаться — это ловушка для функции. Иными словами, мы ловим функцию и берем управление на себя. После этого определения нам открываются заманчивые перспективы: мы можем перехватить вызов любой функции, подменить код на свой, тем самым изменив поведение любой программы на то, которое нам нужно (конечно, в рамках определенных ограничений).

Целью данной статьи является демонстрация установки хука и его непосредственная реализация.

Speech AI с Python & Google API

Добрый день!

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

1) Распознать речь с микрофона
2) Придумать более — менее разумный ответ.
В этом пункте можно сделать много интересного.
Например реализовать управление чем — нибудь физическим и не очень.
3) Преобразовать этот самый ответ в речь и воспроизвести.

Самое интересное, что для всех этих пунктов нашлись библиотеки под Python, чем я и воспользовался.

В итоге получилась связка, практически не зависящая от выбранного в качестве разговорного языка.

Подмигнув дедушке Энштейну, поправив ранец с напалмом и пригладив стильную черную маечку с изображением формулы закона нормального распределения, ведущий аналитик распахнул двери PR-отдела, блистательно улыбнулся и спросил: «Ребят, продолжаете собирать e-mail клиентов в эксельках и креативите методом блуждания левой руки с закрытыми глазами?». Получив радостное «ага :-)», боец мысленно поблагодарил Джона Непера за проделанную работу на благо просвещения человечества и сокращение рутинного труда и… бодро нажал на гашетку.

Альберт Энштейн всегда вдохновлял аналитиков на внедрение передовых алгоритмов

Спустя 5 минут топливо в ранце уже закончилось, было довольно тепло, если не сказать — жарко, но коллеги (?) ничего не замечали и продолжали считать лайки под своими постами в соцсетях.

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

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

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

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

Рис. 1. Схема с неопределенным напряжением в линии передачи. В реальной схеме функцию ключа может выполнять транзистор.

В схеме Рис. 1 при замыкании ключа приёмнику передается 5В источника, однако, когда ключ разомкнут на входе приемника находится неопределенное напряжение.
Этой неопределенности нет в схеме Рис. 2, которая имеет два устойчивых состояния 5В или 0В. Сопротивление R добавлено в схему передатчика для ограничения тока через замкнутый ключ. Переходный процесс в линии пропорционален произведению ёмкости линии на выходное сопротивление передатчика, которое отличается при установлении и сбросе напряжения в линии. При установке напряжения в линии происходит заряд ёмкости через сопротивление R. Во время сброса напряжения ёмкость разряжается через сопротивление замкнутого ключа.


Рис. 2. Передача двух состояний 5В и 0В. Тождественные схемы. Постоянная времени (R*C) перехода из 0В в 5В (заряда емкости) больше постоянной разряда линии через идеальный ключ с нулевым сопротивлением.

Более чем полгода я потратил на совместное с аппаратной и программной технической поддержкой IBM расследование по поводу работы сторожевого таймера на серверах IBM/Lenovo в Linux. Начало этой детективной истории было описано в моей статье SLES 12, сторожевой таймер и серверы IBM/Lenovo. Сейчас, похоже, ситуация разъяснилась, и можно дать конструктивные рекомендации счастливым обладателям железа IBM/Lenovo xSeries.

«Три девицы под окном пряли поздно вечерком.»



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

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

Вскоре «в светлицу вошел царь — стороны той государь» (показан на рисунке). «Во все время разговора...», — ну понятно в общем.
«Собираем лайки нежности — формируем матрицу смежности», — бодро срифмовал он.
Девицы-красавицы с именами Алена, Варвара и Софья засмущались, но лайки (из балалайки) передали.

Вот что там было:

• Алена получила 1 лайк от Софьи и 2 лайка от Варвары.
• Варвара получила по лайку от Алены и Софьи.
• А Софья получила 2 лайка от Алены и 1 от Варвары.

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

Наибольший вес лайков (7 баллов) получила Софья, но титул «мисс Салтан» достался Алене (15 баллов).


После объявления результатов девицы бросились обратились к царю с просьбой рассказать,- откуда взялись эти странные цифры?

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

Данные материалы не претендуют на то, чтобы показать «как надо делать», они лишь помогут наглядно понять, что и как работает, а вот как правильно это сделать — решит только сам разработчик. Однако, кого-то эти материалы могут замотивировать на дальнейшую работу, так как они достаточно наглядны и объясняют простоту создания игр на JavaScript.

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

Я предлагаю вам поиграть в игру: я даю только картинку, на которой видна проблема, попробуйте понять, в каком месте кода нужно искать баг, что именно сломано. Я в эту игру играю ежедневно, досконально смотреть сотни версий рендера у меня нет никакой возможности, поэтому я, как заправский экстрасенс, лечу по фотографии. Зачастую успешно.

Абсолютно все картинки сгенерированы не мной, я лишь собрал самые типичные баги. Настоящая людская боль перед вашими глазами, ко мне, понятно, обращаются (особенно по почте) только после того, как не могут сами найти баг за разумное время.

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

В посте подробно рассматривается техника генерации случайных подземелий. Основной алгоритм генерации, пример работы которого можно посмотреть здесь, используется разработчиками игры TinyKeep. Оригинальный пост от разработчика был размещён на reddit.

Оригинальное описание алгоритма

1. Сначала я задаю нужное количество комнат – к примеру, 150. Естественно, цифра произвольная, и чем она больше, тем сложнее будет подземелье.

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

Вместо равномерно распределённых случайных чисел (какие выдаёт генератор Math.random в большинстве языков), я использую нормальное распределение Парка-Миллера. В результате вероятность появления маленьких комнат превышает вероятность появления больших. Зачем это надо, объясню позже.

Кроме того я проверяю, что соотношение длины и ширины комнаты не слишком велико. Нам не нужны как идеально квадратные комнаты, так и сильно вытянутые.

3. И вот у нас есть 150 случайных комнат, расположенных на небольшом пространстве. Большинство из них наезжают друг на друга. Теперь мы осуществляем их разделение по технологии separation steering, чтобы разделить прямоугольники так, чтоб они не пересекались. В результате они не пересекаются, но находятся достаточно близко друг от друга.

4. Заполняем промежутки клетками размером 1х1. В результате у нас получается квадратная решётка из комнат различного размера.

5. И тут начинается основное веселье. Определяем, какие из клеток решётки являются комнатами – это будут любые клетки с шириной и высотой, превышающими заданные. Из-за распределения Парка-Миллера мы получим сравнительно небольшое количество комнат, между которыми есть довольно много свободного пространства. Но оставшиеся клетки нам также пригодятся.

6. Следующий шаг – связывание комнат вместе. Для этого мы строим граф, содержащий центры всех комнат при помощи триангуляции Делоне. Теперь все комнаты связаны меж собой непересекающимися линиями.

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

8. Дерево получается аккуратным, но скучным – никаких вам замкнутых ходов. Поэтому мы случайным образом добавляем обратно примерно 15% ранее исключённых рёбер графа. В результате получится граф, где все комнаты гарантированно достижимы, с несколькими замкнутыми ходами.

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

И вот пример результата!

Осторожно — под катом много монстров анимированных гифок!

Некоторое время назад в Облаке Mail.Ru появилась возможность проигрывания видеофайлов. Уже в самом начале работы над этим функционалом мы решили, что будем разрабатывать этакий швейцарский нож: требовалась возможность проигрывать любые видеоформаты и функционирование на всех устройствах, где доступно Облако. Загруженные в Облако видеофайлы можно условно разделить на две категории: «фильмы/сериалы» и «видеоролики пользователей», которые люди снимают на телефоны и видеокамеры — для этого случая особенно характерно разнообразие форматов и кодеков. Без предварительной обработки просмотреть все это на любом устройстве невозможно, например, из-за отсутствия нужного кодека или же размер файла окажется слишком большим.

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

Websocket, наверное, самое серьезное и полезное расширение протокола HTTP с момента его появления в начале девяностых. Использование websockets для обмена данными с сервером намного более выгодно, чем привычный AJAX. Экономия трафика в стандартных приложениях существенна, особенно, при активном обмене клиента и сервера небольшими сообщениями. Также, существенно сокращается время отклика при запросах данных. Основным препятствием на пути широкого распространения этой технологии долгое время было то, что многие прокси-сервера криво поддерживали расширенную версию http-протокола. Что приводило, в худшем случае, к проблемам безопасности (пруф). За последние пару лет ситуация с поддержкой вебсокетов стала выправляться и сейчас, на мой взгляд, настало их время.

В этой статье описаны рецепты использования вебсокетов в стандартных компонентах Extjs (gridpanel, treepanel, combobox). И, также, в качестве замены Ext.Ajax.

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

Основная проблема в том, что выполнить оценку производительности сервера нужно быстро, без использования специальных (читай, сложных) инструментов и, разумеется, до релиза. Мы должны уметь снять с сервера некие метрики и, умножив их на известные показатели приложения, получить оценку производительности приложения на этом сервере.

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

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