• 카테고리
    • 전체 글

    • 카테고리1
    • 카테고리2
    • 카테고리3
    • 카테고리4
  • 태그
  • 방명록

'기술자료'에 해당되는 글 351건

  • 2010.07.10 C# Windows Form 용 사용자 컨트롤에 사용자 이벤트 박기.
  • 2010.07.05 Visual Studio를 이용한 IE에서의 자바스크립트 디버깅
  • 2010.07.02 블로그 필자 관리
  • 2010.03.29 바탕화면 폴더 변경 2
  • 2010.02.10 객체 지향 C#의 꽁수. Singleton 패턴.
  • 2010.02.10 2008 R2 x64의 IIS 위에서 32bit 응용 프로그램 돌리는데 꼭 확인 필요.
  • 2010.01.30 Google Apps Engine을 통해 응용 프로그램 설계 시 주의사항 2
  • 2010.01.30 [Google Apps Engine] 응용 프로그램 올리기.

C# Windows Form 용 사용자 컨트롤에 사용자 이벤트 박기.

기술자료/OS 2010. 7. 10. 13:47

단순한 컨트롤인 TextBox 나 ListBox 같은 것은 그냥 쓰면 되는데, 복합 컨트롤을 만들 필요가 있는 경우 사용자 컨트롤을 만들어 사용하곤 한다. 즉 TextBox와 ListBox가 하나로 합쳐진 특수 목적 컨트롤 같은 것을 만들때다.

compositectrl1

저렇게 컨트롤 안에서 동작만 되면 문제가 없는데, 만일 외부로 이벤트를 노출 시킬 필요가 있는 경우가 있다. 위의 그림을 예로 들면 아랫쪽이 ListBox인데, ListBox의 선택이 변경되는 경우 저 통짜 컨트롤을 쓰는 곳에서 그 이벤트를 받기 위해서 구성하는 경우다.

