미투는 참 잘 만들었다니까요.

저도 복부비만 입니다 뭐 운동부족이 원인이죠... 먹는것도 한 몫하려나?

Tolchi 뭐. 저도 먹는 거야 보통인데 전혀 운동도 안하고 평소 움직임도 적으니 말이죠. -_-

모든 남자의 고민이죠 ㅠ.ㅠ

그러니까요, 배둘레햄이 문제인데, 술을 끊어야 하고, 그러면 일도 끊어야 한다는 거죠... 흑...

내일부터 나도 반식

흐흐흐

^^; 저도 자바를 좋아하고, php옹호론자는아닙니다만, 용도의 문제겠죠?

몇가지 궁금한것은 , 1. 적재,초기화,실행 -> 스크립트 언어의 특성을 말하시는건가요? 2. 설계가 복잡하다는것은 언어비종속적 사양에 관한 말씀이신가요? 아님 php를 고려하여 설계하려니 복잡하다는 이야기이신가요? 3. 성능저하문제는 오래된 이슈인듯해요. 보통 이야기가나오면 생산성 및 compile module(JNI같은)이야기를 같이 언급하죠^^;

APM이냐, J2EE냐? 말씀하시니 생각나는데, PHP 기반으로 사업하던 후배에게 서비스 부하는 어쩌냐 하고 물어보니까… '형… 그건 어차피 값싼 서버 주욱 늘리면 되요' 라고 답변하더군요. 장단점이 있기도 하고, 설계하기 나름이라는 생각도 들고…

아시모프님 질문 보니, 이거 토론방이라도 따로 만들거나 블로그에서 토론해야 할까요? 재밌을 듯... (뒤에서 애인한테 문자왔냐, 왜 이리 실실 쪼개냐고 하네요)

제가 php 를 버리지 못한 계기는 외주인력 써먹기 좋아서 인듯

1. 스크립트 언어라고 다 PHP 같지는 않죠. JSP나 ASP 같은 Serverside script page 방식의 기술에서 그런 방식을 사용합니다.

2. 객체지향적으로 SRP 원칙에 맞춰 개발을 하고 (특히 PHP5에 추가된 인터페이스를 사용한다면) 웹 프레임워크나 DB 추상화 기술을 사용한다면 한번의 Request에 수십에서 100여개의 php script 파일을 메모리에 적재해야하는 경우도 있는데 매번 이런 작업을 하는 것은 비록 중간코드 캐쉬를 쓴다고 해도 엄청난 부하가 됩니다. 특히 thread safe하지 않기 때문에 메모리 사용량도 만만하지 않죠.

3. 물론 성능 저하 문제를 해결할 수 있는 방법은 많이 있습니다. Java나 .NET과 바인딩하는 것도 한가지 방법이고요. 하지만 그렇게 된다면 더 이상 PHP를 쓴다고 하기 힘들어지죠. ^^

K-Dog : 예 맞습니다. 하지만 그런 인력의 평균적인 수준 문제를 봤을 때 차라리 그런 인력을 써야만 하는 업계를 벗어나는 것이 더 나을 듯 하더군요. 그러다 보니 이민을 생각하게 되기도...ㅠ.ㅠ

써니 : 뭐. 비교하는 건 의미 없을 수도 있죠. PHP라고 쓸모 없다고 할 수는 없으니까요. 어쩌면 제가 PHP에 한계를 느낀 것은 제가 다른 영역으로 이동했기 때문일 수도 있습니다. 당시에 엄청난 실패를 맛 보았으니까요.

말씀하신대로 뭔가 새로운 시도를 하는 계기의 상당수는 실패 때문인거 같아요. 저도 CVS만 내리 쓰다 요즘 subversion을 도입하려는게 실패를 겪어서...

써니 : 이왕 바꾸시는 거 Mercurial 로 해보세요. ㅎㅎ subversion은 계속 이클립스 plugin이 불안하고 CVS보다 빠르기는 하지만 여전히 느리고...

결론은 1,2,3은 PHP만의 문제가 아니군요^^;

위의 여러 이슈(thread safe , 메모리등등)들이 문제가 될때에는 안쓰는게 정답인듯해요. 하지만 제가 개발한 php 프로젝트가 다행히(?) 소규모라 그런지는 몰라도 아직 위의것들이 이슈가된적은 없었어요.

