Just finished perioperativebleeding.org. An e-learning application designed for anestesiologists, hematologists and allied health professionals who manage, treat, or refer patients in the field of perioperative bleeding management. The physicans can watch lectures and afterwards take short exams to earn CME-credits.
Used technologies:
December 16th, 2007
okflo
Yesterday I’ve got mail from the amazon developer-service (I am a user of amazon s3) about their upcoming feature, also /. has a story about it.
Sounds interesting – building web applications and using amazon’s database (a store where you can create/update und delete objects) as persistence.
More and more applications and services seem to make a shift from traditional SQL/DBMS to object-stores. One of these ideas, I would be interested most, is Allegro Cache – a lisp persistence system for CLOS objects – sadly not free but part of ACL. In the opensource-community there exists elephant and rucksack. Exspecially rucksack seems to be a very interesting stuff, unfortunately in early alpha-state. Elephant depends on BerkleyDB but has the option of alternative backends.
A very interesting topic, exspecially as many frameworks (f.e. ruby on rails) tend to produce automatically surrogate keys. Lee Richardson tries to advocate surrogate keys in his blog-post. I hate surrogate keys, often calling people using them “M$-Access-Users”. But, to be honest, sometimes, exspecially when mapping OOP-Classes into tables, there is no other way. Best answer to Lee’s post seems to be Ian Batty’s comment. Let me cite one paragraph:
“Personally I am a natural key guy. Saying that, and this is where your example loses credibility, practical experience has shown that for a person there is no natural key, so I create a surrogate. However, if I am creating an entity that has a true unique identifier, that doesn’t change and meets all the other requirements then I will use it.”
Seems to be a very good general advice.