2,776

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

1.1.1 의 요건에서는 1.1.2로 밀렸습니다. 아직 내부적으로 플러그인 형태의 지원을 할지, 코어 지원을 할지 결정을 하지 못한 상태입니다.

플러그인 형태의 지원이 된다면 차칸아이님와 이야기해서 여러 노하우를 공유해서 개발하고 싶습니다. (이건 차칸아이님께 아직 여쭈어보지 못해서 그냥 제 희망사항; )

최근 리비전에서 구버전의 방명록 플러그인을 쓸 경우 그럴 '수도' 있습니다. 제이파커님이 해결해 놓으신걸로 알고 있습니다.

http://dev.tattersite.com/svn/plugins/C … G_Default/ 를 한 번 받아서 테스트 부탁드립니다. smile

2,778

(5 답글들, 질문과 답변 / 사용자 지원에 작성)

제가 최신 리비전으로 업하고 하나 로니나님께 날려봤습니다 big_smile

으음 문제가 어디일까... 했는데 혹시나 해서 하나. FF라면 adblock을 한 번 끄고 시도해 주세요. smile

2,779

(5 답글들, 질문과 답변 / 사용자 지원에 작성)

으잉?

해당 리비전 부탁드려요 smile 전 어제도 쐈는데...

카운트로 넘어오는 값이 없을 경우의 예외 처리로 작동할테니 괜찮지 않을까요?

처리했습니다. smile r2768입니다.

감사합니다^^

2,782

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

channy 작성:

현재의 레가시를 없앨 수는 없을 겁니다. 호환성 유지를 해야 겠지요. 대체 치환자를 만들어 제 이야기는 두 개의 방식 모두를 지원하게 하는 것입니다.

