JDBC 2.0 Optional Package API specification: (new)
NOTE: The javax.sql package is also called the JDBC 2.0 Optional Package API
(formerly known as the JDBC 2.0 Standard Extension API). ftp://ftp.javaservice.net/pub/java/spec/jdbc20.stdext.pdf (327,005 bytes)
최근 게시물을 불러올때 하나의 레이어 부분에 여러 개시판을 탭으로 불러오는 소스 우선 버전까지 넣고 계속 업그레이드를 해볼 예정이다...ㅋ 사용 방법은 아래 사용법 보기를 클릭하면 볼 수 있다.
var cview = new bbs_tab(); // 함수 선언하기 cview.add(str '게시판아이디', str '게시판주소', bool 클릭시닫기); // 불러올 게시판 탭 추가 communityView.view('bbs2'); // 처음 불러올 게시판 아이디 탭 추가에서 게시판주소는 두번째 클릭 했을경우 해당 게시판으로 이동 그리고 게시판제목 부분에는 onclick으로 communityView.view('bbs2'); 를 넣어주고 해당 링크의 아이디는 게시판아이디_link 로 통일 시킨다. 예) <a href="#c" id="bbs3_link" onclick="communityView.view('bbs3');" class="ic2">유머</a>
2007.01.12 : 두번 클릭 시 안보이게 하는 기능 추가 2007.01.19 : 전역변수 생성자에서 선언하게 변경 for문을 쓰지 않고 선택된 부분과 전에 선택된 두개만 변경하도록 수정 2007.07.20 : 이벤트 객체 이미지 롤오버 추가 이벤트 객체에 스타일 클래스 추가할 수 있도록 수정
bbs_view string method 선택 이벤트 타입 : click(onclick), roll(onmouseover) boolean isClose 선택 이벤트 일어났을 경우 타겟을 닫을것인지 확인 string _tab 선택 이벤트가 일어날 객체 boolean img_chg 선택 이벤트가 일어날 객체가 이미지일 경우 rollover 할것인지 */ function bbs_view(method, isClose, _tab, img_chg) { this.version = '0.21'; this.itemCount = 0; this.item = new Array(); this.selectedId = null; this.isClose = isClose ? true : false; this.closed = true; this.method = method ? method : 'click'; this._tab = _tab ? _tab : '_tab'; this.img_chg = img_chg ? true : false; this.className = '';
if(this.img_chg) { this._on = '_on'; this._off = '_off'; this.extReg = "(\.[^\.]+)$"; // 확장자와 구분자를 분류하는 정규식 this.onSearch = new RegExp(this._on + this.extReg); this.offSearch = new RegExp(this._off + this.extReg); }
this.add = function(id, url) { var classObj = this; var url_ = url ? url : null; var obj = el_id(id); // 클릭시 나타나는 레이어 var obj_tab = el_id(id+this._tab); // 클릭할 링크나 이미지
1.package명을 정한다.
업무구분 및 기능별 또는 구현기술별로 구분이 쉽도록 naming rule을 정한다. 이는 후에 javadoc를 이용한 자바 API를 구현할 때 필수적이다. EJB를 사용한다면 화면당 name의 상위 package명이 EJB명이 되도록하여 하나의 EJB가 여러화면을 서포트하는 형태를 만드는 것이 좋다. 또는 USE CASE당 하나의 EJB를 만들 수도 있다.
2.공통 class를 가능한 많이 만든다.
모든 서블릿 또는 EJB들이 같이 사용하는 로직을 가능한 많이 공통 class로 만들어 낸다. 또한 READ ONLY 멤버변수/메소드에 대하여는 static 멤버변수/메소드를 활용한다. 공통 class 도출시에는 유연성을 생각하여 향후 확장성을 염두에 두고 생성한다. (getInitialConext(),getConnection() 등등)
3.System.out.println( ) 의 사용을 최소화한다.
개발이외의 운영시에는 가능한 최소화한다. 또는 verbose와 같은 환경변수를 지정하여 ebug용 log의 on/off를 가능케 한다.
4.문자열 연결시에 “+=” 사용보다는 StringBuffer 객체를 사용한다.
문자열 연결은, 다량의 임시 객체를 생성하도록하여 성능의 저하를 유도하므로, 이의 사용은 근본적으로 좋은 습관이 아니다. 문자열(String)은 변경될 수 없으므로, 문자열의 연결은 임시 객체의 생성을 초래하고 이는 GC(garbage collection)와 CPU에 부담을 준다. 그러나 StringBuffer 객체를 너무 크게 잡으면 다량의 사용자가 접근시에 메모리를 할당 받지 못하는 경우가 생길 수 있으므로 StringBuffer의 사이즈를 너무 크게 잡지는 말아야 한다.
5.JDBC 커넥션 풀링을 사용한다.
웹로직은 데이터베이스 커넥션 풀링 기능을 제공한다. 이는 프로그램상에서 직접 데이터베이스에 접속하는 시간이 2-3초 인 것을 감안하여 웹로직이 미리 커넥션 풀을 통하여 데이터베이스와 연결을 맺고 있으므로 서블릿 또는 EJB에서는 웹로직의 커넥션 풀에 수 miliSecs 만에 접속할 수 있도록하여 데이터베이스에 접속하는 시간을 줄여준다.
6.JDBC 커넥션을 사용한후 JDBC 자원을 반드시 반환한다.
JDBC 커넥션을 close()하지 않을 경우, 웹로직은 JDBC 커넥션을 아직도 사용하는 것으로 인식하여 다른 사용자가 사용하지 못하도록 한다. 이는 웹로직으로 요청되어지는 request들이 데이터베이스와 연결을 하지 못하여 큐에 쌓이게 되고 이것이 쌓이다 보면 웹로직의 hang을 야기시키는 직접적인 원인을 제공하게 된다. 그러나 GC(garbage collection)수행시에는
자원 반납이 이루어 진다.
서블릿,JSP 프로그래밍
1. HttpSession
가. 웹로직은 4가지 type의 Session Persistence를 제공한다.
Memory (single-server, non-replicated)
File system persistence
JDBC persistence
In-memory replication (across a cluster)
나. 어떠한 방식을 사용할 것인가.
가장 성능이 좋은 것은 Memory를 사용하는 것이다(cluster일때는 In-memory replication). 여러머신이 클러스터링 되어 있을 경우 하나의 웹로직이 shutdown 또는 kill 되어질때 또 다른 웹로직서버로 session 데이터가 옮겨지게 된다(failover 기능). 기존의 방식이었던 JDBC persistence방식은 session의 수와 Object의 size에 따라 엄청난 성능차이를 보이며 매번 데이터베이스 트랜잭션이 발생하므로 데이터베이스 및 웹로직에 부하를 주게된다.
다. HttpSession은 언제 만들 것인가.
서블릿일 경우
HttpSession을 체크하는 일반적인 로직일 경우 HttpSession의 데이터를 가지고 체크하는
것보다는 HttpSession의 존재여부를 가지고 체크하는 것이 성능을 더 향상 시켜준다.
매번 새로운 HttpSession을 만드는 것은 피해야 한다.
//로직화면이 아닌 경우(이미 만들어진 HttpSession을 가져다 사용한다)
HttpSession session = req.getSession(false);
if ( session == null || session.getValue("juminid") == null)
resp.sendRedirect("/Login"); // 로긴화면으로 분기
JSP일 경우
JSP에서 HttpSession을 디폴트로 생성시키므로 이는 피해야 한다.
<%@ page session = “false” %>
라. HttpSession에 넣는 객체의 수 및 size는 가능한 적게 한다.
마. HttpSession을 다 사용한 후에는 제거한다.
웹로직의 기본 HttpSession 유지시간은 최종 사용한 시간에서 1시간(3600초)동안이다.
weblogic.httpd.session.timeoutSecs=3600 (weblogic.properties내에 설정)
그러나 이전에 HttpSession을 더 이상 사용하지 않을 것이라면 제거시켜준다.
2. 서블릿에서 동기화(Synchronization)를 가능한 사용하지 않는다.
서블릿은 멀티쓰레드로 동작되기에 하나의 코드에 대하여 많은 쓰레드들이
작업을 수행한다. 그러나 코드가 동기화가 되어있다면 동기화된 코드에 대하여는
실제적으로 한번에 한 쓰레드밖에 작업을 수행할 수가 없다.
따라서 멀티쓰레드방식이 아닌 싱글쓰레드방식이 되는 것이다.
그러나 순차적으로 update되어야 하는 코드와 같이 동기화가 반드시 필요하다면
동기화되는 코드의 양을 최소화 시켜준다.
Public void doGet(…..) {
synchronized(this) {
동기화가 필요한 코드;
}
}
3. SingleThreadModel 을 사용하지 않는다.
SingleThreadModel은 사용자 마다 각각의 서블릿 인스턴스를 만듦으로써 서블릿의 수행능력을
떨어뜨린다. 이는 웹로직 4.5.1 이전버젼에서의 ServletServlet를 사용할 때와 같다.
4. 단 한번만 처리하면 되는 작업들은 HttpServlet의 init() 메소드 또는 JSP의 jspInit()메소드를 사용한다.
서블릿 또는 JSP의 init(),jspInit() 메소드는 단 한번만 수행되어지므로 이를 잘 활용하게 되면
서블릿에서 동일한 작업들이 여러 번 반복 수행되는 것을 피할 수 있다.
한번만 호출하여도 되는 작업에는 어떠한 것이 있나. ?
1)JDBC class 얻기
public class JDBCServlet extends HttpServlet
{
private javax.sql.DataSource ds = null;
public void init(ServletConfig config) throws ServletException {
super.init(config);
Class.forName("weblogic.jdbc.pool.Driver").newInstance();
}
public void deGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException
Connection conn = getConnection();
…..
}
}
2)DataSource 얻기
public class JDBCServlet extends HttpServlet
{
private javax.sql.DataSource ds = null;
public void init(ServletConfig config) throws ServletException {
super.init(config);
Context ctx = getInitialContext();
ds = (javax.sql.DataSource)ctx.lookup(“connPool”);
ctx.close();
}
public void deGet(HttpServletRequest req, HttpServletResponse res)
throws ServletException, IOException
Connection conn = ds.getConnection();
…..
}
}
3)Context, Home 얻기
여기에는 개발환경에 따라 어디까지를 init()메소드에서 얻을 것은가를 정해야 한다.
소스는 위(2))와 동일하다.
(Context 얻기, Home interface 얻기)
주의사항) RemoteObject는 freepool에 다수의 인스턴스로 서비스를 한다.
그러나 init()에서 RemoteObject까지 얻었을 경우는 하나의 RemoteObject만이
서비스를 하게되므로 다수의 사용자가 동시 접근시 성능저하의 원인이 될 수있다.
4)해당 서블릿에서만 사용 되어지는 코드성의 데이터
코드성 데이터객체를 멤버변수로 만들어 init()에서 DB의 코드 테이블을 조회한 후에
그 객체를 생성시켜 이후에 호출되어지는 서블릿의 service()들은 DB에서 조회하지 않고
멤버변수의 코드성 데이터객체를 참조하여 코드값을 가져온다.
EJB 프로그래밍
1.EJB Entity Bean의 접근은 EJB Session Bean을 통해서 접근한다.
클라이언트 또는 서블릿에서 EJB Entity Bean의 접근은 절대적으로 피해야 한다.
그보다는 EJB Session Bean안에서 접근해야만 한다. 이렇게 함으로써 클라이언트가
Entity Bean의 Remote 메소드의 호출 횟수를 감소시킬 수 있다. 클라이언트는
Session Bean만을 호출하고 Session Bean이 Entity Bean을 호출한 후 그 결과를
모아 Entity,Vector 또는 특정한 객체형태로 클라이언트에 반환하게 된다.
또한 트랜잭션과 관련되어서 여러 Entity Bean을 하나의 Session Bean에서 모아
하나의 트랜잭션으로 관리할 수가 있다.
2.EJB Home의 재사용
위에서 이미 설명했듯이 경우에 따라 Context, Home를 재 사용하여
성능향상을 기대할 수 있다.
(웹로직 클러스터링이 적용된 경우는 EJB Home을 재 사용하게 되면 EJB bean의
HotDeploy시 문제가 발생하게 된다.)
3.단 한번만 처리하면 되는 작업들은 ejbCreate() 메소드를 사용한다.
서블릿과 같은 원리로 단 한번만 처리하면 되거나 또는 코드성의 데이터 객체들은 EJB의
ejbCreate() 메소드에서 처리한다.
코드성 데이터객체 사용시의 주의사항)
stateless Session Bean을 예를 들어 max-beans-in-free-pool의 갯수가 100개라고
가정했을 때 코드성 데이터 객체의 사이즈가 1M 라고 한다면 최대 100M 까지의 메모리를
Session Bean이 점유할 수도 있다. 따라서 서블릿과는 달리 EJB에서 사용시에는 주의가 요구된다.
4.Entity Bean사용시에도 조회는 Session Bean을 이용한다.
Entity Bean은 데이터 로직처리 및 트랜잭션 처리를 위한 것이므로 트랙잭션과 관련된
사항들(즉, 입력,수정,삭제)은 Entity Bean을 사용하는 것이 효율적이다. 그러나,
조회와 같이 트랜잭션이 없는 사항에 대해서는 Entity Bean보다는 Session Bean에서
직접 JDBC 커넥션 풀을 사용하여 수행하는 것이 성능이 좋다.
Entity Bean사용시 특히 많은 row을 조회할 때 각각의 row 마다 Entity Bean 객체가
만들어지므로 성능 저하의 원인이 된다.
5.EJB Entity Bean에서 Read-Only 메소드를 사용한다.
EJB Entity Bean에 관한 배치 명세서(deployment descriptor)를 설정시, Read-Only 혹은 Const로
getter 메소드를 마크할 수 있다. Read-Only 메소드만으로 구성된 트랜잭션이 수행시에는
Entity Bean의 상태동기화(state synchronization)가 데이타베이스에 요청되지 않는다.
6.Transaction Isolation Level를 적절히 조정한다.
기본적으로, 대부분의 개발자는 트랜잭션 isolation level를 TRANSACTION_SERIALIZABLE로
설정하여 EJBs를 배치한다. 웹로직 또는 웹게인의 EJB 배치 툴에서의 기본 값이다. 이것은 최고의
오버헤드를 지닌 최상의 제한적인 트랜잭션 isolation level이다.
대부분의 어플리케이션에서는 TRANSACTION_READ_UNCOMMITTED만으로도
충분한 isolation level일 것이다.
EJB 트랜잭션 isolation level은 배치 명세서 내에서 설정을 하기 때문에, 같은 EJB는 다른 트랜잭션
isolation level으로 다른 어플리케이션 상에서 재사용될 수 있다.
isolation level의 필요조건과 성능향상을 위하여 적절한 조정을 검토하라
7.Stateful Session Bean 사용후에는 제거한다.
stateful session bean의 인스턴스는 특정한 클라이언트와 연관되어 있다. 이 bean들은 클라이언트에
의해서 명시적으로 제거될 때까지 혹은 타임아웃시에 컨테이너에 의해서 제거될 때까지 컨테이너에
존재할 것이다. 그 동안에, 컨테이너는 디스크로 비활성화된 stateful session bean를
passivate할 필요가 있을 지도 모른다. 이것은 컨테이너에 대한 오버헤드를 요구하게 되고
어플리케이션에 대한 performance hit를 야기시키다. 만약 passivate된 stateful session bean이
바로 뒤이어 어플리케이션에 의해 요청되어진다면 컨테이너는 디스크로부터 읽어들어 활성화되어
질 것이다.
종료시 stateful session bean을 명시적으로 제거함으로써 어플리케이션은 비활성화(passivation)에
대한 요청이 감소할 것이고 컨테이너에 대한 오버헤드를 줄일 수 있다
종래에는 홈페이지가 자국인들만 이용할 것을 예상하고 제작하므로써 외국인 즉, 비한글 사용자들에 대한 서비스를 미쳐 염두에 두지 못하므로써 한글이 ?????$%^&( 처럼 깨져 보이는 무지함을 보였던 것이 사실입니다.이제는 홈페이지 제작도 유니코드(UTF-8) 인코딩 방식이 세계적 추세이며 이러한 추세에 맞추어 MySql도 기본언어를 utf8(UTF-8 인코딩) 방식으로 변경하였으므로, 홈페이지를 종래 euc-kr 등 한글로만 표기하던 방식도 UTF-8 인코딩 방식으로 업데이트해야 할 때 입니다. UTF-8 인코딩 방식은 한국어, 일어, 중국어, 태국어, 아랍어 등 만국어 표기가 가능한 방식입니다.
APM에서 UTF-8을 구현하려면 꽤 많은 부분을 수정해야 합니다 .
다음은 APM에서 UTF-8 구현 방법과 소스코드를 첨부합니다. 원본 저자 아래 환경에서 적용 테스트 .
----------------
OS : WinXP SP2
Apache : httpd-2.0.52
PHP : php-5.0.3
MySQL : mysql-4.1.11
---------------- wono77 같은 방식으로, 아래 환경에서 적용 테스트 성공.(글추가 2006년 5월 24일)
-----------------------------
OS : Linux Redhat 9.0
Apache : httpd-2.0.52-3 PHP : php-5.1.2
MySQL : mysql-5.1.7-beta
-----------------------------
1. apache 환경파일 편집 (httpd.conf)
2. php 환경파일 편집 (php.ini)
3. mysql 환경파일 편집 (my.cnf)
4. apache, mysql 서비스 재시작
5. mysql에서 캐릭터셋 확인 및 디비생성
6. php 소스코드에 mysql_query("set names utf8;"); 함수 추가
7. php 소스에 한글문자열이 있으면 파일저장할때 UTF-8 파일형식으로 저장
8. 웹브라우즈의 보기-인코딩-UTF-8로 선택1. /etc/httpd/conf/httpd.conf 에서 캐릭터셋 수정
/*------------
AddDefaultCharset UTF-8
2. /etc/php.ini 에서 캐릭터셋 수정
/*------------
;default_charset = "iso-8859-1"
default_charset = "utf-8"
3. /etc/my.cnf 에서 캐릭터셋 수정
/*------------
[client]
#password = your_password
default-character-set=utf8
4. 환경변수를 모두 수정후 apache 및 mysql 서비스 재시작
/*------------
5. mysql에서 캐릭터셋 확인
/*------------
# mysql
Welcome to the MySQL monitor. Commands end with ; or \g.
Your MySQL connection id is 247 to server version: 4.1.10a
Type 'help;' or '\h' for help. Type '\c' to clear the buffer.
아무 책방이든 상관없이 들어가서 보면, 7일 안에 자바(Java) 완성이외에 비주얼 베이직(Visual Basic), 윈도우(Windows), 인터넷(the Internet)을 불과 몇시간 또는 몇일에 정복하기의 제목의 책들을 끝없이 나란히 진열된 것을 볼 것이다. Amazon.com에서 다음과 같은 고급(파워) 검색을 했었을때
결과가 무려 248개나 나왔다. 첫 78개는 컴퓨터 관련 책 이었다 (79번은 30 일안에 벵골어 배우기였다.) 나는 "일"대신 "시간"를 입력해봤다. 몇일을 " 몇시간으로" 대체했었을때 놀랍게도 아주 근접한 결과을 얻었다: 곁에 따르는 253개의 책중에 77개의 컴퓨터 책이였고 제 78에 24 시간안에 문법 직접배우기이 있었다. 결과의 최고 200개에서, 96%은 컴퓨터 책 이었다.
이런 결과를 보고 결론 지을 수 있는 것은 컴퓨터를 배울려고 하는 사람들의 큰 붐이 있거나, 컴퓨터를 배우기는 그 어떤것보다도 엄청 배우기 쉽다는 것이다. 베토벤, 물리학, 또는 심지어 개 손질법을 단 몇일 안에 정복하기라는 책은 없다.
정복하기: 3 일 안에 규모있는 프로그램을 쓸 시간이 없다 그리고 그 프로그램을 쓰는데 성공 아니면 실펴함으로의 경험을 통해 배우지 못한다. 경험있는 프로그래머와 같이 일하고 그런 환경 속에서 일하는 것이 어떤 것이가를 알 수 없다. 짧게 말해서 많은 것을 배울 시간이 없다. 그러므로 이런 책 내용들은 깊은 내용들은 물론 못하거니와 표면상으로 이해 할 수 있는 내용들만 다룰 수 밖에 없다. Alexander 로마 교황 말했듯이, 조금만 배우는 것은 위험한 것 이다.
Pascal: 3일안에 Pascal의 문버은 배울 수 있을지는 몰라도 (특별이 미미 비슷한 언어를 알고 있다면) 그 분법을 어떻게 제대로 쓰는지를 배울 수는 없다. 예를 들어, 당신이 Basic 프로그래머이라면 Pascal의 분법으로 Basic 스타일의 프로그램을 짤 수 있을지는 몰라도 Pascal이 어떤 과제 위해 좋으며 무슨 일를 위해 나쁜지 배울 수 없다. 내 취지는 무엇인가? Alan Perlis는 이렇게 말했다: "당신의 프로그램잉 관한 생각 하는 부분에 영향을 미치지 않는 언어는 아니면 배울 가치가 없다. 당신이 업무를 때문에, 현재 쓰는 도구와 연결해서 쓰기 위해 Pascal(또는 더 현실적인 Visual Basic이나 JavaScript)를 약간 배웠다고 하자. 그러나 당신은 프로그램잉을 어떻게 하는 지를 배운 것이 아니라 업무를 어떻게 완수하는지를 배운 것이다.
몇일 안에: 다음 글에 설명하듯이 몇일 가지고는 터문이 없이 부족하다.
10년 안에 프로그램잉을 정복하기
체스, 음악 작곡, 미술, 피아노, 수영, 테니스, neuropsychology 연구, 위상 수학, 등, 어느 많고 다양한 분야에서 전문가가 되기 위해서는 보통 십년 정도가 걸린다고 연구자(Hayes와 Bloom)들은 말한다. 지름길은 없다. 4살때 부터 신동이라 불려진 Mozart도 세계적인 음악을 만들기까지 13년이 더 결였다. Beatles는 1964년도에 Ed Sullivan쇼에 출연하고, 연속 #1 히트들로 단숨에 유명해 졌다. 하지만, 그들은 1957년도 부터 Liverpool과 Hamburg의 작은 클럽에서 활동을 시작했었고, 일찍부터 mass appeal이 있었지만, critical success는 1967년도에 Sgt. Pepper로 비로써 이루어냈다. Samuel Johnson는 10년보다 더 오래 걸린다고 생각했다: "탁월함은 일생의 노력과 노동에 의해여만 달성할 수 있다; 그 것은 그 이하의 값으로 이룰 수 있는 것이 아니다." Chaucer는 "the lyf so short, the craft so long to lerne"라고 호소했다.
여기서 프로그램임을 정복하기 위한 나의 비법이 있다:
먼저 프로그램임에 흥미을 가지고, 재미로 조금만 해보십시오. 10년를 투자할 만큼 충분히 재미를 느끼는 것이란 걸 확인해라.
다른 프로그래머들과 대화를 하십시오; 다른 프로그램들의 소스를 읽으십시요. 이것은 어떤 책또는 훈련 과정보다는 더 중요하다.
프로그램잉을 하십시오. 최선의 학습방법은 하면서 배우는 것이다. 더 전문적으로 표현하자면, "특정 영역안에 개인의 성과 극대 수준은 장시간 경험의 기능으로서 자동 적으로 달성하지 않는다. 그러나 성과의 수준은 개량하는 의도적인 노력의 결과으로서 높은 경험자들도 증가될 수 있다(p. 366)." "효과적인 학습은 개인에게 적당한 수준에 어렵고 분명한 업무, 유익한 피드백과 반복과 과실을 고칠 수 있는 기회를 요구한다." (p. 20-21) 인식의 실제: 매일 생활 속의 마음, 수학 및 문화는 이 관점에 관련된 재밌는 참고서다.
원한다면, 대학에 4년을 (또는 대학원에 더) 투자하십시오. 학위는 자격증을 요구하는 직업에 취직 자격을 줄 것이다, 그리고 분야에 더 깊은 이해를 주지만, 학교에 관심이 없다면 (노력을 한다면) 직업을 통해서 비슷한 경험을 얻을 수 있다. 어찌됐든, 혼자서 책으로만 배우는 건 부족하다. "솔과 안료을 공부함으로 전문화가가 될 수 없듯이 아무나 컴퓨터 과학 교육으로만 전문프로그램어를 만들지 못한다."라고 Eric Raymond가 The New Hacker's Dictionary에 적었다. 내가 이제까지 고용한 최고의 프로그래머중 한 사람은 고졸이였다. 그는 좋은소프트웨어를 많이 만들었고, 그의 고유 뉴스 그룹도 가지고 있으며, stock option으로 나보다 더 부자임은 틀림없다.
다른 프로그래머들과 같이 프로젝트들을 하십시오. 때론 프로젝트의 가장 실력있는 프로그래머가 되고; 때론 프로젝트의 가장 실력없는 프로그래머가 되라. 가장 실력있는 프로그래머일땐 다른 사람들에게 비젼을 주고 그리고 사람들을 이끄는 능력을 시험하게 된다. 가장 실력없는 프로그래머일때는 고수들이 하는 것들과 그들이 싫어하는 것들을 배울 수 있다 (왜냐면, 싫어하는 것들은 당신에게 시킨다).
다른 프로그래머들을 시작한 프로젝트에 뒤늦게 동참하십시오. 다른사람이 짠 프로그램을 이해하도록 몰두하십시오. 원래 프로그래머가 없었을때 그 것을 이해하고 고치기 위해서 무엇이 요구되는지 보십시오. 당신의 프로그램을 다른 사람이 유지해야 할때 보다 더 쉽게 관리 할 수 있도록 어떻게 당신의 프로그램들을 디자인해야 할까를 고민하십시오.
최소 다섯가지 프로그램잉 언어를 배우십시오. class abstractions (자바 또는 C++) 지원하는 언어, coroutines을 (Icon 또는 Scheme) 지원하는 언어, functional abstraction (Lisp 또는 ML) 지원하는 언어, syntactic abstraction (Lisp) 지원하는 언어, declarative specifications를 (Prolog또는 C++ 템플렛) 지원하는 언어, 그리고 parallelism을 (Sisal) 지원하는 언어를 한개씩 배우십시오.
"컴퓨터 과학"안에 " 컴퓨터"가 있는 것을 기억하십시요. 당신의 컴퓨터가 한 명령을 실행할때, 메모리에서 word를 가지고 올때, 디스크에서 연속 word를 가지고 올때, 디스크안에 새로운 위치를 찾을 때 걸리는 시간과 속도를 아십시오. 답
언어 표준화 노력에 참여하십시오. ANSI C++ 위원회 일 수도 있거나, 당신의 현 코딩 스타일을 2칸 아니면 4칸 들여쓰기 할 것인가를 결정할 수도 있다. 다른사람들이 한 언어의 어떤 것을 좋아는지, 그들에게 그 것들이 얼마나 중요한 것인지, 어쩌면 왜 그것을 좋아하는지까지도 알게 될 것이다.
가능한한 빠르게 언어 규격화 노력에서 해방되는 좋은 느낌을 채험해 보십시오.
위것들을 고려할때, 책 학습으로만 어디까지 배울 수 있을까를 의심해볼 여지가 있다. 내 첫째 아이가 태어나기 전에, 찾을 수 있는 모든 How To 책들을 읽었지만, 그래도 초보자로 느껴졌다. 30달 후에, 둘째 아이가 태어났을때 쯤, 난 예전에 읽었던 책들을 다시 들여다 봤을까? 아니다. 대신 나는 전문가가 쓴 천장의 페이지보다도 나에게 더 유용고 자신감을준 내 개인 경험에 의지했다.
Fred Brooks는, 그의 에세이 No Silver Bullets에 굉장한 소프트웨어 디자이너들을 찾아주는 three-part계획을 확인했다:
체계적으로 가능한한 빨리 최고 디자이너들을 확인하십시요.
유력 후보자의 발달과 경력 파일을 책임질 경력 지도자을 선임하십시오.
성장하는 디자이너들이 서로 자극할 수 있는 기회들을 제공하십시오.
이 것들은 이미 굉장한 디자이너가 되기 위해 필요한 자질들을 가지고 있다고 가정한다. 직업이 그들을 적당하게 coax할 것이다. Alan Perlis은 그 것을 명확하게 표현한다: "조각하는 방법은 누구나에게 가르칠 수 있다: Michelangelo는 조각 방법을 못하는 방법을 가르켜 줬을야 했을 것이다. 훌륭한 프로그래머들도 마찬가지다."
이렇게 전방 가고 자바 저 책을 사십시요; 너는 사실 같게 그것의 얼마간 사용을 밖으로 얻을 것이다. 그러나 너는 24 시간, 일,또는 조차 개월안에프로그래머으로서 너의 일생, 또는 너의 진짜 전부전문가적 의견을 변경하지 않을 것이다.
T. Capey가 Amazon의 Complete Problem Solver Page에 "Teach Yourself Bengali in 21 days"와 "Teach Yourself Grammar and Style" 책들을 "Customers who shopped for this item also shopped for these items" 구역에 보여주고 있음을 지적했다. 이 책들을 본 사람들 중에 많은 사람들이 이 페이지에서 찾아 가고 있는 가보다.
invalid-file
RECENT COMMENT