| - \TableOfContents1 |
| = |
| - ! 개성있는 프로그래머가 되는길(2) |
| - |
| - \right 저자 : 이만용(프로그램 세계 기사) |
| - |
| - |
| - 인간이란 특히 기술자인 경우 목표 말고도 목표를 달성하는데 사용하는 도구의 그 |
| - 자체의 매력에 빠지기도 한다. 도구의 매력에 일정 정도 빠지는 일은 전혀 해롭지 |
| - 않다. 도구를 이리저리 사용해 보면서 도구를 매우 정교하게 사용할 수 있게 되기 |
| - 때문이다. |
| - |
| - 프로그래밍 언어 하나를 하나부터 열까지 정교하게 다룰 수 있다는 것은 분명히 장점이다. |
| - |
| - 그러나 프로그래밍 언어를 하나 잘 알고 있다고 해서 모든 일을 한 프로그래밍 언어에 |
| - 의존하는 것은 경계해야 할 습성이다. 아무리 멋진 도구라 할 지라도 결국에는 도구이다. |
| - |
| - 새로운 언어를 열심히 배운다 |
| - 언어는 도구일 뿐이다. 많이 알수록 좋다. 새로운 언어 배우기에 인색하지 말라! |
| - |
| - 언어는 도구이며 이상도 아니고 이하도 아니다. 이 세상에 C나 C++ 이외에도 많은 |
| - 언어가 존재하는 이유는 무엇일까? 각 언어마다 자기 전공이 확실하게 존재한다. |
| - 다목적이긴 하지만 시간이 적게 걸리는 언어가 있는 반면, 일부 목적에 사용되지만 |
| - 그 용도 하나만큼은 확실히 빠르게 처리해주는 언어가 있다. |
| - |
| - 리눅스에서라면 여전히 C 언어의 인기가 높지만 Qt등의 훌륭한 툴킷이 나오면서 |
| - 윈도우에서처럼 C++ 언어의 인기도 높아가고 있다. 프로그래밍을 하는 사람이라면 |
| - 아주 기본적으로 bash, tcsh 사용법을 잘 알고 있어야 한다. 쉘 프로그래밍은 기본이다. |
| - |
| - 그 외에도 펄(Perl), Python(파이썬), Tcl/Tk 등 전세계적으로 적지 않게 사용되고 |
| - 있는 언어들도 있다. 특히 펄(Perl)과 같은 언어는 실용성과 언어학적 측면에서 매우 |
| - 흥미로운 언어라고 생각하며 리눅스 개발자라면 꼭 권장하고 싶다(필자는 요즘 |
| - 펄이라는 도구의 매력에 빠져 있는 단계이다. 숙련되고 나면 누구보다도 빠른 속도로 |
| - 관리/웹 애플리케이션을 만들 수 있으리라 기대한다). |
| - |
| - * 쉘 사용법, 쉘 프로그래밍 언어(본쉘, C쉘 모두) |
| - |
| - * C 언어 & 유닉스 명령 |
| - |
| - * C++ 언어 |
| - |
| - * 펄(Perl) |
| - |
| - * 기타 Tcl/Tk, Python, Java |
| - |
| - 리눅스/유닉스 애플리케이션 개발자라면 무조건적으로 쉘을 잘 사용해야 한다. |
| - 쉘 프로그래밍 언어를 C 언어 배우기와 병행하면 상당히 도움된다. |
| - 언어가 다양하다고는 하나 현대적인 언어의 구조적 뿌리가 되어 주는 언어가 |
| - C 언어이기 때문에 서로 매우 유사하고 한 언어를 잘 하면 다른 언어를 쉽게 |
| - 익힐 수 있다. |
| - |
| - 쉘의 경우 본쉘(Bourne)과 C쉘의 양대 산맥이 있는데 경험상 두 가지에 대하여 |
| - 모두 알아두는 것이 좋다. 대신 개인의 취향상 한 가지 쉘을 특별히 잘 할 필요는 있다. |
| - 리눅스에서라면 단연 본쉘 계열의 GNU bash이다. |
| - |
| - C 언어는 기본 중의 기본이다. |
| - C Programming Language”라는 C 저자의 책부터 시작해서 어마어마하게 많은 C 관련 |
| - 책들이 있다. C 언어는 특히 유닉스와의 관련성이 밀접하므로 유닉스 프로그래밍에 관련된 |
| - 책이라면 어떤 책이든 상관없다. 유닉스 == C, C == 유닉스이기 때문에 유닉스 명령을 |
| - 잘 알면 C 언어를 배우는데 도움이 되고 C 언어를 잘하면 유닉스를 잘 다루게 된다. |
| - |
| - 유닉스 명령을 어느 정도(완전히는 아니고... 원래 불가능하다) 익힌 후, C 언어 |
| - 공부를 시작하면 좋다. C 언어 공부와 유닉스 명령 공부는 무조건 병행한다. |
| - |
| - C 언어의 경우에는 한 번 끝날 수 있는 성질의 것이 아니므로 몇 십 번이고 반복할 |
| - 것이라고 미리 생각하자(필자라면 다른 언어와 상관없이 죽을 때까지 익히게 될 것 같다). |
| - |
| - 하지만 C 언어 지상주의로는 빠지지 않기 바란다. C 언어가 뿌리이기는 해도 더 좋은 |
| - 언어들이 많으며 목표한 것을 빨리 이룰 수 있도록 여러분을 도와준다. |
| - |
| - 그 다음은 C++이다. Java와 같은 언어에서 강력하게 지적하듯 C++ 언어는 C 언어보다 |
| - 대형 애플리케이션 그리고 윈도우 환경과 같은 이벤트 처리 방식의 시스템에서 생산성이 |
| - 높지만 이에 비해 복잡성이 너무 크다. 개인적으로 Java 보다 덜 선호하는 언어이다. |
| - 그러나 피해갈 수 없는 언어라고 생각한다. C++ 책을 작은 것 하나, 굵은 것 하나 |
| - 구입해서 예제를 익혀가면서 어느 정도 알아두는 것이 좋다. |
| - |
| - 펄(Perl)을 익힌 지는 얼마 안되지만(필자는 리눅스에서만큼은 C 언어 도구 중독증의 |
| - 전형적인 예였다) “문제를 해결하는데 있어 한 가지 이상의 방법이 존재한다 |
| - (There’s more than one way to do it)”는 모토를 갖는 펄은 실용성과 함께 도구 |
| - 중독성을 갖고 있는 흥미로운 언어라고 생각한다. Write Once Run Everywhere라는 |
| - 환상적인 모토를 갖고 있는 Java보다 선호하는 언어가 있다면 단연 펄이다. 현실 세계의 |
| - 불완전성 때문에 완벽한 WOWE는 불가능하다. 현실 세계의 문제가 복잡하기 때문에 |
| - 펄도 복잡하다고 이야기하는 솔직함이 더욱 마음에 든다. |
| - |
| - 숙련자든 비숙련자든 같은 문제를 서로 다른 펄 코드로 해결할 수 있다. |
| - |
| - 특히 펄 버전 5에서 OOP(객체 지향 프로그래밍) 스타일의 모듈(Module)이 도입되면서 |
| - 단순 관리용 스크립트가 아니라 C 언어가 할 수 있는 거의 모든 일을 해내는 다목적 |
| - 언어로 발돋움하였다는 점에 주목하고 싶다. |
| - |
| - |
| - Java? |
| - |
| - 등장과 함께 모든 언어를 평정할 듯 위세가 당당했던 Java는 자바 가상머신 |
| - JVM, 자바 프로세서와 관련된 성능 문제라는 악성 문제를 안고 있으며 요즘에는 |
| - Jini 등 Java 본연의? 정보가전, 이동형 장치로 돌아가고 있다는 인상을 지울 수 |
| - 없다. 썬 스팍/솔라리스 조합이 Java 프로세서/운영체계로 바뀔 것이라 생각하는 |
| - 사람은 없을 것이다 |
| - |
| - |
| - 여러분의 생각은 어떠한가? |
| - |
| - |
| - DataBase |
| - |
| - 마이크로소프트사의 마이크로소프트 SQL 서버도 중요한 서버라고 하겠지만 |
| - 리눅스에서 사용할 수 없다는 이유로 누락시켰다. 앞으로 회사의 데이터베이스 |
| - 인프라를 윈도우 NT 플랫폼으로만 국한시키겠다는 생각이 아니라면 |
| - 리눅스/유닉스에서 운영 가능한 데이터베이스를 선택할 수밖에 없다. |
| - |
| - 역시 특정 제품이 중요한 것은 아니다. 데이터베이스 제품에 지배를 받아서야 |
| - 되겠는가? 두루두루 사용될 수 있는 데이터베이스를 배우는 것이 현실적인 |
| - 선택이다. |
| - |
| - 리눅스에서 사용 가능한 경량급 데이터베이스 중 mSQL을 사용하고 있는 사람이 |
| - 있다면 MySQL(http://www.mysql.com) |
| - 또는 PostgreSQL(http://www.postgresql.org)를 고려해 보기 바란다. |
| - |
| - 리눅스 사용자라면 오라클, 인포믹스 중 하나, 그리고 MySQL, PostgresQL 중 |
| - 하나 이렇게 두 가지를 익혀두면 현재와 미래에 도움이 되리라 생각한다. |
| - |
| - |
| - |
| - !! 언어는 무조건 많이 익힐수록 좋다! |
| - |
| - 영어 잘 하는 사람이 일어를 배우면 해가 될까? |
| - 영어, 일어, 불어, 독어 얼마든지 많이 알아두는 것이 좋다. 모든 언어는 배울 만큼의 |
| - 가치를 충분히 가지고 있다. 무엇보다 여러 언어를 알아야 언어에 대한 비판도 가능하다. |
| - |
| - 웹 애플리케이션이라면 요즘에는 다음 두 가지를 익혀야 한다. |
| - |
| - * SQL(Structured Query Language, 관계형 데이터베이스 질의 언어) |
| - |
| - * PHP3(http://www.php.net) |
| - |
| - 인터넷을 비롯한 네트워크화가 진행되어 감에 따라 데이터베이스의 중요성이 놀라울 |
| - 정도로 높아졌다. 모든 자료는 데이터베이스화되기 시작했다. 이때 필요한 것은 역시 |
| - SQL이라는 사실에 대부분의 사람들이 동의할 것이다. 오라클(Oracle), |
| - 인포믹스(Informix)와 같은 유명한 SQL 데이터베이스가 있으며, 리눅스에서는 mSQL, |
| - MySQL, PostgreSQL 등 일반인들에게는 잘 알려져 있지 않으나 오픈 소스 공동체 |
| - 사이에 잘 알려진 중소규모 SQL 데이터베이스도 있다. |
| - |
| - SQL 데이터베이스에서 중요한 것은 SQL 자체가 아니라 데이터베이스 디자인이다. |
| - 무조건 이것저것 자료 구조를 만들어 보고 실습하는 방법밖에 없다. 이론적인 서적을 |
| - 잘 소화하는 사람은 데이터베이스 이론 서적을 읽으면 좋다. 데이터베이스는 프로그래밍 |
| - 분야 중에서 가장 이론적인 분야 중 하나이다. |
| - |
| - PHP는 리눅스 등 오픈 소스 공동체에서 유명한 웹 서버 쪽 스크립트 언어로 |
| - 마이크로소프트사의 ASP에 비유할 수 있다. 그러나 스크립트 언어의 본고장인 |
| - 유닉스/리눅스에서 개발된 PHP는 ASP를 기능이나 다양성, 그리고 속도 모든 면에서 |
| - 능가한다는 평가를 받고 있다. 최근 리눅스 서버이면서 동적인 페이지를 만들어 |
| - 내고 있는 곳이라면 거의 모두 PHP 아니면 펄(Perl)을 사용하고 있다. |
| - |
| - 끝으로 다시 한 번 강조할 것은 “언어 자체는 절대로 중요하지 않다”는 것. |
| - 언어 중심적으로 사고하면 특정 언어의 노예가 되고 만다. 프로그래머란 |
| - 디자이너라는 사실을 잊지 않기 바란다. 중요한 것은 디자인, 프로그래밍에 앞선 |
| - 조사와 분석이다. |
| - |
| - |
| - Hello World를 여러 가지 언어로 나타낸다면? 이라는 질문에 몇 가지 언어의 예가 있다. |
| - |
| - 기타 언어들이 많지만 하나의 문제를 해결할 수 있는 여러 가지 방법을 알고 선택할 |
| - 수 있는 프로그래머가 되길 바란다. 프로그래밍 언어에 지배되지 말고 프로그래밍 |
| - 언어를 확실하게 지배하길 바란다. |
| - |
| - |
| - !! 무조건 많은 코드 애플릿을 작성한다 |
| - |
| - 무조건 많은 소스 코드를 읽는다! 영어를 잘 하려면 무조건 영어로 된 글을 많이 읽고 |
| - 영어로 말하는 것을 많이 듣고 영어로 말해야 한다. 그 밖의 방법은 없다. |
| - 우리가 한국어를 잘 하는 이유는 단 한 가지 매일매일 쉼 없이 사용하고 있기 |
| - 때문이 아닌가? |
| - |
| - 프로그래밍 “언어”도 마찬가지다. |
| - 다음은 많은 사람들의 공통 경험일 것이다. 쓰지 않으면 잘 알았다고 생각했던 것도 |
| - 잊어 먹는다. 필자의 경우 C 언어야 정말 오랫동안 사용해 왔고 시행착오를 많이 |
| - 겪었기 때문에 잘 잊지 않지만 BASIC, FORTRAN, CLIPPER 등의 언어는 이미 잊은 지 |
| - 오래이다. 잘 사용하지 않은 C쉘에 대한 것은 가장 기본적인 것 이상은 기억하지 못한다. |
| - Java도 마찬가지다. Java를 배우기는 했으나 실전에서 응용하지 않기 때문에 |
| - Java를 배웠다는 기억만 있을 뿐이다. |
| - |
| - 애플릿(applet) 코드, 즉 매우 작은 크기의 코드를 작성하는 습관이 중요하다고 본다. |
| - 큰 욕심에는 커다란 노력이 드는 법. 작은 코드를 자주 작성하도록 하자. |
| - 이런 면에 있어 펄(Perl)과 같은 스크립트 언어는 최고의 선택이라는 것이 개인적인 |
| - 생각이다(그래서 펄을 열심히 다시 배우고 있다). |
| - |
| - 또는 최소한 남의 코드 읽는 일을 게을리 하지 말자. 가장 표준적인 남의 코드로는 |
| - 유명 유닉스 프로그래밍 서적의 예제가 있다. 그 다음은 여러분이 관심 있는 영역의 |
| - 오픈 소스 프로그램의 소스 코드를 분석하는 일이다. 이 모든 것이 직접 코드를 |
| - 짜보는 일보다 확실하지는 않지만 직접 코딩하는 일이 아닌 최선의 방법은 이것밖에 없다. |
| - |
| - |
| - !!프로그래밍, 컴퓨터 이외의 것에 관심을 갖자 |
| - |
| - 커널 해커, 컴파일러 설계자가 아닌 이상 응용 소프트웨어를 만들기 원하는 사람은 |
| - 프로그래밍, 컴퓨터가 아닌 완전히 다른 주제의 인생을 즐길 필요가 있다. |
| - |
| - 전혀 관계없는 책도 많이 보고 영화도 많이 본다. 영화를 보면서 우와~ 저런 이미지 |
| - 처리를 나도 해볼 수 있다면 하고 생각해 본다. 그리고 돌아와서는 이미 나와 있는 |
| - 성과를 조사하기 시작한다. 이미 잘 만들어져 있는 바퀴를 다시 발명하는 |
| - 일(reinvent the wheel)은 없도록 하자. GIMP나 POVRAY와 같은 프로그램이 있다는 |
| - 것을 알아내고 분석에 들어간다. 기여할 바가 있으면 기여한다. |
| - |
| - 게임 프로젝트에서 스토리를 짜는 것은 전문적인 사람의 몫이긴 하지만 |
| - 환타지(fantasy)류의 소설이나 기타 흥미로운 소설을 읽고 그것이 재미있다고 생각하지 |
| - 않는 프로그래머라면 단순 게임 프로그래밍이 재미있을까? |
| - |
| - 프로그래밍 언어가 소프트웨어를 위한 도구이듯 결국 컴퓨터 소프트웨어도 결국에는 |
| - 그 어떤 것에 대한 도구이다. 컴퓨터만을 위한 소프트웨어도 있지만 이 세상에서 |
| - 제일 쓸모 있는 것은 실생활을 위한 또는 환상을 채워 줄 수 있는 소프트웨어라고 |
| - 생각한다(썰렁해 보여도 공장 자동화(FA)에 사용되는 소프트웨어를 만드는 |
| - 일은 매우 의미가 있다.) |
| - |
| - 그리고 시리얼 장치나 기타 다른 인터페이스 장치를 이용하여 어떤 기계 장치를 |
| - 제어하는 소프트웨어는 그 나름의 엄청난 매력을 지니고 있다). |
| - |
| - |
| - !!진정한 해커(hacker, not cracker)가 되고 싶다 |
| - |
| - 우선 해커와 크래커를 구별할 줄 알아야 한다. 해커는 나쁜 의도를 가진 녀석들 |
| - 정도라고 생각한다면 아직 리눅스 문화에 익숙하지 않은 초보자일 뿐이다. |
| - |
| - Hacker is good, but cracker is bad. |
| - |
| - 유치한 의도로 남의 시스템을 침입하고 싶어하고 각 운영체계의 보안 버그 족보를 |
| - 뒤지는 사람은 크래커라 부른다. 이런 사람들의 프로그래밍 실력은 사실 보잘 것 없다. |
| - 생쥐와 같은 얍삽이 능력을 가졌을 뿐이다. |
| - |
| - 보통 “리차드 스톨맨 씨를 이 시대 진정한 마지막 해커”라고 부를 때의 그 해커 |
| - 개념을 생각해주기 바란다. 해커의 기본 자질이라면 유닉스를 자유자재로 쓰는 것은 |
| - 물론이고 프로그래밍 언어라는 도구를 잘 다루고 그 내부에 대해서도 잘 아는 수준. |
| - |
| - 진정한 해커, 즐기는 프로그래머가 되려면 대화, 협력하면서 코딩하는 습관을 |
| - 가져야 한다. |
| - |
| - 바로 리눅스, 오픈 소스 소프트웨어가 성장한 방식이다. |
| - |
| - 해커는 항상 온라인 상태여야 한다. 뉴스그룹(예를 들어 comp.os.lang류의 개발 |
| - 언어 관련 뉴스 그룹)에 참여하거나 웹 페이지(예를 들어 국내의 경우라면 |
| - 최준호(junker)씨의 홈페이지(http://www.kr.freebsd.org/~cjh/)를 가지는 것이 |
| - 일반적이다. 메일링 리스트를 만들어 사람들의 의견을 나누면서 개발하는 것도 |
| - 좋은 방법이다. |
| - |
| - |
| - !! 기존의 프로젝트에 열심히 참여하는 것은 정말 훌륭한 일이다. |
| - |
| - 특히 리눅스 세계에서는 현재 커널 이외에도 GNOME, KDE 등 능력 있는(어느 정도 |
| - 여유도 있는) 젊은 고등학생/대학생 개발자를 항상 필요로 하고 있다. |
| - |
| - 물론 어느 공개 프로젝트에 참여하여 일한다는 것은 아무리 작은 프로그램이라 |
| - 할지라도 상당한 관심을 필요로 한다. 이런 점에서 필자는 빵점이다. |
| - |
| - |
| - |
| - !! 프로그래밍을 포기할 때 |
| - |
| - 모든 사람이 프로그래밍을 해야 할 필요는 없다. 또는 프로그래밍에서 자연스럽게 |
| - 멀어져 가기도 한다. 프로그래밍을 하지 않고 많은 시간을 허송세월하고 있다면 |
| - 프로그래밍이 자기에게 별로 맞지 않는다는 자연스런 반증이다. |
| - |
| - |
| - |
| - !! 프로그래밍은 의무가 아니다. |
| - |
| - 그리고 의무여서도 안된다. 프로그래밍도 생계의 한 좋은 수단인 것은 분명하지만 |
| - 앞서 이야기한 무엇인가를 갖추지 못하면 특히 “프로그래밍에 빠져” 있지 않으면 |
| - 프로그래밍 의무는 창조력 없는 단순 노동이다. 재미없는 프로그램의 디버깅은 사람의 |
| - 피를 말리기까지 한다. 여러분의 건강을 심각하게 고려하기 바란다. |
| - |
| - 잘 진행되지 않는 프로젝트에 대해서는 곰곰이 생각해 봐야 한다. 프로그래밍은 |
| - 완력으로 해결할 수 있는 성질의 것이 아니다. 컴퓨터가 제대로 작동하지 않는다고 |
| - 해서 TV에서 보는 것처럼 손으로 한 번 탁 쳐서 문제가 해결되지는 않는다. |
| - |
| - 어떤 프로젝트를 제대로 끌고 갈 수 없다면 두 가지 중 하나이다. 원래부터 여러분의 |
| - 현재 능력으로는 불가능한 프로젝트이므로 잠시 접어두어야 할 필요가 있다. 또는 |
| - 처음 생각과 달리 진행함에 따라 흥미를 잃은 경우이다. |
| - |
| - 끈기도 중요하지만 안되는 것을 되게 하려고 하거나 흥미롭지 않은 일을 밀어붙이려고 |
| - 하지는 말자. 일단 접어두고 그 이유를 분명히 하자. 여러분이 할 수 없는 일에 |
| - 집착하는 것은 시간 낭비이다. 희망 사항은 원대할 지라도 아직 프로그래밍을 |
| - 해야 하는 사람이 아닌 경우에는 자기가 할 수 있는 범위의 일을 찾아서 해내길 바란다. |
| - |
| - 꼭 어려운 과제를 풀어야 느는 것은 아니다. 자기가 잘 할 수 있는 것을 공고하게 |
| - 구축하는 것도 좋은 전략 중 하나이다. |
| - |
| - |
| - |
| - !!원하면 할 수 있다! |
| - |
| - 프로그래머가 되겠다는 생각은 누구로부터의 강압으로는 만들어질 수 없는 자유의지이다. |
| - 프로그래머가 되겠다는 생각을 갖는 사람 자신은 확실한 자기 체험을 하지 않으면 |
| - 안된다. 직접 컴퓨터를 사용하면서 훌륭한 소프트웨어를 경험하던가 아니면 |
| - 스타크래프트(Starcraft)와 같은 명작 오락을 해보는 수밖에 없다. 그리고 |
| - 소프트웨어라는 이 무형의 물건에 감동해야 한다. |
| - |
| - 원하기만 하면 누구나 프로그래머가 될 수 있다. 특히 리눅스와 FreeBSD와 같은 |
| - 오픈 소스 환경이라면 프로그래머가 되겠다는 생각을 먹자마자 그 자리에서 즉시 |
| - 프로그래밍을 시작할 수 있다. C/C++/쉘/Perl 등 모든 프로그래밍 도구가 준비되어 |
| - 있지 않은가? |
| - 이리저리 친구들에게 돌아다니면서 비주얼 C++/비주얼베이식 불법 복사본을 구할 |
| - 필요가 없다. 사실 오픈 소스 소프트웨어 환경은 일반 사용자라기보다는 |
| - “여러분처럼 프로그래밍하고 싶어하는 사람들”을 위해 나온 것이다. 그리고 |
| - 앞으로도 그러할 것이다. |
| - |
| - |
| - ! 게으름(laziness), 성급함(impatience), 자기 과신(hubris) |
| - |
| - |
| - 펄 언어의 저자인 래리 월씨는 상당한 이야기꾼으로 유명하다. |
| - 성공적인(프로그래밍을 잘한다는 점에서) 프로그래머가 되기 위해서 갖추어야 할 |
| - 덕목으로 3가지를 꼽고 있다. |
| - |
| - |
| - !! 1. 게으르지 않으면 안된다? |
| - |
| - 모든 발명과 창조는 게으름에서 나오는 것일까? 일의 처리 과정을 조금 더 편하게 |
| - 해보자는 생각이 없다면, 즉 좀더 게을러지고 싶지 않다면 “좋은 프로그램”은 |
| - 나오지 않는다. |
| - |
| - |
| - !! 2. 성급해야 한다? |
| - |
| - 어떤 일 처리 결과가 여러분의 생각보다 늦게 나오면 이를 참을 수 없어야 한다! 왜 |
| - 빨리 안 나오는 거야? 컴퓨터 세상에 관한 한 성인군자는 별 도움이 되지 않는 듯 |
| - 그리고 무엇보다도 자기 과신(확신?)이 있어야 한다. 필요 이상의 겸손은 추진력을 |
| - 주지 못한다. 여러분의 소스 코드에 대하여 확신을 가지라. 만약 목표한 일을 어떤 |
| - 식으로든 문제없이 해결했다면 소스 코드가 아마추어적인 수준이든 아니든 간에 없는 |
| - 것과는 비교할 수 없을 정도로 가치가 있다. 주저하지 말고 현재 배운 기술만 가지고 |
| - 코딩을 시작하라. 실제로 코딩을 하지 않은 사람의 비판을 너무 진지하게 받아들일 |
| - 필요 없다. |
| - |
| - 한 줄이라도 코딩하느냐 않느냐는 천지차이이다. 어떤 소프트웨어든 버전업이 |
| - 있기 마련이다. 그리고 일정 시점에 가면 모든 것을 다시 디자인해야 할 때가 |
| - 오고야 만다. 디자인이 2-3차례 변화되고 나면 그때에서야 안정적인 프로그램이 나온다. |
| - |
| - 여러분이 작성한 소스 코드는 지금 당장 생각으로는 자기 과신할 수 있을 정도로 |
| - 잘 짜여 보일 지 모르나 처음 소스 코드가 끝까지 남아있는 경우는 없다고 확신하라. |
| - 소프트웨어는 근본적으로 패치 레벨업과 버전업으로 진화하는 무형의 생물이다. |
| - |
| - |
| - !! 3. 기왕 하는 것 즐겁게 하자! |
| - |
| - 프로그래밍을 너무 진지하게 생각할 이유는 없다. 생계를 꾸려가야 하는 문제는 |
| - 그때 가서 생각해도 늦지 않는다. 여러분이 갖추어야 할 것은 프로그램 디자인 |
| - 능력, 기술, 무엇보다도 활력이라고 생각한다. |
| - |
| - 자기가 좋아하는 주제를 가지고 자신을 만족시키는 프로그램 코드를 만들어 보자. |
| - CPU 자원만 잡아먹을 뿐인 예쁘장한 프로그램을 만들면서도 얻을 수 있는 것은 많다. |
| - 마우스 화면을 따라 뛰어다니고 화면에서 낮잠을 자는 공양이 프로그램, |
| - 네코(Neko)를 아는가? 필자가 좋아하는 쓸모 없는(?) 프로그램 중 하나는 GNOME |
| - 프로젝트의 패널(panel)에서 물방울만 뻐끔대는 완다(Wanda)라는 이름의 물고기 |
| - 애플릿이다. 적어도 그 사람은 그 프로그램을 만들면서 즐거워했을 것이 분명하다. |
| - 그리고 필자와 같이 만족하는 사람들이 있으니 성공한 것 아닌가? |
| - |
| - 우선 여러분을 위한 코드를 만들자. 이 세상에는 여러분과 같은 관심을 갖는 |
| - 사람들이 있기 마련. 그러다 보면 어느새 상당히 많은 사람을 즐겁게 하는 |
| - 소프트웨어로 진화하기 마련이다. 필자가 좋아하는 리눅스가 바로 그러한 |
| - 전형적인 예이다. |
| - |
| - |
| - |
| - 그래픽 프로그래밍을 원하는 사람들을 위한 링크 |
| - |
| - - Qt 라이브러리 (http://www.troll.no) |
| - |
| - - gtk+ 라이브러리 (http://www.gtk.org) |
| - |
| - - KDE 프로젝트 (http://www.kde.org) |
| - |
| - - GNOME 프로젝트 (http://www.gnome.org) |
| - |
| - 리눅스에서의 그래픽 프로그래밍은 SVGA 프로그래밍과 X 윈도우 프로그래밍으로 |
| - 크게 나눌 수 있다. 현대적인 프로그래밍은 역시 X 윈도우 프로그래밍이다. |
| - |
| - 이미 리눅스 설치와 함께 X 윈도우가 설치되어 있으며 컴파일러인 gcc(또는 |
| - 최신 egcs)가 설치되어 있기 때문에 프로그래밍 준비가 되어 있다. |
| - |
| - 우선은 간략하게 최하위 레벨의 프로그래밍 API인 Xlib 프로그래밍을 아주 |
| - 짤막하게 마친다(자료가 많지는 않지만 구식 정보이기는 해도 나우누리나 |
| - KLDP에서 Xlib 프로그래밍에 대한 필자의 글을 찾을 수 있을 것이다. |
| - 너무 큰 기대는 하지 말기 바란다). |
| - |
| - 실제로 본격적인 X 윈도우 프로그래밍은 모티프(Motif), Qt, Gtk+ 등의 라이브러리를 |
| - 이용하게 된다. 이 중 모티프는 비싼 비용을 주고 구입해야 하는데다 최근에 나온 |
| - Qt, Gtk에 비해 고물에 가까울 정도로 구식이어서 피하길 권장한다. |
| - |
| - Qt, Gtk를 사용하여 진행되고 있는 KDE, GNOME 프로젝트 결과물을 보고 어떤 |
| - 프로그램을 만들 수 있는지 감을 잡아 보라. 어리고 젊은 많은 프로그래머들이 KDE, |
| - GNOME과 같은 대형 공개 프로젝트에 뛰어들기를 바란다. |
| - |
| - 지금 당장 하자! |
| - |
| - 앞서 말한 것처럼 조급할 필요가 있다. |
| - |
| - - 리눅스 시디를 구입하거나 다운로드 받아서 일단 리눅스를 설치하고 본다 |
| - 리눅스 설치 자체가 상당한 훈련일 것이다. |
| - |
| - - 리눅스 서적, 온라인 문서, 프로그래밍 서적을 구할 수 있는 대로 구해서 닥치는 |
| - 대로 읽고 실험해본다. |
| - |
| - - 마음껏 망쳐도 좋은 하드디스크 하나를 큰 맘 먹고 구입하는 것이 좋다. |
| - 리눅스를 만지다가 리눅스가 이상해지면 처음 2-3번은 편하게 지우고 다시 |
| - 설치하면 그만이다. 리눅스가 망가지지 여러분이 망가지지는 않는다. |
| - |
| - - C 컴파일러인 gcc 사용법을 간단하게 익힌다. |
| - KLDP 사이트 또는 나우누리 리눅스 동호회에 가보면 상당히 오래 전에 작성한 |
| - 글이지만 필자가 작성한 gcc 안내서가 있을 것이다. 오래 되긴 했어도 변한 것은 |
| - 거의 없다. 아니면 여자 친구 또는 남자 친구와의 데이트를 한 번 |
| - 줄이고(아프다고 거짓말하든 말든) 리눅스 프로그래밍에 관련된 책을 하나 큰 맘 |
| - 먹고 구입한다. |
| - |
| - - 얇은 C 책부터 굵은 책으로 전진하며 정복한다. |
| - 필자의 경험상 굵은 책부터 하면 사람의 집중력 수준상 일부 천재를 제외하고는 |
| - 자연스럽게 흐지부지 포기하고 만다. 여러분이 프로그래밍을 좋아하지 않아서가 |
| - 아니라 단지 인간적인 집중력이 떨어지기 때문이다. 그래서 필자는 얇은 |
| - 책부터 시작한다. 그리고 좀더 굵은 책으로 전진한다. 그러면 책들이란 서로 |
| - 비슷한 부분을 많이 가지고 있기 때문에 두 번째 책부터는 훨씬 빨리 읽어 |
| - 내려갈 수 있다. 세 번째, 네 번째도 마찬가지이다. |
| - |
| - 필자의 책꽂이에는 C 프로그래밍 책이 10권 정도 되는 것 같다. 하지만 앞으로도 |
| - 계속 구입할 것이다. 또는 계속 프린팅할 것이다. |
| - |
| - - 동시에 쉘과 펄(Perl)을 배워본다. |
| - 쉘, 특히 펄은 유닉스다운 멋을 지닌 언어이다. 펄의 경우 많은 사람들의 다양한 |
| - 코드를 쉽게 보고 익힐 수 있는 문화가 잘 조성되어 있다. |
| - |
| - - 무조건 컴파일 많이 하고 설치도 많이 해본다. |
| - 프레쉬 미트(http://freshmeat.net) 사이트에 가보면 리눅스와 기타 오픈 소스에 |
| - 관련된 소프트웨어가 매일매일 발표된다. 그것을 가져다 컴파일하여 설치해본다. |
| - |
| - 여러분 마음에 드는 소프트웨어가 있을 것이다. 우선 시작한지 얼마 안되는 |
| - 프로젝트에 참여하라. 소스 크기 아직 크지 않을 때부터 참여하는 것이 이해하는데 |
| - 도움이 될 것이다. |
| - |
| - 운좋게 버그를 발견했다면 패치를 만들어 저자에게 보내본다(안되는 영어라도 |
| - 힘겹게 써본다. 몇 번 보내보면 매번 똑같은 영어를 사용하기 때문에 그렇게 |
| - 어렵지 않을 것이다). |
| - |
| - 모든 것을 여러분이 처음 시작할 필요는 없다. 여러분이 버그 보고나 패치를 통해 |
| - 기여하면 그 소프트웨어는 여러분의 것이다. |
| - |
| - - 소스를 많이 본다. |
| - 현실 세계의 프로그램 소스는 책에서 본 것보다 훨씬 지저분하고 체계적이지 않다. |
| - 왜냐? 현실 세계의 문제는 책에서보다 훨씬 더 복잡하기 때문이다. |
| - 남의 소스를 읽다보면 주석(comment) 문제나 들여 쓰기 문제(indent)에 대하여 |
| - 자연스럽게 고민하게 되고 상대방의 악습을 통해 반사적인 학습이 가능하다. |
| - |
| - |
| - |
| - |
| - 행운을 빈다. 앞으로 여러분을 온라인에서 즐겁게 만날 수 있기 바란다. |
| - |
| - |
| - |
| - ! 관련 링크 |
| - |
| - - 오렐리 출판사 홈페이지 http://www.ora.com |
| - |
| - - 펄 홈페이지 http://www.perl.com |
| - |
| - - 국내 펄 관련 홈페이지 중 하나 http://www.perl.co.kr |
| - |
| - - 펄 뉴스 그룹 news://han.comp.lang.perl |
| - |
| - - 리눅스 뉴스 그룹 news://han.comp.os.linux |
| - |
| - - 최준호씨 홈페이지 http://http://www.kr.freebsd.org/~cjh/ |
| - |
| - - LDP(리눅스 문서 프로젝트 홈페이지) http://sunsite.unc.edu/linux |
| - |
| - - KLDP 홈페이지 http://kldp.org |
| - |
| - |
| = 홈피 보안에 문제가 있네요..%%% |
| = 검색해서 들어왔는데 이렇게 액세스할 수 있다니..%%% |
| = 조속히 문제 해결하시기 바랍니다.%%% |
| = 구글 검색으로 여기에 접근됩니다%%% |
| = |
| = \>글쎄요.. 여기 자료들은 다 링크 걸려 있구.. %%% |
| = 보안상 다른 사람들이 봐서 안될 만한 문서는 없다고 생각하는데요;;;%%% |
| = 누구신지 필명이라도 남겨주시지.. ^^%%% |
| = \right -- [빠바기] <small class="small">2008-05-07 18:01:41</small> |
| + |
