Можно ли написать свой модуль (расширение) к PHP без особых знаний, требующих большого времени изучения теории? Если умеешь программировать на самом PHP, то написать простейший код на С не составит особого труда, тем более, что PHP позволяет генерировать каркас под разрабатываемое расширение, в рамках которого потом пишешь код. Есть еще набирающий популярность зефир на хабре для этого вопроса. Данная публикация для тех, кто решил покопаться в исходниках PHP, немного посмотреть его внутренности, преследуя цель лишь поверхностного исследования. В данный момент я тот же самый исследовать без необходимых знаний. На собеседованиях по PHP часто просят написать код подсчета факториала. Вот такую функцию мы и напишем сейчас на С, которую потом можно вызывать из кода PHP. Я буду описывать действия, которые я сам делал и при этом ничего не знаю изначально по этой части. В интернете можно найти много статей по этому вопросу, большинство из них описывает информацию с использованием zval «старого» формата, но я не думаю, что будет хуже если и я еще добавлю от себя.

Итак, в нашей прошлой статье мы рассмотрели как можно быстро и просто настроить среду для тестирования плейбуков и ролей Ansible. Это всё, конечно, очень хорошо и удобно, но почему бы нам не автоматизировать весь процесс внесения изменений в инфраструктуру от написания плейбука до внесения изменений на сервера?



Напомню несколько условий, при которых мы будем выполнять тестирование конфигураций:

1. Вся конфигурация хранится в git-репозитории;
2. Jenkins периодически опрашивает git-репозиторий с нашими ролями/плейбуками на предмет внесённых изменений;
3. При появлении изменений Jenkins запускает job с тестированием конфигурации. Тесты состоят из двух этапов:
3.1 Kitchen-CI берёт обновленный код из репозитория, запускает полностью свежий docker-контейнер, заливает в них обновлённые плейбуки из репозитория и запускает Ansible локально, в docker-контейнере;
3.2 Если первый этап прошёл успешно, в docker-контейнере запускается serverspec и проверяет, корректно ли встала новая конфигурация;
4. Если в Kitchen-CI все тесты прошли успешно, то Jenkins инициирует заливку новой конфигурации.

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

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

^{Источник изображения.}

Есть ли связь между трехглазой жабой и нейронными сетями? Что общего у программы, выигрывающей в го, и приложением Prisma, перерисовывающим фотографии под стили картин известных художников? Как компьютеры одолели нарды, а затем покусились на святое — и выиграли у человека в “Космических захватчиков”?
Дадим ответы на все эти вопросы, а еще поговорим о революции, связанной с глубоким обучением, благодаря которому удалось добиться прорыва во многих областях.

Дисковый массив с нотками ретро.

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

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

_{Фото: A.V. Photography}

Последняя, заключительная часть. Проект «Око» окончен. «От автора» можно будет почитать в конце публикации.

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

Для новых же читателей внутри есть ссылка на книгу целиком в форматах для читалок.

Ссылки на предыдущие части и обращение к тем, кто видит публикации Ока впервые:

Око — мой личный литературный проект, работу над которым я начал в мае этого 2015 года. Из небольшой зарисовки он перерос в научно-фантастическое произведение, главы которого я выкладываю, по мере написания, на GT.

Предыдущие части:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Часть 6
Часть 7
Часть 8
Часть 9
Часть 10
Часть 11
Часть 12
Часть 13
Часть 14
Часть 15
Часть 16
Часть 17
Часть 18
Часть 19
Часть 20
Часть 21
Часть 22
Часть 23
Часть 24
Часть 25

Начался сбор средств для печати тиража самиздата

На КДПВ белорусские рубли. В переводе на российские общая сумма составляет ~205 000 RUB

Вчера утром на белорусской площадке «Улей» я запустил кампанию по сбору средств для печати тиража книги, которая на протяжении 13 последних месяцев публиковалась по главам специально для читателей Geektimes.

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

Почему я пошел на краудфандинг? Первое — полностью сохранить права на произведение. Это дает возможность выполнить пункт №2: я считаю, что обязательно должна остаться возможность прочитать «Око» в электронном варианте бесплатно для всех желающих. И не важно где, на Geektimes, в формате книги для читалок или скачать с одной из библиотек/раздач.

