posted by 희정냥★ 2012. 7. 13. 21:53

OSGI란?

네트워크상에 연결된 디바이스들이 다양한 서비스를 공유할 수 있도록 하는 자바 언어 기반의 동적인 플랫폼을 만들기 위해 Open Services Gateway initiative라는 이름으로 시작되었다.

이에 의거, OSGI는 기존의 자바 플랫폼이 제공하지 못하는 동적인 컴포넌트 모델을 지원하는 프레임워크라고 볼 수 있다.

OSGi 프레임워크는 아래와 같다.

 

 

1. Class Loading (Module) : OSGi의 근간이 되는 번들을 정의하는 레이어

2. Life Cycle : 번들이 어떻게 동적으로 설치되고 관리될 수 있는지를 정의하는 레이어

번들 내에서 어떻게 외부의 OSGi Context에 접근할 수 있는지를 정의한다.

3. Service : 서비스 레지스트리를 통해 서비스를 등록하고 찾을 수 있도록 지원하는 레이어

4. Security Layer : 자바의 보안 구조에 기반하고 있으며, 패키지나 서비스에 대한 권한을 관리하거나

Digitally Signed JAR파일에 대한 지원을 해주는 레이어

5. JVM(Execution Environment) : 번들이 실행될 수 있는 환경을 말하는 것으로 J2ME, J2SE등과

같은 환경들을 의미한다.

6. Bundles : 왼쪽 위에 있는 Bundles는 레이어 개념이 아닌 OSGi의 레이어를 통하여 작성되고,

프레임워크에 올려진 실제 번들을 의미하는 것으로, 개발자가 개발해서 프레임워크에

올리는 번들이 이 범주에 들어간다.

OSGi의 생명주기는 아래와 같다.

 

 

 

* 출처 : http://gy801110.blog.me/94693541

 

'Computer > Framework' 카테고리의 다른 글

OSGi  (0) 2012.07.13
Spring 시작  (0) 2008.10.08

댓글을 달아 주세요

posted by 희정냥★ 2012. 7. 12. 22:12

얼마나 많은 사용자가 동시에 여러분의 소프트웨어 시스템에 접속할 수 있는가? 성능 저하 없이 얼마나 많은 데이터를 로딩할 수 있는가? 시스템 작업량은 얼마나 되는가? 이런 요구사항들을 얼마나 자주 테스트하는가? 만약 여러분이 이러한 읽기와 성능 요구사항에 대해 최소한 하루에 한 번 기술할 수 있고 검증할 수 있다면 어떨 것 같은가? 로드 테스트를 정기적이고 자동화된 빌드의 일부로 만듬으로써, 특정 로드 조건에서 시스템 성능을 신속하게 판별할 수 있고 변화를 빠르게 수용할 수 있다.

본 연재에 대해

개발자로서, 우리는 고객의 프로세스를 자동화하기 위해 일한다. 하지만, 우리 대부분은 스스로의 개발 프로세스를 자동화할 수 있는 기회를 간과하곤 한다. 더 이상 그러지 않기 위해, 사람을 위한 자동화 연재를 기획하여 소프트웨어 개발 프로세스를 자동화하는 실용적인 사용법들과 자동화를 언제, 어떻게 성공적으로 적용하는지 설명하겠다.

필자가 일했던 곳에서 다수의 트랜잭션으로 동작하는 애플리케이션 로드 테스트를 할 수 있는 자동화된 테스트 집합을 마련한 적이 있다. 문제는 테스트들이 약간의 수동 조작을 필요로 했다. 따라서 개발팀은 사람이 개입하지 않으면 그것들을 실행할 수 없었다. 이로 인해 테스트 작업은 테스터가 참여할 수 있는 시간으로 제한되었다(보통 업무 시간에만 가용하다). 실제로, 테스트 작업은 일과 중 몇 번만 진행되었다. 매 시간 발생하는 문제를 찾아내기에는 부족했다.

이번 기사에서는 JMeter를 사용하는 자동화된 테스트 작성 기술, 자동화 빌드 일부로 해당 테스트 실행, 매일 자동으로 테스트를 실행하도록 스케쥴링하기(컴퓨터의 사용량이 낮을 때 실행하도록)를 설명할 것이다. 테스트를 일정 주기 빌드의 일부로 실행하는 것은 다음과 같은 장점을 준다.

  • 언제든지 로드 테스트를 실행할 수 있다.
  • 개발 프로세스 초기에 로드와 성능 문제를 발견하고 해결할 수 있다.
  • 빌드 서버에서 최신 성능/로드 테스트를 모니터링할 수 있다.
  • 테스트를 설정하고 실행하는 데 한 사람에게 의존할 때 생길지도 모르는 병목과 오류를 줄인다.

JMeter가 무거운 짐을 옮기도록 놔두기

아파치 JMeter는 오픈 소스 프로젝트로 서버에 상당량의 부하를 시뮬레이션하는 데 사용할 수 있다(JMember에 대한 자세한 내용은참고자료를 참조). JMeter의 방대한 문서에서는 많은 기능을 어떻게 사용하는지 설명하고 있으며 많은 예제를 보여주고 있다.

JMeter 실행하기

JMeter ZIP 파일(JMeter 다운로드 링크는 참고자료를 보라)을 다운로드하고 압축을 푼 다음, 커맨드 창을 열고 JMeter 압축을 푼 곳에서 cd bin을 입력하여 bin 디렉터리로 이동한다. bin 디렉터리에서, jmeter를 입력하여 JMeter 스윙 애플리케이션을 열면 그림 1과 같은 것을 볼 수 있다.


그림 1. JMeter GUI
테스트 계획을 세우기 위해 JMeter GUI 사용하기 

테스트 계획 세우기

예제를 사용하여 테스트 작성하기

JMeter는 많은 예제 계획과 스크립트들을 포함하고 있다. 처음부터 새로 테스트 계획을 세우지 말고 docs 디렉터리에 있는 예제를 이용해 프로젝트가 진행되는 것에 따라 테스트 계획을 점진적으로 구성하라. 부하와 성능 요구사항을 효과적으로 확인할 수 있는 테스트를 작성하는 데에는 학습이 많이 필요하다.

JMeter GUI를 사용해 테스트 계획을 작성할 수 있다. 다음과 같은 종류의 테스트 계획들이 JMeter에 포함되어 있다.

  • 웹 테스트 계획
  • 데이터베이스 테스트 계획
  • FTP 테스트 계획
  • LDAP 테스트 계획
  • Extended LDAP 테스트 계획
  • 웹 서비스 테스트 계획
  • JMS 점대점 방식 테스트 계획
  • JMS 토픽 방식 테스트 계획
  • 모니터링 테스트 계획
  • 리스너

각각의 테스트 계획은 XML 파일 형태로 .jms 확장자로 저장된다. 이렇게 바이너리가 아닌 포맷이기 때문에 나중에 계획을 편하게 바꿀 수 있다. JMeter의 XML 스키마를 따라 테스트 계획을 생성할 수도 있지만, GUI를 사용하면 작업이 훨씬 수월하다. 뒤에서, JMeter 설정 값을 매개변수화해 테스트를 실행하는 방법을 커스터마이징하는 예제를 살펴볼 것이다.

인건비를 절약하는 로드 테스트

테스트를 실행할 때 GUI를 사용하려면, 그것을 실행할 사람이 반드시 있어야 한다. 이로 인해, 병목 현상과 지식 편중을 야기할 수 있다. 테스트를 앤트(Ant) 빌드와 같이 자동화된 빌드를 통해 실행하면, JMeter 애플리케이션을 실행하지 않고도 JMeter 테스트를 실행할 수 있다. 더욱이, 매번 테스트를 똑같이 수행할 것이며 추가 작업 수당도 지불할 필요가 없다.

앤트를 사용하여 JMeter 테스트 다루기

필자가 GUI 소프트웨어 도구 사용법을 익혔을 때, 커맨드 라인에서 실행할 수 있는 어떤 유틸리티가 없는지 살펴보길 좋아했다. 같은 동작을 반복해서 하기 싫었기 때문이다. 예를 들어, 필자는 매번 JMeter 애플리케이션을 열고, File > Open을 선택하고, 파일을 열고, 하나 또는 그 이상의 테스트들을 실행한다. 필자는 이 행위들을 스크립트로 만들어 매번 같은 방법으로 실행한다. 운이 좋게도, 앤트 태스크가 JMeter를 대신하여 이런 다양한 일을 해준다. 부가적인 매개변수와 프로퍼티들을 넘겨줄 수 있음과 동시에 로드 테스트들을 실행한다.

예제 빌드 스크립트

JMeter 배포판의 extras 디렉터리에는 build.xml 예제 빌드 스크립트가 들어있다. 여기에 보면 JMeter 앤트 태스크를 사용하는 예제들이 들어 있다.

Listing 1에서, 필자는 앤트의 taskdef를 사용하여 JMeter 태스크를 정의했다. 그 이름을 jmeter라고 지었고 이를 앤트 스크립트 어디서든 참조할 수 있다. 이 스크립트를 사용하려면 반드시 ant-jmeter.jar 파일(참고자료에서 다운로드 링크 참조)을 앤트 클래스패스에 추가해야 한다.


Listing 1. 앤트에 JMeter 태스크 정의하기
<taskdef name="jmeter" classname="org.programmerplanet.ant.taskdefs.jmeter.JMeterTask"/>

Listing 2에 있는 예제 코드는 단일 BreweryTestPlan.jmx라는 JMeter 로드 테스트를 실행한다. 특정 디렉터리에 있는 모든 테스트를 실행하려면, 특정 파일 이름 대신에 간단하게 *.jmx라고 입력하면 된다. jmeter 태스크가 필요로 하는 속성들은 jmeterhome,testplan(s), 또는 resultlog resultlogdir이다(Listing 2에서는 resultlogdir이 보이지 않는데, resultlog를 사용했기 때문이다).


Listing 2. 앤트에서 JMeter 실행하기
<jmeter
  jmeterhome="${jmeter.home}"
  resultlog="${basedir}/target/JMeterResults.xml">
  <testplans dir="${basedir}/tests/load" includes="BreweryTestPlan.jmx"/>
</jmeter>

Listing 2에 있는 앤트 코드는 JMeterResults.xml이라는 결과물 파일을 생성하고 그 파일은 HTML 보고서를 만들 때 사용된다.

XSLT를 사용하여 보고서 렌더링하기

Listing 3처럼 JMeterResult.xml 파일을 xslt 앤트 태스크에 넣어주면, Listing 2에서 실행한 모든 JMeter 테스트에 대한 HTML 보고서를 생성할 수 있다. XSL 스타일 시트(jmeter-result-detail-report_21.xsl)는 JMeter의 extras 디렉터리에 있으며 JMeterResults 파일을 HTML 파일로 변환할 때 사용한다.


Listing 3. XSLT를 사용하여 JMeter HTML 보고서 생성하기
<xslt in="${basedir}/target/JMeterResults.xml"
  out="${basedir}/target/JMeterResults.html"
  style="${jmeter.home}/extras/jmeter-results-detail-report_21.xsl"/>

JMeter는 또한 로드 테스트들의 결과를 종합하여 보여주는 XSL 스타일시트 파일도 제공한다.

HTML로 보고서 살펴보기

그림 2는 Listing 3의 xslt 태스크를 사용하여 생성한 HTML 보고서 예제다. 각각 실행한 로드 테스트와 함께 테스트 상태, 시간 그리고 모든 테스트의 상태와 시간을 묶어 보여준다.


그림 2. JMeter HTML 보고서 생성하기
JMeter HTML 보고서 생성하기 

본 기사의 뒤에서, 이 보고서들을 어떻게 CruiseControl Continuous Integration(CI) 서버(참고자료 참조)에서 볼 수 있는지 설명할 것이다.

JMeter에 매개변수 넘기기

실행하는 테스트의 종류에 따라, 매개변수와 프로퍼티를 넘겨 단일 테스트나 테스트 묶음을 다양한 방법으로 실행하고 싶을 것이다. 예를 들어, Listing 4는 JVM 메모리를 늘리는 방법과 순회할 스레드 개수를 설정하는 방법을 보여준다.


Listing 4. 부가적인 매개변수와 프로퍼티를 JMeter에 넘겨주기
<jmeter
  jmeterhome="${jmeter.home}"
  resultlog="${basedir}/target/JMeterResults.xml">
  <jvmarg value="-Xincgc"/>
  <jvmarg value="-Xmx128m"/>
  <jvmarg value="-Dproperty=value"/>
  <property name="request.threads" value="5"/>
  <property name="request.loop" value="50"/>
  <property name="jmeter.save.saveservice.assertion_results" value="all"/>
  <property name="jmeter.save.saveservice.output_format" value="xml"/>
  <testplans dir="${basedir}/tests/load" includes="BreweryTestPlan.jmx"/>
</jmeter>

JMeter가 테스트를 어떻게 실행할지와 관련된 많은 내장 매개변수와 프로퍼티들이 가용하다(더 많은 정보는 참고자료 참조).

매개변수와 프로퍼티를 사용하여 로드 테스트를 어떻게 실행할지에 대해 어느 정도 유연함을 줄 수 있다. 그러나 그것으로는 테스팅이나 스테이징 같은 서로 다른 대상(target) 환경에서 로드 테스트를 어떻게 실행할 것인지 하는 문제는 해결하지 못한다. 환경에 특화된 정보를 테스트 계획에 추가하려면, jmx 파일들 안에 토큰을 추가하여 로드 테스트가 자동화된 빌드 스크립트에서 실행될 때 그것들을 필터링하고 수정할 수 있도록 해야 한다.

Just-in-time 로드 테스팅

자동화된 빌드로 로드 테스트를 실행할 수 있게 되었다면, 이제 밤과 같이 일정 주기마다 실행하도록 스케쥴링을 하자. 이때 CI 또는 빌드 관리 서버를 사용할 수 있다.

CruiseControl을 스케쥴링하여 매일 로드 테스트 실행하기

CI 서버 사용 목적은 프로젝트의 버전 관리 저장소에 변경이 있을 때마다 자동으로 빌드를 실행하기 위함이다. 물론 빌드를 특정 시간에 실행하도록 설정할 수도 있다. 로드 테스트는 보통 많은 리소스를 필요로 하기 때문에, 테스트를 실행하는 시점에 자원이 충분히 가용해야 한다. 따라서 늦은 밤이나 이른 아침이 효율적일 것이다.

Listing 5에 보면, 자동화된 빌드를 11:00 PM(2300)에 실행하도록 CruiseControl(참고자료 참조)에 스케쥴링되어 있다. CruiseControl 설정 파일을 수정하여 run-load-tests와 같이 특정 앤트 타겟들을 실행하도록 설정할 수 있다.


Listing 5. CruiseControl을 사용하여 로드 테스트를 일정 시간마다 실행하기
  ...
  <modificationset>
    <svn RepositoryLocation="${svnrepo.location}"/>
    <timebuild username="admin" time="2300"/>
  </modificationset>
  ...

Listing 5와 같이 로드 테스트를 밤에 실행함으로써, 작업부하, 쉬는 날 또는 테스트 실행 잊어버리기에 대해 불평을 듣지 않아도 된다. 그래도 돌아갈테니 말이다.

CruiseControl에서 보고서 보여주기

여러분은 이미 앤트를 사용하여 JMeter 테스트 보고서를 보는 방법을 살펴보았다. JMeter 보고서는 단일 머신의 개발자 한 명에게만 의사소통을 하는 한계가 있다. 로드 테스트는 전체 애플리케이션에 영향을 주고, 따라서 팀 전체가 그 결과를 보고 싶어할 것이다. 매우 쉽게 CI 서버를 설정하여 이 보고서를 보여주도록 할 수 있다. 보고서는 이미 앤트가 만들어 두었기 때문에, JMeter HTML 보고서를 CruiseControl 프로젝트 대시보드에서 접근할 수 있게만 하면 된다. CruiseControl의 config.xml 파일에 몇 줄만 추가하면 그렇게 할 수 있다. Listing 6을 참조하라.


Listing 6. CruiseControl에 JMeter 보고서 설정하기
<project name="brewery">
...
<log>
  <merge dir="merge dir="projects/${project.name}/reports/jmeter" />
</log>
...
</project>

이제, 팀원 모두가 같은 페이지를 볼 수 있다. 다수의 다른 CI와 빌드 관리 서버들도 이와 비슷한 보고서 통합 기능을 지니고 있다.

결론

필자는 자동화된 로드 테스트를 개발 도구에 추가하는 방법을 설명했다. 로드 테스트를 자동화된 빌드로 실행하고 테스트를 주기적으로 실행하도록 설정함으로써, 문제가 되기 전에 시스템 역량 이슈에 대해 알 수 있게 되었다. 이런 접근 방법은 아키텍처의 핵심에 접근이 쉽고 데이터 변경을 쉽게 해준다. 본 기사 연재에서 설명한 다른 기술들과 함께 사용하면, 개발 팀이 더 품질 좋은 소프트웨어를 빠르게 개발하게 할 수 있을 것이다.


다운로드 하십시오

설명이름크기다운로드 방식
이 글의 예제 앤트 스크립트j-ap04088-jmeter-example.zip6KBHTTP

다운로드 방식에 대한 정보


참고자료

교육

제품 및 기술 얻기

  • 앤트: 앤트를 다운로드하고 예측 가능하며 반복 가능한 방법으로 소프트웨어를 개선하라.

  • JMeter: JMeter를 다운로드하라.

  • JMeter 앤트 태스크:JMeter 테스트 계획을 실행하기 위한 앤트 태스크

  • CruiseControl: CruiseControl Continuous Integration 서버를 다운로드하라.

  • IBM 제품 평가판을 다운로드하고 애플리케이션 개발 도구와 DB2®, Lotus®, Rational®, Tivoli®, WebSphere®의 미들웨어 제품들을 사용하라.

토론

필자소개

Paul Duvall

Paul Duvall은 컨설팅 회사이자 개발 팀을 애자일 소프트웨어 제작에 최적화하는 데 있어 선구자적인 역할을 하는Stelligent Incorporated의 CTO다. Paul Duvall은 Addison-Wesley Signature Series Book인 Continuous Integration: Improving Software Quality and Reducing Risk(Addison-Wesley, 2007)의 공동 저자다. 또 UML 2 Toolkit(Wiley, 2003)과 No Fluff Just Stuff Anthology(Pragmatic Programmers, 2007)에도 기여하였다.

아티클 순위

'Computer > Testing' 카테고리의 다른 글

JMeter Ant  (1) 2012.07.12

댓글을 달아 주세요

  1. Klee 2012.07.24 16:11  Addr  Edit/Del  Reply

    1등! ㅋ.

posted by 희정냥★ 2012. 7. 7. 15:04


n
         
쿠키란?

ü        쿠키란 서버측에서 클라이언트측에 상태 정보를 저장하고 추출할 수 있는 메커니즘

ü        클라이언트의 매 요청마다 웹 브라우저로부터 서버에게 전송되는 정보패킷의 일종

ü        HTTP에서 클라이언트의 상태 정보를 클라이언트의 하드 디스크에 저장하였다가 필요 시 정보를 참조하거나 재사용할 수 있음.

ü        사용 예

       방문했던 사이트에 다시 방문 하였을 때 아이디와 비밀번호 자동 입력

       팝업에서 오늘 이 창을 다시 보지 않음” 체크

ü        쿠키의 제약조건

       클라이언트에 총 300개까지 쿠키를 저장할 수 있다

       하나의 도메인 당 20개의 값만을 가질 수 있다

       하나의 쿠키 값은 4096Byte까지 저장 가능하다


하나의 도메인에서 설정한 쿠키값이 20개를 초과하면 가장 적게 사용된 쿠키부터 지워짐또한 쿠키는 기존에 설정한 값이 있는 곳에 값을 저장하거나 배열형태의 쿠키에 단일 값을 저장하려고 할 때 아무런 경고 없이 덮어쓰기 때문에 주의를 해야 한다.


n         세션이란?

ü        세션이란 클라이언트와 웹서버 간에 네트워크 연결이 지속적으로 유지되고 있는 상태를 말함

ü        클라이언트가 웹서버에 요청하여 처음 접속하면 JSP(혹은ASP)엔진은 요청한 클라이언트에 대하여 유일한 ID를 부여하게 되는데이 ID를 세션이라 부른다

ü        세션 ID를 임시로 저장하여 페이지 이동 시 이용하거나클라이언트가 재 접속 했을 때 클라이언트를 구분할 수 있는 유일한 수단이 된다

ü        세션의 장점

       각각의 클라이언트마다 고유의 ID 부여

       세션 객체마다 저장해 둔 데이터를 이용하여 서로 다른 클라이언트의 요구에 맞게 서비스 제공

       클라이언트 자신만의 고유한 페이지를 열어놓아서 생길 수 있는 보안상의 문제 해결 용이


n         쿠키와 세션의 차이점

 쿠키(cookie)와 세션(session)은 기능상 비슷한 역할을 하고동작원리도 비슷하다왜냐하면일반적인 세션은 쿠키를 바탕으로 동작하기 때문이다그러나 가장 중요한 차이점은 저장되는 곳이 다르다는 것이다쿠키는 클라이언트에 저장되고세션은 서버에 저장된다쿠키의 경우에는 서버의 자원을 전혀 사용하지 않지만세션의 경우에는 서버에 저장되기 때문에 서버의 자원을 사용할 수가 있다쿠키와 세션의 만료 되는 기간도 다르다.


n         쿠키와 세션의 차이점()

구분

쿠키

세션

저장 위치

클라이언트

서버

저장 형식

텍스트형식

Object 

종료 시점

쿠키 저장 시 설정(설정하지 않으면 브라우저 종료 시 소멸)

정확한 시점을 알 수 없다

     

클라이언트의 자원을 사용

서버의 자원을 사용

용량 제한

한 도메인 당 20쿠키 하나 당 4KB,  300

서버가 허용하는 한 용량에 제한이 없음

 


* 출처 : http://cacung82.blog.me/10035514681

'Computer > Web' 카테고리의 다른 글

쿠키, 세션  (0) 2012.07.07
CSS3 미디어 쿼리  (0) 2012.07.07
반응형 웹(Responsive Web)  (0) 2012.07.07
구글 페이지랭크(PageRank) 알고리즘  (0) 2012.07.06
HTML5 WebStorage  (1) 2012.06.30
HTML5 주요기술  (0) 2012.06.29

댓글을 달아 주세요

posted by 희정냥★ 2012. 7. 7. 14:59

출력 장치의 여러 특징 가운데 일부를 참조하여 CSS 코드를 분기 처리함으로써 하나의 HTML 소스가 여러가지 뷰를 갖도록 구현할 수 있는 명세이다. 일반적으로 뷰포트 해상도에 따라 CSS 코드를 분기한다.

CSS 코드 내부에서 분기하는 방법

CSS 코드 내부에서 사용하는 미디어 쿼리의 기본적인 문법 예는 다음과 같다. 일반적으로 권장하고 널리 쓰이는 방식이다.

