'2010/03'에 해당되는 글 8건

  1. 2010/03/18 호스트 네임과 도메인 네임의 차이 (7)
  2. 2010/03/16 전문가 초청 스터디 방법 (4)
  3. 2010/03/15 웹 용어 정리
  4. 2010/03/11 HTML5 (2)
  5. 2010/03/11 빌드와 컴파일의 차이
  6. 2010/03/11 Java Property 사용하기
  7. 2010/03/03 노먼 락웰 (2)
  8. 2010/03/03 소프트웨어 품질과 테스팅
Daylogs/Etc

호스트 네임과 도메인 네임의 차이

발생일: 2010.03.18

문제:
어떤 면접에서 도메인 네임과 호스트 네임의 차이에 대한 질문을 받았습니다.
음... 정확히 알지 못해 대답하지 못했죠.

아쉬운 마음에 돌아와서 그 차이점이 뭔가 찾아봤습니다.


해결책:
호소트 네임이 한 대의 서버나 PC를 지칭하는 말이라면,
도메인은 그 서버나 PC 그룹을 대표하는 이름이라고 할 수 있다고 하네요.

예를 들어 네이버 메일 주소인 http://mail.naver.com 을 보면
naver.com 이 네이버 서비스를 대표하는 도메인 네임이 되고,
mail 이 호스트 네임이 되는 것입니다.

음. 그렇다면, http://www.naver.com 이라고 되어 있을 때에,
여기서는 어떤 게 호스트 네임이 되는 걸까요.
www 도 호스트 네임일까요...

네~ www 도 호스트 네임이라고 하네요.
www 가 World Wide Web 이라는 건 알고 있었는데,
전제 주소에서 이게 호스트 네임의 역할을 하고 있는 지는 미처 몰랐습니다.

일반적으로 홈페이지에 접속한다라는 것은 web 접속의 의미가 강하기 때문에,
도메인 네임에 www 호스를 붙인다고 하네요.
그에 맞게 서버 설정 시에도 naver.com 을 접속하면
www.naver.com 과 동일한 페이지로 갈 수 있도록 설정한다고 합니다.


아래 링크에서 정보를 얻었습니다.


다음에 질문 받으면 잘 대답할 수 있겠습니다.
(다음이 올까요..? ^^;)

저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG hostname, 도메인네임, 호스트네임
Trackback 0 Comment 7
Daylogs/Etc

전문가 초청 스터디 방법

발생일: 2010.03.16

문제:

며칠 전 Xper 에서 주최한 Rebecca Wirfs-Brock 방한 기념 번개 모임에 다녀왔습니다.

레베카 아줌마는 매우 친 애자일적인 소프트웨어 아키텍트이시고,
이 분의 설계 철학은 Responsibility-driven design 이라고 합니다. (위키 참조)

평일 저녁에 강남역 토즈에서 김창준님의 진행으로 편안하게 모임을 가졌습니다.
특별한 형식 없이, 둥글게 앉아 다과와 함께 질문하고 답변하는 방식으로 진행됐습니다.

개인적으로는 일방적인 주입식 강의가 아닌 이런 편안한 형식의 모임은 거의 처음이었던 것 같아요.
가만 생각해보면 몇 번 있었던 것 같기도 한데, 있어봤자 손에 꼽을 만할 것 같습니다.

여하튼 굉장히 느낌이 좋았습니다.
주제와 내용도 좋았지만, 그걸 떠나서 뭔가 열린 모임 같달까~ 이런 방식이 참 좋았습니다.

아무래도 이런 오프라인 모임의 경험이 너무 없었던 것 같아요.
자주 나가봐야겠습니다.^^;

그 날 모임에 대해 떠올려보다가,
'특별한 모임 절차 없이 어떻게 매끄럽게 잘 진행되었나'란 생각이 들어,
이런 스터디 방법에 대해 몇 가지 정리해 보려고 합니다.


해결책:
이번 모임을 생각해보면서,
'전문가를 초청해 간단한 모임을 가지려 할 때 어떻게 진행하면 좋을까' 에 대한 정리해본 내용입니다.


