BLOG main image
분류 전체보기 (256)
공지사항 (17)
통합_답변 (2)
ISWT (29)
라쿠캡틴 (154)
개발중 (37)
관리용 (7)
덕질 (5)


Today hit, Yesterday hit
daisy rss
tistory 티스토리 가입하기!
'분류 전체보기'에 해당되는 글 256건
2013. 9. 14. 06:11

* 이 포스팅은 해결될 때까지 상단에 위치합니다



===========================================================================

2013-09-13  PM 8:40


돌아왔네요. 슬슬 이전 준비를 해야겠습니다.


===========================================================================

2013-09-13  PM 8:00


오늘 아침부터 ai 팬텀 서버가 작동하지 않는 문제가 발생하고 있습니다.

15일이 등록일이니 아무리 늦어도 그 쯤에는 뭔가 조치가 있을거라고 생각합니다. 빨리 해결이 되면 좋겠지만 낙관할수만도 없는 상황이네요. 뭘 해야할지 고민입니다.


===========================================================================

2013-09-09  PM 9:26


짧게 요약하자면, 이번 사태는 일본 외 IP 에서만 발생하는 문제인 것 같네요. 즉 ai 광장의 원래 대상(?)인 일본에서 접속하시는 분들은 이용에 아무 문제가 없으시다고 합니다. 프록시를 사용해 우회해 이용하는 것도 가능하다지만… 저는 일단 사이트 이전을 결심했습니다. 다만 이전이라고해서 당장 사이트 문을 닫거나 옮기는 건 아니에요. 앞으로 사이트 관리를 위해서는 초기에 반드시 구현해둬야할 시스템들이 있고, 구현을 위해서는 꽤 많은 시간이 필요하거든요.


자세한 내용은 아래 포스팅을 참고해주세요.


이전을 위해서 이것저것 구현중입니다


워드 갱신은 곧 재개될 예정입니다.


===========================================================================

2013-09-08  AM 11:33


일단 아카시 연인 워드에는 임시로 대응했습니다. 연인워드 이용에는 문제가 없으실거에요.

문제가 되는 건 최근에 추가된 다크룸, 미도리마의 호감도 시스템, 그 외에도 이것저것 확인중에 있습니다. 이 건에 대해 개별적으로 문의하시거나 정보를 주실 필요는 없습니다.


불행 중 다행인건 아카시 워드가 name을 참조하고 있다는 건데… 이걸 다행이라고 해야할지 어떨지 모르겠네요.

리다이렉션에 의한 강제 페이지 이동이 있어서 평소보다 페이지 뜨는 게 느리실 수 있습니다. 이 점은 양해해주세요.


또, 하트 시스템은 ai 변수와는 무관하므로 사라질 걱정은 안하셔도 됩니다. 그러니까 캐시 삭제 하지 마세요! 다른 대부분의 변수와는 달리 하트는 복구 시켜드리기가 어렵습니다. 뭔가 이상하다 싶으시면 손대지 마시고 먼저 저에게 문의해주세요.


===========================================================================

2013-09-07  PM 10:50


오늘 접속 관련으로 문의 주신 분들이 많으신데 이제서야 확인했네요. 죄송합니다.

음... 현재 ai 광장은 세이브 데이터를 사용할 수 없는 상태입니다. 이 때문에 변수 관련 기능이 전부 멎어있는 상태고 특히 라쿠캡틴은 사이트 전체적으로 변수에 많이 의존하고 있는 상태라 크리티컬을 맞은 것 같은 상황이네요 orz 서버측 문제라 현재로서는 제가 딱히 대처할 방법이 없는 것 같습니다. 일단 여러모로 알아보고는 있는데 시간이 지나면 자연스레 해결 될 것 같기도하고 그게 아니라면 역대 최악의 사태가 발생할 것 같네요.


오늘 접속이 늦어진 건 다른 일을 하고 있기 때문이었는데... 일단 그걸로라도 기분 전환이 되시지 않을까 싶어 작업을 조금 서둘러보려고 합니다.


다크룸 관련으로 메세지 주신 분들께도 상황이 이렇다보니 당장 테스트하기 어려운 상황이라는 말씀을 먼저 드려야겠네요. 신경 써주셨는데 죄송합니다 (_ _)



이런 일이 일어날때마다 항상 고민하게 되는데... 이번엔 정말 좀 심각하게 이전을 생각해봐야겠습니다.


2013. 9. 13. 19:54

경험과 머릿속에 있는 지식만을 바탕으로 한 추측입니다. 사실과 다른 부분이 있을 수 있습니다. 문제점이 있거나 그 부분은 이런 방법일 것 같다, 아니면 이런 더 나은 방법이 있다, 하는 것들이 있으면 말씀해주셨으면 하는 마음으로 공개해둡니다. 개발자를 위한 글이므로 방문해주시는 분들께서는 이해하지 못하셔도 됩니다 :)

팬텀 서버 기준입니다.


1. 데이터베이스 : 워드 테이블의 구성(column)은 No, Keyword, 본문, 완전일치, 이미지, 기록여부, 태그, 클러스터, 변수, 등록일, Good, Hit


