요즘 스터디하는 책에 UML 이 간혹 나오는데 엔티티의 관계를 표시하는 화살표의 모양이 확 다가오지 않아서 찾아보았습니다.
텍스트로 정리가 잘 된곳이 있어서 가져왔는데 어디서 가져온지를 모르겠군요. ㅡㅡ;



화살표 방향의 의미는 둘로 나뉩니다.
삼각형 화살표 : [상속, 구현]은 자식 --> 부모

꺽쇠 화살표 : [의존,연관]은 A가 B를 참조한다. A--> B

직접 설계할때뿐 아니라 책에 표시되어있는걸 볼떄도 적절한 의미를 파악하기 용의하도록 암기해야겠습니다.

당연한 말이지만  웹표준과 접근성이슈에 대해 알아야 하는건 원래 이런 문제에 관심이 많은 유저그룹이 아닌, 상대적으로  관심이 없는 그룹입니다.  (그런분들은 어떻해서든 알아서 해결하시니까..)


전, 그 대표적인것이 SI의 ServerSide 개발자라고 생각합니다.
포털들이나 몇몇 스스로 운용개발인력을 가지고 있은 곳을 제외하곤 국내의 규모있는 대부분의 사이트들은 SI업체에 의존하고 있는으며, 최종 웹결과물에 마지막 손을 대는것이 SI의 ServerSide 개발자임에도 불구하고 ,
그들은 웹표준과 Front-End에 대해 배경지식이 전무하다 시피 합니다.
희안하게도 웹개발자들(ServerSide)들이 Front-End와 웹표준관련 권고안들을 등안시하면서 SI산업 전반에서 이 분야는 공중에 붕~뜬 분야가 되버렸습니다.
RFP에 분명 웹표준준수에 대해 언급이 있음에도 발주하는 곳도, 수주하는 곳도 그게 무엇인지 잘 알지 못합니다.
이상으로 삼아야 할 목표와 현실적 한계, 바꾸어야 할 현실....   빈틈이 생겨버렸습니다.

그런 틈을 조금 좁힐 수 있는 자리가 있었습니다.
대우정보시스템 본사에서  내부 개발자대상 교육에 Fredns.kr자격으로 초청되어 웹표준과 관련된 세션을 맞아 진행하였습니다.
발표내용은 청중이 SI Java개발자들인것을 감안하여, Static한 내용보다는 국내 현실을 고려한 여러가지 정보와 현재 HTML5를 포함한 웹표준관련 상황, 그리고 장애인자별금지법과 관련하여 Accessibility를 증가실킬 수 있는 웹개발에 관련된 내용으로 풀었습니다.
너무 짧은 시간에(발표자 입장에선 ) 너무 많은 내용을 설명하려다 보니 두서없는 부분도 이었지만, 알아서 잘 소화하셨으리라 믿습니다.



오늘 세미나에서 담지 못한 내용을 조금 적어보면,
국내에도 WAI-ARIA(Accessbility Rich Internet Applications)에 대한 논의도 좀더 활발해졌으면 좋겠습니다. (애니 ARIA 아닙니다. ㅎㅎ)
사실, HTML5자체는 Accessibility와 직접적인 관련은 없습니다. 현시점에서 Accessibility는 표준기술을 다루는 방법으로 실현되는것이지 그것 자체가 어떤 Spec준수로 달성되는것은 아니기 때문입니다.
하지만, ARIA 는 다릅니다. 이것 자체가 Accessbility를 위해 존재합니다. 아직 국내에는 이를 지원하는 ScreenReader가 없다고는 하지만, 웹표준논의가 점점활발해지는 것 처럼 ARIA도 그렇게 되었으면 좋겠습니다.


준비하면서 개인적으로 많이 배울 수 있는 기회가 되었습니다.
역시 남을 가르치는게 가장 공부가 됩니다. 근데, 시연용으로 가저간 노트북이 Ubuntu라서 IE9 preview나, 몇몇 Tools을 말로만 소개한것이 좀 아쉽군요. :)

초대해주신 장의진 차장님께 감사드리고, 중간에 에어콘이 꺼졌음에도 1시간 반이라는 짧지 않은 시간 집중해주신 개발자분들에게 감사합니다.
그리고 필요한 분이 있을까 모르겠지만, 발표자료도 일단 공유합니다. ㅎ