아시모프 : 사실 좀 대충 얘기해서 그렇지 PHP가 좀 특이 합니다. 여기서 토론하기에는 너무 한정적이네요. ^^

예 단순한 사이트에는 효과적인 좋은 기술입니다.

공감합니다. 가벼운 사이트 개발하는데 EJB라도 들고 나오면 정말 길에다 돈 버리는 일이죠.

Mercurial 보다는 Git가 더 좋은거 같은데 (개인적인 취향문제일수도.)

예전 flickr 의 scale-out 관련 자료에서는 request 기반 생명주기가 손쉬운 scale-out 을 가능케 하였다고 했습니다.. 그 관점에서는 "php라서 쉽게 원하는 성능을 얻었다"고 말할 수 있을 것 같네요.

저도 복잡한 business-logic 이라면 java를 선호하겠지만, 짧고 많은 request 라면 php가 더 좋을 수도 있지 않을까요. 흐음, '단순한 사이트' 가 이런 사이트까지 말씀하시는 것이겠죠? (단순한 사이트라는 표현이 너무 모호하네요 ^^;)

자바 리플렉션은 나름 재밌음.

마소에서 연재된 예전 기사를 찾아보면, 딜리셔스 개발자도 PHP로 개발하고 운영하면서 하등의 문제가 없었다는 얘기가 나오더군요.

페이스북도 PHP인걸요? :-)

php를 버리시고 무얼쓰시나효? 뭐하나 재대로 하능게 없어서 한번 배워보려구요 ㅋ (겉핧기 좋아합니다 —ㅅ—;) [ 글보러가기 ]

아까 쓸까 말까 했는데 디토님도 등장하셨으니… 지금까지 본 PHP 코드 중에 MetaBBS가 가장 아름답고 감동적이었습니다.^^);;

직접 서비스를 하는 경우에는 값싼 서버를 탄력적으로 운영하는 것이 가능해서 PHP의 한계를 비교적 쉽게 극복할 수 있지만 일반 기업에서는 서버를 보강하는 일이 예산 등의 일로 쉽지 않기 때문에 제한된 박스로 최대의 성능을 이끌어내야 하는 문제가 있습니다. 결국 위에서도 말했지만 제 사정이 PHP로 적당하지 않은 곳으로 옮겨갔다고 보시면 되겠네요.

맹수 : Git는 아직 이클립스 플러긴이 초기라서...-_-

오리대마왕 : 예 규모가 아니라 비지니스로직의 복잡성을 두고 말한 것입니다. 게시판 수준의 서로 독립적인 모듈들로 구성된 서비스라면 그 모듈 숫자가 100개든 1000개든 단순한 사이트라고 할 수 있는 거죠. 그런데 짧게 쓰려니 자꾸 오해를 일으킬만한 소지를 남기게 되네요. ^^

써니 저도 5년 넘게 PHP로 별별짓하면서 잘 벌어 먹었습니다. 아마 저희가 PHP로 작업한 사이트 말씀 드리면 그런 곳도 PHP 쓰냐고 물어보실 거에요. ^^

상용 환경에서도 코드 캐쉬 잘 사용하고 있는데... 적재 탓은 좀...

세라비 : 적재만 탓하는 것은 아니죠. 코드 캐쉬를 쓴다고 해도 적재의 절반(컴파일 부분)만 해결되는 것이고요. 또 서버 환경에 따라서 불안한 경우가 많아요.

현실상황의 계층 갈등이 인터넷에서 토론되어지고, 똘레랑스를 논의해야 한다는 의견에는 공감합니다. 그런데, 인터넷 화자들 중에 누가 더 나은 블로거인가? 누가 더 유명한가, 누구의 권위가 더 높은 것인가를 놓고 계층을 만들고, 서로를 공격하는 양상은 어찌할까요?

똘레랑스는 극심한 갈등으로인해 사회가 붕괴되는 상황까지 몰린 후에 배울 수 있는 것이라고 생각합니다. 그 과정에서 힘든 고비가 있더라도 끝없이 노력하는 수 밖에 없다고 생각합니다. 하지만 말씀하신 것 보면 인터넷으로 배설하는 사람 얘기 같군요. 제가 약간 초점을 잘못 잡은 듯...ㅎㅎ