이 중 No는 AUTO_INCREMENT, PRIMARY KEY로 사용된다

Keyword, 본문, 이미지, 태그, 변수는 문자열형

완전일치, 기록여부, 클러스터, Good, Hit은 수치형. Good과 Hit은 시스템에 의해 관리되며 편집 화면에서 수정할 수 없다.

등록일은 DATETIME 형


2. 데이터베이스2 : 워드 테이블 외에 베이비별로 필요한 시스템 변수를 할당하고 있다.

배경색, 문자색, 캐릭터이름, 변수목록, 태그 목록, 템플릿, 이미지 카테고리, 이미지 목록, NG 워드 등등.


3. 베이비 작동은 이하의 절차

1) 베이비 no를 기준으로 접근할 테이블을 결정 (GET 방식으로 몇가지 정보를 가져오는 듯 하다)

2) 워드 검색(매칭)을 실행 (처리속도, 과부하, 워드 매칭률을 결정하는 시스템의 핵심)

입력 워드를 기준으로 무언가의 처리를 한 후 LIKE 검색? (이 부분은 불명확... 워드 기준 like 검색이면 시간이 너무 오래걸리지 않을까 하는 생각도 드는데...)(등록된 워드를 입력된 단어에 매칭시키는 방식...일지도 모른다 어쩌면)

검색은 Keyword의 그룹화, AND, OR에 대응하도록 만들어야한다 (그룹화 및 AND OR의 병용 사용은 구현하기 쉽지 않을 듯 하다. ai에서도 몇 번이나 버그가 발생한 전례가 있다)

이 때, 검색은 아마도 2차례 실행된다. ①클러스터 없음 ②클러스터 있음

①은 결과값이 없는 경우 No Word를 불러온다 (혹은 No Word는 무조건 결과에 포함된다, 일지도. if 조건을 넣었을때의 결과를 생각하면 후자가 더 정확한가?)


②에서 검색된 레코드 중 변수 컬럼을 참고, if 조건이 있는 것들의 true 여부를 검토한다


②는 조건이 false인 것만을 제외

①은 조건이 전부 true이며, 조건의 수가 가장 많은 값을 우선적으로 선택한다.


①에서 같은 조건하의 레코드가 여럿 있을 경우 이 중 1개만을 랜덤 선택한다


3) 2)에서 선택된 워드들을 클러스터 순서대로 나열한다. 같은 레벨의 클러스터라면 No가 빠른 쪽이 우선된다

나열된 레코드들 중에서 변수를 참고해 변수의 대입 등을 처리한다(ins) (세이브 데이터가 있다면 세이브 데이터에서 먼저 값을 불러오고 처리할 듯)

가장 마지막에 있는 (이미지 값이 있는) 레코드의 이미지를 출력할 이미지로 선택한다


4) 3)의 결과를 바탕으로 출력화면을 만든다

배경색, 문자색의 셋팅, 이미지 셋팅, 그리고 본문을 워드를 차례대로 출력.

이 때 출력되는 본문의 내용은 일부 변환된다 (변수 출력이나 링크 출력 등)


5) Hit수, 로그에 이번에 선택된 워드, 입력된 워드 등의 정보를 추가한다. 기록 여부가 X라면 기록하지 않는다?

NG워드, NG유저등의 처리가 이 단계에서 행해지는지, 아니면 관리 화면에서 불러올때 행해지는지는 의문. 어느쪽이라도 좋지만.

(이 부분은 ai의 로그 시스템 자체가 현재 제대로 작동하지 않아서 거의 모르겠지만...)


5-1) 사용자가 Good을 눌렀을 경우 화면 이동 후 해당 화면에서 해당 워드(No 기준)의 Good에 가산처리


4. 편집 화면은 특정 갯수만큼(ai는 20개 기준) 형식에 맞춰 출력 (for문이나 while이나... 방법은 많다)

편집 화면의 검색은 출력시의 워드 검색보다는 훨씬 간편할 듯 (조건에 맞는 레코드들을 가져오기만 하면 OK이니)


5. 세이브데이터 및 변수 관련 : 서버측에서 베이비의 No, 해당 베이비의 변수 목록등을 참고해 해당 테이블에 유저별로 값을 보존하고 있을 듯 하다. 유저를 구분하는 방식, 필요 없는 데이터의 삭제등이 어떻게 처리되는지 등이 의문.

또, 임시 변수를 사용할 수 있다는 점을 생각하면 ins와 변수 기록(세이브 데이터)은 각각 독립적으로 작동하고 있다고 볼 수 있다.

name은 예외적으로 GET 방식으로 변수를 매번 셋팅해주는 듯. (존재하는 경우에만)



-----------------------------------------------------------------------

현재 시스템 구현의 장애물


1. DB 문제...

DB를 이용하는 것이 '관리' 및 '속도' 측면에서 매우 유리할 것으로 예상되지만 아직 지식 및 경험이 부족. DB를 사용한 시스템을 쓰려면 사이트 초창기부터 구현해야하는데(도중에 구현할 경우 재이식 필요), 구현하는데 매우 많은 시간이 걸린다는 점이 걸림돌. 그래도 언젠가는 DB 식으로 옮길 예정


