저두요

그래서 전 KSUG 술마실때만 쑉쑉 가지요 ㅎㅎㅎㅎ

off도 중요하지만 on-line에서도 인간미를 잃지 않았으면 해요. ^^

네~ 공감합니다.... T.T

와 맛있겠어요 @@

불조절 하기 힘들죠.. 잘못하면 탄고기를 먹어야 한다는 ..

돼지고기 먹고 싶다.

최악은 익지 않고 그을리기만 한…

어딜 가신거예요..T^T

정말 맛있겠다 후르릅

오오 맛있어보여요

너~어무 맛 있어서 밤에 배탈났었어요.~_~

얼굴이 벌게지는거 같아요.

우리망년회여기서할까?금토

그렇게 되면 전 못가요 T.T

그럼 비스는 회비만 내 ㅋㅋ

필름 제대로 안물리면 숫자 안돌아가지 않나요 ㄷㄷㄷㄷㄷ ㅠㅠ

이 녀석은 완전 기계식이라서 그런 것 모릅니다. -_-);;;

ㅋㅋㅋㅋㅋ

왜 두개나...-_-

써머셋 밖에서 볼 땐 뭔가 상당히 고급스러워보여서 별다방같은 “대중적인” 가게는 없을 줄 알았는데 딱히 그런 것은 아닌가봐요?

제 아지트 같은 곳이에요. 주변이 상당히 고급스럽고 사람도 별로 없어서 얘기하거나 책 읽기 좋아요. ^^

아. 한때 써머셋 자주 갔는데. 하하하. 거기가면 만나는거 아니예요? ^^

눈에 익은 플래너.ㅋㅋ

ㅋㅋ 전혀계획없이살고있다는…

플래너는 그저 자세일 뿐..

그건 보통 건져내지않나요?

아, 부럽습니당. :)

한결이 본지 무지 오래됐네요~

Erica 나는 왜 건져내는지 모르겠어. 그 맛있는 멸치 수육을... -_-

윤지원 님 : 어여 가정을 꾸리시...;;; 소내기 : 많이 컸어. ㅋㅋ

음... 저는 어쩌다 들어가 있는 것도 건져내고 안먹는데... ==3=3

비리진 않았나용? ㅋㅋ

핵심은 좋은 멸치를 사야 한다는 거... 맛없는 멸치는 먹어도 아무 맛도 안나요.

아 입맛 당겨요.

사진찍는프로그래머 : 뭘 좀 아신다는..ㅎㅎ

아 좋은 멸치를 넣어야 하는 군요 @@

때로 내 내면의 변화가 그들의 음악을 따라 갔다는 느낌도 듭니다.

희망을 품고 로또를 사며 즐겁게 살아요 ^^

희망을 품고 질르며 즐겁게 살아요 ^^

요즘 글들이 많이 무겁네요 .. 힘내시고 나아지시길 ^^;

감사합니다. 잠시 눌렸나봐요. ^^

저도 그런 식으로 미투에 말리는 경우가 왕왕...

역시 UNIX 기반 OS 개발자들에겐 UNIX 기반 OS가 편해요

시그윈은 엉망진창 절름발이라고 생각ㅋㅋㅋ bash find grep vim cut echo od 손에 너무 익어서..

시그윈 몽땅 설치했는데 안써요--;

전 리눅스 기반 서버 어플 개발할 때도 Windows 에서 개발했다는;;; Visual Studio 킹왕짱! ㅋㅋ

cygwin은 로컬에서 sshd 띄워서 돌리면 그나마 좀 쓸만한데 한글 지원이 제대로 안 된다는 문제가..ㅠㅠ

오스카 님 : Visual Strudio를 한번도 안 써봤는데 다들 최고라고 하더군요. 한번 불법 복사라도 해서 써봐야겠어요. ㅋㅋ 아침놀 님 : 아항. 그런 방법이... 한글이야 뭐... 보조로 쓸 수 밖에 없으니 대~충

편법이긴 하지만 이런 방법도 있습니다. 물론 저는 우분투 데탑에 따로 머신 두고 쓴다능 -_-;////——- 그 방법

바틈업과 탑다운이 상위 1/3지점쯤에서-_-? 만나는 게 좋겠죵. 근데 보통 PT로 박스만 그리던 분들께서 탑다운 프렛셔~를;; 하는 경향이 있지 않나여 ㅋㅋ

그 적임자중에 끼고 싶은데, 잘 안되네용~

dawnsea 님 : 그죠? 현실에 맞지도 않는 블랙 박스를 가지고 와서 쓰라고 하니... 소내기 : 일단 업무에 집중하다보면 영감이 떠오를 때가 있을거여.

프레임워크라는게 보통 같은일을 세번정도 할 노력이 드는일이라 세번 넘게 할일이 아니면 투자대 효용가치가 없더군요.

