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

Привет, хабр! Продолжаю делиться полезными подборками. Совсем недавно я опубликовал 2 поста с перечнем Github репозиториев: Часть1 и Часть2. На этот раз предлагаю вашему вниманию подборку полезных книг для разработчиков. Кому интересно — добро пожаловать под кат.

Зачем это читать?

Всем привет! Меня зовут Винсент, и я с 2018 года живу в Кремниевой Долине со своей супругой и сыном.

Своим фильмом, Дудь хотел поднять стартапный ажиотаж в России, но в итоге возбудил всех моих товарищей гораздо больше здесь, в Silicon Valley.

Этот пост — расчет стоимости жизни "обычного разработчика" (не "стартапера"), который работает "на дядю". Все максимально честно и подробно.

Самая научно-подтвержденная популярная статья в рунете. Отсюда вы узнаете конкретные способы эффективной профилактики ОРВИ и, вероятно, COVID-19, основанные на самой надёжной информации – мета-анализах клинических исследований.  

В детстве я редко ходил в залы аркадных автоматов, потому что особо в них не нуждался, ведь дома у меня были потрясающие игры для C64… но есть три аркадные игры, на которые у меня всегда находились деньги — Donkey Kong, Dragons Lair и Outrun…

… и я очень любил Outrun — скорость, холмы, пальмы и музыка, даже на слабой версии для C64.


Поэтому я решил попробовать написать олдскульную псевдотрёхмерную гоночную игру в стиле Outrun, Pitstop или Pole position. Я не планирую собрать полную и завершённую игру, но мне кажется, будет интересно заново изучить механики, при помощи которых эти игры реализовывали свои трюки. Кривые, холмы, спрайты и ощущение скорости…

Итак, вот мой «проект на выходные», который в итоге занял пять или шесть недель по выходным

• Сыграть в игру
• Посмотреть исходный код

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

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

Можно также поиграть

• в демо с прямой дорогой
• в демо с кривыми
• в демо с холмами
• в готовую версию

Многим известна проблема трёхмерной графики — отсутствие легковесных кроссплатформенных решений в вопросе вывода текста.

Большинство реализаций позволяет использовать выбранный шрифт в виде текстуры. Публикуемая библиотека ttf2mesh реализует другой способ — она преобразует векторные символы TrueType шрифта в сеточные объекты. Это позволяет выводить текст в виде набора треугольников.

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

В этой части на примере мода для Beat Saber мы рассмотрим общие принципы разработки модов для Unity-игр, узнаем, какие есть трудности, а также познакомимся с Harmony — библиотекой для модификации кода игр, которая используется в RimWorld, Battletech, Cities: Skylines и многих других играх.

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

Недавно я написал небольшой ShaderToy, выполняющий простой объёмный рендеринг, а затем решил опубликовать пост с объяснением его работы. Сам интерактивный ShaderToy можно посмотреть здесь. Если вы читаете с телефона или ноутбука, то рекомендую посмотреть эту быструю версию. Я включил в пост фрагменты кода, которые помогут вам понять работу ShaderToy на высоком уровне, но в них есть не все подробности. Если вы хотите разобраться глубже, то рекомендую сверяться с кодом ShaderToy.

У моего ShaderToy были три основные задачи:

1. Выполнение в реальном времени
2. Простота
3. Физическая корректность (… или типа того)

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

1. Трассировка лучей непрозрачных объектов. Все объекты являются примитивами с простыми пересечениями с лучами (1 плоскость и 3 сферы)
2. Для вычисления освещения используется затенение по Фонгу, а в трёх сферических источниках света применется настраиваемый коэффициент затухания света. Лучи теней не требуются, потому что мы освещаем только плоскость.

Вот как это выглядит:

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

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

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

