'분류 전체보기'에 해당되는 글 1246건

2006.10.10 오마이 뉴스 보다... 댓글 중...
2006.10.09 RAM, Virtual Memory, Pagefile and all that stuff - 요약본
2006.10.08 한가위 그리고 가족
2006.10.04 타짜를 보았다. 2
2006.10.02 처음하는 프로그래밍 [1] - 머릿말
2006.10.02 개구리 올챙이적 생각을...
2006.09.25 SMS 2003에서 SQL 2005를 지원하는가?
2006.09.20 IE7 다이얼로그 상자 크기 - Qucik Update

오마이 뉴스 보다... 댓글 중...

잡글 2006. 10. 10. 19:08

Link : http://www.ohmynews.com/articleview/article_view.asp?at_code=365329
지리산 자락 '함양'이 몸살을 앓고 있습니다
[현장]골프장 건설 등 마구잡이식 난개발로 주민과 군청 갈등
[기사전송] [기사출력] 텍스트만보기 차용택(gimcha1) 기자
촌사람들이 더하다. 2006/10/10 오후 1:50:20

   맹자왈(dj1212) 조회 277, 찬성 0, 반대 3
   자기땅에 골프장을 만들던 공장을 짖던...
   남의 땅가지고서 임자가 법대로 하겠다는 데, 왜 그리 반대하냐?
   남 잘되는것 배 아파서 못 봐준다 이거지...
그렇게 반대만 하고 사니깐, 평생 깡촌에서 살다가,,,,,,,

무슨 생각으로 저런 댓글을 썼을까? 함양땅에 개발하려는 건설 관련 업자 였을까?
남의 땅까지고 임자가.....
저런 생각을 계속 가지고 있으니 언제나 문제만 생기는 것 아닐까?
골프장을 만들던? 공장을 짓던?
그렇게 해서 자신의 시골이 완전히 망가지고 나면? 고작 이용하는 사람은
끊임없이 들어오는 외지인만 이용하고, 쓰레기 널부러져 있고,
생활 환경은 주변에서 부터 바뀐다는 기본 원칙을 모르는 것일가?
점점 저런 공간이 늘어나면 그나마 없는 농민들 마저 다 떠나지 않을가?
그냥 땅팔아서 외지인에게 떠 맡기게 되는 악순환...

도와주지 못할 망정 저런 댓글이나 쓰는 사람은 뭐랄까...(씁쓸..)
댓글에 반대 댓글 쓰고 싶었지만, 오마이뉴스에 아이디가 없어서 내 블로그에
올려 본다.

728x90

하인도1

[하인드/하인도/인도짱 의 홈페이지] 저만의 공간입니다. 다양한 소재들을 나열하는 아주 단순 무식한 홈페이지 입니다. 다양한 문서 자료도 있겠지만, 저의 푸념들도 있답니다.

RAM, Virtual Memory, Pagefile and all that stuff - 요약본

기술자료/OS 2006. 10. 9. 12:06

전체 원본 내용 : http://members.shaw.ca/bsanders/WindowsGeneralWeb/RAMVirtualMemoryPageFileEtc.htm

원본 : http://support.microsoft.com/kb/555223

윈도우를 포함한, 최신 운영체제 대부분은 응용 프로그램이나 각종 프로세스를 실행할 때, 실제 메모리 주소 공간과 매핑되어 있는 가상 메모리 주소 공간 상에서 항상 실행되도록 되어 있습니다. 단지 운영체제 핵심 커널만 실제 메모리 주소 공간을 이용하게 됩니다.
가상 메모리를 항상 이용 함으로써 시스템 상에 설치된 물리적인 램 크기를 넘어서는 용량이 필요한 프로세스들도 정상적으로 동작하게 됩니다.

프로세스와 주소 공간
32 비트 윈도우에서는 실제 시스템 상에 메모리가 얼마이든 간에 모든 프로세스는 4G(Giga Byte)[ 2 ^ 32 -1) ]의 용량의 가상 메모리 주소 공간을 가져올 수 있습니다.
기본 윈도우 설정을 기준으로 4G 중 2G 부분은 프로세스 개별적으로 이용하게 되는 주소 공간이고 나머지 2G는 다른 프로세스 및 운영체제와 공유해서 이용하게 되는 주소 공간입니다.
그래서 보통 응용 프로그램(메모장, 엑셀, 인터넷 익스플로어 등)은 2G 개별 주소 공간내에서 실행되도록 구성 되게 됩니다. 이 때 운영체제는 단지 응용 프로그램에서 필요로 하는 용량 만큼 가상 메모리 페이지 크기에 맞게 RAM상에 페이지 프레임(Page Frame)을 지정하게 됩니다.

여기서 물리 주소 확장(Physical Address Extention : PAE)이라는 기능이 있는데, 물리 메모리 주소를 36 비트로 확장해주는 32비트 아키텍처 입니다.(역주: 32비트 컴퓨터에서는 보통 32 비트의 물리 메모리 주소, 즉 최대 4G [ 2 ^ 32 - 1 ]의 주소공간을 가질 수 있읍니다. 이를 36비트로 확장한다는 의미입니다. 그러므로 최대 64G[ 2 ^ 36 - 1 ]의 주소공간을 가질 수 있게 됩니다.) - 참고 할 만한 정보로는 http://support.microsoft.com/kb/268363 를 보시면 됩니다. 그러나 이 가상 메모리는 PAE로 인해 크기적인 변화가 없으며 단지, 프로세서(CPU)에서 시스템 내에 설치된 메모리의 주소 영역만 확장되는 것입니다.
이 때 프로세스 내에서 동작되는 32Bit 기준의 가상 메모리 주소 공간과 36Bit 메모리 주소 공간 간의 변환 작업은 운영체제에서 관리하는 변환 표(Translate Table)에 따라 하드웨어 상에서 자동적으로 제어되며 투명하게 변환이 됩니다.

다음 목록은 각각 윈도우 버전 및 에디션에 따른 지원되는 최대 램용량입니다.(2004년 11월 현재 기준)
Windows NT 4.0: 4 GB
Windows 2000 Professional: 4 GB
Windows 2000 Standard Server: 4 GB
Windows 2000 Advanced Server: 8GB
Windows 2000 Datacenter Server: 32GB
Windows XP Professional: 4 GB
Windows Server 2003 Web Edition: 2 GB
Windows Server 2003 Standard Edition: 4 GB
Windows Server 2003 Enterprise Edition: 32 GB
Windows Server 2003 Datacenter Edition: 64 GB

페이지 파일
램은 제한 적인 자원인 반면, 가상 메모리는 이상적인 주소 공간이기 때문에 이론적으로 제한이 없습니다. 물론 프로세스 별 최대 할당될 수 있는 주소 크기는 2G입니다. 모든 프로세스들이 사용하는 총 메모리 용량이 실제 메모리의 총 용량을 넘어서면, 운영체제에서는 하나 혹은 여러개의 가상 메모리 주소의 페이지(4Kb 단위의 조각)를 하드 디스크 상에 옮기고, 옮겨진 양 만큼의 메모리 공간을 회수 하게 됩니다. 윈도우 시스템에서는 이들 "페이지 아웃(Paged Out)"된 를 pagefile.sys라고 불리는 파일을 한개 혹은 여러 개로, 시스템 하드 디스크의 루트 디렉토리 상에 저장하게 합니다. 물론 이 파일을 각 하드 디스크의 파티션 별로 하나씩 담을 수도 있습니다. 이 부분에 대한 설정은 시스템 등록정보, 고급, 성능(설정 탭을 클릭)에서 하실 수 있습니다.

가장 많은 질문 내용 중에 "페이지 파일을 얼마나 크게 잡아야 되나요?" 라는 것이 있는데, 사실 이 질문에 대한 정확한 한가지 답은 없습니다. 그 이유는 설치된 램 크기와 작업 중에 가상 메모리 사용량에 따라 달라지기 때문입니다. 그 외 특별한 사항이 없다면, 일반적으로 설치된 메모리의 1.5 배의 용량으로 구성하는 것이 가장 좋은 형태라고 권장하고 있습니다. 서버 시스템 중 일반적인 목적을 위해 구성되어 충분한 램 용량을 갖추어 있다면 굳이 페이지 파일을 구성할 필요는 없습니다. 이런 시스템에서는 큰 페이지 파일을 만들어 제공할 필요가 거의 없는 것이죠. 그러나 다른 한편으로는 간혹 발생될 큰 규모의 메모리 할당이 요구 될 시, 시스템 불안정한 상황이 발생할 수 있습니다. 이런 경우를 대비하기 위해 통상 앞서 말씀 드린 1.5배 이상의 가상 메모리를 미리 잡아 두는 것도 나쁘지는 않습니다.

성능, 아키텍처 상 제한 과 RAM
어느 컴퓨터 시스템이든 간에, 작업량(사용자 수, 업무를 수행하는 개수)이 증가되면 성능(업무를 처리하는데 걸리는 시간)은 감소되게 됩니다. 하지만 이 관계는 비 대칭형으로 진행되게 됩니다. 작업량 증가의 형태가 어느 정도였든간에, 극적인 성능 감소를 넘어서는 지점을 넘어서게 됩니다. 이 의미는 몇몇 자원들이 최악으로 소량 제공되어 결국 병목현상을 불러 일으킨다는 것입니다.

몇몇 지점에서는 최악으로 소량 제공되는 자원들이 증가되지는 않게 됩니다. 이는 아키텍쳐 상 제한에 도달했다는 것을 의미합니다. 윈도우의 아키텍쳐 상 제한에 대한 몇가지 보고 내용은 다음과 같습니다.
1. 시스템 상의 2 GB의 공유 가상 주소 공간
2. 프로세스 당 2 GB의 개별 가상 주소 공간
3. 660 MB 시스템 PTE 저장공간
4. 470 MB 페이지 풀 저장공간
5. 256 MB 페이지 되지 않은 풀 저장 공간

위의 내용은 Windows 2003 기준으로 나열된 사항입니다.(KB 294418 글 참조). 그러므로 Windows XP 및 2000에서는 위의 사항과 다를 수 있습니다.
보통 쉽게 접할 수 있는 권장 사항이 다음과 같은 경우 입니다.
  터미널 서버를 사용하는데, 4GB를 사용하기 전에 공유 메모리인 2G를 완전히 활용하시오.

대부분의 경우 맞기도 하지만, 여러분이 겪는 상황에 따라 다를 수 있습니다. 몇몇 유형 중에, 특정 Windows NT 4.0 또는 Windows 2000 Server에서 충돌이 발생하거나, Windows Server 2003 중에서 불필요할 수도 있습니다. Windows Server 2003으로 넘어오면서 크게 바뀐 부분 중에 보다 효율적으로 이 아키텍쳐상 제한이 발생되는 가능성을 줄였다는 것입니다. 예를 들면 커널 상의 몇가지 프로세스들을 커널 프로세스에서 제외시킴으로써 공유 가상 메모리 사용량을 대폭 줄였습니다.

RAM 및 가상 메모리 사용량 감시하기
성능 감시기(시작, 관리자 도구, 성능)은 시스템의 성능을 측정하고 병목 현상을 실제 일으키는 사항이 무엇인지를 파악할 수 있도록 도와주는 중요한 도구 입니다. 아래에는 이 도구를 이용하여 측정할 수 있는 중요한 정보들에 대한 요약들을 나열합니다.

Memory, Committed Bytes
- 여기서는 가상 메모리의 의존도를 측정하게 됩니다. 운영체제에서 페이지 파일 내에 RAM 페이지 프레임 또는 페이지 슬롯을 적용한(Commited) 바이트 수와 프로세스 상에서 할당한 바이트수가 얼만큼인지를 보여줍니다.(대부분 2가지 동시에). 이 적용 바이트(Committed Byte) 수는 허용된 RAM 용 보다 늘어나게 되면, 페이징이 증가되며, 사용하는 페이지 파일의 총 용량도 증가됩니다. 몇몇 지점에서는 페이징 작업 자체가 실제적인 성능과 직결되어 영향을 미치기 시작할 것입니다.