요즘은 꼭 블로그가 아니어도 정보를 제공하는 사이트라면 왼쪽처럼  생긴 RSS Feed 링크쯤은 하나씩 달려있다. RSS 버튼은 전파를 발산하는 것 같한 형태를 주로 쓰는데, 재미있는건 Feed Icon이라 불리우는 이 아이콘의 배포하는 사이트 도 있다는 사실. [footnote]물론 OPML 아이콘 배포사이트도 있다. OPML Icon Project 라는 거창한 이름으로.[/footnote]

RSS가 웹2.0의 거대한 흐름 한 가운데 있는건 사실이지만, RSS Reader를 쓰지 않는 사람에게는 아무 의미없는 버튼이란 것도 사실이다.

뭐 어쨌든, 개발자 입장에서 보자면, RSS Feed 자체야 XML 스키마 규약만 맞추면 만드는게 어렵지는 않다. [footnote]기술상으론 UTF-8로 XML스키마만 준수하면 되므로 쉽다고 표현했다. 의미적으로야 많은것을 고려해야 하지만... 보다 자세한건 스팩문서를 보자. [/footnote]
그런데, 다음 이미지처럼 IE7(Internet Explorer 7), FF2(FireFox 2.x)같은 피드 인식 브라우저[footnote]IE7과 FF2 모두 피드 인식기능이 추가되었지만, IE의 리더기만을 강요하는 IE7보다, 원하는 리더기 사이트에 연결할 수 있는 FF2방식이 훨씬 맘에든다.[/footnote]가 알아먹게 할려면 어떻게 해야할까?
올블을 샘플로 알아보자.
IE7으로 올블을 들어가면 하단에 피드 구독버튼을 모아놓은 곳이 있고, IE7의 리드 버튼을 클릭하면 이 피드 들이 뜬다.

파폭으로 올블을 들어가봐도 마찬가지다.



이 브라우저 들은 피드 URL을 어떻게 찾는 것일까?
HTML에서 이미지들을 찾아서 그중에 RSS아이콘처럼 생긴걸 찾나? ㅡ ㅡa
HTML 테이중에 <Link>라는 테그가 있다.
태그 <Link>는 현재 document에 확장 docuemnt를 연결하기 위한 테그이다.
가장 흔한, 그리고 거의 유일한 용도는 바로 css파일을 연결하는 것이다.
다음은 이 블로그의 css링크이다.

<link rel="stylesheet" media="screen" type="text/css" href="/skin/customize/1/style.css" >

<Link>의 Attribute 중 REL 이 있는데, 이 REL이 Link의 목적을 정의한다. 
rel 의 MSDN의 설명을 보면, 이 ref="alternate" 일때, 이건 현재문서을 대체할 버전의 Link를 의미한다.
올블을 다시보자.
올블의 HTML Source를 보면 상단에 다음과 같은 태그가 있다.

<link rel="alternate" type="application/rss+xml" title="실시간 전체 글목록 Feed" href="http://rss.allblog.net/AllPosts.xml">
 <link rel="alternate" type="application/rss+xml" title="어제의 추천글 Feed" href="http://rss.allblog.net/BestPosts.xml">
 <link rel="alternate" type="application/rss+xml" title="나의 추천글 Feed" href="http://rss.allblog.net/MyBestPosts.xml">
 <link rel="alternate" type="application/rss+xml" title="모든 이슈 글목록 Feed" href="http://rss.allblog.net/Issue/all.xml">

브라우저는 바로 이 태그를 찾는다.
그래서 이 태그가 있으면 피드버튼을 활성화시키고, 이 태그가 없으면 아무리 접속한 곳이 블로그, 아니 블로그 할아버지 사이트라고 해도 피드버튼은 활성화 되지 않는다.

일반사이트를 들어같을때 비활성화된 피드버튼

이미지, 샘플 소스따가며 주절거렸지만 결론은 'link태그 한줄?' 이다.
하지만... 개발자 입장에서,  
요즘은 프로젝트성격을 불문하고 무조건 '블로그' 혹은 'RSS'관련 개발이 꼬리표처럼 따라다닌다.
RSS관련 구현을 그저 XML양식만 맞추면 된다고 생각했다면, 이미 일반 유저의 주력 브라우저가 절반이상 IE7과 FF2.x로 넘어온 상황에 브라우저 기본 기능도 지원 못하는 반쪽짜리 페이지를 개발하고 있지는 않는지 돌아봐야 할듯 하다.

클라이언트가 '왜 우리사이트는 피드버튼이 활성화 안되요?' 할때, '글쎄요? MS에 물어보시죠.' 하지 말고...

저번주 월요일. MS의 WPF/E가 SilverLight라는 네이밍을 얻고 정식 사이트오픈과 홍보(?)를 시작했다.

