33 Matching Annotations
  1. Aug 2023
    1. TL;DR For classic Rails apps we have a built-in scope for preloading attachments (e.g. User.with_attached_avatar) or can generate the scope ourselves knowing the way Active Storage names internal associations.GraphQL makes preloading data a little bit trickier—we don’t know beforehand which data is needed by the client and cannot just add with_attached_<smth> to every Active Record collection (‘cause that would add an additional overhead when we don’t need this data).That’s why classic preloading approaches (includes, eager_load, etc.) are not very helpful for building GraphQL APIs. Instead, most of the applications use the batch loading technique.
  2. Jul 2023
  3. Jun 2023
    1. We assume the AI will generate what a human collaborator might generate given the prompt.

      Mistaken human assumptions that AI will generate what a human would given the same prompt are reinforced by claims by those selling AI tools that such tools "understand human language." We don't actually know that AI understands, just that it provides a result that we can interpret as understanding (with the help of our cognitive biases).

      This claim to understanding is especially misleading for neural network-based AI. We don't know how neural networks think. With older Lisp based AI we could at least trace through the code to see how the AI thinks.

    2. we can improve AI interfaces by enabling conversational interactions that can let users establish common ground/shared semantics with the AI, and that provide repair mechanisms when such shared semantics are missing.

      By providing interfaces to AI tools that help us duplicate the aligning, clarifying, and iterating behaviors that we perform with human collaborators we can increase the sense that users can predict what results the AI will provide in subsequent iterations. This will remove the frustration of working with a collaborator that doesn't understand you.

    3. Collaborating with another human is better than working with generative AI in part because conversation allows us to establish common ground, build shared semantics and engage in repair strategies when something is ambiguous.

      Collaborating with humans beats collaborating with AI because we can sync up our mental models, clarify ambiguity, and iterate.

      Current AI tools are limited in the methods they make available to perform these tasks.

    4. finding effective prompts is so difficult that there are websites and forums dedicated to collecting and sharing prompts (e.g. PromptHero, Arthub.ai, Reddit/StableDiffusion). There are also marketplaces for buying and selling prompts (e.g. PromptBase). And there is a cottage industry of research papers on prompt engineering.

      Natural language alone is a poor interface for creating an effective prompt. So bad that communities and businesses are surfacing to help people create effective prompts.

    1. Writing json_populate_record in the FROM clause is good practice, since all of the extracted columns are available for use without duplicate function calls.
  4. May 2023
  5. Apr 2023
    1. Dataview query for table of incoming outgoing links

      dataview TABLE length*file.outlinks) as "Outgoing", length(file.inlinks) as "Incoming" where !contains(file.path, "Genie") and !contains(file.path,"Daily") and !contains(file.path,"Private") and !contains(file.path,"Weekly") and !contains(file.path,"FolderA") and !contains(file.path,"FolderB") and !contains(file.path,"FolderC") and !contains(file.path,"FolderD") and !contains(file.publish, "false") SORT length(file.outlinks) DESC LIMIT 50

      via timestamp 00:11:23

  6. Nov 2022
    1. Post.in_order_of(:type, %w[Draft Published Archived]).order(:created_at).pluck(:name) which generates SELECT posts.name FROM posts ORDER BY CASE posts.type WHEN 'Draft' THEN 1 WHEN 'Published' THEN 2 WHEN 'Archived' THEN 3 ELSE 4 END ASC, posts.created_at ASC
  7. Jul 2021
    1. Then in your daily note Template add a tag that flags it as a daily note somewhere (eg. “#journal”. Also add an embedded query that looks like this: ```query {{date}} -"#journal" ```

      Embeddable search queries for Obsidian

  8. Jun 2021
    1. SELECT * FROM ( -- build virtual table of all hours between -- a date range SELECT start_ts, start_ts + interval '1 hour' AS end_ts FROM generate_series( '2017-03-01'::date, '2017-03-03'::timestamp - interval '1 hour', interval '1 hour' ) AS t(start_ts) ) AS cal LEFT JOIN ( -- build virtual table of uptimes SELECT * FROM ( VALUES ('2017-03-01 01:15:00-06'::timestamp, '2017-03-01 02:15:00-06'::timestamp), ('2017-03-01 08:00:00-06', '2017-03-01 20:00:00-06'), ('2017-03-02 19:00:00-06', null) ) AS t(start_ts, end_ts) ) AS uptime ON cal.end_ts > uptime.start_ts AND cal.start_ts <= coalesce(uptime.end_ts, current_timestamp)
  9. May 2021
  10. Feb 2021
  11. Oct 2020
  12. Jun 2020
    1. If those comments are loaded outside of the blog_post association, then attempting to reference the blog_post association from within each comment will result in N blog_posts table queries even if they all belong to the same BlogPost!
  13. Apr 2020
    1. Joins are not expensive. Who said it to you? As basically the whole concept of relational databases revolve around joins (from a practical point of view), these product are very good at joining. The normal way of thinking is starting with properly normalized structures and going into fancy denormalizations and similar stuff when the performance really needs it on the reading side. JSON(B) and hstore (and EAV) are good for data with unknown structure.
  14. Mar 2020
  15. Jan 2020
    1. The SELECT part should not contain any columns not referenced in GROUP BY clause, unless it is wrapped with an aggregate function.
    1. Which to use? ANY is a later, more versatile addition, it can be combined with any binary operator returning a boolean value. IN burns down to a special case of ANY. In fact, its second form is rewritten internally: IN is rewritten with = ANY NOT IN is rewritten with <> ALL
  16. Aug 2016