비텐펠트's FastWebDev@log™

1. Ajax의 개념 및 주요 기술

2011-05-01T02:02:00.000-07:00

Ajax란 어떤 새로운 기술이 아닌 지금까지 웹에서 사용되어왔던 Javascript,DHTML,XML,CSS,DOM 등의 기존 기술들을 모아 풍부한 User Interface를 구현하기 위해 정립된 기술의 집합체라고 할 수 있다. 이는 기존 전통적인 웹 구조의 문제점을 해결하기 위해 ActiveX를 의존함으로써 발생한 특정 벤더의 기술 의존과 배포의 문제점을 해결함으로써 현재 가장 널리 쓰이는 WEB2.0의 대표적인 기술이다.

이 장에서는 Ajax의 기본 개념과 주요기술에 알아보고 전통적인 웹구조의 방식과 비교를 통해 그 차이점을 알수 있도록 하였다.

1.1 Ajax의 개념

BigPipe : 성능 향상을 위한 웹 페이지 파이프라인

2011-03-16T18:35:00.000-07:00

http://www.facebook.com/notes/facebook-engineering/bigpipe-pipelining-web-pages-for-high-performance/389414033919

웹 사이트의 속도는 페이스북의 가장 중요한 회사 목표 중의 하나이다. 이 글에서 설명하는 방법으로 페이스북의 속도를 2009년에 두 배로 성공적으로 개선하였다. 우리의 엔지니어링 팀은 몇 가지 핵심 아이디어에 착안하여 이를 가능하게 하였다. 이 훌륭한 기술적 성과의 토대가 되는 'BipPipe'라 불리는 비밀 무기를 여기서 설명하겠다.

BigPipe는 시스템에 제공되는 동적 웹 페이지의 근본적인 재설계이다. 이 일반적인 아이디어는 웹 페이지를 'pagelets'라 불리는 작은 조각으로 나누고 웹 서버와 브라우저의 실행 단계에 이를 파이프라인 형식으로 보내는 것이다. 이는 대부분의 마이크로프로세서가 수행하는 파이프라인 방식과 유사하다. 최고의 성능을 내기 위해 다수의 명령어가 프로세서의 각기 다른 실행유닛(execution unit)에 파이프라인 형식으로 보내진다. BigPipe는 기존 웹 서비스 프로세스의 재설계에 기초한 것이지만 기존 웹 서버나 브라우저를 변경할 필요는 없다. BigPipe는 전적으로 PHP나 JavaScript 안에서만 실행된다.

Motivation

BigPipe를 이해하려면 기존 동적 웹 페이지 서비스 시스템의 문제점을 살펴볼 필요가 있다. 초기 월드 와이드 웹이 만들어질 당시와 별로 달라진게 없던 시절까지의 문제점을 되돌아 보자. 근대의 웹 사이트는 10년 전에 비해서 드라마틱하게 동적이고 상호작용적으로 변했으며 전통적인 서비스 모델을 고수하는 페이지는 현재의 인터넷 속도를 감당하지 못하게 되었다. 전통적인 모델에서는 사용자 요구사항의 생명 주기가 아래와 같았다.

1. 브라우저가 웹 서버로 HTTP request를 보낸다.

2. 웹 서버는 request를 파싱하여 데이터를 저장소에서 추출하여 HTML 문서를 구성한다. 구성한 HTML 문서는 HTTP response를 사용하여 클라이언트에게 보낸다.

3. HTTP response는 인터넷을 통해 브라우저로 전송된다.

4. 브라우저는 웹 서버의 response를 파싱하여 HTML 문서를 나타내는 DOM 트리를 구성하고 HTML 문서에서 참조하는 CSS와 JavaScript 자원을 다운로드한다.

5. CSS 자원을 다운로드한 후에 브라우저는 CSS를 파싱하여 DOM 트리에 이를 적용한다.

6. JavaScript 자원을 다운로드한 후에 브라우저는 JavaScript를 파싱하여 이를 실행한다.

