반응형
오랜만에 팁하나 올립니다.^^;

컴퓨터 앞에서 작업을 하다가.

잠시 컴퓨터 앞에서 떠날때. 간단한 방법으로 화면을 잠글수 있습니다.

방법은 2가지 있는데요.

먼저 첫번째 방법.

바탕화면에서 오른쪽 마우스 -> 새로 만들기 -> 바로가기

항목 위치 입력에 아래를 입력합니다.

C:\WINDOWS\system32\rundll32.exe user32.dll,LockWorkStation

아이콘과. 파일명은 각자 이쁘게 바꾸시면 되겠네요.

두번째 방법.

Ctrl키와 Alt키 사이에 있는 Windows키+L를 눌러주세요~

----
하던 작업은 계속 진행됩니다. 이게 먼말이냐면;

예를들어 음악을 켜놓고 위의 두방법을 쓰면 음악은 계속 재생됩니다.ㅋ

저는 클박같은데서 자료 다운시켜 놓고 동생이 못 건드리게; 이방법을 씁니다.ㅋ

참!!! 윈도우에 비번 걸려있으면 더욱 좋아요!!
반응형
10월 11일 오늘자로 81.95.146.228라는 아이피로 51개에 달하는 스팸댓글이 달렸다.

그 내용을 보면 좀 웃기다.

마치 영한번역기를 돌려 쓴듯.
너는 아름다운 웹사이트가 있는다!
우수한과 아주 도움이 되는!
아주 재미있는 지점. 감사.
중대하고 유용한 위치!
친구는 너의 위치의 현재 팬이 되었다!
등등등. 더욱더 신기한건

등록된 아이피는 81.95.146.228하나인데

링크된 사이트는 여러개라는 거.

그 링크된 사이트는 약을 팔거나, 저질 포르노사이트.

바로 삭제해버리고 아이피 차단 시켰다.

반응형
약 3주만에 온것 같네요.

오늘 막 수련회 갔다와서 침대에 누을려고 보니 놓여있네요.

사용자 삽입 이미지

비행기 타고 온듯 합니다. ㅋ

사용자 삽입 이미지
사용자 삽입 이미지

관할 우체국에서 저때문에 고생한다는 말을 하시더군요.ㅋ

안쪽 내용도 찍어두었는데

모자이크 처리가 왜 이리 귀찮은지.ㅋ  나중에 올리겠습니다.ㅋ

반응형
구글은 새 프로젝트 ‘국제 청소 주말(International Cleanup Weekend)’을 발표하며 오는 13~14일 세계 각지에서 일제히 지역 청소 활동에 동참하자고 호소했다.

이것은 유저가 청소하는 지역을 ‘구글 맵스’로 지정해 정리하는 것으로 ‘구글 어스’팀의 활동에서 시작됐다.

지역 관계를 위한 사내 환경 활동단체로 시작된 이 활동은 현재 15개국의 커뮤니티에서 받아들여지고 있다. 구글 어스의 사회공헌 활동 팀은 6~10명으로 구성돼 자택 부근을 청소하고 그 모습을 찍은 사진이나 비디오를 이 팀의 구글 맵스에 올려 성과를 공개해 달라고 요구했다.

개인적이고 자주적으로 활동해도 되지만, 구글의 협력 단체인 아이디얼리스트(Idealist.org), 시에라 클럽, 영국 스카우트 협회 등 단체와 상담할 수도 있다. 이들 단체는 지역 활동을 주최할 것을 회원들에게 호소하고 있다.

사용자 삽입 이미지
활동을 주최하는 사람은 우선, 마이 맵스 기능을 사용해 개인 구글 맵을 만든다. 그 다음 구글의 청소 활동 형식에 맵의 URL을 붙여 ‘국제 청소 주말’ 데이터베이스에 등록한다. 그림은 해안 청소를 예로 든 맵이다.

청소 활동을 주최할 때 유의점은 쓰레기봉지나 목장갑 등을 준비하고 팀 멤버의 휴대 전화 번호를 알리는 것 등이라고 구글은 밝혔다. 또 활동 사진이나 비디오를 각 그룹의 구글 맵에 게재해 성과를 공개할 것을 요청했다.

구글의 이런 활동이 뜻밖이라고 생각할 수도 있다. 그러나 결코 그렇지 않다. 구글 어스는 이전에도 워싱턴 D.C.에 있는 대량학살 기념박물관과 협력해 수단 다르푸르 주의 대량학살 현장을 지도에 나타낸 프로젝트를 했었다. 이번 프로젝트는 세계적인 관심을 사서 지구 규모의 활동으로 확대하기 위한 유효한 수단이라고 구글 어스는 밝혔다.
구글이 오랜만에 멋진 기사를 냈습니다.

