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