한 때 웹개발을 수 년간 했었다
초기 ASP를 기반으로 해서 다양한 웹 사이트를 개발했었다
당시 자바스크립트 공부도 꽤 했으며 다양하게 응용도 했었다

그러나 윈도우 응용프로그램을 수 년간 개발하면서 웹 개발을 조금 멀리 했었다

그리고 이후 웹 개발 프로젝트를 수 년간 관리했었다
이 때는 실무 개발보다는 프로젝트 관리자 입장에서 웹을 바라보았으며 코드보다는 성능, 가용성,
연동, 안정성 등을 위주의 관리적 경험이 대부분이었다

그리고 지금...
모바일 웹 부문을 맡게 되면서 다시 웹을 실무수준으로 개발하게 되었다
현재의 웹은 과거 경험했던 웹 보다 더욱 체계화 되었으며 표준에 대한 요구가 많이 늘었음을 느낀다

지금은 웹 개발을 한다는 의미보다 웹을 한다는 의미로 받아 들이고 있다
웹은 소프트웨어 환경에서 빼 놓을 수 없는 플랫폼이다.
웹 개발을 다시 한다는 편협한 시각보다는 웹을 이해한다라는 거시적 관점에서 다시 시작해 보려 한다

그 출발으로, 자바스크립트 라이브러리로 유명한 JQuery 책을 신청했다

과거 언젠가..
더 이상 자바스크립트 공부를 섬세히 할 일이 없을 것이다... 라는 나의 예측이 어긋난 것이다.

내가 본, HTML5를 주제로 한 첫번째 책이다
그간 온라인을 통해서만 HTML5 기술을 습득해 왔는데, 책이 나왔다길래 바로 구입했다
모바일 플랫폼 중 1차로 모바일 웹 부분을 담당하게 될 것 같고 관심도 있고 해서 보게 되었다

어제 외부 세미나를 참석했다

'웹표준 워크샵 2010' 세미나로 오전 10시부터 오후 6시까지 총 7 세션으로 이루어졌다

세션 1 > 웹표준 마크업 개발 프로세스
NHN 의 웹표준팀인가에서 발표를 했는데 자사의 OOMDP(Objective Oriented Markup Develop Process) 라는 개발프로세스를 소개하는 자리였다
웹 표준 코딩으로 개발된 HTML 템플릿을 사이트 주제별로 마련해 두고 재사용을 통한 생산성과
표준 안정성을 보장하는 것과 코딩컨벤션이라는 표준 코딩 검증 프로세스에 대한 내용이었다

조금 아쉬웠던건 성공사례이기보다는 시도사례라는 점이다
그것도 특정 한 회사에서의 시도이며 아직 그 회사에서조차도 완성되지 않은  ~ing 모델이라는 점.

물론 그 회사의 선도적이고 체계적 프로세스 도입 시도는 좋아 보이나 하루라는 시간과 121,000 이라는 돈을 투자하여 세미나에 참석하는 가치(?)에는 크게 부합하지 못하지 않았나는 생각이 든다
지극히 개인적인 기준에서이다. 내가 원했던 정보와 다른 정보이니 난감할 수 밖에 없었던 것 같다
다만 대형 포털사의 웹 표준 마크업 생산에 대한 시도를 엿 볼 수 있다는 점에서는 좋았다

세션 2 > 모바일 환경에서의 마크업 개발이슈
모바일 마크업 실무에 약간의 팁을 얻을 수 있는 세션이었다
발표자가 전문 세미나 진행자가 아니라 순수 실무자이다 보니 발표력에는 큰 점수를 줄 수 없었으나
모바일 웹 마크업 실무에 있어 발생하는 이슈와 해결에 대한 참조를 얻을 수 있어 나름 의미가 있었다

세션 3 > 차세대 웹표준 - HTML5 소개와 활용사례
HTML 5에 대한 전반적인 소개 자리였다
강사의 HTML5 데모사이트인 http://durl.me/23zys 를 앞으로 유심히 참조해야 겠다

