[
https://issues.apache.org/jira/browse/SOLR-14726?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17185855#comment-17185855
]
Gus Heck edited comment on SOLR-14726 at 8/27/20, 2:00 PM:
-----------------------------------------------------------
Can we make it a goal that the user be **completely** unaware of what mode
(cloud or not) they are using in the initial contact. That's deployment stuff
and nothing they should even think about on first contact. I think they should
run "tutorial1.sh" or {{bin/solr -e tutorial1}} and then pull up a page in
their web browser to see it worked. Cloud or non-cloud can be used behind the
scenes as current or future maintainers see fit. An adapted version of my
comments on slack:
There are various things to learn about solr... I might order them thus for
what I (IMHO) consider optimal pedagogy:
# {color:#0747a6}First Contact: A cushy easy intro that stands up solr, throws
data in for them, and let's the user query it either in the UI or via curl as
suits them (different people have different styles){color}
# {color:#0747a6}Basic search concepts: inverted indexes, tokenization, a
query syntax, sort vs relevancy scoring.{color}
# {color:#0747a6}How to get data in (because without data whatever), and the
need to be able to re-index{color}
# How to deploy solr in a basically competent fashion for light duty use in
low security environments
# Features such as facets, highlighting, analysis options etc, this section
should be an a la carte menu into the ref guide, as by this point they are
becoming more advanced.
# Hardening and Scaling solr, and otherwise making it production ready
For the first 3 you really don't want the user to see any of #4 and it really
doesn't matter if it's cloud or not so long as the person trying to learn
doesn't see whichever it is. I think bin/solr -e accomplishes that with #1, and
we basically don't do a good job of teaching #3 (in the ref guide). When you
get to #4 I can't imagine which cases you would want to have them start with
non-cloud solr, though that section should have a closing section on non-cloud
and the trade-offs of using it. #5 should be a la carte anyway, and we do have
a fairly coherent section for #6
was (Author: gus_heck):
Can we make it a goal that the user be **completely** unaware of what mode
(cloud or not) they are using in the initial contact. That's deployment stuff
and nothing they should even think about on first contact. I think they should
run "tutorial1.sh" or {{bin/solr -e tutorial1}} and then pull up a page in
their web browser to see it worked. Cloud or non-cloud can be used behind the
scenes as current or future maintainers see fit. An adapted version of my
comments on slack:
There are various things to learn about solr... I might order them thus for
what I (IMHO) consider optimal pedagogy:
# {color:#0747a6}First Contact: A cushy easy intro that stands up solr, throws
data in for them, and let's the user query it either in the UI or via curl as
suits them (different people have different styles){color}
# {color:#0747a6}Basic search concepts: inverted indexes, tokenization, a
query syntax, sort vs relevancy scoring.{color}
# {color:#0747a6}How to get data in (because without data whatever), and the
need to be able to re-index{color}
# How to deploy solr in a basically competent fashion for light duty use in
low security environments
# Features such as facets, highlighting, analysis options etc, this section
should be an a la carte menu into the ref guide, as by this point they are
becoming more advanced.
# Hardening and Scaling solr, and otherwise making it production ready
For the first 3 you really don't want the user to see any of #4 and it really
doesn't matter if it's cloud or not so long as the person trying to learn
doesn't see whichever it is. I think bin/solr -e accomplishes that with #1, and
we basically don't do a good job of teaching #3 (in the ref guide). When you
get to #4 I can't imagine which cases you would want to have them start with
non-cloud solr, and have a closing section on non-cloud and the trade-offs of
using it. #5 should be a la carte anyway, and we do have a fairly coherent
section for #6
> Streamline getting started experience
> -------------------------------------
>
> Key: SOLR-14726
> URL: https://issues.apache.org/jira/browse/SOLR-14726
> Project: Solr
> Issue Type: Task
> Reporter: Ishan Chattopadhyaya
> Assignee: Alexandre Rafalovitch
> Priority: Major
> Labels: newdev
> Attachments: yasa-http.png
>
>
> The reference guide Solr tutorial is here:
> https://lucene.apache.org/solr/guide/8_6/solr-tutorial.html
> It needs to be simplified and easy to follow. Also, it should reflect our
> best practices, that should also be followed in production. I have following
> suggestions:
> # Make it less verbose. It is too long. On my laptop, it required 35 page
> downs button presses to get to the bottom of the page!
> # First step of the tutorial should be to enable security (basic auth should
> suffice).
> # {{./bin/solr start -e cloud}} <-- All references of -e should be removed.
> # All references of {{bin/solr post}} to be replaced with {{curl}}
> # Convert all {{bin/solr create}} references to curl of collection creation
> commands
> # Add docker based startup instructions.
> # Create a Jupyter Notebook version of the entire tutorial, make it so that
> it can be easily executed from Google Colaboratory. Here's an example:
> https://twitter.com/TheSearchStack/status/1289703715981496320
> # Provide downloadable Postman and Insomnia files so that the same tutorial
> can be executed from those tools. Except for starting Solr, all other steps
> should be possible to be carried out from those tools.
> # Use V2 APIs everywhere in the tutorial
> # Remove all example modes, sample data (films, tech products etc.),
> configsets from Solr's distribution (instead let the examples refer to them
> from github)
> # Remove the post tool from Solr, curl should suffice.
--
This message was sent by Atlassian Jira
(v8.3.4#803005)
---------------------------------------------------------------------
To unsubscribe, e-mail: issues-unsubscr...@lucene.apache.org
For additional commands, e-mail: issues-h...@lucene.apache.org
