Вполне логично, что почти всё то, что было в компьютерных играх, добралось до реальных.

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

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

Зная профессионализм большинства жителей планеты Habrahabr, я решил опубликовать свое исследование здесь. Для того, чтобы 1) получить дополнительную информацию об этом интереснейшем кейсе, 2) попробовать узнать через профсообщество, кто автор этого гигантского PR-проекта? (смотрите новое исследование об идеологе этого проекта от 5 августа)

В первую очередь, надо понимать, что за этой игрой от Niantic стоит 3 корпорации с огромными денежными и PR-ресурсами: Nintendo, Google (с 2015 Alphabet) и The Pokémon Company. У них есть опыт и ресурсы, чтобы «бомба мирового интереса взорвалась». И она взорвалась.

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

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

Взявшись за написание небольшого, но реального и растущего проекта, мы «на собственной шкуре» убедились, насколько важно то, чтобы программа не только хорошо работала, но и была хорошо организована. Не верьте, что продуманная архитектура нужна только большим проектам (просто для больших проектов «смертельность» отсутствия архитектуры очевидна). Сложность, как правило, растет гораздо быстрее размеров программы. И если не позаботиться об этом заранее, то довольно быстро наступает момент, когда ты перестаешь ее контролировать. Правильная архитектура экономит очень много сил, времени и денег. А нередко вообще определяет то, выживет ваш проект или нет. И даже если речь идет всего лишь о «построении табуретки» все равно вначале очень полезно ее спроектировать.

К моему удивлению оказалось, что на вроде бы актуальный вопрос: «Как построить хорошую/красивую архитектуру ПО?» — не так легко найти ответ. Не смотря на то, что есть много книг и статей, посвященных и шаблонам проектирования и принципам проектирования, например, принципам SOLID (кратко описаны тут, подробно и с примерами можно посмотреть тут, тут и тут) и тому, как правильно оформлять код, все равно оставалось чувство, что чего-то важного не хватает. Это было похоже на то, как если бы вам дали множество замечательных и полезных инструментов, но забыли главное — объяснить, а как же «проектировать табуретку».

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

Данная статья является попыткой ответить на эти вопросы хотя бы в первом приближении.

Не забывай свои корни, помни, есть вещи на порядок выше…
Каста здесь

История из жизни

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

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

Сегодня мы поговорим о весёлых макросах.

Большинство программ и алгоритмов можно представить в виде графа, состоящего из набора вершин (N) и ребер (Е). Покрытие графов в тестировании полезно тем, что можно проектировать тесты, используя разные критерии покрытия, и выявить ошибки. Что касается тестирования черного ящика, то покрытие графов здесь тоже может иметь большое значение, если приходится работать с состояниями и переходами, графами состояний сущности и т.д. Если граф достаточно сложен, разные критерии покрытия позволят оценить достаточность тестового набора.

Всем известно — чтобы что-нибудь продать, нужно это что-то или купить, или найти, или отобрать, или ИЗОБРЕСТИ! Вот это, последнее, мы сегодня и разберем. Для чего вообще нужно ставить разработанное программное обеспечение (ПО) на баланс? С чего начать? Когда остановиться? Какие есть пути продажи? Эти и множество других вопросов могут возникнуть у новоиспеченного изобретателя и его руководства. Меня зовут Марина Ремизова, я главбух со стажем работы в ИТ-компаниях, на балансе которых стоит уже не один НМА, и, открою вам тайну – все не так страшно. Изобретать было гораздо сложнее! Давайте пройдем вместе по этому пути.

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

Исходя из определения SaaS (software as a service), пользование программным обеспечением осуществляется в рамках услуг. Однако на практике платный доступ к облачным сервисам оформляется тремя различными договорами:

• договор на информационные услуги,
• лицензионный договор на ПО, и
• договор аренды ПАК.

Ниже вы можете ознакомиться с правовыми рисками применения в рассматриваемых отношениях указанных договоров.

Часто ли вы задумываетесь – почему что-то сделано так или иначе? Почему у вас микросервисы или монолит, двухзвенка или трехзвенка? Зачем вам многослойная архитектура и сколько у вас вообще слоев? Что такое бизнес-логика, логика приложения, презентационная логика и почему все так разделено? Посмотрите на свое приложение – как оно вообще спроектировано? Что в нем и где находится, почему это сделано именно так?
Потому что так написано в книжках или так говорят авторитетные личности? Какие ВАШИ проблемы решает тот или иной подход/паттерн?
Даже то, что на первый взгляд кажется очевидным, порой бывает очень сложно объяснить. А иногда, в попытке объяснения, приходит понимание того, что очевидные мысли были и вовсе ошибочны.
Давайте попробуем взять какой-нибудь пример и изучить на нем эти вопросы со всех сторон.