현재 방식 (계속 유지)
Tags:  [##_tag_label_rep_##]

추가 방식
Tags:
<s_tag_label_rep>
<a href="[##_tag_label_link_##]" class="tags" rel="tag">[##_tag_label_name_##]</a>
</s_tag_label_rep>

추가 방식에서 , 나 |로 구분하는 것은 CSS로 충분히 커버 가능할 뿐만 아니라 rel="tag"에 대한 자유도도 줄수 있죠. 게다가 딜리셔스, 테크노라티용 태그 삽입에도 도움이 됩니다.

기존에 loop 방식을 하나의 치환자에서 표현하는 게 있다면 이런식으로 대체 방식을 제공하는 게 좋겠다는 생각입니다.

옙^^ 이해는 하고 있습니다. smile 그런데 지금 걸리는 레거시가 1.1에서 1.0 지원의 차원이 아니라 1.0 코어에서도 1.1 스킨을 사용할 수 있도록 하는 상하위 호환성에 관련된 레거시입니다. ㅜ_ㅜ

실제로 사이드바 기능이 있든 없든, 현재의 1.1 스킨들은 1.0 코어에서 그냥 쓸 수 있습니다. 1.1 스킨이 범람하면 1.0 사용자들은 강제 업데이트를 해야 하기 때문에, 새로운 스킨 규격을 아예 정의하지 않고 기존의 규격을 추가적으로 업데이트하면 문제가 생긴다는 지적에 따라 타협했습니다. 그래서 베타 과정에서 rc로 오면서 스킨 치환자에 대한 많은 부분이 잘려 나갔습니다. ㅠ_ㅠ

어느정도 이주가 되었다 싶으면 본격적인 추가를 하거나 규격 업데이트를 할 수 있겠습니다. 사실 이번 일로 레거시 유지에 대한 의문도 좀 생겨서 ttskin 규격 1 자체도 업그레이드를 하는게 어떨까 하는 생각을 하게 되네요. 그 경우 1.0 사용자분들이 아쉽게 되겠지요..

r2765, r2766, r2767에서 해당 문제들을 수정하였습니다. smile

2,784

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

이번 일로 하나 확실히 알게 된 것은, 저희의 목표이기도 하지만 블로그가 개인에게 독자적 언론과 미디어로서의 힘을 실어주기를 바랬던 희망만큼은 이루어 지고 있음을 확연히 알게 되었습니다. 동시에 개인이 그걸 얼마나 이해하느냐 못하느냐에 따라서 그게 얼마나 독이 될 수 있는지도 확실히 깨달았습니다.

씁쓸하지만, 올블로그가 자사를 열렬히 응원하던 팬을 한 명 잃었음도 확실합니다.

올블로그 사원들이 이런저런 포스트를 통해 표현하는 것을 보며 왜 저렇게 태터툴즈를 싫어할까 생각을 좀 했습니다. 아마도 이를 일종의 헤게모니에 관한 문제로 인식하고 있는듯 합니다. 자고 있던 이올린을 깨웠고, 태터툴즈는 계속 변합니다. 올블로그에 태그 못 퍼가게 할려고 그거 바꿨다는 식으로 설마 생각 했겠습니까마는, 저녁에 하늘이님의 글을 보고 나서 결국 그정도 생각이었나 싶어 굉장히 마음이 좋지 않습니다.

블로그를 이해한다면서도, 그게 가지고 있으며 가질 수 있는 힘을 이해하지 못하는 모습을 보았습니다. 합리적이고 논리적인 설득절차 없이 자신의 감정섞인 말 한마디를 통해 -그것도 난도질한 글의 조각들로- 노력한 많은 사람들을 어떻게 무시하는지도 보았습니다. 적어도 기업으로 대해 주었다면 그에 대한 응답이 있어야 하는데, 동아리식 답변과 포스트를 보았습니다. 그 과정에서 TNF 커뮤니티의 수많은 사람들을 싹 무시하는 것도 보았고, 어떻게든 기업대 기업의 문제로 가지고 가고 싶어하는지도 보았습니다.

어떻게 좋은 이미지를 유지하면서 잘 마무리하고 싶은 모습도 보았습니다만, 개구리한테 돌 던지고 머리깨지면 약 발라주는 격입니다. 개인적으로 올블로그쪽에 걸었던 큰 기대만큼이나 이번 일은 잊지 못할 것 같습니다. 사람이 사람을 평가하는 것은 굉장히 좋지 않은 일입니다. 그래서 저는 사람에 대한 평가는 유보하고, 기업에 대한 평가만을 머릿속에 남기도록 하겠습니다.

이후에 정당한 방법으로 문제점을 제기하거나 토론을 진행할 경우 언제든지 환영할 것입니다. 그렇지만 자신이 자의든 타의든간에 블로그가 태생적으로 가지고 있고 사람에 따라 가지게 되는 권력으로 커뮤니티와 그 성과물을 비하하거나 의도를 가지고 여론을 호도할 경우 절대로 좌시하지 않을 것입니다.

아울러 TNC 분들께는 이래저래 죄송하게 됐습니다. 그냥 넣고 땡치기에는 스스로 허락이 안 됐습니다. 이 문제는 얼마든지 생산적인 논의와 해결이 가능한 문제입니다. 하지만 한 회사의 CEO와 부사장이 커뮤니티를 어떻게 생각하고 다루는지 보면서도 그냥 넘어갈 정도로 제 성격이 좋은 편은 아닙니다.

2,785

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

daybreaker 작성:

흠.. 자기 전에 rss리더 훑어보다가 읽어볼 만한 것 같아 링크 걸어둡니다.
http://dnzin.com/cunningweb/2007/01/04/ … -standard/

rel-tag를 인정한 이상, 기본값으로 rel-tag 삽입 쪽으로 가는 것이 나을 것 같고, rss에 명기된 permalink에 대한 크롤링은 허용하는 것이 맞지 않겠는가 하는 이야기인데 그렇게 하는 것이 좋을 것 같습니다.

그럼 그렇게 하도록 하죠. smile

그나저나 생각해보니 테크노라티등은 해당 명기 없어도 태그 잘 읽어가더군요. 맨날 쓰고 있는데 잘 읽어가서 별 문제 있는지 모르고 있었습니다.

플러그인 호출시 deprecated된 함수를 쓰고 있는 문제입니다. dev.tattersite.com쪽에는 해결이 되어 있으니, 그쪽 것으로 업데이트하도록 하겠습니다^^

2,787

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

daybreaker 작성:

슬슬 새 스킨 시스템을... 털썩;

스펙 정해야죠. 언제 관심있으실 분들 여기 붙어라! 해서 회의 한 번 할까요? smile

2,788

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

channy 작성:
inureyes 작성:

베타와 샌드박스 공히 r2756 / r2757 입니다. 스킨 설정 - 출력 설정에서 사용의 유무를 변경할 수 있습니다.

참고로 앞에 있었던 논의에 따라, 해당 기능을 사용으로 할 경우 포스트 하나만 출력되는 경우 - 즉 각 포스트의 절대 경로로 접근하는 경우에만 해당 글의 태그 속성에 rel 속성이 붙도록 변경하였습니다.

우선 이런식으로 임시 방편으로 해결 해야겠지만 궁극적으로는 inureyes님이 말씀하신 방법대로 스킨에서 자유도를 높여 주는 방식을 써야 합니다.
워드 프레스도 스킨에서 한 함수로 모두 표현 하는 방법과 Loop로 개별 속성을 표현 하는 방법 들이 함께 제공됩니다.

문제가 된 특정 글의 태그 목록 처럼 loop 구문으로 데이터를 출력하는 것들은 모두 loop 패턴에 대한 대체 방식을 제공해 줘야 합니다. (현재 태그 클라우드 처럼)

옙. 현재 발목잡힌 스킨단에서의 레거시를 털어버리고 새 스킨 시스템을 얹는대로 그렇게 갈 예정입니다.

1.0대 버전으로의 1.1. 스킨 하위 호환성 고려만 아니면 벌써 그렇게 갔을겁니다. 흑 T_T

2,789

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

아직 요건의 코드 반영이 완전히 끝나지 않았습니다. smile

언어팩 담당자 분들께 리소스는 내일 발송할 예정입니다.

2,790

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

베타와 샌드박스 공히 r2756 / r2757 입니다. 스킨 설정 - 출력 설정에서 사용의 유무를 변경할 수 있습니다.

참고로 앞에 있었던 논의에 따라, 해당 기능을 사용으로 할 경우 포스트 하나만 출력되는 경우 - 즉 각 포스트의 절대 경로로 접근하는 경우에만 해당 글의 태그 속성에 rel 속성이 붙도록 변경하였습니다.

2,791

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

아마도 entries의 갯수를 세는 명령이 php에 있었던걸로? 기억됩니다. 걍 $entries 넘어온게 하나인지 보시면 될듯? smile

덧) 오오 로보트는 알았는데 헬스는 몰랐습니다; 나도 몸짱...

2,792

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

gofeel 작성:
inureyes 작성:
daybreaker 작성:

....어째 또 결자해지의 칼이 저한테 올 것 같은 이 느낌! =3==3==3=3

참고로 말씀드리자면 blog/item.php 부분과 더불어 lib/model/skin.php를 약간 수정하면 될 것 같은 생각이 드는군요.

화이팅 >_< (방학인데 수업도 안듣잖아요 하하^^)

방학인데 수업도 안듣는다디 "진짜" 심심하시겠군요. roll

그쪽은 일단 풋노트 업글판 내놓아 주시고. cool

2,793

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

daybreaker 작성:

....어째 또 결자해지의 칼이 저한테 올 것 같은 이 느낌! =3==3==3=3

참고로 말씀드리자면 blog/item.php 부분과 더불어 lib/model/skin.php를 약간 수정하면 될 것 같은 생각이 드는군요.

화이팅 >_< (방학인데 수업도 안듣잖아요 하하^^)

2,794

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

그나저나, 아까 daybreaker님께서 말씀하신 올블로그의 웹 페이지 직접 파싱을 통한 rel="tag"의 수집문제는 확실히 짚어야 할 부분이군요. 하아. RSS에서 카테고리 읽기가 그렇게 힘들었었나...

2,795

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

mf 위키에

#  Where shouldn't I use rel-tag?

    * rel-tag expresses a particular relationship (a) between the page you are on and (b) the target of a link. If you're not asserting this relationship, don't use rel-tag. In particular:
          o don't use rel-tag in Tag Clouds (http://en.wikipedia.org/wiki/Tag_cloud)
          o don't use rel-tag to refer to the pages http://www.technorati.com/tag/xyz, http://del.icio.us/tag/xyz, http://www.flickr.com/photos/tags/xyz/ (and so forth) if you're not asserting "this page is tagged 'xyz'"

라고 되어 있는데, 후자의 경우 그 링크가 태그임을 명시적으로 가리켜주어야 하는군요.

빈 칸이 들어있는 태그의 경우 아직 규격 확정이 되어 있지 않은데, 이 부분도 함께 고민을 더 해야 겠습니다. 태터 소스 내부코드에는 빈칸이 - 로 바뀌는데, 태그도 그냥 그렇게 해 버릴까요? 규격 확정한 후에 저쪽에 알려주면 될 것 같습니다.

덧) 저도 쓰고 나니 그새 답글이;;;

