몇 가지 생각을 공유해 보겠습니다.
질문의 전제가 Python 개발자에서 Discourse 관련 개발로 전환할 수 있는지에 대한 것이라면, 답은 조금 더 복잡합니다.
이미 발견하셨듯이, Python에서 Ruby로 넘어가는 과정은 비교적 단순합니다. Python에서 할 수 있는 일을 Ruby에서도 수행하려면 단순히 의미론적 차이만 익히면 됩니다.
그러나 몇 년 전 저 역시 같은 전환을 경험했는데, Python에서 하던 일을 Ruby에서도 그대로 하려 하면 Ruby를 ‘Ruby답게’ 만드는 요소들을 놓치게 됩니다.
두 번째로, Discourse의 뉘앙스에 대해 말씀드리겠습니다.
백엔드가 Ruby 기반이지만, Discourse에서 무언가를 만들 때의 '복잡성’은 백엔드(Ruby)와 클라이언트(JavaScript/Ember)를 조화롭게 동작시키도록 개발하는 데 상당 부분 있습니다.
Ruby 사용법에 대한 충분한 이해가 있더라도, Discourse 백엔드가 어떻게 기능하는지 이해하는 데도 시간을 투자해야 합니다. 데이터 접근/데이터 구조, 로깅, 프로세스 간 메시지 전달, 비동기 작업 등 백엔드가 플러그인에 제공하는 훌륭한 생태계가 있습니다. 이 부분을 잘 이해하는 것이 중요하다고 느꼈습니다.
Ruby를 살펴보는 것은 정말 보람 있는 일이었지만, 제 필요에 비해 프론트엔드 JavaScript는 너무 도전적이라고 느꼈습니다. 저는 몇 년 경력의 취미 코더이기 때문에, 이는 제 경험 부족과 민첩하지 못한 사고방식 때문이라고 생각합니다.
그럼에도 불구하고, Svelte와 같은 다른 JavaScript 프레임워크는 파악할 수 있었습니다. Ember 특유의 것과 엄격한 인스턴스화 흐름/조율, 폴더 구조는 저와 제 필요에 비해 다소 복잡했습니다.
제 해결책은 훌륭한 Custom Wizard 플러그인을 사용하여 프론트엔드 상호작용을 포착한 후 백엔드 Ruby 코드로 전달하는 것이었습니다. 이는 배치형 프로세스에서는 잘 작동하지만, 인터랙티브 환경에서는 덜 유용합니다.
행운을 빕니다.