Я расскажу о применении различных способов аутентификации для веб-приложений, включая аутентификацию по паролю, по сертификатам, по одноразовым паролям, по ключам доступа и по токенам. Коснусь технологии единого входа (Single Sign-On), рассмотрю различные стандарты и протоколы аутентификации.

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

• Идентификация — это заявление о том, кем вы являетесь. В зависимости от ситуации, это может быть имя, адрес электронной почты, номер учетной записи, итд.
• Аутентификация — предоставление доказательств, что вы на самом деле есть тот, кем идентифицировались (от слова “authentic” — истинный, подлинный).
• Авторизация — проверка, что вам разрешен доступ к запрашиваемому ресурсу.

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

Аналогично эти термины применяются в компьютерных системах, где традиционно под идентификацией понимают получение вашей учетной записи (identity) по username или email; под аутентификацией — проверку, что вы знаете пароль от этой учетной записи, а под авторизацией — проверку вашей роли в системе и решение о предоставлении доступа к запрошенной странице или ресурсу.

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

Прим. переводчика — это всего лишь перевод статьи, которая отражает альтернативную точку зрения на тему «Go против Rust». Вовсе не обязятельно показывать свое несогласие с мнением автора на карме переводчика, спасибо.

Эта статья — небольшой ответ к записи в блоге Дейва Чейни «Почему Go и Rust не соперники». Я настоятельно рекомендую вам почитать его доводы! Вероятно, вам также понравится замечательная дискуссия на реддите.

На самом деле, Go и Rust решают одну и ту же самую проблему: оба пришли в наш мир, чтобы сделать жизнь программистов проще. Go до безобразия упростил концепт конкурентного (ака многопоточного) программирования и мне кажется, сделал программирование приятным занятием, ведь код на Go действительно приятно читать. В то ж время, Rust подарил нам мощные zero-cost абстракции… для паттерн-матчинга. Звучит оправданно, не так ли? Шутки-шутками, но Rust действительно сделал многие непростые штуки проще (частое заблуждение: он не избавился от них). Его дьявольская система типов позволяет гарантировать безопасность памяти, и в том числе, избавиться от состояния гонки, что звучит очень заманчиво.

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



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

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

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

В этой статье я попробую ответить на такие вопросы:

• может ли один доклад умного человека сделать другого человека одержимым?
• как окунуться в машинное обучение (почти) с нуля?
• почему не стоит недооценивать многоруких бандитов?
• существует ли серебряная пуля для a/b тестов?

Ответ на первый вопрос будет самым лаконичным — «да». Услышав это выступление bobuk на YaC/M, я восхитился элегантностью подхода и задумался о том, как бы внедрить похожее решение. Я тогда работал продуктовым менеджером в компании Wargaming и как раз занимался т.н. user acquisition services – технологическими решениями для привлечения пользователей, в число которых входила и система для A/B тестирования лендингов. Так что зерна легли на благодатную почву.

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

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

Унифицированный программный интерфейс

Ключевой момент: совместимость с HTTP-методами в плане безопасности и идемпотентности.

Безопасный запрос — это запрос, который не меняет состояние приложения.

Идемпотентный запрос — это запрос, эффект которого от многократного выполнения равен эффекту от однократного выполнения.

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

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

Принципы условно сгруппированы в три группы: принципы принятия решений; принципы, направленные на повышение качества кода; принципы, направленные на повышение производительности кода.

