음.. 밤샘 세미나라..; 내가 밤을 샐수 있을지가 가장 큰 고민인데..; 그래도 귀여븐 후배들을 위해서라면.. 저두 페어해보는거에 대해 찬성이고여. 기간은 일주일이겠죠? 작년 데블스 캠프때는 무엇을 했나요? - 인수
작년에는 '간략한 세미나(매우 짧습니다.) + 과제 제출 + 다음 문제 관한 세미나 + 제출...' 이런 식이었습니다. 세미나라 하면 거의 문제가 무엇인지를 알려주는 정도였습니다. 스스로 고민을 많이 하게 했던 캠프였습니다. 당시 과제의 갯수는 대략 20개 정도였습니다. --창섭
여태까지 있었던 데블스캠프는 짤막한(정말 어이없을 정도로 짧을 수도 있는..^^) 세미나 직후 문제 내주기, 풀기 등으로 이루어졌던 걸로 압니다. 이번에도 그렇게 할 것인지.. 아니면 Team 프로젝트식으로 선후배가 한 팀이 되어 하는것이 좋을지도 생각해봐야겠습니다. 그런데 아직 경험이 부족한 1학년들과 선배들이 페어가 되어 한다면 (잘하는 사람 예외) 선배들만의 잔치가 될 우려가 있기 때문에 잘 생각해보고 정해야겠습니다. --창섭
음.. 솔직히 문제 주고, 풀게 하고 하는게 더 현실적이고 배울점도 많을거 같네여.. 그러면 02들이 문제풀 동안 나머지 학번들은 뭐 하져? 같이 문제 푼다 해도 시간이 남을거 같은데여..- 상협
작년엔 선배들이 1학년들할 때 지켜보면서 많은 도움을 주셨습니다. 이번에는 어떻게 할까요. 참. 작년엔 선배들이 각각 파트를 나눠서 세미나를 했습니다. 그리고 이번 회의때는 캠프기간에 무엇을 다루었으면 하는지도 있었으면 합니다. 방법 못지 않게 중요한 것이 '무엇을' 이니까요. 작년엔 HTML, C/C++, API, MFC 등을 했습니다. 물론 API, MFC 는 맛봬기였구요. 자료구조도 다루었습니다. --창섭

