Subject: [CODE4LIB] Long way to be a good coder in library

From: Wayne Lam <[email-masked]>
Date: Wed, 22 Jul 2009 11:14:47 +0800

Hi all,

  I am new in here and i am currently worked in the library too.
I am always confused that when i read the post in here, there are always
something i don't understand
and there are so much to learn.
  So, the question is, hows everybody learns to be a good coder for
libraries, what s the secret and what
kind of technology are most important to learn?

thanks

Wayne

---

From: Mike Taylor <[email-masked]>
Date: Wed, 22 Jul 2009 08:42:15 +0000

> kind of technology are most important to learn?

Hi, Wayne, welcome aboard.  I do sympathise -- sometimes it seems that
there is just an amazing amount to learn, and even having been working
in library programming for well over a decade I am always coming
across concepts that are new to me.  I'm afraid there is no secret or
short cut -- you just have to gradually assimilate the many concepts
as you go along.  Don't worry, it DOES start to feel less intimidating
fairly quickly.

If you want a crib-sheet that will explain a lot of the common
acronyms and terms related to XML, then might find this page useful:
http://www.miketaylor.org.uk/tech/xml.html

---

From: Stuart Yeates <[email-masked]>
Date: Wed, 22 Jul 2009 21:35:51 +1200

> kind of technology are most important to learn?

Two pieces of advice: 

(1) Avoid books that we 'dumbed down' ("X in 21 days", "Y for dummies", etc) because they tend to be full of details. These are exactly the details that change completely three years when we move from ILS A to ILS B, from language C to language D or from data format E to data format F. They're also exactly the kind of details that can be found on the web (assuming an open and non-proprietary system / language / data format). Abstract learning transcends these details and make your skills transferable. If you are in an academic library, I suggest that you try and sit in on the most abstract / formal computer science source course offered at first year level.

As for which specific technology: the one with the best motivating examples in your daily job. Motivation is key to learning and if it's job-related your colleagues will be more supportive and helpful.
  
(2) Learn how to ask questions. http://catb.org/~esr/faqs/smart-questions.html is an excellent place to start.

cheers
stuart

---

From: Francis Kayiwa <[email-masked]>
Date: Wed, 22 Jul 2009 06:47:58 -0500

> kind of technology are most important to learn?

Find problems that interest you and go about trying to solve them. Ideally the problems should be of interest to the person who does your annual evaluation.

This means the most important technology (sic) to learn is one that interests you and this is hardly EVER static. I would argue that a decade ago I could get by with knowledge of C. I think development today requires basic knowledge of more languages. 

cheers,
./fxk

---

From: Eric Lease Morgan <[email-masked]>
Date: Wed, 22 Jul 2009 08:10:01 -0400

On Jul 21, 2009, at 11:14 PM, Wayne Lam wrote:

> I am new in here and i am currently worked in the library too. I
> am always confused that when i read the post in here, there are
> always something i don't understand and there are so much to
> learn.
>
> libraries, what s the secret and what kind of technology are most
> important to learn?

Welcome, Wayne.

I believe the path to success in this area is not unlike the path to  
success in other endeavors. It requires a combination of self- 
motivation and practice; Stuart and Mike have provided good starting  
points. Read lots of books, and ask lots of questions. "Well-worded  
questions get responses." The practical nature of computer programming  
hits home when you choose problems to solve that are closer to your  
soul. Personally, I took three "semesters" of BASIC but nothing sunk  
in until I wanted to figure out: 1) how much money was I earning as a  
taxi driver, and 2) where Mars will be on a given day.

The process requires practice, and practice requires time. It is not  
going to work the first time. There will be the syntax hurdle. "Did  
you forget to put the semicolon at the end of your line?" But the  
harder part will be the logic. If this, then that. Do while such and  
such condition is true. Then of course there are the data structures.  
Arrays. Hashes. Hashes within arrays. Arrays within hashes. Accessing  
relational databases. Creating and searching indexes.

Begin at the command line. No graphical interface. Write the  
archetypical "Hello, World!" program. Output the result to the screen.  
Enhance the program so it outputs a simple letter to your Congressman.  
Modify the program so it outputs the letter to a file. Enhance it  
again so it reads the letter from the file system, changes the content  
in some way and saves the result. Enhance it again so the program  
takes input from the command line and outputs difference letters  
accordingly. Output letters as valid XHTML. Save many letters. Use an  
indexer (like swish-e) to make your letters searchable. Write a  
program that... searches your letters. Acquire a batch of MARC  
records. Parse out things like authors and titles from the records and  
indexes them. Write an OPAC. Move to a graphical interface by  
implementing all your scripts as CGI scripts. Identify a problem you  
want to solve -- "an itch you need to scratch". Write a program that  
solves the problem, and when you get this far you I think you are well  
on your way to calling yourself a programmer.

