deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
For a project at work (CIDER) we're using git pretty extensively, with an adapted version of the git-flow model. For all that I'm finding myself becoming a release engineer all over again -- not a career I intended to move back towards, but what can you do? -- I'm really enjoying our development model so far.

Our model is that people do all their work on spot branches, except for ongoing subtle improvements to template toolkit files, which has been happening on a single long-lived branch. When a fix is made the developer makes a pull request. One of the other two of our three core developers -- in practice always me -- does a quick code review, and tests it in our development environment just by doing git checkout --track origin/[branch] (or, in the case of the long-lived branch, git checkout [branch];git pull and running the Web server against the new contents of the directory. When it's tested in the development environment, we just accept the pull request and do a git pull in the production directory.

It's nothing fancy or unusual -- basically git-flow without continuous integration. But over the years of using CVS, RCS, subversion, and perforce, only perforce has given me anything close to as much satisfaction in the release management, and perforce wouldn't work for our current model (where one of our developers is a remote contractor).

Of course I also like using the same environment and tools for work and for dreamwidth, because it takes away the cognitive cost of switching when I come home and decide to work on dreamwidth.
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
Roy Tennant has dashed off the startlingly ignorant "If You Are a Library Sysadmin, You Are Toast". I really hope it was tongue-in-cheek and just missed its mark as far as humor goes.

There's a certain extent to which I think if you are a library sysadmin, you are making poor career choices. If you have that skill set and feel like sitting alone in a basement closet all day interacting with nobody but computers, why are you working in libraries when you could have a real job that pays actual money? (Said the pot to kettle.)

Tennant says:

When I, as just a moderately savvy librarian, can learn maybe five to ten very specific steps and be able to deploy any application I would likely want to deploy, why do I need to talk to my system administrator ever again?


Roy, in this day and age, 90% of what system administrators do is something that you, as a moderately savvy librarian, could figure out how to do. Most systems administrators aren't writing device drivers and patching kernels all day long. But you know what? 90% of what librarians do is something any moderately savvy patron could figure out. 90% of what office administrators do is something any moderately savvy office employee could figure out. You don't have specialized employees because they have access to the supersecret field knowledge that only guild members, with their club handshakes, can discover. You hire specialized employees because in order to have something done well in a time efficient fashion, our society has decided to specialize.

Sure, you could set up an externally hosted ILS, hack Drupal in the cloud all day, store all your data in Amazon S3. And then either:

  1. You will be doing a bad job of managing that information and making sure it is backed up and reliably accessible; you don't have a lot of time because you have your own actual job to do, or

  2. You will be doing a bad job of your own actual job, because you will be too busy making sure that all of your cloud-hosted material is backed up and reliably accessible and managed to actually do the tasks you've been paid to do, or

  3. You will wake up one morning and discover you have become a library sysadmin.


"I can find books and articles myself with Google scholar, what would I ever need a librarian for? LOL your job is in danger!"
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
Library Garden posted on The New IT Librarian Application.
Librarian in Black responded with How to Test Applicants' Tech Skills.
Caveat Lector responded with Testing Your Techies.

Full disclosure: Before I went to library school, I spent ten years as a systems administrator in large corporate environments, and I was damn good at it. I still run my own small ISP. So I'm speaking here as a librarian/archivist but also as a sysadmin.

Library Garden's post is misguided: "If the person's resume and cover letter meet your standards, TEXT their cell phone to set up an interview. Unorthodox? Perhaps, but part of the IT personality is embracing modern technology. Texting is one of the most popular means of communication with our younger population and, if we want to stay current with our patrons, then we need make sure our IT people are familiar with it as well."

This is maybe good advice if you are trying to hire a Library 2.0 guru, but is it good advice to hire IT personnel? No, no, and no. Your IT people need to be able to make sure your servers are backed up. They need to make sure you have fast reliable networks. The need to make sure you have all of the rights you need to administer your data, and all the right tools at your fingertips. They need to make sure that your data are secure. They need to be on top of improvements in file systems, aware of security alerts, knowledgeable about server-class hardware. They probably need to be capable database administrators in a pinch. And if the library staff believes the best way to communicate with users includes setting up text notifications, then your IT people need to be able to set up a good infrastructure for sending text notifications.

Does that mean they need to take in text messages themselves? Maybe you think so. Maybe you think that nobody can set up a good infrastructure of a tool they don't themselves use. But I will tell you, there are plenty of fantastic sysadmins who are complete Luddites about personal technology. Are you really going to hire a sysadmin because she uses twitter? Or are you going to hire her because she writes Debian Linux kernel patches in her spare time? I will give you a hint: there is only one right answer to this question.

Librarian in Black hits it: "And testing an IT person's skills is a lot tricker, but it can be done...assuming you have someone on the other end who can verify the accuracy of the responses. I advocate for essay questions and actual problem-solving questions that present a real problem and ask for code,or a project plan, or a network diagram."

There are two hugely important points here: testing and having someone in-house who can verify the accuracy.

I have no idea how people do real interviews without doing skills tests. My favorite sysadmin test is to hand people this snippet:

crw-rw-rw- 1 root tty 3, 175 2008-06-07 23:43 ttyzf
prw-r----- 1 root adm 0 2008-06-10 10:04 xconsole
brw-rw---- 1 root disk 202, 2 2008-06-07 23:43 xvda2
drwxrwxrwt 7 root root 5120 2008-06-10 15:56 tmp
lrwxrwxrwx 1 root root 4 2008-04-24 15:48 lib64 -> /lib
-rwxr-sr-x 1 root mail 395107 2008-06-09 10:07 elm
-rwx--x--x 1 root staff 15340 2008-06-09 10:07 mmencode


I ask them to talk about it. It's a great piece, because if you have any UNIX admin experience at all, you should be able to at least give a four-word description of that whole class of text. And there are lines in there of some fairly intense levels of complexity, which in many cases only an experienced administrator would be able to describe. It's not a Pass/Fail test, it's a Show Me What You Know test, which is a far better kind. Alternately, I would ask problem-solving questions: "User calls up yelling about [situation]. Fix it." This gives you the opportunity to watch both problem-solving skills and at least the job applicant's stated user-communication skills.

But the vitally important issue here is what Librarian in Black says: assuming you have someone on the other end. It's very, very difficult -- almost impossible -- for an entirely non-technical hiring committee to select a good technical applicant. You can select someone nice, and you can select someone who will fit in with your corporate culture, and you can select somebody who talks a good game. But without finding somebody else with a similar set of job skills to sit on your hiring committee? It's all luck. Trust me, no matter how smoothly the person comes off, no matter how competent he or she seems, you can't do an accurate assessment of technical skills without having the knowledge yourself. Technical people often sound extremely confident in their skill, oftentimes with no good reason. If it is at all possible for you to get an IT person from somewhere else in your organization to sit in on the hiring committee? Do so.
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
[Tagged as, among other things, otw, because even though I am dealing with these issues as a professional I think that The Organization for Transformative Works is very well-placed to be one of the few organizations prepared to confront operational preservation from the outset. After all, the OTW has to deal with one even more frightening aspect of operational preservation: it is an entirely volunteer-run organization which promises perpetual preservation. It takes a lot of planning and commitment to be prepared to follow through on a commitment like that. Luckily, the OTW has both.]

Introductory thoughts on Operational Preservation )

