4,251 inureyes이 작성한 답글

(11 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

crizin 작성:

바꾸려는 이유는 소스코드 간소화도 있고, HTML 편집을 드러내서 HTML 에디터만 쓰는 사람들이 많이 생긴다면 지금처럼 한줄로 붙은 소스 편집하기가 쉽지 않기 때문에 원성이 자자할 듯 해서요.. 아무튼 지금 생각나는 문제들은 대충 이정도인데 2-2번이 가장 걸림돌이 될 것 같네요.. 또다른 문제점 있으면 얘기해주세요..

그리고 [CODE ][ /CODE] 블럭도 그냥 없애는게 어떨까 싶은데요.. HTML 코드를 보여주고 싶은 경우에는 <xmp> 같은 태그를 써 직접 적거나 플러그인을 이용하면 되고.. 아니면 위지윅에디터에서 작성후 4가지 박스 스타일을 클래식처럼 사용자가 지정할 수 있게 해서 쓰면 될 것 같습니다..

의견을 부탁드립니다~

찬성입니다 smile
[CODE ][ /CODE] 블럭같은 경우는 레거시도 있고 하니 기본 플러그인으로 처리부분을 떼어 내는 것이 좋겠네요 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,252 inureyes이 작성한 답글

(2 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

루트에 태터를 설치해 본 적이 없어 정확히는 모르겠습니다만, .htaccess 가 디렉토리 경로를 엎어써서 만들어내는 현상 같네요 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,253 inureyes이 작성한 답글

(19 답글들, 아이디어 및 기능 제안에 작성)

마잇 작성:

이미 많은 고민과 생각으로 계획을 세우신듯 한데 너무 늦은 의견이 아닌가 걱정이 되지만 의견을 적어봅니다.

처음 dev.tattertools.com을 접속했을때 Trac 인터페이스를 보고 매우 반가웠습니다. 한손으로도 꼽아도 남을 횟수의 버그 리폿 경험을 가지고 있지만, 접해본 버그 트래킹 시스템 중에는 편리하고 간단하면서 개발 현황을 어렵지 않게 파악할 수 있었던 경험 때문이었습니다.

Trac과의 첫경험(?) 덕분이었는지 저는 공식적인 버그 트래킹 시스템에 리폿하는것에 대한 막연한 두려움?이랄까 그런것을 버리고 평소 자주 사용하던 소프트웨어의 불편했던 점과 건의사항을 개발자들에게 직접 전달하고 좋은 결과를 얻을 수 있었습니다. 새로운 릴리즈 변경사항에 비록 이름까지는 아니어도 제가 올렸던 버그 넘버가 적혀 있던걸 보고 매우 놀라운 감정을 느꼈습니다. (물론 좋은쪽입니다 ; -)

일단 가입하지 않은 상태에서는 새 티켓을 작성할 수 없는것 처럼 보여서 홈페이지의 게시판과 dev 사이트를 둘러보다가 Forum 메뉴 링크를 눈치채고 이 사이트로 들어오게 되었습니다.

제가 둘러본 바로는 사용자와의 대화창구를 3단계로 나누신 것 같습니다. 공식 홈페이지의 게시판들, 그 다음 이 포럼, 그리고 Trac.

현재 Trac은 저같은 사용자들한테는 읽기 전용으로 보입니다. 새 티켓 작성이 안되는 것 같습니다.

많은 고민과 생각으로 이런 구조을 결정하셨겠지만 저는 이 포럼과 Trac을 가능한 합쳤으면 좋겠다는 의견입니다.
공지사항, 아이디어, 플러그인, 잡담하기 포럼은 이 포럼 성격에 잘 맞는 것 같습니다.
하지만, 벌레잡기, 1.0.5개발 버전 게시판의 내용은 Trac쪽이 낫지 않을까 하는 생각입니다. 물론 그러러면 익명 사용자의 새 티켓 작성이나, 최소 제약없는 회원가입후 티겟 작성까지는 허용되어야 할 것입니다.

더 나아가 공식 홈페이지 쪽 게시판들과 이곳의 공지사항, 아이디어, 플러그인, 잡담하기와 같은 성격의 포럼을 합치는 것도 조심스레 건의를 드려봅니다.

간단히 요약하면, 제가 언급했던 3단계가 원래 의도하신 것이라면 이것을 2단계로 합치는 것이 어떨까 하는 의견이었습니다.

정작 젤 중요한 왜 그래야 하는지에 대한 의견을 못쓰겠네요. 논술세대가 아니어서 그런가 봅니다.  ;-)

어제 질문했던 사람이 오늘 답변하게 되고, 오늘 답변했던 사람이 내일 패치를 올리는 그런 환경을 만들어 나아가는데 보다 직관적이고 단순한 대화창구를 만들어 가는것이 좋다고 생각되어서 늦은감이 있지만 몇 마디 적어 보았습니다.

네. 그렇게 되고 익숙해지면 좋습니다 smile
두가지 문제라면, 사용자들이 다가올 수 있는 진입장벽이 더 높아질 수 있다는 점과, 엄격한 코드 관리가 힘들어진다는 점 입니다. 후자의 이야기는 큰 문제가 아닐 수 있으니 생략하고, 앞 이야기를 해보겠습니다.

trac을 써보셔서 아시겠지만, 컴퓨터와 친하고 trac에 어느정도 익숙한 사람들에게는 정말 편리한 도구이지만 처음 접하거나 프로그래밍이나 위키에 그다지 관심이 없으신 분들에게는 외계어의 조합에 복잡다양한 구조일 뿐입니다. 이런 상황에서 trac으로 모든 개발 관련 사항을 이전한다면, 피드백을 어느정도 포기하자는 말이 되어버립니다. 그것도 가장 중요한 end-user 층에서요.

또한 i18n에 대비하여 현재 작성되는 trac의 내용등이 영어와 한국어 양 쪽을 동시에 작성하고 있으며 (전체는 아니지만) 곧 모든 내용의 작성이 영/한 양쪽으로 작성될 것을 생각하면... 개발관련 사항이 모두 그 쪽으로 이전했을 떄의 진입장벽은 하늘을 찌르겠지요 sad

물론 ticket을 작성할 수 있는 사용자층이 넓어져야 한다는 점에는 동의합니다. 하지만 그 경우 ticket을 작성하기 힘드신 분들에게는 (그 개념이 아예 이해가 힘드신 분들도 계시죠) 일종의 간극이 생겨버린다는 점에서 아직까지 무리라고 봅니다.
(처음에 포럼형식으로 게시판 만드는 것도 다들 의견이 분분했어요 ㅠ_ㅠ 우리나라에서 포럼형식으로 게시판 열면 전문가-_-들만 글 쓸 줄 알거라구요 -o- )

태터가 computer geek들만이 아니라 모든 사람들에게 사랑받으면서 자라려면, 아직까지는 국내의 환경을 고려하지 않을 수 없을 듯 합니다. 제 입장에서야 마잇님의 말대로 되는 것이 가장 직관적이고 편하지만, 천천히 가야 하는것 아니겠습니까 smile

공식홈페이지의 게시판을 합치는 이야기는 여러가지 의견이 있을 수 있으니 다 같이 생각을 해 보았으면 합니다. 여기로 합치면 좋겠지만, 세상엔 제로보드만 게시판으로 아시는 분들이 대부분입니다...

포럼으로 이동: 아이디어 및 기능 제안

4,254 inureyes이 작성한 답글

(3 답글들, 스킨 및 플러그인에 작성)

Peris 작성:

세세한 것까지 깊게 생각한게 아니라 단편적으로 생각나는 것을 적은거라 오류가 있을 수도 있으니 양해해주세요. smile


현 플러그인의 문제점(?)
1. 악의적인 플러그인 제작자에게 취약하다.
2. 추가적으로 필요한 것이 있어도(이벤트 등) 태터툴즈가 버전업을 하지 않으면 지원이 될 수 없다.
3. 플러그인을 제작하는데 있어서 (태터툴즈 기능중) 필요한 것들을 찾기가 쉽지 않다.
4. 플러그인간 충돌이 발생할 가능성이 존재한다.(현재는 긴~ 함수명으로 해결; )
5. php코드와 javascript, css 등이 한 곳에서 다 짬뽕(; )이 된다.
    개인적으로 js, css는 전부 head 태그 안에 들어가야된다고 생각(...)
6. 환경설정 및 백업이 불가능


아래의 내용은, 대략 위와 같은 문제점(?)들이 존재하는데
어떻게하면 이것들을 해결할 수 있을까? 란 생각을 하다가
플러그인 관련 부분을 class로 제작해보면 어떨까? 라는 생각에서 출발했습니다.
제 생각들이므로 경어는 생략(...)


/plugins/ 디렉토리에 plugins.php 파일을 생성하고 그 안에는 plugins class를 만들어
모든 플러그인들이 이 class를 상속받아 제작이 될 경우..

1. 이 class에 DB에 액세스하는 부분을 넣고(물론 DB 모듈은 따로 제작해놓고)
개별 플러그인은 이 것을 사용해서 제작을 하며
mysql_* 등의 함수가 플러그인에 존재하면 작동이 안되게 하는 방식으로 한다면
약간이나마 도움이 되지 않을까?
(물론 config.php 파일을 include 시키는 것도 금지)

2. 관련된 부분을 plugins.php 파일로 독립을 시켜놨기때문에
개별 플러그인은 필요한 plugins.php 파일의 버전만 명시해주면 되니
이 파일만 개별적으로 업데이트가 이루어져도 상관이 없지 않을까?
(자세한 구현방법은 나중에 생각해보고; )

3. (원칙적으로 문서화만 잘되어있다면 문제가 되지 않는 상황이지만)
한 파일 안에 다 몰려있으니 찾는 것도 쉽겠지(...)

4. 개별 플러그인의 class 이름은 디렉토리 이름과 동일하게 만들면 끝(?)
(index.xml 내에서의 정의는 className::functionName 정도로 하면 되지 않을까?)

5. 개별 플러그인의 class에 head 라는 메소드를 만들어 이 곳의 내용은 자동으로 head 태그 안에 포함

6. 여기서 다룰 내용은 아닌거 같으므로 패스;;


욕만 하지 마세요. roll

멋집니다.
플러그인 구조 자체를 클래스로 모듈화하는거군요.

살-짝 제작 진입장벽이 높아지기는 하겠지만, 그런거야 간단한 설명서로 금방 채울 수 있을 것 같습니다. smile

(그리고, plugins.php는 현재도 model로 분리되어 있습니다. smile 아이디어와 방향만 선다면 (그리고 시간!) 적용이 가능하죠.)

포럼으로 이동: 스킨 및 플러그인

4,255 inureyes이 작성한 답글

(10 답글들, 공지사항에 작성)

chester 작성:

오늘 회사에서 엄청나게 시끄러운 서버 두대를 돌리면서 세팅을 완료했습니다.
이제 나이쓰하게 돌리는 일이 남았네요... 다음주를 기대해주세요 !! smile

아니면 안전하게 1.0.5 발표 후에 쓱- 이전하시는 것도?!

포럼으로 이동: 공지사항

4,256 inureyes이 작성한 답글

(11 답글들, 잡담하기에 작성)

JCrew 작성:

오늘 수십번의 짦은 정전(2~5초간격)으로... 결국 견디다 못한 제 컴퓨터가 사망했습니다...(전기회사 이거... 미친거 아녀 이거... -_-+ 빠직! )

이런 정전으로도 컴퓨터가 사망하기도 하는군요... 해부해서 수술중입니다만... 돈이 들어갈껄 생각하니 그냥 다른녀석에게 장기기증을 고민중이기도...

아무튼... 삼가 고...물(?)의 명복을 빌어주세요... ㅡ.ㅡa

달라스에 사시면... 아아...
죄송합니다. '달라스 햄버거' 라는 국적 불명의 햄버거가 생각나 버렸어요 ㅠ_ㅠ

아무쪼록 별 일 없으시길 smile

포럼으로 이동: 잡담하기

4,257 inureyes이 작성한 답글

(11 답글들, 스킨 및 플러그인에 작성)

rhapsody 작성:

이제 대충 TatterTools 코드를 읽었읍니다. "Eolin.PHP.XMLRPC"에 chester님 말씀대로 XML-RPC가 구현되어 있더군요. 결국 Wrapper를 하나 만들어야 하네요. 무식이 박력이라고 제가 metaweblogAPI를 plugin 형태로 실현해 보려고 합니다.  한가지 확실하지 않은게 "Eolin.PHP.XMLRPC" 에서 어떻게 base64 binary 를 Encoding 하는지 잘 모르겠네요.  Moon Night 으로 하는 것이이라 시간은 장담은 못하지만 열심히 해보죠.^^

나이스 하십니다 cool

'xml-rpc 지원'으로 플러그인 게시판에 쓰레드 하나 열어주세요 >_<

포럼으로 이동: 스킨 및 플러그인

4,258 inureyes이 작성한 답글

(19 답글들, 아이디어 및 기능 제안에 작성)

Ever_K 작성:

일단 크게 개발쪽과 고객지원쪽으로 세분화하고 해당 부분에 각 한분씩 총지휘자를 두는형식으로 진두지휘를 하게되고,

개발쪽에  플러그인,스킨 등 테터툴즈를 돌릴때 필요한 각종 개발을 담당하는 하위분야들을 두고, 사용자지원부분에 메뉴얼담당,Q&A담당,FAQ담당 등 이런식으로 빨리 세분화를 이루신후에 각 부분에 적절한 인재분을 배치하는게 좋을것같습니다.

이렇게 세분화하고 각 그룹원에게 자신이 해야될 목표를 확실히 구분지어주면 능률도 오르고 더욱 열심히하리라 생각이됩니다.

지휘자... 라기는 그렇고, chester님 의견대로 분야를 나누고 분야별로 관심있는 분들이 게시판에 모입시다. 그 후 그 카테고리 안에서 참여하시는 분들이 지휘자나 방향등을 자율적으로 결정하는 식이 나을 것 같습니다. (정 처음에 시작이 힘들다면 누구나 동의할만한 분들이 '장'을 맡아주시면 되겠죠^^) 위에서 아래로 척척척- 이 아니라 잘 안 될 것 같지만, 지금 위키 매뉴얼 채워지는 정도나 dev.tattertools.com 보시면 그렇지도 않습니다.
또한 그러한 분야의 구분이 너무 확실해서 배타성을 띄거나 하는 것도 안 좋을 것 같습니다. 일종의 명찰이라고 하는 것이 어떨까요? 모두들 관심있는 것으로 명찰을 하나씩 다는거죠. 나는 1반 너는 2반 이런 식으로요.

이상하게 들릴 수도 있지만, 속도가 전부는 아니라고 생각합니다. 완전한 세분화가 이루어질 수도 없지요. (코드 분석이 없이 플러그인 스트럭처 설명을 할 수는 없을테고, 환경 피드백 없이 디자인을 할 수도 없을테니까요 ^^; ) 주종목 명찰을 달되, 여기저기 기웃거리는 그런 즐거움도 있어야 하겠고, 별로 기여할 거리는 없지만 사람들이 좋아서 자유게시판 죽돌이가 되시는 분도 있어야 하지 않을런지요.

사람이 함께 하는 개발이 되었으면 합니다.
결국 우리가 쓰기 위해서 만드는 태터툴즈잖아요 big_smile

군대식 착착착이 아니라 느릴 것 같지만, 개인적으로는 그 과정이 가장 빨리 발전하는 방향이 되지 않을까 생각합니다. smile

포럼으로 이동: 아이디어 및 기능 제안

4,259 inureyes이 작성한 답글

(6 답글들, 아이디어 및 기능 제안에 작성)

Peris 작성:
inureyes 작성:

한국어에서의 자연어 처리는 컴퓨터 공학의 영원한 숙제입니다.
smile

총대 메실분~?

과연 이걸 혼자서 총대 메서 언제 끝날까요.;;;

...자연어 검색 시스템으로 생각하면 복잡한데, 단순화 시킬 수 있지 않을까? 하다가 얻은 아이디어가 있습니다.

꼭 형태소 분석을 통한 유사성 분석을 통하지 않더라도, 간단하게 하려면 비슷한 부분이 겹치는 순서대로 정렬하면 되지 않을까 했는데, 이건 로드가 좀 있군요. 대략 O(n^2)의 process time이 걸립니다.  (태그가 n개면 n의 제곱개 만큼을 계산해야 한다는 의미입니다.)

아래는 이상한 소리입니다. 혹시 어쩌다가 이 글을 보게 되신 분들은 저거 뭐야! 하시고 요 아랫 부분을 안 읽으셔도 됩니다 ㅠ_ㅠ
(박스로 묶어 버릴게요.)

단어들의 set으로 n x n 문자열 행렬을 만든 다음에, 유사성에 관한 식을 주고 GJ elimination을 한 후, eigenvalue problem으로 생각하고 계산하면 degenerated matrix의 set들을 얻을 수 있을겁니다. 그러면 그 matrix set들이 유사성을 지닌 단어들의 모임이 될 것이고, 그것들을 모아서 차례로 출력하면 됩니다.

그런데 구현의 문제점이라면, GJ elimination을 하는 과정을 제외해도, eigenvalue problem의 계산이 이론적으로 O(tN^2)이 됩니다. 출력할 때 마다 계산하면 로드의 문제가 있겠죠. 그리고 t 자체는 문자열의 지수함수에 비례하여 증가할 것으로 생각되기 때문에 크게 증가하지는 않겠지만, 적어도 4~5 step은 계산해야 합니다.

이걸 php로 구현하면 퍼포먼스가 받쳐 줄까요?
그리고 결정적으로 전 php에서 nxn string matrix를 구현할 수 있는지 없는지를 잘 모릅니다;;; 아직 익숙한 언어가 아니거든요ㅠ_ㅠ

포럼으로 이동: 아이디어 및 기능 제안

4,260 inureyes이 작성한 답글

(2 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

지금 확인해보니 고쳐져 있습니다 cool

그나저나 다들 바쁘신지 피드백이 약하네요 smile
('답글 안달린 글 보기' 하니 많은 수의 '벌레잡기' 글이 나오는군요.)

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,261 inureyes이 작성한 답글

(1 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

정말 못 읽어오는군요 ;;;

지금 확인해보니 티켓으로 등록되었네요 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,262 inureyes이 작성한 답글

(14 답글들, 잡담하기에 작성)

daybreaker 작성:

엇, 그러면 inureyes님은 학부 전산과 출신이셨나보네요?! 어쩐지, 프로그래밍을 잘하시는 것 같다는 생각이 들었는데.. ^^;

svn은 뭐 다른 사람들도 다 쓰거나 하는 건 아니고, 제가 필요에 의해서 사용하고 있는 겁니다.

그러고보니 저도 숙제 due가 몇 분 늦는 바람에 Windows API 써서 timestamp를 살짝 고쳤던 기억이....-_-;;;;

물리학 / 컴퓨터공학 복수전공 출신입니다 smile ;;;;;

포럼으로 이동: 잡담하기

4,263 inureyes이 작성한 답글

(4 답글들, 잡담하기에 작성)

김종찬 작성:

링크 클릭하셔서 보세요.

네이버 인터넷 뉴스 메인색션에.. "스토킹 월드".. 가 제 기사 랍니다.

http://news.naver.com/news/read.php?mod … enu_id=105

잘 읽었습니다 >_<

제 싸이엔 제가 안 들어가도 방명록에 글이 많이 써지더라구요...

"한 번 방문해 보세요"
"우연히 들르게 되었습니다. ....블라블라.... http://XXXXXXXXXX 으로 방문해주세요"
"실례가 되었다면 죄송합니다.    .... 화끈한 XXX"
"그 동안 잘 지냈니?  ....몸이 안좋으면 XX 매트를 써봐. 건강이 좋아져. 구입하고 싶으면 XX)XXXXXXX "

......전 참 인기가 좋은가봅니다 =_=;;
모르는 분들이 와서 친구가 되고 싶다고도 하고 영화도 보자고 하고 건강도 챙겨주고...

포럼으로 이동: 잡담하기

4,264 inureyes이 작성한 주제

(0 답글들, 잡담하기에 작성)

아래에 동시접속자 여덟명 ㅠ_ㅠ
사흘 연속으로 여덟명 동시접속하는 순간을 봤습니다 ㅠ_ㅠ

혹시 더 많이 접속했던 경우도 있나요;
이것도 한 번 통계내는 루틴을 만들어보면 재미있을것 같애요 lol

포럼으로 이동: 잡담하기

4,265 inureyes이 작성한 답글

(4 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

몇 번 시도해봤는데 제 쪽에서는 재현 불가능하네요 ㅠ_ㅠ
혹시 재현해 보신 분 계시나요?

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,266 inureyes이 작성한 답글

(1 답글들, 잡담하기에 작성)

baragi74 작성:

phpbb라서 새로운 글타래를 만드는것에 대한 두려움이있다..
아마도 KLDP에서의 분위기가 그러했었기 때문이리라 생각되기에...


이렇게 혼잣말스럽게 끄적여보네요.
나름대로 태터툴즈라는 블로그툴에 애정을 가지고 이리저리 둘러보고 싶지만..
0.9x대에서 처럼 집중적으로 파고들지 못하고 있기에..
그냥 답답한 사용자입니다.

그나마 최근의 업무가 바쁘게 돌아가서 더더욱 소스를 뒤적거릴 여유가 없기에..
그냥 이렇게나마 발만 슬쩍 걸쳐본답니다.

답답함을 확 푸세요 ~
여유가 생기실때 코드 한 줄의 여유 smile

포럼으로 이동: 잡담하기

4,267 inureyes이 작성한 답글

(1 답글들, 아이디어 및 기능 제안에 작성)

바둥이 작성:

현재 테터툴에 개인의 울타리에서 조금 더 벗어나 테터툴들이 그룹화된 그룹 울타리 서비스를 구현해 보았으면 하는 생각입니다.
마음이 맞는 혹은 주제가 맞는 테터툴 유저들끼리 하나의 그룹을 형성해 해당 그룹에 묶인 유저들의 포스트나 트랙백,댓글 상황등을 하나의 블로그에 종합적으로 보여주는 그런 서비스입니다. 그의 비슷한 예를 찾아보자면 싸이월드의 페이퍼 같은 내용입니다만. 그룹사이트 자체에서 새로운 내용을 만드는 페이퍼와는 형식이 조금 다른 개개인의 블로그에 올려진 자료들을 한데 묶고 섞어 한 블로그에 보여준다는점이 조금 틀린점입니다. allblog처럼 원하는 사람의 모든 정보를 채집하는것이 아니라 그룹형성을 원하는 유저들간의 데이터만 채집하는 그런 그룹채집기 형식이 될것 같네요 smile
이렇게 어려 유저의 데이터를 그룹화함으로서 같은 취지의 그룹들이 데이터를 공유하게되어 좀 더 효율적인 그룹작업이 가능해지고 다른유저들이 원하는 정보를 보다 편리하게 찾을수있는 이점을 얻을 수 있을 것이라 생각합니다.

그게 이올린 플랫폼입니다. (지금은 아직이지만요^^ )

곧(?) 이올린 플랫폼이 만들어지면 지금 말씀하신 것들을 모두 '쉽게' 하실 수 있게 되실거에요 smile

포럼으로 이동: 아이디어 및 기능 제안

4,268 inureyes이 작성한 답글

(3 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

chester 작성:

crizin 님이 validation 을 위해서 [##_categoy_##] 이외에 [##_category_list_##] 처럼 list 형태로 출력하는 기능을 마련했던 것으로 기억납니다. 혹시 이것을 사용하셨는지요 ??

그렇군요 ㅠ_ㅠ

이쪽은 이렇게 해결할 수 있겠네요 big_smile
이제 첨부파일 부분들을 해결하면 되겠습니다 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,269 inureyes이 작성한 답글

(3 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

또 하나;
파일을 업로드해서 포스트에 붙인 경우, 이미지가 아닌데 이미지틱하게 처리를 해서 xhtml 포맷과 왕창 어긋나게 되는 문제가 있습니다. sad

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,270 inureyes이 작성한 주제

(3 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

자기 전에 제 블로그의 xhtml validation을 한 번 체크해 보았습니다. 자연스럽게 통과될 줄 알았는데,

...통과 못했습니다. 오류가 두 개 뜨네요. ㅠ_ㅠ

# Error  Line 665 column 48: there is no attribute "currentselectednode".

...="treeComponent" currentselectednode="1" cellpadding="0" cellspacing="0" styl

You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).

This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.


# Error Line 667 column 30: there is no attribute "name".

        <table id="category_0" name="treeNode" cellpadding="0" cellspacing="0"><tr>

You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).

This error may also result if the element itself is not supported in the document type you are using, as an undefined element will have no supported attributes; in this case, see the element-undefined error message for further information.

How to fix: check the spelling and case of the element and attribute, (Remember XHTML is all lower-case) and/or check that they are both allowed in the chosen document type, and/or use CSS instead of this attribute.

보시다시피 저렇게 두 개가 뜹니다. 모두 카테고리 출력 관련한 부분의 속성이 문제입니다.

수정 들어가야 할 것 같은데, 혹시 이미 카테고리 출력 루틴 수정하신 분 있나요?
하신 분 없으시면 직접 또 소스 노가다 들어가야 하는건가요 ㅠ_ㅠ 혹시 수정하신 분 있으시면 올려주세요 smile
(이전에 daybreaker님께서 한 번 태클을 거신 적이 있는 부분 같은데, 그게 캘린더인지 카테고리인지 햇갈립니다)

...아무도 없으시면 하루 기다렸다가 내일 새벽에 노가다 뛰고 sandbox에 올려놓겠습니다 ㅠ_ㅠ

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,271 inureyes이 작성한 답글

(10 답글들, 공지사항에 작성)

아마 이전하다 잘못될까봐 걱정하시는 것 아닐까요 ㅎㅎ
살짝이라도 문제 생기면 그동안 이올린도 잠시동안 깩- 하고 죽어있을테고 그동안 사람들은 '엉엉 글 안써져 흑' 할테고요 smile

포럼으로 이동: 공지사항

4,272 inureyes이 작성한 답글

(14 답글들, 잡담하기에 작성)

여러 생각 끝에 물리학과 대학원엘 왔는데, 여기서도 맨날 하는건 결국 데이터 분석과 그걸 위한 A4지 수학삽질과 프로그래밍입니다...


뭐랄까... 요새 코딩하면서 학부 다니는 학생들 보면 부럽습니다. IT업계는 정말 무시무시한 속도로 발전하는군요. 저희땐 SVN 그런거 없이 맨날 복사 복사 파일명 바꾸어놓고 복사... 버전 관리를 파일명 뒤에 붙은 번호와 프로그램 안의 주석으로 하던 생각이 납니다. SSDP 컴파일러 짤 때, 당시 짜던 코드를 3일 전 코드로 엎어써서 완전 울었던 기억도 납니다 sad

그래도 즐거운 생각들은 나는군요. 1학년 시절 플밍 숙제 due 늦어서 유닉스의 timestamp를 속이려고 삽질하던 생각과, ANSI C 로 웹 게시판 짜오는 숙제 할 때 서로서로 다른 동기들 게시판 테스트 페이지들에 들어가서 숙제 못하도록 프로그램 버그 찾아서 다운시키면서 놀던 추억이 떠오르네요. (DDoS에, stack overflow에... 덕분에 다들 예외 처리와 로그 관리(범인을 잡아야 복수를 하죠 ㅎㅎ) 에 도사가 되었었죠.) 벌써 6년이나 된 추억이지만, 가끔 그 때를 생각하면 아직도 즐겁습니다. smile

포럼으로 이동: 잡담하기

4,273 inureyes이 작성한 답글

(4 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

답글 길게 쓰는 새에 chester님이 먼저 답글 다셨네요 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,274 inureyes이 작성한 답글

(4 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

아마 받아들여지지 않을 것입니다...
구조상 불가능하며 일부러 불가능하도록 만들었기 때문입니다. smile
(클래식 버전부터 초창기에 비슷한 건의가 아주아주 많았더랩니다)

대부분의 스킨제공 웹 페이지들이 그렇듯이, 스킨파일은 확장자는 .html이지만, 실제로는 태터 내부의 skin parser를 거쳐 치환자들이 해석되고 출력됩니다. 일종의 입력 파일이죠. (예를 들어, 서버에서 html파일도 php해석기로 해석하도록 수정한 후에 skin.html 안에 php코드를 집어넣는다고 해도 태터의 parser가 스킨에 추가한 php 코드를 해석하지 않습니다.) 그렇게 한 이유가 여러가지가 있습니다만, 지금은 보안상의 문제가 제일 클겁니다. (다중 사용자용 블로그인 경우 완전히 블로그 서버측의 대문을 열어놓는 셈이 됩니다.)

사실 스킨 확장자가 .ttskin이라든지 .tsk라든지라도 아무런 상관이 없습니다.
하지만 .html 확장자를 유지함으로써 태터에 굳이 적용을 시키지 않아도 웹 문서 편집기에서 쉽게 내용을 확인할 수 있다거나 드림위버나 나모웹에디터, nvu로 수정할 수 있다는 점이 유리해지기 때문에 그냥 유지하는 것 뿐일겁니다.

(물론 하위버전 호환성도 있겠죠 smile )

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)

4,275 inureyes이 작성한 답글

(19 답글들, 버그 보고 및 QA (Quality Assurance)에 작성)

아이디 지워 드렸습니다 smile

포럼으로 이동: 버그 보고 및 QA (Quality Assurance)