포스트 플래쉬 시대


UI 개발에 대한 관심

UX : 사용자가 제품, 또는 서비스를 제공하는 회사에 대해서 경험하는 전체적인 효과, 효율, 만족을 의미합니다. UI를 포함하는 전체적인 경험을 의미하고, UI를 주요한 요소로 포함합니다.


실버라이트


플래쉬

  • Adobe AIR (Adobe Integrated Runtime - codename Apollo)
  • Build with HTML/AJAX, Build with Flex
  • 웹앱스콘 네이버 오픈API 코드 샘플 (http://www.blo9.com/wp/?p=389)


자바 FX


Posted by 미친병아리

댓글을 달아 주세요

96년도에 졸업하고 사회생활을 하면서 가장 처음으로 접한 DB서버가 MS SQL 6.5였다.. 그래서 그런지, 오라클 보다는 MS SQL에 더 정이 가는가보다.. 첫인연도 그렇지만, 사용하기에 MS SQL 서버가 훨씬 편리하다는 특징이 더 이런 상황을 만들었을 것이라 생각한다..

MS SQL 서버의 편리함은 인스톨과정에서 부터 조금만 사용해보면 바로 나타난다.. 설치, DB 생성, 백업, 백업으로부터의 복구 등등의 과정을 프로젝트 진행간 자주 해보면 MS SQL 서버를 사용해보면 편리하다.. mySQL 같이 간편하면서, 성능은 오라클 못지 않는다고나 할까.. 뭐, 이렇게 말하면 오라클 유저들에게 한 소리 듣는다.. 어떻게 오라클과 MS SQL을 성능 비교를 할 수 있느냐, 비교할 것을 해야지.. 하지만, 난 MS SQL과 오라클의 성능차이는 거의 없다고 생각한다..

아무튼, MS SQL 서버를 사용하면서 가장 편리한 점은 DB 복사를 손쉽게 할 수 있다는 것이다.. 예를들면 개발중인 DB서버에서 이 DB를 다른 서버에 그대로 복사본을 만들고 싶으면 DB 파일만 새 서버에 복사를 해서 새 MS SQL 서버에서 파일로 DB에 연결만 하면 끝이다.. 오라클에서는 이 과정이 꽤 복잡하다..

하지만, 이때 좀 귀찮은 경우가 생길때가 있다.. 위와 같은 방법으로 A서버에 CBT라는 DB를 B서버에 똑같이 만들어서 A서버에서는 계속 개발을하고 B서버에서 단위테스트를 진행을 했다.. 그러다 DB가 변경된 부분들이 생겨서 B서버에 DB를 다시 옮겨야 한다.. 이때도 B서버의 CBT DB를 없애고 위와 같은 방법으로 새로 붙이면 되는데 문제는 계정이 좀 꼬이는 경우가 생긴다..

A서버에서와 같은 이름과 패스워드 계정으로 CBT DB에 접근하고 싶은데 이미 계정이 있으니 만들 수 없다는 둥, 이런 문제가 발생하는 것이다.. 정말 큰 문제는 이런 경우 MS SQL 엔터프라이즈 메니저 (2000이하) 혹은 SQL Server Management Studio (2005이상)가 제공하는 UI 상에서는 이 문제를 해결할 수 있는 방법이 없다.. 모든 작업을 커맨드 라인이 아닌 UI에서 하는 MS SQL 서버의 특징에 위배되는 상황이다.. 하지만, 뭐 방법없다.. UI에서 제공 안해주니 별 수 없지.. 쿼리를 날려 해결해야 한다.. 이때 사용하는 스토어드 프로시저가 sp_change_users_login 이다..

사용법 : EXEC sp_change_users_login 'Update_One', 'cbt', 'cbt'
이 스토어드 프로시저를 사용하지 않으면 해결할 수 있는 방법이 없는데, 도움말에서 이거 찾기도 쉽지 않다.. 쩝..
Posted by 미친병아리
TAG db, MSSQL

댓글을 달아 주세요

  1. Favicon of http://ismytreasure.tistory.com BlogIcon 민서대디 2007.07.05 13:36  댓글주소  수정/삭제  댓글쓰기

    좋은(?) 명령어 죠..^^
    가끔 애용하고 있다는..

  2. Favicon of http://bluesman.tistory.com BlogIcon Jerry 2007.08.15 21:07  댓글주소  수정/삭제  댓글쓰기

    블로그 답방 왔습니다. 티스토리에도 공간을 마련하셨네요. 앞으로 자주 들르도록 하겠습니다. 저는 보안을 하는 입장이다 보니, MS SQL 서버 하면 당장엔 1.25 대란이 떠오르네요. 블로그에 남겨주신 글을 보니, 예전에 기타도 치셨던 모양입니다. 일거리 외에 정신적 위안이 될 수 있는 취미가 있으면 참 좋다는 생각을 하곤 하는데, 간혹 이 취미때문에 스트레스를 받기도 해서 좀 난감할 때가 있습니다. 앞으로 종종 방문하도록 할께요. ^^

새로운 OS가 나오게 되면 가장 관심을 가지는 것은 과연 내가 만든 프로그램이 새 OS에서 정상적으로 동작할 것인가 하는 점이다.. 윈95가 등장할때 그랬으며, 윈98, 윈ME, 윈2000, 윈XP 등등.. 이번 윈도우 비스타도 예외는 아니었지만, 그러면서도 안심이 되는 부분은 MS가 새 OS를 내 놓을때 가장 신경을 많이 쓰는 부분이 다름아닌 하위호환성 보장이라는 것.. 새 OS들이 나올때마다 걱정은 했지만, 별 일 없이 넘어갈 수 있었던 것이 바로 이 부분 때문이었으며, 이번에도 큰 어려움 없을 것이라는 안일한 자세.. 사실 윈3.1에서 윈95로 넘어갈때 말고는 큰 일이 없었던것이 사실이다.. (Microsoft가 그렇게 중요시 하는 하위호환성에 대해 자세히 느껴보고 싶으면 조엘 온 소프트웨어를 읽어보시길..)

하지만, 윈도우 비스타는 달랐다.. 많이 달랐다.. 윈XP에서 잘 돌아가는 프로그램을 윈도우 비스타에서 돌아가게 만드는데 무려 2달 정도가 걸렸다.. 물론, 다른 일들이 많아 팀원 전체가 붙어 대응을 하지 못해 오래 걸리긴 했지만, 애초에 예상했던 것 보다는 훨씬 오래걸린 대응 준비기간이었다..

우리 프로그램의 문제점
- ActiveX 컨트롤
- 레지스트리
- 파일저장
- 프로세스 생성
- 윈도우 메시지 전달
ActiveX 컨트롤은 사실 아무런 문제없이 윈도우 비스타로 옮길 수 있다.. 윈도우 비스타라고 해서 ActiveX 컨트롤이 없으질게 아니고 (Silverlight도 윈도우 환경에서는 ActiveX로 구현되며, 플래쉬, 애크로뱃리더도 ActiveX로 구현되어 있기 때문에 대체기술이 나오기 전에는 없어질 리가 없기 때문에.. 대체기술은 웹표준이 그래픽과 멀티미디어쪽으로 확정되기 전에는 오랜기간 없을 것으로 보인다..) 기본적으로 우리 프로그램도 아무런 문제가 없었지만, 레지스트리와 파일억세스를 하는 부분이 많았다..

레지스트리 접근은 HKEY_CURRENT_USER 하위는 읽고 쓸 수 있기 때문에 위치만 옮기면 아무런 문제가 되지 않는다.. 물론, 현실에서는 이 위치를 공유하는 프로그램들이 많을 수 있고, 어떤 프로그램에서는 위치를 변경하는게 만만한 작업이 아닐 수 있기 때문에 현실은 그리 녹녹치 않을 수도 있다.. 가장 좋은 방법은 레지스트리 사용은 아예 하지 않도록 수정하는 방법이 정답이다.. 하지만, 우리 프로그램은 새 버젼이 개발중이었으므로 최소한의 노력을 들이기로 했다..

파일저장 부분도 사실 큰 어려운 부분은 아니지만, 레지스트리의 경우와 비슷하다.. 권한이 없는 폴더에는 접근하지 않도록 수정해줘야 한다.. 특히, 권한을 가진 프로그램이 만들어둔 파일을 다른 프로세스에서 접근해야 하는 경우 문제가 생길 수 있다.. 가장 문제가 되는 것이 ActiveX 컨트롤이 접근해야 하는 경우인데, 이 경우는 ActiveX 컨트롤이 해당 파일에 접근할 수 있는 방법이 없으므로 권한이 낮은 프로세스에서도 접근 가능한 위치로 옮겨야 한다..

프로세스 생성은 비교적 간단하다.. ShellExecute에 추가된 파라미터를 넣어 높은 권한으로 실행시킬 수 있는 방법이 있기 때문이다.. 하지만, 원래 권한이 낮은 곳에서 (다른 프로세스나 ActiveX 컨트롤이) 높은권한의 프로세스를 실행시키는 일이라 권한상승 경고창이 뜬다..

윈도우즈 메시지 전달은 사실 별로 신경을 쓰지 못했던 부분인데, 낮은 프로세스에서 높은 프로세스로 메시지를 보내는 것은 사정없이 무시된다.. 특히, ActiveX 컨트롤이 실행파일을 실행시킨 후에 메시지를 통해 데이터를 전달하는 구조의 경우 문제가 된다..

하지만, 위의 문제들을 해결하기 위해 그동안 여러가지 검토를 하고 테스트 코드를 짜며 든 생각은 과연 무엇이 더 좋아졌는가 이다.. 좋아진 부분이 딱 하나 있기는 하다.. 권한이 상승된 프로세스가 허락없이 실행될때 경고창이 뜬다는 것이다.. 이점은 나 몰래 어떤 프로그램을 실행시키기가 더 어려워 졌다는 점에서 보안이 강화되었다고 할 수 있는데, 이외의 것들은 소위 하위호환성 때문에 조금만 코드를 고치면 XP에서 동작했던 것 처럼 동작하도록 수정할 수 있다.. 어찌 보면 내가 예상한대로였는데, 작년말쯤 팀원들과 이야기 하던 내용이 기억난다.. "그렇다면 좋아질게 하나도 없는데, 그렇게 고칠거면 뭐하러 고치나?"

열심히 함 고쳐보라는건가? 뭐하러 이런 소모적인 해야 수정을 하는지 모르겠다.. 되먹지 않은 악성 프로그램을 배포하는 사람들이 코드 좀 수정해서 비스타에서도 동작하도록 만들게 하기 위해, 전 세계 수많은 프로그래머들이 비스타에서 돌아가는 프로그램을 위해 코드를 수정하게 만들어야 했는가? 하위호환성 때문에 피해가는 방법이 다 존재한다면, XP에서 문제없이 돌아가는 프로그램은 비스타에서도 그냥 돌아가도록 하는게 더 좋았을 것이다.. 그렇다 하더라도 권한상승창 때문에 원래의 목적은 달성할 수 있었을 것이다.. 참, 아쉬운 부분이다..

권한 상승창이 뜨는 부분은 비스타 사용자들로부터 많은 이야기가 나올 것인데, 윈도우 비스타에서 깔끔하게 돌아가는 프로그램을 만들기 위해서 (권한상승 허가하는 창이 뜨지 않고 동작하도록)는 앞으로는 개발초기 설계시부터 잘 고려를 해야하겠다..


Posted by 미친병아리

댓글을 달아 주세요

  1. Favicon of https://isponge.tistory.com BlogIcon 마음으로 찍는 사진 2007.06.08 22:39 신고  댓글주소  수정/삭제  댓글쓰기

    이곳에도 놀러 왔습니다.
    RSS 등록 완료 하구요... 그런데 내용이 너무 난해해요~!~~