정말 참신한 아이디어인것 같네요. 구글맵스로 청소구역지정.

학교에서나 볼수있었던 청소구역지정을 구글맵스로 지구를 청소한다.

역시 구글입니다.

'Web' 카테고리의 다른 글

신종 스팸 댓글 수법인가.  (0) 2007.10.11
구글 PIN번호 도착!  (2) 2007.10.10
프로블로거가 되기위한 7가지 필수요건  (0) 2007.08.19
아직도 UTF-8을 안 쓰십니까?  (0) 2007.08.19
내 도메인의 가치는?  (1) 2007.07.15
반응형
내용 출처 : http://zrock.tistory.com/entry/seven-requisite-of-problogger

프로와 아마의 차이는 무엇일까요? 스포츠에서 프로는 생계를 위한 수익을 목적으로 전문적인 운동선수를 말하며 아마는 재미와 흥미로 운동을 즐기는 사람을 말합니다. 프로블로거는 블로그를 통해 생계 유지를 위한 주 수입을 얻는 블로거를 말합니다. 여러가지 해석이 가능하지만 가장 객관적인 기준은 수입과 전문성일 것입니다. 얼마전 EBS에서 방영한 구글 다큐멘터리에서는 청년 프로블로거 존 게일이 소개되어 많은 이들의 부러움을 샀습니다. 존 게일만큼은 아니더라도 프로블로거가 되기 위해서 갖춰야 할 요건들에 대해 알아보겠습니다.

1. 충분한 시간
시간은 모든 요건중에 가장 필수적입니다. 충분한 시간의 투자 없이는 블로그에서 좋은 수입을 창출하기는 불가능합니다. 시간이라는 요소는 비단 글을 작성할때뿐 아니라 다른 블로거들과 소통하고 (댓글, 피드백) 정보를 수집하고 (블로그 니치에 관한 정보의 지속적인 수집) 계속해서 업데이트 상태를 유지하는데 (꾸준한 포스팅) 있어 필수적입니다.

2. 주제에 대한 전문성
주제에 대한 전문성이 없다면 다른사람들로 부터 신용을 얻을수가 없습니다. 해당 분야에 대한 박사학위까지 요구하는 것은 압니다. 하지만 남들은 모르는 사실이나 자신의 경험에서 나오는 그 분야에 관한 노하우와 배경지식은 갖추고 있어야 독자들에게 전문성을 인식시켜줄수가 있습니다.

3. 끊임없는 열정
주제에 대해 전문적인 지식을 갖추고 있다 하더라고 결국엔 니치에 관한 열정이 수반되어야 합니다. 블로그로 돈을 벌고자 한다면 흥미를 가지는 것들에 대해서 연구하고 포스트를 작성해야 합니다. 그리고 독자들은 당신의 글을 읽고 당신이 블로그 주제 즉 니치에 열정이 있는지 없는지를 대번에 눈치챕니다. 만일 정말로 열의를 가지고 글을 쓴다고 독자들이 느끼는 경우엔 그만큼 충성도 높은 독자를 얻을수가 있는 것입니다.

4. 좋은 글을 쓰는 능력
문법적인 실수없이 글을 쓸 정도가 되나요? 글로써 자신의 아이디어를 다른 사람들과 의사소통 할수 있는 능력이 되나요? 이 질문들은 당신이 블로그로 생계를 유지하고 싶다면 반드시 자신에게 물어봐야 할 것들입니다. 셰익스피어에 버금가는 테크닉을 자랑하는 블로거가 아니라도 걱정하지 마세요. 시간이 지남에 따라 글을 계속 쓰다보면 자연히 늘게 되어 있는 법입니다. 저는 아직 초딩수준이지만 말입니다.

5. 컴퓨터에 관한 기술적인 지식
프로블로거가 되려면 남들과는 다른 차별화를 꾀해야 하는데 이때 필수적으로 요구되는 것이 컴퓨터에 관한 전반적인 지식입니다. 예를 들어 호스팅에 대한 개념이 있어야 하고 도메인네임을 구입해서 연결하고 스킨을 만들수 있을정도의 포토샵과 CSS 기술이 필요합니다. 더 나아가서 PHP등도 알아두면 좋습니다.

