Только я один вижу на видео, как вначале на месте тетриса отверстие, а при в включении оно заполняется неким экраном? Или это все настолько очевидно, что про это даже никто не пишет?
Это действительно хорошее применение DSL — ведь сырой regex читается с трудом. Но я в своей работе DSL так никогда и не использовал, — то ли задач не было то ли не смог найти адекватное применение. Было бы интересно так же почитать как DSL помогает в других рутинных, но реальных задачах.
Жуков по вертикали чуть больше 10 и размер их 16. Получается не больше 200 пикселей. Используется маштабирование изначального канваса 1 к 5?
ЗЫ. Бекграунд тоже отлично прорисованный. Я не думаю, что бы сделал подобный за один день, по крайней мере, не зная инструментов.
Советую посмотреть еще Google App Engine, он бесплатный в пределах определенного трафика (Это вариант PaaS), Ну а если IaaS больше по душе и не жалко средств, то Google Cloud Computing cloud.google.com/pricing как по мне подешевле. Amazon имхо — это если бизнес «удался»…
На сколько я понял из статьи на IPS невозможно сделать 144 Гц, и действительно я таих мониторов не видел. Но что мне не понятно — это как работает TrueMotion на LG телеках. Там вроде честные 200Гц и AH-IPS. Поправтье меня, пожалуйста, если ошибаюсь.
Вот случай недавно был. Хотел поиграть с другом в TowerFall Ascension. Купил 2-ю копию, переслал ему как подарок. А потом выяснилось, что игра на 2-х только локально. Конечно сам виноват что не посмотрел сразу, но на сколько я понял возврат срадств за подарки невозможен. Так ли это?
У меня вообще получилось странно. Я прицепился к выражению «лицевая сторона» и подумал, что лицевая сторона находиться на стороне задающего задачу. Ответил неправильно. Потом, посмотрев ролик, увидел, что это «one face». Жаль, что не получилось поучасвовать в тесте, как его задумывал автор.
Для некоторых игр нужно одновременное нажатие например: Вверх, вправо, A, B. Будет проблема если контроллер клавиатуры не поддерживает одновременно 4 нажатия.
Я имел в виду, что merge не будет автоматическим. Но по сути, это мелочи по сравению с самой главной причиной — если будут исправления в комите, или новый комит связанный с ревью, то нужно будет снава запускать автотесты, а это долго и отнимает ресурсы CI
Все верно — автоматизации столько же. Но, если после ревью понадобилось делать правки в коде, то в мастер возможно попадет неотестированный код и сессия автотестов для следующего нормального комита другого разработчика может не пройти.
1. Предметом ревью является только код фичи и код тестов. По процессу тесты должны быть запущены перед ревью, локально. Я упустил этот «нулевой» шаг во флоу — прошу прощения. Если, автор ревью «забыл» прогнать тесты, ревьюер может ему об этом напомнить и заморозить ревью.
2. В описаном вами случае — код не попадет в master и никого не сможет потревожить. Такое бывает в 2-х случаях в основном: Тесты не были запущены локально. Или запущены были, но человек локально не сделал pull перед запуском.
Сейчас git.
Наш флоу такой:
1. обязательно пройти pre-push peer code review,
2. Push в спец ветку
3. Jenkins настроен на запуск автотестов с этой ветки (интеграция с герит)
4. Если тесты прошли -> автомердж изменений в мастер.
Если позволить gerit, то можно постараться поменять флоу на
1. Push в спец ветку
2. Автотесты
3. post-push peer code review с помощью gerit
4. Автомердж в master
но мне не нравиться разрывать автоматический флоу в пункте 2 и 4 необходимостью пройти пир ревью. То есть хотелось бы код ревью оставить обязательным, но меньше делать мануальных действий.
Спасибо.
venturebeat.com/2019/10/21/steam-officially-launches-remote-play-together-beta-for-everyone
ЗЫ. Бекграунд тоже отлично прорисованный. Я не думаю, что бы сделал подобный за один день, по крайней мере, не зная инструментов.
Можно, но тогда он уже не будет автоматическим )
1. Предметом ревью является только код фичи и код тестов. По процессу тесты должны быть запущены перед ревью, локально. Я упустил этот «нулевой» шаг во флоу — прошу прощения. Если, автор ревью «забыл» прогнать тесты, ревьюер может ему об этом напомнить и заморозить ревью.
2. В описаном вами случае — код не попадет в master и никого не сможет потревожить. Такое бывает в 2-х случаях в основном: Тесты не были запущены локально. Или запущены были, но человек локально не сделал pull перед запуском.
Наш флоу такой:
1. обязательно пройти pre-push peer code review,
2. Push в спец ветку
3. Jenkins настроен на запуск автотестов с этой ветки (интеграция с герит)
4. Если тесты прошли -> автомердж изменений в мастер.
Если позволить gerit, то можно постараться поменять флоу на
1. Push в спец ветку
2. Автотесты
3. post-push peer code review с помощью gerit
4. Автомердж в master
но мне не нравиться разрывать автоматический флоу в пункте 2 и 4 необходимостью пройти пир ревью. То есть хотелось бы код ревью оставить обязательным, но меньше делать мануальных действий.
Спасибо.