어떻게 해야 될까 고민을 하다가 링크 하나를 발견했다. ( http://www.akadia.com/services/dotnet_user_controls.html )

만드는 방법은 간단하다. 딱 두 줄에 해당하는 내용을 넣으면 된다.

public delegate void 이벤트이름Handler();
public event 이벤트이름Handler 이벤트이름;

위와 같이 구성하면 되는데, 위의 컨트롤에서 사용한 내용은 아래와 같다.

// 컨트롤 내부 소스
public delegate void SelectChangedHander(); 
event SelectChangedHander SelectChanged;

event로 SelectChanged 라는 이름으로 하고 밖에서 연결할 때 사용하는 끈 역할을 하는 Handler를 delegate(대리자)로 선언하여 처리하는 것이다. 그러면 밖에는 이 Handler를 통해 이벤트 가입을 하는 것이다. 가입방법은 예전에도 많이 봤던 그런 형태가 된다. ( 저 이벤트를 받을 메인 프로그램에 선언하는 그 형태. )

// 컨트롤을 사용하는 메인 프로그램 소스
this.categoryCtrl.SelectChanged += new CategoryCtrl.SelectChangeHander(this.categoryCtrl_SelectChanged);

그러면 컨트롤 측에서 이벤트를 발생을 어떻게 하는 걸까?
그 역시 간단하다.

이벤트 이름을 함수로 호출하듯 하면 된다.

// 컨트롤 내부 소스 중 이벤트가 발생되는 시점
if (SelectChanged != null)
   SelectChanged();

보면 뜬금 없이 SelectChage가 null 인지 체크하는 경우가 있는데, 컨트롤이 제대로 초기화되지 않은 상황에서 호출되는 불상사를 막기 위한 안전 장치이다. 무시해도 되긴 하지만, 가급적이면 저렇게 안전장치를 거는걸 권장한다.

자,위와 같이 구성했다면, 이렇게 된다.

컨트롤내부 실행 중

-> SelectChange() 함수 호출

-> SelectChanageHandler로 연결한 모든 부분에 이벤트 발송

-> SelectChangedHandler에 인자값으로 넘긴 함수를 호출
   (위의 예제로 있는 categoryCtrl_SelecChanged() 함수 같은거)

기존에는 그냥 만들어진 이벤트를 소비하기만 했다면 자신만의 이벤트로 작업을 한다면 이런 부분을 활용해 보는 것도 나쁘지 않을 것이다.(생각해보니, 이렇게 만들 수 밖에 없기는 하다.)

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

Visual Studio를 이용한 IE에서의 자바스크립트 디버깅

기술자료/Web 2010. 7. 5. 09:02

MOSS 2007 기반으로 개발을 하거나, 기타 웹 어플리케이션을 만들면 꼭 들어가는 코드가 바로 JavaScript 이다.특히나 동적 웹을 구현을 하려면 특히 자주 활용하게 된다.
하지만, 그 Javascript의 동작이 올바른지 올바르지 않은지에 대한 판단을 하는 모습을 보면, 상당히 원시적으로 하는 경우를 많이 보게 된다. 일단 동작하는 화면을 보고, 그 결과물을 보고 현재 구성된 Javascript를 보고, 일부 수정하거나 MessageBox를 띄우고 결과물 보고..
이렇게 Javascript를 수정하는 경우 경험이 많은 개발자야 짐작과 동시에 문제점을 찾기라도 하지만, 웹 개발에 익숙치 않거나, 아예 문법 오류로 인해 Javascript 자체가 실행 안된 경우라면, 거의 좌절이다. 게다가, 웹 페이지 내에 직접 박아 넣은 Javascript라면 그럭저럭 짐작이라도 하는데, 다른 Javascript 소스를 include 한 경우라면, 이야기가 점점 꼬이기 시작한다. 뭐가 문제인지 짐작도 되지 않는다.
다행이, FireFox나 Google Chrome과 같은 웹브라우저에서는 자체적으로 혹은 외부 플러그인을 통해 디버깅이 가능하며 그 기능은 상상을 초월한다. 훌륭하다 못해 멋지기 까지 할 정도로 정확하게 값을 뽑아오며, 정확히 어느 파일의 어느 위치에 오류가 있는지 알려주며,  현재 상태 값을 보면서 정확한 오류 내용을 파악할 수 있다.

그러나, 우리나라 환경에서 개발하는, 그것도 새로 개발도 아니고, 기존 코드를 수정하는 입장인 경우, Javascript를 까보면, FireFox나, Chrome에서는 동작하지도 않는 경우가 허다하다. 특히나 ActiveX 같은 X 같은 플러그인 꽂은 곳은 아예 Gothem! 레벨. 결국 IE로 띄워 뭔가 디버깅을 시도해야 된다는 슬픈 일이 닥친다.

하지만, MS 기반, IE 온리 개발하는 곳에서는 일반적으로 Visual Studio를 이용한 .NET 개발이 주로 발생되는데, 이 경우 라면 해피하다. 여기서는 이 해피한 경우에 대처하는 좋은 방법을 알려드리려 한다.

1. IE 설정.

IE가 6.0으로 쫑 날 줄 알았으나, FireFox와 Chrome, 사파리 등의 웹 브라우저의 등장으로 위기감의 고조와 함께, 그 동안 계속되었던 6.0의 버그, 속도 문제등의 이유로 결국 7.0을 내 놓았다. 그러나, 7.0을 탑재한 Vista의 처절한 실패로 인해 Windos 7과 함께, 등장한 8.0 으로 업그레이드 되었다.

즉, 이제 IE는 6.0, 7.0, 8.0 이 혼재된 모습을 보이기 시작했다.

일단, 8.0을 기준으로 설명하며, 7,0이나, 6.0은 다른 곳을 찾아보거나, 짐작해서 옵션을 변경해야 할 것 같다.
IE를 실행 한 뒤, 인터넷 옵션을 띄우고, 인터넷 옵션에서 “고급”탭을 클릭해서 연다.

여러가지의 항목들 중 “스크립트 디버깅 사용 안함(기타)”, “스크립트 디버깅 사용 안함(Internet Explorer)”에 체크 되어 있는 것을 끄도록 한다.

2. 에러 페이지까지 가기.

Visual Studio가 깔린 PC에서 IE를 통해 먼저 에러가 발생하는 페이지까지 접근하도록 한다. 지금 필자에게는 마땅히 띄울 UI가 담긴 Page가 없으므로 에러가 발생하는 페이지를 띄우도록 할 것이다.

에러가 발생했다. 그러면 에러 페이지가 뜨는데, 여기서 체크 박스들을 없애고 “예(Y)”를 클릭한다.

위의 팝업이 안뜨면 브라우저의 왼쪽 아래에 있는 경고 표시를 클릭하면 볼 수 있다.

일단 “예(Y)”를 하면, IE에 등록된 Javascript 디버거들의 목록이 뜬다.

현재 필자는 변변한 디버거라고는 Visual Studio 정도지만, Office 2003~2007 을 전체설치하는 경우 Javascript 디버거가 별도로 설치될 수 있다. 또는 3rd Party 제품이 뜰 수도 있다. 다른 제품들은 각 제품의 설명을 보도록 하고, 여기서는 Visual Studio로 선택하도록 한다.

혹여 Visual Studio일지라도 이미 떠 있는 Visual Studio를 선택할 수 있는데, 가급적이면, 새 인스턴스 Visual Studio를 선택하도록 한다.

3. Visual Studio 에서 디버깅.

“새 인스턴스 Visual Studio XXXX”를 선택하고 “Y”를 클릭하면 Visual Studio가 뜬다. 이 때 디버깅을 하는 것은 iexplore.exe 자체. 무슨 프로세스를 걸던 간에 일단 띄워보면, 정확한 오류 메시지를 알려준다.

 
오류 보시고, 이번엔 “중단(B)” 버튼을 클릭한다.
그러면 소스가 보일 것이고, 어디서 오류가 났는지 볼 수 있다.

왼편에는 지금 오류가 난 페이지와 관련된 각종 Javascript 소스들과 Html 소스들이 쭉 나래비가 펼쳐질 것이고,
오른편에는 해당되는 소스가 보인다. 여기서 부터는 Visual Studio 만의 디버그 UI를 활용함으로써 충분한 기능을 발휘할 수 있다.

소스 자체에서 커서를 위로 올리면 인텔리센스의 또다른 기능인, 변수 값들을 볼 수 있으며, 조사식, 콜스택, 지역 변수 값들을 모두 보면서 진행할 수 있다. 한단계씩 실행할 수도 있다.

4. 고급 디버깅 - 중단점

꼭 오류가 나기 이전 단계에서 디버그를 시작하고 싶은 경우에는 중단점을 이용하면 된다.
자신이 원하는 곳에다 중단점을 걸고 진행하면 되는데, 이를 위해서는 항상 동일한 위치에서 오류가 발생해야 쉽게 적용 가능하다. 방법은 아래와 같다.

1. 자신이 원하는 위치에 중단점을 건다.(Visual Studio 버전에 따라 중단점을 걸게 되는 조건이 조금씩 다르다.)
  
2. 디버그를 끝까지 진행시킨다.(디버그에서 계속 버튼 – 디버깅이 멈춰진 곳에서 계속 진행하도록 하는 버튼)을 누르거나 선택하면 된다.)
   