1. 초청 30~40분 쯤 전 모임을 가집니다. 진행자가 한 분 필요합니다.
    이번 모임은 급하게 잡다보니 30분 정도 공백이 생겼었는데, 오히려 질문 준비 시간이 생겨 더 좋았던 것 같네요.

2. 참석자 중에 전문가에 대해 모르는 사람이 있을 수 있으므로, 전문가에 대한 소개를 합니다.
    모임 시작 전 어수선할 수 있으니, 진행자 분이 리드하셔서 요기까지 이끌어주시면 좋을 듯 합니다.

3. 참석자를 작은 그룹(4~6명)으로 나눠서 그룹별로 질문 사항을 취합합니다.
    제가 느끼기에 소그룹으로 분리되니, 질문에 대한 의견을 내는 데에 부담이 덜 한 것 같습니다.

4. 진행자가 질문 사항을 공유하고, 어떤 질문을 할 지 정합니다.
    이번 모임에서는 질문 공유 시간이 없었는데, 질문을 공유했다면 더 좋았겠다라는 생각이 듭니다.

5. 전문가가 오면 소개하고 인사합니다.
    자리를 잡고 앉는데, 일자형 형태보다는 동그랗게 앉으니 뭔가 더 편안함이 느껴집니다.

6. 이제 토크를 시작해봅니다~
    모임에서는 게스트 질문 한 번, 전문가 질문 한 번~ 이렇게 서로 질문하는 식으로 진행됐는데,
    단순히 한쪽에서 일방적으로 가르치거나 묻는 것보다는 이 방법이 좋은 것 같아요.
    뭐랄까, 뭔가 커뮤니케이션 하는 느낌이 든달까요.^^;

7. 시간이 훌쩍 갑니다. 좋은 이야기가 오고 갔겠죠.
    인사하고, 선물도 주고, 사진도 찍고... 좋네요.^^



이런 모임, 또 있으면 좋겠습니다.^^

저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG 스터디 방법, 전문가 초정 모임 방법
Trackback 1 Comment 4
Daylogs/UX

웹 용어 정리

발생일: 2010.03.15

문제:
이런 저런 웹 용어들에 대한 정의를 찾아 서핑하다가 좋은 포스트를 발견했습니다.

UI 개발자가 탑재해야 할 몇 가지 개념들에 대해 설명해 놓은 포스트인데,
쉽고 명확한 설명에 고개가 끄덕여지네요.


해결책:

UI 개발자가 탑재해야할 몇 가지 개념들.
 
   위 포스트에서 언급된 몇 가지 주요 내용을 정리해봤습니다.

    웹 표준
        W3C는 웹이 상호 운영성을 확보하는 것을 목표로 하고 있는데,
        이에 대한 주요한 수단으로 제시하고 권고하는 것이 웹 표준.
        원래의 목적인 상호 운영성을 목표로 삼고 유연하게 웹 표준을 적용해야지,
        웹 표준 자체를 구현의 목표로 잡아서는 안됨.

    웹 접근성
        장애인이 웹을 이용할 수 있는 상태 또는 그것을 측정하는 개념
        비 장애인의 웹 이용에 대한 것을 측정하려면, 상호 운영성, 호환성, 사용성 등으로 측정해야 함

    사용성
        효율과 효능을 측정하는 개념으로 흔히 비 장애인을 대상으로만 측정하고 있지만,
        장애인을 포함하여 다양한 유형의 사용자 패턴을 고려해야 함.
        20대 건장한 청년 10여 명을 데려다 놓고 사용성 테스트를 하는 것은 의미가 없음.
        '모든 사람의 만족'이라는 개념이 필요함.
       
    상호 운영성 & 호환성
        비슷한 개념이나 상호 운영성은 소프트웨어나 하드웨어를 넘나드는 호환성을 지녔을 때,
        호환성은 특정 소프트웨어나 하드웨어 내에서 호환이 될 때,
        그 기능을 측정하는 개념으로 사용함.
        예를 들어, ActiveX 는 상호 운영성이 있다고 표현할 수 있으며,
        HTML 은 호환성이 있다고 표현할 수 있음.

    유니버셜 디자인
        웹 접근성의 개념의 중심에 '장애인'이 있었다면,
        유니버셜 디자인의 중심에는 '모든 사람'이 있다는 것이 다름.
        웹 접근성이나 사용성이 웹을 측정 또는 개선하기 위한 개념으로 사용되었다면,
        유니버셜 디자인은 철학 또는 이념으로 이해해야 함.
        웹 표준, 웹 접근성, 사용성의 한계를 극복하고
        균형잡힌 시각과 웹 개발 궁극의 목표를 잃어버리지 않는데 도움이 될 것이라 생각됨.