기존 방식대로.. 위에서 말하는(PairProgramming, ApprenticeShip ) 방식들은 어느정도 프로그래밍에 기초가 다져진 사람들에게 적합할듯.(신입생들의 실력이 어느정도일지는 모르지만 구구단도 제대로 못짤것 같음.) 기존의 방식은 아직 프로그래밍의 기초가 없는 사람들을 대상으로 성공적이었으므로. 그리고 몇년의 시행착오를 거쳐서 굳어진 방법이므로 . 새로운 방법을 도입한다면 해왔던 만큼의 시행착오를 해야 하므로 후배들이 얻을수 있는 것들에 대한 확신을 못함. --최태호
지금 촛점을 맞추려는 것은 '어떻게 하면 좀 더 유익한 시간으로 만들것인가' 이겠죠? 기왕 할거 잘해보려고 아이디어를 모아보는 것이고요. 그러기에 기존의 방법이나 새로운 스타일이나 결국은 아직 결정되지 않은 '아이디어'라 생각하고, 장단점을 보고 장점은 추구하고 단점은 보완해보려고 하는것이고요.
(제가 괜히 나우누리에서 데블스캠프 글을 뒤져본 게 아닙니다. 과연 지금 00, 01 들은 초기때의 데블스가 어떤 모임이였고, 어떠한 정신으로 데블스캠프가 시작되었는지 알고 있는겁니까? ZP와의 통합때도 요건중 내걸었건 것이 데블스캠프 라면 왜 그런지. 그 중요성이 어떤건지 제대로 알고 있어야 하는것 아닙니까? 밤샘 세미나와 그로인해 고려하지 않았던 점에 대해서는 예전에도 또한 같은 고민을 한 것도 보이고요. 우리는 이 고민을 궁리하고 해결하려고 해야지 똑같은 일을 되풀이해야 할건 아니겠죠.) 이미 ZP와 데블스가 통합된이상 데블스캠프 는 ZP내 데블스사람들만의 행사가 아닙니다. (이번에 제가 참여한다고 한건 정모/2002.5.30 을 확인하시기 바랍니다.)
그리고 기존 방식에 대해서 충실하게 하려면 데블스캠프에 참여하는 모든 사람들이 기존의 데블스 방식을 제대로 알고 있어야 합니다.
그리고 데블스캠프까진 아니여도 세미나나 스터디 진행은 어느정도 해본 경험이 있습니다. 일반적인 스타일의 세미나의 특징은 '학교수업' 과 다를바 없는 모습입니다. 즉, 강사는 강사대로 계속 준비한 거 이야기하고, 학생은 학생대로 가만히 앉아서 듣습니다. 그리고, 한참 멍하고 있다가 레포트나오면 그때서야 책 뒤져가며 공부하고 문제풀려고 노력합니다. 즉, 수업중엔 '문제' 자체를 만들어내질 못합니다.
데블스캠프 (위의 이야기들 01들 기준으로 한 일들에 대한 글을 기본으로) 때는 문제들을 많이 준비하여 (20개정도면 꽤 빡세다고 해도 좋겠죠?) 스스로 고민하고 해결해 나가는 자리를 마련해줍니다. '문제' 들을 중심으로 진행되어가겠죠. 이 경우에 대한 문제점에 대해선 위에 후배들이 쓴 글을 기준으로 볼때 '짤막한 문제들의 나열' 로 끝날 수 있다는 것입니다. (오해가 있는것일지도 모르니 제대로 아시는 분은 답글요청합니다.) 일주일의 모임중 20개의 문제를 푸는중에 저 생각을 한 것이라면 저라면 다음의 경우로 볼것 같습니다.

• 문제가 정말 짧거나
  
• 해당 문제를 푸는 이유를 모르거나 (해당 문제들을 풀고 난 뒤의 추후 응용범위 등)
  

문제를 낸 사람은 해당 문제를 왜 내었고, 이 문제를 풀면 어떠한 다른 문제를 풀 수 있는지 예상할 수 있어야 합니다. (라고 말하기엔 '말' 로 하는 게 너무 쉬운 일일까요. 10년이 넘어가는 학회에 이런 노하우가 쌓여있지 않다는 점은 참 슬픔입니다. 개인적으로 위키쪽 문서화에 열을 올리는것도 그런거고)
그리고 또 하나 나온 문제점은, 캠프 동안 02 학번이나 캠프 참여 선배들 이외의 사람들은 무엇을 할것인가입니다. 기왕 ZP의 큰 행사로 만들 바에는 01 이나 00 학번 또는 그 이상 사람들의 자리일수 있어야 한다고 생각합니다. 그러러면 00, 01 학번 세미나 또는 행사가 진행되어야 할 것입니다. (이 점에서는 02쪽 진행을 맡은 선배들이 밤샘을 해야 한다는 점은 상당한 부담으로 작용할 수 있습니다.)
그러한 점에서 PairProgramming을 진행하는 방법을 생각해보는것도 좋겠다고 생각한 겁니다. 이 경우 생각해야 할 것은 Driver/Observer 의 시간 분배인데, 위에서 우려하는 것은 선배들이 코드를 주도한다는 점이 나왔죠. (스스로 문제해결할 시간을 주는 것도 중요한 일이라 생각합니다. 개인적으로 홀로삽질을 많이 해본 사람 입장으로선 ;;;) 그래서 정모/2002.5.30에서 생각한건 행사 5일중 3일정도는 일반 스타일을, 2일정도는 협업스타일을 해보자고 한 겁니다. (반드시 선배와의 Pair 일 필요는 없습니다. 후배들끼리 Pair 해보는건 어떨까요?) (솔직히 이 글쓰면서 암울한것중 하나는 99 이하 사람들중 팀프로젝트때 실제로 팀플레이를 해본 사람이 있는지 입니다. 개인적으로 느끼는건, 혼자 진행되는 프로젝트로는 대단한 사람들이 아닌이상 3달간 꾸준하게 만들어서 5만라인짜리 프로그램 만들기같은것을 못할것이라는 겁니다.)
올해엔 학술제가 열립니다. 방학기간동안 학술제 작품 궁리 & 진행을 해야 합니다. 팀 참가시에는 반드시 1학년을 참여시키도록 되어있기 때문에 (그 사람들은 어떠한 대책으로 30주년 행사에 그런 조건을 걸었는지 모르지만. 학년별 어드밴티지도 없이 상금 걸려있다는 행사에) 전시회 대신 학술제 참여를 하는 ZP 입장에선 데블스캠프는 매우 중요한 일입니다. 궁리해볼건 궁리해봐야겠죠. --석천
석천이의 글은 잘 읽었음.
나 자신에 대해 매우 반성을 하고 있음.
!o!--최태호

