Hi David!
----- Original Message ----- From: "David Freeman" david_freeman@rocketmail.com To: alug@stu.uea.ac.uk Sent: Saturday, June 09, 2001 10:22 PM Subject: Re: [Alug] ALUG Librarian stuff
--- brodders@cwcom.net wrote:
Migod! ALUG Library's...come back to life!
My<insert object of worship here (Linux torvolds, RMS, ESR, Steve Jobs, sarah michelle gella etc...)> it has come back to life, RUN!
:) poor poor linus .. like it!
OK so no-ones ripped a new one in the idea of a peer-peer ALUG Library. That's nice; I assumed we'd go that way so I've quietly been doodling around with the concepts.
I never got around to ripping it a part. The problems are
- Based on assumptions
a) People are honest b) People will notice books have gone astray c) People will return books
yes. It's either that or it gets real difficult.
Seriously, casual fraud is the only real threat if people try to use the system at all, the system will know who's got what. From this stocktake data is available. The threat is that people just ignore the system, pass things around & it collapses into one big muddle. I don't know how we can stop this one.
Have not thought about consequences of wandering people; don't think it's too much of a problem insofar it's generic & will not go away. I'm for doing no more than normal add-person, delete/edit person etc. Um? fine person? New joiners give a sub which they get back when they go LESS losses? Could be expensive. Perhaps a borrowing cap is in order. Another table... NOPE a new attributes of the Person table; default say 4.
In that case you haven't modelled the system properly. You can't start programming till you have a decent enough idea of how it will work.
incedentally I will have a modell created by mondays IRC.
excellent. Will it have pictures? I like pictures.
This might as well be a progress report on what I've done, so here goes.
Top level concepts as last reported + thoughts on this issue:
Are there any issues if item passed to wrong person. Example: Person A has WonderBook which everyone wants. Person's B,C,D etc. request it. B is at top of list.
Yes. What happens to person B and C do they still remain at places 1 and 2 in the list? What if they ask for the book to be mailed to them?
At the next meet everyone is there except B. Oh dear - a ruck forms; A & book disappear from view & when tussle clears D has made off with it. "Well, B had their chance."
See above.
Is this legal? Don't see why not; B could well miss a meet & it seems fine to me that someone else gets the book. For this to work, everyone must have been issued a key to give A. That may mean another table for the confirmation keys rather then finding a home for <the one key> in say the Transaction table.
There needs to be a dead line for collection and for loans, but you would have modelled this in the functional requirements.
Why? This is at heart a stock control system, in the guise of stock tracking. If an item stays on a shelf for a month, does it need permission to stay there for another month? Is there actually a need to have controlled returns if we know where the item is? We do not have to model our system on anyone else's ideas of how libraries work.
Alternatively if it's NOT OK to passover B - what then? Perhaps C only should be allowed to have the book, not D as decided in the tussle?
Let me think on this one.
My instinct is that the more flexible the better; so I'd plump for "issue N confirmation keys & let people decide for themselves". There are more arguments around this area (the confirmation key is now effectively a person ID, so why keep on scrambling it?) but overall I'm happy with this. It's more secure / difficult to defraud this way.
see above comment
Ultimately - to be perfect the complexity of the solution must mirror the complexity inherent in the problem domain. Or, lop off minor complexities / degrees of freedom in the problem deliberately to straightjacket (= simplify) the solution. I actually sent myself to sleep a few weeks ago thinking about issues arising from trying to correct out-of-order borrowing & impacts on issued keys. Danger Will Robinson - don't go there! Let's make it simple.
Next up, db progress.
Postgres is wonderful, BUT as I had everything to hand to get going with MySQL so I made a start using it (also I had another project which used MySQL).
Fine any DBMS should do the job, even access should work, if designed properly.
Now when I make a start I explore problem areas. This ties in with my design assumptions - which are that everything's easy - except for the problems. So I want to know - what are the problems & where are they? Once these are conquered I can go back to sleep (=base mode).
And what are assumptions?
That everything is easy apart from the difficult bits. And, where it ain't easy, I hits it with this here hammer until it gets simple :)
What I'm saying is that people can make things work - if the things are possible to work at all. So, explore what's more possible vs. what's less (or im)possible.
This is based on a top-down development view which says "don't rely on things which can't be made to work". Idea is to identify the easy / practical route; this means proof-of-concept tests needed when going into new areas.
Once a solution strategy is found possible, getting it working is through dint of effort; leg-work if you will. That's what the next bit is about - I needed a way of proving the solution strategy.
First up I needed a model environment, so I put together a box networked to a PC. There's the server, here's the client <this included a big diversion fighting various Linux distros; they didn't like the ancient embedded video on the server>. MySQL goes in, fight with that. Many minor mistakes; finally import a test database
- for the other project; but principles established. Install MyODBC
onto the PC; that is a success.
sounds like the usual linux development problems.
:)
Next up - how to actually do it? I want a RAD or sumfin'.
How about doing it the real way and telneting in and using SQL?
yep that works too; 's how I did the import & initial table setup etc.
Access works well via the ODBC, but that's not PC. Hm. StarOffice 5.2! It sort of works and crashes but it's just about usable; snag it it doesn't quite fit MySQL nicely.
hmmm?
Subtle unhappynesses which seem to be connected with.. SO5.2 doesn't like base data types used by MySQL, strikes attitudes about keys, crashes when it feels like. Teeters on usable; often just pulls a trick. The MyODBC drivers seem fine with SO though. I can fix table layout shenanigans using SQL.. & my hammer awaits if it needs it's mind changed.
At this point I was going to make a start putting some default forms together. OK not for the final system; they'll have to be over the web. But these are 1st shot functional screens to get things going; SO5.2 has a GUI editor all drag'n'dropish with predefined stuff (fields, buttons, pull down lists etc) & that's nice esp. when it accesses the remote test MySQL db and I see real data in the fields on my PC. At that point I went on holiday & now it's now.
Have you defined the queries necessary to support the application?
In SQL, no, but have worked up notes giving the expectations (delivered functionality) for these. Mostly they are obvious add/delete/edit for the main tables apart from reports & the tricky bits most tricky being the transaction models for requesting & borrowing.
That's why I raise the issues re librarian/peer-peer; these are key process assumptions.
Also don't forget the need to stocktake and do a check on integrity. Stocktake can be done on the fly, ie when an item goes through the hands of a trusted party the item can be "audited". Another table becons. I imagine the integrity check to er um prove transactions are ordered OK vs datestamp sequence, run through transactions and prove the items / persons etc tie in and make sense.
Thanks! Steve
Be Warned - I'm not a coder (well not in the last 15 years).
Neither am I nor am I a Systems analyis, but I think as a group we will muddle through
Thanks
D
Bye Bye for now!
Steve
alug, the Anglian Linux User Group list Send list replies to alug@stu.uea.ac.uk http://www.anglian.lug.org.uk/%C2%A0 http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug See the website for instructions on digest or unsub!
Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
alug, the Anglian Linux User Group list Send list replies to alug@stu.uea.ac.uk http://www.anglian.lug.org.uk/%C2%A0%C2%A0 http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug
See the website for instructions on digest or unsub!