Хотите сделать что-то полезное — найдите open-source проект и помогите своими советами/кодом ему. Нечего пиариться на каком-то никому не нужном кривом проекте. Судя по описанию, вы ищете именно такой,
Что же у вас за софт такой, где нужно конечный автомат конфигурировать из XML извне?
Понятно, что параметры работы программы хорошо было бы иметь возможность менять без перекомпиляции, но менять принцип работы стейт машины… Это вы уже какой-то интерпретатор непонятно чего написали, который должен уметь делать все.
> Машине состояний как конечному автомату совершенно индифферентно предыдущее состояние
В классическом виде да. В классическом виде у состояний не может быть параметров и они не могут хранить данные. Но классические модели и существуют для того, чтобы их модифицировать. Пусть у нас будет FSM с ленточной памятью. Почти машина Тьюринга уже.
Почему люди должны укладывать себя в рамки математического определения конечного автомата? Я в статье его даже не привожу, чтобы народ не пугать.
Про где что писать, да, возможно не совсем понятно.
В setState пишется уникальная логика выхода из состояния, а в stateBla возможна специфическая логика выхода из состояния A при переходе в Bla. Но очень редко используется.
Как и во всех соглашениях, какой-то код может сперва находиться в одном месте, но потом у него появится другой смысл, или окажется, что он где-то дублируется. Тогда мы можем его перенести в другое место. Никто нам не запрещает. Все-таки код не вытесан из камня, это всего лишь текст, который (о ужас!) можно и нужно менять с развитием проекта.
ОК, давайте еще приведем определение конечного автомата из Теории Алгоритмов и будем тыкать пальцами друг в друга ругаясь на неканоническое его использование. Это какое-то полнейшее занудство.
Да, вероятно, я должен был описать, что смена состояния происходит мгновенно через транзакцию атомарных операций. То есть переход из A в B выглядит так: выполнить код выхода из А, сменить текущее состояние на B, выполнить код входа в B. Но, посчитав это common sense, я данную информацию в статью не включил.
> Очень наивная и страшненькая методика построения велосипеда.
«Велосипед» — это еще один метод решения какой-то задачи, для которой уже есть множество вполне удобных решений. Весь смысл статьи как раз в том, что с древнейших времен было изобретено множество велосипедов и ни один из них полностью не обеспечивает должного решения задачи, а чаще всего полученное решение еще и усложняет в Н-цать раз.
Мой «велосипед» ближе всего к тому оригинальному с большущим колесом.
Если бы статья была про фреймворки, то да.
Но статья против фреймворков. Если кому-то действительно он нужен, первая же страница поиска в гугле выдаст множество вариантов.
Судя по плюсам, я был неправ.
Но, все же неприкольно видеть каждый день в ленте список новых заблокированных сайтов.
Предлагаю сделать отдельный ресурс. Назвать его ru_ban_watch. И там уже писать про новых забаненных.
У интерфейсов на жестах есть много проблем. Это только в фильмах супергерои быстро и эффективно пользуются ими, на самом же деле они, в том виде, в котором есть сейчас, ужасно неудобны. Достаточно только взглянуть на кинект. Есть интерфейсы лучше и хуже, но ничего не заменит удобство обычного джойстика.
Или, например, многие видели/слышали о возможности управлять презентацией/докладом взмахом руки. Но многие ли реально пользовались подобным интерфейсом? Я использовал его для доклада на конференции, и, скажу я вам, ужасно ОТВЛЕКАЕТ. Кнопка кликера в руках с тактильным интерфейсом пока что идеальный вариант.
Можно еще много чего сказать об удобстве, о точности распознавания, о неожиданных проблемах, но боюсь написать тут целую статью а не комментарий. Вот, скажите, зачем мне жестовый интерфейс с радиусом действия 15 сантиметров от телефона? Если я уже дотянулся до него, то куда удобнее ткнуть в экран и воспользоваться потрясающей точности тач-интерфейсом, а не пытаться что-то изобразить пальцем, что распознается раза с седьмого.
Но, стоит упомянуть, что такое устройство нашло бы применение в медицие, например, в хирургии. Там, где из соображения стерильности, нельзя ничего трогать вокруг. Люди пытаются для этого сейчас приспособить кинект.
Судя по скриншотам, исполнение какое-то уж больно унылое.
И что-то такое я уже видел. ММО на улицах города. Выглядело уж очень отстойно, так что я сразу удалил.
Конфигурирование и DSL это разные вещи.
Понятно, что параметры работы программы хорошо было бы иметь возможность менять без перекомпиляции, но менять принцип работы стейт машины… Это вы уже какой-то интерпретатор непонятно чего написали, который должен уметь делать все.
В классическом виде да. В классическом виде у состояний не может быть параметров и они не могут хранить данные. Но классические модели и существуют для того, чтобы их модифицировать. Пусть у нас будет FSM с ленточной памятью. Почти машина Тьюринга уже.
Почему люди должны укладывать себя в рамки математического определения конечного автомата? Я в статье его даже не привожу, чтобы народ не пугать.
В setState пишется уникальная логика выхода из состояния, а в stateBla возможна специфическая логика выхода из состояния A при переходе в Bla. Но очень редко используется.
Как и во всех соглашениях, какой-то код может сперва находиться в одном месте, но потом у него появится другой смысл, или окажется, что он где-то дублируется. Тогда мы можем его перенести в другое место. Никто нам не запрещает. Все-таки код не вытесан из камня, это всего лишь текст, который (о ужас!) можно и нужно менять с развитием проекта.
ОК, давайте еще приведем определение конечного автомата из Теории Алгоритмов и будем тыкать пальцами друг в друга ругаясь на неканоническое его использование. Это какое-то полнейшее занудство.
Да, вероятно, я должен был описать, что смена состояния происходит мгновенно через транзакцию атомарных операций. То есть переход из A в B выглядит так: выполнить код выхода из А, сменить текущее состояние на B, выполнить код входа в B. Но, посчитав это common sense, я данную информацию в статью не включил.
«Велосипед» — это еще один метод решения какой-то задачи, для которой уже есть множество вполне удобных решений. Весь смысл статьи как раз в том, что с древнейших времен было изобретено множество велосипедов и ни один из них полностью не обеспечивает должного решения задачи, а чаще всего полученное решение еще и усложняет в Н-цать раз.
Мой «велосипед» ближе всего к тому оригинальному с большущим колесом.
Но статья против фреймворков. Если кому-то действительно он нужен, первая же страница поиска в гугле выдаст множество вариантов.
Был бы идеальный вопрос. Сам спросил — сам ответил!
Но, все же неприкольно видеть каждый день в ленте список новых заблокированных сайтов.
Предлагаю сделать отдельный ресурс. Назвать его ru_ban_watch. И там уже писать про новых забаненных.
Или, например, многие видели/слышали о возможности управлять презентацией/докладом взмахом руки. Но многие ли реально пользовались подобным интерфейсом? Я использовал его для доклада на конференции, и, скажу я вам, ужасно ОТВЛЕКАЕТ. Кнопка кликера в руках с тактильным интерфейсом пока что идеальный вариант.
Можно еще много чего сказать об удобстве, о точности распознавания, о неожиданных проблемах, но боюсь написать тут целую статью а не комментарий. Вот, скажите, зачем мне жестовый интерфейс с радиусом действия 15 сантиметров от телефона? Если я уже дотянулся до него, то куда удобнее ткнуть в экран и воспользоваться потрясающей точности тач-интерфейсом, а не пытаться что-то изобразить пальцем, что распознается раза с седьмого.
Но, стоит упомянуть, что такое устройство нашло бы применение в медицие, например, в хирургии. Там, где из соображения стерильности, нельзя ничего трогать вокруг. Люди пытаются для этого сейчас приспособить кинект.
И что-то такое я уже видел. ММО на улицах города. Выглядело уж очень отстойно, так что я сразу удалил.