Разработал и запустил на домене quickpong.com онлайн версию игры Pong. В игре (by design) реализован только режим мультиплейера, то есть игра идет не против искусственного интеллекта, а против другого человека.

Игра представляет из себя клиент-серверное приложение, серверная часть написана на питоновском фреймворке Twisted, клиентская — на флэшовом фреймворке FlashPunk.

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

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

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

В преддверии PyCon Russia мы решили поговорить с докладчиками конференции о Python, их работе и увлечениях. Первое короткое интервью мы взяли у одного из разработчиков языка Python Андрея Светлова.

Андрей Светлов — Python Core Developer, автор и активный участник многих питоновских библиотек, среди которых asyncio, aiohttp, aiopg, aiozmq, автор популярного блога, посвященного языку программирования Python, программный директор и ежегодный спикер конференции PyCon Russia.

Андрей Светлов — спикер многих python-конференций. Например, вот его выступление на PyCon-2015

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

В наших предыдущих постах мы рассказывали о намерении Microsoft включить подсистему Ubuntu Linux в Windows 10. Исполняемые файлы подсистемы появились в ОС начиная с Windows 10 Insider Preview Build 14251, для использования она стала доступна в Insider Preview Build 14316, а для всех пользователей Windows 10 она станет доступна с обещанным Microsoft большим июньским обновлением, т. е. уже в этом месяце. Для использования подсистемы, ее нужно будет включить специальной настройкой, т. к. по умолчанию она выключена. Процесс включения мы описывали в этом посте.



Microsoft называет подсистему Linux для Windows как Windows Subsystem for Linux (WSL). Сегодня компания опубликовала новые технические детали реализации WSL. Ранее мы уже писали про модель подсистем в Windows 10 (NT) и то, как WSL реализуется на уровне ядра Windows за счет драйверов LXss.sys и LXCore.sys. Так как оригинальная модель ядра Windows позволяет верхнему уровню компонентов (напр. ntdll.dll — Win32) использовать свою семантику системных вызовов за счет расширенного интерфейса ядра, у WSL нет проблем со своей реализацией в окружении Windows.

Мы много пишем о создании торговых систем и создаем инструменты для их разработки (от API брокерской системы до конструктора роботов внутри торгового терминала). Сегодня речь пойдет о проектировании архитектуры алагоритмической торговой системы — именно этой теме посвящен материал из блога Turing Finance, написанный количественным аналитиком хедж-фонда NMRQL Стюартом Ридом.

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

Автор: Евгений Ефимов
QA Lead, DataArt

Моряки, самолеты и корпорации

• Н.Н. Талеб и моряки.
• Абрахам Вальд и самолеты.
• Левитт и корпорации.