Process, Working Set, _Total
- 여기서는 "active"하게 사용되는 가상 메모리 용량을 측정하게 됩니다. RAM내의 모든 프로세스들이 실제적으로 사용하는 가상 메모리에 대해 얼만큼의 RAM 필요한지를 보여주게 됩니다. 여기서는 항상 4,096이 곱해져서 나타내는데, 그 이유는 Windows 상에서 페이지 크기로 그 만큼의 크기를 사용하고 있기 때문입니다.가상 메모리가 사용 가능한 RAM 용량을 넘어서서 의존하게 되면, 운영체제 에서는 사용가능한 RAM과 최소 페이징 이용에 대해 최적화하는 Working Set 에 맞추어 프로세스의 가상 메모리의 양을 조절하게 됩니다.

Paging File, %pagefile in use
- 여기서는 페이지 파일이 실제적으로 사용되는 양을 측정하게 됩니다. 페이지 파일이 적절한 크기 인 경우가 언제 인지 측정하기 위해 사용되는 카운터 입니다. 만일 이 카운터가 100을 가지게 되면, 페이지 파일이 완전히 꽉 찼다는 의미가 되며, 몇몇은 작업을 중지하게 될 것입니다. 작업량의 변화에 따라 충분히 큰 페이지 파일이 필요할지 모르지만, 보통 50~70% 이하로 사용되게 됩니다. 만일 사용된 페이지 파일 수가 적다면, 다른 물리 디스크 상에 하나 또는 그 이상을 가질 수 있게 되며, 성능이 증가되게 됩니다.

Memory, Pages/Sec
- 여기서는 대부분은 잘못 인식된 값의 측정되는 내용 중 하나 입니다. 이 카운터의 최고값이 성능이 RAM 부족으로 인해 병목 현상이 발생된 것이라고 정확하게 의미하는 것은 아닙니다. 운영체제에서는 명시된 메모리에 제공될 스왑 페이지와는 다른 목적으로 페이징 시스템이 이용됩니다.

Memory, Pages Output/Sec
- 여기서는 매 초마다 다른 목적으로 RAM 페이지 프레임이 해제되기 위해 가상 메모리 페이지가 페이지 파일로 얼마나 많이 쓰여 졌는지를 보여줍니다. 이 기능은, 페이징이 성능의 병목현상을 일으키고 있는지 여부를 예측할 때 감시 할 때 사용되는 최적의 카운터 입니다.

728x90

하인도1

한가위 그리고 가족

잡글 2006. 10. 8. 14:33

정말이지 한가위 오랜만에 많은 사람이 있었다.
많은 사람이래 봐야, 우리 가족 말고 2가족이 더 있었지만...

몇년도 일까.. 1997년 정도 때 부터 우리 가족이 가진 한가위는
언제나 우리가족 뿐이였다. 물론 고모댁에서도 매년 오셨지만,
2001년인가, 2년인가, 그 때는 잠시동안 안왔었다.

그리고 이번 2006년. 친가쪽인 작은 아버지와 그의 아들인 내 사촌동생녀석이
왔다. 이젠 사촌 동생이라 부를 만큼 커(사실 가끔 나이차 많은 형/누나를 두어
나이 좀 있는 조카라고 부를 수 있을 만큼 나이차가 컸다. 11살?)서 와서
이젠 조금 대하기가 어려울 정도이다.
그리고 고모댁에서도 근자에 거의 보기 힘든 고종 사촌 녀석도 왔다.
사실 이 녀석은 거의 보기 힘들다. 워낙 바쁜 사업을 하다보니
나에게 까지 관심을 갖긴 어렵지 않을까? 간혹 자신의 비 전문인 컴퓨터에 대해서
이런 저런 조언을 구할 때 나를 통하긴 하는데,
나 자신이 또 그런일을 귀찮아 해서..

여튼 두 가족이 함께 어울어져 한가위를 보냈다. 제사를 지내고 밥도 같이 먹고...

매년 이렇게 지낼 수는 없어도, 가끔은 이런 자리가 있으면 한다.
나는 쌍수들고 환영하지 못하겠지만, 부모님의 얼굴에서 보이는 만족감과 충족감을
위해서라도.