전통적인 모델은 현재 웹 사이트에 매우 불편한 구조이다. 시스템의 많은 오퍼레이션이 순차적이고 각각의 오퍼레이션이 오버랩(overlap)될 수 없기 때문이다. JavaScript 다운로드를 지연시키거나 리소스 다운로드를 병렬적으로 진행하는 것과 같은 최적화 기술이 이런 제한을 극복하기 위한 방법으로 웹 커뮤니티에 광범위하게 적용되어 왔다. 그러나, 최적화 기술 중 아주 극소수만이 웹 서버와 브라우저의 순차적 실행 때문에 발생하는 병목 현상을 해결해 줄 뿐이다. 웹 서버가 페이지를 생성하는 작업으로 부하가 걸릴 때 브라우저는 idle 상태가 되며 아무일도 하지 않는다. 웹 서버가 페이지 생성을 완료하여 이를 브라우저에 전송하면 브라우저는 성능 병목(performance bottleneck) 상태가 되며 웹 서버는 더 이상 도움이 되지 않는다. 웹 서버의 페이지 생성 시간을 브라우저의 렌더링 시간과 오버랩하면 종단 간 지연시간을 줄일 수 있을 뿐만 아니라 웹 페이지의 초기 반응을 사용자에게 이른 시간에 보여줄 수 있다. 따라서, 사용자가 인식하는 지연 시간을 상당히 줄일 수 있다.

웹 서버의 페이지 생성 시간과 브라우저의 렌더링 시간을 오버랩하는 방법은 Facebook과 같은 리치 웹 사이트에 아주 유용한다. 전통적인 Facebook 페이지는 친구 목록, 새 피드, 광고 등과 같이 다양한 데이터소스로부터 생성된 데이터를 포함한다. 전통적인 페이지 렌더링 모델에서는, 최종 HTML 문서가 구성되어 사용자의 컴퓨터로 전송되기 전에, 이런 데이터를 요청하는 쿼리가 데이터를 반환할 때까지 사용자는 기다려야만 했다. 하나의 느린 쿼리가 이 모든 것들을 잡고 있을 수 있다.

How BigPipe works

웹 서버와 브라우저의 병렬 구조를 이용하기 위해 BigPipe는 첫 번째로 웹 페이지를 'pagelets'라 불리는 작은 조각으로 분해한다. 마이크로프로세서의 파이프라인처럼 명령어의 생명 주기를 다수의 계층(instruction fetch, instruction decode, execution, register write back 등)으로 쪼개며 BigPipe는 페이지 생성 프로세스를 다음과 같은 단계로 분할한다.

1. 파싱 요청 : 웹 서버는 HTTP request가 정상임을 검사하고 이를 파싱한다.

2. 데이터 페치 : 웹 서버는 데이터 소스에서 데이터를 페치한다.

3. 마크업 생성 : 웹 서버는 response를 위한 HTML 마크업을 생성한다.

4. 네트워크 전송 : 웹 서버에서 브라우저로 response가 전송된다.

5. CSS 다운로드 : 브라우저는 페이지에 필요한 CSS를 다운로드한다.

6. DOM 트리 구성과 CSS 스타일링 : 브라우저는 HTML 문서의 DOM 트리를 구성하고 CSS를 적용한다.

7. JavaScript 다운로드 : 브라우저는 페이지가 참조하는 자바스크립트 자원을 다운로드한다.

8. JavaScript 실행 : 브라우저는 페이지의 JavaScript 코드를 실행한다.

처음 세 개의 단계는 웹 서버가 실행하고 나머지 네 개 단계는 브라우저가 실행한다. 각 pagelet은 이 모든 단계를 순차적으로 수행해야 한다. 그러나 BigPipe는 몇 개의 pagelet을 각기 다른 단계에서 동시에 수행할 수 있게 한다.

Pagelets in Facebook home page. Each rectangle corresponds to one pagelet.

위 그림은 웹 페이지가 어떻게 작은 pagelet으로 분해될 수 있는지 보여주는 예이다(페이스북의 홈페이지이다). 페이스북의 홈페이지는 몇 개의 pagelet으로 구성된다: 'composer pagelet', 'navigation pagelet', 'news feed pagelet', 'request box pagelet', 'ads pagelet', 'friend suggestion box', 'connection box' 등. 각 pagelet은 독립적이다. 'navigation pagelet'이 사용자에게 보여질 때 'news feed pagelet'은 서버에서 아직 생성 중일 수 있다.

BigPipe에서 사용자 요청은 다음과 같은 생명 주기를 갖는다: 브라우저는 HTTP request를 웹 서버로 보낸다. HTTP ruquest를 수신하고 이의 유효성을 판별한 후에 웹 서버는 태그와 태그의 첫 부분이 포함된 열린(unclosed) HTML 문서를 즉시 브라우저로 보낸다. 태그는 나중에 받게 될 response의 pagelet을 해석하기 위해 BigPipe의 자바스크립트 라이브러리를 포함한다. 태그는 페이지의 논리적 구조와 pagelet의 소유 구조를 정의하는 템플릿이다. 예를 들어,

