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!
--- brodders@cwcom.net wrote:
Hi David!
----- Original Message ----- From: "David Freeman" david_freeman@rocketmail.com
--- 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!
Thanks :o)
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.
Complexity is all relative, what may seam complex can infact be simpified quite nicely when you take a different angle of attach.
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.
Centralisation. As much as I like the idea of the Peer-to-peer networking technique it, like most ideas, is only applicable to certain tasks, and I believe this isn't one of those. I think a hybrid of peer-to-peer and centrailised systems much like napster would be a good solutions.
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.
Would it be a model if it didn't have pretty pictures?
I may also model the relational scheme or I may do it as objects to be written in java.
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.
Do we know who has the item? "who has book x?" "I gave it to the next person on the list at the last meet" "who was that <looks opn system>, so you gave it to john doe?" "yes, Joh do you have the book I gave you at the last meet?" "No I wasn't at the last meet" "So who got that book then?"
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.
Quite true, we need to simplify the domain of the problem into something sensible. As for the thoughts to goto sleep by, try desolved gas algorithms and gas phase modelling, great fun :o)
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 :)
I will have to confiscate your fine adjustment tool at the next meet. Every engineer knows that a large ajustable spanner works better, after all it has more uses than just bugdening something :o)
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.
So basically you have ignored the one assumption which is safe to have "people are a problem"
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.
oh goody an interative development process.
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.
Makes sense.
TO be continued in the next message.
Thanks
D
First up I needed a model environment, so I put together a box networked to
=== message truncated ===
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
--- brodders@cwcom.net wrote:
Hi David!
----- Original Message ----- From: "David Freeman" david_freeman@rocketmail.com
--- 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!
Thanks :o)
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.
Complexity is all relative, what may seam complex can infact be simpified quite nicely when you take a different angle of attach.
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.
Centralisation. As much as I like the idea of the Peer-to-peer networking technique it, like most ideas, is only applicable to certain tasks, and I believe this isn't one of those. I think a hybrid of peer-to-peer and centrailised systems much like napster would be a good solutions.
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.
Would it be a model if it didn't have pretty pictures?
I may also model the relational scheme or I may do it as objects to be written in java.
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.
Do we know who has the item? "who has book x?" "I gave it to the next person on the list at the last meet" "who was that <looks opn system>, so you gave it to john doe?" "yes, Joh do you have the book I gave you at the last meet?" "No I wasn't at the last meet" "So who got that book then?"
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.
Quite true, we need to simplify the domain of the problem into something sensible. As for the thoughts to goto sleep by, try desolved gas algorithms and gas phase modelling, great fun :o)
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 :)
I will have to confiscate your fine adjustment tool at the next meet. Every engineer knows that a large ajustable spanner works better, after all it has more uses than just bugdening something :o)
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.
So basically you have ignored the one assumption which is safe to have "people are a problem"
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.
oh goody an interative development process.
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.
Makes sense.
TO be continued in the next message.
Thanks
D
First up I needed a model environment, so I put together a box networked to
=== message truncated ===
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
--- brodders@cwcom.net wrote:
Hi David!
----- Original Message ----- From: "David Freeman" david_freeman@rocketmail.com
--- brodders@cwcom.net wrote:
=== message truncated ===
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.>?
:)
You know its true :o)
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.
Good, nice to see it being done properly :o)
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.
Why not use a sensible system? Why not write the front end in Java and use the JDBC?
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?
broders wrote: 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. freemadi wrote:
be careful we could say those working notes are the beginning of a model.
Repeat after me: What is an assumption?
The stocktake will always be a problem when using the peer-to-peer system.
Thanks
D
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
__________________________________________________ Do You Yahoo!? Get personalized email addresses from Yahoo! Mail - only $35 a year! http://personal.mail.yahoo.com/
-
brodders＠cwcom.net -
David Freeman