January 2017

M T W T F S S
      1
2345678
9101112131415
16 171819202122
23242526272829
3031     

Style Credit

Expand Cut Tags

No cut tags
Friday, September 14th, 2007 07:13 pm
Just as an offhand request, does anyone out there know of a simple program for managing and searching simple lists of data? In particular, I'm imagining something where I could easily input a list of items, each with a title, brief description, maybe some other data (ratings?), and arbitrarily many keywords to describe it. I'd want the description text to be searchable, and I'd want to be able to browse lists of items with a given keyword (or, ideally, boolean combination of keywords).

I'm pretty sure that what I'm describing here would be satisfied by practically any database. And indeed, I happen to have installed MySQL on my laptop years ago (any important updates since 4.0.18?). But 1) that seems like massive overkill, and 2) if it would take me more than about five minutes to set it up and learn how to use it, I don't have time: this is for a maybe-useful maybe-vaguely-work-related project that is far, far from essential. (As I recall, my earlier look at MySQL sputtered out largely because the tutorials I saw all suffered from either a glacial pace, an overdose of obscure syntax variants and data models, an obsession with moral purity in relational database design, or all of them at once.) By contrast, I can just look at a program like iTunes and understand how to enter data, search and sort, create "smart playlists", and all sorts of other things.

I've actually considered just abusing the excellent Mac bibliography/research-paper-PDF manager BibDesk to do what I want. If I just pretended each data entry was a scientific paper, I think it could work fine. But given how easily I could adapt it (or maybe even iTunes or iPhoto) to do this, it seems crazy to think that simple general purpose tools like this aren't a dime a dozen. I have no idea how to find a good one, though. Any suggestions?

(I understand that newer versions of MySQL include GUI tools to make things a bit more manageable, but I expect that those would still require me to learn a bunch of database jargon and design principles. I wouldn't mind the option to gradually transition to that level of knowledge, but I can't afford to start that way.)
Saturday, September 15th, 2007 07:02 pm (UTC)
Yeah, I guess that throwing something together in perl (python would mean learning a new language) would be pretty easy, though if I went that route I'd probably just hard-code the list into the program file (as Jon suggested) rather than coming up with a structured text file data format and writing some kind of parser. (I've written CGI scripts using both approaches in the past.)

But actually, my "abuse BibDesk" idea would almost work this way: it stores its data in plain text BibTeX files. As long as I ignored all the LaTeX-specific stuff, it would be a decent approximation of the idealized interface that I might want to write. (I think I can even create "smart folders" there to implement boolean operations, albeit with just as much of a hassle as in iTunes.) In fact, BibDesk uses some BSD license variant: with a bit of effort, one could presumably hack it into a more general-purpose program directly. But that's overkill for me.
Sunday, September 16th, 2007 08:21 pm (UTC)
Writing something to parse a line into keywords would be trivial, literally the work of a few minutes, in a scripting language like python or perl. The days where creating and parsing a "structured text file data format" take effort are long gone, thanks to perl. So it's not like it's much work. In python, it would just be something like, if your text file format is "title, then keywords, tab separated"

----
# Read in text file
entries = []
for line in open(myfilename).readlines():
entry = {}
items = line.split('\t')
entry['__title__'] = items[0]
for item in items[1:] # keywords is everything after first column
entry[item] = 1
entries.append(entry)
# Now you have a list of dicts, and it's trivial to query:
search_results = [entry for entry in entries if (entry['foo'] and entry['bar']) or entry['yawn']]
print '\n'.join([result['__title__'] for result in search_results]
----
That's it. I think it's actually easier to write those few lines of parsing than to hard-code the data into your program. And you could write something just as short in perl, although it would be uglier and harder to read.
Sunday, September 16th, 2007 09:04 pm (UTC)
You're right: that is simple, and something like this probably is the way to go. (I do like the simple look of python, too, at least when the indentation isn't swallowed by HTML's whitespace handling. Am I right that indentation is syntactically meaningful, given the lack of loop delimiters?)

But there's still some issue of balancing simplicity of parsing/searching against simplicity of data entry, because I would like to include a handful of other bits of data along with each entry in the list. That "brief description" would probably be a block of text somewhere between a sentence and a paragraph long. Writing (or reading) that without line breaks would be a pain, so the parsing routine would need to have some way of separating entries other than "one newline each". Hence my concern that writing a sufficient program would be more than a 10 minute job. (I might be able to just steal some of my own old code, though.)
Sunday, September 16th, 2007 09:31 pm (UTC)
Yep, python uses indentation to define blocks, saving you the {}. It's an awesome language.

You could do each entry in a different file if you wanted to include more data. Say, keywords on the first line, and everything else the program treats as a big blob.
Tuesday, September 25th, 2007 08:37 pm (UTC)
As someone said above, you could easily use a spreadsheet saving files in CSV format for your data entry.

I love programming in Python. I find that most of the time the way it works is the way I think about code in my head. It has worked very well for a lot of small projects I've done at work or at home.
Saturday, September 29th, 2007 01:38 am (UTC)
this reminds me that I just saw an article today about spreadsheets for programmers, which use python instead of VB as their scripting language.