This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Structuring the Active Record Query Guide #51262
Comments
Hi great initiative, about the:
|
I would ask who's target audience. Are we trying to improve documentation for the beginners or advanced users? |
That's a great question @biske. These guides are meant to be more for beginners/mid-level. Writing aimed at beginners (with more context) will not put off a more experienced developer, so essentially it will serve both audiences. It is further likely that the more advanced user would head straight to the API docs first anyway. We are hoping that beginners will come to these guides searching for an answer (and find it), but also discover a load of other possibilities on how Active Record (in this example) can be utilized. |
I don't have a strong opinion on this, but maybe it would be good to change the order of the chapters. Kind of like going up in level of complexity a little at a time and by level of importance or by the most frequent things first. For example, scopes or enums are way down and are things that are used quite a bit. Likewise, selecting specific fields, unscope, I don't feel like it's something that a beginner would use to present it so early on. I don't want it to be misunderstood in the sense that this shouldn't be. I'm just saying that maybe the order in which it's taught can be quite influential in a junior developer being able to understand things more quickly. |
I took a quick look at stackoverflow researching by the terms activerecord and ruby on rails in most frequent tab. The first question is about case-insensitive search in rails model an example of something with could more explicit in docs. https://stackoverflow.com/questions/tagged/activerecord%2bruby-on-rails?tab=Frequent I believe that stackoverflow would be useful for this kind of research. |
Hi, I love this effort! In the guide, I sometimes miss a brief mention of async queries and calculations, possibly also its strengths and limits. |
maybe a subquery section close to the join section. |
I would second the comment about changing the order of the chapters. Maybe a consistent example that progresses through the chapters would be helpful? A quick example regarding the chapters, maybe moving Some chapters could probably use some more examples and/or clarity. This is a big effort. I'm happy to help contribute. |
Hey @Ridhwana , Wow this is a long piece of (much needed) guide documentation. I have some feedback based on how I try and structure the technical copy at AppSignal. This feedback is mostly related to the structure of the copy rather than the structure of the documentation. As the guide is quite long, and this is not a PR I thought I'd put some focus here and try and keep my as feedback brief as possible. Please let me know if anything I say is unclear! 1. Explain the aim of documentation in the intro In the section 1 What is the Active Record Query Interface? I'd say there is no harm in re-asserting the aim of the document: "This guide will give you a deeper understanding of the Active Record Query Interface, introducing the core concepts and methods needed to efficiently manage Active Record queries." Of course, there is a "this guide will help you" section at the top of the page, but adding a sentence or two outlining the guide's intent will help further clarify the guide, make the focus clear, and catch the attention of people who may scroll past the bullet list at the top of the page. 2. Model introduction: Regarding the introduction to example models in the section 1 What is the Active Record Query Interface?, I would recommend putting this content in its own sub-section (ie "Example models") and having the following structure:
Also note: With domain-specific terms like 3. Descriptive tone of voice and accessible language Using the section Retrieving Objects from the Database as an example, when describing an action, I always favour a descriptive tone of voice (using the ing form of verbs). I'd also advise using more accessible language. For example, terms like "fire a query" or "Instantiate a class" may not be clear to all English speakers, we can use words like "create" and "execute" instead:
4. Describe concepts before demonstrating them It can be beneficial to quickly explain what something is before demonstrating it. For example, in the 3.4 NOT Conditions section, a short explanation could be added before the example:
Another example is with N+1 queries problem, where it may be beneficial to explain what an N+1 query is before walking a reader through an example of one. This helps keep the docs explicit and scannable and provides greater context to lesser senior developers before introducing them to code samples. 5. Lists that link When a list is listing concepts the documentation describes, make that list item link to the relevant docs section to avoid the reader having to scroll down toward it. Final tiny nit-pick: In Retrieving Multiple Objects in Batches it says "as" when I think it is meant to say "such as". |
Hi @noccor thanks for your thoughts on the structure of the copy. We were specifically posting to request information about the structure of topics, but it never hurts to hear feedback about the copy, too, or processes that other technical writers follow. @Ridhwana and @bhumi1102 have been working on updating the guides since early February (Guides that have been merged), so I think you'll be pleased to see that they follow a similar approach with their own technical writing. In particular you can see all of your advice reflected in the Active Model Basics Guide which Ridhwana recently worked on. This level of feedback would be really appreciated once the writers have edited each guide and pushed their PRs to GitHub for community review, so we would love it if you could keep an eye out for those. We have approximately 1-2 a week up for review. Thanks! |
No problem @AmandaPerino, thanks for your response. I'll keep an eye out for up-coming PRs where this feedback is more valuable/well placed. I'd say my only current structure feedback at this point is based on the order of the example models where I'd flip the ordering so the schema comes before the models. It's definitely impressive work from @Ridhwana and @bhumi1102 - look forward to following future PRs! |
@Ridhwana @AmandaPerino Excellent idea! Back in 2020, there was the May of WTFs, where a lot of great feedback was given. Some of it pertains to Active Record and documentation. https://discuss.rubyonrails.org/c/a-may-of-wtfs Do you happen to know if anyone has gone through those threads to see if any of the action items from those pertain to this project as well? |
Some added guidance on when to use each of the three condensed down in single place would be helpful. I also think Thank you for your work on this. |
I notice that neither the "Pure string conditions" section, nor the linked security guide mention Arel.sql which I believe is still the required method for more complex pure sql conditions. If this is indeed still the recommended approach, I think it deserves a mention in one of these two documents. Thanks!!! |
This issue was moved to a discussion.
You can continue the conversation there. Go to discussion →
We're currently in the process of refining our extensive Active Record Query Guide. As it stands, this guide spans almost 3,000 lines of code and comprises 22 sections, covering a comprehensive range of querying techniques.
We recognize the importance of ensuring that this guide is not only comprehensive but also well-structured for ease of understanding and navigation. To achieve this goal, we're looking for insights and feedback on the guide's structural layout.
Specifically, we're interested in hearing your thoughts on:
The text was updated successfully, but these errors were encountered: