올해의 평가시즌은 작년에 비해서 좀 더 빨리 찾아왔다.
12월안에 다 해치우고 내년 1월에 월급인상, 인센티브 등등을 다 처리하겠다는 의지이다.
나는.. 평가시즌이 참 싫다.
결과가 좋던 나쁘게 나오던 편하게 이 기간을 보낸 적이 없기때문이다.
보기와 다르게!!!!! 예민하고 섬세한 부분이 있는데 이게 꼭 평가시즌때 발동이 되어서
눕자마자 30초안에 잠드는 내가!!! 잠을 못 이루는 때도 있으니..
지금 회사전까지는 평가라는 것이 사실상 없었다.
제대로 된 평가(?)를 받고 이에 따른 연봉인상과 인센티브가 결정되는 메카니즘을 경험해 본것이 4번정도 뿐이라
내가 숙달이 덜 된것도 있지만 평소에는 무섭다라는 생각이 안들다가.. 평가시즌이 되면
우리 회사도 참 무서운 곳이구나.. 라는 생각이 든다.
그동안의 경험으로 터득한것은 평가라는 것은 절대적으로 주관적이라는 것!!!이다.
흔히들 지표라는 것으로 이야기를 해야 한다고 한다.
하지만 매출/비용 .. 등 돈과 직접적인 영향이 있는 소수의 부서를 제외하고는 지표로 성과를 이야기하는 것은 참 어렵다.
어떻게든 지표를 만들었다.
프로젝트 기간을 2개월에서 1.5개월로 줄여서 기간을 단축한 것을 지표로 이야기하였다.
하지만 평가자가 그것은 의미가 없다!! 라고 하거나
너의 능력은 그 이상이니 이것을 하는 것은 당연하다! 라고 이야기 하면 애써 만든 지표는 바로 물거품이다.
회사 전체에서 공식화되어 있는 지표가 없는 이상 평가자의 주관적인 시각안에서 벗어날 수 없다.
이런 말도 안되는 지표를 만든다고 머리 아퍼하지 말고
차라리 평가자(주로 팀장이 되겠지만)와 편한 관계를 만드는 것에 초점을 맞춰야 한다.
이미 불편한 관계이다.. 단기간에 쉽게 회복될 상태가 아니다라고 하면 평가는 포기해야 한다.
평가를 위해서 싸우고 결국 합의를 이뤄내지 못해서 실장이나 평가위원회까지 올라가게 되고
어떻게는 약간은 좋게 평가를 올릴수 있겠지만 이를 평가자가 마음에 담아두는 순간!!
내년에는 더 힘든 싸움을 해야 할지도 모른다.
평가는 주는 데로 받고
그동안 개인적으로 섭섭했던 부분이나 아쉬운 부분을 잘 돌려서 이야기해보자.
평가시즌이라는 것은 그래도!!! 평가자 평소보다는 귀를 열심히 열어둘려고 노력할때이니깐 효과는 더 좋다.
그리고 내년을 노려보자!!!
어제 팀장과의 면담으로 1차 평가가 마무리 되었다.
올해는 그전과 다르게 마음은 편하다.
평가가 평가자의 주관일뿐이다. 절대적인 가치는 아니니 기죽지 말자!
지금 하고 있는 일은 검색로그를 분석하는 일이다.
그동안 검색서비스를 적용만 해놓고 잘 돌아가는지만 확인하였는데
사용자들이 어떻게 검색을 하는지, 통계적인 정보를 한번 추려볼 필요가 있을것 같아서 진행중이다.
로그파일을 열어봤는데.. 오... 생각보다 로그가 많다. 하루에 30만건정도 요청이 들어온다.
검색조회와 검색색인을 분리하고 조회는 키워드를 뽑아서 상위랭킹을 만들고.. 등등
로그파일을 분석하는 부분은 금방 만들었다.
사건이 발생하는 것은 이 로그파일을 분석한 원천데이터를 저장하는 부분에서 시작되었다.
요즘 팀장님이 RDBMS를 버리는 일이 심취해계신다.
"
해외에서는 요즘 RDBMS를 대체할 무언가를 찾는 활동이 활발합니다.
그동안 우리가 습관적으로 Repository는 Database 라고 인식하고 써왔는데..
사실은 MongoDB나 CouchDB같은 Document기반도 있고, Memory기반도 있고,
File-Memory 동시에 활용하는 하이브리드도 나오고 있습니다.
"
라는 말로 나를 꼬셔서 데이터를 저장하는 것을 MongoDB를 써보자고 하셨다.
검색로그 분석을 자동적으로 할 예정이긴 하지만 지금 만드는 프로그램은 사업파트에서 어떤 식의 데이터를 보고 싶은지
느낌이 없다고 해서 일종의 프로토타입으로 만들고 기획이슈를 다 정리한 후에 추가 개발할 생각이고
이때 운영을 위해서 저장매체를 결정해도 되는데.. 지금 일은 그냥 하기 위해서...
oracle을 쓰게 되면 하루안에 되는 일이었는데.. 어째튼 MongoDB라는 놈을 써보게 되었다.
팀장님이 그 전에 MongoDB를 써봤는데..
다 된다(정말.. 다 된다고 했다.. ㅠㅜ)라고 해서 편한 마음으로 시작했는데 ㅠㅜ
정말 오랜만에 해보는 한글자 변경하고 돌려보고 한글자 변경하고 돌려보는 코딩을 하고 있다.
우선 30만건의 데이터를 넣는데도 10분정도 걸렸다.
oracle에는 sql loader를 통해서 파일로 떨구고 1분안에 올릴수 있는데.. 라는 생각을 하긴 하지만.. 어째튼 참을만하다
하지만..
통계정보의 핵심상 sum과 group by 가 필수이다.
MongoDB에도 group by가 있기는 하지만 ruby 언어를 위해서는 어떻게 써야 하는지 도대체 모르겠다.
ruby API를 봤지만 예제가 없어서 어떻게 써야 잘 모르겠다. 구글을 뒤져보는데도 거의 없다.
그래서 하나씩 해보고 돌려보고 해보고 돌려보고.. 진짜 -_-;;; 눈감고 코딩질하고 있었다.
ruby source 코드를 열어서 이놈이 어떻게 동작하는지를 보고 거꾸로 parameter를 예측해서 해보고 있다. ㅠ
이런 닭질을 2~3일째.. 결국 group by를 성공하였다.
all = coll.group( [:qtime] ,
{:qkind => 'GET'},
{'count' => 0 },
"function (obj, prev) { prev.count = prev.count + 1; }" , false)
그런데.. 제길.. group by 하는 부분에 한글이 있으니깐 안된다.. ㅠㅜ
데이터를 euc-kr로 변경해서 저장하였는데 넣고 빼기까지는 되는데 group by 할때 안된다. utf-8로 해야 하나?
아우.. 30만건을 시간대별로 group by해서 코드에 있는것처럼 카운팅만 하는데 시간이 한참 걸린다. 5~6분정도.. 제길!!!!!
새로운 기술이 좋기는 하지만
서비스에 쓸만큼 다듬기 위해서는 얼마나 더 구글을 파고 닭질을 해야 할지 모르겠다.
이런 시간들이 나만의 노하우를 가질수 있는 소중한 시간들이겠지만..
이 소중한 시간의 학습은 주로 내가 하는구나.. 난 모자른 놈인가보다 ㅠ
어제 와우 계정이 만료되어서 3개월을 더 결제하였다.
휴.. 잠시 내 결제리스트를 보았는데.. 참 많이도 하였네..오베때부터 지금까지..
3번의 서버이동으로 지금 레인서버에 정착을 하였다.
회사 동료들과 그리고 그 동료들의 와이프, 친구, 처남.. 등등의 점조직으로 이루어진 길드생활
소수정예로 10명을 모아서 10인파티 가기 힘들지만 그래도.. ^^ 오프모임도 해서인지 친밀도는 높다.
만랩 캐릭터는 3개... 술사, 전사, 흑마
와우를 한 시간에 비해서는 많지 않는 숫자이다.
얼마전까진 1개 캐릭을 돌리기도 벅차서 전사에만 올인하고 있었는데
이제 여유가 좀 생겨서 술사와 흑마도 좀 돌리기 시작하고.. 쪼랩 사제도 손을 대고 있다
(5년동안 사제는 처음 키워보는데..쪼랩 사제가 키우기 제일 힘들다.. 내 장담한다!!!)
와우의 가난은 나랏님도 구제 못한다고.. 정말 난 거지다 ㅠㅜ..
순간 순간 현질을 통해서 골드를 채워보겠다는 생각은 자주 하지만 결국 하지 않는다..
전사 만랩때 아는 형이 준 3만골드로 실컷 기분 내본 것이 마지막이고 지금은 5000~6000골드 수준을 유지하고 있다.
자산상태는 거의 비슷한 수준이면서 템은 1~2개씩 맞춰가는 것을 보니.. 이게 세상 돌아가는 방식 아니겠는가..
전사 캐릭은 꽤 많이 맞췄다.
방어/딜러 9티어2 4셋까지 맞췄고 다른 템들도 거의 245레벨이다.
딜무기만 245나 232로 하나 구하면 십자군25인 하드도 편하게 갈수 있는데...
(한번 가봤는데.. 나쁘지 않다.. 1네임드 전체 디피가 6200나오는것을 보니..커트라인은 통과다 ^^)
술사는 가장 먼저, 가장 오랫동안 만랩을 유지하고 있지만 한번 버림을 받아서 템 수준은 별로다
복술은 9티어2 2셋은 맞췄지만 무기도 별로이고 다른 템들도 다 별로다..
유일하게 장신구!!!! 힐러의 최고 장신구라는 위안을 얼떨껼에 2000골드에 먹고.. 도대체 줄지 않는 마나를 보면서
흠.. 역시 명성이 헛되지 않았어.. 라고 기뻐하고 있다.. (이놈 덕분에.. 죽선을 가지고 싶다라는 생각이 든다 ㅠㅠ)
십자군 10인하드를 가고 싶은데.. 술사는 딜스왑이 안되면 가기가 힘들다..
그래서 고술템을 1~2개씩 모으고 있는데 역시 무기가 문제다..
아직도 옛힐스에서 나오는 장착무기다 ㅠㅜ 제길.. 다른 부위는 가죽과 사슬로 거의 바꿔가고 있다.
아눕에서 쩌는 딜실력을 보여주기전에 3.3패치가 먼저 되겠지 ㅠㅜ
흑마는 원래 만랩일 키울 생각이 없었다.
남는 옷감을 보내서 440이 된 재봉기술과 400이었던 마부가.. 아깝고 445가 되면 심수를 뽀갤수 있는 때문에 그냥 키웠다.
이제 올에픽정도는 되어 있는데.. 미안하다..흑마야.. 골드가 없어서 널 십자군25인에는 못보내겠다. ㅠㅜ
전사는 십자군10인(거의 길팟), 10인하드(템 먹으러), 25인(골드 벌러), 25인하드(골드많은 놈들 구경하러 ㅠ)를 가고
술사는 십자군10인(무기 먹으러), 10인하드(템 먹으러), 25인(골드 벌러), 오닉, 아카본을 가고
흑마는 오닉, 아카본, 십자군 10인을 간다.
오늘같이 월요일이나 화요일쯤이 되면.. 거의 할일이 없어진다..
그래서 새롭게 쪼랩 사제를 손대기 시작해서 살~살하고 있다.
다 크고 나서 또 없는 골드때문에 고생할 생각이 달리지 못하고 있다..
이런 저런 다른 게임들도 하고 있지만 와우만한것이 없는것 같다. 종종 지겹기도 하지만.. 3.3패치를 기대해본다.
(완전체라는 단어가 아주 마음에 드는 편은 아니지만 저 단어를 대체할 만한것이
잘 생각이 나지 않아서 그대로 사용하기로 해본다.)
사례 1:
진중권씨가 3개정도의 대학에서 재임용에 실패하였다고 한다.
MB정권이 끝나기전까지는 힘들것이라고 생각하고 세부으로 가서 평소에 하고 싶었던 경비행기에 탄다고 한다
그리고 3년정도 후에 돌아와서 교수를 한다고 한다.
(관련기사)
사례 2:
어떤 기획자가 있다.
기획을 주로 하긴 하지만 사업기획을 시작으로, 서비스기획, 개발관리, 마지막 보고용 지표까지 ..
윗사람들이 보기에는 어떤 일에 대해서 이 기획자에게 시키면 다 된다고 생각한다.
자기가 일을 다 하는것이 아니겠지만 개발은 어떤 개발자가 하는것이 좋은지 리스트업을 해주고
윗사람은 자금을 지원해주고 간간히 올라오는 갈림길에서 선택만 하면 된다.
사례1의 진중권씨와 같이
지금 내가 다니는 직장을 그만두고 3년정도를 지금 하는 일과 전혀 다른 일을 하고 왔는데
과거와 거의 동일한 대우를 받으면서 똑같은 일을 할수가 있을까?
만일 이 질문에 Yes라는 대답을 할수 있다면 그대는 내가 생각하는 완전체라고 봐야 한다.
사례2에서의 기획자는
기획이라는 파트때문에 아니라 스스로 거의 완전한 상품에 가깝다.
따라서 같은 회사내에서 일을 담당할 기회가 많을 뿐만 아니라 새로운 곳(새로운 회사, 새로운 부서...)에서
이 사람을 데려가면 우선 절반이상은 일을 한거다.. 나머진 이 사람이 알아서 해줄테니깐..
내가 생각하는 완전체에 가까워질수록
회사에 대한 의존도가 낮아지고 독립성이 강해지면서 조금 더 자유롭고 편한 삶을 살것이 라는 생각을 해본다.
내가 하고 있는 개발업무는 조~금 수동적이다.
사업적인 이슈가 발생하고 기획서가 만들어지고.. 그러면 개발일을 시작한다.
물론 기획서 없이 개발을 하기도 하지만 특별한 경우이거나 개인적인 프로젝트일때가 많다.
따라서 난 아직 완전체에서 한참 멀었다.
개발에 비지니스부분을 합쳐야지만 완전체에 가까워질까?
우선 이 대답에는 당연히 Yes라고 할수 있을것이다.
전 C개발자입니다, 자바개발자입니다.. 라고 이야기 하는것보다는
전 검색개발자입니다, 빌링개발자입니다, 게임그래픽 엔진 개발자입니다.. 라고 할수 있는 사람들이
살아남기가 더 쉬울것이고 일을 할때 선택받기 더 편하다.
하지만 이것으로는 부족하다.
제일 잘나가는 검색개발자라고 해봤자 어떤 검색서비스를 만들어야 돈을 잘 벌수 있을까가 제일 먼저이고
그안에서 사용되는 기술은 그 다음이라고 볼수 있다. 나 같은 웹서비스 개발자야.. 할말 없다.
웹에 대해서는 무엇이든 만들어드립니다!!! 라고 해봤자 기획자가 어떤 기획을 해오는것인가가 더 중요하다.
개발기술을 늘 최고수준으로 유지하면서 쩌는 비지니스 마인드를 보유한다? 에효.. 잘 모르겠다..
개발을 버리고 싶지 않은데.. 개발로만 하는 방향이 있을까?
이번주 화요일 조촐한 프로젝트 종료 회식이 있었다.
그동안 내가 PM으로 진행해 오던 프로젝트이었는데
종료회식은 우리 팀(개발자)만 참석한 조촐한 회식이었다. (죽어라 술은 마셨지만 ^^)
애자일이 모토인 우리팀에서의 프로젝트는 최대한 애자일스럽게 한다.
1. 기획서 없어 사용자들의 불만사항을 듣는것으로 요구사항을 대신하고
2. 간단한 html의 prototype으로 화면 구성 및 기능에 대한 부분을 사용자에게 confirm 받고
3. prototype이 실제 완성되어 가는 모습을 계속 보여주고
4. 이슈트래커를 사용하여서 이슈사항에 대해서 잘 챙기고
5. svn을 이용한 여러 개발자들의 소스꼬임을 방지하고
6. 자신 컴퓨터의 개발환경이외에 실서버의 셋팅을 프로젝트 시작할때 해서 일일 디스트, 테스트를 통해서
실데이터에 대한 오류를 매일 점검하고
7. 매일 아침 스크럼 미팅으로 한쪽으로 일이 몰리는 것에 대해서 대처하고
나름 잘 챙기면서 멋지게 진행하였다고 하였는데
엉뚱한 곳에서 복병을 만나서 프로젝트가 종료되었음에도 종료되었다라고 이야기를 못하는 상황이 되어 버렸다.
이번 프로젝트에서 만드는 툴이 일반 사용자들이 아니라 특정 팀을 위한 운영툴이었기에
사용자의 대상이 명확해서 정확한 맞춤툴을 만들기에 충분한 환경이었다.
사용자의 불만사항이나 화면 구성, 기능에 대한 confirm을 해줄 사람으로 그 팀의 팀장을 컨택하였는데
그 팀의 팀장이 약간의 기획스킬이 있는 한 사람을 추천해서 2명을 중심으로 진행을 하고 있었다.
그런데..
그 팀의 내부에서 내분이 일어나기 시작하였다.
팀장의 추천을 받은 사람이 다른 사람들에 비해서 신삥이었고
팀장이 그 사람에 대한 특혜를 주고 있다고 생각한 팀원들이 반발하기 시작하였다.
그것에 대한 여파로 우리가 만드는 툴에 대해서 반대를 위한 반대를 하고 있다라는 느낌이
우리 개발팀에게까지 전달되었다. 그저 그들은 No! 라고 이야기할뿐이다. 왜 No!인지에 대한 생각은 없다.
결국 개발쪽과 커뮤니케이션을 하던 그 사람(특혜를 받고 있다던..)은 프로젝트가 끝나기 전에 그만두게 되었고
그 팀의 팀장도 그 일로 팀원들과의 불화가 생겨서 서로에 대한 불신이 팽배해져있다.
완성된 툴에 대해서 팀원들의 불편 사항을 받아서 마무리 작업을 해야 하는데.. 그 부분이 안되고 있다.
팀장이 보기에도 말도 안되는 불만만을 이야기 하니깐.. 진도가 안나가고
그렇다고 그냥 끝!이라고 외치기에는 나중에 진짜로 발생하는 불편사항에 대해서 자신이 곤란해지니깐
그냥 시간만 끌고 있는 상황이다.
개발팀에서는 요구사항을 다 받아서 마무리가 되었는데.
사용자쪽에서 OK! 라는 단어를 외쳐주어야 정말로 끝이 나는건데.. 시간만 지나고 있다.
우리팀에서 한가지 간과한 것이 바로 이것 Product Owner에 대한 관리였다.
불화가 생길 당시에 이 부분을 감지하였다면.... 커뮤니케이션의 채널을 그 한명이 아닌 팀으로 확대하였으면..
커뮤니케이션 채널이 바뀔것에 대한 준비를 하고 있었어야 하였는데..
개발팀안에서는 나름 잘 진행이 되었다고 판단하고 있는데
사용자의 '참 잘했어요'라는 피드백이 없는 성공한 프로젝트.. 아버지를 아버지라고 부르지 못하는 프로젝트가 되어버렸다.
대학교때까지 내 주머니안에는 동전이 거의 없었습니다.
맨날 학교 땡~ 하면 오락실로 달려가서 주머니안의 동전을 탈탈 털어서 정리하곤 하였습니다.
동네 오락실이 거의 없어지고 나도 점차 PC게임으로 건너오면서부터
언제 어디서 만들어진지 모르는 동전때문에 너무 고생중입니다.
그동안은 저금통을 만들어서 꽉꽉 채우면서 기뻐하였는데
저금통을 다 채우고 동전을 지폐로 바꾸기 위해 은행에 갔다가 고생(일주일에 하루만 변경합니다 -_-;; 짜증나)을
한번 하고 나서는 그냥 책상위의 한편에 버려두기 시작하였는데... 이제는 감당하기 힘든 수준까지 되었습니다.
최대한 동전의 생산을 적게 하기 위해서 택시타고 남은 잔돈 같은 경우는 기사님을 드리는 방법까지도 쓰지만
그래도 급격히 늘어나는 동전의 속도를 줄일뿐 줄어들지는 않습니다.
그러다가 생각한 방법 한가지!!
늘 900원의 동전 5개를 들고 다닙니다. 500원짜리 1개, 100원짜리 4개
주머니에서 짤랑 거리는 동전이 싫어서 동전을 적게 생산하기 위해서 최소한의 동전을 가지는 거죠
참 아이러니 합니다. 동전을 막기 위해서 동전을 쓰는 형태인거죠..
세상을 살다가 보면 이런 방법이 유용해질때가 많습니다. 이이제이(以夷制夷)
오늘 제가 참 일하기가 싫은가봅니다. ^^
jEditable은 jQuery의 플러그인 중에 한개이다.
웹화면에서 특별한 변경없이 특정한 부분(예를 들어서 table 필드중에 한개..)을
클릭, 더블클릭, ..(이벤트를 정할수 있다) 등을 해서 input 태크(text field, select box..)로 바꾸고
데이터 1개만을 수정하도록 하는 플러그인이다.
간단히 사용하는 코드를 보자.
<span id="phone" class="dblclick" style="display: inline"><%= @zeous.phone %></span>
html 코드에 class에 특정 키워드(dblclick)을 넣어두고
jQeuery 코드에서는 아래와 같이 저 부분을 잡아낸다
$(function(){
$('.dblclick').editable("/zeous/update", {
indicator: "<img src='/images/ajax-loader.gif'>",
tooltip: "더블클릭 하시면 수정하실 수 있습니다.",
event: "dblclick",
type: "text",
name: "inline_value",
id: "key",
width: 150,
style: "inherit",
submitdata: {id: "<%= @zeous.pcb_id %>", authenticity_token : "<%= form_authenticity_token %>"}
});
});
보내는 주소는 /zeous/update 이고
span 영역을 마우스 왼쪽의 더블클릭 하면 text 로 화면이 바뀌게 되고 submitdata에 text에서 받는것 이외의 데이터를
넘겨줄수 있도록 한다.. (기본적으로 <%= javascript_include_tag "jquery.jeditable" %> 가 있어야 한다)
여기까지가 jEditable의 기본적인 사용방법이다. rails 코드이지만 보기에 큰 무리가 없을것이다.
그런데 jEditable의 기본기능을 사용하였을때
주민번호와 같은 데이터의 중복체크를 어떻게 해야 할것인가.. 사용자에게 alert창으로 보여주고
변경한 데이터를 원래의 데이터로 돌려놓는 정도만 구현하면 될듯한데..
처음에 고민한 방법은 ajax 호출 자체를 실패로 만드는 것이다.
500에러나 기타 에러를 발생시키는 방법인데.. 약간 마음에 안든다.. 에러는 아니자나.. 다만 중복일뿐이지..
설마 이런 고민을 나만 하였을까.. 하고 찾아보니..역시나 있다.
댓글의 맨 마지막에 보면 아래와 같은 코드가 있다.. 누가 구현해놓은 것이다. jQuery의 ajax 호출을 이용하여서
$('.edit').editable(function(value, settings){
$.ajax({
type: 'POST',
url: 'save.html',
async: false,
success: function(data){
if (/ErRoR:/.test(data))
{
data = data.replace(/ErRoR:/g, '');
alert(data + ' Could not save data.');
//Back to edit
}
}
});
return(value);
}, {
indicator : 'Saving...',
width : '170px',
cssclass : 'inlineEdit',
cancel : 'Cancel',
submit : '<br><input type="button" value="Save">',
});
$.ajax({
type: 'POST',
url: 'save.html',
async: false,
success: function(data){
if (/ErRoR:/.test(data))
{
data = data.replace(/ErRoR:/g, '');
alert(data + ' Could not save data.');
//Back to edit
}
}
});
return(value);
}, {
indicator : 'Saving...',
width : '170px',
cssclass : 'inlineEdit',
cancel : 'Cancel',
submit : '<br><input type="button" value="Save">',
});
서버쪽은 이렇게...
render :text => "ErRoR:"+old_data, :layout => false
서버쪽에서 return 해주는 text 중에 앞부분을 ErRoR로 주고 화면 단에서 그것을 처리 하는 방법이다.
그런데 위의 코드의 단점은.. 화면의 텍스트가 원래의 데이터로 돌아와야 하는데. 새롭게 입력된 데이터로 변경된다는 것이다.
그래서 위의 코드를 참고해서 새롭게 변경한 코드는
$(".masked_duplicate").editable(function(value, settings) {
var t_data = value;
$.ajax({
type: 'POST',
url: '/zeous/update',
async: false,
data: {inline_value: value, key: $(this).attr("id"), id: "<%= @zeous.pcb_id %>", authenticity_token : "<%= form_authenticity_token %>", is_duplicate: "true"},
success: function(data)
{
if (/ErRoR:/.test(data))
{
data = data.replace(/ErRoR:/g, '');
alert(value + ' 는 중복된 데이터 입니다.');
t_data = data;
}
}
});
return(t_data);
}
ajax 콜하기전에 데이터를 미리 저장해놨다가 실패시에는 과거 데이터로 return 한다. (서버쪽 코드는 동일하다)
so Cool~ 마음에 든다 ^^
나에게 게임이란 생활에서 받는 스트레스를 날려버리는 필수항목이다!!!
프로젝트가 막바지에 다다르고 있다.
회사 생활이나 프로젝트를 진행하는 것이 스트레스가 없지는 않지만
마지막에 오면서 그 강도 기하급수적으로 늘어나고 있다.
한달 전쯤 회사 컴퓨터가 슬슬 느려지고 netbeans에 코딩을 위한 타이핑이
내가 키보드에 치는것과 화면에 보이는것이 3초정도 시간차를 보여주는 등등 최악으로 가고 있어서
프로젝트의 중간에 부담감이 없지는 않았지만 XP에서 VISTA로 갈아탔다.
이때!!! 프로젝트가 끝날때까지는 회사 컴퓨터에 게임을 설치 하지 않으리라.. 라는 굳은 결심까지..
회사에서의 게임이야..그렇게 많이 하는 편은 아니었다.
점심 먹고 옆팀 사람들과 함께.. 아바 한두판정도..
저녁 먹고 퇴근을 기념하는 wow 보석 일일 퀘스트 정도..
정말 짜증나는 사건&사고가 발생하였을때... 업무시간에 머리를 식히고 짜증을 덜어내기 위한 정도...
가볍게 하는 정도이니깐.. 안해도 괜찮겠지.. 라고 아직도!! 버티고 있지만.. 그 후유증까지는 예측을 못하였다.
어제같은 짜증나는 IE 버그를 만나고 (물론 해결은 하였지만..)
이런 일에 저런일에 치이고, 이런 니미.. 저런 니미 같은 사람들에게 당하고 난것에 대한 풀수 있는 방법이
회사에서는 없다는 것이 문제였다.
책을 보거나 웹서핑을 좀 하면 되겠지..라는 생각은 그 정도의 흥분, 짜증상태에서는 그것도 다 무용지물이었다.
이때는!!!! 정말.. 게임이 필요하다.. 그것도 일반적으로 하던 방식이 아니라..
워3라고 하면 오크로 선택해서 블마로 실컷 견제해주고 와이번을 끝까지 모아서 한번에 확~ 밀어버리는,
또는 휴먼을 선택해서 패멀을 하고 그리폰으로 휩쓸어 주던지..
아바라고 하면 산탄 총을 들고.. 적진으로 달린다.. 중간에 죽는것은 상관없다..
한번에.. 3~4명을 펑펑 잡아주고 적 베이스 뒤쪽에서 술래잡기 하면서 1~2명 더 잡아주면..
와우라고 하면 딜전사로..(탱은 안된다.. 답답한 딜러 보면 짜증이 가중된다 -_-;;;)
5인파티(이 이상은 안된다.. 나보다 더 잘하는 사람이 많다..ㅠㅜ)로 쩌는 딜로 40%이상에 데미지를 해주고
나머지 딜러들에게 썩소를 한번 날려주어야..
기분이 좀 풀린다. 정말 심할때는 저 3개를 다 해줘야만 한다..
마음은 그렇지만.. 회사에서는 안된다.. ㅠㅜ
옆팀 아바하는 것을 구경하거나.. 다른 사람 와우질을 구경만 하고 있다.. 아우..
그리고 퇴근하고 운동을 마치고 게임방으로 달려간다.. 시간이 부족하다.. 달려줘야 한다..라는 강박관념에 더 심하게 하고 있다.
밥도 끼니를 맞춰서 먹으면 적정한 양을 조절할 수 있지만 배가 고프면 그런거 다 잊고 평소보다 훨씬 더 많이 먹는것처럼
퇴근후에 게임을 더 탐닉하는 것 같다..
아.. 그동안에 해오던 가볍게 게임을 해주는 것이 얼마나 나에게 큰 역할을 해주고 있었는지 새삼 느끼고 있다.
ps. 회사 업무시간에 게임을 하는 것이 얼마나!! 중요한지에 대한 글은 아닙니다 ㅠ
ps. 비스타에서 아바를 설치하다가 블루 스크린을 만났다.. ㅠㅜ 제길 프로젝트가 막판이라..
불안해서 설치를 뒤로 미룬다.
(끝까지 읽어보서야 합니다)
인스턴스 변수(instance variable)
루비나 레일스에서 흔히 사용하는 개별 객체(클래스 인스턴스)에 종속되는 변수이다.
(잘 정리된 정의는 여기를 ^^)
루비보다는 레일스에서는 controller와 view의 데이터 전달을
이 인스턴스 변수로 하기 때문에 그 활용도가 엄청나게 높다.
-- controller
class zeousController
def index
@name = 'zeous'
end
end
-- view
<%= @name %>
이 정도까지는 레일스 프로그래밍을 해본 사람이라고 하면 그냥 알수 있는 부분이었고
내가 어제까지 알고 있는 내용이었다.
오늘 새롭게 안 내용은
-- controller
class zeousController
def index
@name ='zeous'
print_name
end
def print_name
puts @name
end
end
-- view
<%= @name %>
이렇게 하면 print_name에서 zeous가 제대로 찍힌다는 것이다!!!!
정의를 다시 생각해보자.. 개별 객체에 종속이 되는 변수...
이렇게 동작하는 것과 정의가 일맥상통하는데.. 난 왜 몰랐을까.. ㅠㅜ
rails에서는 1개의 request에 대해서 thread 형태로 서버에서 동작할테고
아마도 controller를 new해서 쓸테니깐.. 그 안에서는 모두 공유가 가능해지는 형태가 되는것이다.
view에서는 루비에서 다른 클래스의 인스턴스 변수를 참조하는 방법을 바탕으로 접근하는 형태일것이다..
흠.. 원인과 결과, 시작과 끝이 명쾌하게 연결이 되는데.. 왜 그동안은 이렇게 생각을 못한것이지.. ㅠㅜ
에효.. 니가 아는게 머냐.. ㅠㅜ
=========================================================================================================
트랙백에서 허진영님이 알려주신 것을 바탕으로.. 다시 한번 생각, 정리, 찾아보기, 공부를 한 반성문입니다.
결론은 자바이건, 루비이건.. 제가 제대로 알고 있었던것이 한~개도 없었다는 생각이 들면서 참 쪽팔리지만
그래도 이렇게 반성문이라도 써야 할것 같아서 다시 글을 씁니다.
1. rails는 싱글 스레드입니다.
그냥 아무생각 없이 당연히 멀티이겠지.. 라는 생각으로 들어갔는데.. 아니네요..
회사에서 실서비스하고 있는 몇개의 시스템도 다시 생각해보니 lighttp나 fcgi를 통해서 3~5개를 띄워놓고 하고 있습니다.
그 이유가 레일스가 단일스레드의 형태이기때문에 이러한 형태로 운영하고 있었습니다.
2. 자바이건 루비이건 변수종류는 동일하다.
루비에 대해서 이상하다고 느낀것이 자바쪽에서는 이런 것이 없었다라고 생각해서 그렇게 느낀것이었습니다.
자바쪽을 살펴보니..아니었네요.. 자바이건 루비이건 동일한 형태이고.. 이름도 같았네요..
루비
class BaboZeous
@@zeous1 = '1' : 클래스변수
KINGORI = 10 : 상수
def beBabo
@zeous2 = '2' : 인스턴스변수
zeous3 = 3 : 지역변수
end
end
자바
public class BaboZeous
{
private String zeous2 = "2"; : 인스턴스변수
public static String zeous1 = "1"; : 클래스변수
public static final int KINGORI = 10 : 상수
public void beBabo()
{
int zeous3 = 3; : 지역변수
}
}
루비는 동적인 언어이기때문에 인스턴스변수의 선언 위치가 자유롭다. 하지만 변수의 생명주기는 자바와 동일하다.
3. 창피하다.
가장 기초중의 기초이면서 상식으로 알아야 하는 변수 선언과 생명주기를 엉터리로 생각하고 있었다니..
물론 추석 연휴 다음날이라 아무 생각 없었다라고 하기에는 너무 바보 같았습니다.. 앞으로 공부 열심히 하겠습니다. ㅠ
지금 하고 있는 프로젝트는 ruby on rails로 하고 있다.
기본적으로 prototype.js가 기본으로 설치가 되고
그동안 prototype.js로 ajax나 기타 기능들을 사용하고 있었다.
(사실.. 기타 기능은 거의 쓰지 않고 순수한 자바스크립트만을 쓰고 있었다..)
이번 프로젝트에서는 JQuery를 한번 써보기로 하였다. 충실하게...
JQuery로 스터디를 막.. 시작하는 것도 한몫하였지만...
우선 확 JQuery에 호감을 가지도록 한것은 플러그인이 정말 다양하고 마음에 드는것이 많다.
그중에 지금 프로젝트에서 쓰고 있으면서 효과를 톡톡히 보고 있는것이 inline edit 이다
예를 들어서 개인정보를 보고 수정을 하려고 하는데
나는 새로 바뀐 전화번호만을 바꾸고 싶은데 기존에는 전체 정보를 수정 form으로 바꾸고 전화번호를 수정하였는데
view 화면에서 바꾸고 싶은 부분을 클릭, 더블클릭, 마우스 오버등의 이벤트를 통해서 변경하고 바꾸는 것이다.
그리고!!!! 해당 화면의 reload가 없어서.. 서버의 부하도 줄일수 있다.
지금 프로젝트의 특성상 메인화면에 많은 기능들이 있기에 수정할때마다 메인화면을 reload하면
이런 저런 비용이 많이 들텐데... 그것을 확!!! 줄일수 있다.
inline edit에서 약간 부족한 기능(변경되는 정보의 중복체크..등)은 구글링해서..
얻은 정보에 내가 또 수정해서 쓰는등..(이건 다음에 포스팅하겠다) 정말 활용도 100%로 잘 써먹고 있다.
그리고 그동안의 피곤한 자바스크립트 코딩의 패러다임을 완전히 바꾸고 있다. ^^
물론 이렇게 바꾸기 위해서 부족한 지식의 짜맞추기가 힘들지만.. JQuery의 스터디가 끝나고 프로젝트가 끝나고
다음 프로젝트부터는 정말로 깔끔한 코드로 만들수 있을것이다.. (흠.. 너무 심한 구라인가? ^^)
몇개의 코드를 공유해보자면..
check box가 여러개 있을때 전체 체크를 하려면?
$('#selected_games > input:checkbox:not(checked)').attr('checked', 'checked');
select box를 textarea처럼 펼쳐놓고 내용(option)을 맨 마지막에 추가, 선택된 부분을 삭제하려면?
<select id='total' multiple><option>.... </option></select> 일때
추가는
var op_size = $('#total > option').size();
$('#total')[0].options[op_size] = new Option;
$('#total>option:eq('+op_size+')').attr({value:'새로운값',text:'새로운값'});
선택된것의 삭제는
var selected_index = $('#total > option').index($('#total > option:selected'));
$('#total')[0].options[selected_index] = null;
아.. 꼴랑 2~3줄로 완성이 되다니..
물론 아직 공부를 덜해서.. 더 깔끔한 방법이 있는지 모르겠지만.. 이정도로도 충분히 만족스럽다..
약간 힘든것은 에러가 발생하였을때 JQuery가 자체적으로 이것을 먹어버려서.. 디버깅이 힘들긴 하지만
어느정도 숙달이 되고 완성된 단계로 올라서게 되면 초강력, 깔끔한 자바스크립트의 코드들이 되지 않을까..
사랑해요~ JQuery
