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

В этой статье я постараюсь описать то, как работает человеческий мозг и как это использовать в проектировании интерфейсов.

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

В Age of Empires эпичным было практически всё.

За последние 20 лет, в «Эпохах Империй» успели появиться 50 цивилизаций, суммарные продажи серии превысили 20 миллионов копий, и армия из сотен тысяч поклонников провела за игрой бесчисленные часы, причём многие из них играли в неё чуть ли не каждую неделю. Age of Empires является одной из самых влиятельных стратегий всех времен и народов. И сегодня вместо того, чтобы отправиться на свалку истории (что обычно рано или поздно случается со всеми старыми играми), «Империя» наконец-то приходит в сознание и возвращается к своим поклонникам.

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

Arstechnica пообщалась с создателями оригинальной Age of Empires о том, как проходила разработка знаменитой игры, и они откровенно рассказали о своих успехах и неудачах. Вашему вниманию предлагается краткий пересказ того, что нам удалось узнать; речь пойдет в первую очередь про первые части Age of Empires, которые заложили основу серии, но мы вспомним и более поздние игры Ensemble Studios.

На прошедшей неделе в ночь с четверга на пятницу на конференции X019 в Лондоне произошло долгожданное событие — компания Microsoft показала геймплей продолжения знаменитой стратегической серии Age of Empires IV. На первый взгляд проект, окруженный «туманом войны» на протяжении вот уже нескольких лет, напоминает выполненный в 3D ремейк Age of Empires II — самой популярной части серии, в которую до сих пор играют миллионы любителей RTS и истории. Предупреждаем: «кидать деньги в монитор» пока ещё рано — игровые издания называют ориентировочной датой релиза 2020 2021 год.

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

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

Предлагаю вашему вниманию перевод статьи «Three Paradigms» автора Robert C. Martin (Uncle Bob).


За последние 40 лет технологии аппаратного обеспечения увеличили вычислительную мощность наших устройств более чем на двадцать порядков. Теперь мы играем в Angry Birds на наших телефонах, которые обладают вычислительной мощностью суперкомпьютера 70-х годов прошлого века с фреоновым охлаждением.

Но за те же 40 лет технологии программного обеспечения практически не изменились. В конце концов, мы все так же применяем операторы if, while loops и операторы присваивания, которые мы использовали еще в 60-х годах. Если бы я взял программиста из 1960 года и привел его сюда, чтобы он посидел за моим ноутбуком и написал код — ему понадобилось бы 24 часа, чтобы оправиться от шока, но он смог бы написать этот код. Принципы не так сильно изменились.

В процессе написания программ изменились три вещи. Я говорю не об оборудовании, не о скорости компьютера и не о невероятных инструментах, которые у нас есть. Я имею в виду сам код. Три вещи изменились в коде. Можно их назвать парадигмами. И все они были «открыты» за одно десятилетие более 40 лет назад.

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

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


Фото с сайта learn.adafruit.com

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

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

Мы решили сделать свой фреймворк, с C++17 и корутинами. Вот так теперь выглядит типичный код микросервиса:

Response View::Handle(Request&& request, const Dependencies& dependencies) {
  auto cluster = dependencies.pg->GetCluster();
  auto trx = cluster->Begin(storages::postgres::ClusterHostType::kMaster);

  const char* statement = "SELECT ok, baz FROM some WHERE id = $1 LIMIT 1";
  auto row = psql::Execute(trx, statement, request.id)[0];
  if (!row["ok"].As<bool>()) {
    LOG_DEBUG() << request.id << " is not OK of " << GetSomeInfoFromDb();
    return Response400();
  }

  psql::Execute(trx, queries::kUpdateRules, request.foo, request.bar);
  trx.Commit();

  return Response200{row["baz"].As<std::string>()};
}

А вот почему это крайне эффективно и быстро — мы расскажем под катом.

В статье рассматривается несколько способов определения математического уравнения линии простой (парной) регрессии.

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

• Аналитическое решение
• Градиентный спуск
• Стохастический градиентный спуск

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

Весь код, приведенный в статье, написан на языке python 2.7 с использованием Jupyter Notebook. Исходный код и файл с данными выборки выложен на гитхабе

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