비록 일부이기는 하지만 SliverLight 관련 무료 세미나를 MS에서 진행을 해서 신청했다.

작년 말 진행했던 MS DevDay는 조금 실망스러웠다. 내용자체가 새로운게 없는데다가 진행도 그다지 매끄럽다는 느낌을 받지 못했다. (클릭) 그후 6개월 여 만에 가보는 MS 행사이다 보니 비스타도 이미 출시되었고 WPF/E가 첫 선을 보이는것도 아니지만 .NET 3.0이나 비스타가 주제가 아닌 웹자체를 주제로 한, 그것도 UX만이 주제인 세미나다 보니 약간 기대중이다.  들을만한지는 가봐야 알듯.

선착순이라고 하니 관심있는 분은 사전등록부터 해보시길. 링크

코더라는 직업군에 대하여.

일잘하는 코더와 일해본 개발자는 코딩이 잘되어있는게 얼마나 개발 생산성과 품질을 높이는지, 코딩이라는 분야가 하나의 전문성있는 개발 파트임을 알리라 믿는다.

그러나 군소 웹에이전시들은 코더라는 직종을 따로 두지 않는다.

왜? 당연하다. 디자이너가 없으면 디자인이 안되고 개발자가 없으면 개발이 안되지만, 코더가 없으면? 디자이너가 하면 되니까.

웹디자인의 길로 들어선 90%이상이 기본적으로 코딩을 할 줄 알고(웹표준이든 아니든, 툴을 쓰든 안 쓰든 말이다.), 개발자 입장에선 어쨌든 코딩이 완료된 HTML이 필요하고, 그렇다고 PSD를 직접 손대는 건 영역을 벋어난 느낌이 너무도 명확하니 그저 그렇게(디자인의 한영역으로) 자리잡혔다고 보면 틀리지 않을것 같다.

하지만, 그것도 몇 년 전 이야기다. 디자이너가 디자인만을, 개발자가 개발만을 집중할 수 있도록 웹에이전시의 시스템을 다듬으면 다듬을 수록 중간에 코더라는 자리의 필요성은 상대적으로 부각된다. 그래서 조금 규모가되는 웹에이전시는 코더를 두고 있고, 없다고 해도 계약직으로라도 프로젝트에 종종 투입한다.

그럼에도… 잡코리아를 한번 가보라. 코더라는 분류가 있는지.

코더라는 직업군은 아직 대한민국에 존재하지 않는다.  코더는 실존하지만, 인정받지 못하는 직업니다. 디자이너를 소망하고, 개발자를 소망하는 사람들은 있지만, 코더를 소망하는 사람은 없다.

코더는 그저 다른곳으로 가기위해 거처가는 자리거나, 어쩌다 보니 흘러온 자리이다. (코더분들은 무시하는 발언이 아니라 현실적으로 대우받지 못한다는 뜻이다.)

코딩의 품질이 주요시된다면 당연히 코더라는 전문자리가 필요하다고 생각한다.

아니라고 생각할지도 모른다. 디자이너든, 프로그래머던 잘 아는 사람이 하면 되지 않느냐는 주장이다. 하지만 대한민국의 웹개발영역 인력수준이 인터넷 발전에 비해 한참이나 취약한 것은 이런 전문성의 부제가 원인이다.

디자이너가 제로보드 설치해서 사이트 오픈하고, 개발자가 적당히 이미지 따서 페이지 만들고, 페이지 디자이너가 플래시를, 개발자가 DB설계를, DBA가 개발을, .NET개발자가 자바를, 자바개발자가 PHP를.. 결국 이런 식의 디자이너, 개발자 둘만 있으면 웹관련 모든 이슈를 다를 수 있다는 식의 사고가 개별 파트의 전문성을 떨어뜨리고, 그건 사이트 품질저하로 이어져왔다.

나는 코딩이 어디에 귀속되어서는 안되는 독립된 전문분야로서 담당자가 있어야 하고, 그렇게 될 때 웹표준 준수라는 것도 가능하다고 생각한다.
현재 현업에서 일잘하는 코더 구하기는 하늘에 별따기다. 더군다다 웹표준에 대응할 수 있는 코더는 별정도 아니라 안드로메다다. 웹표준을 넓혀야 한다를 이야기할려면 코더가 더 필요하다.

잡설1.