@media only all and (조건문) {실행문}

  • @media: 미디어 쿼리가 시작됨을 선언한다. @media, only, all, and, (조건문) 사이에 포함되어 있는 공백은 필수적이다.
  • only: only 키워드는 미디어 쿼리를 지원하는 사용자 에이전트만 미디어 쿼리 구문을 해석하라는 명령이며 생략 가능하다. 생략했을 때 기본 값은 only로 처리 된다. 생략해도 무방하므로 이 키워드는 일반적으로 작성하지 않는다. 이 자리에는 not 키워드를 사용할 수 있는데 뒤에 오는 모든 조건을 부정하는 연산을 한다.
  • all: all 키워드는 미디어 쿼리를 해석해야 할 대상 미디어를 선언한 것이다. all 이면 모든 미디어가 이 구문을 해석해야 한다. all 키워드 대신 screen 또는 print와 같은 특정 미디어를 구체적으로 언급할 수도 있다. all 키워드는 생략 가능하고 생략했을 때 기본 값은 all 으로 처리된다. 이 밖에도 다양한 미디어 타입(all, aural, braille, embossed, handheld, print, projection, screen, speech, tty, tv)이 있다. all, screen, print를 가장 널리 쓴다.
  • and: and 키워드는 논리적으로 ‘AND’ 연산을 수행하여 앞과 뒤의 조건을 모두 만족해야 한다는 것을 의미한다. 조건이 유일하거나 또는 only, all과 같은 선행 키워드가 생략되면 and 키워드는 사용하지 말아야 한다. and 대신 콤마 ‘,’ 기호를 사용하면 ‘OR’ 연산을 수행한다. ‘OR’ 연산은 나열된 조건 중에서 하나만 참이어도 {실행문}을 해석한다.
  • (조건문): 브라우저는 조건문이 참일때{실행문}을 처리하고 거짓일 때 무시한다. 조건문은 두 가지 이상 등장할 수 있다. 둘 이상의 조건문은 ‘and’ 키워드 또는 콤마 ‘,’ 기호로 연결해야 한다.
  • {실행문}: 일반적인 CSS 코드를 이 괄호 안에 작성한다. 브라우저는 (조건문)이 참일때 실행문 안쪽에 있는 CSS 코드를 해석한다.

CSS 코드 외부에서 분기하는 방법

조건문에 따라 별도의 외부 CSS 파일을 참조하여 분기하는 방법은 다음과 같다. 이 방식은 성능 최적화 측면에서 권장하지 않는다.

<link rel=”stylesheet” type=”text/css” media=”all and (조건A)” href=”A.css”>
<link rel=”stylesheet” type=”text/css” media=”all and (조건B)” href=”B.css”>

데스크탑 브라우저 사용자가 언제든 조건을 변경(예를 들면 창 크기를 조절해서 해상도를 바꿈)할 수 있기 때문에 웹 브라우저는 조건에 관계 없이 A.css 파일과 B.css 파일을 항상 요청한다. HTTP 요청을 불필요하게 두 번 발생시켜 이 페이지를 처음 로딩하는 사용자에게는 성능 저하의 원인이 된다. CSS 파일은 하나로 병합하고 CSS 코드 내부에서 조건 분기하는 방식을 권장한다.

미디어 쿼리 코드 템플릿

아래 코드는 모든 해상도를 커버하기 위한 미디어 쿼리 코드 템플릿이다. All, Mobile, Tablet, Desktop 으로 기기별 대응 코드를 분류 했지만 Liquid 레이아웃 기법을 사용하면 사실상 모든 해상도를 커버할 수 있다.

@charset “utf-8″;

/* All Device */
모든 해상도를 위한 공통 코드를 작성한다. 모든 해상도에서 이 코드가 실행됨.

/* Mobile Device */
768px 미만 해상도의 모바일 기기를 위한 코드를 작성한다. 모든 해상도에서 이 코드가 실행됨. 미디어 쿼리를 지원하지 않는 모바일 기기를 위해 미디어 쿼리 구문을 사용하지 않는다.

/* Tablet & Desktop Device */
@media all and (min-width:768px) {
사용자 해상도가 768px 이상일 때 이 코드가 실행됨. 테블릿과 데스크톱의 공통 코드를 작성한다.
}

/* Tablet Device */
@media all and (min-width:768px) and (max-width:1024px) {
사용자 해상도가 768px 이상이고 1024px 이하일 때 이 코드가 실행됨. 아이패드 또는 비교적 작은 해상도의 랩탑이나 데스크톱에 대응하는 코드를 작성한다.
}

/* Desktop Device */
@media all and (min-width:1025px) {
사용자 해상도가 1025px 이상일 때 이 코드가 실행됨. 1025px 이상의 랩탑 또는 데스크톱에 대응하는 코드를 작성한다.
}

조건문이 될 수 있는 특징들

width / height

뷰포트의 너비와 높이. 뷰포트의 크기는 HTML body 콘텐츠를 표시하는 영역으로 실제 스크린의 크기와는 다르다. 반응형 웹 구현시 가장 일반적으로 사용하는 조건이 된다.

  • Value: <length>
  • Applies to: visual and tactile media types
  • Accepts min/max prefixes: yes

Example:

@media all and (min-width:768px) and (max-width:1024px) { … } // 뷰포트 너비가 768px 이상 ‘그리고’ 1024px 이하이면 실행

@media all and (width:768px), (width:1024px) { … } // 뷰포트 너비가 768px 이거나 ‘또는’ 1024px 이면 실행

@media not all and (min-width:768px) and (max-width:1024px) { … } // 뷰포트 너비가 768px 이상 ‘그리고’ 1024px 이하가 ‘아니면’ 실행

device-width / device-height

스크린의 너비와 높이. 스크린은 출력 장치가 픽셀을 표시할 수 있는 모든 영역으로 일반적으로 HTML body 콘텐츠를 표시하는 뷰포트 보다 크다.

  • Value: <length>
  • Applies to: visual and tactile media types
  • Accepts min/max prefixes: yes

Example:

@media all and (device-width:320px) and (device-height:480px) { … } // 스크린 너비가 320px ‘그리고’ 높이가 480px 이면 실행

@media all and (min-device-width:320px) and (min-device-height:480px) { … } // 스크린 너비가 최소 320px 이상 ‘그리고’ 높이가 최소 480px 이상이면 실행

orientation

뷰포트의 너비와 높이 비율을 이용하여 세로 모드인지 가로 모드인지를 판단한다.

  • Value: portrait | landscape
  • Applies to: bitmap media types
  • Accepts min/max prefixes: no

Example:

@media all and (orientation:portrait) { … } // 세로 모드. 뷰포트의 높이가 너비에 비해 상대적으로 크면 실행

@media all and (orientation:landscape) { … } // 가로 모드. 뷰포트의 너비가 높이에 비해 상대적으로 크면 실행

aspect-ratio

뷰포트의 너비와 높이에 대한 비율. ‘너비/높이’ 순으로 조건을 작성한다. min/max 접두사를 사용하면 너비 값의 최소/최대 비율을 정할 수 있다.

  • Value: <ratio>
  • Applies to: bitmat media types
  • Accepts min/max prefixes: yes

Example:

@media all and (aspect-ratio:5/4) { … } // 뷰포트 너비가 5, 높이가 4 비율이면 실행

@media all and (min-aspect-ratio:5/4) { … } // 뷰포트 너비가 5/4 비율 이상이면 실행

@media all and (max-aspect-ratio:5/4) { … } // 뷰포트 너비가 5/4 비율 이하면 실행

device-aspect-ratio

스크린의 너비와 높이에 대한 비율. ‘너비/높이’ 순으로 조건을 작성한다. min/max 접두사를 사용하면 너비 값의 최소/대최 비율을 정할 수 있다.

  • Value: <ratio>
  • Applies to: bitmap media types
  • Accepts min/max prefixes: yes

Example:

@media all and (device-aspect-ratio:5/4) { … } // 스크린 너비가 5, 높이가 4 비율이면 실행

@media all and (min-device-aspect-ratio:5/4) { … } // 스크린 너비가 5/4 비율 이상이면 실행

@media all and (max-device-aspect-ratio:5/4) { … } // 스크린 너비가 5/4 비율 이하면 실행

color

출력 장치의 색상에 대한 비트 수. 출력 장치가 컬러가 아닌 경우 ’0′의 값에 대응한다.

  • Value: <integer>
  • Applies to: visual media types
  • Accepts min/max prefixes: yes

Example:

@media all and (color) { … } // 출력 장치가 컬러를 지원하면 실행

@media all and (color:0) { … } // 출력 장치가 컬러가 아니면 실행

@media all and (color:8) { … } // 출력 장치가 8비트 색상이면 실행

@media all and (min-color:8) { … } // 출력 장치가 8비트 이상 색상이면 실행

@media all and (max-color:8) { … } // 출력 장치가 8비트 이하 색상이면 실행

color-index

출력 장치가 색상 색인 테이블을 사용하는 경우 표현할 수 있는 색의 수. 출력 장치가 색상 색인 테이블을 사용하지 않으면 ’0′의 값에 대응한다. 현재 제대로 지원하는 브라우저가 없다.

  • Value: <integer>
  • Applies to: visual media types
  • Accepts min/max prefixes: yes

Example:

@media all and (color-index) { … } // 출력 장치가 색상 색인 테이블을 사용하면 실행

@media all and (color-index:0) { … } // 출력 장치가 색상 색인 테이블을 사용하지 않으면 실행

@media all and (color-index:256) { … } // 출력 장치가 256 색을 지원하면 실행

@media all and (min-color-index:256) { … } // 출력 장치가 256 이상 색을 지원하면 실행

@media all and (max-color-index:256) { … } // 출력 장치가 256 이하 색을 지원하면 실행

monochrome

출력 장치가 흑백인 경우 픽셀당 비트 수. 출력 장치가 흑백이 아니라면 ’0′의 값에 대응한다.

  • Value: <integer>
  • Applies to: visual media types
  • Accepts min/max prefixes: yes

Example:

@media all and (monochrome) { … } // 출력 장치가 흑백이면 실행

@media all and (monochrome:0) { … } // 출력 장치가 흑백이 아니면 실행

@media all and (min-monochrome:2) { … } // 출력 장치가 흑백이고 2비트 이상이면 실행

@media all and (max-monochrome:2) { … } // 출력 장치가 흑백이고 2비트 이하이면 실행

resolution

출력 장치의 해상력에 대응한다. min/max 접두사는 사각형 아닌 픽셀(인쇄 장치)에도 대응하지만 접두사 없는 resolution 조건은 사각형 픽셀에만 대응한다. 조건의 값으로 dpi와 dpcm 단위를 사용할 수 있다.

  • Value: <resolution>
  • Applies to: bitmap media types
  • Accepts min/max prefixes: yes

Example:

@media all and (resolution:96dpi) { … } // 1인치당 96개의 사각형 화소를 제공하면 실행

@media all and (min-resolution:96dpi) { … } // 1인치당 96개 이상의 화소를 제공하면 실행

@media all and (max-resolution:96dpi) { … } // 1인치당 96개 이하의 화소를 제공하면 실행

scan

TV의 스캔 방식에 따라 대응한다. progressive 값은 초당 60회 수준의 고화질 스캔에 대응하고 interlace 값은 초당 30회 수준의 일반 스캔에 대응한다. 대부분의 HDTV는 progressive와 interlace 방식을 모두 지원하고 있다.

  • Value: progressive | interlace
  • Applies to: “tv” media types
  • Accepts min/max prefixes: no

Example:

@media tv and (scan:progressive) { … } // 초당 60회 수준의 고화질 스캔 방식 TV에 대응한다

@media tv and (scan:interlace) { … } // 초당 30회 수준의 일반 스캔 방식 TV에 대응한다

grid

출력 장치가 그리드 방식이면 대응한다. 그리드 방식은 타자기와 같이 고정된 글꼴만 사용하는 장치이다. 통상 출력 장치는 비트맵이 아니면 그리드 방식이다. 값은 정수 ’0′과 ’1′ 뿐이고 ’0′의 값은 비트맵 방식에 대응한다.

  • Value: <integer> 0 | 1
  • Applies to: visual and tactile media types
  • Accepts min/max prefixes: no

Example:

@media all and (grid) { … } // 출력 장치가 그리드 방식이면 실행

@media all and (grid:0) { … } // 출력 장치가 그리드 방식이 아니면 실행

@media all and (grid:1) { … } // 출력 장치가 그리드 방식이면 실행


* 미디어 쿼리 속성 리스트

 width

 화면의 너비

 height

 화면의 높이

 device-width

 단말기의 너비

 device-height

 단말기의 높이

 orientation

 화면의 가로/세로 모드

 aspect-ratio

 화면 비율

 device-aspect-ratio

 단말기 화면 비율

 color

 색상 비트수

 color-index

 색상 테이블 엔트리 수

 monochrome

 모노크롬 프레임 버퍼의 픽셀당 비트수

 resolution

 화면 해상도

 scan

 TV의 스캔 방식

 grid

 그리드/비트맵 방식 여부



* 출처 : http://naradesign.net/wp/2012/05/30/1823/

http://blog.naver.com/clxm300?Redirect=Log&logNo=10141136099


'Computer > Web' 카테고리의 다른 글

쿠키, 세션  (0) 2012.07.07
CSS3 미디어 쿼리  (0) 2012.07.07
반응형 웹(Responsive Web)  (0) 2012.07.07
구글 페이지랭크(PageRank) 알고리즘  (0) 2012.07.06
HTML5 WebStorage  (1) 2012.06.30
HTML5 주요기술  (0) 2012.06.29

댓글을 달아 주세요

posted by 희정냥★ 2012. 7. 7. 14:55

반응형 웹(Responsive Web)의 등장 배경?
최근 다양한 모바일 기기가 보급되면서 하나의 사이트를 만들더라도 데스크탑 / 모바일 폰 / 타블렛 PC 등 서로 다른 해상도를 가진 디바이스들을 고려하지 않을 수 없게 되었다. 데스크탑 하나만 보더라도 와이드의 고해상도 디스플레이가 확산됨에 따라 많은 사이트들이 기존의 1024*768 크기를 넘어 점차 사이즈를 키워가고 있는 추세이지만 그렇다고 하나의 해상도에만 맞춰 사이트를 제작하기도 어렵다. 이렇듯 N-Screen의 시대로 불리는 다양한 디바이스의 해상도에 맞춰 사이트의 레이아웃을 변환하는 이슈에 맞춰 등장한 것이 반응형 웹(Responsive Web)이다.

 


반응형 웹(Responsive Web) 이란?
반응형 웹이란 HTML5의 “미디어 쿼리”를 이용하여 하나의 소스로 제작된 컨텐츠가 데스크탑에만 국한되지 않고 타블렛 PC, 모바일 폰 등 다양한 크기의 디바이스 환경에 맞추어 해상도나 화면이 동적으로 변환되는 기법을 말한다.

 

대표적인 예로 The Boston Globe 사이트를 보면 가로 길이에 따라 다음과 같이 레이아웃이 변화된다. 모바일 웹을 별도로 제작할 필요 없이 하나의 반응형 웹사이트로 사이즈에 맞춰 이미지나, 폰트, 사이즈 및 UI가 자동으로 변환되어 모든 디바이스에서 사이트를 이용할 수 있는 것이다.

 

 


 

반응형 웹의 주요 컨셉은 다음과 같다. (참고)
1. A flexible, grid-based layout : 그리드를 상대적(% 단위 등)으로 지정하여 브라우저 크기에 따라 유동적으로 변환 
2. Flexible width media: images, video : 너비가 변경되어도 웹페이지 안의 미디어가 넘치지 않게 하는 기법
3. Media queries : 다양한 브라우저에서 표현양식을 제어할 수 있게 고안된 기능

 

즉, 반응형 웹은 “유동형 그리드, 가변폭 이미지, 미디어쿼리 개념”을 하나로 묶고 체계화 시킨 용어이다. 그러나 반응형 웹에도 아직 극복해야 할 단점들이 있다. 가장 큰 문제는 IE8 이하에서는 사용이 불가능하다는 점이다. (참고)
1. 실제 사용되는 이미지보다 더 큰 이미지를 사용할 수 있다.
2. 이미지 리사이징은 단말기의 CPU를 보다 더 많이 사용한다.
3. 실제로 사용하지 않은 자원(이미지, CSS)을 전송 받을 수 있다.
4. 미디어 쿼리를 지원하지 않는 브라우저의 사용자가 많다 : CSS3의 속성으로 IE8 이하의 버전에서는 사용이 불가능

 

이와 같이 아직까지 미디어 쿼리를 지원하지 않는 브라우저의 사용자가 많기 때문에 기존의 데스크탑 사이트에 HTML5의 미디어 쿼리만 적용한다고 반응형 웹이라고 볼 수 는 없을 것이다. 일부에게는 반응하지 않는 사이트이기 때문이다.


 

반응형 웹(Responsive Web) 디자인 적용 사례 (참고)
# 1 Deren Keskin : 상단 메뉴의 변화가 눈에 띄며 사이트 전체의 이미지/텍스트의 변경이 자연스럽게 이루어진다.

 


 

dConstruct 2011 : 가로 폭에 따라 이미지가 리사이징되며 레이아웃도 변경되는 모습을 볼 수 있다.

 

 

 

#3 Naomi Atkinson : 실제로 브라우저의 가로 폭을 변경해보면 이미지 박스들이 이리저리 옮겨가는 모습을 볼 수 있다. 

 

 

 

#4 Neovada : 사이트 전체가 슬라이딩 방식으로 이루어져 있어 반응형 웹으로 구현하기 좀 더 용이해 보인다.

 


 

반응형 웹(Responsive Web)은 기획? Mobile First!
반응형 웹이 크게 이슈화 된 것도 결국은 모바일 웹 환경 때문이다. 앞서 언급했듯이 모바일 폰과 타블렛 PC를 위해 별도의 사이트를 제작해야 하는 번거로움을 반응형 웹이 대체할 수 있을 것이다. 그렇다면 이렇게 변화하는 사이트를 어떻게 기획해야 효과적인 결과물이 나올까?

 

 

 

“새로운 규칙은 모바일 우선이다 (We understand that the new rule is mobile first)”
 – 구글 CEO 에릭 슈미트(Eric Schmidt)

 

 

 

이번 포스팅을 위해 참고한 대부분의 자료가 “데스크탑용 사이트 + 미디어쿼리 = 반응형 웹”이 아닌 모바일 사이트를 먼저 고려하여 기본적인 사이트를 기획하고 이후 점차적으로 확장해가야 한다고 말하고 있다. 물론 이때 사이트의 사용성과 컨텐츠의 구조는 기본이다.

 

아직까지는 극복해야 할 한계들이 있는 상황(미디어 쿼리를 지원하지 않는 브라우저의 사용자 등)에서 국내에는 반응형 웹 디자인을 적용한 사이트가 많지는 않다(현대자동차 혹은 BLUEWAVE 참조). 하지만 피할 수 없는 N-Screen 시대에 최적화된 웹 환경 제공이 용이하고 기업에서는 노동과 비용을 줄일 수 있다는 장점이 있어 앞으로 반응형 웹의 발전은 필수가 되지 않을까 생각해 본다.


* 출처 : http://allje.tistory.com/109

'Computer > Web' 카테고리의 다른 글

쿠키, 세션  (0) 2012.07.07
CSS3 미디어 쿼리  (0) 2012.07.07
반응형 웹(Responsive Web)  (0) 2012.07.07
구글 페이지랭크(PageRank) 알고리즘  (0) 2012.07.06
HTML5 WebStorage  (1) 2012.06.30
HTML5 주요기술  (0) 2012.06.29

댓글을 달아 주세요

posted by 희정냥★ 2012. 7. 7. 01:11

Postgresql 9.1에서의 리플리케이션 방식은 디폴트로 비동기화 방식이다.

동기화 방식으로 변경하기 위해선 슬레이브 서버의 이름을 설정하고 마스터와 슬레이브 설정 파일에 각각 지정해주면 된다.

우선 리플리케이션 기본 설정 방법.


마스터 : 192.168.0.100

슬레이브 : 192.168.0.101


[마스터 DB 설정]


1. pg_hba.conf 파일 수정


# vi /usr/local/pgsql/data/pg_hba.conf


# IPv4 local connections:

host all all 0.0.0.0/0 md5

host replication postgres 192.168.0.101/32 md5

host replication postgres 192.168.0.100/32 md5

마스터와 슬레이브에 대해 replication이라는 이름의 가상DB 접속권한을 부여한다.


2. postgresql.conf 수정


# vi /usr/local/pgsql/data/postgresql.conf


# WRITE AHEAD LOG

# - Settings -

wal_level = hot_standby


# - Archiving -

archive_mode = on

archive_command = 'cp %p /usr/local/pgsql/data/pg_archive/%f'


# REPLICATION

# - Master Server -

max_wal_senders = 2

wal_keep_segments = 8

#synchronous_standby_names = 'slave1'

# wal_level = hot_standby

마스터가 슬레이브의 접속을 받아들일 수 있도록 준비.


# archive_mode = on

슬레이브 DB의 반영처리가 늦어지는 경우, 또는 장시간동안 슬레이브 DB를 정지한 후에 재가동한 경우등에

아카이브된 WAL archive 파일을 사용해서 마스터 DB와 동기화시킬 수 있는 이점이 있다.

주의할 점은 WAL archive 파일의 수납장소가 마스터와 슬레이브 양쪽에서 참조할 수 있는 곳이여야 한다.

또한 디스크 용량확보를 위해 오래된 WAL archive 파일은 정기적으로 삭제해주는 것이 좋다.


# archive_mode = off

WAL archive 파일을 위한 디스크 확보가 어렵거나 DB의 유지 보수 점검이 어려울 경우에 archive 모드를 off로

할 수도 있다.

단점으로는 슬레이브 DB의 데이터 갱신이 장시간 지연되었을 경우 그 이후 데이터 처리가 정확히 반영되지

못할 수도 있다. 마스터 DB와 동기화가 이뤄지지 않았을 경우에는 다시 마스터 DB의 복제를 해야 할 필요도 생긴다.


# archive 사용 시

archive_mode = on

archive_command = 'cp %p /usr/local/pgsql/data/pg_archive/%f'


# archive 사용하지 않을 시

archive_mode = off

wal_keep_segments = 8 (8~32가 적당)


# max_wal_senders = 2

접속가능한 슬레이브의 접속수를 설정.


# wal_keep_segments = 8

리플리케이션용으로 남겨둘 WAL 파일의 수를 지정.


# synchronous_standby_names = 'slave1'

replication을 동기화 방식으로 처리하고자 할 경우 슬레이브 DB의 이름을 설정한다.

또한 이후에 슬레이브 DB 설정 시에도 위에 적은 이름을 사용한다.


3. WAL Archive 저장 디렉토리 생성

# mkdir /usr/local/pgsql/data/pg_archive

# chown -R postgres:postgres /usr/local/pgsql/data/pg_archive


4. 마스터 DB 재실행

