Thursday, March 15. 2007FacBackOPAC: making Casey Durfee's code talk to UnicornFor the past couple of days, I've been playing with Casey Durfee's code that uses Solr and Django to offer a faceted catalogue. My challenge? Turn a dense set of code focused on Dewey and Horizon ILS into a catalogue that speaks LC and Unicorn. Additionally, I want it to serve as both a proof of several technologies (Solr for faceted searching and Django as a Web application framework) to my colleagues and as a reasonable backup catalogue for when our main catalogue fails (as it all too often does). I emailed Casey today to tell him that I had a number of patches to contribute as a result of my experiments. It turns out that he's not really interested in pursuing this particular project much further, so he gave me his blessing to take his throwaway code and do whatever I want with it. Thus, the emergence of the FacBackOPAC project on code.google.com. If there's a grant out there for worst project name ever, this project's in the running... Anyways, I have contorted Casey's code so that it supports both Dewey and LC, and with a bit more torture it should be flexible enough to support both Horizon and Unicorn. Right now I've twisted it all the way to meet my Unicorn needs and consequently have broken Horizon support, but it won't take much to make it support Horizon again - or any other ILS, for that matter. The main requirement is that you have to be able to get your MARC records and holdings out of your ILS. A secondary requirement is to know how to create links to detailed item views in your current catalogue, because this thing does not yet have any current awareness about item status. There. My itch has been scratched for the time being. Go play with the FacBackOPAC project -- I even have (very) rough documentation on how to get the pieces installed andthe MARC records indexed, although you'll have to dig through the source in the Django catalog tree to overcome some hardcoded strings and URLs for the time being. Don't worry, pulling that hardcoded stuff out of the templates is high on the list of priorities. So, a huge thank you to Casey for freeing this code and making this possible. For something he considers throwaway code, I've learned a lot from walking through it and making it start to meet my needs. I hope it helps you, too! Update 2007-03-18: Edited links to point to the FacBackOPAC project page, rather than the wiki (which is subject to change, and which did -- breaking the dang links in the original version of this story. Argh!) Wednesday, February 28. 2007Lightning talk: File_MARC for PHPI gave a lightning talk at the code4lib conference today on The funny thing is that I had originally pitched a full session talk on this subject for the conference, and it didn't make the cut of the ruthless democracy that is code4lib. In retrospect, even a twenty-minute thunder talk probably would have been too much information for anybody but the most die-hard PHP and MARC coder out there; the lightning talk was a perfect format for the talk. I hope to let the documentation do most of the talking in the future. Here are the slides from the talk in OpenOffice.org and PDF format. Enjoy! /me notes that UnAPI would be useful here... Gotta try and submit a patch to the s9y repository... Tuesday, January 2. 2007Reflections at the start of 20072006 was a year full of change - wonderful, exhausting change. Here's a month-by-month summary of the highlights of 2006:
So, all in all, it was a pretty full year of geekdom, some regular exercise, a bit too much poker, a ton of travel, and a whole lot of change. There wasn't nearly enough Amber (of course there can never be enough), even though I have her all to myself a couple of mornings each week. But I'm living with the people that I love, doing fulfilling work, and that's all I can really ask for. Wednesday, December 27. 2006The state of PHP security (LWN article)One of my favourite online publications, the Linux Weekly News, recently published an article called The state of PHP security. Given Stefan's departure, the great taint debate, the addition of ext/filter in 5.2.0 and all of the associated security changes in both the 5.2.x and the 6 branches, I settled down to enjoy a nice pre-Christmas read. I was hoping for some provocative thoughts about the direction that PHP has been taking for the last six months or so in the arena of security. Unfortunately, I was greatly disappointed. Beyond using Stefan's departure as a kicking-off point for the article, the author didn't even mention any of these issues. Instead, he simply rehashed the history of PHP design missteps (magic_quotes, register_globals, allowing URLs in include) and noted that many PHP tutorials rely on dangerous practices. What bothered me the most, however, was the author's decision to paraphrase a quote Rasmus gave in an interview from 2002 without explicitly noting that the quote was from 2002. The sentence in the article, talking about register_globals, is: It is an extremely dubious feature, but one that PHP creator, Rasmus Lerdorf, seems to think should have been left on by default. Would it have been too much for the author to have actually asked Rasmus if he might have changed his mind in the past five years? Or perhaps the author could have done a little more research and dug up the PHP 6 planning meeting minutes that state that register_globals and magic_quotes were going to be removed entirely from the language. Instead, the author concludes with the following statement: Security seems to fall somewhere below simplicity in the minds of the PHP language developers; that makes it more difficult to have secure PHP applications. Security is a hard problem and any attempt to 'dumb down' a language is likely to run into security issues. Encouraging amateur programmers to write web applications is unlikely to produce secure code in any language, but by providing tutorials and examples that have glaring security issues and by not concentrating on teaching secure coding, PHP makes it that much worse. A great deal of useful code has been written on the PHP platform; it would be nice to find a way to keep that code coming while simultaneously making it more secure. The first sentence in that statement is the most damning of PHP developers, but it entirely ignores the evidence exhibited in the changes we've seen in PHP 5.2.0 and that are in the works for PHP 6. The third sentence, oddly enough, attributes the existence of "tutorials and examples that have glaring security issues" to PHP itself, as though the language itself or the core developers of the language have the ability to prevent insecure tutorials from being published. So I launched into the fray and attempted to right those injustices, perhaps a bit too passionately -- but so be it. I've been pretty quiet in the PHP world for the past while, outside of my little PEAR projects, but I still care about the language. If I can glean anything from this article, it suggests that it might be a good idea to revamp the php.net landing page and documentation a bit to try to highlight tutorials that teach developers how to write secure PHP applications. Right now the landing page is largely a bulletin board for events. It might benefit, say, from a prominent and permanent link to the PHP Security Consortium (if that project is actually still alive--the last posted article dates back to March 2005). We may also want to improve the visibility of the security chapter of the manual (although briefly revisiting the section on SQL injection suggests that we need to revise it to encourage the use of PDO and placeholders).
« previous page
(Page 2 of 8, totaling 30 entries)
» next page
|
QuicksearchAbout MeI'm Dan Scott: barista, library geek, and free-as-in-freedom software developer.
I hack on projects such as the Evergreen
open-source ILS project and PEAR's File_MARC package .
By day I'm the Systems Librarian for Laurentian University. You can reach me by email at dan@coffeecode.net. Identi.ca microblogging
LicenseCategories |
