Error%20%EB%B0%9C%EC%83%9D%EC%8B%9C%20%ED%92%80%EB%A6%AC%EC%A7%80%20%EC%95%8A%EC%9D%84%20%EA%B2%BD%EC%9A%B0%20%ED%99%95%EC%9D%B8

Search BackLinks only
Display context of search results
Case-sensitive searching

• Linux/필수명령어/용법 . . . . 30 matches
       두 번째 형식은 어떤 사용자 레벨을 바꿀 것인가 어떻게 바꿀 것인가를 개별적으로 정하는 방법이다. 숫자를 사용하지 않고 ls 등을 사용할 때 실제로 볼 수 있는 기호 문자를 사용한다는 것과 특정 권한을 줄 것인가 뺄 것인가 지정할 수 있다는 장점이 있다. 특정한 경우 두 번째 형식이 편리하겠지만 고유한 값의 권한을 지정하는데에는 첫 번째 형식이 훨씬 편리할 것이다. 8진법을 다루는 것은 조금만 알면 너무나 쉽기 때문이다.
       만일 중간에 다른 점을 발견한다면 더 이상의 작업은 중단하고 차이를 발견한 지점을 알려주고는 종료한다. 또한 계속해서 일치해 나가다가 두 파일 중 어느 하나가 끝나는 경우가 있을 수 있다. 다시 말해, 한 파일이 다른 파일의 앞부분에 해당하는 경우이다. 이때는 어느쪽 파일의 end of file 표시를 만나게 되었는지를 알려주고 종료한다.
       오프셋을 지정하면 파일의 어느 부분부터 비교할 것인지를 정할 수 있다. -s 옵션이 왜 필요한 지를 이해하지 못할 테지만, cmp 명령이 보이지 않게 리턴값을 들려준다는 점을 알면 이해할 수 있을 것이다. cmp는 비교 후 두 파일이 일치한다고 판단하면 0을 리턴하며, 그렇지 않으면 1을 리턴한다. 셸 스크립트 상에서 비교 결과만을 원하고 화면에 메시지가 출력되는 것을 원치 않을 때에는 이러한 옵션을 사용할 수 있을 것이다. C 언어를 아는 사람이라면 금방 이해할 수 있었으리라 생각된다.
       압축된 파일은 이름에 접미사 .Z가 추가된다. 압축 알고리즘에 의해 크기가 줄어드는 경우만 압축을 수행한다. -d 옵션은 역으로 압축을 풀지만 uncompress를 사용하면 옵션을 주지 않고 압축을 풀 수 있다. 압축을 푸는 경우 파일 이름 뒤에 접미사 .Z를 생략할 수도 있다.
       -i : 복사시 같은 이름의 파일이 존재한다면 덮어쓸 것인가 확인한다.
       만일 파일명2가 이미 존재하는 파일의 이름이라면 기존에 있던 파일은 사라지고 새로운 복사본 파일로 바뀐다. 이것이 원하지 않는 결과라면 -i 옵션을 주어서 확인 작업을 거칠 수 있다. -i 옵션은 파일명2가 이미 존재하는 이름이라면 그대로 복사할 것인지 아닌지를 선택할 수 있게 물어온다.
       : 시스템은 현재의 날짜와 시간을 유지하고 있다. date 명령을 사용하면 그러한 시간을 확인할 수 있다. 또한 날짜와 시간 정보를 변경할 수 있다. 물론 시스템의 날짜와 시간은 슈퍼 유저만이 변경할 수 있다.
       -a 옵션을 사용하였다면 검사도중 발견된 오류는 자동으로 복구된다. -r 옵션을 사용한다면 반드시 -s 옵션을 함께 사용해야 한다. fsck는 기본적으로 한꺼번에 몇 개의 검사를 병행하는 병렬 작업을 하기 때문에 하나의 에러를 발견하더라도 다른 검사는 계속 수행되고 있다. 검사 시간을 최대한 절약하기 위해서 병렬 작업을 하기 때문에 사용자의 수정과 다른 검사 작업의 호홉이 맞지 않을 수 있다. 그러므로 -s 옵션을 주어서 오직 하나의 검사 작업만 진행되도록 해야 한다. 그러나 -r 옵션은 하위 버전과의 호환성을 위한 것으로서 사용자는 -a 옵션만을 사용하는 것으로서 충분하다. 파일 시스템을 지정해 주지 않으면 /etc/fstab 파일에 나열된 파일 시스템을 검색한다.
       문서의 앞 머리 세 줄만 확인하기 위해서 다음과 같이 할 수 있다.
       : 시스템에 등록된 ID를 확인한다.
       셸을 사용할 때 어떤 명령의 사용법이 기억나지 않는 경우가 있다. 혹은 매번 사용하던 명령이라도 특수한 옵션이 필요할 때 그 기호나 사용법을 정확히 확인해야 하는 경우가 많이 있다. 물론 참고 서적을 보면 되겠지만 터미널 상에서 필요한 도움말을 언제라도 제공받을 수 있다. 시스템에 내장된 매뉴얼은 빠르게 볼 수 있을 뿐만 아니라 그 내용도 완벽한 것이어서 옵션의 종류 같은 것은 빠진 것이 없다. 만일 온라인 레퍼런스를 모두 종이로 출력한다면 그 분량은 엄청날 것이 틀림없다.
       -n : 파일을 덮어쓰게 되는 경우에도 경고하지 않는다.
       당신의 터미널이 다른 사용자의 메시지를 받기 원한다면 y, 그렇지 않다면 n을 선택한다. 옵션을 선택하지 않으면 mesg는 현재 터미널의 메시지 수신 가능 여부를 확인하여 알려준다. 보통 기본적으로 터미널은 메시지를 수신할 수 있다.
       -f : 같은 이름의 파일이 존재하고 쓰기 권한이 금지되어 있더라도 물어보지 않고 덮어쓰기를 해버린다. 이런 경우 이 옵션을 사용하지 않으면 사용자에게 다시 확인을 할 것이다.
       -i : 파일을 덮어쓰기 전에 사용자에게 확인한다.
       : 하나 혹은 그 이상의 파일로부터 칼럼 형태의 출력을 만든다. 이것은 cut과 함께 사용되는 경우가 많다.
       -x : 로그인 상태에 있는 동안 아직 완료되지 않은 프로세서들을 보여준다. 유닉스 시 스템은 사용자가 로그아웃하고 난 후에도 임의의 프로세서가 계속 동작하게 할 수 있다. 그러면 그 프로세서는 자신을 실행시킨 셸이 없이도 계속 자신의 일을 수행한다. 이러한 프로세서는 일반적인 ps 명령으로 확인할 수 없다. 이때 -x 옵션을 사용하면 자신의 터미널이 없는 프로세서들을 확인할 수 있다.
       다음과 같은 확인자를 사용한다면 다른 시간 단위를 사용할 수 있다.
       - $ cat sample ,, 분류된 내용 확인
       su의 인수로 원하는 사용자의 ID를 주면 그 사용자의 패스워드를 물어오고, 입력한 패스워드가 일치한다면 새롭게 생성된 셸을 볼 수 있다. 그렇게 다른 사람으로 작업한 후에 exit등으로 셸을 종료하면 다시 이전에 작업하던 셸로 돌아갈 수 있다. 이 명령은 혼자서 시스템을 사용하는 리눅스 사용자들에게 매우 유용하다. 기본적으로 일반 사용자 계정으로 작업하다가 필요한 경우 수퍼 유저로 로그인하고서 필요한 일이 끝나면 다시 일반 계정 셸로 돌아갈 수 있기 때문이다.
• MoreEffectiveC++/Exception . . . . 30 matches
       방법은 올바르다. 예외시에 해당 객체를 지워 버리는것, 그리고 이건 우리가 배운 try-catch-throw를 충실히 사용한 것이다. 하지만.. 복잡하지 않은가? 해당 코드는 말그대로 펼쳐진다.(영서의 표현) 그리고 코드의 가독성도 떨어지며, 차후 관리 차원에서 추가 코드의 발생시에도 어느 영역에 보강할것 인가에 관하여 문제시 된다.
       예외 발생시에 함수가 종료되면 auto_ptr상의 객체는 무조건 해제된다.
       일반적으로 C의 개념으로 짜여진 프로그램들은 createWindow and destroyWindow와 같이 관리한다. 그렇지만 이것 역시 destroyWindow(w)에 도달전에 예외 발생시 자원이 세는 경우가 생긴다. 그렇다면 다음과 같이 바꾸어서 해본다.
       자 이제 깨끗이 해결 된 것으로 보인다. 하지만 이번에는 이런 경우를 상정해 보자
       이런 const 포인터의 경우에는 반드시 초기화 리스트를 이용하여 인자를 초기화 해주어야 하는 경우이다.
        // theAudioClip는 두번째로 초기화 되기 때문에, 예외의 발생경우 이미 할당되어진 theImage의 자원을
       이렇게 디자인 할경우 파괴는 자동으로 이루어 진다. 그러므로 파괴자는
       파괴자 호출은 두가지의 경우가 있다. 첫번째가 'normal'상태로 객체가 파괴되어 질때로 그것은 보통 명시적으로 delete가 불린다. 두번째는 예외가 전달되면서 스택이 풀릴때 예외 처리시(exception-handling) 객체가 파괴되어 지는 경우가 있다.
       아마 대다수의 사람들이 이런 상태로 빠지는걸 원하지 않을 것이다. Session 객체의 파괴는 기록되지 않을 태니까. 그건 상당히 커다란 문제이다 그러나 그것이 좀더 심한 문제를 유발하는건 프로그램이 더 진할수 없을 때 일것이다. 그래서 Session의 파괴자에서의 예외 전달을 막아야 한다. 방법은 하나 try-catch로 잡아 버리는 것이다.
       이럴 경우에는 Session의 파괴자에게 문제를 제거하는 명령을 다시 내릴수 있따 하지만 endTransaction이 예외를 발생히킨다면 다시 try-catch문으로 돌아 갈수 밖에 없다.
       자, 비슷한 면은 언급해보면, 함수 예외 모두 에 인자를 전달할때 세가지로 전달할수 있다. 값(by value)이냐 참조(by reference)냐, 혹은 포인터(by pointer)냐 바로 이것이다. 하지만 이 함수와 예외에서의 인자의 전달 방식은 구동 방법에서 결정적인 차이점을 보인다. 이런 차이점은 당신이 함수를 호출할때 최종적으로 반환되는 값(returns)이 해당 함수를 부르는 위치로 가지만, 예외의 경우에 throw의 위치와 return의 위치가 다르다는 점에서 기인한다.
       객체가 예외를 위하여 복사가 될때 복사는 해당 객체의 복사생성자(copy constructor)에 의하여 수행 된다. 이 복사생성자는 객체의 dynamic형이 아닌 static 형에 해당하는 클래스중 하나이다. 개념의 확인을 위해 위 소스의 수정 버전을 생각해 보자
        throw rw; // rw의 형 즉 Widget의 복사생성자가 작동하여 복사해 예외를 발생시킨다.
       다음의 경우 passAndThrowWidget 이 던지는건 Widget 이다. 위에서 언급했듯이 static type으로 예외는 전달된다. 컴파일러는 rw가 SpecialWidget으로의 동작을 전혀 생각하지 않는다.
       자 그럼 다음의 세가지 catch에 관해서 시험해 보자. passAndThrowWidget에서 발생한 예외는 다음의 세가지의 경우로 잡을수 있는걸 예상할수 있다.
        +-logic_error
        | +-domain_error
        | +-length_error
        +-runtime_error
        +-range_error
• PairProgramming . . . . 23 matches
        * Pair Refactoring - 꼭 소스 코드가 아니더라도 위키 페이지에 대한 ["문서구조조정"] 을 하는 경우에도 적용할 수 있다. 특히, 해당 토론이 벌어진뒤 양론으로 나누어졌을 경우, 각 의견 지지자들이 Pair 로 문서구조조정을 할때 이용할 수 있다.
        * 5분 Pair-Change - 장과 단이 존재하긴 하는데. 장점으로 본다면, 자신의 프로그래밍 차례가 빨리 돌아오면서 Pair 끼리의 Feedback 이 빠르다는 점에서 집중도가 높다는 점이 있다. 단, Junior 의 경우 자신의 사고가 성숙해질 시간을 방해할 수 있다. 이 경우 5분으로 시작, 점차적으로 Change 의 기간을 늘려주는 방법이 있다.
        * Junior : Junior Pair 는 의미가 없다? - 결과물에 상관하지 않는 학습의 경우 그 의미가 있다. Junior 의 실력 한계 내에서의 Output 으로도 의미가 있다. 처음 프로그래밍을 익히는 사람에게 Pair 를 하는 것 자체가 새로운 학습경험이 된다.
       Expert : Junior . 즉, 해당 분야에 대한 전문가 : 초심자 의 문제이다. 이 경우 그 진행이 늦어질 수 있다. (Expert : Expert는 최고의 효율성을 가진다. 물론 이것도 열린 마음을 바탕으로 한다. Junior : Junior 도 나름대로(?) 빨리 움직인다. (제대로 움직인다는 보장은 못한다. -_-;)) 그리고 Expert가 해당 프로그래밍에 대한 답 (코드)을 이미 알고 있는 경우 Expert의 집중도와 긴장감을 해치게 된다.
        * Pair 의 진행을 이끌어가는 것 - 프로그래밍의 흐름이라고 해야 할까. 디자인을 어느정도 선정도로 맞추고 어떠한 문제를 풀 것인가에 대한 약간의 선이 필요할 것 같다. 이 경우에는 초반 디자인이 허술했었다는 약점이 있었다. '전체적인 관점에서 무엇무엇을 하면 프로그램이 완성될 것이다' 라는 것. UserStory 만 생각하고 EnginneringTask 를 간과한 것이 큰 문제였다. (그때 EnginneringTask 에 대한 개념이 없었었다는. 어디서 함부로 주워만 지식. --; 사고를 하자 사고를. -_-)
       집중도는 거의 최고라는 점! (이 점에서 둘이 서로 동의를 했다.) 평소 혼자 프로그래밍할때는 중간에 웹서핑을 하는 등 주위가 산만해지는 경우가 많았다. 하지만 이 Pair 중에는 사람들이 프로그래밍과 토론에만 전념할 수 있었다. (오히려 중간중간 일부러 10분 휴식을 두어야 했다.)
       * Junior 로서의 실수 - 기존 앞에서의 경험에서는 상대적으로 내가 Expert 의 위치에서 작업을 하였다. 이번에는 Junior 의 입장에 서게 되었는데, 기존에 Junior 의 위치에 있었던 사람들의 실수를 내가 하게 되었다. 어려운 부분에 대해서는 이해를 제대로 하지 못했음에도 불구하고 Expert의 속도를 저해할지도 모른다는 생각을 하며 대강 넘어갔었다. (다른 Junior 의 경우도 PP에서 어려움을 겪는 부분중 하나가 이것일지도 모른다. 특히 선후배 관계의 경우) 하지만, 이는 오히려 사태를 악화시킬 수 있다. 프로그래밍 작업을 계속 Expert에게만 의존하게 되기 때문이다. 확실하게 개념을 공유해야 Observer 의 역할과 Driver 의 역할 둘 다 잘할 수 있다. (쉬운 일은 아니다. 확실히)
        * 보통 코딩을 주도하는쪽이 빨리 지치며 집중력도 떨어지게 된다. 특히 PairProgramming 의 경우는 상대편 Pair에 대한 배려상 해당 시간에 작업 이외의 다른 일을 거의 하지 않는다. (화장실도 자주 안간다;;)
        * Junior 의 위치에서 바라본 학습 효과 - 이전에 상경이형이 채팅 프로그램 만드는 법을 직접 보여줬을때가 생각이 난다. (그때 '자. 15분동안 하나 만들어줄께~' 하면서 후다다닥 MFC로 서버/클라이언트 예제를 바로 보여주던 모습은 잊혀지지 않는다;) Junior 의 입장에서 Expert 행동 하나하나는 Check Point 이다. 좋은 습관과 프로그래밍 스타일, 디버깅하는 모습을 직접 눈으로 확인할 수 있었다.
        * 대화 - 상대방이 '알고 있을 것이다' 라는 점도 실제는 모르고 있는 경우가 많다라는 생각을 해본다. 친한친구 이더라도, 상대방을 잘 안다라고 생각하더라도, 상대로부터 읽지 못한 정보는 너무나 많기에.
        * 협동 - 이번경우는 비교적 협동이 잘 된 경우라고 생각한다. Python 으로 문제를 풀기 위한 프로그래밍을 하는데는 석천이, Idea 와 중간에 데이터 편집을 하는데에는 정규표현식을 잘 이용하는 상민이가 큰 도움을 주었다. 적절한 때에 적절하게 주도하는 사람이 전환되었던 것으로 기억.
        * 집중 - 이번 경우에는 '시간제한' 이라는 것까지 있어서인지; 석천은 더더욱 프로그래밍 자체에 집중했다. (스크립트 언어 스타일의 접근방법과 이전의 TDD 연습도 한몫 거든듯. 조금씩 만들고 결과 확인해보고 조금 또 만들어보고 결과 확인을 했다. 단, 이번엔 Test Code 를 안만들어서, 뒤에가서 버그가 났을때 대체를 못했다는.-_-; 잘될때는 문제가 아니다. 잘 안될때, 문제상황에 대한 대처가 중요하다고 생각.)
       넷미팅, VNC 등의 개발 프로그램을 공유할 수 있는 프로그램과 음성채팅 등으로 Virtual PairProgramming을 할 수 있다. (오.. 좋아진 세상~) 단,PairProgramming 에 비해 아쉬운점들이 있다. (관련 책들을 찾아서 보여주지 못한다는 것 등등) 나중에는 PC카메라와 스캐너 등등 이용할 수 있지 않을까. ^^
       나는 일차적으로 switch코드를 없앨 수 있다는 점을 설명했다. 우리는 Connection클래스가 그다지 크게 바뀌지 않을 것이라는 것에 대해 동의했었고 이 점을 근거로 switch를 사용하는 것이 유지보수를 힘들게 하는가에 대해 질문했다. 솔직히 이정도 코드라면 누구나 수정할 수 있을 것이라고 생각한다. 그리고 그렇게 많은 시간을 필요로 하는 작업도 아니라고 생각한다. 파트너는 Connection을 생성하는 부분을 include 화일로 관리하고 그곳에 한번만 define문을 작성하면 문제가 없다고 주장했다.
       나는 이에 대해 하나의 프로젝트에서 여러개의 데이타베이스를 사용하게 될 경우 여러개의 추가적인 파일들을 관리해야 될지도 모른다고 했다. 그리고 new SqlConnection(); , new MySqlConnection()과 같은 방식으로 사용하는 것이 더 직관적인 것 같다고 설명했다.
       긴 토론 끝에 파트너는 나의 의견에 동의했지만 만약 계속 이런 속도로 작업이 진행된다면 회사에서 가만있지 않을 것이다. (어제도 TDD를 사용했었는데 기존의 코딩시간에 비해 3배정도 더 늦어졌다. 그리고 다 끝내지도 못했고 무엇을 먼저 테스트 해야할지 갈팡질팡했었다. 처음부터 함수단위 테스트만 시도해야겠다는 생각이 원인같다.)
• VendingMachine/세연/1002 . . . . 21 matches
       여기서는 저 위의 1-4번 원칙만 생각해 보겠습니다. 일단 이 코드가 제대로 돌아간다는 가정하에서 수정합니다. (문제는 제대로 고쳐졌는지 확인할 길이 적다는. -_-;)
        VendingMachine.PrintErrorMessage ();
        void PrintErrorMessage ();
       void vending_machine::PrintErrorMessage ()
        VendingMachine.PrintErrorMessage ();
       void vending_machine::printErrorInvalidCoinMessage () {
        printErrorInvalidCoinMessage ();
        printErrorInvalidCoinMessage ();
        printErrorInvalidCoinMessage ();
        void PrintErrorMessage ();
        void PrintErrorInvalidCoinMessage ();
       void vending_machine::PrintErrorInvalidCoinMessage () {
        PrintErrorInvalidCoinMessage ();
       void vending_machine::PrintErrorMessage ()
        PrintErrorMessage ();
       void PrintErrorMessage ();
       void PrintErrorInvalidCoinMessage (VendingMachine& vendingMachine);
       void PrintErrorInvalidCoinMessage (VendingMachine& vendingMachine) {
       void PrintErrorMessage ()
        PrintErrorInvalidCoinMessage (vendingMachine);
• 새싹교실/2012/startLine . . . . 18 matches
        * 처음이라 간단하게 하려고 변수와 연산에 대해서만 말을 했는데, 간단하게 하려고 하니까 너무 내용이 간단해져서 뭔지 모르는 사이에 내용이 다 끝나버렸습니다. 그렇다고 잘 했느냐고 하면 그것도 딱히 아닌 느낌이네요. 앞으로는 실습 위주로 하면서 조금 더 자세하게 진행을 해야 하지 않을까 싶습니다. 경우에 따라서는 완전히 다른 방법을 써야 할지도 모르겠지만... 어쨌든 아는 것과 가르치는 것은 다르다는 것을 새삼 느낀 시간이었습니다. - [서민관]
        * 재현이가 기존에 아는 부분들(변수, 제어문) 확인.
        * 일단 재현이가 기존에 C를 어느 정도 공부했는지를 확인하기 위한 시간이라 따로 과제를 준비하지 못 했음.
        * 최재현 - 아는 범위를 확인하고 앞으로의 방향에 대해 얘기 했습니다. 다음에는 모르는 것들에 대해 배우고 아는 것은 확실히 배워야겠습니다.
        * 서민관 - 제어문의 사용에 대한 수업(if문법, switch.. for...) 몇몇 제어문에서 주의해야 할 점들(switch에서의 break, 반복문의 종료조건등..) 그리고 중간중간에 쉬면서 환희가 약간 관심을 보인 부분들에 대해서 설명(윈도우 프로그래밍, python, 다른 c함수들) 저번에 생각보다 진행이 매끄럽지 않아서 이번에도 진행에 대한 걱정을 했는데 1:1이라 그런지 비교적 진행이 편했다. 그리고 환희가 생각보다 다양한 부분에 관심을 가지고 질문을 하는 것 같아서 보기 좋았다. 새내기들이 C를 배우기가 꽤 힘들지 않을까 했는데 의외로 if문이나 for문에서 문법의 이해가 빠른 것 같아서 좀 놀랐다. printf, scanf나 기타 헷갈리기 쉬운 c의 기본문법을 잘 알고 있어서 간단한 실습을 하기에 편했다.
        * 간단한 이전 시간(if문, 반복문)의 복습과 배열의 사용에 대해 알아보았다. 그리고 이번 시간에 주로 한 내용은 함수가 왜 필요한지와 함수를 만드는 법, 함수를 사용하는 법 등이었다. 개인적으로는 함수를 꽤 중요하게 생각하는 만큼 함수의 필요성을 잘 캐치해 줬으면 좋겠다. 그리고 새삼 드는 생각이지만 환희의 질문이 중요한 부분을 잘 찌른다는 생각이 든다. 별다른 언급도 없었는데 함수 내에서 변수의 scope나 함수 내부의 이름 겹침 등에 대한 질문이 있었다. 그리고 중간에 함수 사용의 예제로 printf문을 약간 이상하게 쓴 코드를 보여줬는데 의외로 감을 잘 잡은 것 같았다. 현재 진행상황으로는 다음에 포인터를 다뤄야 할텐데 함수를 쓰는 것을 조금 더 연습을 시킬지 바로 포인터를 나갈지 고민이다. 당장 포인터를 했다가 어려워하지 않을까 모르겠다. - [서민관]
        * 재현, 성훈이의 함수에 대한 지식 확인.
        * swap 함수를 만들어보고 문제점 확인.
        * 처음에 간단하게 재현, 성훈이의 함수에 대한 지식을 확인했다. 그 후에 swap 함수를 만들어 보고 실행시의 문제점에 대해서 이야기를 했다. 함수가 실제로 인자를 그대로 전달하지 않고 값을 복사한다는 것을 이야기 한 후에 포인터에 대한 이야기로 들어갔다. 개인적으로 새싹을 시작하기 전에 가장 고민했던 부분이 포인터를 어떤 타이밍에 넣는가였는데, 아무래도 call-by-value의 문제점에 대해서 이야기를 하면서 포인터를 꺼내는 것이 가장 효과적이지 않을까 싶다. 그 후에는 주로 그림을 통해서 프로그램 실행시 메모리 구조가 어떻게 되는지에 대해서 설명을 하고 포인터 변수를 통해 주소값을 넘기는 방법(call-by-reference)을 이야기했다. 그리고 malloc을 이용해서 메모리를 할당하는 것과 배열과 포인터의 관계에 대해서도 다루었다. 개인적인 느낌으로는 재현이는 약간 표현이 소극적인 것 같아서 정확히 어느 정도 내용을 이해했는지 알기가 어려운 느낌이 있다. 최대한 메모리 구조를 그림으로 알기 쉽게 표현했다고 생각하는데, 그래도 정확한 이해도를 알기 위해서는 연습문제 등이 필요하지 않을까 싶다. 성훈이는 C언어 자체 외에도 이런저런 부분에서 질문이 많았는데 아무래도 C언어 아래 부분쪽에 흥미가 좀 있는 것 같다. 그리고 아무래도 예제를 좀 더 구해야 하지 않을까 하는 생각이 든다. - [서민관]
        * 개인적으로 현재 시점에서 과제를 낸다면 C의 문법을 익히기 위한 과제를 준비할 것 같은데 환희가 현재 시점에서 C 문법을 나름대로 잘 쓰는 만큼 그렇게까지 무리해서 과제를 낼 필요는 없지 않을까 싶다. 사실 언제쯤부터 어떤 과제들을 내야 할지 정확히 감이 안 잡히는 것도 있지만... - [서민관]
        * 저번시간에 했던 swap 함수에 대해서 간단하게 복습을 하고 swap 함수의 문제점에 대해서 짚어보았다. 그리고 포인터의 개념과 함수에서 포인터를 사용하는 방법 순으로 진행을 해 나갔다. 새삼 느끼는 거지만 call-by-value의 문제점을 처리하기 위해서 포인터를 들고 나오는 것이 가장 직접적으로 포인터의 필요성을 느끼게 되는 것 같다. 그리고 개념의 설명을 하기에도 편한 것 같고. 그 후에는 포인터에 대한 부분이 일단락되고 성훈이나 재현이처럼 malloc이나 추가적인 부분을 진행할 예정이었는데 환희가 함수의 사용에 대해서 질문을 좀 해 오고 그 외에도 약간 다른 부분을 다루다 보니 진도가 약간 늦어졌다. 그래도 포인터에서는 이해가 가장 중요하다고 생각하는 만큼 조금 천천히 나가는 것도 괜찮다고 본다. 그리고 앞으로의 목표는 일단 처음에 잡아둔 목표까지 무사히 완주하는 것이다. 원래 첫 진도 예정에 다양한 것들이 담겨있는 만큼 목표만 이루어도 충분히 괜찮은 C 실력이 길러지지 않을까 싶다. - [서민관]
        * 정모 전에 두 시간, 정모 끝나고 두 시간이 걸린 정말 긴 새싹이었습니다. ;;;; 처음 계획으로는 재현이나 성훈이랑 비슷하게 구조체 문법과 사용에 대해서 간단하게 다룰 생각이었는데 환희가 왜 구조체가 필요한지에 대한 이야기를 하면서 이야기가 많이 다른 방향으로 흘러갔네요. 일단 구조체가 필요한 이유를 추상화의 관점에서 추상화 한 타입(구조체)과 타입에 관한 연산(함수)을 제공하기 위해서라고 말을 했는데 그래도 직접 피부에 와 닿았을지 어떨지는 좀 걱정입니다. 역시 이런 부분은 직접적으로 경험을 해 보지 않으면 안 될 것 같네요. 한 시스템(도서관 관리 프로그램이나 은행 시스템 등)을 재현이, 성훈이랑 셋이서 쪼개서 만들어 보게 하거나 하는 게 좀 괜찮지 않을까 싶습니다. 나중에 시켜봐야지. - [서민관]
        * 전체적으로 문자열과 문자열을 다루는 함수만에 초점을 맞춰서 수업을 진행했습니다. 그런데 아무래도 첫 시간에 못지 않게 진행이 늘어졌던 시간이 아니었나 싶습니다. 사실 문자열 함수들은 단순 함수니만큼 인자들을 보고 쓰는 것에 익숙하다면 알아서도 보고 쓸 수준이긴 한데, 그래도 다들 그런 것을 찾아서 써 보거나 한 경험이 별로 없는 만큼 한 번쯤 그런 함수들을 찾아서 쓰는 시간을 가지는 것도 나쁘지 않지 않을까 싶었는데 생각보다 좀 진행이 늘어졌군요. 단순히 설명만 이어졌기 때문인가. 그래도 이번 시간에 굳이 문자열과 관련 함수를 다룬 것은 C언어에서 문자열을 단순한 char의 *가 아닌 하나의 타입으로 보고 그와 관련된 연산(함수)을 제공했다는 것을 한 번쯤 생각해봤으면 합니다. - [서민관]
        * LinkedList에서 구현할 연산들과 구현시 신경 써야 하는 부분들(경우의 수).
• MoniWikiPo . . . . 17 matches
       msgid "Error: No blog entry found!"
       msgid "Error: Don't make a clone!"
       msgstr "<b>가로선</b> ----는 블로그일 경우 적용되지 않습니다."
       msgid "Fatal error !"
       msgid "Error: Don't try to overwrite it"
       msgid "Error: tarball does not exists"
       msgid "Error: Page Not found !"
       msgid "Error: No entry found!"
       msgstr "이메일 주소 확인이 완료되었습니다"
       msgstr "새 비밀번호 확인이 완료되었습니다"
       msgstr "확인이 맞지 않습니다 !"
       msgstr "새 비밀번호 확인"
       msgstr "새 비밀번호를 확인해 주세요"
       msgstr "이메일을 확인해 주세요"
       msgstr "이메일 주소를 먼저 확인해 주세요 !"
       msgstr "이메일을 확인해 주세요"
       msgstr "이메일 확인"
       msgstr "이메일 주소를 확인해 주세요"
       msgid "Conflict error!"
• 새싹교실/2011/데미안반 . . . . 15 matches
        * 나중에 포인터를 사용하는 실습을 하다 보면 많은 깨달음을 얻을 수 있지 않을까 싶습니다...
        * 아무래도 성과가 바로바로 눈에 보이게 출력하여 확인할 수 있는 함수이다 보니, 초보자가 바로 이해하기 어려움에도 불구하고 처음에 배우게 되는 듯 합니다.
        assert(val1 == 7); //val1이 7인 경우 정상 종료, 아닌 경우 오류 출력
        assert(val2 == 4); //val2이 4인 경우 정상 종료, 아닌 경우 오류 출력
        * 기타 대입 연산자 사용 예에서 -= , /= , %= 한 결과를 assert(val1 == 7); 와 같이 assert함수 안에 넣어 확인하시오.
        // 이경우엔 int를 안 써주는게 맞나요???
        * assert는 '''강하게 주장하다'''라는 의미로 위와 같은 경우 val1이 7이 아니다! val2가 4가 아니다! 라고 주장한다는 의미입니다. 하지만 val1값은 7이고, val2의 값은 4니까 에러창을 띄워 주장이 잘못됐다고 알려주는 거에요. 전체적으로 의문사항은 assert문보다는 '''!='''의 의미를 잘 몰라서 그런 듯 합니다. == 는 같다, !=는 아니다라는 의미의 관계연산자입니다.
        * [강소현] - 4피에서 수업이 없는 줄 알고 괜히 이동했다가 다시 6피로 이동하는 번거로운 일을 했었는데, 앞으로는 얌전히 6피에서만 수업을 해야겠어요. 수요일 11시부터 12시까지 딱 새싹 시간에 다른 수업이 있는 줄 몰랐었어요 ㅠㅠ printf와 scanf에서 시간을 많이 투자해서, 급하게 연산자를 쭉쭉- 설명하고 끝내느라 기억에 남지 않을 것 같습니다. 따라서 연산자에 관한 간단한 과제를 내어 익히도록 하겠습니다.(?!) 준비를 잘 해와야하는데, 계속 부족한 강의라고만 하는 것은 겸손이 아니라 그냥 자기비하란 생각이 문득 들었습니다. 그 동안 푸념을 들어주어 미안했고, 앞으로는 그런 일이 없도록 할 것입니다.
        * [박성국] - 오늘은 if를 활용하는 방법에 대해서 자세히 배웠어요^^ 그리고 if와 비슷한 switch를 이용하여 다양한 경우를 출력해 보는것 또한 배웠어요:)
        * [강소현] - if,for,while,switch를 배우고, 실습을 병행하였습니다. 구구단에서 홀수만 출력하는 경우 i+=2 를 하거나, continue를 활용하는 사례도 시행해보았습니다. 다음 주는 시험 일주일 전인 관계로 수업을 휴강하겠습니다. 시험 끝나고 봐요~ㅁ~
        * [강소현] - 함수의 형태를 반환형이 있는 지의 여부와 매개변수가 있는 지의 여부에 따른 4 가지를 실습하여 차이를 알아보았습니다. 그리고 재귀함수에 대한 진도도 나갔으나, 아무래도 그냥 함수 한번 호출하고 끝낼 때보다 이해가 잘 가지 않는 듯 합니다. 다음 시간에 한번 더 복습할 예정입니다. 재귀함수로 만드는 factorial이나 gcd 같은 것을 점화식을 설명하고 보여주면 좀 더 이해가 쉽지 않을까 싶었습니다.
        * [강소현] - 한 시간은 정말 금방 가네요. 근데 왜 학교 수업 들을 때는 그리 길었던거지!? 재귀함수를 사용할 경우 항상! 빠져나올 수 있는 '''조건'''을 걸어야 한다는 것을 복습했습니다. 뭔가 도미노 원칙 어쩌구 하긴 했지만 정확한 게 아니라 비슷하다-고 했던거에요. 정확한 건 3학년 알고리즘 시간에 divide&conquer을 배우면...<< 간단히 설명하자면 한번에 풀기 힘드니까 나눠서 풀자는 내용입니다.
        * 위키 정리가 매우 알차네요!! 그런데 한편으론 이렇게 정리하려면 위키에 적는 것이 새싹교실 선생님에게 너무 부담스럽지 않을까 싶은 걱정도 듭니다. 즐겁게 정리하고 있다면 정말 좋은 일이지만 혹시 너무 부담스럽다면 덜 꼼꼼히 적어도 괜찮을 것 같아요~ - [김수경]
• MoreEffectiveC++/Operator . . . . 14 matches
       cout << r; // error!
       이런 경우에 operator==의 오른쪽에 있는 인자는 int가 single-argument constructor에 거칠수 없기 때문에 에러를 밷어 낸다.
       암튼 저 위와 같이 하면 이해가 갈것이다. 하지만 이럴 경우 요 짓거리를 못한다.
       위의 코드에서는 strlen() 함수내부에서 p에 관련한 null pointer 검사가 필요하지 않다. 왜냐하면 && 에서는 앞의 조건이 부정 즉, ( false && anything ) 의 경우에는 뒤의 조건(anything)은 수행조차 안하기 때문이다. operator ||의 경우도 특정 조건에서,(true || anything) 뒤에 코드를 수행하지 않은다는 것은 비슷하다.
       수많은 개발자들이 이런 단순한 원리를 프로그램 상에서의 짧은 진행(short-circuit)을 추구하는데 사용하였다. 그렇다면 C++에서의 객체들에게 operator ||, && 를 overload 시키면 짧은 진행을 추구하는데 도움이 되지 않을까? 그런데 하지 말라니 왜일까? [[BR]]
       일단 operator &&, ||는 이렇게 두가지의 경우로 둘릴수 있다.
       자 이 두경우 모두를 생각해 보면 1,2 양쪽 다 expression1, expression2 의 결과 값이 필요한 상황이다. 즉, operator && 나 operator || 의 경우 양쪽이 class인자든, 어떤 형태이든 반드시 결과 값이 필요하다. 위에도 언급했지만, 이미 많은 개발자들이 &&와 ||의 특성을 잘 알고 사용하고 있으며, operator &&, ||의 overload는 구동되지 말아야할 코드가 구동되는 의도하지 않은 오류가 발생 소지가 있다.
       보통 C++에서 용어들을 정확히 이해 못할 경우가 있다. 바로 ''new''operator와 ''operator new''가 그 대표적인 예가 될수있을 것이다. 다음의 코드를 보자
       당신은 생성자를 직접 호출하기를 원할때가 있을 것이다. 하지만 생성자는 객체(object)를 초기화 시키고, 객제(object)는 오직 처음 주어지는 단 한번의 값으로 초기화 되어 질수있기 때문에 (예-const 인수들 초기화에 초기화 리스트를 쓰는 경우) 생성자를 이미 존재하고 있는 객체에 호출한다는건 생각의 여지가 없을 것이다.
       해당 함수(construcWidgetInBuffer())는 버퍼에 만들어진 Widget 객체의 포인터를 반환하여 준다. 이렇게 호출할 경우 객체를 임의 위치에 할당할수 있는 능력 때문에 shared memory나 memory-mapped I/O 구현에 용이하다 constructorWidget에 보이는건 바로
       이거 간단히 보이지만 placement new의 전부이다. operator new의 역할은 해당 객체를 위한 메모리를 찾고(할당), 해당 포인터의 반환이고 placement new의 경우에는 호출자가 이미 메모리를 확보하였고, 단순히 포인터 반환만 해준다. 모든 placement new가 반드시 이런 pointer의 전달 역할을 한다. 그리고 size_t 인자가 아무런 이름이 없어도 반항 안한다. 자세한건 Item 6을 보면 이해가 갈것이다.
       그리고 이것의 의미는 당신이 초기화 되지 않은 raw로의 사용의 경우에는 new와 delete operator로 그냥 넘겨야 한다는 의미가 된다. 즉 이코드 대신에 다음의 예를 볼수 있을 것이다.
       별다른 특별한 지적사항이 없다. 여태 까지의 연장선이고 단 new를 이용한 배열 할당을 삭제할 경우
• VonNeumannAirport . . . . 13 matches
        * ["1002"] 의 개인적으로 생각되는 '미숙' 했다고 생각한 점을 든다면, 평소에 프로그래밍을 하는 리듬이 아니였다는 점. 이전 스타일이라면 일단 문제를 보고 문제를 나누면서 시나리오를 어느정도 만들어 놓은 뒤, 그걸 검증해나간다는 느낌으로 테스트코드를 작성했었는데, 이번의 경우 정말 Extreme 하게 작업한 것 같다. (중반에 CRC 라도 한번 하고 싶었는데, 형에게 물어보고 왠지 '아 내가 알던 방법이 틀린걸꺼야' 하며 그냥 Test 만 생각하게 되었다.) 작업하는 중간 뭔가 석연치 않은 느낌이 들었다면, 아마 대강 이런 느낌이였던 것 같다. 전반적 시각을 한번정도 중간에 정리를 할 필요가 있을건데, 그런 시간을 두지 못한것.
        * load 를 발생시키는 예를 Passenger 뿐만 아니라 다른 여러가지를 둔다. ex) 여행객 가방, 컨테이너의 경우 traffic load 2, 4 를 발생시킨다.
        -> 이 경우 PassengerSet 이 따로 빠져있지 않은 경우 고생하지 않을까. PassengerSet 이 빠져있다면, 가방, 컨테이너 부분들에 대해서 case 문이 복잡해질듯.
        -> 이에 따라 Input 부분이 바뀌고, Input 부분이 클래스와 합쳐진 코드의 경우 더더욱 골치.
        * PassengerSet Case가 여러개이고 Configuration 은 1개인 경우에 대해서. Configuration 1 : 여러 Case 에 대해 각각 출력하는 경우.
        -> 역시 PassengerSet 이 따로 있어서 Configuration 과 같이 협동할 경우엔 쉽게 구현 가능. 그렇지 않은 경우 고생 예상.
        -> Output 쪽이 따로 나누어진 경우 금방.
• XMLStudy_2002/Start . . . . 13 matches
        1 Invalid Documents : XML의 태그 규칙을 따르지 않거나,DTD를 사용한 경우에 DTD에 정의된 규칙을 제대로 따르지 않는 문서
        step2. DTD를 사용하는 경우 사용할 DTD 선정 또는 새로 설계하여 작성
        2. DTD(Optional) : DTD를 사용하는 경우에는 어떤 DTD를 사용할지를 선언한 내용또는 DTD가 포함
        *EMPTY : 컨텐츠 스펙이 EMPTY인 경우라면 이 엘리먼트는 내용으로 아무 것도 갖을 수 없다는 것을 의미하고 empty element로 사용
        *Public Identifier는 어디에서 사용되는가? : 공용 엔티티나 공용 DTD를 사용하는 경우에 PI가 사용됨
       10진수의 경우 코드 값이 n일 때<!ENTITY name "&#n;">
       16진수의 경우 코드 값이 n일 때<!ENTITY name "&@xn;">
       엘리먼트를 사용할 때 FIXED로 타입이 지정된 경우에 선언된 디폴트 값과 다른 값을 어트리 뷰트의 값으로 사용할수 없을을 의미함
       id 어트리뷰트의 타입은 ID이고 이 어트리뷰트는 반드시 사용해 주어야 하는 것으로 선언되었다. 그리고 reply_required 라는 어트리뷰트는 이 어트리뷰트의 값으로는 "yes"와"no"만 사용될수 있으며 만약 어트리뷰트가 명시되지 않았을 경우에는 디퐅르 값으로 "yes"를 사용한다.
       이경우에는 desc라는 어트르뷰트를 사용하지 않아도 되고,만약 사용하는 경우에 이 어트리뷰트의 값에는 White space 처리를 하지 않겠다는 예이다.
        *별표(*) : 요소가 없을 수 있다. 만일 있는 경우는 임의의 수만큼 반복될 수 있다(즉, 요소는 0번이상 반복해서 나타난다).
        *물음표(?) : 요소가 없을 수 있다. 만일 있는 경우는 요소가 단 하나만 있어야 한다(즉, 요소는 없거나 하나만 있어야 한다.).
• Gof/Singleton . . . . 12 matches
       몇몇 클래스들에 대해서 오직 하나의 인스턴스 만을 가지는 것은 중요한 일이다. 예를 들면, 어떤 시스템에선 수많은 프린터들이 있더라도 거기에는 단 하나의 프린터 스플러만이 있어야 한다. OS에서 돌아가는 화일시스템이나 윈도우 매니저의 경우도 오직 하나여야 한다 (동시에 2-3개의 윈도우매니저가 돌진 않는다.) 디지털 필터의 경우에도 A/D converter는 단 하나를 가진다.
       어떻게 우리는 클래스로 하여금 단 하나의 인스턴스만을 가지도록 보장해줄 수 있을까? 그리고 그러한 인스턴스를 쉽게 접근하게 할 수 있을 것인가? global 변수로 둘 경우 어디서든지 접근가능하겠지만, global 변수는 단일 인스턴스만을 가지도록 할 수 없다.
       SingletonPattern은 다음과 같은 경우에 사용한다.
        * 단일 인스턴스가 서브클래싱에 의해 확장가능해야 할 경우. 그러면 클라이언트는 그들의 코드 수정없이 확장된 인스턴스를 사용할 수 있어야 한다.
        3. 명령어와 표현을 확장시킬 수 있다. Singleton class는 subclass될 수 있고, 이 확장된 클래스의 인스턴스를 가지고 어플리케이션을 설정하는 것은 쉽다. run-time중에 필요한 경우에도 가능하다.
       1. unique instance임을 보증하는 것. SingletonPattern의 경우도 일반 클래스와 마찬가지로 인스턴스를 생성하는 방법은 같다. 하지만 클래스는 늘 단일 인스턴스가 유지되도록 프로그래밍된다. 이를 구현하는 일반적인 방법은 인스턴스를 만드는 operation을 class operations으로 두는 것이다. (static member function이거나 class method) 이 operation은 unique instance를 가지고 있는 변수에 접근하며 이때 이 변수의 값 (인스턴스)를 리턴하기 전에 이 변수가 unique instance로 초기화 되어지는 것을 보장한다. 이러한 접근은 singleton이 처음 사용되어지 전에 만들어지고 초기화됨으로서 보장된다.
       클래스를 사용하는 Client는 singleton을 Instance operation을 통해 접근한다. _instance 는 0로 초기화되고, static member function 인 Instance는 단일 인스턴스 _Instance를 리턴한다. 만일 _instance가 0인 경우 unique instance로 초기화시키면서 리턴한다. Instance는 lazy-initalization을 이용한다. (Instance operation이 최초로 호출되어전까지는 리턴할 unique instance는 생성되지 않는다.)
        * (b) 모든 singleton들이 static initialization time 대 인스턴스되기 위한 충분한 정보를 가지고 있지 않을수도 있다. singleton은 프로그램이 실행될 때 그러한 정보를 얻을 수 있다.
        self error: 'cannot create new object'
       registry 는 string name 과 singletons 을 mapping 한다. singleton의 instance가 필요한 경우, registry에 string name으로 해당 singleton 을 요청한다. registry는 대응하는 singleton을 찾아서 (만일 존재한다면) 리턴한다. 이러한 접근방법은 모든 가능한 Singleton class들이나 instance들을 Instance operation이 알 필요가 없도록 한다. 필요한 것은 registry에 등록될 모든 Singleton class들을 위한 일반적인 interface이다.
       물론, 코드 어디에선가 클래스를 인스턴스화하지 않으면 생성자는 호출되지 않을 것이다. C++에서는 MySingleton의 static instance를 정의함으로서 이 문제를 잘 해결할 수 있다. 예를 들어, MySingleton 클래스의 구현부를 포함하는 화일에 다음과 같이 정의하면 된다.
       자, 이제 MazeFactory의 subclassing에 대해 생각해보자. MazeFactory의 subclass가 존재할 경우, application은 반드시 사용할 singleton을 결정해야 한다. 여기서는 환경변수를 통해 maze의 종류를 선택하고, 환경변수값에 기반하여 적합한 MazeFactory subclass를 인스턴스화하는 코드를 덧붙일 것이다. Instance operation은 이러한 코드를 구현할 좋은 장소이다. 왜냐하면 Instance operation은 MazeFactory를 인스턴스하는 operation이기 때문이다.
       error C2248: 'CNSingleton::CNSingleton' : cannot access private member declared in class 'CNSingleton' 라고 에러가 발생합니다.
• HelpOnUserPreferences . . . . 12 matches
        * OpenID를 지원하는 경우는 OpenID를 쓰실 수 있습니다.
        * 웹상의 비번은 쉽게 노출될 가능성이 많으므로 가능한 노출되어도 큰 문제가 되지 않을 비밀번호를 사용하시기 바랍니다.
        * '''[[GetText(Password repeat)]]''': 초기 사용자 등록시에 나타납니다. 바로 위에서 입력했던 비밀번호를 확인하는 단계로, 조금 전에 넣어주었던 비밀번호를 그대로 집어넣어 주시면 됩니다.
        * '''[[GetText(Email)]]''': 자주 쓸 이메일 주소. 이메일 주소를 넣어주면 원하는 위키페이지에 대하여 그 변경점을 구독신청하거나 취소하실 수 있습니다. 비밀번호를 잊으셨을 경우에도 이 이메일 주소를 사용해 새로운 비밀번호를 등록하실 수 있습니다.
        * 이메일 주소는 반드시 고유해야 하며, ACL 설정에 따라서는 이메일 주소를 반드시 필요로 하는 경우도 있습니다.
        * 시스템의 기본 설정에 따라서는 테마 변경을 지원하지 않을 수도 있습니다.
        * '''[[GetText(User CSS URL)]]''': 자신이 원하는 CSS로 변경하고 싶을 경우에 사용합니다.
        * 시스템의 기본 설정에 따라서는 CSS변경을 지원하지 않을 수도 있습니다.
        * '''[[GetText(Subscribed wiki pages (one regex per line))]]''': 모든 페이지의 변경알림을 받아보고 싶은 경우에 '''`.*`''' 를 집어넣으시면 됩니다. (위키위키가 많은 변경이 있는 경우 권장하지 않습니다.) 각 페이지를 보고싶은 경우에는 각각의 페이지 이름을 줄 단위로 넣으시면 됩니다. 정규식에 익숙하신 사용자의 경우에 정규식을 사용하실 수도 있습니다. 설정에 따라서 상단의 아이콘 툴바에 [[Icon(email)]]이 나타날 수 있으며, 이메일 아이콘을 누르면 해당 페이지를 구독하는 폼이 뜨게 됩니다.
• MindMapConceptMap . . . . 12 matches
       MindMap 의 경우, 일반적인 책들과 같이 그 체계가 잘 잡혀 있는 지식에 대해 정리하기 편리하다. (SWEBOK 과 같이 아에 해당 지식에 대한 뼈대를 근거로 지식을 분류해놓은 책같은 경우에는 더더욱) 일반적으로 한 챕터에 대해서 5-10분정도면 한번 정리를 다 할 수 있을 정도로 필기할때 속도가 빠르다. 그러면서 해당 중심 주제에 대해서 일관적으로 이어나갈 수 있도록 도와준다. (이는 주로 대부분의 책들이 구조적으로 서술되어있어서이기도 할 것이다.)
       MindMap 의 문제점은 중간에 새어나가는 지식들이 있다. 기본적으로 그 구조가 상하관계 Tree 구조이기 때문이다. 그래서 보통 MindMap 을 어느정도 그려본 사람들의 경우 MindMap을 확장시켜나간다. 즉, 중심 개념을 여러개 두거나 상하관계구조를 약간 무시해나가면서. 하지만 여전히 책을 읽으면서 잡아나간 구조 그 자체를 허물지는 않는다.
       ConceptMap 은 'Concept' 과 'Concept' 간의 관계를 표현하는 다이어그램으로, 트리구조가 아닌 wiki:NoSmok:리좀 구조이다. 비록 도표를 읽는 방법은 'TopDown' 식으로 읽어가지만, 각 'Concept' 간 상하관계를 강요하진 않는다. ConceptMap 으로 책을 읽은 뒤 정리하는 방법은 MindMap 과 다르다. MindMap 이 주로 각 개념들에 대한 연상에 주목을 한다면 ConceptMap 의 경우는 각 개념들에 대한 관계들에 주목한다.
       개인적으로 처음에 MindMap 보다는 그리는데 시간이 많이 걸렸다. 하지만, MindMap 에 비해 각 개념들을 중복적으로 쓰는 경우가 적었다. (물론 MindMap 의 경우도 중복되는 개념에 대해서는 Tree 를 깨고 직접 링크를 걸지만) MindMap 의 Refactoring 된 결과라고 보면 좀 우스우려나; 주로 책을 정리를 할때 MindMap 을 하고 때때로 MindMap 에서의 중복되는 개념들을 토대로 하나의 개념으로 묶어서 ConceptMap 을 그리기도 한다.
        * MindMap 과 ConceptMap 을 보면서 알고리즘 시간의 알고리즘 접근법에 대해서 생각이 났다. DivideAndConquer : DynamicProgramming. 전자의 경우를 MindMap 으로, 후자의 경우를 ConceptMap 이라고 생각해본다면 어떨까.
        ''MindMap 에 경우 중요시 하는 것 중 하나가 연상을 더욱 더 용이하게 하는 이미지이기도 하죠. --석천''
       MindMap 의 표현법을 다른 방면에도 이용할 수 있다. 결국은 트리 뷰(방사형 트리뷰) 이기 때문이다. [1002]의 경우 ToDo 를 적을때 (보통 시간관리책에서 ToDo의 경우 outline 방식으로 표현하는 경우가 많다.) 자주 쓴다. 또는 ProblemRestatement 의 방법을 연습할때 사용한다. --[1002]
• 새싹교실/2012/세싹 . . . . 12 matches
        - physical : 비트들을 물리적으로 이동시키는 역할을 합니다. 유선의 경우 다양한 케이블, 무선일 경우 공기가 매체가 되겠네요.
        - 서버소켓의 경우 창구의 역할을 하기때문에 클라이언트에서 서버로 요청이 올 경우 별도의
        2) 하나의 클라이언트가 다수의 서버에 연결을 요청하는 경우에는 어떻게 될까요?
        - 양방향 통신중 한쪽이 off-line상태인 경우에도 메시지의 전송과 수령이 가능하도록
        * 하나의 클라이언트가 다수의 서버에 연결 요청하는 경우도 해봅시다.
        * 컴파일이 안되서 인터넷으로 확인해보니 다중 스레드를 쓰려면 gcc에 옵션 -lpthread를 주어야하는군요. - [김희성]
        2) 하나의 클라이언트가 다수의 서버에 연결을 요청하는 경우
        * fopen의 경우 Standard함수인데 같은 input일 때, 리눅스에서 다르게 작동할지 궁금합니다. - [김희성]
        * 값을 확인하는데 이상한 값이 나와 검색해보니 MFT에서도 Little Endian형식을 쓰는 군요. - [김희성]
        * CreateFile함수 사용시 문자열이 LPCWSTR로 변환되지 않는 문제가 생기는 경우에는 CreateFileA를 사용해보세요.
• Java Study2003/첫번째과제/장창재 . . . . 11 matches
       자바는 컴파일 시에 에러 검사를 철저하게 하고, 실행 시에 발생할 수 있는 에러에 대해서도 실행 시에 철저하게 검사를 수행함으로써 신뢰도가 높은 프로그램을 작성할 수 있도록 해 줍니다. 또한, C/C++ 프로그램 개발자들을 가장 혼란스럽게 하고, 프로그램의 치명적인 오류를 발생시킬 수 있는 포인터 및 포인터 연산을 자바에서는 사용하지 않게 함으로써, 포인터를 사용함으로써 프로그래머가 범할 수 있는 오류를 없앴다는 것입니다.
       자바 애플릿을 실행시키기 위해 애플릿을 다운로드해야 하는데, 이 때 애플릿에서 사용하는 데이터들도 존재할 수 있습니다. 예를 들어, 애니메이션을 수행하는 애플릿이 있는 HTML 페이지에 접속하여 그 애플릿을 실행시켜야 할 경우, 해당 애플릿 파일과 애플릿에서 애니메이션을 위해 사용하는 각 프레임 이미지도 존재할 것입니다. 따라서, 애플릿 파일은 물론 애플릿에서 사용하는 이미지 파일도 다운로드해야 애플릿에서 제대로 애니메이션을 수행할 수 있겠지요. 이 때, 애플릿 실행과 관련된 모든 파일을 JAR 또는 ZIP 형태의 압축 파일로 묶어 전송하게 됩니다. 이렇게 함으로써, 느린 네트워크를 이용하여 애플릿과 관련된 파일들을 다운로드 하는데 드는 시간을 줄일 수 있습니다.
       다운로드 받은 애플릿과 애플릿 관련 파일들은 웹 클라이언트의 디스크에 캐싱합니다. 예를 들어, 웹 클라이언트가 애플릿이 포함된 페이지를 보다가 다른 페이지에 잠깐 들렀다가 애플릿이 포함된 페이지로 다시 돌아올 경우, 애플릿과 관련된 모든 파일들을 다시 다운로드하는 것이 아니고 웹 클라이언트의 디스크에 캐싱 되어 있는 애플릿 관련 파일들을 사용하게 됩니다. 이렇게 함으로써, 느린 네트워크를 이용하여 애플릿과 관련된 파일들을 다시 다운로드 하는데 걸리는 시간을 없앨 수 있습니다.
       하나의 HTML 페이지 내에 있는 애플릿은 하나의 클래스만을 사용할 경우도 있겠지만, 대부분의 경우 여러 개의 클래스를 필요에 따라 사용하게 됩니다. 여러 개의 클래스를 사용할 경우, 모든 클래스가 동시에 사용되지는 않겠지요. 또한 어떤 클래스는 정의는 되어있지만, 필요에 따라 전혀 사용되지 않을 수도 있겠지요. 따라서, 자바에서는 필요할 경우에만 클래스를 로딩하여 사용하게 됩니다. 이러한 기술을 느린(lazy) 클래스 로딩 이라 합니다.
       이러한 문제점은 느린(Lazy) 클래스 로딩에서 발생하거나 메모리 할당과 가비지 콜렉션이 비결정적이고 느린 최악의 경우(worst-case) 특성을 가지며 stop-start 방식으로 모든 스레드를 멈출 수 있다는 문제점이 있습니다. 이를 해결하기 위해 클래스를 미리 로딩(class preloading)한다거나 정적 초기화(static initializer)를 제거하여 패키지 라이브러리에 대해서는 가상머신 초기화를 사용하고 응용프로그램에서는 명시적인 초기화 를 사용하게 하는 등의 기법을 사용할 수 있습니다. 그리고, 메모리 할당과 쓰레기 수집(garbage collection)에 대해서는 정해진 시간 내에 입터럽트 가능한 쓰레기 수집을 하는 것입니다. 또는 표준화된 실시간 API를 제공함으로써 해결할 수 있습니다.
       이렇게 두 개 이상의 자바 프로그램 규약을 만족시키는 자바 프로그램은 여러 자바 프로그램에 속하게 됩니다. 예를 들어, 하나의 자바 프로그램을 작성했는데, 이 자바 프로그램은 자바 애플리케이션을 위한 규약을 만족시켜 주고 자바 애플릿을 위한 규약도 만족시켜 준다면, 이 자바 프로그램은 JDK와 함께 제공되는 자바 가상머신에 의해 실행되는 자바 애플리케이션으로서 독립적으로 실행될 수도 있고, 자바 호환 웹 브라우저에 내장된 자바 가상머신에 의해 자바 애플릿으로 실행될 수도 있다는 것입니다. 이렇게 자바 언어를 이용하여 여러 규약에 맞는 자바 프로그램을 작성할 수 있지만, 하나의 자바 프로그램이 굳이 두 개 이상의 규약을 모두 만족시켜주도록 자바 프로그램을 작성하는 경우는 자바 애플리케이션과 자바 애플릿의 경우를 제외하고는 거의 없습니다.
• ReleaseDebugBuildStartGo의관계 . . . . 10 matches
        이 코드를 릴리즈 빌드로 만들고, Start(CTRL+F5)로 실행할 때의 b값과 Go(F5)로 실행할 때의 b값을 체크하면 서로 다르게 나옵니다. Start의 경우 b의 값이 false가 나오고, Go의 경우 b의 값이 true로 나옵니다. 바꾸어 말하면 Start는 미초기화 변수를 0으로 놓고, Go는 0이 아닌 값으로 세팅한다는 것입니다. (실제로 bool 타입의 false 값을 VC6의 디버거로 읽으면 0입니다. VC7의 경우엔 false라고 나오지만요)
        한데, 디버그 빌드의 경우는 어떨까요? 그 경우에는 Start나 Go나 차이를 보이지 않고 b값이 true입니다. 여기서 자그마한 결론을 얻을 수 있습니다.
        1. 디버그 빌드를 했거나 F5로 실행시키는 경우, 미초기화 변수는 0이 아닌 값으로 초기화된다.
        2. 릴리즈 빌드한 프로그램을 CTRL-F5로 실행시키는 경우, 미초기화 변수는 0으로 초기화된다.
        디버깅할 때는 잘 돌던 프로그램이 그냥 실행시킬 땐 오동작을 보이는 경우가 있어 막대한 육체적/정신적 에너지를 낭비하는 경우가 있는데, 그런 경우를 만난다면 이 글의 내용을 한 번쯤 떠올려 보시기 바랍니다. 그리고 다음의 점검을 해보시기 바랍니다.
• 데블스캠프2002/진행상황 . . . . 10 matches
       강사/진행자들의 후기 페이지입니다. 이 또한 ["ThreeFs"] 를 생각하기 바랍니다. 오늘의 글들이 다음날, 또는 내년에 쓰일것임을 생각하시길. 그날 자신이 했던 일들 (또는 다른 사람이 했던 일들)을 확인하고, 그에 대해서 무엇이 잘되었는지, 왜 잘되었는지, 무엇이 잘 안되었는지, 왜 안되었는지를 확인하고, 앞으로의 대안을 생각해보도록 작성합시다.
        * 세미나나 스터디를 준비할때 앞 세미나의 흐름이 연결되었을 경우 그 진행이 더 쉽다. 앞에서의 세미나 내용을 이용하여 설명하면 강사나 학습자나 서로 시간낭비를 줄일 수 있으니까. 추후 이러한 세미나 준비를 할때 그 체계성을 고려해야 할 것이다.
        * OOP를 바로 설명하기 전에 나의 프로그래밍 사고 방식을 깨닫고, StructuredProgramming 의 경우와 ObjectOrientedProgramming 의 경우에는 어떠한지, 그 사고방식의 이해에 촛점을 맞추었다.
        * StructuredProgramming - 창준이형이 역사적인 관점에서의 StructuredProgramming에 대해 설명을 하셨다. 그 다음 ["1002"]는 ["RandomWalk2"] 문제에 대해서 StructuredProgramming을 적용하여 풀어나가는 과정을 설명해 나갔다. (원래 예정의 경우 StructuredProgramming 으로 ["RandomWalk2"] 를 만들어가는 과정을 자세하게 보여주려고 했지만, 시간관계상 Prototype 정도에서 그쳤다)
       다른 하나는, 요구사항이 어떻게 제시되느냐가 산출물로서의 프로그램에 큰 영향을 끼친다는 점이다. 요구사항이 어떤 순서로 제시되느냐, 심지어는 어떤 시제로 제시되느냐가 프로그램에 큰 영향을 끼친다. 심리학에서 흥미로운 결과를 찾아냈다. "내일은 한국과 브라질의 경기날입니다. 결과가 어떻게 될까요?"라는 질문과, "어제는 한국과 브라질의 경기가 있었습니다. 결과가 어땠나요?"라는 질문에 대해 사람들의 대답은 큰 차이가 있었다. 후자 경우가 훨씬 더 풍부하고, 자세하며, 구체적인 정보를 끌어냈다. 이 사실은 요구사항에도 적용이 되어서, 요구사항의 내용을 "미래 완료형"이나 "과거형"으로 표현하는 방법(Wiki:FuturePerfectThinking )도 생겼다. "This system will provide a friendly user interface"보다, "This system will have provided a friendly user interface"가 낫다는 이야기다. 어찌되었건, 우리는 요구사항이 표현된 "글" 자체에 종속되고, 많은 영향을 받는다.
       꼭 생소하다의 문제를 떠나서, 전반적인 컴퓨터 동작원리 보다 구체적 용어들 (어떻게 보면, 이미 공부하여 알고 있는 사람들의 경우 일상어화 되어버린 언어들)이 먼저 나와버렸기 때문이다. 컴퓨터가 하드웨어와 소프트웨어로 구분되어지기 이전엔 어떠했는지, 그게 하드웨어와 소프트웨어로서 구분하는 방법으로서 폰 노이만 아키텍쳐가 나온 이야기라던지, 그러하기 때문에 PC 카운터가 필요하며 메모리로부터 명령어를 읽어온 뒤, CPU에서 명령을 해석하고 처리한다라던지 등등. 그러한 이야기가 나오기전에 어드레스/세그먼트/옵셋/디코딩 이 나와버렸기 때문에 어려운 세미나가 되어버렸다고 생각한다. 후에 상민이가 다시 동작원리부터 상대적으로 쉬운 용어로 설명을 해주면서 사람들의 반응을 유도한점에 대해서는 사람들이 한번 생각을 해볼 필요가 있다. 우리와 대화하는 사람은 어느정도의 지식수준을 가지고 있는가에 대해서. 정말 이해 안가는 부분에 대해서는 질문 자체를 만들어내기 힘들다. --석천
        * 불필요한 스레드란 없으니 걱정말고. ^^; 개인적으로 C 와 어셈과의 포인터관계를 어디서 찾았냐면, 해당 주소값이란 것이 무엇인가에서 찾았다. (단, 내가 정직이나 남훈이보단 하드웨어 관련지식이 깊지 않다) '포인터 값을 화면에 찍었을 경우에 나오는 엄청나게 큰 숫자(윈도우의 경우 32비트) 의 의미는 무엇인가?' 라는 질문을 하게 되었고. 그 이후 메모리가 16메가바이트라는 건 메모리에 0번부터 16메가바이트-1 이라는 번호를 부여하고, 해당 번호에 값을 대입하는 것이라는 접근을 하게 되었지. (물론, 이것도 물리적 주소는 아니겠지. 결국 우리가 이용하는 주소란 OS 에 의해 한번 걸러진 논리적 주소겠지.) 추상화의 정도를 이야기하라는 건 꼭 해당 언어 기준으로 이야기하라는 게 아니라, 경험에 대한 연결고리(여기서는 'C에서 포인터 변수를 화면에 찍어보니 이상하게 큰 숫자가 나왔다' 정도)를 찾아보자라고 한다면 정말 이야기가 '추상적'이려나; --석천
• 지금그때2004/여섯색깔모자20040331 . . . . 10 matches
        - 검정 : 시의성으로 볼때 중요한가. 사회자의 경우 그렇지 않아고 본다
       검정 : 신청서 용지를 돌리면 홍보횟수가 적어도 되지 않을까?
        - 검정 & 하양 : 나의 경우 친구따라 왔다. 실제보다 더 늘어나는 경우도 있지 않은가?
        - 검정 & 하양 : 나의 경우 신청하고 가지 않은 경우에 해당된다.
       검정 : 세미나와 행사진행의 경우는 차이가 있다.
       검정 & 하양 : 작년이나 기타 여러 행사의 경우 시간관리자는 따로 있었다. 이번의 경우도 시간관리자가 따로 있으면 된다.
       검정 : 리허설을 하기에는 뭔가 시간이 부족하지 않을까?
• CubicSpline/1002/GraphPanel.py . . . . 9 matches
        self.errorLagrange = ErrorLagrange(DATASET)
        self.errorPiecewiseLagrange = ErrorPiecewiseLagrange(DATASET, 4)
        self.errorCubicSpline = ErrorSpline(DATASET)
        self.plotErrorLagrange(dc)
        self.plotErrorPiecewiseLagrange(dc)
        self.plotErrorCubicSpline(dc)
        def plotErrorLagrange(self, dc):
        self.plotGraph(dc, self.errorLagrange, wxColour(128,128,128))
        def plotErrorPiecewiseLagrange(self, dc):
        self.plotGraph(dc, self.errorPiecewiseLagrange, wxColour(255,255,200))
        def plotErrorCubicSpline(self, dc):
        self.plotGraph(dc, self.errorCubicSpline, wxColour(255,0,255))
• RandomWalk2 . . . . 9 matches
        * 뼈대예시 ["RandomWalk2/ClassPrototype"] (OOP를 처음 다루는 경우가 아니라면 보지 않기를 권한다)
       다음은 이상의 요구조건을 만족하는 프로그램 개발이 완료되었을 경우만 본다.
       교육에 있어 이런 작업이 중요한 이유 중 하나는, 자신이 만든 프로그램이 해답을 제대로 내느냐는 것을 확인하는 데에는 한 문제를 한번 푸는 것으로 족하지만, 거기서 코드의 디자인 질을 확인할 수가 없다는 문제가 있기 때문이다. 하지만, 요구사항 변경에 따라 자신이 개발한 프로그램을 다시 수정하게 되면, 이전에 만든 코드의 질에 따라 그 노력에 현격한 차이가 난다. 디자인 질이 높으면 아주 짧은 시간 안에 간단하게 요구사항 변화에 대응할 수 있을 것이고, 질이 낮았다면 장기간에 걸쳐 여기저기를 들쑤시고 골치를 썩혀야 할 것이다.
       다음은 코드 디자인이 좋지 못했을 경우 고생을 할 요구사항 변경들이다. 그냥 대충 생각나는 대로 아무것이나 나열한 게 아니고, 순서나 변경사항이나 모두 철저하게 교육적 효과를 염두에 두고 "디자인"되었다.
       이 경우 총 네마리의 바퀴가 판 위를 돌아다니게 된다.
       출력정보는 바퀴별 움직인 횟수(슈퍼바퀴의 경우 한번에 두칸을 움직이기에 움직인 횟수 역시 두번으로 친다)와 판의 상태다. 앞서의 경우와 동일하다.
       최초의 요구사항 제시 이후에 나온 변경사항들이 따라오지 않을 것이라 가정하고, 만약 이 RandomWalk2 문제를 다시 접했다면 어떻게 접근하겠는가. 어떤 과정을 거쳐서 어떤 프로그램을 개발하겠는가?
• UnixSocketProgrammingAndWindowsImplementation . . . . 9 matches
        // 에러가 났을경우( sockfd == -1) 에러를 출력하고 프로그램 종료.
        ina.sin_port = htons(PORT); // PORT의 경우 정수를 넣어야한다.
        ina.sin_addr.s_addr = inet_addr(SERVER_IP); // 클라이언트의 경우
        // SERVER_IP의 경우 문자열 포인터를 넣어야한다.
        // ina.sin_addr.s_addr = INADDR_ANY; // 서버의 경우
        fprintf(stderr, "send error");
        fprintf(stderr, "write error");
       ◎ UNIX 체계에서 사용하던 함수들의 헤더파일이 Windows 기반에서는 존재하지 않을 수도 있다.
        fprintf(stderr, "WSAStartup Error"), exit(1);
        fprintf(stderr, "WSAStartup Error"), exit(1);
       void error(char *buf)
        error("WSAStartup Error");
        error("server socket error");
        error("bind() 에러");
        error("listen() 에러");
• 가위바위보/영동 . . . . 9 matches
        result=0; //sunho가 이긴 경우는 0을 대입
        result=2; //insu가 이긴 경우는 2을 대입
        result=0; //sunho가 이긴 경우는 0을 대입
        result=0; //sunho가 이긴 경우는 0을 대입
        result=2; //insu가 이긴 경우는 2을 대입
        result=2; //insu가 이긴 경우는 2을 대입
        result=1; //비긴 경우에는 1 대입
        result=1; //비긴 경우에는 1 대입
        result=1; //비긴 경우에는 1 대입
• 김희성/MTFREADER . . . . 9 matches
       #define FILE_LOAD_ERROR 1
       #define OUT_OF_MEMORY_ERROR 2
        int ErrorCode;
        ErrorCode=0;
        if(!GetLastError())
        ErrorCode=FILE_LOAD_ERROR;
        int LastErrorCode(); //최근에 일어난 클래스 내부의 에러를 반환한다.
        ErrorCode=OUT_OF_MEMORY_ERROR;
        ErrorCode=OUT_OF_MEMORY_ERROR;
        printf("error");
       int _MFT_READER::LastErrorCode()
        return ErrorCode;
• 논문번역/2012년스터디/이민석 . . . . 9 matches
       필기 줄을 전처리한 이미지는 특징 추출 단계의 입력 자료로 사용된다. sliding window 기법을 [11]이 설명하는 접근법과 비슷하게 적용한다. 우리의 경우 이미지의 높이와 열 네 개 크기의 창이 이미지의 왼쪽에서 오른쪽으로 두 열씩 겹치면서 움직이고 기하 추출의 쌍을 추출한다.
       위 식에서 P(W)는 글자 시퀀스 w의 언어 모형 확률이고 P(X|W)는 이 글자 시퀀스를 그 글자 모형에 따라 입력 데이터 x로서 관찰한 확률이다. 우리의 경우 absolute discounting과 backing-off for smoothing of probability distribution을 이용한 바이그램 언어 모형을 적용하였다. (cf. e.g. [3])
       단일 저자식 실험은 Senior 데이터베이스에서 훈련에 282줄, 검정에 141줄을 써서 수행했는데, 글자 수준에서 검정 집합의 바이그램 perplexity는 15.3이다. 베이스라인 시스템의 오류율 13.3%는 바이그램 언어 모형을 채택하여 12.1%로 감소했다. LDA 변환한 특징 공간의 차원이 12로 내려갔지만 오류율은 그다지 커지지 않았다. 단일 저자 시스템의 단어 오류율(표 2)은 어휘 없이 28.5%, 1.5k 어휘가 있으면 10.5%다. 이 결과들은 우리가 같은 데이터베이스를 이용하여 literature(문학 작품은 아닌 것 같다)에서 얻은 오류율과 비교되긴 하지만, 훈련 집합과 검정 집합의 크기가 달라 비교하긴 어렵다. [17]에서 오류율은 글자의 경우 28.3%, 어휘 없는 단어의 경우 84.1%, 1.3k 어휘가 있는 단어의 경우 16.5%다. [15]의 보고에서 단어 오류율은 어휘가 있는 경우 6.6%, 어휘 free인 경우 41.1%다. [9]에서 최고의 어휘 기반 단어 오류율은 15.0%다.
       다저자 필기 인식 작업의 경우 IAM 데이터베이스의 하위집합 c03에서 훈련에 440줄, 검정에 109줄을 사용하였다. 이 줄들은 글씨체가 확연히 다른 저자 여섯이서 작성하였다. 이 작업에서 LDA(12차원으로 경감)를 쓴 글자 오류율 14.2%는 이서체 모형(각 소문자에 이서체 6개)을 추가로 사용하여 13.3%로 더 크게 감소했다. 바이그램 언어 모형을 채택한 결과 오류율은 11.1%로 더욱 감소했다(검정 집합 perplexity는 12.0). 어휘 없는 단어 오류율은 39.0%로, 단어 421개(구두점 포함)를 포함한 어휘를 적용하여 오류율은 13.9%로 줄어들었는데 [11]에 나온 20.5%와 많이 비교된다.
       이 결과들에 고무하여 우리는 더 어려운 작업인 저자 독립 인식 실험을 수행했다. IAM 데이터베이스의 하위 집합 [a- f](저자 약 250명)을 입력 자료로 썼는데, 훈련에 4321줄(양식 [a-d]), 검정에 1097줄(양식 [e-f])을 사용했다. 베이스라인 시스템의 글자 오류율은 31.3%다. 저자 독립의 경우 이서체 모형은 다저자 실험에 비해 별다른 향상을 이루지 못했다. 오류율 31.3%는 글자당 이서체 3개를 써서 얻은 것이며 글자당 이서체 10개를 써서 실험했을 때 오류율(34.8%)과 인식 속도 모두 하락하였다. 하지만 오류율은 LDA 변환한 특징을 썼을 때 29.1%로 크게 감소했다. 언어 모형을 추가로 통합하여 글자 오류율은 22.2%로 더욱 개선되었다(검정 집합의 perplexity는 12.0). 이는 어휘를 쓰지 않았을 때 단어 오류율 60.6%와 대응된다.
• 새싹교실/2011/Noname . . . . 9 matches
        * else if의 경우에는 if-else와 다음 if-else를 합쳐놓은것!!
        * switch의 경우 statement 에 break의 사용을 까먹지 맙시다.
        expr2조건 확인 -> 조건에 충족될때 statement실행 -> expr3 ->
        expr2조건 확인 -> 조건에 충족될때 statement실행 -> expr3 ->
        expr2조건 확인 -> 조건에 충족되지 않을겨우 for문을 빠져나옴.
        * expression이 충족될 경우 statement를 실행한다.
        * while문과 비슷하지만 do_while문은 statement를 무조건 한번은 출력한다.(그 뒤에 조건확인.)
        * 2차원 배열의 경우 행과 열로 나누어 생각하면 편하지만 사실은 1차원의 연속된 저장공간에 저장되는 배열이다.
• 이영호/64bit컴퓨터와그에따른공부방향 . . . . 9 matches
        * 32비트에서 64비트 컴퓨터로 바뀔 경우, 어플리케이션 개발자들의 경우 기존 개발 방식에서 많은 차이가 생길까요? 32비트에서 64비트 컴퓨터로의 전환이 개발자들의 페러다임의 전환을 의미할까요?
        └저도 C (배우게 된다면 Assembly도.ㅎ)를 좋아 합니다.ㅎ 무엇보다 빠른 연산속도와 하드웨어 제어(해본적은 없지만), 포인터를 통한 메모리 접근등 좋은 점이 많아요.^^* 그렇지만 예를 들어 1만 팩토리얼을 출력하는 프로그램을 작성하시오. 라고 문제가 주어졌을때, C로 짜면 한나절이지만 파이썬으로 작성하게 되면 5분도 안걸리게 됩니다. 물런 연산속도가 느리기는 하지만 말입니다.^^ 이런 점에서 봤을때, 속도가 중요하다거나 특화된 프로그램을 작성해야할 경우에는 C와 같은 언어가 좋지만 보편적으로 사용하는 워드프로세서라든지 기타 응용프로그램이나, 제작해야할 프로그램의 제작시간이 짧을 경우에는 상위레벨의 언어가 좋을거라고 봅니다.^^ 뭐 이렇게 말은해도.. 사실 서로의 장점을 그때그때 맞춰서 섞어쓰는게 가장 좋지 않을까요?ㅎ (게임을 만들때 하위레벨의 언어로 하드웨어를 직접 사용한다 하더라도, 다이렉트를 이용하지 각각의 그래픽 카드에 맞춰서 프로그램을 만들지 않는것과 비슷한것 같아요.^^) 이상 지나가는 행인1의 잡다한 생각이었습니다.^^* - [조현태]
       음. 아쉽게도 그런 용도로 Assembly를 평가 한게 아닙니다. 우수하고 못하다의 평가는 여기서도 나오는군요. 한가지만 파면 성공한다와 같은 맥락이랄까요... 저는 미래의 직장보다도 현재의 지식욕을 채우고 싶을 뿐입니다. 누구보다도 이것에 대해 많이 알고 싶고 또한 그렇게 되길 바랄뿐입니다. 과연 Java나 Python등을 공부하다보면 컴퓨터에 대한 가장 기초적인 지식들을 얻기 쉬울까요? 그렇기 때문에 Assembly에 대한 직접적인 접근을 하려고 하는 것입니다. 지식욕이 아니더래도 현직에 계시는 프로그래머분들께 컴퓨터에 대한 기초가 부족하고 프로그램만 짤 줄 아는 신참 직원들은 항상 한계에 다다르면 좌절한다라는 말을 들은적이 있습니다. 한번쯤은 생각해 볼 문제입니다. Assembly > C++을 평가한 것은 이런 맥락입니다. 컴퓨터에 대한 기초가 있느냐 없느냐. Assembly를 만지고 C++을 만진 사람의 경우는 모르겠지만 C++만 만지고 Assembly를 공부하지 않은 사람의 한계는 언젠가는 드러나게 되죠.
       그냥 시스템 프로그래머와 어플리케이션 프로그래머의 차이정도로만 생각하겠습니다. 언어 관련 논쟁과 다른 레이어간 논쟁에 대해서는 정말정말 재미없습니다. ^^ 의도하는 바도 아니고요. 단지, '시스템 프로그래머' 컨텍스트가 붙지 않았을 경우에는 다른 사람들에게는 좀 갸우뚱할 상황이여서 쓴 것일 뿐입니다. (그렇다고 시스템에 대한 이해의 중요성을 무시하려는것은 당연히 절대로 아니고요.)
       "종국에 C++과 같은 현재 패러다임을 따르는 사람들은 결코 나를 넘지 못하리니..."라는 말이 참이 되는 시점이 있다면 "나 역시 그들을 넘지 못하리니."도 참이 되진 않을까 반문해 보세요. 그리고 만에 하나 그렇게 된다면 거기에 만족할 수 있을까 생각해 보세요. 너무 이른 걱정이려나요? (전문성은 분야를 넘어서까지 적용되지는 않는다는 것이 최근 인지과학이 밝혀낸 사실입니다. 반드시 체스 전문가가 바둑을 특별히 잘두거나, 바둑 전문가가 체스를 뛰어나게 잘두거나 하지는 않습니다. 체스 고수가 특별히 IQ가 높고 암기력이 뛰어나거나 하지도 않고요. 한가지를 잘해서 두루 잘하기는 무척 어렵습니다)
        '' '특정언어를 공부한다'에는 두가지 의미가 같이 포함되어서 그런 것 같습니다. 즉, 언어 자체를 공부하는 것과 해당 언어가 쓰이는 분야(시스템, 웹, 컨커런트 등)를 공부하는 것. 아마 영호군의 경우 강조하려는 것은 시스템 레벨에의 지식에 대한 공부일 것이므로, '알고리즘/자료구조 대신 특정 프로그램언어를 공부한다'는 기우가 아닐까 생각. (물론, 하려는 이야기는 이해했음..~)--[1002]''
• AcceleratedC++/Chapter9 . . . . 8 matches
        '''다음은 각기 동일한 표현식을 나타낸 2가지의 경우이다.'''
        헤더파일은 단지 컴파일러가 컴파일을 할때 이런 함수가 존재한다고 가정만 하고, 실제로 그 함수의 코드가 존재하는 것을 확인 할 수 잇는 것은 모든 관련 오브젝트 파일을 링크한뒤에 호출할때 없다는 것을 확인할 수 밖엔 없다.'''
        * 내장 타입 객체인 경우 값지정 초기화시에는 0으로 디폴트 초기화 시에는 정의되지 않은 값으로 세팅된다.
        * 생성자를 갖지 않는 타입인 경우. 객체를 어떤 식으로 초기화했는 가에 따라서 값지정, 디폴트 초기화를 재귀적으로 행함.
        현재 Student_info 형은 3번째의 경우에 해당하며, 현재 제공되는 멤버함수로는 문제가 생길 일이 없지만, 후에 이 클래스에 기능을 추가할 경우 문제가 발생할 가능성이 존재하므로 생성자를 만들어 주는 것이 좋다.
       Student_info::Student_info():midterm(0). final(0) {} // n, homework 의 경우 STL에서 제공되는 디폴트 생성자가 재귀적으로 호출
       using std::domain_error; using std::endl;
        } catch (domain_error e) {
• PragmaticVersionControlWithCVS/WhatIsVersionControl . . . . 8 matches
       개발 중인 프로젝트의 모든 버전이 저장되는 장소이다. 파일 시스템, DB일수도 있으며, 어떤 경우에는 2가지를 같이 사용하기도 한다.
       || 자동으로 생성되는 잔여파일의 경우 굳이이를 관리할 필요는 없다. 대신에 특수한 이유(컴파일 타임. 라이센스)로 필요한 경우에는 관리를 하는 경우도 있다 ||
       CVS가 각기의 파일에 할당하는 버전의 번호는 그 파일의 버전일뿐 전체 프로젝트의 버전일 수는 없다. ''(잡담:물론 따로 기능이 있지 않을까? -_-;)''
       이 경우 PreRelease2를 불러들이게 되면 상기의 버전의 파일들이 불러들여지게 된다. 태그는 프로젝트의 진행에 있어서 중요한 일이 발생한 시점을 기록하는 것으로 사용되는 것도 가능하다.
       이 경우 브랜치에서 수정된 사항이 mainline상에도 반영되어야할 필요가 있을때 이를 병합의 과정을 통해서 하는 것이 가능하다.
       상기와 같은 식으로 소스를 수정한뒤 fix01, fix02를 순차적으로 체크인하면 fix01에 의해서 저장소에 있는 파일이 갱신되었기 때문에 fix02가 체크인 되는 시점에서 충돌이 일어나게 된다. 이경우 CVS는 fix02의 소스에서 fix01에 반영된 3번째 줄의 변경내용을 병합하여 로컬 작업 공간에 반영하고 체크인하게된다.
• Ruby/2011년스터디/세미나 . . . . 8 matches
        * "우아한" 언어인 루비를 다운받아 irb를 사용해 실습을 해보았다. 처음에 irb를 눌렀을 때, 무슨 dll파일이 없어서 실행이 안된다는 팝업창이 떴는데 확인 누르니까 알아서 잘 켜졌다. Ctrl+C를 눌렀더니 끌지 말지 여부가 떴는데 N을 눌러도 꺼졌다. irb보다는 넷빈즈를 이용하는게 좋다는 말이 와닿았다. 1+2를 치면 알아서 3이 나오는 것과 리턴 값이 항상 표시되는 것이 신기했다(없을 경우도 =>nil 로!). 루비의 블록 넘기기는 #define이랑 비슷한 느낌이 들었다. 새로운 언어임에도 쉽게 익힐 수 있어 좋았다. 하지만, 페어로 하는 만큼 실습 시간도 반감되지 않았을까 죄송스러웠다. 세미나 공지가 뜨면 노트북을 가져가도록 해야겠다. - [강소현]
        * 아.. 세미나가 끝나니까 할말이 생각나네요..ㅠㅠ 루비의 블록 넘기기는 사실 블록이 yield구문에게 전달되는 것이 아니라 yield를 만나면 함수의 호출부로 컨트롤이 이동해 블록이 있는지 확인하고 실행합니다. 책에서는 co-routine 이라고 이해하면 된다는 설명이 있어요~ 블록이 전달되는게 아니라 컨트롤 플로우가 왔다갔다!! 스위치 태스킹처럼요. 세미나때 설명을 잘 해드렸어야 했는데 죄송천만번입니다 - [서지혜]
        * ''의도가 명확하다는 것''이 무엇인지 설명하는 것보다 의도가 명확하지 않은 상황을 제시하는 게 이해하기 좋을 것 같으니 하나 예를 들어볼게. RubyLanguage에서 괄호를 쓰지 않아도 되는 것은 if 구문에 대해서만 그런 것은 아니야. 함수의 경우도 마찬가지지. 만약 내가 매개변수 a와 b를 받아 그 둘을 더해 반환해주는 함수 add(a, b)를 만들었다 치자. 이 메서드를 다음과 같이 이용할 수 있겠지.
       }}} 윗줄 아랫줄 모두 문제 없이 실행되지. 이 경우는 의도가 명확한 경우야. 그런데 이 add 메서드를 호출해서 3, 4, 7을 더한 값을 알고 싶다면
       }}} 그런데 위 코드는 대체 어떤 것이 처음 나온 add 메서드에게 넘겨주는 매개변수인지 명확하지 않지? 이런 경우는 의도가 불명확한 경우라 반드시 괄호를 사용해서 코드를 작성해야해. - [김수경]
• SmallTalk/강좌FromHitel/강의3 . . . . 8 matches
       터넷에 연결되어있는지 확인하고 이어서 이 단추를 누르면 Object Arts사의
       * First Name: 여러분의 이름을 넣습니다. 저의 경우는 ChanHong Kim으로 표
       * Last Name: 여러분의 성씨를 넣습니다. 저의 경우에는 Kim이겠지요?
       * Stree Address: 우리의 경우에는 시/군, 구/읍면, 동, 번지로 주소를 쓰지
        만 외국의 경우는 거꾸로 입니다. Street Address에는 여러분의 동 이름
        과 번지수를 씁니다. 저의 경우라면 2288-3, DaeMyung 3 Dong, Nam-Gu
       * State: 미국의 경우는 주를 입력합니다만, 우리는 비워둡니다.
       두어야 하는 이유입니다. 그래야만 만일의 경우에 발생하는 문제를 예방할
• TermProject/재니 . . . . 8 matches
        grade(int), prt_select(), prt_all(), error();
        else error(); // 잘못 입력하였을 경우 에러메시지를 출력하는 함수 호출
        system("pause"); // 실행 결과를 확인하기 위해 실행을 잠시 멈춤
       void sub_menu() // 1, 2번 메뉴의 경우 서브 메뉴를 입력받아 선택된 메뉴를 출력하는 함수
        error(); // 잘못 입력하였을 경우 에러메시지를 출력하는 함수 호출
       void prt_select() // 1, 2번 메뉴의 경우 서브 메뉴에 따라 화면에 결과를 출력함
        if (select == 4) // 선택된 메뉴가 4번일 경우
       void prt_all() // 3, 4번 메뉴를 선택했을 경우 공동으로 사용하는 출력 함수
       void error() // 메뉴를 잘못 입력하였을 경우 에러 메시지를 출력하는 함수
• 포커솔리테어평가 . . . . 8 matches
       1. 노 페어 : 아래 계급에 아무것도 해당되지 않을 경우 (예: AC, 3H, QS, JD, 7D)
       3. 투 페어 : 아래 계급 중 어떠한 것도 해당되지 않으며, 다른 숫자의원 페어 2개로 이루어진 경우(예 : @C, 3H, 4H, 2H, 4D)
       4. 트리플 : 아래 계급 중 어떠한 것도 해당되지 않으며, 동일한 숫자의 카드가 3장인 경우(예 : QS, KH, 2C, QD, QC)
       5. 스트레이트 : 아래 계급 중 어떠한 것도 해당되지 않으며, 5장의 카드의 숫자가 순차적으로 구성되는 경우. A(에이스)는 14나 1로 사용될 수 있다. 예를 들어, AC, 2H, 4D, 3H, 5S도 스트레이트 이며, JH, XD, QC, KD, AS도 스트레이트 이다.
       6. 플러시 : 아래 계급 중 어떠한 것도 해당되지 않으며, 5장의 카드가 모두 동일한 경우 (예:5D, AD, KD, 7D, QD)
       7. 풀하우스 : 아래 계급 중 어떠한 것도 해당되지 않으며, 원 페어와 다른 카드들로 트리플을 이루는 경우(예 : 3C, QS, QP, 3H, 3S)
       9. 스트레이트 플러시 : 5장으로 스트레이트와 플러시 모두 포하되는 경우
• 프로그래머가지녀야할생각 . . . . 8 matches
       모든 ZP인들에게 미안하게 생각합니다. 갑자기 뚱딴지 같은 생각이 났습니다. 과연 ["programmer"]들이 항상 마음에 지니고 있어야 할 ["생각"]은 무엇일까요? 어떤 생각들을 항상 지니고 있어야 잘못된 행동(사고 포함)을 하지 않을 수 (혹은 하고 있다는 것을 깨달을 수 )있을까요? ["programmer"]들이 꼭 지니고 있어야 할 생각들이 무엇일까? 궁금합니다.
       학부시절 혼자하는 프로그래밍의 경우, 사소한 기능 하나를 추가하려다가 제풀에 지쳐서,
       전체 프로그램을 포기하는 경우가 생기곤 하죠..
       ''목적'' 이 무엇인가를 늘 기억했으면 합니다. 무엇을 목적으로 하는지 잊어버릴 경우
       부지런해야 하지는 않을까..(이건 생각에 안들어갈까요..ㅡ.ㅡ?)
        * 다들 인간으로써의 프로그래머를 두고 말씀하시는 것 같아 제 말이 뚱딴지처럼 들릴 것 같네요...^^;[[BR]]전 말이죠... 프로그래머는 컴퓨터를 사랑해야한다고 생각합니다. 정말 제가 생각해서 어이없는 말 같지만, 프로그래머는 컴퓨터에게 명령만 내리는 것이 아니라 컴퓨터와의 커뮤니티가 형성되어야 좋은 프로그램(인간에게가 아니라 컴에게)을 짤 수 있다고 생각합니다. 지극히 추상적이라서 반박의 여지가 많은 말이지만 그냥 그렇지 않을까 생각해봅니다. 컴퓨터에 미친 사람이라면 다음의 말에 공감을 할 지도 모르겠네요. [해커를 위한 파워핸드북]표지에 나오는 말입니다. ''''컴퓨터 속에서 흘러 다니던 비트가 내 혈관 속으로 옮겨와 흐르기 시작하고, 나는 컴퓨터와 함께 오르가즘을 느낀다.'''' --["창섭"]
        * 위엣 말이 컴퓨터 자체에 관한 기계적 이야기라면 인간적 이야기도 추가하고 싶어요. 프로그래머는 프로그램 이전에 인간을 먼저 생각해야 한다는 것이죠... 상민이 형이 줬던 V노트에 나온 말이 인상깊습니다. ''''크래커든 프로그래머든 둘다 시작은 해커를 꿈꾼 젊은이 였으며, 인격을 가진 사람이다. 악이 없이 선이 없듯이 크래커가 영원히 존재하지 않을수는 없을지라도 지금 당신의 열정과 땀으로 주어질 선택이 진정한 존경으로 돌아올수 있도록 유혹을 이겨낸 진짜 승자가 되어야 하지 않을까......'''' --["창섭"]
• 프로그램내에서의주석 . . . . 8 matches
       자바 IDE들이 Source Folding 이 지원하거나 comment 와 관련한 기능을 지원한다면 해결될듯. JavaDoc 은 API군이나 Framework Library의 경우 MSDN의 역할을 해주니까. --석천
       자네의 경우는 주석이 자네의 생각과정이고, 그 다음은 코드를 읽는 사람의 관점인 건데, 프로그램을 이해하기 위해서 그 사람은 어떤 과정을 거칠까? 경험이 있는 사람이야 무엇을 해야 할 지 아니까 abstract 한 클래스 이름이나 메소드들 이름만 봐도 잘 이해를 하지만, 나는 다른 사람들이 실제 코드 구현부분도 읽기를 바랬거든. (소켓에서 Read 부분 관련 블럭킹 방지를 위한 스레드의 이용방법을 모르고, Swing tree 이용법 모르는 사람에겐 더더욱. 해당 부분에 대해선 Pair 중 설명을 하긴 했으니)
        하지만, "확실히 설명할때 {{{~cpp JavaDoc}}}뽑아서 그거가지고 설명하는게 편하긴 편하더라."라고 한말 풀어쓰는 건데, 만약 디자인 이해 후에 코드의 이해라면 {{{~cpp JavaDoc}}} 없고 소스만으로 이해는 너무 어렵다.(최소한 나에게는 그랬다.) 일단 코드 분석시 {{{~cpp JavaDoc}}}이 나올 정도라면, "긴장 완화"의 효과로 먹고 들어 간다. 그리고 우리가 코드를 읽는 시점은 jdk를 쓸때 {{{~cpp JavaDoc}}}을 보지 소스를 보지는 않는 것처럼, 해당 메소드가 library처럼 느껴지지 않을까? 그것이 메소드의 이름이나 필드의 이름만으로 완벽한 표현은 불가능하다고 생각한다. 완벽히 표현했다면 너무나 심한 세분화가 아닐까? 전에 정말 난해한 소스를 분석한 적이 있다. 그때도 가끔 보이는 실낱같은 주석들이 너무나 도움이 된것이 기억난다. 우리가 제출한 Report를 대학원 생들이 분석할때 역시 마찬가지 일것이다. 이건 궁극의 Refactoring문제가 아니다. 프로그래밍 언어가 그 셰익스피어 언어와 같았으면 하기도 하는 생각을 해본다. 생각의 언어를 프로그래밍 언어 대입할수만 있다면야.. --["상민"]
       내가 Comment 와 JavaDoc 둘을 비슷한 대상으로 두고 쓴게 잘못인듯 하다. 두개는 좀 구분할 필요가 있을 것 같다는 생각이 들어서다. 내부 코드 알고리즘 진행을 설명하기 위해서는 다는 주석을 comment로, 해당 구성 클래스들의 interface를 서술하는것을 JavaDoc으로 구분하려나. 이 경우라면 JavaDoc 과 Class Diagram 이 거의 비슷한 역할을 하겠지. (Class Diagram 이 그냥 Conceptual Model 정도라면 또 이야기가 달라지겠지만)
       그리고 계속 이야기 하다보니 주석(comment)과 {{{~cpp JavaDoc}}}을 나누어 설명하는 것이 올바른 생각인듯 하다. 그런 관점이라면 이번 코딩의 컨셉이 녹색글자 최소주의로 나갔다고 볼수 있다. 머리속으로는 특별히 둘을 나누지 않고 있었는데, 코딩 습관에서는 완전히 나누고 있었던거 같다. 녹색 글자를 쓰지 않을려고 발악(?)을 했으니.. 그래도 보이는 녹색 글자들 보면 죄의식이 이것이 object world에서 말하는 "프로그래머의 죄의식"에 해당하는 것이 아닐까. --["상민"]
       주석이 실행될 수 있는 코드가 아니기 때문에, 반드시 코드가 주석대로 수행된다고 볼 수는 없지만 없는것 보다는 낳은 경우도 많다. 코드 자체는 언어의 subset 이기 때문에 아무리 ''코드가 이야기한다(code tells)''라 할지라도 우리가 쓰는 언어의 이해도에 미치기가 어렵다. 이는 마치, 어떤 일을 함에 있어서 메뉴얼이 존재함에도 불구하고 경험자에게 이야기를 듣고 메뉴얼을 볼 경우, 그 이해가 쉽고 빠르게 되는것과 비슷하다.
       우리는 충분히 이성적이기에 주석 자체만을 보고 모든것을 믿으려고 할 만큼 어리석지는 않다. 주석을 먼저 거쳐간 사람의 숨길로 느끼고, 재미로 느낄 수 있게 되면 코드 리뷰가 항상 지루하지는 않을 것이다.
• NamedPipe . . . . 7 matches
        // the function returns a nonzero value. If the function returns // 접속이 될 경우 0 아닌 값이 리턴 되며
        // zero, GetLastError returns ERROR_PIPE_CONNECTED. // 만약 0 값이 리턴이 될 경우 ERROR_PIPE_CONNECTED를 리턴한다.
        TRUE : (GetLastError() == ERROR_PIPE_CONNECTED);
        // Exit if an error other than ERROR_PIPE_BUSY occurs.
        if (GetLastError() != ERROR_PIPE_BUSY)
       // Default는 PIPE_READMODE_DATA 이고 PIPE_READMODE_MESSAGE가 실패할 경우 default로 정해진다.
        if (! fSuccess && GetLastError() != ERROR_MORE_DATA)
        } while (! fSuccess); // repeat loop if ERROR_MORE_DATA
• ZeroPageServer/set2002_815 . . . . 7 matches
        * Resin 상태 확인
        * [[HTML( <STRIKE> php 설치, 확인 </STRIKE> )]]
        * [[HTML( <STRIKE> python 설치, 확인 </STRIKE> )]] 2.1, 2.2 둘다 설치
        * [[HTML( <STRIKE> vim 설치, 확인 </STRIKE> )]] 6.1.18
        * [[HTML( <STRIKE> CVS 설치, 확인 </STRIKE> )]] 1.11.1p1
        * [[HTML( <STRIKE> gcc 확인 </STRIKE> )]] : 2.95, 3.0 중복 설치 ( linux권장 사항 )
        * [[HTML( <STRIKE> CVS 관련 더미 유저 세팅과, 원격지 확인 </STRIKE> )]]
• 대학원준비 . . . . 7 matches
       제출서류 도착확인 2006. 7. 28(금), 10:00 - 8. 4(금), 17:00 KAIST 입학본부 홈페이지
       '''특별 TEPS시험 2006. 8. 6(일), 13:30까지 입실완료 접수 시 시험 장소 확인요망 -> 여기서 http://www.teps.or.kr/kaist/kwa_check.html'''
        * 서류 심사 내용이 간당 간당 한 사람의 경우 면접이 까다로움
        전형료 : 100,000원(우편접수의 경우에는 우편소액환으로 바꾸어 동봉)
        * 가끔 특차로 성적만으로 뽑는 경우 있음. 이렇게 특차로 뽑힌 사람의 경우 원하는 연구실로 가기 싶고, 추후 정시의 경우는 불리 할 수 있다고 함
• 위키설명회2005/PPT준비 . . . . 7 matches
       특히 방학때 ==> 스터디를 통해서 본격적으로 공부함... 여름방학 같은 경우 데블스 캠프, 2학기 프로그램 전시회 준비
        정모에 2회 연속으로 활발히 참여한 사람을 회의를 통해서 회원으로 인정한 경우
       많은 사람이 참여하지 않아서 위키가 널리 퍼지지 못하고 있지는 않을까 생각해 봅니다.
        * 그런데 디자인이 구립니다. 그점이 처음 온 사용자들에게 뒤로 버튼은 눌르게 만드는 결정적인 요인일수도 있습니다. 글씨만 빼곡히 ... 어려워보입니다. 더이상 쉬워지기 힘든데도 말이죠. 많은사람이 참여하지 않아서 그래서 위키의 사상,철학,이념,방식, 시스템이 널리 퍼지지 못하고 있지는 않을까 생각해봅니다
        * 위키위키가 어떠한 경우에나 적합하다고 하기는 힘들 것이다. 예를 들어, 정치적으로 대립이 심한 사이트에서 위키위키가 제대로 운영될 수 있을지는 의문이다.
       백문이 불어일견. 실제로 페이지를 보면서 페이지 구조를 설명하는 시간도 있었으면 좋겠다. 거의 모든 위키의 기능을 담은 페이지가 하나 있으면 좋지 않을까??
       해당 페이지나 그 페이지의 일부분이 특정 페이지와 관련이 있을 경우, 관련있는 부분 마지막에 SeeAlso를 추가한다.
• 전시회 . . . . 7 matches
        * 출석 프로그램의 경우 이름순 정렬이 되지 않는다.
        * 세균전의 경우 더 이상 둘 곳이 없을 때 게임이 끝나지 않는다.
        * 3D지형 프로그램의 경우 지형의 끝에 도달할 경우에도 계속 전진이 가능하다.(좌표의 증가)
        * 이퀄라이져 프로그램의 경우 마이크를 끈 상태에도 이퀄라이져가 움직인다.
        * 설명해주는 오퍼레이터가 프로그램을 잘 모른다. 프로그램 개발자가 직접 오면 좋지만, 그렇지 못한 경우 좀더 상세한 설명이 있으면 좋았을 듯 하다.
        * 저것처럼 큰 행사는 아니어도. 한달에 한번씩 작은 전시회를 해보면 어떨까요??. 아무리 작은 성과라도 발표를 위해서 준비하는 과정이 필요하고 그 과정에서 다들 열심이 하는 분위기가 만들어 지지 않을까요??
• 제로Wiki . . . . 7 matches
        * 개략적 설명 : 각 페이지는 자신의 뇌의 일부분으로 생각 할 수 있다. 각 페이지는 다른 페이지들과 종속 및 포함 관계를 가질 수 있다.(페이지 링크를 통해서 가능함) 그리고 이 페이지를 다른 여러 사람들과 공유할 수 있다. 기존 위키 처럼 하나의 커뮤니티에서의 공유가 아니라 다양한 커뮤니티 사이트들이 서로 서로 페이지를 공유 할 수 있게 되고, 그 공유 페이지가 업데이트 되었을 경우 현재 공유중인 모든 커뮤니티에 그것이 반영된다.(수정된글 목록에 떠서 사람들에게 환기 시킨다)
        * 하는 방법 : 예를 들어서 제로페이지 카페에 자신의 위키에 있는 페이지를 올리고 싶을 경우 먼저 제로페이지 카페에서 화면 오른쪽 상단의 가입하기 버튼을 눌러서 가입한후, 올리기를 원하는 페이지를 고칠때 카페 선택을 제로페이지로 하고 나서 저장하면 그후로 계속 공유 관계가 유지된다.
        * 자신이 페이지 만드는 데에 참여하고 싶은 페이지는 그 페이지가 있는 카페에 가서 그 페이지를 저장할때 카페에 자신의 개인위키를 지정함으로써 자신의 개인 위키에 그 페이지를 등록 시킨다. 그러면 그 페이지와 자신의 개인 위키가 공유 관계를 가지게 한다.(공유 관계 : 공유 중인 페이지가 업데이트(수정) 될 경우 공유 관계에 있는 모든 위키에 그것이 반영된다.)
        * 프로그래밍 카페 : 규모가 커질 경우 너무 다양한 주제 대한 글들이 올라 올 수 있다. 이때 자신이 관심 있는 언어를 분류어로 설정하여 그 언어에 대한 글들만 볼 수 있다.
        * 저렇게 할 필요 없이 각 분류어별로 게시판을 만들면 되지 않냐고 생각할 수 도 있다. 하지만!!! 그렇게 각각의 분류 별로 게시판을 만들경우 그 게시판의 글들을 확인 하기 위해서 각각의 게시판에 들어 가야 한다. 그리고 군대 전우 카페 같은 경우 각 회원마다 군생활 시기가 겹치는 사람도 있고 겹치지 않는 사람도 있는등 각 회원에 따른 맞춤식 정보 제공이 필요하다. 이럴때 분류어 기능이 유용하다.
• 토비의스프링3/밑줄긋기 . . . . 7 matches
        * 템플릿과 콜백을 찾아낼 때는, 변하는 코드의 경계를 찾고 그 경계를 사이에 두고 주고받는 일정한 정보가 있는지 확인하면 된다고 했다.
        * 두 번째 방법은 테스트를 보강해서 원하는 사용자 외의 정보는 변경되지 않았음을 직접 확인하는 것이다.
        * 이것도 확인해야한다는 생각을 미처 못했다. - [김수경]
        * 이 정도 코드라면 한 번 살펴보는 것 만으로도 오류가 있는지 쉽게 찾아낼 자신이 있는 개발자도 있겠지만, 정말 뛰어난 개발자라면 아무리 간단해 보여도 실수할 수 있음을 알고 있기 때문에 테스트를 만들어서 직접 동작하는 모습을 확인해보려고 할 것이다.
        * 성격이 다른 두 가지 경우가 모두 한 곳에서 처리되는 것은 뭔가 이상하다.
        * 하지만 여러 개의 SQL이 사용되는 작업을 하나의 트랜잭션으로 취급해야 하는 경우도 있다.
        * 서비스 추상화란 이렇게 원활한 테스트만을 위해서도 충분히 가치가 있다. 기술이나 환경이 바뀔 가능성이 있음에도, JavaMail처럼 확장이 불가능하게 설계해놓은 API를 사용해야 하는 경우라면 추상화 계층의 도입을 적극 고려해볼 필요가 있다. 특별히 외부의 리소스와 연동하는 대부분 작업은 추상화의 대상이 될 수 있다.
• JavaNetworkProgramming . . . . 6 matches
        *동기화의 효율 : 대부분의 경우 동기화 작업은 매우 중요하며, 때로는 적대 생략해서는 안되는 경우도 있다. 그러나 불필요한 동기화 작업은 프로그램의 수행 성능을 떨어뜨리고, 재사용성을 감소시키며, 프로그램이 교착 상태에 빠지게 할 수도 있다.
        execution = null; //쓰레드가 크리티컬 섹션을 수행하는 도중 이 메소드가 호출되는 경우,중요한 데이터에 다른 쓰레드가 영영 접근할수 없는
        } //경우가 생길 수도 있다. 따라서 stop() 메소드를 사용하는 대신 쓰레드 자신의 종료상태를 인지하고, 수행을 중지하는 플래그
        *효과적인 다중 쓰레딩 : 자바에서 쓰레드를 생성하는 것은 매우 느린 작업이며 일부 자바 가상 머신은 쓰레드에 관련된 메모리 누스 때문에 고생하기도 한다. 따라서 효과적인 쓰레딩을 위해서는 새로 쓰레드르 생성하는 것 보다 이전에 생성했던 쓰레드 객체를 재사용하느 것이 좋다 진보된 형대의 자바 가상 머신에서는 시스템 레벨에서 이러한 쓰레드 재사용을 지원하기도 하지만, 이경우조차도 쓰레드를 재상용하는 방식을 사용하면 여러가지 이점을 얻을수 있다. --예제는 17장쯤에..
        System.out.flush(); //버퍼에 저장된 모든 데이커가 출력되었음을 확인하는 의미에서 스트림을 flush시킨다.
• MySQL . . . . 6 matches
       ZeroPage Server의 경우 MySQL의 자료 저장 디렉토리가 {{{~cpp /var/lib/mysql}}} 이므로 해당 디렉토리 내의 자료를 복사 하는 것으로 가능하다. 복사중 mysql을 정지 시키는 것을 권장한다.
       === 개인 암호 변경 방법 ( 전자가 안될 경우 후자로 변경) ===
       === 관리자의 경우 ===
       MySQL에서 한글이 들어간 문자열을 제대로 정렬하려면 char 타입이 아닌 char binary 타입을 쓰면 됩니다. 하지만 이미 char 타입으로 되어있다면 ORDER BY BINARY 필드명 을 사용하면 됩니다. MySQL에서 char 타입은 순수한 아스키(0~127) 값에서만 제대로 동작합니다. 물론 char 타입을 쓴다고 해서 한글이 저장되지 않거나 하는건 아니지만, 검색이나 정렬등에서 제대로 작동하지 않는 경우가 있습니다. --["상규"]
       MySQL 에서 다른 데이터베이스로 데이터를 옮길 경우 기존 데이터중 문제가 되는 것이 바로 내장함수인 PASSWORD 를 이용해서 암호화를 한 부분이다. 다른 데이터베이스에서 이 데이터를 쓸 방법이 없기 때문이다. 이 경우, 로직 단에서 MySQL의 Password 함수를 대신 구현해줌으로서 해결을 할 순 있다.
• ProjectPrometheus/UserStory . . . . 6 matches
       ||책에 대한 구체적인 정보를 확인할 수 있다. ||
       ||Best Book (Rating, 책 정보 열람에 따른 점수 기준)을 확인할 수 있다. ||
       ||새로 들어온 책을 분야별로 확인할 수 있다. ||
        * Best Book (Rating, 책 정보 열람에 따른 점수 기준)을 확인할 수 있다.
        * 새로 들어온 책을 분야별로 확인할 수 있다.
        * 책에 대한 구체적인 정보를 확인할 수 있다.
• Robbery/조현태 . . . . 6 matches
        경우의 수가 여러가지 나오는 경우를 어떻게 처리할까 고민했는데.. 못찾은 걸로 할까? 아니면 답으로 간주해서 출력할까? 하다가, 이 경우는 못찾은 걸로 처리하였다. ( "Nothing known." 으로 출력된다. )
        '명확한 경우' 에 속하지 않기때문에..^^
        이전의 경우 도둑이 특정시간에 존재할 수 없는경우 "The robber has escaped." 를 출력했으나, 지금은 모든 시간의 움직임을 고려해서 존재하지 않으면 "The robber has escaped."를 출력하도록 수정하였다. (사실 소스상에선 그다지 바뀐건 없다..^^)
• SoftwareEngineeringClass . . . . 6 matches
        * 수업에서 원하는 것을 얻지 못하는 경우 수강은 하되 독학 혹은 학생 차원의 그룹 스터디를 할 것을 강력하게 권한다. 졸업 후 어디를 가건 두고 두고 유용하게 쓰일 것이다. 외국 유명 대학 경우 AOD/VOD로 수업 내용을 볼 수 있는 곳이 많이 있다.
       ["1002"]: 분야가 너무 넓다. 하루 PPT 자료 나아가는 양이 거의 60-70장이 된다. -_-; SWEBOK 에서의 각 Chapter 별로 관련 Reference들 자료만 몇십권이 나오는 것만 봐도. 아마 SoftwareRequirement, SoftwareDesign, SoftwareConstruction, SoftwareConfigurationManagement, SoftwareQualityManagement, SoftwareProcessAssessment 부분중 앞의 3개/뒤의 3개 식으로 수업이 분과되어야 하지 않을까 하는 생각도 해본다. (그게 4학년 객체모델링 수업이려나;) [[BR]]
        * 지금 듣는 사람들의 이야기를 들어서는 실습을 하는 과정이 투자하는 시간에 비해서 얻는 것이 좀 적은 것 같다는 생각들을 많이하던데... 실제로 팀을 이룬 사람들중에서 실무를 확실하게 경험해 보지 않은 사람들만 있는 경우에는 이게 더 심하다고 합니다. 전 내년에나 이거 들을 차례가 올것 같은데... 이경환 교수님께서도 이번을 마지막으로 하신다고 하고... 이 과목을 반드시 들어야하나 그런 생각도 좀 드네요. 저의 경우에는 이걸 청강(or 도강;;)식으로해서 이론적인 것을 듣고, 그냥 DB, PL을 들으려고하는데.. 어떨지 모르겠네요. (그런데 컴파일러 과목은 언제 생기는 거지 ㅡㅡ;;) - 박영창
        * 저희 반 같은 경우에는 현재 컨설팅을 하고 있는 박사과정 선배님이 수업을 맡고 있죠. 가끔가다가 자신이 컨설팅 하는 경험담을 들을 수 있어서 좋다고 생각합니다. 교수님반보다 프로젝트 실습 과정에서 피드백도 더 많은 편이고요. 사실 개인적으로는 소프트웨어 공학에서 요구하는 내용을 경험한 사람이 많지 않기 때문에, 더 자주 피드백이 필요하다고 느끼지만요.
• XpQuestion . . . . 6 matches
        ''Xper 에서 비슷한 기능을 하는 페이지가 '질문답변' 인데, 이 페이지같은 경우는 직접 질문하고 답을 쓴거여서 '질문답변' 에 올리기가 좀 그렇더라구요 Faq 라는 페이지를 만들까 하다가 좀 주관적인 답이여서 그렇고. Xper 에서 페이지 제목 궁리하다가 그냥 일단 여기 만든거라는. ^^; (Xper 에도 올립니다. 페이지들 별로 녹여넣어야겠군요.) --["1002"]''
       어디선가 이야기 나왔었던 문제. 규모가 되는 프로젝트의 경우 100 장의 Index Card 는 보관하기도 어렵고 널려놓기엔 정신을 어지럽힌다.;;
       실제 회사 : 회사 로 수주받은 프로젝트의 경우, 다른 회사에서 오는 '고객' 은 실제로 그 회사에서의 말단 직원인 경우가 많다. 그러므로, 매 Iteration 시 고객에게 Story 를 골라달라고 할때 그 고객은 힘이 없다.
       과연 40시간 작업이란 가능한 일인가? 보통은 밤을 새어도 일을 못하는 경우가 많은데.
       늘 지속할 수 있는 안정적인 흐름을 만들어내는 것이 중요하다. '40' 숫자가 중요하단 뜻은 아니다. (단, PairProgramming 이 기가막히게 잘 진행되는 경우는, '40시간을 초과' 할 수가 없을 것 같다. 사람 진이 다 빠지니까. -_-;)
• 데블스캠프2011/둘째날/Machine-Learning/NaiveBayesClassifier/김동준 . . . . 6 matches
        // 들어온 데이터의 신뢰성을 체크하는 함수. 신뢰성이 없는경우 False 반환
        if(isSkipData(wordTmp)) {continue;} // 1글자Data, 사이트, 블로그, 페이지 주소의 경우 연관성및 신뢰성이 떨어지므로 검색에서 제외
        else { this.sectionWord.put(wordTmp, this.sectionWord.get(wordTmp)+1); } // 있는경우 자신의 것에 갯수를 한개 더 추가
        // 특정 단어의 갯수를 반환, 없는경우 1 반환
        //해당 기사에 대한 연산 결과를 반환하는 함수. 양수일 경우 해당 Index Section 에 일치하는 기사로 판단한 것이며, 음수일 경우 해당 Index Section 에 일치하지 않는 기사라고 판단한 것이다.
• 새싹교실/2012/AClass . . . . 6 matches
        * 6주차(6/13) - 1~5주차를 소화하지 못 할 경우를 위한 한 주.
        * 방학 중에 스터디를 할 경우 - Class, Object + Tree, Graph
        * 성적 계산기의 경우 90점이상 A, 80점이상 B와 같은 구조입니다. 100점만점을 10으로 나누면 switch문으로 풀 수 있습니다.
        * 이 과제가 무슨 말인지 이해가 안되는 경우 반드시 저에게 물어보고, 과제를 해야합니다.
        3.문자열이 대칭인경우 Palindrome, 아닌경우 Not Palindrome을 출력하는 프로그램을 작성해봅시다.
• 토비의스프링3/오브젝트와의존관계 . . . . 6 matches
        * 앞서 만든 클래스가 제대로 동작하는지 확인하려면
        * UserDao 코드가 동작하는지 확인하기 위해 너무 복잡한 작업이 필요.
        * main() 메소드에 작성한 테스트로 확인해보니
        * 모든 변경과 발전은 한 번에 한 가지 관심사항에 집중해서 일어나지만 그에 따른 작업은 한 곳에 집중되지 않는 경우가 많다.
        * 스코프(scope) : 스프링이 관리하는 빈이 생성되고 존재하고 적용되는 범위. 빈의 기본 스코프는 싱글톤으로 컨테이너 내에 한 개의 오브젝트만 만들어져서 강제로 제거하지 않는 한 계속 유지된다. 경우에 따라서 싱글톤 외의 프로토타입(prototype), 요청(request), 세션(session)스코프 등을 가질 수 있다.
        * DI의 장점 : DI를 받았을 경우 주입된 오브젝트를 인터페이스로 받는데 이렇게 하면 코드에 런타임 클래스와의 관계가 직접 드러나지 않기 때문에 주입시 주입하는 오브젝트를 바꿔주는 것으로 코드의 변경, 확장에 쉽게 대응할 수 있다.
• ACM_ICPC/2013년스터디 . . . . 5 matches
        * 풀이 - 삼차원 테이블을 사용한 DP문제, d(bar,unit,width)는 bar번째의 bar를 사용하면서, unit의 위치에 그 bar의 폭이 width일 때의 경우이다. 따라서 가능한 모든 바코드의 수를 구하는 것은 d(bar,unit,0 ~ width)를 전부 더해주면 된다.
        - 설명하면 1110110 이라는 것이 있을 때, 1110110이 오기 전에는 110으로 시작하는 모든 바코드가 있을 것이고, 그 이전에는 10으로 시작하는 모든 바코드가 있을 것이다. 그리고 1110110이라는 바코드가 오기 전에는 111000으로 시작하는 모든 바코드가 있을 것이고, 그 이전에는 11100으로 시작하는 모든 바코드가 있을 것이다. dp테이블에 해당 경우에 대한 경우의 수를 모두 저장해놨기 때문에, 앞에서 부터 차례대로 이전에 올 바코드의 수를 더해나가면 index를 구할 수 있다.
        * 풀면서 주의할 점 : dp테이블의 범위에 벗어나는 경우(예를 들어서 음수 번지)가 나올 수 있으므로 이에 대한 처리를 해줘야 한다. 비쥬얼 스튜디오에서 코드를 작성할 때, 테이블 범위에 벗어나도 정답이 나오는 경우가 생겨서 이런 예외를 발견하기 힘들었음..
• CollectionParameter . . . . 5 matches
       즉, 두 메소드의 결과를 모으는 경우인데, 그리 흔한 경우는 아니였던걸로 기억. 약간은 다르긴 하지만 나의 경우 CollectionParameter 의 성격으로 필요한 경우가 read/write 등 I/O 가 내부적으로 필요할때 또는 Serialization 등의 일이 필요할때. 그 경우 I/O 부분은 Stream 클래스로 만들고(C++ 의 Stream 을 쓰던지 또는 직접 Stream 클래스 만들어 쓰던지) parameter 로 넘겨주고 그 파라메터의 메소드를 사용하는 형태였음. --[1002]
• EightQueenProblemDiscussion . . . . 5 matches
       만약 당신보다 더 짧은 시간에, 더 짧은 코드로 문제를 해결한 사람이 있다면, 그 사람과 함께 PairProgramming (혹은 NetMeeting 등을 이용, VirtualPairProgramming)을 해서 그 문제를 함께 새로 풀어보세요. 당신은 무엇을 배웠습니까? 그 사람은 어떤 방식으로 프로그램의 올바름(correctness)을 확인합니까? 그 사람은 디버깅을 어떻게 합니까(혹은 디버깅이 거의 필요하지 않은 접근법이 있던가요)? 그 사람은 어떤 순서로 문제에 접근해 갑니까? 그 사람은 어느 정도로까지 코드를 모듈화 합니까? 이 경험이 당신의 프로그래밍에 앞으로 어떤 변화를 불러올 것이라 생각합니까?
       그 다음에는 '퀸을 놓을 수 있는 위치가 안전한 곳일까?' 하는 점에 대해 접근. 이를 SelftyZone 이라 칭했다. 이를 체크하기 위해서는 가로/세로/대각선방향을 모두 체크해야 하므로 다시 4개의 작은 모듈로 나누어졌다. 그중 대각선 체크의 경우 처음 비교를 시작할 위치를 측정하기 위한 모듈을 하나 더 추출하게 되었다.
       해당 자리에 놓았을 경우. 다른 퀸을 공격할 수 있는 위치에 대해 알아보기 위한 부분에 대해 생각했다.
       자신에게 항상 "What is the simplest thing that could possibly work?"라는 질문을 하면서 TestDrivenDevelopment를 했나요? 테스트/코드 사이클을 진행하면서 스텝을 작게 하려고 노력했나요? 중간에 진척이 별로 없는 경우, 어떤 액션을 취했나요? 그 때 테스트 사이클의 스텝을 더 작게하려고 했나요? 만약 다시 같은 문제를 새로 푼다면 어떤 순서로 테스트를 하고 싶나요? (직접 다시 한번 새로 시작하는 것도 강력 추천) 왜 다른 사람들에 비해 시간이 상대적으로 많이 걸렸을까요? 테스트 코드를 사용한 것이 그 시간만큼의 이득이 있었나요? TestDrivenDevelopment를 해내가면서 현재 패스하려고 하는 테스트 케이스에서 무엇을 배웠나요? 켄트벡이 말하는 것처럼 사고의 도구가 되어 주었나요? 참고로 저는 EightQueenProblem을 파이썬으로 약 30분 정도 시간에 50 라인 이내로(테스트 코드 제외) 풀었습니다. TestDrivenDevelopment로요. --김창준
       즉, 실제 Queen의 위치들을 정의하는 재귀호출 코드인데요. 이 부분에 대한 TestCase 는 최종적으로 얻어낸 판에 대해 올바른 Queen의 배열인지 확인하는 부분이 되어야 겠죠. 연습장에 계속 의사코드를 적어놓긴 했었는데, 적어놓고 맞을것이다라는 확신을 계속 못했죠. 확신을 위해서는 테스트코드로 뽑아낼 수 있어야 할텐데, 그때당시 이 부분에 대해서 테스트코드를 못만들었죠.
• Gof/Mediator . . . . 5 matches
       Object-Oriented 디자인은 객체들 사이의 행위 분산을 장려한다. 그런 분산은 객체들 사이에 많은 연관을 지닌 객체 구조로 나타날 수 있다. 최악의 경우에는 모든 객체가 결국 모든 다른 객체들을 알게 된다.
        1. 추상 Mediator 클래스 생략하기. 추상 Mediator 클래스를 선언할 필요가 없는 경우는 colleague들이 단지 하나의 mediator와만 작업을 할 때이다. Mediator클래스가 제공하는 추상적인 coupling은 colleague들이 다른 mediator subclass들과 작동학게 해주며 반대의 경우도 그렇다.
       FacadePattern(185)은 보다 편리한 인터페이스를 제공하고자 subsystem의 객체들을 추상화시킨 Mediator와 다르다. 그것의 protocol은 간접적이다. 다시 말하면 Facade 객체들은 subsystem의 요청들을 만들지만 반대의 경우는 그렇지 못하다. 대조적으로 Mediator는 colleague들이 제공하지 못하거나 할 수 없는 협동적인 행위를 가능하게 해준다. 그래서 그 protocol은 multidirectional하다.
       예컨대, Seminar:ElevatorSimulation 에 여러가지 배우(엘레베이터, 사람, 층, ...)들이 존재할 경우, 사람은 층을 참조, 사용하고, 층은 다시 갖고 있는 사람을 참조하고, 엘레베이터는 사람을 참조, 사용하고 하는 식으로 복잡한 (순환) 의존관계가 존재한다. 이럴 때 MediatorPattern을 쓰게되면 이 복잡한 의존고리를 끊을 수 있다.
• HelpOnConfiguration . . . . 5 matches
       MoniWiki는 `config.php`에 있는 설정을 입맛에 맛게 고칠 수 있다. config.php는 MoniWiki본체 프로그램에 의해 `include`되므로 PHP의 include_path변수로 설정된 어느 디렉토리에 위치할 수도 있다. 특별한 경우가 아니라면 MoniWiki가 설치된 디렉토리에 config.php가 있을것이다.
       모니위키의 몇몇 플러그인중 외부 프로그램을 사용하는 프로그램은 환경변수 PATH를 참조하여 외부 프로그램을 호출하게 된다. 이때 PATH의 설정이 제대로 맞지 않아 외부 프로그램이 제대로 실행되지 않는 경우가 있다. 이 경우 config.php에서 `$path`를 고쳐보라.
       윈도우에서 gvim을 사용하여 작동된다. 이 경우 {{{$path}}}설정을 제대로 해주어야 하는데, 예를 들어 다음과 같은 식으로 `config.php`에 설정을 한다.
       /!\ monisetup.php은 config.php를 변경할 수 있으나, 간단한 변경만 지원하고 세세한 변경은 지원하지 않는다. 최근 1.1.3 버전부터는 여러줄의 config.php 설정을 읽고 수정할 수 있다. 단, monisetup.php를 사용할 경우 코멘트는 모두 제거가 되므로 주의해야 한다.
• Minesweeper/이도현 . . . . 5 matches
       이번에는 처음으로 Presentation Error를 여러번 받았다. 이것은 프로그램이 도출하는 답은 맞으나 출력형식이 잘못된 경우 발생한다.
       결과적으로 이야기하면 하나의 출력세트가 있을 경우엔 밑에 빈 줄이 없어야하고 하나 이상일 때만 빈 줄이 있어야한다.
       밑에 코드에서 if문으로 outputNumber > 1 인 부분이 Presentation Error를 벗어나게 하는 해결방법이었다.
        // 출력 (출력이 하나인 경우는 밑에 빈칸을 두지 않는다!!)
• ProjectZephyrus/Thread . . . . 5 matches
        * ''Database Connection Pool 을 사용하던 하지 않던, DB 자원을 얻어오는 부분을 하나의 end point에서 처리하세요. 처음부터 이를 고려하지 않을 경우, '''*.java''' 에서 Database Connection을 생성하고, 사용하는 코드를 머지않아 보게 될겁니다. 이는 정말 최악입니다. pool을 쓰다가 쓰지 않게 될 경우는?다시 pool을 써야 할 경우는? 더 좋은 방법은 interface를 잘 정의해서 사용하고, 실제 DB 작업을 하는 클래스는 Factory 를 통해 생성하는게 좋습니다. 어떤 방식으로 DB를 다루던 간에 위에서 보기엔 항상 같아야 하죠. --이선우 [[BR]]
       가장 이상적인 상태는 예전 창준선배님이 세미나에서 이야기 했었던, '이러 이러한 라이브러리는 여기 있지 않을까 해서 봤더니 바로 그 자리에 있더라.' 하는 상태입니다. 그러면 최악은? '이러 이러한 라이브러리가 필요한데? 음.. 이쁘게 잘 만들어놓기는 귀찮고 에라 다음에 정리하지 뭐' 그리고는 해당 method들을 copy & paste. '''공통 모듈'''을 한곳에서 다루도록 하세요. 공통 모듈은 꽤 많습니다. logging, configuration, resource managing ,..
• SpiralArray/영동 . . . . 5 matches
        return true;//X방향으로 배열을 빠져나갈 경우(MAX이상)
        return true;//Y방향으로 배열을 빠져나갈 경우(MAX이상)
        return true;//X방향으로 배열을 빠져나갈 경우(0이하)
        return true;//Y방향으로 배열을 빠져나갈 경우(0이하)
        return true;//이동할 위치에 이미 딴 숫자가 적혀 있는 경우
• VendingMachine/재니 . . . . 5 matches
        그리고 사람이 주문을 했을 때 주문받은 상품의 가격에 비해 잔액이 충분한지 확인 하는 것 하구..... / 계수기[[BR]]
        사람이 투입한 돈이 형식에 맞는지(10,50,100,500,1000원) 확인해서 잔액을 늘려주어야 할 것이고,[[BR]]
        ''클래스 수가 많아서 복잡해진건 아닌듯(모 VendingMachine 의 경우 Requirement 변경에 따라 클래스갯수가 10개 이상이 되기도 함; 클래스 수가 중요하다기보다도 최종 완료된 소스가 얼마나 명료해졌느냐가 복잡도를 결정하리라 생각). 단, 역할 분담할때 각 클래스별 역할이 명료한지 신경을 쓰는것이 좋겠다. CoinCounter 의 경우 VendingMachine 안에 멤버로 있어도 좋을듯. CRC 세션을 할때 클래스들이 각각 따로 존재하는 것 같지만, 실제론 그 클래스들이 서로를 포함하고 있기도 하거든. 또는 해당 기능을 구현하기 위해 다른 클래스들과 협동하기도 하고 (Collaboration. 실제 구현시엔 다른 클래스의 메소드들을 호출해서 구현한다던지 식임). 역할분담을 하고 난 다음 모의 시나리오를 만든뒤 코딩해나갔다면 어떠했을까 하는 생각도 해본다. 이 경우에는 UnitTest 를 작성하는게 좋겠지. UnitTest 작성 & 진행에 대해선 ["ScheduledWalk/석천"] 의 중반부분이랑 UnitTest 참조.--["1002"]''
• Yggdrasil/가속된씨플플/4장 . . . . 5 matches
        * 전달인자(여기서는 배열)를 값에 의한 전달/참조에 의한 전달을 적절히 사용해야 한다. 원래 값을 보호해야 하는 경우라면 값에 의해서, 원래 값을 바꿔야하는 경우라면 참조에 의해 전달한다.
       인데, compare는 함수인데 괄호는 쓰지 않는다. 괄호를 쓸 경우 그 인자까지 알아서 써줘야할 것 같은데, sort의 정확한 구조를 잘 모르는 나에겐 좀 벅찬 방법이다. 하여튼 괄호는 쓰지 않는다.
        * throw로 예외 상황이 발생되었다는 것을 알린다. 예외 클래스엔 여러개가 있으며, 생성자로 문자열을 집어 넣을 수 있고, 이건 일반적으로 출력이 안되지만, what()함수로 확인 가능.
        * width(n) 메소드: 이전의 넓이를 리턴하며, n이 현재보다 클 경우 나머지 칸에 공백을 넣는다. n이 0이면 넓이 리셋.
• eXtensibleMarkupLanguage . . . . 5 matches
        * XML은 정말로 굉장히 강력하다. 덕분에 톰캣을 위시한 많은 애플리케이션이 셋업 파일로 XML을 활용하기 시작했다. BUT 크리티컬한 부분에 XML을 소통 데이터로 이용하게 될 경우 해당 부분이 그 프로그램의 performance critical path 가 되는 경우가 발생한다.
        * XML은 데이터 표현 방식(data presentation)이기 때문에 문법에 하나라도 어긋나거나 코드셋이 맞지 않는 경우에는 100% 에러를 내뱉는다. HTML을 다루다가 XML을 공부할 경우 이런 점에 당황스럽기도함. (DB 에서 코드셋 잘못 다루면 삽질하는 거랑 비슷함;; -_-)
        * DTD로 검색하다 여기로 왔네요ㅋㅋㅋ 예전에 쓰신 것 같아서 지금은 아시는 내용이겠지만 나중에 다른 분들이 이 페이지를 보실 수 있으니 시간을 건너뛰어 댓글 답니다~ DTD는 Document Type Definition의 약자로 XML 문서 작성을 위한 규칙을 기술하는 형식입니다. valid XML Document의 경우 well-formed XML Document이면서 XML에서 사용되는 원소 이름이 해당 문서에 대한 XML DTD나 XML Schema에 명세된 구조와 합치되어야 한다고 하네요. 이 내용에 대한 수업을 들으며 씁니다ㅋㅋㅋㅋㅋㅋㅋ - [김수경]
• 겨울과프로젝트 . . . . 5 matches
        * 마당을 굳이 나누는 이유는 너무 방만한 시간관리가 이루어지는 경우도 있기 때문이다.
        * XpWeek가 진행되며 방학을 즐기며 술독에 빠져 사는 경우가 많음으로 프로젝트 참가자를 받고, 프로젝트 진행을 위한 사전 준비를 한다. ( 학습방법, 교재, 모임주기, 기타등등 )
        * 이 이후에는 신학기 준비, 이사, OT후유증 기타등등으로 약간은 스터디 진행이 어려워 지지 않을까 생각합니다.
        * 올해 18일쯤 OT를 간 기억인데. 비슷하게 가지 않을까요??
        * 제대로 된다면 뒷풀이도 있지 않을까요??
• 데블스캠프2003/다루어볼문제와관련세미나 . . . . 5 matches
        * 그거 하면 -_-... 우리가 죽어나지 않을까;;; -- [Dantert]
        * ToyProblems 와같은 식이면 좋을것 같은데요. 1학년 텀프로젝트가 있는데 그것 하나만 가지고도 SP, OOP 등의 프로그래밍철학과, STL 등을 다루기에 좋을것 같습니다. ([http://zeropage.org/pds/200361434244/2003C++TrmPrjSpec.ppt spec]) SP 와 OOP 는.. 누가할지.. 맡게되면 고생을할수도 있겠군요. 아래 JuNe 선배님의 CSP 나.. Tuple Space (전에 P2P 관련 문서에서 본것같은 기억이..-_-a ) 등과는 약간 맞지 않을수도 있겠지만요. (그것은 다른 도메인의 문제와 다루는게 좋을듯합니다) - [임인택]
        * 지나가다 잠시 말씀 드릴까 합니다. 아직 oop개념이나 프로그램 모듈화에 대해서 개념이 없는 분들에게 STL같은 것을 가르친다는 것은 약간 문제가 있지 않을까요? oop개념을 가르쳐도 구현 같이 base적인 경험이 없이 단지 가져다 쓰는것을 먼저 배우면 좋지 않을 것 같습니다. 1학년 분들 숙제 하는 것을 보니 모듈화 같은것을 가르쳐도 좋을 것 같은데. 많은 것을 가르치려고 하시는 것은 좋으나 능력에 적절하게 가르치는 것도 맞는 것 같군요. STL 같은 걸 가르치는 건 그 다음이 되었으면 좋겠구요.. 내부사정을 잘 모르니 틀리다 싶은 말이면 걍 흘려보내세요. 지우셔도 상관 없구요. ^^ - 00 나현철
        * 도큐먼트나 튜토리얼을 이용하는 방법을 알려주는 것도 괜찮은 것 같습니다. 새내기들에게 MSDN 에서 검색을 하는 것을 알려줬더니 단지 영어라는 이유로 겁부터 먹고 사용을 못하더군요. 어떠한 주제를 던져주고 이러한 것들을 스스로 찾아서 사용하는 방법을 알려주는 것도 스스로 공부를 해 나가는데 있어서 좋은 경험이 되지 않을까 합니다. -- [상욱]
• 데블스캠프2011/다섯째날/후기 . . . . 5 matches
        * 수경이의 String 코드 레이스에서 저의 프로그래밍 달리기를 너무 빡세게 했던게 부끄러워서 이번엔 1학년 학우(저 같은 경우 성화수 학우)에게 설명해주고 그 학우가 하고 싶은 스펙으로 함께 프로그래밍 하고자 많이 노력했습니다. 파트너 교체 후 순의랑 파란 바를 만들어버리는 실수를 저지르긴 했습니다만 제가 부족한 탓이었구요-_-;; 개인적으로 화수의 '0층부터 지하까지' 아이디어는 신선했어요. 형진이가 처음에 의도했던 엘레베이터 문제(밖에서 누르고 층을 누르는 케이스)는 다른 클래스도 필요하고 일단 화수를 이해시키는데에 초점을 둬서 그걸 못 푼 점은 좀 아쉬웠어요.
        * 남이 짠 스펙을 보고 구현한다는건 처음이었습니다. 대개는 학교 프로젝트 할 경우에는 무슨 기능이 필요하다는걸 처음부터 생각하고 만드는데 실제 일하는 쪽에서는 그렇지 않을테니 좋은 경험이 됐다고 생각합니다. 유닛 테스트에서 해당 테스트 케이스가 스펙이 될 수 있다는 부분에 대해서도 잘 생각해보고 또 적용해보기 위해 노력해봐야겠습니다. 근데 TDD의 단점에 대해서는 크게 말이 없었던 것 같아서 그 부분이 좀 아쉽습니다.
        * 음... 사실 마지막에 발표했던 것처럼 이번 데블스캠프는 뭐라 할 수 없는 달성감이 있었습니다. 시청에 있으면서 이런저런 물건들을 손을 대 봤는데, 이번에 데블스에서 들은 다양한 세미나에 그것들이 들어있는 것을 보면서 반가운 느낌도 약간 들 정도였으니까요. 그리고 태진이 경우를 보면서 제 1학년 데블스 때 생각도 많이 났습니다. 그 때도 객체가 뭔지 모르고 강의를 들었었죠 ㅋㅋ 그래서 그랬는지 1학년 때는 데블스캠프가 전체적으로 힘들었던 기억이 강했습니다. 그런데 이번에는 끝나고 보니 상당히 섭섭한 느낌이 강해서 스스로도 좀 놀랐습니다. 조금이나마 공부를 해 두니까 여유를 가지고 데블스캠프의 분위기를 느낄 수 있게 된 게 아닐까 싶네요. 다만 그런 점에서 역시 1학년에게는 다소 힘든 행사가 아니었을까 하는 생각도 좀 듭니다 -___- 부디 이번 데블스캠프로 이쪽에 흥미를 가지고 스스로 이런저런 공부를 해 보는 계기가 되었으면 하네요. - [서민관]
        이때까지 학교 다니면서 데캠을 끝까지 제대로 나온적이 없어요. 데블스캠프 임원이었는데 제대로 준비한 것도 없는거같아 죄송할 따름입니다. 그래도 방학에, 이 좋은날에 낮부터 새벽까지 함께 해준 분들께 감사한 마음입니다. 좋은 자리였습니다. 살면서 이런 자리를 직접 준비해 볼 날이 많지 않을 것 같아 슬프섭섭하네요. 정모때도 많이 만나요.
• 만년달력/강희경,Leonardong . . . . 5 matches
        이번달이 무슨 요일에서 시작하는지 알 수 있다. 예를 들어 1년 2월 같은 경우
        days = 29;//윤달인경우
        days = 28;//평달인 경우
        days = 28;//평달인경우
        else//평달인 경우
• 문서구조조정토론 . . . . 5 matches
        계속 대화의 핀트가 어긋나고 있습니다. 내용 자체가 전달하려는 의도와 어긋난 것이라면, 해당 작성자가 고치는게 가장 맞는 방법이라는데 동의합니다. 제가 제기한 이야기는 그러한 부분이 아님을 말씀드립니다. 서로 연관된 문제에서 위치를 바꾸는등의 문서 구조 조정 이야기 입니다. 이 경우, 내용 자체의 변화는 없지만, 문서 구조 조정자가 관련글의 위치를 바꿈으로써 잘못된 의미를 전달할 수 있고, 그 결과로써의 파생 결과를 우려하였습니다. 이는 해당 문서 작성자보다, 문서 구조 조정자가 좀 더 신경을 쓰는 편이 맞다고 생각합니다. --이선우
       ["neocoin"]:말씀하시는 문서 조정은 문서 조정은 문서 작성자가 손대지 말아야 한다라는걸 밑바탕에 깔고 말씀 하시는것 같습니다. 문서 조정자는 특별히 문서 조정을 도맡는 사람이 아니고, 한명이 하는 것이 아니라, 다수가 접근해야 한다는 생각입니다. "다같이" 문서 조정을 해야 된다는 것이지요. 문서 조정을 한사람의 도맡고 이후 문서 작성자는 해당 문서에서 자기가 쓴 부분만의 잘못된 의미 전달만을 고친다라는 의미가 아닌, 문서 조정 역시 같이해서 완전에 가까운 문서 조정을 이끌어야 한다는 생각입니다. 즉, 문서 구조 조정이후 잘못된 문서 조정에서 주제에 따른 타인의 글을 잘못 배치했다면, 해당 글쓴이가 다시 그 배치를 바꿀수 있고, 그런 작업의 공동화로, 해당 토론의 주제를 문서 조정자와 작성자간에 상호 이해와 생각의 공유에 일조 하는것 이지요.[[BR]] 논의의 시발점이 된 문서의 경우 상당히 이른 시점에서 문서 구조조정을 시도한 감이 있습니다. 해당 토론이 최대한 빨리 결론을 지어야 다음 일이 진행할수 있을꺼라고 생각했고, thread상에서 더 커다랗게 생각의 묶음이 만들어 지기 전에 묶어서 이런 상황이 발생한듯 합니다. 그렇다면 해당 작성자가 다시 문서 구조 조정을 해서 자신의 주제를 소분류 해야 한다는 것이지요. 아 그리고 현재 문서 구조조정 역시 마지막에 편집분은 원본을 그대로 남겨 놓은 거였는데, 그것이 또 한번 누가 바꾸어 놓았데요. 역시 기본 페이지를 그냥 남겨 두는 것이 좋은것 같네요.(현재 남겨져 있기는 합니다.) --상민
       저는 PairProgramming을 가르치기에 앞서 NoSmok:PairDrawing 을 경험하게 합니다. 여기에는 여러가지 방법이 있는데, 구체적인 대상(사람 얼굴이나 동물 등)을 정해놓고 서로 한 줄 씩 번갈아 가며 그리는 방법이 있고, 아니면 아무것도 정하지 않고, 혹은 대강의 주제만 정해놓고 그냥 "멋진 그림"을 그리자는 합의하에 번갈아 가며 한 줄 씩 그리는 방법이 있습니다. 모두 그리는 중엔 말을 하지 않습니다. 여기서, 후자 경우 적극적으로 상대방의 의도를 이해하려는 노력이 없으면 좋은 그림이 나오기 어렵습니다 -- 한사람은 사람을 그리려고 하고 다른 사람은 나무를 그리려고 하는(혹은 상대가 나무를 그리려고 하고 있다고 오해한) 경우를 생각해 보세요. 상대의 의도를 이해하려고, 또 그것이 더 잘 드러나도록 서로 노력하다보면 혼자 그린 그림보다 더 좋은 그림이 나오는 경우가 종종 있습니다.
• 사랑방 . . . . 5 matches
        ''약간은 사기라고 봐도 됩니다. 퀵소트에서 첫번째 원소를 피봇으로 잡는 경우가 헤스켈에서 아주 간단히 표현될 수 있다는 점을 이용한 것이죠 -- 첫번째가 피봇이 되면 문제가 생기는 상황들이 있죠. 보통 헤스켈의 "간결성"을 강조하기 위해 전형적으로 사용되는 예입니다. 뭔가 독특한 점을 강조하기 위해 쓰인다는 것 자체가 이미 약간의 과장을 암시하고 있습니다. see also Seminar:QuickSort --JuNe''
        ex) &12;{&#; 의 경우 '''&'''12;{'''&'''#; (굵은 글씨가 매치된 케이스)
        i. 스트링 비교하여 "&"일 경우 - 찾음.
        i. 그렇지 않을 경우 - pass.
• 새싹교실/2011 . . . . 5 matches
       내가 짠 코드를 직접 출력을 통해 확인하는 것은 분명 매력적인 일입니다. 그러나 처음 익힌 코딩 습관은 버리기 매우 어렵습니다. 많은 학생들이 처음 프로그래밍을 배우며 printf 함수를 사용하여 코드를 검증하는 습관을 들입니다. 그 때문에 상당수의 졸업할때까지 테스트보다는 직접 눈으로 확인하는 것을 선호합니다. 그런데 작성한 코드가 잘 돌아가는지 알기 위해 직접 눈으로 확인해야만 하는 것은 매우 많은 문제가 있습니다.(이것에 대해서 더 적자면 정말 길어질테니 일단 이 페이지엔 적지 않겠습니다.)
        * 출력을 통한 확인보다는 테스트를 통한 확인을 유도해주세요.
• 우리가나아갈방향 . . . . 5 matches
       ZP는 인력 Pool 이고, 모임의 장으로서의 역할만이라도 충실할 수 있다면. 학교가 그 역할을 제대로 못해주고 술자리로도 그 허전함을 채울 수 없을때 ZP가 그 역할을 제대로 해줄 수 있다면. 그것을 ZP의 정체성으로 정의해도 좋지 않을까. 홈 브루 컴퓨터 클럽을 꿈꿀 수 있을지도.--석천 [[BR]]
        홈 브루 컴퓨터 클럽을 그 대상으로 한다면 참 좋은것 같다. 우리의 정모가 해당 모임이 될수 있을 것이고, 과거에도 그렇게 하려고 노력했것만, 호응도가 낮았다고 생각한다. 뭐 하지만 계속 바위에 계란을 던지다 보면 언젠가 이끼라도 끼지 않을까. 할수있는 최상은 제자리에서 열심히 --상민
       우리나라의 기업은 인턴쉽 제도가 발달되어 있지 않기 때문에, 대학생들이 방학이 되어도 자신의 전공과 관련된 경험을 쌓은 기회를 잡기가 쉽지 않아 보입니다. 그나마 아르바이트를 구하는 경우에는 프로그래밍 언어를 다루는 능력이 뛰어나고 경력이 있는 사람을 선호합니다. 그렇기 때문에 경력도 없고 프로그래밍 실력이 뛰어나지도 않은 대다수의 학부생이 방학 때 경력을 쌓기란 어렵습니다.
       학교를 따라 인맥이 형성되는 현상은 그다지 바람직하지는 않아 보이나, 없는 것보다는 낫다고 생각합니다. 인맥이 문제가 되는 것이 아니라, 아는 사람이라고 무조건 우대하는 눈먼 인맥이 문제이니까요. 인맥을 통하면 자신이 모르는 정보를 얻을 수도 있고, 자신이 하고자 하는 일에 도움을 받을 수도 있습니다. 아르바이트도 아는 사람을 통해서 구하는 경우가 태반입니다.
       연락망을 만드려면 연락처를 구하는 일이 가장 먼저 이루어져야 한다고 생각합니다. 현재 제로페이지 회원 연락망이 회장단에게 물려져 내려오고 있지만 연락처가 부정확한 경우가 상당수 있습니다. 연락이 가능한 회부터 시작하여 꼬리에 꼬리를 물고 연락처를 구해나갈 수 있을 것입니다. 그 다음으로 현재 활동하지 않는 회원들에게도 가치를 돌려줄 수 있는 정보 공유의 장이 마련되어야 하리라 봅니다. 무조건 도움을 받기만을 바라고 이러한 인맥을 만든다면 그다지 많은 호응을 얻어낼 수도 없을 것이기 때문입니다.
• 위키로프로젝트하기 . . . . 5 matches
        * 종료 - 원하는 목표에 도달했을 경우, 또는 Schedule 에 세운 계획에 맞춰 일이 완료되었을 경우에는 프로젝트를 종료한다. 만일 기간을 넘기고, 프로젝트를 진행할 의욕을 잃었다면, 프로젝트를 종료시켜라. (무기한 보류로 오래 끌고 있지 않도록 한다. 이는 추후 새 프로젝트를 열때 발목을 잡을 것이다.)
       일반게시판에 경우 프로젝트가 어떻게 진행될까? 하나의 프로젝트당 하나의 게시판이 열려있어야 한다. 프로젝트가 10개라고 한다면 게시판이 10개가 열려있어야 하고, 각각의 글들은 시간순서대로 저장이 된다. 위키에서의 page 10개의 의미와 게시판 10개의 의미중 어떤 것이 더 cost가 적게 들까? 그리고, 시간순서의 글 index 나열방식과 텍스트 내의 하이퍼링크중심 글 나열방식중 어느것이 더 의미있는 정보를 담을까?
       기존의 게시판방식이 장점이 있다면 '시간의 역사' 라는 점이 있겠다. 매일 작업일지를 쓰는 경우. 시간의 흐름에 따른 진행상황이 처음부터 주욱 보이기 때문이다. 반면 위키는 늘 현재성을 추구한다. 위키의 페이지는 늘 해당 주제를 중심으로 고쳐지는 글이다. 하지만, 시간의 역사 자체의 의미보다는 페이지 자체 내용, 즉 Content 중심의 사고라는 점에 더 무게중심을 두고 싶다. '시간의 역사' 자체가 Content 로서 중요하다면, 그것을 위한 페이지를 열어라.
        * 더 효율적으로 이용하기 원한다면, 해당 지식을 이해한 상태에서 정리가 이루어져야 할 것이다. 만일 2~3명 이상 다른 사람들과 스터디를 하게 되는 경우, 해당 지식에 대한 사람들의 이해의 관점이 다를 수 있음을 알게 될 것이다. 여러 관점을 보는 것 또한 좋은 경험이 될 것이다. (외국의 대학에서는 위키를 해당 강의에 대한 공동필기장으로 쓰기도 한다.)
• 일반적인사용패턴 . . . . 5 matches
       해당 주제에 대해 새로운 위키 페이지를 열어보세요. Edit Text 하신 뒤 [[ "열고싶은주제" ]] 식으로 입력하시면 새 페이지가 열 수 있도록 붉은색의 링크가 생깁니다. 해당 링크를 클릭하신 뒤, 새로 열린 페이지에 Create This Page를 클릭하시고 글을 입력하시면, 그 페이지는 그 다음부터 새로운 위키 페이지가 됩니다. 또 다른 방법으로는, 상단의 'Go' 에 새 페이지 이름을 적어주세요. 'Go' 는 기존에 열린 페이지 이름을 입력하면 바로 가게 되고요. 그렇지 않은 경우는 새 페이지가 열리게 된답니다.
       어느정도 위키에 익숙하시다면 보통 최근 바뀐 글 또는 RecentChanges 를 링크로 걸어놓으십시오. 가장 최근에 수정된 페이지들을 바로 확인하실 수 있습니다.
       위키의 특성상 한 페이지가 길어지는 경우가 많습니다. 스크롤을 위해 휠만 사용하는 것보다는 Page Up, Page Down을 적절하게 사용하시는 것이 편합니다. 한쪽손은 키보드, 한쪽손은 마우스.~
        * 페이지를 삭제하지 않은 경우 - 한쪽 창에서 상단 오른쪽의 파란아이와 짝짝이 안경(?)을 클릭하시면 해당 페이지의 히스토리와 페이지의 수정내용을 알 수 있습니다. 일단 파란아이를 눌러서 복구하고 싶은 버전을 View 하십시오. 그 다음, URL 입력창에서 action=recall 을 action=raw로 바꾼 후 해당 내용을 다시 복사하시면 됩니다. (이때는 Frame 안에서 작업하지마시고, 위키 페이지를 직접 전체화면으로 하여 해당 URL이 보이는 상태에서 작업하십시오.)
        * 페이지를 삭제한 경우 - 짝짝이 안경(diff) 기능이 작동하지 않습니다. 파란아이를 이용하셔서 날린 내용을 얻은뒤 편집해주세요. (조금 번거롭습니다.)
• 프로그래밍십계명 . . . . 5 matches
        *너의 컴퓨터는 1보다는 0을 좋아 하니라. 배열의 첨자가 그 범위를 넘지 않을지 손 댈 때마다 따져 보아라. 수식에 1을 더하거나 뺄 때에는 늘 긴장하라. 너의 프로그램은 단지 한 번 덜해서 틀리고 한 번 더해서 다운되느니라.
       5. 항상 모든 경우의 수를 고려하고 섣불리 생략하지 말지어다.
        *절대로 일어나지 않을 일은 반드시 일어나고, 가장 드물게 일어날 일이 가장 너를괴롭히리라. 그러하니 언제나 논리에 구멍이 없는지 꼼꼼히 따져 보고, if를 쓸 때에는 else부터 생각하라.
        *지금 그 매개 변수가 결코 가질 수 없다는 값을 내일부터는 가지리라. 그러하니 매개 변수값이 올바름을 항상 검사할지어다. 그렇더라도 처리 속도가 문제가 되는 경우는 예외이니라.
        *컴파일러의 경고는 모두 켜 두어라. 경고는 곧 오류이니라. 오류를 알리는 함수의 결과를 확인하지 않는 우를 범하지 말지어다. 모든 파일 입출력과 모든 메모리 할당은 조만간 실패할 것이라.
• 프로그래밍잔치/첫째날후기 . . . . 5 matches
        * 만일 사람들이 Courage 를 내어서, 다른 사람들 페이지에 대해서 구조조정을 빈번하게 해준다면, 계층위키가 많이 필요하지 않을것이다.
        * 개인 페이지에 대해서 '말없이 고치기' 의 경우 해당 사람의 기분을 상하게 할 수도 있다.
        * 처음으로 어떤 언어를 접했을때 그 언어를 보는 기준은 지금까지 내가 알아왔던 언어이다. 예전에 알았던 언어에 있던 구문이 이 첨 보는 언어에서는 어떻게 할 수 있나 살펴 보는 것이다. 그 원하는 기능이 이 첨보는 언어에서는 없을 수도 있고 대신 다른 기능이 있을수도 있는데. -_- 이번에 Haskell이라는 언어를 봤을때 이것도 지금까지 언어들이랑 비슷 비슷할거라고 만만하게 생각했었다. 그래서 지금까지 짜왔던 방식으로 해볼라고 생각했다. 그런데 잘 안되었다. 이 언어는 그 밑바탕에 깔려 있는 개념이 달랐던 것이다. 그래서 그런식의 접근은 좋지 않을 수 밖에 없었던 것이다. 이렇게 다른 패러다임을 바탕으로 하는 언어를 접하게 된것은 신선한 충격이었다. - 상협
        -- 어느정도 Python 을 익숙하게 써본 뒤, Python 이전에 썼던 언어들과 비교해보면 각 언어들을 더 잘 비교해볼 수 있지 않을까 생각해. 요새 자바프로그래밍을 주로 하면서 느꼈던건, '만일 자바가 인터프리터 쉘에서 실행되는 언어라면, 나의 프로그래밍 작업 방식은 어떻게 바뀔까?' 하는것. ["Python"], ["Jython"] 을 꾸준히 쓰면서, 컴파일언어에서 느끼지 못한 재미를 (즉각적으로 결과 반응이 올때 특히!) 느껴서..~ --["1002"]
        * 우선 위키에 글을 올릴 수 있는 용기를 만땅(?) 채울 수 있었다. 앞으론 '세여니'의 글들을 많이 볼 수 있지 않을까나??
• 1thPCinCAUCSE/null전략 . . . . 4 matches
       null 팀의 경우 B 문제 하나를 풀었고 (1시간 5분 정도 소요. 패널티 없음), A 번 문제를 계속 시도하던중 시간초과.
       ["1002"]가 5분 지각을 했습니다.; 암튼, 35분에 시작을 했고, 일단 5분의 시간을 두고 ["neocoin"] 과 ["1002"] 는 문제들을 읽어나가기 시작했습니다. 한글 문서였기 때문에 3개의 문제를 훑는데에도 5분이면 충분하더군요. ["neocoin"] 은 B번을, ["1002"] 는 A번을 일단 읽고, C 번에 대해서는 같이 읽었습니다. 그리고 미리 문제출제자쪽에서 난이도를 C > A > B 임을 언급했습니다. 문제를 읽어나가면서도 일단 B의 경우가 바로 계산이 나올 것 같아서 B 를 먼저 해결하기로 선택했습니다. 그 다음에는 문제에 대한 이해도가 상대적으로 높았던 A번을 해결하기로 했습니다.
       Sample 로 제공한 데이터들을 만족시키는 코드는 작성하였으나, 여전히 변수들이 다 뽑아져지지 않아서, 임의의 결과데이터 (100인 경우) 에 대해 예상되는 결과를 생각하고 코드를 작성한뒤, 코드와 결과들, 코드로부터 발견되는 변수들을 토대로 연습장에 기록을 했고, 그러던중 ["neocoin"] 이 일반화 공식을 찾아내었습니다.
       문제를 풀때 우스개로 이야기했던것이 '수학자의 접근이냐 공학자의 접근이냐'(페르마의 마지막정리 책에 나왔던 예. 즉, 연역/귀납). 이런문제인 경우 문제 풀기전 '어느쪽 접근이 더 유용할까' 궁리를.; 개인적으론 연역이 약해서 후자를..; --["1002"]
• 2thPCinCAUCSE . . . . 4 matches
        * 프로그램의 실행시간이 일정시간(예: 10초)을 지나도 끝나지 않을 경우 틀린 문제가 됩니다.
        * 컴파일 error, 실행 시간 error , 출력 포맷이 문제에서 정한 것과 다른 경우에도 틀림.
        * 제출한 답안이 틀렸을 경우, 매번 일정한 penalty 점수 (10점)를 받게 된다.
• 5인용C++스터디/멀티미디어 . . . . 4 matches
       hmod : 리소스에 있는 Wave파일을 연주할 경우 리소스를 가진 실행파일의 핸들인데, 그 외의 경우는 NULL로 준다.
        사운드 파일을 연주하는 것은 사용하기는 간단하지만 연주할 때마다 디스크에서 사운드 파일을 읽어와야 하므로 반응 속도가 느리다. 따라서 이 경우에는 사운드 파일을 리소스에 포함시켜 놓고 리소스에서 읽어서 연주하는 방법으로 하는 것이 좋을 것이다.
       hWndParent: 부모윈도우를 지정한다. NULL일 경우, 별도의 윈도우로 열린다.
• CxxTest . . . . 4 matches
       C++ 의 경우는 언어차원에서의 리플랙션을 지원하지 않기 때문에 테스트를 추가하는 부분이 자바나 파이썬 등에 비해 상당히 귀찮다. 그에 대한 대안으로 [CUT] 등의 C UnitTestFramework 의 경우 외부에서 Perl 등으로 작성한 스크립트언어로 테스트실행과 관련한 Runner 를 코드제너레이팅하는 방법을 쓰고 있다.
       [1002]의 경우 요새 CxxUnit 을 사용중. 밑의 스크립트를 Visual Studio 의 Tools(일종의 External Tools)에 연결시켜놓고 쓴다. Tool 을 실행하여 코드제너레이팅 한뒤, 컴파일. (cxxtestgen.py 는 CxxTest 안에 있다.) 화일 이름이 Test 로 끝나는 화일들을 등록해준다.
       단점이 있다면 테스트 상속이 안된다는 점이다. 개인적으로 MockObject 만들어 인터페이스 테스트 만든뒤 RealObject 를 만들어 테스트하는 경우가 많은 만큼 귀찮다. (테스트의 중복으로 이어지므로) 어흑.
• DPSCChapter3 . . . . 4 matches
        하지만, 두 경우에 자동차를 생성하기 위한 코드와 그것의 컴포넌트 하위 부분은 여전히 같다. 즉, 모든 CarPartFactory 클래스들은 동일한 메시지 프로토콜을(다형성)을 구현하기 때문에, 팩토리 클라이언트는 팩토리 타입이 무엇인지 상관하지 않고 호출을 할 수 있다. 그것은 단지 팩토리 프로토콜에 의해 제공되는 일반적인 메시지를 전송한다.
        다형성의 힘 때문에, 클라이언트는 코드 구현을 한번만 하면된다. ABSTRACT FACTORY PATTERN을 사용하지 않을 경우, 자동차 생성 코드는 다음과 같이 보일 것이다.(아주 비효율적인 코드)
        따라서, CarAssmebler를 만들기 위한 자동차 종류가 무엇이고 그 하위 부분들이 무엇을 해야하고, 그것의 실제 부분의 인스턴스가 무엇을 수행해야 할지를 결정한다. ABSTRACT FACTORY 해결은 우리가 CarAssembler 객체 밖의 모든 행동들을 추상화시킨다. 그리고 팩토리로 분리한다. 특별한 자동차 팩토리로 CarAssembler 확인을 한 후에, CarAssembler는 간단하게 구체적인 자동차와 하위 부분을 만들기 위한 팩토리를 호출한다.
• EightQueenProblem/nextream . . . . 4 matches
       기본 아이디어는 한 라인씩 진행해 가면서 현재 라인 선상에서 X좌표값을 바꿔가며 위에 있는 퀸들에 의해 위협을 받는지 검사해서 안전한 경우에는 계속 다음 라인으로 진행하고, 아닌 경우에는 철수하는 것입니다. 위협여부에 대해서는 같은 세로선상이거나, 대각선인 경우는 X, Y 좌표의 합과 차가 각각 동일한 것이 있는지를 조사하는 것으로 만들었습니다.
       결과물 확인하기 좋게 display 부분을 약간 수정해봤습니다. --[1002]
• GarbageCollection . . . . 4 matches
       1. 어떻게 앞으로 사용되지 않을 객체를 결정할 수 있는가?
       2번째 경우에 대한 힌트를 학교 자료구조 교재인 Fundamentals of data structure in c 의 Linked List 파트에서 힌트를 얻을 수 있고, 1번째의 내용은 원칙적으로 완벽한 예측이 불가능하기 때문에 시스템에서 객체 참조를 저장하는 식으로 해서 참조가 없으면 다시는 쓰지 않는 다는 식으로 해서 처리하는 듯함. (C++ 참조 변수를 통한 객체 자동 소멸 관련 내용과 관련한 부분인 듯, 추측이긴 한데 이게 맞는거 같음;;; 아닐지도 ㅋㅋㅋ)
       이거 말고도 문제가 상당하다고 하지만, 해석해야하는 관계로;;; 아래 링크에서 확인 바람.
       2번째의 것의 경우에는 자료구조 시간에 들은 바로는 전체 메모리 영역을 2개의 영역으로 구분(used, unused). 메모리를 할당하는 개념이 아니라 unused 영역에서 빌려오고, 사용이 끝나면 다시 unused 영역으로 돌려주는 식으로 만든다고함. ㅡㅡ;; 내가 생각하기에는 이건 OS(or VM), 나 컴파일러 수준(혹은 allocation 관련 라이브러리 수준)에서 지원하지 않으면 안되는 것 같음. 정확하게 아시는 분은 덧붙임좀..;;;
• HelpOnInstallation/SetGid . . . . 4 matches
       보안상의 이유로 웹서버는 php 스크립트를 `nobody, www, apache` 혹은 `httpd`같은 특별히 제한된 계정으로 실행하게 됩니다. 이러한 이유로 [모니위키] 스크립트가 생성하게 되는 여러 파일 혹은 디렉토리는 이러한 특별한 계정의 소유가 되며 진짜 사용자가 소유하지 못하게 되는 일이 발생하고 어떤 경우는 이렇게 만들어진 파일을 읽을수도 지울 수도 없게 됩니다.
       이런 경우를 막기 위해서 `chmod 2777` 대신에 `chmod 777`을 하는 경우도 있으나, 이로서 문제가 모두 해결되지는 않습니다.
       Please see http://www.pmichaud.com/wiki/PmWiki/ErrorMessages
• MFC/Control . . . . 4 matches
       하나의 컨트롤은 클래스와 연계될 수도, 안될 수도 있다. 정적 컨트롤의 경우 클래스가 필요없을 것 같지만 CStatic 이라는 클래스를 통해서 모양을 변경하는 것이 가능하다. 마찬가지로 버튼 컨트롤들의 경우도 대부분 Dialog 객체를 통해서 처리가 된다. CButton 클래스의 경우에는 컨트롤을 관리하는데있어서 객체가 필요할 경우에 이용하게 된다. 이러한 모든 컨트롤들은 모두 윈도우의 일종이기 때문에 CWnd 에서 상속된 클래스를 이용한다.
• ProgrammingLanguageClass . . . . 4 matches
       프로그래밍 언어를 배우는 것은 사고와 표현의 방식을 하나 더 배우는 것이다. 따라서, 설사 해당 언어로 프로그래밍을 할 기회가 별로 없다고 해도, 판이한 언어를 하나 더 배우는 것은 가치있는 일이다. 동시에 무슨 언어를 배우느냐, 어떤 신택스를 익히느냐는 것은 크게 중요하지 않다. 언어는 변하고 사멸하고 신생하며, 유행도 바뀐다. 그보다 그런 언어 저변에 깔려있는 다양한 패러다임을 접하고 충분히 이해하고 적용할 수 있어야 한다. 하지만 이게 가능하려면 구체적인 언어라는 채널을 통하지 않을 수가 없다.
       중앙대학교 컴공과에 컴파일러 수업이 폐강되는 경우가 많은데, 컴파일러와 PL 둘 중 하나는 프로그래머가 되건, 전산학자가 되건 반드시 필요한 교양이다.
       아쉬운 부분은 프로그램 언어론이란 과목임에도 불구하고, 설명의 비중은 많이 쓰이는 언어일수록 높았던 점입니다. 함수형언어(FunctionalLanguage)는 기말 고사 바로 전 시간에 한 시간만에 끝내려다가, 그나마 끝내지도 못하고 요약 부분만 훑었습니다. 그 밖의 종류에 대해서는 거의 절차적 언어, 특히 C계열 언어를 설명하다가 부연 설명으로 나오는 경우가 많았습니다. 논리형언어(LogicLanguage)에 대한 설명은 거의 못 봤습니다. 어차피 쓰지 않을 언어라고 생각해서일까요.--[Leonardong]
• ProjectPrometheus/CookBook . . . . 4 matches
       물리적인 모래시계가 없을 경우 사용할만한 모래시계 소프트웨어
        단순하지만 매우 편리한 타이머. 태스크 바에서 남은 시간을 확인 가능
       getParameter 가 호출되기 전에 request의 인코딩이 세팅되어야 한다. 현재 Prometheus의 Controller의 경우 service 의 명을 보고 각각의 서비스에게 실행 권한을 넘기는데, 가장 처음에 request의 characterEncoding 을 세팅해야 한다. 차후 JSP/Servlet 컨테이너들의 업그레이드 되어야 할 내용으로 생각됨 자세한 내용은 http://javaservice.net/~java/bbs/read.cgi?m=appserver&b=engine&c=r_p&n=957572615 참고
       ["Ant"] 를 이용하면 된다. Ant 의 경우 컴파일 & 배포할때 수정된 화일만 덮어쓰기를 한다. CVS & ["Ant"] 조합이면 해결이라 생각.
• ServiceQualityOfYongsanMarket . . . . 4 matches
        용산의 메인 고객은 소비자가 아니므로. 뭔가 핀트를 잘못맞춘건 아닐까; 그리고 용산의 영수증인 경우, 워낙에 이일저일(?) 하는 일들이 많아서 일부러 자유로이 빈 영수증 두었다가 필요할때 상호 도장찍는 경우 많음..--[1002]
        보통 이런경우보다는 기분좋게 물건사는 경우가 더 많았는데, 이날은 정말 짜증이 밀려와, 개인적으로라도 이 가게는 안가려고 리스트업하는겁니다. 흐흐. - 임인택
• SmallTalk/강좌FromHitel/강의4 . . . . 4 matches
       측할 수 있게 됩니다. 물론 대부분의 경우는 발자취 창의 제목만 보고서도
       문제의 원인을 파악할 수 있습니다. 지금과 같은 경우에는 우리가 내린 명령
       Dolphin의 경우 꾸러미 탐색기나 창맵씨, 자원 탐색기가 있으며, Smalltalk
       언제나 편한 것만은 아닙니다. 어떤 때는 글쇠판이 마우스보다 편할 경우가
• TAOCP/BasicConcepts . . . . 4 matches
       E0. [m >= n 인지 확인하기] m < n 이라면, m <-> n 을 교환한다
       Ω에 속하는 xk 에 대하여 k가 가장 작은 정수라면 계산수열은 k단계에서 종료된다고 한다. 그리고 이 경우에 x로부터 결과 xk가 생성된다고 한다.
        A2. 왼쪽에서 오른쪽으로 가면서 흔적이 없는 첫번째 문자를 START라고 한다. 왼쪽 괄호와 그 문자를 출력하고 흔적을 남긴다. 모든 문자에 흔적이 남을 경우 종료한다.
        A4. 오른쪽으로 가면서 CURRENT와 같은 문자를 찾는다. 찾은 경우 흔적을 남기고 A3로 간다. (못 찾고 오른쪽 끝까지 가면 A5로 간다.)
• TAOCP/InformationStructures . . . . 4 matches
       여태까지는 문제(더 넣을 공간이 없거나, 더 지울 것이 없는 경우)가 없다고 가정했다. 이 문제까지 고려한 과정이 다음과 같다.
       가능한 공간에 리스트가 두 개 있다면 (고정된)bottom을 같이 쓸 수 있다. (p.246 그림 참고) 이런 경우 두 리스트가 메모리를 모두 써버릴 때까지 오버플로우는 생기지 않는다. 이런 형태는 매우 자주 쓰인다.
       n개의 스택이 있는 경우 i번째(1≤i≤n) 스택에 원소를 넣고 빼는 과정을 다음과 같이 적을 수 있다.
        b) ''''아래로 한칸씩 밀기(moving things down)''' a)에 해당하는 k가 없을 경우
• TdddArticle . . . . 4 matches
       류군 이야기로는 Oracle 의 경우 설치하고 딱 실행하는데만 기본 메모리 200메가 잡아먹는다고 한다. -_-; 로컬 테스트를 위해 HypersonicSql를 쓸만도 하군.; (In-memory DB 식으로 지원가능. 인스톨 할것도 없이 그냥 콘솔에서 배치화일 하나 실행만 하면 됨. 근데, JDBC 를 완벽히 지원하진 않는 것도 같아서, 약간 애매. (ResultSet 의 first(), last(), isLast() 등의 메소드들이 실행이 안됨)
        DeleteMe) - 오라클의 경우 인스턴스당 기본으로 먹는게 보통 200 메가 정도. 즉 기본 외에 자기가 만든걸 더 띄울경우 보통 400 메가 이상을 먹게 되는데 이건 뜰때 얘기고 가만히 냅두면 50 메가 이하로 메모리가 내려감. 물론 윈도우 하에서 얘기임. 나머진 확실하지 않음. 연결이 많아지면 메모리가 다시 올라갈것임. -박준용-
       초반 자동화를 위해 준비할 것들에만 좀 신경을 쓰고, 익숙해진다면 잘 할 수 있지 않을까 생각.
• VisualBasicClass/2006/Exam1 . . . . 4 matches
       ② ScrollBar는 수평, 수직, 양방향 모드가 있으며, 여러 줄을 사용하는 속성을 설정할 경우, 사용할 수 있다.
       ② 인수들을 서브프로그램에 모두 다 전달하기 부적절한 경우에는 Optional이란 키워드를 사용하면 효과적이다.
       ④ 일반적으로 함수 이름이 F_Name일 경우, 이 함수 내부에는 F_Name = 식 형태의 할당문이 있어야 한다.
       의외로 다른 결과를 내는 경우가 있다.
• ZeroPage성년식 . . . . 4 matches
        * 페이스북에서 바로 신청을 하는 경우 문제가 있을수도 있는거 같았아요. 정욱이형이 저번에 된줄 알았는데 안됐길래 다시하라고 해서 됐거든요. -[김태진]
        * 그닥 문제가 없었던걸로 기억하는데 저도 제로페이지 메일에서 신청에 문제가 있다고 보내주신걸 확인했습니다. 메일로 간단한 몇가지 사항과 함께 참가 의사를 밝히면 저희가 관리하는 방법도 있지 않을까요 - [지원]
        * 몇시부터 어떻게 몇 시간동안 진행하는지에 따라 25일도 가능하지 않을까 라는 생각도 드네요. 뭐 그게 아니라면 뒤로 늦추는 거 보다는 일찍 하는 것이 좋을 듯 싶네요. - [권순의]
• django . . . . 4 matches
        * 개발이 끝나고 실제로 서비스할 경우에는 apache + mod_python 으로 올려야 한다.
        * html 이 있는 template 에 많은 것을 바라지 말자. 가능하면 view에서 데이터를 거의다 처리해서 template에 넘기는것이 좋다. template에서 받아온 데어터로 리스트와 맵 변수의 첨자(subscriber)로 사용하려고 했는데 안된다. 이러한 경우에는 view에서 데이터를 아예 가공해서 넘기는 것이 좋다.
        * syncdb 해도 admin 에서 추가한 것이 보이지 않을때는 runserver 한거를 중지 시키고 다시 서버를 시작 하면 보인다.
       [예시] /path/to/project/mysite 에 settings.py 파일이 있는 경우
• 경시대회준비반/BigInteger . . . . 4 matches
       C++ 용 BigInteger 클래스로 거의 모든 연산을 지원한다. UVA 사이트의 구식(?) 컴파일러에도 문제없이 통과할 뿐 아니라, 성능또한 훌륭하다. 고정도 정수 연산을 하는 문제의 경우, 고정도 연산을 하는 라이브러리를 본인이 직접 짜거나, 이 클래스를 이용하면 된다. 몇 일동안 삽질한 결과 후자가 낫다는 판단이 선다. 되게 잘 짜여진 코드다. 시간 내서 분석해봐야 겠다.
        enum BigMathERROR { BigMathMEM = 1 , BigMathOVERFLOW , BigMathUNDERFLOW, BigMathINVALIDINTEGER, BigMathDIVIDEBYZERO,BigMathDomain};
        const char *BigIntErrDes[] = { "Allocation Failed", "Overflow","Underflow", "Invalid Integer", "Divide by Zero" ,"Domain Error"};
        void Dump(const char *,enum BigMathERROR);
        string& DumpString (char const*,enum BigMathERROR);
        throw logic_error (DumpString ("DivideAndRemainder (BigInteger/BigInteger)",BigMathDIVIDEBYZERO));
        throw logic_error ( DumpString ("DivideAndRemainder (BigInteger/DATATYPE)",BigMathDIVIDEBYZERO) );
       void Dump(char const* s,enum BigMathERROR e)
        cerr << "Error Code: " << e << endl;
       string& DumpString (char const* s,enum BigMathERROR e)
        ostr << "Error Code: " << e << endl;
        throw domain_error ( DumpString ("Square Root",BigMathDomain) );
• 데블스캠프2004/세미나주제 . . . . 4 matches
        - [STL]의 경우 사용법을 세미나하는것도 좋지만 GenericProgramming 의 개념과 왜 그러한 패러다임이 나왔는지, 그 배경에 대한 설명도 있으면 좋을 것 같습니다 - [임인택]
        - 그 정도 주제까지 간다면, ProgrammingLanguage 관련 전체를 다루는 수업의 연장선에 놓는게 좋지 않을까요? --NeoCoin
        * 시험은 수요일날 완료. RevolutionOS는 '예' 로 든것이고. 실제로 04중에는 알 사람도 얼마 없지 않을까 해서. 적당히 컴퓨터쪽 역사의 과거와 미래에의 모습에 대해 보여줄만한 영화, 그리고 재미있는 녀석이면 환영. --[1002]
        - 영웅은 스스로 만들어지는것이 아니라 시대가 만드는것입니다. 시대의 요구가 있다면야 누군가는 반드시 나타나지 않을까요? -- 장창재
• 문자반대출력/허아영 . . . . 4 matches
        비베에서는 한글이나 일본어처럼 2바이트를 사용하는 글자의 경우 알아서-_- 판단하고 한 글자 단위로 읽는 함수가 있긴 한데 씨에서는 알파벳과 같은 1바이트 문자인지 아니면 2바이트 문자인지를 어떻게 구분해야 할까요? -태훈 [zyint]
        MSB는 비트로 표현된 값에서 가장 중요한 요인이 되는 값을 말합니다. 가령 10001000 이라는 값이 있을때 가장 왼쪽에 있는 1이 MSB입니다. 마찬가지로 가장 왼쪽에 있는 0을 LSB (Least Significant Bit)라고 합니다. 지금 설명드린 내용은 BigEndian Machine 의 경우, 즉, 비트를 왼쪽에서 오른쪽으로 읽는 아키텍처에서의 MSB, LSB를 설명드린 것이고, LittleEndian (비트를 오른쪽에서 왼쪽으로 읽는) 아키텍처에서는 LSB와 MSB가 바뀌어야겠죠. 현대의 거의 모든 아키텍처에서 영문은 ascii 코드로 표현합니다. ascii코드의 값은 0~127인데 이를 8비트 2의 보수를 사용해서 표현하면 MSB가 모두 0 이 됩니다. 이 경우에는 해당 문자가 1바이트의 문자란 것을 뜻하고, MSB가 1인 경우에는 뒤에 부가적인 정보가 더 온다 (죽, 이 문자는 2바이트 문자이다)라는 것을 말합니다.
• 새싹교실/2011/앞반뒷반그리고App반 . . . . 4 matches
        * 그거쓰면 중간에 그 값이 거짓일경우 프로그램 따운 시켜버리는거임. 오류검사할때 쓴다고 봐야하려나..?- [김태진]
        에서 assert안이 참일 경우 그냥 지나가버리지만(프로그램이 종료하지만) 그렇지 않을경우
• 서버재조립토론 . . . . 4 matches
       네 충분히 그렇게 생각 하실수 있다고 생각합니다. 현재로서 서버가 하는일이 웹서버및 소스 Repository 로서의 역할이니깐요. 그리고 마지막에 프로젝트 때문에 필요할 경우에 나 새로 맞출 필요가 있다고 하신 말씀도 동감합니다. 현재 한 3주 동안 제로페이지 서버가 제대로 작동하지 않았습니다. 제로페이지 서버를 아주 자주 이용하는 입장에서는 많이 제로페이지 서버에 들어가니깐 서버가 죽어 있어서 여러가지로 불편했고, 현재 제로페이지 서버와 연계해서 돌아가는 위키 포탈을 운영 및 관리하는 입장에서는 치명적이었습니다. 제로페이지 회원들이야 안면이 있으니깐 이해해 주겠거나 좀 불편하고 말겠지 하고 생각하실수도 있지만, 위키 포탈 서비스가 우리 학회에서 제공을 해주는 서비스지만 외부에서 이용하는 사용자도 꽤 있었는데 왠만한 사용자들은 다 빠져 나간듯 하네요.. 그래서 지금은 급한게 다른 서버에서의 DB 지연을 기다리는 시간을 원래 1분에서 3초로 줄여서 그나마 임시 방편으로 수습을 했습니다. 또 프로젝트 진행을 하는데에도 제로페이지 서버가 자주 죽어서 진행을 제대로 할 수가 없었습니다.
        제로페이지 서버가 현재 분명 문제가 있고, 이것을 해결해야 한다는데에는(즉 좀 가끔가다가 죽으면 뭐 어때 하는 분은 없을거라고 생각합니다.) 모두 동감 하실거라고 생각합니다. 현재 제로페이지 서버가 아주 자주 죽는 문제가 제로페이지 서버의 하드웨어 적인 문제인가, 소프트웨어 적인 문제인가, 인프라적인 문제인가 이 3가지중 하나라고 생각합니다. 인프라적인 문제는 다른 학회나, 동문서버도 안 죽고 하니깐 제외 하겠습니다. 그러면 하드웨어 아니면 소프트웨어 적인 문제인데. 솔직히 저는 리눅스가 오래 사용해서 자주 뻗는다는 것은 좀 이해가 가지 않습니다. 리눅스를 서버로 우리보다 훨씬 오래 사용하는 곳도 부지 기수일텐데 그런곳들이 모두 이런 문제를 겪고 있을까요.. 그렇다고 지금까지 관리가 안되서 그런것도 아니라고 생각합니다. 상민형, 석천이형, 영창이 모두 제가 생각하기에는 그 누구보다도 서버 관리를 잘 했다고 생각합니다. 물론 테스트를 해봐야 알 문제입니다. 오늘 회장님이 테스트 해본다고 했는데 가끔씩 서버가 죽는 문제를 어떻게 테스트를 해야할지 전 감이 안 오네요. 한 일주일정도 제로페이지 서버를 죽이고 다른것(다른 하드에) 웹서버를 깔아서 아주 아주 수시로(몇분 단위로) 그 웹서버로 들어와서 죽었는지 확인을 해야 하는데(물론 테스트는 테스트를 진행하는 한두사람만 하겠죠. 현재의 제로페이지 위키만 해도 하루 방문자가 1000이 넘는것에 비해서...)그게 참 어려운 문제라고 생각합니다. 또 한 일주일동안 서버를 죽이는것도 현재 위키위주로 돌아가는 제로페이지에도 치명적이구요. 이렇게 테스트를 해서 만약 하드웨어 적인 것이 문제라면 또 다시 서버를 업그레이드 한다음에 다시 서버를 설치하는 작업을 해야겠죠.
        즉 제가 서버업그레이드를 제안하는것은 하드웨어적인 문제나 소프트웨어적인 문제를 동시에 해결하고자 제안한 것입니다. 위와 같은 테스트를 할경우 그에 따른 희생및 서버 관리자의 불필요한 수고가 필요합니다. 그리고 학회 운영 및 프로젝트에서도 많은 희생이 따름니다. 그리고 위와 같은 테스트도 확실한 방법은 아니구요, 여전히 불확실성을 내포한 방법입니다.
        저는 업그레이드가 필요하다고 생각합니다. 서버의 핵심은 안정성인데, 지금의 서버는 안타깝게도 그 역활을 제대로 수행해주지 못하고 있기때문입니다. 서버 업그레이드 시도를 하게되면, 이전의 컴퓨터에 문제가 없다고 판단될 경우 새서버의 보조 역활과 리눅스 테스트용 서버로 사용해도 큰 문제가 없다고 생각합니다.^^ 속도 측면에서는 현재의 서버도 전혀 문제가 없지만, 안정성이 낮은점은 이용자의 입장에서 불편하다고 느낄 수 밖에 없기 때문입니다.(실제로 많이 불편했답니다.ㅠ.ㅜ 꼭 필요할때만 죽어있어요..) - [조현태]
• 수학의정석/집합의연산/조현태 . . . . 4 matches
        알고리즘은 1과 0으로 수를 저장, 한칸씩 옮겨가면서 모든 경우의 수를 찾는 것이다.
        또한 예를 들어 7개일 경우는 1개일때, 2개일때, ... 7개일때 이런식으로 나누어서 연산을 한다.
        이렇게 세팅후 1인 경우에 출력한다. 한차례연산후
        이런식으로 연산을 하여 모든 경우의 수를 찾아낸다.^^
• 위시리스트 . . . . 4 matches
        * 신청한 물품은 운영진의 판단 또는 예산, 상황에 따라서 일부 승인되지 않을 수 있습니다.
        * 여러 개가 필요한 경우 갯수도 기재
        * 책의 경우에는 ISBN도 기재
        * 서적같은 경우는 회원 개개인의 관심분야에 따라 수요가 달라질 수 있으니 서적을 신청할 때 해당 서적의 수요 조사를 하고 수요가 높은 순서대로 신청하는 것도 좋을 것 같습니다 - [장혁재]
• 일정잡기 . . . . 4 matches
        * 예를들어 3학년 동기엠티를 추진하는 K군이 있다고 하자. K군은 5월 중에 MT를 가고싶어한다. K군은 일정을 잘 잡는데 필요한 요소를 고려해서 1달 전에 MT를 갈 계획을 세우기 시작한다. 이 때 1달전이라는데서 얻을 수 있는 이점은 1번과 2번이다. 1번의 경우, MT참가 인원에 영향을 미치는 요소들을 미리 파악할 수 있게 된다는 장점이 생기게 되는데, 예를들어 농활(5/3~5/6) 해오름제(5/16) 축제(5/22~5/24)와 같이 일정을 잡는 사람이 바꿀 수 없는 요소를 미리 파악해 이를 피하도록 유도할 수 있다. 2번의 경우, MT참가자들의 일정을 1달전에 고정시킴으로 인해서 자신의 다른 일정들을 다른 날짜로 보내도록 만들고, 해당 날짜에 MT가 있음을 주지시켜 이 날 다른 집단이 일정을 잡는 것을 피하도록 할 수 있었다.
        * 역시 가장 좋은 방법은 위에서 말한대로 일정을 미리 잡는 것인데, 이외에 3번이 필요한 경우도 발생한다. 예를들어 3학년의 특정 한 과목을 재시험쳐야하는 상황이 왔는데, 일정이 있는 당일 오후 6시에 시험을 칠 뻔 하였으나 강의실 사정 등으로 수업시간에 치게되는 운에 의해서 일정에 영향을 받지 않는다던가 말이다.
        * 반면에 1,2,3번이 모두 결여된 경우도 있는데, C집단의 회장 L군은 2012년 C집단의 정모가 매번 다른 일정과 겹치게되는 불운을 맞이하게된다. 정보 수집을 하지 못해 학교 행사와 일정이 겹쳤음은 물론이고, 그 때문에 직전에 날짜를 바꿈으로 인해서 다른 사람들의 다른 일정과 모조리 겹쳐지게 되기도 한다. 게다가 운도 없어 그 날짜에 자신이 참석하지 못하는 불운을 맞이하였고, 일정 파토라는 최악의 사태를 낳기도 했다.
• 정모/2013.9.11 . . . . 4 matches
        * 행사 참여비용이 인당 10만원이 넘는 경우, 그리고 단체 지원금액이 20만원이 넘는 경우, 회의를 통해서 지원 여부를 결정.
        * 몇 달 간격으로 경과 보고를 진행을 해보는 것은 좋지 않을까? - 정의정 학우
        * 오픈 캠프 형식으로 스터디 결과를 보고하는 방법은 좋지 않을까? - 안혁준 학우
• 지금그때2003/토론20030310 . . . . 4 matches
        * 학기 초 들떠있을때보단, 사람들이 어느정도 차분해지고, 자신의 미래를 관찰할 수 있을때 행사를 가지는 것이 좋지 않을까?
        * 오히려 그러한 때에 이러한 행사를 하면 그 의미와 효과가 크지 않을까?
        * 기타 - 금요일인 경우 학교선배가 아닌 다른모임사람들을 같이 참석시킬 수 있다. ex) RenaissanceClub
        ex) 토요일 : 학부생들 수업이 없어서 학교에 오지 않을 가능성 높으므로 참여도가 적다.
• 질문레스토랑 . . . . 4 matches
        * 정말 질문하고 싶은 경우 개인당 1회로 질문권 발동
        * 메뉴판에 없는 질문이 하고 싶은 경우 포스트 잇에 적음
        * 새로운 질문이 등록된 경우 주사위를 굴리기 전 웨이터가 모두에게 질문을 알려줌
        * 한 질문에 대해 7분이 넘는 대답을 하는 경우 매니저가 아이템으로 중지시킴
• 창섭/삽질 . . . . 4 matches
        * 실수는 어이없게 생기는 경우가 허다하다. 황당하게 시간버리지 말자. =_=
        * 이제 절대로 하지 않을 것 같은 삽질, 내가 생각하게에 제일 어이없는 삽질 순위 3까지만 보관한다. 나머진 큐처럼 지우기.
        * 이상하게 함수가 작동을 안하거든 기본적으로 parameter 갯수와 reference 여부를 확인하자.
        * 특히 멀쩡하던거 고칠 때 확인 잘하자.
• 페이지이름 . . . . 4 matches
        * 영문 제목의 경우 모두 빈칸을 붙여서 사용한다. (제목으로 표시될때 자동으로 단어의 대문자 단위로 빈칸을 띄어주므로)
        * 한글 제목의 경우 붙여쓰기를 기본.
        추상적이라 생각되면 일종의 사랑방으로 이용하면 된다고 봅니다. 범용적인 만큼 스레드 성격의 글들을 더 잘 포용할 수 있지 않을까 생각합니다. 저는 '토론'(을 원한다면) 이나 '제안'(성격이라면) 임이 명시적으로 드러나는것이 좋지 않을까 생각한것 뿐, 특별한 다른 뜻은 없습니다. --["1002"]
• 2학기파이선스터디/서버 . . . . 3 matches
        except socket.error:
        print 'Socket Error'
        except socket.error:
        print 'Socket Error'
        except socket.error:
        print 'Socket Error'
• AOI/2004 . . . . 3 matches
       uva robot의 경우 보통 300 번 이상의 test case 를 쓰는 것 같습니다. 동적 메모리가 아닌 정적으로 할당할 경우 이 점을 유의(?)하지 않으면 RE error(포인터 에러)가 납니다. 보창은 이것때문에 하루종일 프로그램을 뜯어고쳤으나, 결국 우연한 기회에 알게 되었습니다. LCD-Display의 경우 robot은 1000줄 이상을 test하는 걸로 보여집니다. -- 보창
• AcceleratedC++/Chapter3 . . . . 3 matches
        * stream으로부터 읽어들이는데 실패할 경우
        * type이 맞지 않을때
        * 실패했을 경우에는 stream 초기화를 시켜줘야 한다.(4장에서 보자)
• AttachmentMacro . . . . 3 matches
       파일이 이미 올려 있을 경우에는 그 파일을 받을 수 있는 링크가 자동으로 걸리게 되고, 파일이 아직 업로드되지 않았다면 파일을 업로드 할 수 있는 링크가 생성된다.
       이 경우 config.php에 {{{$use_convert_thumbs=1}}}를 넣어준다.
       == GUI를 사용하는 경우 ==
• CompleteTreeLabeling/조현태 . . . . 3 matches
        두개를 곱해서 21이하라는 조건인데.. 최악의 경우는 각각 3개의 뿌리를 가질때 깊이가 7이되면..
        3280개의 노드가 생긴다. 고로 이걸 3280!해서 나오는 경우의 수를 생각하면 10^10000이 사뿐히 넘어간다는... 애초에 계산이 될리가 없잖..
        21*1이라도 빠른 속도로 계산하지만.. 깊이가 깊어지는 경우에 대해선 아직 약하다..ㅠ.ㅜ
• CryptKicker . . . . 3 matches
       e, i, o 와 같은 글자는 알파벳의 특성상 10퍼센트가 넘는 출현빈도가 나타난다. 기억나기론 E가 13퍼센트 정도였던것 같다. 이 규칙을 따르지 않는 문장과 단어가 있지 않나고 반박할지 모르지만 확률이다. 특수화된 경우의 문장과, 단어의 경우를 일반화 시키면 곤란하다. 이런 알파벳의 출현빈도는 몇줄의, 몇개의 단어에는 잘 맞지 않을테지만, 암호화된 문장과 문서가 많아질수록 그 출현빈도는 표중화된 확률에 거의 일치하게 된다.
• CubicSpline/1002/NaCurves.py . . . . 3 matches
       class ErrorLagrange:
       class ErrorPiecewiseLagrange:
       class ErrorSpline:
• DebuggingSeminar_2005/DebugCRT . . . . 3 matches
       || _CRTDBG_CHECK_ALWAYS_DF || _CrtCheckMemory() 함수를 모든 new, delete 함수에 대해서 자동 호출 되도록 지정한다.[[BR]] 이 함수는 할당된 공간의 유효성을 지속적으로 체크한다. 즉 domainerror나 기타 메모리 access에 관한 부분을 검사한다. 대신 오버헤드가 상당하다. 그러나 그만큼 디버깅의 효율성을 높여줄 수 있다. ||
       || _CRTDBG_LEAK_CHECK_DF || 프로그램이 종료되는 시점에서 _CrtDumpMemoryLeaks()를 호출. 메모리 해제에 실패한 경우 그 정보를 얻을 수 있다. ||
       || _CRT_ERROR || 복구불가한 치명적 에러 ||
       대체로 클래스에서의 메모리 유출은 동적 멤버 변수들이 만들어졌을 때 해야하는 '삼의 법칙'을 지키지 않는데서 비롯되는 경우가 많다.
        동적 멤버변수를 사용하는 경우에는 대입, 할당 생성자, 소멸자를 반드시 만들어야한다.
• DebuggingSeminar_2005/UndName . . . . 3 matches
       DLL 파일에 의해서 분석된 내용을 보면 DLL 에 함수의 이름이 이상하게(?) 변형되어 있는것을 확인하실 수 있는데(DUMPBIN.EXE 를 통해서 가능합니다.) 이 이름의 원형을 알고 싶을때가 있습니다. 그럴때 undname.exe 라는 파일을 사용하시면 아주 쉽게 확인해 보실 수 있습니다.
       {{{~cpp 'char * __cdecl MapDLLappyFunc(char *)'}}} 라는 알기 쉬운 형태로 변형되어 있음을 확인할 수 있습니다.
• ExtremeBear/VideoShop . . . . 3 matches
       전화번호 뒷자리 물어보는 입력창이 뜨고 같은 번호 중복 되있는 것이 있을 경우 이름도 입력받아서
       이름 물어보고 없을 경우 신규 입력 받음
       등급에 안맞을 경우는 (주민등록번호와 관련되어서 알아서 프로그램이 처리해준다 )대여불가능하다고 나온다.
• GuiTesting . . . . 3 matches
       GuiTesting 을 하는 이유는 여러가지가 있을 수 있다. GUI Programming 에 대한 TestFirstProgramming 에 대한 시도를 할 수 있기 때문이다. 해당 UI Control을 하나하나 만드는 일부터 시작할 수 있다. 하지만, 보통의 경우 UI Control을 만드는 일들은 IDE 툴들에서 하는 것이 더 편하다. GuiTesting 은 해당 이벤트 발생시에 따른 처리과정에 대한 TestFirstProgramming 을 시도하려고 할 때 도움을 줄 것이다.
       대부분의 경우는 TFP를 하는중에 logic 부분과 UI 부분을 분리함으로서 GuiTesting 을 복잡하게 하는 요소들을 줄일 수 있다. 그러면서 Model - View - Controler 의 형태가 유도되어질 것이다.
• HanoiProblem . . . . 3 matches
       재귀함수가 사용되는 대표적인 예 몇가지를 보여줍니다. 재귀함수 사용에도 그 종류가 다른데, 대표적인 종류들을 보여주는 것이 중요합니다. "아, 재귀함수라는 것이 이렇게도 사용될 수 있구나!" 퍼뮤테이션/콤비네이션, 피보나치수열, 트리검색, 팩토리알, 조건문과 재귀호출로 반복문(while) 만들기 등이면 충분하지 않을까 합니다.
       반대로 문제가 너무 단순해서 복잡할 경우에는 오히려 100개, 200개 등의 복잡/일반적인 경우를 생각하는 것이 도움이 될 수도 있습니다.
• HelpOnActions . . . . 3 matches
        * `!DeletePage`: 파일 지우기 - 하단에 파일 지우기 액션 메뉴가 있는 경우가 있습니다. 이 액션을 누르면 페이지의 최종 백업본이 지워지지만 페이지의 역사는 계속 남아있으므로 (시스템 관리자가 이것을 지우지 않는 이상) 언제든지 복구할 수 있습니다. 일부 위키에서는 지우기가 활성화 되어 있지만, 모니위키에서는 기본적으로 관리자만이 페이지를 지울 수 있도록 설정되어 있습니다.
        * `!LikePages`: 비슷한 이름을 가지는 페이지 목록을 찾아줍니다. 영문의 경우 적절히 잘라내어 앞/뒤 단어별로 검색해주며, 한글일 경우에는 앞/뒤 한글자 이상을 잘라내어 비슷한 파일 이름이 있는지 찾아줍니다.
• IpscAfterwords . . . . 3 matches
        * 전에 K-In-A-Row 같은 경우는 일종의 StepwiseRefinement 의 형식이 나와서 비교적 코딩이 빠르게 진행되었었고, (비록 답은 틀렸지만) Candy 문제의 경우 덕준이가 빨리 아이디어를 내어서 진행이 빨랐었는데, 실전에서는 그런 경우들이 나오지 않아 버겨웠던듯 하네요.
• JavaStudy2003/두번째과제/노수민 . . . . 3 matches
        그래서 디버그 및 결과 확인불가.;
       자바 언어를 이용하여 객체를 생성하고 필요에 따라 값을 초기화 해 주어야 하는 경우
       * 메소드 내에서 변수와 객체의 이름이 같을 경우 변수 앞에 this를 붙임
• JavaStudy2004/클래스상속 . . . . 3 matches
        인스턴스 변수의 경우 클래스에 새로운 변수를 만들었다면, 현재 클래스의 변수와 상위클래스에서 정의된 모든 변수를 가질수 있다. 따라서 모든 클래스들의 조합으로 현재의 객체를 위한 템플릿을 형성하게되고 필요한 정보를 채우는 것이다.
        * 디폴트 전달인자 : type functionName( type A1, type A2, A3 = 0 );와 같이 값이 전달 되지 않을경우 자동을 전달되는 값을 가지는 함수의 기능을 말합니다.
• KnightTour/재니 . . . . 3 matches
        나이트가 위치한 셀이 고립된 경우 BackStep 과정을 한 번 더 실행하면 루트를 찾는 시간이 훨씬 짧아짐.
        몇몇 경우에서 broot-force 보다 더 검색을 많이 하는 경우도 발견됨.
• LoadBalancingProblem . . . . 3 matches
        SuperComputer 사는 N 개의 CPU 로 이루어진 슈퍼컴퓨터를 제작하였다. 각각의 CPU는 1에서 N 까지 번호가 새겨져 있으며 각각 독립적인 작업을 수행한다. 새로운 작업이 생기면 무작위로 한개의 CPU 에 그 작업이 할당된다. 이럴 경우 어떤 CPU 에는 작업이 엄청 많고 다른 CPU 에는 할당된 작업이 적거나 아예 없는 상황이 발생하게 된다. 이럴경우 각 CPU 에 작업을 적당하게 분배하여야 하는데 각각의 재분배 작업은 N번 CPU가 1-N, 1-N CPU 에 각각 하나씩의 작업을 전달하는 것이다. 차근차근 살펴보면,
        1. (...) N 번 CPU 를 본다. 작업을 전달해줘야 할 경우 N 번 CPU 의 오른쪽에는 CPU 가 없으므로, 왼쪽으로만 전달할 수 있다.
• MFC/DynamicLinkLibrary . . . . 3 matches
       확장자가 반드시 DLL이어야 하는 것은 아니지만, DLL 이 아닌경우에는 프로그래머가 이를 로드하는 부분을 따로 만들어야 한다. .vbx .ocx같은 것은 특정한 종류의 컨트롤들을 포함하는 DLL 들이다.
       runtime dynmaic linking 의 중요한 점은, 런타임 상에서 해당 모듈을 교체할 수 있다는 점이다. winamp 의 나 KMP 등와 같은 플러그인을 제공해주는 프로그램의 경우 대부분 이러한 runtime-dynamic linking 방법을 이용한다.
       DLL 에서 동적으로 메모리를 생성하는 경우, 해당 DLL 을 이용하는 프로세스의 힙에 해당 메모리 공간이 잡히게 된다. DLL 이 하나만 올라간다고 메모리가 공유되진 않는다.
• MFCStudy_2002_2 . . . . 3 matches
        * [07/18] - 공지는 수시로 확인해 주세요. 부탁드립니다!
        * [08/18] - 이번주는 결국 못모였습니다. 다들 바쁜 모양이더군요. 다음 주 초에 모입시다. 월요일 쯤이 좋을 것 같습니다만, 모두 여기를 확인할 지 의문이군요.
        ' 저는 확인 하긴 했는데.. 월요일이네요~ 에헤헤~ ^-^;; 이번주 내내 학교 나올거 같으니깐.. 시간 정하세요..^-^;;-성재
• NumericalAnalysisClass/Report2002_2 . . . . 3 matches
       (5) Plot the Error f(x) - L10(x)
       (6) Plot the Error f(x) - L3(x)
       (7) Plot the Error f(x)- S3(x)
• OurMajorLangIsCAndCPlusPlus/float.h . . . . 3 matches
       ||FLT_EPSILON ||1.0과 더했을 때 float형으로 1.0이 되지 않을 최소의 값 ||1.192092896e–07F ||
       ||DBL_EPSILON ||1.0과 더했을 때 double형으로 1.0이 되지 않을 최소의 값 ||2.2204460492503131e–016 ||
       ||LDBL_EPSILON ||1.0과 더했을 때 long double형으로 1.0이 되지 않을 최소의 값 ||2.2204460492503131e–016 ||
• OurMajorLangIsCAndCPlusPlus/stdio.h . . . . 3 matches
       || int ferror(FILE *) || 스트림에 오류가 있을경우 0이 아닌값을 리턴 합니다. ||
       || char * fgets(char *, int, FILE *) || char*에 int의 길이만큼 스트림에서 읽어서 저장한다. 파일의 끝이나 오류일 경우 NULL을 리턴한다. ||
       || char * gets(char *) || 표준 입출력에서 한줄을 입력받는다. 오류가 발생할 경우 NULL을 리턴한다. ||
       || void perror(const char *) || 마지막 에러에 대한 오류메시지를 출력한다. ||
• ProgrammingContest . . . . 3 matches
       나이나 학력 제한이 전혀 없습니다(Open경우). 팀은 세명까지 가능하고, 혼자서도 참가 가능합니다. 사용 가능 언어는 Java, C++, Pascal, Python 등 입니다. 제한 조건은 한 팀은 프로그램 개발을 위해서는 하나의 컴퓨터만 사용해야 한다는 것입니다. 이번 금요일(2002/5/10)에 한국 시간으로는 오후 9시부터 5시간 동안입니다. 온라인(이메일)으로 진행합니다. (see also .http://ipsc.ksp.sk/rules.php )
       특이한 점은 토너먼트 형식으로 제한된 시간내에 프로그래밍 대결을 벌인다는 거죠. 이긴자에게 상금을 줍니다만 미국외의 사람에겐 받을 자격이 없는 것 같기도 합니다. 스윙 애플릿을 다운로드 받아서 주어진 문제에 대해 자바, C++, C# 등으로 코딩할 수 있고 제대로 해결했는지 그 자리에서 바로 확인할 수 있습니다. -- 박지훈
       http://ace.delos.com/usacogate 에서 트레이닝 받을 수 있지요. 중,고등학생 대상이라 그리 어렵지 않을겁니다. ["이덕준"]은 ProgrammingContest 준비 첫걸음으로 이 트레이닝을 추천합니다.
• ProjectSemiPhotoshop/요구사항 . . . . 3 matches
        참신한 아이디어를 추가할 경우 최대 3점까지 추가 점수가 가산될 수 있다.
        * 레포트 표지에 자신이 수행한 내용 중 3)을 추가한 경우 설명서의 6, 7, 8과 같이 표시하고, 4)의 내용을 추가한 경우 설명서의 번호 9.를 표시한다.
• ProjectVirush/Rule . . . . 3 matches
       * 명령을 수행하는데는 현실 세계의 시간이 필요하다. 따라서 플레이어는 게임에 접속해서 명령이 수행될 시간을 예약한다. 그리고 예약한 시간에 자신의 명령이 수행되었는지를 다음 번에 확인하고 새로운 전략을 세운다.
        * 기본 항체가 새로운 바이러스를 잡기에 모자라는 경우(바이러스 사살 속도<바이러스 증식 속도), 숙주는 새로운 바이러스임을 알아차리고 이에 특화된 항체를 생산한다. 특화된 항체는 기본 항체보다 바이러스 사살 속도가 빠르다.
        * 한 번 특화된 항체를 생산한 경우 이를 '''습득 항체'''라고 하고, 특화된 항체를 생산하는 과정이 빨리 일어난다.
• ProjectZephyrus/간단CVS사용설명 . . . . 3 matches
        추가후 리부팅 <-확인 안해봤음
        그룹 확인
       groups 확인한아이디
• ToyProblems . . . . 3 matches
        1. 선배가 이 간단한 문제를 다양한 패러다임으로 다르게 풀 수 있다는 것을 보여주고 간략히 설명한다. 이때, 대부분의 경우 긴 설명이 필요없다. 이미 문제를 풀어봤기 때문이기도 하고, 문제 자체가 간단하기 때문이기도 하다.
       학생은 이 경험을 통해 프로그래밍 "개념"과 "패러다임"들을 학습하게 되며, 어떤 경우에 어떤 패러다임이 더 적절한지 판단할 능력이 생기고, 무엇보다도 한가지 패러다임에 대한 초기 각인(새끼새가 처음 본 흰색을 무조건 어미라고 생각하는 효과)을 깨트리고, 좀 더 자유로워질 수 있다 -- 한가지 패러다임만 아는 사람보다는 여러가지 패러다임을 아는 사람이 더 개방적이고 포용력이 넓다. --JuNe
        1. 비교해 본다. 몇 가지 패러다임이 나왔나(아마도 하나나 둘을 넘지 않을 것이다) 10m
• ZPHomePage . . . . 3 matches
        사진첩이랑 자료실은 제로페이지 회원만 접근가능합니다(가입할때 제로페이지 회원으로 가입해야되고요 제가 한번 확인해보고 권한을 드립니다)
       저같은 경우에는 모니터 해상도를 1280 * 1024로 하고 사용하는데 ZP창은 너무 작습니다. 즉 여백이 엄청나게 많습니다. 적당히 해상도에 맞추어 홈페이지를 보여주는 게 좋을 듯 합니다. --재동
       건의사항입니다. 위의 모인모인 캐릭터를 Upload:ZeroWikiLogo.bmp 로 교체하고 기본 CSS를 clean.css로 바꿨으면 합니다. 모인모인 캐릭터의 경우 00학번 강지혜선배께서 그리신 거라는데(그래서 교체하더라도 원본은 삭제하지 않는 것이 좋겠습니다.) 제로위키에 대한 표현력이 부족하다고 생각해서 제가 새로 그려봤습니다. 그리고 clean.css가 기본 바탕이 흰색이고 가장 심플한 것으로 보아 기본 CSS로 가장 적합하다고 생각합니다. -[강희경]
• django/RetrievingObject . . . . 3 matches
       일대다 관계인 레코드의 경우는 selete_related메소드를 이용하면 데이터베이스 접근 횟수를 줄일 수 있다. 일반적인 데이터베이스 조회는 추상화되어있어 실행할 때마다 쿼리를 수행한다. 하지만 selete_related메소드를 사용하면 한 번 데이터베이스에서 결과를 가져온 후 필요할 때는 이를 그대로 사용한다. 다음 예제에서 두 방식이 어떻게 다른지 확인할 수 있다.
       사용자는 원하는 경우 extra메서드를 이용해 원하는 컬럼을 추가한 결과를 얻을 수 있다. 다음은 2006년 1월 1일 이후 보고서를 최신으로 표시하는 컬럼을 가진 리포트 정보를 가져온다.
• html5/communicationAPI . . . . 3 matches
        * 보안을 위해 메세지를 주고받는 상대의 신원 확인 필수
        // origin 속성으로부터 송신처 확인
        // data 속성으로 수신된 메세지 확인
• woodpage/VisualC++HotKeyTip . . . . 3 matches
        *컴파일시 error나 경고에 warning에 대하여 한줄씩 이동함 또 전체 문서에서 찾기(Alt + E + I) 에서 찾은결과에 대하여도 F4로 이동
        *믿을만한 소식통에 확인해본결과 WndTabs 최신버전은 단축키가 바꼈다고하는데 먼지 모르겠다. 별수없이 지금 있는 버전(2.50)을 씀
        *WndTabs를 깔면 울트라 에디트처럼 편집창밑에 열어본 페이지들이 나온다. 근데 열어본 파일이 많을경우 머가 먼지 모르게된다.
        *그럴경우 Ctrl + Shift + O(알파벳)을 누르면 최근에 열어본 페이지들이 앞쪽으로 나오게 된다. 이것도 좀 유용함
• 김영록/연구중/지뢰찾기 . . . . 3 matches
       static int gameover=1; //0일경우 메뉴 무한루프 끝
       void mine_confirm(int X, int Y); //지뢰가 있는지 없는지 확인
       void mine_update(int X, int Y); //지뢰가 없을경우 그근처에 지뢰수를 업뎃
• 네이버지식in . . . . 3 matches
       가장 먼저 떠오른 건, 이용자 수였다. 이용자 수가 엄청나게 많다는 점이 지식in서비스를 활발하게 해 주었다. 이용자 수가 많아진 이유는 여러 가지가 있겠지만, 텔레비전 광고까지 낼 정도로 홍보를 해서 그렇지 않을까? 반면 위키 홍보는 몇 번인가 하고는 그 뒤로는 사람들이 알아서 쓰기를 바랬던 것으로 보인다. 알려지지 않은 서비스가 아무리 많은 장점이 있다 한들 사람들이 알아야 쓸테니까, 위키 사용이 활발하지 않은 건 일단 덜 알려져서라고 생각한다.
       다음으로는 익숙하지 않은 형식이었다. 아예 인터넷을 처음 만나는 사람이라면 익숙한 형식이 있지도 않겠다만, 많은 사람들이 글을 쓸 때는 게시판에 제목과 이름과 내용정도가 달린 게 글 형식이고, 글 제목이 목록으로 한 페이지에 나오는 형식이 익숙한 형식일 것이다. 때문에 전부 '''내용'''처럼 생긴 위키를 보고는 일단 다르게 생긱 형식에 바로 적응하지는 못할 것이다. 쓰기 어렵지는 않겠지만 말이다. 때문에 위키가 엄청난 장점을 가져서 적응하는 노력을 들이고 싶을 만 하지 않다면 굳이 사용하려 하지 않을 것이다. -[Leonardong]
       사람들은 [네이버지식in]을 마치 수학 문제 해답지처럼 여기는 것 같습니다. 저도 요즘엔 누가 궁금한 게 있다고 물어봤을 때 모르는 경우''지식in 검색해봐''라는 말을 자주 합니다. 제가 누군가에게 모르는 걸 물어봤을 때도 자주 듣습니다. ''지식in엔 없는게 없다니까''라는 말도 들어보았습니다. 마치 [네이버지식in]에는 살아가며 궁금한 것들에 대한 모든 해답이 있는 듯이 여기고 있다고 느꼈습니다. -[Leonardong]
• 데블스캠프2006/목요일후기 . . . . 3 matches
       API의 경우 완전 생소하기도 하고 API에 대한 기본적인 이론보다 코딩을 중심으로 가르쳐주셔서
       물론 예상외로 빠른 반응이 올 경우에 대비한 강의분량도 있어야겠지만 그렇다고 해서 느릴 경우를 예상하지 못하면 더 실패할 수 있다.
• 데블스캠프2009/금요일/SPECIALSeminar . . . . 3 matches
        * SI 업체의 경우 분석, 설계 후 Test가 다른 팀에 넘어가기도 하는 등 Feedback이 어렵다.
        * 반복문이 제대로 됐는지 체크 - 첫, 끝 index 출력, 에러 메세지 확인
        * 주어진 정보로 error의 범위를 최대한 좁혀라!!
        * 전문가에게 컨텍하라. - 특히, 외국의 경우, e-mail을 하면 80%는 답변을 해준다
• 루프는0부터? . . . . 3 matches
       보통 비대칭형 범위는 대칭형 범위보다 더 사용하기 쉽습니다. 왜냐하면 다음과 같은 중요한 속성이 있기 때문입니다. [m, n)과 같은 형식의 범위는 n-m개의 요소들을 가지며 [m,n]의 형식은 n-m+1의 요소들을 가집니다. 따라서 [0, rows)에서 요소들의 개수는 직관적인데 반해, [1, rows]에서 요소들의 개수는 덜 직관적 입니다. 이러한 속성차이는, 특히 빈 범위의 경우에 더 뚜렷합니다. 만약 비 대칭형 범위를 사용한다면, 빈 범위를 [m,n)으로 표현할수 있지만, 대칭형 범위에서는 [n, n-1]을 사용해야 합니다. 범위의 끝이 시작보다 더 작을수 있따는 가능성은 프로그램 설계시 끝이 정의되지 않아 버리는 문제를 야기 시킬수 있습니다.
       지금까지 r개의 행을 출력했따고 표현할 수 있기 때문입니다. 만약 1부터 번호를 매긴다면? 이제막 r번째 행을 출력하려는 찰나라고 정의할 수도 있겠지만, 그러한 구문은 불변식으로 정당치 않습니다. 왜냐하면, while이 조건식을 마지막으로 검사할때, rows+1이 되기 때문입니다. 이때 우리가 원하는 것은 rows행만을 출력하는 것 입니다. 따라서 우리는 r번째 행을 막 출력 하려던 것이 아닌 셈이 됩니다. 지금까지 r-1개의 행들을 출력했다고 불변식을 정의할 수도 있을 것입니다. 하지만 불변식을 그런식으로 정의 햇다면, r을 0부터 시작시켜 단순화 시키는 것이 더 낫지 않을까요?
       조건식이 r!=rows라면, 루프가 끝날 때 r==rows라는 사실을 알수 있습니다. 불변식은 r개의 행을 출력했따는 사실을 말해 주기 때문에, 정확히 rows개의 행을 출력했다는 것을 알 수 있습니다. 한편, 만약 조건식이 <=rows라면, 그로부터 알 수 있는 사실은 최소한 rows개의 행을 출력했다는 사실 뿐입니다. 따라서 그 이상을 출력했을 수도 있는 것입니다. 0부터 번호를 매기게 되면 정확히 rows번의 반복을 수행했는지 확실히 하고자 할 때, R!=rows를 조건식으로 사용할 수 있습니다. 또한, 반복횟수가 rows번 또는 그 이상이 되기만을 원한다면, r<rows를 사용할 수 있습니다. 만약 1부터 번호를 매기다면 최소 rows번의 반복만을 원할때 r<=rows를 사용할 수 있습니다. 하지만, rows가 정확한 숫자가 되도록 하려면 어떻게 해야 할까요? 그런 경우에는 좀더 복잡한 조건식인 r==rows+1과 같은 방법을 사용 할수 있습니다. 하지만 이렇게 복잡하게 해서 얻을수 있는 이득은 거의 없습니다.
• 몸짱프로젝트/CrossReference . . . . 3 matches
       ch = fin.get();// 알파벳이 아닌 문자일 경우
       //ofstream fout("result.txt", ios::app); // result.txt 라는 파일에 출력하는 경우
       if ((*node) == NULL){// 빈 노드일 경우
• 문서구조조정 . . . . 3 matches
       위키는 ["DocumentMode"] 를 지향한다. 해당 페이지의 ["ThreadMode"]의 토론이 길어지거나, 이미 그 토론의 역할이 끝났을 경우, 페이지가 너무 길어진 경우, 페이지하나에 여러가지 주제들이 길게 늘여져있는 경우에는 문서구조조정이 필요한 때이다.
• 문제풀이/1회 . . . . 3 matches
       책에서 숫자를 가지고 장난 친경우는 없는것 같아서...
       Equivalent to eval(raw_input(prompt)). Warning: This function is not safe from user errors! It expects a valid Python expression as input; if the input is not syntactically valid, a SyntaxError will be raised. Other exceptions may be raised if there is an error during evaluation. (On the other hand, sometimes this is exactly what you need when writing a quick script for expert use.)
        이런 경우를 개선하기 위해서 map 함수가 있는것입니다. 이를 Haskell에서 차용해와 문법에 내장시키고 있는 것이 List Comprehension 이고 차후 [http://www.python.org/peps/pep-0289.html Genrator Expression]으로 확장될 예정입니다. 그리고 print 와 ,혼용은 그리 추천하지 않습니다. print를 여러번 호출하는것과 동일한 효과라서, 좋은 컴퓨터에서도 눈에 뜨일만큼 처리 속도가 늦습니다. --NeoCoin
• 새싹교실/2011/學高 . . . . 3 matches
        * 학생들이 보충수업을 요청해올 경우 보충수업 또한 진행합니다.
        * [윤종하]: 수업 준비가 미흡해서 제대로 진행못했고, 실습으로 준비한게 수준이 좀 높았다. 김준호 학생의 경우 visual studio 설치와 Wi-Fi가 안 됨을 계속 불만사항으로 지적했으며 수업태도가 상당히 불량했습니다.
        * [윤종하]: 김준호를 제대로 지도하지 못해서 진도가 덜 나가서 약간 좀 진도나가기가 힘들었다. 김준호에 대한 개별 보충학습을 수행하거나 혼자서 공부를 해오도록 유도하겠다. 세영이 같은 경우는 집이 멀어서 공부를 하기가 힘들다고 했다. 따라서 중간 고사 이후에는 시간을 확실히 조정하도록 하겠다. '''더 이상의 참가는 불허할 방침'''
• 새싹교실/2011/무전취식/레벨10 . . . . 3 matches
        //그리고 좌우대칭을 확인??
        * ㅋㅋㅋ오늘도 일등입니당*_* 위키올라오기전에 미리 확인한 건 처음이에요. 과제하다가 들어와서 써용. 오늘 코딩해본 1, 2번은 다했습니다. 스스로 생각해보고 스스로 코딩해보는게 중요한 것 같아욧!! 문제를 보고 어떻게 해결할까 고민하는 과정이 실력을 키우는 것 같네용... 여태까진 다른사람 생각을 그대로 옮기는 코딩을 했다면 이제부터는 제 스스로 생각해보고 코딩을 해야겠어요히히*-_-* 하하핫 이제 3번을..... - [이소라]
       // 만약 first seat이 다 찼을경우 질문 스캔
• 새회원을받으면 . . . . 3 matches
        * 열심히 하지 않을 사람은 안 받는게 좋을껄 --[인수]
        * 왜냐면, 열심히 하는 사람과 열심히 하지 않을 사람이 같이 섞여 있으면 서로 피곤하기 때문이지. 유유상종을 잊지 말게나! --[zennith]
        - [http://netory.org 네토리]처럼 정기적(또는 비정기적)인 무언가가 있었으면 좋겠습니다. 굳이 그것이 모임의 형태가 아니더라도 ''새내기들이 자신이 제로페이지에 지원하였다는 사실을 잊어버리지 않게''해 주는게 필요하지 않을까요? 예를 들면, 숙제를 내준다던지, ProgrammingParty 같은 것들이요. - [임인택]
• 송년회 . . . . 3 matches
       학기 마무리행사로 학교전체가 들썩일텐데, 예약이 필요하지 않을까요?? - [이승한]
       이메일을 잘 확인안하는 사람도 많은데... 문자나 전화가 젤 좋지않을까요?
• 여섯색깔모자 . . . . 3 matches
       평소에 의견을 교환 하다가 보면 어느새 자신의 자존심을 지키려는 논쟁 으로 변하게 되는 경우가 많다. 이 논쟁이란게 시간은 시간대로 잡아 먹고, 각자에게 한가지 생각에만 편향되게 하고(자신이 주장하는 의견), 그 편향된 생각을 뒷받침 하고자 하는 생각들만 하게 만드는 아주 좋지 못한 결과에 이르게 되는 경우가 많다. 시간은 시간대로 엄청 잡아 먹고... 이에 대해서 여섯 색깔 모자의 방법은 굉장히 괜찮을거 같다. 나중에 함 써먹어 봐야 겠다. 인상 깊은 부분은 회의를 통해서 지도를 만들어 나간후 나중에 선택한다는 내용이다. 보통 회의가 흐르기 쉬운 방향은 각자 주장을 하고 그에 뒷받침 되는것을 말하는 식인데, 이것보다 회의를 통해서 같이 머리를 맞대서 지도를 만든후 나중에 그 지도를 보고 같이 올바른 길로 가는 이책의 방식이 여러사람의 지혜를 모을수 있는 더 좋은 방법이라고 생각한다. 이 책도 PowerReading 처럼 잘 활용 해보느냐 해보지 않느냐에 따라서 엄청난 가치를 자신에게 줄 수 도 있고, 아무런 가치도 주지 않을 수 있다고 생각한다. - [상협]
• 정모/2011.4.11 . . . . 3 matches
        * 앗 비… 비 생각은 못 했네요. 비오면 어쩌지ㅜㅜ 확인해볼게요……………… 확인 결과 안 온다고 합니다!! 야호!! - [김수경]
        * 이번 정모에는 11학번 학우분들이 참여하여 반가웠습니다. Ice Breaking때는 화기애애한 분위기가 마음에 들었습니다. 다들 웃으면서 ㅎㅎ 재미있는 시간이었던 것 같습니다. 일일 퍼실리테이터... 어떤 느낌일지는 모르겠지만 한번 해 보는 것도 재밌지 않을까라는 생각도 했습니다. 이번 OMS를 진행하면서.. 음... 역시 배경이 문제였었던 같습니다 -ㅅ-;; 그리고 생각했던거 보다 머리속에 있는 말이 입 밖으로 잘 나오지를 않아가지고 제가 생각했던 것들을 모두 전달하지 못했던 것 같습니다. 사실 음악을 좋아하다 보니까 영화나 TV를 보다가 아는 음악이 나오면 혼자 반가워 하고 그랬는데,, 그 안에 있는 의미를 찾아보는 일은 많이 하지 않았었습니다. 다만, 이런걸 해 보겠다고 생각했던게 아이언맨 2 보다가 (보여드렸던 장면에서) 처음에는 Queen의 You're my Best Friend라는 노래로 생각하고 저 장면과 되게 모순이다라고 생각했었는데 그 노래가 아니라 다른 노래라 조금 당황했던 것도 있고, 노래 가사를 보면서 아 이런 의미가 있을 수도 있겠구나 라는 생각을 했습니다. 그래서 이것 저것 찾아보게 되었던 것이 계기가 되었던 것 같습니다. 그리고 이번 스피드 퀴즈는 그동한 제로페이지에서 했던 것들이 많았구나 라는 생각과 함께, 제가 설명하는데 윤종하 게임이 나올줄이야 이러면서 -ㅅ-;; ㅋㅋㅋ 마지막으로 다음주 소풍 기대되네요 ㅋ - [권순의]
• 지금그때2004/패널토의질문지 . . . . 3 matches
       질문하는 사람이 없을 경우 사회자가 패널에게 질문할 것들
       질문을 할때 사회자의 말투라고 할까요. 내용은 위의 질문내용으로 할 수 있지만 질문접근방법에 대해서도 신경쓰면 더 좋은 답을 얻을 수 있지 않을까 합니다. 그러한 점에서 볼때 [질문의힘] 의 후반부에 나오는 인터뷰들의 예를 참고해볼만 하다 생각합니다.
       "저의 경우 지금 자료구조 수업을 듣고 있는데 머릿속에 잘 안들어옵니다. 선배님들은 자료구조가 중요한 과목이니 열심히 공부하라고 하시지만 쉽지가 않네요. 선배님께서 수업을 들으셨을때는 어떻게 하셨습니까? 그리고, 보다 능동적으로 재밌게 공부할 방법이 없을까요?"
• 코드레이스/2007/RUR_PLE . . . . 3 matches
        * while문을 사용하여 중복된 씨앗의 개수가 2 이상인 임의의 개수일 경우에도 처리 가능하게 위 소스를 수정한다.
        * 아래는 간단하게 2개의 column의 경우 정렬한 모습이다.
        * 아래 그림과 같이 원래 정렬되어 있는 경우에도 제대로 작동되는지 테스트 해본다.
• 콤비반장의메모 . . . . 3 matches
        * 사용자가 한번 플레이 했다는 걸 네트워크로 확인해 보는 법 밖이 없나요? 씨리얼 키나 MD5키 같은 걸 사용해서~
        ''사용자가 한번 플레이 했다는 걸 미디어에 직접 기록하는 방법으로는 디지털 워터마킹이 있습니다. 이 방법은 네트워킹 없이도 문제를 해결할 수 있는 방법입니다만 전문적 지식이 필요합니다. 네트워크로 확인하는 가장 쉬운 방법은 클라이언트는 재생시 마다 서버에서 인증을 받고, 서버측에서는 미디어의 아이디를 확인하고 재생횟수를 저장하는 방법이 아닐까 싶습니다. 미디어의 아이디 생성은 MD5 같은 해쉬함수 정도면 충분 할것 같습니다. --["데기"]''
• 프로그래머가알아야할97가지/ActWithPrudence . . . . 3 matches
       이터레이션 초반에 스케줄이 아무리 여유로워 보인다고 해도, 시간 압박을 다소 받는 건 어쩔 수 없다. “제대로 하기”와 “빨리 하기” 중 선택해야 할 경우, 나중에 다시 돌아와서 고칠 수 있다는 전제하에 “빨리 하기”를 선택하고 싶어지기도 한다. 스스로에게나 팀에게 또는 고객에게 이런 약속을 할 때에는 정말로 나중에 고치겠다는 뜻이다. 그러나 십중팔구 다음 이터레이션에서 새로운 문제가 나타나서 거기에 집중하게 되곤 한다. 이렇게 연기된 작업은 기술적 부채(Technical Debt)라고 알려져 있으며 이런 일에 익숙해져서는 안 된다. 특별히, 마틴 파울러(Martin Fowler)는 그의 기술적 부채 분류 체계에서 이를 의도하지 않은 기술적 부채와 헷갈려서는 안 되는 계획적인 기술적 부채라고 부른다.
       기술적 부채는 대출과 마찬가지다. 그로 인해 단기적인 이익을 얻지만, 전액을 상환하기 전까지는 이자를 지불해야 한다. 이런 코드 내 지름길 때문에 기능을 추가하거나 코드를 구조조정하기 어려워진다. 이런 지름길은 결함과 안정적이지 못한 테스트 케이스가 자라는 밑거름이 된다. 이를 오래 방치하면 방치할수록 더 나빠진다. 수정을 하려고 할 때 즈음이면 코드를 구조조정하고 수정하기 훨씬 어렵게 만드는 그다지 좋지 않은 설계가 애초의 문제 위에 켜켜이 쌓여 있을 수 있다. 사실상, 다시 돌아가서 고쳐야 할 때는 일이 너무 심각해져서 반드시 고쳐야 할 때뿐이다. 그 때엔 일정이나 위험을 감당할 수 없어 고치기 어려운 경우가 다반사이다.
       데드라인을 맞춘다거나 기능의 단편을 구현하려고 기술적 부채를 발생시켜야 할 때가 있다. 이런 입장이 되지 않도록 애써야 하지만, 이런 상황이 반드시 필요하다면 그렇게 하되, 다만 반드시 기술적 부채를 추적해서 재빨리 갚아서 급히 끌어내려야 한다. 그렇게 타협하기로 결정하자마자, 이슈 추적 시스템에 과업 카드나 로그를 작성해서 잊어버리지 않도록 해야 한다.
• 혀뉘 . . . . 3 matches
       당신은 사람을 선택하는데에도 신중하며, 왠만한 일로는 마음이 흔들리지 않을 것입니다.
        그러면 어떤 일이 일어난다 해도 넌 마음의 평화를 잃지 않을 것이다.
        그냥 생각인데, 10여년 후에는 베트남에 대한 보상 문제로 사회가 또한번 발칵 뒤집히지 않을까 싶어.
• 1002/TPOCP . . . . 2 matches
        try & error 식으로 접근. 프로그래밍전 미리 생각하거나 머릿속으로 그려보지 않음
        A - 문제발생시 접근방법을 바꾸기 싫어함.(성능을 희생해야 할것이라 생각해버림)
        * 아무도 도큐먼트 작업을 하려고 하지 않을 것이다.
• 1thPCinCAUCSE/ExtremePair전략 . . . . 2 matches
        * 이때 여러 문제를 동시에 푸는 게(예: 2명이서 2개의 문제를 동시에 푸는 것) 아니라 한 문제에 대해서만 생각했습니다. 왜냐하면 예를 들어 문제 1번을 생각하는 데 A가 12분 B가 8분이 걸리고 문제 2번을 생각하는데 A가 10분 B가 15분이 걸렸다고 하면 한문제를 둘이 동시에 풀면 8 + 10... 총 18분이 걸렸을 것을 문제를 각각 나누어 풀면 최악의 경우 A가 1번 B가 2번으로 나누어 풀면 12 + 15... 총 27분까지 시간이 걸리기 때문입니다. (대회 규칙상 컴퓨터는 각 팀당 무조건 1대입니다)
        * ["TestDrivenDevelopment"]를 사용했다고 말하기는 그렇지만 테스트 케이스를 입력으로 넣어놓고 프로그래밍 중간 중간에 제대로 돌아가는 지를 확인하기 위해 지금까지의 진행 상황을 출력했습니다.
• 2학기파이선스터디/문자열 . . . . 2 matches
        * 작은 따옴표 혹은 큰 따옴표를 세개 연속 사용해서 정의하는 경우 쓰는 그대로 정의됨.
       valueError : substring not found in string.index
• 3DAlca . . . . 2 matches
        * 판이 가운데로 왔을때 카메라도 가운데로 와야 하지 않을까 한다.
        * 약간 치우쳤을 경우 판 움직이는 것보다 좀더 빨리 움직여서 리커버를 해야 한다?
• 3N+1Problem/황재선 . . . . 2 matches
       입력은 0과 1000000 사이의 값을 갖는 한 쌍의 정수이다. 1과 999999를 입력한 경우 몇 초 이내에 답이 나올까. Python으로 4초 이내를 목표로 구현했다. 하지만 만족할 만한 결과가 나오지 않았다. 안타깝게도 더이상 최적화할 묘안이 떠오르지 않는다 -- 재선
       http://bioinfo.sarang.net/wiki/AlgorithmQuiz_2f3Plus1 에서 yong27님의 소스코드를 보았다. 소스가 정말 깔끔했다. 실행속도가 빨라서 그 원인을 분석해가며 지난번 작성했던 코드를 수정했다. 나의 목적은 0.001초라도 빠르게 결과를 출력하는 것이었다. 실행시간을 최소화하기위해 클래스마저 없앴다. 특히 두 부분을 수정하니 실행시간이 현저히 줄었다. 하나는 클래스 멤버변수를 제거하고 지역변수화한 경우인데 왜 그런지 모르겠다. 둘째는 사전형 타입인 cycleDic 에서 key를 문자열에서 숫자로 바꾼 부분이었다. 지난번 구현시 무엇때문에 수치형을 문자열로 변환하여 key로 만들었는지 모르겠다. -- 재선
• APlusProject/PMPL . . . . 2 matches
       Upload:APP_Sequence0606.zip -- EF경우는 객체가 둘 씩 필요한데 표기방법을 잘 몰라서 어떻게 해야할지?
       오케이. 기본 설계서 확인 끝. 병권이 형이 마무리만 하고 끝내면 됨. --재동
• C++Study_2003 . . . . 2 matches
        * 나쁘지 않을 것같네. 나는 마음먹은 대로 프로그래밍을 짤 수 있도록, 후반부의 문법을 가르쳐 주었으면 좋겠다는 생각을 했는데. --[선호]
        - 다음주(7/14 이후부터) 시작하지 않을까 생각합니다. --[선호]
• Chapter I - Sample Code . . . . 2 matches
        인스톨하는 방법인데 별 필요 없을듯.. 우리가 직접 uCOS-II 를 설치하진 않을꺼니까.. 차라리 소스를 구해다가 컴파일을 하면 몰라도.
        OS 를 작성하다보면 전역변수가 필요한 경우가 있다. 전역변수는 어떻게 선언하는가? extern 키워드를 사용하면 된다. 하지만 uCOS-II 에서는 extern 키워드마저 #define 해서 다른 매크로로 사용한다.
• ComputerNetworkClass/Exam2004_1 . . . . 2 matches
       다음 그림은 Y 라우터의 경우 포트 3으로 X 라우터와 연결되어있는 상태이며 X 라우터는 CIDR 로 ____.____.___.____ 에 대해 Network A 로, ____,____,___,____ 에 대해 Network B 로 라우팅 한다.
       UDP 가 TCP 보다 장점을 가지는 경우를 쓰고, UDP 에 알맞는 어플리케이션에 대해 2개의 예를 들어라.
• ComputerNetworkClass/Report2006/BuildingProxyServer . . . . 2 matches
       [http://www.naturesharmony.us/misc/WoW/WoWEmu_Help/wsaerrors.html WSA Error Code]
       [http://www.elbiah.de/hamster/doc/ref/errwinsock.htm Winsock Error Code]
• Counting . . . . 2 matches
       구스타보는 합이 n인 수를 몇 개 만들 수 있는지 알고 싶어한다. n = 2 일 경우에는 11,14,41,44,2 이렇게 다섯 개의 숫자를 만들 수 있다 (5 이상의 수도 셀 수는 있다. 다만 쓰지 못할 뿐이다). 하지만 2보다 큰 경우에 대해서는 그가 만들 수 있는 수의 개수를 알 수가 없어서 여러분에게 도움을 청했다.
• DataStructure/Tree . . . . 2 matches
        * x의 Child가 1개 있을 경우 - 그 노드 지우고 그 자식들을 다 위로 올린다. 고로 할아버지의 자식이 된다는 것이다.(뭔가 좀 이상?--;)
        * x의 Child가 2개 있을 경우 - 그 노드의 Left Subtree에서 가장 큰 값을 찾는다. 이값을 y라고 하면 y는 오른쪽 Child가 없다. y를 x자리에 갖다 놓고 여기서 다시
• EightQueenProblem2Discussion . . . . 2 matches
       이미 알고리즘 수업 시간을 통해 생각해본 문제이기에 주저없이 백트래킹(BackTracking) 기법을 선택해서 슈도코드를 종이에 작성해보았고 그를 바탕으로 구현에 들어갔습니다.(''그냥 호기심에서 질문 하나. 알고리즘 수업에서 백트래킹을 배웠나요? 최근에는 대부분 AI쪽으로 끄집어 내서 가르치는 것이 추세입니다만... 교재가 무엇이었나요? --김창준 Foundations of Algorithms Using C++ Pseudocode, Second Edition 이었습니다. ISBN:0763706205 --이덕준'') 백트래킹은 BruteForce식 알고리즘으로 확장하기에 용이해서 수정엔 그리 많은 시간이 걸리지 않았습니다. 만일 EightQueenProblem에 대한 사전 지식이 없었다면 두번째 과제에서 무척 당황했을것 같습니다. 이번 기회에 코드의 적응도도 중요함을 새삼 확인했습니다. --이덕준
       어제 서점에서 ''Foundations of Algorithms Using C++ Pseudocode''를 봤습니다. 알고리즘 수업 시간에 백트래킹과 EightQueenProblem 문제를 교재를 통해 공부한 사람에게 이 활동은 소기의 효과가 거의 없겠더군요. 그럴 정도일줄은 정말 몰랐습니다. 대충 "이런 문제가 있다" 정도로만 언급되어 있을 주 알았는데... 어느 교재에도 구체적 "해답"이 나와있지 않을, ICPC(ACM의 세계 대학생 프로그래밍 경진대회) 문제 같은 것으로 할 걸 그랬나 봅니다. --김창준
• FoundationOfUNIX . . . . 2 matches
        * ps (process state 프로세스 상태 확인하기)
        * -i (yes, no 묻는거.. 만약 rm -i ex.txt 했을경우 지울것인가 묻게 만드는것..)
• FromDuskTillDawn/조현태 . . . . 2 matches
        //// 가장 시간이 낮은 경우에 대해서 연산을 수행합니다. ////
        //// 가장 시간이 낮은 경우를 제일 앞으로 둡니다. ////
• Gof/Facade . . . . 2 matches
       이 구현에서는 사용하려는 code-generator의 형태에 대해서 hard-codes (직접 특정형태 부분을 추상화시키지 않고 바로 입력)를 했다. 그렇게 함으로서 프로그래머는 목적이 되는 아키텍처로 구체화시키도록 요구받지 않는다. 만일 목적이 되는 아키텍처가 단 하나라면 그것은 아마 이성적인 판단일 것이다. 만일 그러한 경우가 아니라면 우리는 Compiler 의 constructor 에 CodeGenerator 를 인자로 추가하기 원할 것이다. 그러면 프로그래머는 Compiler를 instance화 할때 사용할 generator를 구체화할 수 있다. Compiler facade는 또한 Scanner나 ProgramNodeBuilder 등의 다른 협동하는 서브시스템클래스를 인자화할 수 있다. 그것은 유연성을 증가시키지만, 또한 일반적인 사용형태에 대해 인터페이스의 단순함을 제공하는 Facade pattern의 의의를 떨어뜨린다.
       ET++ application은 또한 built-in browsing support를 없앨수도 있다. 이러한 경우 ProgrammingEnvironment는 이 요청에 대해 null-operation으로서 구현한다. 그러한 null-operation는 아무 일도 하지 않는다. 단지 ETProgrammingEnvironment subclass는 각각 대응하는 browser에 표시해주는 operation을 가지고 이러한 요청을 구현한다. application은 browsing environment가 존재하던지 그렇지 않던지에 대한 정보를 가지고 있지 않다. application 과 browsing 서브시스템 사이에는 추상적인 결합관계가 있다.
• HardcoreCppStudy/두번째숙제/CharacteristicOfOOP/김아영 . . . . 2 matches
       데이터 은닉이란 모듈이 그것이 갖는 기능들을 명세한 인터페이스(interface)를 통해서만 접근되고, 그 기능을 구현하는 방법은 다른 모듈로부터 은닉되도록 하는 것을 말한다. 캡슐화된 객체의 외부 인터페이스를 엄밀히 정의함으로써 독립적으로 작성된 모듈간의 상호 종속성을 극소화하여 캡슐화된 객체는 외부 인터페이스만을 통하여 접근될 수 있도록 한다면, 세부적인 구현 상세 사항에 대해서는 객체내에 은닉시킬 수 있다. 또한 캡슐화된 객체는 객체 구현내역을 변경, 혹은 향상시킬 때 이 객체를 사용하는 타 객체들을 변경하거나 다시 컴파일하지 않도록 할 수 있다. 또 모듈의 내부 구현 사항들이 외부의 접근으로부터 보호될 수 있음으로, 그 객체의 정당성을 보증할 수 있으며, 오류가 발생되었을 경우에 오류는 한 모듈내로 국지화될 수 있다.
       우리가 흔히 다루는 각각의 객체들은 서로의 관련되 영역을 사용할 수 있는 부분과 없는 부분이 있다. 이것은 별도로 접근이 가능한 영역과 불가능한 영역으로 나누어서 관리하기 때문이다. 이것을 바로 캡슐화라 한다. 갭슐화는 바로 접근 가능한 코드와 불가능한 코드로 나눔으로 인해서 데이터나 특별한 영역을 보호하거나 감추는 역활을 할 수 있다. 때문에 필요한 경우 데이터의 접근 필드를 제한함으로서 데이터를 보호하는 결과를 얻을 수 있다.
• HelpForDevelopers . . . . 2 matches
       모니위키 사용중에 문제점이 발생하는 경우에는 지체없이 http://kldp.net/projects/moniwiki/bugs 사이트에서 문제점을 보고해주시기 바랍니다. 혹은 사용중에 불편한 점이 있다고 생각하셔도 보고해 주시면 고맙겠습니다.
       개발자는 사용자가 불편하게 생각하는 부분을 잘 모르는 경우가 많습니다. 사용자의 피드백은 모니위키를 좀 더 사용하기 편리하게 만들어 줄 가능성을 열어줍니다!
• HelpOnInstallation/MultipleUser . . . . 2 matches
       이 경우 대부분의 php파일이 설치되지 않은채로 각 사용자가 사용하게 되기 때문에, 모니위키의 php취약점이 발견되었을 경우 관리자가 설치된 [모니위키]만을 업데이트하는 것으로 문제점을 해결할 수 있게 됩니다. 물론 일부 카피된 파일 및 php 이외에 웹상에 직접 노출되는 지역 파일은 사용자가 직접 업데이트해야 하겠지요.
• Hessian . . . . 2 matches
       Resin 을 이용하는 경우라면 Hessian 이용해서 간단하게 RPC 를 구현할 수 있다.
       Java 의 경우는 다음과 같다. 위에서 정의한 interface 인 Basic 이 있어야 한다.
• HowBigIsIt? . . . . 2 matches
       각 테스트 케이스에 대해 원들을 모두 포장할 수 있는 가장 작은 직사각형 상자의 크기를 출력한다. 각 케이스에 대한 결과가 서로 다른 줄에 출력되어야 하며, 소수점 아래로 셋째 자리까지 출력한다. 숫자가 1보다 작지 않은 경우에는 앞에 불필요한 0을 덧붙이지 않는다(1 미만인 경우에는 0.543 같은 식으로 앞에 0을 하나 붙여준다).
• HowToStudyDataStructureAndAlgorithms . . . . 2 matches
       제가 생각컨데, 교육적인 목적에서는, 자료구조나 알고리즘을 처음 공부할 때는 우선은 특정 언어로 구현된 것을 보지 않는 것이 좋은 경우가 많습니다 -- 대신 pseudo-code 등으로 그 개념까지만 이해하는 것이죠. 그 아이디어를 Procedural(C, 어셈블리어)이나 Functional(LISP,Scheme,Haskel), OOP(Java,Smalltalk) 언어 등으로 직접 구현해 보는 겁니다. 이 다음에는 다른 사람(책)의 코드와 비교를 합니다. 이 경험을 애초에 박탈 당한 사람은 귀중한 배움과 깨달음의 기회를 잃은 셈입니다. 참고로 알고리즘 교재로는 10년에 한 번 나올까 말까한 CLR(''Introduction to Algorithms, Thomas H. Cormen, Charles E. Leiserson, and Ronald L. Rivest'')을 적극 추천합니다(이와 함께 혹은 이전에 Jon Bentley의 ''Programming Pearls''도 강력 추천합니다. 전세계의 짱짱한 프로그래머/전산학자들이 함께 꼽은 "위대한 책" 리스트에서 몇 손가락 안에 드는 책입니다. 아마 우리 학교 도서관에 있을 것인데, 아직 이 책을 본 적 없는 사람은 축하드립니다. 아마 몇 주 간은 감동 속에 하루하루를 보내게 될 겁니다.). 만약 함께 스터디를 한다면, 각자 동일한 아이디어를 (같은 언어로 혹은 다른 언어로) 어떻게 다르게 표현했는지를 서로 비교해 보면 또 배우는 것이 매우 많습니다. 우리가 자료구조나 알고리즘을 공부하는 이유는, 특정 "실세계의 문제"를 어떠한 "수학적 아이디어"로 매핑을 시켜서 해결하는 것이 가능하고 또 효율적이고, 또 이를 컴퓨터에 어떻게 구현하는 것이 가능하고 효율적인지를 따지기 위해서이며, 이 과정에 있어 수학적 개념을 프로그래밍 언어로 표현해 내는 것은 아주 중요한 능력이 됩니다. 개별 알고리즘의 카탈로그를 이해, 암기하며 익히는 것도 중요하지만 더 중요한 것은 알고리즘을 생각해 낼 수 있는 능력과 이 알고리즘의 효율을 비교할 수 있는 능력, 그리고 이를 표현할 수 있는 능력입니다.
       첫번째가 제대로 훈련되지 못한 사람은 알고리즘 목록의 스테레오 타입에만 길들여져 있어서 모든 문제를 자신이 가진 알고리즘 목록에 끼워맞추려고 합니다. DesignPatterns를 잘 못 공부한 사람과 비슷합니다. 이 사람들은 마치 과거 수학 정석을 수십번을 공부해서 문제를 하나 던져주기만 하면, 생각해보지도 않고 자신이 풀었던 문제들의 패턴 중 가장 비슷한 것 하나를 기계적, 무의식적으로 풀어제끼는 "문제풀이기계"와 비슷합니다. 그들에게 도중에 물어보십시오. "너 지금 무슨 문제 풀고있는거니?" 열심히 연습장에 뭔가 풀어나가고는 있지만 그들은 자신이 뭘 풀고있는지도 잘 인식하지 못하는 경우가 많습니다. 머리가 푸는 게 아니고 손이 푸는 것이죠.
• IDL . . . . 2 matches
       [CORBA] 의 경우 분산된 네트워크상에 따로 위치한 객체 간의 투명한 접근을 제공하는 서로 간의 약속이 필요하다. 이런 약속을 정의할 때 특정 언어([C], [C++], [Java] 등)에 의존하지 않는 인터페이스 정의 언어가 필요하게 되었는데, 그것이 바로 IDL(Interface Definition Language)이다. 서버와 클라이언트가 서로 통신을 하기 위해서 서버는 클라이언트에게 제공하는 서비스 인터페이스를 IDL 로 정의하게 되며, 클라이언트는 이런 인터페이스 정보를 활용하여 서비스를 활용하게 되는 것이다. CORBA 프로그램을 개발하기 위해서는 가장 먼저 IDL 을 정의해야 하는데, IDL 은 구현에 대한 정보는 포함하고 있지 않아 정의된 IDL 을 원하는 언어로
       물론, 인터페이스를 정의하는 방법이 IDL 만 있는 것은 아니다. [Visibroker] 의 경우 [Caffeine] 이라는 것을 이용하면 IDL 을 사용하지 않아도 되며, Java 의 RMI 나 RMI-IIOP 를 이용해면 IDL 을 몰라도 인터페이스를 정의할 수 있다. 하지만, IDL 은 OMG에서 규정하고 있는 인터페이스 정의 언어의 표준이고 개발자가 익히기에 어렵지 않은 만큼 CORBA 프로그램을 할 때는 꼭 IDL 을 사용하도록 하자.
• Linux . . . . 2 matches
       리눅스는 현재 컴퓨터의 커다란 흐름중의 하나이다. FSF에 의해서 지원을 받는 핵심적인 운영체제로 현재 기능적, 보안적 측면이 기존의 [Unix] 시스템에 버금갈 정도 발전하였고 [GNU]의 사상하에 만들어진 [GPL]을 따르기 때문에 무료로 사용이 가능하여 서버 운영체제로 많은 인기를 누리고 있다. 본디 리눅스라는 하는 것은 운영체제의 [Kernel] 명칭이며, 주로 접하게 되는 패키지 형태로 이루어진 배포판의 전체 구성을 리눅스라고 여기는 경우가 있으나 이는 리눅스의 광의적 정의라고 생각하면 될듯 싶다.
       리눅스와 비슷한 운영체제로는 정통적인 유닉스 클론 이라고 평가받는 [:FreeBSD BSD]계열이 있다. BSD계열중 가장 잘알려진 [http://www.kr.freebsd.org FreeBSD]의 경우 실제로 과거부터 hotmail.com, yahoo.com, cdrom.com 을 운영해온 네트워킹에 대한 안정성이 입증된 운영체제이다. 실제로 2.6커널의 도입이전에는 BSD의 네트워킹이 더욱 뛰어나다는 평가를 받았지만 일반적인 의견이었으나, 많은 구조적 변경을 통해서 리눅스는 현재 이런 점을 극복하고 BSD와 리눅스를 선택하는 것은 운영자의 기호일 뿐이라는 이야기를 한다. 최근에는 리눅스를 데스크탑의 용도로 까지 확장하려는 노력의 덕분에 로케일 설정관련 부분이 대폭 강화되었으며, 사용자 편의성을 고려한 WindowManager인 [Gnome], [KDE] 등의 프로그램이 대폭 강화되면서 low-level 유저라도 약간의 관심만 기울인다면 충분히 서버로써 쓸 만한 운영체제로 변모하였다.
• LinuxSystemClass . . . . 2 matches
       개인적으로 교재가 마음에 든다. 단, 제대로 공부할 것이라면 가능한 한 원서를 권한다. 한서의 경우 용어의 혼동문제와, 중간 오역문제가 눈에 띈다. (inexpensive를 expensive 로 정 반대의 뜻으로 해석한) 뭐, 물론 그럼에도 불구하고 아마 사람들은 한서 읽는 속도가 원서 읽는 속도의 3배 이상은 될테니. 알아서 잘.
       학교 수업공부를 하거나 레포트를 쓰는 경우 위의 학교 교재와 함께 'The Design of the Unix Operating System' 을 같이 보면 도움이 많이 된다. 해당 알고리즘들에 대해서 좀 더 구체적으로 서술되어있다. 단, 책이 좀 오래된 감이 있다.
• ModelingSimulationClass_Exam2006_1 . . . . 2 matches
       (a) 해당 모델을 구성하고 필요할 경우 가정을 해도 좋다. (7 points)
       1) 나의 경우 해당 문제를 간단한 확률 모델 + Single Queue, Multi Server 의 문제로 파악했다. 확률모델은 1차 합격자를 가리는데 쓰이고, SQMS모델은 실기 시험을 가리는데 사용하고, 가정으로 실기 시험은 7분을 최고 점으로갖는 Triangle Distribution 이라고 가정하고 풀이했음.
• NSIS/예제2 . . . . 2 matches
       ; (만일 인스톨을 다시 할경우
       ; (만일 인스톨을 다시 할경우
• NumberBaseballGame . . . . 2 matches
       조금 더 문제 정의를 명확히 할 필요가 있지 않을까 합니다. (여기에 올라온 몇 개의 코드들을 살펴볼 때 명확한 스펙이 잘 전달되지 않은듯 합니다)
       만약 그렇다면, 다음의 경우에 스트라이크와 볼은 각각 얼마인가요? 혹은 어떤 에러 메시지를 출력하나요?
• Polynomial . . . . 2 matches
        이 방법을 사용할때 발생할수 있는 문제점은 memory leakage (메모리 누수)이다. Java같은 경우는 쓰레기 수집기가 있지만 c 는 코더(-_-)가 일일이 사용되지 않는 자원을 회수해줘야 한다. 그렇지 않으면 그 자원을 다시 사용할 수 없게 된다.
        /* 문제점 : 다음과 같은 경우는 어떻게 처리해야 할까?
• Postech/QualityEntranceExam06 . . . . 2 matches
        - 어떤 경우에 counting semaphore 를 쓰는지,,
       Dynamic Scoping 에서 Shallow Access 하는 경우에 상관 없는 키워드 발견하기.
• PowerOfCryptography/이영호 . . . . 2 matches
        if(ret_buf >= (ceil(ret_buf)+floor(ret_buf))/2) // 반올림. 올림+내림/2보다 클거나 같을 경우
        ret = (int)ret_buf; // 내림일경우 여기서 저절로 내린다.
• PowerOfCryptography/조현태 . . . . 2 matches
        두번째 소스.. 숫자가 커도 저장하고 연산할 수 있을...듯 하다..;;ㅁ;; ㅎㅎㅎ MAX_LONG의 값을 10으로 줄이고 테스트를 해서 2개 이상의 경우에도 돌아가는 것은 알겠는데... 3번째 4번째 예제의 수가 원체 커야지 말이다. 연산의 결과가 좀처럼 안나온다. 곱하기 루틴에서 계속 더하고 있는듯..;;ㅁ;;
        cout << "결과값에 1을 입력할경우 프로그램이 끝납니다.\n";
• ProjectAR/CollisionCheck . . . . 2 matches
        * 그러자니 오브젝트마다 그림 크기에 맞는 2차원 배열을 가져야 한다. 어쩌면 비트맵을 읽어오면서, 그 비트맵이 메모리에 있을테니, 그걸 참조하는 방법도 있을듯 하다. 안된다 하더라도, 요즘 컴퓨터 메모리 남아도니까 별로 문제가 되지는 않을듯 싶다.
        일단 히트 판정이 날려면 주인공이 공격을 하게 됩니다. 그 때 발생하는 무기의 범위는 부채꼴이 되겠죠? 그렇게 때문에 오브젝트가 주인공의 위치와 무기의 거리사이에(각도는 제한된 상태) 들어온다면 히트 판정이 나게 되겠죠? 그러므로 정교한 히트 판정이 나기 위해서는 사각형 영역보다 부채꼴 형태가 더 적합하다고 생각합니다. 그리고 적의 충돌을 판정하기 위해서는 적은 최대한 둥근 모습으로 만든다면 해결이 어느정도 가능하다고 생각합니다. 둥그스름한 물체가 땅에 닿는 곳은 원형이 되겠죠? 그 원형을 판단하면 되지 않을까요? 어짜피 그려지는 곳의 머리가 주인공의 무기와 겹치는 동시에 친다면 더 부자연스러울꺼 같네요...
• QuestionsAboutMultiProcessAndThread . . . . 2 matches
        * 그럼 여러 개의 Thread가 존재하는 상황일 때, 하나의 Thread가 One Time Slice를 전부 사용하는 경우가 있는가??
        * 어느 바쁜 음식점(machine)입니다. 두 명의 요리사(processor)가 있는데, 주문이 밀려서 5개의 요리(process)를 동시에 하고 있습니다. 그 중 어떤 한 요리는 소스를 끓이면서(thread) 동시에 양념도 다지고(thread), 재료들을 오븐에 굽는데(thread) 요리를 빠르게 완성하기 위해 이 모든 것을 동시에 합니다. 한 명의 요리사는 특정시점에 단 한 가지 행위(instruction)만 할 수 있으므로, 양념을 다지다가 (context switching) 소스가 잘 끓도록 저어주기도 하고 (context switching) 다시 양념을 다지다가 (context switching) 같이 하던 다른 요리를 확인하다가, 오븐에 타이머가 울리면(interrupt) 구워진 재료를 꺼내어 요리합니다. 물론 두 명의 요리사는 같은 시점에 각자가 물리적으로 서로 다른 행위를 할 수 있으며, 하나의 요리를 두 요리사가 나눠서(parallel program) 동시에 할 수도 있습니다. - [변형진]
• Randomwalk/조동영 . . . . 2 matches
        bool existZero = false; // 바퀴벌레가 모두 돌아다녔는지 확인할때 쓰일 bool형 값
        편하기야 하겠지만 남발하는건 좋지 않음. 특히 자료구조 숙제같은 경우에는 :( - [임인택]
• Self-describingSequence/1002 . . . . 2 matches
       문제는, 1000000000 의 경우에 대해서 답이 나오는 시간이 엄청나게 걸린다는 점이다. 이에 대해서 어떻게 할 것인가 고민,
       수열의 값이 늘 증가한다 할때 다음번에 검색하는 경우 앞에서 검색했던 그룹 아니면 그 다음 그룹임을 생각하게 됨.
• SeminarHowToProgramIt/Pipe/VendingMachineParser.py . . . . 2 matches
        raise NotImplementedError
        except ValueError:
        self.outstream.write(self.lexer.error_leader()+msg+'\n')
• SmalltalkBestPracticePatterns/DispatchedInterpretation . . . . 2 matches
       때때로, 그러나, 한 객체의 정보는 다른 객체의 행위에 영향을 미칠 것이다. 정보의 사용이 단순할 경우, 또는 제한된 정보에 기반해서 선택이 가능할 경우에는 인코딩된 객체에게 메시지를 보내는 것이 충분히 가능하다. 이와 같이, 부울린 값들은 두 클래스의 하나의 인스턴스로 표현되어진다는 사실은, True 그리고 False, 메시지 #ifTrue: ifFalse:. 뒤로 숨겨진다
• Telephone . . . . 2 matches
       미국에서는 이발소 TV 광고의 경우 전화번호와 동시에 'HAIRCUT' 이라는 문구를 보여준다. 'HAIRCUT' 은 전화기의 번호의 각 영문에 대응되기 때문에 전화번호로 번역이 가능하다.
       즉, 'HAIRCUT' 의 경우 밑의 전화기 자판을 보면 H 는 4, A 는 2 ... 등에 각각 대응되므로 424-7288 이 된다.
• TestDrivenDevelopmentBetweenTeams . . . . 2 matches
       일단 각 팀들끼리 TDD 를 하면서 팀들간의 대화를 통해서 일종의 공통 interface 를 빼낼 수 있다. 일단은 일종의 MockObject 로 가짜값을 채워서 테스트를 통과시킨뒤, 실제 Object 가 구현되면, 천천히 하나씩 실제 Object 의 interface 를 끼워가면서 테스트를 통과하는지를 확인한다. 그리고 최종적으로 실제 Object 로 MockObject 를 대체시킨다.
       Java 의 경우 inteface 키워드나 abstact class 를 이용하여 interface 를 정의할 수 있다. 팀의 구성원끼리 Pair를 교체한 뒤 interface를 정의하면 더욱 효과적이겠다.
• TkinterProgramming/Calculator2 . . . . 2 matches
        except SyntaxError:
        return 'Error'
• UniversalsAndParticulars . . . . 2 matches
       자바 스윙에서 어떤 API를 통해 어떻게 그림을 그리는지를 가르치기 보다, Event Driven Programming을 가르치되, 스윙이라는 맥락을 방편으로 이용해 가르친다. 해당 프레임웍의 API가 복잡한 경우, 학습자들은 오히려 그 API를 외우고 공부하느라 더 중요한 것을 잊을 수 있다. 따라서 이런 경우 가르치는 사람이 미리 좀 더 추상적인 차원의 레이어를 만들어(이를 교육학에선 스캐폴딩이라 한다) 제공할 수 있다.
• callusedHand/books . . . . 2 matches
        프로그램에 치명적인 버그가 있을 때 책임지고 고쳐 줄 사람이 없기 때문에 오픈 소스 개발 방식은 위험하다는 주장도 오픈 소스 개발 방식에 대한 오해에서 비롯된 것이라고 생각합니다. 위에서 말했지만 오픈 소스 개발 방식은 수많은 소프트웨어 개발 방법 중 하나 일 뿐입니다. 기존의 많은 오픈 소스 프로젝트가 개발자들의 취미, 재미라는 동기에서 비롯되었기 때문에 사후 관리가 미미하고 개발자들이 개발을 포기하는 경우 엔드 유저는 피해를 볼 수 밖에 없었던 것입니다.
        요구 사항 분석, 시스템 디자인, 세부 디자인 과정이 구체적으로 진행되지 않거나 문서화가 이루어 지고 있지않는 점입니다. 이는 프로그램의 유지보수, 재사용 측면에서 볼 때 심각한 문제로 한 프로그램을 개선시키고자 하는 개발자가 있을 때 디자인에 관한 문서가 없으면 많은 시행 착오를 겪을 수 밖에 없으며. 좋은 코드들이 그냥 버려지게 되는 경우가 많아 집니다. 이것들은 분명히 낭비라고 볼 수 있습니다. 그러므로 문서화 할 필요가 있습니다.
• iruril/도자기토론 . . . . 2 matches
       부가적으로 붙어야 하지 않을까
       앞으로 도예문화가 더 발전하고 보편화 됬으면 좋겠다 라고 끝내도 되지않을가..
• ★강원길★ . . . . 2 matches
       어제같은 경우엔 ... 책 보려다 잠들었다니깐 ㅎㅎ
       일어나니 4시.. 그런 쉣한 경우가 ㅎㅎ 그냥 윤리며 C 며 깨끗하게 붙여넣어줬지 ^^
• 권영기/web crawler . . . . 2 matches
       except URLError, e:
        * os.mkdir(path[, mode]) - Create a directory named path with numeric mode mode. If the directory already exists, OSError is raised.
        http://stackoverflow.com/questions/8046667/vpython-error-on-ubuntu-11-10
• 날다람쥐 6월9일 . . . . 2 matches
       그리고 printf("%d", a); 라는 명령어를 통해 바뀐 것을 확인할 수 있다.
       하지만 포인터를 왜'쓰는지 잘 모르는 경우가 많다.-_-;
• 대학원준비에대한조언 . . . . 2 matches
       여러명이 모여서 스터디를 한 지도 삼 주가 다 되어간다. 같이 준비하면서 때로는 너무 사소한 것에 매달리는 것이 아닌가 싶을 정도로 한 부분에서 넘어가지 못하는 경우가 있다. 한참을 이야기해서 결론을 내보니 이미 말하던 도중에 나왔던 이야기였거나 책을 보면 알 수 있는 내용인 경우도 있다. 하지만 그렇게 해서도 결론이 나지 않는 문제들이 있었고 [대학원준비06] 팀은 교수님께 찾아가서 질문을 했다.
• 데블스캠프2004 . . . . 2 matches
        * 벌써 2004년도 DevilsCamp 를 시작할 때가 되었군요..^^; 하하.. 미안한 느낌만 드는건 왜일까요;; 뭐.. 그건 그렇다 치고 허접하지만 의견하나 내도 될련지... DevilsCamp는 참여하는 그 당시도 중요하지만 끝나고 나중에 "아. 그 때는 이렇게 했었지."라는 생각을 하면서 전의 내용을 확인하는 것도 중요하다고 생각합니다. 그렇기 위해서 필요한게 다시 한번 돌아보는 일입니다. 그 주제가 끝났다고 그냥 지나가는 것이 아니라는 거죠. 뭔가 부족한 것은 다시 한번 확인해서 고쳐도 보고 다르게도 만들어보고 또 다른 사람들과 비교도 하는 과정이 그대로 위키에 체계적으로 정리가 될 때 나중에 더 큰 재산이 된다는 것입니다.^^; 이상 허접한 의견이었습니다. 많은 테클 부탁드립니다.(답변은 못올림;;) -[상욱]
• 데블스캠프2009/화요일후기 . . . . 2 matches
        * '''강소현''' - API가 뭔지, 그걸로 어떠어떠한 프로그램을 만들 수 있는 지 알게된 수업이었어요. 왠지 마지막 피아노...최종귀축 여동생 플랑도르 같은 거도 연주하게 할 수 있지 않을까하는 느낌이 ㅇㅁㅇ(!) 직접 연주하는 프로그램인 거같긴 했지만ㅋㅋ;;
        * [송지원] - 학우들이 OOP를 배우기 좀 더 좋지 않을까 싶다. 컴공에서 죽어라 부딪치며 삽질하고 어려워하는 개념에 대해 정말 쉽고 재밌게 설명해주는 형진이의 내공은 역시 최고인것 같다. 시간이 부족한게 아쉬운건 어쩔 수 없는듯.
• 데블스캠프2011/둘째날/후기 . . . . 2 matches
        * Hacking != Cracking. Cheat Engine, 자바스크립트를 이용한 사이트 공격? 툴을 이용한 Packet Cracking 등 개인적으로 무척 재미있던 세미나였습니다. 뭐... 사실 많이들 관심은 있지만 실제로 하는 걸 보는 건 흔치 않은 만큼 이번에 세미나를 볼 수 있었던 것은 여러모로 행운이었다고 생각합니다. 더군다나 질문을 꽤 많이 했는데 선배님이 친절하게 답변을 해 주셔서 정말 감사했습니다. 웹 쪽은 이래저래 공격을 당할 가능성도 높은 만큼 나중에 그쪽으로 가게 된다면 관련 기술들도 배워둬야 하지 않을까 싶군요.
        * 코드도 올려야하는데 이거 원 안좋아서 망설여지네요. hashmap으로 다시 짠 걸 올립니다. 식을 잘못 계산했더니 천단위의 양수가 나와버리는 경우가 있었습니다. 어익후 확률계산식을 잘못 줄였었네요.. 이런 순수 알고리즘 재미있군요ㅋㅋ
• 몸짱프로젝트/BinarySearchTree . . . . 2 matches
        cout << "Error" << endl;
        cout << "Error" << endl;
• 블로그2007 . . . . 2 matches
        *새벽에 책 보다가 불연득 떠오른 생각이 있어서 그대로 해보니까 잘 되는거 같아요~ㅋㅋㅋ[[BR]] 수생이형 신경써줘서 고마워요~ㅎ[[BR]]아 그리고 이클립스 쓰니까 저장만 하면 내장 브라우져로 바로바로 확인 가능해서[[BR]]웹 브라우져 따로 안열어도 되고 참 편해요!! 다만 아직 잘 쓸줄 몰라서...ㅎ[[BR]]근데 정말 상협이형 말대로 더 편하긴 편하네요~ㅋㅋㅋㅋ 남박사님 감사요~ㅎ
       미래에는 PDT로 수렴되겠지만 아직은 정식 버전에 잘 결합이 되지 않을 만큼 불안합니다. 따라서 PHPEclipse를 추천하는데 Web개발을 위해서는 이뿐만이 아니라, HTML Coloring 지원 도구등 여러 도구들이 필요합니다. 귀찮은 작업입니다. Calisto가 나오기 전부터 Eclipse 도구를 분야별로 사용하기 쉽게 패키징 프로젝트가 등장했는데 [http://www.easyeclipse.org/ Easy Eclipse]가 가장 대표적인 곳입니다. 아직도 잘 유지보수되고 있고, Calisto가 수렴하지 못하는 Script 개발 환경 같은 것도 잘 패키징 되어 있습니다. [http://www.easyeclipse.org/site/distributions/index.html Easy Eclipse Distribution]에서 PHP개발 환경을 다운 받아서 쓰세요. more를 눌러서 무엇들이 같이 패키징 되었나 보세요.
• 상협/Diary/7월 . . . . 2 matches
        * 오늘은 별로 한게 없당... 오늘 기숙사에서 기분이 좀 나빠지는 일이 있었다. 그때는 막 화가 났는데, 조금만 다르게 생각하자 그렇게 나빴던 기분도 풀렸다. 역시 사람은 화를 내는것보다 웃는게 훨씬 나은거 같다.^^ 옛날에 어디서 그런 연구 결과를 본거 같다.(화를 내는 경우와 웃는 경우 신체적 호르몬 분비나 스트레스 해소나 축적 정도...) 화내는것은 자기만 손해이고 스트레스만 쌓이는거 같다. 차라리 상대편 사람에게 화난점을 말하거나 그러한 여건이 안되면, 그 사람의 입장을 이해해 보려고 노력해 보거나 그사람이 나한테 잘해줬던 일들이라도 생각해보던지 해야겠다. 그리고 사람이 한번 소심해지면 한없이 계속 소심해지는거 같다. 오늘 기숙사에서의 일도 여러가지 방향과, 여러 사람의 입장에서 다양하게 생각해보면 그렇게 기분 나쁠일은 아닌거 같다. 소심해 지지 말잣~
• 상협/Diary/9월 . . . . 2 matches
        * 장점 : 이 길을 선택하면 내가 노력을 많이 하게 된다. 학사 병특가는게 쉽지 않다고 하는 만큼 널럴하게 놀면서 지내지는 않을 테니깐.
        * 너무 심각하게 생각하지 말아야 겠다. 뭐 최악의 경우라고 해봤자 나이 엄청 먹어서 군대가서 젊은 얘들한테 욕먹는건데, 그정도를 못버티면 내 자질이 부족한거니깐.
• 새싹교실/2011/AmazingC/6일차 . . . . 2 matches
        * sum2의 경우 호출시 메인함수 위에 선언이 되어있나 확인한 다음 sum2의 정의부를 실행한다!!
• 새싹교실/2012/주먹밥 . . . . 2 matches
       ///typedef를 쓴경우
        * APM_SETUP폴더에 htdocs폴더에 index.html을 하기. http://www.w3schools.com/js/default.asp 가서 javascript예제 index.html에 작성하고 돌아가는것 확인.
• 새싹배움터05 . . . . 2 matches
       신입생들에게도 우리들에게도 좀더 많은것이 남을 수 있는 새싹 배움터가 될 수 있지 않을까요??[[HTML(</font></b>)]]
       7피의 프로젝터는 재학생이 이용할수 없습니다. 교수님만 이용할수 있다고 합니다. 피치못할경우 빌릴수는 있긴 합니다. - [톱아보다]
• 위키QnA . . . . 2 matches
        * 예외 경우
       Q: 어디에 글을 올려야 될지 고민하던 중 이곳에 글을 올립니다. 위키를 쓰다가 얼마전부터 느끼기 시작한 점인데요. 이것이 문제인지 아닌지는 잘 모르겠습니다. 위키의 Recent Changes를 통해 바뀐 글중 관심있는 글들을 봅니다. 변경되었다고 해서 글을 읽어보지만 쉽게 무엇이 변경되었는지 알아볼 수 없었습니다. 시간이 많이 흐른 뒤에나 읽어보게 되는게 아닌가 생각합니다. 아무튼 제가 느끼기에 제가 읽지 않은 부분을 쉽게 알 수 있으면 편하지 않을까 생각합니다. 이미 안다고 생각한 글을 다시 읽어도 많은 도움이 되겠지만... ^^; 세세한 변화는 눈치채기 힘든듯 합니다.--["Benghun"]
• 이병윤 . . . . 2 matches
        1 파싱결과를 통해 신청하고자 하는 과목의 여석이 존재하는지 확인한다.
        1 여석이 존재할경우 수강신청 페이지를 요청하여 신청한다.
• 정모/2002.7.11 . . . . 2 matches
        이선우가 알고 있기로 현재 zeropage.org 도메인은 ["구근"]이 가지고 있고, 도메인 이용료 또한 직접 내고 있는것으로 알고 있습니다. (이 이야기가 맞다면) 제로페이지는 개인에게 비용을 부담시키는 현재의 상황을 해결해주어야 합니다. 그리고, 도메인 또한 단체가 소유할 수 있는지는 모르겠군요(아는분?). 소유할 수 있다면, 차후 관리는 제로페이지에서 직접 하는게 좋지 않을까요?
       ''DeleteMe later: 천천히 제로페이지 회원들을 위한 컴퓨터 공부 로드맵(roadmap)을 하나씩 만들어 가면 어떨까요? 갑을 공부하려면 이걸 먼저 보고, 그 다음 이런 프로젝트들을 한번 씩 해보고, 어떤 기사를 보고 등등. 각 과목에 대해서 만들어도 좋고, 특정 기술에 대해서 만들어도 좋겠습니다. 가능하면 선배들이 각자 자신이 공부한 경험을 토대로 "공동 작성"하면 참 좋겠죠. 다만 한시적인 기술일 경우 "축적"의 가치가 별로 없이 해당 로드맵이 일이년 만에 쓸모없어 질 수도 있겠죠. --JuNe''[[BR]]
• 정모/2007.3.27 . . . . 2 matches
        - PC관리 비용이 나오지 않을 경우 우리 또한 PC실을 관리할 이유가 없다(학교에 맡겨버리자)
• 정모/2011.3.21 . . . . 2 matches
        * 현이의 이번 아이스 브레이킹은 새로운 시도였던 것 같았는데, 아쉽게도 처음이라 그런지 시행착오를 겪은 것 같았습니다. 다음 아이스 브레이킹때 이번에 아쉬웠던 점이 보안되면 더 재미있는 시간이 되지 않을까 생각합니다. 승한이 형의 Emacs & Elips 세미나를 듣고 나서는 한편으로는 저런 것을 써 보는 것도 괜찮을 것 같다라는 생각도 들었지만.. 아직은 지금 쓰고 있는거 부터 잘 다룰 줄 알고나서 접근하는 게 좋지 않을까라는 생각도 들었습니다. -_-;; 워낙 초보인 나 자신이 부끄럽기도 한 시간이었습니다. 쩝. 그 이후엔 일이 있어서 먼저 갔는데... 저.. 참가자에 제 이름이 없네요 -ㅅ-ㅋ (먼저 가서 그런가 ㅋ) - [권순의]
• 정모/2013.7.29 . . . . 2 matches
        * 일반적으로, 매 스터디 진행시에 다과를 구입해서 먹는 경우가 많기 때문이며, 1회에 한해서 전액을 사용하는 것이 효율적이지 못하다는 의견이 있기 때문
        * 제 입장에서는 중앙대 GDG와 ZeroPage는 분리를 했으면 좋겠네요. 현재 ZP만 봐도 다양한 혜택을 받고 있는 만큼 또한 다양한 책임을 지고 있다고 생각하는데, 여기에서 GDG까지 하게 되면 역시 추가적으로 해야 하는 일이 늘지 않을까 생각합니다. 사실 해야 하는 일이 느는 것 자체가 문제라기 보다는 나중에 정말로 하고 싶은 일이 생겼을 때 현재 지고 있는 짐(책임)이 무거워서 몸을 움직일 수 없다면 문제가 아닐까 하는 염려 때문이네요. - [서민관]
• 정모/2013.9.4 . . . . 2 matches
        * 해천 -> 1명만 가는 경우 지원은 당연히 안되는 것이고, 영기말처럼 하는게 더 맞는것같다.
        * 제가 할법한 잔소리는 이미 한종이가 위에서 했으니 제끼고 궁금한 게 있어서 이쪽에 붙습니다. 한명만 가는 경우 지원하지 말아야 할 당연한 이유가 있나요? 학술활동이 꼭 단체활동이어야 한다는 법도 없고.. 같이 갈 사람 못 구하면 지원도 못 받는 건 어쩐지 이상하게 느껴집니다. - [김수경]
• 제12회 한국자바개발자 컨퍼런스 후기/유상민의후기 . . . . 2 matches
        * 자신의 이론을 세웠다면, 이를 패턴화 하고 용어를 만들고, 사례를 만들고, 통계를 뽑고, 결과를 반영해야 이정도 발표를 해야하지 않을까. 싶다.
       소프트웨어 진흥원에서 이런식으로 가이드를 한다는 부분이 충격이었다. 컨설팅 후 참여 인원이 지속하기 너무 어렵지 않을까 싶다. 본인이 정립했으므로, 시중에 참고할 만한 관련 서적은 당연히 없고 용어 정의 부터 모호하다. 인상 깊은건 중간에 발표자와 프로그래머의 '행복'에 대한 언급을 많이 하는데.. 난 이거 듣고 많이 우울해 졌다.
• 코바용어정리 . . . . 2 matches
       의 인터페이스 타입에 대해 스텁에 대한 프로그래밍 인터페이스를 필요로 한다. 보통 스텁은 OMG-IDL로 정의되어 있는 객체 오퍼레이션에 대한 액세를 하게 해주는데, 일단 프로그래머가 OMG-IDL 및 특정 프로그래밍 언어에 대한 언어 매핑에 친숙해지면 손쉽게 예상이 가능한 방식으로 액세르를 하게 해준다. 해당 스텁은 ORB 코어에 전용이며 최적화된 인터페이스를 사용해서 나머지 ORB들을 호출하게 될 것이다. 만약 여러 개의 ORB를 사용하게 된다면 각각의 스텁은 제 각기 해당하는 ORB를 호출하게 될 것이다. 이 경우에 ORB와 언어 맵핑은 공조하여 각각의 스텁이 특정 객체 레퍼런스와 제대로 연결될 수 있도록 해야 할 것이다.
       클라이언트가 호출될 객체와 수행할 오퍼레이션을 지정하고자 할 때, 특정 객체 A의 특정 오퍼레이션을 지정하는 대신 객체 호출을 동적으로 생성하도록 허용하는 인터페이스를 이용할 수 있다. 이러한 경우 클라이언트 코드에서는 수행되는 오퍼레이션과 전달되는 파라미터의 타입에 대한 정보를 제공해야 한다. 이 정보는 대개 인터페이스 저장소와 같은 런타입 소스에서 얻어진다. 실행 시간 중에 해당 정보를 얻은 후, 클라이언트 코드는 이른바 동적 호출 인터페이스(DII)를 이용해서 동적으로 호출을 할 수 있게 된다.
• 큐와 스택/문원명 . . . . 2 matches
       // VC++ 6.0 이라면, 아마 release 모드에서 실행이 되지 않을것입니다.
        array[count] = array[count+1]; // string의 경우와 달리, Pointer 값만 복사됩니다.
• 프로그래밍언어와학습 . . . . 2 matches
        * 학교에서 C++ 배운다고 하드웨어 건드리나. -_-; (전전공이라면 몰라도..) 컴퓨터공학과의 경우 학교에서 C++ 배워도 어셈블러 레벨까지 다루는 사람이 별로 없다고 할때, C++ 을 배웠다고 시스템레벨 까지의 깊은 이해가 필요없었다는 점인데.. 글을 읽으면, 마치 '교육용 언어로 C, C++ 을 배웠다면 시스템 레벨까지 이해할 것' 처럼 쓴 것 같다고 생각. (C, C++ 포인터를 레퍼런스 이상의 개념으로 쓴적이 있었나.. --a) 차라리 '우리는 전전공 출신에 하드웨어제어 해본 사람 뽑습니다' 라고 할것이지..쩝. Domain-Specific 한 부분을 생각치 않고서는 시스템 프로그래머에게서는 늘 자바와 Script Language 는 '군인을 나약하게 만드는 무기' 일 수밖에 없으니까.
       하드웨어를 "뼈 속 깊이 꿰뚫고 있는 사람"과 그런 거라곤 하나도 모르는 사람이 동일한 문제에 접근했을 때 후자의 경우가 더 훌륭한 프로그램을 더 빨리 산출해낼 가능성은 얼마든지 있습니다.
• 프로그래밍잔치/첫째날 . . . . 2 matches
        * 우리가 졸업을 하면서 접하는 언어의 수가 얼마나 되는가? 10손가락에 꼽을수 있지 않을까? 프로그래밍 경력이 짧은 사람이라면, 많은 경험을, 많은 사람이라면 색다른 경험을 접해 보자.
        * 결과 확인 10
• 1thPCinCAUCSE/ProblemA . . . . 1 match
       아날로그 시계는 12시간 단위로 동작하며 시침과 분침이 있다. 주어진 시간 동안 시침과 분침이 몇 번 겹치는가를 알고 싶다. 예를 들어, 시작 시각이 11시 1분이고 끝 시각이 3시 20분이면, 이 시간 동안 시침과 분침은 4번 정확하게 일치한다. 각자 자기 시계로 확인 해 보세요. 시작 시각이나 끝 시각에 시침과 분침이 일치하더라도 회수에 포함한다.
• 2002년도ACM문제샘플풀이 . . . . 1 match
        ''부끄러워할 필요가 없다. 촉박한 시간에 쫓겼다고는 하나, 결국 정해진 시간 내에 모두 풀은 셈이니 오히려 자랑스러워 해야 할지도 모르겠다. 아마 네 후배들은 이런 배우려는 태도에서 더 많은 걸 느끼지 않을까 싶다. 이걸 리팩토링 해서 다시 올리는 것도 좋겠고, 내 생각엔 아예 새로 해서(DoItAgainToLearn) 올려보는 것도 좋겠다. 이번에는 테스트 코드를 만들고 리팩토링도 해가면서 처음 문제 풀었던 때보다 더 짧은 시간 내에 가능하게 해보면 어떨까? 이미 풀어본 문제이니 좀 더 편하게 할 수 있을 것 같지 않니? --JuNe''
• 2ndPCinCAUCSE/ProblemA . . . . 1 match
        (2) 삼각형을 한 개도 만들 수 없으면 0을 출력한다. 예를 들어서, 주어진 성냥개비의 개수가1, 2, 또는 4인 경우에는 삼각형을 한 개도 만들수 없다.
• 2ndPCinCAUCSE/ProblemB . . . . 1 match
       출력은 표준 출력이다. 출력은 T줄로 이뤄진다. 각 테스트 케이스에 대해서 입력에서 요구한 두 사람의 촌수를 나타내는 정수를 출력한다. 어떤 경우에는 두 사람간의 친척 관계가 전혀 없어 촌수를 계산할 수 없을 때가 있다. 이 때는 -1을 출력한다. T개의 테스트 케이스를 모두 맞혀야 이 문제를 맞힌 것이다.
• 2학기파이선스터디/모듈 . . . . 1 match
       ['_StringTypes', '__builtins__', '__doc__', '__file__', '__name__', '_float', '_idmap', '_idmapL', '_int', '_long', 'ascii_letters', 'ascii_lowercase', 'ascii_uppercase', 'atof', 'atof_error', 'atoi', 'atoi_error', 'atol', 'atol_error', 'capitalize', 'capwords', 'center', 'count', 'digits', 'expandtabs', 'find', 'hexdigits', 'index', 'index_error', 'join', 'joinfields', 'letters', 'ljust', 'lower', 'lowercase', 'lstrip', 'maketrans', 'octdigits', 'printable', 'punctuation', 'replace', 'rfind', 'rindex', 'rjust', 'rstrip', 'split', 'splitfields', 'strip', 'swapcase', 'translate', 'upper', 'uppercase', 'whitespace', 'zfill']
       AttributeError: 'module' object has no attribute 'b'
• 3 N+1 Problem/조동영 . . . . 1 match
        흔히 생각하는 알고리즘은 다들 비슷해서 소스가 비슷한 경우가 많어. 그걸 더욱 더 향상 시키려는 노력이 필요하지. 요즘 다른 알고리즘을 생각하려고 노력 중인데 잘 안떠오르네 ㅋ --[강희경]
• 5인용C++스터디/후기 . . . . 1 match
       중간에 빠졌던 날이 좀 부담됐지만 ! 결국 끝까지 4번 결석 압박을 견뎌내며 스터디를 마무리해서 기쁘네요.ㅋㅋ MFC를 했으니 이제 부담은 많이 줄었고요. 더불어 새 언어를 배우는데도 부담스럽지 않을 거라는 생각도 드네요. 자. 다음 스터디를 향해 전진~!
• ACM_ICPC . . . . 1 match
       || floyd || . || 그래프 연결성 확인 || . ||
• AM/20040705두번째모임 . . . . 1 match
        * 실제 돌아가는 결과물을 확인
• AM/AboutMFC . . . . 1 match
       그나저나 정말 유치하게 써놨군요. 이 자료는 제 이야기를 전제하고 있어서 전혀 친절하지 않습니다.위에 언급한 프세 기사도 내용이 내용이니 만큼 :) 친절한 편은 아니지만 한줄씩 확인하면서 읽으면 알수 있습니다. 처음의 흥미로운 부분과 머릿말들을 보고 MFC 소스를 따라가는 방법만을 보세요.
• AcceptanceTest . . . . 1 match
       QualityAssurance (QA)는 XP process의 주요 부분이다. 몇몇 프로젝트들의 QA는 분리된 그룹으로부터 수행되어지지만, 어떤 프로젝트들에서의 QA는 개발팀 스스로에 의해 수행되어진다. 각각의 경우에서 XP는 좀 더 QA와 관계있는 개발을 요구한다.
• ActiveXDataObjects . . . . 1 match
       마이크로소프트 ADO(ActiveX Data Objects)는 데이터 소스에 접근하려고 고안된 COM객체이다. 이것은 프로그래밍 언어와 데이터 베이스 사이의 층을 만들어준다. 이 층은 개발자들이 DB의 구현부에 신경쓰지 않고 데이터를 다루는 프로그램을 작성하도록 해준다. ADO 를 이용할 경우, 데이터베이스에 접근하기 위해서 SQL 을 알 필요는 없다. 물론, SQL 커맨드를 수행하기 위해 ADO 를 이용할 수 있다. 하지만, SQL 커맨드를 직접 이용하는 방법은 데이터베이스에 대한 의존성을 가져온다는 단점이 있다.
• AdventuresInMoving:PartIV . . . . 1 match
       위의 테스트 케이스를 보면 처음에는 거리가 100인 주유소에 무조건 가야합니다. 그러면 기름은 0이 되고, 스터디때 말한 방법으로 하면 앞의 200까지를 살피고, 가장 작은 가격이 있는 곳인 (200, 777) 까지 갈 수 있는 기름 100을 넣고 출발합니다. 그러나 여기서 살펴보면 최적의 해는 여기서 50만큼의 기름만 넣고, 150의 지점에서 또 50의 기름을 넣어서 (200,777)에 가는 경우입니다. -- 보창
• AppletVSApplication/영동 . . . . 1 match
        * 장점: 클라이언트/서버나 그 외의 네트웍 어플리케이션을 개발할 경우에 이익이 많다.
• Athena . . . . 1 match
        (영상을 이용한 변환에서 0이 있는 영상의 경우 나눗셈할수 없음. 1로 나눌때랑 같게 했음)
• B급좌파 . . . . 1 match
       맨날 '학연이네 지연이네 지역감정이 어쩌네' 하면서, 무심코 나는 그 사람에게 폭력을 행사한 것이리라. 차라리 그냥 'ZeroPage 에서 활동중 누구입니다' 라고 할걸. 온라인 모임이름이라면 그래도 1년에 10만 이상 못들어가는 대학교보단 그래도 덜 폭력적이련만. (하긴 결국 중대모임이므로 똑같으려나..) 나의 언어에선 당연한 세상이 다른 사람들에겐 당연할 수 없는 세상인 경우가 있다. 순간에 대해서 민감할 수 있었더라면. 깨어있었다면. -- ["1002"]
• C++Seminar03 . . . . 1 match
        1. 사회자 한명과 2인 1PC 또는 3인 1PC 로 PC 1대당 한조가 되어 PairProgramming 식으로 진행. 사회자는 간단한 개념을 설명하고 개념에 대한 실습(?) 또는 적용된 코드작성을 Pair 해본다. (이런식으로 진행할경우 장소에 문제가 될 수도 있을것 같네요. 실습실 하나를 제로페이지가 점령할수도 없는 일이고..-_- 강의실에서 간단한 설명 -> PC 실로 이동.. 정도가 대안이 될까요? ) --["임인택"]
• CC2호 . . . . 1 match
       || [주민등록번호확인하기] || . || . ||
• COM/IUnknown . . . . 1 match
       정상규현된 컴포넌트라면 인터페이스 포인터를 비교하는 것을 통해서 각 객체가 같은 컴포넌트의 인스턴스인지 확인이 가능하다.
• Celfin's ACM training . . . . 1 match
       || No. || Problem No. || Problem Name || Error || Source Code ||
• ClearType . . . . 1 match
       그림을 보면 잘 이해할 듯. 4번째의 경우가 클리어 타입이 사용하는 방식이다.
• CompleteTreeLabeling . . . . 1 match
       입력된 각 줄에 대해 한 줄의 결과를 출력한다. 그 줄에는 위에서 설명한 조건을 만족시키면서 k진 트리에 레이블을 붙이는 경우의 수를 출력한다.
• ComputerNetworkClass/Exam2006_2 . . . . 1 match
       3. PEM 으로 이메일 보낼경우, 보내지는 내용들 구조와 함께 설명. 같이 보내지는 첨부 파일은 a.jpg
• CppStudy_2002_2 . . . . 1 match
        언제나 처음의 마음을 잊지말구 해나간다면 우리 스터디는 성공하지 않을까?? -세연
• CryptKicker2 . . . . 1 match
       각 테스트 케이스에 대해 각 줄을 복호화하여 표준 출력으로 출력한다. 가능한 암호화 방법이 두 개 이상있으면 그 중 아무 결과나 출력해도 된다. 복호화할 수 없는 경우에는 다음과 같은 결과를 출력한다.
• DPSCChapter2 . . . . 1 match
       Validation. 스캔되고 입력되어진 form들은 각 필드들에 대해 일관성보증과 모든 폼이 완전히 채워졌는지에 대한 보증을 위해 검증작업을 거친다. 불완전하거나 적절치 못한 입력은 시스템에 의해 reject되고, 재확인을 위해 요구자에게 도로 보내진다.
• DataCommunicationSummaryProject/Chapter11 . . . . 1 match
        * 광케이블의 경우 중간에 신호확장을 거치기 전까지 초당 1000테라비트(페타비트)까지도 보내지만 무선은 이렇게 할 수 없다. 하지만 통신의 말단부분(Local Loop)에선 다르다. 도심 한가운데다가 광케이블을 파묻기 위해 다 뒤엎진 못하지 않는가...;;
• DataStructure/String . . . . 1 match
        같은 것이 없는 경우 - abcabcac f(j) = -1 -- [황재선]
• DefaultValueMethod . . . . 1 match
       의사소통을 더 쉽게 해주고, 상속될때에 오버라이딩 할 수 있는 여지를 남겨준다.(상속관계마다 상수가 다른 경우를 말하는 것 같다.)
• DesignPatterns/2011년스터디/1학기 . . . . 1 match
        1. 상속구현은 커플링을 늘리는 것 + 찾기 힘든 버그를 발생시키는 원인 이라 매우 슬픈거 같다.
• DirectVariableAccess . . . . 1 match
       와드 아저씨의 말로는, '클래스에 아주 적은 양의 메소드만 존재한다면, getter/setter를 추가하는 것만으로도 메소드의 수가 두배가 되어버린다. 이는 전혀 사용되지 않을 유연성을 위해 쓸데없이 갯수를 늘린 것이다.' 라고 한다.
• DispatchedInterpretation . . . . 1 match
       그.러.나. 객체의 정보가 다른 객체에 영향을 미쳐야만 할때가 있다. 간단할때는, 그냥 인코딩된 오브젝트에 메세지를 보내면 수월하게 해결이 가능하다. 하지만 복잡한 경우에는 힘들다. 문제는 수백의 클라이언트들에게 모든 타입의 정보에 대해 명시적으로 case 형태의 구조를 만들기를 원하지 않는다는 것이다.(??)
• Eclipse/PluginUrls . . . . 1 match
        * 가끔 동기화가 안되는 경우가 생기기도 한다.
• EightQueenProblem/김준엽 . . . . 1 match
       1번문제를 제대로 이해 못해서 실수로 모든 경우를 구해버렸습니다. -0-;;;
• Error 발생시 풀리지 않을 경우 확인 . . . . 1 match
       1. 컨트럴 ID 가 제대로 연결되어 있는지 확인하라.
• ExtremeProgrammingExplained . . . . 1 match
       [임인택]이 도서관에 신청해둠. (다시 확인해보니 아닌것같다...-_-. 누가 먼저 한듯.. ㅎㅎ)
• FileInputOutput . . . . 1 match
        System.out.println("Error : "+ e.toString()); {}
• GDG . . . . 1 match
        * 대학의 이름(중앙대)을 걸고 설립을 할 수는 있어도 동아리의 이름(ZeroPage)을 걸고 설립을 할 수는 없음 (확인 요망)
• Hacking/20040930첫번째모임 . . . . 1 match
        - 가볍게 읽어보신후 자신의 컴퓨터는 어떤 포트가 열려있는지 확인해보세요
• HelpOnSmileys . . . . 1 match
       편집 화면에서 {{{[[SmileyChooser]]}}}를 넣고 싶은 경우에는 아래와 같이 EditTextForm 페이지를 편집해주셔야 합니다.
• HostFile . . . . 1 match
       windows 의 경우는 system32/drivers/etc/host 라는 화일.
• HowToStudyRefactoring . . . . 1 match
        * Minimize Comments : 코드의 가독성을 떨어뜨리지 않거나 혹은 오히려 올리면서 주석을 최소화하도록 노력한다. 이렇게 하면, 자동으로 리팩토링이 이뤄지는 경우가 많다.
• HowToStudyXp . . . . 1 match
       이게 힘들면 같이 스터디를 하는 방법이 있습니다(스터디 그룹에 관한 패턴 KH도 참고하시길. http://www.industriallogic.com/papers/khdraft.pdf). 이 때 같이 책을 공부하거나 하는 것은 시간 낭비가 많습니다. 차라리 공부는 미리 다 해오고 만나서 토론을 하거나 아니면 직접 실험을 해보는 것이 훨씬 좋습니다 -- 두사람 당 한대의 컴퓨터와 커대란 화이트 보드를 옆에 두고 말이죠. 제 경우 스터디 팀과 함께 저녁 시간마다 가상 XP 프로젝트를 많이 진행했고, 짤막짤막하게 프로그래밍 세션도 많이 가졌습니다.
• ISAPI . . . . 1 match
        * IIS(Internet Information Services)란 웹 서버, FTP 서버와 같이 기본적이고 범용적인 인터넷 서비스를 시스템에서 제공할 수 있게 해주는 소프트웨어를 말한다. 기존 윈도우2000 제품군의 경우 기본적으로 IIS 5.0을 제공하였고 윈도우XP의 기존 IIS 5.0의 기능을 개선한 IIS 5.1을 제공하고 있다. 한 마디로 HTTP, FTP, SMTP 서버의 묶음이다.
• IsBiggerSmarter?/문보창 . . . . 1 match
       단순히 Greedy 알고리즘으로 접근. 실패. Dynamic Programming 이 필요함을 테스트 케이스로써 확인했다. Dynamic Programming 을 실제로 해본 경험이 없기 때문에 감이 잡히지 않았다. Introduction To Algorithm에서 Dynamic Programing 부분을 읽어 공부한 후 문제분석을 다시 시도했다. 이 문제를 쉽게 풀기 위해 Weight를 정렬한 배열과 IQ를 정렬한 배열을 하나의 문자열로 보았다. 그렇다면 문제에서 원하는 "가장 긴 시퀀스" 는 Longest Common Subsequence가 되고, LCS는 Dynamic Algorithm으로 쉽게 풀리는 문제중 하나였다. 무게가 같거나, IQ가 같을수도 있기 때문에 LCS에서 오류가 나는 것을 피하기 위해 소트함수를 처리해 주는 과정에서 약간의 어려움을 겪었다.
• JTDStudy/두번째과제/장길 . . . . 1 match
       * 너무 오랫만에 숙제를 했네요....... windfencer.zerpage.org 여기에 들어가면 위 소스로 만든 애플릿을 확인하실수 있습니다. - 장길 -
• Java Study2003/첫번째과제/방선희 . . . . 1 match
        * 2. 서블릿이나 JSP 는 J2EE의 구성원들로서 서버사이드 스크립트라고 합니다. JSP가 만들어진 이유가 뭐냐하면, 서블릿의 문제점을 해결하기 위해서라고나 할까... 웹 프로그래밍이란게 본질적으로 웹디자이너와의 협력이 불가피한데 서블릿의 경우에는 DISPLAY 부분을 수정하기 위해서 웹디자이너가 접근하기 어렵다는 단점이 있죠.. 이때문에 JSP가 만들어졌다고 알고 있습니다. JSP라는 파일은 웹 디자이너가 페이지를 수정하기 편하게 되어있다는게 장점이죠. JSP가 컴파일되면 서블릿이 됩니다.(이게 전부임...) 그리고 서블릿이 실행되면 실제 HTML 페이지가 클라이언트에게 전송되는 것입니다.
• JavaScript/2011년스터디/JSON-js분석 . . . . 1 match
        * perl에서는 "use strict"라고 썻을 경우 선언되지 않은 변수등은 오류로 뜸(프로그래머의 실수 방지)
• JavaStudy2003/두번째과제/곽세환 . . . . 1 match
        아직 상속을 읽고 있는 중이기 때문에 모르는 것이지요^^. private 과 protected 는 상속이 이루어지지 않으면 똑같이 사용이 됩니다. 하지만 상속이 이루어진다면 의미는 틀려지죠. 만약 '''자동차''' 라는 객체가 있다고 봅시다. 그런데 이것은 굉장히 추상적인 개념이지요. 이 '''자동차''' 의 하위 개념인 '''트럭''' 과 '''버스''' 와 '''승용차''' 를 '''자동차'''에서 상속받아 만들었다고 합시다. 그랬을 때 '''자동차''' 가 가지는 어떠한 상태는 '''트럭''' 과 '''버스''' 와 '''승용차'''도 역시 가지고 있을 수도 있습니다. 이런 경우 protected 로 선언해 주면 그 상태를 상속받을 수 있다는 것이지요. 하지만 외부에서 접근은 불가능하다는 사실은 변함이 없습니다. 하지만 public 은 외부에서 접근이 가능하게 되는 것이지요. 한번 직접 코드로 만들어보세요. 어떻게 다른지 채험하는게 가장 이해가 쉬울겁니다.
• JavaStudy2004/자바따라잡기 . . . . 1 match
        *4. 그 밖의 경우에서의 가상머신은, 컴퓨터를 실행하는 운영체계나, 어떤 프로그램을 의미하기 위해 사용되기도 했었다. 이를 인용하면
• JollyJumpers/곽세환 . . . . 1 match
       맨 처음에 n을 입력 받는 작업이 있으니, 배열을 동적으로 생성하는 것이 더 좋지 않을까? --[강희경]
• KIV봉사활동/개인준비물 . . . . 1 match
        * 집에서 마지막으로 짐을 꾸리면서 확인할 점검표 역할을 합니다.
• KnowledgeManagement . . . . 1 match
        * Nonaka 와 Takeuchi 는 성공적인 KM program 은 지식의 공유를 위해서 내면화된 무언의 지식을 명시적으로 체계화된 지식으로 바꿀 필요가 있다고 얘기한다. 그리고 또한 반대의 경우도 개인이나 그룹에게 있어서 KM 시스템에서 한번 추출한 지식을 내면화 하고 의미있게 체계화 하기 위해서 필요하다고 이야기 한다.
• Komodo . . . . 1 match
       가장 인상적인 기능을 뽑는다면 Rx(Regular Expression) Toolkit 을 들 수 있다. 이를 이용하면 Regular Expression 에서 각 그룹에 따른 변수들이 어떻게 뽑아져나오는지 쉽게 눈으로 확인할 수 있다.
• LearningToDrive . . . . 1 match
        * 하지만. 한편으론 '이상적인 만남' 일때 가능하지 않을까 하는 생각도. Communcation 이란 상호작용이라고 생각해볼때.
• NeoZeropageWeb . . . . 1 match
       뭐가 좋을까? ㅡㅡ? 쉽기는 3번이 가장 쉽고... 재미있기에는 2번이 가장 재미있고 독특한 형태가 되지 않을까 생각하는데...
• OurMajorLangIsCAndCPlusPlus/XML/조현태 . . . . 1 match
        /* 단순한 연결의 경우 */
• OurMajorLangIsCAndCPlusPlus/locale.h . . . . 1 match
       || char* setlocale(int category, const char* locale); || category에 대해 로케일 locale을 설정하고 (물론, 사용 가능한 로케일인 경우), 설정된 로케일값을 리턴. ||
• PragmaticVersionControlWithCVS/HowTo . . . . 1 match
       이 경우 체크인처럼 여러번 그리고 자주하는 일에 적용되는 규칙은 간단해햐한다.
• ProgrammingWithInterface . . . . 1 match
       상속을 사용하는 상황을 국한 시켜야 할 것같다. 상위 클래스의 기능을 100%로 사용하면서 추가적인 기능을 필요로 하는 객체가 필요할 때! .. 이런 상황일 때는 상속을 사용해도 후풍이 두렵지 않을 것 같다. GoF의 책이나 다른 DP의 책들은 항상 말한다. 상속 보다는 인터페이스를 통해 다형성을 사용하라고... 그 이유를 이제야 알 것같다. 동감하지 않는가? Base 클래스를 수정할 때마다 하위 클래스를 수정해야 하는 상황이 발생한다면 그건 인터페이스를 통해 다형성을 지원하는게 더 낫다는 신호이다. 객체는 언제나 [[SOLID|SRP (Single Responsiblity Principle)]]을 지켜야 한다고 생각한다.
• ProjectAR/ThinkAbout . . . . 1 match
       층을 자유자제로 움직이기 때문에 이벤트가 진행되는 경우의 수는 굉장히 많을 것이다. 이것들이 버그
• ProjectPrometheus/Estimation . . . . 1 match
        * 신청 도서 확인
• ProjectPrometheus/Iteration5 . . . . 1 match
       || Login 후 검색해서 RS 여부 확인 AT || . || . ||
• ProjectPrometheus/LibraryCgiAnalysis . . . . 1 match
        소장정보확인
• ProjectPrometheus/MappingObjectToRDB . . . . 1 match
        * 패턴의 오/남용 문제가 발생할 수 있다. - 어설프게 아는것은 모르느니만 못한 경우가 있다. 그리고 제대로 안다고 해서 "많이" 하는 것은 정말 잘 아는게 아닐 수 있다.
• ProjectSemiPhotoshop . . . . 1 match
        * ''Xp Process 에서 거론되는 '''''트럭에 치일경우 프로젝트에 결정적 영향을 끼치는 평균 수치이다.''''' ''
• ProjectVirush/Idea . . . . 1 match
        ( 숙주가 너무 많아질 경우 서버가 감당하기 힘들 수 있기 때문이다. )
• PyIde . . . . 1 match
        * 툴의 아주 작은 기능들이라도 구현해보면서 뭔가 배우는 것이 있지 않을까.
• PyIde/BicycleRepairMan분석 . . . . 1 match
       BicycleRepairMan_Idle.py 가 실마리가 될것 같다. VIM이나 Idle 통합부분의 경우 BRM에서의 facade를 사용한다.
• Python/DataBase . . . . 1 match
       client_flag - integer, 필요할 경우 사용하기 위한 flag (0)
• PythonNetworkProgramming . . . . 1 match
        print "Socket Error occured.."
• PythonXmlRpc . . . . 1 match
        raise AttributeError, "No XML-RPC procedure %s" % method
• R'sSource . . . . 1 match
        console=["rep.py"], # 도스창에서 실행할 파일을 생성할 경우
• RUR-PLE/Etc . . . . 1 match
        * 이 경우에서의 처리를 while 문을 사용하여 처리한다.
• RandomFunction . . . . 1 match
        b가 -일 경우에는 사용에 주의가 필요합니다
• RandomWalk . . . . 1 match
        바퀴벌레는 임의의 한 점에서 시작하여서 임의의 방향으로 움직이게 된다. 이미 지나갔던 자리에 다시 갈 수 있으며 프로그램은 바퀴벌레가 각 위치에 몇번 갔는지 기억하여야 한다. 프로그램은 바퀴벌레가 모든 지점에 적어도 한번 이상 도달하였을 경우 끝난다. 바퀴벌레는 가로, 세로, 대각선으로 한칸 씩만 움직일수 있으며, 바퀴벌레가 움직이는 방향을 랜덤하게 만드는 것은 각자가 생각해 보도록 한다.
• RandomWalk2/TestCase2 . . . . 1 match
       3. 가로 세로 같으며, 벽에서 다른 벽으로 나오는가 확인
• RandomWalk2/Vector로2차원동적배열만들기 . . . . 1 match
       ''DeleteMe 페이지 이름으로 MultidimensionalArray가 더 좋지 않을까요?''
• ReverseAndAdd . . . . 1 match
        * 안하지 않을까요? --[김회영]
• Ruby/2011년스터디/서지혜 . . . . 1 match
        * 웹 브라우저가 종료되지 않을 때
        _tprintf(_T("Process32First error!\n"));
• RubyLanguage/InputOutput . . . . 1 match
        * 단 예외 발생시 File.close는 호출되지 않는다. ensure 구문에서 처리할 수 있다.
• SearchAndReplaceTool . . . . 1 match
       Actual Search & Replace 를 쓰는중. 기존 사이트 이어받은거 웹 노가다일을 해야 할 경우 매우 편리. (예전에는 그때그때 python script 를 만들어썼는데, 그럴 필요가 없을듯) --[1002]
• ServerBackup . . . . 1 match
        * 문제 ~ DNS Server 가 죽었음 (or 잘못 설정되어 있음 165.194.35.222 서버 확인 필요) 그래서 주소 기반으로 외부로 ping을 날릴수 없다.
• SharedSourceProgram . . . . 1 match
       MVP만의 뉴스그룹에서 창업한 경우도
• SignatureSurvey . . . . 1 match
       처음써봐서 완벽하게 확신이 들진 않지만, SignatureSurvey 를 사용하면 Duplication Code 를 찾는 방법으로 일반화를 시킬 수 있지 않을까 하는 상상을 해본다.
• SimpleDelegation . . . . 1 match
       위임하는 객체(delegating object)는 위임 객체 또는 위임자 객체, 위임된 객체(delegate)는 대리자로 번역할 수 있을 것 같고(차라리 영어를 그대로 쓰는게 좋을지도 모르겠네요), 주체성은 참조를 의미하지 않을까요?
• SolidStateDisk . . . . 1 match
       백업 메카니즘으로서 배터리나 일반적인 자기디스크를 내장하곤 한다. SDD 는 일반적인 HDD I/O interface 로 연결된다. 이로 인해서 얻을 수 있는 잇점은 적은시간에 빈번한 I/O 작업이 일어날 경우에, seek time 이나 rotational latency 가 없는 메모리로서, 자기디스크에 비해 월등한 성능을 나타낼 수 있다. 그에 덧붙여 구동부가 없는 구조로서 좀더 내구성이 뛰어나다고도 할 수 있겠다. 단점은, 특성상 대용량화가 어려우며 커다란 데이터의 요구량이 커질때. 즉 access time 보다 transfer time 이 더 요구될때 효율성이 안좋다.
• SpikeSolution . . . . 1 match
       이러한 실험들을 XP에서는 Spike Solution이라고 한다. 다른 점이라면, 우리는 보통 실험 코드를 만든 뒤 실전 코드에 바로 붙일 것이다. 하지만 Spike Solution 의 경우는 '실험은 실험에서 끝난다' 에서 다를 수 있다. 보통 Spike Solution 에서 실험한 코드들을 메인소스에 바로 적용시키지 않는다. Spike Solution은 처음 계획시 estimate의 선을 잡기 위한 것으로 메인소스에 그대로 적용될 코드는 아닌 것이다. 지우고 다시 만들어 내도록 한다. 그러함으로써 한편으로는 학습효과를 가져오고, 실전 소스의 질을 향상시킬 수 있다.
• SummationOfFourPrimes . . . . 1 match
       [http://www.n2n.pe.kr/util/find_prime.php 소수판정기]로 답을 확인해볼 수 있겠네요. --[Leonardong]
• SwitchAndCaseAsBadSmell . . . . 1 match
       ["가위바위보"] 구현 코드들을 보면 케이스 문을 많이 쓰거나 혹은 비슷한 구조의 if 문이 중복된 경우가 많습니다.
• Temp/Parser . . . . 1 match
        except ValueError:
        self.outstream.write(self.lexer.error_leader()+msg+'\n')
• TheTrip/Leonardong . . . . 1 match
       문제를 풀기 전에 샘플 입력부터 보는 경향이 있다. 문제를 이해 못했으므로 샘플 입력을 보다가 결국 다시 문제를 보느라 시간이 지체된다. 따라서 문제를 다 이해하고, 정의한 뒤 샘플 입력을 보아 정의가 맞는지 확인하는 순서로 문제를 풀어야겠다. 해결책은 문제를 정의한 다음에 떠올린다.
• UML/CaseTool . . . . 1 match
       UML 케이스 툴과 달리 Visio 같은 경우에는 Diagramming 기능만을 제공한다. Diagramming Tool 이라고 분류하는 듯하다.
• UglyNumbers/1002 . . . . 1 match
       하지만, 결과값을 보면서 지수 스타일의 접근법이 원하는 접근법이라는 생각을 하게 되다. (10억이 넘는다 할때, isUglyNumber 식이라면 10억번이 실행된다.) 하지만, 그냥 지수로만 생각하면 uglynumber 의 순서 상 맞지 않을 것인지라 (1 : 2^0*3^0*5^0, 2 : 2^1*3^0*5^0, 3 : 2^0*3^1*5^0, 4 : 2^2*3^0*5^0 ... 0,0,0 , 1,0,0, 0,1,0 , 2,0,0 .. 도무지 숫자들 간의 연관성이 잡히지 않았다.
• VMWare . . . . 1 match
       유사제품으로 [Parallels] ( [eXtremeProgramming] 으로 개발되었다고 함. Mac 버전의 경우 윈도우 환경을 거 70%~90% 퍼포먼스로 구현했다고 들었음) 가 있다.
• WikiGardening . . . . 1 match
       ''실제 위키의 View 구조를 조성하는 사람들이 드물기 때문에, 기존 게시판에서의 스타일과 똑같은 이용형태가 계속 진행되어버렸다는 생각이 든다. (이 경우 RecentChanges 가 Main View 가 된다.) (조만간 위키 전체에 대한 링크 구조 분석이나 해볼까 궁리중. 예상컨데, 현재의 ZeroWiki 는 Mind Map 스타일에 더 가까운 구조이리라 생각. (개념간 연결성이 적을것이란 뜻. 개인적으로는 볼땐, 처음의 의도한 바와 다르긴 하다.) --1002'' (DeleteMe ["1002"]의 글을 다른 페이지에서 옮겨왔습니다.)
• XMLStudy_2002/Encoding . . . . 1 match
        *유니코드에 대해서 자세히 알고 싶거나 참조해야 하는 경우 : [http://www.unicode.org/]
• Yggdrasil/가속된씨플플/2장 . . . . 1 match
        * 루프불변식(loop invariant): while문이 그 조건식을 검사하는 매 경우에 대하여 참일 것이라고 가정하는 속성. 처음에 이걸 보고, 이런 개념도 있었냐고 생각했음. 루프불변식은 코드는 아니고 주석에 해당하며, while문이 진행되면서 while문의 제일 처음과 끝에서 루프의 내용이 의도한 대로 돌아간 건지를 정의한 문장이다.(말로 설명하기 애매한 듯...) 하여튼 이것을 쓰는 이유는 루프문을 제대로 설계하기 위해서. 아래의 코드는, 책에 있는 코드로, 불변식의 예이다.
• ZeroPageSeminar . . . . 1 match
       앞으로 계획되어 있는 세미나 입니다. 자세한 사항은 세미나별 페이지에서 확인하세요.
• ZeroPageServer/BlockingUninvitedGuests . . . . 1 match
       제로페이지 위키의 RecentChanges 를 보면 가끔 쓰레기 페이지가 생성이 되는 경우가 있는데, 매번 수작업으로 페이지를 삭제해야 하는 번거로움이 있다. 이를 서버 또는 위키위키 자체가 막아주는 방법에 대해서 토의해 보는 페이지.
• ZeroPageServer/FixDate . . . . 1 match
       로 확인할수 있다.
• ZeroPageServer/UpdateUpgrade . . . . 1 match
       확인하면서 업그레이드 하고 싶다면
• ZeroPageServer/계정신청방법 . . . . 1 match
        ZeroPageServer 페이지에서 계정신청상황,질문답변 확인 가능
• ZeroPage회칙토론 . . . . 1 match
       각 항목에 몇조 몇항을 두는 이유는 index가 용이하라고 있는것이겠지만, 이 상황에 경우는 그리 필요없을것이라 생각함.--석천
• ZeroWiki/Mobile . . . . 1 match
       모바일 환경에서 열람만 가능할 것인가? 편집도 가능하게 할 것인가? 편집을 할 경우 편집 도구라던가 [AJAX]라던가 어떻게 해야 하나 고민이 있음
• [Lovely]boy^_^/USACO/BrokenNecklace . . . . 1 match
        * 전혀 생각도 못한 경우가 튀어나와서 그걸 생각 못해준게;;
• eXtensibleStylesheetLanguageTransformations . . . . 1 match
       XML+CSS 로는 데이터의 바꾸는 것이 불가능하지만 XSLT를 이용할 경우 아예 XML 구조 자체를 변경하는 것이 가능하다. - [eternalbleu]
• html5 . . . . 1 match
       == 브라우저 지원여부 확인 ==
• joosama . . . . 1 match
       정작일본의 매스컴에서는 이를 보도 하지도 않을 뿐더러,
• neocoin/Log . . . . 1 match
        * U- ocu 유닉스 계정 확인
• 나를만든책장/서지혜 . . . . 1 match
        * 개발자를 ''남자친구''로 둔 사람들을 위한 글임. 여자가 개발자일 경우따위 고려 안함^^ 왜 읽었을까. 불쏘시개이다.
• 넥슨입사문제 . . . . 1 match
        당연히 프로그램. 프로그램을 보내면 회사에서 문제에 나오지 않은 테스트셋으로 프로그램이 맞는 지 확인하겠지. --재동
• 논문번역/2012년스터디/신형준 . . . . 1 match
       이같은 경우에 개인적인 점들(화살표 그것 스스로에 대해서)은 특별한 중요성을 가지고 있지 않습니다.
• 데블스캠프2009/금요일/SPECIALSeminar/송지훈/김홍기/박성현 . . . . 1 match
       1. 기회와 재확인
• 마이포지셔닝 . . . . 1 match
        * 이책은 글로벌CEO 특강에서 스파이렉스 사코사의 박인순 사장님이 아주 아주 강력하게 추천해서 정현이와 공동 구매 해서 샀다. 아직 도서관에는 안 들어 왔는데 지금 우선 신청은 해놓은 상태다. 우선 전체적인 느낌은 보통의 성공학, 자기계발서는 어찌 좀 뜬구름 잡는듯한 내용도 많았는데 이책은 아주 현실적으로 접근하고 있다. 처세서, 성공학 같은 책중에서 이책이 가장 솔직하고 정확하게 그 길을 제시해주는거 같다. 저런 책에 관심이 있다면 이 책을 꼭 읽어 보는게 좋다. 누군가와 협력하고, 누군가의 장점을 알아볼수 있고, 좋은 아이디어를 알아볼수 있는 능력이 정말 핵심인거 같다. 그리고 혼자 잘나서 다 할수 있다는 생각을 가지면 절대 안되고, 자신이 올라탈 말이 있어야 한다. 그리고 2막은 없다는 이야기가 있는데 1막에서 성공하였다고 해서, 그 똑같은 일을 그 회사 나와서 다시 다른 회사 차려서 해서 성공하는 경우는 거의 없다. 그것은 자기 자신이 시기를 잘 만나서 성공한게 아니라 자기가 잘나서 성공한거라는것을 대중에게 보여주고자 하는 자아 때문인데, 그런 자아를 가지고서 다시 성공할 수도 없다. '수로부여'라고 자신이 한번 잘되었던 일이 있으면 계속 그런식으로 일을 하는것을 말하는 특성이 있는데, 두번째로 할때도 첫번째것이 성공하였다고 그런식으로 똑같이 해서 어떤 경쟁력도 생길수 없다.
• 문자반대출력 . . . . 1 match
        * C 에도 라이브러리로 문자열 반전 시켜주는 함수를 제공합니다. strrev()라는 함수를 사용하면 '\0'바로 전 글자부터 거꾸로 만들어주죠. 물론 ANSI 표준은 아니고 Semantec, Borland, Microsoft 에서 제공하는 컴파일러의 경우에 자체 라이브러리로 제공합니다. 이식성을 생각하지 않는 일반적인 코딩에서는 위에 나열한 컴파일러를 이용한다면 사용할 수 있습니다. - 도현
• 문제풀이/제안 . . . . 1 match
        * 하지만 지나치게 높거나 낮은 수준의 문제가 업로드 되었을 경우. 의견을 조율하여 새로 올립니다.
• 상협/감상 . . . . 1 match
        * 난 원래 영화 잘 안보는 스타일 이지만, 마음도 심난하고 해서 컴퓨터로 이 영화를 보게 되었다. 처음 부분에서는 좀 황당한 재미가 있었고, 중간 부분으로 가면서 지루해져서 그만 볼까 하는 생각도 했지만, 좀 더 보다 보니깐 재밌어져서 결국 끝까지 봤다. 이 영화를 보고 느낀점은... 음.. 지금 내가 보고 있는 세계도 혹시 환상은 아닐까 하는. ㅡㅡ;; 메트릭스도 생각나고.. 그리고 영화속 주인공이 불쌍해 보였다. 뭐 비록 천재인거 같지만 그렇게 사는것은 별로 유쾌한 일은 아닐거다. 또한 천재적인 사람들은 사회에 잘 적응 못하는건 아닐까 하는 생각도 해본다. 한때 나도 머리가 천재적으로 좋았다면 좋겠다고 생각도 해보았지만, 그땐 이런 생각을 했었다. 머리가 너무 좋다면 노력해서 뭔가를 해내는 그런 쾌감을 얻을 기회가 적을 수도 있고, 주위로부터 한사람의 인격체로 인정되기 보다는 하나의 이용해 먹을 도구로 인식되지는 않을까 하는 생각도 해본다.(그사람 == 머리, 이런 이미지가 생기면 그 사람의 다른 모습은 전혀 관심밖의 일이 될테니..)
• 상협/모순 . . . . 1 match
        * 나는 이말에 대해서 이 소설을 읽기 전까지는 그렇게 크게 느껴지는게 없었는데.. 소설을 읽고 나서는 이말에 대해서 느껴지는게 많아 졌다. 인생을.. 미리 짜여진 계획대로.. 마음대로.. 된다고 한다면 행복할까? 자기가 하고 싶은것은 다 할수 있고, 못하는게 없다면?? 과연 행복할까~?? 어떠한 불행도 없는 행복을 행복이라고 할수 있을까? 하는 생각을 해본다. 인생이 그렇게 만만하지는 않을거 같고, 그렇게 만만하게 사는게 좋을거 같지는 않다. 나의 인생도 내 계획대로 된것도 아닌고.. 지금 생각하면 그게 더 재밌는 삶을 살 수 있게 만든건 아닌지 하는 생각이 든다.
• 새싹교실/2011/學高/5회차 . . . . 1 match
       x=y일경우 x에다 y를 넣는거고, 같다는건 x==y
• 새싹교실/2011/學高/8회차 . . . . 1 match
        * 음... 헤더는 제가 실수한거구요. 하노이의 탑을 짤 때 제대로 짰는지 확인해보라는 의미로 count를 넣었기 때문에 굳이 함수의 형태를 건들기보단 전역변수를 임시로 선언해서 쓰는것이 더 좋을 것 같아서 이렇게 작성했습니다. - [윤종하]
• 새싹교실/2012/새싹교실강사교육 . . . . 1 match
        1. 일주일에 2시간강의를 진행할때 나누어서 자주 만나는것이 더 관계, 대화를 진척시켜 빠른 피드백에 의한 지식 전달에 도움이 된다(출석률이 좋을경우).
• 새싹교실/2012/아우토반/앞반/5.10 . . . . 1 match
       2. 다음 소스 코드를 실행하고 결과를 확인, 이유를 분석해오시오
• 새싹교실/2012/앞부분만본반 . . . . 1 match
       Ax=b 에서 A : coefficient matrix (계수 행렬) -> mxn행렬일 경우 -> 방정식의 수 : m 미지수의 수 : n
• 새싹교실/2012/열반/120507 . . . . 1 match
        * A[n]으로 선언할 경우 첨자는 0 부터 n-1 까지 쓸 수 있습니다.
• 새싹교실/2013/양반/3회차 . . . . 1 match
        (3.2) 그렇지 않은 경우에는 다음 case 절의 문장들을 실행한다.
• 새싹스터디2006/의견 . . . . 1 match
       어느쪽이 되었든 하위페이지는 신중히 만들어야 합니다. 하위페이지는 순간 만들기 쉽지만 갈수록 구조를 바꾸기가 어려워집니다. '''숙제'''로 제로페이지 위키에 있는 페이지를 검색해 보세요. 내용으로 정리할 수 있는 페이지가 있지만, 손보려면 드는 시간이 적지 않을 겁니다. 일일이 페이지를 열어보기 전까지는 그 안에 어떤 내용이 있는지 알 수도 없고요. 또 하위페이지는 링크를 걸기가 더 어렵습니다. 상위 페이지 외에는 그 하위 페이지의 역링크 개수는 0에 가깝습니다. 이를테면 [5인용C++스터디/멀티쓰레드]는 [5인용C++스터디]에서만 링크하고 있습니다. 이러한 현상은 하위의 하위 페이지로 들어가면 더 심해질 것입니다. -- [Leonardong]
• 성당과시장 . . . . 1 match
       나의 경우 이런 책은 잘 않읽기 때문에 그냥 요점만 알아두는 것을 좋아한다. -_-;
• 시간관리하기 . . . . 1 match
       ["1002"] 의 경우 치열하게 살고 있진 않지만, 몇몇개 해본 일들이 있다. 처음에는 크고 거창하게 계획 세우고 일들 순위 매기면서 하는 스타일을 시도했었는데, 요사이는 작고 간단하며 실천적인 행동들을 생각하려고 노력한다. (하지만, 여전히 게으르다;)
• 실습 . . . . 1 match
       16) Error를 모두 잡은 후, Ctrl+F5를 눌러 실행하여 본다.
• 음계연습하기 . . . . 1 match
       프로그래밍도 이러한 음계(etude-연습곡)연습을 꾸준히 해서 장인(Craftsman)으로 발전해 나가는 길이 있지 않을까?
• 임시분류 . . . . 1 match
       일회용 페이지들에 대한 분류.DeleteThisPage 의 대상이 될수 있는 페이지다. 경우에 따라 보존될 가능성도 있는 페이지들. 가령 설문조사등은 일회용이 될수 있지만 일종의 자료로 남을 수도 있다. DeleteThisPage 가 아니라면 추후 재분류 대상 페이지.
• 임인택/CVSDelete . . . . 1 match
        except os.error:
       나의 경우는, 1. 탐색기에서 해당 디렉토리에 CVS로 화일검색(하위폴더 포함) 2. 전체 선택 3. 삭제 --[1002]
• 임인택/RealVNCPatcher . . . . 1 match
        - 윈9x 일 경우에는 어쩌지? -> 쌩까...? -_-;;
• 정규표현식/스터디/문자집합으로찾기 . . . . 1 match
        * {{{또한 다음과 같이 [0-9] = [0123456789]와 같이 사용하며 문자 또한 지원한다. 축약법은 하이픈(-)을 붙이는 방법으로 [A-Z][a-z] 이방법은 아스키 코드 방식을 따르며 축약시킬 경우 [a-A]는 역순이므로 되지 않는다. 또한 리스트([])안에서는 또다른 리스트([])와 역슬래시(\), 하이픈(-)을 제외하고는 모두 일반 문자와 같이 인식하므로 특수문자 %&^&#*$ 를 단순히 리스트 안에 나열하는것으로 검색할수 있다 리스트 안에서 리스트([])를 검색하는 방법은 역슬래시를 붙여 이스케이프를 시켜야한다.}}}
• 정모/2002.5.16 . . . . 1 match
        * 우리 전시회를 대체할 2학기 학술제에 낼 작품에 대해서 얘기해봐야 하지 않을까요? (왠지 이러다가 그냥 묻힐거 같아서..) -상협
• 정모/2004.2.3 . . . . 1 match
       == (있을 경우) 추가 안건 ==
• 정모/2006.1.5 . . . . 1 match
        * 프로젝트 진행상황 ( 2주에 한번 하는게 낫지 않을까요? )
• 정모/2007.1.6 . . . . 1 match
        이장길 - 후배의 경우에는 감정이 앞설것 같지만 잘 풀어서 관계를 유지하겠다. 선배가 강하게 나와도 어느정도는 자신의 기준을 지키겠다.
• 정모/2011.5.9 . . . . 1 match
        * OMS 재밌었습니다. 스타1 유즈맵을 즐기는 저로서는 스타2의 무한한 가능성을 엿본듯한 -_-;; 비록 아직은 버그투성에 애로사항이 있더라도 좀더 지나고나면 똑똑한 게임개발툴이 나올 것 같네요. 월드아이티쇼.. 저는 아마 불발될 거 같습니다. ㅜㅜ 수금은 수업 때문에 안되고 목토는 일이 있어서 에구; 담주 OMS 준비를 제대로 할 수 있을까 걱정입니다;; 구글신 찬양과 함께 미래의 안드로이드와 클라우드 서비스에 대해 할까 하다가.. 준비할 시간이 많지 않을거 같으니 아마도 경시대회 관련 주제로 준비될거 같습니당.. - [정진경]
• 정모/2011.7.11 . . . . 1 match
        * DP 세미나 참여 때문에 일찍 끝나서 뭔가 약간 아쉬웠습니다. 데블스캠프도 마치고 새로운 스터디/프로젝트도 시작되어서 사실 공유할 수 있는 것들이 많았을텐데 (저 같은 경우 DB2 Certi Program에 대해 좀 공유하고 싶었고..) 다음주를 기약 해야겠어요. 태진이의 OMS는 MacBook의 디스플레이가 원활했다면 keynote로 더 좋은 presentation이 될 수 있었을텐데 아쉬웠을 것 같아요. 본의 아니게 (주제가 Apple이다 보니) 선배님들이 많이 (농담조로) 디스했는데 발표는 좋았답니다. 역시 태진이는 기대치를 높여주는 친구에요. - [지원]
• 정모/2012.2.24 . . . . 1 match
        * 신입생들 대상으로 하는 얘기 맞지? 새싹 OT 하는 날 합쳐서 간단한 소개는 필요하지 않을까? 따로 하는 건 좀 오버인거 같구 ㅋㅋ 주로 새싹 소개하면서 ZeroPage 설명부터 하고 시작했던 것 같아. 그리고 간단한 세미나(혹은 새내기에게 하고싶은 말 세션) 같은 것도 함께 했던 적이 많고. - [김수경]
• 조현태/놀이/미스틱아츠 . . . . 1 match
        처음에는 아무생각 없이 만들면 되지 않을까 하는생각에 만들기 시작했다.
• 조현태/놀이/지뢰파인더 . . . . 1 match
        ㅋㅋ 우리 자바 공부해서 뭔가 프로그램 만들어 보지 않을래? 겨울방학 때 ㅋㅋㅋ --아영
• 주민등록번호확인하기/정수민 . . . . 1 match
       [LittleAOI] [주민등록번호확인하기]
• 주요한/노트북선택... . . . . 1 match
        나같은 경우에는 [http://kr.dcinside14.imagesearch.yahoo.com/zb40/zboard.php?id=notesell nbinsde노트북중고] 에서 중고 매물로 소니바이오 S38LP를 158만원에 샀는데,, 아는 선배는 같은것을 새거로 290만원 가까이 주고 샀었다는 말을 주고 보람도 있었음,,
• 지금그때 . . . . 1 match
        * 지금그때는 단지 고학년이 저학년에게 경험을 나누어주는 정도의 행사는 아니라고 생각합니다. 마치 개구리 올챙이적 시절 기억못하듯이, 그때 궁금해 했지만 지금은 왜 궁금했는지 조차 모르는 그런것, 지금과 다르게 생각했던 그시절 기억들. 그런것을 고학년도 경험을 할 수 있는 기회되지 않을까요?? 때로는 우리가 조언해 주고 있는 사람들이 가지고 있는 신선한 질문들은 자신을 자신의 일을 한번 더 돌아볼수 있게 만드는 기회를 주기도 하지 않나요?? - 이승한
• 지금그때2004/전통과사유20040329 . . . . 1 match
        * 5:30 신피 모임, 칠판있는 곳으로 이동, 자료확인(4413)
• 지금그때2004/홍보 . . . . 1 match
       '''필수 : 강의실 위치 확인'''
• 지금그때2005 . . . . 1 match
       지금그때의 의미를 담은 자료집과 질문릴레이에서 좋은 내용을 받아 적을 수 있는 종이. 그리고 OST를 간단하게 받아 적을수 있는 종이를 나눠준다면 좋지 않을까요?? - 이승한
• 지금그때2005/리허설 . . . . 1 match
       앞에는 저희가 생각한 이번시간에는 최소한 이런 이야기는 꼭 나왔으면 한다는 이야기들을 적어 놓았습니다. 그 이외에 또 질문하고 싶으신 내용이 있으시다면 언제든 나오셔서 질문을 등록하실수 있습니다. 대답에 집중하는 사이에 어느순간 질문을 까먹어 버리는 경우도 많으니까요.
• 지금그때2005/회의20050308 . . . . 1 match
        패스하지 않을 질문으로 만들자. 패스를 하면 엄한 벌칙을 준다.
• 책분류Template . . . . 1 match
       [노스모크]에서는 ISBN 링크가 되는 책소개의 경우 링크를 상단에, 서평을 하단에 적는것을 원칙으로 한다.
• 최소정수의합/문보창 . . . . 1 match
        * 원래 이렇게 쓰는거 인가요 ? n(n+1)/2 가 n까지 숫자의 합으로 알고 있는데, 코딩할 때 만약에 공식을 모르는 경우는 어떻게 하나요?
• 캠이랑놀자 . . . . 1 match
        * C++ & Python - 현재 라이브러리들 관계상 C++ 로 구현된 것들이 많은 관계로. 중간에 [1002] 가 Python Wrapper Class 만들기를 시도할 것이긴 함.~ Python 의 경우 이미지 처리에 대해서 prototyping 을 위해 중간에 이용할 예정.
• 컴퓨터고전스터디 . . . . 1 match
       요즘 전산학과 대학생들이 모여서 리눅스 해킹법이니, MFC API니 하는 걸 같이 스터디하는 것도 나름대로 의미가 있겠지만 컴퓨터계의 고전 하나를 제대로 스터디하는 것은 어떨까 합니다. ''군자무본 본립이도생. 군자는 근본에 힘을 쓰니, 근본이 서야 길이 생기기 때문이다.''라는 말이 논어에 나오죠. 나이가 아직 어리고, 시간적 여유가 있는 때에는 어떤 구체적인 "기술"보다 좀더 일반적이고 보편적이며 이론적인 사유를 훈련하는 것이 좋지 않을까요. 구체적 기술은 거기에 갖혀버리는(Lock-In) 경향이 있습니다. 2-3년 뒤에는 쓸모없어진다든가 하는 것이죠. 하지만 고전은 대부분 앞으로도 10년은 족히 유효한 것들입니다. 꾸준히 재해석될 가능성이 있는 것들이고, 무엇보다 문제의식과 함께 치밀한 사유를 배우는 겁니다. 생각하는 법 말이죠.
• 파스칼삼각형/김영록 . . . . 1 match
       int num_ret(int X, int Y) //재귀호출 1인경우(X=1,X=Y)엔 1을 리턴하는방식
• 파스칼삼각형/조현태 . . . . 1 match
        가게일 돕다가 중요한 메일이 와서 확인차 잠시 겜방에 왔더닛..
• 학회간교류/08 . . . . 1 match
        * 특정학회의 위키에 종속되는 것 보다는 스프링노트가 낫지 않을까 싶다.
• 현재 위키에 어떤 습관이 생기고 있는걸까? . . . . 1 match
        + 길에 비유를 했었는데 우리는 0'Wiki를 사용함으로 해서 익숙한 길이 있기 때문에 1'Wiki에도 역시 똑같이 사용하는것 같습니다. 이대로 페이지가 쌓인다면 0'Wiki와 똑같이 되지 않을까 합니다.-[상욱]
• 화이트헤드과정철학의이해 . . . . 1 match
       우리는 진리를 찾기 위해 오늘도 자신의 공식에 Control Point 를 하나더 추가하고 있는것일지도 모른다. (단, 라그랑주일경우엔 좀 더 정확해보이는 Cubic Spline 으로 페러다임 전환을 하자. ^^;)

Found 387 matching pages out of 7555 total pages (1440 pages are searched)

You can also click here to search title.