NewdleBoard
Last week I managed to sneak out a new version of the
NoodleBoard.
I’ve got a lot of paying work on at the moment, so keeping the ‘free-ware’ side of the business up-to-date has been hard. However I was really pleased with the new UI, which was done by Victoria Weston (a London based web/graphic designer) and I’d managed to fix a few bugs so it seemed a shame to sit on it all until the next major functional release, so we sneaked this out the door.
So far it’s been impressive and there has been a marked increase in downloads and sign-ups.
A few people have asked me, “What’s the point in NoodleBoard? Isn’t it just costing you money?”
And, well, yeah, it is. But not much, what it is doing however is proving some very interesting points...
Firstly, the server side of NoodleBoard is running on a virtualized installation of Fedora Core Linux (i.e. a shared server), it is written in J5EE (EJB3) and it all sits inside a JBoss 4.0.x server. And I’ve not had to reboot it once since it launched.
I’ve redeployed the entire server application a couple of times, but the JBoss deployer is extremely robust and I doubt anyone even noticed (and no, it’s not because no-one uses it :)
Secondly, I have learned a lot about selling (well giving away) software and support to end-users. As a consultant I’m all too used to finding solutions to, often in-house, business problems and really letting the client deal with the running of things. Now, I’m getting emails and even the occasional call about all sorts from all kinds of users - most (thankfully) are grateful and pleasant, a few are not.
I try and reply to them all with the kind of reply that I would expect.
Thirdly, marketing has become an interest of mine and it’s up there alongside version control systems and design patterns... I’m finding it fascinating, especially how quickly posts on blogs tend to cascade down and directly affect download rates, even on a small project like this.
I suppose the one thing I’ve learned since launching is that there’s still a lot left to learn. I think that being constantly reminded this is worth the bandwidth fees.
I’ve got a lot of paying work on at the moment, so keeping the ‘free-ware’ side of the business up-to-date has been hard. However I was really pleased with the new UI, which was done by Victoria Weston (a London based web/graphic designer) and I’d managed to fix a few bugs so it seemed a shame to sit on it all until the next major functional release, so we sneaked this out the door.
So far it’s been impressive and there has been a marked increase in downloads and sign-ups.
A few people have asked me, “What’s the point in NoodleBoard? Isn’t it just costing you money?”
And, well, yeah, it is. But not much, what it is doing however is proving some very interesting points...
Firstly, the server side of NoodleBoard is running on a virtualized installation of Fedora Core Linux (i.e. a shared server), it is written in J5EE (EJB3) and it all sits inside a JBoss 4.0.x server. And I’ve not had to reboot it once since it launched.
I’ve redeployed the entire server application a couple of times, but the JBoss deployer is extremely robust and I doubt anyone even noticed (and no, it’s not because no-one uses it :)
Secondly, I have learned a lot about selling (well giving away) software and support to end-users. As a consultant I’m all too used to finding solutions to, often in-house, business problems and really letting the client deal with the running of things. Now, I’m getting emails and even the occasional call about all sorts from all kinds of users - most (thankfully) are grateful and pleasant, a few are not.
I try and reply to them all with the kind of reply that I would expect.
Thirdly, marketing has become an interest of mine and it’s up there alongside version control systems and design patterns... I’m finding it fascinating, especially how quickly posts on blogs tend to cascade down and directly affect download rates, even on a small project like this.
I suppose the one thing I’ve learned since launching is that there’s still a lot left to learn. I think that being constantly reminded this is worth the bandwidth fees.
|
Tackling complexity with crayons
ur team has just finished implementing a large
workflow system using jBPM as a BPM engine. It
was, for all of us I think, our first brush with
Graph Oriented Programming (GOP) and a couple of
interesting things fell out of it.
Firstly, GOP has the beautifully neat side effect of handling state for you, both in a macro sense (think workflow) and a micro one (think page-flow). This has the knock on effect of removing a lot of complexity from the application - no more figuring out what to do next from the current context (or lack of it).
The approach we took when designing the application was to model each task in the workflow as a separate atomic use-case, each one implemented using an appropriate mechanism (in our case, dispatchers/Session Beans) but with the slight difference that at the end of each use-case we signal to the process that the current task has ended.
By doing this we effectively decoupled the process flow from the task implementation in all but a minority of cases.
But this is cool decoupling. Not just abstracting out application tiers for the sake of it - we could actually change and deploy a new process on the fly without modifying the code.
Shall I say that again? We could actually change and deploy a new process on the fly -
Without.
Modifying.
The.
Code.
Oh. Did I mention that jBPM allows you to deploy multiple versions of the same process?
No?
Well, it isn't quite true but it's close. Once a new process graph is deployed all new instances of the process that are started follow the new graph, existing ones continue down the path of the graph that was in place when they started.
Another thing we noticed is how immediately everyone grasped the concept of modeling process flow. For once we were using a modeling paradigm that 'ordinary users' could join in with (be prepared to allow some deviation from the standard UML notation). A lot of paper was harmed in the making of the system, but given the price of scrap paper I think it was worth it.
Firstly, GOP has the beautifully neat side effect of handling state for you, both in a macro sense (think workflow) and a micro one (think page-flow). This has the knock on effect of removing a lot of complexity from the application - no more figuring out what to do next from the current context (or lack of it).
The approach we took when designing the application was to model each task in the workflow as a separate atomic use-case, each one implemented using an appropriate mechanism (in our case, dispatchers/Session Beans) but with the slight difference that at the end of each use-case we signal to the process that the current task has ended.
By doing this we effectively decoupled the process flow from the task implementation in all but a minority of cases.
But this is cool decoupling. Not just abstracting out application tiers for the sake of it - we could actually change and deploy a new process on the fly without modifying the code.
Shall I say that again? We could actually change and deploy a new process on the fly -
Without.
Modifying.
The.
Code.
Oh. Did I mention that jBPM allows you to deploy multiple versions of the same process?
No?
Well, it isn't quite true but it's close. Once a new process graph is deployed all new instances of the process that are started follow the new graph, existing ones continue down the path of the graph that was in place when they started.
Another thing we noticed is how immediately everyone grasped the concept of modeling process flow. For once we were using a modeling paradigm that 'ordinary users' could join in with (be prepared to allow some deviation from the standard UML notation). A lot of paper was harmed in the making of the system, but given the price of scrap paper I think it was worth it.