객체지향방법론은 프레임워크 디자인과 어플리케이션 디자인에서 약간의 차이를 보입니다.
객체지향 방법론은 유지관리성에 최적화 되어 있고, 어플리케이션 디자인 적용에서 더욱 가깝습니다.  이 포스트에서는 어플리케이션 디자인, 커스텀 라이브러리 디자인, 프레임워크의 디자인에 적용되는 객체지향방법론의 약간 다른 접근에 대해서 서술합니다.


Framework의 탄생
운영체제 벤더 들은 추상화된 API를 제공함으로써 개발자들이 좀더 쉽게 어플리케이션을 개발할 수 있다는 것을 인지 하였습니다.

동시에 Object-Oriented 방법론은 확장성과 재사용성 강조하는 방법론 이었고, 운영체제 와 라이브러리 벤더들은 OO방법론을 채택하였습니다. 이것이 우리가 생각하는 Framework의 개념의 탄생입니다.

더 많은 벤더들이 서로 연결함으로써 하나의 어플리케이션을 완성할 수 있는 재사용 가능한 컴포넌트들을 제공하였고, 어플리케이션 개발자들은 더이상 매번의 개발마다 맨땅에서 시작하는 일이 없을 줄 알았습니다.

하지만, 몇몇 컴포넌트들은 서로 잘 접합되지 않고, 필요 없는 요소들로 가득한 경우가 많아서 생산성에 부정적인 영향을 주게 되었죠.

결국에는 재사용 가능한 컴포넌트들에게 공통적인 룰을 적용함으로써  일관성(consistency)과 이음매 없는 통합(seamless integration)이 가능하다는 것이 명확해 졌습니다.

이로써  객체지향 방법론은 프레임워크( Framework ) 에 뼛속 깊이 스며들게 됩니다.

하지만, 프레임워크 디자인에 객체지향 방법론을 적용할 때 주의해야 할 사항이 있습니다.




어플리케이션 디자인
어플리케이션 개발자들은 프레임워크 위에 커스텀 라이브러리를 접합시키고 이를 이용하여 하나의 어플리케이션을 개발합니다. 유지관리성이 중요한 요소 입니다.





과도한 엔지니어링(OverEngineered) 문제

커스텀 라이브러리 디자인은 어플리케이션 디자인 보다는  프레임워크 디자인 개념에 가깝습니다.

개발자들이 프레임워크 디자인을 하지 않더라도 커스텀 라이브러리 디자인은 어플리케이션 디자인과는 다른 접근이 필요합니다.


객체지향디자인 방법론은 유지관리성에 최적화 되어 있습니다. 이는 지나친 추상화와 상속 구조를 강요합니다.

기반클래스(Base Class)의 수정으로 파생된 모든 클래스를 관리할 수 있으며, 코드 재사용을 지원하며 , Single Control Management를 가능하게 하기 때문이죠.

문제는 지나친 추상화와 상속은 프레임워크와 라이브러리 사용자로 하여금  간단한 시나리오의 어플리케이션을 작성할 때에도 전문가 이기를 강요하게 됩니다.





확장성에 대한 조금 다른 접근
어플리케이션 디자인에서의 클래스의 봉인(sealing)은 프레임워크 디자인에서의 것 보다 일반적 입니다. 어플리케이션과 커스텀 라이브러리는 도메인 specific 적입니다. 도메인에서의 역할 이외에 상속 되거나 확장되지 않도록 하는 것이 중요하며, 프레임워크는 어플리케이션 과 커스텀 라이브러리의 경우보다 일반적으로 사용되거나 확장되도록 허용 하는 것이 중요합니다.

어플리케이션과 커스텀 라이브러리가 sealed 가 일반적이라면 프레임워크 디자인은 unsealed 로 확장성을 중시 하는 것이 일반적이라고 볼 수 있습니다.






Interface에 대한 관점
프레임워크 디자인 가이드라인으로는 Interface 보다는 Class의 사용을 가이드 합니다. 프레임워크는 라이프사이클이 길고, shipping 된 후에 Class는 변경 가능하지만 Interface는 변경 불가능하면, Interface의 변경은 모든 구현된 객체의 변경을 요구하기 때문입니다.  Interface 보다는 Class가 좀더 유연하다는(flexibility) 관점입니다.

어플리케이션의 디자인에서는 Interface를 선택하는 것을 가이드로 할 수 있습니다.



결론
어플리케이션 디자인, 커스텀 라이브러리 디자인, 프레임워크 디자인에 모두 객체지향 디자인 방법론이 적용 되지만, 어플리케이션 디자인에는 유지관리성이, 프레임워크 디자인에서는 유연성과 확장성이 강조되고 커스텀 라이브러리 디자인은 둘 사이의 중간에 위치한다고 말 할 수 있습니다.



참조 : Framework Design Guidelines Second Edition , Addison-Wesley p.2, p32. p91.
현재글 : 객체지향 방법론과 프레임워크 디자인 vs. 어플리케이션 디자인 차이 posted By - 반더빌트 2010/02/03 14:59

웹기획자는 무엇을 하는 사람이고 어떤 결과물을 내놓아야 할까요?

이번에는 웹개발자의 역할에 이어 웹기획자의 역할을 포스팅 합니다.


정확히 말해서 개발 세상에서 '웹기획자'라는 직분은 모호합니다.

고객의 요구사항과 개발에 대한 모든 것을 모든 개발자가 알고 개발을 하면 이상적이겠죠. 
하지만, 개발 도메인 자체가 너무 큰 이유로 이상대로 한다면 개발자들은 커뮤니케이션만 하다가 프로덕트는 나오지 않고 볼짱 다보고, 회사는 문을 닫겠죠.  국민들 모두가 직접 정치를 하는 것과 같습니다.

  그래서 시니어 개발자(경험/경력이 있는 선임 개발자)가 전략 및 요구사항 분석에 참여 하여 개발의 큰 틀을 짜는 역할을 합니다. 개발이 진행 되는 동안 이해 관계자들과 지속적인 커뮤니케이션을 통해 개발을 보정(수정)하고 개발 진행을 지휘하게 됩니다. 간과 하지 말아야 하는 것은 이 일을 하면 능력의 대부분을 커뮤니케이션 하는데 보내야 한다는 것입니다. 이런 역할을 소프트웨어 엔지니어링에서는 '소프트웨어 아키텍트'라고 하죠.

'웹기획자'의 대두
이 과정에서 '웹기획자'라는 역할이 대두 됩니다. 개발자는 기술적인 부분을 전문화 하도록 뇌가 프로그램 되어 있습니다. 개발 세상의 전략이 아닌 실세계의 전략을 세우는 사람이 필요해 지는 것입니다.
 
프로젝트의 목표를 달성 , 개발자가 개발 할 수 있도록 
1. 개발로 번역 가능한 언어로된 문서를 작성 할 줄 아는
2. 실세계의 전략을 세울 수 있는
3. 개발 이외의 세상과의 대화능력을 가지고 있는
4. 프로덕트를 부드럽게 완성시키는데 조율 능력을 가지고 있는.

 개발 이외의 전문적으로 그 일들을 할 수 있는 그런 역할이 필요하게 된겁니다. 
- 마틴 파울러의 [소트웍스 앤솔러지]에서 '반복관리자'라고 표현하고 있는 역할이 이와 비슷하다고 말할 수 있습니다.


이런 역할을 하는 사람을  개발 세상에서는 "웹 기획자"라는 명함을 박아 줬습니다.


또는, 대한민국에서 '소프트웨어 아키텍트'를 거세하고 '개발자(Developer)'만을 남겨두고 '소프트웨어 아키텍트'의 역할을 '웹 기획자'에게 주었습니다. 그럼 "소프트웨어 아키텍트" ≒ "웹 기획자"의 개발 역할이 무엇일까요.

