То, что свой код проверять нельзя это ясно, но если кодить спарками аналитик-разработчик, на описании задачи и тестировании аналитик, разработчик понятно чем занимается.
Насколько по вашему это нежизнеспособная ситуация?
Регресс тесты автоматические, пишет команда под архитектором, который как раз становится чуть свободнее к середине проекта, когда появляется необходимость в регрессе.
Уж не говоря о том, что поворот должен быть +-180, а не 0-360.
И кстати, а на момент отделения блок не закручен был? Может поэтому 270 в попутном выгоднее, чем -90?
К акселерометрам просто табличное ускорение свободного падения плюсуют АФАИР, так что реальное ускорение и скорость легко вычисляются. И растёт скорость или нет, легко видно.
Скорчед естественно примитивна до безобразия — там собственно нет объектов кроме танков, любая «земля» падает вертикально вниз.
То что на вашей гифке — вы думаете, если в энгри бёрдс добавить возможность перебивать снарядом блоки на несколько и добавить «гнущиеся» (и ломающиеся при перенапряжении) блоки, то выйдет непохоже?
Навскидку я не могу предложить как нарезать на блоки сплошной «утёс» в который долбимся сбоку, а потом оно падает (первая гифка в статье) Но всё равно, я бы пошёл по пути термеха с динамически меняющимся приближением объектов примитивами. Так что у меня бы с начала не гнулось, а потом сразу ломалось ;)
Правда у меня есть важное отличие от автора статьи — он написал игру, а я — нет. Так что ясно, кого стоит больше слушать.
Тут на первый взгляд Scorched eath с графикой апгрейженной до леммингов. Гнущиеся балки конечно прикольно, и наверное действительно положат ЦПУ если их разложить на 1ККК частиц, но вот увидеть, что это невозможно сделать иначе, обойдясь парой десятков боксов и чуть чуть частиц из ролика не получилось.
С удивлением узнал в своё время, что теплокровность у птиц и млекопитающих зародилась независимо. Почему бы и жизни не возникнуть в одинаковом+- бульёне в нескольких местах?
Не знаю как токари, а начальник автопарка в одной производственной конторе, где я учёт настраивал, получал действительно меньше, чем половина его водителей.
Правда у него оклад и 8 часов, а у них ночные и оплачиваемые переработки.
Continuous delivery это если бы когда ты контролируешь до конечного продукта. То есть для платформа как сервис подходит, а при продаже коробок деливери всё одно до клиента не долетает. В корп сегменте вроде больше LTS в моде.
Да выпускают пусть сколько угодно. Главное, чтобы типовая конфигурация требовала только последний стабильный релиз прошлого года. (Использовать можно что угодно, но работать должна на декабрьском)
>Стратегический выбор был сделан в пользу работы в браузерах.
Хреново он сделан. Вот я живу в браузерном 1С: документообороте. Он тупит как я не знаю что. Зато я знаю пяток способов его уронить. Ну и гонку команд он не переживает. Если я вдруг ошибусь и нажму в браузере подряд открыть форму выбора реквизита и закрыть документ с этим реквизитом, то всё умрет в половине случаев. Так как попытается открыться окно с уже убитым владельцем.
В тонком же клиенте все вертится довольно шустро даже в том же режиме работы через веб сервер.
Кроме специально подогнанных под это форм, массовой работы в браузере я не вижу, несмотря на то, что упр формам сто лет в обед. Даже для как угодно удалённых пользователей гораздо стабильнее работает клиент 1С. Лучше — толстый ;)
И по поводу тонкости клиента — на той машине, где летали обычные формы с «толстым» клиентом и обсчётом на клиенте, управляемые — тупят. Потому, что всё это js браузерное великолепие оказалось более требовательным как к памяти, так и к процессору, чем бизнес логика. А тяжёлые запросы выполняются на стороне сервера что в тонком, что в толстом клиенте.
В смысле «критерий обработки данных»?
Вы про представление картины в цифре, или ещё о чем-то?
ну да, картина имеет цифровое представление. БМП например, фактически я не знаю какое. сетка контролёр кучей нейронов первого слоя это пережёвывает, отдаёт результат дальше по ансамблю, последний слой один нейрон — 0 или 1. (ну может не дискретно, а вероятность).
Соответсвенно, «художник» на входе имеет тот же цифровой вектор — исходное фото. На выходе вектор — обработанное фото, его выход идёт на вход контролёра.
Или вы считаете, что в цифровом представлении картины для нейросетки зашиты не пиксели изображения, а некие предобработанные абстрактные сущности, одна из которых «стиль»?
Критерий для «контролирующего» алгоритма простой — «Это картина художника, которому учим?». Угадал — положительная обратная связь. Не угадал — отрицательная.
Для «художника» тоже простой критерий «Контролёр поверил, что это картина художника?» Поверил — положительная связь, не поверил — отрицательная.
Насколько по вашему это нежизнеспособная ситуация?
Регресс тесты автоматические, пишет команда под архитектором, который как раз становится чуть свободнее к середине проекта, когда появляется необходимость в регрессе.
И кстати, а на момент отделения блок не закручен был? Может поэтому 270 в попутном выгоднее, чем -90?
То что на вашей гифке — вы думаете, если в энгри бёрдс добавить возможность перебивать снарядом блоки на несколько и добавить «гнущиеся» (и ломающиеся при перенапряжении) блоки, то выйдет непохоже?
Навскидку я не могу предложить как нарезать на блоки сплошной «утёс» в который долбимся сбоку, а потом оно падает (первая гифка в статье) Но всё равно, я бы пошёл по пути термеха с динамически меняющимся приближением объектов примитивами. Так что у меня бы с начала не гнулось, а потом сразу ломалось ;)
Правда у меня есть важное отличие от автора статьи — он написал игру, а я — нет. Так что ясно, кого стоит больше слушать.
Правда у него оклад и 8 часов, а у них ночные и оплачиваемые переработки.
>Стратегический выбор был сделан в пользу работы в браузерах.
Хреново он сделан. Вот я живу в браузерном 1С: документообороте. Он тупит как я не знаю что. Зато я знаю пяток способов его уронить. Ну и гонку команд он не переживает. Если я вдруг ошибусь и нажму в браузере подряд открыть форму выбора реквизита и закрыть документ с этим реквизитом, то всё умрет в половине случаев. Так как попытается открыться окно с уже убитым владельцем.
В тонком же клиенте все вертится довольно шустро даже в том же режиме работы через веб сервер.
Кроме специально подогнанных под это форм, массовой работы в браузере я не вижу, несмотря на то, что упр формам сто лет в обед. Даже для как угодно удалённых пользователей гораздо стабильнее работает клиент 1С. Лучше — толстый ;)
И по поводу тонкости клиента — на той машине, где летали обычные формы с «толстым» клиентом и обсчётом на клиенте, управляемые — тупят. Потому, что всё это js браузерное великолепие оказалось более требовательным как к памяти, так и к процессору, чем бизнес логика. А тяжёлые запросы выполняются на стороне сервера что в тонком, что в толстом клиенте.
Вы про представление картины в цифре, или ещё о чем-то?
ну да, картина имеет цифровое представление. БМП например, фактически я не знаю какое. сетка контролёр кучей нейронов первого слоя это пережёвывает, отдаёт результат дальше по ансамблю, последний слой один нейрон — 0 или 1. (ну может не дискретно, а вероятность).
Соответсвенно, «художник» на входе имеет тот же цифровой вектор — исходное фото. На выходе вектор — обработанное фото, его выход идёт на вход контролёра.
Или вы считаете, что в цифровом представлении картины для нейросетки зашиты не пиксели изображения, а некие предобработанные абстрактные сущности, одна из которых «стиль»?
Для «художника» тоже простой критерий «Контролёр поверил, что это картина художника?» Поверил — положительная связь, не поверил — отрицательная.