As I have recently joined the code4libBC planning group, I thought I would reflect a little on how the planning happened and worked for code4lib north even though it was a while ago. Continue reading “Planning a Regional Code4Lib: North 2013”
Terry Brady – File Analyzer and Metadata Harvester
- purpose: assemble collection of tasks into a simple user interface
- modular code: hopefully easy to add/modify
- File Analyzer: scans file system and performs actions on files, can also import file to edit records
- Want to know if looks interesting/useful
Misty De Meo – Human Rights Thesaurus: Transitioning a legacy thesaurus to SKOS/RDF
- legacy thesaurus did not do any validation of spelling, syntax, etc.
- sublime highlighting for the particular format
- ruby script to parse errors in data
- Vocabulary Management Tool: iqvoc.net
Roy Tennant – Under the Hood of Hadoop Processing at OCLC Research
For background see Adventures in Hadoop
- (the slides had a lot of the info, so I’ll try to get the link)
- can track jobs, and monitor nodes in web interface
Kate Kosturski – How I Taught Myself Drupal In a Weekend (And You Can Too!)
- Have no fear: “you can’t break Drupal”
- a lot of modules and themes to choose from, especially a WYSIWYG editor
- Quick and Dirty Solution: Drupal Gardens – can at least get you more comfortable with it
- Live site
Thanks to Peter Murray for organizing!
Hands off! Best Practices and Top Ten Lists for Code Handoffs
- Naomi Dushay, Stanford University Library
Code handoffs are never smooth. Ever.
Ratio of time spend reading vs. writing code, 10:1.
The Truck Test
- what if you were run over a truck and someone else had to take over?
- need to code so a stranger can read it and understand it
The Boy Scout Rule
- “Leave the code cleaner than you found it”
- need to maintain your code
- otherwise you’re part of the problem
It’s More Than Code
- naming should make sense: servers, scripts, everything
- config files should not point to boxes
- tools chosen can be the problem
- should you be rolling this on your own?
- probably something been done before
- some think if you write code really well, then you don’t need to comment. Not true.
- Documentation and comments are there to inform, explain, clarify, warn, need maintenance
- readme’s should make sense
- tests are code, should also think about readability of these
- failures should be addressed ASAP
- KISS – Keep It Simple Stupid
- DRY – don’t repeat yourself
- follow conventions
- meaningful names: variable, method, class, file
- small, single purpose methods
Cleverness that reduces readability isn’t clever.
- Clean Code: A Handbook of Agile Software Craftsmanship by Robert Martin
- Refactoring: Improving the Design of Existing Code by Martin Folwer et al.
The Care and Feeding of a Crowd
- Shawn Averkamp, University of Iowa
- Matthew Butler, University of Iowa
- transcribe items in collection
- omeka + scripto + mediawiki
- still in development: want to add social media aspects/integration
- err sorry, brain temporarily sort of died. See slides and I’ll go get a cookie to recharge
How to be an effective evangelist for your open source project Creating a Commons
- Bess Sadler, Stanford University Library
Lost a member of our community this year: Aaron Swartz
- helped to define Creative Commons licenses
- 3 versions: machine, human, and lawyer readable
- code4lib should do the same principle
- shared engineering practices are becoming more and more important
- investment that’s worth it
- please get code contributors to sign a contributor license agreement
- can determine whether contract allows participation
- don’t want to lose informal sharing, but law cases have happened and we need to protect ourselves
- what are we building?
- we are building a culture, a commons
- Fedora4lib – came early and rented a house together
- Hydra = a community
- cultivate a place where we can
- teaching at Ruby on Rails workshops – too big a job to leave to a small group of people
- how is knowledge acquired?
- how do we decide what’s true?
- collaboration with disregard of conventional mental thinking
Building the Community
- need to expand and include everyone who wants to join
- more steps in building a more inclusive community
- adopted a code of conduct, because it was a good idea and making an explicit statement
- need to let other people to know that we’re trying
- “We are all imposters.” – just acknowledge it, we all feel that way, but bolster ourselves
- allow ourselves to be seen even when there’s no guarantee of success
- we can support each other
- cannot be accomplished alone
- want to craft a process for submitting issues
Thank you, code4lib!
And that’s it! Until 2014.
- directory of data
- bag has what you’re bagging, data, contact email/name, organization information, profile identifier (JSON via a URI)
- pull in all the field values
- wrote a spec and send it to digital curation community
- can look up profiles in the registry
Okay, I got a little lost, but you can see more on github.
- see demo
Bookfinder – @TheRealArty & Steven
- I will write this up later probably as a separate blog post, or maybe journal article
TPL’s Web Services Architecture: Understanding the Big Picture – @waharnum
- many different systems that don’t easily communicate, which needs specialized knowledge even to do basic tasks
- address the challenges by translation, simplication, standardization
- Three tiers: Front End Systems (requests to back end) / TPL Web Services (REST) / Back End Systems (responds to front end)
- Example: TPL Website -> Account Web Services -> Symphony Web Services (Symphony) – and back
- can add new features and functions
- helps to solve the challenges mentioned
- also helps with reusability e.g. in addition to website, build mobile-friendly website, iPhone App
- Might end up with:
- Front End (Website, mobile, App)
- Middle Tier (Account Web Services, ebook Web Services, online payment web services)
- Back End (symphony, overdrive, payment gateway, accounting systems)
- other benefits:
- increase ease of knowledge transfer about how our systems work
- follow modern best practice approach to building interoperating systems
- reduce cost and integration time
- reduce learning time for new staff or consultants
- metrics: wish had resources
- bolting together a lot of things, not using a lot of custom code
Ladder (aka MyTPL 2) – @mjsuhonos
- wanted to solve problem: discovery layers suck
- not scalable
- better than open source options (VuFind, Blacklight)
- cheaper (than proprietary)
- scalable as WorldCat
- schema-free/multi-schema (e.g. Dublin Core)
- horizontally scalable (multi-node)
- modern OSS components
- simple data model (RDF)
- hierarchical relations
- real-time import & indexing
- responsive UI
- fully multilingual (18/10)
- dynamic faceting
- dynamic mapping modification
- digital content storage (coming soon)
- built on a linked data
- not a discovery layer; it’s an integration platform
- News Announcement and Promotional Video
- previously not centralized: hard drives, flickr, etc.
- need central repository for tri-campus initiative with search & discovery, preservation, long-term access to content and metadata, support for multiple formats (e.g. images, books, documents, video, exhibits)
- Drupal + Solr (search) + Fedora Commons (collection management, batch ingesting, metadata crosswalk, digital preservation) == islandora (digital asset management system)
- pilot: 8 parent collections (by format, by campus)
- exhibits in Drupal, not through islandora/fedora commons
- modules: internet archive book reader (OCR on the fly), galleria, colorbox
- official launch: 2 weeks ago
That’s it! Food and drinks time!
So inspired by the ASIS&T Cool Tool Day, I thought it’d be neat to do one of these since there weren’t many volunteers to do lightning talks/presentations at the code4lib Toronto meetup this time around. Our attendance was a little… paltry, but we had some great presentations! Here are my notes from the session.
Presented by @waharnum
- working with REST based web services
- testing automation tool for web services
- best for building with other API
- autogenerate stubs using WSDL
- interface between internal systems
- good for documenting web services, code style with examples
- normally, mostly used for unit testing
- virtual card based whiteboard
- flexible for planning based
- great usability/UI
- even has mobile apps
- maintaining HTML email templates
- also works as a crazy text editor for nerds
XSL Transforms plugin in Firefox
- local reporting
- anything XSLT with just a few security restrictions
- e.g. SVN reporting
Presented by @adr
- cross platform presentation
- push from laptop to another computer
Sidenote: Other Presentation Tools
Presented by @ruebot
- pathogen – linking for VIM plugins to automatically load VIM plugins
- nerdtree – pull files quickly by displaying directory/tree
Presented by Pomax
Thimble HTML/CSS Live Web editor
- teach anyone (kids, adults) HTML and CSS
- use existing projects to make it fun!
- easy inline flickr search of CC images
- attribution in alt text
Presented by me
- monitor hue changer, supposedly to help people sleep better by telling your body what time of day it is
That’s it! Hope to do another one of these or lightning talks next time.
Daniel Chudnov from George Washington University was the first Keynote of the conference.
Dan began with a bit of an introduction and then went into a very touching overview of the story of his family and his life. His life lesson was that
We Blew It
We have turned away too many people: way more than 100 people. That was a terrible mistake. If we don’t address this mistake, this [conference] is not going to last.
Code4lib was inspired by Access, with some key aspects:
- single track
The difference the organizers wanted was a (possibly) geekier version in the USA in Spring (so as not to compete with Access). What might have really pushed this discussion is that
we turned away more people in 2012 than attended in 2007.
Why? The most common answers revolved around the capacity of venue. There were of course, some other concerns about keeping it a small, informal, participatory conference that were expressed, especially in the backchannels (IRC and Twitter).
Nevertheless, Dan asked the key question “Why do you come?” He expressed how he comes to connect with people, and hang out with the attendees, and there are many others that wanted to join, but were turned away.
He went on to talk about how while there is a chasm of techies vs. non-techies, there shouldn’t be. Plenty of people want to learn what coders do, and as a group, we should want to help respond to change constructively. They want to code, and we should connect and work more closely with them. We have one choice to make:
HACK OR DIE
We Must Expand
Dan used PyCon as a possible a good mode to follow. They have:
- 2 days of pre-conference tutorial days
- up front training for all levels
- 4 days post-conference sprint days
- back-end collaboration for all levels
- plenary talks, plenary lightning
- multiple tracks
Dan was against multiple tracks for many years, but not anymore, because
we need to connect or this thing we have will fall out from under us.
His point is that next year people won’t even bother if there is no clear statement to make things work.
- break complacency
- lack of proposals to host
- too heavy a burden on local organizers
Committees need to be formalized, especially an advisory committee of former hosts to help future hosts. The work needs to be done through the year, and more open like it used to be. Dan also suggested a formal program committee to replace the “diebold-o-tron”, but there was some disagreement because it’s less participatory.
Some other ideas included a multi-core code4lib where each regional group would be 1 hour live streaming on the same day, and the BarCamp approach where there are no pre-planned presentations, which might work for regional code4lib conferences. However, concern was expressed with having too many small conferences organized, burning out possible hosts for the annual code4lib.
The next code4lib conference should aim for 500 people.
Chicago is ready. Are you?