A couple of years ago I wrote a set of tutorials to address just this  
issue. Hmm... I wonder where they are?

-- 
Eric "Off To Search His Archive" Morgan
Head, Digital Access and Information Architecture Department
Hesburgh Libraries, University of Notre Dame

(574) 631-8604

---

From: Jon Gorman <[email-masked]>
Date: Wed, 22 Jul 2009 07:54:53 -0500

> kind of technology are most important to learn?

Hi Wayne,

There's lots of projects out there in library land and I feel like I
rarely know as much about all the projects and technologies as I would
like.

That being said, what is your background as far as programming and
computing in general?  Also, do you prefer to learn from classes,
working with one or two people, or are you a solitary learner?  I
guess for now I'm going to assume you're working in a library and want
to learn how to be a programmer.

If you're really interested in programming and you are very new to the
field, I'd say the best thing would be to take some basic computer
science classes like systems architecture, algorithms, programming
101, database 101, and a software engineering course.  Whenever you
get an assignment where you can chose what to do, do a problem related
to libraries.  Programming a lot will get you comfortable with
programming, learning more about how everything works and looking at
other people's work should make you a better programmer.  As far as
languages, I'd probably lean towards ruby or python for starters or
maybe Java.  Then move into php after you have a grasp of good
programming practice.  You'll also figure out more what you like to
work on.

One issue is with most college-level cs courses is that they teach
theory but they're not going to teach the tools that will be really
useful to learn for day-to-day programming and practice.  Start
playing around with different Integrated Development Environments
(IDEs).  Maybe try to install something like Gforge onto a spare
machine.  Get into the habit of using a version control system like
svn or git.  I have a tendency to recommend having a linux computer to
learn programming on, although windows/microsoft have become better
again about providing tools for the learning programmer.   Get
comfortable using the command line, there's plenty of documentation
out there now.

If you already have the computer background but are more curious in
library software, that's a whole other set of answers ;).

Jon Gorman

---

From: John Fereira <[email-masked]>
Date: Wed, 22 Jul 2009 09:11:56 -0400

Some good answers so far...

First, regarding books.  While the suggestion of avoiding "dumbed 
downed" books has some merit it is worth noting the distinction between 
books that are primarily used for reference and books that are more 
about theory.  I haven't fund much use for "reference" books so much as 
usually the same material can be found online and kept more up to date.  
However, theory books on algorithms and software design can provide a 
good background on how,  in general, to write good code. 

One of the best ways to learn how to write good code is to learn by 
example, and one of the best ways to do that is to surround yourself by 
others that write good code.   Find an area of interest, then look for a 
good community open source project, then join their mailing lists, and 
become involved with the community.  While you probably wouldn't be 
making too many contributions to the Drupal core, there is a lot that 
can be learned by following the Drupal development community to observe 
coding best practices,  software design and patterns that experienced 
coders use.  Drupal is just an example here. 

IMHO,  a good software application/system begins with a good 
architecture, and a good  architecture makes it much easier to write 
good code.

---

From: Mike Taylor <[email-masked]>
Date: Wed, 22 Jul 2009 13:22:43 +0000

2009/7/22 John Fereira <[email-masked]>:
> First, regarding books.  While the suggestion of avoiding "dumbed downed"
> books has some merit it is worth noting the distinction between books that
> are primarily used for reference and books that are more about theory.  I
> haven't fund much use for "reference" books so much as usually the same
> material can be found online and kept more up to date.  However, theory
> books on algorithms and software design can provide a good background on
> how,  in general, to write good code.

Very true.  And the paradoxical upshot is that these days, some of the
best books on programming are old ones, which a few years back would
have been thought of as outdated.

In particularly, I can't speak highly enough of Jon Bentley's classic
_Programming Pearls_ (originally 1986, second ed. 1999), which is
chatty and anecdotal yet rigorous, and will help you to _think_ like a
programmer, as opposed to merely accumulating techniques.