$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data restart -m fast



[슬레이브 DB 설정]


1. DB 설치


# tar xvzf postgresql-9.1.1.tar.gz

# ./configure

# gmake

# su

# gmake install

# adduser postgres -d /home/pgsql


2. 마스터 DB 복제


9.1에서는 DB 복제 전용툴로 pg_basebackup이 추가되었다. 원격 서버의 백업용도로도 활용할 수 있고,

테이블스페이스가 있을 경우에도 전체를 다 백업해 준다.


# /usr/local/pgsql/bin/pg_basebackup -h 192.168.0.100 -p 5432 -U postgres -D /usr/local/pgsql/data --xlog --checkpoint=fast --progress


3. postgresql.conf 수정


# vi /usr/local/pgsql/data/postgresql.conf


hot_standby = on


4. pg_archivecleanup 유틸리티 설치


# cd 소스파일/contrib/pg_archivecleanup

# make all && make install


5. recovery.conf 파일 생성


# cp /usr/local/pgsql/share/recovery.conf.sample /usr/local/pgsql/data/recovery.conf

# vi /usr/local/pgsql/data/recovery.conf


restore_command = 'cp /usr/local/pgsql/data/pg_archive/%f %p'

archive_cleanup_command = 'pg_archivecleanup /usr/local/pgsql/data/pg_archive %r'

recovery_target_timeline = 'latest'

standby_mode = on

primary_conninfo = 'host=192.168.0.100 port=5432 user=postgres password=비밀번호'

#trigger_file = '/tmp/pgsql.trigger'

# 동기화 방식 replication

마스터와 슬레이브의 설정 파일에서 슬레이브 DB의 이름을 같은 것으로 설정하면 동기화 방식이 이루어진다.


마스터 DB postgresql.conf

synchronous_standby_names = 'slave1'


슬레이브 DB recovery.conf

primary_conninfo = 'host=192.168.0.100 port=5432 user=postgres password=비밀번호 application_name=slave1'


# 동기화 방식으로 replication을 할 경우에 슬레이브 DB가 멈춰 있으면 입력 처리가 되지 않는 것에 주의한다.


6. 슬레이브 DB 실행


$ /usr/local/pgsql/bin/pg_ctl -D /usr/local/pgsql/data start -m fast


7. replication 상태 확인


$ /usr/local/pgsql/bin/psql -x -c "Select * From pg_stat_replication"


-[ RECORD 1 ]----+------------------------------

procpid | 2876

usesysid | 10

usename | postgres

application_name | walreceiver

client_addr | 192.168.0.101

client_hostname |

client_port | 49082

backend_start | 2012-05-30 12:16:37.720519+09

state | streaming

sent_location | 0/5D00C980

write_location | 0/5D00C980

flush_location | 0/5D00C980

replay_location | 0/5D00C930

sync_priority | 0

sync_state | async


마스터와 슬레이브에서 슬레이브 DB의 이름을 지정하지 않았기 때문에 async(비동기방식)으로 표시된다.

 

'Computer > DB' 카테고리의 다른 글

Postgresql 9.1 Replication  (0) 2012.07.07
Java JDBC 이용한 MySql connection  (1) 2008.10.04

댓글을 달아 주세요

posted by 희정냥★ 2012. 7. 6. 19:36
구글 개발자 서르게이 브린 논문 번역

Abstract

웹 페이지의 '중요성'은 본질적으로 주관적인 문제여서 읽는 사람의 관심사나 지식 그리고 태도 등에 의존한다. 하지만 웹 페이지의 상대적 중요성에 관해서는 객관적으로 얘기할 수 있는 부분이 많다. 이 논문은 객관적이고 기계적으로 웹 페이지를 랭킹해서 읽는 사람의 관심이나 기울이는 주의를 효과적으로 측정할 수 있는 수단인 "PageRank"를 소개한다. 우리는 페이지랭크(PageRank)를 이상적인 랜덤 웹 써퍼(random web surfer)에 비교해 볼 것이며, 어떻게 많은 웹 페이지를 대상으로 PageRank를 능률적으로 계산할 수 있는지를 설명할 것이다. 그리고 어떤 방식으로 PageRank를 검색이나 사용자 네비게이션에 응용할 수 있는지도 보여 주고자 한다.

1. 도입과 동기(Introduction and Motivation)

월드와이드웹(World Wide Web)은 정보검색(Information Retrieval)에 새로운 과제를 안겨 주었다. 웹은 매우 거대하며 이질적(heterogenous)이다. 현재 추산으로도 약 1억5천만 페이지 이상이 웹에 존재하며, 이 숫자는 매년 적어도 두 배씩 커지고 있다. 더욱 중요한 점은, 웹 페이지들이 극단적으로 다양하다는 것이다. 예를 들면 "Joe가 오늘 점심 때 뭘 먹었지?"와 같은 질문이 있는가하면 정보검색에 관한 전문적 논문집이 있기도 하다. 이런 주된 도전 과제들 외에도 웹에는 익숙하지 못한 초보 사용자들과 검색 엔진의 랭킹 기능(ranking function)을 교묘히 이용하려는 많은 웹 페이지들로부터 비롯되는 문제점이 있다.

그러나 웹은 다른 "평면적"인 문서 컬렉션(flat document collections)과 달리 하이퍼텍스트가 있다. 하이퍼텍스트(hypertext)는 웹 페이지 자체의 텍스트 외에 링크 구조(link structure)나 링크 텍스트(link text)같은 상당한 수준의 부가적인 정보를 제공한다.

이 논문에서 우리는, 모든 웹 페이지를 보편적 "중요도" 순으로 순위를 매기기 위해 웹의 링크 구조를 사용하였다. 이 랭킹은 페이지랭크(PageRank)라 하며, 검색엔진 사용자나 웹 사용자가 거대한 이질적 세계인 월드와이드웹을 빠르게 이해할 수 있게 도와준다.

1.1 웹 페이지의 다양성(Diversity of Web Pages)

학술적 인용(academic citation)을 분석한 문헌은 이미 많이 존재하지만 웹 페이지와 학술 출판물 사이에는 많은 중요한 차이가 있다. 학술 논문은 철두철미하게 리뷰되지만 웹 페이지는 '품질 관리'나 '출판 비용' 없이 늘어난다. 단순한 프로그램 하나만으로도 아주 많은 페이지를 손쉽게 만들어 낼 수 있으며 인위적으로 인용 횟수를 쉽게 부풀릴 수 있다. 웹 환경 속에는 그 안에서 이익을 찾는 많은 벤쳐들이 있기 때문에 이들이 사용자의 주의를 끌어오는 전략 역시 검색엔진 알고리듬의 발달에 맞춰서 함께 진화되어 왔다. 이러한 이유로 복제가능한 특징을 세는 방식으로 웹 페이지를 평가하려는 전략은 손쉽게 악용될 수 있다. 게다가, 학술 논문의 경우는 그 갯수를 정확히 셀 수 있을 뿐만 아니라 사실상 질적인 면 및 인용 횟수 등에서 유사하고 그 목적 역시 비슷하다.(대개 '지식의 몸체'를 키우기 위한 목적으로 만들어진다.) 하지만 웹 페이지는 질적인 면에서나 사용적인 측면, 인용, 길이 등에 있어서 학술 논문보다 훨씬 더 다양하다. IBM 컴퓨터에 관한 애매한 질문들을 모아놓은 것은 IBM 홈페이지와 매우 다르다. 운전자에게 휴대폰이 미치는 영향에 관해서 연구한 논문은 특정 휴대폰 회사의 광고와 매우 다르다. 사용자가 읽은 웹 페이지의 평균적인 질은 평균적인 웹 페이지의 질보다 높다. 그것은 웹 페이지를 만들고 퍼블리슁하는 것이 매우 쉽기 때문에 웹에는 사용자들이 읽지 않으려 하는 많은 저품질의 웹 페이지가 있기 때문이다.

웹 페이지에는 여러 가지 분화될 수 있는 요소가 많이 있다. 이 논문에서 우리는 그 중의 하나 - 웹 페이지의 상대적 중요성을 어떻게 추산할 것인가 - 라는 문제를 주로 다룬다.

1.2 페이지랭크(PageRank)

웹 페이지의 상대적 중요성을 측정하기 위해 우리는 웹 그래프를 기반으로 웹 페이지를 랭킹(ranking)하는 방식인 페이지랭크를 제안한다. 페이지랭크는 검색이나 브라우징, 트래픽 추산에 적용될 수 있다. 섹션 2에서는 페이지랭크의 수학적 기술을 다룰 것이며 직관적인 정당화(intuitive justification)를 얘기할 것이다. 섹션 3에서는 5억1800만 개에 이르는 하이퍼링크에 대해 어떻게 효율적으로 페이지랭크를 계산할 수 있는지 보여주고자 한다. 페이지랭크의 유용성을 테스트하기 위해 우리는 구글(Google)이라는 웹 검색 엔진을 구축했다. 이것은 섹션 5에서 다룬다. 섹션 7.3에서는 페이지랭크가 어떻게 브라우징을 도울 수 있는지 보여주고자 한다.

2. 웹 상의 모든 페이지의 순위 매기기(A ranking for every page on the Web)

2.1 관련 자료

학술 인용 분석에 관해서는 매우 많은 연구가 이미 존재한다. Goofman은 과학 커뮤니티에서 일종의 유행병처럼 정보 흐름이 퍼져 나간다는 것을 주장한 흥미로운 이론을 발표하기도 했다.

웹 같은 대형 하이퍼텍스트 시스템에서 어떤 방식으로 링크 구조(link structure)를 이용할 수 있는지에 관해서도 최근들어 상당한 연구가 이뤄지고 있다. Pitkow는 얼마 전에 다양한 방식의 링크 기반 분석을 설명한 "월드와이드웹 생태계의 특징"이라는 제목의 박사 학위 논문을 완성했다. Weiss는 링크 구조를 감안한 클러스터링 방식에 대해서 논했다. Spertus는 여러 가지 적용사례에 있어서 링크 구조로 부터 얻어낼 수 있는 정보에 관해 발표했다. 좋은 시각화를 위해서는 하이퍼텍스트에 부가적인 구조가 필요하다는 연구도 있었다. Kleinberg는 웹을 서로 인용하는 행렬로 보고 그 고유벡터(eigenvector)를 계산하는 방식을 기반으로 "헙 & 오쏘리티(Hubs and Authorities) 모델"이라는 흥미로운 모델을 개발했다. 마지막으로, 도서관 커뮤니티 쪽에서는 웹의 "질"이라는 것에 대해 관심을 갖고 있기도 하다.

일반적인 인용 분석 테크닉을 웹의 하이퍼텍스트적 인용 구조에 적용하고자 시도하는 것은 너무도 자연스러운 것이다. 단순하게 웹 페이지에 있는 각각의 링크를 학술적 인용처럼 생각해 볼 수 있는 것이다. 야후! 같은 메이져 페이지는 야후!를 가리키는 수 만, 수십 만 개의 백 링크(backlinks) 또는 인용을 갖고 있는 것이다.

야후! 홈페이지가 아주 많은 백 링크를 갖고 있다는 사실은 야후! 홈페이지가 매우 중요하다는 사실을 함축한다. 사실 많은 웹 검색엔진들은 어떤 페이지가 얼마나 중요한가 내지는 높은 질을 갖고 있는가를 판단할 때 백 링크 숫자를 바탕으로 가중치를 주고 있다. 하지만 단순히 백 링크의 갯수를 세는 것은 많은 문제점을 갖는다. 이 문제점들은 학술 인용 데이타베이스에는 존재하지 않는 웹만의 특징과 관련이 있는 것들이다.

2.2 웹의 링크 구조(Link Structure of the Web)

약간의 편차는 있지만 현재 크롤링 가능한 웹 그래프는 약 1억5천만개의 노드(node;페이지)와 17억 개의 엣지(edge;링크)가 있다고 알려져 있다. 각각의 웹 페이지는 그 페이지로부터 밖으로 나가는 포워드 링크(forward link; outedges)와 그 페이지를 가리키는 백 링크(backlink; inedges)를 갖는다. 어떤 페이지의 모든 백 링크를 다 찾아낸다는 것은 불가능하지만 페이지를 다운로드하고 나면, 포워드 링크가 무엇인지는 알 수 있다.

backlink 백 링크

웹 페이지가 백 링크를 몇 개나 갖느냐는 매우 다양하다. 우리가 갖고 있는 데이타베이스에 따르면 넷스케잎 홈페이지는 62804개의 백 링크를 갖는데 반해 대개의 페이지들은 단지 몇 개의 백 링크만을 갖는다. 일반적으로 링크가 많이 된 페이지일수록 그렇지 못한 페이지보다 더 "중요하다". 학술 인용에서도 인용의 횟수를 세는 단순한 방법이 미래의 노벨상 수상자를 예측하는 데 사용될 수 있다. 페이지랭크는 인용 횟수를 세는 방식 이상의 훨씬 더 정교화된 방법을 제시한다.

페이지랭크가 흥미로운 이유는 인용 횟수가 일반적인 의미의 중요성과 일치하지 않는 경우가 매우 많기 때문이다. 어떤 웹 페이지가 야후!에 링크가 되어 있다면 그 페이지는 오직 하나의 백 링크밖에 없지만 그 링크는 매우 중요한 링크다. 야후!에 링크된 그 페이지는 다른 별 볼 일 없는 여러 곳에서 링크된 페이지보다 더 높은 순위를 가져야 한다. 페이지랭크는 링크 구조만을 사용해서 어떻게 "중요성"을 정확히 추정해낼 수 있을까를 시도한 것이다.

2.3 링크를 통한 랭킹의 전파(Propagation of Ranking through Links)

위의 논의를 기초로, 우리는 페이지랭크에 대한 직관적 기술을 다음과 같이 할 수 있다: 어떤 페이지가 높은 랭크의 백 링크를 많이 가질수록 그 페이지의 랭크도 올라간다. 이것은 어떤 페이지가 많은 백 링크를 갖는 경우와 몇 개의 높은 랭크값 백 링크를 갖는 경우 모두를 포괄하는 것이다.

2.4 페이지랭크(PageRank)의 정의

어떤 웹 페이지를 u라고 하고 u 페이지가 가리키는 페이지들의 집합을 Fu, u 페이지를 가리키는 페이지의 집합을 Bu라 하자. Nu = |Fu|라 하고, 이것은 u 페이지로부터 나가는 링크의 갯수, 즉 Fu의 갯수다. 그리고 노멀라이제이션에 사용되는 팩터를 c라고 하자.(노멀라이제이션은 전체 웹 페이지의 랭크 총합을 일정하게 하기 위해서다.)

일단, 단순 랭킹 R을 정의하는 것에서 출발해 보자. 단순 랭킹 R은 페이지랭크(PageRank)를 약간 단순화시킨 버전이다.

Simple PageRank

위 식은 전 섹션에서 얘기한 직관을 공식화한 것이다. 어떤 페이지가 가리키는 페이지들의 랭크에 균일하게 기여하기 위해, 링크가 나가는 페이지의 랭크를 그 페이지의 포워드 링크 갯수로 나누고 있다는 점에 주의하자. 그리고 c는 1보다 작아야 하는데, c < 1인 이유는 포워드 링크가 없는 페이지도 많이 있기 때문에 그런 페이지들의 가중치는 시스템 속에서 사라질 수 있기 때문이다.(섹션 2.7을 참조하라.) 위 등식은 재귀적(recursive)인 식이지만 초기 랭크 집합을 주고 수렴할 때까지 연산을 함으로써 계산할 수 있다.

단순 버전 페이지랭크

그림 2 단순화된 페이지랭크의 계산

단순 버전 페이지랭크의 계산
그림 3 정상상태를 이루고 있는 페이지들

그림 2는 한 쌍의 페이지로부터 다른 한 쌍의 페이지로 랭크가 전파되어 나가는 것을 보여주고 있다. 그림 3에서는 일군의 페이지들 사이에서 일정한 정상상태(steady state)의 솔루션을 이루고 있는 것을 볼 수 있다.

이것을 다른 방식으로 표현해 보자. 각 행과 열이 웹 페이지에 대응하는 정방행렬을 A라 하자. 그리고, 페이지 u에서 v로 가는 연결(edge)이 있다면 Au,v = 1/Nu이라 하고, 엣지가 없다면 Au,v는 0이라 하자. R을 웹 페이지들의 벡터로 생각해 보면, R = cAR이 된다. 그러므로 R은 A의 아이겐벡터(eigenvector; 고유벡터)가 되고 아이겐밸류는 c이다. 사실, 우리가 원하는 것은 A의 지배적 고유벡터(dominant eigenvector)다. 이것은 A를 여러 비퇴화적 시작 벡터(nondegenerate start vector)에 반복적으로 적용함으로써 계산될 수 있을 것이다.

랭크 싱크
그림 4 랭크 싱크

위에서 살펴 본 단순화된 랭킹 함수는 약간의 문제가 있다. 두 페이지가 서로서로 가리키고 있으며 다른 페이지로는 연결되어 있지 않은 경우를 생각해 보자. 다른 웹 페이지가 그 두 페이지 중 하나를 가리키고 있는 경우, 반복연산(iteration)이 진행되면서 그 루프에서는 랭크가 계속 축적될 뿐 외부로 전혀 분산하지 못 한다.(왜냐하면 외부로 나가는 엣지가 전혀 없으므로.) 루프는 일종의 함정을 형성하게 된다. 우린 이것을 랭크 싱크(rank sink)라 부른다. 랭크 싱크로부터 초래되는 문제를 해결하기 위해, 우리는 랭크 소스를 도입한다.

정의 1:
랭크의 소스에 해당하는 웹 페이지의 벡터 중 하나를 E(u)라 하자. 그러면 일군의 웹 페이지들의 페이지랭크는 다음 식을 만족하며 ||R||1 = 1(||R||1은 R'의 L1 norm)이고 c가 최대값을 가질 때의 R'이다.역자주

PageRank 페이지랭크

E가 모두 다 양수이면 등식의 균형을 위해서 c 값이 줄어들어야만 한다는 것에 주의하자. 그러므로 이 테크닉은 소멸계수(decay factor)에 해당한다. 위 식을 행렬 용어로 표현하면 R' = c(AR' + E)이고, ||R||1 = 1이므로 이 식은R' = c(A + E x 1)R'로 다시 쓸 수 있다. 여기서 1은 1로만 구성된 벡터다. 그러므로, R'은 (A + Ex1)의 아이겐벡터라고 할 수 있다.

역자주 L1 norm은 (a,b,c,d,e,..)라는 벡터가 있을 때 (a+b+c+d+e+..)의 값을 의미합니다. '소스'(source)와 '싱크'(sink)는 그래프 이론에서 나온 용어로, 아웃엣지가 없는, 즉 밖으로 나가는 링크가 없는 것을 싱크라 하고 반대로 인엣지가 없는, 즉 안으로 들어 오는 링크는 없고 밖으로 나가는 것만 있는 것을 소스라 합니다.

2.5 랜덤 써퍼 모델(Random Surfer Model)

위와 같은 페이지랭크의 정의는 그래프 상의 랜덤 워크(random walks)라는 또 하나의 직관적 기반을 갖고 있는 것으로 볼 수 있다. 단순화된 버전의 페이지랭크는 웹 그래프 상에서 랜덤 워크의 확률분포에 해당한다. 직관적으로 생각해 보면 이것은 "랜덤 써퍼"의 행동을 모델링한 것으로 볼 수 있다. "랜덤 써퍼"는 무작위로 일련의 링크들을 클릭해 나간다. 하지만 실제 웹 써퍼가 작은 루프에 빠져 들었을 때도 계속해서 그 루프 내를 맴돌 가능성은 거의 없다. 대신, 그 써퍼는 다른 페이지로 점프하려 할 것이다. 부가적 팩터인 E는 바로 그 행동을 모델링한 것으로 볼 수 있다. 즉, 써퍼는 주기적으로 "지루해지고" E의 분포에 기반해서 선택된 무작위 페이지로 점프하는 것이다.

지금까지 우리는 E를 사용자 정의 퍼래미터로 생각했다. 대부분의 테스트에서 우리는 E를 모든 웹 페이지에 걸쳐 동일하게 α값을 갖는 것으로 했다. 하지만, 섹션 6에서는, E 값이 달라짐에 따라 페이지의 랭크가 어떻게 "사용자화"될 수 있는지를 보여줄 것이다.

2.6 페이지랭크 계산(Computing PageRank)

페이지랭크를 계산하는 것은 규모의 문제를 무시한다면 아주 간단명료하다. S를 웹 페이지의 벡터(E 같은)라 하자. 그러면 페이지랭크는 다음과 같이 계산될 수 있을 것이다.


R0 <--- S
loop:
	Ri+1 <--- ARi
		d <--- ||Ri||1 - ||Ri+1||1
	Ri+1 <--- Ri+1 +dE
		δ<--- ||Ri+1 - Ri||1
while δ> ε

d 팩터가 수렴속도를 빠르게 하고 ||R||1을 유지하는 것에 주목하자. 또 다른 노멀라이제이션 방법은 적절한 팩터를 R에 곱하는 것이다. d의 사용은 E의 영향에 작은 효과만 미칠 것이다.

2.7 댕글링 링크(Dangling Links)

이 모델과 관계되는 이슈 중 하나는 댕글링 링크 문제다. 댕글링 링크란 외부로 나가는 링크가 없는 페이지를 가리키는 링크를 뜻한다. 댕글링 링크가 모델에 영향을 주는 이유는, 이것의 가중치가 어디로 분산되고 있는지가 불분명하고 또 아주 많은 댕글링 링크가 존재하기 때문이다. 종종 댕글링 링크가 가리키고 있는 페이지는 다운로드되지 않은 페이지일 수도 있다. 웹을 통째로 샘플링하는 것은 어렵기 때문이다.(현재 우리가 다운로드한 2400만 페이지에는 아직 URL이 가리키는 문서가 다운로드되지 않은 5100만 개의 URL이 있는 상태다. 즉, 5100만 개의 댕글링 링크가 있는 것이다.) 댕글링 링크는 다른 페이지의 순위에 직접적으로 영향을 주지는 않기 때문에, 우리는 모든 페이지랭크가 계산될 때까지 댕글링 링크를 그냥 제거했다. 페이지랭크 계산이 다 끝난 뒤에, 즉 큰 문제를 일으키지 않게 되었을 때, 댕글링 링크를 다시 첨가할 수 있다. 링크가 제거됨으로써 그 페이지에 있는 다른 링크의 노멀라이제이션이 영향받을 수는 있지만 크게 변화되는 건 아니다.

3 임플리멘테이션(Implementation)

