The Day

어제 새로 이사 온 Fairview Crescent의 내 집엔 아직 룸메들이 안 들어와서 현정이랑 같이 지내고 있다.
오늘 12: 30분에 있던 마이크로소프트 전화 인터뷰는 걱정 했던 것 보단 평이했다는 느낌이야. 예를 들면,

• 스트링에 있는 문자 중 중복 된 것 찾기
• 링크드 리스트의 가운데 노드 찾기
• 키보드를 테스트 하게 된다면 어떻게 할 것인가. (시간과 자원이 무한하다는 가정)
  

• 컴퓨터를 하는 이유.
• 컴퓨터에 처음 발을 들이게 된 계기
  

내가 관심 있다고 했던 Business solution 쪽으로 내 정보를 보낸다고 하니 난 NTCU에서 즐기며 기다려야지 =)
다만, 혹시 내가 질문의 뒤에 숨은 의도를 파악하지 못한 건 아닐까 하는 우려 정도?
실수도 하고 완벽하진 않았던 인터뷰였지만, 나와 통화 했던 그녀가 나의 열정과 관심을 알아 주셨으면 하는 희망으로 기분 UP 해야지 =) 인터뷰 준비한다고 자료 구조나 알고리즘, 퀴즈 같은 것을 보는 자체로도 재미있었어 ^~^* 마이크로소프트, 정말이지 매번 내 편견을 깨는 구나. 인터뷰 문제들이 식상하지가 않아.. 내 스타일이야 ㅋㄷ 여행 하면서 심심할 때 생각해 볼 만한 문제들~

우박이 쏟아졌다가 개었다가 비가 한 바탕 내렸다가 개었다가 하는 변덕스러운 날씨에도 불구하고 피곤한 몸을 이끌고, Northwestern Technology Conference에 갔는데 생각보다 적은 수의 학생들이 있었어. 대략 서른명 남짓? 그래도 좋아. 왜냐하면 오히려 더 단란하게 행사를 보낼 수 있으니까. 내일과 모레 있을 컨퍼런스가 기대돼 ^~^*
일찍 일어나야지!!
꺄악!! 재밌어 재밌어!! 오늘도 즐거운 하루였다. =p

성공으로 가는 직급별 목표

[중앙일보 JOBs] 부장급 대리, 대리급 부장…꿈과 뜻이 가른다 [본문 보기]

직급이나 연차가 낮을 때는 열정과 성실함을 바탕으로 일을 배워 나가는 자세가 중요하지만 직급이 높아지면 전문성과 핵심 역량을 쌓고 리더십을 키워야 한다.

인크루트 신상훈 컨설턴트는 "20년 뒤 꿈꾸는 모습을 정하고 그 목표에 이르기 위해 지금 무엇을 해야 하는지 역산해 계획을 짠 뒤 1년 단위로 현 위치와 목표를 비교.점검하라"고 조언했다.

대리 직급부터는 스스로 판단해야 할 상황이 점점 많아진다. 기안과 프레젠테이션도 직접 해야 한다.

• 기초단계-커리어 로드맵을 그려라
• 신입사원부터 대리급까지는 업무에 관한 기본 지식과 실무를 익히면서 직장 예절, 부서 간 커뮤니케이션 능력, 조직 문화를 배우는 때다. 일이 적성에 맞는지 살펴보는 것도 중요하다. 관심과 소질, 장래성과 전문성, 임금 등을 고려해 판단한다. 이 시기는 직장을 옮기기 수월하고 '몸값'을 높일 수 있다.

• 개발 단계-자신만의 핵심 능력 갖춰라
• 고급화 된 직무를 하면서 기초적인 관리 능력도 보여 줘야 하는 시기. 계획과 목표를 세우고 달성할 수 있는 리더로서의 자질을 키워야 한다. 온.오프라인 커뮤니티에 참여해 인맥을 쌓으면 든든한 재산이 된다. 핵심 역량을 개발해야 한다.