세션 4 >웹 표준 기반의 3D 그래픽 처리
개인적으로 가장 흥미롭게 봤던 세션이다
3D 자체가 익숙하지 않아서 개념적으로 신선했으며 각종 정보를 많이 얻을 수 있는 자리였다

세션 5 > 모바일 네이트, UI개발과 이슈
데스크탑 웹과 모바일 웹은 같은 웹이지만 디바이스의 특징이나 네트워크 환경등 많은 차이가 난다
이는 구현단에서도 직접적으로 연관되는 것으로 기획단계에서 이러한 차이점이 적절히 반영되어야 한다
이 세션에서는 모바일 웹을 위한 사전 고려사항을 적절히 제공했으며 구현단계에서 겪은 에피소드를
소개해 주었다. 세션2와 조금 중복되는 느낌이었으나 좋은 정보를 얻었다고 생각한다

세션 6 >SK컴즈에서 JavaScript 개발자 되기
음.. 개인적으로 가장 난감한 세션이었다고 평하고 싶다
SK 커뮤니케이션이라는 회사에서 자바스크립트 직무를 도입한지 18개월 되었다고 한다
사실 웹 개발회사에서 자바스크립트만을 전문적으로 담당하는 개발자를 두는 곳은 잘 없다
통상 웹 개발자 혹은 퍼블리셔라 불리는 코더가 개발하거나 일부는 디자이너가 처리하기도 한다

자바스크립트 자체가 페이지에 오픈되는 구조라서 쉽게 참조할 수 있으며 적당히 흉내낼 수 있으며 라이언트 단을 제어하는 역할이라는 점에서 중요성을 인정 못 받기도 한 탓이다.

그러나 요즘 웹 개발 추세는 웹 표준이니 웹 2.0이니 하는 트랜드로 스크립트의 중요성이 조금은 부각되고 있으며 웹이 페이지 수준을 넘어 어플리케이션 수준으로 요구되다 보니 고퀄리티를 점점 더 요구하고 있다. JQuery 및 Prototype 과 같은 자바스크립트 라이브러리의 인기도 이러한 시류의 증거인 것 같다

어쨋던 이 세션 발표자는 자바스크립트를 전문적으로 개발하는 사람으로 회사에서도 독립 직군으로 인정받아 일 하는 분인데, 자신이 느끼는 직무의 특징과 외부에서 바라보는 조금은 다른 시각들, 자바스크립트 개발자가 원하는 시선 등을 발표하였다. 그리고 일하면서 겪은 협업상 에피소드, 개선점 등을 예기해 주었다.

개인적으로는 자바스크립트의 표준 코딩 참조와 각종 라이브러리 정보를 얻고 싶었는데,
직무 특징이나 바라는 점, 어찌보면 개인적으로 업무를 하면서 바라는 의견등을 피력(?)하는 자리가
아닌가 싶었다. 물론 발표자의 능력을 의심하진 않는다. 그리고 그 직무 특징을 무시하지도 않는다
그리고 경험적으로 그 분의 말에 일리가 있다는 것을 느끼며 공감하는 내용도 많았다

다만 내가  얻고 싶었던 정보는 그게 아니라는 것이다
코드가 중요하나요? 할 수도 있겠지만, 난 하루라는 시간과 돈을 투자해서 간 것은 코드를 보기위해,
개발 참조를 빨리 하기 위해 간 것이다. 뭐가 더 중요하다는 것이 아니라 내 목적과 부합되지 않는
세션이라 조금은 실망스러웠다. 가장 긴 시간을 진행한 세션이기도 했다

세션 7 > Web App와 HTML5
세션 3과 조금 중복되는 느낌이었다
다만 세션 3은 조금은 추상적, 상위단 예기였던 반면 이 세션은 HTML5 의 세부 기능을 살펴보는 자리였다. HTML5를 처음 접한 사람에게는 매우 유익한 정보이겠지만 이미 한권의 책과 각종 블로그를 통해
어느정도 접해본 나에게는 복습하는 기분이 들게 하는 자리였다


