Re^2: designing layout of a program

If logic does differ, but there is some untrivial overlap, factor out the common behavior to a module.

Logic does differ, and there is a lot of non-trivial overlap which will be factored out into common modules moved up the ladder to app_lib. "sales" and "marketing" are just examples -- I will eventually have more than a dozen datasets. So, I could use load.pl --dataset <datasetname> or I could use <datasetname>.pl. Six of one, squareroot of 36 of the other. Or is it? Any gotchas that I need to plan for? Especially when using the OS scheduler (currently, my preference).

--

when small people start casting long shadows, it is time to go to bed

Comment on Re^2: designing layout of a program Select or Download Code

Replies are listed 'Best First'.
Re^3: designing layout of a program by gaal (Parson) on Mar 29, 2006 at 19:15 UTC
If they perform conceptually the same task, I like to have them in one executable. Because it's cheaper to refactor things that way, the code tends to end up closer to where it should. Can't say more without knowing more about your application domain. How comfortable are you with your OS scheduler, and how refined are the scheduling requirements? I know how to do certain things with unix cron, but not others. If for example the exact timing of the next task depends on something that happened in the current one, I'd avoid the OS scheduler (although I also know how to use it if I wanted to). If all you need is "run daily at HH:MM", the system schduler can certainly do it. It's more a delivery/deployment/field engineering question than a deep architechtural one. But you need to consider: `- what happens when the system is restarted? - what happens when a job is killed? - who changes scheduling (the process/administrator/you)? how often? w +here from? - how is the system installed? - how portable does this need to be?` [download]	[reply] [d/l]

Replies are listed 'Best First'.

Re^3: designing layout of a program
by gaal (Parson) on Mar 29, 2006 at 19:15 UTC

How comfortable are you with your OS scheduler, and how refined are the scheduling requirements? I know how to do certain things with unix cron, but not others. If for example the exact timing of the next task depends on something that happened in the current one, I'd avoid the OS scheduler (although I also know how to use it if I wanted to). If all you need is "run daily at HH:MM", the system schduler can certainly do it. It's more a delivery/deployment/field engineering question than a deep architechtural one. But you need to consider:

- what happens when the system is restarted?
- what happens when a job is killed?
- who changes scheduling (the process/administrator/you)? how often? w
+here from?
- how is the system installed?
- how portable does this need to be?
[download]

[reply]
[d/l]