• 숙련 단계-프로필을 관리하자
• 부장급과 초기 중역급은 회사에 수익을 창출할 수 있는 사람이라는 것을 입증해야 한다. 쌓아온 역량을 효과적으로 통합해 운영 능력을 극대화하는 작업이 필요하다. 업무를 스스로 개발하고 지시나 도움 없이 과제를 해결해 나갈 수 있어야 한다. 후배 구성원들의 신뢰와 지지도 상당히 중요하다. 리더의 자격을 갖췄다는 것을 보여 줘야 한다.임원이 되기 이전에 미리 프로필에 넣을 만한 이력이나 경력을 쌓을 필요가 있다.
  

• 마스터링 단계-전략적 사고 필요
• 고위 임원 또는 경영진에 가장 필요한 것은 전략적 리더십과 비즈니스 오너십이다. 비즈니스 오너십이란 당장 사장이 되더라도 기업을 충분히 이끌어갈 만한 수준의 사업에 대한 이해와 통찰력을 말한다. 이때부터 사업의 큰 그림을 보는 능력이 요구된다.
• 자기 담당이 아닌 다른 부서의 돌아가는 사정도 파악해 전체 회사 업무의 윤곽을 알고 있어야 한다. 현재 속한 비즈니스 영역을 뛰어넘는 응용력과 전략도 보여 줘야 한다. 회사를 책임지고 이끌어 나갈 수 있는 후진 양성이 가장 중요한 임무
  

박현영 기자

“코앞의 성공만 보는 모범생 여직원 너무 많아”

박선이 전문기자의 커리어우먼 탐구 [기사 읽기]


아무리 똑바로 걸어가려고 해도 고개 푹 숙이고 한 치 앞만 보고 걸어가면 당초 의도했던 곳과는 다른 곳에 도착하게 된다. 우리의 몸은 완전한 대칭이 아니기 때문에 한 쪽으로 걸음걸이가 치우치기 때문이다.
마찬가지로 Career를 만들어 나갈 때도 당장 내 손바닥 안에 들어오는 것 만을 보고 결정한다면 결국 내가 진실로 원하는 것을 잃을 수가 있다.
저기 목표의 깃발을 바라보며 당당히 걸어나가자.
멀리 보면 종국에는 지향점에 도달할 수가 있다.

To Make Better Programs

1. Fully Understand Customer's Needs
• 고객, 즉 사용자가 무엇을 원하는지 파악하는 것이 중요하다. 아무리 좋은 기능이라고 해도 당신의 고객이 원하지 않는다면 가치가 없다.
  
2. Scheduling: According to The Mythical Man-Month, you may spend time for
   Design (1/3), Coding (1/6), Component testing (1/4), and System testing (1/4). That means Design (4) : Coding (2) : Component testing (3) : System testing (3)
• Brooks law에 따르면 늦어진 프로젝트에 사람을 충원하는 것은 프로젝트를 더욱 느리게 만들 뿐이다. 대게 실제 코딩을 하는 데 대부분의 시간을 쓴다고 생각하지만 실제 코딩은 1/6의 시간을 차지하는 것이 적당하다. 그리고 테스트에 전체의 1/2의 기간이 소요된다.
  
3. Communication Between Team Members
• Class들의 Cohesion(응집성)만 중요한 것이 아니다. 조직행동론에 따르면 높은 Cohesion을 보이는 팀은 높은 성과를 내거나 낮은 성과를 낸다. (반면, 응집력이 작은 팀은 약간 좋은 성과를 내거나, 약간 낮은 성과를 낸다.) 성패를 좌우하는 것은 탁 팀원들의 공통 목표를 제대로 인식하고 goal을 향해 나아가는 가이다.
  
4. Exactly Understand What Problem Is
• 해결해야 하는 문제가 무엇인지 올바로 파악해야, 문제를 풀 수 있다.
  
5. Appropriate Software Design (using Design Patterns)
• 문제에 적절한 디자인 패턴을 이용한다. 자신이 알고 있는 디자인을 Golden hammer로 모든 곳에 적용하려 해서는 안 된다. (Golden hammer와 Anti-pattern을 참고.)
  