결론>
누구든지 세미나를 참석할 때 분명한 목적을 두고 간다. 특히 유료세미나는 그 목적의식이 더 강하다
나 역시 그렇다. 오히려 나 같은 경우 목적이 보다 구체적인 경우가 있다
이번 세미나가 그런 경우다. 컨셉성 세미나 보다는 구체적 구현 관점에서의 목적을 크게 두고 갔다
돈과 시간을 투자한 만큼, 목적과 부합하는 이득을 얻고 싶은 것이다

물론 나의 목적이 다른 사람의 목적과 다를 수 있으며 각 참석자 마다 수준이나 보는 시각이 다 다를 수 있다. 그러나 내가 가진 목적이란게 별다른 특수한 것이 아니라 세미나 주제와 제시한 커리큘럼의 범주에 근거한 목적을 둔다는 점이다. 이런 점에서 전체적으로는 조금 아쉬운 세미나였던 것 같다

기대치에는 조금 못 미쳤지만 얻은 정보가 없는 것은 아니다
세미나 진행자나 세션 발표자의 능력은 의심하지도 않는다
훌륭하고 선도적인 분들의 경험담과 사례 습득은 두 말할 것 없이 가치있는 일이다
그러나 어제의 세미나는 얻은 것과 기대한 것의 차이는 분명 있었다는 것이다

그리고 한가지.
세션 발표자의 자료와 배포된 자료와의 불일치가 굉장히 거슬렸다
세미나 한달전에 발표자료를 주최측에 제공한 나머지 중간에 바뀐 것을 반영하지 못했다는 점은
알겠으나 이해하고 싶지는 않다

그건 이해를 바랄 것이 아니라 개선을 해야 한다
한달전이라는 프로세스에 문제가 있으며 세미나 당일 전에 최종 변경이 반영되는 운영의 미가 아쉬웠다. 발표자료와 일치하지 않은 장면이 나올 때 마다 책장을 이리저리 넘기게되어 집중력의 순간 확 떨어진다. 그리고 흑백으로 출력된 자료에 진한색의 바탕이 있는 페이지도 문제가 있다
필기를 하고 싶어도 할 자리가 없는 것이다.
이것 역시 세미나 진행에 있어 전문성을 보이지 못한 사례라 하겠다

기사 원문: 앱개발, '4천만원들여 연83만원번다

작년 말 출시된 애플의 아이폰을 시작으로 국내에서도 스마트폰 열풍이 일어났다

그와 더불어 스마트폰에서 구동되는 어플리케이션 거래를 위한 오픈마켓인 앱스토어도 굉장한 인기다
아이폰은 버전을 업그레이드 해서 신제품을 출시했고 구글의 안드로이드 MS의 윈도우폰7 ,
국내에서도 삼성 등이 스마트폰 시장에 활발히 경쟁중이다

주위에선 이미 개발자 몇 명이 모여 모바일 앱 개발사를 창립한 것을 심심찮게 볼 수 있고
각 기업에서도 스마트폰 환경에 적응하기 위한 다양한 앱 개발이 활발이 추진중이다

어차피 앱 개발이란게 대박을 노리기 힘든 구조인 것은 아는 사람은 다 안다
그런데 기사를 보니 조금 더 심각함(?)을 느낄 수 있겠군

다만 통째로 묶어서 다.. 잘되기 힘든 구조이다.. 라는 결론은 내리기 힘들다
앱도 어디서 어떤 목적으로 어떤 대상으로 개발하느냐에따라 성/패의 기준이 달라질 것이다

단순히 앱 올려서 자체 수익을 내겠다는 목적도 있겠으나, 기업의 확장 플랫폼으로써의 앱,
잠재고객 확보 측면에서의 앱, 추가 편의성 제공 측면에서의 앱 등은 그 앱의 자체 수익이라는
지표는 어찌보면 무의미 할 수 있는 것이다

앱이 돈을 위한 것일 수도 다른 것의 지원사격, 확장개념 일 수도 있는 것이다

