= 01이상 진행상황 후기 =
강사/진행자들의 후기 페이지입니다. 이 또한 ["ThreeFs"] 를 생각하기 바랍니다. 오늘의 글들이 다음날, 또는 내년에 쓰일것임을 생각하시길. 그날 자신이 했던 일들 (또는 다른 사람이 했던 일들)을 확인하고, 그에 대해서 무엇이 잘되었는지, 왜 잘되었는지, 무엇이 잘 안되었는지, 왜 안되었는지를 확인하고, 앞으로의 대안을 생각해보도록 작성합시다.

== 금요일 ==
 * 네트워크 세미나 + TCP/IP 동영상 보기. (http://edu.hackerslab.com/home/html/temp/movie.htm)
 * 목요일의 ["RandomWalk2"] 에 대해서 다시 CRC 디자인 세션과 구현시간을 가져보았다. (["ScheduledWalk/재니&영동"], ["ScheduledWalk/창섭&상규"]) 이번에는 신입회원팀과 기존회원팀으로 나누어서 디자인 세션을 가지고, 팀별로 구현을 하였다. (신입회원 팀에서의 클래스 구현에서는 1002가 중간 Support)

=== 느낀점 ===
 * 남훈아 수고 했다. 후배들에게는 당근 어려웠겠지만, 개인적으로는 유익했던지라; ^^; traceroute 의 원리 설명은 정말; TCP/IP 동영상을 먼저보여주는게 더 쉬웠을려나 하는 생각도.

 * 일요일, 그리고 목요일, 금요일 동안 지겹도록 풀었을것 같은 RandomWalk 가 이렇게 다양한 모습을 보여주었다는 점에선 꼭 푸는 문제 수가 중요하지 않다라는 점을 확신시켜주었다.

 * CRC 디자인 세션때 후배들끼리 대화하면서 디자인하는 모습을 보았다. 목요일날 창준이형과 1002가 했었던 때에 얼핏 지나갔을지도 몰랐을 '이 스펙에서 명사에 해당되는 것들은 어떤것이였죠?' 라는 말을 기억하며 대화중에 언급하는 모습을 보며 보람을 느껴본다.

 * 마지막 날에 온 사람이 3명. 그리고 문제를 푸는데 참여한 사람이 2명 밖에 안남았다는 점은 데블스캠프를 준비한 사람들을 좌절하게 한다. 그나마 한편으로 기뻤던 점은, 아침 7시가 되도록 컴퓨터 하나를 두고 서로 대화를 하며 RandomWalk를 만들어가는 모습을 구경했다는 점. 그 경험이 어떻게 기억될지 궁금해진다. 

 * 화이트 보드 - 목요일 세미나 이후 화이트보드를 5층 피시실에 그냥 두었다. 처음엔 들고 갈까 했었다가 귀찮아서 두었는데, 중간에 후배가 어제 배운 내용에 대해 질문했을 때 '오. 마침 화이트보드가 있네?' 어제 했었던 방법으로 적어나가면서 편리함을 느꼈다.
 게다가 피시실에 서 있는중 중간중간 아이디어가 떠오를때 화이트보드를 쳐다보고 있노나니 내용 없는 빈 보드를 가만히 두고 싶어지지 않는다. 손이 근절근절해지도록 일종의 NoSmok:어포던스 를 제공한다고 할까. 칠판과는 다르게 손도 잘 안더러워진다.
  
 피시실에 컴퓨터만 바꿀 것이 아니라, 화이트보드를 놓는 것도 좋은 피시실 환경을 제공하는데 도움을 주리라 생각한다. (과 사무실에서 디지털 카메라를 빌릴 수 있다면 더더욱 좋겠다. 화이트보드로 아이디어를 적고, 디지털 카메라로 찍어서 바로 올리고..) 

-- ["1002"]
 * me too-- ["상민"]
=== 교훈 ===
 * 세미나나 스터디를 준비할때 앞 세미나의 흐름이 연결되었을 경우 그 진행이 더 쉽다. 앞에서의 세미나 내용을 이용하여 설명하면 강사나 학습자나 서로 시간낭비를 줄일 수 있으니까. 추후 이러한 세미나 준비를 할때 그 체계성을 고려해야 할 것이다. 

-- ["1002"]
== 목요일 ==
=== 한일 ===
이번 세미나의 부제를 단다면 "우리는 어떻게 사고하고 어떤 과정으로 프로그래밍 하는가" 정도가 될 것이다. 지금 학생들의 프로그래밍 과정과 사고 과정을 밖으로 끄집어 내어서 함께 관찰하고, 함께 논의할 수 있도록 했고, 동시에 선배/전문가들의 사고 과정과 프로그래밍 과정을 직접 보여주어서 그 차이를 느끼고, 거기서 학습이 일어나도록 했다.

우리는 수학문제에 대해 달랑 답만 달아놓으면, 설령 답이 맞더라도 "과정이 없다"고 문제를 틀리기도 한다. 프로그램은 최종적인 "답"이다. 우리는 그 답이 나오는 과정에 너무도 무관심하다.

 * 세미나
  * OOP를 바로 설명하기 전에 나의 프로그래밍 사고 방식을 깨닫고, StructuredProgramming 의 경우와 ObjectOrientedProgramming 의 경우에는 어떠한지, 그 사고방식의 이해에 촛점을 맞추었다. 

 * 일단 지난시간에 만들었었던 RandomWalk 의 스펙을 수정한 RandomWalk2 를 사람들로 하여금 풀게 한뒤, 그 중에 완성한 두명을 뽑아 (상규와 현민) 자신이 어떻게 프로그래밍을 했는지에 대해 창준이형의 진행으로 질답을 하면서 설명해나갔다. 그리고 코드를 프로젝터와 노트북을 이용, 신피의 벽에 비추며 설명하였다. (["RandomWalk2/상규"], ["RandomWalk2/현민"])
 * StructuredProgramming - 창준이형이 역사적인 관점에서의 StructuredProgramming에 대해 설명을 하셨다. 그 다음 ["1002"]는 ["RandomWalk2"] 문제에 대해서 StructuredProgramming을 적용하여 풀어나가는 과정을 설명해 나갔다. (원래 예정의 경우 StructuredProgramming 으로 ["RandomWalk2"] 를 만들어가는 과정을 자세하게 보여주려고 했지만, 시간관계상 Prototype 정도에서 그쳤다)
 * ObjectOrientedProgramming - ["RandomWalk2"] 에 대해서 창준이형과 ["1002"] 는 서로 이야기를 해 나가면서 하나씩 객체들을 뽑아내가는 과정을 설명했다. 일종의 CRC 카드 세션이었다. 그러고 나서는 프로젝터를 통해, 직접 Prototype을 만들어 보였다. OOP/OOAD로 접근하는 사람의 사고방식과 프로그래밍의 과정을 바로 옆에서 관찰할 수 있었다.
 * Python 기초 + 객체 가지고 놀기 실습 - Gateway 에서 Zealot, Dragoon 을 만들어보는 예제를 Python Interpreter 에서 입력해보았다.
 * ["RandomWalk2"] 를 ObjectOrientedProgramming 으로 구현하기 - 위의 Python 관련 실습동안 ["1002"] 는 ["RandomWalk2"] 에 대해서 C++ Prototype을 작성. (["RandomWalk2/ClassPrototype"]) 이를 뼈대로 삼아서 ["RandomWalk2"] 를 작성해보도록 실습. 해당 소스에 대한 간략한 설명, 구현의 예를 설명. 중간에 객체들에 대한 독립적인 테스트방법을 설명하면서 assert 문을 이용한 UnitTest 의 예를 보였다.
 * 마무리 소감 & 정리.

=== 느낀점 ===
Python으로 만든 스타크래프트 놀이는 참가자들이 무척이나 좋아했다. 또 그 직전에 Python Interactive Shell에서 간단하게 남자, 여자, 인간 클래스를 직접 만들어 보게 한 것도 좋아했다. 아주 짧은 시간 동안에 OOP의 "감"을 느끼게 해주는 데 일조를 했다고 본다.

또한, JuNe과 ["1002"]의 CrcCard 세션을 (마치 주변에 사람이 없는 듯 가정하고) 보여줬던 것도 좋은 반응을 얻었다(원래는 ["1002"]가 혼자 문제를 푸는 과정을 보여주려고 했다가 JuNe이 보기에 두 사람의 협력 과정을 보여주는 것도 좋을 듯 했고, 분위기가 약간 지루해 지거나 쳐질 수 있는 상황이어서 중간에 계획을 바꿨다.) 선배들이 자신이 풀어놓은 "모범답안"으로서의 코드 자체를 보여주는 것은 했어도 분석하고 디자인하고, 프로그래밍 해나가는 과정을 거의 보여준 적이 없어서, 그들에게 신선하게 다가간 것 같다.

또, 동일 문제를 여러번 하는 것의 교육적 효과를 다시금 확신하게 되었다. 내용이 이어지고 연계가 되니, "현재의 주제를 벗어난 것들에 에너지를 덜 소모하면서" 많은 학습이 가능했다. 최소한 문제를 매번 새로 설명하고, 그걸 이해시키게 하는 시간은 주제가 바뀔 때마다 아낄 수 있었다.

참가자들 중 대표로 몇 명의 코드를 프로젝터를 통해 직접 보면서 하나 하나 짚어 나갔다. 그 사람이 어떤 순서로 프로그램을 만들었고, 어떤 의도에서 이걸 이렇게 했는지. 한 줄 한 줄 정말 "많은 것을 가르쳐주고, 배울 수 있겠다" 하는 생각이 들었다. 우리는 "교사/정답에게서만 배운다"는 사고에서 자유로워질 필요가 있다.

--JuNe

 * 어떤 만화에서 보면 한 스승이 춤을 지도할때 재현성에 대해 이야기한다. '극장에 가득찬 관중들 앞에서, 당신은 "오늘은 신이 내리지 않았습니다" 라고 사과할 셈인가요?" 세계의 정상엔 최고의 춤에 '재현성'을 가지고 있습니다. 의식하십시오. 발가락, 발바닥, 모든 근육들을.' 
과정을 의식하고 행한다는 것은 그런것 같다. 문제 SPEC을 받았을때부터 코드의 끝까지. 잘못된 부분을 의식하지 않으면 끝까지 고칠수 없다. 문제 자체가 드러나지 않으면 문제를 풀 수 없으니까. 문제가 나를 지배하기 전에 내가 문제들을 지배하려면. 하나하나 나의 제어영역으로 들어오도록 해야겠다. 이름상으로는 세미나의 진행자로 올랐지만, 이 시간만큼 나는 세미나 진행자인 동시에 배우는 사람일 수 있었다.
 * '''Pair Teaching''' 세미나를 혼자서 진행하는게 아닌 둘이서 진행한다면? CRC 디자인 세션이라던지, Structured Programming 시 한명은 프로그래밍을, 한명은 설명을 해주는 방법을 해보면서 '만일 이 일을 혼자서 진행했다면?' 하는 생각을 해본다. 비록 신입회원들에게 하고싶었던 말들 (중간중간 팻감거리들;) 에 대해 언급하진 못했지만, 오히려 세미나 내용 자체에 더 집중할 수 있었다. (팻감거리들이 너무 길어지면 이야기가 산으로 가기 쉽기에.) 그리고 내용설명을 하고 있는 사람이 놓치고 있는 내용이나 사람들과의 Feedback 을 다른 진행자가 읽고, 다음 단계시 생각해볼 수 있었다.

--["1002"]
----
["RandomWalk2"]를 풀 때 어떤 사람들은 요구사항에 설명된 글의 순서대로(예컨대, 입력부분을 만들고, 그 다음 종료조건을 생각하고, ...) 생각하고, 또 거의 그 순서로 프로그래밍을 해 나갔다. 이 순서가 반드시 최선은 아닐텐데, 그렇게 한 이유는 무엇일까. 두가지 정도를 생각해 볼 수 있겠다.

하나는 사람들이 별다른 외현화를 하지 않고 바로 프로그래밍에 들어갔기 때문이다. 외현화라는 것은 자기 생각을 머리 바깥에 표현하는 것을 말한다. 다이어그램을 그리거나, 글을 쓰거나 해서 표식을 남기는 것이다. 외현화가 필요한 이유는, 사람의 단기기억 장치는 상당히 작은 수의 것들만 기억할 수 있기 때문에 일종의 "보조기억장치"를 통해 기억부담을 줄여야 하기 때문이다. 그런데, 미리 문제이해/분석/기획시에 특별히 자신이 이해하고 계획한 문제풀이를 외현화하지 않았기 때문에, 프로그래밍을 하는 중엔 유일한 보조물인 "요구사항"을 그대로 보고 따라하게 된 것이 아닐까 생각한다. 만약 문제를 보고 분석을 하면서 간단한 다이어그램을 그려뒀고, 그것을 참조하면서 프로그래밍했다면, "좀 더 바람직한 순서"를 택할 수 있지 않았을까.

다른 하나는, 요구사항이 어떻게 제시되느냐가 산출물로서의 프로그램에 큰 영향을 끼친다는 점이다. 요구사항이 어떤 순서로 제시되느냐, 심지어는 어떤 시제로 제시되느냐가 프로그램에 큰 영향을 끼친다. 심리학에서 흥미로운 결과를 찾아냈다. "내일은 한국과 브라질의 경기날입니다. 결과가 어떻게 될까요?"라는 질문과, "어제는 한국과 브라질의 경기가 있었습니다. 결과가 어땠나요?"라는 질문에 대해 사람들의 대답은 큰 차이가 있었다. 후자 경우가 훨씬 더 풍부하고, 자세하며, 구체적인 정보를 끌어냈다. 이 사실은 요구사항에도 적용이 되어서, 요구사항의 내용을 "미래 완료형"이나 "과거형"으로 표현하는 방법(Wiki:FuturePerfectThinking )도 생겼다. "This system will provide a friendly user interface"보다, "This system will have provided a friendly user interface"가 낫다는 이야기다. 어찌되었건, 우리는 요구사항이 표현된 "글" 자체에 종속되고, 많은 영향을 받는다.

따라서, 프로그래머는 "요구사항"이라는 말과 글의 울타리에서 가능한 한 벗어나서 "고객의 의도"를 먼저 파악하려는 시도가 필요하고, 동시에 자신의 이해와, 디자인 계획 등을 별도로 외현화 해두는 것이 중요하다.

--JuNe
----
처음 ["1002"]가 계획한 세미나 스케쥴은 조금 달랐다. "어떻게 하면 ObjectOrientedProgramming의 기본 지식을 많이 전달할까"하는 질문에서 나온 스케쥴 같았다. 나름대로 꽤 짜임새 있고, 훌륭한(특히 OOP를 조금은 아는 사람에게) 프로그램이었지만, 전혀 모르는 사람에게 몇 시간 동안의 세미나에서 그 많은 것을 전달하기는 무리가 아닐까 하고 JuNe은 생각했다. 그것은 몇 번의 세미나 경험을 통해 직접 느낀 것이었다. 그가 그간의 경험을 통해 얻은 화두는 다음의 것들이었다. 어떻게 하면 적게 전달하면서 충분히 깊이 그리고 많이 전달할까. 어떻게 하면 작은 크기의 씨앗을 주되, 그것이 그들 속에서 앞으로 튼튼한 나무로, 나아가 거대한 숲으로 잘 자라나게 할 것인가.

그래서 ["1002"]와 JuNe은 세미나 스케쥴을 전면적으로 재구성했다. 가르치려던 개념의 수를 2/3 이하로 확 잘랐고, 대신 깊이 있는 학습이 되도록 노력했다. 가능하면 "하면서 배우는 학습"(Learn By Doing)이 되도록 노력했다.

그렇지만 초반에 시간관리가 부족해서 전체적으로 약간 시간이 부족했다. 하지만, 처음 계획했던 것의 80% 이상을 실행했다는 점에서 꽤 성공적이었다고 생각한다.

----
아쉬운 점이 있었다면, 
 * 마지막의 ScheduledWalk Prototype 부분을 사람들이 제대로 활용하지 못했다. 세미나때 '가장 빨리 써먹는 방법은 기존의 코드를 읽고 흉내내는 겁니다' 라고 창준이형이 이야기했지만, 사람들에겐 아직 익숙하지 않아서 였을까. 
 * 세미나 전 미리 공부해온 사람이 적었다는 점(그래도 두명은 있었던 것 같다) '미리 어디 공부해오라고 알려준바 없어요' 라고 이야기하겠지만. 하긴, 이건 내 영향력 밖의 일이니 일단은. --["1002"]

=== 교훈 ===
역시 세미나 준비자가 많이 준비하고(특히 양은 줄이되 질과 "체계성"을 높이는 면에서), 많이 고민할수록 참가자들이 더 많은 것을 더 즐겁게 얻어갈 확률도 높아지는 듯 하다. --JuNe

== 수요일 ==
=== 한일 ===
 * 세미나 - DevelopmentinWindows, EventDrivenProgramming, Web Programming
 * 실습 - Personal Web Server 설치 & 간단한 ASP 실습. 윈도우즈 프로그래밍 관련 실습. 도스용 ["Omok"] 프로그래밍
=== 느낀점 ===
 * DevelopmentinWindows 세미나는 신입생들에게는 조금 어려웠나봅니다. 준비도 많이 하고 쉽게 설명하려고 복잡한건 다 뺐는데...... 그래도 어려웠나봅니다. 어쨌든 조금이나마 도움이 되었으면 좋겠습니다. --상규
   * 준비 많이 한건 세미나 자료물 나누어준것만 봐도 이해한다. 본래의 위키페이지에선 각 Resource 별 이미지들까지 캡쳐했으니. ^^ 단, 아쉬운 점이라면 
   * Web Programming 때 상규의 보충설명을 보면서 상규가 대단하다는 생각을 해봤다. 간과하고 넘어갈 뻔 했었던 Web Program의 작동원리에 대해서 제대로 짚어줬다고 생각한다. --["1002"]

----
EventDrivenProgramming 의 설명에서 또하나의 새로운 시각을 얻었다. 전에는 Finite State Machine 을 보면서 Program = State Transition 이란 생각을 했었는데, Problem Solving 과 State Transition 의 연관관계를 짚어지며 최종적으로 Problem Solving = State Transition = Program 이라는 A=B, B=C, 고로 A=C 라는. 아, 이날 필기해둔 종이를 잃어버린게 아쉽다. 찾는대로 정리를; --["1002"]

== 월요일 ==
=== 한일 ===
 * 세미나 
  * ["FoundationOfUNIX"] - Unix
  * DOS/컴구조 세미나
 * 실습 
  * 홈페이지를 유닉스 계정에 올리기
  * 도스에서 Debug 를 이용, 어셈블러로 abcde-z 를 화면에 출력하기.
  * ["RandomWalk"]
  * ["HanoiProblem"]
=== 느낀점 ===
 * 본래 Unix 실습때 쉘 스크립트를 이용, 쓰레기통 작성을 하려고 했지만, 실제 실습때 하지 못했다. 

 * 대체적으로 RandomWalk 는 많이 풀었고, HanoiProblem 은 아직 재귀함수를 많이 접해보지 않은 신입회원들에게는 어렵게 다가간거 같다. - 상협

 * DOS/컴퓨터구조 세미나는 신입회원들에게 난이도가 좀 있는 세미나 였다.

꼭 생소하다의 문제를 떠나서, 전반적인 컴퓨터 동작원리 보다 구체적 용어들 (어떻게 보면, 이미 공부하여 알고 있는 사람들의 경우 일상어화 되어버린 언어들)이 먼저 나와버렸기 때문이다. 컴퓨터가 하드웨어와 소프트웨어로 구분되어지기 이전엔 어떠했는지, 그게 하드웨어와 소프트웨어로서 구분하는 방법으로서 폰 노이만 아키텍쳐가 나온 이야기라던지, 그러하기 때문에 PC 카운터가 필요하며 메모리로부터 명령어를 읽어온 뒤, CPU에서 명령을 해석하고 처리한다라던지 등등. 그러한 이야기가 나오기전에 어드레스/세그먼트/옵셋/디코딩 이 나와버렸기 때문에 어려운 세미나가 되어버렸다고 생각한다. 후에 상민이가 다시 동작원리부터 상대적으로 쉬운 용어로 설명을 해주면서 사람들의 반응을 유도한점에 대해서는 사람들이 한번 생각을 해볼 필요가 있다. 우리와 대화하는 사람은 어느정도의 지식수준을 가지고 있는가에 대해서. 정말 이해 안가는 부분에 대해서는 질문 자체를 만들어내기 힘들다. --석천

 * 이날 했던 UNIX가 쉽게 신입 회원들에게 느껴졌고, 컴퓨터 구조는 좀 어렵게 느껴진거 같다. 쉬운것과 어려운 세미나가 이렇게 섞인것이 내가 보기에는 쉬운것만 하는거나 어려운것만 하는것보다 더 좋았던거 같다. - 상협
    -- 왜 어려웠을까, 왜 쉬웠을까에 대해서 생각해봤으면 좋겠다. 그리고 또한 '정말 쉬웠을까?' 라는 점도. 이건 사람들에게 물어보며 Feedback 을 얻어야 할 것이다. 개인적인 생각으론 Unix 또한 그리 많이 쉬운 세미나는 아니였다고 생각한다. 다음에 것들에 대해 답할 수 있는지.
  * Unix 가 뭐하는거에요? Linux 랑 다른거에요?
  * 왜 필요해요? 꼭 써야 해요? 어디에 쓰여요?
  * 상대경로와 절대경로가 Unix에만 쓰여요?
  * Unix가 윈도우보다 좋은거에요? 아니면 용도가 다른가요? 어떻게 다른가요? 

 * 설명중에 '(설명) .... 말로 하긴 그렇고 앞으로 실습해 보면 이해가 갈거에요...' 이라는 말을 자주 하는 것으로 들렸다. 한편으로는 '실습으로 이해하는 것이 더 확실할겁니다' 란 말이겠지만, 한편으로는 '말로 설명하기엔 좀 힘들어요' 라는 인상을 풍길수도 있을 것 같다. 받아들이는 사람 입장에선. 실습으로서 말할 수 있는 내용들에 대해서는 대략 설명하고, 실습으로 설명할 수 없는 내용들에 대해서 (Unix 의 역사, DOS와 윈도우즈 등과 다른 점 등) 설명할 수 있지 않았을까. 실습 중간중간에 설명하는 것이 더 좋은 내용이라면 그건 실습때 설명하는것이 더 나을지도. -- 석천

 * ["neocoin"] :  정직, 맘 상했다면 정말 미안하다. 미리 언질을 주고 덧붙이기를 하더라도 해야 했는데, 시간이 모자라서 그냥 막무가내로 나와서 이야기를 풀어 놓았구나. 그리고, 앞에서 이야기 하던 중 영문도 모르게, 박수를 받게 만든 남훈이에게도 미안 하다. 엎드려 있는 사람을 완전히 깨우기 위해 '환기의 큰소리'가 필요 했었다. 앉아 있는 사람들은 못느꼈을지 모르겠지만, 앞에서 보고 있던 나는, 그 박수 소리로 마지막 2명이 일어나 칠판을 바라 보는 큰 효과를 보았다. 박수 후 이야기 중 불쾌한 모습 보이지 않아서 고맙다. --["상민"]
  * 상민이도 글에서 언급했지만, 의도야 어찌되었건 세미나 중간에 강사의 이야기를 끊은점은 나를 비롯해서 잘못한 점이 크다고 생각한다. 세미나를 주도하는 사람은 세미나 발표자이라는 점을 망각을 한 것 같다. 나도 미안하다. --석천

=== 깨달은점(앞으로 할일) ===
 * 추상화 단계에 대해서 - 세미나 대상자의 수준을 파악하고, 그 사람에게 친숙한 지식들 (만일 컴구조에서 어드레스/옵셋 이야기를 그들이 배웠던 포인터의 개념과 같이 설명했더라면? 우리가 파이프라인 설명을 들었을때 책에서 세탁기의 예가 나온것처럼 설명을 했었더라면?)과 융합시키는 건 어떨까. 정직이가 중간에 '포인터 지금 어렵죠? 그거 나중에 어셈을 배우면 그냥 저건 메모리 주소에요' 라고 설명했었는데, 그것을 실제로 메모리 그림을 그려주고, 포인터의 값이 어떻게 들어가는지에 대해 설명했었더라면 어떠했을까? --석천
   * 불필요한 스레드일지도 모르겠으나, 일단 완벽히 어셈쪽 이야기를 하는 것이 아니라, 단순히 C 언어같은 하이레벨 언어에서의 관점으로 얘기하는 것이라면, 포인터란 '가르키는 것' 이라는 추상적인 개념일 뿐입니다. 오히려 어설프게 메모리의 주소라는 개념을 알게 된다면 나중에 더욱 큰 혼돈을 불러일으킬 수 있습니다.. 저처럼요.. -["zennith"]
      * 불필요한 스레드란 없으니 걱정말고. ^^; 개인적으로 C 와 어셈과의 포인터관계를 어디서 찾았냐면, 해당 주소값이란 것이 무엇인가에서 찾았다. (단, 내가 정직이나 남훈이보단 하드웨어 관련지식이 깊지 않다) '포인터 값을 화면에 찍었을 경우에 나오는 엄청나게 큰 숫자(윈도우의 경우 32비트) 의 의미는 무엇인가?' 라는 질문을 하게 되었고. 그 이후 메모리가 16메가바이트라는 건 메모리에 0번부터 16메가바이트-1 이라는 번호를 부여하고, 해당 번호에 값을 대입하는 것이라는 접근을 하게 되었지. (물론, 이것도 물리적 주소는 아니겠지. 결국 우리가 이용하는 주소란 OS 에 의해 한번 걸러진 논리적 주소겠지.) 추상화의 정도를 이야기하라는 건 꼭 해당 언어 기준으로 이야기하라는 게 아니라, 경험에 대한 연결고리(여기서는 'C에서 포인터 변수를 화면에 찍어보니 이상하게 큰 숫자가 나왔다' 정도)를 찾아보자라고 한다면 정말 이야기가 '추상적'이려나; --석천

== 일요일 ==
=== 한일 ===
 * 세미나
  * C++ 화일 입출력의 이해
 * 실습
  * ["MagicSquare"]
  * ["NumberBaseballGame"]
  * ["가위바위보"]
=== 느낀점 ===
강의 중간에 나가서 끝까지 관찰하진 못했지만, 두가지 점이 대강 보였는데.
 * 사람들의 참여 유도 - 이것은 선호가 비교적 원만하게 진행한 것 같다. 사람들에게 어떤 부분이 궁금한지 질문을 북돋았다는 점은 잘 진행된 듯.
 * 진행의 순서 모호 - 선호도 인정했지만 체계적인 준비가 좀 부족했던점. 본래 준비하기로 한 내용과 달랐다는 점(화일 입출력 부분) 그리고 Table Of Contents 의 부재. 그리고 사람들의 질문을 받아서 이야기 하는 방법의 약점이라고 할까. 잘못하면 전체 내용의 연결고리를 잇지 못한다는 점이 있었다고 생각 
첫날이였으니. 일단.~ - 석천 
 * 강의 중 강사 외 껴들기; - 이건 나의 잘못;; 그 덕에 선호의 진행이 매끄럽게 되지 못한것 같다. 

=== 앞으로 할 일 ===
 * 진행의 순서 - 이는 강사가 준비해야 할 점이겠지만. 전체 체계를 한번은 생각하자.
 * 강의중 강사외 껴들기에 대한 대안 - 일단 강의의 흐름을 끊지 않는다는 하에 적절한 시간관리를 한 '보충시간' 을 신청하도록 하는게 좋을듯. --석천

----
["데블스캠프2002"]