야후코리아는 코더가 8명쯤 된다고 한다. IE6과 FF는 크로스브라우징이 되고 있고, 새로 나온 IE7과 기타 브라우저로 크로스브라우징을 넓히고 있다. 야후코리아는 본사의 시스템을 따르고 있다고 하니, 특별히 웹표준, 크로스브라우징을 노력하고 있다기 보다는 야후의 글로벌 기준에 따르고 있는듯 하다.

잡설2.

현실적으로 코더를 둘 수 없는 곳도 분명 있다. 업무량이 고정인력 한 명분도 안되는 수많은 자체 서비스 업체들의 경우는 원하던 원치 않던 내부인력이 해야 한다.

죽어도 코더가! 라기보다는 코딩의 중요성에 대한 글로 이해하자.

하지만, 웹표준에 관심이 없는(혹은 모르는) 코딩까지 책임지던 디자이너에게 웹표준을 가르치는 것은 너무너무 어렵다. 차라리 개발자가 포토샵을 배우지. ㅡ ㅡa

잡설 3.

사실 이 글은 다른 주제의 글을 쓰다가 너무 길어져서 따로 빼냈다. 게다가 그나마도 너무 길어서 반으로 줄였다. 글쓰긴 너무 어렵다. ㅡ ㅡa

트랙백글을 읽고 생각이 번져서 적어본다.

맥이 UI가 윈도우보다 편하다는 데는 기본적으로 동의한다.
하지만 그렇다고 윈도가 쓰레기냐? 모든 사람이 정말 억지로 쓰고 있냐? 에 대해서는 아니라고 생각한다.
그게 컴맹인 가족때문이든, 게임때문이든, 인터넷뱅킹떄문이든, 네이버때문이든, 개발때문이든, 업무때문이든,  쓰고있다는것은 윈도가 필요하기때문이다.
게다가 차타고 다니면서 '망할 현대자동차...'라고 투덜되는것과는 달리 우리, 대부분은 윈도를 구매하지 않았다.
사지 않은 놈은 불평도 못하냐? 라거나 난 샀다! 해도 되지? 라고 반문한다면 할말은 없다.
하지만 애플은 아이팟에서 바이러스가 나와도 불평을 안하고, MS는 보안을 강화해도 욕을 먹는 분위기는 지나치게 맹목적인 추종과 비난이 아닌가 생각한다. 그리고 대부분의 유저는 맥을 스크린샷이나 화려한 UI의 동영상, 맥센터에서 몇분 만저본것이 다다. 윈도우도 그정도만 접하면 괜찮아 보일 수도 있다. (물론 확인은 없다. ㅡ ㅡa)
애플의 제품철학과 OSX의 UI가 훌률하다는데는 동의하지만, 잡스의 MS, Vista에 대한 농담조의 조롱도 결국은 자사제품의 상대우위확보를 위한 마케팅의 일부인것도 사실이지 않은가.  
잡스의 농담이 작은 기쁨을 주기는 하지만, 결국은 경쟁하는 기업들일 뿐이다. (관련기사)
애플의 대단한점은 자사 제품을 문화화 했다는것이고, MS은 그러지 못했다. (안했다는게 맞겠다.)
하지만 그것이 절대적인 품질의 증거인지는... 난 잘 모르겠다.
맥을 써도 이슈내용만 다르지 사용에 따른  비슷한 정도의 불평은 나올것이고, 맥을 만족하고 쓰는 사람보다, 더 맣은 사람이 윈도우에 만족하고 쓰고 있고, 그것은 단지 맥을 써보지 않았기때문만은 아니다.

요즘... 개발자에게 블로깅이 얼마나 중요한지를 새삼 느끼고 있다.
단지 내가 알고자 하는 내용을 키워드로 검색하는것 보다 훨씬 풍부한 내용이 블로그들을 통해 생산되고 있다.

네이버보다, 구글보다, 블로깅을 통한 정보수집이 더 중요한 세상이 오고있는것 같다.
(정말은, 이미 왔는데, 내가 몰랐던거지만. 쿨럭. ㅡ ㅡ)

그리고, 왜 이렇게 뛰어난 개발자가 많은것이냐~~~ ㅜ ㅜ

디카로 찍은 JPG는 기본적으로 Exif라는 촬영정보에 대한 MetaData를 가지고 있다.
이정보는 유틸리티를 통해 볼수 있는데... 당연히 프로그램으로도 컨르롤 가능하다.


.NET에서는 이미지를 System.Drawing.Image 로 컨트롤 하고..
.NET도움말을 보면 Image클래스로 이미지를 로드하면, Image.PropertyItems 로 Eixf정보를 조회할 수 있다고 되어있다.
PropertyItems 는 PropertyIitem의 배열이고 PropertyIitem이 우리가 원하는 Exif의 개별 정보이다.