6. 블로깅 관련 지식
기술적인 지식과는 별개로 프로블로거가 되기 위해서는 블로그코리아, 올블로그와 같은 블로그 메타사이트는 어떻게 구성되어 있으며 어떤 식으로 이같은 공간을 이용해 블로그를 노출시킬수 있는지를 알고 있어야 합니다. 트랙백을 어떻게 사용해야 하는지 알아야 하며, 북마킹 사이트와 같은 기본적인 것들에 대한 사전지식이 요구됩니다. 부차적으로 검색엔진 최적화(SEO)에 대한 지식도 필요합니다. 결코 쉬운일이 아닙니다. 하지만 블로깅을 하다보면 자연스레 알게 되는 것이니 크게 걱정할 필요는 없어요.

7. 창의적인 아이디어
우물 안개구리가 되지 않을 자신이 있나요? 다른사람들이 흥미를 느낄만한 창의적인 아이디어를 가지고 있나요? 대개의 프로블로거들은 그들의 블로그 니치(주제)에 있어 선구자들이었습니다. 진정한 가치는 똑같은 일을 더 잘하는 것이 아니라 같은 일을 하더라도 다르게 하는 것입니다. 창의적이고 독창적인 아이디어가 질좋은 포스트를  작성하는데 도움이 되며 블로그 프로모션에도 한몫하게 되고 결국엔 새로운 수익을 창출하도록 도와줍니다.
반응형

Written by 안재우(Jaewoo Ahn), 닷넷엑스퍼트(.netXpert)

 ASP 등으로 되어 있는 이전 사이트들을 .NET으로 마이그레이션하다가 한번씩 겪는 문제점 중 하나는 그놈의 지긋지긋한 한글 인코딩 문제입니다.

 그 유명한 베스트셀러(?)인 '조엘 온 소프트웨어'에서도 이러한 인코딩 문제에 대해 언급을 하고 있습니다. 미국애들 중에 몇몇이 여전히 ASCII를 쓰는 것처럼, 우리나라 개발자들 역시 여전히 KSC-5601이나 ECU-KR 인코딩을 고집하는 사람들이 많습니다.

 심지어 일반 사용자들마저도 한글 인코딩과 관련된 문제를 겪어보지 않은 사람들이 없을 것입니다. 가장 대표적인 사례로, 페이지의 이미지가 보이지 않는 일은 누구나 겪어 봤을 것입니다. 실제 이미지가 없는 경우는 제외하고, 이 문제의 원인 중 99%는 이미지 파일 이름이 한글로 되어 있는 경우입니다.

대부분의 사이트 또는 지식검색 등에서는 IE의 옵션에서 URL을 항상 UTF-8로 보냄이라는 옵션을 꺼서 해결하라고 말하곤 합니다. 문제는 이것이 근본적인 해결책은 아니며, 한글 인코딩 문제의 해결을 더더욱 멀게 만드는 장벽이 된다는 것입니다.

 잠깐 빗나갔는데 다시 개발에 대해서 초점을 맞춰서 다시 얘기해보겠습니다.

일반적으로 한글 인코딩과 관련된 문제가 말썽을 부릴 소지가 있는 경우는 다음과 같습니다.

1. 웹 페이지의 한글 컨텐츠가 KSC-5601이나 EUC-KR로 되어 있는 경우

2. 브라우저에서 호출하는 URL에 한글이 포함되어 있는 경우

3. 데이터베이스에서 한글 인코딩이 UTF-8이 아닌 다른 것으로 지정되어 있는 경우

 먼저 1번의 경우..

근본적인 문제가 생기는 원인은 ASP.NET을 비롯하여 .NET에서는 기본 인코딩이 UTF-8인 것부터 출발합니다. 그러므로 예를 들어, 웹 페이지의 한글 컨텐츠가 KSC-5601이나 EUC-KR로 되어 있는 경우, 인코딩이 깨지게 되는 것입니다.

물론 이 문제의 잘못이 무조건 개발자에게만 있느냐하면, 절대 그렇지는 않습니다. 일반적으로 웹 페이지를 디자인하는 것은 웹 디자이너들의 몫이며, 이 디자이너들이 페이지를 디자인할 때 KSC-5601이나 EUC-KR을 사용해서 작성해버리는 경우가 대다수입니다.

또, 종종 개발자를 당혹스럽게 하는 것 중 하는 .inc나 .js를 통해 include한 파일의 경우입니다. 아무 이상 없이 잘 돌던 .js였는데, 단지 ASPX 내에 붙여 넣었다는 이유만으로 스크립트 에러가 발생합니다. 이러한 경우, 역시 십중팔구는 스크립트 파일 내에 한글이 포함되어 있는 경우입니다.

일단 이 문제를 해결할 수 있는 방법은..

