Re: [CODE4LIB] distributed library alpha server up, feedback welcome

2011-04-25 Thread Dave Caroline
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

2011-04-25 Thread Markus Fischer

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

2011-04-25 Thread Elliot Hallmark

 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

2011-04-25 Thread Elliot Hallmark
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

2011-04-25 Thread Doran, Michael D
 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

2011-04-25 Thread Elliot Hallmark
@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

2011-04-24 Thread Gabriel Farrell
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. 

[CODE4LIB] distributed library alpha server up, feedback welcome

2011-04-23 Thread 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 accepts 5 digits

thanks for reading,
Elliot