DEV Community: Byron Salty

A little Rust proxy for Ollama

Byron Salty — Sun, 30 Mar 2025 23:19:18 +0000

Introduction

Recently, while exploring the new Zed IDE, I encountered a need to integrate it with a self-hosted Ollama model. Zed allows for custom LLM integrations, which is great, but I ran into a small hiccup.

Problem Description

The challenge arose because Ollama's configuration in Zed requires a connection to localhost. However, I have Ollama running on my GPU-enabled home server, not on my local machine.

Solution Approach

To bridge this gap, I devised a simple solution: a Rust script that acts as a proxy. This script forwards the Ollama port from my server to the local machine, allowing Zed to connect seamlessly.

Implementation Details

Here's a brief walkthrough of the Rust script:

use hyper::service::{make_service_fn, service_fn};
use hyper::{Body, Client, Request, Response, Server};
use std::convert::Infallible;
use std::net::SocketAddr;

async fn proxy(req: Request<Body>) -> Result<Response<Body>, hyper::Error> {
    // Create a client to send the forwarded request.
    let client = Client::new();

    // Build a new URI using the hostname "ace" and the appropriate port.
    // Here, we assume your Ollama server is also listening on port 11434.
    // Adjust the port in the format string if it's different.
    let uri_string = format!("http://ace:11434{}", req.uri());
    let new_uri = uri_string.parse().expect("Failed to parse URI");

    // Replace the URI in the incoming request with the new one.
    // This effectively "redirects" the request to your remote server.
    let mut proxied_request = req;
    *proxied_request.uri_mut() = new_uri;

    // Forward the request to the remote server.
    client.request(proxied_request).await
}

#[tokio::main]
async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {
    // Bind to local port 11434.
    let addr = SocketAddr::from(([127, 0, 0, 1], 11434));
    let make_svc = make_service_fn(|_conn| async {
        // For each connection, we create a service to handle the request.
        Ok::<_, Infallible>(service_fn(proxy))
    });

    let server = Server::bind(&addr).serve(make_svc);

    println!("Reverse proxy running on http://{}", addr);

    // Run the server until it's stopped.
    server.await?;
    Ok(())
}

The script efficiently handles the port forwarding with no noticeable performance penalty, making the integration smooth and reliable.

Conclusion

This quick Rust script solved the integration challenge, enabling me to use Zed with my self-hosted Ollama model effortlessly. It's a testament to how small, targeted scripts can effectively solve specific problems without overcomplicating the setup.

To me this is a very interesting implication of the new world of AI tooling. I just used some simple prompts and had a working solution to a problem in a few minutes. I'm sure I could have taken the time to make caddy or nginx or something else work, but custom built software for a specific need is also an option nowadays.

A Simple Test HTTP server from Flask

Byron Salty — Fri, 16 Aug 2024 04:26:33 +0000

Last night I found myself needing to update some app code to switch from a synchronous http call to an async one. This is not a particularly hard problem but it can be tricky to get correct.

What I needed therefore was a way to test these http calls, and the machine I was using didn't already have any http servers running to use as the target.

No problem: it has Python - and that's all you need.

Don't Install - Just create

This pattern has been forming for me. For simple tasks, it's often easier to just write a little utility script instead of installing some full blown software to do a job.