물론, 소프트웨어 아키텍트가 존재하고 논리적인 전략 차원에서 기획자가 존재하는 회사가 존재할 수도 있습니다.

하지만, 개발자가 기획요소에 참여하는 것을 월권으로 여기고, 코딩 이외의 일(도메인 분석, 아키텍처, 소프트웨어 디자인)을 하는 것은 놀고 있다는 시각을 인정한다고 가정하고, 그럼 웹기획자 ≒ 소프트웨어 아키텍트 의 역할이 무었인가 입니다.

제대로 된 프로덕트가 나오기 위한 개발 TASK를 폭포수(waterfall)방식으로 살펴 본 후 웹기획자의 역할을 말하겠습니다.


개발 TASK 폭포수
1.프로덕트가 달성해야 하는 비지니스 목표와 전략을 도출 합니다.
2. 고객의 요구사항을 분석합니다. Requirements Analysis
3. Use Case를 도출 합니다.
4. 1~3을 만족 시키기 위한 IA를 설계합니다.(인포메이션 아키텍처, UI, UX)
5. 1~4를 만족시키기 위한  플렛폼, 언어를 선택합니다. 또는 1~4의 과정 동안 잠재적인 플렛폼과 언어는 선택되어 있습니다.
6. 오브젝트 모델링, 데이터 모델링을 합니다.
7. Use Case를 구현 합니다.
8. 프로덕트를 릴리즈 합니다.
9. 1~8을 반복합니다.



웹 기획자 ≒ 소프트웨어 아키텍트 역할에게는 어떤 산출물을 기대하나
1~4 까지의 산출물을 내놓아야 합니다.
1. 프로덕트가 달성 해야 할 비지니스 목표와 전략, 컨셉 문서
2. 요구사항 명세서 ( Software Requirements Specification, SRS) : SRS 위키
     1) 고객 요구사항
     2) 기능 요구사항
     3) 비기능 요구사항
     4) 성능 요구사항
     5) 디자인 요구사항
     6) 파생 요구사항
     7) 배치 또는 구성 요구사항

3. Use Case 명세서
시스템에서 '누가' '무엇'을 할 수 있는지 , 행위, 룰, 결과물을 기술 하는 것 입니다.

1) Use Case 이름
2) 버전
3) 목적
4) 요약
5) 행위자 (사람, 시스템 또는 디바이스)
6)  이해 관계 계층 - 요구 사항  끼리의 연관 계층
7) 트리거
8) Basic course of Event - 최소한 하나의 주 시나리오
9)  대안 패쓰
10) Postcondition : Use Case가 달성 해야 할 출력
11) 비지니스 룰 : Use Case가 준수 해야 하는 비지니스 규칙, 도메인 내에서 Use Case끼리 상충 되지 않도록 해야 함.
12) Notes
13) 작성자 , 작성일

4. 화면 설계서
사용자가 1~3을 달성 할 수 있도록 통로를 제공하거나 네비게이션 패스, 정보의 구성을 담은 화면 설계서를 의미 합니다. 디자이너는 이 설계서를 기반으로 그래픽 디자인을 수행하고, 개발자는 Use Case 프리젠테이션 레이어를 구성합니다.

실무 개발자는 위의 1~4를 가지고 데이터 모델링을 하고, 프리젠테이션을 구성하고, 유즈케이스에 기술된 기능을 구현합니다. 이 과정이 진행 됨에 따라서 눈에 볼수 있는 프로덕트가 나온게 되는 것이죠.
이제 부터는 개발자가 웹사이트 개발하기 과정: 웹 개발자가 하는 일을 밟아 갑니다.



자! 현실로 돌아와 봅시다.



개발자가 전달 받는 산출물은 어떻습니까?  "1~3이 약간씩 첨가된 [산출물 맛] 4번의 스토리 보드" 입니다.

기획자는 "자 스토리 보드 건넸으니 일정을 주시죠"라고 말을 하죠. 개발자는 "이 기능은 어떻고, 저 기능은 결과가 어떻습니까?" 등등의 수천가지 확인 해야 하는 일이 남아 있습니다.

도저히 뭘 만들고자 기획 했는지 모를 문서를 받아 드는 경우가 많습니다. "좀 더 세부 정의를 해 주세요" 라는 개발자에 요구에, 기획자는 "여기에 그림 다 그려 놨는데 뭘 더 달라는 겁니까?", "뭘 더 줘야 하는지 설명해 보세요!", 개발자는 설명을 위한 설명을 시작합니다.



자! 제가 모든 기획자와 개발자들을 위해 "뭐가" 필요한지 말해 드립니다.

"바로 1~4를 말하는 겁니다. 1~4", 그리고 "부드러운 조율"

위의 과정을 열심히 해도 "소프트웨어 위기 Software Crisis"라는 것이 옵니다. 부정확한 요구사항 분석, 빈번한 요구사항 변경, 구현 실패 등. 위에 언급한 것들이 프로젝트 성공의 "필요조건" 이라는 것이죠. 절대 "충분조건" 이 아닙니다.


싫다 좋다 말씀 마시고, "바로 1~4를 말하는 겁니다. 1~4", 그리고 "부드러운 조율" 입니다.




추신:

"네가 언급한 것 들은 개발자들인 해야 할 일 아니야?" 라고 말씀 하시는 분들도 있으실 겁니다. 개발팀은 코딩 이외에도 위에 언급한 1~4의 작업을 개발을 위해서 , 유지보수를 위해서, 작성합니다. '개발 관점'이라는 것으로 작성됩니다. 귀사에 '소프트웨어 아키텍트'라는 TO가 있습니까?, '소프트웨어 디자이너'라는 TO가 있습니까? 개발팀이 모든 것을 다 해야 한다면, 그럼 님께서 생각하시는 기획자는 뭘 하는 사람인거죠? 


"어느 사이트에 있는 그 기능을 넣어 주세요!"는 고객의 사전에 있는 용어이지, 기획자에게 허락된 용어가 아닙니다.

현재글 : 웹기획자는 무엇을 하는 사람일까요? - 개발에서의 웹기획자 역할 posted By - 반더빌트 2010/01/25 11:01

C-Thinker 님의 많은 포스트를 읽고 매우 상쾌해지는 느낌과 동시에 많은 도움이 되었습니다.

하지만  Entity Framework 4.0 - 아직도 헤메는 MS 라는 포스트는 많은 부분에 동의를 하지 못하였고, 이렇게 EF에 대한 변론(?) 을 하는 포스트를 작성하게 되었습니다.

일단, 포스트 내용을 반박하게 되는 글이 될 것과 C-Thinker님의 글에서 EF에 대한 문제의식을 제대로 집어 내지 못한 것이 포스트를 작성하는 것에 대해 조심 스럽게 만듭니다. 하지만 논쟁을 통해서 서로가 발전할 수 있다는 변증법 사고에 기반을 두고 EF에 대한 저의 의견을 적어 봅니다.


Table Module Pattern 의 개발 모델 문제에 대해 말 해 보도록 하죠.

이상한 모습도 그렇지만 아직도 테이블 기반 (Table Module Pattern) 의 애플리케이션 개발 모델을 버리지 못하고 있는 느낌이다.

우선 EF가 테이블 기반인가? 테이블로 부터 EDM을 생성하므로 테이블 기반이라고 말 할 수 있겠네요. 하지만 마틴 파울러가 말한 Table Module Pattern이냐? 라는 것에는 이견이 있군요. 파울러의 Table Module Pattern은 Data Access Layer를 작성할 때 1:1 테이블로 사상된 일명 DataSet을 통해 작업을 하느냐. 다시 말하면 직접적인 RecordSet을 통하여 작업 하느냐 라고 봅니다.  개발자가 이용하는 관점에서는 EF는 Domain Model 이며, Data Mapper를 구현 할때 Table의 메타 데이터를 이용한다. 라고 볼수  있네요.

매퍼 자체가 매핑을 하기 위해서 Gateway를 이용해야 하는데 Gateway는 Table Data Gateway, Row Data Gateway, Active Record를 사용할 수 있으나,  이것은 매퍼를 구현하는 방법에서의 적절한 것을 선택하는 것의 문제이지 Table을 기반으로 생성된 EDM이 문제일 수는 없다고 봅니다.





ORM과  Persistence Ignorance를 아래의 글로 언급하셨는데

ORM 의 근본 목적이라면 OO (Object Orientation) 프로그램 상에서 생성되고 관리되는 객체들과 관계형 (Relation) 으로 구성된 데이타베이스와의 구조적 차이 (Impedance Mismatch) 를 극복하기 위한 반복되는 코드를 줄이고 어떻게 저장되는 지에 대해서는 상관하지 않겠다 (Persistence Ignorance) 는 관점에 있다고 볼 수 있다.

저는 "ORM 이라는 것은 Object Oriented 객체와 RDBMS와의 임피던스 미스매치(Impedance Mismatch)를 조절하며 데이터 영속화(Data Persistence)를 자동화(Automate) 함으로써 비지니스 로직을 작성하는 개발자에게 Domain Model로 작업하도록 지원해 주는 것이 목표 라는 것"이라고 정리하고 있는데,  artofsoftwaredev님의 의견과 거의 같으면서도 다름이 느껴집니다.


Persistence Ignorance는 Jimmy Nilsson 의 책 Applying Domain-Driven
Design and Patterns: With Examples in C# and .NET (Addison-Wesley Professional, 2006)에서 제시한 용어로써 "keep your domain model decoupled from your persistence layer " 로써 정확한 정의가 모호합니다.

Eric Evans의 DDD 방법론과 마틴 파울러의 생각을 정의해 보자면  "도메인 모델이 저장 장소에 무지하도록 한다." 라고 할 수 있습니다. 저장장소가 인-메모리 가 되었건 , 파일 시스템이 되었건, SQL Server가 되었건 몰라도 영속화를 할 수 있어야 함을 의미 하는 것으로 , "어떻게" 보다는 "어디"에 또는 "무엇"에 영속화 되는가에 관심이 있겠다 말할 수 있습니다.

영속화 매체가 파일 시스템, 또는 오라클이냐, MySql이냐, MS SQL 이냐를 도메인 모델이 인지를 하지 않고 특정 영속화 인터페이스를 사용한다면 영속화 할 수 있다는 개념으로 Repository 패턴을 생각해 볼 수 있습니다.





객체와 테이블이 1:1의 관계이냐?

데이타베이스로 부터 모델을 생성하고 코드만 자동으로 생성을 하지 않은 후, 그 모델에 맞는 객체를 만들어야 한다. 예를 들어 주문 테이블이 있다고 하면 이 테이블로 부터 주문이라는 모델을 만들고 이 주문이라는 모델이 갖고 있는 필드들을 갖고 있는 객체를 만들어야 한다는 얘기다. 여기서 다시 객체와 테이블의 1 : 1 관계를 벗어나지 못한다. 그래도 여기까지는 큰 문제가 없다고 봐 줄 수도 있다. 정작 문제는 이 객체들을 데이타베이스에 넣고 빼는 과정을 자동화 해 주는 ObjectContext 이다.

우선 EF는 상속받아 구현되는 컴플렉스 타입을 지원하며 1:1 관계라는 것 자체가 사실과 다릅니다.
OO의 객체를 영속화 하기 위해서 테이블을 모델링 할 때 상속받아 구현된 모든 객체를 테이블과 1:1로 구현 할 수도 있고, 타입으로 구분하여 상속받아 구현된 모든 객체를 한개의 테이블에 저장할 수도 있습니다. 이 두가지 모두 전략에 따라 적절한 패턴의 선택 문제입니다.




그럼 문제가 된다고 말씀하시는 ObjectContext의 POCO 지원시에 의존성 문제를 볼까요

객체들을 자동으로 생성하지 않았으므로 POCO 를 사용할 경우 ObjectContext 는 어떤 객체들이 어떤 모델들과 어떤 관계를 갖고 있는지 알 수가 없게 된다. 따라서 ObjectContext 를 상속받는 객체를 만들어 사용을 해야 하는데 문제는 각 POCO 객체를 Entity Framework 에서 Entity 로 인식을 하고 처리를 하기 위해 이 POCO 객체타입으로 EntitySet 을 만들어야 한다는 것이다. 다시 말해서 도메인 객체를 데이타 엑세스 레이어에서 알고 있어야 한다는 얘기다. 어라... 이건 뭐가 거꾸로 되도 한참 거꾸로 됐다. 프로젝트를 UI, 도메인, 데이타 레이어로 나누었을 경우 UI -> 도메인 -> 데이타 순서가 아니라 UI -> 데이타 -> 도메인 순서의 의존성 (Dependency) 가 생긴다.

객체를 영속화 하기 위해서는 상태 관리, CRUD의 인터페이스를 제공하는 그 어떤것이 필요하게 되는데 ObjectContext가 그 역할을 하는 것입니다. POCO의 영속성을 지원하기 위해서는 지원하는 '그 무엇'이 있어야 합니다. 그것이 Transaction Script가 되었건, Table Module이 되었건 말이죠. EF 4에서는 POCO를 지원하기 위해 POCO를 EDM에 추가하는 것으로 해결하는 것이죠.

도메인에서 만들어진 객체를 데이터 레이어에서 알아야 하는 것이 문제라고 말씀하셨는데, 언어의 Primative 타입만을 데이타 레이어에 전송하지 않고 Object로 전달하기로 결정하는 순가. DTO라고 하는 객체가 필요하게 됩니다. DTO는 도메인 모델과 데이터 모델에서 알지 않고서는 작업이 되지 않기 때문에 EDM의 엔터티 자체가 DTO 역할을 하면서 엔터티의 상태 관리와 CRUD 및 데이터 매핑 작업을 ObjectContext가 해 주는 구조 입니다.

다시 말해서 DTO가 필요해 지는 순간 도메인 레이어와 데이터 레이어가 동시에 알아야 할 필요성이 생기고, 이것을 의존성이라고 말한다면 Primative Type 만으로 작업하는 것 이 외에는 방법이 없다고 생각합니다.

의존성의 순서는 둘째 치고, 의존성이 있다는 얘기는 변경발생시 두군데의 변경이 불가피 하나는 얘기이고 굳이 두개로 나눌 이유가 없다는 말일 수도 있다. 이는 다시말해 도메인 로직과 데이타 엑세스가 분리 될 수 없다는 것을 말하고 결국 데이타베이스에 대한 의존성은 줄지 않았다는 얘기가 된다.

의존성 문제는 개발자의 코드 자체가 레이어 간의 의존성을 가지냐의 관점으로 봐야 옳으며, 중간자 (Mediator)가 의존성을 알고 있느냐의 관점으로 보는 것이 아니라고 생각합니다. 데이터베이스의 변경 마다, 데이터 레이어와 도메인 레이어의 수직 변경을 메터데이터(EDM)에 위임하고 , EDM의 업데이트로 변경을 반영함으로써 , 수직 변경을 최소화하는 것은 옳은 관점이라고 생각합니다.


artofsoftwaredev 님의 말씀대로 모든 레이어가 Ignore 하고 서로의 변경에 전혀 관심 갖지 않아도 된다면 얼마나 좋겠습니까 만은 , 그 개념은 아직 이상적이며 완벽한 솔루션이 없습니다.