2,796

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

daybreaker 작성:

흠.. 나중에 하늘이님이 올린 글을 보니 rel="tag" 방법이 microformat으로 채택된 것이긴 하군요.
스펙을 훑어봤는데, 제가 대충 알고 있던 것과는 조금 달라서 몇 자 더 써봅니다.

일단 <a href="http://xxxxxx/.../yyy" rel="tag">linkname</a>과 같은 형태를 가지고 있어야 하고 링크된 uri에서 마지막 segment에 있는 문자열(여기서는 yyy)만 태그로 인식할 뿐 linkname과는 관계가 없더군요. 그러한 microformats의 정의대로라면, rel="tag"를 쓴 것이 HTML 표준에서 말하는 rel 속성의 의미를 해친 것이라 보기는 힘들 것 같습니다. 링크된 문서와 현재 문서와의 관계를 나타내기 위한 것이고 URL을 통해 tag를 정의하는 것이며 그 문서가 반드시 존재해야 함을 정의하고 있거든요. (오히려 예전에 태터툴즈에 있었던 '키워드' 기능과 더 가깝다고 볼 수 있겠습니다.)

graphittie님이 지적하신 3번 사항에 대해서는 좀더 논의를 해봐야 한다고 생각하며, 필요하다면 microformat에 issue로 제기(rel-tag issues 참조)하는 건 어떨까 합니다.