첫 번째 response를 클라이언트에게 전송하고 웹 서버는 순차적으로 각 pagelet을 생성하는 작업을 계속한다. pagelet이 생성되자마자 이에 해당하는 response는 즉시 JSON 형식으로 인코딩된 객체로 클라이언트에게 전송된다. JSON 형식의 객체는 pagelet이 필요한 모든 CSS와 자바스크립트, HTML 콘텐츠, 메타데이터를 포함한다.

클라이언트 측에서는 pagelet에 대한 response를 'onPageletArrive' 호출을 통해 받으며 이 호출을 받자마자, BigPipe의 자바스크립트 라이브러리는 CSS 자원을 먼저 다운로드하고 CSS 다운로드가 완료되면 BigPipe는 pagelet이 보여질 부분에 해당하는 Div의 innerHTML에 pagelet의 HTML 마크업을 설정하여 pagelet을 보여준다. 다수의 pagelet의 CSS는 동시에 다운로드될 수 있으며 어떤 CSS가 먼저 다운로드되는지에 따라 순서 없이 보여질 수 있다. BigPipe에서는, 자바스크립트 자원은 CSS와 콘텐츠보다 낮은 우선순위를 갖는다. 그러므로 BigPipe는 페이지의 모든 pagelet이 보여질 때까지 자바스크립트 다운로드를 시작하지 않는다. 모든 pagelet의 자바스크립트가 비동기적으로 다운로드된 후에 pagelet의 자바스크립트 설치 코드가 실행된다. 물론 먼저 다운로드된 자바스크립트 코드가 먼저 실행된다.

이렇게 높은 병렬 시스템의 결과로 몇 개의 pagelet은 다른 단계에서 동시에 실행되기도 한다. 예를 들면, 브라우저는 세 개의 pagelet에 대한 CSS를 다운로드하면서 다른 pagelet의 콘텐트를 렌더링할 수 있다. 이때 서버는 다른 pagelet의 response를 생성하고 있을 수 있다. 사용자 관점에서는 페이지는 순차적으로 렌더링된다. 페이지의 처음 부분을 이른 시간에 보여줄 수 있어 페이지의 지연 시간을 드라마틱하게 향상시킨다. 이런 차이점을 확인하고 싶다면 다음 두 개의 링크를 방문해 보라. Traditional model과 BigPipe. 첫 번째 링크는 전통적인 한 개의 flush 모델을 사용하여 페이지를 렌더링한다. 두 번째 링크는 BigPipe의 파이프라인 모델을 사용하여 페이지를 렌더링한다. 두 개 페이지의 로딩 시간 차이는 오래된 버전의 브라우저를 사용하거나 네트워크 속도가 느리거나, 브라우저 캐시가 오염되었을때 더 극명하게 벌어진다.

Performance results

아래 그래프는 75%의 사용자가 페이지에서 가장 중요한 콘텐트(news feed는 페이스북 홈페이지에서 가장 중요한 콘텐트로 취급된다)를 보는데 전통적인 모델과 BigPipe 모델에서 걸리는 지연시간을 비교한 자료이다. 이 데이터는 콜드(cold) 브라우저 캐시를 가진 브라우저를 사용하여 페이스북 홈페이지를 50번 로딩하는 방법으로 수집하였다. 이 그래프는 BigPipe가 사용자가 인식하는 지연시간을 대부분의 브라우저에서 반으로 줄여줌을 보여준다.

페이스북의 홈페이지와 상호작용하는 지연시간

BigPipe가 마이크로프로세서의 파이프라인 방식에서 고안되었음은 말할 필요도 없지만, BigPipe에 의해 수행되는 파이프라인과 마이크로프로세서의 파이프라인과는 약간의 차이점이 있다. 예를 들면, BigPipe의 대부분의 단계가 한 번에 하나의 pagelet에서만 동작하지만 CSS와 자바스크립트 다운로드와 같은 어떤 단계에서는 동시에 여러 개의 pagelet에서 수행되기도 한다. 이는 수퍼스칼라 마이크로프로세서와 유사하다. 다른 중요한 차이점은, BigPipe에서는 병렬 프로그래밍에서 차용한 'barrier' 개념을 사용한다.

notepad++ 실행파일 설정

2011-03-15T17:57:00.000-07:00

notepad++\plugins\Config\npes_saved.txt
::JAVA Compile
cmd /c cd "$(CURRENT_DIRECTORY)" && "javac" "$(FULL_CURRENT_PATH)"
::JAVA Run
cd $(CURRENT_DIRECTORY)
cmd /k cd $(CURRENT_DIRECTORY) && "java" "$(NAME_PART)" && exit
::C#2.0 Compile
cd $(CURRENT_DIRECTORY)
cmd /k cd $(CURRENT_DIRECTORY) && "C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\csc.exe" "$(FULL_CURRENT_PATH)" && exit
cmd /k $(NAME_PART) && exit

