Kyra

사용자들의 Ajax 방식의 웹 환경에 경험이 많아지면서 일부분이라도 Ajax 방식의 애플리 케이션을 제작 해야 합니다.
하지만 시간도 없고 당장 구현도 해야 하니 다른 사이트나 강좌를 통해 코드 카피를 통해 구현 하는 것을 많이 봐 왔습니다.
웹 애플리케이션에 대한 Ajax를 적용한다는건 제가 경험 하기로는 단순한 사용자 UI의 변경을 의미 하는건 아니였습니다.
Ajax 애플리케이션은 시스템 전체에 영향을 주며, 아키텍처적 변경 부터 구현 알고리즘까지 모든 개발 과정과 사고에 영향을 주는 막대한 작업 이였습니다.
그렇다고 Ajax를 구현하기가 심히 어렵거나 비용이 많이 들어가는건 아닙니다.
다만 모든 기술이 그렇듯 사용하기 위해 그 기술에 대한 깊은 이해를 바탕으로 이용을 해야 합니다. 그렇지 못한 경우 그 기술이 양날의 검이 되어서 내게로 다시 돌아와 돌이킬수 없는 큰 상처를 남기기도 하지요 그래서 다음과 같은 Ajax의 개론에 대한 강좌를 팀 블로거로 가져 와 봤습니다.
물론 개론적인 것이지만 실무적으로 또는 더 깊이가 있는 내용을 원한다면, 지금은 서적및 Ajax에 대한 자료들이 넘쳐나니 개인적으로 충분이 구하실수 있다고 생각하고 아래 내용만 올려 드립니다.

작성자 네오비스

금주 Microsoft는 ASP.NET에서의 AJAX 개발을 위한 프레임워크였던 Atlas를 ASP.NET AJAX라는 이름으로 변경하고, 그 베타버전을 출시하였다. 단순히 웹 개발을 위한 프레임워크의 출시로 볼 수 있지만, 새로운 변화를 준비하는 Microsoft의 웹 개발의 관점에서다시 한번 생각해 보도록 하자. Microsoft는 2007년 1월 Windows Vista와 Office의 새로운 버전을준비하고 있다. 더불어 윈도우 라이브 닷컴을 통해 인터넷 서비스 기업으로의 영역 확대를 시도하고 있다. 얼마 전 국내에서는 Microsoft DevDays2006 행사를통해 윈도우 라이브 닷컴 가젯(플러그인 또는 작은 응용 프로그램) 콘테스트의 시상식을 가졌다. 일반 개발자들을 대상으로 한콘테스트의 의미도 있지만, Microsoft는 전세계 웹 개발자들에게 윈도우 라이브 닷컴의 존재와 매시업(mash-up) 형태의개방된 가젯 구조를 지원하고 있다는 것을 알리는데 더 큰 의미를 두었을 것이다. 다른 나라 개발자들의 작품을 살펴보고 싶다면 윈도우 라이브 닷컴 가젯 갤러리를 한번 방문해 보자.

ASP.NET AJAX로의 프레임워크 이름을 변경하다.
이번 프레임워크에서의 표면적인 큰 변화는 바로 ASP.NET AJAX로의 이름 변경이다. 지금까지 Atlas라는 이름보다는 보다직관적인 이름을 사용하여 개발자들이 쉽게 프레임워크의 기능을 이해하도록 배려하였다. 진작 이런 이름을 사용하였으면 더 좋았을것이지만 지금이라도 이렇게 변경해주니 그나마 바른 선택이라 생각한다.

더불어 기존 Atlas CTP 버전을 통해제공하던 프레임워크의 기능을 크게 3가지로 나누어 배포하고 있다. ASP.NET AJAX Core에 해당하는 ASP.NETAJAX 1.0 Beta, 기존 CTP 버전에서 제공하였지만 Core에 포함되지 않은 부가기능에 해당하는 ASP.NET AJAXCTP, 마지막으로 공개적으로 개발되고 있는 다양한 컨트롤을 제공하는 ASP.NET AJAX Control Toolkit이 이에해당한다. 여기서 한가지 주목할 부분이 바로 Control Toolkit이다. 지금까지 Microsoft는 모든 개발 툴 및컴포넌트를 자사에서 개발하였다. 그러나 이번 ASP.NET AJAX Control Toolkit은 외부로 공개하여 다른개발자들도 참여할 수 있도록 유도하고 있다. 이전에 비해 사뭇 달라진 그들의 모습을 볼 수 있는 대목이라 생각된다. 국내개발자들도 프로젝트 사이트를 통해 참여할 수 있으니 한번 살펴보도록 하자.

