Shared publicly  - 
Tal Rotbart's profile photoAlan Skorkin's profile photoErica Smith's profile photoMichael Coates's profile photo
I use state machines! The state design pattern is probably the pattern I've found most useful as a programmer. Love it.
In most shitty enterprise software you wouldn't need I guess :-) even if u do it will have 4 or 5 states
WTF it is too - sweet, it's gotta be the bunny picture :).
btw, i tried to +1 your article on't work. Again! hahaha
Haha, yeah I keep meaning to remove that button, it's added by one of the plugins, but doesn't work for some reason. I need to either figure out why and fix it or remove the thing all together. Google gotta make that thing easier to integrate, it's a bit brittle at the moment.
Oh don't worry, I am sure he'll be checking out this comment thread :P.
Looks interesting mate, I've forked it so I can hack at it a little bit, probably help me with my javascript learning as well, cheers.
So I was sure you'd used JBPM at some point skorks. What distinction do you see between workflow engines (being state machines with extras) & a more specific view of a FSM? Are you actually saying that you've never used a state machine where your state is kept within your domain, rather than having never used one at all?
I haven't really used JBPM at any point, I've seen it and know of it that's about it. It probably would pretty much be a state machine under the hood, but it's the "with extras" bit that's the problem. That's always the problem with Java stuff. Big java libs try to be everything to everyone and they stuff in so many extras that it obscures the main purpose of the library in some cases completely beyond recognition.
Workflow is definitely not the same as an FSM. Workflow encourages different branches of the same process happening in parallel, stores runtime data (like the currently assigned actor/group) inside the states, and adds quite a lot of extra overhead like swimlanes and task life cycles. There have been numerous times where I've argued against the introduction of a workflow engine when 30 lines of plain old Java code would make the equivalent FSM with significantly less complexity.... But I think Java devs like complexity. (it makes us feel smarter, maybe?)
Certainly workflow isn't FSM, but by the same token I think most "workflows" I've seen developers produce are actually FSM implementations that don't make use of features such as parallel execution or maintaining ownership (which is kept in the domain).
Add a comment...