Alex,
I'm with you on this one. I think it's far more important to delve into
the technology in a more general sense, to be able to work WITH
programmers, than it is to be able to program. I would suggest that a
person with cataloging background would be far better off learning data
management technologies, RDF, vocabulary management (SKOS, for
instance), and the many other things that will be driving our future,
than to dabble in programming.
All I can say is that it's worked for me ...
Diane
On 4/16/10 10:54 PM, Alexander Johannesen wrote:
> 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 Sat Apr 17 2010 - 10:13:24 EDT