Meet Your Developer: QA Dan

With the Islandora Conference coming up , we thought it would be a good time to Meet some Developers, especially those who will be leading workshops. Kicking it off is Daniel Aitken, better known in the Islandora community as QA Dan, master of testing. Despite the name, Dan now works for discoverygarden, Inc as a developer, although he maintains ceremonial duties as Lord Regent of the QA Department. He's known for thorough troubleshooting on the listserv, some very handy custom modules, and will be leading workshops on How to Tuque and Solution Packs (Experts) at the upcoming Islandora Conference. Here's QA Dan in his own words:

Please tell us a little about yourself. What do you do when you’re not at work? Hmm … when I’m not working, and I decide to do something more interesting than sitting on the couch, I’m probably baking. Pies, biscuits, cookies … currently I’m working on making fishcakes from scratch. Batch one was less than stellar. I think I accidentally cooked the starch out of the potatoes.   How long have you been working with Islandora? How did you get started? I’ve been with discoverygarden for about three years now. I kind of randomly fell into it! I didn’t really know what to expect, but the team here is fantastic, and I’ve gotten the opportunity to work on so many fascinating projects that it’s been a blast.   Sum up your area of expertise in three words: Uh … code base security?   What are you working on right now? Right this second? Looking at a fix to the basic solr config that should prevent GSearch/Fedora from spinning its wheels in an unusual case where certain fields end in whitespace. Once I actually get some free time here in the QA department? Updating our Travis-CI .yaml scripts to use caching between builds so that hopefully we don’t have 45 minute-plus build processing times.   What contribution to Islandora are you most proud of? The testing back-ends! Y’know, all this stuff. To be fair, a bare-bones version was there before I got my hands on it, but it’s been updated to the point where it’s almost indistinguishable from its first form. It separates testing utilities from the actual test base class so that it can be shoehorned into other frameworks, like the woefully-underused, or even in included frameworks like the basically-magical datastream validation stuff! That way, no matter what you’re doing, you can manipulate Fedora objects during tests! It’s also been made easy to extend, hint hint.   What new feature or improvement would you most like to see? Does ‘consolidated documentation’ count? I feel like that’s what slips a lot of people up. I know we’ve been working on improving it - we have a whole interest group devoted to it - but it’s a multi-tendriled beast that needs to be tamed. We have appendices living in multiple places, API documentation that only lives in individual modules’ api.php files, and just … all kinds of other stuff. As a kind-of-but-not-really-an-end-user sort, I only really make improvements to technical documents like Working With Fedora Objects Programmatically via Tuque, and half the time these are ones I made myself because there was a desperate gap in the knowledgebase.   What’s the one tool/software/resource you cannot live without? Ten Million with a Hat! I don’t know what I did before I had it. Actually, I do; I flushed all my time down the toilet manually creating all the objects I use in my regular testing. So I made a thing with the concept of ‘just batch ingest a bunch of random objects, and modify each one via hooks’. Then, I started working on the hooks - things to add OBJs and generate derivatives and randomly construct MODS datastreams and do DC crosswalking and add things to bookmarks and whatnot - whatever fits the case for whatever I’m testing. Now I’ve gone from ingesting objects I need manually like some kind of chump to having Islandora take care of it for me. The moral of the story is that if you think you couldn’t live without a tool, probably just make it? Code is magic. Tuque is also magic.   If you could leave the community with one message from reading this interview, what would it be? Write tests and Travis integration for your contributed modules! I know it’s a time investment, but I’ve put a lot of work into making it easier for you! There’s even a guideline here. It’ll tell you all about how to poke at things inside Islandora and make assertions about what comes back, like whether or not objects are objects and whether or not the datastreams exist and are well-formed (they tend to rely on the actual contents of the binary, and never on extensions or mime types). Well-written high-level tests can tell you if you’ve broken something that you didn’t expect to, and Travis can tell you all sorts of things about the quality of your code per-commit. A tiny weight is lifted off my shoulder every time I see a project I’ve never encountered before that has a ‘tests’ folder and a ‘.travis.yml’ and a big green ‘PASSING’ in the README on GitHub.   Happy Islandora-ing!