Code4Lib Virtual Lightning Talks: Notes

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
  • Slides

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!

Code4Lib Day 3: Morning Notes

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

Readable Code

  • follow conventions
  • meaningful names: variable, method, class, file
  • small, single purpose methods

Cleverness that reduces readability isn’t clever.

Sources

  • 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

Presentation Slides

DIY History

  • 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

Full Write Up by Bess herself

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

Building Code

  • 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

Hacker Epistemology

  • 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!

The End

And that’s it! Until 2014.

nuzzling red pandas
Feel the Love. Happy Valentine’s Day

code4lib Cool Tool Day

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

soapUI

  • 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

Trello

  • virtual card based whiteboard
  • flexible for planning based
  • collaborative
  • great usability/UI
  • even has mobile apps

Mustache Templates

  • 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

ShowOff

  • cross platform presentation
  • push from laptop to another computer

Sidenote: Other Presentation Tools

Presented by @ruebot

VIM Plugins

  • 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!

FlickrFindr

  • easy inline flickr search of CC images
  • attribution in alt text

Presented by me

F.lux

  • 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.

Code4lib Day 1: Keynote on Code4libcon

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

things fall apart.

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
  • participatory
  • social
  • beer
  • fun

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.

Challenges

  • break complacency
  • lack of proposals to host
  • too heavy a burden on local organizers

Possible Solutions

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?