notepad++\plugins\Config\NppExec.ini
[Console]
Visible=0
ShowHelp=0
Encoding=17
SaveOnExecute=0
CmdHistory=1
SaveCmdHistory=1
NoInternalMsgs=0
TextColorNormal=0(6)
TextColorError=A01010
TextColorMessage=208020
BackgroundColor=00
[Restore]
LastSelectedScript=1
[UserMenu]
NppMacrosSubmenu=1
0="JAVA Compile :: JAVA Compile"
1="JAVA Run :: JAVA Run"
2="C#2.0 Compile :: C#2.0 Compile"

ODP.NET를 이용한 오라클과 C#연동 샘플

2010-11-12T21:01:00.000-08:00

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using Oracle.DataAccess.Client;

namespace Oracle
{
class Class1
{
static void Main(string[] args)
{
try
{
string connstring =
"Data Source=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=ora-002.cafe24.com)(PORT=1521))" +
"(CONNECT_DATA=(SID=orcl)));User Id=myID;Password=myPWD;";
using (OracleConnection conn = new OracleConnection(connstring))
{
conn.Open();
Console.WriteLine("접속 성공");
string sql = "select test from testdb";
using (OracleCommand comm = new OracleCommand(sql, conn))
{
using (OracleDataReader rdr = comm.ExecuteReader())
{
while (rdr.Read())
{
Console.WriteLine(rdr.GetString(0));
Console.ReadLine();
}
}
}
}
}
catch
{
Console.WriteLine("접속 실패");
}
}
}
}

자바스크립트 산술 오류

2010-11-04T03:18:00.000-07:00

자바스크립트에서 산술오류가 난다는 것은 왠만한 웹개발자들이라면 익히 알고 있습니다.

다음 예제 소스를 보시죠.

<html>
<head>
<script language='javascript'>
   function test(){
      var a= 20.31;
      var b=100;

      alert("js:" + a*b );
      alert("vb:" + vbs(a,b));

   }
</script>
<script language=vbscript>
   function vbs(a, b)
      vbs = a*b
      msgbox(vbs)
   end function
</script>

</head>
<body>
   <input type="button" value="javascript" onclick="test()" >
</body>
</html>

위의 소스는 VB스크립트와 자바스크립트의 연산작동을 비교한것입니다.

자바스크립트에서 출력할때는

js:2030.9999999999997

vb:2030.9999999999997

라고 나오죠. 그럼 VB스크립트에서 찍은 값은 어떻게 나올까요?

네. 2031 이라고 나옵니다.

이게 맞는거죠.

테스트를 IE에서 해서 그런지는 모르겠지만 VB스크립트가 정확한 답을 줍니다.

오페라나 파이어폭스,구글크롬에서는 VB스크립트가 작동하지 않네요.

어쨋든 자바 스크립트 안에서만 이런 오류가 난다는 것은 무언가 문제가 있다는 것인데 수정이 되질 않고 있습니다.

그래서 다시 수정해야합니다. 다음과 같이 말이죠.

<html>
<head>
<script language='javascript'>
function test(){
var a= 20.31;
var b= 100;
var c = a*b;
d= c.toFixed(0);

alert("js:" + d );
alert("vb:" + vbs(a,b));

}
</script>
<script language=vbscript>
function vbs(a, b)
vbs = a*b
msgbox(vbs)
end function
</script>

</head>
<body>
<input type="button" value="javascript" onclick="test()" >
</body>
</html>

굵은 부분이 수정된 부분입니다.

js:2031

vb:2030.9999999999997

위와 같이 출력됩니다. VB스크립트는 아무런 조치를 취하지 않았습니다.

비교를 해보기 위해서요.

밑의 VB스트립트는 2031 이라고 내뱉는군요. 정확하게...

문제가 있죠. 값이 가변적으로 변할때는 위의 조치 보다

좀더 많이 힘들어 진다는 겁니다.

요건 근본적으로 해결이 안되는 걸까요?

빠른 시간내에 해결되기를 기대합니다.

ksc5601로 된 오라클 데이터를 php에서 불러오기

2009-11-15T01:15:00.000-08:00

별거없습니다.

iconv 를 설치 하여 불러올수만 있으면 됩니다.

iconv('CP949' ,'utf-8', OCI_Result($stmt,"SEQNO"));

이런식으로..

여기서 중요한건 불러오는 연동 문제가 아니었습니다.

