Yagur의 Juggling ::

« 2010/09 »
일	월	화	수	목	금	토
			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

'낙서'에 해당되는 글 4건

2008/07/17 TDD 인하우스 툴, Eclipse Ganymede 잡담.
2008/05/19 객체간 소통에 관한 낙서(2)
2008/04/03 "다수의 프레임워크를 합성하기"에 관한 낙서
2008/03/29 표준 레이어에 관한 낙서

TDD 인하우스 툴, Eclipse Ganymede 잡담.

개발/낙서 | 2008/07/17 10:37

TDD할때 쓰는 인하우스 툴입니다. 취향대로 쓸려다보니 적당한게 없어서 만들어쓰게 되는군요.

이전 수필들에 쓴것과 같이, system, component, integration, package, class, unit, chain-unit 같은 단위로 테스트 되고 테스트간 dependency 설정이 테스트 진행에 영향을 미칩니다. 로그와 테스트 콜 스택같은걸 보여줘서 복잡하고 커다란 테스트에 어느정도 도움이 되는군요.
아직 dependency graph 시각화 몇 편집 같은 plug-in은 만들지 못했지만, 일이 어느정도 마무리 되면 추가할 생각입니다.

Eclispe Ganymede에 UML 2.0 플러그인이 있더군요. 매우 쓸만해 보입니다.

StarUML을 써왓는데, 이걸로 갈아타봐야겠습니다. 일단 관계 연결 선 결합이 매우 깔끔하게 되는게 마음에 듭니다. 더써봐야알겠지만요 =)

'개발 > 낙서' 카테고리의 다른 글

TDD 인하우스 툴, Eclipse Ganymede 잡담. (0)	2008/07/17
객체간 소통에 관한 낙서 (2)	2008/05/19
"다수의 프레임워크를 합성하기"에 관한 낙서 (0)	2008/04/03
표준 레이어에 관한 낙서 (0)	2008/03/29

Posted by yagur

낙서

Comment 0 Trackback 0

Trackback : http://yagur.impon.net/trackback/143

객체간 소통에 관한 낙서

개발/낙서 | 2008/05/19 23:52

작성자: yagur Rev : 1

두명의 사람이 대화를 한다면...

세명의 사람이 대화를 한다면...

열명의 사람이 서로 전부 정보를 전달하게 된다면...

이 그룹에 한명이 정보를 바꾸면 어떤 상황이 벌어질까? 전부 변경된 정보를 얻을 확률은? 정보의 변경 영향력을 추측하기 어려울것이다.
이들의 중간 매개체가 존재한다면 어떠할까?

예를 들면 위키 같은것....
하지만 구성원이 위키를 확인하기전까지, 구성원에게 정보가 갱신이 되지 않을수도 있다. 그래서 이들 구성원은 때론.... 탑다운 형태를 지니기도 한다.

이들은 모두 역활로 정의된 것들을 실체화 하는 구성원들이다. 모두 대체될수 있는것이 이상적일것이며, 저들의 정보 소통경로의 효율성에 따라 해당 그룹의 품질은 평가 될수 있다.
지금 작성하는 객체들은 어떠할까? 모두가 모두를 알아야 할정도로 정보 소통의 경로가 복잡하지 않은가? 정보 공개의 제한을 어디까지 해야 객체간의 효율적인 정보 교환이 이루어질까...

'개발 > 낙서' 카테고리의 다른 글

TDD 인하우스 툴, Eclipse Ganymede 잡담. (0)	2008/07/17
객체간 소통에 관한 낙서 (2)	2008/05/19
"다수의 프레임워크를 합성하기"에 관한 낙서 (0)	2008/04/03
표준 레이어에 관한 낙서 (0)	2008/03/29

Posted by yagur

OOP, 낙서

Comment 2 Trackback 0

황상철 2008/07/11 00:18
이야 참 재밌네요. 사람을 더 추가하게는 프로젝트를 도와주는게 아니라는 말이 생각납니다. ^^
- yagur 2008/07/12 23:20
  존재 목적 그리고 정보 소통 방법과 소통량이 인적자원 혹은 객체자원에게 중요한것 같습니다. 구멍난 배에 사람을 더 태우는면 더 빨리 가라앉을것 같습니다. =)

Trackback : http://yagur.impon.net/trackback/140

"다수의 프레임워크를 합성하기"에 관한 낙서