덧.
원문 포스트의 댓글에서,
'웹 접근성은 장애인만을 대상으로 하는가?' 라는 주제로 토론이 있었는데,
이 부분이 재밌어 요약해 봅니다.
(편의 상 저자는 A, 게스트는 B 로 표시하였습니다.)

[B: 아니다]
접근성 부분은 동의할 수 없다.
접근성은 장애인만을 위한 개념이 아니며,
접근성이 높은 사이트는 곧 접근하기 쉬운 사이트이다.
오히려 장애인을 위한 지침으로 생각하는 것이 오해다.

[A: 그렇다]
웹 접근성은 신체 장애인의 장애를 극복하기 위한 개념으로 받아들여야 한다.
그렇지 않으면 '접근성'의 범위가 너무 크고 그에 대한 지침이 더 방대해져야 한다.

[B: 아니다]
웹 접근성은 '얼마나 웹에 접근하기 쉬운가'로 보는 것이 타당하다.
웹 접근성이 장애인에 대한 것이라는 건 W3C 만의 견해일 뿐이다.
'접근성'이라는 용어의 일관성을 유지해야 하며,
현실적으로 사용되는 단어의 의미도 모든 사용자를 대상으로 한다.

[A: 그렇다]
웹을 떠나서 접근성이라는 단어를 사용할 때에는 '장애인'이 주요 대상이 아닌 것이 맞다.
그러나 '웹' 안에서 논하는 '접근성'은 국어 사전이나 백과 사전의 정의를 인용하기에는 부적절하다.
우리게에 필요한 것은 '웹'에 필요한 개념이며,
비 장애인들의 접근과 관련된 문제를 다루기 위해 이 구분을 명확하게 할 필요가 있다.


이 외에도 해당 블로그에 유익한 정보가 많으니,
원문의 블로그를 참고해 보세요.^^
저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG 사용성, 상호 운영성, 웹 접근성, 웹 표준, 유니버셜 디자인
Trackback 0 Comment 0
Daylogs/HTML/CSS

HTML5

발생일: 2010.03.11

문제:
얼마 전에 파이어폭스를 업데이트 받았는데, video 태그를 지원한다고 하더군요.
오픈비디오 타입으로 <video> 태그를 구현하면, 플러그인 추가 없이 바로 재생이 가능한 태그라는 설명입니다.

요게 아마 소문으로만 듣던 HTML5 가 아닐까 하는 생각이 들었습니다.
HTML5 에서는 AJAX 도 스크립팅 없이 태그로 바로 구현되지 않을까,
Comet 같은 서버 푸시형 요청이나 스트리밍 통신 같은 것도 지원되지 않을까 하는 생각이 문득 들었습니다.

HTML5 의 정확한 스펙이 뭘까요.


해결책:
스티브잡스가 '어도비 너네 이제 맘에 안들어. 플래시 안 쓸 거야. 대신 HTML5 쓸 거야.' 이런 이후로,
HTML5 에 대한 관심이 더 커졌다고 합니다.

HTML5 에 대한 좋은 포스트가 많네요.^^

HTML5의 모든 것
정말 좋은 자료를 모두 모아둔 포스트입니다. 추천.