현재로써는 "관심의 분리 , Seperate of Concern"로 "한 곳에서만 관리하도록 하자 Single Point Management "의 관점으로 디자인 하는 것이 옳다고 볼수 있습니다.


EF가 완벽하냐? 라고 묻는다면 대답할 수 없습니다만, 디자인 관점이 옳으냐 라고 묻는다면 "예" 라고 하겠습니다.

현재글 : Entity Framework 에 대한 변론 posted By - 반더빌트 2010/01/20 13:41

인포메이션 아키텍처(Information Architecture)란 무엇일까요?
컨텍스트에서 컨셉을 만족하는 정보의 구성과 최적의 탐색 루트 정의라고 말할 수 있습니다.
분류를 하자면 기획서에 들어 있어야 할 내용입니다.


Information Architecture(IA) 소개
데이터를 사람들이 사용할 수 있는 의미있는 정보로 변환할 필요성이 있음을 묘사하기 위해,  1975년 Richard Wurman에 의해서 만들어진 용어입니다. 완전히 새로운 생각은 아니지만 현재의 용어를 일반적인 IA Label 에 결합한 최초의 시도였습니다.

아키텍처에 컨셉, 정보 디자인(inforamtion design), 타이포그래피, 그래픽디자인을 세우는 Wurman의 세로운 비전은 1990년대 월드와이트웹이 태동하기까지 관심을 받지 못했습니다.


IA의 정의
공식적인 정의 없이, Mosenfield 와 Morville 이 여러개의 정의를 제안 했습니다.

1. 정보시스템에서의  organization, labeling, navigation scheme의 조합.
2. 정보 스페이스를 작업 완료를 용이하게 하고, 직관에의해 컨텐츠에 접근할 수 있게 구조적으로 디자인 하는 것.
3. 사람들이 웹사이트와 인트라넷의 정보를 찾을 수 있고, 관리할 수 있게 분류하고 설계하는 예술과 과학.
4. 디지털 세상을 설계와 디자인을 가능케 하는 새로운 공동체의 실제적인 초점과 규칙.

현재글 : 인포메이션 아키텍처 - Information Architecture posted By - 반더빌트 2010/01/12 15:01

이번 포스트의 주제는 우리 할머니에게 웹사이트 개발 방법 가르쳐 주기 입니다. - how to teach my grandmother to  development website 입죠

현재 대한민국의 학부생 또는 청소년들이 개발자 또는 웹개발자가 되기를 희망하는 사람이 얼마나 될지 모릅니다. 후배들에게 개발자를 직업으로 추천 할 수 있을지 또한 의문입니다.

개발자의 세계가 현실 세계와 너무 동떨어져 있는 것과 개발자 이외의 집단이 개발자를 이해하는 것, 그리고 개발자 집단 내부에서도 개발자를 이해하는 것은 쉽지 않습니다.

개발자는 디테일 하나 하나에 집착 합니다. 작은 것 하나쯤이야 하고 소홀히 대했을 때 석달 열흘을, 원인 모를 오류로 디버깅을 하면서 밤을 세울 수도 있기 때문입니다. 그런 개발자들에게 그냥 두리뭉실 좋은 게 좋은 것 아니냐며 대충 이래 저래 돌아가게 만들어라 하는 것은 타협 할 여지가 없음을 이외의 사람들은 이해하지 못합니다.

개발자들도 개발이외의 집단에서의 요구사항인 "뭔가 좀 맘에 안들어요, 그 뭔가를 좀 고쳐줘 봐요" 의 그 뭔지 모를 "뭔가"를 이해 하는 회로가 뇌에서 빠져 버린 듯 합니다.
 
아무리 연관 관계를 줄이려고 해도 코드들 객체(오브젝트)들은 연관을 가지고 있습니다. 현실 세계와 마찬가지로 프로그램의 세계에서도 독야청청 홀로 떨어져 있는 객체는 존재 할 수 없음을 개발자들은 알고 있으니까요. 개발자 이외의 집단에서 하는 말인 "그거 하나 수정하는데 뭐가 그렇게 어려워!?"라는 말에 속시원히 답하기 어려운 개발자들 마음은 더욱 답답합니다.



그럼 개발자들이 왜 그렇게 생각이 많고, 혼자서 집중할 수 있는 공간을 요구하는지 우리 할머니에게 설명하는 것처럼 말해 보겠습니다.

개발자들이 하나의 웹사이트를 개발하기 위해서, 또는 개발자가 되기 위해서는 무엇을 공부해야 하나?  ASP.NET 개발자의 경우로 말해 보도록 하죠.



웹사이트의 컨셉, 목표, 해결해야 할 현실 문제, 요구사항, 기획, 디자인이 나왔다고 가정하도록 하죠.

첫번째, 윗 줄에 열거한 모든 것을 이해 해야 합니다. 그리고, 머리 속으로 시스템을 그립니다. 머리 속으로 그리려면 열거한 모든 것들에 대해서 공부 해야 합니다. 업무 영역, 업무 프로세스, 업무가 해결해야 할 과제 등등. 현실 세계의 거의 모든 상식을 지니고 있어야 합니다.

개발자의 좀더 구체적인 세계로 들어가 보도록 하죠.

두번째, 윈도우즈 서버 환경에 대해서 공부하고 이해 해야 합니다. 여러개의 서버가 함께 일할 수 있는 서버팜 , High availability 환경에 대해 이해하고 통제 할 수 있어야 합니다.

세번째, 웹사이트를 구동 시켜 줄 수 있는 IIS(Internet Information Services)를 공부하고 이해하고 통제 할 수 있어야 합니다. 버전 별로 특성과 지원되는 기능을 알아야 합니다.

네번째, web application framework인  ASP.NET을 공부하고 이해해야 합니다.

다섯번째, ASP.NET 위에서 구동할  주로 사용할 언어에 통달 해야 합니다. C#.NET 또는 VB.NET을 공부 해야 합니다.

여섯번째, 언어가 구동되는 프레임워크인 .Net Framework를 공부해야 합니다. 주요 모듈이 Common Language Runtime 이라는 CLR에 대한 공부가 필요 합니다.




일곱번째, 언어를 가지고 문제를 해결하기 위해서 알고리즘과 자료구조, 객체를  구조화 하기 위한 디자인 패턴 , 아키텍쳐를 공부하고 머리에 담고 있어야 합니다.  

여덟번째, 드디어 사용자들이 볼수 있는 화면을 구성하는 언어인 HTML: Hypertext Markup Language 을 공부해야 할 시간입니다. <html></html><body></body><a href="src" ></a> <img src="" alt="" /> 이런 것들이 HTML입니다.

아홉번째, 내용을 디자인과 분리하기 위해서 CSS(Cascading Style Sheet) 를 공부 해야 합니다.

열번째, 사용자에게 더욱 좋은 경험 또는 서비스 요구 사항을 들어 주기 위한 언어인 Javascript 라고 불리우는 ECMA Script를 공부해야 합니다. javascript를 좀더 사용가능한 언어처럼 사용하기 위해서 javascript framework인  jQuery 또는 Prototype을 익혀야 합니다.

열한번째, 위에서 만든 서비스의 데이터를 영구적으로 저장 하기 위한 Server인 RDBMS, SQL 서버를 공부 해야 합니다.T-SQL이라고 불리우는 언어를 공부해야 합니다.

열두번째, 웹서비스에서 DB 서버와 통신하는 여러가지 기술을 익혀야 합니다. ADO.NET, 최근의 LINQ TO SQL, ENTITY FRAMEWORK, NHibernate, iBatis.NET등의 ORM( Object-Relation-Mapping)이라는 것을 익혀야 합니다.