728x90

하인도1

타짜를 보았다.

잡글 2006. 10. 4. 22:35

허영만 화백이 그렸던 타짜.
이 만화는 아마도 신문지상에 나왔던 그 만화를 먼저 접했을 것이다.

도박판의 진정한 도박꾼들. 다양한 도박 기술과 속임수를 이용해
속된말로 "호구"들에게서 돈을 뜯어내는 자들이 바로 그 타짜이다.
그 들의 코드를 담은 만화를 영화로 옮긴 것이다.

오늘 친구와 함께 그 영화를 보았다. 사실 큰 기대감 없이 단지 영화를 또 한편 보겠다는 마음에서 출발해서 인지도 모르겠지만, 주연/조연 할 것 없이 너무도 재미있게 그렸으며 사실적으로 그렸다.
어색한 부분도, 속도감도 어느 부분 하나 흠잡을때 없는 또하나의 웰메이드.

화려한 액션이나 그래픽없이도 오로지 시나리오와 연기력만으로도
이렇게 멋진 영화가 나오는 것은 언제나 쌍수 들고 환영한다.

그 중 평경장을 분 했던 백윤식씨은 진짜 허영만 화백이 담고 싶은 미묘한 블랙 코미디를 잘 실어 주었다. 언제나 최고의 사부, 달인의 모습으로 나왔지만, 달궈진 카리스마는 언제 보아도 멋지다.

나도 남자인 이상 김혜수씨의 전라 누드 역시 매력적이다. 특히나 엉덩이의 미묘하게 난 반점에서 눈을 떼지 못했다 -_-;;;;

어쨌던, 이들의 이야기는 정말이지 리얼했고, 만일 이 영화를 보고 도박판에 빠진다고 생각하시는 분들이 있다면.. 내 머리에서는 갸웃이다.
정말 이 영화를 보 고 난뒤 도박을 하고 싶어 질까?
실력이 없을땐 호구로써 타짜들에게 돈을 뜯기며, 타짜가 되기 위한 그 기나긴 고생, 그리고 타짜가 된 후 언제나 폭력 조직과 연루되어 겉으로 보기에는 화려하지만, 결국 쓰레기 인생으로써 비참한 최후를 맞는 모습.... 정말 하고 싶어질까...

멋지게 화려하게 그려졌으며 그 뒤의 쓰디쓴 경험.
이게... 영화이며, 그 뒤에 남겨진 작은 교훈이지 않을까?

728x90

하인도1

처음하는 프로그래밍 [1] - 머릿말

기술자료/.NET 2006. 10. 2. 14:55

지금 부터 동생님을 위해 자그만한 글타래를 펼쳐보려 합니다.
사실 프로그래밍의 프자도 모르는 사람에게, C#이라는 도구를 던져주고
프로그래머 같은 생각을 하며, 프로그래밍을 짜라고 하면 상당히 막막한
입장에 빠집니다.
게다가, 제대로 기능을 활용 못하는 도구를 실행 시켜 맨 도화지 같은 상태에서 프로그래밍을 시작하기란 정말이지 힘든일이 아닐 수 없습니다.
어제 문득 동생님의 프로그래밍을 돕다가 "왜 프로그래밍을 못짤까?" 라는 화두를 나에게 스스로 던져 보았습니다. 물론 프로그래밍을 모른다는 것도 있을 것이며, 제가 잘못 알려준 것도 있으며, 더욱이 제가 C#을 제대로 모르는 것도 있을 수 있습니다.
그러나 그보다 더 근원적인 무언가가 있을 것이라 생각이 되었고, 담배를 입에 물면서 고민을 했습니다.
난 언제 부터 프로그래밍적인 사고를 갖게 된 것일까요? 그래서 지금의 위치에 있는 것일까요? 물론 무척 잘하거나 많이 아는 것은 아니지만, 최소한 이런 저런 기술책을 보면서도 그다지 난해하다고 생각되지 않다고 생각된 내용이 왜 내 동생에게는 난해하다고 생각하는 것 일까요? 내가 나름대로 쉽게 가르친다고 생각도 했고, 나중에 겪을 수 있는 혼란을 미리 예방한다는 생각에 알려주었습니다. 그러나 내 동생은 그렇게 받지 못하고, 도리어 혼란속에 허우적 대고 있다는 것입니다.