• В Hellblade предупреждение перед игрой было тщательно продумано, чтобы заставить игроков поверить, будто в игре срабатывает система permadeath в случае, если игрок умирает слишком часто, хотя на самом деле ее там нет.
• Pacman может огибать углы более резко, чем это делают призраки, тем самым наделяя игрока небольшим преимуществом.
• Во многих шутерах последние очки здоровья стоят больше всей остальной шкалы, чтобы усилить чувство «выживания на грани». С той же целью в System Shock последняя пуля нанесет урон в 4 раза более сильный, чем остальные.
• И, напротив, Shadow of Mordor слегка увеличивает здоровье некоторых врагов, чтобы бои длились дольше.
• В Bioshock и Devil May Cry, находясь за спиной игрока, противники замедляют свою атаку.
• В Xcom, если промахнуться много раз подряд, игрок получит скрытый бонус для последующих выстрелов. Кроме того, если игроки остаются пассивными слишком долго, враги усиливают свою агрессивность.
• Похоже, что в Heartstone есть pity timers ― таймеры жалости. Многие другие игры позорно использовали их в более ранние годы.
• В Resident Evil 4 после слишком большого количества смертей заспавнится меньше врагов, чтобы дать игроку больше шансов пройти трудный для него эпизод.
• В любой гоночной игре реализован адаптивный ИИ, чтобы сделать соревнование более жестким.

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

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

Я много пишу в интернетах и мне захотелось завести свой личный стэндалон блог, куда можно писать мелкие заметки и статьи, не подходящие для других площадок. Главная проблема личного блога — мне лень оформлять посты. Чтобы черкануть пару строк в каком-нибудь Wordpress, нужно слишком много телодвижений. Я попробовал несколько разных движков и каждый раз ловил себя на ощущении, что мне не хочется ими пользоваться, намного быстрее и проще писать в записную книжку вроде Evernote или Notion. Так я стал искать идеальный движок для блога, отвечающий всем моим потребностям.

Мои требования к идеальному движку:

• Желательно self-hosted — я пережил много закрытий сервисов, от narod.ru до google+ и точно знаю, что рано или поздно все протухает, поэтому надежнее всего держать контент у себя. Также посты могут удалять по каким-то фейковым жалобам или по DMCA, как это происходит на Medium и LiveJournal.
• Возможность подключения своего домена — мне нужен сайт-визитка со всеми проектами и ссылками в одном месте, где можно разместить портфолио, резюме, контакты.
• Минимум телодвижений и интерфейса — в идеале интерфейса CMS вообще не должно быть видно, админская панель не нужна, посты должны редактироваться, создаваться и просматриваться в одном месте.
• Полноценный WYSIWYG редактор — поддержка разметки Markdown и обработка её в реальном времени, подсветка кода, вставка картинок из буфера обмена.
• Нормальные комментарии — возможность оставлять анонимные комментарии и авторизовываться через максимум соц. сетей для персонифицированных комментариев.
• Минималистичный внешний вид — я не хочу заниматься версткой и темами, подходящее оформление должно быть из коробки.

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

Если вы побродите по форуму DOTS, то можете встретить там подобные посты о том, как автор написал библиотеку, способную рендерить миллион анимированных спрайтов, и всё равно получает только 60fps. Я создал собственный рендерер спрайтов DOTS, который достаточно хорош для нашей игры, но он не способен справиться с миллионом. Мне стало любопытно.

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

Вы руководите командой из нескольких программистов и художников, работающих над портированием красивой VR-игры на PS4 под Oculus Quest. У вас есть на это шесть месяцев. Каким будет ваш первый ход? Давайте попробуем воспользоваться Unity Addressables.

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

Предположу следующее: примерно 70% читателей скажут, что самой большой проблемой при портировании игры на Quest является производительность ЦП/GPU. Я могу ответить на это: скорее всего, вы правы. Повышение производительности — одна из сложнейших областей в VR-игре. Для оптимизаций такого типа необходимо глубокое изучение продукта, а на это требуется время. Иногда дальнейшая оптимизация невозможна, из-за чего обычно приходится избавляться от затратных элементов геймплея и графики. А разочаровывать игроков опасно.

Привет! На связи Станислав Яблонский, Lead Server Developer из Pixonic.

Когда я только пришел в Pixonic, наши игровые сервера представляли собой приложения на основе Photon Realtime SDK: многофункционального, но весьма тяжелого фреймворка. Решение это, казалось бы, должно было упростить работу с сервером. Так оно и было ― до определенного момента.

Photon Realtime привязывал нас к себе тем, что приходилось использовать его для обмена данными между игроками и сервером, ― а также привязывал к ОС Windows, поскольку может работать только на ней. Это накладывало на нас ограничения как с точки зрения runtime (среды исполнения): нельзя было изменить многие важные настройки виртуальной машины .NET, ― так и операционной системы. Мы привыкли работать с Linux-серверами, а не Windows. Кроме того, они нам обходились дешевле.