Для иллюстрации материала используем очень простой пример.

Серверный код в Instagram пишут исключительно на Python. Ну, в основном это именно так. Мы используем немного Cython, а в состав зависимостей входит немало C++-кода, с которым можно работать из Python как с C-расширениями.



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

Наша серверная система — это монолит, который очень часто меняется. Каждый день сотни программистов делают сотни коммитов в код. Мы непрерывно разворачиваем эти изменения, делая это каждые семь минут. В результате развёртывание проекта в продакшне выполняется около ста раз за сутки. Мы стремимся к тому, чтобы между попаданием коммита в ветку master и развёртыванием соответствующего кода в продакшне проходило бы менее часа (вот выступление об этом, сделанное на PyCon 2019).

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

Этот материал посвящён тому, как мы пользуемся линтингом и автоматическим рефакторингом для того чтобы облегчить управление кодовой базой, написанной на Python.

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

→ Вторая часть

Примечание: полный исходный код этого проекта выложен здесь: [source].

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

После выпуска первоначального концепта Task-Bot [перевод на Хабре] я почувствовал, что меня ограничивает двухмерное пространство, в котором я работал. Казалось, что оно сдерживает возможности емерджентного поведения ботов.

Предыдущие неудачные попытки изучения современного OpenGL поставили передо мной мысленный барьер, но в конце июля я каким-то образом наконец пробил его. Сегодня, в конце октября, у меня уже достаточно уверенное понимание концепций, поэтому я выпустил собственный простой воксельный движок, который будет средой для жизни и процветания моих Task-Bots.

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

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

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

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

Когда-то давным давно во всех академических дисциплинах было заложено фундаментальное убеждение — существует единственная бесконечность.

Но 1874 году довольно малоизвестный математик провёл серию революционных наблюдений, подвергавших сомнению это всеми принятое и глубоко укоренившееся убеждение. Георг Кантор в своей (теперь уже ставшей легендарной) публикации On a Property of the Collection of All Real Algebraic Numbers доказал, что множество вещественных чисел «более многочисленно», чем множество алгебраических чисел. Так он впервые показал, что существуют бесконечные множества разных размеров (не волнуйтесь — для прояснения этого мы вскоре подробно изучим его статью).

Qt — чрезвычайно мощный и удобный фреймворк для C++. Но у этого удобства есть и обратная сторона: довольно много вещей в Qt происходят скрыто от пользователя. В большинстве случаев соответствующая функциональность в Qt «магически» работает и это приучает пользователя просто принимать эту магию как данность. Однако когда магия все же ломается то распознать и решить неожиданно возникшую на ровном казалось бы месте проблему оказывается чрезвычайно сложно.

Эта статья — попытка систематизации того как в Qt «под капотом» реализована работа с потоками и о некотором количестве неочевидных подводных камней связанных с ограничениями этой модели.

Основы
Thread affinity, инициализация и их ограничения
Главный поток, QCoreApplication и GUI
Rendering thread
Заключение

Перевод статьи подготовлен специально для студентов базового и продвинутого курсов «Математика для Data Science».

---

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

P(A|B) = P(B|A) * P(A)/P(B)

Вот так она выглядит, но что это значит и как работает? Сегодня мы это узнаем и углубимся в теорему Байеса.

Создаём семантический поисковик с машинным обучением в реальном времени за 300 строк Python кода.

Мой опыт подсказывает, что любой более или менее сложный проект по машинному обучению рано или поздно превращается в набор сложных неподдерживаемых внутренних инструментов. Эти инструменты, как правило, мешанина из скриптов Jupyter Notebooks и Flask, которые сложно развёртывать и интегрировать с решениями типа GPU сессий Tensorflow.

Впервые я столкнулся с этим в университете Карнеги, затем в Беркли, в Google X, и, наконец, при создании автономных роботов в Zoox. Зарождались инструменты в виде небольших Jupyter notebooks: утилита калибровки сенсора, сервис моделирования, приложение LIDAR, утилита для сценариев и т.д.