그와는 별도로 프레임워크가 커버하는 영역을 잘 이해하고 있으려면 세번정도 같으나 다른일들을 삽질해본 사람이 아니면, 제대로된 프레임워크가 안나온다능..

반복되는 일은 다른 사람을 시키세요. (일자리 창출)

그래서 Django가 좋은 듯합니다;; 실제로 웹사이트 개발하다가 짜던 것을 그대로 프레임웍화한 경우라고 하니...

아침놀 : 오호 그렇군요. ORM 쪽만 잠깐 살펴 보았었는데... 애석하게도 Python을 사용할 기회가 없군요.

첫 댓글에 무례가 될런지 모르겠습니디만, 이 토론을 제가 작성하는 PPT 자료에 인용해도 될까요? 자료는 웹 공개용입니다만... ^^;

이 글 지금 고민하고 있는 주제에 대한 뚜렷한 해답. 그리고 토론~ 인용해도 될런지 문의 중…

framework의 다른측면 재사용성 이외의 project policy(exception, coding rule.etc) 적인 부분에 대해선 어떻게 생각하시나요?

아시모프 님 : 아마 framework이라는 단어에 대한 이해가 저랑 약간 다른 듯 합니다. 저는 말씀하신 것들을 framework이 아닌 개발 표준으로 분류해서 다룹니다.

써니 님 : 아이고 뭘 문의까지... 공개된 것이니 마음 껏... ^^

제가 알고 있는 framework 의 이해입니다. 예를들어 struts를 보더라도 validation의 대한 exception처리라든지 action간의 이동들은 framework의 규약에 종속되어 있습니다.(물론 커스텀도 가능하지만 말이죠..)

아참 위의 처음덧글에서 말하는 coding rule은 제블로그 글(덧글포함)에서 말하는 코드를 강제한다는 의미로서 말한것입니다.

(필요 이상으로) 논란이 되었던 글의 답글이군요. ^^ 개인적으로 프레임워크에서 재사용을 다루어야 하는 것인지는 의문입니다. 예를 들어 스트럿츠는 action의 재사용성을 고려하고 만들었습니다. 하지만 action의 재사용성이 프레임워크에서 지원해야 할 문제일까요? 저는 언어 차원에서 OOP적인 기법으로 충분히 재사용을 할 수 있다고 봅니다.

저는 framework의 재사용성이라고 하면 컴포넌트 코드의 재사용이 아닌 workflow의 재사용이라고 생각합니다. 흔히 말하듯 template method pattern의 확장된 형태가 framework이라는 거죠.

참고로 제가 가지고 있는 프레임워크에 대한 생각은 이 글 을 참고해주시고요. 이 글을 쓴 취지가 좋은 프레임워크는 실무를 반영해야 한다는 것이므로 토비님의 이 글 이 제가 말하고 싶은 내용이라고 보시면 될 듯 합니다.

결국 실무를 하는 사람들이 객체지향 기술을 더욱 익혀 프레임워크로 발전시키는 것이 좋은 프레임워크를 만드는 바른 방향이라는 생각, 즉 강조점은 '객체지향 원리'에 있었던 ... ㅎㅎ

^^; 링크하신 글에 대해 별다른 이견은 없고요. 재사용성에 관해서는 조금 이견이 있습니다. 논점을 나눠야할듯한데, 1.서서히 만들어지는 것이 더 낫다 2. 실무자가 만드는것이좋다. 에서 제가 애초 말하고자 했던 부분은 1에 관한 이야기였습니다. framework의 정책은 개발중 수시로 변경될수 있는 부분이 아니기 때문에, top down의 접근도 필요하다는 생각입니다.

맞습니다. 모든 것은 종합적이어야 하겠죠. 다만 수시로 변경되는 것과 성장하는 것은 구별이 되어야 한다고 생각합니다.

그러면 '내가 들어가서 바꾸겠다'라는 생각으로 접근하심은;;

아침놀 님 : 물론이죠. 일단 들어가면! (다 죽었어!)

에릭감마 같은 초고수가 인터페이스 이름 뒤에 1,2 숫자나 붙이고 있을 수 밖에 없는 상황이라니...

오호 에릭감마가 어디서 그러고 있어요? +_+ 설마 1,2 안 부치고 One,Two...;;;

전 반대로 생각했습니다. 정의된 interface를 변경하지 않는 것은 사용하는 측을 배려하기 위함으로 보입니다. 제가 해석하기로 본문 중 2,3 으로 숫자가 붙은 것은 원래 interface 쓰는 client module이 안심하고 사용하기 위함이지, 언어적 한계때문에 우회한 방법이라고 보이진 않네요.