결론은 "개구리, 올챙이적 생각을 못한다" 였습니다.

그래서 내 시작이 어떤 것이였는지, 그리고 내가 가진 철학은 무엇인지를 알려주고, 혼란을 최소화 하기 위한 문제/답 스타일의 이야기를 펼쳐 알려줘야 겠다는 생각이 듭니다.

1. 프로그래밍 시작.
내가 프로그래밍을 시작하게된 계기는 무엇일까...라는 생각을 했습니다.
사실 굉장히 개인적인 부분이고, 그 시작이 될 수 있는 부분은 인연과 같은 우연적인 요소가 강하기 때문에, 사실 단언해서 이것이 정답이며 이렇게 걸어야 한다! 라고 말하긴 힘듭니다.

하지만, 제가 만난 사람들과 이야기를 나누면서 프로그래밍을 시작한 계기들을 정리하자면 다음과 같습니다.
- 개인적인 흥미로 시작했습니다.
어릴 때, 게임을 보거나, 자신이 만든 프로그램 결과물이 즐겁거나, 아니면 성취감에 대한
정신적 만족감을 느껴 본 것입니다. 보통은 큰 규모의 프로그래밍 보다는 작은 규모의
프로그래밍, 특히 정답이라는 형태가 잡혀 있는 문제와 답 형식 간단한 구현을 통해 책을
통해 다양한 시도를 하면서 독학을 하게 되었을 것입니다.
- 일을 하다가 시작했어요.
프로그래밍 하는 것을 선배 혹은 사수(자신의 직속 상관)을 통해서 신입사원때 배운 것
입니다. 위를 통해 전수 받는 것이기 때문에, 그 형태는 다양하게 나오게 되는데, 보통
많이 갈구는 스타일한테 배운 사람이 많이 늘더군요. 역시 매를 맞아가면서 배워야
빨리 는다는 아주 원초적인 교육적 원리인 것 같습니다.
- 학원(학교)에서 배웠습니다.
더 이상 시도해볼 것도 없거나, 자신의 실력이 없거나, 돈을 많이 벌 수 있다는 등의
다양한 계기로 인해 학원에서 부터 출발할 수 있습니다. 또는 학교에서 정규 과정을 통해
서 출발 할 수 있습니다. 여기서는 대부분은 정규적인 과정이 있으며 그 중간 중간,
간단한 문제와 답을 함으로써 기초적인 지식을 쌓게 합니다. 물론 Bit 전산원 같이 무척
까탈시러운 과정을 통해 통과할 수 있습니다.
- 기타.
그 외에는 다양한 계기들과 다양한 조건들이 있을 것입니다.

어느 부분 부터 시작된 것인지는 알 길은 없지만, 분명 저 중에 한가지 이거나 2~3가지가 복합적일 것입니다. 이것도 저것도 아니라더라도 기타에 다 걸릴 것입니다(笑). 무엇이 중요하고 잘 판단한 것인지는 개개인 마다 틀린 기준이기 때문에, 어디서 부터 출발하는 것이 좋은지는 알 수 없습니다. 단지, 자신이 어디에 처한지 정도 알 수 있겠죠?

2. 프로그래밍을 위한 자세
사실 프로그래밍을 하기 위한 자세란 딱히 없습니다. 대충 대충 짜든, 설계를 해서 짜든 결과만 제대로 나오기만 해도 반은 먹고 들어갑니다. 하지만, 프로그램 = 일 이라는 공식에 빠진 사람들은 대부분 이 4D(4-Danger)업종에서 발전없이 고생만 하다 나오는 것이 대부분의 패턴입니다. 크게 다르진 않죠. 그래도 곰같이 우직하게 일하시는 분들도 있지만...