HTML5 에 대한 인터뷰 형식의 포스트입니다.
인터뷰 형식이라 더 이해하기 쉽고 쏙쏙 들어오네요.^^
포럼에서처럼 구글 페이지의 소스를 열어보니 정말 HTML5 형식으로 선언되어 있습니다.



아직 국내 포털에는 적용되어 있지 않습니다.
HTML5 최종 표준안이 기대됩니다.


앞으로 개인 작업은 HTML5 로 진행해 봐야겠습니다.
저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG html5
Trackback 1 Comment 2
Daylogs/Java

빌드와 컴파일의 차이

발생일: 2010.03.11

문제:
후배 P와 같이 시스템 운영 이관을 하다 문득 배치 파일 옵션에 빌드와 컴파일이 구분되어 있는 걸 보고,
궁금한 마음에 '빌드와 컴파일 차이가 뭐죠?' 라고 물었습니다.

뭘까요...?
같은 용어라 생각하고 다르단 생각을 못해봤는데 구분되어 있네요. 뭘까요...

해결책:

빌드와 컴파일의 차이
빌드와 컴파일의 차이에 대해 명확하고 쉽게 설명해 놓은 좋은 포스트가 있습니다.
컴파일은 빌드의 부분 집합이며,
단순한 컴파일에 비해 빌드는 실행할 수 있는 소프트웨어로 변환하는 과정이라고 합니다.

그러고 보니, 시스템 이관을 할 때에도, 개인 작업을 할 때에도,
빌드 버전을 따거나 '빌드'라는 것에 중점을 두고 수행한 적은 없었습니다.

같은 분이 작성하신 빌드의 중요성 글도 좋으니 참고해보세요.

저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG build, 빌드, 컴파일
Trackback 0 Comment 0
Daylogs/Java

Java Property 사용하기

발생일: 2010.03.09

문제:
꽤 오랫동안 시스템을 운영해왔고 프로젝트도 여러 번 있었지만,
properties 파일들은 별 생각 없이 가이드 대로 사용하고 있었습니다.
만들어진 시스템을 받을 때 쯤이면, 이미 properties 파일들은 제 위치에 놓여져 있기 때문이기도 했고요.

이번에 작은 라이브러리를 만들어 배포해 보려고 하니,
사용자 별 설정을 읽어와야 해서 properties 에 대해 고민할 기회가 생겼습니다.


해결책:
날이 갈수록 좋은 프레임웍이 만들어지고 하다보니,
기본적인 것보다는 만들어 진 라이브러리의 사용법 학습에 더 치중하게 되는 경향이 생기는 것 같네요.

위 내용은 구글링 해보니 쉽게 찾을 수 있었습니다.

Smartly load your properties (영문)
꽤 오래된 (03년도) 포스트이긴 하지만, 내용이 아주 좋습니다.
자바에서 프로퍼티 파일을 로드하는 방법을 디테일하게 알려줍니다.
기존에는 단순히 (편하다는 이유로) ResourceBundle 을 이용했는데,
ClassLoader 를 사용하는 방법과 각 메서드간의 차이점도 잘 정리해 놓았네요.
저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG java property, properties, ResourceBundle, 프로퍼티
Trackback 0 Comment 0
About me./이야기

노먼 락웰

얼마 전 구글 메인 화면에 노먼 락웰의 생일 기념 로고가 있어 캡춰해뒀다.




노먼 락웰(Norman Rockwell) 을 처음 안 건, 대학교 3학년 때였던 것 같다.

애니메이션 센터에서 주최했던 '캐릭터 애니메이션 마스터 과정'에 참여했었는데,
애니메이션 로봇(Robot) 제작에 참여했던 블루스카이의 이문성씨가 와서 강의를 했었다.
3D 애니메이션 업계에서는 되게 유명한 아저씨였다.