Maybe even better is Kernighan and Plauger's tour de force _Software
Tools_ (1976!)  In 320 pages, they start by developing a program to
copy its input to its output, and end up by showing you how to design
and build a macro processor and programming-language pre-processor --
covering sorting, pattern matching and a hundred other topics along
the way.  I know of no other book that goes from 0 to 60 so rapidly,
readably and painlessly.  The language that the tools are written in
(RATFOR) is hopelessly outdated now, but the princples are timeless.

These are books that I have come back to time and time again.  They
contain treasures worth a hundred time more than whatever currently
trendy Design Pattern is being pushed by this month's hot book.

Hope this helps.

---

From: Jacob <[email-masked]>
Date: Wed, 22 Jul 2009 16:05:32 +0200

On Wed, Jul 22, 2009 at 3:22 PM, Mike Taylor<[email-masked]> wrote:
> have been thought of as outdated

Indeed, there are timeless masterpieces like the "C programming
language". Good programming language books usually follow a
step-by-step approach - they introduce a couple of fundamental ideas
and basic elements and give an example of a real-life (or close)
problem that gets solved by that. E.g. in TCPL right after presenting
the basic C syntax there is a naive implementation of standard Unix
"wc" to illustrate that. The book does not get anywhere near pointers
before the 100th page or so. Reference-like books are not worth a
dime, they tend to be so boring that you don't go passed the first
chapter without yawning.

> trendy Design Pattern is being pushed by this month's hot book.

You surely don't mean the GoF classic here, do you? It's a must-have
for anyone doing serious OOP, be it Java/C# or C++. It's a rather
demanding lecture and one should stay away from it unless he really
feels needing it :). It's known to do more harm than good at times.
Nevertheless, It does save you from re-inventing the wheel each time
you have a particular design problem.

-- 

Cheers,
Jakub

---

From: Chris Gray <[email-masked]>
Date: Wed, 22 Jul 2009 10:18:05 -0400

I think the best advice you can take appears in an article by Peter 
Norvig: Teach Yourself Programming in Ten Years.  
<http://norvig.com/21-days.html>  This repeats the "learn by doing" and 
"do what interests you" advice others have given.  Other similar advice 
and tips can be found in How To Become A Hacker by Eric S. Raymond.  
<http://catb.org/~esr/faqs/hacker-howto.html>

If you're looking for what to learn first, know that the web is the main 
focus of libraries these days and it helps a great deal to have the 
fundamental areas down pat.  The more thoroughly you know HTML and HTTP 
the better.  People often unfortunately neglect learning HTTP and what 
goes on between the server and browser.  CSS and JavaScript are next.  
Learn best practices in each area.  A good resource for web application 
best practices is Ellliotte Rusty Harold's Refactoring HTML but it is 
not for absolute beginners.  Also look at POSH (plain old semantic HTML) 
and Microformats.

In libraries, programmers typically don't have a background in CS.  
There is no need to be ashamed about this since this is often true in 
many areas where programming is not the focus but an aid to something 
else.  Take courses in computer science only if you love computer 
science for its own sake.

The biggest problem for those of us who have learned informally is 
learning to be efficient programmers, which is something usually not 
taught to someone learning a new language.  The skills you need are 
taught by the free online course in Software Carpentry. 
<http://osl.iu.edu/~lums/swc/>  The audio of the first lecture explains 
clearly the need for these neglected skills.  
<http://osl.iu.edu/~lums/swc/mp3/intro.mp3>  Again, you're better off 
coming to this after you've learned and used a first programming language.

How do I know all this advice is good?  Because I've been meaning to 
take it myself for quite a while now! :)

Chris Gray
Library Systems
University of Waterloo

---

From: Joe Hourcle <[email-masked]>
Date: Wed, 22 Jul 2009 10:20:39 -0400

> kind of technology are most important to learn?

You learn to be a good coder in a library the same way as any other 
environment -- pay attention to the needs of the users and the demands 
made by management.  And all the while, keep up with advancements in the 
field so that you can apply the best solution to a problem.

How you balance those first two things probably depends how receptive the 
management is to ideas that they didn't come up with.  (and you can still 
pull the 'didn't you say something a while back about ...' trick so they 
can still claim credit and you can get the better solution done.)

For the keeping up with advancements, I spend a fair bit of time scanning 
headlines on various news websites, blogs and mailing lists (which was a 
bad procrastination habit even before I started working for Fark), reading 
books, the occassional side project to test out a new language, etc.