열세번째, 소프트웨어를 구동할 수 있는  물리적인 컴퓨터의  네트워크, RAID, SCSI, HBA, SAN등의하드웨어와  기술들에 대해서 알고 있어야 합니다.

열네번째, 첫번째에 이해한 것들을 구현하기 위해서 열세개의 영역을 엮어(Weaving) 나갑니다. 위에 언급한 언어들(흡사 영어,프랑스어,스페인어와 같은 언어로 보시면 됩니다.)을 적절히 섞어가며 감동과 재미를 동시에 충족하는 문학작품 같은 것을 써 내려 갑니다. 아니 부분 부분을 써서 적재 적소에 엮습니다.
 
드디어 뭔가 돌아가는 화면을 볼 수 있습니다.

웹사이트 개발을 진행 하는 동안 요구사항의 변경과 버전의 변경, 개발 트렌드의 변화을 추적하면서 위에 언급한 열 세가지를 반복합니다.

개발자 이외의 잡단이 볼때 키보드나 또닥 거리며, 사무실 주변을 어슬렁 거리는 행위를 하는 동안 머리 속으로 , 또는 문서에 , 또는, 노트에 위의 열 세가지를 엮고 있는 것입니다. 비지니스의 선행조건 , 후행조건 등의 제약사항을 준수 하면서 말이죠.


개발자들은 위의 열세가지의 요소를 엮고 있으니, "제발 좀 나를 내버려 둬"라고 무언으로 말하지만, 회사 인간 관계에 서툰 미친놈 소리를 듣지 않기 위해서 뇌의 일부 영역을 주변 인간 관계를 위해서 남겨둡니다. 가끔 다른 팀의 컴퓨터도 고쳐줘야 하고, 윈도우도 깔아주거나 오피스도 깔아줘야 합니다. 개발자들이 자신의 세계로 다시 돌아가서 자신의 일을 하기 위해  갖추어야 할, 책에서 가르쳐 주지 않는 소양입니다.


인고의 시간이 지나고 프로덕트가 나옵니다. 많은 아니 대부분의 프로젝트가 아래의 결과를 보입니다.



위의 프로젝트 결과에 고객과 여타의 팀에서 볼맨 소리가 빗발칩니다. 비에 홀딱 젖어 익사하지 않기 위해서는 구멍난 우산이나 스노클이라도 준비 해야 합니다.

새로운 요구사항을 들어주고 변경된 제품을 내놓기 위해서 개발자들은 위의 열세가지를 수정하고, 삭제하고, 재배치하고, 새로 작성하고 동시에 유지관리를 걱정하며 엮어갑니다.

열세가지의 실로 엮은 스웨터가 구멍이 숭숭 난 누더기가 아닌 명품 캐시미어 스웨터로 만들려고 머리 속이 꽉차 있는 하루 하루를 보내는 것입니다.

실력이 있는 개발자 이건  부족한 개발자이건 모두가 같은 입장입니다. 한 가지도 소홀 할 수 없습니다.

개발자를 꿈꾸고 있거나 개발자이외의 우리 할머니, 개발자가 하는 일이, 되기 위해 하는 일이 무엇인지, 개발자들의 뇌속이 조금 머리 속으로 그려 지십니까? 다른 세계에 사는 사람인 듯 타협하기 힘든 개발자들의 속성을 조금 이해 하시나요?

이런 끊임없이 공부 해야 하고 머리속이 꽉찬 하루 하루를 보내는 개발자라는 직업이 쉽지만은 않습니다. 개발팀을 영원한 '을'로 여기는 대한민국의 인식은 후배들에게 개발자를 추천 하는 것을 망설이게 합니다.

그러나 개발자들은 무형의 그 상상을 현실화 하는 것에 무한한 행복을 느낍니다. 무한한 기쁨을 느낍니다. 한단계 한단계 성장하는 자신을 느끼면서 세상 그 무엇도 부럽지 않습니다. 현실로 돌아오면 깨지기 쉬운 유리 그릇 같은 만족감 이지만 행복합니다. 개발을 사랑합니다.

이 행복이 노력의 댓가로 지불되는 것이 아니기에 망설여집니다. 이것도 딜레마에 빠지게 합니다. 모두가 개발자를 하지 않으면 유능하며, 발전하며 행복을 느끼는 후임 개발자를 볼 수 없기 때문입니다.

"그거 하나 고치는데 뭐가 그렇게 어려워?" 라는 질문에 대한 답이 조금 되셨습니까? 물론 고치기 쉬운 것이 얼마간 있는 것도 인정합니다.
 
개발자 이외의 분들 이제 개발/개발자가 되기 위해 뭘 해야 하는지 아셨으니 한번 직접 개발해 보시겠습니까?
현재글 : 우리 할머니에게 웹사이트 개발 방법 가르쳐 주기 - 웹 개발자가 하는 일 posted By - 반더빌트 2010/01/06 00:14

화상전화와 같이 성공을 믿어 의심하지 않았던 기술이 성공하지 못한 이유는 무엇일까? 마티아스 호르크스의 테크놀로지의 종말(TECHNOLUTION)은 기술 혁명, 혁신의 조건을 기술한 책이다. 번역된 제목 "테크놀로지의 종말"은 독자를 혼란스럽게 한다. 책의 내용은 테크놀로지의 종말이 아닌 혁명과 혁신의 조건과 과정이기 때문이다.



서비스의 기획 개발에서 우리가 혁신적인 서비스를 만들었는데 폭발적으로 성공하지 못하는 이유가 뭘까? 라고 고민하는 회사가 많을 것이다. 역사상에서도 혁신적인 기술 이었음에도 불구하고 성공하지 못한 이유가 뭘까? 테크놀로지의 종말은 그 구조와 과정을 밝힌다.

테크놀로지의 종말 = 과학혁명의 구조 + 미디어의 이해 + 에세이 로 이해 할 수 있다.

화상전화 성공의 방해 요인 - 음성 전화기가 당연히 화상 전화기로 발전하리라는 예상은 커뮤니케이션의 본질을 잘못 이해한 근본적인 오류에서 비롯된다. ~ 중략 ~  개인주의로 대표되는 선진 문화에서 통신은 결코 가까움을 위해 봉사하지 않는다. 오히려 거리 유지에 봉사한다. 그리고 바로 이것이 화상전화를 가로막는 근본적인 훼방꾼이다. p.50

매체의 멸종하지 않는다 - 어떤 경우든 한 매체가 다른 매체를 완전히 흡수하는 사례는 매우 드물다. 물론 오늘날 파피루스나 양피지를 찾아보기는 힘들다. 그러나 이것은 책의 멸종이 아니라 단지 책의 소재가 바뀐 것이다. p56.

주) TV가 등장 했을 때 많은 사람들이 영화산업은 죽었다고 말했지만, 오히려 영화 산업은 매우 큰 시장을 가지고 성공하고 있다.
  
커뮤니케이션의 세계와 테크놀로지 - 복잡성은 어쩔수 없이 개별기능의 성능을 떨어뜨린다. 전문화는 성능을 높인다. pp68-69

진보를 위한 조건 - 고대 그리스때 이미 도르래 장치가 발명 되었음에도 불구하고 그리스 로마는 장비를 거의 이용하지 않았다. 무거운 짐을 옮기거나 방앗간을 돌리는 데에도 소를 쓰는 경우가 드물었다. 대부분 사람을 썻다.
이집트, 그리스, 로마는 모두 혁신의 속도를 늦춘 똑같은 장애물을 가지고 있었다. 바로 노예제 였다. p117.

진보는 직선이 아니다 - p152. 

