nezy의 IT 블로그

마우스로 드래그 가능해요.(글자 건드리면 이상해지는 버그있어요 -_-;)

위 예제는 APE 공식 사이트에서 내려받은 APE 로는 구현할 수 없습니다. 기본 APE 로는 사각형 박스가 빗면을 내려올 때, 빗면을 따라 내려오는 것이 아니라 충돌했을 때의 모습 그대로 어색하게 내려오게 됩니다.

위 예제처럼 구현하려면, APE 의 branch 중에 RigidParticle(RectangleParticle 을 충돌에 따라 angle 을 바꿀 수 있게 한 것)이 추가 구현된 것을 사용해야 합니다. 검색 끝에 찾아낸 곳은 요기.
http://dobbee.com/en/node/393

잘 읽어보시면서 따라가 보시면, 개선된 버전도 만나실 수 있습니다.

그럼 물리엔진으로 즐거운 플래시 개발을 해봅시다. ^-^/

 
마우스를 올려보세요.

디자인 없이 그냥 한번 만들어봤습니다~ 엉성하지만 일단 한번 출품해봤는데, 뽑히면 다른 분들도 카페나 블로그에 담을 수 있겠네요 ^-^;

이 위젯의 장점은
매일매일 엄선된 재밌는 동영상들로 업데이트 된다는 것이지요~

클라: 서비님~ 채팅하다가 크게 말하기를 선택하고 채팅하면 해당 서버의 유저들에게 broadcast 되게 해야 되는데요~ 그 기능이랑 프로토콜 하나 추가해주세요~
서비: 네, 기능은 추가로 개발하는데 2일 정도 걸릴거 같고, 프로토콜은 평소 하던대로 하나 추가하고 알려주세요.
클라: 네~

2일 후

서비: 클라님~ 다 됐어요 테스트 해보세요~
클라: 와~ 잘되네요 감사감사

기호: 개돌님~ 이번에 새로 특수한 기능이 붙은 달력을 하나 개발해야 되는데 일정이 얼마나 걸릴지 산정해주시겠어요?
개돌: 네~

기획서를 본 후..