6. Spiral Design Process: Waterfalls model은 지양해야 한다.
   Star lifecycle model, simple interaction design model, simple interaction design model, usability engineering lifecycle 등 Evaluation을 강조한 다양한 Design process가 있다.
   
   
• Spiral model (Waterfalls model을 사용하지 말라.)
• Interface Design and Usability Engineering
7. Make a couple of scenarios
• 예상되는 사용 시나리오를 몇 개 작성해 본다. 프로그램이 어떻게 사용 될지, 어떻게 사용자, H/W, 시스템이 서로 영향을 미칠지 구체적으로 기술한다.
  
8. Understand What I have to do for a project, by attending meetings.
• 특히 팀으로 진행 되는 경우, 각자의 역할이 무엇인지 명확하게 설정 되어 있어야 서로 overlap되지 않아 효율을 높일 수 있다.
  
9. Cohesion and Decoupling (especially for OOP)
• OOP의 기본 개념이다. 보다 maintainable한 프로그램을 위한 조건이다. 프로그램을 디자인할 때 염두해야 한다.
  
10. Documentation (Comments, API, Javadoc, helper methods, etc.)
• 이 역시 maintainable한 프로그램을 위한 조건이다. 덧붙여 프로젝트가 진행 됨에 따라 개발자가 교체되거나 개발팀 외부의 사람과 대화 할 때 유용하다.
  

Figure. Spiral model: www.swc.scipy.org/lec/dev01.html
Figure. Interface Design and Usability Engineering: http://grouplab.cpsc.ucalgary.ca/saul/481/

Hyun Jung's Life: Presentation Tips

1. Presentation 순서를 잘 구성한다.
   
1. 주제 및 팀 소개
2. 다룰 내용 (Contents)
3. 논리적으로 결론을 유도할 수 있는 짜임새 있는 내용 구성.
4. Conclusion or Summary
5. Q & A
• 논리의 흐름이 있어야, 청중을 설득시킬 수 있다.내용을 언급하는 타당한 이유가 있어야 청중의 질문에 명확한 답을 줄 수 있는 것이다. 이것 저것 자료 검색한 것을 순서 없이 붙여 넣으면 안 된다는 것이다.
  
2. 배경 색은 밝고 글씨는 진한 색으로 한다.
• 어두운 배경은 자칫 차갑고 지루한 느낌을 줄 수 있고 글씨 읽기가 힘들 수 있으니 주의한다. 의외로 흰색 등의 밝은 배경이 professional 해 보일 수 있다. 하지만 너무 허전해 보이지는 않도록 한다.
  
3. Histogram (막대그래프)을 사용한다.
   