맹수 : 이클립스 맹글면서 그러고 있다잖아. 언어가 이러니 저러니 투덜 거리는 것도 사실 바보 같은 짓이기는 하지. 솔직히 난 아직도 internal과 public도 구별 못하는 수준인데...

일단 publish 된 interface 의 경우 변경하지 않는 것이 cilent 의 상호 연동을 보장하기 위한 방안이라고 생각합니다. 확장이야 모르겠지만, interface가 변경되어 버리면 그에 의존하던 기존 코드들은 다 동작을 못하겠죠. 감마옹도 그래서 일부러 2,3을 붙이더라도 기존것을 유지하려고 애쓴 것이 아닐까요

오리대마왕 : 그게 메소를 변경하는 문제라면 말씀이 맞는데요. 단순히 몇가지 메소드를 추가하는 것 조차 안되니 말이죠. 저 글에서도 이런 특성 때문에 interface 대신 추상 클래스가 유용한 경우도 있다고 하네요. 켄트백의 구현패턴에서도 같은 얘기가 있고요. 하지만 추상 클래스는 다중 상속 문제 때문에 한계가...;;;

메소->메소드 입니다. (또 오타... -_-);

아, "확장"에 국한해서 말씀하시는 것이라면 그렇겠네요. 전 "확장"이라는 표현을 "확장" 해서 "변경" 까지 언급하시는 것으로 잘못 이해했습니다. ^^

켄트백의 구현 패턴에 보면 version interface pattern이 있는데 이 것이 이런 자바의 제한 때문에 생긴 패턴이죠. 그런데 다른 언어에서는 인터페이스를 써본 적이 없어서 어떤지 모르겠네요.

오리대마왕 님 : 다시 읽어보니 제가 좀 오해하게 썼네요. ㅎㅎ 죄송...

하긴 자바 처음 설계할 때에 누가 인터페이스가 이렇게 성공할 줄 알았겠어.

ㅋㅋㅋ 그런데 확장까지 가능한 어떤 새로운 방법이 있다면, 어떤 것일까요? 흠, 그건 programming langauge 개발자가 알아서 할 일인가..

자바의 경우 프레임워크 클래스에 메소드가 추가 되었다고 해도 그 클래스를 가져다 쓰는 놈은 다시 컴파일 할 필요 없이 그냥 바이너리 상태에서 돌릴 수 있는데 인터페이스의 경우는 인터페이스에 어떤 변형(단순한 확장)만 있어도 다시 컴파일 해야만 하거든요. 어떤 특별한 기술 문제가 아니라 언어의 특성일 뿐이에요. (물론 제가 이해 못하는 언어학적인 이유가 있을지도 모르겠지만... -_-);'

사실 버젼의 문제라면 인터페이스의 문제라고 하기 보다는 모듈이나 컨포넌트에서 하는게 맞지 않나 싶은데요. 펄이나 루비처럼 모듈에 버젼기능을 추가한다거나.

이제 슬슬 기억이 안나는데.. 인터페이스끼리는 mixin 혹은 다중상속등이 안되나요? --;

OSGI 같은 것을 사용해서 버전 관리를 한다고 해도 Interface가 변경되면 다시 컴파일 해야 하는 문제는 여전히 존재. SOAP, REST 같은 비 Java 기술을 사용해서 컴포넌트끼리 연동하지 않는 한 Interface 문제는 계속 남을 수 밖에 없지 않을까?

맹수 : 너무 다양한 언어를 하다보니 혼돈이 오고 있는 거야. -_-;

솔직히 다시 컴파일 하는게 왜 문제인지 모르겠어요. 객체처럼 작은 단위들 안해서 굳이 그런 재컴파일 없는 동적인 부분이 필요한지.

Subinterfaces은 여러개 되는 군요. 흠.

그냥 내가 만드는 프로그램 내에서라면 문제가 없지. 그런데 프레임워크나 기타 API를 만드는 경우라면 내가 만든 모듈을 누가 얼마나 쓰고 있는지 알 수 없는 상황이 되고 인터페이스 변경으로 하위 호환성이 안되는 일이 생겨 버리는 것이 문제.

대규모로 설계해 본적은 없지만.. 결국 변화를 줄때 변하지는 않는 축을 결정하고 그 축 중심으로 변화하라.라는 객채마법사들의 주문들이니까. 명시적으로 프로토콜을 만들든지. 덕타입으로 각각 책임을 할당하듯. 또 다형성 확득의 차원에서 계약 자체의 변화에 너무 많은 기능도 좀 아니지 않을까. .

해서요... 그리고 사실 그런 프레임워크나 라이브러리의 API의 변화는 자바이든지 루비이든지. deprecated 하는 정책 말고 본적이 없어서요. (..)

그런데 별도 지시어라고 하니까 DesignByContract가 생각 나는 군요.. DuckType에 DByC을 부치는게 이득일까요? StrongType이 더 이득일까요?

