Об авторе: Хэм Фокке — разработчик и консультант ThoughtWorks в Германии. Устав от деплоя в три ночи, он добавил в свой инструментарий средства непрерывной доставки и тщательной автоматизации. Сейчас налаживает такие системы другим командам для обеспечения надёжной и эффективной поставки программного обеспечения. Так он экономит компаниям время, которое эти надоедливые людишки тратили на свои выходки.

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

Первая часть статьи здесь.

Часть 6. Избегание коллизий

Для правильной навигации NPC часто требуется способность избегать препятствий. В этой части мы рассмотрим steering behavior collision avoidance (избегание коллизий), позволяющее персонажам благополучно уворачиваться от препятствий в окружении.

---

Введение

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

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


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

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

Объяснение

Что же такое hitbox и hurtbox? Разве это не одно и то же?

Ответ может зависеть от того, кому вы зададите вопрос, но в статье мы будем придерживаться мнения, что hitbox и hurtbox — это два различных понятия с разным применением, как это бывает в любой достойной игре-файтинге.

Hitbox — это невидимый прямоугольник (или сфера), определяющий, куда попадает атака.

Hurtbox — это тоже невидимый прямоугольник (или сфера), но определяющий место, в которое игрок или объект может ударить с помощью Hitbox.


На этом изображении из Street Fighter IV красный прямоугольник — это hitbox, а зелёный — hurtbox

Корпорация Google с каждым годом усиливает своё влияние. Минули времена, когда люди делились ссылкой на новый поисковик с экзотическим названием google.com вообще без рекламы, а потом инвайты на Gmail ценились на вес золота. Сейчас ситуация совершенно иная. Как-то незаметно Google вырос и изменил бизнес-модель.

Активисты движения Restore Privacy считают, что «вся бизнес-модель Google основана на том, что вы становитесь под их корпоративную слежку. Вот и всё. Все, что они делают — это переупаковывают массовую корпоративную слежку в удобные, бесплатные, модные приложения, которые засасывают все ваши данные. Ваши личные данные помогают Google доминировать на рынке интернет-рекламы».

В такой модели вы являетесь продуктом.

Введение

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

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

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

Недавно на одном онлайн-форуме был задан вопрос: насколько востребована математика в условиях работы реального программиста, как часто он пользуется ей и каким ее областями? И вот мой ответ.

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

Далее, я часто занимаюсь анализом трудоемкости алгоритмов. Размеры наборов данных, подвергаемые обработке в наши дни, просто колоссальны. В 2010 году на конференции Techonomy Эрик Шмидт сказал, что объем данных, создаваемых сегодня человечеством всего за два дня, равен объему всех существовавших в мире данных по состоянию на 2003 год. Мне важно уметь обрабатывать большие сегменты этих объемов и извлекать из них пользу. И в этом смысле понимание пространственно-временной сложности операций, применяемых нами к данным есть ключ к определению того, возможны ли те или иные вычисления в принципе. В отличие от более традиционных видов O-анализа или тета-анализа постоянные множители в таких масштабах оказывают существенное влияние: множитель 2 не меняет асимптотическую временную сложность алгоритма, но потребует увеличения количества процессоров с 10 тыс. до 20 тыс., и такая разница в потреблении ресурсов будет ощутима. В результате вычисления становятся более изощренными. Примеры: могу ли я взять некое линейное вычисление и снизить его в силе до логарифмического? Можно ли снизить потребление памяти в три раза? И так далее.

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

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

Очевидно, что лучше предотвратить болезнь, чем впоследствии ее лечить.

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

Наша техподдержка работает активно, очень активно. Она консультирует, помогает настроить и, конечно, решает проблемы в видеосистемах. Часто эти проблемы видны в среде ПО, но с Macroscop они не связаны. Видеосистема многокомпонентна, если что-то в ней ломается или просто не работает должным образом, пользователь не увидит, что какая-то часть испортилась. Он увидит, что в realtime-видео появились рывки, а в архиве – “дырки”. Значит ли это, что проблема в ПО? Часто причина совсем в другом.

– Нет, так дело не пойдет! – почти кричал взбешенный Анатолий Викторович. – Я не понимаю, за что плачу такие – заметьте, не малые – деньги! Чем программисты лучше других? Они что, какие-то особенные?

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

– Вот этими сказками я уже сыт по горло, про таинство творческих профессий! Слава Богу, у нас еще дизайнеров нет…

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