어쨋던 앱스토어 자체만의 환상은 조심해야 할 부분인 것 같다

HTML5 기반 웹 사이트 개발 시 서버측 기술을 고민하다 ASP.NET MVC 패턴을 떠올리게 되었다
http://mobilepp.tistory.com/3

 

앞서 테스트를 통해 ASP.NET 서버컨트롤, 이벤트, 바인딩 등으로 자동 생성되는 HTML 태그가 표준 웹구현상 그리 큰 문제가 되지 않겠다는 1차 결론을 내렸다

관련 글: http://mobilepp.tistory.com/entry/ASPNET-페이지가-자동-생성하는-HTML-코드-보기

그렇다면 ASP.NET 결과페이지가 HTML5 문서로써 적합한가를 검증해 보도록 하자

http://html5.validator.nu 라는 사이트는 HTML5 문서를 검증해 주는 서비스를 제공한다
웹 페이지 URL 이나 소스 업로드 혹은 직접 코딩 등을 통해 HTML5 문서 검증을 수행해 준다

앞서 테스트에서 사용된(GirdView 바인딩 예제)의 결과 HTML 을 검증해 보았다
(아래 HTML 코드가 검증 대상 코드이다)

일단 검증전에, 눈에 딱 거슬리는 몇 가지.. 있긴 하다
HTML5의 공식 도뮤먼트타입인 <!DOCTYPE html> 에 위배되는 모습이다. 일단 검증을 돌려보자

아래 그림은 결과화면의 일부를 캡쳐 받은 것이다
역시 HTML5 처음에 DockType이 제일 처음 위치해야 한다는 내용과 틀린 DockType이라는 에러가 보고된다. 그리고 이로 인해 head 와 title 등과 같은 정상 태그들도 그 위치가 애매하다고 한다

예상했던대로 이전에 많던 오류보고가 대부분 사라졌다
다만 GirdView 가 변환된 table 태그에 cellspacing, rules, border 속성들이 obsolete,
즉 구식속성이라 보고된다. 보고서에서는 이 속성들 대신에 CSS를 사용하라고 권장(?)도 해 준다

* 제약이 많은 HTML 기반의 컨트롤
서버 컨트롤은 자신을 HTML로 렌더링 하기는 하지만 대체로 웹 표준을 만족 하지 못하거나 CSS를 적용 하기 어려운 구조이다. 또한 서버 컨트롤이 생성한 클라이언트 ID 값은 예측 하기 어렵고 복잡하여 JavaScript로 접근 하기 매우 어렵다
[출처] ASP.NET MVC 도입 해야 할까?|작성자 쭌스

다만 아직 결론을 내리기는 힘들고, ASP.NET 의 MVC 패턴 프레임워크를 추가로 살펴보기로 하자

HTML5은 차세대 웹 표준으로 자리를 잡겠지만 현재까지는 표준안이 완성된 것은 아니다
따라서 각 브라우저에서 HTML5의 각종 태그와 API에 대한 지원이 서로 상이하다

http://www.html5test.com/ 에서는 현재 브라우저가 HTML5를 얼마나 지원하는지 검사해 준다
HTML5의 각 세부 요소별로 점수를 계산하여 300점 만점 기준으로 종합 점수를 보여준다

아래는 내 PC에 설치된 IE, 크롬, 사파리, 파이어폭스를 검사 해 본 결과이다

IE 8.0                   :  27 점
크롬 5.0                : 197점   
파이어폭스 3.6.6   : 139점
오페라 10.60         : 159점
사파리 5.0             : 207점

사파리가 가장 좋은 점수를 받았다
역시 플래시를 거부하고 HTML5 를 적극지원하겠다던 애플다운 행보인 것 같다
구글의 크롬 역시 높은 점수를 기록했으며 파이어폭스나 오페라는 그저그런 수준인 듯...
(뭐얌.. 지원할 꺼면 언능언능 지원하던지 않구선.. )

마이크로소프트의 경우 다음버전인 IE9에서는 HTML58를 전폭 지원한다고 했으니 다음에 검사한번
해 봐야 겠다