개발자들에게 선택의 폭을 넓혀주는 ASP.NET AJAX
AJAX기반의 웹 페이지를 만든다는 것은 개발자들에게 있어 더 많은 코드작업을 요구한다고 이해하면 된다. 보다 멋진 화면을 위해비동기처리니 클라이언트에서의 자바스크립트 코드 작업에 지금도 고생하고 있는 그들이다. 그러나 ASP.NET AJAX는 기본적으로AJAX 기반의 웹 페이지 개발에 있어 서버상의 ASP.NET의 특징과 클라이언트의 스크립트 특징을 통합하여 제공하려는 목적이있다. 즉 ASP.NET 서버 사이드 개발과 함께 클라이언트 스크립팅을 통합하여 제공하고 있다. 대부분의 AJAX 기반의 웹개발이 클라이언트 또는 서버 중 하나에 집중되어 있는데 반해 ASP.NET AJAX는 개발자들이 사용하기 편한 방식을 선택하여응용 프로그램을 제어할 수 있도록 클라이언트/서버 모두를 위한 툴을 지원하고 있다.

그러므로 개발자들은 보다쉬운 코딩 방식을 선택하여 ASP.NET 기반의 AJAX 웹 페이지를 구축할 수 있는 것이다. 예를 들어 AJAX 서버 컨트롤을이용하면, ASP.NET 웹 페이지(*.aspx)에서의 어떠한 자바스크립트 코드 작업 없이 단순한 컨트롤의 추가만으로 페이지의일부가 렌더링되는 AJAX 스타일의 페이지를 만들 수가 있다. 바로 서버 컨트롤과 ASP.NET AJAX 프레임워크가 페이지실행을 위한 클라이언트 스크립트를 자동으로 만들어주기 때문에 가능한 코딩 방법인 것이다. AJAX 스타일의 웹 개발에서 큰문제로 대두되고 있는 개발 생산성 문제를 어느 정도 해결해 줄 것으로 기대되는 부분으로 가장 큰 매력이 될 것이다.

[그림 1] 서버 중심의 응용 프로그램 모델


[그림 2] 클라이언트 중심의 응용 프로그램 모델



Microsoft는 윈도우 라이브 닷컴에서 보듯이 서비스 시장으로의 확대를 준비하고 있다. 이런 준비와 함께 웹 개발자들을 위한 새로운프레임워크와 프로그램을 제공할 예정이다. 또한 그들이 제작하는 웹 페이지에 이런 기술들을 사용하여 개발자들에게 신뢰를 주고,개발자들에게 보다 쉬운 개발환경과 생산성을 제공하여 입지를 굳건히 하려고 노력하고 있다. 이와 함께 자신들과 동일한 개발플랫폼을 사용하는 사이트를 확대하기 위한 노력도 ASP.NET AJAX를 통해 알 수 있다. 

웹 2.0 시대로넘어오면서 PHP, Ruby 같은 언어들이 보다 더 많이 주목을 받고 있다. 국내 시장만 들여다보더라도 과히 PHP의 전성시대인것 같다. 서버 점유율로만 보더라도 이전에도 PHP가 국내 웹 개발 시장의 대세였다. 이런 국내 환경에서 Microsoft가지금까지의 부진을 만회할 수 있을지 앞으로의 행보가 궁금하다. 모든 개발은 주어진 환경과 상황에 맞게 그 플랫폼이 선택되고,구현되어야 한다고 필자는 믿고 있다. 잠시 자신의 개발 플랫폼 이외의 다른 개발 플랫폼을 들여다 보는 여유를 가져보는 것은어떻겠는가? 더불어 국내에서 보다 활발하게 웹 2.0스러운 사이트가 개발되기를 바라며, ASP.NET AJAX를 이용한 좋은사이트들이 많이 생겨 ASP.NET AJAX 공식 사이트에서 소개되기를 기대해본다.

앞전에 글에서 닷넷의 형에 대해서 간략히 이야기 해보고 더 진행 한다고 했는데 아직 못하고 있네요 ㅡㅡ
이러니 블로거가 활성화 되지 않는 것 같습니다.
잛은시간에 강의에 맞먹는 글을 쓰기는 힘들 것 같고 또한 일방적인 전달 방식의 지식은 별로 유용하지 못 할 것 같아. 오늘은 그냥 같이 고민해 보아야 할 문제에 대해서 여러분의 의견을 듣고 싶습니다.
객체 지향 언어 에서는 모든 문제는 선택의 문제만 있고 딱이 이거다라는 답이 없습니다.
물론 프로그램을 처음 하시는 분이나 선택 차체가 어려운 분은 다른 사람의 지식을 모방하는 수준에서 프로그램을 하겠지만 이것 또한 잘못 된건 아니라고 생각 합니다.
다만 모방과 카피를 통해 프로그램을 하더라도 기본적인 문제에 대한 고민은 같이 해봐야 할 것 같습니다.
다시 한번 말씀드리지만 정답은 없습니다. 다만 자신의 생각과 논리에 의거한 선택이 있을 뿐입니다. 가벼운 마음으로 오늘의 문제인 변수에 대해서 자유롭게 말씀해주세요