하지만, PropertyIitem는 Id, Value, Len, Type이라는 4가지 속성을 가지고 있고,
값의 형태를 나타내는 Type에 의해서 호출하는 방식이 완전히 다르다 .
(나중에 다루지만, Type이 같아도 어떤 Exif정보를 가져오냐에 따라서도 완전히 다르다.)

Id 는 메타데이터 구분 식별자,
Value는 바이트 배열형태의 실데이터,
Len은 Value 의 길이,
Type은 MSDN에 다음과 같이 정의되어있다.

Type=1 : Value가 바이트 배열임을 지정합니다.
Type=2 :Value가 null로 끝나는 ASCII 문자열임을 지정합니다. 형식 데이터 멤버를 ASCII 형식으로 설정하는 경우 null 종결자를 포함하는 문자열의 길이로 Len 속성을 설정해야 합니다. 예를 들어, 문자열 "Hello"의 길이는 6입니다.
Type=3 :Value가 부호 없는 16비트 정수(Short)의 배열임을 지정합니다.
Type=4 :Value가 부호 없는 32비트 정수(Long)의 배열임을 지정합니다.
Type=5 :Value 데이터 멤버가 부호 없는 정수(Long) 쌍의 배열임을 지정합니다. 각 쌍은 분수를 나타냅니다. 첫째 정수는 분자이고 둘째 정수는 분모입니다.
Type=6 :Value가 데이터 형식의 값을 보유할 수 있는 바이트 배열임을 지정합니다.
Type=7 :Value가 부호 있는 32비트 정수(Long)의 배열임을 지정합니다.
Type=10 :Value가 부호 있는 정수(Long) 쌍의 배열임을 지정합니다. 각 쌍은 분수를 나타냅니다. 첫째 정수는 분자이고 둘째 정수는 분모입니다.

쉽게 정의하면, Type=1은 쓰이지 않고 Type=2가 문자이면 나머지는 모두 숫자형 데이터다.
이 Type과 PropertyIitem을 구분하는 Id에 따라서 값을 어떻게 불러와야 하는지가 결정된다.
Type이 2인 문자는 다음과 같이 불러올 수 있다.

알라딘이 블로거들을 자기들 사이트와 연동하는 방법을 들고 나왔다.

테터는 최진호님의 BlogAPI 플러그인을  통해 원격 포스팅을 지원하므로 편리하게 쓸 수 있다.
책리뷰 쓰기도 편하고, 일종의 수익(?)도 기대할 수 있단다.
작은 불만이라면, 알라딘에 원격글쓰기가 자~~악은 팝업이라는거... 좀더 컸으면 좋겠다...

탭브라우징, 검색바, 그리스몽키 가 포털들을 위협할거라는 이야기는
이번의 검색엔진 통합 마케팅 컨퍼런스 에서도 언급된 이야기다.
문제는 이런 'IE 7.0 이나 FireFox 2.0등의 차기 브라우저가 포털을 위협할거다' 라는 주장이
네티즌에 의해서가 아니라 소위 전문가라는 사람들에 이해 배포되고 있다는 점이다.

시맨틱웹, Web2.0 이라는 이슈가 계속 확대해석되고 있는 상황에서
일종의 '미래예측'에 욕식을 낸 사람들이 오버한거라 생각한다.
그리고 포털들이 바보가 아닌이상 문제가 될만한 이슈는 또다른 행결방법을 모색하지 않을까?

'위협' 이란 표현보다는 '변화' 를 부를것이라는 표현이 적절해 보인다.
FireFox가 점유율을 높이고 있다..는 이야기가 들릴때도 포털들은 요지부동이였다.
하지만, Web2.0이 구체화되고, 그것이 대세임이 확인되자, 포털들은 제각각 행보를 시작했다.
다음은 포털중 처음으로 HTML 웹표준을 준수를 선언했고, (비록 메인뿐이고, 컨텐츠에 따라서 오락가락하지만..)
야후는 메일서비스를 시작으로 전체서비스를 Ajax기반으로 바꾸기 시작했다.
IE 7.0이 나와서 무언가 포털들의 현재 포션에 영향을 주는 일들이 발생하면, 그때도 포털들은 또 적절히 대응할것이다.

뭐가 뭘 망하게 할것이다... 뭐가 세상을 바꿀꺼다.. 라고 이야기하는것중에 맞는거 거의 본적 없다.