각 페이지의 meta 태그 등에서 charset을 지정해주거나,

web.config에서 다음과 같이 인코딩을 지정해주는 방법이 있습니다.


<configuration>
   <system.web>
      <globalization
         requestEncoding="ksc5601-1987"
         responseEncoding="ksc5601-1987"
         fileEncoding="ksc5601-1987"/>
   </system.web>
</configuration>

그런데, 이렇게 하면 정말 해결이 된 것일까요?

역시 이것 역시 임시적인 해결책에 지나지 않습니다.

더이상 인코딩 문제를 겪지 않으려면, UTF-8을 쓰는 것이 확실한 답입니다.

그러므로 바람직한 방법은 설사 디자이너가 다른 인코딩으로 전달을 해왔다고 하더라도, 메모장 등을 통해서 UTF-8로 변환해서 저장하는 것입니다. 스크립트 파일들 역시 메모장에서 연 다음 UTF-8로 변환해서 저장합니다.


2번의 경우.. 한글이 포함된 URL의 경우, 올바른 전송을 위해서는 한글을 URL에 맞게 인코딩을 수행해야 합니다.


예를 들어..

http://search.naver.com/search.naver?where=nexearch&query=한글인코딩&frm=t1

이 아니라..

http://search.naver.com/search.naver?where=nexearch&query=%C7%D1%B1%DB%C0%CE%C4%DA%B5%F9&frm=t1

가 되어야 한다는 것입니다.

(물론 네이버는 euc-kr 인코딩을 쓰고 있긴 합니다. -_-;;)


.NET의 경우..

문자열을 신뢰할 수 있는 URL 문자열로 만들기 위해 두 개의 메서드를 제공합니다.

HttpServerUtility.UrlEncode

HttpUtility.UrlEncode


이와는 반대로 다시 디코딩해서 원래의 문자로 돌리도록 다음 메서드들도 제공됩니다.

HttpServerUtility.UrlDecode

HttpUtility.UrlDecode


결국 Response 시에는 UrlEncode를 사용해서 인코딩을 하고, Request 받은 것을 처리할 때는 다시 UrlDecode를 사용해서 디코딩을 하는 형태로 해결을 하면 됩니다.


물론 이러한 부분을 처리하는데는 개발자의 귀차니즘이 수반되게 됩니다. 그 귀차니즘 덕분에 수많은 사용자들이 URL을 항상 UTF-8로 전송 옵션을 꺼야 합니다.


3번의 경우.. SQL 서버에서보다는 Oracle에서 많이 볼 수 있는 경우입니다.

상당수 Oracle 데이터베이스가 UTF-8이 아닌.. 심지어 US-ASCII7을 사용하는 경우가 있습니다.

대표적인 경우가 회사 내부에서 SAP을 사용하는 경우인데, 제가 알고 있기론 SAP 설치 시 기본 인코딩이 US-ASCII7인 걸로 압니다.

그래서 어떤 문제가 생기느냐? .NET에서 Oracle에 연결하기 위한 프로바이더로 ODP.NET이라는 놈이 있습니다. 이놈은 .NET이 붙은 넘 답게.. UTF-8을 사용합니다.

고로 ODP.NET을 사용하여 데이터베이스 인코딩이 US-ASCII7로 지정된 DB에서 한글 데이터를 읽으면 한글이 깨져버리는 사태가 발생하게 됩니다.

이에 대한 해결책은 DB 서버의 인코딩을 바꿔주거나, 쿼리에서 일일이 Encode 메서드를 사용해서 UTF-8로 변환하거나, 받은 후 애플리케이션 코드에서 인코딩을 변환시켜주는 수 밖에 없다는 것입니다. 어느 것 하나 쉬운게 없는데, 이러한 고생을 하는 이유가 한글 인코딩에 대해 무지했던 과거의 개발자/시스템 관리자들이 저질러 놓은 사고입니다.


사실 가장 이상적인 것은 Windows에서 인코딩을 UTF-8만 사용하도록 해버리면 확실한 해결책이 될지도 모릅니다. 대신 언젠가 만약 그런 날이 온다면, 기존의 UTF-8을 사용하지 않은 웹 사이트들은 문제가 생기게 되겠죠.

그러나, UTF-8이 표준화되었으므로 언젠가는 정말로 그런 날이 올지도 모릅니다. 그런 날이 오지 않기를 빌면서 통일을 반대하는 것보다는 하나씩 하나씩 바꿔 나가야 하지 않을까 합니다.


제발 이제는.. UTF-8을 쓰세요.

+ Recent posts