If you need a real server, by all means go for it (but even then I'd suggest Docker if possible). But if you just need a quick endpoint to test with or to solve a single use case then Python is probably your friend.

I'm saying Python specifically because it's rather ubiquitous with a rich standard library and ecosystem.

Server code

The idea with this simple server was to help me test the async client calls so I wanted it to wait 5 seconds and then respond. I just wanted it to respond to any standard call with a 200 after 5 seconds.

from flask import Flask, request
import time

app = Flask(__name__)

@app.route('/', defaults={'path': ''}, methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH'])
@app.route('/<path:path>', methods=['GET', 'POST', 'PUT', 'DELETE', 'PATCH'])
def catch_all(path):
    print(f"Path: {path}")
    print(f"Headers: {dict(request.headers)}")
    print(f"Params: {request.args}")
    print(f"Data: {request.data}")

    # Wait for 5 seconds
    time.sleep(5)

    return "yessir"

if __name__ == '__main__':
    app.run(host='0.0.0.0', port=5000)

Adding Embeddings to a Phoenix App

Byron Salty — Mon, 19 Feb 2024 05:35:50 +0000

Let's add OpenAI based Embeddings to a Phoenix app and store the vector in the database so we can use it for similarity searches.

This resulting code for this article is captured in this sample project:
https://github.com/byronsalty/questify

Specifically this commit:
https://github.com/byronsalty/questify/commit/cba277ce8104c6f3b29dc2a6f602158ba4d1f62a

Steps:

Add PG Vector to deps
Add a migration to install Vector db extension
Add Postgrex.Types
Configure OpenAI embedding endpoints
Hit the API endpoint
Setup your schema for vector types
Incorporate vectors into your queries

Add PG Vector to deps

In mix.exs:

      {:pgvector, "~> 0.2.0"},

Add Migration to install the vector extension

Create a migration to install the PGVector extension:

defmodule Questify.Repo.Migrations.AddPgVector do
  use Ecto.Migration

  def up do
    execute "CREATE EXTENSION IF NOT EXISTS vector"
  end

  def down do
    execute "DROP EXTENSION vector"
  end
end

Add Postgrex.Types

This is so you can use the term vector in your type definitions.

Add a file postgrex_types.ex in your /lib folder with the following contents:

Postgrex.Types.define(
  Questify.PostgrexTypes,
  [Pgvector.Extensions.Vector] ++ Ecto.Adapters.Postgres.extensions(),
  []
)

Add this to your config.exs:

config :questify, Questify.Repo, types: Questify.PostgrexTypes

Configure your app with the OpenAI endpoints

Here are the relevant lines to add to your configuration. I put this into the runtime.exs file:

openai_api_key = System.get_env("OPENAI_API_KEY") ||
  raise """
  environment variable OPENAI_API_KEY is missing
  """

config :questify, :openai,
  openai_api_key: openai_api_key,
  embedding_url: "https://api.openai.com/v1/embeddings",
  embedding_model: "text-embedding-ada-002"

Hit the API

The embedding API will simply take in a text string and will return a JSON response with the embedding information.

You can hit the API with HTTPoison like so:

    response =
      HTTPoison.post(
        embedding_url,
        Jason.encode!(%{
          input: text,
          model: Keyword.get(opts, :model, embedding_model)
        }),
        [
          {"Content-Type", "application/json"},
          {"Authorization", "Bearer #{openai_api_key}"}
        ]
      )

See the whole file here: https://github.com/byronsalty/questify/blob/cba277ce8104c6f3b29dc2a6f602158ba4d1f62a/lib/questify/embeddings.ex

Add a vector to one of your schemas

Add a migration like this:

defmodule Questify.Repo.Migrations.AddCommandEmbeddings do
  use Ecto.Migration

  def change do
    alter table(:actions) do
      add :embedding, :vector, size: 1536
    end
  end
end

Then update your schema with a new vector type field like this:

    field :embedding, Pgvector.Ecto.Vector

Incorporate Vectors into Queries

You'll need to add this line at the top of an model where you plan to query with PGVector specific functions - importantly including the "distance" ones that we're looking to use.

  import Pgvector.Ecto.Query

Now you can query like the following:

  def get_action_by_text(location, text) do
    embedding = Questify.Embeddings.embed!(text)
    min_distance = 1.0

    Repo.all(
      from a in Action,
        order_by: cosine_distance(a.embedding, ^embedding),
        limit: 1,
        where: cosine_distance(a.embedding, ^embedding) < ^min_distance,
        where: a.from_id == ^location.id
    )
  end

Follow along for more ways to add LLM related capabilities into your Phoenix apps.

See more related content here.

Adding /blog proxy to a Phoenix app

Byron Salty — Tue, 06 Feb 2024 05:46:51 +0000

Let's say you have a product you are creating using Elixir/Phoenix but for marketing purposes you also setup a blog on a separate site like Wordpress.

It makes sense to keep this separation of concerns and let some off the shelf software worry about creating a blog experience, while you work on your primary product.

However, for user experience and SEO purposes you may want to have your applications appear to come from a single domain. I did a quick search for the importance of a single domain vs subdomains and the first article I found also uses this exact blog use case as their example.

Today I'll use just a couple bits of code and configuration to make to solve this problem directly in Phoenix. No access to your https proxy (nginx, caddy, etc) required!

Goal:

Create a proxy endpoint that will take all traffic to my primary domain mydomain.com/blog and route it over to the actual host of blog.mydomain.com

One reason I wanted to do this all in Elixir/Phoenix was I like to use Fly.io and their setup is super simple and effective... but I don't have direct access to their load balancer where I might otherwise setup a proxy like this.

The other thing that is nice about this setup is I will be able to use Elixir to manipulate the upstream request and response, which will come in handy as I make the experience seamless.

Step 1: The Proxy

I used the Elixir library reverse_proxy_plug which has the very nice benefit of not assuming anything about the hosting for the upstream service. For instance, it didn't need to be another Phoenix app or a service running on the same host.

Add this to your deps in mix.exs:

      {:reverse_proxy_plug, "~> 2.3"},

Then you can add this to your router.ex:

  scope "/blog" do
    pipe_through [:browser]
    forward "/", ReverseProxyPlug, upstream: "https://blog.mydomain.com", response_mode: :buffer
  end

Note that my use case is not high volume so I didn't really worry about different response modes. I believe the :buffer option works well enough for me here.

At this point, you should be able to hit your project at /blog and get some html that really came from your upstream service.

But there's a problem...

Step 2: Rewrite the content

The problem now is that the html that you will get will not know that you're trying to serve from mydomain.com/blog and will still have all links etc pointing to blog.mydomain.com.

No problem, we just need to alter the html response on the way out so that all of these references are updated.

This was a bit tricky because the conn struct is very particular about how it can be interacted with, stemming from the fact that HTTP is similarly and correctly picky. It wouldn't make sense if you could alter a response after you've already sent or even began sending it back to the client. So we need to pinpoint the moment where we have the response body but we are allowed to alter it.

Luckily, Plugs give us this exact ability in the standard function Plug.Conn.register_before_send/2. This gives us the opportunity to define a function that will be called with the Conn after the response is ready but before it's actually given back to the client.

We just need to define a custom plug.

Update the scope and define a new pipeline in router.ex:

  pipeline :transform_blog do
    plug BuddyWeb.Plugs.TransformBlog
  end

  scope "/blog" do
    pipe_through [:transform_blog]
    forward "/", ReverseProxyPlug, upstream: "https://blog.mydomain.com", response_mode: :buffer
  end

And here's the entire TransformBlog plug:

defmodule BuddyWeb.Plugs.TransformBlog do

  def init(options), do: options

  def call(%Plug.Conn{} = conn, _ \\ []) do
    Plug.Conn.register_before_send(conn, &BuddyWeb.Plugs.TransformBlog.transform_body/1)
  end

  def transform_body(%Plug.Conn{} = conn) do
    case List.keyfind(conn.resp_headers, "content-type", 0) do
      {_, "text/html" <> _} ->
        body =
          conn.resp_body
          |> String.replace("blog.mydomain.com", "mydomain.com/blog")

        %Plug.Conn{conn | resp_body: body}

      type ->
        IO.inspect(type, label: "content type header")
        conn
    end
  end
end

Thanks to Curiosum for their article on this using Plugs in this way. My code borrows heavily from their example.

But there's one more problem...

Note: If you test the code at this point you may notice that you get expected results in curl or wget but not in a browser.

Step 3: Dealing with encodings

The reason why browsers give a different response than the command line tools are the accept-encoding headers are different.

The command line tools are essentially asking for a response in a text format so our string replace is working and we get the result we expect.

But browsers will ask for a response in gzip or br encoding. Binary encodings that will only get turned back into text on the end-user's client so our string replace will not work.

The fix I employed here was to override the accept-encoding header to force a non-binary response from our upstream service. This will be less efficient but fine for my purposes and scale.

Update the same TransformBlog plug to change the request headers on the way in:

  def call(%Plug.Conn{} = conn, _ \\ []) do
    Plug.Conn.register_before_send(conn, &BuddyWeb.Plugs.TransformBlog.transform_body/1)
    |> Plug.Conn.update_req_header(
      "accept-encoding",
      "identity",
      fn _ -> "identity" end
    )
  end

The update_req_header() function asks you to specify both the default value (in case the header doesn't already exist) and a function to manipulate the existing header. In my case, I don't care what the previous header was - I'm just overriding to use identity which means no modification or compression.

That's all there is to it - one dependency to configure and one plug.

Happy Proxying~!

Techniques for Idempotency in seeds.exs

Byron Salty — Tue, 09 Jan 2024 05:21:19 +0000

Idempotency is an annoying word that makes people think you are an asshole when you use it, at least if they aren't exactly sure what it means.

But it's such a useful concept that I use it anyway and will just suffer the consequences.

For the uninitiated, it simply means that I can run the same code over and over and over but the result will always be the same.

Consider these two versions of a function trying to add tax to a bill:

defmodule Bill do
  defstruct total: 0.0, subtotal: 0.0
end

defmodule Tax do
  def calc_tax(bill) do
    %Bill{bill | total: bill.total * 1.07}
  end

  def calc_tax_w_subtotal(bill) do
    tax = bill.subtotal * 0.07
    %Bill{bill | total: bill.subtotal + tax}
  end
end

Both would work fine, if they are only called one time. In both cases, the current total is increased by 7%. The second version is more complex because we have the concept of both a subtotal and a total.

But the first version is not idempotent.

A race condition, bad calling code, or any number of other reasons could result in something like the following:

bill1 = %Bill{total: 10.0}
bill1 = Tax.calc_tax(bill1)
bill1 = Tax.calc_tax(bill1)
bill1.total # 11.449

vs:

bill2 = %Bill{subtotal: 10.0}
bill2 = Tax.calc_tax_w_subtotal(bill2)
bill2 = Tax.calc_tax_w_subtotal(bill2)
bill2.total # 10.7

In the case of the first, the tax compounds because we're only working with a single total and we can't tell if that total already includes tax. In the second case, we can calculate tax as much as we want but it doesn't effect the result after the first time.

Where it matters - Seeds

I see the need for idempotency in a lot of places but a very likely place you'll run into and need to care about it is with your seeds code.

If you run your seeds multiple times you probably don't want your default users or system categories or whatever created more than once.

I tried out a new form today to achieve idempotency in my seeds.exs and I found it cleaner than a simple if based approach so I thought I'd share. I'd love to hear if others have found better forms.

Approach one - `ecto.reset`

I suppose should start with the brute force method. If you always run your seeds as part of mix ecto.reset then you are achieving idempotency by always starting with a blank slate.

Similarly, you could create another approach in which you try to delete specific entities if they exist, before creating them in the seeds. (We can call that 1B)

Approach two - `try`

We could rely on database unique constraints to prevent multiple similar entries. We just try to create every time and ignore any errors:

try do
  Repo.insert!(%Category{
    name: "Books",
  })
rescue
  _ ->
    IO.puts("Already seeded")
end

Approach three - `if`

I've done this one a fair amount. It's not too bad, and rather readable, especially if all you want to do is create the entry (but not use it later in the seeds).

For example, this doesn't look horrible:

if Repo.get_by(Category, name: "Books") == nil do
  Repo.insert!(%Category{
    name: "Books",
  })
end

But it looks worse if you want to use that entity later:

book_category = 
  if Repo.get_by(Category, name: "Books") == nil do
    Repo.insert!(%Category{
      name: "Books",
    })
  else
    Repo.get_by(Category, name: "Books")
  end

(Yes, you could keep the result of the first get_by but the form doesn't really get much cleaner.)

lookup = Repo.get_by(Category, name: "Books")
book_category = 
  if lookup == nil do
    Repo.insert!(%Category{
      name: "Books",
    })
  else
    lookup
  end

Approach four - `case`

This is my current favorite way of achieving idempotency and capturing the value for later use:

book_category =
  case Repo.get_by(Category, name: "Books") do
    nil -> Repo.insert!(%Category{
      name: "Books",
    })
    category -> category
  end

Is there something even better that you use?

Please share!

If you found this article helpful, show your support with a Like, Comment, or Follow.

Read more of Byron’s articles about Leadership and AI.

Development articles here.

Follow on Medium, Dev.to, Twitter, or LinkedIn.

Elegantly Running multiple validators in Elixir

Byron Salty — Sun, 07 Jan 2024 23:33:32 +0000

I need to update some validation code to be elegant and not this chained set of if statements.

  def validate_guess(prompt, words) do
    if not Enum.all?(words, fn w -> String.trim(w) != "" end) do
      "Please fill in all the blanks"
    else
      if Enum.any?(words, fn w -> String.trim(w) |> String.length() < 3 end) do
        "No words less than 3 letters"
      else
        if Enum.any?(words, fn w -> Regex.match?(~r/\W/, w) end) do
          "Words can only contain letters"
        else
  ...

How can we write this better?

Step 1 - write some tests

Despite how the code looks, it works. Let's make sure we have tests in place before we refactor so that it continues to work.

Writing tests will also help refactor the code, because we need to make the interfaces easily testable.

  describe "test validations" do
    test "test for blank words" do
      prompt = nil
      words = ["", "dog", "walking", "around", "tree"]
      assert TextHelper.validate_guess(prompt, words) == "Please fill in all the blanks"
    end

    test "test for only letters" do
      prompt = nil
      words = ["some words", "dog", "walking", "around", "tree"]
      assert TextHelper.validate_guess(prompt, words) == "Words can only contain letters"

      words = ["brown1123", "dog", "walking", "around", "tree"]
      assert TextHelper.validate_guess(prompt, words) == "Words can only contain letters"

      words = ["brown!", "dog", "walking", "around", "tree"]
      assert TextHelper.validate_guess(prompt, words) == "Words can only contain letters"
    end

    test "test for no words less than 3 letters" do
      prompt = nil
      words = ["br", "dog", "walking", "around", "tree"]
      assert TextHelper.validate_guess(prompt, words) == "No words less than 3 letters"
    end
  end

Note: I did end up finding an error where my former code was not detecting (rejecting) words with digits, so a win for unit tests!

Step 2 - Rewrite using `with` statement

I saw this structure in this project:
SpellingBee project

And here is another article talking specifically about using the with statement for this reason.

A much cleaner way to combine all of the validations:

  def validate_guess(prompt, words) do
    with "" <- validate_blank_words(words),
         "" <- validate_word_characters(words),
         "" <- validate_word_length(words),
         "" <- validate_grammar(prompt, words) do
      ""
    end
  end

Individual validators:

  defp validate_blank_words(words) do
    case Enum.any?(words, fn w -> String.trim(w) == "" end) do
      true -> "Please fill in all the blanks"
      false -> ""
    end
  end
  defp validate_word_length(words) do
    case Enum.any?(words, fn w -> String.trim(w) |> String.length() < 3 end) do
      true -> "No words less than 3 letters"
      false -> ""
    end
  end
  defp validate_word_characters(words) do
    case Enum.any?(words, fn w -> Regex.match?(~r/[\W\d]/, w) end) do
      true -> "Words can only contain letters"
      false -> ""
    end
  end

And all the tests pass:

Finished in 0.08 seconds (0.00s async, 0.08s sync)
3 tests, 0 failures

Woot!

If you found this article helpful, show your support with a Like, Comment, or Follow.

Read more of Byron’s articles about Leadership and AI.

Development articles here.

Follow on Medium, Dev.to, Twitter, or LinkedIn.

Creating an Elixir library for Spell Checking

Byron Salty — Sun, 07 Jan 2024 19:48:24 +0000

Instead of directly incorporating my simple spell checking code into my project, why not turn this into a library that I could more easily use in other places as well as share publicly.

I know that some other libraries exist but none appear to be a standard, and since I'm really doing this as an experiment forgive me for re-inventing the wheel a bit.

I'm following this official guide for creating a library.

Create a Project

Let's start with simply creating a new library.

$ mix new spell_chex

I prefer an evolutionary and iterative style of development so before I worry about the complexity of a GenServer in my final spell checker build, I'll create the project with the naive implementation (discussed previously) and make sure I can create the library and then use the library in my host application.

Let's be good citizens and add some docs too:

defmodule SpellChex do
  @moduledoc """
  Module used to invoke SpellChex.
  """
  @moduledoc since: "1.0.0"

  @sample_words ["hello", "world", "elixir", "phoenix", "spell", "check", "dog", "cat"]


  @doc """
  Determines if a given `word` is in the list of known words.

  Returns `true` or `false`.

  ## Examples

      iex> SpellChex.exists?("dog")
      true

      iex> SpellChex.exists?("asdfas")
      false

  """
  @doc since: "1.3.0"
  def exists?(word) do
    # GenServer.call(__MODULE__, {:check_exists, word})
    word in @sample_words
  end
end

In order to get our docs to create we need at add the ex_doc dependency to our mix.exs.

  defp deps do
    [
      {:ex_doc, "~> 0.31", only: :dev, runtime: false}
    ]

And let's test out those docs. (More on running docs locally here.)

mix deps.get
mix docs
cd doc
caddy file-server --browse --listen :5051

That should be it for the naive implementation. Now let's figure out how to build it locally and use it in our host project.

Consume the library locally

Eventually we will want to push our local code to github and publish on Hex, but why worry about publishing every time you want to test something out locally?

First thing to do is to update your host project to reference your new library with the path option:

  defp deps do
    [
      ...
      {:spell_chex, path: "../spell_chex"},

Grab your deps again (mix deps.get) and now you can start using the library:

iex(1)> SpellChex.exists?("dog")
true

Configure the Library

Since the library relies on a GenServer to create a dictionary of words we need to add our dictionary to the host application's start-up.

Update children in lib/<host>/application.ex:

 def start(_type, _args) do

    children = [
      ...
      SpellChex.Dictionary,
      ...
    ]

Now you should be able to start your host mix app and test it out:

iex -S mix
...

iex(1)> SpellChex.exists?("dog")
true
iex(2)> SpellChex.exists?("blahblah")
false
iex(3)> SpellChex.exists?("bonsai")  
true

Publish via Github

You could simply push your latest to main and then reference your library from the host app's mix.exs like this

      {:spell_chex, git: "https://github.com/byronsalty/spell_chex"},

But you may want to still utilize versioning. If so you'd tag in get like this:

git tag -a "0.0.1"
git push origin 0.0.1
# or
git push origin --tags

Then you can use the version in the mix.exs:

      {:spell_chex, git: "https://github.com/byronsalty/spell_chex", tag: "0.0.1"},

Publish to Hex

But maybe you want to make your library truly global...

Following this guide to publishing to Hex:
https://hex.pm/docs/publish

Highlights:

Setup your hex account.
Add all of the required metadata.
Make sure your docs build.
Publish! mix hex.publish

Now you can use the standard mix.exs dependency style:

      {:spell_chex, "~> 0.0.1"},

Happy Coding!

If you found this article helpful, show your support with a Like, Comment, or Follow.

Read more of Byron’s articles about Leadership and AI.

Development articles here.

Follow on Medium, Dev.to, Twitter, or LinkedIn.

Creating an efficient SpellChecker in Elixir

Byron Salty — Fri, 05 Jan 2024 06:05:53 +0000

Goal

To efficiently use a large list of known English words to create a spell checker.

NOTE This is a work in progress. Please respond with comments on how it could be done better / if there are existing frameworks or libraries that I should use instead.

Plan

In this article I'll create two versions of a simple spell checker which really will just take a word and see if it's in a large list of known words. I'm using this list of 20,000 words, which is supposed to be a list of the most frequent ones.

I plan to use this in a Phoenix app so I wanted to do some measurements and determine the performance characteristics. My first thought was to use a GenServer so that I could have a single process load up the list and answer check requests, but I wanted to make sure overhead of a GenServer is worth it.

Code Structure

I'm creating two different SpellCheckers - a Naive one and a GenServer one.

I'm going to use a page from Bram Stoker's Dracula as test data.

And then I'll use Benchee to measure results.

Implementations

Helper:

defmodule FileReader do
  def read_words_from_file(file_path) do
    file_path
    |> File.stream!()
    |> Enum.map(&String.trim/1)
    |> Enum.reject(&(&1 == ""))
  end
end

Naive:

defmodule SpellCheck.Naive do

  #@all_words ["these", "are", "some", "words"]

  def exists?(word) do
    all_words = FileReader.read_words_from_file("/tmp/20k.txt")

    word in all_words
  end
end

GenServer:

defmodule SpellCheck.GenServer do
  use GenServer

  #@all_words ["these", "are", "some", "words"]

  def start_link(_opts \\ []) do
    GenServer.start_link(__MODULE__, :ok, name: __MODULE__)
  end

  def exists?(word) do
    GenServer.call(__MODULE__, {:check_exists, word})
  end

  @impl true
  def init(_) do
    all_words = FileReader.read_words_from_file("/tmp/20k.txt")
    {:ok, all_words}
  end


  @impl true
  def handle_call({:check_exists, word}, _from, all_words) do
    {:reply, word in all_words, all_words}
  end
end

SpellCheck.GenServer.start_link()

Test words:

sample_text = """
I soon lost sight and recollection of ghostly fears
<snip>
"""

eval_words = String.split(sample_text, " ", trim: true)

Benchee:

Benchee.run(%{
    "Naive" => fn -> Enum.map(eval_words, fn w -> SpellCheck.Naive.exists?(w) end) end,
    "GenServer" => fn -> Enum.map(eval_words, fn w -> SpellCheck.GenServer.exists?(w) end) end
  },
  time: 5, 
  memory_time: 2
  )

Test 1 - Hard coded dictionary

First, I actually tested the code without reading the 20,000 words from a file and just used an array set as module attributes.

Perhaps not surprisingly, when using a hard coded list of words as a dictionary the extra overhead of a GenServer was noticable and the Naive implementation performed better:

Name                ips        average  deviation         median         99th %
Naive           14.17 K       70.57 μs    ±37.68%       69.79 μs       87.25 μs
GenServer        2.99 K      333.95 μs     ±3.30%      330.88 μs      374.93 μs

Comparison: 
Naive           14.17 K
GenServer        2.99 K - 4.73x slower +263.38 μs

Memory usage statistics:

Name         Memory usage
Naive           171.97 KB
GenServer       246.55 KB - 1.43x memory usage +74.58 KB

Interpreting the results: Naive was 5x faster and used ~60% less memory.

But this is not a viable way to check spelling because we need to load a large set of words.

How will it perform at higher scale?

Test 2 - Reading dictionary from a file

You won't be surprised to see that the GenServer performs much better, considering that their purpose is maintaining state so we don't need to load the state over and over.

However, I was surprised to see HOW MUCH better it was:

Name                ips        average  deviation         median         99th %
GenServer        110.18      0.00908 s    ±55.16%      0.00876 s      0.00981 s
Naive              0.68         1.46 s     ±6.78%         1.41 s         1.61 s

Comparison: 
GenServer        110.18
Naive              0.68 - 160.88x slower +1.45 s

Memory usage statistics:

Name         Memory usage
GenServer      0.00024 GB
Naive             1.98 GB - 8419.39x memory usage +1.98 GB

Interpreting the results: GenServer was 160x faster and a tiny fraction of the memory that Naive used. In fact, it looks like GenServer's memory usage didn't change much between tests.

Though the overall throughput between the two tests varies significantly. My method of checking if a word is in the dictionary could certainly be improved with a data structure that supports a binary search instead of a linear search. But this is good enough for my use case and I'll need to explore faster searching another time.

Easy LLM based text classification with instructor_ex

Byron Salty — Thu, 04 Jan 2024 05:38:06 +0000

I got lucky today.

Just as I was contemplating how to add grammar and spell checking to my Text-to-Image game, I read about a new library that I could use to solve both problems at the same time.

My game involves trying to find 5 missing words needed to complete a prompt phrase which was used to generate the original image. Every time there is a unique guess, I generate a new image to show the user if they were close. But if a user guesses a phrase that someone else guessed then I can pull the image from cache and don't need to pay for a new generation.

This means that spelling errors cost me money.

And since the target phrase is grammatically correct, any bad grammar is also a waste.

I was considering adding a dictionary to check words against, and I wasn't sure what to do about grammar checking...

Enter instructor_ex and LLMs

I'm a bit ashamed to admit that I didn't first jump to using an LLM to solve this problem - because the answer is pretty obvious now.

Why not just ask an LLM, which understands both grammar and spelling VERY well:
"Is the following phrase grammatically correct and spelled correctly?"

This is the exact type of question and use case that Thomas Millar's new library instructor_ex is designed to make easy.

Step 0 - Add Instructor to your project

Update your mix.exs deps

 defp deps do
    [
      ...
      {:instructor, "~> 0.0.2"},
      ...
    ]

Add instructor and openai to your config:

config :instructor,
  adapter: Instructor.Adapters.OpenAI

config :openai,
  api_key: "sk-...8pj",
  http_options: [recv_timeout: 10 * 60 * 1000]

Note You can tell from this config that OpenAI is not the only adapter and LLM you can use.

Step 1 - Create a Grammar classifier

Instructor follows the ecto schema pattern, which I believe could be extremely helpful for more complex use cases. In my use case, the effort was minimal and definition was pretty clear.

The one part that was a bit confusing was that the question being asked of the LLM is embedded in the @doc string for the schema. Here's my classifier:

defmodule GrammarClassification do
  use Ecto.Schema

  @doc """
  A classification of whether or not a provided phrase is grammatically correct and has correct spelling
  """
  @primary_key false
  embedded_schema do
    field(:is_correct?, :boolean)
  end
end

Step 2 - Classify some text and get a result

I then wrapped the calling of the classifier in a simple helper function which follows the exact format from the example notebooks found in project:

defmodule Teleprompt.TextHelper do
  def is_correct?(phrase) do
    {:ok, %{is_correct?: result}} =
      Instructor.chat_completion(
        model: "gpt-3.5-turbo",
        response_model: GrammarClassification,
        messages: [
          %{
            role: "user",
            content: "Classify the following text: #{phrase}"
          }
        ]
      )

    result
  end
end

Now I can simply call a single function, pass in a string of words, and receive a true/false response on whether or not it is spelled correctly and grammatically correct.

Hell yeah!

Adding DALL-E to your Elixir app

Byron Salty — Wed, 03 Jan 2024 05:54:24 +0000

I recently updated my little image generation game, Teleprompt, to use DALL-E 3 instead of Stable Diffusion as the image engine.

If you're curious about the reasoning, overall product and architecture, check out my previous, high-level article with those details - as well as some cool pictures of dragons!

In this article, I will give you the few pieces of code you need to create your own DALL-E 3 integration with Elixir.

...

Step 1 - Setup OpenAI

DALL-E is part of the OpenAI product suite, under Image Generation.

Create an account with OpenAI and on the left nav bar you'll see an option for API Keys.

From there you can select "Create new secret key" and copy the value that will look like sk-....

I like to add this to a .env file to source and make available to my project:

export OPENAI_API_KEY=sk-...u8pj

Step 2 - API request

In Teleprompt, I setup a GenServer in order to asynchronously call the OpenAI API. Depending on your use case you might not need this complexity but I felt it was important for a webapp to be more event driven and then use PubSub to inform listeners when the image generation was complete.

defmodule Teleprompt.GenerationHandler do
  use GenServer

  ...

  def start_generating(prompt) do
    # create a post request to the server
    GenServer.cast(__MODULE__, {:generate, prompt, listener_code})
  end

  @impl true
  def handle_cast({:generate, prompt, listener_code}, _state) do
    endpoint = "https://api.openai.com/v1/images/generations"
    openai_api_key = @openai_key
    {model, size} = {"dall-e-3", "1024x1024"}
    # {model, size} = {"dall-e-2", "512x512"}

    data =
      %{
        "model" => model,
        "size" => size,
        "quality" => "standard",
        "n" => 1,
        "prompt" => prompt
      }
      |> Jason.encode!()

    opts = [async: true, recv_timeout: 30_000, timeout: 30_000]

    response =
      HTTPoison.post!(
        endpoint,
        data,
        [
          {"Content-Type", "application/json"},
          {"Authorization", "Bearer #{openai_api_key}"}
        ],
        opts
      )

    response_body = 
      response
      |> Map.get(:body)
      |> Jason.decode!()

    # url in body: body["data"][0]["url"]
    url = response_body |> get_in(["data", Access.at(0), "url"])

  ...

Here we are making the post with mostly default parameters. I did try out DALL-E 2 as well, which allows for different parameters and different options (like sizes).

One parameter I was a bit surprised to see missing is a seed, so I don't know if DALL-E allows you to create repeatable results.

You can see the OpenAI API reference here.

I also used the default response type, which is a url to a public image, however I could have also specified a different response_format and received the file contents as base64 encoded json.

Step 3 - Use the file

In my case I did want to download the file and manipulated it so I immediately take the URL and do some processing on it. Perhaps the b64_json response would have made more sense but I was already setup to handle urls so I left that code in place.

One question I have is how long the images would last on the OpenAI CDN if you wanted to directly use the url they give you in your app.

I didn't trust that the image would last forever so I took the url, downloaded the file, uploaded it to AWS to serve myself.

Here's how the end of my generate handler looks, after I get the generated image url:

    ...
    url = response_body |> get_in(["data", Access.at(0), "url"])
    {file_name, file_path} = download_and_resize_image(url)

    # upload to s3
    {:ok, file_binary} = File.read(file_path)

    write_file_to_s3(file_name, file_binary, "image/png")

    Teleprompt.Messaging.received_image(listener_code)

    {:noreply, nil}
  end

I'll save some of the small details around resizing but the download code is simply a get and File.write:

  ...
  file_path = "/tmp/#{file_name}"
  {:ok, response} = HTTPoison.get(image_url)

  File.write!(file_path, response.body)
  ...

That's really all there is to it. Now go make some images!

Upgrading to Phoenix 1.7

Byron Salty — Fri, 29 Dec 2023 05:20:27 +0000

I consider this a work in progress. This is a guide that I'll use myself as I migrate all my projects to 1.7 so it will refine over time and please submit comments / suggestions for improvements.

The Problem

I have several older projects that are in the Phoenix 1.6 style and structure, and lots of newer ones in 1.7. In order to share code and solutions between them I need to move them all to 1.7 and do it by making the 1.6 look exactly like a project started on 1.7.

Therefore, I'm moving things and removing things resulting in changes that may not be strictly necessary if you are just trying to get 1.7 to run.

Some other good tutorials exist that can be helpful to just make a project work, for example by adding Views back into the project via an optional dependency.

Steps

0. Create a branch in git

Disclaimer

In order to make the app look like a true 1.7 app, we need to move, edit and delete a lot of files.

Start with creating a branch in git in case you ever need to revert or reference the 1.6 code:

git checkout -b phoenix_1_6
git checkout -b upgrading_to_1_7

I also suggest that you keep a separate clone of the old version, or at least grab the list of generated routes for use later when you convert to path sigils:

mix phx.routes > routes.txt

(I'm saying store it because once you start making these changes your project may not compile again until all the issues are fixed. In my latest conversion, there were over 800 issues to be fixed to get the project to compile again.)

1. Update dependencies

List of deps that I changed:

defp deps do
 [
    {:phoenix, "~> 1.7.10"},
    {:phoenix_html, "~> 3.3"},
    {:phoenix_live_reload, "~> 1.2", only: [:dev]},
    {:phoenix_live_view, "~> 0.19"},
    {:phoenix_live_dashboard, "~> 0.8.0"},
    {:esbuild, "~> 0.7", runtime: Mix.env() == :dev},
    ...

Run:

mix deps.clean --all
rm mix.lock
mix deps.get
mix deps.compile

2. Fix issues related to Views

Phoenix 1.7 removed the view files so things need to be updated. You'll see errors like:

error: module Phoenix.View is not loaded and could not be found. This may be happening because the module you are trying to load directly or indirectly depends on the current module 
...

Instead, Phoenix 1.7 uses html_template embedding modules. (See Step 5)

Take note of any functionality that you may have added to your *_view.ex modules. This will likely move into your *_html.ex files that we'll create in Step 5.

I suggest keeping those View modules for now, but remove the use <App>Web, :view so that it won't throw compilation errors.

But if you only have boilerplate code in /views then you can safely remove those files and that directory:

# NOTE: Only if you don't need to keep any of those files
#   Otherwise run this after Step 5.
rm -fr lib/appName_web/views

3. Create components dir

This is where layouts and standard components will live now.

mkdir lib/<app>_web/components

Move you layouts from the former templates dir:

mv lib/<app>_web/templates/layouts lib/<app>_web/components/.

Note: If you have a live.html.heex layout, you should be able to remove it. One of the major benefits of 1.7 is that the layouts are shared across live and dead views.

4. Move template dirs

Instead of being in a separate templates directory, the remaining templates folders with the *.html.heex files move into the controllers dir as subfolders:

mv lib/appName_web/templates/* lib/appName_web/controllers/.

Note: I then manually renamed them to include the standard _html suffix.

cd lib/appName_web/controllers
mv page page_html
mv post post_html

After that you should be able to get rid of the templates dir:

rm -fr lib/appName_web/templates

5. Add the html embedding modules

Let's say you still have a PageController. You'll want to add a companion file next to the page_controller.ex conventionally called page_html.ex which looks like this by default:

defmodule AppNameWeb.PageHTML do
    use AppNameWeb, :html
    embed_templates "page_html/*"
end

You will probably get an error that :html is an unknown function in your app's web module. You'll need to find your base module at lib/appName_web/appName_web.ex and change a few functions.

Add: html, html_helpers, verified_routes, and static_paths:

def html do
    quote do
        use Phoenix.Component
        # Import convenience functions from controllers

        import Phoenix.Controller,
            only: [get_csrf_token: 0, view_module: 1, view_template: 1]

        # Include general helpers for rendering HTML
        unquote(html_helpers())
    end
end

defp html_helpers do
    quote do
        # HTML escaping functionality
        import Phoenix.HTML

        # Core UI components and translation
        import AppNameWeb.CoreComponents
        import AppNameWeb.Gettext

        # Shortcut for generating JS commands
        alias Phoenix.LiveView.JS

        # Routes generation with the ~p sigil
        unquote(verified_routes())
    end
end

def verified_routes do
    quote do
        use Phoenix.VerifiedRoutes,
            endpoint: AppNameWeb.Endpoint,
            router: AppNameWeb.Router,
            statics: AppNameWeb.static_paths()
    end
end

def static_paths, do: ~w(assets fonts images favicon.ico robots.txt)

Remove component, view and view_helpers

Update references to view_helpers to html_helpers

Also - update the controller,live_view and live_component function:

def controller do
    quote do
        use Phoenix.Controller,
            formats: [:html, :json],
            layouts: [html: AppNameWeb.Layouts]

        import Plug.Conn
        import AppNameWeb.Gettext

        unquote(verified_routes())
    end
end

  def live_view do
    quote do
      use Phoenix.LiveView,
        layout: {AppNameWeb.Layouts, :app}

      unquote(html_helpers())
    end
  end

  def live_component do
    quote do
      use Phoenix.LiveComponent

      unquote(html_helpers())
    end
  end

6. Add standard files

Add some components

Grab the core_components.ex and layouts.ex from any 1.7 projects or clone this example project and put it into lib/appName_web/components

Add Gettext

If you don't have GetText in the base of your app then grab that too from lib/appName_web/gettext.ex

Make sure you updated "appName"

Make sure this doesn't find anything:

grep -ri lib appname

7. Small change to the csrf_token

Your root.html.heex layout probably has a function call like:

csrf_token_value()

This needs to change to:

get_csrf_token()

8. Update router

The :browser pipeline needs to reference the layouts with the new module name. Change:

#from
plug :put_root_layout, {AppNameWeb.LayoutView, :root}

#to
plug :put_root_layout, html: {AppNameWeb.Layouts, :root}

9. Update Routes to use `~p` sigil

Now you can use the much more convenient ~p sigil.

Look in all of your html for references to Routes. and change them similar to the following examples:

# from:
href={Routes.static_path(@conn, "/assets/app.css")}

# to:
href={~p"/assets/app.css"}

# from
<img src={Routes.static_path(@conn, "/images/logo.png")}

# to
<img src={~p"/images/logo.png")}

# from
Routes.post_path(@conn, :index)

# to
~p"/posts"

# from
Routes.post_path(@conn, :update, @post)

# to
~p"/admin/prompts/#{@prompt}"

10. Update heex to use components

Instead of embedding elixir code into templates with <%= ... %>, convert these snippets to components where appropriate.

Some example replacements:

# from:
<%= live_title_tag assigns[:page_title] || "App" %>

# to:
<.live_title suffix="">
    <%= assigns[:page_title] || "App" %>
</.live_title>

# from:
<%= render 'form.html', ... %>

# to:
<.post_form changeset={@changeset} action={~p"/posts/update/#{@post}"} />

# from:
<%= link "Edit", to: Routes.page_path(@conn, :edit, @page) %>

# to:
<.link navigate={~p"/pages/#{@page}"}>Edit</.link>

# from:
<%= link "Delete", to: Routes.page_path(@conn, :delete, page), method: :delete, data: [confirm: "Are you sure you want to delete #{page.title}?"] %>

# to:
<.link href={~p"/mascots/#{mascot}"} method="delete" data-confirm="Are you sure?">
  Delete
</.link>

# from:
  <%= label f, :name %>
  <%= text_input f, :name %>
  <%= error_tag f, :name %>

# to:
  <.input field={f[:name]} type="text" label="Name" />

# from:
  <%= inputs_for f, :children, fn c -> %>

    <%= label c, :baby_name %>
    <%= text_input c, :baby_name %>
    <%= error_tag c, :baby_name %>

# to:

# from:
  <%= if @changeset.action do %>
    <div class="alert alert-danger">
      <p>Oops, something went wrong! Please check the errors below.</p>
    </div>
  <% end %>

# to:
  <.error :if={@changeset.action}>
    Oops, something went wrong! Please check the errors below.
  </.error>

# from:
  <div class="buttons">
    <%= submit "Save" %>
  </div>

# to:
  <:actions>
    <.button>Save</.button>
  </:actions>

TIP: Keep a 1.7 generated app nearby with a some forms etc created with mix phx.gen.html ... for comparisons during this phase.

10B - Check that you didn't miss anything

Here are a few scripts to run against your lib dir to find missed replacements:

grep -r lib "<%= link"

11. Update various heex items

The form component now needs :let instead of let.

You could try bulk updating like this:

# MacOS
find lib -type f -name "*.heex" -exec sed -i '' 's/form let/form :let/g' {} +

# Linux
find lib -type f -name "*.heex" -exec sed -i 's/form let/form :let/g' {} +

If this was helpful - give it a Like and Follow!

Happy Coding.

Clustering with Phoenix 1.7

Byron Salty — Tue, 08 Aug 2023 08:17:55 +0000

There several good articles about how to setup a Phoenix cluster with PubSub messaging through the nodes but I found them to be incomplete or slightly out of date so in this article I plan to give step by step instructions on how to create a clustered Phoenix 1.7 application in 2023.

The goal of this article will be to run multiple instances of our Phoenix which seamlessly can do message passing between nodes.

The target production environment will be Fly.io for this article, but I'll also show how to setup your project for local development as well so you can make sure you are subscribing and broadcasting correctly.

Simplest Demo Project

We're going to create a stripped down Phoenix app that does only two things:

Exposes a live view that displays messages received
Has an API end-point to receive external messages via HTTP

Create project

Note - we will build this project step by step but feel free to check out the completed project here

Setup Phoenix app

Phoenix new with most things removed:

mix phx.new talkie --no-ecto --no-mailer

Update the config/dev.exs file to allow passing in a PORT since we'll need to run two instances:

# Before
config :talkie, TalkieWeb.Endpoint,
    http: [ip: {127, 0, 0, 1}, port: 4000],
    ...

# After
port = String.to_integer(System.get_env("PORT") || "5000")

config :talkie, TalkieWeb.Endpoint,
    http: [ip: {127, 0, 0, 1}, port: port],
    ...

Create the `ping` API endpoint:

# Add this controller
defmodule TalkieWeb.APIController do
    use TalkieWeb, :controller

    def ping(conn, _params) do
        # Not doing anything but responding so far
        json(conn, %{pong: true})
    end
end

Add the ping route to your router.ex inside the existing /api scope:

scope "/api", TalkieWeb do
    pipe_through :api
    get "/ping", APIController, :ping
end

Test it:

curl http://127.0.0.1:5000/api/ping

# {"pong": true}

Create the Liveview viewer

Add a LiveView module like this

defmodule TalkieWeb.ViewerLive.Index do
    use TalkieWeb, :live_view

    @impl true
    def render(assigns) do
        ~H"""
        <h1>Messages</h1>
        <%= for msg <- @messages do %>
            <span><%= msg %></span>
        <% end %>
        """
    end

    @impl true
    def mount(_params, _session, socket) do
        {:ok, assign(socket, :messages, [])}
    end

    @impl true
    def handle_info({:message, msg}, socket) do
        {:noreply, assign(socket, 
            :messages, [msg | socket.assigns.messages])}
    end

    @impl true
    def handle_info(
        %Phoenix.Socket.Broadcast{
            topic: "messages",
            event: "ping",
            payload: {:message, msg}
        }, socket) do
        handle_info({:message, msg}, socket)
    end
end

And add this line to your router.ex:

    # in the browser scope
    live "/viewer", ViewerLive.Index

Test it by pointing your browser at (http://127.0.0.1:5000/viewer)

Listen for messages on One instance

Now that we have those components. Let's wire them together with a single instance.

We're going to have our Viewer listen for messages, and our API broadcast whenever the /ping api is hit.

You "listen" by subscribing to a topic. Update the liveview mount to look like this now:

def mount(_params, _session, socket) do
    TalkieWeb.Endpoint.subscribe("messages")
    {:ok, assign(socket, :messages, ["test message..."])}
end

And you broadcast by adding the broadcast to the ping function this the API Controller:

def ping(conn, _params) do
    Phoenix.PubSub.broadcast!(Talkie.PubSub, "messages",
        %Phoenix.Socket.Broadcast{
            topic: "messages",
            event: "ping",
            payload: {:message, "ping"}
        }
    )
    json(conn, %{pong: true})
end

Test it

Start the server:

PORT=5000 mix phx.server

Open a browser to: (http://127.0.0.1:5000/viewer)

Hit the ping api again:

curl http://127.0.0.1:5000/api/ping

This should cause the Viewer to display a "ping" message instantly.

Clustering for local dev

Now let's see clustering NOT work first. Open up two instances like this:

PORT=5000 elixir --name a@127.0.0.1 -S mix phx.server
PORT=5001 elixir --name b@127.0.0.1 -S mix phx.server

Bring up a Viewer pointed to both servers:
(http://127.0.0.1:5000/viewer)
(http://127.0.0.1:5001/viewer)

And if you run the curl on the ping API you'll see that only one viewer will update.

Add `libcluster` to your dependencies in `mix.exs` and rerun `mix deps.get`

{:libcluster, "~> 3.3"},

Add the libcluster config to your `config/dev.exs`:

config :libcluster,
    topologies: [
        example: [
            strategy: Cluster.Strategy.Epmd,
            config: [hosts: [:"a@127.0.0.1", :"b@127.0.0.1"]],
            connect: {:net_kernel, :connect_node, []},
            disconnect: {:erlang, :disconnect_node, []},
            list_nodes: {:erlang, :nodes, [:connected]},
        ]
    ]

Update your `application.ex`

You will define a topologies variable in your start() function and add a Cluster.Supervisor to the list of children.

It will look like:

def start(_type, _args) do
    topologies = Application.get_env(:libcluster, :topologies) || []

    children = [
        ...
        {Cluster.Supervisor, [topologies, [name: Talkie.ClusterSupervisor]]}
    ]

    ...

Now if you restart both of the instances and test again you SHOULD see both Viewers update when you ping either one of the instances.

Pretty cool right!

Clustering with Fly.io

First, deploy the app as-is to Fly and test that you see it not working as expected again.

What you should see (assuming you default to 2 instances) is a 50/50 chance that you'll receive the ping message if you pull up a /viewer page and then hit the ping API. A rough test is to bring up 2-4 separate windows and to the /viewer path and test a ping to see how many of the windows update.

Add `libcluster` configuration to prod in the `config/runtime.exs` file

app_name = System.get_env("FLY_APP_NAME") || "talkie"

config :libcluster,
    debug: true,
    topologies: [
        fly6pn: [
            strategy: Cluster.Strategy.DNSPoll,
            config: [
                polling_interval: 5_000,
                query: "#{app_name}.internal",
                node_basename: app_name
            ]
        ]
    ]

Change how the RELEASE_NODE value is set in the `rel/env.sh.eex`

Note if you don't have this file, then you just haven't completed fly deploy yet. Do that first.

#Before
export RELEASE_NODE="${FLY_APP_NAME}-${FLY_IMAGE_REF##*-}@${FLY_PRIVATE_IP}"

#After
ip=$(grep fly-local-6pn /etc/hosts | cut -f 1)
export RELEASE_NODE="${FLY_APP_NAME}@${ip}"

See more from Fly.io guide

See the full project

Check out the Github Repofor the project used to test this article.

Other Resources

There are some good examples here:

Well written article from Alvise Susmel that helped me a lot

DEV Community: Byron Salty

A little Rust proxy for Ollama

Introduction

Problem Description

Solution Approach

Implementation Details

Conclusion

A Simple Test HTTP server from Flask

Don't Install - Just create

Server code

Adding Embeddings to a Phoenix App

Add PG Vector to deps

Add Migration to install the vector extension

Add Postgrex.Types

Configure your app with the OpenAI endpoints

Hit the API

Add a vector to one of your schemas

Incorporate Vectors into Queries

Adding /blog proxy to a Phoenix app

Goal:

Step 1: The Proxy

Step 2: Rewrite the content

Step 3: Dealing with encodings

Techniques for Idempotency in seeds.exs

Where it matters - Seeds

Approach one - ecto.reset

Approach two - try

Approach three - if

Approach four - case

Elegantly Running multiple validators in Elixir

Step 1 - write some tests

Step 2 - Rewrite using with statement

Creating an Elixir library for Spell Checking

Create a Project

Consume the library locally

Configure the Library

Publish via Github

Publish to Hex

Creating an efficient SpellChecker in Elixir

Goal

Plan

Code Structure

Implementations

Test 1 - Hard coded dictionary

Test 2 - Reading dictionary from a file

Easy LLM based text classification with instructor_ex

Enter instructor_ex and LLMs

Step 0 - Add Instructor to your project

Step 1 - Create a Grammar classifier

Step 2 - Classify some text and get a result

Adding DALL-E to your Elixir app

Step 1 - Setup OpenAI

Step 2 - API request

Step 3 - Use the file

Upgrading to Phoenix 1.7

The Problem

Steps

0. Create a branch in git

1. Update dependencies

2. Fix issues related to Views

3. Create components dir

4. Move template dirs

5. Add the html embedding modules

6. Add standard files

Add some components

Add Gettext

Make sure you updated "appName"

7. Small change to the csrf_token

8. Update router

9. Update Routes to use ~p sigil

10. Update heex to use components

10B - Check that you didn't miss anything

11. Update various heex items

Clustering with Phoenix 1.7

Simplest Demo Project

Create project

Setup Phoenix app

Create the ping API endpoint:

Create the Liveview viewer

Listen for messages on One instance

Approach one - `ecto.reset`

Approach two - `try`

Approach three - `if`

Approach four - `case`

Step 2 - Rewrite using `with` statement

9. Update Routes to use `~p` sigil

Create the `ping` API endpoint:

Add `libcluster` to your dependencies in `mix.exs` and rerun `mix deps.get`

Add the libcluster config to your `config/dev.exs`:

Update your `application.ex`

Add `libcluster` configuration to prod in the `config/runtime.exs` file

Change how the RELEASE_NODE value is set in the `rel/env.sh.eex`