오라클의 캐릭터셋이 American의 KSC5601로 된 경우 어쩐 일인지 불러오질 못하더군요.

데이터가 모두 깨집니다...

UTF8과 EUC-KR로 해도 깨집니다.

아무리 불러서 연동시켜봐도 안되더군요.

한잠을 헤매다가 발견한 사실 하나는 KSC5601가 'CP949' 로 불어와 진다는 사실입니다.

사용해 봤더니 되더군요.... 참 머쓱한 순간이 아닐수 없습니다..

무슨 문제가 있는지 모르지만 어쨌든 불러오기 성공입니다....

헤....^_________^

날짜 수 계산

2009-11-15T01:01:00.000-08:00

//날짜 수 계산 함수

function fn_getDateDegree(){
var DgreeDate =cld_from.Value;

for(var i=0; i < 100; i++){
DgreeDate = Adddate( DgreeDate ,1);

   if( DgreeDate == cld_to.Value ){
   return i+1 ;
break ;
   }
   }
}

루비 스크립트를 실행 파일(EXE)로 배포하기

2009-11-15T00:58:00.000-08:00

예전에 어디선가 제가 자료를 모으는 와중에 가져온거 같습니다.

어느분이 쓴건지는 모르겠지만 유용한 팁 글이라 올려 놓습니다.

혹시 출처를 아시는 분이 있다면 알려주시기 바랍니다.

루비로 정말 유용한 프로그램을 만들어서 다른 사람들도 쓸 수 있도록 배포를 하고자 할 경우가 있다. 사용자의 PC에 이미 루비가 깔려 있다면 배포는 비교적 쉽다. 소스를 압축하여 배포하거나, 근래에 커뮤니티에서 인기를 끌고 있는 gem등의 형태로 패키지를 만들어서 배포할 수 있다. 하지만 루비가 깔려있는 PC에는 먼저 루비를 깔라고 해야 할까?

추천할 만한 방법은 루비 인터프리터를 포함한 하나의 실행 파일(EXE)를 만들어서 배포하는 것이다. 다행스럽게도 exerb를 이용하면 간단하게 EXE 파일을 생성할 수 있다.

Exerb는 루비 1.8.1을 지원하는 3.3 버전을 홈페이지에서 내려 받을 수 있다. 설치는 setup.rb 스크립트를 실행함으로써 가능하다. (자세한 설치 방법은 README.en 참조)

간단한 예제

1. EXE로 변환할 루비 파일(foo.rb)을 준비하자.

2. 먼저 recipe 파일을 만들어준다. mkexr 스크립트가 자동으로 exr을 만들어준다.

ruby -r exerb/mkexr foo.rb

3. 생성된 foo.rb.exr 파일을 입맛에 맞게 수정한다. 자세한 명령어에 대한 설명은 doc/recipe.en.rd를 참조하면 된다. 여기서는 자동으로 생성된 exr 파일에 set_out_filepath 명령을 사용하여 생성될 EXE 파일의 이름을 정해준다. 그리고 set_core_by_name 명령을 이용하여 코어를 선택한다. 기본 코어는 cui이지만, 이 경우 콘솔창이 뜨는 불편함이 있기 때문에 나는 gui를 선호한다.

set_core_by_name	gui

set_out_filepath	Foo.exe

4. exerb를 이용해서 EXE를 실행한다.

ruby exerb foo.rb.exr

5. Foo.exe를 실행해서 테스트 한다.

그 외에

이런 커맨드가 어렵다고 생각하는 사람을 위해 Win32 GUI Client도 지원하고 있다. (하지만 그냥 커맨드라인 툴을 사용하는 것이 더 쉽다는 생각이 든다.)

자바-MySQL 연결

2009-11-15T00:56:00.000-08:00

public static String toMySQL(String strStr){

try{

if (strStr != null)

return new String(strStr.getBytes("KSC5601"), "8859_1");

else

return null;

} catch (Exception e) {

e.printStackTrace();

return null;

}
}

에디트플러스에서 루비 설정

2009-10-16T06:14:00.000-07:00

그전에 루비는 먼저 설치 해야한다는 겁니다...

설치를 했다는 것을 전제로 삼고 해보죠.

요거슨 내 에디트플러스의 버전입니다.. 3.0이상 이기를 바랍니다..

메뉴 박스 중 도구을 열어서 사용자 도구 구성을 클릭하여 다음과 같이 만듭니다.

저장하고 확인한 다음 루비 프로그램을 돌려 확인 합니다.

끝~

cygwin 삭제

2009-08-28T00:42:00.001-07:00