현재 프로젝트는 모바일 환경을 기반으로 한다
그리고 나에게 일차적으로 주어진 미션은 모바일 웹 개발 부문이다

개인적으로는 모바일 앱(App) 개발도 흥미를 가지고 있다
그 중에서도 구글의 안드로이드 개발을 조금씩 공부하고 있는데 프로젝트를 당장 구현하는 것이
아니라 진도가 좀 늦긴 하다. 그러나 매일 조금씩 공부하고 개인적인 앱도 한번 제작해 볼 요량이다

그런데 이.. 안드로이드.. 자바기반 개발 환경이다
이클립스로 개발하는데 비주얼스튜디오에 익숙한 나에게는 낯설기도 하고 툴의 기능이 조금 불편하기도 하다. 그리고 한글화가 안 되어 있다는 점과 MSDN 에 버금가는 완벽에 가까운 헬퍼(Helper) 문서가 없는 점도 아쉬운 부분이다

지금 책 한권 보며 진도를 빼고 있는데, 책 다보고 나서 간단한 앱 한번 구현해 볼 예정이다. 책을 아무리 보고 이해했더라도 직접 구현해 보면 많은 문제에 봉착하고 이러한 상황을 해결해 나가면서 기술이 점점 내 것이 되어가는 것이다

프로젝트에서 요구하는 것이 아니라서 진도는 좀 늦어질 것 같다

다음주 수요일(7월7일) 유료 세미나 신청했다

웹 표준과 HTML5, 모바일 환경에서의 웹 응용 등을 다루는 세미나이다
하루짜리로 사전 등록비 121,000 원

현재 진행하는 프로젝트에 도움이 될 것 같다

http://www.bizdeli.com/webstandard/

트위터를 보면 글에 인터넷 주소 링크를 심심찮게 볼 수 있다
그리고 대부분의 링크 주소는 꽤 심플하다

그런데 링크를 클릭해서 넘어가보면 다른 주소, 원래의 긴~ 주소 페이지로 이동한다
그럼 긴 URL 을 짧은 URL로 매핑 시켜주는 무엇인가가 있다는 예기인데...
트위터가 제공하는 걸까? 아니면 실제 컨텐츠 제공자가 지원하는 걸까?

팀장님으로 부터 조사 임무를 부여받고, 살펴 보게 되었다
아래는 조사 후 팀에 공유한 메일 내용이다

그나저나 이 조사 덕에 기존에 관심을 두지 않았던 트위터에 가입하게 되고 재미까지 느끼고 있다
조사하는 시간은 약 1시간 정도였는데, 트윗질은 하루 종일 했다는 ... ㅎ
------------------------------------------------------------------------------------------
아시다시피 트위터는 글 수 제한(140자)이 있습니다

외부링크주소(URL) 역시 글 수에 포함되기 때문에 URL 단축 기법이 이용됩니다

URL을 줄일 수 있는 방법이 필요한데, 현재 트위터에서 사용되고 있는 대부분의
단축 URL 기법은 트위터와는 무관한 제 3자에 의해 제공됩니다

제 3자에 의한 URL 단축 서비스 제공

기본적으로 URL을 단축해 주는 시스템은 제 3자에 의해 제공됩니다

URL을 단축해 주는 사이트가 굉장히 많으며 트위터는 물론 기사원문을 제공하는 곳과도
완전히 별개의 사이트 입니다. 아래는 단축 URL 에 대한 서비스 흐름도 입니다

단축 URL 을 제공하는 사이트 목록입니다(꽤 많네요..)

http://bit.ly http://tln.kr http://durl.kr http://tinyurl.com http://yep.it http://foldurl.com http://is.gd http://j.mp http://tr.im http://url.fm

http://qurl.net http://url123.com http://ataja.es http://lin.kz http://lnk.in http://shurl.net http://simurl.com http://tinyclink.com http://urlcut.com http://w3t.org http://2u.lc

컨텐츠 공급자가 직접 제공하는 Fancy Url