Также использование Photon било по производительности как на сервере, так и на клиенте, а при профилировании образовывалась приличная нагрузка на сборщик мусора и большое количество boxing/unboxing.

Короче говоря, решение с Photon Realtime было далеко от оптимального для нас, и давно надо было что-то с этим делать ― но всегда находились более срочные задачи, и до решения проблем с сервером руки банально не доходили.

Так как мне было интересно не только решить проблему, но и лучше разобраться в работе сети, я решил взять инициативу в свои руки и попробовать написать библиотеку самостоятельно. Но, сами понимаете, дома ― дом, на работе ― работа, в результате время на разработку библиотеки находилось только в транспорте. Однако это не помешало довести идею до реализации.

Что из этого вышло ― читайте дальше.

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

Этой статьей мы бы хотели ещё раз обратить внимание русскоговорящих Android разработчиков и пользователей на недавние изменения политик Google Play, и немного подробнее рассказать о двух наиболее значимых изменениях: более прозрачных для пользователей предложениях платной подписки и ограничении доступа приложений к геолокации.

Привет, меня зовут Александр Васин, я бэкенд-разработчик в Едадиле. Идея этого материала началась с того, что я хотел разобрать вступительное задание (Я.Диск) в Школу бэкенд-разработки Яндекса. Я начал описывать все тонкости выбора тех или иных технологий, методику тестирования… Получался совсем не разбор, а очень подробный гайд по тому, как писать бэкенды на Python. От первоначальной идеи остались только требования к сервису, на примере которых удобно разбирать инструменты и технологии. В итоге я очнулся на сотне тысяч символов. Ровно столько потребовалось, чтобы рассмотреть всё в мельчайших подробностях. Итак, программа на следующие 100 килобайт: как строить бэкенд сервиса, начиная от выбора инструментов и заканчивая деплоем.



TL;DR: Вот репка на GitHub с приложением, а кто любит (настоящие) лонгриды — прошу под кат.

Изображение: Unsplash

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

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

Я решил разобраться, так ли это на самом деле или в реальности не всё так просто. Для этого я поговорил с Денисом Неклюдовым, Staff Engineer в компании Lyft (конкурент Uber) и автором DevJobAccelerator. Итак, посмотрим, как на самом деле выглядит карьерный путь разработчиков в Кремниевой долине – от старта до компенсаций в миллионы долларов.

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

Ведущий геймдизайнер Ustwo Games, создателей Monument Valley и недавней Assemble with Care для Apple Arcade, рассказал, как студия использует бесплатные инструменты для креативного прототипирования. Перевод под катом.

Приветствую, дорогие любители и профессионалы, программисты графики! Приступаем ко второй части нашего цикла статей про оптимизацию рендера под Mobile. В этой части мы будем рассматривать основные семейства GPU, представленные у игроков на Mobile.

Для начала рассмотрим ряд критериев, по которым можно классифицировать мобильные GPU.

UPD 1: Статья устарела
Используйте feature-sliced.design
UPD 2: ещё у меня есть Telegram-канал, где я собираю ссылки на свои статьи про разработку, развитие SaaS-проектов и управление IT-проектами.

Добрый день, уважаемые читатели. В этой статье мы поговорим об архитектуре программного обеспечения в веб-разработке. Довольно долгое время я и мои коллеги используем вариацию The Clean Architecture для построения архитектуры в своих проектах Frontend проектах. Изначально я взял ее на вооружение с переходом на TypeScript, так как не нашел других подходящих общепринятых архитектурных подходов в мире разработки на React (а пришел я из Android-разработки, где давным-давно, еще до Kotlin, наделала шумихи статья от Fernando Cejas, на которую я до сих пор иногда ссылаюсь).

В данной статье я хочу рассказать вам о нашем опыте применения The Clean Architecture в React-приложениях с использованием TypeScript. Зачем я это рассказываю? — Иногда мне приходится разъяснять и обосновывать ее использование разработчикам, которые еще не знакомы с таким подходом. Поэтому здесь я сделаю детальный разбор с наглядными пояснениями на которое я смогу ссылаться в будущем.

$google = "We don't allow apps that lack reasonable sensitivity towards or capitalize on a natural disaster, atrocity, conflict, death, or other tragic event";
mysql_query("UPDATE cvirus_users SET winners = winners+19, message='$google' WHERE imea='$imea' ");

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

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

Пришлось постараться.