DEV Community: Vincent Nguyen

What are we really building AI for?

Vincent Nguyen — Thu, 17 Apr 2025 11:11:13 +0000

I use AI every day.

But not the way people hype it up.

I still type. I still think. I still debug.
I use AI like a pair programmer — a partner to bounce ideas off of, not a machine to outsource my brain.

Recently, I saw many posts on LinkedIn that said something like:

"90% of the code I write is done by AI. I don’t type functions or variables anymore. It's all prompts."

"Coding is just an implementation detail now."

That hit me in a weird way.

I get the logic. It's efficient. It's fast. It scales. But it also made me stop and ask:

If writing, building, and crafting things becomes "just a detail" … what are we even doing anymore?

I'm not afraid of AI. I think it's powerful. But I don’t want to live in a world where all our thinking and doing gets handed off to a machine—while we're told to go "focus on business."

Because here is the thing:

- People can still survive without AI.

- We've done it for centuries.

- We still can.

That's how we've evolved: through challenge, through building, through effort.

If AI starts doing our jobs for us…

What’s left for us to grow from? To learn from? To take pride in?

But here’s what really gets me:

Why is so much AI effort focused on coding, writing, and design—

While people still do laundry, clean bathrooms, go grocery shopping, and cook every meal?

Where are the AI products that actually help people in daily life?

We say we're building tools to save time. But most AI right now is built for people who already have time - To help them type faster, ship startups quicker, and raise funding sooner.

I want to see more AI built for:

- The parent with a sink full of dishes

- The overworked caregiver juggling groceries and laundry

- The person who spends more time cleaning than creating

These aren't edge cases. These are real lives.

I know real-world automation is hard. It's messier than code. It doesn't scale as neatly. But it's also where help is actually needed.

Let's not forget:

People don’t just want to be faster.
People want to feel like what they do matters.

If AI makes everything easy, then we better ask:

Are we making life better, or just making people feel replaceable?

I'll say it again — I use AI. But I want it to support me, not define me. I want it to help solve real problems, not just make my commits look impressive.

Let's build a future where AI helps us live better.

Because being human? That's still the point.

External Service testing in Phoenix

Vincent Nguyen — Mon, 14 May 2018 11:37:06 +0000

Getting Started

Before going to the detail, let's me share a little bit about our system - we're using Elixir-Phoenix framework to build a backend system and from the requirement, we need to build an API that can support our front-end client (ReactJS/React-Native) upload files to AWS_S3.

In Phoenix framework, we used an AWS client's hex package called ex_aws to upload files to S3. Basically, the controller code will be:

unique_filename = "#{UUID.uuid4(:hex)}_#{filename}"

{:ok, image_binary} = filepath |> File.read()

Application.get_env(:my_app, :image_bucket_name) |> ExAws.S3.put_object(unique_filename, image_binary) |> ExAws.request!()

ExAWS.request!() will return the status_code is 200 if uploading is successful, otherwise, it will return another status_code.

Uploading module

As usual, we moved uploading code from UploadController to a UploadService module - this will make the controller looks more readable and easy to write the test.

defmodule MyApp.UploadController do
  use MyApp, :controller

  @upload_service Application.get_env(:my_app, :upload_service)
  import UploadService

  def upload_image(conn, params) don
    case upload(params) do
      {:ok, filename} ->
        json(conn, %{url: resolve_url(filename), error: nil})

      {:error, reason} ->
        json(conn, %{url: nil, error: reason})
    end
  end
end

defmodule UploadService do
  def upload(params) do
    %{"file" => %{filename: filename, path: filepath}} = params
    unique_filename = "#{UUID.uuid4(:hex)}_#{filename}"
    {:ok, image_binary} = filepath |> File.read()

    case Application.get_env(:my_app, :image_bucket_name)
         |> ExAws.S3.put_object(unique_filename, image_binary)
         |> ExAws.request!() do
      %{status_code: 200} ->
        {:ok, unique_filename}

      _ ->
        {:error, "can't upload"}
    end
  end
end

Write test for Uploading API

When integrating with external services we want to make sure our test suite isn’t hitting any 3rd party services. Our tests should run in isolation. ThoughBot

With our UploadService module, we don’t need to test the request to S3 because the package itself already test. So, we only need to mock module to return ok or error response.

Setup the corresponding modules for different environments

The development and production environment will use the real UploadService and test environment will use the UploadService.Mock.

# dev.exs and prod.exs
config :my_app, :upload_service, UploadService

# test.exs
config :my_app, :upload_service, UploadService.Mock

And then, we changed a bit in the controller to dynamic loading the corresponding modules.