1. cygwin을 종료
2. 시작 > 실행 에서 regedit 입력 실행 후
- HKEY_CURRENT_USER\Softeare\Cygnus Solutions
- HKEY_LOCAL_MACHINE\Softeare\Cygnus Solutions 레지스터 폴더 삭제
3. Cygwin 디렉토리를 옮기거나 삭제 가능
[출처] Cygwin 삭제작성자 yohanyooo

파이어폭스 DB만 정리해도 속도 빨라져

2009-07-19T21:31:00.000-07:00

파이어폭스를 오래 사용할수록 북마크, 히스토리 등을 저장하는 SQLite 데이터베이스가 커져만 가는데요. 특히 3.0 버전 이후 히스토리와 북마크를 적극 활용하는 주소표시줄의 방문 기록 저장 기간이 기본 9일에서 90일로 늘어나면서 데이터베이스 덩치가 더욱 커졌습니다.

또 어떤 데이터베이스나 다 그렇겠지만 SQLite 데이터베이스도 시간이 지날수록 조각화가 심해지고 사용하지 않는 공간이 늘어나기 때문에 주기적으로 이 데이터베이스를 정리해주면 파이어폭스 시작 시간이나 RSS, 주소표시줄 같은 북마크, 히스토리 관련 작업이 한결 빠르고 가벼워집니다.

1. 먼저 SQLite3를 다운로드 합니다. (윈도용, 매킨토시용, 리눅스용)

2. 압축을 푼 SQLite3 실행 파일을 파이어폭스 프로필 폴더로 복사합니다. 프로필 폴더 위치는 운영체제에 따라 다음과 같습니다.

윈도XP, 2000 : C:\Documents and Settings\Application Data\Mozilla\Firefox\Profiles\ (%APPDATA%\Mozilla\Firefox\Profiles\) 윈도 비스타, 7 : C:\USERS\APPDATA\ROAMING\MOZILLA\FIREFOX\PROFILES\ MAC OS X : ~/Library/Mozilla/Firefox/Profiles/ 또는 ~/Library/Application SUPPORT/FIREFOX/PROFILES/ 유닉스 : ~/.mozilla/firefox/ 3. 파이어폭스를 종료합니다.
드디어 등장한 파이어폭스 3.5

4. 프로필 폴더에서 명령 프롬프트를 열어 다음 명령을 입력합니다. 마이크로소프트 Powertoy의 하나인 CmdHere(설치하기 클릭)를 설치하면 마우스 우클릭 메뉴에서 편리하게 명령 프롬프트를 열 수 있습니다.

특정 sqlite 파일을 최적화하는 명령입니다. 예) sqlite3 place.sqlite VACUUM
이렇게 덩치가 커진 sqlite 파일을 하나하나 최적화 해줘도 되지만 아래 명령을 입력하면 한번에 윈도 프로필 폴더 내의 모든 sqlite 파일의 최적화가 가능합니다. 스크립트로 만들어서 윈도 시작 시 자동으로 실행되게 만들어 놓으면 편리하겠죠.
for %a in (*.sqlite) do (sqlite3 %a vacuum)
맥 OS X
cd ~/Library/Application\ Support/Firefox/Profiles/for f in */*.sqlite; do sqlite3 $f 'VACUUM;'; done리눅스
for f in ~/.mozilla/firefox-3.5/*/*.sqlite; do sqlite3 $f 'VACUUM;'; done참고로 명령 프롬프트가 불편한 분들은 BleachBit을 이용해 보세요. 다양한 애플리케이션의 찌꺼기를 제거하는 프로그램이지만 파이어폭스 Vacuum 기능도 제공하고 있습니다. Vacuum에 체크하고 상단의 delete 버튼을 누르면 간단하게 SQLite 데이터베이스를 최적화 합니다. BleachBit은 윈도와 리눅스를 지원합니다.
BleachBit 다운로드 (윈도용)

net3.0

2009-07-16T22:05:00.001-07:00

Windows Vista가 드디어 RTM 버전까지 발표가 되었다.

