9Cells

NineBoard 개발일지

2020-08-26

2020-08-08

2020-08-07 금요일

2020-08-01 토요일 ~ 2020-08-06 목요일

웹 인터페이스로 글 작성을 지원하기 위해 파일에 작성하던 meta정보를 db로 옮기는 작업이 있었음.

2020-07-17

자동차 커뮤니티를 만들기로 했다. 대부분 게시판으로 이뤄져있는 기획이기 때문에 기존 코드를 활용한다. CMS를 만들고 자동차 커뮤니티 뿐만 아니라 다른 게시판 기반 사이트를 만드는 것에 사용할 수 있게 구성한다.

2020-07-02

2020-07-01

2020-06-29

entry 테이블의 content에 메타 데이터를 빼야함

웹 버전 편집기가 만들어진다면 사용자가 content에 메타를 입력하는 일은 없을 것이다.

메타에 들어가는 것은 모두 db의 여러 필드로 나뉘어 들어가야 한다.

원래는 메타를 저장하지 않는 버전도 있었으나 파일 업로드를 통한 업데이트 기능을 만들면서 content 변경을 업로드로 감지하다보니 메타도 저장하게 됐다.

content에서 메타가 빠지면 메타의 내용은 여러 필드에 저장될 것이므로 파일 업로드 변경 감지는 메타 비교가 아닌 필드를 비교하는 식으로 바뀌어야 한다.

메타 데이터에서 Twig를 YAML로 변경 필요

현재 문서 전반적으로 Twig 문법을 사용 중이고 메타를 읽을 때도 Twig 렌더링을 하고있다.

문서 본문에서 Twig function을 사용하는 경우가 있는데 메타를 렌더링 하면서 본문도 같이 렌더링 된다.

문서가 links 태그로 스스로를 포함하는 경우가 생겼는데 이 때 렌더링이 무한루프를 돌면서 종료되는 문제가 발생했다.

이 문제를 해결하기 위해 메타를 YAML 같은 언어를 사용하여 파싱하고 메타를 얻는 동안 본문이 렌더링 되는 것을 피해야한다.

앞선 결정(entry 테이블의 content에 메타 데이터를 빼야함)에서 메타는 db에 저장하기로 했으므로 DB에서 글을 읽어오는 시점에 메타의 렌더링 자체가 불필요할 수도 있다.

하지만 DB와 File을 동시에 지원하게 될 수도 있는 것이고 메타 데이터를 얻는 동안 본문도 렌더링 되는 문제를 근본적으로 해결하려면 메타에서 다른 언어를 사용하는 것이 좋아보인다.

2020-06-24

2020-06-23

2020-06-21

2020-06-19

2020-06-18

inotifywait를 사용하여 SFTP 파일 업로드를 감지하고 파일을 DB에 저장하도록 변경. 결과적으로 데스크탑 markdown 에디터로 서버 콘텐츠를 수정할 수 있게 함.

2020-06-17

파일을 어디까지 활용할까?

2020-06-12

시간 기반으로 변경을 감지하다보니 문제가 발생했다.

SFTP로 업로드하여 변경 문서로 로깅한 후에 git으로 싱크를 맞추면 이때 문서가 다시 수정된 것으로 감지되는 문제.

content도 같이 저장해서 시간 변경이 아닌 content에 변경이 생겼는지를 비교하도록 수정했다.

2020-06-11

(a)문서 수정일과 (b)변경문서 목록을 보여주기 위해 문서의 변경을 감지해야 한다고 생각했다. 문서 파일의 상단에 작성하는 메타 데이터에 updated_at 필드를 두고 이 필드의 값이 OS의 파일 수정일과 다르면 변경으로 취급하는 로직을 만들었다. 하지만 좋은 방법은 아니었다.

(a)문서 수정일을 보여주려면 그냥 OS의 파일 수정일을 보여주면 되는 것이다. updated_at을 write하고 비교하는 작업은 의미가 없다.

(b)변경문서 목록을 보여주려면 문서가 이전과 달라졌는지를 감지해야 한다. 이를 위해 updated_at 필드를 추가했는데, 동일한 소스에서 작업하기 위해 서버에서 만들어준 updated_at 필드 부분을 다시 로컬로 받아와서 편집을 해야하는 귀찮음이 있었고 파일 퍼미션에서 몇 가지 문제가 발생해서 방식을 바꾸게 됐다.

아래 두 버전 진행에서 알게된 것들을 (v1), (v2)로 적는다.

(v1) updated_at을 php에서 업데이트하는 방식 (비추천)

php가 file write를 할 수 있도록 퍼미션 변경 필요.

로컬에서 글을 쓸 때는 updated_at을 변경하지 않고 업로드를 한다. 이 문서를 서버에서 글을 보여줄 때 updated_at은 그대로인데 파일 수정일은 더 최신이 됐을 것이다. 그러면 변경으로 판단한다.

변경감지 후 변경시각을 updated_at에 쓰려고 하는데 이 때 파일 날짜가 또 바뀌는 문제가 발생했다. 이 경우 파일을 바꾸기 전에 날짜를 얻고 파일 수정 후 얻어놓은 날짜로 다시 touch()를 실행하는 로직으로 구현했다.

이상한 점은 www-data 그룹으로 퍼미션을 줬는데도 touch()에서 에러가 발생하는 것이다. 스택 오버플로우를 찾아보니 user:group 에서 user도 www-data가 돼야 한다고 한다. user를 www-data로 바꿔보니, touch가 잘 됐으나 문서에서 버그라고 설명하고 있어서 피할 수 있으면 피하려고 마음먹게 됐다.

문서 배포는 데스크탑에서 저장 시에 SFTP로 업로드하는 방식이 제일 편하다. 그런데 앞에서 user를 www-data로 바꿨기에 퍼미션 작업이 필요해졌다. 내 계정을 www-data 그룹에 넣고 그룹 write 권한을 줘서 해결했다.

usermod -a -G www-data user
sudo chmod -R ug+rwx pages

이 작업 후 IDE에서 문서 업로드는 되는데 파일 날짜관련 오류가 발생했다.

Tools | Deployment | Options | Preserve files timestamps

IDE의 세팅에서 위 체크를 빼면 된다는 답변을 찾아서 해결했다.

결국 이 방식은 버렸다. 앞서 설명을 했지만 수정일을 보여주는 것만 보자면 updated_at을 기록할 필요가 없기도 했고, 메타 데이터 수정을 위해 퍼미션 관련 작업이 너무 많다는 생각이 들었기 때문이다.

(v2) 파일의 변경 시각을 사용하는 방식

find pages -type d -exec chmod 755 {} \;
find pages -type f -exec chmod 644 {} \;

우선 퍼미션을 원래대로 좀 더 강하게 돌려놨다. IDE의 설정도 다시 되돌렸다.

파일 수정일을 얻는 것은 OS의 파일 수정 시각을 그대로 보여주도록 변경.

수정일을 얻을 수 있다고 해도 변경 자체를 감지해야 했는데 변경 전 파일 시각을 저장할 필요가 생겼다.

여기서 DB를 사용했다. 여러가지 연산에서 DB를 사용하는 것이 훨씬 편하기도 하고, 파일을 써서 생기는 장점은 형상관리가 가능하다는 것인데 최근변경 목록은 형상관리가 필요하지 않다고 생각해서 DB를 사용했다.

2020-06-09

요구사항

아이디어