여기서 제가 말하고 싶은 것은 2가지 입니다. 물론 이 내용들은 프로그래밍뿐 만 아니라 일 자체를 임할때 필요한 자세입니다.
첫번째는, 어느 방법으로 출발을 했던 일단 프로그래밍에 대해 재미있게 그리고 즐기면서 해야 합니다. 든 일은 재미있고 즐겁게 해야 그 결과가 완벽하거나 두세배의 결과치를 얻을 수 있습니다. 일 자체의 결과물 뿐만 아니라, 스스로의 능력도 배가 되는 것을 알 수 있습니다.
두번째는, 목표를 정확히 하는 것입니다. 내가 무엇을 할 것인지, 무엇이 될 것인지를 알아야 합니다. 내가 프로그래밍으로 무엇을 만들 것인지를 알아야 그 내용을 구현할 수 있을 것입니다. 또한 어떻게 배워야 하는지, 무엇을 더 공부해야 할지를 알 수 있을 것입니다. 거기에 내가 어떤 위치에 도달해야 하는지를 명확하게 하면 보다 더 정확한 목표의식을 가지게 됩니다.
이런 목표의식과 즐겁게 일을 할 수 있는 마음을 가질 수 있거나 그와 유사한 형태까지 갔다면 제가 이제 부터 풀어나갈 이야기들을 쉽게 수용하고 빠르게 배울 수 있을 것입니다.
아니라고 해도, 진행이 조금 늦을 뿐 배우기는 할 수 있을 것입니다.

3. 이야기를 하기 위한 Agenda
이 처음하는 프로그래밍을 위한 특별한 교육 순서는 없습니다. 그렇다고 많은 교재들이 택하고 있는 함수는 어쩌내, 클래스는 어쩌내, 상속은 어쩌내 하는 방법을 택하기엔 지겨울 듯 싶구요. 그래서 프로그래밍에 대한 나만이 가진 생각들을 말씀 드리고, 이 후에 문제와 답을 통해 간단한 프로그래밍을 실제로 구현해도록 합니다.
하다가 더 필요하다 싶으면 더 많은 내용을 이야기 할 것입니다.
다음은 이 이야기를 위한 순서 입니다.

0. 머릿말
1. 프로그래밍이란?
2. 문제와 해결방법
3. C#과 .NET Framework
4. 고객 관리 프로그램
5. 그래픽 프로그램.
6. 정리

728x90

하인도1

개구리 올챙이적 생각을...

잡글 2006. 10. 2. 10:34

어제 동생이 자신이 만들고 싶어하는 프로그램을 짜는데 애를 먹고 있었다.
사실 남의 시간을 뺏는 질문은 나나 내 동생은 별로 즐겨하지 않는다.
(그런점에서 보면, 그런 질문을 대놓고 하는 사람은 왠지 달갑지 않다.)
그렇기 때문에, 동생이 나에게 질문한다는 것 자체가 상당한 용기를 낸 것이고
그점은 높이 산다.

질문 내용은 자신이 이런이런 기능을 구현하고 싶은데, C#으로 도저히 못만드는 것이다.
게다가 프로그래밍은 전혀 해본적 없는데다, 낯선 방법의 생각으로 짜야하기에 더더욱 어려운 것이다. 사람에게 새로운 패러다임을 적용하여 구성하라 하면 무척 힘들어 한다. 늘 A 라는 방식을 기준으로 B를 생각해 왔는데, 뜬금없이 C 라는 방식을 제시하게 되면, 상당히 어려워지게 된다. 더욱이 A와 C가 서로 아무런 연관 관계가 없다면 이 또한 무식하게 힘든 일이 되버린다.C# 문법도 전혀 모르는 상황에서 더욱이 정답없는 최선의 답만을 요구하는 프로그래밍 분야에 대해서 접하다 보니 무척이나 난감한 상태에다 심하게는 좌멸감 까지 들고 있을지 모르겠다. 정답도, 기준도 없는 상황에서 어떻게 짜란 말인가?

그렇다면 이런 프로그래머들에게 어떻게 제시하는 것이 좋을까? 물론 동생과 대담을 통해 이런저런 문제점을 짚어 줄 수도 있고, 내가 직접 구현을 하면서 가르쳐 줄 수 있을지 모르겠다. 그러나 그건 결국 고기를 직접 전해 줄 뿐, 이 후 낚시는 전혀 못하는 사태까지 갈 지 모른다는 이유 모를 우려감이 물씬 물씬 올라온다.