닷넷 프레임워크 3.0도 Vista에 종속적이기 때문에 Windows Vista와 더불어 RTM 버전이 발표된 것이다. 그럼 Windows Vista와 닷넷 프레임워크 3.0은 어떤 관계를 가지고 있는지 또한 닷넷 프레임워크 3.0의 구조는 어떻게 되었는지 이번 강의에서 살펴볼 것이다, 더불어 WCF의 정의와 기본적인 아키텍쳐를 살펴 보도록 하겠다.닷넷에 열정을 가지고 여러 세미나에 두루 참석하거나 MS에서 발표한 기술자료를 열심히 살펴 본 독자라면 WinFX라는 코드명을 들어 본 적이 있을 것이다. 얼마전 WinFX는 닷넷 프레임워크 3.0으로 이름을 바꾸고 이제는 사용되지 않는 명칭이다. 다음 그림은 새롭게 발표된 닷넷 프레임워크의 구조다. (이 그림은 초창기 닷넷 3.0이 발표될 당시의 그림으로 WCS로 표기가 되어 있지만 실제로 WCS는 사용하지 않고 Card Space라는 명칭을 사용한다)예 전에 WinFX는 닷넷 2.0 기반에서 작동하게 된다고 소개해왔다. 하지만 닷넷 프레임워크3.0은 WPF, WCF, WF, CardSpace라는 새로운 기술들이 추가돼 더 완벽한 프레임워크로 변모했다. 닷넷 프레임워크가 동작하는 환경은 다음과 같다.

● Windows Vista
● Windows "Longhorn" Server
● Windows XP SP2, Windows Server 2003 SP1, Windows Server 2003 R2
새롭게 발표되는 비스타나 Longhorn 서버에서는 닷넷 프레임워크3.0이 장착되어 있다. XP에서는 서비스 팩3에서 지원 될 예정이라고 한다. 비스타의 출시는 Win95 이래로 가장 큰 런칭이 된다. 무엇보다도 사용자 경험의 새로운 변화가 그 어느 때 보다 크다. 윈도우2000을 사용해 왔던 사용자가 윈도우 XP를 다루는 것은 큰 어려움이 없었지만 윈도우 Vista는 그렇지 않다. 새로운 사용자 경험이 크게 변화된 것 뿐만 아니라 가젯과 같은 새로운 개념들이 도입되기 때문이다. 윈도우 비스타에는 기본적으로 닷넷 프레임워크 3.0이 설치되어 있다. 만약 윈도우 비스타의 세대가 도래하게 되면, 그동안 번거로웠던 닷넷 프레임워크의 배포 문제가 해결될 것이다. 또한 그만큼 닷넷 개발자들을 많이 필요로 하게 될 것이며, 그만큼 닷넷 프로그래머의 가치는 높아질 수밖에 없다. 그렇기 때문에 닷넷 개발자들은 윈도우 Vista를 기대해야 된다는 것이다.[Windows Vista의 모습]
필자 메모주 위의 개발자들을 보면 닷넷 프레임워크3.0의 탄생을 시련으로 받아들이는 개발자가 많이 있다. Microsoft사의 .NET을 사용하고 있는 개발자라면 지금의 현실이 다소 혼란스럽고 어려운 시기일지도 모른다. 이유는 닷넷2.0이 탄생한지 1년채 지나지 않아서 닷넷 3.0의 정식 발표가 될 예정이기 때문이기도 하다. 하지만 .NET을 주된 업으로 삼아 개발하고 있고, 적어도 자신의 가치를 인정받는 개발자가 되기를 원한다면 발 빠르게 움직여 변화를 대비해야 할 것이다. 개발자는 생각과 동시에 실천이 이루어져야 한다. 즉, 닷넷 프레임워크3.0 개발 환경을 설정해보고 .NET 3.0관련 기술 문서나 실행 예제를 보면서 한 번쯤은 실행해 보라는 것이다. 닷넷 3.0을 설치하는데 큰 공수가 드는 것이 아니고, 예제를 실행하는데도 크게 어려울 것이 없다. 단지, 이걸 알고 있으면서도 움직이거나 움직이지 않거나의 차이가 되는 것이다. 일찍 일어나는 새가 먹이를 먼저 잡듯이 먼저 발 빠르게 대응하고 있는 개발자에게 기회는 반드시 더 많이 찾아오기 마련이다.
새롭게 추가된 기술
닷넷 프레임워크 3.0에 새롭게 추가된 기술들을 간단하게 요약해 보도록 하겠다. 단 WCF는 이번 강의실에서 상세하게 알아볼 것이기 때문에 WPF, WF, CardSpace만 설명 하도록 하겠다.
WPF(Windows Presentation Foundation)
WPF는 닷넷 프레임워크의 가장 최전방에 있는 UI 기술이다. 윈도우 비스타는 기본적으로 3D 기반에서 동작이 된다. 그렇기 때문에 당연히 비스타 환경을 충족 시켜줄 수 있는 개발도구가 필요 할 것이다. 바로 WPF가 UI의 혁명적으로 등장한 3D 개발 기술이다. <화면 2>는 WPF를 실행한 화면이다. 이렇게 화려한 UI를 가지고 있는 기술이 바로 WPF이다. WPF는 XAML이라는 XML을 이용해서 UI를 정의하고, 코드는 CS로 작성하게 된다.
WF(Windows Workflow Foundation)
WF는Windows Workflow Foundation의 약자이다. 그럼 Workflow는 무엇인가? 이 개념을 잘 알고 있다면 WF를 이해하기 쉬울 테지만, 개발자들이 쉽게 이해하고, 적용할 수 있는 개념은 아니다. Workflow는 ‘작업 흐름’이라는 의미를 가지고 있다. 쇼핑몰을 예를 들어 보겠다. 물건이 거래가 되기 위해서는 물건을 구매하고, 입금을 확인하고, 배송을 하고, 배송확인을 받는 순서를 거쳐야 한다. 이러한 쇼핑물의 흐름이 바로 Workflow가 되는 것이다. WF는 이러한 작업 흐름을 간단하게 디자이너로 드래그 & 드랍으로 구현할 수 있다. <화면 3>에서 Visual Studio.NET에서 WF를 이용해 Workflow를 구축하고 있다.
WF 로 작업을 하면 Workflow를 명확하게 정의 할 수 있다. 또한 Workflow가 변경 되었을 때 코드를 수정하지 않아도 간단하게 드래그 만으로 작업 흐름을 수정할 수 있기 때문에 쉽게 유지 보수를 할 수 있다는 특징을 가지고 있다고 보면 될 것이다.
Windows CardSpace
얼마전 한 컨퍼런스에서 빌 게이츠는 "패스워드 시대의 종말이 올 것이다" 라는 선언을 했다. 그리고 그에 대한 해결책으로 ‘인포카드’를 소개했다. 인포카드의 개념은 온라인상에서 자신의 신원정보를 제시하는 하나의 인증수단이라고 볼 수 있다.
보통 대학교 도서관을 이용하려면 학생증과 같은 신원확인 카드를 가지고 신원확인을 한 후에 도서관을 이용할 수 있다. 도서관뿐만 아니라 그 학교의 학생을 증명하는 용도로 사용하게 된다. 인포카드는 바로 이러한 카드처럼 자신의 신상정보를 인포카드에 담아두고 온라인에서 요구하는 신원 인증을 통일해 보겠다는 것이다. 포탈 사이트에서 하나의 아이디만 갖고, 인증을 받으면 메일이나 카페, 블로그 등등 여러 서비스들을 동시에 인증을 받아서 사용할 수 있게 된다. 하지만 이건 포탈이라는 울타리 내에서만 가능할 뿐이다. 다른 포탈 사이트와 연계가 되는 것은 아니다. 하지만 인포카드는 전 세계의 웹을 통합해 보겠다는 당찬 시도를 하게 된 것이다. <화면 4>는 윈도우 비스타의 인포 카드를 캡쳐한 화면이다.
[비스타의 인포카드 인증화면]
MS는 이전에 패스포트로 온라인 계정을 통합해 보려고 했지만 실패한 전략이 되었다. 그리고 이번에 인포카드는 두 번째 시도가 되는 것이다. 그러면 Card Space는 무엇인가? WCS는 Windows CardSpace의 약자로 WCF를 이용해서 통신을 하는 부분을 담당하는 부분이 바로 이 Card Space가 된다.