개발/낙서 | 2008/04/03 22:11

작성자: yagur Rev : 1

프레임워크를 지닌 컴포넌트들의 제약으로, 일부는 하드코딩하거나 재사용이 조금 힘든 프레임워크들의 조합을 그동안은 사용하고 있었습니다. 만일 사용자가 테스트 프레임워크, 실시간 렌더링 프레임워크, 사용자 정의 GUI 프레임워크를 전부 사용해야한다면 어떠할까요. 아마 특정 프레임워크에 나머지 프레임워크를 울며 겨자 먹기로 붙여 넣기 하고 있는 분도 계실것입니다. 어떤 경우 프레임워크간의 경계가 점점 사라지고 끈끈히 결합되는 경우도 있습니다. 결합이 나쁘다는 것은 아닙니다. 단지 프레임워크간의 의존성을 명확히 하지 못하고 스파게티처럼 얽혀버리는 경우는 피해야 하기때문에, 어느정도 주의는 필요합니다.

기본 아이디어

루프를 통해 실행되는것과 한번만 실행되는 것의 차이

어떤 프레임워크의 동작은 위의것과 같은 차이점을 나타내기도 합니다. 한번 실행되고 종료되는 프레임워크가 있을수 있고, 루프를 돌며 실행되는 프레임워크가 있을수도 있습니다.
합성대상인 프레임워크를 하나의 레이어로 보고, 공통 인터페이스로 접근해 이들을 합성하는것은 기존의 프레임워크를 재사용하는데 의미를 둘수 있습니다.
이 레이어들의 형태를 보면 Scope관련 관용구들과 비슷하기도 합니다. 작은 범위안의 관용구가 아닌, 멀리서 봤을때의 커다란 플로우 청크들의 범위를 보는것이기 때문에 유사합니다.

'개발 > 낙서' 카테고리의 다른 글

TDD 인하우스 툴, Eclipse Ganymede 잡담. (0)	2008/07/17
객체간 소통에 관한 낙서 (2)	2008/05/19
"다수의 프레임워크를 합성하기"에 관한 낙서 (0)	2008/04/03
표준 레이어에 관한 낙서 (0)	2008/03/29

Posted by yagur

OOD, 낙서

Comment 0 Trackback 0

Trackback : http://yagur.impon.net/trackback/136

표준 레이어에 관한 낙서

개발/낙서 | 2008/03/29 18:13

작성자: yagur Rev : 1

컴포넌트마다 기능과 인터페이스도 다르고, 교체가능이 불가능한 경우가 렌더링 엔진들의 현재인것 같습니다. =) 아마 NotReal로 제작했다가 GameBrother로 교체하면 렌더링 파트를 전부 다시 짜야하는 사태가 올것같군요.

하지만 중간에 업계 표준 레이어가 존재한다면....

지원 기능 범위, 품질, 설계가 판이하게 다르기 때문에 비현실적인 이야기입니다. 하지만 저런 추상 레이어가 존재할때의 이점은 사용자에게 매우 매력적으로 보일것입니다. 컴포넌트 제작자에겐 족쇄가 될수도 있지만 말이죠 =). 물리 엔진이나 사운드 엔진도 똑같이 그릴수 있겠군요.
만약 저것이 현실화 된다면, 공짜 Troll로 개발해서 서비스 하다가 돈이 모이면 컴포넌트만 VendorWare로 바꾸고, 대박치면 NotReal로 교체하면 되는데 말이죠 =)
음 DirectX나 OpenGL에 따라 달라지는 문제도 일종의 표준 레이어가 존재한다면 =) 더 수월할수도 있겠군요.

지금의 형태

레이어를 가진다면?

저렇게 되려면 그래픽스 표준 협회와 독점을 견제하고 경쟁하는 그래픽 API(표준을 잘지키는)들이 존재해야 할것입니다. 그렇게 되면 아마 얼추 비슷해질 가능성(?)도 있겠군요.

'개발 > 낙서' 카테고리의 다른 글

TDD 인하우스 툴, Eclipse Ganymede 잡담. (0)	2008/07/17
객체간 소통에 관한 낙서 (2)	2008/05/19
"다수의 프레임워크를 합성하기"에 관한 낙서 (0)	2008/04/03
표준 레이어에 관한 낙서 (0)	2008/03/29