I’m back to the Filewatcher project after both the Christmas and New Year break as well as an additional chunk of work I had to get out of the way as a matter of urgency.
Fortunately I’ll be working 2 days a week on this project for the next month rather than out of hours becuase I’ve re-negotiated my current contract with my main client (see previous post).
Current Standing with the File Watcher Project
1. Last piece of work was working with WPF in more detail to create a better UI metaphor. This is currently work in progress (WIP) and I’d gotten as far as trying to understand the binding to a .NET CLR type mechanism (uptil now I’ve just used XML). I’ll come back to this work at some point.
2. Get the systems up and running again. It’s only a two computer setup but there a number of gotchas. This I completed this morning - things like remembering to manual start the SQL Server 2005 service up (must write a test), disabling particular security items, running the existing tests (all passed), updating the IP setting in a couple of config files (I don’t have a name server), and backing up various files (I don’t have a version system in place at the moment .. going to hell for that).
3. Next item of work: I require an ASP.NET UI to view file event messages. Due to the nature of web apps then I hit a design issue straight away. A browser page is not a piece of software that can easily subscribe and listen for events - contrast that with a winForms app or a console service - so I have two options:
- Investigate whether I’m right in saying that the web page can’t listen for events. Just in case this problem has been resolved before.
- Look at the possibility of using javascript on the clientside to poll for events - this is not the same as listening for an event and may not working properly. Also I’d guess that some intermediate service will be required between the javascript and the actual event. This intermediate service may be as simple as something that implements something akin to a high level adapter pattern (it could be called a translation service too I suppose) or, it may also need to offer data persistence too.
- Implement a non-event driven solution .. that is just have it query a persistence store of some sort when the user requests it. TBH this is the simplist solution and the one I know will work with no risks. It also adds a feature which will ultimately be required by this UI but also the persistence service will be re-used by any number of other potential consuming services eg obviously the other UI types (WPF, WinForms, Console, Sharepoint) and also the Reporting service that I intend to create.
This third option raises a number of interesting questions
One question it raises is “should I create the persistence service as something that lots of other consumers could readily use?”
The answer is yes but not so much so that it actually involves extra work eg wrapping the persisence service behind a web service so that it offers an easy to re-use interface. In fact, normally you shouldn’t create something (be it a web service, a class or even just code within a method) unless you are about to use it (and from a TDD point of view .. that requirement only occurs if you have an actual test that needs it). This applies to the design of the solution just as much as the actual code and there’s actually a standard XP term to describe the situation where you add some feature in the hope/desire/belief that it will be usefull some time in the future: YAGNI.
But this is, I think, slightly different .. I will re-use the persistence service. The only reason I’m not building the Sharepoint UI and the Reporting service now is becuase I don’t have time yet.
Hmmm … Alarm bells ringing! My reason for not producing those other systems are the very same that all other software departments encounter .. therefore it’s not really a valid reason, or at least, it’s the very same set of good intentions that can led a software project to build something that is overly complex.
OK .. I’m going to go back on myself. The whole point of this project is for me to learn more about different ways of building software and not the actual software produced in particular. I want to learn about what design/programming practices work and which don’t.
So I will do as the rule states .. I will NOT build the persistence service so that it’s deployable as a seperate service. I will build it as a part of the ASP.NET UI but I will do it in a manner that means it will ultimately be easier to split apart if required - I’ll attempt to create code that has low coupling between the consumer of the persistence service and the persistence service itself [
Coupling And Cohesion]).
The other interesting option three raises is “I’m I going for option three just because there’s less risk but it doesnt actually address the real, business need: that the app can monitor events in real time?”
If I went for option three the system may come in on time, it may be bug free and a sexy as anything but it may just miss the whole point of why the system was created in the first place.
In which case I can’t hide from the real time event handling requirement .. I must address it. It’s the riskist bit of this project and to mitegate that risk I really need to spend some time to investigate it and understand the situation. Doing this also has an XP term associated with it: Architectural Spike
Conclusion
1. I will investigate the mechanism by which the ASP.NET UI will be able to respond/display file events in real time.
2. If I have to create a persistence mechanism then it will be part of the ASP.NET UI solution but built with low coupling so that I have the option of re-using it for other services at a later date.