문. 로컬 변수와 필드 변수 를 어떻게 사용하십니까?

* 질문이 막연 합니다 ^^ 우리가 클래스를 구성 할때 특정 상태나 데이터의 전달을 위해서 변수를 사용합니다. 객체지향의 클래스에서 사용하는 변수는 특성상 로컬 변수와 클래스 필드로 나눌 수 있습니다.
그럼 여러분은 과연 어떻게 로컬 변수 와 클래스 필드의 사용을 결정 하십니까?

모두에게 행운이

VS2005 SP1의 설치 옵션으로 시간은 단축 했지만
이번에는 디지털 서명 확인 오류가 발생했다.
물론 위 내용은 설치 옵션 사용에서 밝혀 뜻이 설치 옵션으로 설치시 아무런 메시지 없이 설치가 되지 않아 정상적인 방법으로(무려 2시간) 설치 과정에서 나온것이다.(삽질 이였다. quiet 모드로 설치 해도 로그 파일은 지정한 장소에 남는다 해당 로그에서 오류가 발생했는지 확인하면된다.)

각 설 하고 위 내용은 http://support.microsoft.com/kb/925336/ko 에 문서화 되어 있다.
참 어이가 없는게 원인이 MSI 패키지나 MSP 패키지의 서명 정보를 확인 하는데 필요한 연속의 가상 메모리 공간이 부족해서 나온다고 한다.
이런! VM 에 1.5G 를 활당 했는데도 메모리 공간이 부족하다?
그럼 메모리를 더 줘야 하나?
결코 그런유의 버그가 아니다. 위 링크의 문서 맨 아래 쪽에  참고 에 보면 컴퓨터에 RAM을 더 추가해도 문제가 해결 되지 않는다는 문구 ㅡㅡ;
쓰발 Windows Installer 의 서명 확인 알고리즘에 문제가 있는것이다.

위 문서에서는 3가지의 해결 방법을 제시 하고 있는데 첫번째가 핫 픽스(KB925336) 적용이다. 핫픽스는 2003 용으로 으로 만 있기 때문에 XP 등에서 적용이 불가능 하다. 또한  문서 상에도 핫 픽스를 신뢰 하지 못하는 느낌이 강하게 온다.('특정 문제가 발생하는 시스템에만 핫픽스를 적용해야 합니다.')
그래서 이방법은 패스

두번째 방법은 NT 계열 OS에 모두 적용할 수 있는 방법으로 Register 수정 방법을 제시 하고 있다. HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Safer\CodeIdentifiers
에 PolicyScope 의 값을 1로 변경하고, msiserver 를  서비스를 죽인다.
그런데 위 방법으로도 해결이 안될수 있다는 문구 가 있다.
당연이 misserver 서비스를 죽여 버리니 해당 서비스에 종속적인 패키지는 설치 되지 않겠지 ㅡㅡ 또 성공후에는 수정한 레지스트리 키와 서비스를 다시 원상 복구 해야 한다.
귀찮고 성공할지도 모르고 그래서 이방법도 패스

이제 이문제를 해결 할수 있는 방법은 단 하나 남았다.
먼저 관리 도구에서 로컬 보안 정책으로 가 소프트웨어 제한 정책을 만들고 개체유형에서 강요를 선택한다.
로컬 관리자를 제외한 모든 사용자를 선택 해서 확인하고 재부팅후 설치 한다.

물론 로컬 보안 정책은 도메인 환경 등 때문에 불가능 할 수도 있지만 그럴때는 SA 와 의논한 후 해당 방법을 적용한다.

설치후는 변경내용을 원상 복귀 하기 바란다.

VS 2005 Sp1 설치하는 과정이 너무 오래 걸린다.
마소에서는 전혀 이 문제에 대한 해결책을 제시할 의사가 없는게 분명하고
그렇다고 설치 시 마다 스트레스 받아가며 돌아버릴 것 같은 몇시간을 보내기 싫어서
다른 방법을 찾아보니 명령창에서 다음 속성을 이용하여 설치파일을 실행하면 30분 이내에 끝난다.^^ 주여 감사합니다.
다만 진행 로그나 오류 등은 나오지 않으니 설치후 VS2005  정보에서 RTM 이 아닌  SP 버전이 적용되었는지 확인 해야 할 것이다.

