we're permanently stuck with every bad design decision released in a JDK로드 존슨 등이 맹렬하게 비난하는 JDBC나 JavaMail의 경우는
more..
켄트 벡이 정의한 단순한 디자인/설계의 네 가지 규칙. OAOO(Once And Only Once)
- 모든 테스트를 실행할 수 있어야 한다.(Runs all the tests.)
- 중복된 로직이 없어야 한다. 병렬 클래스 계층구조와 같은 숨은 중복에 주의해야 한다.(Has no duplicated logic. Be wary of hidden duplication like parallel class hierarchies.)
- 프로그래머들에게 중요한 모든 의도를 알려줄 수 있어야 한다.(States every intention important to the programmers.)
- 클래스와 메서드는 가능한 적어야 한다.(Has the fewest possible classes and methods.)
이들 중에서 개발자 커뮤니티에서 국내외를 불문하고 가장 파장이 큰 것은 ajax입니다. 국내 서점에 출시된 서적들의 숫자로 국내의 인기를 추정할 수 있습니다. 해외의 경우는 작년 최대의 화두로 꼽히고 있구요. 수많은 라이브러리가 존재하는 것을 통해 영향력을 알 수 있습니다.
AJAX는 Asynchronous JavaScript and XML의 약자이지만, 굳이 Javascript와 DOM이라고 표현한 이유는 꼭 XML만 쓰일 수 있는 것은 아니기 때문이죠. AJAX에서 javacript는 브라우저(클라이언트)에 기능을 추가해줍니다. 다양한 동적인 움직임을 가능하게 해주죠. 웹에서 드래그 앤 드롭을 구현한다거나 부드럽게 오르 내리는 UI 컴포넌트의 움직임들이 단적인 예라고 할 수 있습니다. 물론, 이들은 행위가 강화된다는 것을 알려주는 두드러진 특징일뿐, 사용자 이벤트에 대한 반응이 강력해진다는 것이 더 중요합니다.
자바 스크립트가 제공하는 풍부해진 기능에 내용을 채우는 것이 DOM(Document Object Model)입니다. 서버에서 받은 데이터는 DOM을 통해서 화면의 적절한 위치에 나타날 수 있습니다. 물론, 자바스크립트와 CSS의 도움을 받게 되죠. 데이터를 실어 나르는 용기 혹은 차량 역할을 하는 것이 대개 XML인데요. 굳이 XML이 아니라 일반 테스트나 JSON 혹은 HTML 등으로도 전송이 가능합니다.
Ajax 구현을 돕는 수많은 라이브러리 혹은 프레임워크가 있는데 간단하게 주요 목록만 뽑아보죠.
An Open Source AJAX Comparison Matrix에서 5점 척도로 Ajax를 비교한 자료
ActiveX 컨트롤. ActiveX 컨트롤은 IE와 함께 널리 사용된다. 대부분의 전자 상거래를 위한 인증서도 ActiveX 기술을 사용하고 있고, 대다수 포털 사이트의 편집기도 ActiveX를 이용하여 구현되었다. 웹 하드와 같은 것을 사용해본 경험이 있다면 RIA의 사용자 경험을 상당수 맛본 것이라고 할 수 있다. 국내 SI 산업에서 최근 급속도로 확산되는 X-인터넷 도구들은 대부분 ActiveX 기반이다. Ajax나 Flex와 달리 ActiveX 컨트롤은 Internet Explorer(당연히 OS는 윈도우)에서만 구동한다는 제약을 갖고 있다.
국내에 유독 ActiveX 기술이 득세하는 이유에 대해서는 다음의 칼럼에서 잘 설명해준다:
ActiveX 문제의 진실
첨부:
사용자를 자바 개발자에 국한하여 산정한 통계인 듯 하다.
출처: Most Popular Java / Ajax Frameworks
최근에는 모두가 "loosely coupled"를 외친다. 산재된 이슈와 레거시와의 융화, 타 기업과의 잦은 연동의 필요성 등은 "loosely coupled"의 동기이다. RoR은 "tightly-coupled" 혹은 "monolithic" 측면을 갖고 있었다. 그럼에도 불구하고 좋아 보이는 것은 도메인 중심으로 초점이 맞춰져 있다는 점이다. 단순히 추측에 지나지 않지만 자바 진영에서도 DDD를 실현해내려면 RoR 스타일의 도메인 중심의 프로그래밍 스타일을 찾아내야 할 것 같다.
컴퓨터 관계된 일 하는 사람이 아닌 일반인에게 G메일의 편리함을 이야기해봐야 이상한 눈으로 쳐다볼 뿐이다. 다른 개발자들과 이런 얘기를 여러 차례 했었는데 아주 단적으로 정리한 글이 올라왔네.
네이버를 향해 모두 우향우~
태그 파일로 복잡한 태그를 단순화 하는 일은 화면 출력 내용/로직의 캡슐화로 볼 수도 있고, HTML에서의 중복 제거로 볼 수도 있다. 설명을 위해 사용할 예제 페이지는 Encapsulating Reusable Content Using Tag Files의 코드를 일부 수정했다.
<%@ taglib tagdir="/WEB-INF/tags" prefix="h" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/core"
prefix="c" %>
<%@ taglib uri="http://java.sun.com/jsp/jstl/functions"
prefix="fn" %>
<html>
<head><title>Hello</title></head>
<body bgcolor="white">
<img src="younghoe.png">
<c:set var="greeting" value="Hello" />
<h2>${greeting}, my name is Younghoe. What's yours?</h2>
<form method="get">
<input type="text" name="username" size="25">
<p></p>
<input type="submit" value="Submit">
<input type="reset" value="Reset">
</form>
<c:if test="${fn:length(param.username) > 0}" >
<h2><font color="black">${greeting}, ${param.username}!</font></h2>
</c:if>
</body>
</html>
노란색으로 칠한 부분이 중복 사용되어서 태그 파일로 분리하려 한다 가정해보자.
위와 같은 용법으로 쓰고 싶다. 태그 파일을 하나의 컴포넌트로 보면 일종의 컴포넌트 인터페이스를 설계하는 것이다. 태그의 이름을 결정했고, 인자로 전달할 두 개의 속성명을 결정했다. 이제 태그 파일을 정의해야 한다.
직관적으로 이해할 수 있는 작성법이다. 매크로(Macro)를 써본 경험이 있는 사람이라면 데자뷰 현상을 느낄 수 있다. 태그 파일 사용부를 수정했고, 태그 파일 작성도 끝났다. 이제는 배포(deployment)하는 일이 남았다. 태그파일 빌드(build)는 JSP 처럼 동적으로 수행된다.
Sun의 튜토리얼에 따르면 배포하는 방법은 두 가지이다. 하나는 WEB-INF/tags에 위치시키는 것이다. 태그의 이름과 태그 파일의 이름이 같아야 하고, 확장자는 tag가 되어야 한다. 이러한 컨벤션을 따라 주면 별도의 설정이 필요 없어 편리하다.
또 한가지 방법은 jar에 포함시키는 방법인데.. 자세한 내용은 링크만 남긴다.
1. Customer Team Member
XP에서는 고객(Customer)이 시스템의 기능과 우선 순위를 정한다. 고객은 사용자를 대표하는 사람일 수도 있고, 개발팀과 같은 조직의 업무 분석가나 마케팅 관련자가 될 수도 있다.
고객이 누구건 중요한 것은 XP에서는 고객을 개발팀의 구성원으로 생각한다는 점이다.
2. User Stories
요구사항 분석을 Estimation 즉, 프로젝트에 필요한 비용, 기간과 인력 등을 측정할 수 있을 정도에서 끝내라는 것이다. UP(Unified Process)1를 학습하면서 꼼꼼히 분석을 할 때, 점차 구현에 대한 불안감이 마음에 자리한다. UP에서는 상당기간을 아키텍처를 수립하는 쪽에 중점을 둔다. 매우 잘 조직화 된 개발팀이 아니면 상당히 위험할 수 있다. 기존의 소프트웨어에서 위험요소(Risk)로 인식했던 것을 XP에서는 개발 프로세스의 메커니즘으로 수용해버렸다.
프로젝트 초반에 요구사항에 집중하고, 개발은 잠시 미뤄두는 것이 아니라 요구사항과 구현을 동시에 고려하는 것이다. 매우 바람직한 방향이지만 고객과의 협업 주기가 짧다는 것이 전제되어야 한다. 만일, 일주일에 한번 미팅하는 정도로 요구사항을 정립하는 상황이라면, '글쎄'를 떠올려봐야 하지 않을까.
참고
다음과 같이 자바의 transient 키워드를 사용하여도 동일한 효과를 얻을 수 있다.@Entity public class Employee {
@Id int id;
@Transient User currentUser;
... }
@Id 등의 다른 애노테이션을 getter에 붙여 놓은 경우는 @Transient 역시 getter에 붙여야 정상적으로 적용된다. 이 경우 transient 키워드 역시 효과가 없다.@Entity public class Employee {
@Id int id;
transient User currentUser;
... }
SequenceGenerator나 TableGenerator 애노테이션에서 명시된 주키 생성자를 재사용할 때 쓰인다. 디폴트 값은 공백문자("")이다. 영속성을 갖는 객체의 수를 결정하는 식별자 값의 데이터 타입은 범위를 고려하여 결정해야 한다.
정수형 타입(Integral Types)의 범위는 다음과 같다.
byte, from -128 to 127, inclusive
short, from -32768 to 32767, inclusive
int, from -2147483648 to 2147483647, inclusive
long, from -9223372036854775808 to 9223372036854775807, inclusive
char, from '\u0000' to '\uffff' inclusive, that is, from 0 to 65535
좀 더 사람이 기억할 수준의 정보로 대체하면
byte(1) : -128 ~ 127
short(2) : -32,768 ~ 32,767
char(2) : 0 ~ 65535 (UTF-16)
int(4) : -20억 ~ 20억
long(8) : 헤아리기 힘든 수
참고: The Java Language Specification 4.2.1 항목