Re: VIEW와 GiitHub을 사용하여 기술서 계약서를 작성하면(엔지니어가 아닌 사람 포함)

이번에 씨98공기코미켓에는 디스코드의 그룹 멤버들이 함께 공동 잡지를 발간했다.그리고 두 권 더 있어요.
자세한 내용은 아래 트위터 등을 확인해 주세요.
그렇다면 이번 집필에서 리바이브와 지아이허브를 활용해 집필 환경을 구축했기 때문에 설명하고 싶다.

과거의 제본 방법

스튜디오에서는 C96과 C97이 이미 두 차례 공동잡지를 발간했다.
그때는 Google Doctoment와 Markdown을 사용했습니다.
다만, 어떤 경우든 문제가 있다.

GoogleDoocument의 경우 각자 자유로운 스타일로 쓰기 때문에 포맷을 통일하기 어렵다

Markedown이라면 포맷을 통일할 수 있지만 디렉터리 생성과 페이지 번호 등'책'의 질을 높이기 어렵다

이러한 문제를 해결하기 위해 이번에는 Re:VIEW를 사용하여 원고를 쓰기로 결정했습니다.
(참고로 저는 이번부터 운용팀으로 참가하겠습니다.)

Re: VIEW란 무엇입니까?

Re: VIEW 공식 웹 사이트
Re:VIEW는 전자책과 종이책에 사용되는 간결하고 강력한 디지털 출판 도구이다.컴퓨터책 등 기술서적(종이·전자)에 쓰이는 상업출판과 동인출판.
이번에는 PDF로 출력하는 기능만 사용했는데 ePub 등의 형태로도 출력할 수 있을 것 같다.
최근에는 기술서적 등에서도 많이 활용되고 있다.
카탈로그 자동 생성 등을 책으로 활용하는 체제를 통합해 유용한 판단으로 활용하기로 했다.

Re:VIEW Starter 활용

주변에 약간의 자신감이 없다는 설정으로 C98이 골든위크에서 진행하는 관계 준비 기간에 충분히 확보하지 못해 이번에 활용했다Re:VIEW Starter.
초기 설정은 GUI로 할 수 있고, LaTex 지식이 없어도 이미 조정돼 초보자도 쉽게 이용할 수 있다.
자세한 설명은 제작자의 Qita 보도이 있으니 저쪽을 보세요.

GiitHub 활용에 대한 집필.

이번에는 지티허브를 활용해 글을 쓰기로 했다.
두 가지 이유가 있다.

1. 집필자의 증가에 따라 관리 원가를 통제한다.

원래 Google Drive를 이용하여 파일 등을 교환합니다.
그러나 C98을 대상으로 한 공동잡지는 두 종류로 제작돼 집필자가 더 늘어날 것으로 보인다.
구글 드라이브로 커뮤니케이션을 진행하면 관리 비용은 인원 증가에 따라 증가한다.
GiitHub을 유연하게 활용함으로써 글쓰기와 교정 등 관리 비용을 억제할 수 있다.

2. Re: VIEW의 구축 난이도

Re:VIEW(Re:VIEW Starter)는 자신의 컴퓨터에 최소한의 Docker 지식을 필요로 한다.
하지만 이번에는 엔지니어가 아닌 사람과 Docker에 익숙하지 않은 사람도 많아 PDF 구축이 매우 어려운 상황이다.
잠시 후 GiitHub Actions를 활용해 이를 GiitHub에 push하면 누구나 PDF 구축이 가능하다는 점을 상세히 설명할 예정이다.

GiitHub의 집필 프로세스 활용

대략적인 구성은 다음과 같다.

실제로는 집필 순서대로 설명한다.

작문을 준비하다

집필환경부터 구축해야 한다.집필자마다 다음과 같은 전용 요구를 준비했다.

지트에 익숙하지 않은 사람도 있어 지부 운용을 단순화하기 위해 1집필자에게 1PR(1지부) 형식을 적용했기 때문이다.
브랜드 홍보의 관리 원가를 낮추는 목적도 있다.
clone은 이 지정된 PR의 지점 집필을 하세요.

글을 짓다

지정된 브랜치에서 PR에 작성된 편집 가능한 파일, 폴더만 편집합니다.
다른 서류를 만들면 충돌 등이 발생할 가능성이 기본적으로 금지돼 있기 때문이다.
이 운용은 집필에 큰 장애가 없다.

PDF 장정 확인

