main June 2001

main@lists.alug.org.uk

50 participants
174 discussions

Re: [Alug] ANNOUNCE: ALUG 2001.4 (End Of The Academic Year!)
by MJ Ray 11 Jun '01

11 Jun '01

"Mark Wilkinson" <mark(a)wilkinson.uk.com> writes: > I hate to be the one to say this but I think it's worth pointing out that > 17th June is Father's day and some of us may have other commitments that > day, especially those travelling a long distance. Oh well, where were you 10 days ago? Bit late to change now, unless there's an overwhelming outcry. I'll hold the announcement back until tomorrow just in case. -- MJR

2 1

Re: [Alug] ALUG Librarian stuff
by MJ Ray 10 Jun '01

10 Jun '01

David Freeman <david_freeman(a)rocketmail.com> writes: > > Anyway, imperative-OO still has "do this, do that" at its core... > Not if used properly. its more on event x do y etc... Still, imperative. [...] > True. I wasn't there so can't comment much. but how was the program > spec defined? I'm not too clear on that (I was just trying to assess technical skills), but copiously specified by recognised experts from partner institutions. ;-) > prototypes? you design it in pseudo code, Yippee, non-testable code! > this then becomes your comments as you write code round them. All > languages(well most) have the same basic principles of sequence > selection and interation. Read Code Complete by Steve Mcconnell. Is it a book, article, kiwi fruit, sth else? You're describing imperative programming again, but that's irrelevant here. -- MJR

1 0

Assumptions and Paradoxes Re: ALUG Librarian stuff
by MJ Ray 10 Jun '01

10 Jun '01

David Freeman <david_freeman(a)rocketmail.com> writes: > > Have to pretty much try this. Having some sort of deposits may be a > > good move, but who holds them? > In a per-to-peer system? good question, in a centralised system? the > librarian. So who is the librarian with lots of space and time for travelling? No-one, I suspect. [assumptions] > So basically you are using one incomplete system for prove another > incomplete system? An assumption is object with no evidence of fact > backing it up which is used to help prove one system. And as such they > are the mother of all f*** ups. No, assumptions are essential to any logic system. You may not like them because they can't be proved, but you can't do anything without them. Did you know that the commonly-taught version of mathematical set theory has assumptions which lead to logical inconsistencies? A good example is Russell's paradox, the set of all sets which do not contain themselves. There was a long effort early last century to define a set theory which was free of inconsistencies. My memory is not perfect, but I don't think that it succeeded. Therefore, I propose that any system will have flaws arising from its assumptions. The best we can hope for is minor flaws, but by making the assumptions relevant, we can get something which serves us well. -- MJR

2 1

Re: [Alug] ALUG Librarian stuff, part 2
by MJ Ray 10 Jun '01

10 Jun '01

<skirmish type="horseback" carrying="scythe"> David Freeman <david_freeman(a)rocketmail.com> writes: > Why not use a sensible system? Why not write the front end in Java and > use the JDBC? <slay with="scythe" reason="playing devil's advocate">David Freeman</slay> <fx type="blood-curdling scream" /> </skirmish> Oh, and now find the system which is running the library in Java with JDBC... > 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, If you accept items which have moved successfully recently, you only have to get the original issue codes from the holders of the other books to make sure they still have it and accept responsibility for it. Flag anything that hasn't moved for ages or has moved unsuccessfully for investigation by the admin. -- MJR

2 1

Re: [Alug] ALUG Librarian stuff
by MJ Ray 10 Jun '01

10 Jun '01

David Freeman <david_freeman(a)rocketmail.com> writes: > we think > a has the facilities to do x y and y > b inherites the functionaility from a and adds p q r and s > OO is better for modern software. Some people may, but I see a process as a composition of processes carried out by actors. Imperative-OO is just so much overhead to this viewpoint. Anyway, imperative-OO still has "do this, do that" at its core... > Read UML in a nutshell and get back to me, and also phone the poor sod > and give him the Job, he sounds like he may know what he's talking > about. Formally proving programs, nice :o) Sure, he'd be good for a job, but not a job where we needed someone to design applications to an already-defined specification and deal with a large backlog of data to be processed. Horse for courses ;-) At the very least, he was off-beam with his pitch. > > > > > Good code is code which meets the needs of the application and > > > > > doesn't crash. [...] > > > > Being written is a prerequisite for these. > > > No its not, being written well is the prerequisite. > > How is being written not a prereq for being written well? ;-) > You obviously aren't in the camp of designing bugs out of programs. Yes, but how can you design without prototypes? Show me someone who can make things without ever experimenting and I'll show you some angels on the head of a pin... > I'm no expert in this sort fo stuff, but I do know that the whole > relational Paradigm and the OO paradigm are very closely tide in, ARF! -- MJR

2 1

Re: [Alug] ALUG Librarian stuff
by MJ Ray 10 Jun '01

10 Jun '01