start /wait VS80sp1-KB926605-X86-KOR.exe /quiet /L*v+ VS80sp1-KB926605-X86-KOR.log

*위 와 같이 quiet 모드로 설치를 해도 로그 정보는 기록 됩니다.
다만 ??.log 의 위치를 해당 설치 파일과 틀린 디스크에 저장 하시면 실행 속도를 높일 수 있습니다.
설치 후 log 의 마지막 라인에 '설치가 잘 끝났습니다' 라는 메시지가 있으면 정상적으로 설치 가 완료 된 것 입니다.

앞전 boxing 과 upboxing에서 값 형식 과 참조 형식에 대한 언급이 있었습니다.

그럼 값 형식과 참조 형식이란 무엇 일까요?

닷넷 프레임워크에서 형식이 무엇 인지 알기 위해 먼저 닷넷 프레임워크의 형식의 모든 것인 Common Type System(이하 CTS) 을 살펴 봐야 합니다..

CTS 란 런타임에서 형식을 선언하고 사용 및 관리하는 방법을 정의할 뿐 아니라 언어 간 통합에 대한 런타임 지원의 중요한 부분을 차지 합니다.

위 내용은 msdn 의 CTS 의 개요 내용입니다.

Boxing , unboxing 또한 CTS에서 제공하는 기능입니다.

CTS 의 가장 중요한 역할은 실제 애플리케이션이 실행 할 때 애플리케이션의 형식(type)의 사용과 관리를 하는 것 입니다.

형식(type)이란 런타임시 메모리 공간에 탑재될 데이터의 형태를 말 합니다.

가령 int 형의 변수를 선언하여 실제 구동하게 되면, 런타임에서는 선언된 int을 사용하기 위해 CTS가  OS에게 메모리 상에 32bit 크기의 공간을 요청 하게 됩니다.

그렇게 OS에게 요청 된 것은 OS의 알고리즘에 따라 추상적인 메모리공간이 활당 되게 되며 활당된 메모리 공간에 데이터를 바인딩 하게 됩니다.

또한 메모리상의 바인딩 데이터를 사용할때도 CTS 는 적당한 방법으로 데이터를 해석하여 사용가능하도록 합니다.

부동소수점 형태의 경우 32bit 크기의 메모리공간을 요청하지만 사용방법은 int 형과 완전이 틀립니다. Int 의 경우 32bit 전체 공간에 정수를 저장 하지만 부동소수점 형 은 32bit 공간중 일부 구간을 소수점 이하 자리를 위한 공간으로 사용하게 됩니다.

소수점 이하 몇자리 까지 사용할 건지에 따라 정밀도라 부르며, 닷넷에서 지원하는 부동 소수점 형태는 msdn 을 참조 하면 정확하게 확인 할수 있다.

이처럼 CTS는 메모리의 사용과 관리에 관한 일을 주 임무로 하고 있습니다.
그리고 CTS는 형 안정성을 추구 하기도 합니다. 형 안정성은 형의 사용에 있어서 문제가 발생 할 수 있는 코들를 컴파일러 에서 확인 가능하도록 하며, 최악의 경우에도 런타임시 예외나 오류의 발생으로 혹시 있을지 모를 데이터의 손상을 막아 주는 기능 입니다.

모든 소프트웨어 컴파일러 및 개발 언어들은 자체의 Type System을 제공 하고 있으며, 각 형태는 언어 마다 특이 점들이 많습니다.

루비 같은 경우 모든 타입을 참조형으로 보며, 타입들의 변환이 매우 자유로운 환경을 제공 하고, 자바 스크립트 같은 경우 형의 선언 없이 사용가능한 방법을 제공 하기 도 합니다.

닷넷 이전까지의 Type System 은 프로그램 언어의 컴파일러 기능으로 각 언어별 정수를 나타내는 int 형이라고 할지라도 그 사용 방법이나 관리 방법의 차이로 호환이 불가능 했습니다.

하지만 닷넷 에서는 Type System을 프레임워크의 기능으로 탑재 하여 각 닷넷을 지원하는 언어들이 아무런 문제없이 서로의 데이터 형을 이용 가능 하도록 하였습니다.

그래서 앞에 Common이 붙은 거겠죠.

이렇게 CTS가 사용 및 관리한는 형은 크게 값 형과(value Type) 과 참조 형(Reference Type) 으로 분류 할 수 있습니다.

대충 CTS가 무엇인지 설명 드렸습니다만 Type System에 관련된 내용은 컴파일러 및 OS와 프로그램의 런타임과도 많은 관련이 있어 자세히 설명 하지 않았습니다.(사실 설명하기에는 아직 제 지식이 …) 그럼 다음 시간에 CTS의 값 형식에 대해서 알아 보겠습니다.

모두에게 행운이 있기를…