... and it's impossible to recommend any specifics without an idea of what 
your overall role and background are.  (are you a librarian who's been 
pushed into the 'systems librarian' role, or a computer science person 
who's new to libraries?  are you working on front ends, backends, systems 
administration?  On windows, unix, linx?  are you writing new software, or 
just customizing existing packages for your library?)

-Joe

---

From: Ed Summers <[email-masked]>
Date: Wed, 22 Jul 2009 10:34:55 -0400

Hi Wayne:

My advice would be to find a real, do-able, and hopefully exciting
problem where you work (or elsewhere) that can be solved with a bit of
automation. Once you've found something to work on, fish around for
the right tools(s) to solve the problem. You can use your peers in
here or elsewhere on the Intarwebs to determine what 'right tool'
could mean. There are very active communities around the most popular
software development tools that are easy to tap into via email, irc,
twitter, blogs, etc. When looking for a problem to solve, don't worry
about re-inventing the wheel. Some wheels needs to be re-invented, and
the process of re-invention can be great learning experiences.

I think finding something local to work on as an individual rather
than diving into an opensource project can prove to be more productive
-- at least initially. It lets you experiment without being afraid of
doing things "right". It's more important I think to find people (aka
stakeholders) that need something done, and who will be pleased if you
can help them do it. It's kind of a rewarding feeling, and one that
can keep you going as a software developer during bleak moments :-)

My personal favorite book about programming is The Pragmatic
Programmer [1]. I like it for the same reason that Mike suggested
Programming Pearls: it helps you think like a programmer. I like it
also because it helped me realize that software development isn't
something that happens in a theoretical, ivory tower full of books --
it's a craft that is learned by doing: making mistakes, and learning
from them ; following the advice of others, and consciously diverging
from them.

//Ed

[1] http://www.pragprog.com/titles/tpp/the-pragmatic-programmer

---

From: Mike Taylor <[email-masked]>
Date: Wed, 22 Jul 2009 14:46:28 +0000

> you have a particular design problem.

No, I didn't have the the GoF book in mind!  Maybe I should have taken
a little longer of crafting that sentence, and eliminated the
not-really-relevant reference to Patterns -- my target was really
flavour-of-the-month stuff that everyone will have forgotten in 2010.
Whatever the GoF book's faults, it has at least demonstrated
longevity.

---

From: Ross Singer <[email-masked]>
Date: Wed, 22 Jul 2009 10:46:40 -0400

On Wed, Jul 22, 2009 at 8:54 AM, Jon Gorman<[email-masked]> wrote:

> As far as

Given the plaintive tone of the original post, I disagree with this
advice.  Development is almost solely based on confidence and
experience (with the latter affecting the former and vice-versa).
"Good code" is secondary.

I would almost certainly say start out with a procedural scripting
language (or at least a procedural approach) that is more common and
Googleable (PHP immediately comes to mind).  The nice thing about
something like PHP, in my mind, is that it's incredibly easy to see
immediate results without having any real idea of what's going on
(that being said, I have _no_ idea what Wayne's background might be --
perhaps this advice is too novice).  As many others have replied, it's
so much easier to learn by solving an actual problem (rather than
following the 'pet store' example in your tutorial) and, in my mind,
PHP is the easiest way get off the ground.  Successes breed confidence
to take on bigger projects, etc.

Once you've realized that this stuff isn't rocket science, /then/
break out the theory, find a different language (perhaps more suited
to the task at hand -- or not!) and think about good code.

Rob Styles sent this to my delicious account the other day (I'm not
sure what he was trying to tell me):
http://cowboyprogramming.com/2007/01/18/the-seven-stages-of-programming/

which I think sums up the arc pretty well.

-Ross.

---

From: Ed Summers <[email-masked]>
Date: Wed, 22 Jul 2009 10:44:58 -0400

Here's another reference to add to some of the great ones so far
(hadn't seen that Norvig one before Chris!). Whatever you think about
Perl, it's hard to argue with Larry Wall's 3 great virtues of a
computer programmer:

  http://www.c2.com/cgi/wiki?LazinessImpatienceHubris

//Ed

---

From: Jacob <[email-masked]>
Date: Wed, 22 Jul 2009 17:12:14 +0200

> to take on bigger projects, etc.

Fully agree with that. Programming has to be learned incrementally, by
getting your hands dirty a little then studying the necessary theory
and repeating the cycle to tackle bigger problems. If I didn't hate
the language so much I'd vote for PHP as well:) But surely a scripting
language with a prominent Web presence, to start with. Preferably one
that is clean, minimalist and well thought through like Smalltalk :)