3. 경고창으로 뜨는 메시지에 예외를 iexplore로 보내겠다는 메시지에 예(Y)를 선택한다.
  
4. 브라우저로 돌아와서, 다시 Refresh를 한다.

5. 그러면 자신이 중단점을 건 위치에 커서가 멈춰 있게 된다.
  

 

5. 줄이며.

사실 Visual Studio의 기능은 막강한 편이다. 최초 5.0, 6.0 같은 경우 Windows 기반 Application 제작에 비중이 실렸다면, Visual Studio 2003 부터 조금씩 조금씩 웹 쪽에 대한 기능이 실리기 시작했다. 특히 Visual Studio 2005 부터는 ASP 개발에 있어 그 편리성은 혁신에 가깝게 진행되었다.

최소한 위의 디버그 모드에 대한 기능은 2003보다는 2005가, 2005 보다는 2008에서 더 정확하게 확실하게 동작함을 알 수 있다. 다소 툴이 무거워 쉽게 접근하는건 무리겠지만, 웹 표준에 제대로 맞지도 않는 웹 개발을 특히나 유지보수를 하려고 한다면, IE를 쓰고, Visual Studio를 쓰는 강수를 노려야 되니… 뭐 억지로라도 쓰도록 한다.
일단 쓸 수 있는 환경(CPU나 RAM이나.. 개발자 PC의 성능 문제가 대부분)이라면, 나름 장점이 많은 도구이니, 활용하는데 큰 무리가 없으리라 본다.


UPDATE:

저 위의 방법은 Javascript가 오류가 난다는 가정하에서 하나씩 거는 방법이다. 만일 Javascript의 오류가 나지 않을때, 디버그를 걸어 확인하고 싶을 때까 있다.

그런 경우에는 소스 내에 "debugger;" 라는 줄을 추가하면 된다.

그러면 debugger 라고 적힌 줄에서 에러가 난 것 처럼 표시되고, 위의 방법대로 진행이 가능하다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

블로그 필자 관리

기술자료/Web 2010. 7. 2. 11:30

블로그 내 필자를 관리하는 방법을 설명합니다.

 

일단 scmaid.org의 관리자 페이지에 들어갑니다.

들어가는 방법은 아래 메뉴에 표시된 위치를 클릭하면 들어가집니다.

 

 

다음은, 관리자 화면으로 넘어갈때, ID/Password를 묻는데, (안 묻는다면 일단 Logout을 하시고 다시 들어기시기 바랍니다.) 그 안에 관리자 아이디와 암호를 넣습니다.
(아이디와 암호 부분은 이정호 선임을 통해 전달 받거나 하시면 됩니다.)

 

 

이제 관리자 화면을 볼 수 있는데, 그 중, 네트워크 –> 필진 목록을 클릭해주세요.

(만일 IE 8.0에서 메뉴가 제대로 보이지 않으면 주소 줄 옆의 호환성 보기 아이콘( )을 클릭하세요!)

 

 