스탠포드 웹 베이스 프로젝트(Stanford WebBase project)의 일환으로, 우리는 현재 총 2400만 페이지의 리파지터리(repository)를 갖고 있는 완전한 크롤링 & 인덱싱 시스템을 구축했다. 웹에 있는 모든 URL을 찾을 수 있게 하기 위해서는 모든 웹 크롤러가 URL 데이타베이스를 유지하고 있어야 한다. 웹 크롤러는 페이지랭크의 임플리멘테이션을 위해, 크롤링하면서 만나는 링크의 인덱스만 구축하면 된다. 작업 자체는 단순한 것이지만 볼륨이 거대하기 때문에 쉽지 않다. 예를 들어, 현재 우리가 구축한 2400만 페이지의 데이타베이스를 5일 안에 인덱싱하기 위해서는, 초당 50 페이지를 프로세싱해야 한다. 보통의 페이지 하나에 통상 11개의 링크가 있으므로(무엇을 링크로 셀 것인가에 따라 달라질 수는 있다.) 초당 550개의 링크를 프로세싱해야 하는 것이다. 또한, 우리가 구축한 2400만 페이지의 데이타베이스는 7500만 개의 각기 다른 URL을 참조하고 있으며, 각각의 링크는 반드시 서로 비교되어야만 하는 것이다.

웹에 깊숙히 그리고 미묘하게 존재하는 결함들에 유연하게 대응할 수 있는 시스템을 구축하기 위해서 많은 시간이 걸렸다. 웹에는 한없이 커다란 싸이트, 페이지, 심지어 끝없이 계속되는 긴 URL들이 있다. 상당수의 웹 페이지가 잘못된 HTML을 담고 있기 때문에 파서(parser)를 디자인하는 것이 까다로왔다. 예를 들어, 우리는 URL에 /cgi-bin/이 들어 있는 경우 크롤링하지 않았다. 물론, 웹은 계속해서 변하고 있기 때문에 "전체 웹"을 정확하게 샘플링한다는 것은 불가능하다. 싸이트가 다운되는 경우도 있고, 어떤 경우는 자신의 싸이트를 인덱싱되지 않도록 해 놓기도 한다. 이런 모든 점에도 불구하고, 우리는 공개적으로 접근가능한 웹의 실제 링크 구조를 상당한 수준으로 표현했다고 생각하고 있다.

3.1 페이지랭크 임플리멘테이션

우리는 각각의 URL을 각기 유니크한 정수로 변환하고, 하이퍼링크의 페이지를 구분할 수 있도록 모든 하이퍼링크를 페이지의 정수 ID를 이용해서 데이타베이스에 저장했다. 임플리멘테이션에 관한 자세한 사항은 구글 검색엔진의 해부학 논문에서 밝혔다. 보통, 페이지랭크는 다음과 같은 식으로 임플리멘테이션했다.

먼저, 부모 ID(Parent ID)를 이용해서 링크 구조를 정렬한다. 그 다음, 앞에서 말한 것과 같은 이유로 링크 데이타베이스에서 댕글링 링크를 제거한다. (몇 번의 반복 작업만으로도 대부분의 댕글링 링크를 제거할 수 있다.) 그 다음, 랭크 값을 초기화한다. 초기화 값을 어떻게 할 것인가는 어떤 전략을 갖고 있느냐에 따라 달라진다. 수렴할 때까지 반복작업을 계속할 생각이라면, 일반적으로 초기값은 최종값에 영향을 미치지 않는다. 단지 수렴 속도만 빠르게 할 뿐이다. 하지만 초기값을 잘 선택하면 수렴과정의 속도를 높일 수 있다. 우리는 초기 할당값을 신중하게 선택하면 제한적 횟수의 많지 않은 반복 작업만으로도 아주 좋은 결과를 얻거나 더 나은 퍼포먼스를 만들어 낼 수 있다고 믿고 있다.

각 페이지의 가중치에 메모리를 할당한다. 우리는 단정도 부동소수점(single precision floating point) 값을 사용했고, 각각은 4바이트씩 할당했으므로 7500만 개의 URL은 곧 300메가바이트의 크기가 된다. 만약 모든 가중치를 담고 있을 만큼 램이 충분치 않으면 여러 번의 패쓰(pass)를 사용해도 된다.(우리가 임플리멘테이션한 것은 메모리의 절반과 2개의 패쓰를 사용했다.) 현재 진행 중인 단계의 가중치는 메모리에 저장되고, 전단계의 가중치는 디스크를 통해 리니어(linear)하게 억세스한다. 또한, 링크 데이타베이스 - 즉 알고리듬 정의에서의 A - 로의 모든 억세스도 정렬되어 있기 때문에 리니어하다. 그러므로 A 역시 디스크에 저장될 수 있다. 이러한 데이타 구조들이 매우 큰 크기임에도 불구하고, 리니어 디스크 억세스를 통한 각 반복작업에 걸리는 시간은 보통의 웍스테이션상에서 약 6분 정도면 된다. 가중치들이 수렴하고 나면, 다시 댕글링 링크를 추가하고, 랭킹을 재연산한다. 댕글링 링크를 되돌려 넣은 뒤에 필요한 반복 작업 횟수는 댕글링 링크를 제거하는 데 요구되었던 횟수와 똑같다는 점에 주의하라. 그렇지 않으면, 댕글링 링크의 일부는 가중치가 0이 될 것이다.

이상의 모든 과정은 현재의 임플리멘테이션의 경우 총 5시간이 소요된다. 수렴 조건을 덜 엄격하게 하고, 더 최적화를 한다면 계산속도는 더 빨라질 수 있을 것이다. 또는, 아이겐벡터를 추산하는 보다 더 효율적인 테크닉이 사용되어도 퍼포먼스가 더 좋아질 것이다. 어쨌든, 페이지랭크를 계산하는 데 필요한 코스트는 풀 텍스트 인덱스를 구축하는 데 필요한 것에 비하자면 아주 사소한 것이라 할 수 있다.

4 수렴 특성(Convergence Properties)

그림 5에서 볼 수 있는 것처럼, 3억 2200만개라는 큰 링크 데이타베이스를 합리적으로 감내할 만한 수준으로 수렴시키는 데 필요한 반복작업은 약 52회다. 데이타의 크기가 반이라면 대략 45회면 된다. 이 그래프를 통해서, 극단적으로 큰 크기의 컬렉션에서도 페이지랭크가 아주 쉽게 확장될 수 있다는 것을 알 수 있다. 스케일링 팩터가 대략 logn과 거의 선형관계를 이룬다.

페이지랭크의 수렴
그림 5 페이지랭크 연산의 수렴

페이지랭크 연산이 아주 빠르게 수렴한다는 사실로부터 파생되는 한 가지 흥미로운 점은 웹이 익스팬더양 그래프(expander-like graph)라는 점이다. 이 부분의 이해를 돕기 위해서 그래프 상의 랜덤 워크 이론의 간단한 개론을 살펴 보자. 자세한 것은 Motwani-Raghavan이 쓴 페이퍼를 참조하라.

그래프 상의 랜덤 워크는 스토캐스틱(stochastic)한 과정이다. 즉, 임의의 한 타임스텝에 우리는 그래프 상의 특정 노드에 서 있고, 다음 타임스텝에 어떤 노드로 이동할 것인지는 균일하게 무작위적으로 분포하는 아웃엣지 중 하나를 선택해서 결정하는 것이다. 만약 모든 (너무 크지는 않은) 서브셋 노드 S가 이웃(neighborhood; S에 속한 노드들로부터 아웃엣지를 통해 접근가능한 꼭지점들의 집합)을 가지고 있고, 그 이웃 노드의 크기가 |S|보다 α배 이상 크다면 그 그래프는 하나의 익스팬더(expander)라고 할 수 있다. 그리고 만약, 특히 가장 큰 아이겐벨류가 두 번째로 큰 아이겐벨류보다 충분히 더 큰 경우, 그 그래프는 좋은 익스팬젼 팩터를 갖고 있다고 볼 수 있다. 랜덤 워크가 빠른 속도로 그래프 상의 노드들의 제한된 분포로 수렴해 가면 그 그래프는 래피들리-믹싱(rapidly-mixing)하다. 또한 그래프가 익스팬더이고 아이겐벨류 분리(eigenvalue separation)를 갖고 있다면 그 랜덤 워크는 래피들리-믹싱인 경우라 할 수 있다.

이상의 내용을 페이지랭크 연산과 관련 지어 보자. 페이지랭크란 본질적으로, 웹 그래프 상의 랜덤 워크의 제한된 분포로 결정짓는 것이다. 어떤 노드의 중요도 랭킹이란, 본질적으로 충분히 시간이 흐른 뒤에 랜덤 워크가 그 노드에 있을 확률인 것이다. 페이지랭크 연산이 로그 시간 내에 종결될 수 있다는 사실은 랜덤 워크가 래피들리 믹싱이거나 그래프가 좋은 익스팬젼 팩터를 갖고 있다는 말이 된다. 익스팬더 그래프는 여러 가지 바람직한 특성을 많이 갖고 있기 때문에 웹 그래프와 관계된 연산을 함에 있어서 앞으로 다양하게 활용할 수 있을 것이다.

5 페이지랭크를 이용한 검색

페이지랭크의 주된 적용처는 검색이다. 우리는 페이지랭크를 활용한 두 가지 검색엔진을 임플리멘테이션했다. 하나는 단순한 타이틀 기반의 검색엔진이고 다른 하나는 풀 텍스트 검색엔진이다. 후자의 이름은 구글이다. 구글은 표준적인 IR 측정치, 근접성(proximity), 앵커 텍스트(웹 페이지를 가리키는 링크의 텍스트), 그리고 페이지랭크 등의 많은 요소를 바탕으로 검색 결과를 랭킹한다. 페이지랭크가 어떤 이점을 갖는지에 관한 포괄적인 유져 스터디는 이 논문의 범위를 벗어나지만, 몇 가지 비교 실험과 검색 결과 샘플을 이 논문을 통해 얘기해 보려 한다.

페이지랭크의 이점이 가장 크게 활용될 수 있는 부분은 덜 특화된 질의어(underspecified queries)를 처리하는 것이다. 예를 들어, "스탠포드 대학"이라는 질의어를 넣으면, 일반적인 검색엔진은 스탠포드가 들어 간 많은 페이지들을 결과로 보여 줄 뿐이다. 하지만 페이지랭크를 활용하면 스탠포드 대학 홈 페이지가 순위의 가장 위로 올라 오는 것이다.

5.1 타이틀 검색

페이지랭크가 검색에 활용되면 얼마나 유용한지를 시험해 보기 위해 우리는 1600만 페이지의 제목만을 사용하는 검색엔진을 만들어 보았다. 그 검색엔진은 질의어를 넣으면 문서 제목에 질의어가 들어 있는 모든 웹 페이지를 찾은 다음, 그 결과를 페이지랭크를 이용해서 정렬한다. 이 검색엔진은 아주 단순한 것이고 간단하게 구축할 수 있는데, 비공식적인 시험을 해 본 결과 놀랄 만큼 훌륭한 성능을 보여 주었다. 그림 6에서 볼 수 있는 것처럼 "University"라는 검색어에 대해 페이지랭크를 이용한 제목 검색엔진은 대표적인 대학들의 목록을 보여 준 것이다. 이 그림은 우리가 만든 MultiQuery 시스템으로, 두 개의 검색엔진에 동시에 질의를 할 수 있는 시스템이다. 그림의 왼 편에 있는 것이 페이지랭크를 기반으로 한 타이틀 검색엔진이다. 검색 결과에 있는 바 그래프와 퍼센티지는 탑 페이지를 100%로 잡고 페이지의 실제 페이지랭크 값에 로그를 취한 다음 노멀라이징한 값이다. 이 논문의 다른 곳에서는 계속 퍼센타일(percentile)을 사용했지만 여기서는 아닌 것이다. 그림의 오른 쪽에 있는 것은 알타비스타 검색엔진이다. 알타비스타의 검색 결과를 보면 "University"라는 질의어에 맷칭되는 무작위적으로 보이는 웹 페이지들 그리고 여러 써버의 루트 페이지가 보인다. (알타비스타는 퀄리티 휴리스틱으로 URL의 길이를 사용하는 것 같다.)

Multi Search
그림 6 "University" 검색어에 대한 결과 비교

5.2 랭크 머징(Rank Merging)

타이틀에 기반한 페이지랭크 시스템이 아주 훌륭한 결과를 보여 주는 이유는, 제목을 맷칭하는 것이 페이지의 높은 프리시젼을 보장하고, 페이지랭크가 페이지의 높은 품질을 보장하기 때문이다. 웹 검색에서 "University" 같은 질의를 하는 경우, 사용자가 살펴 볼 페이지보다 훨씬 많은 페이지들이 존재하기 때문에 리콜은 그다지 중요하지 않다. 리콜이 중요하게 요구되는 특화된 검색의 경우는 풀 텍스트에 대한 전통적인 정보검색 점수와 페이지랭크를 함께 적용할 수 있을 것이다. 구글 시스템은 그런 형태의 랭크 머징을 사용한다. 랭크 머징은 아주 까다로운 문제로 알려져 있어서 우리는 그런 형태의 질의어를 합리적으로 평가할 수 있게 구축하기 위해 상당한 노력을 부가적으로 기울여야만 했다. 하지만, 그런 형태의 질의어에 있어서도 페이지랭크가 상당히 도움이 된다고 생각된다.

5.3 몇 가지 샘플 결과

우리는 페이지랭크를 이용한 풀 텍스트 검색엔진인 구글을 이용해서 상당히 많은 테스트를 해 보았다. 완전한 형태의 유져 스터디는 이 논문의 범위를 벗어나지만, 몇 개의 샘플을 이 논문의 부록 A에 수록했다. 더 많은 질의어에 대한 결과를 원하는 분은 직접 구글을 테스트 해보면 된다.

표 1은 페이지랭크에 기반한 탑 15위 페이지 목록이다. 이 리스트는 1996년 7월 시점의 결과다. 최근 다시 페이지랭크를 계산해 보았을 때는 마이크로소프트가 넷스케잎보다 조금 더 큰 페이지랭크를 보여 주었다.

Top 15 페이지랭크
표 1

5.4 커먼 케이스(Common Case)

페이지랭크의 디자인 목표 중 하나가 질의어의 커먼 케이스를 잘 처리하게 한다는 것이었다. 예를 들어, 미시건 대학의 학생 관리자 기능 시스템의 이름에 "wolverine"이라는 게 들어 있었던 것으로 기억하고 있는 사람이 "wolverine"이라는 검색을 한다고 하자. 우리의 페이지랭크 기반 타이틀 검색엔진은 "Wolverine Access"를 검색 결과의 첫 번째로 보여 준다. 이것은 대단히 합리적이다. 왜냐하면 모든 학생들은 Wolverine Access 시스템을 사용하고 있고, "wolverine"이라는 질의를 한 사람이라면 Wolverine Access 페이지를 살펴 보려 할 가능성이 매우 크기 때문이다. 그런데 Wolverine Access 싸이트가 좋은 커먼 케이스라는 사실은 그 페이지의 HTML에는 전혀 담겨 있지 않다. 심지어 이런 형태의 메타 정보를 페이지 내에 담을 수 있는 방법이 있다고 하더라도, 이런 류의 평가에 있어서는 페이지를 만든 사람을 신뢰하기 힘들다는 게 문제가 된다. 웹 페이지를 만드는 많은 사람들이 자신이 만든 페이지가 웹에서 가장 훌륭하고 가장 자주 읽힌다고 주장할 것이기 때문이다.

wolverine이라는 것에 관해서 가장 많은 정보를 담고 있는 페이지를 찾는 것과 wolverine 싸이트의 커먼 케이스를 찾는 것은 전혀 다른 일이라는 사실이 중요하다. 웹의 링크구조를 통해 텍스트의 매칭 점수를 전파해 나감으로써 어떤 주제를 자세하게 다룬 싸이트를 찾아내는 흥미로운 시스템이 있다.(Massimo Marchiori. The quest for correct information on the web: Hyper search engines.) 그 시스템은 그런 과정을 통해 가장 중심적인 경로에 포함되는 페이지들을 결과로 보여주는 것이다. 이런 방식은 "flower" 같은 질의어의 경우 좋은 결과를 보여 준다. 즉, 그 시스템은 '꽃'이라는 주제를 자세히 다루고 있는 싸이트에 도달할 수 있는 경로 중 가장 좋은 것을 보여주는 것이다. 이것과 커먼 케이스를 찾는 접근법을 비교해 보자. 커먼 케이스 접근법은 꽃에 관한 정보대신 꽃을 구입하는 방법만이 담긴, 사람들이 가장 많이 찾는 꽃 판매 싸이트를 보여줄 지도 모른다. 두 가지 방식 모두 중요하다는 게 우리의 생각이고, 일반적 목적의 웹 검색엔진이라면 마땅히 위의 두 가지 태스크 모두에 있어서 만족스러운 결과를 보여줘야 한다고 생각한다. 이 논문에서는, 우리는 커먼 케이스적 접근법에만 집중하고 있다.

5.5 커먼 케이스의 하부 구성요소(Subcomponents of Common Case)

페이지랭크가 도움이 될 수 있는 커먼 케이스 시나리오가 어떤 성격을 갖는가를 생각해 보는 것은 무척 유익하다. Wolverine Access 싸이트처럼 가장 자주 사용되는 페이지 외에도, 페이지랭크는 협동적 오쏘리티 또는 신뢰할 수 있는 싸이트 역시 표현해 준다. 예를 들어, 사용자는 어떤 뉴스가 단지 뉴욕 타임즈 홈 페이지로부터 직접 링크되어 있다는 이유만으로 더 선호할 수 있다. 물론, 그 뉴스 페이지는 뉴욕 타임즈처럼 중요도가 높은 페이지로부터 링크되어 있다는 사실만으로 매우 높은 페이지랭크 값을 갖게 된다. 이것은 일종의 협동적 신뢰(collaborative trust)의 특성을 잡아내고 있는 것처럼 보인다. 왜냐하면, 신뢰도가 높고 권위 있는 소스로부터 언급된 페이지일수록 그 페이지의 신뢰도와 권위가 올라가기 때문이다. 유사하게, 페이지의 품질이나 중요도 역시 이런 류의 순환적 정의에 잘 부합되는 것 같다.

6 개인화된 페이지랭크(Personalized PageRank)

페이지랭크 연산의 중요한 요소 중 하나가 E이다. E는, 랭크 싱크처럼 아웃엣지가 없는 싸이클을 보충하기 위한 랭크 소스 웹 페이지의 벡터다. 한편, E는 랭크 싱크 문제에 대한 해결책으로써뿐만 아니라, 페이지랭크 값을 조정할 수 있는 강력한 퍼래미터이기도 하다. 직관적으로 보자면, E 벡터는 랜덤 써퍼가 주기적으로 점프해 가는 웹 페이지의 분포에 해당한다. 밑에서 살펴 보겠지만, 이것은 웹을 거시적으로 관찰하거나 특정 부분에 대해 집중적이고 개인화된 관찰을 하는 데 사용될 수 있다.

우리가 수행한 실험은 대부분 E 벡터를 모든 웹 페이지에 걸쳐 균일하게 ||E||1 = 0.15로 가정했다. 즉, 랜덤 써퍼가 주기적으로 또 다른 랜덤 웹 페이지로 점프하는 것을 가정한 것이다. 이것은 모든 웹 페이지가 단지 존재하고 있다는 이유만으로 똑같이 가치를 부여받는 것이므로 E를 무척 민주적으로 선택한 것이다. 이런 테크닉이 상당히 성공적이었기는 했지만 중요한 문제점도 갖고 있다. 관련 링크가 많은 어떤 웹 페이지들이 지나치게 높은 랭킹을 받을 수 있는 문제다. 예컨데, 저작권 관련 페이지나 상호간에 링크가 많이 된 메일링 리스트 모음 등이 여기에 해당한다.

또 하나의 극단적 형태로, E를 오직 하나의 웹 페이지로만 구성할 수 있다. 우리는 두 가지로 실험해 보았다. 하나는 넷스케잎 홈 페이지로 해 보았고 다른 하나는 유명한 컴퓨터 과학자인 존 맥카씨(John McCarthy)의 홈 페이지로 했다. 넷스케잎의 홈 페이지로 한 실험은, 넷스케잎을 기본 홈 페이지로 하고 있는 초보 사용자의 시각에서 페이지의 랭크를 만들어 내려는 시도를 한 것이다. 존 맥카씨의 홈 페이지를 이용한 실험은, 그의 홈 페이지에 있는 링크를 바탕으로 우리에게 상당한 문맥적 정보를 제공한 개인의 시각에서 페이지랭크를 계산한 것이다.

두 경우 모두, 위에서 말한 메일링 리스트 문제가 나타나지 않았다. 그리고 두 경우 모두에서, 각각의 홈 페이지가 가장 높은 페이지랭크 값을 나타냈으며 그 페이지로부터 직접 연결된 페이지들이 그 뒤를 이엇다. 그 다음 시점부터는 불균형은 줄어 들었다. 표 2는 각각의 경우에서 여러 페이지들의 페이지랭크 퍼센타일을 나타낸 것이다. 컴퓨터 사이언스에 관계된 페이지일수록 넷스케잎 쪽 랭크보다 매카씨 랭 크쪽이 더 높은 값을 갖고, 특히 스탠포드 대학의 컴퓨터 사이언스 학과와 관계되는 페이지는 더욱 높은 매카씨 랭크 값을 갖는 것을 볼 수 있다. 예를 들어 스탠포드 컴퓨터 사이언스 학과의 또 다른 교수의 웹 페이지는 매카씨 쪽 랭크가 넷스케잎의 경우보다 6 퍼센타일 더 높다. 그리고 페이지랭크 값을 퍼센타일로 표시한 것에 주의하자. 이렇게 한 것은 상위 순위에서 나타나는 페이지랭크 값의 큰 차이를 줄여서 표현하기 위해서다.

Netscape vs McCarthy
표 2

위와 같은 개인화된 페이지랭크는 개인화된 검색엔진처럼 다양하게 응용할 수 있을 것이다. 개인화된 검색엔진은, 단순히 북마크나 홈 페이지를 입력하는 것만으로 사용자의 취향을 상당 부분 효과적으로 추측해내서 사용자의 수고를 대폭 덜어줄 수 있을 것이다. "Mitchell"이라는 질의어로 시행한 예를 부록 A에 수록했다. 그 예를 보면, 웹 상에 "Mitchell"이라는 이름을 가진 사람이 아주 많음에도, 존 매카씨 교수의 동료인 존 밋첼 교수의 홈 페이지가 결과의 1위로 나타난 것을 볼 수 있다.

6.1 상업적 이익을 위한 조작

이런 형태의 개인화된 페이지랭크는 상업적 이익을 위해 조작하는 것을 사실상 완전히 차단할 수 있다. 높은 페이지랭크 값을 갖기 위해서는 중요한 페이지로부터 언급되거나 중요하지 않은 많은 페이지로부터 링크되어야만 한다. 최악의 경우, 중요한 싸이트에서 광고(링크)를 구입하는 형태의 조작이 있을 수 있겠지만 그건 비용이 소요되므로 충분히 조절 가능하다. 조작에 대한 이런 저항성은 정말로 중요한 특성 중 하나다. 왜냐하면 상업적 조작 때문에 많은 검색엔진이 골머리를 앓고 있으며 훌륭한 기능을 임플리멘테이션하는 것이 조작 때문에 매우 어려워지기 때문이다. 예컨데, 문서가 자주 업데잇되는 것은 매우 바람직한 특징임에도 검색 결과를 조작하고자 하는 사람에 의해 이런 특징이 남용되고 있는 것이다.