• 시각적으로 한 눈에 자료의 의미를 전달하기 위해서는 글 보다 표가 더 좋고, 표 보다 Histograms이 더 좋다. (pie graph는 사용하지 말란다. 왜냐하면 카테고리들의 관계 비교가 비교적 어렵기 때문이다.
4. 한 슬라이드에 약 7줄, 한 줄에 약 7 단어를 넘기지 않는다.
   
• 한 슬라이드에 많고 작은 글씨를 쓴다고 누가 다 읽겠는가. 중요한 시각적 데이터와 아웃라인만 잡아주도록 한다.
  
5. 각 슬라이드의 아래에 출처를 적어주는 것이 좋다.
• 맨 뒷장에 Appendix를 사용하기 보다는 각 슬라이드 아래에 신빙성 있는 출처를 적어준다.
6. Presentation 하는 동안, 3초씩 eye contact을 한다.
• 슬라이드만 바라보고 읽어서는 청중을 설득하기가 힘들다. 눈을 보라. 그리고 메시지를 전달하라. 그러나 굳이 부정적인 표정의 관객을 볼 필요는 없다. 긍정적인 반응을 보이는 사람을 보는 것이 긴장감을 줄여줄 것이다.
  
7. 발표 중 약간의 gesture를 더하면 자연스럽게 해 준다.
   
• 발표 시 조금씩 자리를 이동하며 약간의 몸짓을 더하면 긴장하지 않은 것처럼 보이게 한다. 또한 한 자리에 계속 서 있는 발표자를 계속 바라보는 것은 발표를 보는 입장에서도 지루하다.
  
8. 중요한 부분에선 과감하게 강조!
• Presentation도 한 편의 (연)극과 같다. 발표의 강약을 준다. 차트를 직접 손으로 가리키며 힘주어 설명하는 것도 프로페셔널 해 보인다.
9. 시각적 효과를 더한다.
• 적당한 애니메이션 효과, 내용과 관련된 클립 아트, 관련 (제품) 사진 등을 추가하여 보는 이에게 재미를 주고 집중할 수 있게 해준다.
  
10. 배경에 직선 보다 곡선을 사용하면 looks good~*
• Windows 95와 Windows XP를 떠 올려 보아라.
  

Bugs 헤는 밤

H. Park

Green line이 지나가는 화면에는

Breakpoint로 가득 차 있습니다.

나는 아무 걱정도 없이
class 속의 함수들을 다 'Step Into' 할 듯합니다.

Variables view에 하나 둘 변해가는 변수를

이제 다 못 헤는 것은
쉬이 'Source not found.' 가 되는 까닭이요,
내일 밤이 남은 까닭이요,
아직 나의 개발이 다하지 않은 까닭입니다.

변수 하나에 int와
변수 하나에 double과
변수 하나에 boolean과
변수 하나에 String과
변수 하나에 null과
변수 하나에 Scanner, Scanner.

Scanner(System.in), 나는 변수 하나에 아름다운 값 한 마디씩 assign합니다.
밤을 새고 아침을 같이 먹던 동기들의 이름과, 존(John), 헐먼(Herman), 사이먼(Simon).
이런 이국 훈남들의 이름과, 벌써 신입사원 된 계집애들의 이름과,
KU-UBC 사람들의 이름과, 꾀꼬리, 매, 뜸부기, 까치, 왜가리,
빌 게이츠, 스티브 폴 잡스, 이런 거물들의 이름을 assign합니다.

이네들은 너무나 멀리 있습니다.
TestCase의 끝이 아스라이 멀 듯이.
그리고, 당신은 throws Exception 하십니다.

나는 무엇인지 그리워
이 많은 함수가 정의된 class 위에
내 이름자를 써 보고
Javadoc으로 만들어 버리었습니다.

딴은, 밤을 새워 발견되는 bugs는
부끄러운 주소를 참조하는 까닭입니다.

그러나, midterm이 지나고 나의 학기에도 final이 오면,
밤샘 후에 피부 트러블이 시작되듯이
내 이름자 적힌 성적표 위에도
자랑처럼 에이풀이 무성할 거외다.

- 화면과 호출과 변수와 null, Eclipse SDK 3.2.0

An Origami

네가 오랜 시간 공을 들여 어렵사리 만들어 놓은 Application을 보여주었어. 그런데 그가 어떻게 다뤄야 하는지 어떻게 반응해야 하는지 알아채지 못하고 계속 이리저리 헤매이고 있으면 넌 섭섭해 질거야. 조금 후엔 답답해지기도 할테고,

'어떻게 모를 수 있어. 혹시 바보 아니야?'

라며 화를 낼 수도 있겠지. 도와준다는 미명아래 그의 손을 잡고 내가 의도했던 길로 이끌고 싶어 견딜 수 없어질수도 있겠고..
그렇지만 그에게 익숙해 질 수 있는 얼마간의 시간을 주어야해. 사실은 그에게 건네주기 전에 그에게 더 친숙하고 그가 쉽게 이해할 수 있도록 배려하여 만들었어야겠지.

이건 비단 Computer Scientist 만을 위한 교훈은 아니야.
다른 사람에게 네 마음을 보여 주는 것도 마찬가지 일거야.

- After observing a girl who tried to make an origami with a little poor instruction in HCI Lab

Beej's Guide to Network Programming

Beej's Guide to Network Programming ver. 2.3.18 (Oct. 5. 2005)

http://beej.us/guide/bgnet/output/htmlsingle/bgnet.html

[Download]

http://beej.us/guide/bgnet/

Korean version (ver. 2.3.1)

http://wiki.kldp.org/wiki.php/BeeJNetworkProgramming