필진 목록을 클릭하면 필진 목록이 보이는데, 여기에 모든 기능이 담겨 있습니다.

직접 페이지를 띄워서 테스트를 하셔도 되고, 화면을 보시면서 익혀도 됩니다.

 

 

1. 필진 초대하기.

팀 블로그이기 때문에, 필자가 1인이지 않습니다. 여러 사람이 동시에 글을 올릴 수 있습니다. 그러나 공개 게시판과 같은 형식이 아니기 때문에, 특정 인에 대해서만 필진으로 등록하게 됩니다. 여기서 중요한 것은 필진의 이메일 주소가 반드시 필요합니다. 또한 이메일 주소 자체가 ID이기 때문에, 반드시 올바른 이메일 주소여야만 합니다.

먼저 관리자는 초대장 부분에 있는 “받는 사람” 필드에 E-Mail 주소를 넣습니다.

그 외의 부분은 필요한 만큼만 채우시면 됩니다. 그리고 초대장을 발송하세요.

 

그러면 받는 사람에게 다음과 같은 메일이 옵니다.  메일 안에 “블로그 바로가기”라는 링크를 클릭하시면 됩니다.

클릭하면 아래와 같은 화면이 뜹니다.(자동으로 생성된 암호로 로그인됩니다.)

 

필명에다가 자신의 별명이나 이름을 씁니다. 저 이름으로 글 쓸 때마다 박히니, 가명을 쓰셔도

되고, 진명을 쓰셔도 되고, 별명을 쓰셔도 무방합니다.  그리고 그 아래의 “저장하기” 버튼 클릭하시구요.

 

다음은 비밀번호 있는 부분에 있는 부분에서 “새로운 비밀번호” “비밀번호 확인” 부분에 자신만의 암호를 넣어주세요.

만일 이 부분을 안채우시면 암호를 알 길이 없습니다.(자동으로 만들어진 비밀 번호이여서, 관리자도 알 수 없습니다.)

입력 후 “저장하기” 버튼을 클릭하세요.

 

나머지는 그대로 두세요!

 

 

이렇게 필진을 등록하시면 됩니다.

 

2. 필진 관리하기.

필진 관리는 관리자 권한에서만 가능합니다.

관리로는 필진의 권한 설정과 필진 삭제 정도의 기능이 있습니다.

그 모든 처리는 표 안에서 다 됩니다.

필진 관리를 하기 위해서는 관리자 페이지에서 네트워크 –> 필진 관리로 일단 들어갑니다.

 

 

권한 부분의 설정은 관리자, 글관리가 있는데,

이중 최소한 글 관리에 체크를 해주시기 바랍니다.

체크하는 순간 알아서 저장 적용됩니다.

 

마찬가지로 필진을 빼고 싶은 경우 사용자 제외를 클릭하시면 됩니다.

(삭제된 필진의 글은 모두 관리자로 넘어가게 됩니다.)

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

바탕화면 폴더 변경

기술자료/OS 2010. 3. 29. 12:15

예전에 포스팅 했던 글 중에 하나가 있었는데, 미묘하게 잘 안되길래, 이래 저래 확인해서

다시 정리한다.

사실 바탕화면에 파일을 어지럽게 많이 올려놓게 되면 시스템이 전체적으로 느려지는 현상이 있다.

하지만, 업무를 하다 보면, 이 바탕화면의 활용도가 당연스럽게 높기 때문에 이 부분에

각종 서류들이나 작업 파일들이 존재하게 된다.

이 때, 긴급하게 윈도우를 밀어야 될 때, 바탕화면 백업에 대해 잘 신경 쓰시는 분은 문제 없지만,

나 같은 경우 대부분 신경 끊고 밀어 버리는 경우가 많다.

그러다가 서류 파일도 덩달아…

이번에 업무 관계로 XP를 설치했는데, 문득 든 생각으로 정리하는 마음에 다시 적는다.

 

Windows Vista와 Windows 7은 잘 정리된 개인화 폴더 설정으로,

특정 개인 폴더(내 그림, 내 문서, 바탕화면, 내 음악 등등)이 얼마든지 커스터마이징이 된다.

그런데, XP에서 제공되는 기능은 내 문서가 고작 변경이 가능하다.

이 부분은 레지스트리 편집으로 어떻게든 매울 수 있다.

 