PDF 확인 방법은 두 가지입니다.
첫 번째는 GiitHub에서 push를 해서 CI가 생성한 것을 확인하는 방법으로 누구나 쉽게 만들 수 있다.
GiitHub Actions 설정 방법은 이쪽 기사에 적혀 있고 자세한 내용은 저쪽을 확인해 주세요.
GiitHub Actions를 사용한 Re:VIEW Starter PDF 구축
두 번째는 docker의 이미지를 사용하여 구축하는 방법입니다.
Re:VIEW Starter에서 빌딩용docker 이미지을 준비해 그곳을 이용해 빌딩을 진행한다.make 명령 활용

make build

간편하게 구축할 수 있습니다.

작문을 완성하다

집필이 완료되면 모두 제출해 PM에 떠넘기고, PM 확인을 거쳐 집필이 일정 기간 완료된다.
이 상태에서 PR은 병합됩니다.

교정하다

일단 작문을 마친 후에 교정을 진행할 것이다.
교정은 각 집필자가 교정 지점을 다시 잘라서 PR을 보내도록 하는 것이다.
각 집필자는 PR에서 교정 내용을 확인하고 승인 또는 수정한다.
교정이 끝난 후 집필자의 업무는 끝났다.
교정 이외에 잊어버리고 쓰는 등 정정하고 싶은 부분이 있다면 PR을 다시 만들어 수정 대응했다.

Re: VIEW에 대한 메모

Re: VIEW의 기법에 익숙하지 않으면 쓰기가 좀 어려워요.
따라서 자주 사용하는 기법에 대해 위키에서'Re:VIEW 기법 블러셔표'형식으로 정리했다.
또한 블러셔 기법에는 리: VIEW Starter 맞춤형 기법을 사용하는데 우선적으로 사용하기 위한 것이다.

또 Mardown에 익숙해진 사람도 있기 때문에 Mardown과 Re:VIEW의 대응표도 준비했다.

전체에 대한 주지법

지금까지 설명한 내용을 모두 전달하기 위해 미리 위키피디아에서 정리했다.
또 집필과 별개로 리뷰 구성 등이 기재돼 있는데 최악의 목표는 스스로 떨어져도 운용할 수 있는 형식이다.

지트를 못 배운 사람들에 대한 대응.

기릿허브를 쓰는 전제이기 때문에 기릿을 배우지 않으면 집필이 어렵다.
그래서 이번에는 작가가 좋아하는 방법을 선택하도록 두 가지 방법을 제시했다.

Giit의 사용법을 개별적으로 설명하고 이번 집필에 필요한 최소한의 Giit

를 배운다.

Google Doocument에서 집필하고 운용팀 Re: VIEW에서 작성하십시오

지트 설명을 할 때는 디스코드의 화면으로 확인 손 옆을 공유하면서 음성으로 지시하면서 설명한다.
집필의 절차는 상술한 것과 같다.
Google Docoment를 사용할 때 Google Docoment에서 교정을 포함한 모든 집필 작업을 수행합니다.

실제 갔을 때의 문제점에 관하여

이 방법으로'새로운 도전을 하고 싶을 때 보는 책Vol3'집필과'자신이 도전했을 때 하는 말을 이야기하는 책'에 대한 문제점을 적는다.

1. 글쓰기 설명은 엔지니어가 아니면 이해하기 어려운 부분이 있다

위키에는 글쓰기에 대한 설명이 기재돼 있지만 비엔지니어에게는 설명하기 어려운 부분이 있다.
기트를 이해한다는 전제하에 wiki를 썼기 때문에 이런 문제가 발생할 수 있다.

2. Giit의 설명 및 Re: VIEW 기록에 따른 비용

이번에는 엔지니어가 많아서 Giit에 대한 설명과 Re:VIEW에 대한 기록 처리가 많지 않다.
하지만 GTI를 사용하지 못하는 사람이 늘어나면 운용팀이 쓰는 비용이 커진다.
이런 상황에서 대응하는 방법을 연구할 필요가 있다.

3. Push를 사용하지 않으면 PDF를 구축할 수 없기 때문에 매우 힘들다

Docker 사용법을 모르면 GiitHub push 외에는 PDF를 만드는 방법이 없습니다.
이런 상황에서 그림의 크기를 조정하고 구축 오류를 해결할 때 매번push가 구축을 기다려야 하기 때문에 매우 번거롭다.
구축에 관한 오류는 기본적으로 제가 확인하고 해결했지만 이미지 사이즈에 대해서는 본인이 확인해야 합니다.

향후

나는 최초로 향상된 책의 품질의 목적이 이미 완전히 달성되었다고 생각한다.
하지만 엔지니어가 아니면 출전 문턱이 높아진다.
하지만 이번에 집필한'도전장'과'자설서'에는 엔지니어 이외의 분들도 적극적으로 참여해주셨으면 좋겠습니다.
앞으로 나는 글쓰기의 문턱이 낮고 원가가 낮은 글쓰기 환경을 탐색할 것이다.