Archives for: November 2006

Nov 28, 2006 : Tai Chi

Nigh upon a year ago, one of my friends encouraged me to take Tai Chi classes. He was taking one and loved it.

I was looking through the winter Grand Rapids Park & Rec brochure and saw they were offering Tai Chi classes, and at a pretty low cost. So I think I'm going to enroll. There also was a fencing offering (equipment supplied) which was tempting.

Mmm.. chai tea

Nov 25, 2006 : Javascript RDFParser from Tabulator

David Sheets introduces himself and the new RDF/XML parser he added to the Tabulator all-javascript RDF browser. I've been using the RDF parser from Jim Ley in a generic JavaScript RDF Editor (to work with any OWL/schema files; no public release yet, but let me know if you're interested, especially in helping out). So recently I worked on using Tabulator's rdf parser to see if it was better. It seems to be designed a bit better (separate data store from parser from XML loading) and David's post says it is more accurate and often faster.

I had been hoping to find some additional functionality to use in my JsRdfEditor. Namely, modelling the RDF document instead of just getting all the triples. For example, knowing where a nodeID was used, and the XML arrangement of the triples. That way the JsRdfEditor could parse a file, add some triples, and output a new document that is arranged much like the one that was loaded. But no luck there; sounds like I'll have to add that capability to the parser myself, if I want to have elegant RDF/XML output.

So here's how you can use Tabulator's RDF Parser in your own projects:


// depends on:
//  dig.csail.mit.edu/2005/ajar/ajaw/rdf/term.js
//  dig.csail.mit.edu/2005/ajar/ajaw/uri.js
//  dig.csail.mit.edu/2005/ajar/ajaw/rdf/rdfparser.js

// TestStore implementation from dig.csail.mit.edu/2005/ajar/ajaw/test/rdf/rdfparser.test.html
// see also RDFIndexedFormula from dig.csail.mit.edu/2005/ajar/ajaw/rdf/identity.js
//  (extends RDFFormula from dig.csail.mit.edu/2005/ajar/ajaw/rdf/term.js no indexing and smushing)
// for the real implementation used by Tabulator which uses indexing and smushing
var store = new TestStore()
var parser = new RDFParser(store);
parser.reify = parser.forceRDF = true;
// forceRDF isn't used??


var url = 'http://something.or/other';

// get the XML
var xhr = XMLHTTPFactory(); // returns a new XMLHttpRequest, or ActiveX XMLHTTP object
if (xhr.overrideMimeType) {
    xhr.overrideMimeType("text/xml");
}
// the "data/" path and encoding is just how I store files locally
xhr.open("GET", "data/" + encodeURIComponent(encodeURIComponent(url)), false);
xhr.send("");
var nodeTree = xhr.responseXML;
if (nodeTree === null && xhr.responseText !== null) {
    // Only if the server fails to set Content-Type: text/xml AND xmlhttprequest doesn't have the overrideMimeType method
    console.debug("no responseXML, parsing responseText");
    nodeTree = (new DOMParser()).parseFromString(xhr.responseText, 'text/xml');
}
// must be an XML document node tree
parser.parse(nodeTree,url);

// use FireBug extension to inspect console.debug'd objects
// Using TestStore you can access store.triples
console.debug('store',store);
Technorati tags:

Nov 02, 2006 : Great Lakes Software Excellence Conference; and not doing TDD


Last week I got to go to the Great Lakes Software Excellence Conference. It was a very good one-day conference (plus workshops the day before), especially since it was local. There was a developers track, a process track, and a testing track. All had good presentations; lots of them focused on agile methods and many emphasized the value in good people and good relationships. Thanks to the organizers: XP West Michigan and the American Society for Quality! It was fun to see fellow Calvin CS alumni at the conference :)

I'd like to use more agile methods and test-driven development at work, but our department is very very small so we each already wear many hats and we don't overlap much. That makes pair programming difficult. The presentation on pairing suggested that you could pair on other tasks too, like writing the requirements doc, or testing, which I think we could do effectively. For test driven development, this may be heresy, but I don't think it's worth doing for many of our projects. The processes & data for which we write software are not critical to our organization. Sure they're useful, but their not critical. (We used purchased software to do all our core business functionality). All the software that we develop are very useful but are not critical. In fact they are so far from critical that virtually all bugs in "production" are actually acceptable. The cost to do TDD does not offset the cost of not doing it.

Technorati tags:

<< Previous Page

<< Previous Page

<  November 2006  >
Mon Tue Wed Thu Fri Sat Sun
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30      

Categories


Archives

Misc

Syndicate this blog XML

powered by
b2evolution