Re: [CODE4LIB] distributed library alpha server up, feedback welcome
I am another self coder using my own ideas not stuck with legacy ideas and using a web design with mysql db I happen to use php and dont use a cms like many seem to these days. I find use of a CMS somewhat restricting to the use of the database for full speed. You may get a CMS up quickly but it can bite you when you try to scale later, some have poor use of the database behind, I have lurked and helped in #mysql for a number of years and seen that problem a number of times. Search is possible on smaller systems you just need to implement an inverted index on the data you want to search this can be complex and large, Solr, or Sphinx or even the one mysql has built in a fulltext index. I went the way of creating the index in my application, that gives me a multi table search. http://www.collection.archivist.info/searchv13.php?searchstr=steam I went beyond marc because I store subject info in the database. http://www.collection.archivist.info/searchv13.php?searchstr=proceedings A good example is http://www.collection.archivist.info/searchv13.php?searchstr=bk2108 As mine is for my own personal book collection, some data is only available on an internal view of the data eg shelf, or if I've lent to someone and who. The search engine can be separated out from the code and used in other db schemas, I tried this on a partial marc import cherry picking a few of the fields, this is web viewable too http://www.marc.archivist.info/searchv10.php?searchstr=james applied to another set of data with computer manuals http://manx.archivist.info/search.php?search=altos I thought this would easily fit your system till I looked at django, wrong language I use PHP, which will run anywhere almost. If running your own server on own IP address then you just need to buy a domain name and have it pointed to you, I happen to do similar except I run the dns name server too so I can add as many sub domains as I wish. Running a name server means you need a secondary name server, get a friend to do that. Dave Caroline
Re: [CODE4LIB] distributed library alpha server up, feedback welcome
Hi Elliot congrats, you did it! Wish you all the best for the further development! Markus Am 23.04.2011 23:27, schrieb Elliot Hallmark: All, It was at the end of last year that I came here saying I was writing an open source ILS for a distributed (book sharing) library. While I had lots of enthusiasm and time for it at the time, our development computer didn't have the capacity to run a solr based discovery front end. Even though the back end was ready for feedback (though still very alpha), I dallied in posting the IP because there was no discovery layer. In the interest of moving forward, and since a complex discovery layer may not be necessary for a while (not for 100 books), here is the IP. Please check it out and give feed back. Play around with whatever, this data isn't real. http://72.48.75.76 If this IP changes, I'll let y'all know on this thread. Soon I would like to use this system at our private alternative schoolhttp://www.clearviewsudburyschool.orgin hopes that it would facilitate folks letting us use their excellent books, since they would be lending them, not donating them. Having a database keeping track of who owns the books would give a little peace of mind. in the future, setting up a network of libraries would be easy. notes: 1. This is a distributed library, where a book enters the system through a primal loan (from owner to library), and is due back at some point. The book or item can be further lent to a regular borrower, or to another library (which inherits lending privilages). extending lending privilages must be done through the administrative back end, so it wouldn't happen accidentally. 2. The discovery layer is severely crippled because I don't want to write a indexer for our MARC records unless it becomes necessary (ie, better searching is needed but writing a VuFind driver or integrating with Kochief isn't yet feasible). All books entered in this system also have MARC records associated with them, so a solr or other front end can be added later. 3. If you'd like to try uploading a MARC record, email it to me and I'll put it up for anyone to enter through the cataloging app. 4. This is written in django. Hooray for python! 5. This is not at all perfect yet. here is my todolist so far (please add to it): when checking a book out, do not allow a due date later than the current lease on the book. subtitle, does this really need to be limited to 100 characters? create an end of day script that: sends emails to books that are due back soon sends emails to books that are overdue activate fines model and add an Fine.calcuate() method make a legit zipcode field. current one accepts5 digits thanks for reading, Elliot
Re: [CODE4LIB] distributed library alpha server up, feedback welcome
Another thing that differentiates you from other small libraries attempting this sort of thing is your contacting of this list. Most of the readers here are used to big-data problems, where they're trying to make sense of the storage, maintenance, and display of millions of records, so it's a bit of work to scale the mind down to a situation such as yours. True, my issues are completely different from those usually tackled here. But, still, some folks here may potentially be interested in the capabilities this circulation system offers. Also, y'all know what problems can arise when thousands upon thousands of records accumulate, and I have no idea what may go awry with this as it handles unexpected cases. So, you might have insights for me. related to indexing records in the app: Yes, as an intermediate between a title list and a solr catalog (VuFind, Kochief), I could write a quick app that stores subject, author and pub date from the MARC records and then do search with icontains queries. That would be then next biggish step. @Dave. Django is not a CMS, but a package of python libraries one would use to write a CMS. The poor use of the database would be my own fault, because I write the queries (or python code which is compiled into SQL). For instance, every blog with a headline that contains (case sensitive) Lennon is executed with Blog.objects.filter(entry__headline__contains='Lennon') read more here if you like: http://docs.djangoproject.com/en/dev/topics/db/queries/ Also, any host will support php, but only *most* of them support django at the level of the cheapest possible plan. At the second cheapest level, pretty much any established host supports django. University of Texas is switching to django for all of their internal DB stuff like accounting and payroll for reasons that are obvious to anyone who has used django.
Re: [CODE4LIB] distributed library alpha server up, feedback welcome
Interesting point about the checkout history. Not displaying it automatically is probably a good idea. I wouldn't drop that info though, or obscure it in the DB.
Re: [CODE4LIB] distributed library alpha server up, feedback welcome
University of Texas is switching to django for all of their internal DB stuff like accounting and payroll for reasons that are obvious to anyone who has used django. Huh? Django may be great, but this seems highly unlikely. -- Michael # Michael Doran, Systems Librarian # University of Texas at Arlington # 817-272-5326 office # 817-688-1926 mobile # do...@uta.edu # http://rocky.uta.edu/doran/ From: Code for Libraries [CODE4LIB@LISTSERV.ND.EDU] On Behalf Of Elliot Hallmark [permafact...@gmail.com] Sent: Monday, April 25, 2011 1:58 PM To: CODE4LIB@LISTSERV.ND.EDU Subject: Re: [CODE4LIB] distributed library alpha server up, feedback welcome Another thing that differentiates you from other small libraries attempting this sort of thing is your contacting of this list. Most of the readers here are used to big-data problems, where they're trying to make sense of the storage, maintenance, and display of millions of records, so it's a bit of work to scale the mind down to a situation such as yours. True, my issues are completely different from those usually tackled here. But, still, some folks here may potentially be interested in the capabilities this circulation system offers. Also, y'all know what problems can arise when thousands upon thousands of records accumulate, and I have no idea what may go awry with this as it handles unexpected cases. So, you might have insights for me. related to indexing records in the app: Yes, as an intermediate between a title list and a solr catalog (VuFind, Kochief), I could write a quick app that stores subject, author and pub date from the MARC records and then do search with icontains queries. That would be then next biggish step. @Dave. Django is not a CMS, but a package of python libraries one would use to write a CMS. The poor use of the database would be my own fault, because I write the queries (or python code which is compiled into SQL). For instance, every blog with a headline that contains (case sensitive) Lennon is executed with Blog.objects.filter(entry__headline__contains='Lennon') read more here if you like: http://docs.djangoproject.com/en/dev/topics/db/queries/ Also, any host will support php, but only *most* of them support django at the level of the cheapest possible plan. At the second cheapest level, pretty much any established host supports django. University of Texas is switching to django for all of their internal DB stuff like accounting and payroll for reasons that are obvious to anyone who has used django.
Re: [CODE4LIB] distributed library alpha server up, feedback welcome
@brice: good point, its on the list now @michael: University of Texas is switching to django for all of their internal DB stuff like accounting and payroll for reasons that are obvious to anyone who has used django. Huh? Django may be great, but this seems highly unlikely. I may very well not have the correct information. But (just in theory) it would be the work of an hour to map any database schema into django and then use the python shell to navigate your database instead of raw sql. HUGE improvement right there (human readable inner joins, simple 'or' relationships in queries, and on and on). as an added bonus, all the data you pull out is then immediately accessible to other python functions and libraries. I'm not saying they are writing a pretty web interface. Also, I could have been misinformed or misunderstood the UT austin CS student I heard this from.
Re: [CODE4LIB] distributed library alpha server up, feedback welcome
The distributed library, where all patrons are both lenders and borrowers, is an intriguing concept, and it's great that you have a rudimentary system up to experiment with it. Aside from the unusual requirements of a distributed library, you have one thing which separates you from the masses of small libraries who set up systems for their resources: you're not using MS Access. I applaud your decision to build a webapp, though some might call this overkill. As long as your patrons are able to use the system, and you're having fun with the challenge, charge on ahead. I have a few questions and comments. I see you're storing only the title and location of each book in the Django database, and tying into MarcEdit for the rest of the record. I assume you're using MarcEdit for the Z39.50 client and the editing interface, but you might want to look into exporting the records from MarcEdit (as MARCXML, most likely) and ingesting them into the webapp database. Keeping the two databases in sync and communicating with each hit, especially once the webapp is on its own server, could become difficult. Also, you may want to allow for remote cataloging at some point. If you're really feeling adventurous, you might look into wrapping PyZ3950 into a cataloging app. I agree that a collection of that size doesn't warrant a search engine like Solr. Some icontains queries are probably enough if browsing alone doesn't suffice. Most circ apps don't display the history of patrons who have checked out an item, or a patron's history of checked-out items, for privacy reasons. Some even drop those records from the database, or anonymize them. Another thing that differentiates you from other small libraries attempting this sort of thing is your contacting of this list. Most of the readers here are used to big-data problems, where they're trying to make sense of the storage, maintenance, and display of millions of records, so it's a bit of work to scale the mind down to a situation such as yours. Also, most of us spend much of our time working around legacy systems, so the troubles of a small, young app are both foreign and envied. That's my way of explaining why you might not get much response here. And for heaven's sake, point a subdomain or something at that machine. No reason to pass around IP addresses in this day and age. On Sat, Apr 23, 2011 at 5:27 PM, Elliot Hallmark permafact...@gmail.com wrote: All, It was at the end of last year that I came here saying I was writing an open source ILS for a distributed (book sharing) library. While I had lots of enthusiasm and time for it at the time, our development computer didn't have the capacity to run a solr based discovery front end. Even though the back end was ready for feedback (though still very alpha), I dallied in posting the IP because there was no discovery layer. In the interest of moving forward, and since a complex discovery layer may not be necessary for a while (not for 100 books), here is the IP. Please check it out and give feed back. Play around with whatever, this data isn't real. http://72.48.75.76 If this IP changes, I'll let y'all know on this thread. Soon I would like to use this system at our private alternative schoolhttp://www.clearviewsudburyschool.orgin hopes that it would facilitate folks letting us use their excellent books, since they would be lending them, not donating them. Having a database keeping track of who owns the books would give a little peace of mind. in the future, setting up a network of libraries would be easy. notes: 1. This is a distributed library, where a book enters the system through a primal loan (from owner to library), and is due back at some point. The book or item can be further lent to a regular borrower, or to another library (which inherits lending privilages). extending lending privilages must be done through the administrative back end, so it wouldn't happen accidentally. 2. The discovery layer is severely crippled because I don't want to write a indexer for our MARC records unless it becomes necessary (ie, better searching is needed but writing a VuFind driver or integrating with Kochief isn't yet feasible). All books entered in this system also have MARC records associated with them, so a solr or other front end can be added later. 3. If you'd like to try uploading a MARC record, email it to me and I'll put it up for anyone to enter through the cataloging app. 4. This is written in django. Hooray for python! 5. This is not at all perfect yet. here is my todolist so far (please add to it): when checking a book out, do not allow a due date later than the current lease on the book. subtitle, does this really need to be limited to 100 characters? create an end of day script that: sends emails to books that are due back soon sends emails to books that are overdue activate fines model and add an Fine.calcuate() method make a legit zipcode field.