그러다가.... 담배를 피면서 곰곰히 생각했다.
지금 내 동생이 겪는 문제는 난 어떻게 해결 했을까?
아주 간단한 방법이였다. 그냥 실행이 되는 작은 프로그램을 수도 없이 짜보았다. 단 한권의 참고서를 보면서 말이다. 이것도 해보고 저것도 해보고...
그러면서 스스로의 기준점을 만든 것 같다. 아마도 이런 방법을 하라고해야 겠는데....
어떻게 할지는... 잘 모르겠다.
이미 많은 시간이 흘렀고, 그 당시에 겪었던 나만의 문제는 이미 까맣게 잊고 있으니깐.

초보 프로그래머들은 어떻게 하는 것이 가장 좋은 방법일까?

728x90

하인도1

SMS 2003에서 SQL 2005를 지원하는가?

기술자료/개발도구 2006. 9. 25. 18:18

네, 단 SMS 2003 with SP2에서만 SQL 2005를 지원합니다. SMS 2003 with SP2 이전 버전에서는 SQL 2005를 지원하지 않습니다. 만일 이전 버전에 대한 설치 후 업그레이드를 하려면 다음과 같은 업그레이드 순서를 거쳐 진행하셔야 합니다.

업그레이드 순서

1.	SQL 2000 SP3 또는 4를 설치합니다.
2.	SMS 2003 with SP1을 설치합니다.
3.	SMS 2003 사이트 서버를 SP2로 업그레이드 합니다.
4.	SQL 2000 서버를 SQL 2005 서버로 업그레이드 합니다.

지원되는 플랫폼과 시스템 요구사항과 같은 자세한 정보는 Microsoft Download center 에 있는 Supported Configurations Guide SMS 2003 SP2 라는 문서의 "Server Software Requirement"를 보시기 바랍니다.

From : http://www.microsoft.com/technet/prodtechnol/sms/sms2003/techfaq/tfaq02.mspx

728x90

하인도1

IE7 다이얼로그 상자 크기 - Qucik Update

기술자료/ETC 2006. 9. 20. 12:04

이 내용은 예전에 게시했던 dialog sizing in IE7 를 먼저 보신 후 확인하셔야 합니다. 예전 포스트 내용 중 최소 다이얼로그 height 제약에 대한 피드백 내용을 기본으로, 우리 팀에서는 최소 높이를 150에서 100으로 변경하고, 위치에 대한 재 평가를 하였습니다. 이 결과로 다음과 같은 사항들을 생각할 수 있습니다.

IE6 최소 높이에 맞추어 코딩된 다이얼로그에 대한 응용 프로그램 호환성 문제를 줄일 수 있습니다.
다른 브라우저 최소 높이 제공 값에 따른 혼돈을 불러 올 수 있습니다.

다시한번 저희들에게 이런 사항에 대한 피드백을 주시기 바랍니다. 일단 현재 설정한 상황은 계속 유지하도록 하겠습니다.

-Travis
Trident/OM

from IE Blog : http://blogs.msdn.com/ie/archive/2006/09/19/761272.aspx

728x90

하인도1

250x250

블로그 내에 소스 코드 삽입 이사온 기념 스킨도... RSS 전문 기능 비활성화 관련. 스킨 바꾸어 보았습니다. 서버 파일 정리 좀 했습니다.

« 2025/06 »
일	월	화	수	목	금	토
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
29	30

SharePoint 지름신 MOSS 2007 me2dayzm 매뉴얼 moss WSS Azure 것 Tutorial 2010 인터파크 Google Apps Engine e-book 비스킷 개발환경 me2photo 수 me2sms 좀 Buscuit 오류 java 불만 twi2me 블로그 windows 친구 Visual Studio 협업

Total :
Today :
Yesterday :

'분류 전체보기'에 해당되는 글 1246건

검색

공지

보관함

달력

링크

태그 목록

최근 포스트

최근 댓글

카운터

티스토리툴바