설정 방법은 다음과 같다.

 

  1. Regedit를 실행한다.
  2. HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer 위치로 이동한다.
  3. Explore 폴더 아래에 에서 먼저 User Shell Folders 로 이동한다.
           desktop_location_change002
        그 안의 값들 중 “Desktop”의 위치에 자신의 폴더값으로 변경한다.
        지금 현재 내가 사용하는 값이 D:\MyData\Desktop 인데, 이 값으로 변경했다.
        desktop_location_change004
            
  4. 변경했으면 이번에는 Shell Folders 로 이동한다.
           desktop_location_change001
        마찬가지로 그 안의 값들 중 “Desktop”의 위치에 자신의 폴더값으로 변경한다.
        지금 현재 내가 사용하는 값이 D:\MyData\Desktop 인데, 이 값으로 변경했다.
         desktop_location_change004
  5. 모두 변경 완료 되었으면 이번엔 자신의 바탕화면 폴더에 있는 모든 파일을 저 위치로 복사해준다.
       파일 옵션에 시스템 파일 숨김이나, 숨김 파일 숨김 기능들은 모두 끄고 열어야 모든 파일이 보인다.
       보통 XP의 바탕화면에 있는 파일들은 C:\Documents and Settings\{자신의로그인ID}\바탕 화면
       (예를 들어 로그인 이름이 “홍길동”이면 C:\Documents and Settings\홍길동\바탕 화면 )
        위치에 있다.
  6. 복사까지 끝났으면 이제 리붓.

 

 

사실 방법은 크게 어려운 것은 아니지만, 처음 해보거나 하면 문제가 있을 수 있으므로 십분 주의하면서 해야 한다. 해보고 자신이 붙으면 다른 폴더들(내 음악 등등)도 변경할 수 있을 것이다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

객체 지향 C#의 꽁수. Singleton 패턴.

기술자료/.NET 2010. 2. 10. 11:02

사실 전역변수 처럼 쓰이는 각종 응용 프로그램 설정 내역들이 있다.

보통은 app.config 혹은 web.config 를 통해 값을 읽어오게 되는데,

그 로직 아무리 짧아야, 2~3줄씩 되고,

설정이 필요할 때 마다 app.config 혹은 web.config에서 일일히 읽어오는 것도 나름대로 곤욕이다.

그러기 위해 Sigleton 패턴을 사용하는게 제일인듯.

 

그런데, 이런 Singleton 패턴은 Windows 응용 프로그램 같은 경우야,

하나의 인스턴스니 상관 없지만, 웹 응용 프로그램같은 경우에는 조금 난감한 것도 사실.

 

이에 현재 나름대로 고민해서 짜본 방법이 아래와 같다.

 

public static class ConfigManager()

{

        public static string TempFileLocation

        {

                get

                {

                          string sResult = string.empty;

                          try

                          {

                                 sResult = ConfigurationManager.AppSettings["tempfolder"];

                          }

                          catch

                          {

                           }

                           return sResult;

                 }

 

         }

}

 

저렇게 만들면 ConfigManager를 일일히 new 할 필요가 없다. Heap이 아닌 응용 프로그램 저장 위치에 단 한개의 인스턴스만 존재하므로, 최소한 이 부분을 띄워주는데에서는 무조건 저 한개의 로직에서 처리가 된다.

저 방법의 핵심은 static 인데, static으로 정의되는 내용은 어쨌던 별도의 Instance 생성이 필요없다는 훌륭한 강점을 가지게 된다.

 

그런데, 설정 구성이 많아지게 되면 그 만큼 코드도 무척 길어지게 된다. 처음 설정 내역이 4~5개 까지는 그럭저럭 봐주는데, 설정 내용이 20여개를 넘자, 매번 저렇게 구성하는것도 환장하겠고, 더욱이 appsetting의 Key 값이 변경될때도 나름 고역. 
더욱이  매번 appsetting 에서 값을 읽어오는게 영 마음에 꺼림찍했다.(NET 프레임워크 개발한 분들도 나름 천재들이니, 옵티마이징 하면, 저 로직도 나름 정리가 잘 되리라 생각은 하지만)

그럼 데이터를 1회만 읽어오고, 모두 한자리에 때려 박는 방법을 다시 생각했다.

public static class ConfigManager()

{

       static ConfigManager()

       {

                try

                {

                        ConfigManager.tempFolderLocation =
                                     ConfigurationManager.AppSettings["tempfolder"];

                }

                catch

                {

                }

         }

 

        static string tempFolderLocation;

        public static string TempFileLocation

        {

                get

                {

                          return ConfigManager.tempFolderLocation;

                 }

 

         }

}

 

즉 static 클래스 안에 Constructor를 만들어서 그 안에서 1회 읽어오게 하고,

실제 일반 사용자가 사용하는 부분에서는 static으로 저장된 변수 값만 읽어가게 되는 것이다.

직접 XML이나, INI 파일 파서를 만든 상태라면, 그 로직을 Constructor에 만들고

구성하면 되는 것이다.

즉 핵심은 static 클래스에서 static 생성자를 만드는 것!. 이게 핵심.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

2008 R2 x64의 IIS 위에서 32bit 응용 프로그램 돌리는데 꼭 확인 필요.

기술자료/Web 2010. 2. 10. 10:43

