사실 프로젝트를 진행해오면서 표준이 필요하다는 생각이 많이 들었습니다. XP에서도 주장하는 것은 죽은 문서를 만들지 말자는 것이지, 문서를 만들지 말자는 것이 아니듯이, 필요한 문서라면, 자주 참고해야 되는 내용이라면 당연히 문서화 하는 것이 맞습니다. 프로젝트가 오래 진행될 수록 네이밍, 클래스 상관도, 기본 설계 방침과 같은 것들에 대한 필요성이 절실했습니다. 아키텍처가 없을 때 같은 일을 하는 메소드가 중복 되고, 어떤 클래스는 크고 어떤 클래스는 작고, 어설픈 패턴적용으로 클래스 간의 관계가 모호하거나 복잡하고, 기능별 처리 주체 불분명해지는 등의 많은 문제를 안게 됩니다. 이런 문제를 책임지고 해결해줄 사람이 바로 아키텍트였습니다. 이 책에서는 아키텍트를 책임 설계자라고도 칭했는데, 아키텍처와 ..
L1과 L2, L3는 컴퓨터 내의 캐시 메모리의 계층들이다. 만약에 컴퓨터 프로세서가 다음 번 연산을 위해 필요한 데이터를 캐시 메모리 내에서 찾을 수 있다면, 그것을 램으로부터 가져오는 것과 비교할 때 많은 시간을 절약할 수 있게 된다. L1이란 "level-1"의 약자로서, 마이크로프로세서 칩 그 자체 내에 마련되어 있는 캐시메모리이다. 예를 들어, 인텔 MMX 마이크로프로세서의 경우에 32 KB의 L1 캐시메모리가 딸려 내온다. "level-2"의 약자인 L2 캐시메모리는 메인 메모리에 비해 더욱 빠르게 액세스할 수 있도록, 별도의 칩이나 확장 카드 상에 구현되어 있다. L2 캐시메모리는 1 MB 정도의 크기가 가장 보편적이다. 그렇다면 L1,L2,L3 캐시 메모리의 차이와 역할은 무엇일까? 1. ..
사실 소프트웨어 개발에서 자바를 사용할 것인가, C++을 사용할 것인가, 윈도우를 사용할 것인가, 리눅스를 사용할 것인가, DBMS는 어떤 것을 사용할 것인가와 같은 기술적인 이슈는 빠질 수 없는 요소입니다. 그렇지만 기술적인 요소들에 대한 이해도가 높고, 능숙한 기술들로 소프트웨어를 개발한다고 했을 때에도 여전히 소프트웨어 개발은 쉽지 않습니다. 제가 천재가 아니라 확실하진 않지만, 천재도 실수를 하더군요. 당연한 것 아니겠습니까? 사람은 불완전한 존재니까요. 그렇다보니 익스트림 프로그래밍(eXtream Programming, 이하 XP)에서는 그런 실수를 줄이기 위해 테스트를 먼저 작성하고 프로그램에 포함 시키는 테스트 우선 프로그래밍(Test First Programming)을 하자고 주장하고 있습..
에러 메시지 에러번호 "WSAEINTR: Interrupted system call" 10004 "WSAEBADF: Bad file number" 10009 "WSACCESS: Permission denied" 10013 "WSAEFAULT: Bad address" 10014 "WSAEINVAL: Invalid argument" 10022 "WSAEMFILE: Too many open files" 10024 "WSAEWOULDBLOCK: Operation would block" 10035 "WSAEINPROGRESS: Operation now in progress" 10036 "WSAEALREADY: Operation already in progress" 10037 "WSAENOTSOCK: Socket ..
현재 윈도우 게임 서버를 만드는 중이다보니 윈도우, MSSQL, MS Visual Studio 에 관심이 많다. 그 중에서 가장 큰 관심대상은 역시나 Visual C++. 나 개인적으로 가장 자주 사용하고, 가장 많은 프로그램을 만들어낸 언어가 C와 C++이기에 펄, 어셈블리와 같은 사용할 수 있는 다른 언어들 보다도 애착이 가는 언어다. 사실 툴만들 때에는 MFC를 사용해왔고, 사용하고 있지만...Native API나, C 표준 라이브러리, C++ 표준 라이브러리를 더 좋아하고 더 자주 사용하기에 그에 대한 관심이 많았다. 그래서 죄송한 이야기지만, 김광태씨의 MFC 9.0 소개보다, 신경준씨의 디버깅 노하우 및 Crash Dump 분석을 듣기 위해 갔던게 사실이다. 결과부터 말하자면... 나에게는 혁..
1. 소스코드 관리 시스템을 사용하고 있습니까? 2. 한방에 빌드를 만들어 낼 수 있습니까? 3. 일일 빌드를 하고 있습니까? 4. 버그 추적 시스템을 운영하고 있습니까? 5. 코드를 새로 작성하기 전에 버그를 수정합니까? 6. 일정을 업데이트 하고 있습니까? 7. 명세서를 작성하고 있습니까? 8. 조용한 작업환경에서 일하고 있습니까? 9. 경제적인 범위 내에서 최고 성능의 도구를 사용하고 있습니까? 10. 테스터를 별도로 두고 있습니까? 11. 프로그래머 채용 인터뷰 때 코딩 테스트를 합니까? 12. 무작위 사용편의성 테스트를 수행하고 있습니까?
- Total
- Today
- Yesterday
- 조엘 온 소프트웨어
- 엘키
- 디버깅
- EzShortcut
- 리버스 엔지니어링
- ruby
- ftp
- EasyExec
- perfmon
- TraceRoute
- 멀티스레드
- 디자인 패턴
- 바로가기 프로그램
- SDL
- 루비 온 레일즈
- NDC2013
- 게임개발포에버
- svn
- CppSQLite
- Ruby on Rails
- MS-SQL
- SQLite Spy
- TDD
- c언어
- 루비
- RoR
- 게임데브포에버
- 임백준
- 좋은 프로그래머
- Rails
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | ||||||
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 |