2007년 8월 29일 수요일

flex 관련 문서

http://flexdocs.kr/docs/flex2/docs/Part5_ProgAS.html

오늘 부터 공부 한 번 해봐야겠다.
필요한게 뭐지?

adobe에 가서 flex builder를 다운 받는 중 - ecllips IDE와 일반버젼이 있음

Compiling shared PECL extensions with phpize

$ cd extname
$ phpize
$ ./configure
$ make
# make install

PECL을 사용한 install을 이렇게 해야 함

// extension이 설치되는 dir확인
$ php-config --extension-dir

2007년 8월 27일 월요일

json사용을 위한 PECL extensions설치

php같은 경우 module을 여러 관리 프로그램으로 install하네..희안하네~

# pecl install json
WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
downloading json-1.2.1.tgz ...
Starting to download json-1.2.1.tgz (17,780 bytes)
......done: 17,780 bytes
11 source files, building
running: phpize
Configuring for:
PHP Api Version:         20041225
Zend Module Api No:      20050922
Zend Extension Api No:   220051025

2007년 8월 24일 금요일

pear installer를 사용한 php module설치

php에도 perl의 cpan install manager와 같은 install manager가 있었다 이름하여~~pear 흐흐..

root계정에서 pear의 실행이 가능하도록 설정한 후 간단히 실행하면 된다.

1. HTTP/Request 설치
# pear install Http_Request    
WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
downloading HTTP_Request-1.4.1.tgz ...
Starting to download HTTP_Request-1.4.1.tgz (15,927 bytes)
......done: 15,927 bytes
downloading Net_URL-1.0.15.tgz ...
Starting to download Net_URL-1.0.15.tgz (6,303 bytes)
...done: 6,303 bytes
install ok: channel://pear.php.net/Net_URL-1.0.15
install ok: channel://pear.php.net/HTTP_Request-1.4.1


2. Net/Socket 설치
pear install Net_Socket
WARNING: channel "pear.php.net" has updated its protocols, use "channel-update pear.php.net" to update
downloading Net_Socket-1.0.8.tgz ...
Starting to download Net_Socket-1.0.8.tgz (5,441 bytes)
.....done: 5,441 bytes
install ok: channel://pear.php.net/Net_Socket-1.0.8

2007년 8월 23일 목요일

새로운 adsense를 만들어 봤음 ㅋㅋㅋ

좋구만~~

송장 확인 프로젝트

시나리오

고객은 파일을 등록한다, 파일은 excel로만 등록해야 하며 등록 후 자동으로 파싱되어 화면에 출력된다.

화면에서  송장번호라인을 선택한 후 작업 시작 버튼을 누르면 조회 작업이 시작된다.

어떻게 보여주는게 좋을지..생각 중..

작업완료 되면 결과를 다운 받을 수 있다.

 

프로그램 관련

파일 업로드 처리 ( 완료 )

 => 등록된 파일명을 리턴한다.

탭 처리 부분  (완료)

 

업로드한 엑셀의 파싱 (date: 2007.8.17 ~ )

xls2htm등을 사용해 data를 출력한다. 이때 중요한것은 column마다 같은 class를 가져야 한다는 것임 그래야 header를 선택할 경우 전체의 색이 변경될 수 있음

 

파싱한 데이터의 화면 출력

 

화면 출력한 데이터의 헤더 선택

 

 

 

수익모델 디자인

 

 

 

 

이 글은 스프링노트에서 작성되었습니다.

2007년 8월 22일 수요일

[jQuery] 가져온 xml data의 control이 필요함

date: 2007.8.22

XSLT와 XML을 사용해 사이트 개발 중

XSLT구현에서도 몇 가지 문제점이 있음.
jQuery를 사용해 xsl과 xml을 가져옴 google에서 배포한 ajaxslt를 사용해 특정 div에 결과값을 출력 함
=> 여기까지는 전혀 문제 없음

가져온 xml 데이터를 looping하고 결과를 바꿔주려 함, Client에서 해당 값을 변경함으로써 Server로부터 값을 가져오는데 따른 overhead를 방지 할 수 있음.

2007년 8월 10일 금요일

Representational State Transfer(REST)

SOA를 구현하기 위한 많은 표준이 제시되고 있지만 크게 SOAP, XML-RPC, REST로 진영이 나누어 져있다고 보면 무방할 것이다.

REST란 대규모 네트워크 시스템을 위한 아키텍처로 2000년 Roy Fielding의 박사 학위 논문에서 처음 제안되었다. REST는 원래 웹과 같은 대규모 네트워크 시스템을 위한 원칙들의 모음을 말하는 것이지만, 요즘에는 XML과 HTTP를 사용하는 단순한 웹 기반 인터페이스(즉, REST의 원칙을 따르는 Web Services)를 지칭하기도 한다.