개돌: 기호님~ 대충 한 2주는 걸릴거 같은데요~
기호: 다행이다. 사실 2주 정도밖에 시간이 없거든요. 적당하네요. ^^
개돌: 음.. 근데 여기 있는 이 이미지는 뭐에요?
기호: 아 이건 말이죠. 사용자가 마우스로 적당히 편집한 이미지를 넣을 수 있게 해주려구해요.
개돌: 음.. 이미지 편집이라.. 그럼 천상 activex 나 플래시를 써야겠네요.
기호: activex 는 사용자들이 싫어하니 플래시로 가죠.
개돌: (플래시로 제작은 언제.. 뭐 그건 그렇다치고)그럼 편집한 이미지는 어디에 저장하죠? 우린 저장할 데가 없을텐데..
기호: 우리 이미지 올리는 서버 있잖아요. 그거 쓰면 안되요?
개돌: 어.. 그건 디자이너들이 디자인한 파일만 올릴 수 있게 되어 있는 서버에요. 사용자는 올릴 수 없는데..
기호: 그럼 뭐 사용자도 올릴 수 있게 만들죠.
개돌: 그렇게 하면 처음에 말한 2주 안에 다 못만드는데요?
기호: 그렇게 오래 걸려요?
개돌: 네. 일단 장비를 확보한 후에 이미지를 받아주는 걸 만들어야 하는데, 이미지를 이용한 해킹을 막기 위해서 헤더 분석하는 툴도 같이 얹어 줘야 하구요. unique 한 이미지 경로를 만들어주는 것도 만들어야 해요. 거기에 서버 가용량을 넘어서는지 체크하는 모니터링 툴도 있어야 하거든요. 그리고 이것만 만들 것도 아니잖아요. 2주는 무리에요.
기호: 에.. 그렇군요.
개돌: 그리고 여기보면 사용자가 올린 이미지의 원본 파일 이름도 보여주게 되어 있는데 이렇게 하려면 DB 에 따로 또 저장을 해야 해요.
기호: 조그만 이미지 하나 붙이는데 뭔가 많이 필요하군요.
개돌: 네 =_=
기호: 그럼 그건 빼죠. 어차피 필수 요소도 아니니.
개돌: 네. 그리고 여기 보면 날짜를 보여주는 부분이 항상 맨 첫 스케쥴의 대각선 1/3 위치 위에 올라오게 되어 있는데, IE 는 되지만 파폭에선 안되는 거에요.
기호: 어 그건 디자인쪽에서 1/3 위치가 예쁘다고 그렇게 넣어달라고 해서 그렇게 한건데요
개돌: 예쁜건 전 잘 모르겠구요. 파폭에선 기본으로 지원하지 않아서요. 1/2 지점이면 문제가 없을텐데. 파폭에서도 되게 하려면.. 꽁수를 부려야 하구요.(그럼 시간도 더 걸리는데..)
기호: 꽁수라면? +_+
개돌: 그러니깐 이걸 이렇게 만들어서 안보여주고 있다가 전체 길이를 잰 후에 맨 첫 스케쥴을 찾고, 그 스케쥴의 위치를 가지고 다시 계산해주면 되겠네요. 대신 파폭에선 로딩 시에 번쩍거릴 수 있어요. IE 에선 그냥 한번에 되는데 파폭은 그래야 해요.
기호: 흠.. 번쩍거린다는게 걸리긴 하지만.. 뭐 알아서 잘 해주실거라 믿어요. ^^
개돌: 1/3 지점이 아니라 1/2 지점이면 그런 문제 없는데..
기호: 근데 디자인에서 1/3 지점을 원하니 1/3 지점으로 가죠.
개돌: (더 오래 걸릴텐데.. -_-)네. 그리고 여기 이 부분은 플래시로 해야 한다고 되어 있는데 동시에 마우스 오른쪽을 사용하게 되어 있네요. 여기선 마우스 오른쪽 버튼 먹지 않아요.
기호: 아.. 근데 다른데 가보니깐 마우스 오른쪽 눌렀을 때 메뉴가 나오던걸요.
개돌: 그건 고정된 간단한 메뉴인 경우에는 그렇게 박아넣어 놓는게 가능하지만, 여기 이것처럼 왼쪽 위에서 눌렀을 때는 이 메뉴가 나오고 오른쪽 아래에서 눌렀을 때는 저 메뉴가 나오게 하는건 불가능해요. 음 그리고 전체적으로 플래시가 너무 많은데요. 플래시를 늘리면 사이트 로딩 속도가 느려져서 좋지 않아요. 게다가 아시다시피 이번 프로젝트에 투입되는 인원이 이걸 다 감당할 만큼 많지 않아요. 플래시를 많이 줄여야 하지 않을가요?
기호: 그렇군요. 근데 플래시를 많이 넣은건 디자인쪽에서 그게 예쁘다고 해서...
개돌: ...
기호: 그럼 뭐 다 빼지요.
개돌: 그리고 여기에 일정을 한데 묶어서 보여주되 내게 wow 를 많이 준 것을 기준으로 친한 친구를 산정해서 그 친구들의 일정을 3개까지 날짜별로 같이 보여주도록 되어 있는데요. 이것 현재 저희 DB 구조상 불가능해요. 현재 쌓여 있는 데이터 갯수가 너무 많아서 이걸 매번 가져오게 하면 부하가 너무 커서 페이지가 느리거나 아예 뜨지 않을 수도 있어요. DB 캐시를 걸어줘도 좀 무리일거 같은데요.
기호: 음.. 근데 이건 있으면 정말 편한 기능이고, 친구들과 같이 보는 것이어서 거의 핵심 기능인데요.
개돌: 네 저도 있으면 정말 편한 기능일거 같은데.. 현재 구조상으론 어렵구요. 새로 방법을 찾아야 해요. 기존 데이터와 연동도 되야 하니 쉽지는 않을거 같애요.
기호: 그래서 얼마나 걸릴까요?
개돌: 잘 모르겠어요. 이부분은 고민을 오래해봐야 알 수 있을거 같은걸요.
기호: 움.. 그럼 다시 더 고민해보고 알려주세요~

질문: 왜 그렇게 태클만 거세요?

개돌:
저도 사실 yes 맨이 되고 싶죠. 하지만 현실은 그렇지 않잖아요?
일정에 유연성이 있다고 해도 사실 한계가 있는데, 그 안에 만들어내려면 가지를 쳐낼 수 밖에 없어요. 기호가 보아온 수 많은 다른 어플리케이션들도 그 쪽 개발자들이 많은 시간을 들여 공들여 만든 것들인데, 보기에 그리고 사용하기에 쉬워보인다고 만들기도 쉬운 건 아니거든요. 아니 사실 더 만들기 어렵죠 사용하기 쉬운건. 저도 시간만 많이 주면 OS 도 만들겠어요. (아니 인공위성도 만들겠네)

질문: 일하기 귀찮아서 대충 대답하는 것 아니에요?

