|
이하는 오마이뉴스에서 퍼온 것이에요...^^ 하루에 하나씩 실천해야지...호호호 ========================================================================================================= "인기 블로그 되려면 타인을 도와라, 솔직해라" [오마이뉴스 안홍기 기자]
비결이 소개된 곳은 '우웹'(wooweb.org)이라는 블로그로, 이 블로그의 주인은 8일 '인기블로그를 만드는 15가지 방법'이라는 글을 올려 많은 블로거들의 호응을 얻었고, 블로거 커뮤니티 올블로그에서 8일 오전 중 실시간 인기글 1위에 오르기도 했다. 이 글은 마이크로소프트의 기업 블로거이기도 했던 유명 블로거 로버트 스코블(scobleizer.com)과 그의 부인 메리엄 스코블(maryamie.spaces.live.com)이 발표한 것을 간략하게 정리한 것. 스코블 부부는 지난 10월 25일부터 27일까지 미국 시애틀에서 열린 '블로그 비지니스 서미트 2006 '(The Blog Business Summit)에 참석, '10 Ways To A Killer Blog'라는 제목으로 인기블로그의 비결을 소개했다. 블로거 휴 매클라우드(Hugh Macleod)가 그린 삽화로 구성된 스코블 부부의 발표자료 제목은 '10가지 방법'으로 돼 있지만 내용은 15가지를 소개하고 있다. 다음은 스코블 부부의 발표를 토대로 '우웹'에 올라온 '인기블로그를 만드는 15가지 방법'. 1.Blog cause you want to - 당신이 원하는 것, 사랑하는 것, 좋아하는 것에서부터 블로깅은 시작된다. 2. Read other blogs - 다른 블로그를 방문하여 읽어라. 다른 이들의 블로그를 방문하는 순간 당신은 이미 블로거다. 당신이 관심가지고 좋아하는 주제에 대한 블로그를 꾸준히 방문하고 또 격려·성원하라. '관계'가 만들어지는 계기가 된다. 3. Pick a niche you can own (be different) - 모든 사람은 검색으로, 구글을 통해 세상과 대화한다. 일반인들이 애용하는, 시의적절한 키워드(또는 분야)에 대해 자주 언급하였다면 때에따라 당신은 검색결과의 상위에 노출될 것이고 많은 독자를 얻게 될것이다.(예를 들어 blog about the London Underground 라는 블로그는 매우 지루한 주제의 블로그라 생각되지만 런던 지하철 폭발사건이 있은 후 이 블로그는 검색에 의해 순식간에 인기블로그로 변모하였다. 이후 이 블로그에 기재된 독특한 포스트들이 인기를 끌기 시작했다.) 4. Link to other blogs - 다른 블로그 포스트의 링크를 걸어라. 그리고 링크한 포스트에 덧글을 남겨라. 블로거들은 일반적으로 리퍼러를 통해 방문자들의 동향을 확인한다(포털 블로거들은 제외). 따라서 그들에 대한, 그들의 주목을 끌만한 주제에 대해 블로깅을 하고 링크를 걸어라. 5. Admit mistakes - 실수를 인정하라. 실수나 실언으로 인해 부정적인 덧글이나 욕설이 남겨지더라도 떳떳하게 인정할 경우 방문자들의 태도는 다시 긍정적으로 변화한다. 실생활에서 처럼 실수를 인정하는 길만이 독자들로부터 신뢰를 얻는 최선의 방법이다. 6. Write good headlines - 낚시(?)를 잘 하라. 방문자는 주로 검색엔진(제목)과 Feed(메타블로그 or 리더기-제목)를 통해 정보를 습득한다. 멋진 제목은 검색결과페이지에서 Feed 목록에서 당신의 포스트를 눈에 띄게 해줄 것이다.(물론 좋은 내용이 수반되어야 함은 필수) 7. Use other media- 일반적으로 오프라인보다 온라인에서 읽기속도가 30%가량 떨어진다고 한다. 따라서 podcast, vedio, image 등을 적극적으로 활용(트래픽에 영향을 주지않도록 관련 서비스를 활용한다. Youtube, Flickr 등)할 경우 방문자의 가독성과 빠른 이해에 도움을 주므로 동일한 내용이라도 다양한 방법으로 차별화를 꾀하도록 하라. (Techcruch의 경우 모든 포스트에 이미지를 이용하고 있다.) 8. Have a voice - 기교적으로만 글을 쓰려 노력하지 말고 인간적인 면을 보여라. 친한 누군가(친구나 와이프)와 이야기하듯이 글을 쓰라. 9. Get outside the blogosphere - 다양한 모임과 이벤트 등 활발한 오프라인 활동을 통해서 블로거들과 Face to face 관계를 맺어라. 그러면 더 많은 링크와 독자를 얻게될 것이다. 오프라인 활동 또한 다양한 미디어(Flickr, Youtube 등)를 통해 포스팅하라. 이를 확인하기 위해서라도 그들은 당신의 블로그를 방문할 것이다. 10. Market yourself - 적극적으로 마케팅하라. 아직까지 명함에 블로그 주소를 포함한 사람은 별로 없다. 명함 등과 같이 자신의 블로그를 홍보할 수 있는 모든 방법을 이용하라. 11. Write well - 항상 오타를 확인하고 배포 전에 다시 한번 문장을 확인하라. 글의 상단에 주제를 배치하고 글의 길이가 길 수록 완독률이 떨어지므로 글의 제목과 첫번째 단락이 독자가 포스트를 읽을지 말지를 결정하는 중요한 요인이라는 것을 명심하라. 또한 글쓰기 등에 관한 책을 꾸준히 읽고 글쓰기 능력을 배가하라. 12. Expose yourself - 당신만의 스타일(개성)을 드러내라. 마치 신문기사와 같은 문구로 포스팅하지 말라. 100개중 한두개 정도는 당신의 개인적 관심을 드러내어 주제의 지루함을 방지하라. 13. Help other people blog - 당신이 블로깅을 하며 배운 것을 공유하고 새로운 블로거들의 목소리를 전해 그들이 블로고스피어에 적응하도록 도와라. 14. Engage with commenters - 다른 이들의 블로그에 덧글이나 트랙백을 남겨 대화에 참여하라. 독자들은 종종 덧글/트랙백을 통해 당신의 블로그를 방문하곤 한다. 15. Keep your integrity - 항상 정직함을 유지하고 자신에 대해 숨기거나 독자들을 속이려 하지 말아라. 어떠한 광고형 포스팅을 하거나 상업적 목적을 위한 어떤 댓가를 받았을땐 숨기지 말고 이를 밝혀라. (에델만의 '월마트 가짜블로그 사건'이 한 예이다.)
요즘 심한 슬럼프에 빠져서 이것 저것 잘 되는 일이 없는 것 같다.
과연 나는 무엇으로 사는가? 요즘 고민 중에 하나는 이 것이다. 뭔가를 열심히 하는 내 모습이 무척이나 자랑스러웠던 시절이 있었고 결과 또한 그에 상응되던 시절이 있었다. 그러나 지금은?... 한동안 두문불출하며 나의 새로운 30대를 준비하고 있었지만 아직 그러한 장미빛 꿈이 실현될지는 미지수다. 장미빛 꿈이라...어차피 꿈이 없는 인생은 너무 무료하지 않는가? 그렇다고 꿈을 쫓아가면서 사다는 것이 궁극의 인생 행복을 가져다 주는 것은 아닌 것 같고 무수히 많은 시행착오를 겪고 있는 지금은 어떠한 동기 부여가 필요한 것 같다. 스포츠...나를 지탱시켜주던 힘이 있는 그런 존재이었던 시절이 있었다. 그러나 지금은 아주 아주 잘되지 않는다. 나이를 탓하지 않아도 플레이에서 난 이미 패배자인 것 같다. 왜그러지? 뭐 지금 이런 혼란과 혼돈이 나에게 무의미 하지는 않는 것 같아서 좋기는 하지만 너무 혼란스럽다. 이대로 밀고 나갈 것인가? 아니면 다 포기하고 현실에 타협할 것인가? 대답은 모르겠다이다...결국 포기를 하지는 않겠지만 아무래도 이런 물음의 과정을 즐기는 건 아닌지... 그럴 시간이 인제는 정말 부족한데...앞으로 5개월 후면 인생을 한번 정리해야할 30대가 오건만...미치겠다... 2006년 6월 24일 도서관에서...
아래의 내용은 내친구 헌기군 블로그에서 퍼왔음을 알려드리고
저작권은 그 친구하테 물어보시오... ========================================================================================================= 당신이 제작한 프로그램을 사용하는 사용자들이 당신에게 해당 프로그램에서 "crash"가 발생했다고 투덜거렸다고 하자. 당신은 단지 "crash"가 발생했다는 사실만을 알뿐, 그래서 프로그램에 어딘가 문제가 있다는 사실만 알게 될 뿐, 어디에 문제가 있는지 발견해 수정하기는 여간 어려운 일일 것이다. 그런데, 만약 그 유저가 "crash address"를 보내주었다면, 또는 "crash"가 발생했을 때 "crash address"를 전송 받을 수 있는 구조의 프로그램이라면, MAP 파일을 통해 코드의 어느 부분에서 crash가 발생했는지 찾을 수 있다. 지금부터 MAP 파일을 이용해서 crash address로부터 코드의 어디에서 crash가 발생했는지찾아내는 방법을 알아보도록 하자.
2005년 4월 8일 박헌기 정리 P.S. 꽤 열심히 정리했어요. ^^ 혹시 다른 곳으로 퍼가실 때는 출처를 남겨주세요. Creating a MAP File 먼저 MAP 파일을 가지고 있어야 분석을 할 수 있을 것이다. 따러서 MAP 파일을 만드는 방법부터 알아보도록 하자. Visual Studio를 기준으로 기본 releas 셋팅으로부터 몇몇 옵션을 조정하면 MAP 파일을 얻을 수 있다. 다음의 셋팅을 조정해 주자. 뭐, 영문판 Visual Studio이든, 한글판이든 비슷하니까 별로 어렵지 않게 셋팅을 조정할 수 있을 것이다. 1. Project Setting의 C/C++ 탭 -> Debug Info. -> Line Number Only 를 선택한다. (이 셋팅을 하지 않으면 MAP 파일은 얻을 수 있지만, 어떤 함수에서 crash 가 발생했는지까지만 찾을 수 있고, 어떤 라인에서 crash가 발생했는지는 찾기 어려워 진다. 함수까지만으로도^^;; 자신 있다면, 이 셋팅은 하지 않아도 되겠다. 이 셋팅을 바꾼다고 exe/dll 자체에 변화가 생기는 것은 아니니 이왕이면 셋팅해 주면 좋겠다.) 2. Link 탭 -> Generate mapfile 옵션을 선택해준다. 아마도 여기까지 하면 빌드 옵션의 명령줄 부분에 /MAPINFO:LINES 와 /MAPINFO:EXPORTS 등이 생길 것이다. 이 셋팅으로 빌드하면 실행파일과 이름이 같은 .map 파일이 생성될 것이다. 코드가 수정되면 당연히 MAP 파일도 바뀌게 되므로 버젼을 하나 만들때마다 이 MAP 파일을 보관해 두는 센스가 필요하다. (Build 후 이벤트 등을 이용하면 좋겠다.) Reading the MAP file 이제 crash address로부터 어디가 문제인지 찾아보자. 만약 코드에 다음과 같은 "무시무시한" 라인이 있다고 예를 들어보자. char* pEmpty = NULL; *pEmpty = 'x'; // This is line 119 당연히도 위의 코드는 crash 를 유발하는 코드가 된다. 이제 MAP 파일을 보자. MAP 파일의 앞부분은 다음과 같다. 뭐 약간씩 다를 수도 있지만 Visual Studio에서 컴파일 했다면 대강 비슷한 모습을 가질 것이다. 앞부분에서는 Preferred load address를 주의 깊게 보자. (이 Preferred load address는 Project Setting에서 수정이 가능하다. "Link 탭의 고급 -> 기준 주소" 부분을 수정해 주면 된다. 이 Preferred load address 값은 이후 계산에 포함되는 값이므로 좀 더 단순한 값으로 수정해 두는 것도 좋을 것으로 보인다. 사실 기본값인 00400000으로도 충분하긴 하다. 단 여러 모듈을 복합적으로 사용하는 어플리캐이션의 경우에는 각 dll, exe 마다 다른 다른 기준주소를 지정해 두는 편이 구분을 위해 좋을 것 같다.) ********************************************************************* Test Timestamp is 4254ed7d (Thu Apr 07 17:21:17 2005) Preferred load address is 00400000 Start Length Name Class 0001:00000000 000ef7e6H .text CODE 0001:000ef7f0 00006d47H .text$x CODE 0001:000f6540 000001a0H .text$yc CODE .............. ( 중략 ) .............. Address Publics by Value Rva+Base Lib:Object 0001:00000000 _WinMain@16 00401000 f MAPFILE.obj 0001:000000c0 ?MyRegisterClass@@YAGPAUHINSTANCE__@@@Z 004010c0 f MAPFILE.obj 0001:00000150 ?InitInstance@@YAHPAUHINSTANCE__@@H@Z 00401150 f MAPFILE.obj 0001:000001b0 ?WndProc@@YGJPAUHWND__@@IIJ@Z 004011b0 f MAPFILE.obj .............. ( 중략 ) .............. entry point at 0001:00000350 Static symbols 0001:000035d0 LeadUp1 004045d0 f LIBC:memmove.obj 0001:000035fc LeadUp2 004045fc f LIBC:memmove.obj .............. ( 중략 ) .............. Line numbers for .ReleaseMAPFILE.obj(F:MAPFILEMAPFILE.cpp) segment .text 24 0001:00000000 30 0001:00000004 31 0001:0000001b 32 0001:00000027 35 0001:0000002d 53 0001:00000041 40 0001:00000047 43 0001:00000050 45 0001:00000077 47 0001:00000088 48 0001:0000008f 52 0001:000000ad 53 0001:000000b3 71 0001:000000c0 80 0001:000000c3 81 0001:000000c8 82 0001:000000ff 86 0001:00000114 88 0001:00000135 89 0001:00000145 102 0001:00000150 108 0001:00000155 110 0001:00000188 122 0001:0000018d 115 0001:0000018e 116 0001:0000019a 119 0001:000001a1 121 0001:000001a8 122 0001:000001ae 135 0001:000001b0 143 0001:000001cc 172 0001:000001ee .............. ( 이하 생략 ) .............. ********************************************************************* 설명의 편의를 위해 예를 들어 설명하겠다. 사용자가 보내온 crash address가 "0x004011a1" 라고 하자. 이 값은 "00401150"와 "004011b0" 사이의 값임을 알 수 있다. 이는 crash가 InitInstance@@YAHPAUHINSTANCE__@@H@Z 함수에서 발생했음을 이야기 한다. 다시 말해 crash address를 얻었다면 "이를 넘지 않는 가장 큰 Rva+Base 값"을 가진 함수를 찾으면 되는 것이다. 이정도만 하더라도 crash 문제를 해결하는데 있어서 많은 도움이 될 것인데, 추가로 어느 라인에서 crash가 발생했는지 알 수 있다. 자~ 잘 따라와 보자. 필자는 글을 잘 못 쓴다 ^^; 여러분이 이 글을 잘 이해해 주는 것이 가장 중요하다. 먼저 Portable Excutable (PE)의 크기값을 알아야 한다. (PE가 무엇인지 궁금하다면 다른 자료를 찾아서 보도록 하자) 이는 MAP 파일에서 알 수 있다. 앞의 예에서 다음의 부분을 주목하자. 0001:000000c0 ?MyRegisterClass@@YAGPAUHINSTANCE__@@@Z 004010c0 f MAPFILE.obj 처음에 Address, 000000c0 과 Rva+Base, 004010c0 의 차를 보자. Address에서 Preferred load address를 더하고 PE를 더하면 Rva+Base가 된다. 우리는 Preferred load address의 값이 00400000임을 이미 알고 있으므로, PE의 값은 1000임을 알 수 있다. 이제 본격적으로 어떤 라인에서 crash가 발생했는지를 찾아보자. 다음과 같은 계산을 한다. 여기서 말하는 값은 모두 16진수임을 주목하여 생각한다. "crash address" - "Preferred load address" - "the Size of PE" 우리의 예에서는 0x004011a1 - 0x00400000 - 0x1000 = 0x1a1 와 같이 계산되겠다. 이제 이 값을 MAP 파일에서 찾아보자. 앞서 crash가 발생한 함수를 찾을 때와 같이 해당 소스파일에서 "넘지 않는 가장 근접한 최대값"을 찾아보면 119번 라인이라는 사실을 알 수 있다. 아싸~ 이제 119번 라인에서 crash가 발생했음을 알게 되었다. 이제 우리는 release 빌드에서도 어디서 crash 오류가 발생했는지 알게 되었다. 뭐, memory dump 같은 방법을 사용하면 이 상황에서 변수의 값도 볼 수 있겠지만, 코드의 어느 라인에서 crash가 발생했는지 아는 것만으로도 프로그램의 유지보수에 많은 도움이 될 것임에는 틀림 없다. 여러분은 "BugslayerUtil" 라는것을 아시는가? 이를 이용하면 앞에서 이야기한 crash가 발생했을 때 crash address를 사용자가 프로그램을 유지보수하는 사람에게 보내줄 수 있는 구조를 만들 수 있을 것이다. 추가로, crash가 발생했을 때의 call stack 역시 받아볼 수 있을 것이다. 관심 있으신 분은 한번 찾아보시기를 권해 드린다. 나중에 이 부분도 정리하도록 해야겠다 ^^ 2005년 4월 8일 박헌기 정리
전반 10(상대편):4
후반 19(상대편):12 전/후반 20개의 골을 내기를 하는 순간....이정도의 상황이라면 누구나가 자포자기하게 된다. 물론 않그런 사람도 있을테지만 내 농구 경험상 우리는 8골을 넣어야 하고, 상대편은 1골만 넣으면 게임오버되는 상황에 기를쓰고 열심히 하는 사람은 별로 없다. 나도 모르게 동료도 모르게 패배의 차디찬 기운을 몸소 느끼며 그럴수도 있다고 스스로를 위한하기 마련이다. 그러나 에이스는 그렇지 않다. 에이스는 어떤 존재인가? 적어도 내 경험상 과자는 아니다. 절체 절명의 순간 모든 플레이어는 에이스에 의존하게 된다. 제는 꼭 넣어줄꺼야라고 생각하며 패스를 하기 마련이다. 에이스의 여러 옵션중 실력이 제일 중요하겠지만 클러치 능력또한 중요한 옵션이다. 마지막 순간의 동료와 팬의 기대를 저버리지 않고 엄청스런 부담스런 시선을 받으며 슛을 성공시키기는 그리 쉽지않다. 슛을 성공시키는 순간 에이스는 게임을 이기는 것보다 더 중요한것을 얻게된다. 바로 자신감이다. 자신감이라는 놈은 자기기 경험하고 연습한 상황일수록 발휘되기 쉬운 특성을 가지고 있어서 다음번에 이런 상황과 유사한 상황이 무딪치게 되었을때 드디어 빛을 바라는 것이다. 이런 의미에서 마이클 조던은 누구보다도 유리하다. 이런 경험을 많이 했으므로... 물론 어제의 얘기로 돌아가자. 우리는 8골을 연속으로 넣으며 경기를 뒤집었다. 마지막 19:19, 동점인 순간...질수도 있다는 패배의 기운이 온몸을 덮쳐올때 회심의 마시막 슛~성공~승리...뭐 이론 이야기다. 자랑은 아니지만 짜릿했다. 에이스이 부활인가? 어째튼 마지막 순간을 해결했다는 자신감이 온몸에 각인되었던 하루였다. 자신감을 코트 밖에서 발휘할 수있을까? 나에게 던져 보는 질문이다. 그 자신감이 발휘되기를 기원하며... 코비
|
 by 열혈보이 카테고리
이전블로그
이글루링크
최근 등록된 덧글
제 블로그에 퍼갑니다.
by huhu at 06/08 몸 크기로 보나~ 의상으.. by bbibbo at 05/08 hello by Naomi at 04/06 hello by Naomi at 04/06 hello by Naomi at 04/06 hello by Naomi at 04/06 nice by Robert at 04/06 nice by Robert at 04/06 nice by Robert at 04/06 nice by Robert at 04/06  | |||||||||||
