Пользователь
У задач классификации, в отличии от задач регрессии, есть одно очень приятное свойство:
большинство ML алгоритмов решения задач классификации выдают не просто ответ, а некоторую оценку уверенности модели в ответе. То есть помимо метрик самой модели мы обладаем оценкой вероятности для конкретного ответа на конкретном примере. Это здорово помогает в принятии решений.
Неправда ли хотелось бы иметь что-то такое и для задач регресии?
Дизайн-система позволяет быстро взаимодействовать с компонентами, легко вносить изменения во все макеты и в целом прививает дизайнеру навык организации больших объемов информации.
Зачастую, дизайнер начинает делать дизайн-систему аккуратно, придавая ей должное внимание. Но в по мере увеличения экранов становится, как мне кажется, морально труднее вносить новые компоненты и корректировки. Но помните одну вещь - чем больше времени уделить дизайн-системе, тем больше времени она сэкономит в будущем.
Основное правило дизайн-систем: чем меньше компонентов — тем лучше и вам, разработчику и конечному юзеру. Это касается количества цветов, шрифтов, иконок и так далее. Дизайн будет выглядеть более консистентным и единым.
Источник картинки
Работающий код может иметь изъяны — например, быть недостаточно простым, лаконичным и понятным. Это может быть признаком более глубоких проблем в коде, а избавиться от них можно с помощью рефакторинга. В этой статье разберем наиболее популярные недостатки кода. Материал адаптирован на русский язык вместе с Глебом Михеевым, директором по технологиям Skillbox и спикером профессии «Frontend-разработчик PRO» и преподавателем курса Frontend-разработки в Skillbox Борзуновым Игорем.
В предыдущих статьях "PostgreSQL Antipatterns: навигация по реестру", "PostgreSQL 13: happy pagination WITH TIES" и "SQL HowTo: курсорный пейджинг с неподходящей сортировкой" я уже рассматривал проблемы навигации по данным, представленных в виде плоского реестра.
Но что если мы хотим выводить данные не простым "бесконечным списком", а в виде иерархической структуры с быстрой навигацией по узлам - например, обширный каталог товаров или меню ресторана, как это делает Presto - наш продукт для автоматизации заведений питания? Вот тут нам и придется что-то поизобретать...
Научитесь внедрять рандомизацию в создаваемую игру, чтобы игроки оставались вовлечены в процесс и стремились перейти к следующей сцене. Это второй пост Кристо Ноббса, посвященный разработке систем, основанный на авторском вкладе Кристо в книгу The Unity game designer playbook. В данной книге подробнее рассказано о том, как прототипировать, собирать и тестировать игровой процесс (геймплей) в Unity.
В более раннем посте Кристо рассказывал, как разработчики могут создавать в своих играх такие системы, которые позволяют построить интригующий и неожиданный геймплей. Данный пост более узкоспециальный, рассказывает о том, как правильно организовать в игре рандомизацию.
Привет, друзья!
В данной шпаргалке представлены все основные интерфейсы и методы по работе с медиа в браузере, описываемые в следующих спецификациях:
Шпаргалка представлена в форме вопрос-ответ.
Туториалы по теме:
Если вам это интересно, прошу под кат.
Привет, Хабр! В свободное от работы время по вечерам мне нравится воплощать в жизнь свои сумасшедшие идеи. В один из таких вечеров родилась мысль реализовать компилятор кода в машину Тьюринга. Осознав всю тщетность бытия сложность реализации, было принято решение начать с чего-то более простого – симулятора простенького процессора со своим собственным ассемблером, в котором команды выполнялись бы с помощью различных состояний машины Тьюринга, а данные хранились бы на одной ленте. В конечном итоге удалось осуществить практически первоначальную задумку, а именно получить одну единственную машину Тьюринга, способную выполнять скомпилированную из NASM подобного ассемблера программу без какого-либо внешнего взаимодействия.
Привет, меня зовут Владимир Кононенко и я – руководитель управления внедрения в Группе компаний ОТР. Всем, кто работает с информационными системами (ИС), знакома такая история: на определенном этапе жизненного цикла ИС возникают ситуации, когда заказчик, использующий ИС, высказывает недовольство, что все тормозит, пользователи не могут работать, софт не выдерживает нагрузку, и так далее. В данной статье я бы хотел пошагово рассказать, как я решаю проблемы с производительностью и стабильностью ИС, созданных нашей компанией.
Я буду опираться на личный опыт и практику в недавних проектах ОТР – у нас много крутых специалистов с высоким уровнем экспертизы, есть центр компетенций PostgreSQL – а также на собственные знания: в свое время я окончил с отличием Ростовский государственный университет по специальности «Математические методы и исследование операций в экономике», а также получил сертифицированный черный пояс по программе «Шесть сигм» Государственного университета штата Аризона, США. На примерах из моей практики вы увидите, какие я выбираю инструменты и как они работают на каждом этапе.
Так уж повелось, что знание математики редко считают необходимым для работы геймдизайнером — а если оно и требуется, то школьной программы хватит. Чаще всего так и есть. Но иногда знание определенных концепций и методов из вышмата может упростить жизнь и помочь иначе взглянуть на проблему.
Всем привет, меня зовут Лев, я геймдизайнер из WhaleKit. И в этой статье мы разберем две математические концепции: цепи Маркова и случайные блуждания. Сразу замечу, что статья скорее «поп», чем «науч», поэтому часть доказательств выведенных формул будет опущена. После теории мы перейдем к реальным кейсам, где эти инструменты могут пригодиться, например:
1. Сколько сундуков откроет игрок, если из сундуков могут выпасть еще сундуки;
2. Сколько золота уйдет на прокачку меча, если меч может ломаться;
3. Какая вероятность победить в денежном поединке.
Однажды, если мне не изменяет память, в Нью-Йоркском университете кто-то сформулировал определение геймдизайна как «мотивирование игрока на определенные действия». Хорошая формулировка. По аналогии с ней, про левел-дизайн я бы сказал так:
Левел-дизайн — это мотивирование игрока на определенные действия через окружение, в котором существует управляемый персонаж.
Почему мы отталкиваемся от определения геймдизайна — хотя, казалось бы, я должен отстаивать левел-дизайн как самостоятельную нишу? Всё очень просто: наша первая и основная задача — подкреплять в пространстве механики, заложенные геймдизайном. Давать игроку возможность поиграть. А «душную» поправку про управляемого персонажа я добавил тогда, когда в очередной раз услышал в обсуждении левел-дизайна споры про интерфейс. Давайте забудем про него на время прочтения этой статьи: все-таки UI почти всегда существует вне игрового пространства и не является инструментом левел-дизайнера.
А теперь, когда у нас есть определение, разберемся в сущности левел-дизайна.
Откуда возникла эта ниша? Что левел-дизайнер отдаёт в результате работы над локациями? В этом мы и будем разбираться дальше в этой статье. А вообще их будет целый цикл, в котором я постараюсь охватить всю базу этой области геймдизайна от самых основ до приемов AAA-сегмента.
Из новостей: культовая демо-сцена Sponza получила обновление, Wolfire Games выложила в открытый доступ исходный код Overgrowth, официально запустился SketchUp для iPad, Steam возобновил выплаты для разработчиков из России, вышел Mudbox 2023.
Из интересностей: как создавалась игра Among Us, диздок игры Crankin для Playdate от Кейты Такахаши, про дизайн окружения и уровней Dying Light 2.