개돌:
무슨 그런 말씀을..!
뭐 세상엔 별의 별 사람이 다 있으니 그런 식으로 일하는 개발자도 분명 있을 수 있겠죠. 할 줄 알면서도 일부러 그러거나 아니면 정말 몰라서 그러거나. 하지만 대다수의 개발자들은 그러지 않아요.

질문: 안된다고 했는데, 사실은 방법이 있었다! 그럼 어떻해요?

개돌:
사실 그 때가 제일 당혹스럽죠. 자책감도 많이 느끼구요. 내가 아는 지식 안에서는 분명 좋은 방법이 없었는데, 세상엔 머리 좋은 사람들도 많다보니, 종종 같은 일을 쉽고 간단하게 처리해버리는 사람들이 분명 있습니다. 그럴 때마다 아 역시 더 노력해야 되겠구나 반성을 하게 되죠. 프로젝트요? 아직 고칠 여지가 있다면 당연히 고치는 것이고 이미 지나간 것이면 할 수 없는거지요. 근데 역시 사람이 하는 일이라 완벽할 수는 없다는 걸 기호가 이해해줬으면 좋겠어요.

질문: 개발자면서 왜 그렇게 안되는게 많고, 모르는게 많아요? 개발자 맞아요?

개돌:
(잠시 노려보다가) 어흠. 2가지 버전으로 말씀드릴께요.
첫번째 시니컬 버전으로 말씀드리면 다 제가 부족한 탓입니다.
두번째 변명 버전은 좀 길게 말씀드려볼께요. 일단 안되는게 왜 그리 많냐면 개발은 이미 만들어진 것 위에서 또 다른 것을 만들어 가는 과정의 연속이고, 이 과정의 결과물들은 한정적인 제어점을 가질 수 밖에 없기 때문이에요. 좀더 쉽게 말하면 결과물이 쌓일수록 자유도가 떨어질 수 밖에 없다는 거죠. 피라미드 생각하시면 되겠네요.
모르는게 많다는 것의 원인으로는 급변하는 소프트웨어 환경과 부족한 지식을 들 수도 있겠지만, 사실 더 크고 직접적인 원인은 혼자 개발하는게 아니기 때문이에요. 이게 무슨 말이냐면 하나의 시스템 내에서도 특히 web app 는 다른 개발자가 만들어 놓은 것들도 같이 고려를 해서 개발해야 하는데 그 많은걸 다 기억하고 고려할 수 있는 개발자는 거의 없다는 거죠. 개발자는 신이 아니에요.

질문: 위 기호와의 대화에서는 대답을 척척 잘 하시던데

개돌:
에이 저거야 연극이니깐 저렇게 척척 답하죠. 현실에선 저렇게 못해요. 아까도 말했지만 web app 안의 모든 것을 다 알 수도 기억할 수도 없는 상황인데 저도 소스코드 뒤져봐야 알고, 주변 동료 개발자들한테 물어봐야 알죠. 해결책을 척척 내놓는 것도 사실 불가능하죠. 해결하는게 가능한지는 많이 생각해봐야 하고, 더 좋은 방법은 없는지도 또 고려해봐야 하고.
아까도 말했지만 개발자는 신이 아니래두요.

질문: 근데.. 왜 자꾸 다른걸 가져다 쓰고 그래요? 그냥 다 만들면 안되요?

개돌:
다 만들면 좋겠죠. 역시 시간이 문제에요. 가져다쓰면 이틀만에 만들 수 있고, 직접 만들면 두달이 걸린다면 질문자분은 어떤 길을 택하시겠어요?

질문: 두달요.

개돌:
그러니 아직 취직을 못했지.

디자: 개돌님~ 디자인 시안 확정이 됐는데요. 디자인 파일 어떻게 잘라서 드리면 될까요?
개돌: 아~ 이 디자인은 요기서 요기까지 이렇게 잘라주시고, 저건 이렇게 저렇게 하나하나 다 따로 잘라주세요.
디자: 네~
개돌: 그리고 이건~ 움... 어떻게 잘라야 하려나.. (잘 모르겠네) 일단 요렇게 잘라봐 주세요.
디자: 네~

디자인 파일을 다 받아서 개발 시작

얼마 후