Уже 25 мая угроза штрафа в 20 млн Евро или 4% от мирового оборота (что из этого больше) станет реальностью – впадать в панику или не впадать? Поскольку я уже ливанул ведро бензина в огонь, чувствую себя обязаным показать дорогу к пожарному выходу, не дожидаясь анонсированного в предыдущей статье события. Зарание прошу прощения за шероховатости – экспромт, очень fast и очень dirty, зато полезность зашкаливает (надеюсь).

Как давно вы проверяли надежность своего SSL? Мало просто купить SSL сертификат и его установить, нужно его и настроить.

Почему это важно. Внешний анализ безопасности (ручной или автоматический) обычно начинается с проверки SSL-конфигурации. SSL конфигурация обычно показывает общий уровень защищенности всей системы защиты данных. Поэтому продвинутые пользователи начинают слать запросы типа “как вы можете защитить мои персональные данные, если у вас ещё SSL v3 включён”. В рамках GDPR надежная настройка SSL относится к техническим мерам по защите персональных данных.

Тестирование конфигурации SSL

Проблемы связанные с версиями SSL протоколов:

• SSL v2 небезопасен, устарел и не рекомендуется для использования. См. атаку DROWN по этому протоколу.
• SSL v3 небезопасен и устаревший инструмент. См. атаку POODLE.
• TLS v1.0 также является устаревшим протоколом, но на практике он все же оказывается необходим. Его основная слабость (BEAST) была смягчена в современных браузерах.
• TLS v1.1 и TLS v1.2 оба не имеют известных проблем с безопасностью, но только v1.2 предоставляет современные криптографические алгоритмы.

SSL 2.0, SSL 3.0 и TLS 1.0 настоятельно рекомендуется отключить, так как большинство стандартов безопасности их уже давно не поддерживают (например, PCI DSS 3.1).

Рекомендуемые протоколы TLS v1.1 и TLS v1.2 с актуальными алгоритмами шифрование и снятия хэшей.

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

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



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

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

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



Я уезжаю в любое удобное время, кидаю ключи туда – и всё готово. Он приходит, открывает дверь своим комплектом и поднимает с пола гостевой. Есть противоположность такого интерфейса по удобству — система установки номера вагона в одном из поездов РЖД (ФПК).

Провайдеры услуг публичного облака в конце 2017 объявили о своем доходе за 3 квартал. Показатели дохода впечатляют своим размером и скоростью роста. Совокупный доход трёх крупных компаний (Amazon Web Services, Microsoft Azure и Google Cloud Platform) составил 7,5 млрд долларов за третий квартал или 30 млрд долларов США в пересчете на год.

10 миллиардов долларов в расходах на облака являются потерями

Аналитики RightScale задались вопросом, сколько доходов облачных провайдеров приходится на арендаторов, которые не понимают, как они могли бы предотвратить напрасные потери в совокупных затратах на облачные вычисления. Ранее в отчете «RightScale 2017 State of the Cloud Report» было отмечено, что пользователи облачных вычислений считают, что излишние затраты достигают 30 процентов от расходов на облако. На самом деле, вероятно, что эта цифра даже выше.

Недавно я выпустил свою первую игру BYTEPATH и мне показалось, что будет полезно записать свои мысли о том, чему я научился в процессе её создания. Я разделю эти уроки на «мягкие» и «жёсткие»: под мягкими я подразумеваю идеи, связанные с разработкой ПО, жёсткие — это более технические аспекты программирования. Кроме того, я расскажу о том, почему хочу написать собственный движок.

Мягкие уроки

Сообщу ради контекста, что начал делать собственные игры примерно 5-6 лет назад и у меня есть 3 «серьёзных» проекта, над которыми я работал до выпуска первой игры. Два из эти проектов мертвы и полностью провалились, а последний я временно приостановил, чтобы поработать над BYTEPATH.


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

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

В этой статье мы рассматриваем ПО, которое способно справиться с этими задачами.

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

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

Кейси Муратори — один из программистов игры The Witness. В процессе разработки игры он публиковал в своём блоге посты о технических задачах, которые перед ним вставали. Ниже представлен перевод одного из таких постов.

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

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

Код, описанный мной на прошлой неделе, уже встроен в дерево исходников The Witness вместе с множеством других не связанных с ним модификаций системы травы, о которых я расскажу на следующей неделе. Это было разумное решение очевидной проблемы, а времени было в обрез, поэтому я знал, что тогда было не до решения более глубоких вопросов. Но в голове я сделал мысленную заметку о том, что в следующий раз при работе над генерацией паттернов, мне нужно задаться вопросом «почему». Благодаря времени, выделенному на написание этой статьи, я получил такую возможность.

Вопрос «почему» в этом случае достаточно прост: почему мы используем для размещения травы синий шум?