그게 무서워요~ 극한의 대립, 혁명을 거쳐야 한다는 거 말이죠. 우리 민족 내란 벌어지면 장난 아니잖아요.

사실 동학운동이 그런 상황에서 일어난 것인데 아쉽게 끝났었지요.

똘레랑스가 충만한 사회는 똘레랑스를 인정하지 않는 인간'들'을 물리적으로 배제해야 이뤄낼 수 있을 것 같습니다.

ho : 그런 똘레랑스는 똘레랑스라고 할 수 없지 않을까요? ^^

호주 ㄱㄱㅅ

ㅠ_ㅠ

호주가서 메드 맥스나 찍고 올까요? -_-

매드 맥스... 캥거루가 뒤쫒는 상황이 아닐까여? ㅋㅋ

ㄱㄱㅆ

안그래도 devpia 에서 오늘 메일에 호주 /캐나다 취업이민 같은 내용이 오면 한참을 쳐다 보게 되더라구요. 호주는 일자리만 있음 정말 멋진 곳이던데요

영국 구직 사이트에도 많아요~ ㅎㅎ

rath 님! 미워요! ㅠ.ㅠ

영어만 되면...

spring은 안부러운데 agile은 부럽네요.

배고프시겠어요.--;

그냥 아침만 먹지 말고 오라네요. 저녁은 맛나게 먹었습니다. ^^

안드신게 오늘 아침은 아니죠? --ㅅ--; 실제로 그러신분 있다고함

켁! 그 아침을...;;;;

의사 선생님께서 위는 큰 이상 없지만 배에 두르고 있는 타이어를 빼야 한다며 앞으로 반식을 하라고 지시하셨음. (하지만 난 오늘 삼겹살 2인분을 먹었고…)

음... 사진만큼?

아..아직은 양호하군요. -_-

볼 권리 말고 안 볼 권리도 좀.. 인정받는 날이 올 수 있기를.. ㅠㅠ 쥐 얼굴 안보고 시퍼염.

엡케알 1000% 공감요. ㅠ.ㅠ

왕공감 하나 추가요~

공감 1000%! ㅠ.ㅠ

하지만 나라면 BDD는 인수 테스트나 통합 테스트에 이용하는 것이 더 적당할 듯. 개발자들은 여전히 '테스트'를 작성해서 TDD로 개발하고...

인수 테스트가 무언가요? '_'

FIT와 BDD가 좀 겹치는 부분이 있다는 느낌이 있긴 했어요. 인수테스트도 TDD의 한 부분이라고 생각해서. :-)

TDD를 좀 큰 주기로도 생각하는 사람들도 있기는 한데 (틀리다고는 생각하지 않지만) 적어도 켄트백의 책에서는 짧은 주기 (수십초에서 길어 봤자 수분) 안에 끝나는 결정에 대한 테스트를 말하고 있다고 생각해. 인수테스트는 아무리 XP같이 반복 주기가 짧은 방법론이라고 해도 일주일인데...

그 짧은 주기는 TDD 훈련할때 아닌가요. TDD라는게 결국 피드백에 대한 이야기이라고 생각해서. 전략적으로 결정할 문제. 라고. 생각되어지는 되요. (잘은 모르지만.)

피드백에 대한 얘기지... 더 정확히 말하면 피드백을 빨리 얻자는... TDD를 확장하는 논의에 대해서 반대하지는 않지만 인수테스트에 테스트 자동화 기술을 사용하는 것과 극히 짧은 주기의 TDD를 쓰는 것과는 성격이 무척 다르다고 생각해... 예를 들어 오늘 내가 작업할 것을 테스트로 작성하고 하루 종일 작업한 다음에 테스트를 돌리는 것이 TDD일까? 난 아니라고 봐.

아 제가 TDD에 어떤 식견이나 아는게 없어서 자꾸 댓글 다는게 거시기 하긴 하지만요. :-)

전 단지 피드백을 빨리 얻기 위해서라고는 생각하지 않습니다. 사실 저는 켄트백의 TDD 책도 제대로 보지 못했네요. :-)