개돌: 아.. 이건 이렇게 자르면 적용할 수가 없겠구나. 디자님~ 이것 좀 다시 요렇게 잘라주시겠어요?
디자: 네? 아~ 그럴께요.
개돌: 아 그리고 이 컴포넌트는 이런 식의 스킨을 지원하지 않더라구요.(workaround 방법은 없는지 또다른 컴포넌트는 없는지 등등 이 말을 하기 위해 이미 많은 시간을 소비함) 그래서 이 모양으론 갈 수 없을거 같아요. 그래서 요렇게 좀 바꿔봤는데 괜찮아요?
디자: 어 그건 안되는데.. 이게 이것 하나만 그렇게 만든게 아니라 전체에서 이렇게 나오는 거라서 이 모양으로 가야 해요.
개돌: 저도 그렇게 가고 싶은데, 사용하고 있는 컴포넌트에서 지원을 하지 않아요. ㅠ_ㅠ
디자: 그럼 진작에 그렇게 말씀하셨어야죠.
개돌: 저도 몰랐죠. ㅠ_ㅠ
디자: 뭐에요~

1차 개발이 완료된 후

개돌: 디자님~ 개발이 대충 완료되었는데 검수 부탁드릴께요~
디자: 네~

잠시 후

디자: 개돌님, 이 부분은 왼쪽에 3px 띄우라고 했는데 2px 띄우셨네요.
개돌: 아 그게 3px 로 했는데 컴포넌트에서 짝수 단위로만 처리하게 되어 있더라구요. 그래서 일단 2px 로 해두었어요.
디자: 3px 로 해야 되는데.. 3px 로 해주세요~
개돌: 그게 안되는건 아닌데.. 다시 만들어야 하고 그러려면 시간이 오래 걸려요. 제가 만든 컴포넌트가 아니라 다른데서 가져다 쓰는 거거든요. 이게 확장도 불가능하게 되어 있어서 바닥부터 새로 다 만들어야 해요. 1px 차이인데... 굳이 고쳐야 해요?
디자: 고쳐야 해요~
개돌: 오픈이 낼 모레인데 불가능해요. ㅠ_ㅠ
디자: 그럴거였으면 진작에 말씀하시지 이제 와서 그러면 어떻해요~
개돌: 그 땐 몰랐죠.

분위기 급랭..

디자: 그리고 이 부분 여기로 옮겨가니깐 폰트가 옆으로 살짝 어그러지는데요.
개돌: 그건 그 컴포넌트를 옮긴 지점의 좌표가 소수점이 되고 다른 컴포넌트의 아래에 오게 되면 간헐적으로 발생하는 문제인데 왜 그런지 잘 모르겠어요. 사용하는 프레임웍의 문제인 것 같은데.. 디버깅 중이에요.
디자: 몰라요~ 고쳐주세요~

분위기 급랭..

디자: 이 부분 디자인과 아예 달라요. 디자인 파일 보신거 맞아요?
개돌: 당연히 봤죠. ㅠ_ㅠ 근데 일정이 촉박해서 적용하지 못했어요. 일단 default 로 가고 오픈 후에 고칠께요.
디자: 이렇게 해서 어떻게 오픈을 해요.
개돌: 기능상으론 문제가 없는데 그냥 오픈하면 안될까요? 별로 큰 차이도 안나잖아요.
디자: 이게 어떻게 큰 차이가 안나요.

분위기 급랭..

질문: 뭐 하시고 싶은 말씀이라도?

개돌:
문득 기호나 디자가 하는 일과 제가 하는 일의 차이점이 생각나서 말씀드리는건데요.
기호나 디자는 새로운 일을 하게 되면 새로운 일에 집중하면 되요. 물론 과거의 결과물을 고려하는 일이 아주 없진 않겠지만 상대적으로 많지 않다는 거죠. 하지만 전 예전에 저 혹은 다른 개발자가 만들어 놓은 것들이 저의 새로운 일에 제한점을 만들어 주게 됩니다. 그게 쌓일 수록 힘들어지는 것이죠.

디자가 저렇게 얘기하는 것도 이해는 가요. 디자이너 일이라는게 사실 이쪽 바닥에서 제일 창조적인 일이고 그 만큼 자신들의 결과물에 대해 프라이드를 가지고 그것을 다른 이가 건드리는 것에 특히 더 민감하다는 것도 알고 있어요. 그 장인 정신만큼은 높게 사고 저도 본받고 싶어요. 세상에 없는 새로운 걸 만들어 내느라 시간과 공을 들여 열심히 다 해놨더니, 다~ 무시하고 자기 맘대로 만든 후에 뻘쭘한 변명이나 하는 것처럼 보이는 제가 짜증날 수도 있겠죠.
하지만 제 입장에서는 기호와 얘기하면서 고려해야 했던 개발적인 이슈들과 잘 돌아가는 코드를 만들기 위한 생각들을 유지하면서 일정도 맞춰야 해서 빡세게 달리느라 머리가 터질 지경인데 한 픽셀 틀렸다고 거대 수정을 요구하며 저를 죄인 취급하는 디자가 야속할 수 있다는 것을 알아주세요.