이메일과 사회기술  - 이메일은 보내는 이와 받는 이가 동시성을 갖지 않아도 된다. 그러면서도 동시에 도착하는 매체다. 이메일을 고도의 상호작용을 요하지만 응답에 관해선는 융통성도 있다. p166.

테크놀로지 성공의 조건 - 에버렛 로저스 [혁신의 확산] - 시험가능성, 비교우위, 호환성, 복잡성, 과시효과. p221.
기술진화와 생물 진화의 차이 - 생물을 정보를 직계로 전달하고, 물질과 문화는 정보를 수평으로 전달한다. p235.

경제적 적응의 4단계
1단계 - 분기점 가격
2단계 - 분기점의 양
3단계 - 다른 테크놀로지의 대체
4단계 - 공짜나 마찬가지. 몇몇 테크놀로지는 심지어 마지막에 덤이나 헐값에 팔리는 덤으로 변한다.
pp186-187.

진화, 폭발과 멸종 사이
약 5억년 전인 캄브리아기에 지구에는 유례없이 생물이 엄청나게 분화한 '종의 다양성 폭발'이 있었다. ~ 전 지구 역사에서 하필이면 이 짧은 시기 동안 그토록 막대한 변이가 만개한 까닭은 무엇일까? 그 많던 변종들은 어째서 그렇게 빨리 다시 멸종 했을까?  - 닐스 엘드리지와 스티블 제이 굴드의 '깨진 균형 이론'으로 설명. p194.



관련 링크 :
구텐베르크 은하계(부제-활자인간의 형성) - 웹2.0 과 웹3.0의 미래
미디어의 이해 - Understanding of Media (1/2)
미디어의 이해(Understanding of Media) - 마샬 맥루한 (2/2)
개발자 기획자가 꼭 읽어야 할 책 - 미디어의 이해
[미디어] 신문경영론(김동률) - 뉴스는 신문의 영혼이며 광고는 신문의 심장이다
최재천교수의 다윈 2.0 자연선택의 원리

현재글 : 테크놀로지의 종말 - 테크놀로지의 자연 선택을 밝히다. posted By - 반더빌트 2010/01/02 14:39

MS의 LINQ to SQL , LINQ to Entities , ENTITY FRAMEWORK는 .NET 개발자 진영에서 많은 논쟁을 벌여 왔습니다.

ORM의 역사가 짧은 .NET 진영에서 얼리아답터 들은 NHibernate 와 iBatis.NET을 받아 들였고, LINQ to SQL을 받아들인 개발 그룹, Enterprise Library를 이용하고 있는 그룹, MS Database Application Building Block을 이용하는 그룹, Raw기술인 DataSet을 이용하는 그룹 등이 혼재되어 있습니다. 국내에서는 아직  EF 는 보고 되지 않고 있군요.
심지어는 아직까지 ASP와 VBScript를 사용하고 있는 서비스도 많습니다. - Active Server Page가 나쁘다는 의미가 아닙니다.  개발 언어와 플렛폼이 개발자와 서비스를 제한하기 때문에 '심지어'라고 표현 한 것이니 오해 하진 말아 주세요.

이런 상황이니 L2S의 등장과 지원 중단이라는 말이 상당히 이해하기 힘들 수가 있음을 느끼고 있습니다.

또한, LINQ to SQL이 중단 되나? 라는 어휘가 명확하지 않아 오해의 소지가 있음을 권효중님의 댓글을 보고 새로운 포스트를 작성하게 되었습니다.

Julie Lerman 의 Programing Entity Framework 책을 기반으로  LINQ to SQL (이하 L2S)의 뒷면(Behind the Scene)를 적어 봅니다.

Julie Lerman은 Entity Framework 팀 구성과 개발에 참여한 개발자이며, Programing Entity Framework의 저자입니다. 블로그 및 사이트를 운영하고 있습니다.

2008년 10월 중순의 PDC2008에서 LINQ to SQL에 대한 더 이상의 지원이 중단 된다는 발표에 이미 CTP 때부터 L2S를 학습 및 적용했던 개발자들은 일제히 MS에 분개하며  'LINQ to SQL is Dead' 또는 'Is LINQ to SQL Dead'라는 블로그 포스트 들이 올라 오기 시작합니다.

이에 ADO.NET 블로그 팀은 해명에 나섭니다. L2S에서 Entity Framework로의 마이그레이션 가이드 라인과 함께, L2S가 Line up에서 제외 되지는 않는다. 다만 지속적인 evolution이 EF만큼 되지는 않을 것이다. 라는 공식 입장을 표명합니니다.

새로운 기술 또는 프레임워크를 도입한다는 것은 익숙해 지기까지 학습 비용과 적용 비용을 수반합니다. 또한 시간 투자도 요구 합니다. 앞으로의 유지 보수 및 추가 개발 문제도 고려 됩니다.

ADO.NET 팀 블로그의 공식 발표에도 불구하고 공식 발표가 명확하지 않아 L2S의 생사에 관한 논쟁은 1년이 넘도록 진행 중 입니다.

공식발표의 늬앙스에서도 읽을 수 있듯이 L2S의 더 이상의 향상이 어렵다는 것을 읽을 수 있습니다. 서비스나 프로그램이 지속성을 가지는 것이기 때문에 L2S 보다는 EF를 선택하는 것이 유리하다는 것이 저의 견해입니다.

Julie Lerman은 그의 책(1.7장)에서 왜 비슷한 기술이 만들어 졌을까?의 질문에 답을 밝힙니다. 

L2S는 LINQ Language를 개발하는 도중에  LINQ 프로젝트로 부터 나왔습니다.
EF는 Data Programmability team으로 부터 나왔고,  Entity SQL language 에 집중하엿습니다. 그로 부터 두개의 기술은 서로 별개로 개발되어져 왔습니다.  두 팀에게 기술이 보여 졌을 때에 MS는 두개의 기술이 서로 다른 목표를 만족 시킬수 있다고 판단 했습니다.
EF팀은 LINQ를 받아 들여 LINQ to Entities를 만듭니다(L2E가 L2S보다 10개월여 늦게 포함 된 것은 이 이유로 추측됩니다.). 하지만 L2S와 L2E가 너무 비슷하게 되어서 서로 다른 목표를 만족 시키는 시나리오가 틀려 버리게 됩니다.
결국에는 L2S가 EF팀에 통합되었습니다. L2S는 Language보다는 데이터 팀에 더 가까웠기 때문이라고 판단됩니다.

이윽고 PDC2008 에서 L2S의 개발 지원 중단이 발표 되게 되죠, SQL에만 한정되어 있으면서 또한 같은 역할을 하는 2개의 기술을 병행 개발하는 것은 비효율이라고 판단 한 것 같습니다.

Lerman은 그의 책 23.1장의 The Future of LINQ to SQL에서 L2S와 EF가 ADO.NET팀의 통제하에 있고, MS는 EF를 주요 전략으로 선택했음을 명확하게 결정 했다고 합니다. L2S 도 지속해서 유지보수( Maintain ) 와 미세조정( Tweak ) 될 것이지만 EF 만큼 투자 되지는 않을 것임을 결정 했다고 합니다. 또한 EF 로의 마이그레이션을 추천(Recommend) 합니다.

결론은 개발자와 회사의 입장으로서 앞으로의 서비스 및 제품의 유지보수와 진화를 위해 EF를 선택하는 것이 더 나은 판단으로 사료 됩니다.

관련 포스트  합니다. 1년 전에 작성 했었던 PDC 관련 내용이군요.
Linq to Entities 와 ADO.NET ENTITY FRAMEWORK 가 승리자가 되다.

 
 

현재글 : LINQ to SQL Behind the Scene posted By - 반더빌트 2009/12/30 21:53

