Developing filePro apps for developers

[Brian K. White]

----- Original Message ----- 
From: "Jay R. Ashworth" <jra at baylink.com>
To: <filepro-list at lists.celestial.com>
Sent: Friday, June 15, 2007 2:49 PM
Subject: Developing filePro apps for developers


> On Fri, Jun 15, 2007 at 08:32:57AM -0400, Walter Vaughan wrote:
>> I did have an idea that could make your accounting app work in a
>> method that would allow for you to keep improving it, and yet allow
>> developers to make changes to their systems and not break things.
> [ ... ]
>> So we worked with (paid) someone who was helped us to setup an SVK
>> repository. SVK is a tool that acts as both a svn client and svn
>> server. So we can pull down the laterst svn (they call it smerging!)
>> from the parent project, and our internal people syncronize with our
>> local repository.
>>
>> I guess since I've not worked in a version control system before, but
>> it seemed like magic in that it really worked. I know who changed what
>> file and when, and can get diffs, roll back... our developers can
>> quickly build patches for the parent project or commit local changes
>> and everything works.
>>
>> And the first place ourside of our internal needs I thought of was the
>> problem that was discussed a few weeks ago on the filepro list with
>> your accounting system.
>
> But, alas, that won't help him.  His fundamental problem is going to be
> field number conflicts between *his own* changes and extensions, and
> those of downstream developers or users.  Short of *requiring* that all
> changes and extensions be made as one-to-one sibling files -- which is a)
> a pain in the ass and b) unenforceable anyway -- I see no way to get
> around that.
>
> It's the fundamental problem with trying to do what John's trying to do
> (and indeed, what Fourgen did 20 years earlier) in filePro.  It's not
> the *only* problem with trying to apply F/OSS development methodologies
> -- or indeed ones which got started there, and moved back into
> proprietary development, like source code control -- to filePro, but
> it's a biggie.

Too right. Our answer to that problem was, we just about stopped selling 
software and switched to selling subscriptions to our software and the 
servers it runs on and the backups etc...

We all develop on one development box, which no users live on but which 
contains some dummy data to work with as well as the code and is otherwise 
the same as the other boxes.
And we have an rsync script that pushes the code out exactly the same to all 
the live application server boxes, excluding only keys, datas, & indexes, 
including menus and printer tables etc.. twice a day it'll do the whole 
filepro directory from cron, plus any developer can run it on demand.
We have a another similar script to make it painless to push out other files 
that commonly need to be broadcast as part of development like scripts or 
cgi scripts, fpmerge template files etc, which also has a mode that makes it 
painless to use it to push out a specific file from the filepro directory, 
like just a single output format, instead of having to do the whole mass of 
files just to get one teeny change out.

It's helped in other ways too. I as the server/network/power/plumber guy 
have fewer boxes to nanny over, and more control over them, and can make 
them all more and more identical to each other and keep improving ways to 
automate the few things that do still need to remain different on each box.

Theres more to it of course, like I had to make scripts to make it painless 
to delete a qualifier, copy a qualifier, copy a qualifier from one box to 
another, which between those also gets you rename/move a qualifier both 
locally and across boxes, all in-place without disturbing the other 80 
qualifiers on a given box in the same filepro tree. Had to make an ap-alike 
for linux to make it less painful to copy users from box to box. I'm just 
starting to experiment with using server hosting companies instead of buying 
servers ourselves, to get the hosting comanies better networks and 
facilities and to spread the users around to more different physical sites 
so that a single telephone pole getting hit by a drunk driver doesn't take 
out the whole userbase. It's both a little more hassle for me and a little 
less. But largely it's about equally simple to host the users just about 
anywhere.

We still have to save up restructure type tasks and do them together and 
infrequently, on every box manually.
It's a few steps but not too many to make a box quiescent so no new filepro 
process will start while doing the restructure work, yet without getting in 
the developers way like say  renaming *clerk & *report would. create 
/etc/nologin, shut down cron and apache, kill off any remaining fp-related 
process, do the work, release the hounds and move to the next box.
Thats a future project for me. To get a script working that can rsync out 
maps and index definitions and run autoshufs and dxmaints remotely, 
_reliably_, or at least so you never miss if it fails anywhere.

We were getting really bogged down before with so may customers with their 
own servers and their own bags of site-specific network and user problems, 
and many of them wanting essentially the same software improvements we had 
to all spend so much time doing over and over again. Not only was it boring, 
and prone to error, but while we are writing the same single improvement 25 
times on 25 different versions of our stuff on 25 different boxes... all 
that time we are _not_ writing 25 _new_ improvements to the core app and so 
the app gets older and older without getting much better.

It's not ideal but it's allowed us to get out of the mud and run for the 
last few years anyways.

Brian K. White    brian at aljex.com    http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro  BBx    Linux  SCO  FreeBSD    #callahans  Satriani  Filk!