Должен признаться: я читаю ACM Magazine. Это делает меня «ботаником» даже по меркам программистов. Среди прочего, я узнал из этого журнала о «метаморфическом тестировании». Раньше я никогда о нём не слышал, как и все люди, которых я спрашивал. Но научная литература по этой теме на удивление объёмна: есть множество невероятно успешных примеров её применения в совершенно разных областях исследований. Так почему же мы не слышали о нём раньше? Существует только одна статья для людей вне научных кругов. Пусть теперь их будет две.

Краткая предыстория

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

def test_dist():
    p1 = (0, 3)
    p2 = (4, 0)
    assert dist(p1, p2) == 5

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

Это приводит нас к генеративному тестированию (generative testing): написанию тестов, покрывающих случайное множество в пространстве состояний. Самым популярным стилем генеративного тестирования является property based testing, или PBT. Мы находим «свойство» (property) функции, а затем генерируем входные значения и проверяем, соответствуют ли выходные значения этому свойству.

def test_dist():
    p1 = random_point()
    p2 = random_point()
    assert dist(p1, p2) >= 0

Преимущество PBT заключается в покрытии большего пространства. Его недостаток — утеря специфичности. Это уже не оракул-тест! Мы не знаем, каким должен быть ответ, и функция может быть ошибочна, но таким образом, что обладает тем же свойством. Здесь мы полагаемся на эвристики.

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

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

В этой статье я тезисно перечислю наиболее интересные для меня выводы и чеклисты, которые я нашёл в книге Рафа Костера «Theory of Fun for Game Design».

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

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

Если вам это знакомо, то данная статья как раз для вас, так что продолжайте читать.

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

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

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

Unity — платформа, которая существует довольно давно и постоянно развивается. Однако, работая в ней с несколькими проектами одновременно, все еще можно столкнуться со сложностями в использовании общих исходников (.cs), библиотек (.dll) и остальных ассетов (изображения, звуки, модели, префабы). В этой статье мы расскажем о нашем опыте работы с нативным решением такой проблемы для Unity.

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

Вы настолько хорошо умеете их готовить, что могли бы получить звезду Мишлена (а то и две), будь у вас свой ресторан. Конечно! Никто не останется равнодушным, отведав ваш Буйабес с корутинным соусом.

Уже целую неделю код в проде не падает! Обертки, callback’и и методы Start/Stop Coroutine — удел холопов. Вам нужно больше контроля и свободы действий. Вы готовы подняться на следующую ступеньку (но не бросить корутины, конечно).

Если в этих строках вы узнали себя, — добро пожаловать под кат.

Если вы когда-либо сделали игру, вероятно, вы столкнулись с той же проблемой, что и многие другие разработчики до вас: никто не знает о вашей игре. Под катом я расскажу, как рассказать миру о вашей инкрементальной** игре бесплатно, быстро и эффективно (в какой-то степени).

Раньше я очень любил C#

Это был мой основной язык программирования, и каждый раз, когда я сравнивал его с другими, я радовался тому, что в свое время случайно выбрал именно его. Python и Javascript сразу проигрывают динамической типизацией (если к джаваскрипту понятие типизации вообще имеет смысл применять), Java уступает дженериками, отстутствием ивентов, value-типов, вытекающей из этого карусели с разделением примитивов и объектов на два лагеря и зеркальными классами-обертками вроде Integer, отсутствием пропертей и так далее. Одним словом — C# клевый.

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

А потом я из любопытства попробовал F#.

В новой версии unity 2018 года наконец официально добавили новую систему Entity component system или сокращенно ECS которая позволяет вместо привычной работы с компонентами объекта работать только с их данными.

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

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

Примечание: Материалы статьи опираются на исследования Е.Д. Авериной, Д.Б. Никуличевой, Э.В. Гуннемарка и П.Нейшна, пропущенные через призму моего восприятия и опыт изучения 3 иностранных языков.

В Unity3D с выходом версии 2018 появилась возможность использовать нативную (для Unity) ECS систему, сдобренную многопоточностью в виде Job System. Материалов в интернете не особо много (пара проектов от самих Unity Technologies да пара обучающих видео на ютубе). Я попробовал осознать масштаб и удобность ECS, сделав небольшой проект не из кубов и кнопок. До этого у меня не было опыта проектирования ECS, так что два дня ушло на изучение материалов и перестроение мышления с ООП, день ушел на восхищение подходом, и еще один-два дня — на разработку проекта, борьбу с Unity, выдергивание волос и курение семплов. В статье содержится немного теории и небольшой пример проекта.