defmodule MyApp.UploadController do
  use MyApp, :controller

  @upload_service Application.get_env(:my_app, :upload_service)
  @upload_image_token Application.get_env(:my_app, :upload_image_token)

  def @upload_image_token.upload_image(conn, params) don
    case upload(params) do
      {:ok, filename} ->
        json(conn, %{url: resolve_url(filename), error: nil})

      {:error, reason} ->
        json(conn, %{url: nil, error: reason})
    end
  end
end

Next, we will create UploadService.Mock module.

Create a Mocking module

defmodule UploadService.Mock do
  def upload(%{"file" => %{
    "filename" => "success", "path" => _path
  }}) do
    {:ok, "your-file.png"}
  end

  def upload(%{"file" => %{
    "filename" => "fail", "path" => _path
  }}) do
    {:error, "can't upload"}
  end
end

We used pattern-matching with different filename to return ok or error.

Write the test

And now the test will not difficult to write.

test "uploads success", %{image_token: image_token, conn: conn} do
  conn = put_req_header(conn, "authorization", image_token)
  file = %{
    "filename" => "success",
    "path" => "/your/image/path"
  }
  response =
    post(
      conn,
      "/upload",
      %{
        "file" => file
      }
    )

  assert %{"error" => nil, "url" => _url} = json_response(response, 200)
end

test "uploads fail", %{image_token: image_token, conn: conn} do
  conn = put_req_header(conn, "authorization", image_token)
  file = %{
    "filename" => "fail",
    "path" => "/your/image/path"
  }
  response =
    post(
      conn,
      "/upload",
      %{
        "file" => file
      }
    )

  assert %{"error" => "can't upload", "url" => nil} = json_response(response, 200)
end

Conclusion

This is the way how we write test for API without hitting to external services. It could not a good way, so if you guys have any idea, fell free to comment.

Thank you!

Migration scripts (migrate/rollback/seeding) database when releasing a Phoenix/OTP app by Distillery

Vincent Nguyen — Mon, 23 Apr 2018 10:49:03 +0000

Hi everyone!

In this post, I would like to share the migration script (migrate, rollback by step and seeding data) when releasing a Phoenix/OTP application. This script is extended from original Running Migration documentation of Distillery’s creator, I and my colleagues - we wrote more functions to support database rollback and seeding data.

Step 1:

Init a new module

# apps/myapp/lib/migration.ex

defmodule MyApp.ReleaseTasks do
  @start_apps [
    :postgrex,
    :ecto
  ]
  @app :myapp

  def repos, do: Application.get_env(@app, :ecto_repos, [])

  def seed do
    prepare()
    # Run seed script
    Enum.each(repos(), &run_seeds_for/1)

    # Signal shutdown
    IO.puts("Success!")
  end

  defp run_seeds_for(repo) do
    # Run the seed script if it exists
    seed_script = seeds_path(repo)

    if File.exists?(seed_script) do
      IO.puts("Running seed script..")
      Code.eval_file(seed_script)
    end
  end

  def migrate do
    prepare()
    Enum.each(repos(), &run_migrations_for/1)
    IO.puts("Migrations successful!")
  end

  defp run_migrations_for(repo) do
    app = Keyword.get(repo.config, :otp_app)
    IO.puts("Running migrations for #{app}")
    Ecto.Migrator.run(repo, migrations_path(repo), :up, all: true)
  end

  def rollback do
    prepare()

    get_step =
      IO.gets("Enter the number of steps: ")
      |> String.trim()
      |> Integer.parse()

    case get_step do
      {int, _trailing} ->
        Enum.each(repos(), fn repo -> run_rollbacks_for(repo, int) end)
        IO.puts("Rollback successful!")

      :error ->
        IO.puts("Invalid integer")
    end
  end

  defp run_rollbacks_for(repo, step) do
    app = Keyword.get(repo.config, :otp_app)
    IO.puts("Running rollbacks for #{app} (STEP=#{step})")
    Ecto.Migrator.run(repo, migrations_path(repo), :down, all: false, step: step)
  end

  defp prepare do
    IO.puts("Loading #{@app}..")
    # Load the code for myapp, but don't start it
    :ok = Application.load(@app)

    IO.puts("Starting dependencies..")
    # Start apps necessary for executing migrations
    Enum.each(@start_apps, &Application.ensure_all_started/1)

    # Start the Repo(s) for myapp
    IO.puts("Starting repos..")
    Enum.each(repos(), & &1.start_link(pool_size: 1))
  end

  defp seeds_path(repo), do: priv_path_for(repo, "seeds.exs")

  defp priv_path_for(repo, filename) do
    app = Keyword.get(repo.config, :otp_app)
    IO.puts("App: #{app}")
    repo_underscore = repo |> Module.split() |> List.last() |> Macro.underscore()
    Path.join([priv_dir(app), repo_underscore, filename])
  end

  defp priv_dir(app), do: "#{:code.priv_dir(app)}"
end

Step 2:

Create shell script files to call functions:

Migrate script at rel/commands/migrate.sh

#!/bin/sh

$RELEASE_ROOT_DIR/bin/myapp command Elixir.MyApp.ReleaseTasks migrate

Seed script at rel/commands/seed.sh

#!/bin/sh

$RELEASE_ROOT_DIR/bin/myapp command Elixir.MyApp.ReleaseTasks seed

Rollback script at rel/commands/rollback.sh

#!/bin/sh

$RELEASE_ROOT_DIR/bin/myapp command Elixir.MyApp.ReleaseTasks rollback

Step 3:

Setup commands from rel/config.exs

release :myapp do
  set version: current_version(:myapp)
  set applications: [
    :runtime_tools,
    :misc_random,
    admin: :permanent, graphql: :permanent,
    redis: :permanent,
    session: :permanent,
    myapp: :permanent
  ]

  set commands: [
    "seed": "rel/commands/seed.sh",
    "migrate": "rel/commands/migrate.sh",
    "rollback": "rel/commands/rollback.sh",
  ]
end

Step 4:

Once you have deployed the application, you can run:

Migrate

bin/myapp migrate

Seed

bin/myapp seed

Rollback. You can specify how many steps you wanna rollback

bin/myapp rollback

You guys can download the code from my gist. Thanks!

Integration testing Phoenix application with Circle CI 2.0

Vincent Nguyen — Thu, 18 Jan 2018 13:57:57 +0000

Introduction

Writing test cases is a thing that a software developer should do. Writing tests to make sure the quality of project’s source code.

When developing application by Ruby on Rails framework, we often use Capybara.

So which library that we should use if we develop application by Elixir/Phoenix. Hound is an Elixir library for writing integration tests and browser automation. Hound is not a new library, I believe you guys can find a lot of tutorials on Internet that show how to use Hound in Elixir/Phoenix application.

In this post, I will show how to run the integration tests that written by Hound on Circle CI 2.0 for Phoenix application.

Circle CI 2.0

All we know when run integration tests on any CI environment, we need to config for the test can run on headless browser mode that will be setup before CI execute the test.

There are various tools out there to help with headless testing such as PhantomJS, Headless Chrome, Selenium. And there are also many ways to setup these tools on CI environment. For example: In Travis CI, we can use before_script block to run the shell script to install headless testing tool. And in Circle CI 2.0, they supports browser testing out of the box. Sound cool, right?

Getting Started

Specify correct image

To enable headless testing on Circle CI 2.0, the primary image has the current stable version of Chrome pre-installed (this is designated by the -browsers suffix). This means, your .circleci/config.yml file needs to utilize an image with the -browsers suffix.

version: 2
jobs:
  build:
    working_directory: ~/my_application
    docker:
      - image: circleci/elixir:1.5-browsers

Install Selenium driver

Hound use Selenium driver by default, so this step, I’m going to install Selenium on Circle CI 2.0:

steps:
  - checkout
  - run:
      name: Download Selenium
      command: |
        curl -O http://selenium-release.storage.googleapis.com/3.5/selenium-server-standalone-3.5.3.jar
  - run:
      name: Start Selenium
      command: |
        java -jar selenium-server-standalone-3.5.3.jar -log test-reports/selenium.log
      background: true

Run the test

The final step is put all configurations together:

version: 2
jobs:
  build:
    working_directory: ~/my_application
    docker:
      - image: circleci/elixir:1.5-browsers
        environment:
          TEST_DATABASE_URL: postgresql://developer@localhost/my_application_test?sslmode=disable
      - image: circleci/postgres:9.5-alpine
        environment:
          POSTGRES_USER: developer
          POSTGRES_DB: my_application_test
          POSTGRES_PASSWORD: ""

    steps:
      - checkout
      - run:
          name: Download Selenium
          command: |
            curl -O http://selenium-release.storage.googleapis.com/3.5/selenium-server-standalone-3.5.3.jar
      - run:
          name: Start Selenium
          command: |
            java -jar selenium-server-standalone-3.5.3.jar -log test-reports/selenium.log
          background: true
      - run:
          name: Install System Dependencies
          command: sudo apt-get update -qq && sudo apt-get install -y build-essential postgresql postgresql-client libpq-dev rake nodejs unzip
      - run: mix local.hex --force
      - run: mix local.rebar
      - run: mix deps.get
      - run: MIX_ENV=test mix ecto.create
      - run: MIX_ENV=test mix ecto.load -d apps/my_application/priv/repo/structure.sql
      - run: mix test

Conclusion

Getting Phoenix integration test and Circle CI to work in harmony is not difficult. Hope you enjoyed and feel free to let me know your comment. Thanks!

Source: https://thefirstapril.com/2018/01/18/Integration-testing-Phoenix-application-with-Circle-CI-2-0/