David Freeman <david_freeman(a)rocketmail.com> writes: David, trim your quotes, please. ;-) > 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. Well, this has been covered in the earlier messages, but unless we have this p2p scheme, then either books will have to only change hands at our irregularly-spaced meetings when the borrowers are both present or whoever is the librarian will have to travel a lot. > I may also model the relational scheme or I may do it as objects to be > written in java. Oi! Implementation issues! Make your mind up! ;^) [...] > "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?" This is why the ticket-code system was being mooted. As I understand it, it could work like this: the prospective borrower gets a release code on their request which is also sent to the current borrower. The current borrower checks that the person asking for the book has this release code when handing the book over, then confirms the handover to the library system, once again with the code. > 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) Adjustable spanners are crap. They break when you bludgeon things with them. > oh goody an interative development process. Is this sarcasm or not? :-S -- MJR

2 1

ANNOUNCE: ALUG 2001.4 (End Of The Academic Year!)
by MJ Ray 10 Jun '01

10 Jun '01

Announce: ALUG 2001.4 (End Of The Academic Year!) The next ALUG meeting will be at our UEA Norwich venue as a guest of tsw.org.uk (the student web) on Sunday 17th June 2001 2:00pm - 6:00pm. We hope to hold a demonstration of some security attacks (very likely), a discussion of security measures (almost certain) and a practical exercise on configuring printers (quite likely). Venue details at http://www.anglian.lug.org.uk/venues/uea.html. If you are coming please email me on (alug at towers.org.uk) with details of any kit you are bringing so we can update the web site. Please mail the list if you have any requests for help or would like a demonstration of anything specific and we will try to accommodate if at all possible. tsw will provide tables, chairs and some networking, while drinks and food vending machines are available. There is no entrance charge to this venue, but refreshment facilities other than the above may be limited. It is anticipated that we will move to a pub after the meeting. I'll post this to relevant Usenet groups later today if no-one has upgrades? (And of course "waaaaaaaaaaaah the web site is out of control" again.) -- MJR

4 4

Re: [Alug] ALUG Librarian stuff
by MJ Ray 10 Jun '01

10 Jun '01

David Freeman <david_freeman(a)rocketmail.com> writes: > This is cos you probalby have no formal training in systems analysis. > once you try and use them they will become second nature, have a look > at the book "UML in a nutshell" it explains it all, I was like you I > ignored it all untill I understood how it would all work, I now will > try and use UML for my software to improve it. Well, I'll take a look, but the majority of systems analysis methods appeared to be focused on the object-orientated imperative paradigm, which isn't where I usually (want to) live. Am I wrong on this? Would I be able to use UML in my work? I know that I've been on panels rejecting a candidate who started spouting about using UML. (OK, they were also talking about Z, formally proving programs and other things we didn't want for a "data juggler" who had to start with a backlog of data which had already had its format designed by experts elsewhere ;-) ) > > http://rabbit.stu.uea.ac.uk/pipermail/alug/2001-May/001083.html > > Only Brett seemed to criticise it... > Critisie my scheme or my methods? Scheme afaict. > > > Good code is code which meets the needs of the application and > > > doesn't crash. [...] > > Being written is a prerequisite for these. > No its not, being written well is the prerequisite. How is being written not a prereq for being written well? ;-) > > Is an RDBMS appropriate, or should we just assume an OO backing > > store? > true, but the principles are the same, they all boil down to designing > a relationa scheme which then needs to be normalised, and as relational > theory is based on set theory as is OO theory the design is applicable > to both, hence my keeping animplementation independent view of things. The realities of modern RDBMSs with all the triggers and code inside the database seems to be quite far from pure set theory to me. There's quite a nice piece about it in the most recent VSJ, I think. -- MJR

3 3

Re: [Alug] ALUG Librarian stuff
by MJ Ray 10 Jun '01

10 Jun '01

David Freeman <david_freeman(a)rocketmail.com> writes: > I never got around to ripping it a part. The problems are > 1) Based on assumptions > a) People are honest Have to pretty much try this. Having some sort of deposits may be a good move, but who holds them? > b) People will notice books have gone astray Send out "please confirm your borrowing" emails and email the maintainers or this list if people don't answer? > c) People will return books Same as a, surely? > 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. It seems this model is slipping further and further back... > There needs to be a dead line for collection and for loans, but you > would have modelled this in the functional requirements. Unless we discuss this thing, how do we find these things out? I don't believe any initial model will get all of these things right first time. > And what are assumptions? Assumptions are beliefs which you accept as truths in order to build a logical system. They cannot be proved, but they are used to prove other results. I would have thought you'd know that, having used the word so freely... -- MJR

2 1

Re: [Alug] ALUG Librarian stuff
by brodders＠cwcom.net 10 Jun '01

10 Jun '01

Hi David! ----- Original Message ----- From: "David Freeman" <david_freeman(a)rocketmail.com> To: <alug(a)stu.uea.ac.uk> Sent: Saturday, June 09, 2001 10:22 PM Subject: Re: [Alug] ALUG Librarian stuff > > --- brodders(a)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 > > 1) 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(a)stu.uea.ac.uk > > http://www.anglian.lug.org.uk/ > > 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(a)stu.uea.ac.uk > http://www.anglian.lug.org.uk/ http://rabbit.stu.uea.ac.uk/cgi-bin/listinfo/alug > See the website for instructions on digest or unsub!

2 3

← Newer
1
...
10
11
12
13
14
15
16
17
18
Older →

Jump to page:

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

2000

1999

1998

1997

main June 2001