• Принятие решений
  • Любое техническое решение должно быть обосновано
  • Ответственность за принятое решение всегда лежит на том или тех, кто принял данное решение
  • При принятии технических решений необходимо учитывать их действие во времени и их соответствие потребностям бизнеса
  • Одним из основных критериев при принятии технических и иных решений должна быть их наибольшая эффективность
  • Смело отступать от правил, методологий, шаблонов и прочих ограничений, если эффект от такого отступления превышает возможные потери (Special cases aren't special enough to break the rules, although practicality beats purity)
  • При необходимости сделать работающее, но, возможно, не наилучшее, решение сразу, а позднее улучшить его (Now is better than never, although never is often better than *right* now)
  • Если сложно выбрать между двумя альтернативными техническими решениями, то нужно выбрать любое и двигаться с ним дальше, когда появится больше инфорации, то можно будет сделать рефакторинг, если решение оказалось неоптимальным
  • Гибкость технических решений крайне желательна, а универсальность не обязательна
• Качество исходного кода
  • Качество кода следует оптимизировать на базе сформированной системы критериев, сбалансированной по отношению к затратам в краткосрочном и долгосрочном периодах
  • Писать оптимальный код сразу, если это не увеличивает его сложность и сроки разработки (Beautiful is better than ugly)
  • Самодокументируемый код имеет приоритет над хорошо прокомментированным (Beautiful is better than ugly)
  • Писать TODO и FIXME в коде
  • Давать переменным, функциям, методам, классам и другим объектам исходного кода имена точно отражающие их назначение, несмотря на увеличение длины названий (Explicit is better than implicit)
  • Меньшее число строк и объем кода предпочтительнее, при сохранении прежней читабельности кода (Simple is better than complex)
  • Применять инспекцию кода (code review) как инструмент обнаружения ошибок, выравнивания стиля разработки, знакомства с чужим кодом и обучения в команде
  • Применять повторное использование своего и чужого кода
  • Использовать специализированные библиотеки для решения конкретных задач, вместо разработки своего аналогичного кода
• Производительность
  • Производительность разработки кода имеет приоритет над производительностью исполнения кода
  • Оптимизация производительности исполнения кода должна быть обоснована соответствующей потребностью
  • Оптимизация производительности исполнения кода должна выполняться за счет устранения наиболее серьезных узких мест
  • В первую очередь должны быть использованы наиболее эффективные методы оптимизации производительности исполнения кода

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

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

• Ухудшало взаимодействие с пользователем. Нужно передавать в функцию специально сконструированный объект. Не понятно что делать с необязательными аргументами.
• Усложняло разработку. При наследовании классов нужно наследовать соответствующие структуры аргументов. С namedtuple-ом не получится это сделать, надо писать собственный хитрый класс. Куча работы по внедрению.
• И главное, все равно полностью не спасало от опечаток в именах.

Решение, к которому я в итоге пришел, не может защитить в 100% всех возможных случаев, однако в тех необходимых 80% (в моем проекте, 100%) прекрасно справляется со своей задачей. Если кратко, оно заключается в анализе исходного (байт)кода функции, построении матрицы расстояний между найденными «настоящими» именами и переданными извне и печати предупреждений по заданным критериям. Исходники.

Время от времени вдруг начинает хотеться именованных параметров в C++. Не так давно была статья, да и сам какое-то время назад писал на эту тему. И вот что удивительно — со времен той своей статьи я участвую в новом проекте без необходимости тащить за собой старый код, и как-то удивительным образом всего этого описанного собой же не использую. Т.е. в вопросе разобрался, восхитился перспективами… и продолжил работать по-старинке! Как же так? Лень? Инерция? Ответ постараюсь дать под катом.

В далекие времена, для IT-индустрии это 70-е годы прошлого века, ученые-математики (так раньше назывались программисты) сражались как Дон-Кихоты в неравном бою с компьютерами, которые тогда были размером с маленькие ветряные мельницы. Задачи ставились серьезные: поиск вражеских подлодок в океане по снимкам с орбиты, расчет баллистики ракет дальнего действия, и прочее. Для их решения компьютер должен оперировать действительными числами, которых, как известно, континуум, тогда как память конечна. Поэтому приходится отображать этот континуум на конечное множество нулей и единиц. В поисках компромисса между скоростью, размером и точностью представления ученые предложили числа с плавающей запятой (или плавающей точкой, если по-буржуйски).

Арифметика с плавающей запятой почему-то считается экзотической областью компьютерных наук, учитывая, что соответствующие типы данных присутствуют в каждом языке программирования. Я сам, если честно, никогда не придавал особого значения компьютерной арифметике, пока решая одну и ту же задачу на CPU и GPU получил разный результат. Оказалось, что в потайных углах этой области скрываются очень любопытные и странные явления: некоммутативность и неассоциативность арифметических операций, ноль со знаком, разность неравных чисел дает ноль, и прочее. Корни этого айсберга уходят глубоко в математику, а я под катом постараюсь обрисовать лишь то, что лежит на поверхности.

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