ㄴ 이 부분은 내일 함께 이야기 하도록 해요. :-) 사실 요즘 생각은 TDD가 무언지..등등이 중요한게 아닌듯. ㅎㅎㅎ

이미 말했지만 TDD를 확장하는 논의는 언제나 가능하다고 봐. 하지만 적어도 TDD를 제안한 사람의 의도와 추가적인 확장은 구분되서 논의 되어야 혼돈이 안 생길 것 같아. 같은 단어를 서로 다르게 이해하고 있다면 문제가 좀 되니까.

아! 내일이군. 오키...

실장님의 내용이 저자의 의도인가요? 흠. 책은 안봐서 믿음이 안가요. ㅎㅎㅎ

ㄴ 농담이구요. ;-)

제가 알고 있는 TDD은 몇줄 안되는 군요.

"TDD is an awareness of the gap between decision and feedback during programming, and techniques to control that gap." -Kent back.

ㄴ 사실 한줄. -_-;

"What if I do a paper design for a week, then test-drive the code? Is that TDD?" Sure. it's TDD. You were aware of the gap between decision and feedback, and you controlled the gap deliberately.

이것도 켄트 아저씨 말씀~~

둘 다 저자 서문에 있는 말이야. TDD가 뭔지 얘기할 때 잊지 말아야 할 몇가지 중에 포함되는 중요한 언급이라고 생각해.

두번째의 'a week'이 혹시 feedback 기간이라고 생각할지도 모르겠는데 그게 아니고 1주일 동안 생각하고나서, 그러니까 미리 설계를 대략하고나서 TDD로 코딩하는 것도 TDD라고 할 수 있다는 의미... 여전히 TDD의 주기는 수십초에서 수분 적어도 한시간은 안 넘는 짧은 주기인거지.

design for a week 가 decison이고 test-drive the code 가 feedback 이라면 TDD의 주기이고 unit testing하는 주기는 딴거 아닐까요? 하지만 TDD 훈련할때는 책에 있듯이 짧게 하는 훈련이 필요 할듯 해요.

우리 수요일날은 그냥 놀아요 ㅎㅎㅎ

저자 서문을 함 쭉 읽어보셔... 그리고 원래 우리는 이러면서 놀잖아. -_-

다리원에서 저녁에 밥먹던 기억이 나는 군요.

그러게 말야…

전.. 주인이 바뀌기 전에 가봤었는데.. 맛이 어때요? 친구랑 한번 가보려고 했는데 바꼈군요

쑤짱 맛은 큰 차이 모르겠어. 에전에도 품질이 왔다 갔다 했기 때문에 한번 먹어보고는 판단이... 하지만 분위기는 싹 바뀌었다는... 서빙하는 언니들도 다 한국 사람...

헉.. 예전 다리원와 틀리다니. 왠지 실망할거 같아요.

경험과 관계가 있나요? 전 경험도 없는데. 전 왜... (....)

ㄴ 그 경험이 TDD경험을 말하는게 아닌듯하이.

암튼, TDD는 할수록 어려워져요. ㅋㅋㅋ

리오 : 저는 아직 1년 정도도 안 되어서 잘 모르겠어요. UI 부분은 어려울 것 같고... 동시성 부분도 잘 모르겠고... 일단 테스트하기 쉬운 것 먼저 해보고 있어요.

저도 목차 찾기 어려운 책들로 뇽뇽했던 기억들이... ^^

ㅋㅋㅋㅋㅋㅋㅋ

흠. 전 원서랑 번역서 둘다 있는데. 오히려 그런 부분들이 좋던데요. :-)

맹수 : 글 내용이야 당근 좋지. 그낭 목차 찾기 힘들다고 말한 것 뿐.

오혹 저만 그런게 아닌가요!!

힘들지 않을까요 =3

ㅠ.ㅠ (초반에 아주 재미있지 않으면 포기할 듯)

어떻게 해결하셨나염??

data만 저장해 놓은 파티션에서 제 이름이 있는 파일을 찾아서 복사 신공으로 처리했습니다. ^^

민트가 모에요?

ㄴ http://www.linuxmint.com/ 나도 호기심을 함 받아봤어

리눅스 민트라... 담에 ubuntu upgrade 할 즈음에 한 번 try 해보겠습니다. :)