당시에는 애니메이팅 부분의 전문 교육이 거의 없다시피 해서 수강 경쟁률도 꽤 높았다.
그 때의 나도 의욕으로 충만돼 있었고, 정말 원하던 수업이어서 눈이 반짝반짝 하도록 열심히 들었다.
재밌었다! 지금도 그 때 작성했던 노트를 보면 내가 이렇게 열심히 했었나 싶을 정도다. ㅎㅎ

정말 좋고 유익한 교육이었다. 내가 "좋은 교육"의 매력을 알았던 계기가 된 강의였다.


여튼, 강의 자료 중에 노먼 락웰의 그림이 있었고 처음 노먼 락웰이라는 작가를 알게 됐다.




노먼 아저씨의 그림은 굉장히 재미있다.

늘 한 장의 그림으로 상세한 스토리를 얘기해준다.
그림 속 사람들이 무슨 이야기를 하고 있는 지 굉장히 궁금해지기도 하고,
심지어는 등장인물들이 대화 소리가 들리는 듯한 착각을 일으키기도 한다.
("내가 있잖아~~" 속닥속닥,.. "뭐 정말~?" "오.." "에이~~" "진짜라니까~~" 뭐 이런 종류의...? ^^ㅋ)

캐릭터의 포즈가 너무 명료하고 좋아서 그 마음이 전해지는 것 같기도 하고,
시선의 흐름이 잘 표현되어 있어 그림에 빨려들어가 집중하게 된다.

너무 매력적인 그림들이다.
우왕! 이거 진짜 써프라이즈다!! 이러면서, 당시에 없는 돈 탈탈 털어 화보집도 샀었다.ㅎㅎ
화보집 펴놓고 스케치북에 따라 그리기도 많이 했다 ^^;


지금은 열어본 지 한참 되었고,.. 애니메이션을 하고 있지도 않지만,..
나이 들면 나도 저런 그림을 그려보고 싶다는 생각은 아직도 아주 많다. ㅎㅎㅎ


멋진 그림이다!
나도 나중에 멋진 그림을 그리는 할아버지가 되어야지.
저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG Norman Rockwell, 노먼락웰
Trackback 0 Comment 2
About me./이야기

소프트웨어 품질과 테스팅

아침 사내 방송에 삼성전자 전자렌지에 관한 이야기가 나왔다.
삼성전자가 만든 제품 중 가장 많이 팔린 제품이 전자렌지란다.

30년 이상 사용한 전자렌지를 고객들이 기증하기도 한다는 내용도 있었다.
제조년월이 막 1982년 이런다. ㅎㅎ 정말 오래 쓰기도 하셨고, 제품이 오래 가기도 했다.

제작 과정에 대한 부분도 잠깐 나왔는데,
제품 출시 전 2000시간 동안 쉬지 않고 돌리고,
영상 60도, 영하 30도 등에서 제품 테스트를 한다고 한다-

전자에서 근무하는 후배 J에게 예전에 핸드폰 테스트 하는 과정에 대해 잠깐 이야길 들은 적이 있기도 했고,
무선사업부 건물을 왔다 갔다 하면서 으리으리한 테스팅룸을 보기도 했지만-
테스팅 과정에 대한 화면으로 보니 더 신기하더라.

가만 생각해보면, 소프트웨어는 하드웨어에 비해 테스팅 강도가 좀 낮다는 생각도 든다.
물론 TDD 도 있고, 여러 프로세스에 관련된 방법론이 있지만-
아무래도... 하드웨어에 비하면 덜하다는 느낌이다...
하드웨어 보다 만들기 쉽고 비용이 덜 들어서 그런 걸까...

...까지 생각을 했었는데...

그러고 보면, 은행 모듈 같이 크리티컬한 시스템이나 트래픽이 많은 대형 포털 같은 데서는-
테스트 케이스도 제대로 되어 있고, 강도 높은 스트레스 테스트도 할 것 같다는 생각이 들었다.

아무렴 그렇겠지. 그래야 한다.


뭘 하나 만들어도 옳은 걸 만들자.

저작자 표시 비영리 변경 금지
Posted by ohgyun
TAG 옳은것
Trackback 0 Comment 0