-- 

Cheers,
Jakub

---

From: Jon Gorman <[email-masked]>
Date: Wed, 22 Jul 2009 10:16:37 -0500

On Wed, Jul 22, 2009 at 9:46 AM, Ross Singer<[email-masked]> wrote:
> Googleable (PHP immediately comes to mind).
[snipped some more good points for brevity ;) ]

Good point.  One of my main thoughts was that ruby and python are both
"hot" languages right now and there might be a lot of tutorials and
tolerance out there now for the "hello world" type of approaches.  I
also considered for suggesting perl, but was afraid of being stoned
;).  PHP is popular and a pretty common entry language and it does
have a nice feedback loop as you pointed out.  One concern would be
that to get a handle on the web app related stuff you'll need a web
server + php.  That's been getting easier and easier to set up though.

Jon

ps As long as we're throwing out books, I like the first few chapters
of Fowler's Refactoring.  It can give a good feeling how Object
Orientated programming lends itself towards restructuring.

---

From: Joe Hourcle <[email-masked]>
Date: Wed, 22 Jul 2009 11:34:11 -0400

>>> programming practice.  You'll also figure out more what you like to

[trimmed]

> that is clean, minimalist and well thought through like Smalltalk :)

I'll agree that all of us have to go through the writing bad code before 
we really understand what's going on.  (I cringe when looking at programs 
I wrote 3 years ago, much less those I wrote 15+ years ago)

... but on the language front, I think it's pointless for any of us to 
recommend a language without understanding the environment.

If there's someone other programmer in your group, learning a language 
that they know might not give the group as a whole as many tools to 
complete tasks, but odds are, you're going to have to be maintaining each 
other's code, and you'll have someone to act as a mentor and ask questions 
of.

If you're on your own, then I'd probably look at what packages you might 
have to maintain, and what they're written in.  After that, I'd look at 
what type of programming you're doing -- if you're doing mostly systems 
work without GUIs, I'd go for perl or python, not PHP.  If you have to 
make stand-alone apps (non-web-based), possibly Java.

All languages are just tools -- there are some things that each one does 
well, and there are tasks for a given language that are just horrible to 
implement.

I'd also look for local support groups for whatever language(s) you 
choose. Search for "(language) user groups" and you'll find lists for C 
varients, PHP, Perl, ColdFusion, Java, etc.

-Joe

---

From: Jonathan Rochkind <[email-masked]>
Date: Wed, 22 Jul 2009 11:39:59 -0400

I do think that what language you choose to learn in will effect what 
you learn though. As someone else mentioned, which was a good point, 
being exposed to good code is the best thing to help you learn to write 
it.  And on that basis, PHP is maybe not a good choice, and Perl can 
be... dangerous.   Ruby or Python would be great on this front, but 
maybe not so great for your particular environment.  Java... maybe. 

But yeah, the most important thing is picking something that will work 
for the context you are in. But within that... especially for a 
beginner, I think it's easy to pick up bad habits from working with bad 
code.

Jonathan

---

From: Joe Hourcle <[email-masked]>
Date: Wed, 22 Jul 2009 11:40:21 -0400

On Wed, 22 Jul 2009, Jon Gorman wrote:

[trimmed]

> server + php.  That's been getting easier and easier to set up though.

XAMPP or any of the '*AMP' bundles make giving you a platform for PHP / 
Perl (or Python) web development completely trivial:

 	http://www.apachefriends.org/en/xampp.html
 	http://en.wikipedia.org/wiki/List_of_AMP_packages

-Joe

---

From: Joe Atzberger <[email-masked]>
Date: Wed, 22 Jul 2009 11:49:06 -0400

It's about time to make this thread a wiki post.
--Joe

---

From: Jonathan Rochkind <[email-masked]>
Date: Wed, 22 Jul 2009 12:20:48 -0400

Also note, as far as wiki posts, for those at a slightly more 
intermediate level, me and BillDueber tried starting this out, to try 
and develop some common knowledge about how to make a shared open source 
codebase that can actually be shared and not forked.

Please feel free to add to or edit it, we're hoping it will be useful.

http://wiki.code4lib.org/index.php/Category:Patterns

---