Существует понятие «систематическая ошибка выжившего». Оно встречается в книгах Талеба “The Black Swan. The Impact of the Highly Improbable” («Черный лебедь. Под знаком непредсказуемости» и “Fooled by Randomness: The Hidden Role of Chance in Life and in the Markets” («Одураченные случайностью. Скрытая роль Шанса на рынках и в Жизни»). Он описывает красивую картину, на ней древнегреческие моряки молятся богам во время шторма. Богам нравится, как они молятся? и поэтому моряки спасены. Шторм превращается в штиль или слабый ветер, корабль доплывает до берега, и все остаются целы. Когда спрашивают других моряков, как удалось доплыть, они тоже говорят: «Мы молимся богам и всегда доплываем». Проблема в том, что мы не можем спросить об этом моряков, которые утонули. Возможно, что они тоже молились, но не доплыли. И вообще дело было не в этом, а, т. к. в то время почти все моряки были религиозны, можно предположить, что молились все. И есть вероятность, что это не действует.
Вторая история — про математика и статистика Абрахама Вальда и про самолеты. Действие происходит во время Второй мировой войны. Британские бомбардировщики возвращаются на базу. Задача — понять, где и как укреплять самолеты, чтобы как можно больше возвращалось и как можно меньше падало. Они смотрят на самолеты, которые вернулись, и говорят, что необходимо укреплять наиболее поврежденные попаданиями части. Поскольку в них все время стреляют, мы их укрепим, и все пули улетят обратно во вражеский самолет и всех там перебьют.

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

Стивен Левитт написал интересную книгу «Фрикономика». Он выбрал стандартные книги из серии «10 шагов к успеху» и проанализировал две книги, где рассказывалось про корпорации, использовавшие нововведения, которые привели их к успеху. Эти книги были условно написаны в 2000 году, и корпорации, используя эти наработки, побеждали остальные компании. На момент, когда Левит их анализировал оказалось, что три четверти этих корпораций закрылись. Они оказались убыточными, потому что внешняя среда поменялась, а они не изменили подход к успеху. Соответственно, все эти истории успеха не всегда и не для всех работают.

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

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

---

На конференции PyGrunn 2016 я выступил с докладом о пакете Python cffi и его использовании для встраивания PyPy кода в приложения на C.

С выходом cffi 1.5.0 и его последующим включением в PyPy 5, становится возможным встраивать PyPy код. Это делается путем компиляции кода Python в динамическую библиотеку, которая затем может быть использована в любом другом языке. В этой статье я покажу вам, как это делать.

Как-то поиграв в оффисе в hexbug, зародилась идея написать игрушку по схожим мотивам.
По текущему роду деятельности я веб разработчик и поэтому захотелось чтобы в игре использовался только HTML, JavaScript и CSS — средства знакомые каждому вебразработчику. Никакого вам flash или даже canvas. Звучит хардкорно, но на самом деле сейчас HTML + CSS3 это очень мощные и гибкие средства визуализации, а писать игровой код на JavaScript — одно удовольствие. Вдобавок захотелось чтобы игра была с сетевым мультиплеером, притом интерактивной — никаких там шашек, карточных игр, пошаговых стратегий, все должно быть в действии и движении.

Вот что получилось в итоге:



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

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

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

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

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

Привет, читатель хабра.

Наверное, ты сразу спросишь меня: «Да кто ты такой, чтобы давать мне советы?». Итак, немного обо мне.

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

Я не хочу рассказывать как надо делать, эта статья результат моего опыта и попытка написать рекомендации тем, кто только начинает, хотя и для матерых верстальщиков (слово режущие слух) здесь могут найтись интересные идеи.
Если ты заинтересовался прошу под кат…

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

Дзен Angular

• Хорошо отделять манипуляцию DOM-ом от логики работы приложения. Это существенно улучшает тестируемость кода.
• Хорошо считать, что автоматизированное тестирование приложения настолько же важно, насколько и написание самого приложения. Тестируемость очень сильно зависит от того, как структурирован код.
• Хорошо отделять разработку клиентской части от серверной. Это позволяет вести разработку параллельно и улучшает повторное использование на обеих сторонах.
• Хорошо, когда фреймворк ведет разработчика по всему циклу разработки приложения: от проектирования UI через написание бизнес-логики к тестированию.
• Хорошо, когда распространенные задачи становятся тривиальными, а сложные — упрощаются.

AngularJS представляет собой комплексный фреймворк. В стандартной поставке он предоставляет следующие возможности:

• Все, что вам нужно для создания CRUD-приложений: data-binding, базовые директивы для шаблонов, валидация форм, роутинг, deep linking, повторное использование компонентов, dependency injection, инструменты для взаимодействия с серверными (RESTful) источниками данных.
• Все, что вам нужно для тестирования: средства для модульного тестирование, end-to-end тестирования, mock-и.
• Шаблон типового приложения, включающего в себя структуру каталогов и тестовые скрипты.

AngularJS разрабатывается сотрудниками Google и используется, как минимум, в одном сервисе Google — DoubleClick.

Продолжение перевода неофициальной документации Selenium для Python.
Перевод сделан с разрешения автора Baiju Muthukadan.
Оригинал можно найти здесь.

Содержание:

1. Установка
2. Первые Шаги
3. Навигация
4. Поиск Элементов
5. Ожидания
6. Объекты Страницы
7. WebDriver API
8. Приложение: Часто Задаваемые Вопросы

AngularJS — прекрасный фреймворк для построения веб-приложений. У него замечательная документация, снабженная примерами. В обучающих «пробных» приложениях (вроде TodoMVC Project) он очень достойно показывает себя среди остальных прочих фреймворков. По нему есть отличные презентации и скринкасты.

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

У фреймворка AngularJS есть несколько интересных решений в коде. Сегодня мы рассмотрим два из них – как работают области видимости и директивы.

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

Если в следующей картинке вам что-то непонятно – эта статья для вас.



(В статье рассматривается AngularJS 1.3.0)

Весной нам в голову пришла идея сделать простой сервис для облачного бэкапа серверов. Поскольку в то время работа над проектом велась преимущественно по вечерам и по выходным, для ускорения процесса было решено использовать только те технологии, в которых у нас есть опыт. Для backend-части был выбран Django, а реализация клиентской части предполагалась в виде SPA на базе AngularJS. Задумка была в следующем: сделать продукт с минимальным функционалом, а затем постепенно добавлять новые возможности. Для этого необходимо было сделать достаточно гибкую и масштабируемую систему. Немного пораскинув мозгами, мы приступили.

Достаточно вольный перевод заметки 7 reasons why angularJS rocks.


Я backend-разработчик и мир Javascript фреймворков для меня достаточно нов, хотя в последние полгода мой интерес к ним сильно растет. Причина проста: я считаю, что стек технологий REST + JSON + Rich JS все больше подходит для широкого круга веб-приложений. Такой подход помогает победить дерьмовую сомнительную концепцию MVC в серверных приложениях. Почему MVC можно считать вредным — это отдельная история, сейчас лучше поговорим об AngularJS.

Что в AngularJS особенного?

В процессе использования angular.js трудно обойтись без объекта $q (он же promise/deferred), ведь он лежит в основе всего фреймворка. Deferred механизм является очень простым и мощным инструментом, который позволяет писать лаконичный код. Но чтобы по-настоящему использовать эту мощь, необходимо знать обо всех возможностях данного инструмента.
Вот несколько моментов, о которых вы возможно не знали.

После прочтения Google's AngularJS Guidelines у меня создалось впечатление о его незавершённости, а ещё в нём часто намекали на профит от использования библиотеки Closure. Ещё они заявили, «Мы не думаем, что эти рекомендации одинаково хорошо применимы для всех проектов, использующих AngularJS. Мы будем рады видеть инициативу от сообщества за более общий стайлгайд, применимый как для небольших так и крупных проектов».

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

На мой взгляд, директивы являются основной изюминкой декларативного стиля Angularjs. Однако, если открыть комментарии пользователей в разделе официальной документации Angularjs, посвященной директивам, то вы увидите, что самый популярный из них: «Пожалуйста, перепишите документацию, сделайте ее более доступной и структурированной. Начинающему разработчику на Angularjs сложно в ней разобраться» («Please rewrite a clearer well structured documentation of directives., this is not friendly to first time angular developers»). С этим трудно не согласится, документация пока еще сыровата и в некоторых моментах приходится прилагать большие усилия, чтобы разобраться в логике и сути функционала. Поэтому я предлагаю вам свой вольный пересказ данной главы в надежде, что кому-то это позволит сэкономить время, а так же рассчитываю на вашу поддержку и участие в комментариях. Итак, поехали!