Самолет компании Swissair следующий рейсом в Эритрею попал в зону турбулентности на высоте 10 000 метров над уровнем моря. До посадки оставался примерно час, когда салон самолета тряхнуло и пластиковый стаканчик, выскользнув из руки Евгения Владимировича, опрокинул отвратительный растворимый кофе с молоком ему на брюки. Практически сразу раздался голос командира экипажа, который попросил пассажиров сохранять спокойствие и пристегнуть ремни. Салфетки, разумеется, остались на подносе с остатками обеда, который заботливая стюардесса унесла перед тем как раздать напитки. «Хана брюкам, рубашку может еще удастся спасти, но брюкам хана. Если б сразу замочить, то может еще удалось бы отстирать, но к тому времени как доберусь до гостиницы можно даже не пытаться. Впрочем, все равно рубашку отдавать в прачечную, можно и брюки попробовать, думал Евгений Владимирович без всякой надежды на то, что его надежды сбудутся. Хорошо что хоть пиджак снял». Его расстройство было отягощено тем фактом, что вылетел он налегке, практически без багажа, в ручной клади был только лэптоп с зарядками и бритвенный набор, вот собственно и все. По идее больше и не должно было понадобиться. Командировка случилась внезапной и короткой.

Сегодня Redux — это одно из наиболее интересных явлений мира JavaScript. Он выделяется из сотни библиотек и фреймворков тем, что грамотно решает множество разных вопросов путем введения простой и предсказуемой модели состояний, уклоне на функциональное программирование и неизменяемые данные, предоставления компактного API. Что ещё нужно для счастья? Redux — библиотека очень маленькая, и выучить её API не сложно. Но у многих людей происходит своеобразный разрыв шаблона — небольшое количество компонентов и добровольные ограничения чистых функций и неизменяемых данных могут показаться неоправданным принуждением. Каким именно образом работать в таких условиях?

В этом руководстве мы рассмотрим создание с нуля full-stack приложения с использованием Redux и Immutable-js. Применив подход TDD, пройдём все этапы конструирования Node+Redux бэкенда и React+Redux фронтенда приложения. Помимо этого мы будем использовать такие инструменты, как ES6, Babel, Socket.io, Webpack и Mocha. Набор весьма любопытный, и вы мигом его освоите!

Выступления и посты в блогах о производительности JavaScript часто обращают внимание на важность мономорфного кода, однако обычно не дается внятного никакого объяснения, что такое мономорфизм/полиморфизм и почему это имеет значение. Даже мои собственные выступления зачастую сводятся к дихотомии в стиле Невероятного Халка: «ОДИН ТИП ХОРОШО! ДВА ТИП ПЛОХО!». Неудивительно, что когда люди обращаются ко мне за советом по производительности, чаще всего они просят объяснить, что на самом деле такое мономорфизм, откуда берется полиморфизм и что в нем плохого.

Ситуацию осложняет еще и то, что само слово «полиморфизм» имеет множество значений. В классическом объектно-ориентированном программировании полиморфизм связан с созданием дочерних классов, в которых можно переопределить поведение базового класса. Программисты, работающие с Haskell, вместо этого подумают о параметрическом полиморфизме. Однако полиморфизм, о котором предупреждают в докладах о производительности JavaScript – это полиморфизм вызовов функции.

Я объяснял этот механизм столькими различными путями, что наконец-то собрался и написал данную статью: теперь можно будет не импровизировать, а просто дать на нее ссылку.

_{Я также попробовал новый способ объяснять вещи – изображая взаимодействие составных частей виртуальной машины в виде коротких комиксов. Кроме того, данная статья не покрывает некоторые детали, которые я посчитал незначительными, излишними или не связанными напрямую.}

_{Фото: A.V. Photography}

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

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

Для новых же читателей внутри есть ссылки на предыдущие главы с 1 по 25, объединенные в один файл, в форматах для читалок.

Ссылки на предыдущие части и обращение к тем, кто видит публикации Ока впервые:

Око — мой личный литературный проект, работу над которым я начал в мае этого 2015 года. Из небольшой зарисовки он перерос в научно-фантастическое произведение, главы которого я выкладываю, по мере написания, на GT.

Предыдущие части:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Часть 6
Часть 7
Часть 8
Часть 9
Часть 10
Часть 11
Часть 12
Часть 13
Часть 14
Часть 15
Часть 16
Часть 17
Часть 18
Часть 19
Часть 20
Часть 21
Часть 22
Часть 23
Часть 24

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Как повесить идеальный хэдшот если у тебя пинг 2 секунды? Вы узнаете в этой статье.

Текущий алгоритм работы мультиплеера

• Сервер получает команды с клиентов и времена их отправления
  
• Сервер обновляет состояние мира
  
• Сервер с некоторой частотой отправляет свое состояние всем клиентам
  
• Клиент отправляет команды и локально воспроизводит их результат
  
• Клиент получает обновленные состояния мира и:
  • Применяет состояние от сервера
  • Заново применяет все свои команды, которые сервер не успел применить.
  • Интерполирует предыдущие состояния других игроков
• С точки зрения игрока, есть два серьезных последствия:
  • Игрок видит себя в настоящем
  • Игрок видит других в прошлом.

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

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Введение

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

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

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

Вы спросите: «Кому вообще интересны эти небесные объекты?» и даже: «Ну и при чём здесь 2ГИС?» и будете отчасти правы. Ведь методы пространственного индексирования являются универсальной ценностью.

Обычно, имея дело с геоданными, мы работаем с локальной проекцией на плоскость и тем самым отмахиваемся от искажений. В масштабах планеты это сделать труднее — начинают выпирать астрономические проблемы.
Что касается объёмов данных, уже сейчас в OSM более 4 млрд точек и 300 млн дорог. Это соизмеримо с масштабами, характерными для звёздных объектов. Да и помимо всего прочего, звёздные атласы — отличный стенд для разработки и отладки пространственных алгоритмов.

Обещанные тонкости и выводы под катом.

1. Части I, II (синглплеер с авторитарным сервером)
2. Часть III (Появление врага)
3. Часть IV (Хэдшот!)

Предлагаю вашему вниманию перевод статьи Fast-Paced Multiplayer (Part I): Introduction.

Разработка игры — само по себе непростое занятие. Но мультиплеерные игры создают совершенно новые проблемы, требующие разрешения. Забавно, что у наших проблем всего две причины: человеческая натура и законы физики. Законы физики привнесут проблемы из области теории относительности, а человеческая натура не даст нам доверять сообщениям с клиента.

_{Фото: A.V. Photography}

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

Для новых же читателей внутри есть ссылки на предыдущие главы с 1 по 24, объединенные в один файл, в форматах для читалок.

Ссылки на предыдущие части и обращение к тем, кто видит публикации Ока впервые:

Око — мой личный литературный проект, работу над которым я начал в мае этого 2015 года. Из небольшой зарисовки он перерос в научно-фантастическое произведение, главы которого я выкладываю, по мере написания, на GT.

Предыдущие части:

Часть 1
Часть 2
Часть 3
Часть 4
Часть 5
Часть 6
Часть 7
Часть 8
Часть 9
Часть 10
Часть 11
Часть 12
Часть 13
Часть 14
Часть 15
Часть 16
Часть 17
Часть 18
Часть 19
Часть 20
Часть 21
Часть 22
Часть 23

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

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

Для подписчиков Windows Insider Program (Fast builds only, судя по всему) наконец-то стала доступна долгожданная сборка 14316, первая после Build 2016 и включающая в себя тот самый Bash, а если точнее, то «Bash on Ubuntu on Windows», который является обычным bash'ем в составе самой настоящей (не виртуализированной) Ubuntu 14.04 (собственно ее Microsoft называют «Ubuntu on Windows» [иногда сокращая до «uow»]), которая сожительствует с Windows 10 с помощью beta-версии компоненты «Windows Subsystem for Linux», транслирующей вызовы одной вселенной в другую.



Надо сразу отметить, что стеснительные Microsoft форсируют новомодную пепяку именно под названием Bash, хотя на самом деле это весь user-mode *nix софт (в ближайшем будущем точно).