지금까지 2003 IIS만 주로 쓰고 있다가, 2008로 넘어오면서 나름 적응을 했다고 생각했다.

그런데, 2008 R2에서는 시스템 성능 및 보안 등등 여러가지를 손 본듯 싶었다.

 

이번에 지원 프로젝트건이 있어 잠시 나왔다.

ClearQuest 7.1.1 과 IIS간의 연동 부분이 있는데, ClearQuest에서 제공하는 COM 과 연결하는 작업이 반드시 필요한 내용이였다.

로컬 및 자체 Staging 서버(애석하게도 여기는 2008이였지, 2008 R2가 아니였다.)에서는

잘 돌다가, 갑자기 운영서버에 올라가니 다음과 같은 오류를 뿜었다.

 

'/' 응용 프로그램에 서버 오류가 있습니다.
--------------------------------------------------------------------------------

80040154 오류로 인해 CLSID가 {94773112-72E8-11D0-A42E-00A024DED613}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.
설명: 현재 웹 요청을 실행하는 동안 처리되지 않은 예외가 발생했습니다. 스택 추적을 검토하여 발생한 오류 및 코드에서 오류가 발생한 위치에 대한 자세한 정보를 확인하십시오.

예외 정보: System.Runtime.InteropServices.COMException: 80040154 오류로 인해 CLSID가 {94773112-72E8-11D0-A42E-00A024DED613}인 구성 요소의 COM 클래스 팩터리를 검색하지 못했습니다.

소스 오류:

줄 19: ....

 

처음에는 COM이기 때문에, 해당 서버에 저 COM이 제대로 등록되어 있지 않았나 싶었다.

그래서 구성 요소 서비스에 들어가, 해당 Component가 이상한가 봤는데,

애석하게도 내가 다루고 있던 COM은 서버형이 아니므로 전혀 무관계.

이번에는 RegEdit 를 띄운 뒤, 저 CLSID를 검색하는데,

잘 걸린다. 위치도 제대로 되어 있고, 모든 설정은 OK! 였다.

.NET Framework 문제인가? 3.5가 아닌 2.0 기반의 Classic .NET 설정의 문제인가.

아니면 내가 코드를 짤 때 레퍼런스 설정이 잘못된 것인가?

여러가지 의문점들을 하나씩 수정하면서 체크해봤다.

대략 1시간 정도 시간을 보내고 났다.

그러나 방법은 모르겠고.....

 

그러다가, 현재 동작 중인 응용 프로그램 설정에서 다음을 보았다.

3264compotableproblem

 

저게 x64 형태의 서버에서만 설정하는 부분인 것 같다.

성능상의 Issue를 최소화 시키기 위해 x86기반의 응용 프로그램 제외 모드가 있는 것 같다.

그런데, 애석하게도 저 옵션이 Default 값이 False인듯.

True로 바꾸자 모든게 매끄럽게 진행이되었다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

Google Apps Engine을 통해 응용 프로그램 설계 시 주의사항

기술자료/Web 2010. 1. 30. 21:40

앞서 포스팅한 글에서 언급한 문제에 대해서 자세히 설명을 하려고 한다.

 

아마도 Google Apps Engine은 아마존이나 MS와는 다르게 초기 진행은

완전 무료로 진행되기 때문에, 어중이 떠중이(필자를 포함한) 다양한 사람들이 접근하기 때문에,

CPU에 큰 무리가 될 작업은 아예 배제하고 출발한 것 같다.

(아니면 단순히 설계에서 고려 사항에서 제외하고 출시 한 것일지 모른다.)

 

지금 현재 관점으로 바라볼때 Google Apps Engine은 다음과 같은 구조를 가지고 있다.

아주 단순한 모양인데, GAE 위에 얹어 놓은 모든 응용 프로그램은 Request/Response 기반으로

동작하게 된다.

 

자 여기서 함정이다.

즉 Request와 Reponse 사이에 Web Browser에서는 Time-Out을 결정하게 된다.

만일 GAE에 올려놓은 응용 프로그램 내에 처리해야 되는 내용이 많은 경우에는

Web Browser에 Response를 줄 수 없는데, 이러면 응용 프로그램 오류가 발생한다.

 

물론 응용 프로그램의 설계를 웹 중심으로 다시 생각하여 하나씩 재 설계하면 가능하다.

 

하지만, 로직을 만들다 보면, 내부적으로 처리되야 하는 경우가 있다.

무언가 작업의 Flow가 있을때, 중간에 끊기면 다음 작업의 완성도에 대한 장담이 어려운 경우가

있는데, 이런 응용 프로그램은 참 곤란하다.

예전에 아마존 클라우드 서비스에 대한 소개 내용 중 이런게 있었다.

한 대중 매체 사이트에 담긴 모든 형태의 파일 형식을 바꿀 일이 있었는데,

