Library Hat Rotating Header Image

Continuing Education

Tips for Everyone Doing the #codeyear

Jan 30th, 2012
by Bohyun (Library Hat).
2 comments

***   This post has been originally posted to the ACRL TechConnect blog.  ***

Learn to Code in 2012!

If you are a librarian interested in learning how to code, 2012 is a perfect year for you to start the project. Thanks to CodeAcademy (http://codeacademy.com), free JavaScript lessons are provided every week at http://codeyear.com/. The lessons are interactive and geared towards beginners. So even if you do not have any previous experience in programming, you will be able to pick up the new skill soon enough as long as you are patient and willing to spend time on mastering each lesson every week.

A great thing about this learn-how-to-program project, called #codeyear in Twitter (#libcodeyear and #catcode in the library-land) is that there are +375,443 people (and counting up) out there who are doing exactly the same lessons as you are. The greatest thing about this #libcodeyear / #catcode project is that librarians have organized themselves around this project for the collective learning experience.  How librarian-like, don’t you think?

Now, if you are ready to dive in, here are some useful resources.  And after these Resources, I will tell you a little bit more about how to best ask help about your codes when they are not working for you.

Resources for Collective Learning

Syntax Error: Catch the most frustrating bugs!

Now what I really like about #codeyear lessons so far is that some of the lessons trip you by trivial things like a typo! So you need to find a typo and fix it to pass a certain lesson. Now you may ask “How the hell does fixing a typo count as a programming lesson?”

Let me tell you. Finding a typo is no triviality in coding. Catching a similar syntax error will save you from the most frustrating experience in coding.

The examples of seemingly innocuous syntax errors are:

  • var myFunction = funtction (){blah, blah, blah … };
  • var myNewFunction = function (]{blah, blah, blah … };
  • for(i=0,  i<10, i++;)
  • var substr=’Hello World’; alert(subst);
  • –//This is my first JavaScript

Can you figure out why these lines would not work?  Give it a try! You won’t be sorry. Post your answers in the comments section.

How to Ask Help about Your Codes      

by Matteo De Felice in Flickr (http://farm4.staticflickr.com/3577/3502347936_43b5e2a886.jpg)

I am assuming that as #codeyear, #catcode, #libcodeyear project progresses, more people are going to ask questions about problems that stump them. Some lessons already have Q&A in the CodeAcademy site. So check those out. Reading through others’ questions will give valuable insight to how codes work and where they can easily trip you.

That having been said, you may want to ask questions to the places mentioned in the Resources section above. If you do, it’s a good idea to follow some rules. This will make your question more likely to be looked at by others and way more likely to be answered correctly.

  • Before asking a question, try to research yourself. Google the question, check out the Q&A section in the CodeAcademy website, check out other online tutorials about JS (see below for some of the recommended ones).
  • If this fails, do the following:
    • Specify your problem clearly.
      (Don’t say things like “I don’t get lesson 3.5.” or “JavaScript function is too hard” unless the purpose is just to rant.)
    • Provide your codes with any parts/details that are related to the lines with a problem.
      (Bear in mind that you might think there is a problem in line 10 but the problem may lie in line 1, which you are not looking.) Highlight/color code the line you are having a problem. Make it easy for others to immediately see the problematic part.
    • Describe what you have done to troubleshoot this (even if it didn’t work.)
      : This helps the possible commenter to know what your reasoning is behind your codes and what solutions you have already tried, thereby saving their time. So this will make it more likely that someone will actually help you. To believe it or not, what seems completely obvious and clear to you can be completely alien and unfathomable to others.

Some JavaScript Resources

There are many resources that will facilitate your learning JavaScript. In addition to the lessons provided by CodeAcademy, you may also find these other tutorials helpful to get a quick overview of JavaScript syntax, usage, functions, etc. From my experience, I know that I get a better understanding when I review the same subject from more than one resource.

If you have other favorite Javascript please share in the comment section.

ACRL TechConnect blog will continue to cover #libcodeyear / #catcode related topics throughout the year!  The post up next will tell you all about some of the excuses people deploy to postpone learning how to code and what might break the mental blockage!

Magic is more in your staff than in technologies

Sep 13th, 2009
by Bohyun (Library Hat).
Comments are off for this post

Roy Tennant recently posted “The Top Ten Things Library Administrators Should Know About Technology” in TechEssence blog. Among the ten things, what I like most is No. 4: “Maximize the effectiveness of your most costly technology investment — your people.”  In the other post, “Your ideas for “Top Ten Things“” a similar suggestion appears: “Allow your staff time and resources to experiment – even if nothing comes of it. Innovation comes with risks.”

I wholeheartedly agree with these as a solo web services librarian. One of the challenges for solo web-services librarians is the scarcity of R&D time. It may be true that technologies are getting easier and cheaper all the time. But that doesn’t mean that there will be less things that the staff should learn and experiment with every day. Actually, more technologies usually require more human efforts for maintenance.

As a librarian who work in e-resources management (ERM), I am often surprised by the fact that most people are simply unaware of how much maintenance is required to make those electronic resources to be accessible by one-click as many library users expect. There is no magic in online resources that would make accessing them more easy and efforless than in print resources. There are systems to be configured, maintained, and updated on a daily basis, and there are people who are configuring, maintaining, updaing those systems every day. If a library user is clicking one link and is taken to the full-text page of an article immediately, that means that a lot of people spent a lot of time on making that happen wihtout an error. Technologies do not necessarily cut down on the work that the library staff have to do in order make those technologies work as expected. Many users take it for granted that links in OPAC records work. But they rarely think about how many times catalogers have been updating those links over and over again in order to keep them up-to-date.

In a similar way, technology librarians have the burden of learning new technologies, deciding on whether they would be a good fit for a given organization, implementing them the way they would get widely adopted, tweaking them in the way that they would fit better with either users or staff’s workflows, and supporting and maintaining them so that they would continue to be tools that boost productivity. Even if it were true that technologies get cheaper and easier all the time, it isn’t true that technologies simply work and work better and better all the time.

Most solo web services librarians know too well that they have to continuously train themselves and learn new things. But not often are they given sufficient time to do so. And that is because there are many more urgent day-to-day tasks to be taken care of.  It is important to complete those tasks in a timely manner. However, without sufficient time for R&D, learn, and experiment, technology librarians are likely to be either burned out or become less effective. On the other hand, they are likely to blossom when encouraged to experiment and take initiatives in new technologies. After all, they are the ones who love to work with technologies and want to show how those technologies can improve everyday work.

Imagine a library that can afford best technologies all the time regardless of costs. Still, that library won’t be the best unless it has techie librarian staff who would work on how to make those technologies fit and work in the way that would best benefit library users and staff. One can buy technologies any time, but dedicated and knowledgeable staff cannot be established in a day. The magic is in staff, more than in technologies.