균일한 E로 할 것인지 아니면 단일 페이지 E로 할 것인지의 절충안으로 E를 모든 웹 써버의 루트 수준 페이지로 구성할 수도 있다. `이 경우, 어느 정도의 페이지랭크 조작이 가능하다는 것에 주의해야 한다. 많은 루트 레벨 써버를 확보해서 특정 싸이트로 링크하면 간단히 조작되기 때문이다.

7 적용(Applicaitons)

7.1 웹 트래픽의 추산

페이지랭크는 대략 랜덤 웹 써퍼에 해당하기 때문에(섹션 2.5 참조), 페이지랭크가 실제 사용도와 어떻게 대응되는지 알아 보는 것은 아주 흥미로운 일이다. 우리는 NLANR(NLANR)의 프록시 캐쉬로부터 얻은 웹 페이지의 접근 횟수를 페이지랭크와 비교해 보았다. NLANR 데이타는 미 전역에 있는 프록시 캐쉬에 있는 여러 달에 걸쳐진 기록으로, 11,817,665개의 각기 다른 URL에 관한 자료이다. 그 데이타에 따르면 가장 히트가 높은 것은 알타비스타로 638,657 히트다. 그 데이타베이스는 우리가 갖고 있는 7500만 개 URL 데이타베이스와 260만 페이지가 중복된다. 이들 데이타셋을 분석, 비교하는 것은 몇 가지 이유에서 대단히 까다로운데, 우선 캐쉬 억세스 데이타에 있는 많은 URL들이 무료 이메일 서비스에 있는 개인 메일을 읽기 위해 접근한 것들이라는 점이 있다. 그리고 중복된 써버 이름과 페이지 이름도 심각한 문제점이다. 불완전성과 편향됨은 페이지랭크 데이타와 사용도 데이타 모두에서 문제가 된다. 하지만, 몇 가지 흥미로운 트렌드를 볼 수 있었다. 캐쉬 데이타에서는 포르노그래프 싸이트들이 높은 사용도를 보였음에도 이들의 페이지랭크 값은 대부분 낮았다. 이것은, 사람들이 자신의 웹 페이지에 포르토그래피 싸이트로 링크하는 것을 원하지 않기 때문인 것으로 생각된다. 그러므로 페이지랭크와 사용도 데이타 사이의 차이점을 살펴 보는 것을 통해, 사람들이 보고는 싶어하는데 자신의 웹 페이지에서는 언급하고 싶어 하지 않는 게 어떤 것이 있는지를 알아낼 수 있을 것이다. 어떤 싸이트는 매우 높은 사용도를 갖는데 페이지랭크가 낮은 경우가 있다. netscape.yahoo.com 같은 게 그렇다. 이것은 아마도 우리 데이타베이스에 중요한 백 링크가 누락되어 있기 때문인 것 같다. 우리 데이타베이스는 웹 링크 구조이 일부분만을 담고 있기 때문이다. 사용도 데이타를 페이지랭크 계산의 시작 벡터로 사용하고 페이지랭크 연산을 몇 차례 반복하는 것도 가능할 것이다. 이렇게 하면 사용도 데이타가 채워주지 못 한 부분을 메꿀 수 있을 것이다. 어떤 식이 되었든, 이런 형태의 비교는 향후 연구를 위한 흥미로운 주제이다.

7.2 백 링크 예측자로써의 페이지랭크

페이지랭크는 백 링크의 예측자로써의 의미가 있다. "Efficient crawling through url ordering"(Junghoo Cho, Hector Garcia Molina, and Lawrence Page) 논문에서, 우리는 어떻게 웹을 효율적으로 크롤링할 수 있는지, 더 좋은 문서들을 먼저 크롤링할 수 있는지의 문제를 탐색했다. 우리는 스탠포드 웹에서 시행한 테스트를 통해서 페이지랭크가 단순히 인용 횟수를 세는 것보다 훨씬 더 좋은 미래 인용 횟수의 예측자라는 것을 알게 되었다.

실험은, 다른 정보 없이 단일 URL에서 출발해서 가급적 최적의 순서에 가깝게 페이지를 크롤링하는 것을 목표로 하고 있다. 최적의 순서란 평가함수에 따른 랭크 순서와 정확히 일치하는 순서로 페이지를 크롤링하는 것이다. 이 실험에서의 평가함수는 완전한 정보가 주어졌을 때의 인용 횟수 순서로 했다. 문제는, 평가함수를 계산할 정보를 완전히 알게 되는 것은 모든 문서를 크롤링한 다음이라는 점이다. 이렇게 불완전한 데이타를 사용해서 크롤링 순서를 정할 때, 단순히 이미 알고 있는 인용 횟수를 활용하는 것보다 페이지랭크를 이용하는 쪽이 더 효과적인 것으로 드러났다. 바꿔 얘기하자면, 심지어 측정 기준이 인용횟수를 세는 것일지라도, 페이지랭크가 인용회수를 직접 세는 것보다 더 좋은 예측자라는 얘기다! 이것의 이유는 페이지랭크의 경우 인용 횟수를 세는 것이 국소적으로만 최대화되는 것을 피할 수 있기 때문인 것 같다. 예를 들어, 인용 횟수를 직접 세는 경우에는 스탠포드 CS 웹 페이지들의 컬렉션 속에만 빠져 드는 경향이 있어서 그곳을 벗어나 다른 곳에 있는 인용 회수가 높은 페이지를 찾아 나서는 데 오랜 시간이 걸린다. 하지만 페이지랭크는 스탠포드 홈 페이지가 중요하다는 것을 금방 알게 되고, 그 하부 페이지들에게 우호적인 점수를 주기 때문에 더 효율적이고 광범위한 검색이 가능한 것이다.

이러한 인용 횟수의 예측자로써의 페이지랭크의 능력은 페이지랭크를 사용해야 하는 아주 설득력 있는 이유가 된다. 웹의 인용구조를 완전히 매핑하는 것은 아주 까다롭기 때문에, 인용 횟수를 직접 세는 것보다 페이지랭크가 훨씬 더 좋은 인용 횟수 근사치가 될 수 있는 것이다.

7.3 사용자 네비게이션: 페이지랭크 프락시(User Navigation: The PageRank Proxy)

우리는 사용자가 각 링크의 페이지랭크와 함께 부가적인 설명을 볼 수 있는 웹 프락시 애플리케이션을 개발했다. 그 애플리케이션은 아주 유용했는데, 사용자가 링크를 클릭하기 전에 관련 정보를 미리 알 수 있기 때문이다. 그림 7은 프록시 프로그램의 스크린샷이다.빨간 바의 길이는 URL의 페이지랭크 값에 로그를 취한 값이다. 그림을 보면 스탠포드 대학 같은 메이져 조직은 매우 높은 랭킹을 받게 되고, 뒤이어 리서치 그룹이, 그 다음으로 개인이 -개인의 경우 스케일의 최상단에는 교수가 위치한다 - 나타남을 알 수 있다. 또한 ACM이 스탠포드 대학보다는 높지 않지만 매우 높은 페이지랭크를 갖는 것도 볼 수 있다. 재미있는 것은, 아주 지명도가 높은 교수의 페이지가 심할 정도로 낮은 페이지랭크 값을 갖고 있는 것을 찾으면 URL이 잘못 되어 있는 것을 찾아낼 수 있다는 점이다. 결과적으로, 프락시 툴은 네비게이션 뿐만 아니라 페이지 제작에도 도움이 될 수 있는 것 같다. 이 프락시 애플리케이션은 다른 검색엔진의 결과를 살펴 보는 데에도 아주 유용하다. 그리고 야후의 리스팅 같이 링크가 매우 많은 페이지를 파악하는 데도 큰 도움이 된다. 프락시를 통해서 많은 링크 중 어떤 것이 더 흥미로운 것인지를 짐작할 수 있기 때문이다. 또는 자신이 찾고 있는 링크가 "중요도" 측면에서 어느 정도인지를 알 수도 있고, 훨씬 더 빠르게 페이지를 전체적으로 살펴볼 수 있다.

PageRank Proxy
그림 7 페이지랭크 프락시

7.4 페이지랭크의 다른 용도

페이지랭크의 최초 목표는 백 링크를 정렬해서, 만약 어떤 문서가 많은 백 링크를 갖는다면 그 중 어떤 것이 "최상"의 것인지를 찾아서 그걸 가장 먼저 보여주려는 것이었다. 그리고 우리는 그런 시스템을 임플리멘테이션했다. 페이지랭크를 기준으로 정렬된 백 링크를 살펴 보는 것은 경쟁을 파악하는 측면에서도 아주 흥미롭다. 예를 들어, 뉴스 싸이트를 운영하는 사람이라면 경쟁자가 확보한 중요한 백 링크가 어떤 것인지 지속적으로 관찰하고자 할 것이다. 또한, 페이지랭크는 사용자가 어떤 싸이트가 신뢰할 수 있는 것인지 아닌지 판단하는 데 도움을 준다. 예를 들어, 스탠포드 홈 페이지에서 직접 인용된 정보라면 아무래도 사용자가 더 신뢰하려 할 것이다.

8 결론

이 논문에서, 우리는 웰드 와이드 웹 상의 모든 페이지를 페이지랭크라는 단일한 숫자로 압축하고자 하는 담대한 작업을 다루어 보았다. 페이지랭크는 페이지의 컨텐트와 상관없이, 오직 웹의 그래프 구조 상의 위치에만 의존하는 모든 웹 페이지의 글로벌 랭킹이다.

페이지랭크를 사용함으로써 우리는 더 중요하고 중심적인 웹 페이지들을 더욱 선호하는 식으로 검색 결과를 정렬할 수 있다. 여러 실험을 통해서, 페이지랭크는 고품질의 검색 결과를 보여줌을 알 수 있었다. 페이지랭크의 기반이 되는 직관은 웹 페이지 외부에 있는 정보, 즉 일종의 피어 리뷰인, 백 링크를 사용한다는 것이다. 게다가, "중요한" 페이지들로부터의 백 링크는 평균적인 페이지들로부터의 백 링크보다 더 중요하며, 이것은 페이지랭크의 재귀적인 정의(섹션 2.4 참조)를 통해 확실히 구현되어 있다.

페이지랭크는 대부분의 질의어에 대한 답변이 될 수 있는 소수의 자주 사용되는 문서들을 분리해 내는 데에도 사용될 수 있다. 풀 데이타베이스는 작은 데이타베이스가 질의어에 적절히 응답할 수 없을 때만 참조되면 된다. 마지막으로, 페이지랭크는 클러스터의 센터로 사용할 수 있는 대표 페이지를 찾아내는 좋은 방법이 될 수도 있을 것이다.

페이지랭크는 검색 외에도 트래픽 추산이나 사용자 네비게이션 같은 다른 많은 곳에 적용될 수 있다. 또한, 웹을 특정 시점에서 바라볼 수 있는 사용자화된 페이지랭크 역시 만들어 낼 수 있다.

종합하자면, 페이지랭크를 이용한 실험은 웹 그래프의 구조가 다양한 정보검색 작업에서 매우 유용하게 사용될 수 있음을 보여 준다고 할 수 있다.


문서출처: 이명헌 경영스쿨 http://www.emh.co.kr/xhtml/google_pagerank_citation_ranking.html

'Computer > Web' 카테고리의 다른 글

CSS3 미디어 쿼리  (0) 2012.07.07
반응형 웹(Responsive Web)  (0) 2012.07.07
구글 페이지랭크(PageRank) 알고리즘  (0) 2012.07.06
HTML5 WebStorage  (1) 2012.06.30
HTML5 주요기술  (0) 2012.06.29
HTML5 웹소켓  (4) 2012.06.29

댓글을 달아 주세요

posted by 희정냥★ 2012. 6. 30. 00:04

* HTML5 WebStorage


클라이언트측에 데이터를 저장할 수 있는 기능이다.

키/값 쌍으로 데이터가 저장되고 키를 기준으로 데이터를 조회한다.


로컬스토리지(Local Storage): 영구 데이터를 저장하는 용도로 사용

window 전역객체의 localStorage 컬렉션을 이용해서 접근할 수 있다.


세션스토리지(Session Storage): 브라우저 컨텍스트에서만 유지.

window 전역객체의 sessionStorage 컬렉션을 이용해서 접근할 수 있다.


기존의 쿠키와 많이 비슷하지만 다음과 같은 점이 개선되었다.


1. 네트워크 트래픽 감조: 웹스토리지는 저장된 데이터를 서버에 전송되지 않는다.

2. 더 많은 저장 용량: 쿠키는 데이터의 개수와 용량에 제한(한사이트당 20개,4KB)을 두고 있지만, 

무제한은 아니지만 훨씬 더 큰 자료를 저장할 수 있도록 제약이 적다.

3. 더 긴 데이터 보존 기간: 만료기간이 없으므로 한번 저장한 데이터는 영구적으로 보관된다.

4. 객체 저장: 쿠키는 문자열만 저장 가능하지만 웹스토리지는 객체를 저장할 수 있다.


<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
<title>HTML5-WebStorage</title>
<script type="text/javascript">


//Local Storage에 데이터 저장
function setLocalStorage(){
if(!!window['localStorage']){
var textBox = document.querySelector('#textBox1');
window.localStorage['key1'] = textBox.value;
}
}


//Local Storage 조회
function getLocalStorage(){
if(!!window['localStorage']){
var textBox = document.querySelector('#textBox2');
textBox.value = window.localStorage['key1'];
}
}

//Session Storage에 데이터 저장

function setSessionStorage(){
if(!!window['sessionStorage']){
var textBox = document.querySelector('#textBox3');
window.sessionStorage['key1'] = textBox.value;
}
}

//Session Storage 조회
function getSessionStorage(){
if(!!window['sessionStorage']){
var textBox = document.querySelector('#textBox4');
textBox.value = window.sessionStorage['key1'];
}
}
</script>
</head>
<body>
<input type="text" id="textBox1">
<button onclick="setLocalStorage()">Local Storage에 데이터 저장</button>
<br>
<input type="text" id="textBox2">
<button onclick="getLocalStorage()">Local Storage 조회</button>
<hr>

<input type="text" id="textBox3">
<button onclick="setSessionStorage()">Session Storage에 데이터 저장</button>
<br>
<input type="text" id="textBox4">
<button onclick="getSessionStorage()">Session Storage 조회</button>
</body>
</html>

'Computer > Web' 카테고리의 다른 글

반응형 웹(Responsive Web)  (0) 2012.07.07
구글 페이지랭크(PageRank) 알고리즘  (0) 2012.07.06
HTML5 WebStorage  (1) 2012.06.30
HTML5 주요기술  (0) 2012.06.29
HTML5 웹소켓  (4) 2012.06.29
CSS Box Model  (0) 2011.09.18

댓글을 달아 주세요

  1. 문정규 2012.07.17 20:30  Addr  Edit/Del  Reply

    좋은자료 잘 보고 갑니다.
    VD 근무하시군요? 반가워요.^^

posted by 희정냥★ 2012. 6. 29. 23:59

HTML5


-.  WebPage에서 WebApp로의 변화에 대응하는 해결책

-. 2012년 W3C에서 표준화 예정이나 현재 대부분 브라우저에서 제공.

   (IE는 버전 9에서 지원 예정, IE점유가 약한 모바일은 현재 지원한다고 보아야 함)

-. 현재 브라우저별 지원 수준이 틀리나, 향후 1 ~ 2년 내 변화 주시 필요.



HTML5의 주요기술


1. 캔버스

  -. 도형, 선, 글자, 이미지 등을 사각형에 그릴수 있다.

2. 웹 비디오

  -. 브라우저가 컨테이너와 코덱을 직접 지원한다.

3. 오프라인 웹App

  -. URL에 있는 리소를 PC 로컬에 캐싱하고 갱신한다.

  -. 인터넷 연결 단절시는 웹사이트가 아닌 로컬 캐싱에 접속한다.

4. 강력해진 웹폼

  -. 달력, 메일, 숫자, 진행바, 입력검증 기능 등을 테그가 지원한다.

5. 다양한 웹 App작성용 API

  -. Drag & Drop이 가능

  -. Communication api

  -. Web Storage: 로컬 저장소를 지원, 쿠기 수준 이상으로 용량 큼.

  -. Web Sql Database: 로컬 저장소를 SQL로 접근 가능한 랩퍼 제공, 현재 구글 기어.

  -. Web Workers: 백그라운드 프로세스 처리로, 쓰레딩이 가능.

  -. Web Socket

  -. Server Sent Events

  -. Geolocation API

  -. etc(file api, Xhttp…level2)


* 출처 : http://blog.naver.com/imdhnam?Redirect=Log&logNo=110104108968

'Computer > Web' 카테고리의 다른 글

구글 페이지랭크(PageRank) 알고리즘  (0) 2012.07.06
HTML5 WebStorage  (1) 2012.06.30
HTML5 주요기술  (0) 2012.06.29
HTML5 웹소켓  (4) 2012.06.29
CSS Box Model  (0) 2011.09.18
CSS 선택자  (0) 2011.09.18

댓글을 달아 주세요

posted by 희정냥★ 2012. 6. 29. 23:49

1. HTML5 웹소켓

- 서버측에서의 복잡한 프로그래밍 없이 웹을 통해서 일반적인 TCP소켓과 같이 실시간 연결지향 양방향 전이중 통신을 가능하게 하는 기술

- 기존 웹브라우져에서 서버로 데이터를 요청하는 방식에 비해, 서버에서 브라우저로 데이터 전송이 가능

- HTTP 통신에서, 서버 통신중에 발생하는 불필요한 데이터인  파일 '헤더' 부분을 최대 1/1000 가량 줄일수 있음

-  웹소켓 기술 업체 카징(Kaazing)에서는 '카징 케이트웨이 HTML5 에디션'  런칭 발표, 본격적인 웹 소겟 시대를 알림


 

2. 웹 소켓과 (Ajax의 통신 객체인) XMLHttpRequest 의 속도 비교

http://bloga.jp/ws/jq/wakachi/mecab/wakachi.html  (크롬 or 사파리에서 실행)

웹 소켓이 대략 50배 이상 좋은 성능을 나타냄



3. 웹 소켓이 필요한 경우

Your web application has data that must flow bi-directional simultaneously.

- 실시간 양방향 데이터 통신이 필요한 경우

Your web application must scale to large numbers of concurrent users.

- 많은 수의 동시 접속자를 수용해야 하는 경우

Your web application must extend TCP-based protocols to the browser.

- 브라우저에서 TCP 기반의 통신으로 확장해야 하는 경우

Your web application developers need an API that is easy to use.

- 개발자에게 사용하기 쉬운 API가 필요할 경우

Your web application must extend SOA over the Web and in the Cloud.

- 클라우드 환경이나 웹을 넘어 SOA 로 확장해야 하는 경우



4. 지원 브라우저

IE와 오페라를 제외한 사파리,크롬,파이어폭스 최신버전에서 웹 소켓을 지원



그림1. 브라우저별 Web Sockeet 지원 현황 (출처: http://caniuse.com/)



5. 웹소켓 구현

서버연결
HTML5가 제공하는 WebSocket 객체를 통해 서버 연결 수행.

일반 통신은 ws, 보안 통신은 wss 프로토콜을 이용.
기본 포트 역시 http,https와 동일한 80,443을 이용.
var wSocket = new WebSocket("ws://yourdomain/demo");

- 데이터 송신
서버와 연결이 되면 데이터를 주고 받을 수 있게 된다. 

WebSocket 객체의 send 함수로 데이터를 서버로 송신.
wSocket.send("송신 메시지");

데이터 수신
서버에서 푸시(전송)하는 데이터를 받으려면 message 이벤트를 구현.
wSocket.onmessage function(e){ //매개변수 e를 통해 수신된 데이터를 조회할 수 있다 }

- 이벤트 제공
-- open 이벤트: 연결이 설정되면 발생
-- close 이벤트: 연결이 끊어지면 발생

- 웹 소켓을 이용하는 클라이언트 코드의 전체 모습

<script>
  var wSocket = new WebSocket("ws:yourdomain/demo");
  
  wSocket.onmessage = function(e){  alert(e.data);  }  

  wSocket.onopen = function(e){ alert("서버 연결 완료"); } 
  wSocket.onclose = function(e){ alert("서버 연결 종료"); }  

  function send(){ //서버로 데이터를 전송하는 메서드
    wSocket.send("Hello");
  }
</script>



6. 웹소켓 서버

웹 소켓은 일반적인 TCP 소켓과는 다른 프로토콜로 설계되었다. 

따라서 웹소켓 서버 사양에 맞게 새로 구현해야 한다.

- 웹 소켓 서버를 위한 오픈소스 모듈
pywebsocket

phpwebsocket

jWebSocket

web-socket-ruby

Socket.IO-node



7.  jWebSocket를 이용한 모듈
- 라이브러리 다운로드 : http://jwebsocket.org/ 
- jWebSocketServer : 자바로 구현된 웹 소켓 서버모듈

- jWebSocketClient : 자바스크립트로 구현된 웹 소켓 클라이언트 데모 

- jWebSocketFullSource : jWebSocket 라이브러리의 전체 소스코드 



8. jWebSocketServer 구동
- 아파치 웹서버나 톰켓을 이용하여 구동

- Stand-Alone 구동

- java 설정

 -- jre 1.6 이상.

 -- PATH에 java.exe 등록.

 -- 환경변수에 JAVA_HOME 설정 : 자바 ROOT

 -- 환경변수에 JWEBSOCKET_HOME 설정 : jWebSocket 루트 디렉토리


- Stand-Alone로 구동 예제
1) 다운받는 jWebSocketServer을 압축해제 

2) bin 폴더에 있는 jWebSocketServer.bat 파일을 명령프롬프트에서 실행 

3)  웹 소켓 서버의 구동됨.

4) 웹 소켓 서버와의 통신로그와 디버그 메세지 기록됨.
5) 실행창을 닫으면 서버 종료

* 참고 퀵스타트 : http://code.google.com/p/jwebsocket/wiki/QuickStart



9. jWebSocketClient 데모 테스트
- jWebSocketClient 다운 후 압축해제
- 채팅데모인 chat.htm 을 실행

두 개의 크롬 브라우저에서 각각 로그인 한 뒤, 채팅하는 모습




jWebSocket 에서 서버 연결을 위해 다음과 같은 url을 정의하고 있다
var lURL = jws.JWS_SERVER_URL + "/;prot=json,timeout=360000";
...
JWS_SERVER_URL: "ws://" + ( self.location.hostname ? self.location.hostname : "localhost" ) + ":8787"

ws 프토토콜

localhost, 8787포트로 연결

json 포맷과 타임아웃이 설정


포트 등 변경시 : \conf\jWebSocket.xml 파일 수정

상태 검사 : ws.readState == WebSocket.OPEN / CONNECTING / CLOSED


* 출처 : http://m.mkexdev.net/98

http://blog.daum.net/hopefullife/241


'Computer > Web' 카테고리의 다른 글

HTML5 WebStorage  (1) 2012.06.30
HTML5 주요기술  (0) 2012.06.29
HTML5 웹소켓  (4) 2012.06.29
CSS Box Model  (0) 2011.09.18
CSS 선택자  (0) 2011.09.18
Web 2.0 기반의 Presentation On The Web  (0) 2009.08.06

댓글을 달아 주세요

  1. june 2012.07.10 15:04  Addr  Edit/Del  Reply

    안녕하세요^^ 정보 감사합니다. 혹시..개인적 질문인데... jwebsocket나 websocket을 통해서 파일전송 관련된 예제나 참고할 만한 자료 있는 곳을 아시나요? 그럼 좋은 하루 보내세요^^

  2. Brad 2012.11.16 04:45  Addr  Edit/Del  Reply

    저 SOA는 서비스 지향 아키텍쳐를 말씀하시는것 같습니다!?

  3. 김영규 2013.01.31 17:20  Addr  Edit/Del  Reply

    많은 도움이 되었습니다. 감사합니다.^^

  4. 우왕 2013.12.24 18:21  Addr  Edit/Del  Reply

    감사합니다..^^

posted by 희정냥★ 2012. 6. 20. 00:52

SSD(solid state driver)

 

1. SSD란?

1980년대에 등장한 SSD는 Solid State Disk 또는 Solid State Drive를 일컫는 말로써, NAND플래시 또는 DRAM 등 초고속 반도체 메모리를 저장 매체로 사용하는 대용량 저장 장치를 뜻한다. 여기서 말하는 초고속 반도체 메모리는 휴대폰, MP3, 메모리 카드, 디지털카메라 등에 사용되는 데이터 저장용 반도체 소자를 가리킨다. SSD는 기본적으로 메모리 카드와 동작 방식이 유사지만, HDD를 대체하기 위한 것이기 때문에 용량이 메모리 카드에 비해서 훨씬 크다. 보통 메모리 카드는 2G에서 8G 정도의 용량을 사용하지만, SSD는 32G에서 1TB(1,000GB) 정도의 대용량을 필요로 한다. 또한 기계적 장치인 HDD와는 달리 반도체를 이용해 정보를 저장한다. 임의 접근하여 탐색 시간 없이 고속으로 데이터를 입출력할 수 있으면서도 기계적 지연이나 실패율이 현저히 적다. 외부 충격으로 데이터가 손상되지 않으며 발열·소음과 전력 소모가 적고 소형화·경량화 할 수 있다는 것도 장점이다. 그러나 아직까지는 가격 경쟁력이 부족하여 고도의 안정성과 높은 데이터 처리 속도가 요구되는 군사, 항공우주, 선박과 같은 특수 분야에서 주로 사용되고 있다. 비싼 가격 문제가 해결된다면 HDD를 대신할 차세대 저장 장치가 될 것으로 전망된다.

 

 

2. SSD 장점

1) HDD에 비해 속도가 비약적으로 빠름.

이유는 HDD는 헤드를 물리적으로 움직이면서 쓰기 읽기를 하지만

SSD는 물리적인 헤드가 아니라 메모리칩과 컨트롤러로 작동하므로 속도가 빠르다.

 

2) 저발열 저전력 무소음 경량

발열은 거의 없다고 보면 되고 물리적 작동없이 순수 메모리칩들이기 때문에 소음이 있을 수 없다.

그리고 하드에 비해 전기소모도 적으므로 모바일 컴퓨팅에겐 유리한 세팅이다.

하드보다 가벼우므로 ssd세팅시 조금이라도 더 노트북이 가벼워진다.

 

3) 일반인들에겐 반영구적인 수명

물리적인 하드는 보통 일반인기준 4~5년이 지나면 소음이 심해지고 노화가 되며 속도도 조금 떨어진다.

이유는 섹터들이나 하드들이 노후되기 때문이다.

하지만 ssd는 메모리칩이라 거의 꾸준한 성능을 내고 쓰기 횟수가 정해져있긴 하지만

일반인이 신경쓸 정도로 작은수치는 아니며 계산데로라면 수십년써도 되는 그럼 수명이다.

 

4) 충격에 강하다

메모리칩이고 헤드 등 이런 유동적 장치가 없기에 충격에 강하다.

usb가 충격에 강한것과 같다.


5) 조각모음이 필요없다

헤드가 직접 자료를 찾아가는 방식이 아닌 즉각적으로 메모리칩에서 자료가 바로바로 반응하는 타입이다.

 

 

3. SSD 방식

- SLC(Single Level Cell)

메모리 최소 저장공간인 Cell 에 전하 유무(0,1)로 정보를 표현한다.

(1개의 기억소자(셀)에 1비트만 기억가능)

트랜지스터의 게이트에 한가지 전압 레벨로 셀당 1 bit 를 저장하는 기술이다.

기억소자의 열화나 노이즈에 대한 내성이 강함.

비트당 단가가 비싸다.

다이(Die) 크기가 크다

평균 수명 : Write 횟수 약 10만회

 

- MLC(Multi Level Cell)

메모리 최소 저장공간인 Cell 에 전하의 유무(00,11)와 전하량(01,10)에 따라 정보를 표현한다.

Flash Memory chip 에서 Cell 당 다수의 bit 를 저장하는 기술.

트랜지스터의 게이트를 다수의 전압 레벨로 변화시켜 셀당 다수의 비트를 저장하는 기술이다.

셀당 레셀 수에 따라 저장능력은 증가하지만 다이(Die) 크기는 별로 커지지 않는다.

다중셀로 갈수록 전압레벨을 변화하는 기술이 어렵다.

 SLC제품에 비해 저렴한 대용량 제품을 제조할 수 있는 장점이 있다.

기억소자의 열화나 노이즈에 의해 전하량이 불안정하면 잘못된 값으로 읽혀 SLC형에 비해 신뢰성이 떨어지는 단점이 있다.

평균 수명 : Write 횟수 약 2~3만회

 

 


 

 

4. SSD 구조

 

 

 

5. SSD 성능 최적화 방법

1) 바이오스 설정에서 AHCI 방식 선택

 

AHCI란?

고급 호스트 컨트롤러 인터페이스(Advanced Host Controller Interface, AHCI)는 소프트웨어가, 병렬 구조의 ATA(PATA)에서 제공되는 않는 기능(핫 플러깅 등)을 제공하도록 설계된 호스트 버스 어댑터와 같은 시리얼 ATA (SATA) 장치들과 신호를 주고 받을 수 있도록 만든 하드웨어 구조를 뜻한다. 이 규격은 시스템 메모리와 장치 사이의 데이터 전송을 목적으로 컴퓨터 하드웨어 제조업체들을 위한 시스템 메모리 구조를 자세하게 명시해 놓고 있다. 현재의 규격 버전은 2008년 6월 v1.3이다.[1]

많은 SATA 컨트롤러들은 AHCI만 따로, 또는 RAID 지원과 결합하여 사용할 수 있다. 인텔은 자사 메인보드에 AHCI/SATA 모드보다 AHCI와 더불어 RAID 모드를 선택할 것을 권하고 있다.[2]

AHCI는 마이크로소프트 윈도 비스타, 7과, 커널 2.6.19의 리눅스 운영 체제에서 완전히 지원된다. AHCI 지원은 윈도 XP 미디어 센터 에디션부터 지원한다. (별도의 드라이버 설치를 하지 않는 한 유일하게 지원하는 XP 버전이다) 더 오래된 운영 체제들이 AHCI를 지원하게 하려면 호스트 버스 어댑터 제조업체가 제공하는 드라이버를 사용해야 한다.


 

2) 조각모음 해제

 

3) 복원기능 해제

 

4) 페이징 파일 용량 줄이기

 

5) 최대절전모드 해제

 

6) 전원옵션 설정에서 고성능으로 변경

 

7) 색인 기능 비활성화

 

 

6. 트림

 

트림이란?

SSD에 기록되어진 데이터중 불필요한 데이터를 삭제해 주는 기술이다.

 

SSD 는 내부에 데이터가 일정수준까지 채워지게 되면 성능 저하 현상이 발생하게 되는데 그 원인은 낸드플레시의 특성상 바로 오버라이트(덮어쓰기) 되지 않는 특성과 SSD 컨트롤러에 관리하지 않아도 되는 불필요한 쓰레기 데이터로 인해서 부하가 발생하기 되기 때문이다. 따라서 SSD가 입출력 작업을 하는 경우 되도록 많은 양의 클린상태(기록되어 있지 않은)의 셀을 확보하고 내부에 불필요한 쓰레기 데이터를 SSD컨트롤러가 관리하지 않도록 관리해 줄 필요성이 있게 된다.

 

하지만 기존 OS(VISTA이전 세대)의 경우 HDD만을 예상하고 있었기 때문에 OS차원에서 데이터 삭제 명령을 하더라도 실제로 저장 매체에서 해당 데이터가 삭제되는 것이 아닌 저장위치기록만 삭제 되기 때문에 데이터 영역에 불필요한 데이터가 그대로 남아 있는 상태가 지속이 된다. 물론 바로 오버라이트가 가능한 HDD의 경우에는 이러한 것이 문제가 되지 않지만 그와는 달리 SSD에 그대로 적용할 경우 위에서 살펴 본 SSD의 특성에 기인해서 성능저하가 발생할 가능성이 생기게 되기 때문에 SSD 적합하도록 OS 상에서 데이터 삭제 명령시 실제 데이터 영역의 데이터까지 삭제하도록 명령이 내려지도록 고안된 것이 트림커맨드 기술이라고 할 수 있다. 이 기술을 통해서 SSD의 성능 저하를 완화 시키는 역할을 하게 된다.

 

요약하자면 HDD가 기존 데이터에 덮어쓰기가 되는것과 달리 SSD는 데이터를 기록하기 위해서 빈셀이 없으면 기존 셀을 지우고 기록하게 된다. 따라서 데이터 영역이 모두 채워져 있으면 쓰기속도 저하로 이어지게 되는데 이러한 상태를 최대한 완하 시키기 위해서 바로 바로 셀을 비워 주는 트림커맨드라는 기술을 도입해서 성능저하를 완화 시키는 것이다.


셀을 실제로 지우는 시간만큼의 시간만이 더 걸릴 뿐이며 읽기 속도와 SSD의 수명에는 지장이 없다.

 

트림 설정 확인 방법 : cmd 창에서 "fsutil behavior query DisableDeleteNotify" 를 입력.

 

 

7. 참고 링크

http://terms.naver.com/entry.nhn?docId=300469&mobile&categoryId=388

http://blog.naver.com/sfoods?Redirect=Log&logNo=147735773

http://navercast.naver.com/contents.nhn?contents_id=5081

http://blog.naver.com/mercurian21?Redirect=Log&logNo=30023702646

 

 

 

 

 

댓글을 달아 주세요

posted by 희정냥★ 2011. 9. 18. 23:15

각각의 엘리먼트를 문서에 배치하기 위해서는 Box Model 이라고 부르는 margin, padding 그리고 border 속성을 전체적으로 이해해야 합니다.

 

위의 그림에서 중요한 4가지는 content, padding, border, margin 입니다.

content : 순수한 콘텐츠
padding : 콘텐츠와 경계선 사이의 여백
border : 경계선
margin : 경계선 밖에서 박스모델의 최종 경계선까지의 여백
 

 <table width="300" cellpadding="0" cellspacing="0" border="0" align="center">
<tr>
 <td bgcolor="#EEEEEE">
  <div style="padding:10px; margin:10px; border:1px gray solid;">Box Model을 설명하기 위한 예제</div>
 </td>
</tr>
</table>
이 예제에서 padding값과 margin값을 변경해 보면 이 값이 어떤 부분을 의미하는지 이해할 수 있습니다.

'Computer > Web' 카테고리의 다른 글

HTML5 주요기술  (0) 2012.06.29
HTML5 웹소켓  (4) 2012.06.29
CSS Box Model  (0) 2011.09.18
CSS 선택자  (0) 2011.09.18
Web 2.0 기반의 Presentation On The Web  (0) 2009.08.06
syntaxhighlighter를 tistory에서 사용 하는 방법  (0) 2008.10.08

댓글을 달아 주세요

posted by 희정냥★ 2011. 9. 18. 23:13
CSS에서 가장 중요한 개념은 선택자(Selector)라고 할 수 있습니다. 선택자(Selector)가 있어야 선언된 CSS가 어디에 적용될지를 결정할 수 있기 때문입니다. 특히 CSS는 상속의 개념을 가지므로 선택자(Selector)에 대한 확실한 이해가 없이는 CSS를 제대로 활용하지 못합니다.

선택자(Selector)의 종류

선택자(Selector)는 아래와 같이 4개로 나누어볼 수 있습니다.

공통 선택자(Universal Selector)
타입 선택자(Type Selector)
ID 선택자(ID Selector)
Class 선택자(Class Selector)
 

공통 선택자(Universal Selector)
공통 선택자(Universal Selector)는 *로 표현되는 선택자입니다.

* { color: gray; }
위와 같이 정의하면 모든 element 에 color: gray; 라는 스타일을 지정한다는 의미입니다.

 

타입 선택자(Type Selector)
타입 선택자(Type Selector)는 p, div, span, table, td, form...등과 같은 HTML 태그를 선택하는 선택자 입니다.

p { color: gray; }
이런식으로 정의하면 P element에 color: gray; 라는 스타일을 지정한다는 의미입니다.

 

ID 선택자(ID Selector)
#이라는 지시어를 사용하면서 element의 아이디값을 지정해주면 됩니다. 즉 특정 element에만 스타일을 지정한다는 의미입니다. 

#gray_text { color: gray; }
위와 같이 지정하면 id 값이 gray_text 인 element에만 스타일이 적용됩니다.

 

Class 선택자(Class Selector)
.이라는 지시어를 사용하면서 element의 클래스값을 지정해주면 됩니다. 특정 element에만 스타일을 지정한다는 의미로 ID 선택자와 차이점이라면 클래스의 경우는 한 문서에 동일한 이름의 클래스가 여러개 위치해도 괜찮으나 아이디는 유일해야 한다는 차이가 있습니다.

.gray_text { color: gray; }
위와 같이 지정하면 클래스 값이 gray_text 인 element에만 스타일이 적용됩니다.

 

'Computer > Web' 카테고리의 다른 글

HTML5 웹소켓  (4) 2012.06.29
CSS Box Model  (0) 2011.09.18
CSS 선택자  (0) 2011.09.18
Web 2.0 기반의 Presentation On The Web  (0) 2009.08.06
syntaxhighlighter를 tistory에서 사용 하는 방법  (0) 2008.10.08
IE6,IE7 ,FireFox 에 대해 CSS 맞추기  (0) 2008.07.09

댓글을 달아 주세요

posted by 희정냥★ 2011. 9. 12. 21:36
터미널 실행 후 sudo nano /private/etc/hosts 입력 하고 enter!

내용을 수정 후 ctrl + o 누른 후 enter! (Write Out)

ctrl + x 로 빠져나감. (exit)

내용 적용하려면 재부팅 하거나

dscacheutil -flushcache 입력후 enter 해서 바로 적용.


댓글을 달아 주세요

posted by 희정냥★ 2011. 9. 12. 21:32
터미널을 열고
defaults write .GlobalPreferences com.apple.mouse.scaling -21000
치고 엔터!

그리고 리붓 한번 하면 적용 됩니다.
21000 숫자를 조절하여 감도를 알맞게 바꿀수 있고
원래 상태로 돌리고 싶을땐 시스템 환경설정(마우스, 손쉬운 사용... ), better touch tool 등으로 감도 조절하면 됩니다.

댓글을 달아 주세요

posted by 희정냥★ 2010. 3. 11. 23:08
2010년 3월 11일 목요일 오후 8시~10시 강남토즈

Rebecca Wirfs-Brock을 만나다.

이번에 한국의 모 전자 기업에 강의하러 한국에 들르셨다구 하네요.

김창준님께서 급히 자리를 마련해주신 덕분에 Rebecca를 직접 만날 수 있었고, 그녀의 얘기를 들을 수 있었습니다. 저에겐 무척 영광이였죠.

Xper 모임의 많은 분들이 참석해주셨습니다. (대략 30명쯤 될듯...?)

참석한 사람들이 Rebecca에게 궁금한 것을 질문했고, 그녀는 질문에 대답하는 형태로 이루어졌습니다.

주로 아키텍트로써 자신의 경험, 자신의 생각들을 얘기 했던것 같습니다.

영어가 짧아서 잘 이해하진 못했지만 ㅠ
중간중간에 김창준님이 설명해주신 덕분에 그나마 이해를 할수 있었습니다 ㅠ

참 멋지신 분입니다 ^^




최승준님이 iPhone으로 찍어서 Xper 그룹 메일링리스트로 보내주신 사진 입니다. ㅎ

이번에도 역시 싸인을 받았습니다. >.<

TAG

댓글을 달아 주세요

posted by 희정냥★ 2010. 1. 7. 11:31
Flex 3 Builder 에서 as, mxml 소스를 자동정렬 해주는 플러그인입니다.

사용방법>

1. 첨부파일을 다운받은 후 압축을 풉니다.

2. Flex 3 Builder 설치 폴더 내의 plugins 폴더에 압축 푼 후 나오는 3개의 jar파일을 복사시켜 줍니다.

(저의 경우는 C:\Program Files\Adobe\Flex Builder 3\plugins 경로입니다.)

3. Flex 3 Builder 를 다시 시작합니다.

4. Flex 3 Builder의 Window 메뉴에 Preferences... 를 선택합니다.

5. "Flex Formatting" 이라는 새로운 항목이 추가됐을껍니다.

거기서 자신에 맞게 설정한 후 사용하시면 됩니다.


사용해보니 완전 편해요^^

'Computer > FLEX' 카테고리의 다른 글

(FLEX) as, mxml 자동정렬 플러그인  (1) 2010.01.07
FLEX에 움직이는 GIF 넣기  (3) 2010.01.07

댓글을 달아 주세요

  1. 2010.01.20 10:22  Addr  Edit/Del  Reply

    비밀댓글입니다

posted by 희정냥★ 2010. 1. 7. 11:15


첨부한 파일을 다운 받아서 프로젝트에 넣어주시구요.

(출처 : http://flexology.wordpress.com/2008/09/30/loadinganimated_gif_in_flex/ )

AnimatedGIFImage.as 파일을 추가합니다.
소스는 아래와 같습니다.

package gif
{
 import flash.net.URLRequest;

 import mx.controls.Image;
 import mx.core.UIComponent;

 import org.gif.player.GIFPlayer;

 public class AnimatedGIFImage extends Image
 {
  private var _gifImage:UIComponent;

  public function AnimatedGIFImage()
  {
   super();
   this._gifImage=new UIComponent();
  }

  override public function set source(value:Object):void
  {
   if (!value is String)
   {
    throw new ArgumentError("Source must be of type String");
   }

   super.source=value;
  }

  override protected function createChildren():void
  {
   super.createChildren();
   var player:GIFPlayer=new GIFPlayer();
   player.load(new URLRequest(this.source as String));
   this._gifImage.addChild(player);
  }

  override protected function updateDisplayList(unscaledWidth:Number, unscaledHeight:Number):void
  {
   this.addChild(this._gifImage);
   super.updateDisplayList(unscaledWidth, unscaledHeight);
  }
 }
}

그리고 사용하실땐
<gif:AnimatedGIFImage source="test.gif" width="100" height="100"/> 와 같이 사용하시면 됩니다.

'Computer > FLEX' 카테고리의 다른 글

(FLEX) as, mxml 자동정렬 플러그인  (1) 2010.01.07
FLEX에 움직이는 GIF 넣기  (3) 2010.01.07

댓글을 달아 주세요

  1. duubuu 2010.07.30 15:14  Addr  Edit/Del  Reply

    헤매다가 겨우 찾았어요 ㅠㅠ
    아 감격의 눈물ㅠㅠㅠㅠ
    정보 감사합니다 ㅎㅎ

  2. BlogIcon 아범맨 2010.08.04 11:10  Addr  Edit/Del  Reply

    와 ~ 유용한 정보 잘 공유하여 갑니다 ~ ^^

  3. ff 2011.08.12 16:21  Addr  Edit/Del  Reply

    첨부파일이 어딨죠?ㅠㅠ

posted by 희정냥★ 2009. 9. 5. 14:07

2009년 9월 4일 금요일 오전 9시 30분 - 오후 5시 과학기술회관 대회의실
켄트벡의 Responsive Design 세미나가 있어서 듣고 왔습니다.

* Responsive Design: When, How, and What (반응적 설계 : 언제, 어떻게, 무엇을 : http://agile.egloos.com/5087979

아래 링크에서도 Responsive Design 동영상 강의를 들을 수 있습니다.


처음엔 김창준님이 켄트벡을 소개하는 시간이 있었습니다.

켄트벡의 강의가 시작됩니다.

전날 삼성 SDS에서도 같은 주제의 세미나가 3시간동안 있었는데,
두번 들으니까 아주 조금 이해 가네요.. -_-;;
이것이 쪼랩과 만랩의 차이인가요..;; ㄷㄷ



* 질문, 답변
질문, 답변은 미리 온라인으로 받은 질문과,
현장에서 포스트잇으로 사람들이 적은 질문 중 몇개를 뽑아서 답변을 했습니다.
그리고 질문있는 사람이 손 들어서 질문을 하기도 했습니다.



* 사진 한번 더 찍었습니다. ㅋ



* 정리... 는 다음에...

댓글을 달아 주세요

  1. BlogIcon 강성희 2009.09.08 00:07 신고  Addr  Edit/Del  Reply

    블로그 스킨이 저와 똑같아서 깜짝 놀랐네요 ㅎㅎ.
    정말 인상깊은 강연이었습니다 ^^

  2. 레드 2009.12.23 15:33  Addr  Edit/Del  Reply

    요샌.. 새글이 없네요~~ = .=

posted by 희정냥★ 2009. 9. 4. 19:31
2009년 9월 3일 목요일 오후 8시 - 10시 토즈 강남대로

9월 4일(금)에 있을 켄트벡 세미나에 앞서 켄트벡 미리 만나보기 행사가 있어서
참여하게 되었습니다.
켄트벡은 가족들과 함께 왔었고, 
기술적인 얘기보다는 주로 친근한(?) 이야기를 하는 시간이였습니다.

켄트벡과 가족들입니다.

발레하는 가족 사진입니다 ㅋ 너무 보기 좋네요.


* 첫시간
핑퐁 방식으로
켄트벡 가족들이 참가자들에게, 참가자들이 켄트벡 가족들에게
번갈아가며 질문/답변 하는 시간을 가졌습니다.

* 둘째시간
3~4명씩 조를 짜서 즉흥연기를 통해 질문을 보여주면
켄트벡이 그것을 보고 질문을 판단해서 대답하는 것입니다.





* 시상
조별 역활극을 보고 켄트벡 가족들이 가장 잘한 조를 뽑았습니다.

지금은 심사 중..


그리고 뽑힌 조원들에게는 켄트벡 사인을 한 테스트 주도 개발 책을 선물로 주었습니다.

가족간의 갈등을 어떻게 해결하나에 대한 역활극이 1등을 하였습니다.
켄트벡의 아이들이 켄트벡과 놀아달라고 하지만
일이 바쁘다고 놀아주지 못하는 (ㅡ_ㅡ;;) 그런 내용이였던것 같습니다.

켄트벡은 일도 중요하지만 가족들과 함께 보내는 시간을 많이 가져야 한다고 했습니다.
늘 가족들과 함께 다니는 모습이 보기 좋았고, 가족의 소중함을 돌아볼 수 있었습니다.

그리고,,
익스트림 프로그래밍의 공동 저자이자 부부인
켄트벡, 신시아 안드레스의 사인을 받았습니다!





켄트벡과 함께 사진도! ㅎㅎ
옆에는 사내 애자일 커뮤니티 운영자이시자
함께 QSM 스터디를 하시는 조현길님 >.<



댓글을 달아 주세요

  1. leeme@boanin.com 2009.09.07 09:35  Addr  Edit/Del  Reply

    안녕하세요 지나가다 우연히 봤네요
    그때 질문으로 1등했던 조의 조원입니다.
    저희가 생각했던 질문은 "바쁜 일정 중에 본인 만을 위한 시간은 어떻게 하시나요?" 였는데
    잘 전달이 안됐더라구요
    진실은 저희 조 만이 안다는;;

posted by 희정냥★ 2009. 8. 30. 20:00

냐호호홋~ 드디어 제주도에 갔다 왔습니다~

즐거운 데브데이 ~ 랄랄라~





일정이 아래와 같았구요,


8월 28일(금)

시간 내용 비고
 ~ 05:50 공항 집결 장소 : 김포공항 
 ~ 07:50 김포공항 → 제주공항  
 ~ 08:50 인원파악 및 GMC로 이동  아침식사 : 샌드위치
 ~ 10:00 팀 및 프로젝트 소개  페차쿠차 형식(슬라이드당 20초, 4장)
 장소 : GMC 미디어홀
 ~ 10:30 GMC 투어  
 ~ 10:50 휴식  
 ~ 12:30 발표세션 장소 : GMC 미디어홀
 ~ 13:30 점심시간 장소 : GMC 다이닝룸
 ~ 19:00 개별 프로젝트  
 ~ 20:30 저녁식사 장소 : GMC 바베큐장
 ~ 21:30 프로젝트 마무리 및 발표 준비  
 ~ 23:00 발표 및 시상 장소 : GMC 바베큐장 or 미디어홀
 ~ 00:30 Beer Party & OST 장소 : GMC 바베큐장
OST란?

8월 29일(토)

시간 내용 비고
 ~ 09:00 기상 및 아침식사 장소 : 탐라무문
 ~ 10:00 GMC → 한림공원  
 ~ 12:00 한림공원 관람 장소 : 한림공원
 ~ 13:00 점심식사  
 ~ 16:30 Beach Party 장소 : 협재해수욕장
 ~ 17:30 협재→제주공항  
 ~ 19:20 제주공항 → 인천공항  


 

8/28 (금)
* 공항으로 출발!
첫날 서울대에서 김포공항으로 가는 6003번 버스 4시 40분 첫차를 타고 갔습니다.
서울대 입구에서 4시 45분쯤에 탔구요, 5시 35분쯤에 김포공항 국내선 청사에 도착했습니다.
집합장소였던 국내선청사 2층 던킨도너츠 앞에 모여서, 
출석 체크 하고~ 표 받고~ 무슨 몸 수색하고 -_-;;
비행기를 탔습니다.
일기예보에는 금요일엔 비가 온다고 되어 있어서 걱정했는데, 다행히 비 안왔어요 ㅎㅎ
 

제주항공이였는데, 전 TV에서 커~다란 비행기만 봐서인지, 너무 귀엽더군요 ㅎㅎㅎ
셔틀버스를 타고 잠깐 이동한 뒤 비행기를 탔습니다.
슁~슁~

* 비행기안에서
창문자리 말고 그 옆자리를 앉았는데,
첫좌석이라서 앞에 공간이 조금 넓었고, 다리가 편했습니다.


창문밖으로 바라보는데 구름이 뭉개뭉개~
너무 신기하고 이뻤습니다.


그리고 제주공항에 도착했습니다.

* Daum GMC
제주공항에 내린 후 버스를 타고 다음 GMC에 도착!


노트북 하는 돌하루방이 반기더군요 ㅋ


아침은 간단히 샌드위치를 먹고, 행사 설명을 듣고, GMC 투어도 하고, 세미나도 듣고,
직원식당에서 점심을 먹었습니다~
GMC 건물은,,,
이쁘고, 여러가지 직원들을 위한 편의 시설이 많았습니다.



* 라이브 코딩
그 다음엔 라이브 코딩~ ㄱㄱㄱ
삽질삽질 끝없는 삽질과 ㅠㅠ
결국 아우풋은 안드로메다로 흘러가고 ㅠㅠ
발표할 생각하니 앞이 깜깜하고.. ㅠㅠ

* 저녁은 출장뷔페
저녁엔 바베큐장에서 출장뷔페로~ ㅋ


완소희정냥사랑 회랑 초밥도 있더군요 ㅠㅠ
맛있게 잘 먹었습니다 ㅋㅋ

* 프로젝트 발표
이후 프로젝트 발표를 했습니다.
프로젝트 발표는 필수인지 알았는데, 지원이었습니다.
참가한 대부분의 팀들이 다 발표를 했던것 같습니다.
저는 하루죙일 삽질만 하다가 완성도 다 못했고, 별로 보여줄만한것도 없어서
뽀샵 + PPT로 발표할만한걸 만들었는데, 차마 발표하기 부끄러워서 지원하지 않았습니다. -_-;;
그런데 발표가 끝나니, 발표한 팀에겐 다음 쿠션을 선물로 주더군요 ㅠㅠㅠㅠㅠㅠㅠㅠ
다음 쿠션 준다는 사실을 알았더라면 제일 먼저 손번쩍 들고 발표할꺼라고 했을텐데
너무 아쉬워서 눈물이 줄줄줄... ㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠㅠ

* 바베큐장에서 Beer Party
맥주 동호회에서 만든 맥주를 간단한 안주와 함께 먹으며 대화를 나눴던 시간입니다.
저는 몸이 안좋아서 일찍 숙소로 들어갔는데, 사람들 말로는 새벽 5시에 종료되었다는.. -_-;

* 민박


잠은 GMC 근처 민박집에서 잤습니다.
주위에는 풀들과 나무들이.. ;; 있고.. 자연과 함께 하는 민박집이였습니다;;


8/29 (토)
* 아침 전복죽
아침은 민박집 식당인듯한 곳에서 전복죽을 먹었습니다~


전복죽 처음 먹어봤어요 -0-;; ㅋㅋㅋㅋ
한그릇 다 비웠습니다~ 만세~

* 한림공원 구경 ㅋ
그 다음엔 단체로 버스타고 한림공원으로 이동했습니다.

쭉~ 둘러봤는데
너무 신기한 식물들과 나무들이 많았습니다.


TV에서만 보던 나무들을 실제로 보니 감동... *.*


동굴도 가보고.. ㅎㅎㅎ


그런데 시간이 조금 부족해서 다 둘러보진 못했습니다.
생각보다 넓더군욤..;;


지금은 얼음놀이 중 ㅋㅋ

* 점심은 흑돼지??
한림공원 내 식당에서 고기와 함께 점심을 먹었는데,
고기 너무 맛있었습니다;;; 흑돼지 삼겹살이라고 하던데 맞나요~?


빈민층 희정냥은 흑돼지도 처음 먹어보는 ㄷㄷㄷ
이것도 한그릇 다 비웠습니다~ 만세만세~

* 오후엔 협재해수욕장~
정말 그림같은 바다였습니다~


애매랄드빛 바다~ 대감동 ㅠㅠ


바다 너무 이쁘고 모래도 고와서 수영도 하고 모래장난도 치고.. ㅎ
초딩플레이를... ㄷㄷㄷ


튜브 5천원 주고 빌려서, 튜브끼고 바둥바둥 거리며 파도따라 밀려내리기놀이 했습니다 -_-;


다른 분들은 협재 해수욕장에서 다시 버스타고 제주공항으로 이동했지만,
전 서울로 돌아가는 날을 30일(일)로 신청해서,
여기서 계속 놀았습니다. ㅎ

돌아가는 날을 자신이 선택할 수 있었거든요 ㅎ
이후 제주도 여행을 하다 30일 비행기 타고 집으로 돌아왔습니다 ㅎ

* DevDay - 좋았던점
말로만 듣던 GMC 구경도 할 수 있었고, 다양한 사람들을 만날수 있어서 좋았습니다.
발표를 통해 여러 플젝들을 공유할 수 있었던 점도 좋았습니다.
그리고 제주도 관광도 너무 좋았어요 >.< 꺄악~ >.<

* DevDay - 아쉬운 점
이건 제 개인적인거지만,
내내 삽질만 하다 완성도 못하고 발표도 못하고 선물도 못받은게 너무 아쉽습니다 ㅠㅠ
나름 꼭 만들어보고 싶은 플젝인데
기회가 된다면 내년에도 참가해서
꼭꼭 완성해서 멋지게 보여드리고 싶습니다~
과연 내년에도 참가할 수 있을가요 ㅠ_ㅠ?

* 득템목록 자랑질 ㅋ
기념사진 촬영 퍼즐과 메모장!


그리고 이건 질문에 답하면 선물준다길래 번쩍 손들고 답해서 받은 메모책(?)




이번 데브데이 너무 즐거웠습니다~~~~~~ 
좋은 여름 휴가가 되었습니다 ㅋ
감사합니다 ㅎㅎ
이상~!

* Daum DevDay : http://dna.daum.net/archives/581

이 장소를 Daum지도에서 확인해보세요.
제주 제주시 아라동 | 다음글로벌미디어센터
도움말 Daum 지도

댓글을 달아 주세요

  1. BlogIcon 영맹's 2009.09.01 15:30 신고  Addr  Edit/Del  Reply

    안녕하세요 희정님 Staff 였던 이영민입니다. ;
    후기 캄사 합니다. ~~~ ㅎㅎ

    덧 : 쿠션은 =ㅁ=;; 죄송합니다. 미리 공지 드릴껄 ...

    덧 2 : 죄송하지만 저희 내부적으로도 후기를 작성할까 하는데 . 희정님 사진을 몇개 사용해도 될까요 ?

    좋은 하루 되세요 :)

  2. BlogIcon jollaman999~!! 2009.09.04 18:11  Addr  Edit/Del  Reply

    ㅎㅎ 즐거운 여행이었겠어요...

    그나저나 저 Daum 앞에 놓인 노트북하시는 돌하르방 님이 볼때마다 귀엽군요...ㅋㅋ ^^;;

  3. BlogIcon 타돌이 2009.09.04 23:47  Addr  Edit/Del  Reply

    안녕하세요. DNA Lab 이승철입니다.
    후기 잘 쓰셨네욤~ 잘 보고 가욤~!^^

posted by 희정냥★ 2009. 8. 19. 16:07




이클립스와 GoF의 에릭 감마가 한국에 온다길래
또 냉큼냉큼 갔습니다 -0-

첫번째 시간은 위의 아젠다대로 Jazz의 소개였구요,
두번째 시간은 Q&A 시간을 가졌습니다~
Q&A에서는 정말 많은 분들이 질문을 해주셨어요;


동시통역도 신기했습니당.. ㄷㄷ
질문, 답변때도 다 통역해주시더군요.
통역하시는분 정말 깜놀이였어요.. *.*


내용은 다음에 정리하기로 하고, 일단 사진부터.. ㅋㅋㅋ

에릭 감마의 싸인을 받고 함께 사진을 찍었던 역사적인 순간입니다 ㅠ



첫시간 발표중인 에릭 감마 ㅋ




에릭에게 무엇이든 물어보세요 시간 ㅋ




우연히 만난 윤석씨(포항공대 연구소에서 함께 일했었던;)와 그의 인턴들(-_-;;).. ㅋ
함께 사진 찍었습니다 ㅎ
저 너무 이상하게 생겼음.. ㅠㅠ




기념품으로 받은 마우스패드에 싸인 받았어요 ㅋ
손목 많이 아팠는데 손목도 받치면서 잘 쓰고 있어요 ㅋㅋ




요고는 교재!



댓글을 달아 주세요

  1. jindog 2009.08.20 09:39  Addr  Edit/Del  Reply

    잘 알려진 네임드 몹 2분을 다 만나시다니 orz 부럽...

  2. BlogIcon 아름프로 2009.08.25 23:41  Addr  Edit/Del  Reply

    후기 잘 봤습니다. 후기를 jazzlab.net 에 링크 걸었습니다.
    혹시 삭제 원하시면 말씀주세요. 감사합니다.

  3. BlogIcon 정의의소 2009.08.26 16:44  Addr  Edit/Del  Reply

    희정씨 블로그가 여기군요... 제가 누굴까요? ㅎㅎㅎ ^^;

posted by 희정냥★ 2009. 8. 15. 22:41

일시: 8.15 토요일(오후 4시 - 6시)
장소: 동숭동 제로원 디자인 센터

이번에 있었던 Sharing Experiences 2009 Exhibition에 갔다왔습니다.^^

첫날 컨퍼런스에서 가서 여러가지 강의를 들었다면,
이번엔 3일간의 워크샵을 통해 직접 구현해본 작품들을 보았습니다.
재미있는 아이디어와 작품이 많이 있었습니다.
시간 부족으로 인해 완성을 못한것도 있었지만,
아이디어만으로도 충분히 멋진 작품들이였습니다.

직접 구현된 작품들을 보고, 직접 체험해보니
컨퍼런스에서 얘기로만 듣던 내용들이 훨씬 더 이해가 잘 되었습니다.

작품별로 UCC를 찍어서 옆에 항상 틀어놨었는데,
UCC도 재미있게 잘 만들었을 뿐만 아니라,
설명도 해 주셔서 작품을 이해하기가 더 좋았습니다.

제가 갔던 시간이 마침 오프닝 행사 시간이라 
공짜로 크리스피 크림 도너츠랑 음료수를 마련해뒀길래
막 집어먹었습니다.. ㅋㅋㅋ

아래는 사진입니다. ㅋ

카메라를 깜빡하고 안가져가서 핸폰으로 찍었는데,
너무 아쉽네요 ㅠㅠ
사진 제대로 찍어놨어야 하는데 ㅠㅠ


이 장소를 Daum지도에서 확인해보세요.
서울특별시 종로구 이화동 | 동숭동 제로원 디자인
도움말 Daum 지도

댓글을 달아 주세요

  1. BlogIcon jollaman999 2009.09.12 18:28 신고  Addr  Edit/Del  Reply

    근데 저 사진들은 대체 멀까요??ㅎㅎ ^^;;

posted by 희정냥★ 2009. 8. 15. 22:37
'Ralph Johnson과 함께하는 소프트웨어 개발의 지혜들'라는 주제로
GoF 중 한명이신 Ralph Johnson의 강의가 있어서 냅따 들으러 갔습니다.


(장소가 너무 멀고, 참가비가 있어서 약간 부담스럽기도 했지만 ㅠㅠ
Ralph Johnson의 강의를 듣는다는 설레임으로 가게 되었습니다~
국민대는 처음가봤는데, 강의 장소를 못찾아서 고생좀 하고 ㅠㅠ 힘들게 찾아갔습니다 ㅠㅠ)

(이건 강의 다 끝나고 마치기 직전에 찍은 사진입니다 ㅋㅋ)

정말 열정적이신 분이였습니다. 쉬지 않고 강의 하시더군요.
연세가 있으셔서 힘드실법도 한데, 강의도 열정적으로, 질문의 답도 열정적으로 하셨습니다.
멋지신 분이에요 *.*
사람들이 마지막에 GoF Design Patterns 책 들고와서 싸인받으시길래
전 안들고가서 걍 제 플래너에 받았습니다.. ;; ㅎㅎ


오전엔 대표적인 디자인 패턴에 대한 설명을 하셨습니다.
그리고 오후엔 리팩터링에 대한 설명을 하셨습니다. 간단한 코드 예제도 보여주셨구요.





    1) 교육 일시 :  2009년 8월 15일 (토) 오전 10시 - 오후 2시 30분

    2) 교육 장소 :  국민대학교 경상관 317호 (BIT 컨퍼런스 룸)



시 간
내용 강    사
10:00 - 11:30
Fifteen years of Design Patterns.
"Design Patterns" was released in October, 1994. In the years since, some of the patterns have turned out to be very important, some less important. New patterns have arisen that have displaced some of the older patterns.  There are common ways that the patterns are misused. Ralph Johnson will talk about what he has learned about the patterns since the book was published.

Ralph Johnson is one of four coauthors of "Design Patterns" and the leader of the group that built the first refactoring tool, the Smalltalk Refactoring Browser. He is currently working on patterns for parallel programming and for safe software, and on tools for refactoring systems to be more secure and to be more parallel. Ralph Johnson is a Research Associate Professor in the Department of Computer Science at the University of Illinois at Urbana-Champaign.

Ralph Johnson

11:30 - 12:30 점심 먹으면서 간담회

 

12:30 - 02:00
Keeping software young and limber
As software ages, it tends to get harder to change.  People try to make changes in such a way that nothing breaks, but it becomes harder and harder to change it successfully.  Eventually the software is so hard to change that it is abandoned.

Not all projects are like this.  Open source projects seem to run on and on.  Some commercial projects seem to last indefinitely, sometimes because they are so valuable that no effort to save them is too great, other times because the software stays flexible and so developers are able to adaptit to new situations.

There are a set of techniques that help keep software flexible and adaptable.  They are often named "refactoring", but there is a lot more to it than just a particular set of techniques for changing code.  Flexible code requires certain management practices, as well.  This talk will describe how to keep your software young and limber. 

Ralph Johnson

02:00 - 02:30 질의 및 응답  
 

이 장소를 Daum지도에서 확인해보세요.
서울특별시 성북구 정릉제3동 | 국민대 경상관
도움말 Daum 지도

댓글을 달아 주세요

  1. BlogIcon 거북사마 2009.08.17 16:17  Addr  Edit/Del  Reply

    정말 열심히 하시네요~^^

posted by 희정냥★ 2009. 8. 12. 23:58

저의 관심분야이자 제가 완전 가고 싶어하는 MIT Media Lab에서 컨퍼런스를 마련해서,
주저없이 들으러 갔습니다 ㅎ

2009.08.10. (월)
오전 9시 30분 ~ 오후 6시
연세대학교 100주년 기념관
http://www.workshopseoul.com


1000명 사전 신청을 받았던만큼 굉장히 많은 사람들이 오셨습니다.
대부분 대학생인듯 했지만, 나이가 많으신 어른들도 계셨어요.

MIT Media Lab에 대한 소개와 랩에서 진행했었던 과제를 소개해 주셨습니다.
여러 재미있는 과제들이 많았구요.
소개해주신것 중에서는 제가 관심가지고 찾아서 UCC로 봤었던 과제들도 꽤나 많았습니다.
Media Lab에 한국 학생들도 점점 늘어나고 있다고 하네요.






각 분야별 스티커가 4가지 있었는데, 저는 공학이라 이것을 선택했습니다.





이번 행사를 소개한 얇은 책자입니다. 2000원주고 구매했어요.





히로시 이시이 교수님께서 여러 과제와 Media Lab을 소개 하셨습니다.
실력 뿐만 아니라 굉장히 유머감각 있으신 교수님이신것 같아요.





Media Lab 소속 학생, 연구원들은 다양한 분야들의 융합에 대해 많이 얘기하셨습니다.




다양한 과제들을 알게 되었을 뿐만 아니라,
여러가지를 생각해보았던 시간이였습니다.
늘 도전했었던(그리고 많이 실패도 했었던) 어린시절에 비해
나이가 들어갈수록 너무 현실에 안주하고 있지 않은가라는 생각이 드네요.
'왜 생각만 하고 실천에 옮기지 못할까. 왜 실패를 두려워 하고 크게 도전하지 못할까.' 하는 것들이지요.
연세대 HCI랩 김진우 교수님께서 말씀하셨던 그 선무당이 사람 잡는다(새로운 것에 일단 도전하라)는 마인드를 잊지 말아야 겠어요.

댓글을 달아 주세요

  1. BlogIcon 거북사마 2009.08.13 18:04  Addr  Edit/Del  Reply

    무척 가고 싶었는데 회사가 바뻐서 못갔네요;;;ㅎㅎ
    부러워요~~~

    • BlogIcon 희정냥★ 2009.08.14 00:22 신고  Addr  Edit/Del

      전 3일간의 워크샵도 참여하고 싶었는데 4일씩이나 빠질수가 없어서 ㅠㅠ 아쉬워요 ㅠㅠ 이번 다음 데브데이 제주도는 꼭 갈수 있어야 할텐데요 ㅠㅠ

posted by 희정냥★ 2009. 8. 6. 16:31

* 과제소개 : Samsung Software Membership online 9th Exhibition
아래는 제가 2007년도에 멤버십 회원이 되고 나서 처음으로 했었던 과제이고,
2007년 5월부터 2007년 7월까지 진행했었습니다.
위에 링크되어 있는 온라인전시회 페이지에 소개된 내용입니다.


1. Introduction




웹 환경에서 프레젠테이션 문서를 제작함으로써 설치와 같은 환경의 제약이 없이 사용이 가능하며, 데이터 공유와 정보의 공개 등을 통한 새로운 사용자 컨텐츠 문화를 조성한다. 제작한 문서의 사용자간 공유 기능이 매우 뛰어난 장점이 있다. AJAX와 ASP .NET을 이용한 동적인 컨텐츠를 통해 표현의 제약을 뛰어 넘고, 나아가 여러 비즈니스 모델을 제시한다.




김정하  하승우  김희정 


 


            


이 서비스는 두 가지 측면의 문제를 해결하고자 기획되었다.


첫째, 프리젠테이션 프로그램의 로컬환경의 작업으로 인해 문서 및 정보의 사용자간 공유가 매우 힘들다는 점이다. 무거운 프로그램과 웹 환경에서 편집이 되지 않는 점 등이 웹 환경으로의 전환을 꾀하지 못한다는 단점이 있다.

둘째, 현재 존재하고 있는 온라인상의 많은 부분의 컨텐츠가 텍스트 위주의 정적인 컨텐츠이다. 또, 각 컨텐츠는 하나의 특징만을 가지는 독립적인 것이 대부분이다.

이 서비스를 통해 다양한 방법에서 표현할 수 있는 진정한 동적 컨텐츠를 생성하고자 하며 사용자간 데이터 공유와 정보의 공개 등을 통한 새로운 사용자 컨텐츠 문화를 조성하며, 서비스 제공자는 이를 통한 여러 상업적인 효과를 창출할 수 있다.



2. Development Description


본 과제는 웹 오피스 Web 2.0의 한 부분을 비중있게 다룬 작품이다.

많은 분야에서 이와 같은 모델이 연구되고 있지만 웹 오피스의 장점을 비즈니스 모델과 접목 시키는 부분에 대해서는 미흡한 것이 사실이다. 우리는 이에 착안하여 웹의 특성을 살린 사용자들간의 공유와 출판의 개념을 접목 시키고자 하였다. 또한, 관련 기술은 AJAX를 심도있게 다루었으며, ASP .NET을 이용하여 내부적인 비즈니스 로직을 제작하였다.

로컬 환경의 프로그램이 웹 환경으로 진화하면서 사용자들은 자신의 지식을 다른 사용자와 공유할 수 있으며, 이를 자신을 표현하고 나타내는 수단으로 사용할 수 있다. 또한 서비스 제공 업체에서는 관련 서비스를 이용하여 많은 비즈니스 모델을 구상할 수 있게 되었다.

이것은 바로 Web 2.0 의 개념을 가장 잘 표현한 부분이며, 이 작품에서 자신있게 보여주는 부분이다.



 

  



DB를 제외한 전체적인 3-Tier Architecture로 구성이 되어 있다. 이는 추후 서비스가 대형화 되었을 때를 대비하여 커넥션 풀링과 같은 부분을 고려하기 위함이라 할 수 있다.

1. UI

일반 사용자에게 보여지는 Web Site, PT문서작성, Open API를 포함한다. 사용자의 이벤트 등을 처리하며 입력 Data를 BIZ layer로 넘기거나 BIZ layer를 통해 Data를 조회한다.

2. BIZ

각종 업무단위로 묶여지며 입력 Data를 처리하고 처리된 Data를 DAC layer로 넘기거나 DAC layer를 통해 Data를 조회한다. AJAX처리를 위한 WebService BIZ와 일반적인 Web Site부분에서 사용될 BIZ부분으로 나누어지며 WebService BIZ는 다시 공용 BIZ를 사용하게 된다. 공용 BIZ는 COM+로 구성되며 Transaction 처리를 담당한다.

3. DAC

COM+과 SQL Helper을 통해 DataBase와의 Connection과 Connection Timeout등을 관리하며 Stored Procedure의 Parameter 생성과 호출을 담당한다.

4.  DataBase

MS SQL 2005로 구성된다.



 

5. XML

데이터베이스에서 문서를 불러오거나 사용자의 요구에 의해서 문서가 편집 되었을 때, 하나의 XML 문서의 형태로 데이터가 저장되어 제어를 할 한다. 또한 이렇게 제작된 XML 데이터를 바탕으로 사용자 디스플레이에 렌더링 된다.




  

1. 과제 목표

본 과제는 동기에서 볼 수 있듯이 Web 2.0 이란 기술을 활용해서 웹 오피스와 접목 시켰을 경우, 얼마나 많은 상승 효과를 보여줄 수 있는 지에 대한 증명을 목표로 하고 있다.

프로그램 측면에서 기본적인 텍스트와 이미지의 입력과 편리한 유저 인터페이스의 제공을 목표로 하고 있으며, 웹 컨텐츠 확보를 위한 포스팅과 사용자들간의 자료 공유에 중점을 두어 프로젝트의 기획을 하게 되었다.

또한, 데이터베이스의 확장성과 향후 서버의 확장을 고려하여 XML 문서의 형태를 분리 저장하고 로딩되는 과정에서 통합하는 형태로 자료구조를 설계하고자 하였다.

2. 과제 결과

2.1. UI

오피스 제품군을 사용하던 사용자들이 웹 환경에서 본 서비스를 사용하였을 때, 이질감을 줄이기 위해 최대한 편리한 UI를 제공해주고 있는데, 이와 같은 UI의 형태를 리본 UI라고 한다.

           

 

2.2. Editing

편집 기능에서는 로컬에서 제공되는 것과 같은 텍스트 입력과 이미지, 멀티미디어 등이 제공되며, 각 객체에는 애니메이션을 부여하여 동적인 문서를 제작할 수 있다.
또한, 이미지에 대한 그룹화와 스마트 아트를 지원하고 있으며, Redo/Undo 기능을 위한 메모리 스택을 제작하였다.

프리젠테이션 프로그램의 특성을 살려 분할 출력 기능이나 클립보드와 같은 기능 역시 제공을 하고 있다.

2.3. Viewing

제작된 문서는 다음과 같은 화면의 형태로 사용자에게 보여지게 된다.

좌측 하단에 현재 페이지가 나오고 있으며, 우측 하단에는 페이지 이동, 슬라이드쇼, 프린트 기능 등을 제공하고 있다.

               

 

2.4. Posting

사용자는 서비스 사이트에서 제공되는 문서를 포스팅 하여 자신의 블로그나 타 사이트의 게시판에 포스팅 할 수 있다. 이러한 기능을 통해 사용자들은 기존의 텍스트, 이미지가 아닌 새로운 형태의 매체를 접할 수 있게 된다.

               

 

2.5. Contents Upload

웹의 특징을 활용한 부분의 한 방법으로 컨텐츠의 업로드 기능이 있다.

사용자는 자신이 만든 도형이나 클립아트, 템플릿 등을 서버에 업로드를 할수 있으며 이를 이용하여 다른 사용자들과 공유를 할 수 있게 된다.

이러한 기능을 통해 사용자간의 데이터 공유의 활성화를 기대할 수 있으며, 이는 사용자들의 컨텐츠 제작의 질을 한층 더 향상 시킬 수 있다.

               

 

2.6. Task Sharing

다음 그림은 두명의 사용자가 하나의 문서를 동시에 작업할 수 있다는 것을 보여주고 있다.

파일 기반의 서비스의 경우 하나의 문서에 대해서 여러명이 동시에 작업을 할 경우에, 문서를 제작하고 통합하는 과정이 번거로웠다. 하지만 웹환경에서는 문서 작업을 원하는 사용자에게 편집 권한만을 부여해주는 행위 하나만으로 사용자간의 협업 시스템이 훌륭하게 이루어 지게된다.



 

2.7. Service Site

위에서 설명한 모든 기능을 서비스하기 위한 서비스 사이트를 제작하였으며, 이 사이트 역시 전반적인 AJAX 기술을 활용하여 제작하였다.

사용자의 편의성을 위해, 카테고리별 등록과 실시간 인기 검색어, 검색 자동완성 기능 등을 제공해 주고 있다.

 

 

[[applied technology]]

1. AJAX

서버와 클라이언트의 비동기 통신 방식인 AJAX 기술을 활용하여, PT 제작 부분의 전반적인 부분에 활용이 되었다.

본 프로젝트의 경우 데이터의 로딩과 저장을 하는 과정이 AJAX 기술을 가장 많이 활용한 부분이다. 이를 이용해 웹 상에서의 데이터 유실을 막을 수 있는 자동저장과 같은 기능을 구현하였다.

2. Vector Image 제작

웹 환경에서는 로컬 환경의 오피스 제품군과는 달리 벡터 형식의 이미지 처리를 지원하지 못한다.

때문에 이미지의 확대나 축소와 같은 기능을 사용자에게 제공하기 위해서는 사용자로부터 입력받은 마우스의 위치 데이터를 파악하여야 한다. 벡터 이미지 계산 수식을 적용하여 비즈니스 로직 부분에서 계산된 데이터를 바탕으로 렌더링 과정을 통해 브라우저로 실시간에 표시하게 된다.

3. COM+

3Tier Architecture 상에서 BIZ Layer 와 DAC Layer에 COM+ 기술을 적용하였다.

BIZ Layer에서는 데이터 처리상에 Transaction 을 담당하게 되고 DAC Layer에서는 Connection Pooling을 담당하게 되는데 이를 통해 대규모의 Data 및 다수의 동시접속자에 대한 처리를 할 수 있도록 설계하였다.




1. Software 

  [IDE] Visual Studio .Net 2005
  [Database] MS SQL 2005
  [Etc] JAVASCRIPT (AJAX 기술 포함)



3. Improvement



 

1. PPT 포맷 호환

현재는 자체 제작한 XML Document의 형태로 문서가 저장되고 있지만, 추후 업데이트를 통해 MS사의 PPT와도 호환이 가능하도록 구현할 예정이다. 이러한 호환이 가능해 질 경우 사용자들에게 편의성을 증가시키고, 서비스의 확대를 가지고 올 수 있다.

2. 모바일 장치와의 연동

웹 환경 어디에서든 적용이 가능하기 때문에 모바일 장치에서도 문서를 제작하거나 볼 수 있는 환경을 만들 수 있다.



4. Epilogue

 


1. 그래픽 환경

로컬 환경의 프로그램의 경우 벡터형태의 이미지로 이루어진 반면, 웹에서는 벡터 이미지를 표현해 주지 않기 때문에 이 부분을 처리하는데 어려움이 있었지만, 내부적인 계산 로직을 적용하여 해결할 수 있었다.

2. 표

사이즈의 조절과 같은 기능은 제공을 할 수 있지만, 표 안에 내용을 직접 삽입하는 등의 방법에서 많은 에로사항이 발생하였다. 이 부분에 대해서는 향후 적합한 방법을 모색중에 있다.

3. 텍스트 입력

텍스트 박스를 로컬 환경과 같은 모습으로 제작하기 위해서는 상당히 많은 기술적인 부분을 요구 했지만, 개발의 목적과 시간을 고려하여 텍스트 입력창을 따로 두었던 점이 약간의 아쉬운 점으로 남는다.

 

5. Manager's comment


 

현재 활발히 연구되고 있는 Desktop Client의 한 분야로써, 로컬 환경에서만 사용되었던 프로그램을 설치 없이 웹에서 사용할 수 있다는 점에 Web 2.0 개념을 접목시켜 사용자 측면의 편의성을 최대한으로 높였다. 기존의 파워포인트를 웹에서도 클라이언트처럼 실행할 수 있다는 것이 상당한 매력이다.
[SW멤버십 WEB2.0 공모전 금상]



 

'Computer > Web' 카테고리의 다른 글

CSS Box Model  (0) 2011.09.18
CSS 선택자  (0) 2011.09.18
Web 2.0 기반의 Presentation On The Web  (0) 2009.08.06
syntaxhighlighter를 tistory에서 사용 하는 방법  (0) 2008.10.08
IE6,IE7 ,FireFox 에 대해 CSS 맞추기  (0) 2008.07.09
CSS에서 브라우저 구별 (IE6, IE7, FIREFOX)  (0) 2008.07.09

댓글을 달아 주세요

posted by 희정냥★ 2009. 8. 4. 00:50




Sketch Flow 워크샵에 갔다왔습니다 ㅎㅎㅎㅎㅎㅎ

2009.08.01 토요일 12:00 ~ 18:00
장소 : 포스코센터 5층 한국마이크로소프트 Drive Room








[첫시간. 전찬주 (작은아이 agiletalk)]
#
어떻게 구현해야 할지
프로토타이핑 -> 
1) 페이퍼 프로토타이핑 : 종이를 이용. 쉽게 할 수 있고, 특별한 기술이 필요없이도 바로 할 수 있다.

한메일에서 메일 서비스를 개편하면서
자세하게 프로토타이핑해서 동영상으로 찍어서 올려둔 것이 있으니 참고.

2) 디지털 프로토타이핑
컴퓨터를 이용.
컴퓨터를 이용해서 이미지를 클릭했을때, 이동하면서

3) 실제 프로토타이핑
실제 제품이랑 똑같이 만들기
휴대폰, mp3 같은 제품들
장점 : 사용자 입장에서 실제로 제품과 같은 프로토타입을 볼 수 있기 때문에
실제 제품 사용자 경험, 디자이너는 바로 피드백 받을 수 있다.

#
수평적 / 수직적 프로토타입
제품이나 서비스에 간략하게 
수평적 : 실제 제품이나 서비스가 나오기전에 사용자입장에서 
수직적 : 기능적. 기능을 완벽하게 다 구현해서 보여주는 프로토타입.
시나리오 : 수평적, 수직적의 중간정도. 몇개를 뽑아서 정확하게 구현. 
사용자 입장에서는 그 몇가지 기능들에 대해 볼 수 있는

#
프로토타입의 장점
1) 피드백
제품이나 서비스를 만들기 전에 .
2) 문제점 발견.
기획단계에서 발견하지 못한 잠재적인 문제점 발견해서 고칠수 있다.
3) 빠르고 반복적. 
한번 만들게 되면 계속 빠르고 반복적으로 고치고.
4) 커뮤니케이션.
디자이너, 기획자, 사용자 간의 커뮤니케이션 도구로 사용할 수 있다.

단점
1) 과대평가. 제한된 테스트. 알려지지 않은 요구사항.

#
1. 결국 사용자는 화면을 보면서 일을 하므로 내부 논리 보다는 UI에 관심이 많다.
2. 프로토타이핑은 위험을 줄일수 있는가?
3. 기획자, 개발자, 운영자 등 관련자와 함께 만들어가는 것이 중요하다.
4. 해답을 프로토타이핑하는 것이 아니라, 해답을 찾고자 프로토타이핑을 한다.

목업, 와이어 프레임 -> 일정한 틀을 만든다.
프로토타이핑 -> 어떤 기능을 넣어 사용자가 직접 체험할 수 있게 한다.


[둘째시간. 황리건]
#
Sketch(질문) Vs Prototype(답)
Evocative -> Didactic
Suggest -> Describe
Explorer -> Refine
Question -> Answer
Propose -> Test
Provoke -> Resolve
Tentative -> Specific
noncommittal -> Depiction

두단계를 걸칠 것도 조금더 빨리.

#
흐름(Flow)
중간에 어떻게 변화는지를 좀 더 스캐치 할 수 있다.
중간에 이게 서서히 어두어지고 밝아지는 등의 Flow가 중요.

State Transition Diagram
Product in Stock
...
 
Sketch Flow For Player 화면은
각각의 상태들이 어떻게 왔다갔다하는지를

Production


[세번째시간. 조편성]
1. 박승현. 실버라이트게임. 개발자. 기획에 많은 관심. : 박찬용(개), 
2. 공인석. 개발자. 실버라이트. 휴즈플로우 : 선주현(디), 신기현(디), 최명화(디)
3. 이근화. 기획. 휴즈플로우. -> 이 분. 김희정(디), 김희정(개), 전훈(개)
4. 허미호. 휴즈플로우. 실버라이트. 기획. 그 전엔 야후에서 기획. : 안설희(디), 최홍배(개), 한지호(기)
5. 전찬주.  : 박성환(디) , 정진희(디)
6. 신현일. 청주에서 올라옴. : 노지훈(기)
7. 송기수. 개발.  
8. 김병환. 노트북 대여해줌. : 

(글씨가 잘 안보여서 거의 못적음...;;;)

 
[넷째시간. 이원준]
이노티브 http://blend.pe.kr
후기를 까페에 올려놓으면 무선키보드마우스 세트 줌.

#
실습시간
Blend 3 SketchFlow로 영화 예매 Widget 만들기.


(동영상출처 : http://uxfactory.com/720)

 
[다섯째시간. 실습 - 조별 아이디어 회의]


[여섯째시간. 실습 - 조별 구현]


이 동영상 마지막 부분에 희정냥도 나와요~ ㅋ

스케치플로우 워크샵 현장 스케치(media by 작은아이)
(동영상출처 : http://uxfactory.com/720)


[일곱째시간. 조별 발표]
조별로 만든 작품들을 발표하는 시간이었습니다.

저작권은 만드신 분들에게 있습니다~


I'm a Developer - 스트레스로 대머리가 된 개발자를 위한 해결책 제시

 
심리 테스트 위젯 - 초식남에게 맞는 쇼핑 추천


구설수닷컴 - 가십 검색

 
I'm here!! - 지역기반 모바일 SNS 애플리케이션


"나는 네가 한 일을 알고 있다." - 소프트웨어 사용량 체크


 무한공짜월드 - 지역과 시간별 공짜 선물 이벤트 찾기

(동영상출처:http://uxfactory.com/722)


* 희정이가 느낀 SketchFlow
재미있는 기능이였습니다.
쉽게 프로그램의 흐름을 만들고, 간단하게 사용해 보고, 피드백까지 가능하니
협업에 많은 도움이 될 것 같습니다.
하지만 저는 아직 툴에 익숙치 않아서 많이 활용해보진 못했습니다.
잘 이용하면 멋진 툴이 될 것 같습니다.


* 희정이가 느낀 워크샵
무엇보다도 직접 조를 짜서 아이디어를 내고, 만들어 본다는게 재밌었던것 같습니다.
설명만 들으면 곧 잊어버리기 마련인데,
직접 노트북으로 실습도 해보고, 만들어 보니 좀 더 빨리 익힐수 있었습니다.
새로운 사람들과도 빨리 친해질 수 있었구요.
그리고 마지막에 조별 결과를 발표하면서,
여러 재미있는 아이디어를 공유할 수 있었던 점이 좋았습니다.
앞으로 이런 자리가 많이 있었으면 좋겠습니다.

댓글을 달아 주세요

posted by 희정냥★ 2009. 7. 23. 18:57
재미있는 동영상을 발견했습니다.
나온지는 좀 지난것 같지만.. ㅎ



그려노은 모양에 따라, 그리고 사람의 몸짓에 따라 물이 흐르네요.
웅덩이가 생기기도 하고 물고기가 헤엄치기도 하고~
흐르지 못하고 고인 물은 썩기도 하고.. ㅎ
아이디어가 신선하네요. ㅎ

'Computer > Multimedia' 카테고리의 다른 글

WaterBoard  (0) 2009.07.23
내가 좋아하는 UCC  (0) 2008.02.05
OpenCV 설치하기  (3) 2007.12.09
TAG

댓글을 달아 주세요

posted by 희정냥★ 2009. 7. 20. 11:12




7회 태터캠프를 참가한 후기입니다 ㅎ

역삼역 구글코리아에서 했었는데요,
구글은 처음 가봤는데,,
구글스러운 분위기 너무 좋습니다 ㅎ

마음대로 음료수도 마실수 있구, 과일~ 과자~ 컵라면까지 ㅋㅋㅋ
다트게임에~ 당구장도 있고.. ;;
감동이였습니다;;  *.*








처음엔 아이스브레이킹 시간이 있었습니다.
참가하신 모든분이 간단하게 자기소개를 하는 시간이였는데
재밌으신 분들 참 많으시더군요.. ㅎㅎ
부산 광주 등 멀리서 오신분들, 고3인데 정신 못차리고 오셨다는분... ㅋㅋㅋㅋㅋ

그 다음엔
약간의 강의 시간(?)도 있었구요,,,
TNF와 구글 텍스트큐브, 다음 티스토리에서 이야기를 해주셨습니다.

마지막엔 관심그룹을 나눠서 토론(?)을 했었습니다...

BoF에서는 텍스트큐브 개발이란 주제로 얘기를 했었는데,
새롭게 알게된 사실도 많았구요...
스킨 개발자의 고통도 알게 되었습니다.. ㄷㄷ



* 오늘의 득템 목록


구글티, 핸드폰 받침대, 메모지, 볼펜, 여행 파우치~~~

냐하하하~ 신난다~~~~~~~~~~~~~



댓글을 달아 주세요

  1. BlogIcon TISTORY 2009.07.20 14:11 신고  Addr  Edit/Del  Reply

    재미있는 BoF에 참석하신 것 같네요~.
    많은 자유를 주다보니 그만큼의 책임이 따르는 것처럼 개발이나 스킨 제작이나 생각만큼 쉽지 않은 것은 사실입니다. 그래도 같이 머리 맞대고 고민하고, 함께 만들어간다면 좋은 방법이 있을 것이라 생각합니다. 어렵다고 자유를 제한하면 안되니까요 ^^

    즐거운 캠프되셨길 바라고, 앞으로도 종종 뵙겠습니다.

    - 샨새교 교주

  2. BlogIcon 맥퓨처 2009.07.21 00:15  Addr  Edit/Del  Reply

    BoF 때 같이 말씀 나눴던 맥퓨처입니다.. :)
    궂은 날씨에도 참석해 주셔서 감사드리고요..
    다음 태터캠프는 더 재미있는 주제로 같이 말씀나눌 수 있으면 좋겠습니다..
    뵙게 되면 꼭 아는척 해주세요.. :)

posted by 희정냥★ 2009. 7. 16. 19:11

Windows 7을 써본지 일주일이 다 되어 가는군요... ㅎㅎ
개인적으로는 매우 만족입니다.
그전엔 XP와 Vista를 썼었는데, Vista보다 빨리진것 같구요, XP보단 간지납니다.. ㅎㅎ
프로그램도 거의 다 돌아가는 것 같네요.

제가 확인한 건
Eclipse 3.5
알집, 알씨, 알쇼, 알송 (알약은 안깔립니다)
Visual Studio (2008, 2010 Beta)
Office 2007
한글 2007
V3
Adobe Acrobat
Gtalk
크롬
네이트온
zero IRC

인터넷 뱅킹 - 우리은행, 외환은행

정도..?

더는,, 생각이.. 안나네요 ㅎ

여튼 만족하고 있습니다 ㅎ


'Computer > OS' 카테고리의 다른 글

Windows 7을 써보니...  (5) 2009.07.16
Windows 7 설치!  (1) 2009.07.11
NACHOS 관련 재밌는 시  (2) 2006.03.07
TAG

댓글을 달아 주세요

  1. BlogIcon Flask 2009.07.16 19:24 신고  Addr  Edit/Del  Reply

    정작 게임은 버벅이던데;;;;;; (친구 말론, 그래픽 연산의 루트를 살짝 변경했다더군요, 그래서 연산하는데 쫌더 시간이 지연되서 버벅이는 현상을 초래;;;)

  2. BlogIcon HㅇYa 2009.07.16 21:03 신고  Addr  Edit/Del  Reply

    조만간 7로 갈아타야 겠네요..

  3. BlogIcon [안양]개긔 2009.07.16 21:14 신고  Addr  Edit/Del  Reply

    저는 가상화프로그램에 설치햇엇는데 약 XP설치속도의 3배가 걸리며 약 1시간 넘게 소요됫구요.
    가상화 프로그램으로해서 그런지 엄청 버벅되더라구요.
    비스타와 다른점은 단지 가벼워졋다는거 뿐인가요??

    • BlogIcon metalOsn0w 2009.07.16 21:46  Addr  Edit/Del

      버박이나 브이엠웨어같은 가상머신에 깔면 그 머신들의 자체 그래픽카드로 대체되어서 자긴 본체의 성능을 100% 못 끌어낸다고 하네요.

    • BlogIcon [안양]개긔 2009.07.17 09:20 신고  Addr  Edit/Del

      조만간 넷북구매하면 win7로 아예 바꾸어 놓으려구요;