How do you learn deeply about newer technologies that don't have a well-established book?

Question

Recently I've wanted to learn about Solr, the web front-end for Lucene. I went so far as to purchase the only existing book solely about Lucene (Lucene in Action, by Manning Press) but it barely had a word on Solr.

So there I am, trying to do a proof-of-concept implementation for a professional project, and I'm reading source-code, my eyes glazing over like a zombie. Where do I start in the source code? I feel like I'm wasting my employers time poring over line after line of code until it starts to lose its meaning.

I've had this experience before. I Google, and there's a couple of slim tutorials that say how to do the most basic possible use case, but try implementing anything real-world, and you're reading source code and API documentation (which isn't much better).

I know there's super-stud programmers out there that can scan 3000 lines of source code and understand the basic usage, but how about for regular guys like me who really like to see an example?

Answer 1

ask it at stackoverflow. ;)

but if you really can't find any information at all via google, best you can do is to read through the documentation, however painful that might be.

and try to contact the developers, and hopefully the might reply back. else i would say it's mostly via trial and error by yourself.

the only good thing about exploring totally new system like this is you might get established as one of it's expert if you really go deep enough.

else look for a popular alternative which does the same thing.

Answer 2

It really depends on how much you want to use the technology, and whether there are alternatives.

If you think it really is a good fit for your needs, but the documentation is inadequate, the best thing to do would be to get on the mailing list, ask for a bit of help - and then write documentation yourself to help the next person in your situation. If the technology is suitably important, you might even consider approaching a publisher about writing "the book that isn't there yet".

All of this only applies if you have the luxury of time, however. If you really, really need to just get the job done and the current state of documentation doesn't cut it (and the mailing list isn't helpful pretty quickly) then it's probably best to bail out almost immediately.

Answer 3

This is a skill that can be hard to learn, and doing it is never really easy. There is a book, Code Reading: the Open Source Perspective, that has a lot of good hints.

The basic triock is to think exactly about the use cases, preferably for some things you can observe easily. Figure out where the use case goes through the code, keeping notes as you go. Keep a "research notebook" in which you write down what you've seen, and record your iceas of what's going on. Some of them will be wrong, but that's okay. Keep reading the code, following scenarios, and you'll find a picture of the code will start to build up over time.