I would love to get comments from the community on this, because I truly believe that this could be a very useful model for organizations designing digitization projects. I know I'm going to prompt my institution to follow this matrix for all new digitization efforts.

Problem Statement: When an archivist deposits material in a digital archive, he or she often has assumptions that object is preserved in perpetuity, just as it would be worried a physical object. Depositors of digital material often have the same assumptions, as do institutional administrators. However, the assumptions of the software development and maintenance community do not assume permanence on the same scale in which archivists are accustomed to providing permanence. Moreover, administrators (and archivists) often have unrealistic assumptions about the labor and costs involved in daily operational maintenance to provide digital preservation, which are -- if not higher -- certainly different from the operational maintenance costs for providing physical preservation. Even worse, many digital preservation projects are funded by limited-duration soft money instead of out of an operational budget.

Or, in a nutshell, we need to remember that Digital preservation has an ongoing operational cost which cannot be provided within the archive.

Operational Preservation: To that end, I am proposing this matrix for new preservation and archival projects to see if they have thought of the requirements necessary for permanent preservation.

Anything calling itself a digital preservation project has to be prepared, in perpetuity, to provide all items down the left-hand column for all of the items in the top row. Funding is really a redundant item -- by "Labor", I mean funding for staff to provide all of the work involved, and "Physical facility" is really something which can be provided by funding -- but the fact that digital preservation requires ongoing operational money is too important to ignore. By "Bureaucratic support" I mean policies and procedures in place which support the operational business of preservation at an organizational level.

Operational Preservation Matrix
Labor Physical facility Bureaucratic support Funding
Existence of the datastream
in a file system or database
. . . .
Object access via handle/doi/uri . . . .
Maintenance, repair, and upgrade
of hardware (server, disk, etc.)
. . . .
Maintenance, patching, and upgrade
operating system
. . . .
(The following tasks are not as
essential, but still very important)
. . . .
Rolling forward file formats . . . .
Transferring data to more modern
repository and software tools when appropriate
. . . .
Modernizing user interface as appropriate . . . .


