 |
블로그를 방문해 주셔서 감사합니다! 어느덧 되돌아 보니 긴 시간이 한순간에 흘러가 버린 것만 같습니다. 하지만 개미와 같이 열심히 일한 덕분에 조금씩 성과가 나타나고 있습니다. 이런 노력이 계속된다면 좀 더 획기적인 결과와 우리는 만날 수 있을 것이라 기대합니다. |
트랙백(Trackback)이란? | 기타트랙백(Trackback)이란?
“내가 작성한 글을 다른 사람에게 알리는 기능”입니다. 쉬운 이해를 돕기 위해서 코멘트와의 차이점을 알려 드리겠습니다. 다른 사람의 블로그에 방문했을 때 글을 읽고 그 글에 대한 간단한 코멘트를 남깁니다. 코멘트는 보통 글 길이에 제한을 두기 때문에 글에 대한 긴 글을 쓸 수가 없습니다. 또 한번 쓰고 난 후 코멘트를 수정하고 싶을 때는 다시 그 블로그를 찾아 들어가야 하는 번거로움이 있지요. 트랙백 서비스는 위의 단점들을 모두 해결할 수 있습니다.
트랙백을 이용하면 다른 사람<A라고 예를 듭시다>의 글에 대한 생각이나 의견들을 내 블로그에 남길 수 있으며, 내가 남긴 글은 <A>의 트랙백 아래에 자동 붙게 되는 것입니다. 즉, 나는 내 블로그에 글을 썼지만 결과적으로는 <A>라는 사람의 글에도 내가 썼던 글 내용이 자동으로 보여집니다.
블로그에서 지원하는 트랙백은 블로그 뿐만 아니라 트랙백을 지원하는 외부 사이트와도 모두 완벽하게 연동이 되는 표준규격을 사용하였습니다.
블로그 와 외부 블로그 간 트랙백 쓰기
1. 트랙백 서비스를 지원하는 블로그라면 트랙백을 눌러서 주소를 복사하세요. (사이트에 따라 트랙백 명칭이 다를 수 있습니다.)
2. 내 블로그로 가서 글쓰기를 누른 후, 복사해온 트랙백 주소를 글쓰기 하단에 있는 트랙백 주소 입력에 붙여 넣습니다.
3. 그리고 일반 글쓰기 할 때와 같이 글을 입력하세요. 글쓰기를 마치셨다면 확인을 누르세요. 내 블로그로 이동합니다.
4. 좀 전에 방문했던 타 블로그에 가보면 내가 쓴 글이 붙어져 있음을 확인할 수 있습니다.
트랙백 서비스는 한 회사에서 서비스하는 블로그는 같은 블로그끼리만 커뮤니케이션 할 수 있다는 통념을 깨트리는 아주 좋은 기능입니다. 이 기능을 이용해서 외국의 블로그와도 커뮤니케이션 할 수 있으며, 수정 또한 간단하게 내 블로그에서 할 수 있습니다.
619 comments
( 10317 views )
| [ 0 trackbacks ]
| permalink
( 3 / 1601 ) 
absolute 와 relative의 차이점, div와 span의 차이점 | 기술absolute(절대적 위치)
브라우저를 기준으로 위치 속성을 사용 하며 parent 요소에 의해 하위 위치에
있다면 그 곳을 기준으로 합니다.
즉, 레이어 속성인 z-index를 쓸경우 top, left, right, bottom을 통해서
좌표를 잡는데 실제 브라우저를 기준으로 위치하게 됩니다.
relative(상대적 위치)
객체가 위치 속성에 의해 설정 되거나 태그내에 위치시 마지막 위치를
기준으로 상대값을 정해 줍니다.
즉, 포지션을 정하지 않은 상태에서 보면 그곳에 위치가 브라우저에
나올것입니다. 바로 그곳을 기준으로 포지션에 relative를 사용해서
top, left, right, bottom을 이용해서 위치를 정할수 있습니다.
위에 질문 하신 소스에 보시면 relative를 먼저 사용 하셨는데요
두 태그를 바꿔서 해보시면 아실 겁니다.
그리고 div와 span태그는 서식에 관한 태그입니다.
div
div태그는 문단 서식에 관한 태그입니다. 그래서 스타일을
이용해서 크기를 잡지 않는다면 기본적으로 줄바꿈이 됩니다.
즉, 라인 전체에 적용이 되는 이유입니다.
span
span태그는 서식에 관한 태그이긴 하나 문단이 아닌 한줄에 관한 서식
입니다.
그래서 span태그에 스타일로 크기를 잡아주지 않으면 태그가 쓰인곳 안에
내용까지만 적용이 됩니다.
예를 들어
<div style="background-color: blue">줄전체에 색상</div>
위 경우는 라인전체에 해당(문단을 적용 하기 위해 자동으로 줄바꿈)
<span style="background-color: blue">이글에만 색상</span>
이글에만 색상
위의 경우는 줄서식이므로 태그안에 쓰인 글에만 적용 됩니다.
그럼 수고 하세요
[기사]이젠 Captcha마저 막을 수 없단 말인가? | 뉴스[기사]이젠 Captcha마저 막을 수 없단 말인가?
다수의 웹메일 계정 서비스업체들이 자동으로 메일계정을 생성하는 봇(bot) 소프트웨어를 막기 위한 기술을 적용하고 있지만 스패머들이 이를 간단히 무력화시키고 있는 것으로 드러났다.
스패머들은 무단 메일을 발송하기 위해 주로 핫메일, 야후와 같은 웹메일 서비스를 사용한다. 계정 1개당 한번에 보낼 수 있는 수가 제한돼 있기 때문에, 엄청난 양의 메일을 발송해야 하는 스패머들은 수천 개에 달하는 웹메일 계정을 등록해야 한다. 이 계정 등록과정을 자동으로 처리하는 소프트웨어가 바로 봇.
야후, 핫메일, 네이버 등 웹메일 업체들은 봇 소프트웨어의 자동 계정등록을 막기위해 계정 등록시 ‘Captcha(Completely Automated Public Test to tell Humans and Computers Apart)’ 테스트를 거치도록 하고 있다.
Captcha는 간단한 단어를 시각적으로 훼손시키고 복잡한 패턴의 배경화면 위에 보여준다. 메일 계정을 등록하려는 사용자는 해당 단어를 그대로 키보드로 입력해야 계정을 생성할 수 있다. Captcha가 보여주는 ‘일부러 훼손시킨 글자’는 사람은 쉽게 알아볼 수 있지만 컴퓨터(봇)는 알아보지 못한다. 따라서 봇을 사용할 수 없는 스패머는 자동으로 계정을 생성할 수 없게 되고, 스팸 메일 발송도 그만큼 어려워지게 되는 것이다.
스패머가 이 Captcha 테스트를 무력화 시킬 수 있다는 사실은 올초 보잉보잉 블로그(boingboing.net)를 통해 처음 드러났다.
먼저 스패머는 포르노 사이트를 만들어 광고를
해 방문자를 모은다. 그리고 무료로 포르노 컨텐트를 보여주기전에 Captcha 인증 단계를 거쳐 방문자에게 단어를 입력하도록 한다. 바로 이 부분이 Captcha 테스트를 통과하는 단계다.
즉 스패머가 여기에 적용해둔 스크립트는 웹메일 생성의 Captcha 테스트 단계와 포르노 사이트를 동기화시키고, 방문자가 입력한 Captcha 단어를 즉시 봇 소프트웨어로 전송, 결국 봇이 계정을 생성하도록 한다. 방문자는 Captcha 단어를 입력한 대가로 포르노 컨텐트를 무료로 액세스할 수 있게 된다.
이에 대해 컴퓨터 어쏘시에이츠(CA)의 사이먼 페리 부사장은 웹메일 서비스 업체들이 새로운 보안책을 개발할 때 마다 결국 이를 무력화시키는 방법이 개발된다면서 “보안이란 것은 움직이는 타겟을 맞추는 일과 같다”고 말했다.
그는 “하지만 보안이 발전되면 스패머는 그만큼 스팸메일을 발송하기가 어려워진다. (서비스 보안 개발은) 바로 그 수준을 점점 더 높여가는 과정”이라며 비록 무력화하는 방법이 발견됐다고 하지만 Captcha는 분명히 스패머들의 작업속도를 늦추고 있음을 강조했다.
페리는 “Captcha가 적용되기 전에 봇 소프트웨어는 하루에 100만개의 핫메일 계정을 생성했다. 하지만 지금 스패머들은 1만개의 계정을 생성하려면 1만명을 먼저 자기 사이트로 불러 모아야 한다. 이는 분명한 발전”이라고 말했다.
MS 핫메일과 야후는 Captcha 문제에 관한 언급을 거부했다
4-6. OPML(Outline Processor Markup Language) | 일반4-6. OPML(Outline Processor Markup Language)
OPML은 "다른 운영체제와 환경 위에서 동작하는 어플리케이션에서 outline으로 구조화된 정보의 교환을 허락하는 XML 기반의 문서 형식입니다.
2000년 9월 16일에 Dave Winer (UserLand 소프트웨어)는 새로운 XML 기반의 “Outline Processor Markup Language" 또는 OPML, 1.0 공고했습니다.
"이 OPML 형식의 목적은 아웃 라이너를 통하여 탐색되거나 제어가 가능한 아웃 라이너와 인터넷 서비스 사이에서 정보를 교환하는 길을 제공합니다.
이경우에 '아웃라인'은 각 이음매가 끈 가치와 함께 한 세트의 이름을 지어지는 속성을 포함하는 트리입니다.
OPML 디자인 목적은 방대한 양의 데이터는 쉽게 탐색하고, 편집이 가능하드록 형상화된 포멧이기 때문에 쉽게 읽을 수 있다. 따라서 단순하며, 자체적으로 문서화가 가능하며, 확장성이 매우 뛰어납니다.
보다 쉽게 설명하자면 여러 개의 블로그 사이트 RSS 또는 ATOM을 하나의 문서 파일로 만들어 놓은 XML이 파일이 OPML입니다.
OPML 문서의 예)
<?xml version="1.0" encoding="EUC-KR"?>
<opml version="1.0">
<head>
<title>나의 OPML 목록</title>
<dateCreated>2005-05-16T11:55:41</dateCreated>
<ownerName>userid</ownerName>
</head>
<body>
<outline text="자주보는목록">
<outline type="rss" text="SecureIIS" title="SecureIIS" xmlUrl="http://blogbridge.naver.com/post/postXMLList.jsp?blogId=invictusy"/>
<outline type="rss" text="제목없음" title="제목없음" xmlUrl="http://blog.naver.com/tb/gkdus2004/20010744338"/>
</outline>
</body>
</opml>
5. RSS 리더별 RSS, OPML, ATOM 지원상황
사용된 XML의 URL
RSS 0.92
http://fantomaster.com/fantomNews/feed/rss/
RSS 1.0
http://www.w3.org/2000/08/w3c-synd/home.rss
RSS 2.0
http://blog.daum.net/xml/rss/yyeosan
http://ecrm.dreamwiz.com/GEN/rss/hompy.rss
RSS ATOM 0.3
http://blog.daum.net/xml/atom/yyeosan
4-4. 차세대 컨텐츠 신디케이션을 위한 ATOM 표준화 | 일반4-4. 차세대 컨텐츠 신디케이션을 위한 ATOM 표준화
RSS의 확산과 더불어 컨텐츠 신디케이션의 중요도에 대한 인식과 새로운 기능, 그리고 표준화의 필요성이 대두되었습니다.
컨텐츠 신디케이션 표준화를 위한 많은 논의와 노력들이 진행되었으나, 사실상 병렬화된 다양한 포멧의 RSS 규격을 단일화 시키고 표준화 시키기 어렵다는 결론에 도달하게 되었고, 새로운 표준화를 위한 ATOM이라는 이름의 프로젝트로 구체화되기 시작하였으며, 이 표준화 활동을 어디에서 진행할 것인가에 대한 많은 노력들이 2003년을 거쳐 2004년 초까지 진행되었다.
이 과정에서 Atom 프로젝트 그룹과 표준화 활동을 유치하기 위한 경쟁이 W3C와 IETF에서 벌어지게 되었다. W3C에서는 웹 기술과 시맨틱 웹 기술과의 연관성, 그리고 웹 표준화 기구라는 대표성을 내세워 W3C에서 활동이 진행되길 요청하였고, IETF에서는 보다 자유로운 참여가 가능하다는 장점을 내세웠다. 결국 사용자들의 투표에 의해 보다 자유로운 멤버들의 참여가 가능한 IETF에서의 활동하기로 결정하고, Atom Publishing Format and Protocol (atompub) WG을 구성하여 2004년 말부터 활동을 시작하였다.
현재 IETF의 AtomPub WG에서는 “웹 리소스들(블로그, 온라인 저널 등)을 위한 효율적인 컨텐츠 관리 프로토콜 개발”이라는 커다란 목적을 가지고 크게 세가지의 표준 초안 개발 작업을 진행하고 있으며, 이중 자동발견 규격을 제외한 두가지 표준 초안에 대한 표준화 작업을 진행하고 있다.
-5. RSS 와 ATOM 의 스펙 비교
RSS 에서의 ITEM 신디케이션 포맷
대부분의 경우 블로그 업체들은 description 중 일부 요약본만 전송시켜 줌으로써, 전문을 보기 위해서 자사의 사이트를 방문하도록 유도한다.
따라서 뉴스리더 프로그램에서는 항상 2~3 줄의 간단한 요약만 확인이 가능하다.
ATOM 에서는 ITEM (Entry 로 표현된다.)
ATOM 도 SUMMARY 형태의 description 을 제공하기는 하지만,