이 때 아마존의 클라우드 서비스를 이용하여 임대 식으로 해당 자원을 활용하여 변환했다고 한다.

만일 고도의 계산이나 많은 부하가 필요한 변환 작업이라고 할때, 한번 변환 작업이 5분 걸린다면?

이거 Timeout으로 Exception 뿜고 죽는다.

 

 

그렇다면? Back-end에서 처리하는 방법은?

안그래도 Azure를 하면서 그런 기능을 찾아보았다.

Azure에서는 Worker라는 개념이 있어서, 사용자의 특정한 Request가 없이도 실행할 수 있는

로직이 있었다. 게다가, 이 개념에서 시작과 끝에 대해서는 완전 비동기로 동작할 수 있도록 했다.

즉 사용자의 Request는 그 Worker를 동작시켜주세요!!!! 이 정도로 끝내고,

나중에 필요할 때 그 결과값을 얻을 수 있었다.

 

그러나 이 GAE 안에는 그런 개념은 없었다.

비슷한 기능이라고 생각한 기능을 찾기는 했는데....

바로 Cron이였다. 아 뭐 특이한건 아니고, Linux에 있는 그 Cron이다.

일정 시간이 되면 실행하는 그 데몬. 그런데 웃기는건 이 Cron도 위의 한계를 그대로 안고 있다는

것이다. 즉, 사용자가 직접 액션을 안한다 뿐이지, 실제로는 그 동일한 한계를 들어낸다.

위와 같은 꼴이니, 만일 GAE안의 응용 프로그램이 Timeout에 빠진다고 한다면?

동일한 오류를 뿜고 끝!

 

그래서 방법은 한가지 밖에 없다고 판단한다.

클라이언트가 복잡해지는 수 밖에 없다는 생각이다.

 

 

뭔가 복잡한 그림이 됐지만, 원리는 간단하다.
즉 Client 쪽에 로직을 세우면 된다.

 

프로그램을 시작한 뒤, 그 다음 단계에 뭐하고 그 다음 단계의 다음 단계에 뭐하고 하는 것을

Client에서 구현한 뒤, 실제 데이터 입출력이나 처리 작업만 일부분만 넘기는 것이다.

GAE에서는 단지 그 일부분을 처리하기 위한 로직 만을 세우면 되는 것이다.

 

위의 예를 가지고 사용자의 클릭 한번에

     Action1 -> Action 2 -> Action 4

의 작업을 수행한다 가정하자.

그러면 다음과 같은 순서로 실행될 것이다.

  1. Action 1 실행
  2. Action 1에서 GAE의 Action1에 해당하는 루틴 Requst.
  3. GAE의 Response 내용을 받음.
  4. Action 2 실행.
  5. Action 2에서 GAE에 Action2에 해당하는 루틴 Request.
  6. GAE의 Response 내용을 받음
  7. Action 4 실행
  8. Action 4에서 GAE에 Action2에 해당하는 루틴 Request.

 

즉 GAE에서는 웹 서비스의 단위 메소드,

이른바 Web 2.0의 한 유행인, 공개 API와 같은 꼴로 구성하면 어떻게든 된다.

 

 

아직은 구성에 대해서 다양한 시도와 파악 중이다.

현재까지 이 Google Apps Engine을 통해 무언가를 만든다는 개념은

위의 형태에서 벗어나게 되면 이래 저래 힘들듯 싶다는 생각이다.

 

지금까지 파악한 방법에서 성공한 방법은

클라이언트 측은 Rich 하게 만들고, GAE에서는 가볍게 만들어

GAE에 데이터를 저장하고 가공하는 정도?

그것도 Time-out 걸리지 않을 정도로, 아주 가볍게 처리해야 한다는 것이다.

 

UPDATE 2010-01-30   21:40

Auzre의 Worker의 비동기 개념을 탑재 시켜준 거와 비슷한 기능이 있다.

Task Queue Java API다.  그런데, Time Out 레벨의 작업 역시 못하리라 생각은 든다.

Workflow 형태로 뭔가 Back-end에서 실행은 할 수 있을지는 모르겠는데,

역시 동작에 필요한 무언가의 작업은 Google Apps 내 웹을 부르는 작업을 수행한다.

하지만 아직 이 부분에 대해서 실험은 안 해봤다.

(게다가 이 동작 Java 에서는 베타 테스트 중이다. )

 

아직은 개발 도상 단계인듯. 조금 더 살펴봐야 겠다.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

[Google Apps Engine] 응용 프로그램 올리기.

기술자료/Web 2010. 1. 30. 20:39

