2009년 11월 버전에 이어서, Windows Azure Tools의 최신 버전이 업데이트되었습니다. 이번 업데이트에서는 2009년 11월 버전에서 보고된 주요 문제점들 (특히 Visual Studio 2010 Beta 2에서 발견된 문제점들)이 많이 개선된 것이 눈에 띄며, 곧 출시될 Visual Studio 2010 RC (Release Candidate) 버전과 Visual Studio 2008 SP1을 대상으로 설치가 가능합니다.
이번에 배포되는 SDK에서 신규 제공하는 Windows Azure와의 연동 기능은 크게 두 가지입니다.
* Windows Azure Storage에 드라이브 마운트: Microsoft.WindowsAzure.StorageClient.CloudDrive 클래스 (http://msdn.microsoft.com/en-us/library/microsoft.windowsazure.storageclient.clouddrive.mount.aspx)를 이용하여, 프로그래밍 레벨에서 Windows Azure Storage에 마운트하여 드라이브 문자를 할당할 수 있는 기능을 제공합니다. 이 기능을 통하여, 기존의 Legacy Win32 응용프로그램을 별 다른 확장 기술 없이 자연스럽게 Windows Azure와 연동될 수 있도록 만들 수 있습니다. 만약 자세한 백서가 필요하시다면, http://go.microsoft.com/?linkid=9710117 에서 다운로드할 수 있습니다. 이 기능을 이용하려면, Windows Azure OS의 버전을 적어도 1.1 이상으로 설정하여 배포하여야 합니다.
* Windows Azure 버전 선택: Windows Azure 자체는 하나의 완전한 운영 체제이며, Windows Azure Platform을 구성하는 가상 머신의 운영 체제입니다. 이 글을 작성하는 현 시점에서, 2009년 12월에 발표된 Windows Azure 1.0 (http://msdn.microsoft.com/en-us/library/ee956589.aspx)과 2010년 1월에 발표된 Windows Azure 1.1 (http://msdn.microsoft.com/en-us/library/ee924682.aspx) 중 택일할 수 있으며, 환경 설정 도구에서 편리하게 선택할 수 있는 옵션을 제공합니다. 그리고, 당연한 이야기이지만, 기능에 대한 변화 뿐만 아니라, 다각도에서 테스트하여 발생 가능한 보안 문제를 수정하는 노력도 더해지므로 항상 최상의 보안 상태를 유지할 수 있는 이점도 제공합니다.
그 외 다수의 버그들이 수정되었으며, 설치 방법은 2009년 11월 버전 때와 마찬가지로 일부 Hotfix들을 OS와 사용하는 개발 도구에 맞추어 추가 설치해야 합니다. (설치 방법에 대한 문서 보기: Windows Azure 개발 환경 구축 단계별 설명서)
Windows Azure SDK 1.1 설치: http://www.microsoft.com/downloads/details.aspx?FamilyID=dba6a576-468d-4ef6-877e-b14e3c865d3a&displaylang=en
Windows Azure Tools 1.1 설치: http://www.microsoft.com/downloads/details.aspx?familyid=5664019E-6860-4C33-9843-4EB40B297AB6&displaylang=en
IT 업계의 최신 트렌드와 함께, 2010년에 가장 주목받을 수 있는 기술 분야들을 한꺼번에 정리하는 IT 트렌드 2010 웹 사이트가 런칭되었습니다. 이 웹 사이트에서는 Microsoft의 최신 기술들을 바탕으로 10가지 테마를 소개합니다. "클라우드 컴퓨팅", "그린 IT", "3스크린 전략 및 새로운 UX 기술", "가상화", "마켓플레이스", "모바일", "소셜리틱 어플리케이션", "통합 보안 환경", "IT 거버넌스", "소프트웨어 품질"에 대한 이야기를 전하고 있습니다. 관심있으신 분들께서는 꼭 방문하여 좋은 정보 얻어가시면 좋겠습니다.
닷넷 프레임워크를 이용하는 동안, 의외로 곳곳에 훌륭한 기술들이 많이 숨어있습니다. 특히 문자열 처리에 관한 부분은 특별한 경우가 아니면, 기본으로 내장되어있는 API들 (Formatting API와 정규 표현식 API)만으로 쉽게 처리가 가능합니다. 예전 블로그 아티클 중에 정규표현식에 관련된 아티클들이 몇 가지 있으니 이 아티클과 더불어서 보시면 좋을것 같습니다.
오늘 살펴보려고 하는 내용은 String Formatting API에 대한 내용입니다.
1. 자유자재로 사용하는 치환자
대부분의 예제, 대부분의 코드에서는 String Formatting API에 서식 문자열을 지정할 때, 인자 순서대로, 단 한 번씩만 치환자를 사용합니다. 하지만, 같은 치환자를 여러번 중복해서 사용하거나, 인자 순서와는 별개로 지정할 필요는 많습니다. 이럴 때에는, 걱정하지 말고 매개 변수 개수에 유의하면서 치환자를 자유롭게 사용하면 됩니다.
String.Format("{0} {1} {1} {4} {3} {2}", 'a', 'b', 'c', 'd', 'e');
// => a b b e d c
2. C# 만의 편리한 기능: Verbatim String과 함께 사용하는 강력한 Formatting API
여러 줄에 걸친 문자열을 별도의 데이터 파일이 아닌, C# 코드 내에 포함할 수 있다면, 좀 더 String Formatting API를 극적으로 활용할 수 있을 것입니다. 이럴 때, Verbatim String을 활용하면 좋습니다. Verbatim String은 @" 으로 시작하여 " 로 끝이나는 문자열 구문 전체를 말합니다. 이 문자열 블럭 안에는 Back Slash나 CR/LF 등의 문자를 포함할 수 있습니다.
String.Format(@"<html>
<head><title>Hello World!</title></head>
<body>
<p>{0}</p>
</body>
</html>", DateTime.Now);
다만 유의할 점이 하나 있다면, 문자열이 파일로부터 나타난 것이든, Verbatim String에 의한 것이든, 의미를 다르게 해석할 가능성이 있는 글자 (예: '{' 나 '}' 같은 글자)들은 그 의미를 정확하게 살릴 수 있도록 지정하거나, 같은 문자를 연속으로 두번으로 지정하여 이스케이프 처리해야 합니다. (예: "{{", "}}")
String.Format(@"int main(int argc, char **argv) {
return 0;
}");
즉, 위의 경우 String.Format 메서드에서 오류를 반환합니다. 치환자 시작 기호 다음에 적절한 수식 대신 다른 문자열들이 열거되기 때문에 치환할 수 없다는 오류가 발생합니다. 위의 경우 중괄호 부분들을 아래와 같이 수정해야 합니다.
String.Format(@"int main(int argc, char **argv) {{
return 0;
}}");
위의 예시에서는 C 언어 코드에 대한 것을 예로 들었습니다만, 같은 방법으로 C# 프로그래밍 코드를 코드 안에 포함하여 재사용할 수도 있습니다. 또는, IronPython 등의 코드를 Embedding하여 DLR에서 사용할 수 있도록 재구성하는 시나리오도 생각해 볼 수 있을 것입니다.
3. 날짜 및 시간 표현을 자유자재로 활용하기
아직도 날짜 및 시간 표현을 위하여 문자열을 조립하거나, 알고리즘을 사용하여 오전/오후를 구분하십니까? 그렇게 할 이유가 없습니다. 오히려 좀 더 세밀하고 다양한 기능을 제공하는 기본 기능이 있기 때문입니다.
String.Format(@"{0:yyyy-MM-dd}", DateTime.Now); // 2009-01-30
String.Format(@"{0:tt hh:mm:ss}", DateTime.Now); // 오전 01:47:33
String.Format(@"{0:yyyy-MM-dd tt hh:mm:ss}", DateTime.Now); // 2009-01-30 오전 01:48:11
만약 오전/오후에 해당하는 문자열을
한글이 아닌 영문 표기 (AM/PM)로 변경하려면 어떻게 해야 할까요? 이럴 때에는
CultureInfo 객체를 Format 메서드에 전달하면 간단해집니다. CultureInfo는 System.Globalization 네임스페이스 안에 있습니다.
String.Format(CultureInfo.GetCultureInfo("en-US"), @"{0:tt hh:mm:ss}", DateTime.Now); // AM 04:30:44
String.Format(CultureInfo.GetCultureInfo("ko-KR"), @"{0:tt hh:mm:ss}", DateTime.Now); // 오후 03:03:02
String.Format(CultureInfo.GetCultureInfo("ja-JP"), @"{0:tt hh:mm:ss}", DateTime.Now); // 午後 10:08:03
위의 예시에서 주석으로 표시한 것과 같이 현재 시간에서 "오전"과 "오후"에 대한 표현을 해당 국가의 언어의 표기법에 맞추어 표기하고 있습니다. en-US는 언어를 영어로 사용하며 지리적으로 미국을 기준으로 한다는 의미로 해석되며, ko-KR은 언어를 한국어로 사용하고 지리적으로는 대한민국, ja-JP는 언어를 일본어로 사용하고 지리적으로 일본을 기준으로 한다는 의미로 해석됩니다.
위와 같이 언어 및 지역 코드를 설정할 때 알아야 할 사항이 두 가지가 있는데, 첫 째는 반드시 언어 코드의 전체 이름을 기재해야 합니다. 예를 들어, en-US에서 en만 지정하면 en에 해당하는 설정은 "중립 문화권"이기 때문에 CultureInfo.GetCultureInfo 메서드로는 받아들일 수 없습니다. 그리고 US만 지정하면 US에 해당하는 코드가 없으므로 역시 오류가 발생합니다. 그리고, 언어 코드가 시간대 설정까지 자동으로 반영하는 것은 아니므로 en-JP (언어는 영어이며 지역은 일본)와 같은 설정은 유효하지 않으며 표준 코드 정의 내역에 없기 때문에 받아들여지지 않습니다. 시간대에 대한 설정은 http://msdn.microsoft.com/ko-kr/library/system.timezone.aspx 에 소개된 TimeZone 클래스 (닷넷 3.5부터 사용 가능합니다)를 활용해야 합니다.
4. 통화 금액 표현하기
지역 설정을 이용하여 손쉽게 처리할 수 있는 일이 또 한 가지 있는데, 바로 통화 금액 표기에 관한 것입니다. 아래의 코드를 살펴보기로 하겠습니다.
String.Format(CultureInfo.GetCultureInfo("es-ES"), "{0:C}", 300); // 300,00 €
String.Format(CultureInfo.GetCultureInfo("ko-KR"), "{0:C}", 300); // ₩300
그리고, 좀 더 구체적으로 소수점 자릿수 등을 표현하거나, 음수/양수/영점 표현을 설정하고자 한다면 아래와 같이 활용할 수 있습니다. (Delphi Basic 웹 사이트 http://www.delphibasics.co.uk/RTL.asp?Name=FormatFloat 에서 부분 발췌한 샘플 코드를 올립니다.)
// 반올림 예시
String.Format("{0:#####}", 1234.567);
String.Format("{0:00000}", 1234.567);
String.Format("{0:0}", 1234.567);
String.Format("{0:#,##0}", 1234.567);
String.Format("{0:0,0}", 1234.567);
// 소수점 사용 예시
String.Format("{0:0.####}", 1234.567);
String.Format("{0:0.0000}", 1234.567);
// 공학용 표기
String.Format("{0:0.0000000E+00}", 1234.567);
String.Format("{0:0.0000000E-00}", 1234.567);
String.Format("{0:#.#######E-0#}", 1234.567);
// 음수/양수/ZERO 에 따른 표기
String.Format("{0:0.0}", -1234.567);
String.Format("{0:0.0 CR;0.0 DB}", -1234.567);
String.Format("{0:0.0 CR;0.0 DB}", 1234.567);
String.Format("{0:0.0 CR;0.0 DB;Zero}", 0.00);
5. Bonus: 자연스러운 16진수 표기 방법 (String.Format을 사용하지 않습니다.)
"0x" + (16).ToString("X8"); // 8자리 16진수 표기, 대문자
"0x" + (33).ToString("x4"); // 4자리 16진수 표기, 소문자
미리 알림) 이 글은 아직 출시되지 않은 소프트웨어와 그에 대한 개인적인 소견을 덧붙인 글로, 시간이 지남에 따라 내용에 변동이 생기거나 입장이 변경될 수 있음을 미리 알립니다.
CNN의 2009년 11월 19일자 기사 중 Internet Explorer 9.0에 대한 기사 ( http://www.cnn.com/2009/TECH/11/19/cnet.internet.explorer.nine/index.html)에 관하여 소개 겸 개인적인 의견을 덧붙여보고자 블로그에 글을 남깁니다. 소개한 기사는 Microsoft의 Internet Explorer 팀의 책임자 딘 하차모비치와의 인터뷰를 수록하고 있습니다. 자세한 내용은 기사를 참고하시면 좋겠습니다.
Microsoft가 브라우저 전쟁에 다시 복귀하게 되는 시점은 줄곧 예상되어왔지만 아마도 Internet Explorer 9.0을 기점으로 전쟁터에 다시 뛰어들지 않겠느냐 하는 이야기가 많습니다. 그리고 그 점은 어느정도 일리있어 보입니다.
현재, 웹 브라우저는 이전과는 전혀 다른 방향으로 발전을 꾀하는듯 합니다. 클라우드 컴퓨팅과 웹 프레젠테이션 기술의 발달, 무선 네트워크 기술 향상 등 이전보다 더 "유비쿼터스적 형상"에 가까워지는 IT 기술 덕분에, 이전의 브라우저 전쟁에서처럼 단순한 응용프로그램 - 또는 - 패키지 소프트웨어에 국한되지 않고, OS 자체의 목적을 웹 브라우징으로 초점을 변경하는 시도 - 또는 - OS의 특징적인 영역들의 상당 부분을 인터넷으로 옮기는 시도와 같이 새로운 시도를 하고 있습니다.
물론 이러한 시도를 반갑게 여기지 않는 곳도 많지만, 주류 컴퓨팅 시장을 리드할 권한을 지니고 있는 몇몇 업체들의 공통된 방향이 이러한 방향이라면, 어느 정도 영향은 끼치게 되지 않겠는가 하는 생각이 듭니다.
Internet Explorer 9.0은 Internet Explorer 8.0에서 이룬 변화를 기초로, Windows 7 이후부터 사용할 수 있는 고유의 독창적인 기술들을 더 적극적으로 사용하고자 한다는 것이 특징적입니다. Software + Service 전략에 Windows Azure, Windows Live Services를 더하는 것 말고도, 사용자들이 눈에 보이게 체감할 수 있는 Plus Alpha를 준비하는것으로 생각됩니다.
Internet Explorer 9.0의 개발 목적을 "더 뛰어난 브라우저를 대다수의 고객인 Windows 사용자들에게 제공하는 것"으로 소개하고 있듯이, 특정 브라우저가 지니고 있는 독창적이거나 특수한 기술보다는, 일반 사용자들에게 더 어필하기 쉬운, 안정화된 모습의 브라우저를 개발하고자 하는 것이 주된 요점으로 보입니다.
기사에서 열거된 Internet Explorer 9.0의 주요 변경 사항 및 개선 사항들은 대략 아래와 같습니다.
하드웨어 가속: Windows Vista 이후부터 도입된 Aero 덕분에, GDI를 사용하는 응용프로그램들도 더 향상된 그래픽 및 사용자 경험을 체감할 수 있었습니다. 그리고 GDI+는 개발자들을 위하여, GDI에서 부재 사항으로 알려진 여러 이미징 관련 부가 기술에 대한 확장된 API를 제공하였습니다. 하지만, GDI가 아닌 완전히 새로운 차원의 2D 그래픽 Drawing을 DirectX 위에서 가능하게 하는, Direct 2D를 Internet Explorer 9.0에서부터는 GDI 대신 도입할 예정이라고 합니다.
호환성 향상: 다른 브라우저에 비하여 Internet Explorer가 최신 기술에 취약하다는 것을 설명하기 위해 주로 차용되던 ACID3 테스트에 대한 평점 향상을 지속적으로 수행하고 있다는 이야기와 함께, HTML5에 대한 지원, CSS 지원 향상 등을 목적으로 개발중이라고 합니다.
자바스크립트 향상: 현재 Microsoft의 자바스크립트 기술은 Internet Explorer 6.0 이후로 특별히 개선되거나 하는 것은 없으며, 일반적인 범주의 자바스크립트 사용 방법과, ActiveX, COM 등의 기술과의 호환성을 다루는데에는 최상의 성능을 보여줍니다. 하지만, 이번에 개발 중인 Internet Explorer 9.0에서는, Google Docs나Microsoft Office 웹 어플리케이션과 같이 JavaScript를 전적으로 사용하는 웹 어플리케이션을 "빠르고 안전하게 실행할 수 있도록" 개선하는 것을 진행 중이라고 합니다.
다른 브라우저들이 이미 충실히 지원하는 것을 뒤늦게 맞추는 감도 없지는 않지만, 시장 점유율이 높은 브라우저의 움직임은 전달 속도 이외의 다른 전략을 꾀하는 노림수가 될 가능성 또한 있어 보입니다. 이러한 움직임 하나 하나는 주목할 만한 부분이 아닌가 싶습니다.















