lucene-solr-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky" <j...@basetechnology.com>
Subject Re: Adding pdf/word file using JSON/XML
Date Sun, 16 Jun 2013 22:05:36 GMT
Jan, you made no mention of "mastering" Solr - which was the crux of my 
comments.

I think everyone agrees that anyone can download and "use" Solr, in a basic 
sense, with minimal effort. The issue is how far the average application 
developer can get beyond "start" towards "mastery" without a detailed cheat 
sheet and eventually intensive guidance, if not outright exasperation and 
pain. How many of the many thousands of Solr deployments didn't hit some 
kind of wall where they had the impression that Solr should be able to do 
something easily and found that was not the case (multi-word synonyms come 
to mind.)

Oh, and yes, by my standards, MOST software IS "bad" and "hard to use". The 
level of training and books is certainly an indicator of the level of 
"badness". Some of Solr is indeed "not so bad" - while other parts are have 
at least some elements of "extreme badness" (NPE for a missing or invalid 
parameters is a mark of extreme badness.)

[Again, my apologies to Roland - none of these comments reflect on his 
original inquiry! Except, that Solr's divergence from a true, pure REST API 
is certainly one of the elements of its "badness". The fact that SolrCell 
does not support partial update as a true REST CRUD API should, is a good 
example of relative "badness" in Solr.]

-- Jack Krupansky

-----Original Message----- 
From: Jan Høydahl
Sent: Sunday, June 16, 2013 4:16 PM
To: solr-user@lucene.apache.org
Subject: Re: Adding pdf/word file using JSON/XML

Hi,

I've never heard the complaint that Solr is hard to use. To the contrary, 
most people I come across have downloaded Solr themselves, walked through 
the tutorial and praise the simplicity with which they can start indexing 
and searching content.

When they come to us asking for consultancy or training, they are already in 
love with the product, they use it but realize that great search is so much 
more than just getting the HTTP requests or XML right. So while any "average 
Java developer" will be able to download and use Solr within an hour or two 
(my statement - even PHP developers can do that :-) ), that's just the 
beginning of it all.

With your reasoning, all software for which training classes exist are bad 
and hard to use. Our training classes do not focus on the technology itself, 
but best practices to achieve good search user experience *using* Solr. This 
is a skill not even seasoned SQL developers have.

--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com

15. juni 2013 kl. 21:39 skrev Jack Krupansky <jack@basetechnology.com>:

> [My apologies to Roland for "hijacking" his original thread for this rant! 
> Look what you started!!]
>
> And I will stand by my statement: "Solr is too much of a beast for average 
> app developers to master."
>
> And the key word there, in case a too-casual reader missed it is 
> "master" - not "use" in the sense of hack something together or solving a 
> niche application for a typical Solr deployment, but master in the sense 
> of having a high level of confidence about the vast bulk (even if not 
> absolutely 100%) of the subject matter, Solr itself.
>
> I mean, generally, on average what percentage of Solr's many features  has 
> the average Solr app-deployer actually "mastered"?
>
> And, what I am really referring to is not what expertise the pioneers and 
> "expert" Solr solution consultants have had, but the level of expertise 
> required for those who are to come in the years ahead who simply want to 
> focus on their application without needing to become a "Solr expert" 
> first.
>
> The context of my statement was the application "devs" referenced earlier 
> in this thread who were struggling because the Solr API was not 100% pure 
> RESTful. As the respondent indicated, they were much happier to have a 
> cleaner, more RESTful API that they as app developers can deal with, so 
> that they wouldn't have to "master" all of the bizarre inconsistencies of 
> Solr itself (e.g., just the knowledge that SolrCell doesn't support 
> partial/atomic update.)
>
> And, the real focus of my statement, again in this particular context" is 
> the actual application devs, the guys focused on the actual application 
> subject matter itself, not the "Solr Experts" or "Solr solution 
> architects" who do have a lot higher mastery of Solr than the "average" 
> application devs.
>
> And if my statement were in fact false, questions such as began this 
> thread would never have come up. The level of traffic for Solr User would 
> be essentially zero if it were really true that average application 
> developers can easily "master" Solr.
>
> And there would be zero need so many of these Solr training classes if 
> Solr were so easy to "master". In fact, the very existence of so many Solr 
> training classes effectively proves my point. And that's just for "basic" 
> Solr, not any of the many esoteric points such as at the heart of this 
> particular thread (i.e., SolrCell not supporting partial/atomic update.)
>
> And, in conclusion, my real interest is in helping the many "average" 
> application developers who post inquiries on this Solr user list for the 
> simple reason that they ARE in fact "struggling" with Solr.
>
> Personally, I would suggest that a typical (average) successful deployer 
> of Solr would be more readily characterized as having "survived" the Solr 
> deployment process rather than having achieved a truly deep "mastery" of 
> Solr. They may have achieved confidence about exactly what they have 
> deployed, but do they also have great confidence that they know exactly 
> what will happen if they make slight and subtle changes or what exactly 
> the fix will be for certain runtime errors? For the "average application 
> developer" I'm talking about, not the elite expert Solr consultants.
>
> One final way of putting it. If a manager or project leader wanted to 
> staff a dev position to be "in-house Solr expert", can they just hire any 
> old average Java programmer with no Solr experience and expect that he 
> will rapidly "master" Solr?
>
> I mean, why would so many recruiters be looking for a "Solr expert" or 
> engaging the services of Solr sonsultancies if mastery of Solr by "average 
> application developers" was a reality?!
>
> [I want to hear Otis' take on this!]
>
> -- Jack Krupansky
>
> -----Original Message----- From: Grant Ingersoll
> Sent: Saturday, June 15, 2013 1:47 PM
> To: solr-user@lucene.apache.org
> Subject: Re: Adding pdf/word file using JSON/XML
>
>
> On Jun 15, 2013, at 12:54 PM, Alexandre Rafalovitch <arafalov@gmail.com> 
> wrote:
>
>> On Sat, Jun 15, 2013 at 10:35 AM, Grant Ingersoll <gsingers@apache.org> 
>> wrote:
>>> That being said, it truly amazes me that people were ever able to 
>>> implement Solr, given some of the FUD in this thread.  I guess those 
>>> tens of thousands of deployments out there were all done by above 
>>> average devs...
>>
>> I would not classify the thread as FUD.
>
> I was just referring to the part about how Solr isn't something average 
> devs can do, which I think is FUD.
>
> At any rate, I think the ExtractingReqHandler could be updated to allow 
> for metadata, etc. to be passed in with the raw document itself and a 
> patch would be welcome.  It's something the literals stand in for now as a 
> lightweight proxy, but clearly there is an opportunity for more to be 
> passed in.= 


Mime
View raw message