그리고 디자의 경우 일을 하는 목적을 다시 한번 생각해줬으면 좋겠어요. 목적이 예쁜 디자인 결과물을 만들어 내는 것이라면 디자의 장인 정신은 길이길이 물려주어야 할 인류의 재산이죠. 근데 우리의 목적은 사용자에게 유용한 웹 서비스를 기한 안에 만들어 내는 것이거든요. 목적 달성을 위해서 좀 서로서로 물러날 줄도 알아야 하지 않을까요? 협업이라는 게 이런걸 잘해야 원활하게 이루어진다고 생각해요.


질문: 워워.. 갑자기 난입하시다니..

개돌:
네 그 부분 대단히 불만이실거라고 생각해요. 그 이유에 대해서 말씀드릴께요.
개발자들이 처음에 얘기를 못하는 이유는 고려해야 할 사항들이 너무 많아서 파악이 덜 되었기 때문이에요. 그리고 대다수의 프로젝트들은 초기에 개발자들에게 충분한 정보를 제공해주지 못한다는 것도 한 원인이죠. 심지어 중간에 바뀌기까지 하거든요. 그리고 앞서 인터뷰에서도 비슷한 얘길 했는데 어떻게 진행할지 혼자서 다 파악한다는 것도 불가능해요. 기술적으로 가능한지 불가능한지부터 시작해서 기존의 다른 시스템에 영향은 없는지, 현재 리소스를 가지고 일정 안에 개발이 가능한지 등등 코드를 만들기도 전에 고려해야 할 사항들은 넘쳐나거든요. 그래서 프로젝트 중간에 새로운 사실(저는 암초라고 표현하죠)이 나타나면 고칠 수 밖에 없어요.

디자인 하시는 분들은 평면 위에 있는 하나하나의 점들(픽셀들)이 모두 제어 가능하잖아요. 원하는 것이 있으면? 그려내면 되구요. 하지만 개발은 그렇게 하나하나 다 만들 수 없습니다. 가능하지도 않을 뿐더러 그랬다간 일정을 맞출 수도 없구요. 아까도 얘기했다시피 개발은 만들어진 것 위에서 또 다른 것을 만들어 가는 과정의 연속이고, 이 과정의 결과물들은 한정적인 제어점을 가질 수 밖에 없기 때문이죠.

질문: 그럼 사전에 꼼꼼히 좀 체크하시면 안되나요?

개돌:
사전에 꼼꼼히 체크하려고 노력하죠. 근데 저도 인간인지라 완벽하게 체크한다는 건 불가능에 가까워요. 중간에 수정사항이 생기는 것에 대해서는 기계와 일하는 것이 아닌 사람과 일하는 것이니 이해해주셨으면 좋겠어요.

질문: 본인은 중간에 수정 사항이 생기면 짜증내지 않아요?

개돌:
(뜨끔) 안그러도록 노력하겠습니다. (__)

/**
 * 이 클래스는 이런 일도 하구요 저런 일도 해요. 그리고 할 말이 좀 있는데염. 와하하;
 * 줄을 바꿔서 적어도 한줄로 모두 나오구요. 줄 바꿈을 하고 싶으면 html 태그인 p 태그를 이용
 * 하면 되요.
 * <p>이렇게요.</p>
 * <p>근데 class 요약으로 볼 때는 맨 첫줄의 마침표까지만 코멘트가 나온답니다. 여기
 * 예제에서는 '이 클래스는 이런 일도 하구요 저런 일도 해요." 까지지요.</p>
 * <p>'그리고 할 말이 좀 있는데염. 와하하;' 부터는 class 상세 페이지로 가야만 보이지요</p>
 */
class SomeClass {

    /**
     * 이 메소드는 뭔가 일을 해염.
     * 뭐하는지 궁금하죠? 근데 이게 다 문서에 남는다고 생각하니 쑥스럽네요.
     *
     * @param1 아무 값이나 주면 되염
     * @param2 아무 값이나 주면 안되염
     * @return param1과 param2 를 가지고 이상한 Canvas 를 만들어서 리턴해주지요.
     *
     * @see FlexEvent.CREATION_COMPLETE
     */
    public function doSomething(param1:uint, param2:uint): Canvas {
        ...
        return canvas;
    }
}

-doc-classes "AClass,BClass,CClass"