팬시 URL 기법은 이전부터 존재 했던 방식으로 유저가 URL을 기억하기 쉽도록 서비스 사에서 직접 단축 url을 제공하는 방식입니다

예를 들어, 네이버 블로그의 경우 다음과 팬시 url 이 제공됩니다

실제 주소: http://blog.naver.com/NBlogMain.nhn?blogId=mkex&

Fancy Url: http://blog.naver.com/mkex/

이는 블로그 주소는 물론 게시물 주소도 해당됩니다. 서비스를 제공하는 업체에서 직접
제공하는 방식입니다

이 개념을 적용해 컨텐츠 공급자 차원에서 트위터를 겨냥해 단축 url 을 제공해 주는 경우도
있습니다. 국내 위키트리라는 뉴스 사이트에서는 기사 원문에 대해 단축 url 을 직접 생성 해 주며 글 내용도 자동 생성해 줍니다

아래 그림과 같이 기사 원문에서 트위터 이미지를 클릭하면,

다음과 같이 트위터 글 쓰기 폼이 열리며 단축 주소와 글 내용이 자동 생성되어 열립니다

오픈 API를 이용한 연동 가능

트위터는 기능에 대한 API 를 오픈하고 있어 이를 이용하면 외부 사이트에서 트위터로 글을
등록할 수 있습니다

현재 대표적으로 트위터에 이미지를 등록하는 http://twitpic.com  에서 트위터의 Open API 를 이용해 이미지를 등록해 줍니다. 이 방식을 활용하면 우리의 서비스 글을 트위터로 올리는
편리한 프로세스를 (제한적이지만) 만들 수 있을 것 같습니다

아래는 트위터에 이미지를 등록해 주는 사이트 목록입니다

http://twitpic.com http://www.yfrog.com http://www.mobypicture.com http://www.twitgoo.com http://tweetphoto.com

이상 기본적인 조사입니다

추가 확인 사항 있으면 회신해 주세요

모바일 웹 사이트 개발을 위해 HTML5를 선택하기로 했지만, 이는 클라이언트 기술일 뿐 막상
서버측 기술은 어떤걸 쓰야 할지 고민이다

문제는 웹 표준이다. 모든 모바일 장비에서 원활히 돌아가야 하기에 표준을 준수하는게 중요하다

ASP.NET 을 사용하자니 각종 서버 컨트롤과 웸폼, 뷰스테이트, 포스트백 등의 매커니즘을 위해
닷넷 프레임워크 차원에서 자동 생성하는 HTML 태그들이 마음에 걸린다.
아직 상세히 테스트를 해 보진 않았지만 예상하기에 대략 호환성에 문제가 있지 않을까 싶다

그러면 ASP냐? 이건 뭐.. MS 자체에서도 기술지원을 그만 둔 과거 기술이기에 시대를 거스르고
싶진 않다. 그러면 JSP, PHP? 이건 내가 잘 모르는 기술이다. 물론 이 환경이 꼭 필요하다면 개발자를
채용해서 담담하도록 하면 되지만, 이 기술들이 필수로 필요하다는 이유가 없다

그러면 ASP.NET 을 ASP 처럼 구현한다?
즉 서버 컨트롤이나 자동 바인딩, 포스트 백 등등 ASP.NET 웹폼 기술은 전혀 사용하지 않고 요청에 대한 처리만 담당하고 프리젠테이션 부문의 디스플레이는 일일이 수동으로 하는 것이다

뭐, 대략 가능은 하겠으나 그리 땡기지는 않는다

우연히 회사 동료랑 예기하다가 MVC 패턴을 고려하게 되었다
닷넷에서도 MVC 프레임워크를 철저히(?) 제공해 주며 이전 서버컨트롤의 난무함(?)이 없다고 하니
일단은 가장 적합한 모델이지 않나 싶다

닷넷이 제공하는 MVC 프레임워크에서 프리젠테이션 컨트롤들과 데이터 연동을 어떤 식으로 하는지
확인해 봐야 겠다