2. 키워드의 그룹화 및 OR 대응

기존의 AND 시스템에까지 버그가 발생할 우려가 있다. 또, 테스트에 시간이 걸린다는 게 가장 큰 문제점. 속도 문제도 약간 걱정스럽다. 관리 측면에서는 구현하는 편이 훨씬 깔끔한데... DB로 옮기게 되면 검색 시스템도 어차피 새로 짜야할테고 지금은 미뤄두는 게 효율적일지도.


3. 본문 변환

변환을 등록 단계에서 할지 출력 단계에서 할지 고민. 전자는 (출력)속도상 유리하고 후자는 워드 관리상 유리하다. 한번에 대량의 워드의 내용을 바꿀수도 있다는 점에서 후자인 편이 나으려나...? 차후 이식을 생각해도...


그 외에는 링크 변환이 은근히 어렵다. <<링크워드>> 만으로 <a href=…>를 구현하려면 어떻게 해야할까. split 만으로는 한줄에 2개 이상이 나왔을때 등이 걱정. 꼬일 우려가 있다.

[word=''][/w] 정도는 그럭저럭 구현할 수 있을지도.


4. 변수 관련

가장 핵심적인 '문제'. 자바스크립트를 이용해 비슷한 시스템을 구현하는 것도 가능하긴 하지만 무척 번거롭다. 변수 1개만을 사용하는 경우는 비교적 간단히 구현할 수 있지만...

ai와 비슷한 시스템을 만든다면 변수는 서버측에서 관리하는 게 best. 문제는 이 변수 데이터를 어떻게 만들고 관리할 것인가. 가입, 로그인을 구현하는 게 안정적일 것 같지만 이 경우 가입, 관리 폼을 따로 구현해야하고 그 외에도 대화하기 사이트에 가입은 여러모로 생소하지 않을까...

어차피 호스팅을 쓰면 php 등을 써서 여러가지를 구현할 수 있긴 하지만 '워드' 레벨에서 관리할 수 있는 변수 시스템이 무척 편해서 고민중. …하지만 이것도 결국은 DB 시스템과 함께 가야하는 부분일지도 모른다.


5. 클러스터, 랜덤 워드

현재 임시로 구현해 둔 대화하기 시스템은 딱 한 워드만을 찾고 거기서 검색을 중지하므로 아마 구현하기는 힘들 듯 하다. 랜덤 워드는 간단한 방법으로 구현 완료. …이식할 때는 제법 불편할지도. 이식은 3번의 본문 변환과도 크게 관련이 있지만.




-----------------------------------------------------------------------

머릿 속 정리도 할 겸 일단 적어봤습니다. 요즘들어 ai가 계속 불안정하기도하고 관리상의 불편을 감수하면 출력 자체는 기존의 ai와 큰 차이 없이 가능할 것 같으니... 빨리 이식 쪽으로 눈을 돌려야하는 건가 싶습니다. 뭐 시스템이 하루 이틀만에 뚝딱 완성되는 게 아닌 한 재이식은 피할 수 없을 것 같고 그냥 여러가지로 각오해 둬야겠네요 orz


더 불편한 시스템에서 업뎃하는 분들도 계시고 그저 이것저것 구현해보고 싶은 제 욕심이 큰게 유일한 문제인 것 같기도해서 많이 생각해보고 있습니다. 한가지 확실히 알게된 건 역시 남의 시스템에 너무 의존하면 곤란하다는 것(AND사태나 지금의 세이브 데이터나). 직접 백업할 수 있는 환경이 제일 좋다는 것, 이네요.


본가, 별관은 아주 복잡한 처리를 하는 게 아니라 큰 문제는 없을 것 같고 (리퍼러 기능을 기존과 동일한 방식으로 구현해야할지 고민인데... 키세 이식을 생각하면 어쨌거나 빨리 구현해둬야겠네요. 어차피 재이식 하면 뜯어 고쳐야할 게 한두개도 아니고) 다크룸은 php를 써서 새로 만들어야할 것 같습니다. ...그나마 javascript를 즐겨 썼던 게 다행이네요. 쿠로바스룸이나 하트 시스템을 그럭저럭 옮겨올 수 있을 것 같으니까요.


앞으로의 업뎃 워드를 등록할 사이트는 오늘의 ai 사태도 참고해서 결정하겠습니다. 시간... 언제나 시간이 필요하네요ㅠㅠㅠㅠㅠㅠㅠ



2013. 9. 13. 19:50

제이카님, 야로님, 그 외 답변 불필요로 메세지 주신 모든 분들 감사드립니다. 여러분의 배려 잊지 않을게요!



'라쿠캡틴 > 박수답변' 카테고리의 다른 글

2013 / 09 / 15 일자  (2) 2013.09.16
2013 / 09 / 13 일자  (0) 2013.09.15
2013 / 09 / 08 일자  (0) 2013.09.09
2013 / 09 / 07 일자  (2) 2013.09.08
2013 / 09 / 06 일자  (0) 2013.09.08