'코딩호러가 들려주는 진짜 소프트웨어 개발 이야기' 책의 저자님께서
유일하게 추천하는 자기계발 서적이라 읽어 봤다.
교보문고 자료 보니 09년도 출간되서 베스트도서로 추천받은 책이라고 한다.
뭐 어쨌든 요즘 너무 개발자 위주 서적만 보는 것 같아서
방향을 조금 바꿔봤다.
저자인 리처드 와이즈먼은 심리학자이고 책도 여러권 내서 꽤 유명세를 탄 듯한 분이다.
300쪽 조금 넘는 책에 10장으로 구성되어 있다.
은근 두꺼워서 솔직히 읽기도 전에 조금 부담 ㅡ_ㅡ....
제프 엣우드가 이 도서를 추천한 이유는
자기 잘난 듯이 이래저래 충고하는, 쓰레기같은 자기계발서가 아닌
여러 실험 과정을 통해서 과학적으로 쓰였다는 이유로 추천했다.
그래서인지 줄곧 내용이 실험에 대한 설명과 결과, 그리고 결론.
이렇게 구성되어 있다.
그런데 여기서 약간 고민을 했었어야 하는게.....
대부분 미국인들을 대상으로 실험을 했을테니
한국인으로서 조금 결론에 대해서 공감하기 어려웠던 것도 있고,
아니면 이 책의 원서가 쓰였을 당시에는 신선했을 결론일지도 모르나
내가 지금 읽을 시점에서는 너무나도 당연한 이야기 아닌가 싶은 내용들이 많았다.
......그래서 좀 이 책은 대충 읽었다. 게다가..
이책말고도 다른 책들도 읽어야 될 게 많은지라 (코딩 호러의 이펙티브 프로그래밍, Head First Design Pattern)
조금 조급한 마음에 빨리 헤치워버리자라는 마음이 나도 모르게 나왔다 보다.
그래도 리뷰는 남기고 싶으니 간단하게라도 적겠다.
1장. 내편 만들기 : 면접, 협상, 부탁에 관한 상식 밖의 실험
- 이 장에서 가장 기억에 남는 건 뒷담화에 대한 이야기.
보통 나의 경우 사람의 뒷담화를 잘 하는 편인데...
일단 나는 뒷담화가 무조건 나쁘다고 생각하지 않는다.
뒷담화 만큼 사람을 친밀한 관계로 만들어 주는 요소는 많다고 생각하지 않으니까 ㅡ_ㅡ.....
근데 여기서 다른 사람에 대해 하는 이야기는 모두 자신에게 되돌아온다(혹은 전이된다)라는
이야기를 듣고 조금 오싹했다 ㅋㅋㅋㅋㅋㅋㅋㅋ
보통 부정적인 이야기를 많이 하는 편이라 타인도 헐뜯은 사람 뿐만 아니라
나도 부정적으로 본다는 생각에 께름칙한 마음이 확 피어났다..
이제는 자리에 없는 누군가의 이야기를 할 때... 긍정적인 이야기만 하는 게 좋겠다.
누구나 그렇겠지만 다른 사람이 나를 부정적으로 본다는 것만큼은 피하고 싶으니까.
- 최소한의 호의, 최대의 효과
나는 워낙 힘든 유년시절(?)을 보내왔기 때문에 남에게 베푸는 것에는 짠 편이다.
베풀어 주고 싶어도 베풀 능력이 안 되기에... 짜다.
근데 이게 만성이 되다보니 돈이 있어도 쓰고 싶다는 마음만 있지
행동으로는 꽤나 절제한다. 좋게보면 절약이겠지만 남에게 베푸는 것에 짜다는 건
절약과는 전혀 다른 얘기라는 걸 인정하기에... 조금 반성하게 됐다.
지금은 누군가에게 물질적으로 베푸는 건 힘들지 몰라도.. 적어도 마음만으로도
충분히 베푸는 게 가능함에도 불구하고 못 본체 하지는 말자는 생각을 하게 됐다.
2장. 목표 달성의 요술램프 : 소원을 말해도 이루어지지 않을 때
- 장밋빛 미래의 함정, 이중 사고 활용하기
이 책의 특징이 잘 나타나는 장.
기존의 우리가 자주 듣고 익숙해져버린 고정 관념? 에 대해서 의심을 품어
실제로 실험에 보고 그건 사실과 다르고, 실제로는 이렇다! 라는 전개.
그저 장밋빛 미래만을 보지 말고!
그 미래가 무엇이고 그것을 달성하기 위해 어떤 세부 목표가 필요한지
구체적으로 정리해서 실현해 나가는 게 짱이다..............
조금더 추가하자면
환상+현실 모두 생각하는 이중 사고 기법을 활용하는 사람이 성공할 확률이 높다고 한다.
목표 달성이 가져다줄 혜택(환상) + 도중에 마주칠지도 모르는 문제에 대한 현실적 평가(현실)
이 균형을 잘 잡는 게 중요하다는 점.
너무나 당연한 이야기다. 하지만 난 알면서도 이를 실천하지 않는다.
왜 그럴까. 뻔뻔하지만 난 그 이유도 안다 ㅋ
귀찮으니까 + 어떤 목표를 설정해야 될지 잘 모르겠다, 확신이 없다 + 어물어물 + 우유부단? + 은근 겁많음
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ 진짜 짜증난다 나한테 ㅋㅋ
- 미적거림, 차이가르니크 효과
'시작이 반이다'....................
이 말에 격하게 공감한다. 난 한번 시작하면 끝을 봐야 되는 인간인데
문제는 시작조차 하는 걸 굉장히 부담스러워한다...........ㅠ_ㅠ
3장. 창조성은 어디에서 오는가 : 브레인스토밍의 신화 탈출하기
- 브레인스토밍... 다수의 사람들이 머리를 맞댄다고 해서 그게 무조건 좋을까?
에 대한 의심으로 시작한다 ㅋㅋㅋ 결과는 당연히 아니다.
오히려 사람이 많기에 시간과 행동을 위한 에너지 투자에 대해 동기부여를 반감시키고,
기존의 틀 안에서 사고하는 경향이 더 강해진다고 한다.
하지만 그렇다고 해서 '혼자 조용히 생각하는 게 낫다'라고 말하는 건 아니라는 점.
- 딴 생각이 아이디어를 만든다
해결해야 하는 어떤 문제가 있다면 우선 그 문제에 대해 확실히 인식을 한 다음,
그 생각을 잠시 접고 다른 일에 집중을 한다.
(예를 들어 십자말 풀이, 스도쿠 풀이 등 짧은 시간에 집중할 수 있는 다른 일)
이렇게 다른 일에 집중하는 동안에 내 무의식은 앞에 인식했던 문제에 대한 해결을 위해 일하게(?) 된다고 한다.
다른 일에 집중하는 시간이 끝나고나서 다시 실제 문제에 대한 해결책을 생각하는 게
좀더 혁신적인 사고를 할 수 있다는 결과였다.
기존의 우리는 오히려 스트레스 받는 문제가 있으면 마음을 편안히 비우고
생각하는 게 좋다고 생각하는 경향이 있다.
하지만 이것과 다르게 딴 생각...하는 방법도 있다는 이야기.
타인이 딴 생각한다고 화내지말자.
- 창조성을 자극하는 환경 만들기
초록색 환경(식물, 컬러 등), 현대 미술 작품 걸어놓기, 새 얼굴 효과 등
○○○○○ ▲▲▲▲▲
○○○●○ ▲▲▲▲▲
○○○○○ ▲△▲▲▲
4장. 유혹의 기술 : 매력적인 사람들은 무엇이 다를까
- 뭔가... 이 장을 읽으면 진짜 웃기다.
무슨....연애의 비법 전수(?) 이런 듯한 내용이라 ㅋㅋㅋㅋㅋ
유치한 느낌에 딱히 리뷰남길 것도 없다고 생각된다.
5장. 안티-스트레스 라이프 : 분노와 불안을 잠재우는 특별한 방법
- 불쾌한 경험의 긍정적인 측면 생각하기
...나는 긍정이라는 단어와 좀 거리가 먼 편이지만 가까워지고 싶어 한다.
그래서 책에 적혀있는 내용을 조금 가져오겠다. 긍정이 이런 거구나 라는 느낌을 받기 위해 ㅋ
그 사건을 통해서 나는...
* 그동안 알지 못했던 나의 강한 면을 알게되었다 or 내 삶에 대해 모르고 있던 측면을 알게 되었다.
* 더 현명해지거나 어떤 사람과 관계가 더 좋아졌다.
* 감정을 전달하는 데 더 능숙해졌거나, 자신감이 더 생겼거나, 나쁜 관계를 청산할 수 있었다.
* 동정심과 이해심이 더 많아졌다.
* 해를 가한 사람과 관계가 오히려 더 좋아졌다.
이런 식으로 솔직하게 적어나가면 분노와 불안을 잠재우는 데 효과적이라고 한다.
- 반려동물
실험 결과들을 보아하니 확실히 불안을 없애는 데 효과적인 동물은 '개'다.
(심지어 반려자보다 효과가 있다고 한다ㅡ_ㅡㅋ)
고양이는 나쁜 기분을 완화시키는 데 도움이 되지만 기분을 아주 좋게 해주지는 못한다고 한다.
하지만 고양이를 기르는 입장으로서는 동의 못 한다 ㅋㅋㅋㅋㅋㅋ
난 고양이의 귀욤귀욤귀요미 매력에 빠진 덕분에
고양이랑 같이 편안히 있을 때마다 엔돌핀이 아주 팡팡 돈다. 움쪽쪽.
6장. 화성남자와 금성여자의 지구 생활 : 재앙을 막는 관계 유지의 비결
- 부부 관계에 대한 이야기이니 PASS -
7장. 솔로몬의 선택 : 후회 없는 결정을 위한 교훈
- 일단 발 들여놓기, 무리한 요청 먼저하기, 특이한 부탁으로 상대방 얼떨떨하게 만들기,
덤으로 하나 더 등의 방법이 영업사원들이 많이 사용한다고는 한다고 하지만 ㅋㅋㅋ
실생활에서도 많이 써 먹을 수 있는 방법이긴하다.
실제로 나는 특이한 부탁으로 혼을 빼놓거나 Deal(?)을 하거나 아니면
최후의 수단으로 배째라는 식으로 떼를 쓴다거나 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
하는 방법을 쓰긴 하지만... 일단 나는 누구에게 부탁하는 걸 안 좋아하기 때문에 ㅡ_ㅡ..ㅋ
- 아까 딴 생각이 아이디어를 만든다고 했는데 어떤 결정을 내릴 때에도
이 방법이 가능하다고 한다. 결정해야 할 문제를 생각한 뒤 다른 일(스도쿠 풀이 등)을 하고 난뒤에
결정을 내린 선택이 나중에 후회하는 경우가 보통 결정을 내리는 과정보다 적다고 한다.
딴 생각의 힘인가. (정확하게는 무의식)
- 후회하면 스트레스만 받으니... 후회를 아예 하지 말거나 후회할 짓을 미리 방지하자.
ㅋㅋㅋㅋ 솔직히 이것도 다 아는 건데 실천이 힘들지 않나?
8장. 똑똑한 아이 만들기 : 내 아이를 위한 교육의 기술
- 아이가 없으니 PASS : 이름잘짓기, 능력보다는 노력에 대한 칭찬, 자제력 길러주기 등 -
9장. 당신은 내 손 안에 있다 : 종잡을 수 없는 상대방을 간파하는 법
- 제일 재밌게 읽었던 장이다.
- OCEAN 성격 진단법
개방성, 신중함, 외향성, 동조성, 신경증
개방성 :
상상력과 창의력이 뛰어나지만 금방 싫증을 느끼기 쉽고 항상 새로운 생각과 경험을 추구하는 경향이 있다.
반대인 사람은 현실적이고 기존의 개념을 실현할 수 있는 상황을 추구하며 과감한 변화보다는 단계적인 변화를
원하고 잘 확립된 관행과 규칙을 따르려는 경향이 있다.
신중함 :
조직적이고 의무에 충실하다. 모든 것이 있어야 할 자리가 정해져 있고, 모든 것이 제자리에 있는,
잘 조직되고 예측 가능한 환경에서 최고의 능력을 발휘한다.
반대인 사람은 느긋하고 인생을 즐기면서 살려고 하지만 자제력이 있어야 하는 상황에서는 다른 사람의 도움이
필요할지도 모른다.
외향성 :
다른 사람과 함께 있을 때 힘이 나고, 밤이 되면 생기가 넘치며, 채찍보다는 당근을 써야 더 열심히 하는 스타일.
반대인 사람은 조용한 환경에서 혼자 일하길 좋아하며, 오전에 집중력이 높고, 당근보다는 채찍을 써야
더 열심히 하는 스타일.
동조성 :
신뢰성이 높고 우호적이며 협조적이지만, 남들이 그런 성격을 이용할 수도 있으니 조심해야 한다.
반대인 사람은 공격적이고 경쟁 의식이 강하며 강인한 사고와 직설적인 화법이 필요한 상황에서 능력을 발휘한다.
신경증 :
불안과 고민에 빠지기 쉬우며, 부정적인 감정을 삭이는 데 시간이 오래 걸리기 때문에
가능하면 기분 나쁜 상황을 피하려고 한다.
반대인 사람은 느긋하고 감정에 덜 치우치며, 웬만한 일에는 고민하지 않는다.
다른 사람들이 스트레스를 심하게 받는 상황에서도 잘 견딘다.
- 2D:4D (집게손가락:약손가락)
두번째 < 네번째 손가락이면, 위 비율이 1보다 작다.
두번째 > 네번째 손가락이면, 위 비율이 1보다 크다.
보통 남자는 1보다 작고 여자는 1에 가깝다.
나는... 양손 다 네번째 손가락이 더 길다 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
책에 따르면 그런 여자는 적극적이고 모험을 두려워하지 않는 경향이 있다는 연구가 있다고 한다.
위로가 되는 건 1보다 큰 값을 갖고 있는 사람이
더 무거운 무게를 들어올리고, 더 빨리 달리고, 유명 축구선수들, 우수한 공간 정보 처리, 뛰어난 음악적 재능을
갖고 있는 경우가 많다고 한다. 비과학적인 직관이겠지만... 그래도 연구 결과, 통계적으로 그렇게 나온다는 거.
- 그 밖에
(1) 애완 동물의 성격은 주인의 성격이 투영된 것이라는 사실이 드러났다고 한다.
(2) 차에 범퍼 스티커를 많이 붙힌 사람을 조심해라. 공격적인 운전을 할 가능성이 높다.
(3) 깍지 껴서 오른손 엄지가 위에 있으면 좌뇌가 우세하고 (좋은 언어능력,분석적)
왼손 엄지가 위에 있으면 우뇌가 우세하다. (시각적, 창의력, 직관적)
10장. 행복 연습 : 완전한 삶에 관한 놀라운 진실
- 장기적인 행복감을 위해 '표현적 글쓰기'를 해라.
내용은 감사 표시, 멋진 순간, 환상적인 미래, 사랑하는 사람, 현실 되돌아보기 등등.
이 책도 그렇고 코딩 호러 책도 그렇고 모두 공통적으로 강조한 말은 '글쓰기를 해라'다.
난 글을 써본 적이 많지 않아서 정말 글짓기 젬병 이지만...
이렇게 쓰다보면 확실히 글쓰기 능력이 향상된다는 것을 느낀다.
그게 연필로 썼던 간에, 블로그로 썼던 간에 생각을 이렇게 정리한다는 건
나한테 긍정적인 효과를 많이 보여준다고 느낀다.
- 돈으로 행복사기
* 물건 대신에 경험을 사라. 예를 들면 외식, 콘서트, 영화, 연극, 여행, 댄스 배우기, 야외 활동 등.
* take 보다는 give.
대충 읽기는 했지만 그래도 읽을 건 다 읽은 듯.
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
난 분명히 위에 적었다시피 간단하게 적을 생각이었는데
책을 이리저리 뒤적거리다 보니 꽤 남기고 싶은 내용이 많았나 보다ㅋㅋ
그런데 쓰다가 깨달았는데 여기서는 반드시 직접 실험해보거나 다른 사람이 실험했던 내용을
인용한 이야기가 대부분이다. 하지만 잘 읽어보니 표본이 적다고 생각되는 실험들도 간간이 눈에 띈다.
그런 것을 보면 왠지 신뢰성이 떨어지긴 해도ㅋ 목차만 보고 관심이 생기거나
읽다보니 흥미롭게 느껴지는 글들이 있어서 재밌었다. 잘 읽었다.
자기 계발서라 그런지 스스로 반성하는 시간도 갖게 되었고~
(글 중간에 갑자기 자학하는 글도 쓰는 걸로 보아선 ㅋㅋㅋ)
가끔씩 읽는 것도 나쁘진 않은 것 같다. 당연한 이야기들이 많긴 하지만
실제로 행하지 않는 내 모습을 되돌아 볼 수 있게 되니까 시간낭비까지는 아닌듯ㅎ
| 책 리뷰 : 조엘 온 소프트웨어 (0) | 2014.10.12 |
|---|---|
| 책 리뷰 : 실용주의 프로그래머 (0) | 2014.07.04 |
| 책 리뷰 : 코딩 호러의 이펙티브 프로그래밍 (0) | 2014.05.13 |
| 책 리뷰 : 코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기 (0) | 2014.05.01 |
| 책 리뷰 : 읽기 좋은 코드가 좋은 코드다 (임백준 역, 한빛미디어) (0) | 2014.04.27 |
2014.05.07
구글 코리아에서 채용 설명회를 한다는 정보를 접하고
갈까말까 무지하게 고민하다가 결국 갔다왔다.
연세대 광복관 B105호 에서 오후 5시부터 시작한다고 했는데
4시에 도착하는 바람에 왠지 버블티가 먹고 싶어져서 학생회관으로 ㄱㄱ
(지금은 연대 입구쪽이 공사판이라 먼지 한가득 마시고 온듯. 끄엑ㅡㅡ)
이거 찾느라 조금 고생했다 ㅡㅡ....
학생회관 버블티가 싸고 맛있다고 그러길래 이거 찾느라 B1 에서 헤맸다.
결국엔 1층으로 올라가서 찾았지만 ㅋ
http://blog.naver.com/mar21/30150095508
사진은 위 블로그에서 발췌. 허락없이 편집해서 죄송.
제가 지쳐서 따로 사진을 못 찍었어여.
(언짢으시면 지울게여ㅠㅠ)
위 블로그 분께서 쿠키바닐라 버블티 드셨다길래
나도 똑같은 걸로 +샷추가 +버블추가 해서 주문했는데 3100원 밖에 안했다!! 우왕굳
버블도 쫀득하니 맛났다!
직원 분들이 바쁜 탓에 조금 힘드셔서 그닥 친절하지는 않았지만
맛,가격은 착하고 살앙스럽다ㅋ.ㅋ
일단 연대 안쪽으로 들어가다보면 여기저기 대자보랑 현수막이 겁나 붙어있는데...
보통 대기업 채용 설명회가 실시되면 안내 공고나 표시라도 있는 게 정상이라고 생각하건만
구글 코리아............... 절대 그런 거 없다.
마치 "굳이 우리가 안내를 안해도 관심있는 애들은 알아서 잘 찾아오겠지" 마냥ㅡ_ㅡ....
내가 광복관 들어가서 강의실 찾아갈 때까지
구글 코리아 채용설명회가 있다는 대자보, 공고, 현수막, 안내 표지판 등 그런 거
일절 없.었.다.하.나.도.
그래서 검색+물어물어 4:50 PM 쯤에 도착했드니
앞에 무슨 고딩들 상대로 뭐하는 게 있어서
설명회 들으러 온 사람들은 밖에서 5시까지 그대로 대기 했다.
뭔가 워낙 비밀리(?)에 진행되는 것처럼 보이는 설명회라서
그렇게 많은 사람들이 오지는 않았다. 40명도 안 되는듯.
아무튼 자리 잡고 구글 코리아 직원 4분 께서 오셨는데....
진짜 충격 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
나 개발자 지망생인데 채용 설명하시러 오신 분들 전부 세일즈&광고 마케팅 쪽ㅋㅋㅋㅋㅋㅋㅋㅋ
ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
발표자 분께서 연대 07학번 출신의 세일즈 팀이라고 말하는 순간
머리 속이 퍼엉 ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
한 10초 멘붕 상태였지만 그렇다고 연대까지 왔는데 자리 박차고 나오기도 그래서 그냥 들었다 ㅡ_ㅡ...
하지만 충격 상태가 커서 아무런 사진도 찍지 않았고 그냥 기억에 남는 내용만 몇 자 적을거다. 흑.
- 구글 코리아 직원이 250명 정도 되는데 그 중에 절반이 엔지니어다.
- 구글의 각 나라별 오피스마다 엔지니어링 팀이 있는 곳도, 없는 곳도 있는데
코리아의 경우 엔지니어링 오피스가 큰 편이라고 한다.
- 구글 코리아에서 본사로 이동하는 케이스가 꽤 있다고 한다.
한 여성 직원분 말로는 40명 정도라고도 하고 아무튼 적지는 않다고 한다.
구글 내부에도 채용 사이트가 있어서 자리만 난다면 지원할 수 있다고 한다.
물론 여러 인터뷰를 거치는 과정은 필수다.
- 이 날 오신 분들은 최근에 세일즈 파트의 'Advertising Operations Associate' 쪽의 채용 공고가
뜬 것에 대해서 채용 설명회 하러 오신 것 같았다. 직원 네 분 모두가 경영 or 경제 학과 출신에
광고홍보를 복수전공 하신 분도 계셨다.
- 구글이야 뭐... 인재를 뽑을 때 워낙 꼼꼼히 살펴보기로 유명한 기업이기 때문에
일반 한국의 대기업처럼 대규모 공개채용을 하지 않는다.
그냥 평소에 내가 원하는 직무 쪽의 자리가 났는지 채용 사이트를 기웃거리는 게 방법인듯.
- 사람 한명 한명 모두를 상세히 평가하기 때문에 당연히 채용 프로세스가 조금 긴 편이다.
차이는 있겠지만 인터뷰도 3번 이상은 보는 것 같고... (전화/온라인/오프라인 등_영어면접必)
구글답게 절대 아무나 안 뽑는다ㅠ_ㅠ
- 구글은 수평적 구조로 유명한데 대표적인 예로...ㅋㅋㅋㅋ
사장님이 누리는 복지와 신입이 누리는 복지가 동일하다고 한다. 대박.
뭐 누구나 다 알고는 있겠지만 과장/대리/사원 등의 직급 없이 '~님'이라고 부르고
심지어 주차장 자리 뽑기할 때도 사장님도 같이 뽑기해서 꽝 나오면
대중교통으로 출퇴근 하든가 해야 된다고 한다.
- 특히 엔지니어링 파트는 철저히 능력 위주 평가라 사실 학벌, 학점, 학위가 무의미하다고 한다.
난 여기저기 주워들은 게 많아서 학사(BS) 가지고는 조금 힘들지 않을까 했는데ㅡ_ㅡ
그런 거 전혀 없는 듯. 말 그대로 능력만 있으면 언제든지 웰컴.
- Q&A 질문에서 빠지지 않는 것 중에 하나가 '학점이 중요한가?'인데 역시 나왔다.
그 분들과 내 생각이 동일 했다.
언제부턴가 제로베이스 채용으로 바뀌는 추세다보니 학점이 높지 않아도 채용이 되는 사람들이 꽤 있다.
하지만 그 사람들은 학점이 남들보다 딸리는 만큼 다른 무언가를 함으로서
자신의 경험을 어필했기 때문에 채용이 됐다는 걸 잊으면 안 된다.
뭐... 결론만 얘기하면 중요하다/중요하지 않다 라고는 대답 못 하겠고..
학점이 높으면 다행이지만, 안 높으면! 그 만큼을 땜빵(?)할 수 있는 경험이 있어야 된다.
내가 이미 취업의 쓴맛을 좀 봐서 그런지 확실히 애들이 질문하는 거 보면
진짜....ㅡ_ㅡ 이런 말하기 뭐하지만 수준이 보인다. 연대생이고 뭐고 한심할 정도의 질문들이
나올 때마다 정말 ㅋㅋㅋㅋㅋㅋ 답변하시는 직원 분들 속이 뒤집어 지실듯.
대표적으로 학점 얘기, 영어 얘기, 앞에서 설명한 거 안 듣고 또 질문하는 얘기 등등.
- 영어 얘기가 나와서 생각났는데 설명회 오신 직원 네 분들 중에서 07년도 입사해
가장 오래 재직하신 분께서 진짜 딱 잘라서 대답하시는 게 시원시원 하더라.
(보통 영어 수준이 얼마나 되야 되냐고 물어보면 잘하면 잘할수록 좋다 등등
약간 돌려서 좋게좋게 말씀하시는 분들이 많은데 그냥 딱 잘라서 얘기해 주는 게 나은듯.)
대답은 "준 Native 실력은 되야합니다"
구글 코리아라도 대부분 영어로 근무하기 때문에...영어 못하면 일 못한다고 생각하면 될듯.
사실 채용 사이트 들어가서 이력서만 작성해도
어느 정도 영어를 잘 해야하는지 조금이나마 체감할 수 있을 것이다ㅋ
(물론 나도 영어 젬병이라 슬픈 현실이라는 건 알고있음)
- 구글 코리아에서
<< 채용 설명회하러 오신 분들의 팀 기준으로 (SMB:Sales Management 뭐시기인듯) >>
30% 미만이 해외 대학 출신 이라고 한다. 컹.
- 구글 직원이 전부 합쳐서 4만명? 정도 된다고는 하는데...
우리나라 대기업들에 비하면 적은 직원수지만 구글의 파급효과를 보면 뭐랄까...
그냥 진짜 소수정예 집단인 것 같다. 레알 알짜배기? 느낌.
흑 나도 끼고싶다ㅠㅠ
뭐 이정도 기억나는 것 같다.
아까도 말했듯이 나는 개발자 지망생에 이미 취업의 쓴맛을 겪어 봤기 때문에
더 많은 이야기가 있음에도 불구하고 듣고 싶은 것만 들어서 여기까지 인듯 ㅋㅋㅋ
그리고 구글은 내가 워낙 좋아하는 기업이라 조금은 알고 있어서
자세한 건 안 적었다. 궁금하면 구글 채용사이트 ㄱㄱ
구글 코리아는 http://www.google.com/about/careers/locations/seoul/
(영어 싫어하면 들어가지 마세요. 현기증 날겁니다ㅋ)
사람인에서도 이 날 설명회 왔었나 보다. 잘 정리해놓으셔서 참고하기 좋을 듯 하다.
아, 설명회 끝나고 따로 질문하러 갔었는데
내 앞에서 질문하신 분들 중에 대학생 처럼 보이는데...
이미 해외에서 근무를 하고 있다고 하더라.
대박, 대체 여긴 어떻게 온 거임?
항상 말로만 미국에서 개발자로 살고 싶다고는 하지만
결코 절실하고 간절한 마음없이는 불가능 할거라고 느낀다.. 푸하하
| 프로그래머가 인문학을 해야 하는 이유 (0) | 2014.08.28 |
|---|---|
| Stack Exchange, Stack Overflow 무슨 차이일까? (0) | 2014.05.13 |
임백준 님이 번역하신 또 다른 책 ! ㅎㅎㅎㅎ
저자이신 제프 앳우드 님은 프로그래머 사이에 유명한 블로그인 '코딩 호러'를 운영하시는 분이시다.
그리고 코딩하면서 구글링을 했다면 누구나 알 법한 stackoverflow.com 을 창립해 사이트를 구축하신 분.
오랫동안 닷넷 프로그래머로 일하셨고 지금은 루비 쪽에 관심이 있으신 것 같다.
'읽기 좋은 코드가 좋은 코드다' 라는 책에선 코드로 설명을 많이 하는 반면
이 책은 정말 - 이야기 - 가 많다.
그래서 조금......... 지루했다. 읽는 것도 꽤 걸렸다.
물론 다 피가 되고 살이 되는 이야기 겠지만..............
지루하기도 하고 지겹기도 해서 어떤 글들은 대충 읽기도 했다.
제프 앳우드 님의 블로그에서 좋은 글들을 선별해 엮은 책이라 확실히 블로그 스러운 느낌의 글들이 많다.
절대로 그 분의 글솜씨를 폄하할 생각은 없지만 (물론 역자님 탓을 하고 싶지도 않다)
약간 앞뒤 말이 안 맞는 부분도 있었고, 문장이 길어서 이해하기 힘든 부분도 있었다.
내용 자체가 어려웠던 부분도 있었다.
짧게 결론을 내리면...............
'읽기 좋은 코드가 좋은 코드가' 라는 책보다 확실히 재미없었다 ㅡ_ㅡ...
나중에 좀 더 레벨업 된 개발자가 됐을 때 다시 읽어 보든가 해야겠다.
- 내가 이해력이 딸려서 그런 것일 수도 있으니 -
포스팅 시작부터 이렇게 부정적인 얘기만 blah blah 하니까
아무도 안 읽을 것 같다. ㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋㅋ
하지만 !!! 물론 읽을 만한 글들도 있다. 정말로 지루하기만 했다면 리뷰 글따위 쓸까 보냐.
처음부터 하나씩 훑으면서 자세한 리뷰를 남기겠다.
Part 1. 쓸데없는 일을 줄이는 법
아까 위에서 앞뒤 말이 안 맞는 부분이 있었다고 했는데
바로 이 파트에 그런 글들이 있었다.
'쓸데없는 일 하지 않기' 라는 글에서 할일 목록 따위를 만들어서
스스로를 강박주의자로 만들지 말라는 글이 있었다.
심지어 굉장히 진지하게 할일 목록을 전부 내다 버리라고 글을 쓰셨다.
정말로 중요한 일이 있다면 우리의 뇌가 그걸 잊어버릴 일은 없다고.
그런데
'우리 프로젝트는 언제나 90퍼센트 가 완료돼 있을 뿐이다.' 라는 글에서는 조금 다르다.
이 글에서는 목록이 없으면 스케줄도 없다고 하며
프로젝트가 90% 완료에만 머무는 슬럼프를 넘기 위해서는
개발자들에게 자기가 해야 할 일을 모두 자세하게 나열해보도록 권장하는 글이 있었다.
둘다 쓸데없는 일을 줄이는 방법이긴 하지만 전혀 다른 방법이다...
물론 내가 이해 못 한 부분이 있기야 하겠으나 이런 모순된 글을 보면서
앞뒤가 안 맞는 부분이 있다고 생각했다.
'열정이 있는데 재능이 무슨 필요람?'
- 이 컬럼은 앞에 무슨 얘기인지 잘 이해가 안 됐지만 마지막 글귀가 가슴에 와닿았다.
'당신보다 재능이 있는 수천명의 개발자가 있다고 해서 기죽지 말라.
당신에게 열정이 있는데 재능이 무슨 필요가 있단 말인가?'
솔직히 낭만주의에 젖은 듯한 말 같지만 그래도 공감이 전혀 안되는 건 아니다.
열정이 있고, 열정이 있다는 걸 확실히 표출하는 게 중요하다고 생각한다.
뭐 어찌됐든 이 파트에서 가장 기억에 남는 글은 '보이드의 반복법칙' 이라는 글이다.
상당히 흥미로운 글이었다.
소프트웨어 개발에서 사용되는 반복적인 방법(iterative)과 재귀적인 방법(recursive)의
사이에 존재하는 차이를 설명하기 위해 선택한 비유가 있었다.
그 비유로서 한 공군 대령이 제트 전투기와 관련된 연구 이야기를 하는데 꽤 재밌는 이야기였다.
이 글에서 말하고 싶은 바는 보이드의 반복법칙 그대로였다.
반복의 속도가 반복의 질보다 우선한다.
상당히 인상 깊은 글이었다. 굳.
Part 2. 프로그래밍
'깨진 유리창 이론'
- 깨진 유리창을 고치지 않은 채로 방치하지 말라.
일단 창문이 깨지기 시작하면 깔끔하고 기능적으로 잘 동작하던 시스템이
순간적으로 엉망이 되어버리는 모습을 보아왔다. 그러니 최대한 빨리 고쳐야 하고
제대로 고칠 시간이 충분하지 않다면 일단 나무 판자라도 대서 때우기라도 하면서
더 이상 훼손되지 않도록 조치를 취해 그 문제를 인식하고 처리중이라는 사실을 드러내라.
위의 글은 실용주의 프로그래머에서 설명된 글 일부를 정리해서 쓴 것이다.
저런 경험이 있는 지는 잘 모르겠지만 왠지 모르게 공감이 가서 여기에 대충 적어봤다.
'궁극의 코드 카타'
- 카타 : 미리 정해진 동작을 반복해서 훈련하는 것을 의미. 무술에서 사용하는 단어.
프로그래밍을 잘 하기 위해선 어떻게 해야 되는지 방법들이 적혀있다.
참고할 수 있을 만한 사이트가 주석으로 달려있다.
'프로그래밍에서는 1이 가장 외로운 숫자다', '당신의 코딩 친구는 누구인가?'
- 음........ 위 글들은 페어 프로그래밍(Pair Programming) 이라는 키워드는 없었지만
이 키워드를 강조하는 글들이었다.
나한테 코딩 친구가 있는지 생각해보니까 아직은 없는 것 같다. 흐음.
아직까지 우리나라에서는 페어로 일하는 문화는 거의 없지 않나 싶다.(개발자들 사이에서)
오히려 서로 터치해봤자 트러블이 있을 수 있으니 각자 독립적으로 일하는 분위기랄까.
"쿨하지 못해 미안해. 그러니 각자 할 일 하자." 이런 느낌? 유감스럽다.
'소프트웨어 도제살이'
- 소프트웨어 개발에서 견습생/고참/장인 이라는 관계를 키워나가야 될 필요성을 말하는 글.
확실히 그런 건 있는 것 같다.
'내가 하면 오늘 안으로 다 할 것을, 일부러 후배에게 일임하면서 경험을 쌓도록 도와주는 것'
쉬운 일은 아니다. 왜냐면 멘토 입장에서 후배하는 거 보면 복장이 터질 정도로 답답할 수 있으니까.
그럼에도 불구하고 훌륭한 후배들을 양산해 내기 위해 노력하시는 개발자 분들을 보면
정말 존경스럽다. 나도 그런 분들을 닮고 싶다.
Part 3. 웹 디자인
솔직히 개발자를 위한 책에서 이 파트가 다뤄졌다는 점이 신기하다.
게다가 글도 꽤 많은 양을 차지하고 있는 파트다. 우왕 의외다.
'앱이 웹사이트를 죽일 것인가?'
- 이 글에서의 결론을 정리하자면
웹사이트가 앱에게 죽지 않으려면 멍청한 웹사이트가 되어선 안 된다.
- 앱이 웹사이트 보다 나은 이유
(1) 더 빠를 수 있다.
(2) 단순한 Native UI Control 을 사용한다.
(3) 앱은 스크롤 공간을 더 효율적으로 사용한다.
(4) 온오프라인 상관없이 잘 동작한다.
- 웹사이트가 앱보다 나은 이유
(1) 브라우저만 있으면 어떤 장치에서도 사용할 수 있다.
(2) 설치할 필요가 없다.
(3) 업데이트 될 필요가 없다.
(4) 웹사이트는 보편적인 UI 경험을 제공할 수 있다.
'값싸고 손쉬운 사용성'
- 소프트웨어 프로젝트의 사용성과 관련해서 입문자를 위한 쉬운 책
'스티브 크룩의 사용성 평가, 이렇게 하라!'
'사용성 VS. 학습용이성'
- 조엘 스폴스키의 책 '프로그래머를 위한 사용자 인터페이스 디자인' 中
학습 용이성에 관심을 가져야 하는 경우 : 관광지 여행객과 같이 아주 가끔 방문하는 사용자
사용성에 관심을 가져야 하는 경우 : 전문적인 작가를 위한 워드프로세서
'구글의 가장 큰 UI 실수'
- 구글 메인의 I'm Feeling Lucky 버튼에 대해 엄청 까는 글인데 재밌다. ㅋㅋㅋ
Part 4. 테스트
- 유닛테스트(Unit Test) 를 한번 해보고 싶다는 생각은 하지만 아직도 실천되지 않는....ㅠ_ㅠ
- '예외 로그는 고객의 피드백이 가질 수 있는 최고의 형태다' 라고 하셨는데 맞는 얘기다. 공감 빵빵.
Part 5. 당신의 사용자를 알라
- 꽤 많은 양의 글을 담고 있지만 기억에 남는 글은 별로 없었다.
'묻지 말고 관찰하라'
- 이 글을 보면 초창기 구글.co.kr 의 화면 이미지가 있는데 정말 화가 난다. 지저분해서 ㅡ_ㅡ
지금은 모르겠는데 당시 한국 사람들은 고급 제품으로부터 복잡성을 기대한다는 이야기를 보고 놀랐다.
말도 안돼. 나도 한국 사람이지만 이해가 안 된다. 리얼리? ㅋㅋㅋ
- 그 밖에는 아마존의 상품 추천 기술 도입에 대한 실험 정신을 볼 수 있는 에피소드가 재밌었다.
Part 6. 우리가 관심을 둬야 할 것들
'인터넷... 그리고 그 밖의 모든 것들을 보존하기'
- 제이슨 스콧 : 2011년 인터넷 아카이브에서 공식적인 사료보관인으로 임명받음.
- 인터넷 아카이브가 하는 일 : 인터넷에서 단 한 번이라도 존재한 적이 있는 웹페이지를
당시의 모습 그대로 영구히 저장한다.
- 왜 ? : 인터넷에 올라오는 정보들은 너무나 빠르게 변하기 때문에 순식간에 모두 상실되는 것은
정상적인 현상이지만 그 결과로 우리의 문명은 기억상실증에 걸린 듯 하다.
과거의 하이퍼링크에 대한 소스가 필요한 평범한 시민들에게 있어 꼭 필요한 일이다.
'유튜브 VS. 정당한 사용'
- 저자가 블로그에 어떤 영화의 일부 장면을 인용하고자 유튜브 동영상을 올리다가
유튜브에게 저지 당한.... (정확하게는 컨텐츠 제작자) 사연이 있는 글인데, 재밌다.
흥미롭기까지 할 정도인 유튜브의 기술..............ㅋㅋㅋㅋㅋㅋㅋ 진짜 대단하다. 짱이다.
- TED 강연 : How youtube thinks about copyright
http://www.ted.com/talks/margaret_stewart_how_youtube_thinks_about_copyright
꼭 봐야지 라고 생각하는 것들 중 하나가 되어버렸다. 대ㅋ박ㅋ
Part 7. 게이밍
- 아타리와 비쥬얼 베이직부터 시작해 게임 분석에 관한 이야기,
게임 플레이어에서 게임 개발자로까지의 이야기가 있지만............
왠지 세대차이도 조금 느껴지고 당연한 이야기인 것 같아서 조금 실망.
Part 8. 읽어볼 만한 내용
'프로그래머는 책을 읽지 않지만 당신은 읽어야 한다'
- 저자가 추천해주신 책 목록
1. Code Complete 2
2. Don't Make Me Think (상식이 통하는 웹사이트가 성공한다)
3. Peopleware
4. Pragmatic Programmer (실용주의 프로그래머)
5. Facts and Fallacies of Software Engineering (소프트웨어 공학의 사실과 오해)
'아무도 당신을 돕지 않을 것이다. 그리고 그 점이 바로 멋진 부분이다'
- 시중에 나온 자기계발서의 95%는 완전히 쓰레기다............. 라고 하셨다.
ㅋㅋㅋㅋㅋㅋㅋ 왠지 책을 많이 안 읽어서 다행이다 라고 한심한 생각을 하게 된다 ㅋㅋㅋㅋㅋㅋ
- 유일하게 추천하는 자기계발서 '59초: 순식간에 원하는 결과를 끌어내는 결정적 행동의 비밀'
영문책이라 한글판으로 있는 지는 모르겠다. 원제는 '59 Seconds: Think a little, Change a lot'.
추천하는 이유는 과학적 연구결과를 찾아 인용하면서 설득하기 때문이라고 한다. 믿을만 하다는 것이다.
음........... 앞에 부정적인 말들을 많이 한 것 치고는 정리해보니
그래도 잘 읽은 책인 것 같다 ㅋㅋㅋ 나도 참 줏대없는 인간인듯ㅋ
원래 이 책이 나오기 전에
'코딩 호러의 이펙티브 프로그래밍' 이라는 책이 먼저 나왔는데 그거 먼저 읽을 것 그랬다.
역자의 말에 의하면 그 책보다는 이 책이 좀 더 개발자에게 재밌을 거라고ㅋ
ㅇㅏ ~~~~~
다음엔 뭘 읽어볼까.
| 책 리뷰 : 조엘 온 소프트웨어 (0) | 2014.10.12 |
|---|---|
| 책 리뷰 : 실용주의 프로그래머 (0) | 2014.07.04 |
| 책 리뷰 : 코딩 호러의 이펙티브 프로그래밍 (0) | 2014.05.13 |
| 책 리뷰 : 59초 - 순식간에 원하는 결과를 끌어내는 결정적 행동의 비밀 - (0) | 2014.05.12 |
| 책 리뷰 : 읽기 좋은 코드가 좋은 코드다 (임백준 역, 한빛미디어) (0) | 2014.04.27 |
독서와 수십 억광년의 거리를 두다 언제부턴가 개발자를 위한 책을 읽기 시작 하면서
조금씩 책을 읽게 되었다. 그리고 지금은 리뷰까지 쓴다. 헛소리겠지만 나이 들었나 보다ㅋ
아무튼 간만에 재미있게 읽은 책이었다. 처음엔 단순히 임백준 님이 번역했다는 이유로
책을 선정했는데 선택하길 잘 한 것 같다. 굿초이스였다!
중학교때인가 독후감을 써내야 했었다. 당시의 난 책 읽는 것을 무지 싫어했지만
쓰긴 써야되니 임백준 님의 '뉴욕의 프로그래머'라는 책을 읽었다고 뻥을 치고 독후감을 썼다.
그러다 대학생이 되고 어느 날, 언니가 빌려온 책 중에 '뉴욕의 프로그래머'가 있는 걸 보고
중학교 때 생각이 나면서 호기심에 읽기 시작했고 임백준 님을 존경하게 되었다. 지금도 존경한다.
존경하는 분이 번역하신 책인 만큼 재미있겠거니 하고 '읽기 좋은 코드가 좋은 코드다' 라는 책을 읽게 되었다.
저자이신 더스틴 보즈웰, 트레버 파우커 두 분 모두 구글에서 근무한 경력이 있으신 분들이다. 짱이다.
지은이의 말이 시작하기 전에 다음 그림을 보고 공감해버리고 말았다.
으, 생각만 하면 창피하다.
내가 지금도 이런다면 문제가 심각하겠지만 불과 2~3년 전만 해도
저랬던 건 확실하게 기억이 난다. 내가 짠 코드를 한 1년 뒤에 언니가 그 코드가 필요하다고 해서
파일을 넘겼는데 언니가 했던 말, '이 코드는 뭐하는 코드야? 이건 뭐고 저건 뭐하는 변수야?' 등등....
나 혼자 짠 코드라 주석따위 거의 없었고 변수 이름도 보면
내가 다시 봐도 기억도 안나고 뭐하는 변수인지 잘 파악도 안되는 그런 코드였다.
딱 위에 있는 그림과 같은 상황이었다. 제기랄.
리뷰에 앞서 참고로 이 책은 꽤 자잘하게 많은 예제 코드들이 있어
내 이해를 더 도울 수 있었고 코드 랭귀지도 C++, JAVA, Python, JavaScript, PHP 등 다양한 언어들로
예시를 들어서 개인적으로 다양한 언어를 경험해본 나로서는 꽤 흥미로웠다.
그리고 이 책은 4 가지 파트로 구성되어있다.
1부. 표면적 수준에서의 개선 (이름 짓기, 주석, 미학, 코드베이스의 모든 줄에 적용될 수 있는 간단한 조언들)
2부. 루프와 논리를 단순화하기
3부. 코드 재작성하기
4부. 선택된 주제들
각 파트별로 리뷰를 남겨보겠다. 안 그러면 나중에 읽고서도 무슨 내용이 있었는지 기억이 잘 안난다.
중요하거나 기억에 남는 부분을 위주로 작성하겠다.
<< 1부. 표면적 수준에서의 개선 >>
(1) 이름에 정보담기
- 내 생각엔 이 파트의 내용은 정~~~말 깨알같은 도움이 되는 내용이었다. 버릴 게 없다.
특히 상황에 적합한 단어들을 골라 명명하라는 내용은 격하게 공감한다.
다음은 책에서 소개된 내용들이다.
get |
fetch, download |
send |
deliver, dispatch, announce, distribute, route |
find |
search, extract, locate, recover |
start |
launch, create, begin, open |
make |
create, set up, build, generate, compose, add, new |
filter |
select, exclude |
왼쪽은 보통 일반적으로 많이 쓰는 단어들이다. 하지만 추상적으로 쓰일 때가 꽤 많다.
이를 대체하기 위해서는 아까도 말했듯이 오른쪽 단어들과 같이 상황에 적합한 단어들을 골라야 한다는
내용이 기억에 남는다.
나야 아마추어 수준이거나 그 이하의(ㅠㅠ) 개발자 지망생이긴 하지만...
어쨌든 개발하면서 왼쪽의 단어들을 많이 사용하는데 확실히 지금보니 추상적으로 썼을 때가
많았던 것 같다. 어휘력이 딸리다보니ㅡ_ㅡ.........
주석으로 blah blah 하느니 선언한 변수에 구체적이고 충분한 정보를 담는 이름을 명명하는 게
훨씬 효율적이라는 것을 다시 한번 돌아볼 수 있었다.
그 외 기타 주의사항
- 단위 : time 보다는 time_ms, size 보다는 size_mb, angle 보다는 degrees_cw 등등
(2) 오해할 수 없는 이름들
- 경계를 다루는 한계값 관련
[1, 5] 가 1, 2, 3, 4, 5 를 포함하고 [5, 10) 가 5, 6, 7, 8, 9 를 포함하는 표기가 있듯이
영어도 이러한 표기 단어들이 있다.
경계를 포함하는 한계값 : min/max, first/last
경계를 포함하고 배제하는 범위 : begin/end (end가 애매하긴 하지만 관행인 것 같다)
(3) 미학
- 내가 개인적으로 추구하는 미학이랑 공감할 수 있는 부분이 많은 것 같아서 천만다행이다.
(4) 주석에 담아야 하는 대상
- '코드에서 빠르게 유추할 수 있는 내용은 주석으로 달지 말라' -> 이 이야기 보고 조금 뜨끔했다.
내 예전 코드를 까보면 내가 안 좋은 짓이란 짓은 꽤 많이 했었던 것 같다.(특히 쓸데없는 거) 끄엑ㅠㅠ
- 다음은 프로그래머 사이에서 널리 사용되는 표시라고 한다.
TODO: |
아직 하지 않은 일, 해야할 일 (중요한 건 TODO:, 덜 중요한 건 todo: 이렇게 구분도 가능) |
FIXME: |
오작동을 일으킨다고 알려진 코드 |
HACK: |
아름답지 않은 해결책 |
XXX: |
위험! 여기 큰 문제가 있다 |
솔직히 TODO 빼고는 다 처음 본다..ㅋㅋㅋㅋㅋㅋㅋ
어쨌든 깨알같은(명확하고 간결한) 주석은 부지런히 달자.
난 너무 주석을 안 다는 버릇이 있어서 고쳐야 된다.
다 피가 되고 살이 된다.
<< 2부. 루프와 논리를 단순화하기 >>
(1) 읽기 쉽게 흐름제어 만들기
- 함수 중간에서 반환해 중첩 제거하기
- 루프 내부에 있는 중첩 제거하기
아래 코드는 책에 있는 예제이다. 처음 코드를 두번째 코드로 고치자.
for ( int i=0; i<results.size(); i++ )
{
if ( results[i] != NULL )
{
non_null_count++;
if ( results[i]->name != "" )
{
cout << "considering candidate..." << endl;
}
}
}
for ( int i=0; i<results.size(); i++ )
{
if ( results[i] == NULL ) { continue; }
non_null_count++;
if ( results[i]->name != "" ) { continue; }
cout << "considering candidate..." << endl;
}
이 내용을 보면 '당연히 아래 코드처럼 짜야되는 거 아니야?' 라고 생각할지 모른다.
확실히 누가 봐도 아래 코드가 더 간결하고 아름답다. 혹은 'for each' 을 써서 다듬거나.
나는 이 책을 보면서 과거에 내가 짰던 코드들에 대해 많이 되돌아 보고 반성할 수 있었다.
왜 내가 첫번째 코드처럼 지저분하게 중첩을 사용했는지는 잘 모르겠다. 당시 좀 멍청했었나 보다.
코딩을 하다보면 가끔 이런 지저분한 중첩으로 논리를 복잡하게 할 때가 있는데 반성해야겠다.
정신놓고 코딩하면 첫번째 코드로 짤 수 있는 여지는 충분하다고 본다 ㅠ_ㅠ
(2) 거대한 표현을 잘게 쪼개기
- 이 장의 제목 그대로이다. 영리한 코드가 아닌 누구나 쉽게 이해할 수 있는 심플한 코드를 만들자.
자기 혼자 머리가 좋다고 논리를 복잡하게 꼬아놓은 그건 정말 ㅄ............. 잘난 척하지말자.
- Tip : Python, JavaScript, Ruby 같은 언어는 'OR' 연산자가 인수 중 하나를 반환한다.
(해당 값은 Boolean 으로 변환되지 않는다)
ex ) x = a || b || c 라는 코드는 a, b, c 라는 세 값 중에서 첫번째 '참' 값을 반환한다.
- C++ 에서 매크로를 사용할 수 있는데 보통 매크로의 사용을 자제하는 것이 좋다고 한다.
하지만 책의 예제와 같이 때에 따라선 매크로가 간단한 사용과 코드 가독성을 도움을 주기도 하니 기억해두자.
(3) 변수와 가독성
- 이 장에서는 내가 이 책에서 읽은 내용 중 가장 충격적(?)인 내용이 담겨져있다.
- 다음은 JavaScript 에서 Form 을 제출할 때의 함수이다.
대부분 아래와 같은 방식으로 코딩할 것이라고 생각했다...
submitted = false; // 주의 : 전역 변수
var submit_form = function (form_name) {
if (submitted) {
return; // 중복 제출 방지
}
...
submitted = true;
};
그런데 잘 알다시피 전역 변수는 사용하지 않는 편이 좋다.
특히 JavaScript 에서는 변수를 정의할 때 'var' 를 생략하면 해당 변수는 모든 JavaScript 파일과 <script> 블록에 접근할 수가 있다. 그러다보니 자기도 모르게 무의식적으로 이 변수와 같은 이름의 변수를 사용하면
이상한 버그를 만들어낸다. 나중에 작성한 코드에서 여전히 그 변수를 볼 수 있기 때문이다.
내 기억에 의하면 난 이 경험을 해본 적이 있다. 최악이었다.
var submit_form = (function ()
{
var submitted = false; // 주의 : 아래에 있는 함수만 접근 가능
return function (form_name) {
if (submitted) {
return; // 중복 제출 방지
}
...
submitted = true;
};
}());
어쨌든 아래 코드는 이해하기 힘들지만 JavaScript 에서 Private 변수를 만드는 테크닉이라고 한다.
정말 듣도 보도 못한 테크닉이고 이게 돌아가는 코드인지 조차 의심이 되는 이상한 코드였다 ! !
그래서 충격이었다. 이게 고급 개발자의 테크닉이란 말인가 ㅎㄷㄷ.... OTL......
익명함수가 있다는 걸 알고는 있었지만.... 이건... 크헙... 말도 안 나온다..
이런 식으로 익명 함수를 사용해 Private 한 범위를 만든다니............. 진짜 충격.......ㅠㅠ
이거 진짜 어떻게 돌아가는 건지.... submitted 변수가 계속 저장이 되나 저게????
그리고 어떻게 사용하는 건지 모르겠다.... form_name 은 어떻게 넣어 주는거지???
흐앙 ㅠㅠ........................ 패닉이다.
책에는 (이러한 테크닉에 대해 더 알고 싶으면 더글라스 크락포드의 자바스크립트 핵심 가이드(한빛,2008)를
보라) 라고만 적혀있다......... 나중에 저 책을 사서 보든가 해야겠다 흑흑..
<< 3부. 코드 재작성하기 >>
(1) 상관없는 하위문제 추출하기
- 코딩을 하다보면 프로젝트랑은 직접적 연관은 없고, 자주 사용되는 도구 같이 유틸리티스러운(?) 부분을 짜게 된다.
그런 부분은 따로 디렉토리를 만들어서 모아두면 유용하게 쓰일 수 있다는 건 알고 있다.
하지만 실제로 난 코딩하면서 그래본 적이 없다 ㅡㅡ................. 이론만 알지 실천을 안하나보다. 제길.
어쨌든 일반적인 목적의 코드를 프로젝트의 특정 코드에서 분리하는 버릇을 좀 갖자 ! !
(2) 한번에 하나씩
- 책에 있는 예제가 깨알같다. 보면서 와닿는 것이 많고 깔끔한 코드가 정말 사랑스럽다.
- 한번에 여러 개를 못하고 하나에만 집중하는 타입인 나지만 이런 실수도 가끔 하는 것 같다.
One Time One Job 하자!
(3) 생각을 코드로 만들자
- 앞에 코드 중첩을 피하는 방법이 다시 나오기는 하지만 그래도 다른 예제로 다시 상기시킬 수 있으니 좋았다.
- 저자님들의 말씀에 따르면
" 간결한 코드를 작성하는 기술 중 하나는 라이브러리가 제공하는 기능을 잘 활용하는 것이다. "
이런 구절이 있는데 이걸 보고 감동 먹었다...........ㅠ_ㅠ.......
사실 나는 라이브러리를 나름 잘 갖다쓰는(?) 인간인데
가끔 몇몇 분들께서 라이브러리를 활용해 구현했다고 하면
그 순간, 그 사람의 능력을 폄하하고 개무시하는 분들이 계신다ㅡㅡ.
물론 혼자 완전 근본의 근본부터 다 짜면 좋겠지.... 인정한다.
하지만 굳이 있는, 좋은 라이브러리를 무시하면서까지 과연 내가 그걸 일일이 다 짜야할 필요가 있을까.
내 궁극적인 목적은 그게 아닌데도?? 제한된 시간은 어쩔건데??
라고 혼자 궁시렁 거리고는 한다 ㅠ_ㅠ....
그런 분들을 꽤 봤기 때문에 나는 - 내가 인정받지 못하는 게 두려우니까 -
되도록이면 라이브러리를 사용했다는 얘기를 많이 숨기는 편이다.
난 적절한 라이브러리를 찾아서 입맛에 맞게 잘 사용하는 것도 능력이고 노력하는 거라고 생각하건만.
(ㅋ 물론 '남이 하면 불륜이고 내가 하면 로맨스'라는 생각일지도 모르겠다)
아무튼 저자님의 저 말씀을 읽고는 왠지 용기를 불끈! 얻었다.
감사합니다. 사랑합니다. 저 힘낼게요.
- 고무 오리 기법 : 실제로 어떤 대학의 컴퓨터 연구실은 프로그램을 디버깅할 때 누군가에게 도움을 요청하기에 앞서
그 문제를 방 한 켠에 놓아둔 곰 인형에게 말로 설명하라는 정책을 가지고 있다고 한다. 놀랍게도 이렇게 문제를
큰 목소리로 말하는 행위가 학생 스스로 해결책을 찾게 도움을 주는 것으로 드러났다.
아마 누구나 저런 경험 있지 않을까 싶다. 타인에게 도움을 청하려고 이런 문제가 있다고 말하다가 갑자기
혼자 해결하고는 싱겁게 대화가 끝나버리는 상황ㅋ
어쨌거나 어떤 프로그램 or 생각을 말로 설명하는 행위는 문제의 틀을 제대로 잡는 데 도움을 준다고 한다.
(4) 코드 분량 줄이기
- 자기 주변에 있는 라이브러리에 친숙해져라 :
""매일 15분씩 자신의 표준 라이브러리에 있는 모든 함수/모듈/형들의 이름을 읽어라.""
(C++ 표준 템플릿 라이브러리 STL, 자바 API, 파이썬 내장 모듈 등)
이 말에 공감하지만.... 매일 읽게 되지는 않는다는 슬픈 현실ㅠ_ㅠ.... 귀차니즘이 죄다.
하지만 저 귀차니즘이 도움이 됐다고 해야될까, 나는 한때 구현하는 게 귀찮아서
자바 API 를 정말 이 잡듯이 뒤지면서 코딩을 했던 적이 있다.
뭐... 좋게 보면 활용 능력이 좋은거고(?) 나쁘게 보면 능력이 없다고 볼 수 있다.
무능력 하다는 소리는 듣기 싫으니 부지런해져야겠다. 아직 경험이 많이 부족하니까 ㅠ_ㅠ 휴 -
<< 4부. 선택된 주제들 >>
(1) 테스트와 가독성
사실 테스트 코드를 따로 작성해 본 경험은 없지만...
이 장에서는 멍청하게 테스트 하는 방법을 똑똑하게 테스트 하는 방법으로 도달하기까지의 과정이
예제를 통해 잘 정리되서 나와있다. 역시 깨알같다. 굳굳.
가독성을 위한 책이다 보니 심플한 게 킹왕짱이다ㅋ
(2) 분/시간 카운터를 설계하고 구현하기
- 앞에서 보았던 내용들이 총집합 되는 예제가 나온다.
코드를 처음부터 잘 짜는 것 보다는 오히려 아름답지 않더라도 우선 작성을 하고
문제점이 뭔지 파악하면서 계속 개선해나가는 방향으로 설명을 한다.
사실 마지막 장의 내용이 잘 이해가 안 간다. 앞에 봤던 코드들에 비해서 코드 양이 많아서
이리저리 정신없이 책을 뒤적이며 코드 이해하다가 조금 짜증이 났다.
그리고 내용도 좀 수준이 있는 것 같다. 설계와 성능에 대해 논하면서 코드를 개선해 나가는데
중상급 개발자 정도는 되야 이 정도 아이디어가 나오지 않을까 하는 생각이 들었다.
배경지식이 좀 필요하다보니... 나같은 허접이 이런 아이디어를 낸다는 건 조금 무리인듯ㅠ_ㅠ
모든 장을 훑다보니 리뷰가 길어졌다.
이 책은 한번 읽었지만 나중에 다시 한번 읽어볼 가치가 있는 것 같다.
내가 이 책을 읽고 과연 이렇게 실행에 옮겼는지 반성하게 되는 의미에서 좋은 책이라고 생각한다.
수학이나 개발 관련 서적이 좋은 게...
원서가 영어라도 수학 기호나 프로그래밍 언어는 누구나 공통으로 알고 있으니
그것을 통해서 이해가 잘 된다는 점이다ㅋ.ㅋ
아무튼 이 책은 실질적으로 도움이 되는 팁이나 조언들이 깨알같이 수록되어 있어 소장가치가 있는 것 같다.
나같은 초급 개발자도 충분히 읽었기 때문에 개발자라면 누구나 읽을 수 있고 ~
책도 300 페이지가 안 되는 책이라 접근성(?)이 뛰어나다고 할 수 있다 ㅋㅋㅋ
읽기 잘 했다는 생각이 드는 책이라 언니에게도 추천해줬다 ㅋ.ㅋ
다음엔 임백준 님이 번역하신 또다른 책을 읽어볼 계획이다!
| 책 리뷰 : 조엘 온 소프트웨어 (0) | 2014.10.12 |
|---|---|
| 책 리뷰 : 실용주의 프로그래머 (0) | 2014.07.04 |
| 책 리뷰 : 코딩 호러의 이펙티브 프로그래밍 (0) | 2014.05.13 |
| 책 리뷰 : 59초 - 순식간에 원하는 결과를 끌어내는 결정적 행동의 비밀 - (0) | 2014.05.12 |
| 책 리뷰 : 코딩 호러가 들려주는 진짜 소프트웨어 개발 이야기 (0) | 2014.05.01 |
Stack, Queue 에 이어서 Linked List.
사실 이걸 먼저 포스팅 했어야 되는데 ㅡ_ㅡ; 어쩌다보니 순서가 바꼈다.
<< Linked List >>
(1) 포인터를 이용하여 데이터를 저장한다.
(2) Array 와는 다르게 물리적 구조가 순차적이지 않다.
Array 의 경우, 메모리에 순차적으로 저장되지만
Linked List 는 포인터를 이용하기 때문에 데이터가 메모리에 순차적으로 저장되어 있지 않다.
(3) Linked List 의 기본 단위는 Node 구조체로 이루어져 있다.
Node 구조체에 데이터와 Link 를 저장해놓는다.
(4) 각 Node 의 생성은 동적 할당으로 이루어지고,
첫번째 Node 를 가르키는 노드인 Header Node 가 존재한다.
(5) Linked List 에는 3가지 종류가 있다.
- Single Linked List / Circular Linked List / Double Linked List
- 각 리스트 별로 삽입(Insert), 삭제(Remove) 연산이 있고,
각 연산 별로 Header / Middle / Tail 에서 일어나는 경우를 살펴볼 것이다.
(이미지 출처 : http://blog.naver.com/zkd1750/90183988309)
연산 처리 과정을 그림으로 이해하기 쉽게 정리하면 좋겠지만
이미 다 배운 내용을 정리하는 차원이라 굳이 그리지는 않겠다. 귀찮다.
1. Single Linked List
(1) Insert
- Header
[Head] -> [A] -> [B] -> [C:Tail] 이런 상태에서
[Head] -> [?] -> [A] -> [B] -> [C:Tail] 로 [?] 라는 노드를 삽입할 것이다.
방법은 간단하다. 다음과 같은 순서로 노드의 삽입이 이루어진다.
① [?].next = [Head].next
② [Head].next = [?]
- Middle
[Head] -> [A] -> [B] -> [C:Tail] 이런 상태에서
[Head] -> [A] -> [B] -> [?] -> [C:Tail] 로 [?] 라는 노드를 삽입할 것이다.
① [?].next = [B].next
② [B].next = [?]
- Tail
[Head] -> [A] -> [B] -> [C:Tail] 이런 상태에서
[Head] -> [A] -> [B] -> [C] -> [?:Tail] 로 [?] 라는 노드를 삽입할 것이다.
① [C:Tail].next = [?]
② [?].next = NULL
(1번과 2번의 순서가 바뀌어도 상관은 없다.)
③ *tail = [?]
(2) Remove
- Header
[Head] -> [A] -> [B] -> [C:Tail] 이런 상태에서 [A] 를 삭제하면,
[Head] -> [B] -> [C:Tail] 이렇게 된다.
① [Head].next = [A].next 또는 [Head].next = [Head].next.next
② [A].next = NULL // ① 연산으로 [A]를 가르키는 노드가 없으니 ① 연산 전에 [A]를 따로 저장
③ free([A])
- Middle
[Head] -> [A] -> [B] -> [C:Tail] 이런 상태에서 [B] 를 삭제하면,
[Head] -> [A] -> [C:Tail] 이렇게 된다.
① [A].next = [B].next 또는 [A].next = [A].next.next
② [B].next = NULL // ① 연산으로 [B]를 가르키는 노드가 없으니 ① 연산 전에 [B]를 따로 저장
③ free([B])
- Tail
[Head] -> [A] -> [B] -> [C:Tail] 이런 상태에서 [C:Tail] 를 삭제하면,
[Head] -> [A] -> [B:Tail] 이렇게 된다.
① free([B].next) // next 가 tail 인 녀석을 찾아서 메모리 해제
② [B].next = NULL
③ *tail = [B]
2. Circular Linked List
(1) Insert
- Header
[Head] -> [A] -> [B] -> [C:Tail] -> [A] 이런 상태에서
[Head] -> [?] -> [A] -> [B] -> [C:Tail] -> [?] 로 [?] 라는 노드를 삽입할 것이다.
① [?].next = [Head].next
② [Head].next = [?]
③ [C:Tail].next = [?]
- Middle
S.L.L 와 동일하다.
- Tail
[Head] -> [A] -> [B] -> [C:Tail] -> [A] 이런 상태에서
[Head] -> [A] -> [B] -> [C] -> [?:Tail] -> [A] 로 [?] 라는 노드를 삽입할 것이다.
① [?].next = [C:Tail].next 또는 [?].next = [Head].next
② [C:Tail].next = [?]
③ *tail = [?]
(2) Remove
- Header
[Head] -> [A] -> [B] -> [C:Tail] -> [A] 이런 상태에서 [A] 를 삭제하면,
[Head] -> [B] -> [C:Tail] -> [B] 이렇게 된다.
① [Head].next = [A].next 또는 [Head].next = [Head].next.next
② [C:Tail] = [Head].next
③ [A].next = NULL // ① 연산으로 [A]를 가르키는 노드가 없으니 ① 연산 전에 [A]를 따로 저장
④ free([A])
- Middle
S.L.L 와 동일하다.
- Tail
[Head] -> [A] -> [B] -> [C:Tail] -> [A] 이런 상태에서 [C:Tail] 를 삭제하면,
[Head] -> [A] -> [B:Tail] -> [A] 이렇게 된다.
① [B].next.next = NULL // next 가 Tail 인 녀석을 찾아보니 [B]. 즉, [B].next = Tail
연산 후 모습 : [Head] -> [A] -> [B] -> [C:Tail]
② free([B].next)
연산 후 모습 : [Head] -> [A] -> [B] -> [ ]
③ [B].next = [Head].next
연산 후 모습 : [Head] -> [A] -> [B] -> [A]
④ *tail = [B]
[Head] -> [A] -> [B:Tail] -> [A]
3. Double Linked List
- previous, next 가 존재해서 조금 귀찮다.
- 어떤 책은 prev / next 로 하는 책도 있고, left /right 로 하는 책도 있는데 전자를 선택하겠다.
- 앞에 보았던 노드의 구조가 [Data, Next] 라면 지금은 [Prev, Data, Next] 정도 되겠다.
(1) Insert
- Header
[Head] ↔ [A] ↔ [B] ↔ [C:Tail] 이런 상태에서
[Head] ↔ [?] ↔ [A] ↔ [B] ↔ [C:Tail] 로 [?] 라는 노드를 삽입할 것이다.
① [?].prev = [Head]
② [?].next = [Head].next
③ [Head].next = [?]
④ [?].next.prev = [?]
- Middle (Header 와 똑같다고 보면 된다)
[Head] ↔ [A] ↔ [B] ↔ [C:Tail] 이런 상태에서
[Head] ↔ [A] ↔ [?] ↔ [B] ↔ [C:Tail] 로 [?] 라는 노드를 삽입할 것이다.
① [?].prev = [A]
② [?].next = [A].next
③ [A].next = [?]
④ [?].next.prev = [?]
- Tail
[Head] ↔ [A] ↔ [B] ↔ [C:Tail] 이런 상태에서
[Head] ↔ [A] ↔ [B] ↔ [C] ↔ [?:Tail] 로 [?] 라는 노드를 삽입할 것이다.
① [?].prev = [C:Tail]
② [?].next = NULL
③ [C:Tail].next = [?]
④ *tail = [?]
(2) Remove
- Header
[Head] ↔ [A] ↔ [B] ↔ [C:Tail] 이런 상태에서 [A] 를 삭제하면,
[Head] ↔ [B] ↔ [C:Tail] 이렇게 된다.
① [Head].next = [A].next 또는 [Head].next = [Head].next.next
② [Head].next.prev = [Head]
③ [A].prev = NULL // ①, ② 연산으로 [A]를 가르키는 노드가 없으니 ① 연산 전에 [A]를 따로 저장
④ [A].next = NULL
⑤ free([A])
- Middle (Header 와 똑같다고 보면 된다)
[Head] ↔ [A] ↔ [B] ↔ [C:Tail] 이런 상태에서 [B] 를 삭제하면,
[Head] ↔ [A] ↔ [C:Tail] 이렇게 된다.
① [A].next = [B].next 또는 [A].next = [A].next.next
② [A].next.prev = [A]
③ [B].prev = NULL // ①, ② 연산으로 [B]를 가르키는 노드가 없으니 ① 연산 전에 [B]를 따로 저장
④ [B].next = NULL
⑤ free([B])
- Tail
[Head] ↔ [A] ↔ [B] ↔ [C:Tail] 이런 상태에서 [C] 를 삭제하면,
[Head] ↔ [A] ↔ [B:Tail] 이렇게 된다.
① [B].next.prev = NULL // next 가 Tail 인 녀석을 찾아보니 [B]. 즉, [B].next = Tail
② free([B].next)
③ [B].next = NULL
④ *tail = [B]
# Linked List 사용 사례 :
- Stack, Queue, Tree 구현할 때 사용될 수 있다.
- 많이 쓰이기는 하는데 막상 사용 예제를 검색해보면 딱히 나오지는 않는 것 같다...
아, 드럽게 많네.
그림 별로 안 올려도 포스팅 하는데 겁나 오래걸린다ㅠㅠ
( + 이 포스팅에서 free 나 *tail 은 C언어로 쓰인 자료 참고하느라 추가했다.
원래 Java 로 코드를 한번 짜봤었는데 C 로는 안 해봐서 조금 지저분해도 써봤다. )
| [C]printf()에서 "%ul"와 "%lu"의 차이? (0) | 2015.07.05 |
|---|---|
| 언리얼엔진4 : DataTable 오브젝트 생성하기 (0) | 2014.09.22 |
| Delegate (대리자) (1) | 2013.12.20 |
| [Python, C#]Lambda Form (0) | 2013.12.19 |
| PHP vs. Ruby vs. Python (0) | 2013.12.19 |
기본단축키
파일 작업 관련 단축키
[ Ctrl + N ] : 새 캔버스 만들기
[ Ctrl + O ] : 파일 불러오기
[ Alt + Ctrl + O ] : Adobe Bridge 실행하기
[ Ctrl + W ] : 현재 캔버스 닫기
[ Alt + Ctrl + W ] : 모든 캔버스 닫기
[ Ctrl + S ] : 현재 파일 저장하기
[ Shift + Ctrl + S ] : 다른 이름으로 저장하기
[ F12 ] : 처음 상태로 되돌리기
[ Ctrl + P ] : 인쇄하기
[ Ctrl + Q ] : 포토샵 프로그램 종료하기
브러시 관련 단축 키
[ Ctrl + Z ] : 바로 직전에 실행한 작업 취소하기
[ Ctrl + Alt + Z ] : 작업 여러 번 취소하기
[ , ] : 브러시 목록에서 이전 브러시 선택하기
[ . ] : 브러시 목록에서 다음 브러시 선택하기
[ X ] : 전경색/배경색 전환하기
도구 사용 단축키
[ Alt + 도구 선택 ] : 숨어 있는 도구 선택하기
[ Eyedropper Tool + Alt를 누른 채 클릭 ] : 배경색으로 지정
[ Spacebar ] : 임시로 Hand Tool 사용하기
[ Ctrl] :임시로 Move Tool 사용하기
[ Ctrl + Spacebar ] : 임시로 Zoom Tool(+) 사용하기
[ Alt + Spacebar ] : 임시로 Zoom Tool(-) 사용하기
선택 영역 관련 단축키
[ Ctrl + A ] : 이미지 전체 영역을 선택하기
[ Ctrl + Shift + D ] : 마지막으로 지정하였던 선택 영역 다시 선택하기
[ Shift + 드래그 ] : 정 비율로 선택하기
화면 조작 관련 단축키
[ Tab ] : Tool 패널, 패널 감추기/나타내기
[ Shift + Tab ] : 패널만 감추기/나타내기
[ Ctrl + + ] : 화면 확대하여 보기
[ Ctrl + - ] : 화면 축소하여 보기
[ Ctrl + R ] : 눈금자 나타내기/감추기
[ Ctrl + ; ] : 안내선 나타내기/감추기
[ Ctrl + Alt + ; ] : 안내선 잠그기
[ Ctrl + ' ] : 그리드 나타내기/감추기
[ Ctrl + H ] : 표시자 보이기/감추기
[ Shift + Ctrl + ; ] : 스냅 선택/해제하기
[ F ] : 윈도우 모드 변경하기
[Ctrl + 0] : Fit on Screen
레이어 작업 관련 단축키
[ Ctrl + Shift + N ] : 새 레이어 만들기
[ Ctrl + E ] : 아래 레이어와 합치기
[ Ctrl + G ] : 선택한 레이어를 그룹에 넣기
[ Ctrl + Shift + G ] : 그룹 해제하기
이미지 보정 관련 단축키
[ Ctrl + L ] : Levels 대화상자 불러오기
[ Ctrl + Shift + L ] : Auto Levels 적용하기
[ Ctrl + Alt + Shift + L ] : Auto Contrast 적용하기
[ Shift + Ctrl + B ] : Auto Colors 적용하기
[ Ctrl + M ] : Curves 대화상자 불러오기
[ Ctrl + B ] : Color Balance 대화상자 불러오기
[ Ctrl + U ] : Hue/Saturation 대화상자 불러오기
[ Ctrl + Shift + U ] : Desaturate 적용하기
[ Ctrl + F + I ] : 이미지의 색상을 반전하기
[ Ctrl + F ] : 마지막에 적용한 필터 반복 적용하기
패널 관련 단축키
[ F5 ] : BRUSHES 패널 열기/닫기
[ F6 ] : COLORS 패널 열기/닫기
[ F7 ] : LAYERS 패널 열기/닫기
[ F8 ] : INFO 패널 열기/닫기
[ F9 ] : ACTION 패널 열기/닫기
선택 영역이 지정된 상태에서 사용하는 단축키
[ Ctrl + D ] : 지정된 선택 영역 해제하기
[ Shift + 드래그 ] : 선택 영역에서 추가로 더 선택하기
[ Alt + 드래그 ] : 선택한 영역의 일부분 빼기
[ Ctrl + Shift + I ] : 선택 영역 반전시키키
[ Ctrl + T ] : 선택 영역의 이미지 변경하기
[ Ctrl + C ] : 선택영역의 이미지 복사하기
[ Ctrl + X ] : 선택 영역의 이미지 오려내기
[ Ctrl + Alt + 드래그 ] : 선택 영역의 이미지 복사하여 이동하기
[ Ctrl + 드래그 ] : 선택 영역의 이미지 오려서 이동하기
[ Alt + Delete ] : 선택 영역에 전경색 채우기
[ Ctrl + Delete ] : 선택 영역에 배경색 채우기
[ Alt + Shift + Delete ] : 투명 영역을 보호하면서 전경색 채우기
[ Alt + I + P ] : 선택 영역의 이미지만 남기고 자르기
[ Ctrl + 방향키 ] : 선택 영역의 이미지를 오려서 픽셀 단위로 이동하기
[ Shift + 방향키 ] : 선택 영역의 위치를 10픽셀 단위로 이동하기
[ Shift + Ctrl + 방향키 ] : 선택 영역의 이미지를 오려 10픽셀 단위로 이동하기
[ Ctrl + J ] : 선택 영역의 이미지를 복사하여 새 레이어로 만들기
[ Ctrl + Shift + J ] : 선택 영역의 이미지를 잘라서 새 레이어로 만들기
| Google Syntaxhighlighter (0) | 2014.05.19 |
|---|
출처 : http://www.hoons.net/board/asptip/content/30981
- 위 출처에 나와있는 포스팅 내용을 요약하여 정리하였다.
먼저 들어가기 전 용어 정의.
<< Terminology >>
Method : 클래스에서 사용되어지는 함수 형태
Function : 일반 C언어나 Script 에서 사용되어지는 함수 형태
Function Pointer : 일반 C언어나 Script 에서 사용되어 지는 함수 포인터
위 포스팅한 분이 정리해놓은 Delegate 에 대해 정의하자면
- 특정한 때에 조건에 부합한 특정 클래스의 Method 를 실행
- 언제 무엇이 실행될 지 모를 때 사용하는 것
ex ) 유언장과 유언장을 집행하는 대리자
: 유언장에 죽은 후 해야 할 몇 가지 Method(유언) 들을 적어 놓고, 이 Method 들이 언제 실행될까?
정답은 '아무도 모른다'이다. 예를 들어 대리자 입장에서 유산이 얼마 없는데 백억을 후손에게 물려줘야 된다고
유언장에 적혀있다면 그 유언은 실행되지 않을 것이다. 즉, 조건이 맞아야 그 Method 를 실행시킬 수 있다.
위 예제를 다시 요약하면 패러미터 타입과 리턴 타입이 동일 + 성립된 조건 하에 어떤 Method 든지 실행이 가능하다.
특정한 때에.
=> 여기서 '이벤트'를 떠올린다.
delegate 선언을 보면,
delegate void SimpleDelegate();
밑줄 친 부분을 보면 클래스의 Method 로 보이고, C언어라면 함수의 형태를 띄고 있다고 할 수 있다.
But, 객체지향 언어는 클래스 기반이라 C언어에 있는 함수라는 게 존재하지 않아 위와 같은 형태로 사용하는 것은 불가능!
그런데...... "delegate 는 클래스처럼 인스턴스를 생성시킬 수 있다."
SimpleDelegate simpleDelegate = new SimpleDelegate();
클래스가 아님에도 하나의 함수가 마치 클래스처럼 동작한다는 점.
-> 왜 이렇게 동작을 시켜야 하는지, 필요한 이유가 무엇인지
: 이벤트로 인해 일반적으로 "클래스가 아닌 특정한 때에 특정 Method 만을 호출" 할 수 있는
무언가가 필요하기 때문. 그 무언가가 'delegate' 이다.
아래 예제를 보자.
eTest.ckEvent += new evnetDelegate(MainClass.Click);
이벤트가 발생해 특정 Method 만을 호출하고 그 Method 에 개발자가 원하는 동작을 하도록 코딩을 한다.
실제 동작하는 코드가 있는 Method 는 MainClass.Click 인데 이 경우 MainClass 에 대한 참조가 필요하다는 것이다.
클래스가 아닌 저 Click 이벤트 핸들러에서 정의된 메소드만 필요하건만,
객체지향 에서는 저 메소드 하나때문에 불가피하게 MainClass 를 생성할 수 밖에 없다는 거......
delegate 가 필요한 이유를 잘 읽어보면,
C 에서의 함수 포인터와 C# 의 delegate 는 사실상 같다고 볼 수 있다.
C에서의 함수 포인터란 ?
- 함수가 존재하는 메모리의 주소를 가리키는 특수한 변수. 또한 실행(호출)도 가능하다.
delegate 는 Method 를 실행시키고 함수포인터는 함수를 실행시킬 뿐 사실상 같은 역할을 하고 있다.
<< Delegate 사용법 >>
참고로 위 코드를 보면 알겠지만 Delegate 는 MainClass.Click 과 같이 일반화된 메소드 역시 참조할 수 있다.
또한 하나의 Delegate로 여러 개의 메소드를 동시에 참조할 수 있다 : Delegate.Combine()
그리고 Combine 된 참조를 해제할 수 도 있다 : Delegate.Remove() 또는 '-=' 연산자
Calculate calc;
calc = delegate(int a, int b){ return a + b; } // 이렇게 익명 메소드로도 사용할 수 있다.
delegate myDel = (int a, int b) => a+ b; // 람다식 사용도 가능
| 언리얼엔진4 : DataTable 오브젝트 생성하기 (0) | 2014.09.22 |
|---|---|
| 자료구조 : Linked List (0) | 2014.04.25 |
| [Python, C#]Lambda Form (0) | 2013.12.19 |
| PHP vs. Ruby vs. Python (0) | 2013.12.19 |
| HTML5 Canvas Element 를 사용할 때 주의할점 - drawImage() 관련 (2) | 2013.01.11 |
람다식 (Lambda Expression)
- A lambda expression is an anonymous (익명인) function
tha you can use to create delegates or expression tree types.
- 람다 연산자 : '=>'
- 귀차니즘(?)으로 인해 생겨났다는... 점잖게 얘기하자면 번거로움을 줄이기 위해 생겨났다는 람다식.
어떤 번거러움을 덜어주는 지에 대한 예제를 가져와봤다.
출처 : http://rintiantta.blog.me/40115460090
C#
static void Main(string[] args)
{
List<string> list = new List<string>()
{
"A", "B", "C", "D", "E", "F"
};
Console.WriteLine( (list.Where(data => data.Contains("A"))).Count() ); // 1
}
List 에는 Where 라는 메소드가 있고, 그 메소드는 조건에 맞는 녀석들을 뽑아서
다시 배열로 만들어 주는 메소드 입니다. 패러미터로 Func<string, bool> predicate 를 받는데
뜻은 string을 인자로 주면 bool 로 리턴한다는 뜻이랍니다.
저렇게 람다식을 바로 안 넣고 패러미터를 string을 받고 bool로 리턴하는 메소드를 따로 만들어
그 메소드를 predicate 로 넣어도 되지만 저렇게 간단한 메소드인 경우
메소드를 따로 정의하기엔.. 코드도 길어지고 귀찮기도 하겠죠ㅎㅎ
static void Main(string[] args)
{
int[] numbers = { 5, 4, 1, 3, 9, 8, 6, 7, 2, 0 };
int oddNumbers = numbers.Count(n => n % 2 == 1); // Count 메소드도 위 Where 메소드와 비슷합니다
Console.WriteLine(oddNumbers); // 5, 1, 3, 9, 7
}
C# 람다식 문법
( 출처 : http://msdn.microsoft.com/ko-kr/library/bb397687.aspx )
delegate int del(int i);
static void Main(string[] args) { del myDelegate = x => x * x; int j = myDelegate(5); // j = 25 }
1. C# Expression Lambda :
(input parameters) => expression
왼쪽 괄호는 매개 변수가 1개일 경우, 생략가능
ex )
x => x * x
(x, y) => x == y(int x, string s) => s.Length > x
() => SomeMethod() : 입력 매개 변수가 0개 일 경우
2. C# Statement Lambda :
(input parameters) => {statement;}
ex )
delegate void TestDelegate(string s);
...
TestDelegate myDel = n => { string s = n + " " + "World"; Console.WriteLine(s); };
myDel("Hello"); // Hello World
3. Asynchronous Lambda
4. 람다 식의 변수 범위
- 3, 4 번 관련 내용은 위 C# 람다식 관련 출처 링크를 통해 보는 게 나을듯.
Python 람다식 문법
( 출처 : http://www.trypython.org/#part2-page4 ) : ctrl + c, v 가 안 되는 이 슬픔..
>>> def make_incrementor(n) :
return lambda x : x + n
...
>>> f = make_incrementor(42)
>>> f(0)
42
>>> f(1)
43
쌩뚱맞게 C# 이랑 Python 람다식 문법을 가져온 이유는..
람다식에 대한 내용을 Python 공부하다가 어쩌다 발견하게 되었고 예제 또한 이해가 잘 되서 가져왔다.
C# 의 경우 delegate(대리자) 과 관련되서 람다식이 나오는 것을 보고 가져와봤다.
대리자 관련 포스팅도 따로 할 예정.
| 자료구조 : Linked List (0) | 2014.04.25 |
|---|---|
| Delegate (대리자) (1) | 2013.12.20 |
| PHP vs. Ruby vs. Python (0) | 2013.12.19 |
| HTML5 Canvas Element 를 사용할 때 주의할점 - drawImage() 관련 (2) | 2013.01.11 |
| jQuery : css() 그리고 jQuery UI 소개 (0) | 2013.01.02 |
얼마 전에 Ruby 와 Python 어떤 Script Language 를
공부해볼까 고민하면서 이것저것 고민해보다가
여러 좋은 자료들을 발견해서 블로그에 정리해본다 :D
조금 오래된 자료이지만 도식화 되있어서 보기 편리하다는 장점ㅎㅎ
개인적으로는 PHP 가 가장 경험많고, Python 은 진짜 맛 보기만 해봤고 Ruby 는 전혀..경험이 없다.
Ruby 를 웹에서 간단하게 해볼 수 있는 유용한 사이트가 있다.
사이트 디자인도 제법 귀여운 요소가 많아서 좀 의외.(좀 일본느낌나지만)
http://tryruby.org/levels/1/challenges/1 : Script 언어 처음이신 분은 조금 신세계 일지도.
Ruby 와 Python 을 비교해놓은 오래된 포스팅도 발견.
일단 링크는 적어놓지만.. 마지막 포스팅이 2009 년이라 언제 없어질지 모르는 자료라서 여기에 옮겨놓는다.(죄송ㅠㅠ)
http://nextcontext.tistory.com/17 : 아래 접어놓은 글 중에 링크들은 안 긁혀져서 여기 링크를 통해야 된다.
Ruby 의 경우 개발자들을 위해 만든 언어라서 그런지 생각보다 한번 빠지신 분들은 깊은 충성도(?)를 자랑하는 듯 했다.
Python 은 Google 의 3대 개발 언어 중 하나이고, 지금은 어떤지 모르나 위의 Performance 표를 비교해 보면
확실히 눈에 띌 정도로 High Performance 를 자랑한다. 안정되면서도 뛰어난 성능을 자랑하니
개인적으로 선호하는 건 Ruby 이지만.. Python 을 더 공부하는 게 나을 것 같은.. 애매한 생각이 든다.
| Delegate (대리자) (1) | 2013.12.20 |
|---|---|
| [Python, C#]Lambda Form (0) | 2013.12.19 |
| HTML5 Canvas Element 를 사용할 때 주의할점 - drawImage() 관련 (2) | 2013.01.11 |
| jQuery : css() 그리고 jQuery UI 소개 (0) | 2013.01.02 |
| jQuery : val(), text(), html()의 차이 (2) | 2013.01.02 |
인턴하면서 WPF 프로그래밍을 접해봤고, MVVM 패턴이라는
디자인 패턴을 처음 접해보았다.
학교에서 배운 디자인 패턴들도 있었으나 그 패턴들을
직접 코딩해보면서 알아가지 않아 확실히 느낀 바가 없어서
배워도 그게 뭐였더라 하면서 애매했었는데 이번 기회에 정리해보려고 한다 :D
그림이 쬐끔해서 엄청 마음에 안듦
위 그림들을 서술형으로 정리해보자면
MVC (Model - View - Controller)
- Controller 에 직접 Input
- View 와 Controller : Many to One 관계
- View 는 Controller 를 참조하지 않음
- Model 은 View 를 간접적으로 참조함
- > Controller 에 입력이 들어오면 Controller 는 Model 에 있는 Data 를 조작하고, View 는 Model 에서 조작된 data 를
참조하여 View 를 수정한다. 이 때 View 가 Model 을 참조하거나 Model 이 View 를 참조하거나 하는 방식으로
변화에 대한 업데이트를 할텐데 결국 View 와 Model 이 참조를 할 수 밖에 없다는 이야기.
MVP (Model - View - Presenter)
- View 에 직접 Input
- View 와 Presenter : One to One 관계
- View 는 자신의 Presenter 를 참조하고 Presenter 역시 View 를 알고 있음
- View 는 Model 를 참조하지 않아 Presenter 를 통해 Model 을 업데이트함
-> View 에 입력이 들어오면 Presenter 에 data 를 요청하고, Presenter 는 자신이 참조하는 Model 에 업데이트를
요청하는 방식으로 동작한다. 이 경우 View와 Model 은 완벽히 분리되지만 View 와 Code 가 완벽히 분리됐다고
보기는 어렵다.
MVVM (Model - View - ViewModel)
- View 에 직접 Input
- View 와 ViewModel : Many to One 관계
- ViewModel 은 View 를 참조하지 않음
- View 는 Model 를 참조하지 않아 ViewModel 를 통해 Model 을 업데이트함
-> View 에 입력이 들어오면 View 가 참조하고 있는 ViewModel 에서 Binding 된 객체를 찾아 업데이트를 한다.
MVP 패턴에서는 Presenter 는 전적으로 View 의 형태에 따라 달라지지만,
MVVM 패턴에서는 ViewModel 이 View 를 참조하지 않으므로 Model 의 형태를 따른다고 할 수 있다.
View 는 Model 과 완벽히 분리되며 ViewModel 과도 Binding 을 통해 자동 업데이트 되므로 data 와도 완벽히 분리된다.
ex )
- .xaml (xaml의 .cs 파일에서 DataContext 프로퍼티를 참조할 ViewModel 로 Set)
<TextBlock Text={Binding TestText} />
- ViewModel.cs
private string _testText = "";
public string TestText
{
get { return _testText; }
set { _testText = value; OnPropertyChanged("TestText"); }
}
- 참고 자료
1. 선배님 발표자료 'WPF / MVVM 소개'
2. http://geekswithblogs.net/dlussier/archive/2009/11/21/136454.aspx
| Head First : Design Patterns - 제5강 : Singleton 패턴 (0) | 2014.05.20 |
|---|---|
| Head First : Design Patterns - 제4강 : Factory 패턴 (0) | 2014.05.19 |
| Head First : Design Patterns - 제3강 : Decorator 패턴 (0) | 2014.05.18 |
| Head First : Design Patterns - 제2강 : Observer 패턴 (0) | 2014.05.16 |
| Head First : Design Patterns - 제1강 : Strategy 패턴 (0) | 2014.05.16 |
RECENT COMMENT