구글로 대변되는 검색 혁명, 유튜브의 리치 미디어(동영상) 이후 웹 생태계는 근 2년간 정체되어 있었으나, 올해는 마이크로 블로그라는 이름의 트위터(twitter)가 성공 신화의 역사를 장식했다. 깨질 것 같지 않던 정적을 깰수 있었던 힘은 무엇이었을까?


1. 빠른 생산 및 소비 속도 (Frequency)
빈도(Frequency)는 서비스 성공에 중요한 요소이다. 아무리 좋은 정보가 있어도 사용 빈도가 높지 않으면 성공하지 못한다.

커뮤니케이의션의 형태는 중앙집중적 성격의 위키, 개인 미디어의 블로그, 블로그의 소형화 또는 메신저의 영속화의 마이크로 블로그를 들 수 있다.

정보 생산 및 소비 속도를 미디어 별로 나타내자면

위키 -  10 km/h
블로그 - 20 km/h
마이크로 블로그 - 100 km/h

라고 말 할 수 있다.

위키는 3가지 미디어중에서 가장 영속적 이지만 생산 속도가 느려서 지속적으로 방문할 또는 관찰할 필요성이 적다.

블로그는 위키보다는 빠르지만 정보 수요 속도를 충족 시키지 못한다. 구독하고 있는 블로그가 하루에 1개 이상의 포스트가 업데이트 되는 경우는 별로 없을 것이다. 구독하고 있는 블로그를 하루에 1번 이상 방문할 필요성이 없게 된다.

마이크로 블로그는 가장 빈도수가 높은 인스턴트 메신저를 영속화 하고, 통신 대상을 개방한 형태이다. 생산 속도가 빠르고 빈도도 높으며, 지속적인 방문 및 관찰을 요구한다. 트위터는 높은 빈도를 만족 시키는 서비스 이다.


2. 정보습득의 새로운 방법 제시
소셜 미디어 이전의 정보 습득 방법은 검색(Search) 또는 찾기(Finding)이었다. 소셜미디어는 마치 거실에 TV를 켜놓은 것과 같다. 주의(Attention)만 유지하면 다른 일을 하면서도 관심 있는 주제에 대해서 집중해서 낚으면 된다.

트위터는 소셜미디어의 성격을 가지고 있다. 메신저가 Private 소셜 이라면, 트위터는 Public 소셜이다. 소셜 미디어는 정보 자체 보다는 사람과 사람의 행위(Behavior)에 주목한다. 정보 과잉 시점이 오면서 소비자들은 사람에 의한 정보 필터링이라는 검색엔진 이외의 필터링 도구를 사용하게 되었다.

Attention과 Person Behavior에 의한 정보 필터링 방법을 광범위하게 전파한 것이 트위터이다.

트위터의 주 이용자 층이 30~40대의 남성인 것은 정보 자체 보다는 관계의 행동이 중요한 계층이기 때문이다.


3. 모바일 환경의 전개
근 몇년 모바일 통신 대역폭이 급속히 증가하였다.  모바일은 언제(Every Time), 어디(Every Where)든 소비자와 함께 있는 정보 단말기 이다. 모바일 기반의 정보 통신에 가장 적합한 미디어가 단문 메세지 중심인 트위터의 서비스에 적합했던 것이다.


트위터의 성공은 지속 가능한가?
답은 글쎄다.

140 byte의 미디어는 다른 영역의 가치를 생산해 낼 수 있는 만큼의 정보를 담을 수 없는 한계를 가지고 있다. 즉, 자신의 영역에서 가치를 생산해 낼 만한 정보를 트위터의 미디어가 담아 줄 수 없는 것이다.
트위터, 아저씨들의 놀이터? - 트위터 사용자의 성별 및 연령

정보의 내용 자체가 휘발성과 불연속성을 가지고 있다.
웹에 기록 된다고 모든 정보가 영속성을 갖는 것은 아니다. 내용 자체의 생명기간이 짧은 한계를 가지고 있다.

대화라는 속성은 불연속적이며 종종 관계없는 내용들로 가득찬다. 또한 재구성 비용이 매우 높다.

트위터는 아이 러브 스쿨의 경우를 경계해야 한다. 관계 형성의 필요성이 충족 되고 나면 서비스의 가치도 하락하기 때문이다.



관련 포스트

트위터(twitter) : 주목받는 온라인 커뮤니케이션 통로
트위터를 이용하는 목적, 남-녀가 달랐다
트위터의 성공비결

현재글 : 트위터(Twitter)의 3가지 성공 요인 posted By - 반더빌트 2009/12/30 11:32

.NET 개발자를 위한 오픈소스 검색엔진 라이브러리로 Lucene.Net 이 있습니다.

자바로 진행중인 Lucene 프로젝트를 .NET Framework 으로 포팅하는 프로젝트 입니다.

아파치의 인큐베이터에 포함된 프로젝트이며, 2.4 버전이 릴리즈 되어 있으며, 알파 버전으로는 2.9.1 버전이 진행 중입니다.

Lucene의 자바는 3.0 버전이 2009.11.25일 릴리즈 되어 있습니다.

자바 루씬 프로젝트 : Lucene Docs
Lucene.Net 프로젝트 :  Lucene.Net
Linq to Lucene 프로젝트 : Linq to Lucene

Linq to Lucene은 Lucene.Net 라이브러리를 Linq로 이용할 수 있도록 진행되는 프로젝트 입니다.

Lucene.Net을 Linq의 범용 확장성의 날개를 가질 수 있는 프로젝트가 Linq to Lucene 입니다.

Linq to Lucene은 Linq to SQL을 기반으로 작성되어 있으며, Linq to SQL 기반으로 진행되는 프로젝트에서는 같은 방법을 사용하는 Linq to Lucene을 그대로 사용하는 것이 프로젝트 통합 관리에 유리할 것입니다.

하지만, Linq to Entities 또는 Entity Framework 기반으로 프로젝트를 진행 한다면, Linq to Lucene을 그대로 사용하는 것이 껄끄러울 것입니다.

Linq to SQL 기반의 Linq to Lucene은 DatabaseIndexSet<DataContext>:IndexSet 을 상속받은 구상 DataBase  , e.g NorthwindIndexContext  를 직접 정의 하여 사용하는 방식을 취합니다.

Entity Framework(EF) 기반의 프로젝트에 직접 사용하기 위해서 구글링을 하였으나, EF용 코드가 존재 하지 않아, 코드를 작성하였습니다.
L2S 기반의 DatabaseIndexSet 에 대응하는 EF 기반 DatabaseEFIndexSet 을 Lucene.Linq 프로젝트에 포함하고 사용하면 됩니다.