문제는 RSS만 크롤링하느냐, rel-tag 정보를 얻기 위해 웹페이지까지 크롤링해도 되느냐 하는 것으로 보입니다. 이건 정책/라이센스 상의 문제가 되므로 rel-tag 표준을 인정하고 넘어간다 하더라도 분명히 짚어야 하지 않나 싶습니다.

rel-tag를 인정할 경우 일단 태그 클라우드의 경우는 불가능할 것 같고, 각 포스트가 하나씩만 보일 때만 해당 포스트의 태그 링크를 rel 처리를 해주는 방법이 있을 수 있겠군요. 파서부분에 약간의 변화가 있겠지만 mf를 인정한다면 그렇게 연결하는 것 자체는 별 무리 없을 것 같습니다. 어느정도 정리를 해서 mf 위키쪽으로 이러한 경우의 confliction에 관해서 제안을 보내 봐야겠네요.

이상, 올블로그 CEO님의 블로그를 잠시 들어가보고 경악한 inureyes였습니다. (올블로그, 기업 아니었나요? 하는 생각이... 블로그코리아 서버 날라간 사건때의 초창기부터 엄청 좋아했었는데 하루만에 이미지 다 무너지네요. 글은 난도질이고 링크는 진짜 안 보이게 되어 있길래 그냥 댓글로 링크나 하나 달고 왔습니다.)

2,797

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

안녕하세요. smile

오랜 시간이 걸려서 TNF의 저장소가 베타 떼고 이제 정식으로 작동을 시작합니다. (trac 0.10.3의 오류가 이제야 완벽하게 해결이 되네요)

주소는 http://dev.tattersite.com 입니다. 포럼 위의 링크를 따라가셔도 됩니다.

혹시 해당 저장소에서 플러그인 개발이나 태터툴즈 관련 프로젝트등을 진행하실 분들께서는 진행하실 프로젝트 설명과 함께 아래 댓글로 연락처를 남겨주시거나, trac@tattersite.com 으로 메일을 보내주시기 바랍니다.^^

사용법은 subversion과 동일합니다. 어려우신 분들을 위해서 윈도우용으로 tortoiseSVN 이라는 도구가 나와 있으므로 한 번 사용해 보시기 바랍니다. 이 프로그램으로 http://dev.tattertools.com 에서 직접 태터툴즈 개발 버전을 내려받을 수도 있습니다.

그럼 즐거운 시간 되세요! >_<

2,798

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

골빈해커 작성:

꼬랑지. 마지막으로 조금 감정적인 말씀을 드리자면 제가 회사의 입장으로 말을 한다고 하셨는데, 그런 말씀은 정말 억울하고 싫고 화가납니다. 저를 아는 누구한테고 한 번 물어보십시오. 제가 회사를 먼저 생각하는지 블로거를 먼저 생각하는지. 그런 말씀은 제가 블로그를 위해 굶어가면서까지 노력했던 몇년간의 세월을 무시하시는겁니다.

올블로그는 블로그칵테일의 메타블로그 솔루션인 것으로 알고 있고, rel='tag'의 수집은 그 솔루션의 크롤러와 태터툴즈의 수정된 소스의 confliction에 대해서 말씀하고 있는 것으로 이해하고 있습니다. 그리고 그 부분은 TNF의 모더레이션 그룹에서 예전에 판단한 바와 상충하는 부분이 있는 것이죠.