최근까지 했던 세미나(??)에서 했던게 구구단, 소트, 피보나치 수열, 팩토리알, 스택, 큐 등 기본 문법과 기초 자료구조를 익히기 좋은 문제들이었거든요. 대다수가 잘 짜던것 같습니다. 기본 문법은 확실히 다져진 것 같으니 뭔가 좀 응용성 있는것을 해봐도 된다고 생각합니다. --인수
----
제 생각에는 꼭 한가지 방법을 모든 신입 회원들에게 적용할 이유는 없다고 생각합니다. 아직 기초가 부족하다 싶은 회원, 좀 프로그래밍에 익숙하다 싶은 회원을 각자 다른 방법으로 캠프를 진행해도 괜찮다고 생각합니다. (작년에 MFC스터디 벽돌깨기팀과 오목짜기 팀처럼 익숙한 정도에 따라 방법을 나누는 거죠..) --상협

• 좀 제대로 할것
  
  • C++ 클래스 부분은 어떨까요? - 상협
    
• 맛만 보여줄 것
  
  • MFC도 간단히 맛좀 보여줘도 좋을거 같은데요.. - 상협
    
  • PHP나 비베 오ㅤㅆㅠㅤ로 듣는 사람 있으니깐 그런건 어떨까...ㅎㅎ -병희
    
    • 스크립트 언어를 가르친다면 제일 익숙하고 쉬운 자바스크립트는 어떨지... (사실.. 내가 자바스크립트를 아~주 약간 봐서..ㅋㄷ) --창섭
      

선배들이 어떻게 문제를 해결하는지 보여주는 것도 좋을 것 같습니다. --데기
데블스 캠프 참가자와 선배들을 팀으로 만들어서 (물론 선배 한명당 참가자 한명이 될지는 의문입니다만,) 선배들은 그냥 지켜보고만 있다가 나중에 문제점을 고쳐준다던지, 이렇게 하면 더 좋은 방법이 된다는 것을 알려주는 방법이 좋을듯 합니다. 참가자가 고민하면서 문제를 해결해 나갈수 있도록 해야 도움이 될꺼라고 생각되고, 또한 나중에 선배들이 이러한 문제는 이러한 방식으로 풀면 되는 예시 코드를 보여주면 자신이 문제를 해결한 방법과 어떤 부분이 다른지 알게되어서 한층 더 도움이 될것 같다고 생각합니다. -- 윤정수

이런 걸 할 때 날마다 위키에 조별로 공동일기를 쓰고 ThreeFs를 공유하면 좋을 겁니다. 그리고, 매일 저녁에 조원들이 같이 모여 Daily Retrospective를 갖도록 합니다. 이런 건 좋았다, 나빴다, 내일은 이렇게 저렇게 해보자 등등. 그러고 나서, 선배들이 같이 모여 전체 Daily Retrospective를 합니다. 우리 조는 이랬고, 너희 조는 저랬구나, 그럼 우리는 이렇게 해야겠다 등.
----
토론분류