계약과 인터페이스

내가 문제 삼는 것은 너무 '많은 변화'가 아닌 어떤 변화(단순한 메소드 추가)도 허용하지 않는 경직성이고 만약 계약 때문이었다면 interface 선언할 때에 final 같은 지시자를 두도록 하는 방법을 쓸 수 있었다고 생각해. 그리고 설계를 뒤로 미루는 Agile과 자바가 친해지기 어렵게 만드는 이유가 되기도 하고...

Strong Type을 Design by contract라고 하기에는 좀 그렇지 않나? ㅎㅎ 그런데 DByC는 뭐여?

JAVA, 잡아, 자 봐...

DByC DesingByContract 인가보네요.

전 제가 뭘 배포해서 남들이 가져다 쓴적이 없어서. --;

아 항! DByC가 그거…(바보 아냐. -_-) 솔직히 Duck Type의 단점을 DByC(바로 써먹..)로 해결하는 것은 너무 무거운 느낌이고 dynamic type, static type, DByC 모두를 제공하는 것이 좋지 않을까? Scala의 compund type도 실용적인 것 같고…

ucandoit 님 : 예 낮잠 좀 자보도록 하겠습니다. ㅋㅋ

멋지시군요. 다 자바를 사랑하기에 하시는 고민인듯.. 자바의 문제는 자바를 사용하는 대부분이 자바를 사랑하지 않는다는데 있지 않겠습니까?

아~ 나는 말한마디 섞지도 못하능구나…..(저는 설계보다는 구현에 중점을…..실은 구현하기도 바쁘다능 캬캬캬) [ 글보러가기 ]

잘 모르니까 이렇게 말이 많은거죠. 구현하다보면 길을 잃고 뱅뱅 도는 일이 일상다반사에요. -_-

좋은 동료들과 일하셨었군요.

계도 : 예. 행운이었지요.

흑! 가슴찡! 또 함께 할날이 왔으면 좋겠어요 ^^

이직하세요?

그래서 눌렀나요!!!!!!

dawnsea 이직이라기 보다는 다니던 회사가 뽕! 해버려서요. ㅎㅎ 소내기 눌렀찌. -_-

ㄴ 거기서 부장되시면 저 댈꼬 가주세요--; (이제 본격적인 김칫국시리즈!!)

저도 좀 굽신굽신

저두 어떻게 안될가요 ㅋㅋ

저도 좀 어떻해 안될까요? 이히히히히;;;

저도 좀 하악~~~

이분들이! 저는 썩은 동아줄이에효.

저도 어떻게 안될까요? ㅡㅜ

저도 어떻게 안될까요? ㅡㅜ (2)

모야. 우리 gen129 만드는 거야? ㅎㅎ

말처럼 우리가 다시 모이는 것은 어려울지도 몰라. 그래도 난 우리가 같이 일했던 것이 너무 자랑스럽고 행복했어. 내가 최고가 아닌 것처럼 우리 중 누구도 최고는 아니었지만, 같이 있으면 든든했고 서로 생각을 나누며 함께 성장할 수 있었던 그것이 좋았어.

옹~

요새는 커피도 칵테일????

ㅎㅎ 칵테일… 보통 하우스 블렌드라고 해서 커피가게마다 고유의 맛을 내는데 여기는 8가지 커피를 혼합하더라고요. 아마도 싸구려에 고급커피 약간 넣는 식 아닐까요? 저는 아시아산 커피를 좋아해서 이렇게 한가지만 파는 곳은 약간 아쉽죠.

오 미금이면 바로 옆마을인데

정자동에서 일부러 가기는 좀 그렇지만 혹시 미금 가실일 있으면 함 들러보세요. ^^

예전부터 궁금했는데, ,슈퍼돔을 하나사서 가상화로 여러 대 서버를 돌리는게, 경제적인거 맞나요? 하기야. 여러가시 시스템많으면 한서버에 때려넣으면 문제가 많기는 하겠쥐만, 전체적인 성능은 이건 뭐 좀 아니다 싶고, 이거 뭐 내가 장기하도 아니고 싶네요--;(전기세는 좀 덜나갈려나)

예전에는 ibm 360 같이 폐쇄적인 시스템에서 타 시스템을 예외적으로 지원하는데 가상화가 사용되었었는데 요즘은 유지보수성과 유연성 때문에 이것을 사용하는 듯 하더라고... Unix를 사고 싶은데 가끔 NT도 돌릴일이 있을 것 같은 고객에게 "저희 것은 가상 머쉰으로 NT도 돌릴 수 있습니다. 걱정말고 사세요. "라고 말하는 것 아닐까?

중장기적인 총비용을 따지면 역시 따로따로 머신을 구입하는 것이;;;