개발 환경 설정하기
개발 환경을 설정해 보도록 하겠다. 필자가 책을 쓰고 있는 당시의 상황은 Visual Studio.Net 2005가 발표 되었고 닷넷 프레임워크 3.0은 베타만 나와 있는 상황이기 때문에 먼 훗날 개발환경 설정 방법이 달라 질 수 있다. 개발 환경을 설치 하기 위해서는 다음과 같은 프로그램을 차례대로 설치 하여야 한다. MS 다운로드 사이트에 가면 다음과 같은 프로그램들을 다운 받을 수 있을 것이다.
● .NET Framework 3.0 Setup.
● Windows SDK(Software Development Kit) Setup
● Development Tool for .NET Framework3.0 Setup

이 설치는 VS.NET 2005가 설치 된 후에 진행해야 된다. 주의할 점은 같은 버전의 개발Kit 들을 설치해야 한다. 예를 들어서 .Net Framework는 베타1인데 Windows SDK 는 베타2이거나 한다면 올바른 개발 환경을 설정할 수가 없다. 앞서서 진행한 WPF의 강좌에서도 설치 방법을 소개하고 있고, 많은 블로그들 에서도 이런 설치 하는 방법에 대해서 많이 설명을 해주고 있기 때문에 이번 강좌에서는 따로 소개하지 않는다.