관리자 콘솔(Administration Console)를 사용하여 App Engine 안의 각종 응용 프로그램을 생성하고, 관리할 수 있습니다. 응용 프로그램에 대한 응용 프로그램 ID를 한번 등록하면, 다른 이클립스 플러그인이든, SDK 에서 제공하는 명령줄 도구를 사용하든, App Engine으로 업로드 할 수 있습니다.

 

NOTES: 응용 프로그램 ID를 한번 등록한 뒤, 그 응용 프로그램을 삭제하면, 나중에 그 ID로 같은 응용 프로그램을 올리지 못합니다. 만일 지금 등록하지 않으려면, 이 단계를 건너 뛰시기 바랍니다.

 

응용 프로그램 등록하기.

App Engine 관리자 콘솔에서 App Engine 웹 응용 프로그램들을 생성하고 관리할 수 있습니다. 이 App Engine 관리자 콘솔에 접속하려면 다음 URL에 접속하도록 합니다.

https://appengine.google.com/

 

지금 사용 중인 구글 계정을 통해 이 App Engine에 가입하도록 합니다. 구글 계정이 없으시면, 이메일 주소와 암호를 가지고 https://www.google.com/accounts/ 에서 구글 계정을 생성하실 수 있습니다.

 

응용 프로그램을 생성하려면, "Create an Application" 버튼을 클릭하시기 바랍니다. 그리고 그 안에서 설명하는 내용을 따라 이 응용 프로그램에 대한 application ID와 고유한 이름을 등록하시기 바랍니다. 만일 무료로 도메인을 제공하는 appspot.com 을 그대로 사용한다면, 전체 URL은 http://application-id.appspot.com 이 됩니다. 아니면 top-level의 별도의 도메인을 구입하여 사용하신다면, 원하는 이름으로 설정하여 구성하실 수 있습니다.

 

일단 응용 프로그램 ID를 받았으면 그 내용을 지금 만든 응용 프로그램에 그 내용을 넣어주셔야 합니다. 그 방법은, appengine-web.xml 파일을 연 뒤, <application> 엘리멘트 안에 등록한 응용 프로그램 ID를 넣어주시면 됩니다.

 

응용 프로그램 올리기.

이클립스를 사용하여 응용 프로그램을 올리는 방법은 간단합니다.

모든 동작은 Google Apps SDK의 플러그인에서 대부분 자동으로 처리해 줍니다.

일단 응용 프로그램이 모두 정상적으로 동작한 것을 확인 하셨으면,

툴 바에서 App Engine deploy 버튼(

)을 클릭해주시면 됩니다.

 

그리고 아이디와 암호 입력창이 뜨면, 구글 계정에 대한 아이디(이메일 주소)와 암호를 넣어주시면 됩니다. 그리고 Upload 버튼을 클릭해주시면 됩니다. 그러면 이클립스에서는 앞서 수정한 appengine-web.xml 에서 응용 프로그램 ID와 버전 정보를 가져와서 war/ 디렉터리에 있는 파일을 패키징 해서 업로드 하기 시작합니다.

 

올린 응용 프로그램 실행해보기.

App Engine 상에 만든 응용 프로그램을 실제로 확인할 차례 입니다. 간단하게 무료로 제공하는 appspot.com 도메인을 통해 바로 접속해 볼 수 있습니다.

 

http://application-id.appspot.com

 

 

축하드립니다!!!

이제 기초적인 내용은 모두 끝났습니다. 최소한 이 단계까지 오셨다면 Java를 이용한 Google Apps Engine 용 응용 프로그램 만들기의 처음부터 끝까지 다 거친 것입니다.

이 외의 더 자세한 내용은 App Engine 문서를 통해 자세하게 확인해보시기 바랍니다.

 

 

 

 

You create and manage applications in App Engine using the Administration Console. Once you have registered an application ID for your application, you upload it to App Engine using either the Eclipse plugin, or a command-line tool in the SDK.

728x90
블로그 이미지

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

  • «
  • 1
  • ···
  • 9
  • 10
  • 11
  • 12
  • 13
  • 14
  • 15
  • ···
  • 44
  • »
250x250

블로그 내에 소스 코드 삽입 이사온 기념 스킨도... RSS 전문 기능 비활성화 관련. 스킨 바꾸어 보았습니다. 서버 파일 정리 좀 했습니다.

«   2025/05   »
일 월 화 수 목 금 토
1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30 31

windows java 블로그 moss 비스킷 me2photo 좀 협업 Buscuit 개발환경 MOSS 2007 수 것 매뉴얼 me2dayzm Azure 오류 지름신 me2sms Google Apps Engine Visual Studio 불만 인터파크 twi2me WSS 2010 SharePoint Tutorial e-book 친구

  • Total :
  • Today :
  • Yesterday :

Copyright © 2015-2025 Socialdev. All Rights Reserved.

Copyright © 2015-2025 Socialdev. All Rights Reserved.

티스토리툴바