Вообще, они обещают релиз в 2017, пара фреймворков для web уже есть, сейчас только ORM осталось написать. Если интересно следить за ними — вот чат в телеграмме.
Ещё можете обратить внимание на игру Zero Tolerance, на sega. Там пароли тоже интересные. В детстве помню, что-то с ними делал, но не помню что именно уже.
В примере было указано, что мы поворачиваем его на 90 градусов, а при повороте зажмуриваемся.
Поэтому, чтобы показать процесс его поворота, нужно описать из какого в какое состояние он переходит и насколько перешёл.
Предположу, что куб, будучи повернут на 10 градусов, может быть описан как 8/9 начального состояния и 1/9 состояния в которое он стремится перейти. А когда он закончит переход, будет на 1 состоять из какого-то одного состояния и на 0 из всех состояний в которые может перейти.
А можно вас попросить написать об этом подробнее, или дать пример посмотреть?
Сам думаю либо вариант toxicmt, либо ваш построить, пока к какому-то решению не пришел.
В 300гр высокий стакан наливаем 150 гр швепса, лучше красного, он же Russian. Не очень холодного и осторожно. А туда грамм 30 теплого адвоката. Если скорость отпивания вкусной пены будет меньше скорости ее генерации — получим искомый эффект ;)
Немного похоже на паттерн про интерфейс, или еще подобный из GoF. Производству не обязательно знать откуда принесут гайки. Просто надо знать, куда об этом сказать. А там уже пусть система решает, толи взять из местного запаса, толи купить у поставщиков, толи свой завод металлургический строить начать.
Судя по примеру со штрихкодом, у меня получилось донести мысль. А вот пример с водителем показывает обратное. Кладовщик обязан собрать и отдать. Кому именно — его волновать не должно. Он со своей задачей уже справился. В вашем примере выполнение заказа кладовщиком должен принять водитель, а доставку водителем — производство.
А нюанс про 100 заказов и призвана решить система, насколько я понимаю причины ее внедрения, то есть, либо производство в момент постановки задачи увидит, что в ближайшие три дня гаек не будет, либо директор увидит, что от одного единственного подразделения с не самой высокооплачиваемой работой простаивает весь завод, так как по факту задержки склада откладывает срок сдачи готового продукта.
Или манекен который сидит за твоим столом и иногда меняет руку, которая держит голову. Этого хватит на время, пока ты из аэропорта другой страны не выйдешь.
А почему бы не сделать так, что результат каждого действия в системе оценивает постановщик задачи?
Например, производству требуется 4 гайки (понятно, что это тоже для выполнения какой-то цели, поставленной производству), оно говорит складу: приготовить 4 гайки. Человек на складе, собирает их в коробочку и в системе отмечает, что заказ собран. Главный момент: заказ считается собранным, когда это подтвердит в своем интерфейсе человек из производства. Если на выполнение этой задачи есть какой-то норматив времени, то человек со склада будет на производстве джигу танцевать, лишь бы постановщик задачи скорей принял заказ.
Таким образом и данных вводить меньше и каждый «чих» внесен в систему, собирается статистика по нагрузке отделов, среднее время выполнения операции и т.д.
Поэтому, чтобы показать процесс его поворота, нужно описать из какого в какое состояние он переходит и насколько перешёл.
Предположу, что куб, будучи повернут на 10 градусов, может быть описан как 8/9 начального состояния и 1/9 состояния в которое он стремится перейти. А когда он закончит переход, будет на 1 состоять из какого-то одного состояния и на 0 из всех состояний в которые может перейти.
http://doam.ru/react-js-for-rails-developers-part-1/
Сам думаю либо вариант toxicmt, либо ваш построить, пока к какому-то решению не пришел.
Ведь по сути тогда у нас 2 времени, реальное и параллельное, которое такты реализуют?
Хоть на дропбокс архивом или страницей.
Морда открывается.
Запрет.инфо мешает зайти, пров. Ростелеком.
А нюанс про 100 заказов и призвана решить система, насколько я понимаю причины ее внедрения, то есть, либо производство в момент постановки задачи увидит, что в ближайшие три дня гаек не будет, либо директор увидит, что от одного единственного подразделения с не самой высокооплачиваемой работой простаивает весь завод, так как по факту задержки склада откладывает срок сдачи готового продукта.
Например, производству требуется 4 гайки (понятно, что это тоже для выполнения какой-то цели, поставленной производству), оно говорит складу: приготовить 4 гайки. Человек на складе, собирает их в коробочку и в системе отмечает, что заказ собран. Главный момент: заказ считается собранным, когда это подтвердит в своем интерфейсе человек из производства. Если на выполнение этой задачи есть какой-то норматив времени, то человек со склада будет на производстве джигу танцевать, лишь бы постановщик задачи скорей принял заказ.
Таким образом и данных вводить меньше и каждый «чих» внесен в систему, собирается статистика по нагрузке отделов, среднее время выполнения операции и т.д.