Notes from day 2 of Code4lib BC talks. Continue reading “Code4libBC Day 2: Lightning Talks Notes”
Notes from the first day of lightning talk presentations at Code4lib BC. Continue reading “Code4libBC Day 1: Lightning Talk Notes”
As part of an introduction to the fifth annual Code4libBC unconference, I did a brief talk on the history and community of Code4lib and Code4lib BC. Continue reading “Code4libBC Lightning Talk: Code4lib(BC): What It’s All About”
This was originally published in the November 2015 issue of the BCLA Perspectives newsletter. The original article was meant to be a short published piece in order to encourage more attendance and participation in the next Code4LibBC unconference. Continue reading “Code4Lib is for you, for me, for everyone”
I taught a workshop last week on doing usability on a budget. Usability is such a big topic that it’s impossible to cover everything in just 3 hours, but it’s a quick overview of how to put some of these methods into practice in a low cost, low resource way.
These are the notes I have along with all the links and such. Continue reading “Code4LibBC Workshop: Usability On a Budget”
I’ve had some people ask to see my application since I was a recipient for one of the 2012 Code4Lib diversity and minority scholarships mostly just to see what kind of information they might include since the application requirements are fairly open. Continue reading “Code4Lib 2012 Gender Diversity and Minority Scholarship Application”
For this presentation, I decided to speak more broadly on accessibility (rather than focus specifically on web accessibility), partly because it’s so short (5-10 minute lightning talk) and partly due to the fact that despite it being a “Code4Lib” regional, we wanted to promote cross collaboration across all skill and knowledge levels. I still used a technology example, but had physical space related examples as well. Continue reading “Code4LibBC: Shifting Perspectives: From Disability Accommodation to Universal Design”
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.