최근엔 많은 Open-Api가 만들어지고 있으며 사용의 편리성때문에 SOAP계열보다는 REST로 무게의 추가 기운 느낌이다.

간단하게 REST계열의 특징을 보면 REST는 HTTP프로토콜을 사용하며 초창기의 WEB과 동일한 룰을 가지고 있다고 보면 된다.

  - 상태를 유지하지 않는 클라이언트/서버 구조를 가진다.

  - 작고 어디에서나 적용되는 인터페이스를 가진다. (e.g., GET, POST, PUT, DELETE)

  - 모든 자원은 URI를 이용하여 유일하게 지칭될 수 있다.

  - 자원들의 표현(Representation)들이 URI을 통해 서로 연결되어 있다.


이와 같은 특징으로 인해 웹 서버와 웹 클라이언트의 종류에 상관없이 URI만 알면 HTTP GET과 같은 인터페이스를 이용하여 간단히 해당 자원에 접근할 수 있다.

 

오늘날 대부분의 웹 어플리케이션들은 사용자 인증 또는 상태 정보를 유지하기 위해 쿠키 또는 HttpSession 등을 사용하고 있는데 이것은 REST의 원칙에 명백히 위배되는 방식이다. 또, 웹 서버상의 데이터를 조회하는 것은 물론이고 변경이나 삭제 심지어는 생성을 위해서도 GET method를 사용하는 경우도 매우 많은 것이 사실이다. (서버 사이드의 변경을 유발하는 요청에 대해서는 POST를 사용하는 것이 바람직하며, ActiveResource 에서는 생성을 위해서는 PUT, 삭제를 위해서는 DELETE를 사용한다.)


보통 PERL이나 PHP로 프로그램을 할때, GET $URL, POST $URL등을 사용하지만 표준엔 DELETE도 있다. 사용해 본적 없는데..지워지면 큰일이게..
 

하지만 현실적으로 여러 사용자에 대한 동적인 정보를 다루는 웹사이트를 쿠키나 세션없이 개발하는 것은 쉬운 일이 아니다. 또 PUT과 DELETE 같은 method는 HTTP 스펙에는 존재하지만 실제 이를 지원하는 브라우저는 많지 않다. (참고로 XMLHttpRequest 에서는 PUT과 DELETE를 지원한다. ? Using REST with Ajax )

 

웹은 수많은 행위자들이 상호작용하는 시스템 중 가장 성공한 예이다. 그러므로 유사한 시스템에서 REST모델은 가치 있는 프레임워크를 제공해 줄 수 있다.REST와 가장 비교되는 모델은 Remote Procedure Call(RPC)모델 이다. RPC모델은 로컬 프로그래밍 모델의 함수 호출 형식을 네트워크 시스템에 적용시킨 것이다. REST의 성공과 DCOM, CORBA, RMI와 같은 기존 RPC모델의 실패는 REST가 큰 스케일의 네트워크 시스템에 적합하다는 것을 의미한다.

 

그러나 모든 웹 application들이 Stateless 와 Uniform Interface 라는 특성을 충분히 따르기에는 현실적인 어려움이 많으므로 당분간은 순수한 REST가 일반적인 웹 개발의 패러다임으로 자리잡지는 못할 것으로 보인다.

  

그런데 최근 관심이 높아지고 있는 분야들인 Open API, Ajax, Rails 와 같은 곳에서 REST라는 용어를 자주 접하게 되는 것은 반가운 현상이다.
REST를 사용하게 되면 어떻게 보면 서버쪽에 요청을 자주 할것 같지만 사실은 어떻게 디자인 하는가의 문제이다. XML로 전체 데이터를 받은 후 CLIENT의 메모리와 프로세서 파워를 사용해 이리저리 조합해 보여주고, DATA는 Ajax를 사용하여 Server와 Sync한다면 훨씬 훌륭한 구조가 될 수 있다.

 

 

Amazone, eBay, Yahoo 와 같은 주요 웹 업체들은 대부분 REST 방식의 OPEN API를 제공하고 있으며 ( Amazone 이 제공하는 SOAP, REST 두 가지 방식의 API 중에서 REST API 의 사용율이 85%라는 정보도 소개 된 바 있다.) 최근에 Google 이 기존의 SOAP 방식 API의 지원을 중단 하면서 Ajax를 이용한 API를 새로 제공하기 시작한 것도 눈여겨 볼만한 대목이다