제가 불로장생약 개발을 시작했을 때 알았으면 좋겠어요.

이것들은 내가 elixir 개발 작업 절차에서 자주 사용하는 것들로 흥미를 끌 수 있다.

elixir와erlang의 여러 버전 관리
한 번에 여러 항목에서 작업을 해야 할 때, 이것은 다른 elixir와erlang 버전을 처리해야 한다는 것을 의미할 수 있기 때문에 운영체제에서 제공하는 기본 버전을 설치하는 것은 도움이 되지 않을 것입니다.이곳은 asdf 이 문제를 해결하는 곳입니다. asdf 우리는 같은 기계에 서로 다른 버전의 elixir,erlang과 다른 언어를 가지고 있어서 쉽게 전환할 수 있습니다.
macOS에서 brew install asdf로 설치하고 설치 프로그램에 따라 출력하는 설명에 따라 설정할 수 있습니다PATH. 더 많은 정보는 Github 페이지https://github.com/asdf-vm/asdf 참조
현재 설치asdf되어 있습니다erlang와 elixir를 처리하기 위해 플러그인을 설치해야 합니다. 다음과 같은 방법으로 설치할 수 있습니다.

asdf plugin add erlang
asdf plugin add elixir

이를 설치한 후에는 프로젝트에서 사용할 버전을 정의해야 하며 다음과 같은 여러 가지 방법이 있습니다.

환경 변수 사용
우리는 ASDF_ 접두사를 사용하여 환경 변수를 정의하여 필요한 버전을 설정할 수 있기 때문에 버전 elixir1.10가 필요하다면 값ASDF_ELIXIR_VERSION 정의 변수1.10를 사용해야 한다. 이것은erlang이나 다른 프로그래밍 언어에도 적용된다.
예를 들어, elixir 및 erlang의 변수를 다음과 같이 정의할 수 있습니다.

export ASDF_ELIXIR_VERSION=1.10.3-otp-22
export ASDF_ERLANG_VERSION=22.3

To handle environment variables in a easy way we can use direnv, it allows to define environment variables in a file .envrc and it will loaded automatically as soon as we enter to out project folder.

파일 기반 프로파일asdf 프로젝트에 필요한 모든 버전을 배치할 수 있는 .tool-versions 파일을 정의할 수 있습니다. 예를 들면 다음과 같습니다.

erlang 23.0.2
elixir 1.10.4-otp-23

새 항목 만들기
프로젝트에서 사용하는 버전을 먼저 정의해야 하기 때문에 mix new my_app만 실행할 수 없습니다. asdf는 우리가 어떤 버전을 원하는지 모르기 때문입니다.이를 위해 다음과 같은 두 가지 옵션이 있습니다.

예를 들어 asdf global elixir 1.9.0와erlangasdf global erlang 22.3을 사용하여elixir와erlang의 전역 버전을 정의한 다음에 우리는 정상적으로 실행할 수 있다mix new my_app

명령에 대해서만 정의된 버전을 실행합니다. 예를 들어 mix new 그러면 전역 범위에 영향을 주지 않고 창설된 프로젝트에서 같은 버전을 정의할 수 있습니다.

새 프로젝트를 만들 때마다 전역 버전을 변경할 필요가 없고, bash 역사에서 명령을 쉽게 접근할 수 있기 때문에 두 번째를 좋아합니다.

erlang 컴파일에 대한 주석ASDF_ELIXIR_VERSION=1.9.0 ASDF_ERLANG_VERSION=22.3 mix new my_app 백엔드에서 asdferlang 컴파일을 처리합니다. 새 버전을 설치할 때 자바 설치를 요구합니다.😕, 이러한 동작을 방지하기 위해 다음과 같은 환경 변수를 정의할 수 있습니다.

export KERL_CONFIGURE_OPTIONS="--disable-debug --without-javac"

외계 데이터베이스 url
프로젝트에서 데이터베이스를 처리하는 경우 EXTO를 사용할 수 있습니다.Ecto를 사용하면 두 가지 방법으로 데이터베이스 자격 증명을 정의할 수 있습니다. 첫 번째는 다음과 같이 개별적으로 정의합니다.

config :my_app, Repo,
  database: "ecto_simple",
  username: "postgres",
  password: "postgres",
  hostname: "localhost"

두 번째는 고유한 매개변수를 사용하는 것입니다.

config :my_app, Repo,
  url: "postgres://postgres:postgres@localhost/ecto_simple"

다음과 같은 이유로 이것이 내가 가장 좋아하는 선택이다.

하나의 값만 유지 관리

이런 형식은 kerl에서도 받아들여진다. 예를 들어 우리는 psql를 실행하고 데이터베이스에 연결할 수 있다.나는 몇 주 전에야 비로소 발견하였다😅

우리는 증거를 변경할 수 있다. 예를 들어 환경 변수

에서 값을 불러올 때psql postgres://postgres:postgres@localhost/ecto_simplemix 명령을 실행할 때 미리 설정값DATABASE_URL=postgres://postgres:postgres@localhost/test_db mix something만 하면 된다.
그리고 DATABASE_URL라는 변수에 연결된 URL이 있다면 당연히 사용해야 한다direnv😉, 데이터베이스 세션으로 psql $DATABASE_URL만 실행하면 됩니다.

iex 사용

셸 기록 사용하기
elixiriex의 멋진 특징은 모듈을 불러오고 다시 컴파일할 수 있다는 것이다. 그러나 우리가 때때로'큰'코드 세션을 실행하거나 코드나 다른 상황을 이해하려고 할 때 세션을 다시 시작해야 할 때 우리는 모든 역사 기록을 잃어버렸다.😢, -kernel shell_history enabled 세션을 시작하기 전에 환경 변수ERL_AFLAGS에 로고iex를 추가하여 이러한 상황을 피할 수 있습니다.나는 단지 나의 .zshrc에 다음 코드를 추가하여 나의 모든 항목에 사용할 수 있도록 했다.