С ростом важности инструментов появлялись менеджеры. Бюрократия росла. Требования повышались. Маленькие проекты превращались в огромные неуклюжие кошмары.

Tesseract — это движок оптического распознавания символов (OCR) с открытым исходным кодом, является самой популярной и качественной OCR-библиотекой.

OCR использует нейронные сети для поиска и распознавания текста на изображениях.

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

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

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

Обозначим через:

X — торговую площадь(кв. м.)

Y — годовой товарооборот(млн. р.)

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

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

Выдвинем гипотезу, что наше значение Y зависит от X в виде: Y = a + b * X

Чтобы решить нашу задачу, мы должны подобрать коэффициенты a и b.

Выпущенная в 1983 году домашняя консоль Nintendo Entertainment System (NES) была дешёвой, но мощной машиной, достигшей феноменального успеха. При помощи блока обработки изображений (Picture Processing Unit, PPU) система могла создавать достаточно впечатляющую по тем временам графику, которая и сегодня в нужном контексте выглядит вполне неплохо. Самым важным аспектом была эффективность памяти — при создании графики приходилось обходиться как можно меньшим количеством байтов. Однако вместе с этим NES предоставила разработчикам мощные и простые в использовании функции, позволившие ей выделиться на фоне более старых домашних консолей. Поняв принципы создания графики NES, можно проникнуться техническим совершенством системы и осознать, насколько проще работать современным разработчикам игр.

Фоновая графика NES собиралась из четырёх отдельных компонентов, комбинация которых образовывала изображение, которое мы видим на экране. Каждый компонент отвечал за отдельный аспект; цвет, расположение, «сырая» пиксельная графика и т.д. Такая система может показаться излишне сложной и громоздкой, но в конечном итоге она намного эффективнее использовала память и позволяла создавать простые эффекты в малом объёме кода. Если вы хотите понимать графику NES, то ключевой информацией будут эти четыре компонента.

В этой статье подразумевается, что вы знакомы с компьютерной математикой, и в частности с тем, что 8 бит = 1 байт, а 8 бит могут обозначать 256 значений. Также необходимо понимание того, как работает шестнадцатеричная запись. Но даже без этих технических знаний статья может показаться интересной.

Начав писать про стратегии обработки, я понял что творю «обезьяний набор» — пошаговое руководство даже не для чайников, а для идиотов, мои шаги повторить можно, сделать свои по образцу тоже, но понимания не добавляется. В свое время, когда я внезапно решил стать фрезеровщиком, имея в бэкграунде высшее медицинское, МБА и 10 лет компьютерного ритейла, мне было очень сложно продираться через терминологию и абсолютно новый понятийный аппарат.

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



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

В НИТУ «МИСиС» заработал первый в России прототип квантового компьютера. Устройство на двух кубитах выполнило квантовый алгоритм Гровера, превысив ранее известный предел точности на 3%. В качестве основы для кубитов были взяты сверхпроводящие материалы.

Криостат квантового компьютера, собранного в НИТУ «МИСиС».

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

В геймдев индустрии огромное количество разработчиков, которые охотно делятся своими историями, наработками, архитектурными решениями — в том или ином виде. Этот опыт, выложенный в публичное пространство в виде статей, презентаций и докладов, является отличным источником идей и вдохновения. Например, доклады команды разработки из Overwatch были для нас очень полезны при работе над движком. Как и сама игра, они очень талантливо сделаны, и я советую посмотреть их всем интересующимся. Доступны в GDC vault и на YouTube.

Это одна из причин, по которой мы также хотим вносить вклад в общее дело — и эта статья одна из первых, посвященная техническим деталям разработки движка Blitz Engine и игры на нем — Battle Prime.

Статья будет поделена на две части:

• ECS: имплементация Entity-Component-System паттерна внутри Blitz Engine. Этот раздел важен для понимания примеров кода в статье, и сам по себе является отдельной интересной темой.
• Неткод и геймплей: все, что касается высокоуровневой сетевой части и ее использования внутри игры — клиент-серверная архитектура, клиентские предсказания, репликация. Одной из важнейших вещей в шутере является стрельба, так что ей будет уделено большее количество времени.

Под катом много мегабайт гифок!

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

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