골빈해커님께서 회사를 먼저 생각하는지, 블로거를 먼저 생각하는지는 이 이야기의 주제와 특별한 관계가 없습니다. 단지 한말씀 드리자면 프로페셔널해야 하는 내용을 개인의 영역으로 밀어 넣는 것은 지양해야 하는 점이 아닌가 싶습니다.  블로거를 회사보다 먼저 생각하기 때문에 블로그칵테일의 입장에서 생각되는 것이 억울하다고 생각되실 수 있습니다만, 그것은 개인적인 부분입니다. 회사 차원에서 메타 블로그 솔루션이 개발 및 업그레이드 중인 것이 현실이고, 적어도 올블로그에 대해서 이야기할 때는 메인 개발자로서 둘을 일체화 시켜야 하는 것이 프로페셔널한 자세가 아닌가 생각합니다. 제가 TNF의 소스 디벨로퍼 분들께 항상 부탁드리는 내용이기도 합니다.

사족이지만 골빈해커님처럼 굶어가면서 블로그 사용자들을 위해 노력하고 있는 사람들을 많이 알고 있습니다. 저도 제 시간 쪼개서 쓰느라 스케쥴 밀릴 때는 며칠 잠도 안 잡니다. 대부분 댓가도 없이 노력해 주시고 계시고, 어떻게 그 많은 분들께 힘이 될 수 있을지 생각 많이 하는 중입니다.

이대로라면 논의가 새겠군요.
포럼에서는 어떤 종류의 토론도 환영합니다. 비판이 비난이 되지 않는 한 모든 비판과 토론은 발전으로의 가능성을 여는 첫걸음이니까요.

2,799

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

골빈해커님, 말씀하신 모든 부분에서 글의 태그정보는 RSS의 category 필드로 날라가고 있습니다.

rel='tag'가 문제되는 부분은 해당 페이지를 직접 파싱하지 않는 한 전혀 문제되는 부분이 없습니다. 이올린의 경우도 날라가는 핑을 분석해서 img가 있으면 그걸 읽어오는 식이지, 해당 웹 페이지를 파싱하지는 않습니다. 애초에 이올린은 보내준 핑으로만 해당 페이지를 인식하지, 그걸 가지고 가서 삽질은 안합니다. 하면 제가 여론 형성을 해서 막았을겁니다.

올블로그에 사용자가 RSS를 등록할 때, RSS의 공개에 찬성하는지 아니면 RSS가 등록된 웹페이지 전체의 크롤링에 찬성했는지는 제가 가입을 워낙 초창기에 해서 기억이 나지 않습니다만, 대부분의 경우 전자라고 생각합니다. 아무래도 그에 대해서는 해명이 있어야 할 것 같군요. 굉장히 올블로그를 좋아하는 사용자로써, 이런 견해를 만나게 되어 진심으로 유감입니다.


말씀하신 '그냥 만들어진' rel=tag 부분을 자동 파싱하게 되면 사용자가 빼고 싶어도 못 뺍니다. 저는 기본적으로 도구는 사용자가 하고 싶은 것을 하게 해 주어야 한다고 생각하고 있고, 하기 싫은데도 해 주는 것은 굉장히 잘못된 방향이라고 생각합니다. 그래서 계속 태터툴즈 코어를 줄여나가고 있고 플러그인으로 대부분을 이관하고 있습니다.

TNC에서 이 건을 추가하는 쪽으로 밀어붙여도, TNF의 수장으로써 제가 해당 코드 revert 프로세스에 대한 비토를 행사할겁니다. 전 TNC나 블로그칵테일처럼 회사도 아니라, 회사의 입장을 우선적으로 생각하지 않습니다. 솔직한 마음은 사용자가 원하는 만큼의 자유를 가질 수 있다면 어찌해도 상관 없습니다.

원하는 분은 rel='tag'를 스킨단에 추가하는 쪽으로 하고, 그것도 귀찮은 분은 rel='tag'를 자동으로 붙여주는 플러그인을 만들어 쓰시면 될겁니다. 이슈화가 되면 아마 나오겠죠. 단기적으로는 해당 태그의 삽입에 관하여, 장기적으로는 메타 사이트들이 등록한 정보에 명기된 이상을 쿼리하는 것에 대하여 이슈화를 시킬 필요가 있다는 판단이 듭니다.

2,800

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

rel='tag'의 강제삽입이 사용자의 자유를 해친다고 판단하며, 이 건에 대해서는 집어넣지 않는 것으로 하겠습니다.

필요한 분은 스킨 편집에서 해당 속성을 넣을 수 있다는 정도를 매뉴얼에 명기하도록 하는 쪽으로 하죠.