EF용 DatabaseEFIndexSet

 public class DatabaseEFIndexSet<TObjectContext>: IndexSet
        where TObjectContext : ObjectContext {
        #region Fields/Properties

        readonly ReaderWriterLockSlim _dataContextLock = new ReaderWriterLockSlim(LockRecursionPolicy.SupportsRecursion);
        TObjectContext _dataContext;
        

        /// <summary>
        /// The data context instance. 
        /// Data Contexts should be recycled periodically based on unit-of-work basis.
        /// 
        /// </summary>
        public TObjectContext ObjectContext
        {
            get
            {
                return _dataContext;
            }
            set {
                if (value == null) 
                    throw new ArgumentNullException("value");

                using (_dataContextLock.WriteLock()) {
                    _dataContext = value;
                }
            }
        }

        #endregion

        #region Ctors/Init

        /// <summary>Creates RAM Indexes from data context</summary>
        /// <param name="dataContext">The data context instance</param>
        public DatabaseEFIndexSet(TObjectContext dataContext)
            : base() {
            if (dataContext == null)
                throw new ArgumentNullException("dataContext");

            ObjectContext = dataContext;
            Init();
        }

        ///<summary>Creates File System Indexes from data context</summary>
        ///<param name="path">File System path</param>
        /// <param name="dataContext">The data context instance</param>
        public DatabaseEFIndexSet(string path, TObjectContext dataContext):base(path) {
            if (dataContext == null)
                throw new ArgumentNullException("dataContext");

            ObjectContext = dataContext;
            Init();
        }

        ///<summary>Creates file system indexes from data context</summary>
        ///<param name="directory">File system directory info</param>
        /// <param name="dataContext">The data context instance.</param>
        public DatabaseEFIndexSet(DirectoryInfo directory, TObjectContext dataContext)
            : base(directory) {

            if (dataContext == null)
                throw new ArgumentNullException("dataContext");

            ObjectContext = dataContext;
            Init();
        }



        private void Init() {

            Type dcType = typeof(TObjectContext);

            // get all tables in db context
            var linqTableTypes = GetTableTypes();

            int linqTableCount = linqTableTypes.Count();

            // Throw if there are no tables
            if (linqTableCount == 0)
            {
                throw new ArgumentException("The data context type has no Tables");
            }

            // if there are any tables on the context, add them to the set
            foreach (var linqTableType in linqTableTypes)
            {
                try
                {
                    Add(linqTableType);
                }
                catch (ArgumentException)
                {
                    // linq table type doesn't have Document attribute
                    // for now, skipping this table type makes sense
                }
            }

                
            

        }

        #endregion
        
        #region Private Methods

        private IEnumerable<Type> GetTableTypes() {

            Type iTableType = typeof(EntityObject);
            var linqTableTypes = from prop in typeof(TObjectContext).GetProperties()
                                 where prop.PropertyType.IsClass && prop.PropertyType.Name =="ObjectQuery`1"
                                 select prop.PropertyType.GetGenericArguments()[0];
            //var linqTableTypes = from prop in typeof(TObjectContext).GetProperties()
            //                     where prop.PropertyType.IsGenericType &&
            //                           iTableType.IsAssignableFrom(prop.PropertyType)
            //                     select prop.PropertyType.GetGenericArguments()[0];

            return linqTableTypes;
        }

        private int GetTableRecordCount(ITable table, Type tableType) {
            Expression expr = Expression.Call(typeof(Queryable), "Count", new Type[] { tableType }, Expression.Constant(table));
            int count = table.Provider.Execute<int>(expr);
            return count;
            
        }


        #endregion

        #region Public Methods

        /// <summary>Write all the records from the table type into their respective indexes</summary>
        /// <typeparam name="TEntity">Table type to index</typeparam>
        public void Write<TEntity>() {
            //Write(typeof(TEntity));


            using (_dataContextLock.ReadLock())
            {
                Type tableType = typeof(TEntity);
                string name = tableType.Name;

                IIndex index = this.Get(tableType);

                ObjectQuery<TEntity> objectQuery = _dataContext.CreateQuery<TEntity>(name);
                if (objectQuery == null)
                    throw new ArgumentException("tableType doesnt belong to db");

                int itemCount = objectQuery.Execute(MergeOption.NoTracking).Count();

                var items = objectQuery.AsEnumerable();

                Console.WriteLine("About to write " + name + "s...");


                if (itemCount == index.Count)
                {
                    Console.WriteLine("Not adding " + name + "s, because index is up to date.");
                }
                else
                {
                    index.Add(items);
                    Console.WriteLine("Added " + index.Count + " " + name + "s.");
                } 
            }




        }

}

사용예: 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.Data.SqlClient;
using System.Data.Common;
using Lucene.Linq;
using System.Data.Linq;
using Lucene.Linq.Expressions;
using System.Diagnostics;
using Lucene.Linq.Utility;
using Lucene.Net.Search;
using Lucene.Net.Index;

namespace Lucene.Linq.EntityDemo
{
    class Program
    {
        static NorthwindIndexContext index = null;

        static void Main(string[] args)
        {

            var path = @"C:\temp\index";
            try
            {
                System.IO.Directory.Delete(path, true);
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex);
            }
            System.IO.Directory.CreateDirectory(path);
            Console.WriteLine("Northwind Db index:" + path);

            Type cType = typeof(Customers);

            index = new NorthwindIndexContext(path, new NorthwindContext());

            // add all the customers/orders to the index
            //index.Write(); // uncomment this line to write both Orders and Customers
            index.Write<Customers>();

            DefaultFieldsDemo();

            System.Console.WriteLine("Press any key to continue...");
            System.Console.ReadLine();

        }


        static void SimpleDemo()
        {
            var query = from c in index.Customer
                        where c.ContactTitle == "Owner"
                        select c;

            Console.WriteLine("Simple Query:");
            ObjectDumper.Write(query);
            Console.WriteLine("Query Output: {0}", query.ToString());
            Console.WriteLine();

            var results = query.ToList();
            Console.WriteLine("SimpleDemo returned {0} results", results.Count);
        }

        static void DefaultFieldsDemo()
        {
            var query = from c in index.Customer
                        where (c.Match("Folies"))
                        select new { Name = c.ContactName, Id = c.CustomerID, Company = c.CompanyName };

            Console.WriteLine("Default Fields Query:");
            ObjectDumper.Write(query);
            Console.WriteLine("Query Output: {0}", query.ToString());
            Console.WriteLine();
        }

    }




}

현재글 : Lucene.Linq with Entity Framework, Linq To Entities posted By - 반더빌트 2009/12/27 20:53

개발을 하다보면 데이터베이스를 연결하는 경우가 있습니다.

데이터베이스 파일 자체에 기존의 로그인 계정이 존재하지만, 데이터베이스 인스턴스의 로그인과 매핑이 되어야  새로 연결한 데이터베이스에 로그인 하여 사용할 수 있습니다.

SSMS로 인스턴스에 매핑할 사용자를 만들었는데

Error 15023 User or role already exists in the current database

에러 메세지를 낼때가 있습니다.

 인스턴스의 계정과 기존의 데이터베이스에 있는 계정이 매핑에 실패하였을 때 발생하며, 새쿼리 창을 띄워서 아래의 명령을 실행 시키면 문제가 해결 됩니다.

exec sp_change_users_login Update_One, 'MyLogin', 'MyLogin'

솔루션 해결에 대한 블로그 포스트
Error 15023 User or role already exists in the current database

You may run into the 15023 error if you restore a MS SQL database from backup.  You expect a restored database to be in exactly the same state as the backup, but the login fails for a user that had permissions in the backed up database.  When you use the "User Mapping" SQL Management Studio functionality to allow the user permissions to the new database, you receive the 15023 error.  This is caused by Security identification numbers (SID) that are mismatched or 'orphaned' in the sysusers table. 

The SQL Server stored proc sp_change_users_login locates and fixes these records.  Run it with a single parameter 'Report' to get a listing of abandoned user names and corresponding SIDs:

exec sp_change_users_login Report

The 'Update_One' parameter will reconnect a single login:

exec sp_change_users_login Update_One, 'MyLogin', 'MyLogin'

You can find more info about this issue at:

http://support.microsoft.com/kb/246133

http://support.microsoft.com/kb/240872

This next blog expands on the available parameters for sp_change_users_login:

http://blog.sqlauthority.com/2007/02/15/sql-server-fix-error-15023-user-already-exists-in-current-database/

Also, try checking out the source for sp_change_users_login found in the Sql Server Management Studio under Databases | System Databases | Master | Programmability | Stored Procedures | sp_change_users_login.

현재글 : [MSSQL Server 2008 SSMS] Error 15023 User or role already exists in the current database posted By - 반더빌트 2009/11/24 15:13