export ERL_AFLAGS="-kernel shell_history enabled"

별칭 미리 로드
또 다른 짜증날 수 있는 것은 하나의 큰 모듈 이름에 별명을 붙이는 것이다. 예를 들어 MyApp.Contexts.Authentication.User가 있고 이 모듈을 자주 사용한다면 iex 세션을 시작할 때 불러오는 것이 더 쉬울 것이다. 프로젝트 루트 디렉터리에 .iex.exs 파일을 정의하고 필요한 별명을 사용해서 이를 실현할 수 있다. 예를 들어:

alias MyApp.Contexts.Authentication.User

이제 우리가 새로운 iex 세션을 시작할 때, 우리는 처음부터 이 모듈에 별명을 사용할 것이다. 그러면 우리는 문제없이 사용할 수 있다. User.whatever

Keep in mind that even if we can make an alias(a module name is just an atom) when we starting a session using just iex we cannot access to its functions. We need to start our iex session using iex -S mix

모듈 재컴파일iex 세션에서 우리는 r module_name만 작성하는 모듈을 다시 컴파일할 수 있다. 사용자가 우리가 실행할 수 있는 모든 항목recompile을 다시 컴파일하려면 코드를 변경할 때 매우 유용하다. 우리는 우리가 정의한 모든 값을 사용하여 테스트를 해야 한다.그것도'REPL 기반 개발'이라고 불리며 lisp 기반 프로그래밍 언어로 가장 많이 사용되지만 elixiriex에도 이런 좋은 기능을 사용할 수 있다.

혼합 작업
이것들은 mix 실행할 수 있는 임무입니다.그러나 우리는 그것들을 만들고 프로젝트에서 사용할 수 있다.예를 들어, 우리는 일부 코드를 디버깅하고 있을 수도 있다. 우리는 긴 프로세스 (업무 프로세스) 를 실행하고 싶지 않고, 단지 함수 호출을 추출한 후에 기존 데이터를 사용하여 혼합 작업에서 그것들을 실행한다.다음 코드를 사용하여 블렌드 작업을 생성할 수 있습니다.

defmodule Mix.Tasks.Foo do
  @moduledoc false
  use Mix.Task

  def run(_args) do
    Application.ensure_all_started(:my_app)
    IO.puts("runnning...")
  end
end

우리는 이 파일을 foo.ex로 명명하고 lib 폴더에 넣어야 한다. 현재 우리는 mix foo를 실행할 수 있고 running... 메시지를 받을 수 있다.
나는 여러 번 사용한 적이 있는데, 실제로 나는 많은 항목에서 몇 가지 임무를 정의했다. 반복해서 사용해서 업무 흐름을 디버깅하는 것이 아니라.

I know that we "should" be defining the cases that we are debugging in a test, run it and then try to fix the code and then run the tests again but this way works for me so I'm OK with that 🙃

현지 제3자 도서관과 합작
어떤 상황에서 우리는 제3자 라이브러리가 어떻게 작동하는지 더 깊이 이해하고자 하는 버그를 발견할 수 있다.이 경우 프로젝트에서 사용하는 라이브러리의 로컬 버전을 설정하기가 어려울 수 있습니다.
나는python에서justpip install -e path_to_library를 사용했고 라이브러리 코드를 바꾸기 시작한 것을 기억한다.
elixir에서 라이브러리의 로컬 버전을 설치하려면 mix.exs 파일에 경로를 지정할 수 있습니다. 예를 들어 다음과 같습니다.

defmodule MyApp.MixProject do
  use Mix.Project

  def project() do
    [
      app: :my_app,
      version: "0.0.1",
      elixir: "~> 1.0",
      deps: deps(),
    ]
  end

  def application() do
    []
  end

  defp deps() do
    [
      {:ecto, "~> 2.0"},
      {:postgrex, "~> 0.8.1"},
      {:ecto_sql, path: "ecto_sql_local_path"}
    ]
  end
end

이 예에서, 우리가 우리에게 알려준 프로젝트는 주어진 ecto_sql 설치 path 로부터 설치되어 있지만, 이것은 첫 번째일 뿐이다. 왜냐하면 이것은 시작할 때 불러오고 컴파일되기 때문이다. ecto_sql 그리고 ecto_sql_local_path 의 코드를 변경할 때, 이 변경 사항들은 자동으로 다시 컴파일되지 않기 때문이다. mix 프로젝트 내부의 변경 사항에만 관심을 가지기 때문이다.이러한 상황에서 우리는 r Ecto.Migrator 세션에서 iex를 사용하여 일부 모듈을 강제로 재컴파일할 수 있지만, 만약 우리가 더 많은 모듈을 수정하려고 한다면, 그 중의 모든 모듈을 수동으로 재컴파일하는 것은 매우 번거롭다. 이러한 상황에서 우리는 Recompiler 모듈을 정의해서, 사용자가 필요로 하는 명칭에 따라 다음과 같이 포함시킬 수 있다.

defmodule Recompiler do
  def run do
    modules_to_recompile = [
      Ecto.Migrator,
      Ecto.SomeOtherModule
    ]

    for module <- modules_to_recompile do
      IEx.Helpers.r(module)
    end
  end
end

이 모듈을 lib 폴더의 어느 곳에 두면 Recompiler.run 세션에서 iex 호출할 때 정의된 모든 모듈을 다시 컴파일할 수 있습니다.