편지 광장: 부검(LiveView의 믿을 수 없는 복제자)

최근에 배우고 싶습니다Phoenix LiveView. 이것은 Phoenix 프레임워크를 바탕으로 하는 불로장생의 약고로 실시간 응용 프로그램을 구축하는 데 사용됩니다.
이 프로그램의 주요 특징은 서버에서 HTML을 보여줌으로써 프로그램이 완전히 Elixir로 작성될 수 있도록 하는 것이다. (비록 모든 용례를 자바스크립트로 바꿀 수 없지만, 웹소켓을 설정하고 DOM을 업데이트하는 데 의존한다.)
어쨌든, 그것은 발표된 이래로, 나는 줄곧 그것을 주목해 왔지만, 진정으로 그것을 시도할 시간이 없었다.나는 마침내 시간을 찾았다. 그것을 배우기 위해서, 나는Boggle 클론을 만들기로 결정했다. Letter Square
나의 계획은:

네트워크상의 동적 Boggle(게임에 익숙하지 않으면 the rules을 보십시오.

사람들은 같은 알파벳 격자 위에서 놀 수 있다.

게임이 끝날 때 랭킹이 표시되며 유저는 다음 게임이 시작될 때까지 일정 시간 채팅을 할 수 있습니다.

나는 또한 실제 온라인 배치를 통해 가능한 한 그것을 보완함으로써 일의 진일보한 발전을 추진하고 싶다.

3주 동안의 개발 과정에서 배운 것을 이야기해 봅시다.

Boggle 게임 작성

LiveView에 들어가기 전에, 나는 게임 자체를 위해 규칙과 조수를 프로그래밍했다.이것은 단어 목록에서 단어를 찾고 점수를 계산하는 알파벳 격자를 만드는 것을 포함한다.

격자에서 단어 찾기

알고리즘 애호가로서 이것은 나에게 있어서 가장 재미있는 부분 중의 하나이다.내가 실현한 알고리즘의 전체적인 사고방식은 다음과 같다.

메쉬의 한 위치에서 시작

이 위치의 모든 유효한 경로를 거슬러 올라갑니다.각 단계에서 다음을 수행합니다.

현재 경로가 사전에 존재하는 단어를 형성하면 목록에 추가하십시오.

사전에 현재 자모 서열로 시작하는 단어가 없으면 더 이상 탐구하지 마십시오.

메쉬의 각 위치를 반복합니다.

사전에 단어가 있는지, 아니면 접두사로 시작하는 단어가 있는지 효과적으로 검사하기 위해서 trie 를 사용했습니다.나는 작은 불로장생의 약고를 찾았는데, 마침 나의 수요를 만족시켰다.
그것은 내가 그것을 무료 Gigalixir 실례에 배치할 때까지 잘 작동했다. 이 실례의 메모리는 500MB로 제한되어 있다.5MB 사전을 로드하고 trie로 변환한 결과 메모리가 너무 많이 사용되었습니다.
나는 블록에 따라 사전을 불러오는 우아한 해결 방안을 찾았다.모든 블록에 대해 나는 그것을 비교적 작은 사전으로 간주하고 위의 알고리즘을 사용하여 단어를 찾을 수 있다.그리고 나서 나는 사전 한 권을 다 읽을 때까지 한 단락 한 단락을 반복했다.Retrieval를 사용하면 초기 함수를 업데이트할 필요가 없을 정도로 간단합니다.

defmodule WordSearch do
  def list_all(grid, dictionary) when is_list(dictionary) do
    # My initial implementation, taking a list of words
  end

  def list_all(%Grid{} = grid, dict_stream) do
    dict_stream
    |> Stream.chunk_every(5_000)
    |> Stream.map(fn subdictionary ->
      list_all(grid, subdictionary)
    end)
    |> Enum.into([])
    |> List.flatten()
    |> Enum.sort_by(&String.length/1, :desc)
  end

  # ...
end

시냇물 메쉬 생성

나의 첫 번째 격자 랜덤 생성의 실현은 매우 간단하다. 모든 자모는 독립적으로 선택한 것이고, 한 자모를 선택할 확률은 언어의 주파수에 달려 있다.
이런 기술을 사용하면 나는 곧 문제를 만났다. 찾으려는 단어의 수량이 보통 매우 적기 때문에 격자가 너무 딱딱하고 재미있지도 않다.많은 격자에 너무 많은 자음이 모음에 연결되지 않았다.
그래서 다른 방법을 시도해 봤어요.나는 자모를 독립적으로 생성하지 않고 격자 안에서 자모를 생성하는 무작위 경로이다.경로의 첫 번째 문자는 완전히 무작위로 선택되지만, 다음 문자의 선택은 경로의 첫 번째 문자에 달려 있다.확률은 사전에서 계산된 쌍자모 그룹 (쌍자모) 의 주파수에 근거한다.이런 기술을 사용하면 사전에서 찾을 수 있는 인접 자모가 격자에서도 함께 있을 수 있다는 것을 확보할 수 있다.
이것은 매우 복잡한 기술이지만, 각 격자의 평균 글자수가 증가함에 따라, 그것은 보답을 받았다. (비록 나는 그것을 측정하지 않았지만.)긴 단어도 빈번해졌다.

단어 목록 찾기

또 하나는 도전이 될 줄은 몰랐지만, 사실은 밤새도록 좋은 단어 목록을 찾아서 사전으로 사용했다.
맞춤법에 사용되는 공식 어휘 목록은 인터넷에서 찾을 수 있지만, 자유롭게 사용할 수 없을 것 같다.다른 목록은 폐기된 웹 페이지와 리콜 프로토콜에서 어디서나 볼 수 있지만, 그것들의 좋고 나쁨은 영원히 명확하지 않고, 종종 이상하거나 짜증나는 형식으로 나타난다. (예: XLS)마지막으로 나는 의 하나를 썼지만, 나는 여전히 그것의 질을 믿지 않는다.

이 GitHub 저장소 Phoenix LiveView&Surface

내가 좋아하는

그 후에 저는 Phoenix LiveView로 인터페이스의 행동을 실현했습니다.트림을 몇 번 하는 것 외에 매우 가볍고 편안함을 느낀다.나는 Elixir만 사용해서 모든 일을 하는 것을 좋아한다. 자바스크립트에 신경 쓸 필요도, API를 구축해서 둘을 연결할 필요도 없다. 이것은 훨씬 복잡할 것이다.마지막으로, 나는 심지어 내가 CSS를 정확하게 사용하려고 더 많은 시간을 쓰지 않았는지 알고 싶다.
나도'바닐라'라이브뷰를 사용하지 않았다. 왜냐하면 나는 라이브러리를 사용했기 때문이다.이것은 LiveView를 둘러싼 포장기로서 새로운 문법을 가져와 체험을 더욱 편안하게 한다.
예를 들어, 다음은 내 구성 요소 중 하나에 대한 코드로 남은 시간을 표시합니다.
Surface
보시다시피 Surface는 템플릿에 ~H 기호를 가져왔습니다. 이것은 Vue와 매우 유사한 문법을 사용하고 {{ }} Elixir 삽입을 사용할 수 있습니다.나는 지금까지 Phoenix의 문법을 좋아하지 않았고, 항상 Vue의 문법을 좋아했기 때문에, 이것은 즉각적으로Surface를 시도하도록 설득했다.
Vue와 마찬가지로 주기와 조건은 외부 속성이 아닌 HTML 태그 내부의 특수 속성으로 이루어져 추가 중첩 단계를 방지합니다.
표준 피닉스:

<ul>
  <%= for item <- @items do %>
    <li>
      <%= item.name %>
    </li>
  <% end %>
</ul>

표면:

<ul>
  <li :for={{ item <- @items }}>
    {{ item.name }}
  </li>
</ul>

속성, 내부 데이터, 슬롯 또는 이벤트는 모듈 상단에 정의되어 즉시 볼 수 있습니다.이 구성 요소의 이름은 예시된 Stat 구성 요소와 같이 다른 구성 요소에서 사용할 수 있습니다.이 슬라이드에서는 LiveView 방식보다 간단하고 표현력이 뛰어납니다.

<%= live_component @socket, Timer, seconds: @seconds %>

Surface는 나만 할 수 있다.

<Timer seconds={{ @seconds }} />

LiveView와 Surface가 모두 젊다는 점을 감안하면, 나는 그들이 공동으로 이룩한 성과에 놀라움을 느꼈고, 나는 그들이 어떻게 발전할지 보고 싶어 죽을 지경이었다.

이것보다 더 좋은 것이 있습니까

몇 가지 일이 나로 하여금 약간의 시간을 잃게 했다.

LiveView는 일반적으로 자바스크립트를 작성하지 않아도 상호작용 페이지를 만들 수 있는 방법으로 묘사된다(나는 심지어 본문에서도 이렇게 했다).그럼에도 불구하고 JavaScript를 사용하거나 JavaScript를 사용하기에 더 적합한 경우도 있습니다.이 경우 아직 필요하지 않은 상황에서 자바스크립트를 사용할 동기를 찾기가 더 어렵다.나는 아직 제한을 어디에 두어야 할지 확실하지 않다.

마찬가지로 LiveView와 Surface 사이의 분리도 간혹 불분명하다.한편, LiveView 자체의 함수를 허용하거나 사용해야 하는지, Surface에 의존해야 하는지 항상 확인하지는 않습니다.다른 한편,Surface 문서는 일반적으로 LiveView가 어떻게 작동하는지 알고 있다고 가정하고, 최종적으로 사용하지 않을 것을 미리 알도록 강요합니다.

서피스에 대해 Vue처럼 보인다는 사실은 모든 것이 Vue처럼 작동할 것이라고 생각한다.그 자체가 문제가 되지는 않지만, 만약 당신이 Vue에서 왔다면, 그것은 때때로 좀 곤혹스러울 수도 있으니 주의하십시오.특히 사건의 작업 방식은 완전히 같지 않다.

LiveView에서 콜백이 두 번 호출되었습니다.이 방면에는 mount 가 있는데 문서에서도 이 점을 언급했다.그러나 나는 이 점을 놓쳤다. 처음에는 곤혹스러웠다.나는 그곳에서 상당히 무거운 행동을 촉발했기 때문에 정말 두 번은 하고 싶지 않다. 단지 두 번째 탈것만 하고 싶다.나는 왜 두 탈것이 반드시 같은 기능을 사용해야 하는지 여전히 모르겠다.

좋은 이유 하나. Gigalixir를 사용한 배포

배치에 대해서는 의 무료 옵션을 사용했습니다.앞에서 말한 바와 같이 나는 500MB로 제한되어 있어서 일부분을 매우 곤란하게 한다.그러나 가격으로는 이미 상당히 높다.
이 일에 관해서 나는 거의 할 말이 없다. 단지 그것이 한바탕 미풍이라고 말할 뿐이다.한 시간도 안 되어 내 프로그램이 실행되기 시작했는데 업데이트가 한 발자국도 남지 않았다git push.또한 로그와 콘솔에 쉽게 액세스하여 CPU와 메모리 액세스를 모니터링할 수 있습니다.
Phoenix Gigalixir 문서를 따랐기 때문에 프로그램에 이름을 붙일 수 있는 문서가 없습니다.따라서 URL에서 사용되는 기본 이름quirky-barren-canvasback을 얻었습니다. 다른 선택의 여지가 없이 실례를 삭제하고 새 실례를 만들어서 이름을 변경할 수 있습니다.

Gigalixir에 배포 결론

어쨌든, 이것은 아주 좋은 경험이었다. 나는 LiveView와 Surface에 관한 프로젝트를 더 많이 하고 싶었다.내가 무의식중에 발견한 문제는 모두 커다란 장애 요소가 아니다. 그 중 대다수는 이 두 항목이 모두 아직 젊기 때문일 것이다.나는 그들이 갈수록 좋아질 것이라고 조금도 의심하지 않는다. 나는 언젠가 공헌을 할 수 있기를 바란다.