From: "Cloutman, David" <[email-masked]>
Date: Wed, 22 Jul 2009 10:11:21 -0700

Most of the responses I've seen have focused on the raw technology. For
a different perspective, I'm going to assume that you know how to
program, and do it well, and that you are looking for advise with
regards to working in a library. Here's my take:

1. Learn about your organization. Figure out what makes it tick. Every
library is unique, and libraries are a unique type of organization. Make
an effort to understand the values and theory of librarianship.
Librarians love to talk about this, so don't be afraid to ask. 

2. Don't forget to look at trends outside of "Libraryland". A lot of
professional library discussion takes place in an echo chamber, and bad
ideas often get repeated and gain credibility as a result. Librarians
usually overstate the uniqueness of their organizations and professions.
When the question, "What are other libraries doing?" arises in
addressing a technical problem, don't be afraid to generalize the
question to other types of organizations. Too often, the answer to the
question, "What are other libraries doing?" is "Failing." Emulate for
the sake of success, not conformity.

3. Do your best to control your situation. Most likely, you will be
managed by committee. Most likely, you will not have a competent project
manager. Learn to gather your own requirements, develop your own project
plans, set reasonable expectations with your users, set and meet
obtainable deadlines, and stop scope creep dead in its tracks. Once
you've mastered that, tell us how you did it. Most of us work under very
difficult organizational pressures.

4. Be suspicious of extraordinary claims by library vendors. More often
than not they will "cluck defiance".

5. Follow standards to the best of your ability.

6. Innovate. Be creative. Find new solutions to old problems. Remember
why you became a programmer. Expect resistance. Ignore bad advice.

Best of luck in your endeavors.

- David

---
David Cloutman <[email-masked]>
Electronic Services Librarian
Marin County Free Library 

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of
Wayne Lam
Sent: Tuesday, July 21, 2009 8:15 PM
To: [email-masked]
Subject: [CODE4LIB] Long way to be a good coder in library

Hi all,

thanks

Wayne

Email Disclaimer: http://www.co.marin.ca.us/nav/misc/EmailDisclaimer.cfm

---

From: Wayne Lam <[email-masked]>
Date: Thu, 23 Jul 2009 01:18:43 +0800

Thank you so much for all the reply.
Maybe i should say something about my background first.
I was a business (information system) (a half computer, half business
degree) student but i work in IT industry for more than 5 years (mainly web
development),
I learnt some basic language by that time (outdated already) and i did pick
up some new technology thanks to google.
I know some of the programming/scripting language mostly web-based (PHP,
ASP, Java, javascript ,etc) but not in a very "high level". (Like i can read
and write some code from opensource project to fit my needs, create some
little programme using OO approach).

The reason of my question is i feel that coding in library is very
complicated and advanced. For example, there are both traditional technology
like MARC and Z39.5 and developing technology like Semantic web, RDF. And
there are traditional properitary ILS, opensource ILS and some very nice
discovery tools like VuFind and also some Institute Repository software. All
these very board and wide variety of software, technology in it make me
don't know where to start and learn which one first over the other one.

So i start browsing on the internet about what OAI, Solr and all related
thing without a direction, reading books on what Semantic web is and
subscribe some mailing list of interesting projects. But for a newbie like
me, it was a bit like information overflow for me. There are so many
technology that are new to me and i am afraid that by the time i manage to
"know" it, that became an old-fashion already. I am wondering if there are
some way that i can learn it in a structural way.

Thanks all

Wayne

2009/7/22 Joe Atzberger <[email-masked]>

---

From: Tim Hodson <[email-masked]>
Date: Wed, 22 Jul 2009 19:31:02 +0100

Hi Wayne,

As has already been said, the best you can do is find a problem that
you will see real value in solving, and that might be a problem that
seems quite small.
The next step is to find a technology that fits the problem. i.e. is
it web based, do you need to process textual information, records in
particular formats, etc
Then you have to work out how to make that solution deployable abd supportable.
Once you have done that, you will be well on the way to knowing an
awful lot about some very specific areas of how a technology works.

That's my definition of playing :)

Tim

===================
informationtakesover.co.uk

---

From: Ed Summers <[email-masked]>
Date: Wed, 22 Jul 2009 14:50:07 -0400

> some way that i can learn it in a structural way.

The first step is admitting that you are unable to understand *all*
the crazy library technology lingo, and that library-technology
environment as a whole has become unmanageable. :-)