민트 정말 엘라강스하게 만들어진거 같아요 ㅋㅋㅋ

좌파는 어디에?..

RedBaron : 뭐..뭐… RedBaron님이 Red니까.. 좌파 하삼요. ㅋㅋ

작은아이! : 덕분에 용기(?)를 내서 깔아봤어요. ^^

오호... 업무용으로 쓸수 있을 정도는 되나요?

백일몽 : 한시라도 멈추면 안되는 상황이라면 비추입니다. 서버는 데비안이나 우분투 LTS. 데탑 업무용은 우분투. 개인용은 민트... 이정도 같아요.

전 좌파지만 Debian...(흑)

아까 별다방에서 민트를 설치했는데 한글 지원이 기본 설치 안 되어서 설치하려니 인터넷이 연결되어야 하고… 별다방 인터넷을 사용하려면 (실명인증 때문에) 한글을 입력해야 하고… 어쩌라고? 아주 힘들었다는 거죠.

RedBaron : 설마 stable?

테스팅입니다...ㅋㅋ

좌파로 인정합니다. 민트보다 더 급진적인... -_-

역시 장난감으로 써야 할 녀석이로군요

백일몽 : 일단 설치 과정에서 몇번 불안한 상황을 격었는데 좀 더 써봐야 확실히 알 것 같아요. 분명 데비안 테스팅보다는 안정적입니다. ^^

데비안은 순혈주의 우분투는 실용주의 민트는 ... 잘 몰라요 -_-;

진짜 좌파는 Gentoo.

홍민희 : ㅋㅋ 그건 다른 차원의 존재.. deb 패키지 기반만 다룹니다요. ^^

저런 멋진 노인이 될 수 있어야 할 텐데 말이죠… ㅎㅎㅎ

그러게말이에요.말을걸어보고가르침을받고싶었지만용기가없어옆에서바라보기만했어요

저도 저렇게 멋지게 늙고싶어요.

광화문 썸머셋!!!

여기 아시나 보네요 ㅎㅎ 아직 부산이시죠?

네. 그렇습니다. ㅠ_ㅠ

설 오심 함 뵈요. 불고기 버거라도 씹으며 질긴 인생에 대해 얘기해 보아요. ㅋㅋ

저도 일단 vb에 설치. dpkg 쓰는건 맘에 드네요

OKJSP?..

얼마 전에 가입했는데... 케누님이 열심이기는 하지만 명성에 비해서 글 올라오는 건 수는 많지 않은 것 같아요.

하긴 타 언어에 비해 자바는 자바 만으로 뭘 할 수 있는 게 없군요. 자바 개발자로 묶는 것 자체가 무리...

ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ

RedBaron : 너무 웃으면 보안이가 물지 몰라요. 쩝... 이민가고 싶을 뿐...

멋지신데요 :)

미친 신청 감사합니다~

험블 : 그냥 기분 뿐이고 역시 보기는 E.T에요. Gift : 오히려 제가... ^^

카메라와 렌즈 넣기 딱이군요. 카메라 배낭이 하나 필요했는데 음.. 근데 도시락은 ㅎㅎ

근데 저렇게 들고다니면 어깨 안아파요??

사진찍는프로그래머 : 예. 노트북에 책 몇권 그리고 카메라 가지고 다니기 딱 좋은 것 같아요. Erica : 어깨가 아니라 허리가 아프지. 그래도 숄더 백 보다는 편해.

오호 어디 다니시는데요? +_+

카메라 드시게요? -ㅂ-;;

와웃~ 도시락도 싸가지고 다니시나봐요. 근데 카메라 가방인가봐요~ ㅎㅎㅎ

제정신 상태를 일정 수준으로 유지 할수 있는 뭔가를 빨리 만들어내야 할텐데....

이걸 MS가 했다면 독제라느니 말이 나올텐데 애플이 하니 틀리군요^^

다들 애플이 여기에 신경 쓰는 것을 아니까요. 제가 처음 본 애플 UI 가이드가 맥 플러스의 것이었던 것 같아요. 지금에 비하면 상당히 단순했지만요.

그리고 MS는 오히려 거꾸로 아닌가요? 리본 인터패이스를 자기들만 쓰다가 허용하면서 선심 쓰듯 하는 것 같던데...