(Of course, traditional preservation of physical objects is also an ongoing operational cost. Physical objects require extensive physical facilities with narrow environmental limitations, they require re-housing and repair, they require maintenance and supervision. But these ongoing operational tasks can be performed by archivists with traditional skills. The technological operational tasks of a digital archive often can't be performed even by technologically-trained archivists, because the institution will have specific requirements about who is able to, say, maintain the network.)
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
I've been getting increasingly concerned about what I see as a too-shallow view of sustainability in digital preservation. There's been a lot of lip service paid over the last few years to preservation, and I have certainly heard talks by grant-funding agencies in which they explained that they are now only funding grants which have sustainability written into the grant structure. Yet time and time again, I see soft money being awarded to projects for which the project administrators clearly have only the vaguest idea of what sustainability really means in a software environment.

I don't see this as anyone's fault, mind you. Software developers and IT folks aren't used to thinking of software projects in terms of Permanence. In the traditional software world, the only way something is going to be around forever is if it's going to be used all that time -- for example, a financial application which is in constant use needs to be constantly up. But archival digital preservation has a very different sense of permanence. For us, permanence might mean that you build a digital archival collection once, don't touch its content again for 10 years, but can still discover all of its preserved content at the end of those 10 years.

Meanwhile, in Internet time, a project which has been around for two years is clearly well past its prime and ready to be retired.

Repository managers are putting all of this great work into the repository layer* of preservation: handles and DOIs, PRESERV and PRONOM, JHOVE and audit trails and the RLG checklist. But meanwhile, all of these collections of digital objects -- many of them funded by limited-duration soft money -- are running on operating systems which will need to be upgraded and patched as time passes, on hardware which will need to be upgraded and repaired as time passes, on networks which require maintenance. Software requires sustenance and maintenance, and no project which doesn't take into account that such maintenance requires skilled technical people in perpetuity can succeed as perpetual preservation. Real sustainability means commitment from and communication with the programmers and sysadmins. It requires the techies understand an archivist's notion of "permanence", and the librarians and archivists (and grant agencies) understand how that a computer needs more than electricity to keep running -- it needs regular care and feeding.

(This, by the way, is one of the reasons I'm so excited by the OTW Archive of One's Own and the Transformative Works and Cultures journal. The individuals responsible for the archive and the journal *do* have a real understanding of and commitment to permanence down to the hardware and network provider level. Admittedly, it's a volunteer-run, donation supported organization, so its sustainability is an open question. But it's a question the OTW Board is wholeheartedly investigating, because they understand its importance.)

*I'm somewhat tempted to make an archival model of preservation that follows the layered structue of the OSI model of network communication. Collection policy layer, Accession layer, Content layer, Descriptive Metadata layer, Preservation Metadata layer, Application Layer, Operating System layer, Hardware layer. Then you could make sure any new preservation project has all of those checkboxes ticked. Sort of an uber-simplification of the RLG Checklist, in a nice, nerd-friendly format.
deborah: the Library of Congress cataloging numbers for children's literature, technology, and library science (Default)
I'd forgotten how much I completely hate doing systems administration-type things by voice. Basically I'm spelling in the alpha-bravo alphabet at extremely high speeds, and anytime I want to say anything lengthy it's easiest to do it in a dictation box or DragonPad window because correction hasn't worked in xterm for several versions of NaturallySpeaking. And, as I remember from the last time I went through this, it's my hands which know how to do programming and system administration, and all of those pathways are burned from brain directly to fingers. My mouth doesn't know how to do these things. Is this what it feels like, at a certain level, to be split brain? Honestly, put a keyboard in front of me and a heavy dose of painkillers and I can program adequately and administer systems with the best of them, but make my voice be the interface and suddenly I'm stupid, I've forgotten everything. And my brain is just incredibly, strangely tired, like I've just run a marathon and my brain did all the work.

In any case, I finally have a default installation of DSpace up and running, so that's something that will be fun to play with. What should I put in it? Just copies of the same files and metadata we currently have in our existing repository (which is Ex Libris Digitool)? Arguably that would be the best first test (not only of DSpace, but of Digitool's ability to export in standard formats).

<violin class="world's smallest">

You know, I don't regret being a librarian. Hell, I love being a librarian, and I know I would've never come to this if I hadn't hurt my hands. But it's really so frustrating to know that there was something I was once very good at and now I just can neither do it well nor enjoy the process of relearning.

</violin>
Page generated Apr. 28th, 2017 04:30 am
Powered by Dreamwidth Studios