Сколько уже было мануалов "Как сделать игру на Unity за 3 часа", "Делаем Counter-Strike за вечер" и т.п.? Низкий порог входа — это, несомненно, главный плюс и минус Unity. Действительно, можно накидать “ассетов”, дописать несколько простых “скриптов”, обмотать синей изолентой и это даже будет как-то работать. Но когда проект обрастает игровыми механиками, сложной логикой поведения, то проблемы при подобном подходе нарастают как снежный ком. Для внедрения новых механик требуется переписывание кода во многих местах, постоянная проверка и переделывание префабов из-за побившихся ссылок на компоненты логики, не говоря уже об оптимизации и тестировании всего этого. Разумеется, архитектуру можно продумать изначально, но на практике это всегда недостижимая цель — дизайн-документ довольно часто меняется, какие-то части выкидываются, добавляются абсолютно новые и никак не связанные со старой логикой поведения. Компоненты в Unity — это шаг в правильном направлении в виде декомпозиции кода на изолированные блоки, но особенности реализации не позволяют достичь необходимой гибкости, а самое главное, производительности. Разработчики придумывают свои фреймворки и велосипеды, но чаще всего останавливаются на ECS (Entity Component System). ECS – одно из решений, продолжающее идею компонентной модели Unity, но придающее ей ещё больше гибкости и сильно упрощающее рефакторинг и дальнейшее расширение приложения новым функционалом без кардинальных изменений в текущем коде.

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

Для людей с научным складом ума естественно пытаться применять рациональные методы для оценки рисков повседневной жизни. К примеру, надо ли делать прививку от гриппа, если вам нет 40 лет и вы здоровы? Нужно ли выпрыгивать из самолёта (с парашютом)? Благородная цель, применение логики для оценки рисков, однако, сталкивается с двумя препятствиями. Во-первых, в отсутствии определённости мы обычно принимаем решения на основании комбинации из интуиции и целесообразности, и довольно часто это срабатывает. Во-вторых, нас постоянно атакует множество всё время изменяющихся случайных событий. "Как случайность управляет нашей жизнью" – такой подзаголовок был у весьма поучительного бестселлера Леонарда Млодинова. Эти постоянные тычки от случайных сил красочно продемонстрированы в этом отрывке, перефразированном из гораздо более длинной детской сказки 1964 года под названием "К счастью" Реми Чарлипа, который вдохновил нашу первую задачу.

С этой теорией заговора может сравниться разве что история про фейковый полет на Луну. Её сторонники верят, убеждают других, бьют себя в грудь… Но понимаете ли вы, реальность или миф — глобальное потепление? Если нет, то обязательно посмотрите наш новый выпуск с Александром Сергеевым про миф и реальность глобального потепления. А под катом вы найдёте расшифровку этого видео, максимально адаптированную для чтения.

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

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

На этот пост меня подтолкнула публикация «Почему я ворую книги, бедные авторы, и как это исправить», а именно — скепсис и возражения на мой комментарий о том, что я не читаю плохие книги. Мне предложили рассказать, как я выбираю книги для чтения и что именно читаю. Ну я и повелся.
Оформить список было сравнительно просто, FBReader любезно хранил на GoogleDrive все скачанные книги с того момента, как там появилась эта услуга. Предлагаю вашему вниманию список прочитанного мной за 2,5 года из жанров фентези и фантастики.

Не забудьте почитать:
Что такое качество в веб-дизайне: примеры и рекомендации. Часть 1. (или здесь)
Что такое качество в веб-дизайне: примеры и рекомендации. Часть 2. (или здесь)

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

05. Сдержанность и деликатность

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

Несколько выдающихся примеров и рекомендаций по созданию качественного дизайна веб-страницы или блога



Многие люди склонны описывать предоставляемые ими услуги по веб-дизайну как «качественные». Но что означает здесь слово «качество», как определить, является дизайн качественным или нет? Что ж, я вижу несколько способов определить качество применительно к сфере веб-дизайна. Ведь если однажды определить, что позволяет создавать качественный веб-дизайн, можно использовать эти же приемы для оттачивания собственного стиля.

Чтобы объяснить, как я понимаю качество в дизайне веб-сайтов, я собрал несколько рекомендаций и примеров.

Компания Tesla Motors не перестаёт удивлять своими электромобилями.
Напомню — эта молодая компания наделала много шуму своим Tesla Roadster.
И вот на днях был продемонстрирован семейный седан Tesla Model S.

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