Hi,
Um, well, hi there. And, uh, I was a bit hesitant in replying,
figuring I should just shut up, but unfortunately (for me) it's too
close to my heart to leave alone. But as some of you know, I can't
leave *anything* alone, especially that which I *should* leave alone.
So. Um.
First, let me restate what Tim said about catalogers; they are the
most impressive bunch of people I know, good instincts and certainly
have that programmer's mindset. They know about meta data, know about
good record-keeping skills, have learned about good backup practices,
and realizes that tools that you didn't make yourself and understand
mostly sucks. So.
Unless you know why you get into technology, don't just rush in, but
take a breath and explore *why* technology. No, there's nothing wrong
with digging into, say, programming or becoming an expert in knowledge
management systems and Wiki, but you should shape your technology path
based on what you think you might be best at. Here's why. As a
cataloger wanting to extend their skills there's nothing wrong about
pursuing technology, in fact, if you worry about the future it will
certainly make you employable outside of the library world, and that
is a good thing all in itself. But there are millions of technologists
out there already most of which are already infinitely better than you
at programming. You need to focus on what skills and knowledge you've
already got that can make you competitive in the real-world. Some
times you compete with them as they get employed at your library,
other times there might be a time when you might compete with them in
the real-world as your library gets shut down. Other times you compete
for resources for your project over others. You compete with others
ideas. You compete with others management skills, or process skills,
or whatever. We all compete. Just sayin', and reflections on this
should enter into your technology path.
Part 1 : Programming
Legend has it that programming requires a somewhat logic and / or
mathematical mind. It states further that it is just a matter of
telling the computer what it should do, and off we go, that technology
is nothing more than a reflection of humans in a logical and orderly
fashion. Needless to say, this isn't the case. Programming is a
creative process that happens to involve varying degrees of logic. If
you've only got one of those mindsets, if you're only creative or only
logical, you won't like it much.
Then the next thing to think about is where you think you want to go.
Exploring programming can be a lot of fun, and if fun is what you
want, look no further. But if you want to also become productive and
solve real problems, there's a few things that needs to be said as we
enter the world of software development which is split in three
equally sized boxes ; the Java box, the .Net box, and the misc. box.
Both Java and .Net are both frameworks which happens to have a
language (or two) in them; Java's language is also called Java, and
.Net's primary language is called C# (c sharp). They are both
object-oriented curly-bracketed in nature with a slew of APIs
(basically functions you ask the framework to do for you) you need to
know and understand to make any sense of them. The learning curve is
somewhat sloooooow because there is just so much to be learned, and
the framework is large and hard to move about. Consultants and large
companies thrive in this section.
The misc. box is everything else, including fun things.
The next thing to think about is at what level of technology are you
at now. Do you know what a browser is? Silly question, I know, but do
you *really* know what it is? Does this sound Greek to you (or
Norwegian if you're Greek or know Greek) ; it's a stateless client
application that asks a DNS server to resolve URIs, and sends (most of
the time) HTTP GET or POST requests to the resolved IP addresses, and
then render returning HTTP, HTTPS, FTP (and possibly other) responses,
or HTTP status codes
(http://en.wikipedia.org/wiki/List_of_HTTP_status_codes). Or if you
use the Opera browser, it contains a server as well, just to make life
even more interesting.
If it sounded Greek to you, working with Internet technology is going
to be hard at first. I could go on with the client - server false
dichotomy, I suppose, another chestnut of poorly understood pitfalls
and a language all in itself. Or even try to explain what a localhost
is in that soup? Do you understand IP addresses
(http://en.wikipedia.org/wiki/Internet_Protocol)? Read that page, and
if it makes your head hurt, Internet stuff in a technological sense
will only make you feel small and insignificant.
Creating programs in isolation is usually easier and mostly fun;
convert an XML to another through XSLT is fun; a JQuery demo gallery
can be fun; a Ruby internal model of a workflow can be fun; a PHP
framework for event-based and declarative programming is heaps fun!
But when you want to play with the world it becomes real complex real
fast. It will take a lot of time to get there.
Let's talk languages ;
Ruby, Python, Scala are somewhat fun but complex languages, but have
great communities. PHP is easy, and is one of the worlds most used
languages (LibraryThing uses it, for example) for its ease of
deployment. Perl is to be avoided unless you're a rock-star
programmer. Lisp is for academics. XSLT is underrated, Java is
overrated and bloated. C is for hackers, C++ is for programmers, C# is
for drones. And this is *strictly* my silly opinions that aren't true
to anyone but me. And you'll find that all programmers have differing
preferences and opinions on these matters. It is probably dangerous to
enter into a conversation about what language one should begin with,
because they *all* have their ups and downs, they all will be good or
bad for you depending on why you are, what you're like and how you
think.
I think my point so far is that if programming has slipped your mind,
then I'd warn you that that path leads to madness. Programming is not
easy. It is not always fun. Most of the time you won't even be
programming, but configuring stuff, or debugging code in trying to
find out why something doesn't work as expected.
Part 2 : Technology
Knowing glimpses of programming is fine, especially if you're managing
or dealing with programmers; You can squash any programming argument
from them through clever use of technology understanding (like "no,
the client-server paradigm is a false dichotomy") or, perhaps a better
example, guide and direct others in the right direction.
One thing I love about librarians is that they all have their pet area
of expertise. You'll be discussing some weird part of a MARC
sub-field, and you might blurt out "Who ever came up with *that*?" to
which a librarian with a fetish for MARC history pipes up the exact
person, the reasoning behind it, and all the fields affected (not to
mention that "we don't do it that way these days, anyway, this is
wrong, and this punctuation should be in this other field after the
slash instead").
Anyway, what is technology? It's just tools which these days happens
to be mostly digital. Ok, what does that mean? Well, it means that all
books will be scanned and turned into bits and bytes, and placed in
database systems that can search, retrieve and mangle them further.
That is a field worth exploring. Learn about how computers use pattern
recognition, sharpening and blurring filters, various ratio and edge
filtering, resolution scanning, zooming and sharpening techniques, all
to convert bitmaps of letters into vectors of coordinates on which the
system can match letters and words. Or learn about search and
indexing, how computers can store parts of a longer thing, use
mathematics to cluster similarities together, or MapReduce to deal
with huge amounts of data, or ... uh, a million other things involved.
Technology isn't scary, but there is one problem; it is always moving.
You can't learn one part of technology and expect to then know it. You
need to practice it, and you need to change as the technology change.
This is a challenge to a lot of people, so you might as well get it
straight away; technology never stays the same, it always move, it
shifts with human culture. The programming I knew 10 years ago is all
moot. The systems I worked on 20 years ago are all gone. Heck, the
systems I built last year is already gone. The purpose of my current
project is changing as we speak. The cultural baggage from when I
learned programming as a young lad still inhibits me today when
everything has changed. If you're a person that doesn't like change,
can I offer you a career in brick-laying instead? Because that's what
I feel like doing these days.
Anyway, I'll stop rambling now. And go and lay some bricks.
Regards,
Alex (the anti-Feist)
On Sat, Apr 17, 2010 at 11:43, Simpson, Sarah <ssimpso_at_tulsalibrary.org> wrote:
> I've spoken with many of you directly, but I just wanted everyone to know how incredibly helpful these answers are to me, wow!! Keep them coming, and thank you so much for the time you're taking to help out - I've been lurking and listening long enough to know this is the place for me, I just need to get the skills I need to contribute. Thanks again!
>
> Sarah
>
> -----Original Message-----
> From: Next generation catalogs for libraries [mailto:NGC4LIB_at_LISTSERV.ND.EDU] On Behalf Of R Kemp
> Sent: Friday, April 16, 2010 6:25 PM
> To: NGC4LIB_at_LISTSERV.ND.EDU
> Subject: Re: [NGC4LIB] What do I need to know?!
>
> Okay, here it goes - my first newbie post to a bunch of people who know a lot. My background: I am a library school student with dreams of cataloging when she finishes next semester. I have had paraprofessional experience as a copy cataloger.
>
>
>
> Sarah, I'm assuming you have the Masters degree. If so, I would recommend taking a class in XHTML. XHTML is a hypertext markup language and is the basic building block of the Internet. It will also help you - once you've finished - understand the different metadata systems out there as they are based on hypertext markup languages and (don't worry about what this means) SGML.
>
>
>
> After XHTML, look for a metadata course. Apparently there is one self-paced one at the LOC because my metadata instructor keeps referring to it!
>
>
>
> RDA is not a huge concern of mine right now as I asked my public library boss what would happen when RDA finally came out. She said "we will adopt it when the Library of Congress adopts it". In the time between now and then, look for different courses on it offered by different organizations such as ALA, etc.
>
>
>
> For database structure, have you taken any database software? I am talking as simple as MS Access to a more sophisticated program such as Oracle with SQL, etc. If you are concerned, take Access first, then start looking around.
>
>
>
> What other people have said is true also. However, this is the lowest level you can enter the places you have questions about.
>
>
>
> Rebecca
>
>> Date: Fri, 16 Apr 2010 10:02:42 -0500
>> From: ssimpso_at_TULSALIBRARY.ORG
>> Subject: [NGC4LIB] What do I need to know?!
>> To: NGC4LIB_at_LISTSERV.ND.EDU
>>
>> I have to admit, I always hesitate to post a question of this sort to a list, for a variety of reasons. However, as I try to figure out how I'm going to contribute to the cataloging world, honestly, you just seem like the best people to ask.
>>
>> I'm a very good cataloger (and modest, too, as you can tell). However, I am becoming very aware that in order to remain a good cataloger and make any forward progress, I am going to need to know other things than cataloging. Specifically, technology. I will need to learn more about the workings of our catalogs, what we know and need to tell our customers about the digital resources we have, what is necessary to share our data with the Web, and so on.
>>
>> So, where do I start? Are there particular things to learn about technology that would be the most useful, particular classes, particular topics? What software do I need to know? I want to learn what I need to know, but just have no idea where to start! I have 3 universities and a community college in my immediate area, but do I need a computer science degree, or can I be more targeted than that?
>>
>> I want to know why RDA is a good or bad idea, I want to be able to tell my library how big of a project it will be to implement, and to tell the truth, I want the background to be part of the discussion as RDA continues to be modified and improved. ANYTHING you can tell me about how to learn what I need to know and what it is I need to know will be very, very much appreciated.
>>
>> Sarah Simpson
>> Tulsa City-County Library
>
> _________________________________________________________________
> The New Busy is not the old busy. Search, chat and e-mail from your inbox.
> http://www.windowslive.com/campaign/thenewbusy?ocid=PID28326::T:WLMTAGL:ON:WL:en-US:WM_HMP:042010_3
>
--
Project Wrangler, SOA, Information Alchemist, UX, RESTafarian, Topic Maps
--- http://shelter.nu/blog/ ----------------------------------------------
------------------ http://www.google.com/profiles/alexander.johannesen ---
Received on Fri Apr 16 2010 - 22:55:19 EDT