Seriously though, I think what David said earlier can't be over-emphasized:

"""
"""

//Ed

---

From: "Donahue, Amy (NIH/NLM) [C]" <[email-masked]>
Date: Wed, 22 Jul 2009 17:04:52 -0400

Just a quick thank you to everyone who contributed to this discussion.  I've been a lurker for I think a couple years and have learned tons just being on the list and trying to absorb what I can without having any real coding experience (anyone ever hear of Dr. Scheme?  That's the language I used in Comp Sci 101, but I'll agree that what little theory I had there was INVALUABLE).  But the thought had somehow never entered into my head to just ask for a good starting point.  So extra thanks to Wayne for getting the ball rolling, and I'll second the call for a wiki thread... 

And, for what it's worth, I'm working on wrapping up an "environmental scan" of discovery interfaces for NLM (part of my fellowship year) and an awful lot of stuff I saw on this list (and NGC4LIB) informed it.  You can see the slides on Slideshare here: 

http://www.slideshare.net/ultimatelibrarian/discovery-interfaces-the-next-generation

(The one specific example I can think of right now being Jonathon's FindIt, which is linked to on slide 15...oh, and the Brooklyn Museum API...)
 
So, thanks!  And maybe one day I'll be able to contribute.

Sincerely,
Amy Donahue, MLIS
Associate Fellow
National Library of Medicine
Bldg 38 Rm 2N-05A MSC 3818
(301) 594-7527
[email-masked]

-----Original Message-----
From: Code for Libraries [mailto:[email-masked]] On Behalf Of Ed Summers
Sent: Wednesday, July 22, 2009 2:50 PM
To: [email-masked]
Subject: Re: [CODE4LIB] Long way to be a good coder in library

"""

//Ed

---

From: Ryan Eby <[email-masked]>
Date: Wed, 22 Jul 2009 22:20:36 -0400

There is a lot to learn but as like any noise filled room you'll probably
just need to learn to filter out the conversations/technologies that you're
not interested in/don't apply. I agree with most if not all i've read in
this conversation, especially with what edsu and david c. had to say.
Technologies aside I think what you'll find is that everyone in code4lib is
solving a problem for their area and all of them have problems they have yet
to get to, many of which may or may not be applicable to your situation. I
think the key is identifying what you see as the problems facing your
library or worklife. With that you'll come across the many technologies that
might assist you, and with them, the others in the group grappling the same
problems (the big win imho). I think the diversity of code4lib is one of its
strong assets and even if you have a very niche issue you're trying to think
about, there are no shortage of opinions or bastards.

If you're ever unsure whether something is worth your time I have no doubt
someone will answer the call of "why should i care about X". Even if you
don't learn everything mentioned you'll still be short on time to learn what
you want to.

eby

---

From: Till Kinstler <[email-masked]>
Date: Thu, 23 Jul 2009 09:55:15 +0200

> environment as a whole has become unmanageable. :-)

[evil grin]

> 2. Don't forget to look at trends outside of "Libraryland". 

I think that's really an important point. But I think you won't reach 
that point until you have gone through all this library technology 
madness (I think a lot here have, haven't you?).
It's not only the "big trends" that libraries tend to interpret their 
own way: I spent a lot of effort in learning a crude "kind of 
programming language" used in a library metasearch engine (maybe 20 
poeple in the world have some grasp of that "broker programming 
language" or "Robol" or whatever it is called, it even doesn't have a 
real name!). Totally worthless knowledge... The same could have been 
done with some lines of PHP, Java or whatever, but of course, libraries 
are special and need special solutions :-). Same with data conversion: 
For things that could be easily done using some regular expressions, 
Perl, XSLT, even sed or whatever usual text processing tool you like, we 
use a product specific (again crude) "kind of programming language" 
(nowhere clearly defined or documented, of course). Our whole business 
depends on putting lots of effort into pretty worthless technology 
knowledge...
And there are still people in the library scene, that dogmatically tell 
you reasons why you can't handle holy bibliographic library records in 
"vulgar full text search engines" like Solr... So the question is: Who 
has to learn?

Till

---

From: Walter Lewis <[email-masked]>
Date: Thu, 23 Jul 2009 19:29:28 -0400

>> environment as a whole has become unmanageable. :-)
If all else fails, as a noise filter, you could also do worse than to 
track the technologies that Ed Summers is interested in, or has 
contributed to ...

Walter Lewis
    part time edsu groupie