'전체'에 해당되는 글 11건
- 2007/10/29 SKY 신규제품 IM-S240K (7)
- 2007/08/29 일단 한걸음. 스킨위자드 (2)
- 2007/08/21 블로깅과 삶의 여유 (2)
- 2007/08/20 Tomcat DBCP 설정(Oracle 10g) (2)
- 2007/08/08 수평관계에서의 프로젝트 진행
- 2007/07/13 Oracle 10g XE JDBC 연결하기 (1)
- 2007/06/26 Tomcat 기반 JSP 개발 환경설정
- 2007/05/18 invoker 의 역할
- 2007/05/16 결혼..?
- 2007/05/08 주민등록번호 알고리즘
처음에는 3G+ 보급을 위해 저가형으로 출시된 Anycall 의 SCH-W330 제품을 구입할 생각을 하였습니다만, 여러가지 이유들로 인해서 보류상태에 빠지고 어제저녁즘에 다시 알아보게 된 시점에서 SKY 의 새로운 제품 출시 소식을 듣게 되었습니다.
네. 바로 IM-S240K 에 관한 소식이랍니다. :-)
심플한 다자인을 선호하는 저로서는 참 오랬만에 마음에 드는 녀석을 찾은거 같습니다. 한동안 많은 분들의 SKY 에 대한 비난이 심했던것 같은데, 한정된 시장에서.. 여러 경쟁업체가 있는 상황에서 할 수 있는 선택은 그리 많은 편이 아니라고 생각되기 때문에 가볍게 패스~
안타까운것은 뒤의 K 자가 의미하는바처럼 KTF 전용 SHOW 폰으로 출시가 되었다라는 점입니다. 지금까지 LGT 만을 8년여를 사용해 온 저로서는 안타까운 상황이지만, 장기이용자에대한 특별한 정책없이 거의 물주로 생각하는 통신사들의 작태에 슬슬 지쳐가는 시점이라 큰 문제가 되지도 않는듯 합니다.
이미지를 첨부해 보려 했으나, 회사에서 외부로의 업로드 형식의 패킷은 전부 차단하고 있네요.
한동안 잊고 지내왔던 새로운 휴대폰에 대한 갈증이 시작된것 같습니다. :-)
그렇다고 해서 실망을 했다던가 하는 것은 아닙니다. 모든것에는 순서가 있기 마련이고, 지금 제공되는 스킨위자드라면 일단 첫걸음으로서의 기능은 어느정도 만족할만한 수준이라고 생각합니다.
사소한 배경 하나를 바꾸는데도 [HTML / CSS] 에 대한 지식을 알아야 하고, 본문이 너무 좁아 사진이 자꾸 보기에 좋지 않은데도 불고하고 역시나 [HTML/CSS] 에 대한 지식이 없으면 아주 사소한 부분이라도 스킨을 수정하는것은 엔드유저 에게는 쉬운일이 아닌것이 사실입니다. 하지만 이러한 작은것 같지만 정작 가장 중요한 부분을 스킨 위저드가 어느정도는 해결해 줄 수 있을거라는 생각이 들었습니다.
기본적으로 지원하는 본문의 width 길이 지정. 배경 색상/이미지 변경등은 아주 유용할 거라 생각이 들고, font 등을 수정하는 기능 역시 편리할 것 같습니다.
이 스킨위자드 기능을 이용하기 위해서는 [표준스킨] 처럼, 제작시에 가이드라인 을 제공해 주는 스킨이 따라와 주어야, 현재 태터툴즈 등에서 스킨을 제작해 배포를 하고 계시는 분들의 참여로 스킨의 다양화가 이루어 질거라는 생각이 들었습니다.(금방 해결 되겠죠?)
아쉬운 점은, 이번 스킨위자드 에 포함되어 있는 기능들의 대부분은 엔드유저 가 아닌 스스로 HTML/CSS 수정이 어느정도 가능하신 분들에게는 그다지 유용할 거라는 느낌이 와 닿지 않았습니다.
일단 [티스토리 + 자바스크립트] 의 조합으로 인해서 공용 회선에서는 극악의 속도를 자랑합니다. 변경등이 바로 반영이 이루어지지 않고 페이지가 멈추는 현상도 발생을 하더군요. 이는 코드 최적화 등을 통해서 빠르게 조치가 되어야 할듯 합니다.
전체적으로 살펴 본 이번 스킨위자드.
"배경이미지 하나 바꾸는 것도 너무 어려워요!" 라고 한번이라고 느껴보셨을 분들을 위하여 준비하였습니다. 스킨위자드는 html/css를 직접 편집을 하지 않고도 좀 더 쉽고 편하게 스킨을 수정/편집 할 수 있는 새로운 스킨 편집 기능을 소개합니다!엔드유저 분들을 위한 스킨편집 의 편리성을 위해서 시작된 아이디어. 시작하는 느낌이 참 좋은 것 같습니다. :-)
여러 분들은 블로그가 삶에서 어떠한 비중을 차지하시는지 궁금해 졌습니다. 저의 경우를 예로 들면, 제가 지금 살아가고 있는 이 순간의 여유를 표현해 주는 가장 적합한 대상이 블로그가 아닐까 합니다.
'그깟 글 하나 쓰는데 뭐 그리 시간이 많이 걸린다고?' 라고 생각을 하신다면 죄송하다는 말씀밖에는 딱히 드릴만한 말은 없습니다. 다만, 여유가 없다는것은 지금 하고있는 일 이외의 것에 집중을 할 수 있을만큼의 정신적인 여유가 없다고 생각해 주시면 아니될까요? :-)
H 모 호스팅사와 계약기간이 종료되는것도 모르고 방치했다가 기존의 포스트는 모두 사라져 버리고 나서야 백업의 중요성을 다시한번 느꼈답니다.(전화한통 해 주지 않다니.. 나쁜것들!!)
어서 이 바쁜 삶의 시간이 지나갔으면 좋겠습니다. 여유로움을 만끽하며 내가 좋아하는 것들을 하나씩 이루어 나가는 삶이.. 참으로 그리워 지는 시간을 지나가고 있는것 같습니다. :-)
(그런데 이렇게 바쁜생활이.. 그리 싫지만도 않네요? -.-)
대부분의 어플리캐이션에서 가장 부하가 많이 걸리는 부분은 DB 에 접속 하는 부분이라고 합니다. 그에따라 대부분의 상용 사이트 혹은 동시접속자가 생기는 솔루션의 경우에는 DataBase Pool 이라는 기법을 이용하여 Connection 되어있는 객체를 생성하고, 요구사항이 있을때 임대해 주는 방식을 많이 사용합니다. 이 부분을 직접 작성해 보는것 또한 많은 것을 학습할 수 있는 기회가 되지만, 실제 서비스되는 곳에 실험적으로 만들어진 코드를 사용하기는 현실적으로 많이 어려운것 같습니다.
따라서 apache 재단의 Java 서브 프로젝트인 jakarta 에서 DBCP 라는 프레임워크(?) 많이들 이용하고 있습니다. 물론, 학습시에 말이죠. :-)
자바를 배워 나아간다는것은, 영업직들의 화려한 활약으로 인해서 EJB 가 필수적인 스킬이 되어 가고 있는 상황이고 EJB 라는 녀석 자체가 초기 투자비용이 워낙 큰 녀석이다보니 WAS 에서 학습시에 세팅에 열을 올리는 대부분의 것들을 자체적으로 지원해 주기 마련입니다. 그래서 DBCP(DB Connection Pool) 에 대한 전반적인 지식이 없이 EJB 로 넘어가는 사례를 많이 보곤 합니다. 하지만 제가 항상 강조하듯이 지식을 끌어안지 못하고 과정을 학습하는것은, 차후에 그것을 기반으로 한 상위의 무언가를 배울때 걸림돌이 될 것이 확실하다고 생각합니다.
그래서 결론은, 'DBCP 에 대한 전반적인 지식을 끌어안고 상위로 나아가자' 가 되겠죠. :-)
항상 포스팅을 할 때마다 느끼는것이지만, 사설이 너무 길어지는거 같습니다.
1> 라이브러리 복사.
2> server.xml ==> <Resource /> 추가
3> context.xml 혹은 server.xml ==> <ResourceLink /> 추가
4> web.xml ==> <resource-ref> ... </resource-ref> 추가
5> TEST!!
1-1> DBCP 라이브러리 복사.
common-collections-3.2.jar
common-dbcp-1.2.1.jar
common-pool-1.3
위의 3개 파일을 <context>/WEB-INF/lib 디렉토리에 복사.
1-2> oracle JDBC 드라이버 파일 복사.
ojdbc14.jar
위 파일을 <context>/WEB-INF/lib 디렉토리에 복사.
[<TOMCAT_HOME>/common/lib 디렉토리에 복사]
2> server.xml 파일의 <GlobalNamingResources> 의 내부태그로 <Resource /> 추가
<Resource auth="Container" driverClassName="oracle.jdbc.driver.OracleDriver" maxActive="20" maxIdle="10" maxWait="-1" name="jdbc/project" password="tiger" type="javax.sql.DataSource" url="jdbc:oracle:thin:@127.0.0.1:1521:xe" username="scott" />
3> context.xml 혹은 server.xml 파일의 <Context> 의 내부태그로 <ResourceLink /> 추가
<ResourceLink global="jdbc/project" name="jdbc/project" type="javax.sql.DataSource" />
4> web.xml 파일에 <resource-ref> 추가.
<resource-ref>
<description>DB Connection</description>
<res-ref-name>jdbc/project</res-ref-name>
<res-type>javax.sql.DataSource</res-type>
<res-auth>Container</res-auth>
</resource-ref>
5> TEST!!
<%@ page contentType="text/html" pageEncoding="UTF-8"
import="java.sql.*"
import="javax.sql.*"
import="javax.naming.*"
%>
<html>
<head>
<title></title>
</head>
<body>
<%
try {
Context initCtx = new InitialContext();
Context envCtx = (Context)initCtx.lookup("java:/comp/env");
DataSource ds = (DataSource)envCtx.lookup("jdbc/project");Connection conn = ds.getConnection();
out.write("DB Connection..");
conn.close();
}
catch(Exception e) {
e.printStackTrace();
}
%>
</body></html>
5번 과정을 마친 후 톰캣을 가동하고 웹브라우저에서 실행시 "DB Connection.." 이라는 메시지가 브라우저에 출력이 된다면 연결이 성공한 것입니다. :-)
지금 교육을 받고 있는 곳에서 1-2개월정도의 기간동안 자율주제 프로젝트를 진행할 수 있게 되었습니다. 서로가 같이 교육을 받아왔던 분들이라 상하관계라곤 없는 상황. 누구나 발언을 할 수 있고, 마음에 안드는 부분에서는 투정이라도 부릴 수 있는 기회가 생긴 것이랍니다.
지금 시간이 1개월여가 지나가고 있는 시점에 있습니다. 제가 지금 매우 재미있는 프로젝트를 진행하고 있을까요? 아니면 난처한 상황에 처해 있을까요?
안타깝게도 정답은 후자 입니다.
수평관계에서의 프로젝트 진행은 얼핏 상당히 이상적인 방법인듯 느껴지지만, 이번 프로젝트를 진행하면서 제가 느끼게 된 것은, 최소한 일정 이상의 발언권을 가진 인물(팀장이 되겠네요)이 중심을 잡아줘야 할듯 합니다. 사공이 많으면 배가 산으로 간다는 말이 있듯이 여러 사람들이 자신의 주장을 펼치고, 그에따른 적절한 합의가 이루어지지 않으니 실지 프로젝트에서 하루도 안걸려서 마무리 될법한 토의가 일주일을 넘기는일도 아주 자주 있는일이 되어가고 있습니다. 물론 저희팀 뿐만이 아닌 다른 팀도 어느정도의 차이가 있을 뿐, 전체적인 양상은 비슷한듯 보였습니다.
많은 분들께서 개발자에게 가장 중요한 스킬은 코딩 혹은 설계능력이 아닌 커뮤니케이션 능력이라는것을 말씀해 오셨는데, 이것이 지금처럼 크게 와 닿은적이 없었던것 같습니다. 천재는 다른이의 실수에서 배우고, 범재는 자신의 실수에서 배우며, 둔재는 자신의 실수를 여러번 되풀이해서 배워간다고 했던것 같습니다.
저는.. 아무래도 둔재에 가까운것 같습니다. :-(
Oracle 10g Express Edition 의 목적은 개인의 학습용 / 개발자용 / 교육기관의 학습용 으로 배포되는 것이라 합니다. 학습을 용도로 한 저에게는 Oracle 9i 같은 통합 제품군 보다는 오히려 XE 버전이 훨씬 더 알맞은 제품군이라는 판단이 서게 되었고, 설치를 마치게 되었습니다. :-)
일단, 배포본의 Size 에서 많은 차이가 나는 것을 느꼈습니다. Oracle 9i 의 경우 CD 3 장 분량으로 제공이 되고 있으나, XE 의 경우는 200MB 정도의 파일 하나만이 필요했습니다.
(이도 oracle 공식 사이트에서 무료로 제공되고 있습니다. 물론 한글버전으로 나온답니다.)
메모리 점유율 등을 살펴보면 생각만큼 큰 폭의 낮은 리소스를 사용하는 것은 아니지만, 아무래도 통합 배포본보다야 가벼울 수 밖에 없었습니다.
(약 1/3 정도는 빨라진것을 느꼈습니다.)
설치를 마치고 난 후 기존에 사용하던 방법을 이용해서 JDBC 드라이버를 세팅해 주고, Connection 객체를 생성하다가 갑작스럽게 벽에 부딛히게 되었습니다. 네. 맞아요. SID 아이디를 뭘 적어줘야 할지 갈피를 잡지 못했던 것이랍니다. 부랴부랴 오라클 공식 홈페이지를 찾아 다니면서 관련 문서들을 읽어 보며, 무언가를 문서화 시키는것을 습관화 시키지 못하는 사람은(특히나 개발자라면) 나중에 반드시 한번은 큰 난관에 부딛히리라는 느낌이 와 닿게 되었습니다.
자.. 사설이 길었습니다. :-)
ojdbc14.jar 파일
(Path : C:\oraclexe\app\oracle\product\10.2.0\server\jdbc\lib)
JAVA_HOME/jre/lib/ext
CATALINA_HOME/lib 혹은 CATALINA_HOME/common/lib
위 두곳에 복사해 줍니다.
Java 에서 Connection 객체를 생성할 때
Class.forName("oracle.jdbc.driver.OracleDriver");
URL : jdbc.oracle.thin:@localhost:1521:XE
DataBase 사용자 계정에서 scott 계정을 생성.
(기존의 Oracle 에서 이용하던 scott / tiger 를 이용하기 위한 설정입니다.)
위와 같은 방법으로 이용하면, 기존에 이용하던 방법으로 오라클을 이용할 수 있었습니다.
주변의 사례들을 예로 보면, 개발단계에서 DB 에 단순한 Query 만을 날리면서도 완성된 제품군을 선호하는 사람들이 많은것 같습니다. 하지만 목적에 어긋날 정도로 비대한 녀석을 명확한 사용방법도 인지하지 못한채 '그저 좋은것' 이라는 인식만으로 사용하는것은 상당히 잘못된 무언가가 있는것이 아닐까라는 생각을 하게 되었습니다.
(그것도 불법 S/W 를 사용하죠. 개발자가 되겠다는 사람이..)
조금 더 넓은 시야를 가질 수 있는 연습이 필요한것 같습니다. :-)
자바 설치 후 PATH, JAVA_HOME, CLASSPATH 설정.
JAVA_HOME = C:\java\j2sdk
PATH = %PATH%; %JAVA_HOME%\bin;
CLASSPATH = .;
Tomcat 설치 후 CATALINA_HOME 설정.
CATALINA_HOME = C:\tomcat
Java 컴파일러에서 서블릿의 클래스 파일을 인식시키기 위해서 대부분의 서적에서 CLASSPATH 를 설정해 주는 방식을 사용하는것 같습니다. 하지만 매번 새로운 모듈이 필요할 경우마다 설정을 바꾸어 주어야 하는 수고스러움(?)이 발생하는 문제점이 있습니다. 따라서 저는 JAVA_HOME\jre\lib\ext 디렉토리에 해당 모듈을 넣어주는 방식을 선호합니다. :-)
(이 방식은 개발시에 용이하지만, 실제 서비스를 해야 하는 경우라면 CLASSPATH 를 설정해 주는것이 올바른것 같습니다.)
servlet-api.jar, jsp-api.jar 파일을 JAVA_HOME\jre\lib\ext 디렉토리에 복사.
mysql-connector-java-5.0.5-bin.jar 파일을 JAVA_HOME\jre\lib\ext 디렉토리에 복사.
(mysql 버전에 따라 차이가 있습니다.)
여기까지의 설정만을 이용하면 Servlet 및 JSP 에서 MySQL Database 에 접근할 수 있었습니다. 굳이 MySQL 이 아닌 Oracle 이나 MS-SQL 역시 JDBC 드라이버만 JAVA_HOME\jre\lib\ext 디렉토리에 복사해 주면 정해진 API 를 통해 접근이 가능해 지는것을 확인하였습니다.
아직까지 마음에 들진 않지만.. 역시나 배우는 입장이니 시키는 대로 따라가 보아야 겠습니다. :-)
이전 포스트를 보시면 알 수 있겠지만, 책을 구입후 처음부터 invoker 이라는 녀석을 사용해서 Servlet 를 이용하도록 되어 있는데, invoker 에 관한 주변설명이 없어서 역할이나 목적등을 쉽게 이해하기가 힘들었습니다. 일단 무언가를 시작하는 입장이기에 의문보다는 전체적인 흐름에 포커스를 마추고 따라가다보면 일정 시점에서 궁금증을 해결 할 수 있을 거라 생각했으나, 자주 등장하고, 또한 사용 빈도가 높은 무언가를 목적이나 역할도 모르는채 이용한다는것이 조금 앞뒤가 안맞는다는 생각에 이것저것 알아보기 시작했습니다.
그래서 도달한 결론은 Thread 라는 것이었죠. :-)
이 invoker 이라는 녀석은 컨테이너 레벨에서 단독으로 동작하는 쓰레드 였습니다. Servler 을 invoker 로 매핑을 시켜주면, 매핑되어있는 URI 로 서블릿을 실행할 수 있는 역할을 하는 것이죠. 조금 더 구체적으로 설명을 해 보자면, 클라이언트가 서블릿을 호출하면, 메모리에 로드되어 있는 서블릿의 Context 를 할당받아, Java Application 의 main() 메소드에 해당되는 서블릿의 service() 메소드를 호출해 주는 역할을 합니다.
실제 학습을 하는데 있어서 이것이 무엇을 위해 존재하는지 정확한 역할을 몰라도 따라하기 식으로 학습해 나아가면 크게 문제가 없는부분이 상당수가 있습니다. 그 따라하는 과정 자체를 학습해 버리니까요. 하지만 이것들을 기반으로 하는 상위의 무언가를 배워나갈때 걸림돌이 되느냐, 아니면 촉매제가 되느냐 하는 차이가 발생할 수 있습니다. 사용되는 빈도수가 높으면서도 정확한 목적을 모른채 사용해 나간다면 자기 자신이 답답해 하는것이야 말로 정상적인 사고방식은 아닐까요? :-)
아직까지 결혼이라는것에 대해서 구체적인 생각을 해 볼 여유가 없었기 때문일까요? 어색한 기분을 떨쳐버리기가 많이 힘들었습니다. 친구녀석들과 이런 저런 말을 해 보아도, 어색한것은 마찬가지 인듯 합니다. 다만, 친구들 중에서 가장 먼저 결혼에 성공한 녀석이다 보니 친인척들의 결혼식에 참여했을때와는 느낌이 많이 다르다는 말들은 한결같이들 하더군요. :-)
친구녀석의 결혼식에서 미묘한 사건을 겪었습니다. 입장에 따라서 충분히 이해할 수도 있을법도 하지만, 개인적인 감정으로 봤을때는 많이 실망스러운 사건이었지요. 모든 사람마다 다른이들에게 말하기 힘든 사정이라는 것은 분명히 존재하고, 그러한 것들을 전후 사정도 모른채 무작정 나무라고 싶은 생각은 없습니다. 하지만 최소한 들어올때 다르고 나갈때 다른듯한 모습을 보이는 것은 친구라는 관계를 떠나서 사람대 사람 으로서 최대한 보이지 말아야 할 모습은 아니었을까요?
정확한 전후사정을 이곳에 남길 수는 없지만, 이렇게라도 흔적을 남기고 있다는것은, 그 일을, 그리고 그녀석을 아마도 한동안은 잊지 않을거라는 나만의 다짐일지도 모르겠습니다.
영섭이 이녀석!! 결혼 축하한다~ :-)
지금은 대부분의 상업적 목적을 가지는 웹사이트들이 주민등록번호 인증제도를 도입하지만, 그리 오래되지 않은 시절에는 대부분 직접 주민등록번호를 체크하는 루틴을 가지고 있었습니다. 속설에 의하면 허위 주민등록번호로 가입하는것을 막기 위해서 의도적으로 유출이 된 알고리즘이라고 하지만, 오히려 역효과로 인해서 주민등록번호 생성기가 웹을 휩쓸었던 시절이 도래하기도 했었지요.
현재는 주민등록번호 생성기 등을 제작해 배포하는 것은 큰 문제가 된답니다.
var sn = "1234561234567";
var key = "234567892345";
var sum = 0;
for( var i=0; i < key.length; i++ ) {
sum += parseInt( sn.charAt(i) ) * parseInt( key.charAt(i) );
}
digit = ( 11 - (sum % 11) ) % 10;
res = ( parseInt(sn.charAt(sn.length - 1)) == digit )? "True" : "False";
window.alert( res );
이러한 알고리즘에 관심이 있으신분은 대부분 개발자 혹은 개발자지망생 일거라 예상되고, 코드는 비교적 간단하다고 생각되는 JavaScript 를 이용했습니다. 한번 읽어보시면 알고리즘 정도는 눈에 들어오시겠죠? :-)
아, 참고로 2000 년 이후 출생자는 이 알고리즘이 적용되지 않는것으로 알고 있습니다.

Prev

