Google이 일반을 대상으로 하는 서비스가 몇개나 될까? 검색하다보면 하나씩 하나씩 나온다.
그러면서 놀래.. 아니 구글이 이런서비스를.. 왜 이제야 알았지...
이런 서비를 정리 해 놓은 사이트를 본적이 없는데... 이건좀 아쉽지만..
구글의 이런 서비스는 나를 놀라게한다.
더구나 무료이고.
아래는 내가 현재 사용하는 서비스인데... 빠진게 모가 있을까~~
목요일, 4월 30, 2009
수요일, 4월 29, 2009
Gran Torino, 2008
Gran Torino를 우연히 보았습니다.
그렇지, 아무거나 걸린걸 보는 것이었지.
이번주에 도대체 내가 무슨일을 했는지 모르게 하루 하루가 지나고 있습니다.
그러니까 주말에 연휴이니 벌써 연휴로 가버렸는지도 모르겠고,
제품을 리눅스로 포팅하는 작업도 그렇지 평소라면 간단한 작업을 몇일째 부여잡고 있었지요.
은근히 짜증나는, 별 소득도 없고, 의미도 없으며, 왜라는 질문만 난무하는 .... 그런 하루 였습니다.
휴.. 사실 얼마전에 이야기했던 이클립스에 몬가 하려던 것도 진도가 나가고 있지 않습니다.
영어로 토론하거나 코멘트가 가능해야하는데, 이건 뭐.. 그것조차 되지 않으니 더이상 진도가 나갈수 없는 것이죠.
사실 몇가지 이클립스 제품은 나도 그깟이것 만들수 있어..
그게 모가 어렵다고 하는것도 존재합니다... 그렇지만, 지금까지 경험으로 미루어.. 제품이 그렇게 나온것은 많은 사람들의 의사교환과 토론 고통의 인내를 견디어 나온것을 잘 압니다.
그저 코딩실력만 있어서는 안되는 것이죠.
아이디어와 기획 의사교환 초기 파일럿과 테스트를 거쳐 사용자들에게 배포하고 다시 의견을 반영하고 그 결과가 사용자들에게 좋은 결과로 나타나서 다시 제품화하는 과정을 격는 일련의 과정을 겪여야 하는것 입니다. 말이 쉽지 결코 쉽지 않는 과정을 지금까지 경험을 통해 알수 있습니다.
다시 Gran Torino라는 것으로 돌아와서, 영화를 보는 내내 얼마나 몰입되던지 말입니다.
그 일상의 지루함이 감동이었습니다.
영화를 다 보고 난 후에 나의 기분은 전혀 새로워 졌습니다.
그냥 기분이 좋아지고, 낳아졌습니다.
그리고 다시 열정이 되살아 났습니다.
사실 무지 부끄러운 이야기지만, 영어 문법책을 다시 보고 있습니다.
그리고 틈나면 영어로 된 무엇이든 듣고 써보고 있지요.
내가 하고 싶은 것, 앞으로 되고 싶은 일을 향해 좀더 나를 정진해야겠습니다.
몇분이나 이 글을 보실지 모르지만, 한금이가 꼭 되어 보이겠습니다.
그렇지, 아무거나 걸린걸 보는 것이었지.
이번주에 도대체 내가 무슨일을 했는지 모르게 하루 하루가 지나고 있습니다.
그러니까 주말에 연휴이니 벌써 연휴로 가버렸는지도 모르겠고,
제품을 리눅스로 포팅하는 작업도 그렇지 평소라면 간단한 작업을 몇일째 부여잡고 있었지요.
은근히 짜증나는, 별 소득도 없고, 의미도 없으며, 왜라는 질문만 난무하는 .... 그런 하루 였습니다.
휴.. 사실 얼마전에 이야기했던 이클립스에 몬가 하려던 것도 진도가 나가고 있지 않습니다.
영어로 토론하거나 코멘트가 가능해야하는데, 이건 뭐.. 그것조차 되지 않으니 더이상 진도가 나갈수 없는 것이죠.
사실 몇가지 이클립스 제품은 나도 그깟이것 만들수 있어..
그게 모가 어렵다고 하는것도 존재합니다... 그렇지만, 지금까지 경험으로 미루어.. 제품이 그렇게 나온것은 많은 사람들의 의사교환과 토론 고통의 인내를 견디어 나온것을 잘 압니다.
그저 코딩실력만 있어서는 안되는 것이죠.
아이디어와 기획 의사교환 초기 파일럿과 테스트를 거쳐 사용자들에게 배포하고 다시 의견을 반영하고 그 결과가 사용자들에게 좋은 결과로 나타나서 다시 제품화하는 과정을 격는 일련의 과정을 겪여야 하는것 입니다. 말이 쉽지 결코 쉽지 않는 과정을 지금까지 경험을 통해 알수 있습니다.
다시 Gran Torino라는 것으로 돌아와서, 영화를 보는 내내 얼마나 몰입되던지 말입니다.
그 일상의 지루함이 감동이었습니다.
영화를 다 보고 난 후에 나의 기분은 전혀 새로워 졌습니다.
그냥 기분이 좋아지고, 낳아졌습니다.
그리고 다시 열정이 되살아 났습니다.
사실 무지 부끄러운 이야기지만, 영어 문법책을 다시 보고 있습니다.
그리고 틈나면 영어로 된 무엇이든 듣고 써보고 있지요.
내가 하고 싶은 것, 앞으로 되고 싶은 일을 향해 좀더 나를 정진해야겠습니다.
몇분이나 이 글을 보실지 모르지만, 한금이가 꼭 되어 보이겠습니다.
월요일, 4월 27, 2009
엄마보러 광주갑니다.
부모님 뵈러 광주 가네요.
변변치 않는 재주 이지만 Eclipse Platform(SWT/JFace, RCP, RAP, PlugIn, EMF, ECF, GEF) 요정도 기술등에 질문 거리가 있으시거나 궁금한 분은 연락주세요. 몇시간 정도는 가벼운 마음으로 충분히 가능할 듯 합니다.
사실 EMF, ECF, GEF은 안해본지 반년에서 2년 이상 된것도 있으니... 질문 받으면 모를지도 모릅니다. -_-;;
광주에는 5/1 - 5/4까지 있을예정이구요.
혹은 저의 기술 베이스를 아시는 선에서 질문도 괸찮고요.
전라도 광주 변방이라 질문하실분이 없을거라(?) 예상해 보지만 말입니다.
황금연휴가 다가오네요.
ps) 사실 아무것도 없으면서... 괸시리....
지방에 산다는 이유로 좋은 컨퍼런스나 모임 못 가지셨을텐데....
무슨 대단한 존재도 아니면서 글올리네요. 이런글 올렸다가 싸대기로 욕먹는거 아닌가모르겟네요. -_-;;;;
변변치 않는 재주 이지만 Eclipse Platform(SWT/JFace, RCP, RAP, PlugIn, EMF, ECF, GEF) 요정도 기술등에 질문 거리가 있으시거나 궁금한 분은 연락주세요. 몇시간 정도는 가벼운 마음으로 충분히 가능할 듯 합니다.
사실 EMF, ECF, GEF은 안해본지 반년에서 2년 이상 된것도 있으니... 질문 받으면 모를지도 모릅니다. -_-;;
광주에는 5/1 - 5/4까지 있을예정이구요.
혹은 저의 기술 베이스를 아시는 선에서 질문도 괸찮고요.
전라도 광주 변방이라 질문하실분이 없을거라(?) 예상해 보지만 말입니다.
황금연휴가 다가오네요.
ps) 사실 아무것도 없으면서... 괸시리....
지방에 산다는 이유로 좋은 컨퍼런스나 모임 못 가지셨을텐데....
무슨 대단한 존재도 아니면서 글올리네요. 이런글 올렸다가 싸대기로 욕먹는거 아닌가모르겟네요. -_-;;;;
영어로 말을 걸면 한글로 말해주는 친구다.
Google Talk에 친구를 추가했다.
친구명은 다음과 같고.
en2ko.dict@bot.talk.google.com
영어로 말을 걸면 한글로 말해주는 친구다.
친구명은 다음과 같고.
en2ko.dict@bot.talk.google.com
영어로 말을 걸면 한글로 말해주는 친구다.
SWT/JFace Study PPT
저번(?)에 진행했던 SWT/JFace 스터디에 대한 PPT를 올렸습니다.
1주차 PPT
2주차 PPT
3주차 PPT
SlideShare라는 곳에서 ppt, pdf등을 보여주는 서비스를 해주고 있었네요.
마음에 드는데요
할수 있다면 5월 중순에 Eclipse RCP 스터디(?)를 할수 있도록 PPT를 준비해야겠습니다.
물런 무료 스터디는 모두에게(?) 별로 좋지 않고, 유료이어야한다는 생각에는 SWT/JFace 하면서 느끼는 결론 입니다.
혹시 그래서 못하게 된다면, EMF, GEF, ECF, DSDP, GMF등의 PPT를 준비해 볼 생각입니다.
나를 위한 준비이기도 하고요
1주차 PPT
2주차 PPT
3주차 PPT
SlideShare라는 곳에서 ppt, pdf등을 보여주는 서비스를 해주고 있었네요.
마음에 드는데요
할수 있다면 5월 중순에 Eclipse RCP 스터디(?)를 할수 있도록 PPT를 준비해야겠습니다.
물런 무료 스터디는 모두에게(?) 별로 좋지 않고, 유료이어야한다는 생각에는 SWT/JFace 하면서 느끼는 결론 입니다.
혹시 그래서 못하게 된다면, EMF, GEF, ECF, DSDP, GMF등의 PPT를 준비해 볼 생각입니다.
나를 위한 준비이기도 하고요
목요일, 4월 23, 2009
구글을 지탱하는 기술
구글을 지탱하는 기술이라는 책을 읽고 있습니다.
흠..... .... .... .... .... .... ....
요새 저의 블로그 수정하는 재미에 빠져있네요.
저의 개인 소개를 바꾸었고, Wish list를 추가했으며, 지지자들 리스트를 추가했고(첫번째 지지자 모집중입니다), 레이블을 추가, 다른 블로거에게 친구신청을 했고............
이런기능은 블로그를 처음만들때에는 없었던 기능(?) 이었습니다.
책을 읽으면서 이런것이 이해가 됩니다.
이런 부분이 내가 구글을 사용하는 이유가 됩니다. 블로그가 계속 진화합니다. 내가 편하게 흥미를 갖도록 말이죠.
묘한 매력이랄까요?
비교를 해보자면 네이버와 다음의 카페나 이런것은 잘 살펴보진 않았지만 몇년전과 별반 달라지지 않은 서비스(?) 인듯합니다. 서비스가 진화하지 못하고 유지보수(?)하기 바쁘랄까요.
내가 관심이 없어서 인지 몰라도 말입니다.
시간이 지나면서 계속 발전하는 구글의 기존 서비스를 볼때마다, 그리고 사용할때 구글의 마법에 사로 잡혀가는 듯 합니다.
구글 빠 한금이...
태양처럼 변하지 말아줘.
흠..... .... .... .... .... .... ....
요새 저의 블로그 수정하는 재미에 빠져있네요.
저의 개인 소개를 바꾸었고, Wish list를 추가했으며, 지지자들 리스트를 추가했고(첫번째 지지자 모집중입니다), 레이블을 추가, 다른 블로거에게 친구신청을 했고............
이런기능은 블로그를 처음만들때에는 없었던 기능(?) 이었습니다.
책을 읽으면서 이런것이 이해가 됩니다.
이런 부분이 내가 구글을 사용하는 이유가 됩니다. 블로그가 계속 진화합니다. 내가 편하게 흥미를 갖도록 말이죠.
묘한 매력이랄까요?
비교를 해보자면 네이버와 다음의 카페나 이런것은 잘 살펴보진 않았지만 몇년전과 별반 달라지지 않은 서비스(?) 인듯합니다. 서비스가 진화하지 못하고 유지보수(?)하기 바쁘랄까요.
내가 관심이 없어서 인지 몰라도 말입니다.
시간이 지나면서 계속 발전하는 구글의 기존 서비스를 볼때마다, 그리고 사용할때 구글의 마법에 사로 잡혀가는 듯 합니다.
구글 빠 한금이...
태양처럼 변하지 말아줘.
RAP full screen
보통 RCP같은 경우 WorkbenchWindowAdvisor를 상속받은 클래스 즉,
public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {
의
public void createWindowContents(Shell shell) {
super.createWindowContents(shell);
shell.setMaximized(true);
}
를 수정해 주면 됩니다. 그렇지만 이렇게 RAP를 해주면 전체화면으로는 되지만, 정작
전체화면되어지고 화면안에 있는 Widget들은 전체화면에 맞게 재 배치 되어지지 않습니다.
내일 쯤 시간을 내어 디버깅을 해봐야 겠습니다.
그래서, 모든 화면이 오픈되고 마지막 후처리하는 메소드에 다음과 같이 추가하면 되겠습니다.
public void postWindowOpen() {
final IWorkbenchWindow window = getWindowConfigurer().getWindow();
Shell shell = window.getShell();
shell.setMaximized( true );
}
그러면 원래 의도했던 화면이 생성 됩니다.
public class ApplicationWorkbenchWindowAdvisor extends WorkbenchWindowAdvisor {
의
public void createWindowContents(Shell shell) {
super.createWindowContents(shell);
shell.setMaximized(true);
}
를 수정해 주면 됩니다. 그렇지만 이렇게 RAP를 해주면 전체화면으로는 되지만, 정작
전체화면되어지고 화면안에 있는 Widget들은 전체화면에 맞게 재 배치 되어지지 않습니다.
내일 쯤 시간을 내어 디버깅을 해봐야 겠습니다.
그래서, 모든 화면이 오픈되고 마지막 후처리하는 메소드에 다음과 같이 추가하면 되겠습니다.
public void postWindowOpen() {
final IWorkbenchWindow window = getWindowConfigurer().getWindow();
Shell shell = window.getShell();
shell.setMaximized( true );
}
그러면 원래 의도했던 화면이 생성 됩니다.
RAP of history
무언가 찾다가 버그질라에서 발견한 내용인데요.
2007년도에 RAP커미터중 한사람인 Jochen Krause 가 쓴 글인데요.
출발은 우리와 비슷한 프로젝트(?)로 출발 했지만, 나중에 결과물은 천지차이네요.
그 뚝심과 인내에 경의를 표하고 싶어 지네요.
원문은 (http://dev.eclipse.org/newslists/news.eclipse.technology.rap/msg01601.html)
Here you go with some RAP history:
RWT has indeed evolved from Innoopracts W4T technology, W4T stands for "www windowing toolkit". The first release of W4T was in December 2001, and it was our goal to make Java web development easier. This was not en vogue at that time, most of the Java crowd liked the complexity ;-)
We created a visual design tool for W4T as an Eclipse plugin - W4T Eclipse. W4T Eclipse became pretty popular with some groups as it simplified the creation of Java web apps quite a bit.
However, W4T was not a standard and we had an eye on JSF, which took almost forever to complete. We created a JSF compatible implementation that we dumped again, because we thought that the API of the components is almost impossible to understand for a Java (the language) developer. At least, we implemented a lifecycle management similar to that of JSF for W4T and moved ahead in 2005 to ajaxify the library. With the new Ajax capabilities we thought about enabling a workbench and plug-in based development approach for web applications. We successfully implemented proof of concepts for a "web workbench" as well as running osgi within a webcontainer in the summer of 2005. All of that was still based on the W4T api.
The RAP project was proposed in March 2006, and became an Eclipse project in late June 2006. It was still the plan to create a workbench implementation with W4T as widget toolkit. We realized pretty quickly that the Eclipse community preferred the SWT api for various valid reasons (not because W4T api was bad, but for code reuse, skill preservation, ...). So we began to re-implement the component layer with mostly SWT api and qooxdoo on the client side. Based on ongoing community feedback and after aligning with Steve Northover we decided in March 2007 to make RWT a subset of SWT.
That was the short version ;-). With respect to the development process of the Application framework the most notable thing in my eyes was the adoption of Eclipse APIs during the development. Even in the W4T days we had a JFace implementation (not fully API compatible). We decided at some point to innovate around an existing application framework that we think is very powerful (osgi, rcp), even if we don't agree with everything. If you want to get more info on how Eclipse as an application framework has evolved there are some great (old) slides by Jim de Rivieres. Erich Gamma and others. I don't have them handy but I think I could dig them out.
Cheers, Jochen
2007년도에 RAP커미터중 한사람인 Jochen Krause 가 쓴 글인데요.
출발은 우리와 비슷한 프로젝트(?)로 출발 했지만, 나중에 결과물은 천지차이네요.
그 뚝심과 인내에 경의를 표하고 싶어 지네요.
원문은 (http://dev.eclipse.org/newslists/news.eclipse.technology.rap/msg01601.html)
Here you go with some RAP history:
RWT has indeed evolved from Innoopracts W4T technology, W4T stands for "www windowing toolkit". The first release of W4T was in December 2001, and it was our goal to make Java web development easier. This was not en vogue at that time, most of the Java crowd liked the complexity ;-)
We created a visual design tool for W4T as an Eclipse plugin - W4T Eclipse. W4T Eclipse became pretty popular with some groups as it simplified the creation of Java web apps quite a bit.
However, W4T was not a standard and we had an eye on JSF, which took almost forever to complete. We created a JSF compatible implementation that we dumped again, because we thought that the API of the components is almost impossible to understand for a Java (the language) developer. At least, we implemented a lifecycle management similar to that of JSF for W4T and moved ahead in 2005 to ajaxify the library. With the new Ajax capabilities we thought about enabling a workbench and plug-in based development approach for web applications. We successfully implemented proof of concepts for a "web workbench" as well as running osgi within a webcontainer in the summer of 2005. All of that was still based on the W4T api.
The RAP project was proposed in March 2006, and became an Eclipse project in late June 2006. It was still the plan to create a workbench implementation with W4T as widget toolkit. We realized pretty quickly that the Eclipse community preferred the SWT api for various valid reasons (not because W4T api was bad, but for code reuse, skill preservation, ...). So we began to re-implement the component layer with mostly SWT api and qooxdoo on the client side. Based on ongoing community feedback and after aligning with Steve Northover we decided in March 2007 to make RWT a subset of SWT.
That was the short version ;-). With respect to the development process of the Application framework the most notable thing in my eyes was the adoption of Eclipse APIs during the development. Even in the W4T days we had a JFace implementation (not fully API compatible). We decided at some point to innovate around an existing application framework that we think is very powerful (osgi, rcp), even if we don't agree with everything. If you want to get more info on how Eclipse as an application framework has evolved there are some great (old) slides by Jim de Rivieres. Erich Gamma and others. I don't have them handy but I think I could dig them out.
Cheers, Jochen
화요일, 4월 21, 2009
Finding SWT Leaks with Sleak
http://eclipsesource.com/blogs/2009/04/17/finding-swt-leaks-with-sleak/
Sleak 소개 팁입니다.
01....
02.org.eclipse.swt.SWTError: No more handles
03.at org.eclipse.swt.SWT.error(SWT.java:2966)
04.at org.eclipse.swt.SWT.error(SWT.java:2863)
05.at org.eclipse.swt.SWT.error(SWT.java:2834)
06.at org.eclipse.swt.widgets.Widget.error(Widget.java:395)
07.at org.eclipse.swt.widgets.Control.createHandle(Control.java:482)
08.at org.eclipse.swt.widgets.Composite.createHandle(Composite.java:229)
09.at org.eclipse.swt.widgets.Control.createWidget(Control.java:497)
10.at org.eclipse.swt.widgets.Scrollable.createWidget(Scrollable.java:131)
11.at org.eclipse.swt.widgets.Control. (Control.java:97)
12.at org.eclipse.swt.widgets.Scrollable. (Scrollable.java:72)
13.at org.eclipse.swt.widgets.Composite. (Composite.java:87)
이미지나 폰트등을 사용한 후에는 반드시 dispose를 호출해주어서 리소스스를 시스템에 반납해주어야하는데요.
그러지않고 무한정 생성만했을 경우 위와 같은 상황이 나타납니다. 물런 사용할때는 당연 ImageRegistry, FontRegistry 이것들을 관리해주는 JFaceResource를 사용해서 재사용해야 겠습니다.
이것들을 이용해서 처리해도 너무 많은 자원을 생성해서 가지고 있다면 위와 같은 에러를 만날수도있습니다. 시스템에서 위의 리소스를 만들수있는 한계가 있기때문에 그런 것 입니다.
이 것을 생성할수 있는 한계는 os마다 틀리기때문이지요.
어찌됐든 위와같은에러가 나왔을때 사용하는 도구가 Sleak입니다.
Sleak 홈페이지가도 처음하시는 분들은 감갑자기도 힘들텐데 정리가 잘되어 있네요.
알면 엄청나게 편한것이고, 모르면 몇일 날밤 새는 그런 것이므로 한번쯤은 꼭 봐두면 좋을듯 싶네요.
Sleak 소개 팁입니다.
01....
02.org.eclipse.swt.SWTError: No more handles
03.at org.eclipse.swt.SWT.error(SWT.java:2966)
04.at org.eclipse.swt.SWT.error(SWT.java:2863)
05.at org.eclipse.swt.SWT.error(SWT.java:2834)
06.at org.eclipse.swt.widgets.Widget.error(Widget.java:395)
07.at org.eclipse.swt.widgets.Control.createHandle(Control.java:482)
08.at org.eclipse.swt.widgets.Composite.createHandle(Composite.java:229)
09.at org.eclipse.swt.widgets.Control.createWidget(Control.java:497)
10.at org.eclipse.swt.widgets.Scrollable.createWidget(Scrollable.java:131)
11.at org.eclipse.swt.widgets.Control. (Control.java:97)
12.at org.eclipse.swt.widgets.Scrollable. (Scrollable.java:72)
13.at org.eclipse.swt.widgets.Composite. (Composite.java:87)
이미지나 폰트등을 사용한 후에는 반드시 dispose를 호출해주어서 리소스스를 시스템에 반납해주어야하는데요.
그러지않고 무한정 생성만했을 경우 위와 같은 상황이 나타납니다. 물런 사용할때는 당연 ImageRegistry, FontRegistry 이것들을 관리해주는 JFaceResource를 사용해서 재사용해야 겠습니다.
이것들을 이용해서 처리해도 너무 많은 자원을 생성해서 가지고 있다면 위와 같은 에러를 만날수도있습니다. 시스템에서 위의 리소스를 만들수있는 한계가 있기때문에 그런 것 입니다.
이 것을 생성할수 있는 한계는 os마다 틀리기때문이지요.
어찌됐든 위와같은에러가 나왔을때 사용하는 도구가 Sleak입니다.
Sleak 홈페이지가도 처음하시는 분들은 감갑자기도 힘들텐데 정리가 잘되어 있네요.
알면 엄청나게 편한것이고, 모르면 몇일 날밤 새는 그런 것이므로 한번쯤은 꼭 봐두면 좋을듯 싶네요.
금요일, 4월 17, 2009
목요일, 4월 16, 2009
RAP 근거리 미래
Eclipse나 혹은 RCP가 어떻게 발전하는지 궁금하다면 혹은 근래에 어떻게 나올것인지 궁금하다면 나는 RSA(Rational Software Architect)나 로토스 노츠??등을 찾아봅니다.
그러면 그 다음버전에 이클립스는 대부분 그렇게 변해서 나옵니다.
외형에서부터 기반 프레임웍에 해당하는 것까지 그렇습니다. 그럴수 밖에 없는것이 그 개발팀이 있는곳에 커미터들이 있기 때문입니다.
자 그럼 RAP의 미래는 어디서 엿볼수 있을까요?
그것은 http://www.eclipse.org/rap/demos.php의 CAS PIA를 통해 어느정도는 볼수있습니다.
어느 블로거의 글에서 봣는지 모르지만 e4에서 나오는 것들에 대한 힌트가 있었는데, 그 힌트에 대한 이야기가 이 프로젝트에는 그대로 녹아 있습니다.
RAP E4 기대가 됩니다. 참고로 아래프로그램은 영어가 아니라 독어입니다.
RAP의 한 축을 이루는 qooxdoo도 독일에서 나왔으며, RAP커미터 중 두명은 아래 CAS Software사람입니다. EclipseSource에 속해있는 커미터는 8명입니다.
누군가가 개발하면 표준이되고, 누군가는 표준이 되는 코드를 쫒아가면 되는데...
이제 그만 쫒아가고 싶습니다.
한국에서 이런것에 대해 고민하는 기업과 학교가 좀더 투자하고 이끌어 나갔으면 좋겠습니다.
그러면 그 다음버전에 이클립스는 대부분 그렇게 변해서 나옵니다.
외형에서부터 기반 프레임웍에 해당하는 것까지 그렇습니다. 그럴수 밖에 없는것이 그 개발팀이 있는곳에 커미터들이 있기 때문입니다.
자 그럼 RAP의 미래는 어디서 엿볼수 있을까요?
그것은 http://www.eclipse.org/rap/demos.php의 CAS PIA를 통해 어느정도는 볼수있습니다.
어느 블로거의 글에서 봣는지 모르지만 e4에서 나오는 것들에 대한 힌트가 있었는데, 그 힌트에 대한 이야기가 이 프로젝트에는 그대로 녹아 있습니다.
RAP E4 기대가 됩니다. 참고로 아래프로그램은 영어가 아니라 독어입니다.
RAP의 한 축을 이루는 qooxdoo도 독일에서 나왔으며, RAP커미터 중 두명은 아래 CAS Software사람입니다. EclipseSource에 속해있는 커미터는 8명입니다.
누군가가 개발하면 표준이되고, 누군가는 표준이 되는 코드를 쫒아가면 되는데...
이제 그만 쫒아가고 싶습니다.
한국에서 이런것에 대해 고민하는 기업과 학교가 좀더 투자하고 이끌어 나갔으면 좋겠습니다.
화요일, 4월 14, 2009
눈물만 주르르
어제부터 개발하는 시스템의 리팩토링을 하고 있습니다.
대략 쓰레드가 10개 미만, 클래스 40개 미만의 작은 시스템입니다.
시스템을 모니터링 하는 것이 주요한 기능입니다.
처음에 파일럿으로 만든 베이스 구조(Base Framwork)를 그대로 사용하고 있었습니다.
몬가 하나 수정할때마 베이스가 구조가 허약함을 느끼고 있었지만, 고치는게 귀찮고, 약간의 귀차늠을 감수하면 되므로 그냥 두고 있었습니다.
어제 다른 부분 리팩토링을 하려다가, 여전히 걸리는 것이 베이스 구조 이었습니다.
RAP에 대한 이해도 부족한채 만든 구조가 튼튼할리가 없습니다.
고치기 시작 대략 7개 미만의 클래스가 추가 되었습니다.
여러가지일을 하는 클래스를 쪼개 었지요. 흠흠흠...
역시나, 그림이라도 한번 그려보고 했어야 하는데 말입니다.
무료 uml plugin 도구를 찾아봐야겠습니다. RAS가 그립네요
눈물만 주르르 입니다.
대략 쓰레드가 10개 미만, 클래스 40개 미만의 작은 시스템입니다.
시스템을 모니터링 하는 것이 주요한 기능입니다.
처음에 파일럿으로 만든 베이스 구조(Base Framwork)를 그대로 사용하고 있었습니다.
몬가 하나 수정할때마 베이스가 구조가 허약함을 느끼고 있었지만, 고치는게 귀찮고, 약간의 귀차늠을 감수하면 되므로 그냥 두고 있었습니다.
어제 다른 부분 리팩토링을 하려다가, 여전히 걸리는 것이 베이스 구조 이었습니다.
RAP에 대한 이해도 부족한채 만든 구조가 튼튼할리가 없습니다.
고치기 시작 대략 7개 미만의 클래스가 추가 되었습니다.
여러가지일을 하는 클래스를 쪼개 었지요. 흠흠흠...
역시나, 그림이라도 한번 그려보고 했어야 하는데 말입니다.
무료 uml plugin 도구를 찾아봐야겠습니다. RAS가 그립네요
눈물만 주르르 입니다.
월요일, 4월 13, 2009
토요일, 4월 11, 2009
RAP 개발환경(RAP Developement Environment)
RAP 개발환경을 먼저 이야기를 해야하는데, 이전 게시물과 순서가 조금 뒤바뀐듯 합니다.
개발 환경
Java Version 1.6.0
Eclipse Version: 3.4.2 Build id: M20090211-1700
PlugIn : WTP, Log4E 등
RAP Version : 1.2.0.20090319-1224 M6
(1.1.2 service release보다 1.2 M6을 권장합니다.)
Window Vista
MySQL 5.5
실제운영하게 될 Target Platform : Open Suse 10.x버전
환경에 작업해야 했습니다.
FireFox 3.0.8, Internet Explorer 7.x, Google Chrome, Apple Safari에서 모드 잘 동작했습니다.
그 중에 Google Chrome가 제일 빨랐 습니다.
Ghrome은 특정부분에서 화면이 어그러지는 현상이 발생했구요. 아마도 속도를 위해 디테일을 희생한 느낌이었습니다.
Explorer에서는 특정부분에서 동작하지 않았습니다.
(Thread가 동작하는 화면에서(UICallback때문에) Dialog창을 열면 javascript에러가 나고 죽습니다. 이건 모 설명하기가 까다롭네요, 결국은 로직을 바꾸어서 모든 브라우져에서 동작하도록 수정했습니다. -_-;;)
프로젝트 구성은 위와 같습니다.
com.xxx.rap.monitor 프로젝트는 비지니스로직이 있는 플러그인 입니다.
일반적인 실행은 jetty로 수행합니다.
com.xxx.rap.monitor-tomcat 프로젝트는 wtp에서 사용할 web 프로젝트 이구요. 그래서 톰켓으로 올려서 테스트 해야하면 이 프로젝트를 사용합니다.
com.xxx.rap.monitor.feature 프로젝트는 tomcat으로 실행하기위해 빌드하는 프로젝트입니다.
com.eclipse.rap.demo.feature 프로젝트를 모태로해서 수정한 것이구요. 수정 이유는 제 블로그 글 중에 있으니 읽어보면 되겠습니다.
나머지 프로젝트는 feature빌드하기 위한 부분 플러그인입니다.
사실 글로 적으니 몇줄 안되니 무엇인가 많이 빠지 느낌입니다.
RAP의 장점은 실제로 개발을 주도하는(?) EclipseSource에
Why RAP 주재로 다음과 같은 소개글이 있습니다.
Single Source RCP Desktop and Web Applications
Eclipse Developers are up to the speed in web development quickly
RAP enable reuse
RAP works on all popular browsers
RAP로 제가 좀 독특한 프로젝트를 했는지 몰라도 Single Source 라는 주재는 납득하기 힘든면이 있습니다.
개발 환경
Java Version 1.6.0
Eclipse Version: 3.4.2 Build id: M20090211-1700
PlugIn : WTP, Log4E 등
RAP Version : 1.2.0.20090319-1224 M6
(1.1.2 service release보다 1.2 M6을 권장합니다.)
Window Vista
MySQL 5.5
실제운영하게 될 Target Platform : Open Suse 10.x버전
환경에 작업해야 했습니다.
FireFox 3.0.8, Internet Explorer 7.x, Google Chrome, Apple Safari에서 모드 잘 동작했습니다.
그 중에 Google Chrome가 제일 빨랐 습니다.
Ghrome은 특정부분에서 화면이 어그러지는 현상이 발생했구요. 아마도 속도를 위해 디테일을 희생한 느낌이었습니다.
Explorer에서는 특정부분에서 동작하지 않았습니다.
(Thread가 동작하는 화면에서(UICallback때문에) Dialog창을 열면 javascript에러가 나고 죽습니다. 이건 모 설명하기가 까다롭네요, 결국은 로직을 바꾸어서 모든 브라우져에서 동작하도록 수정했습니다. -_-;;)
프로젝트 구성은 위와 같습니다.
com.xxx.rap.monitor 프로젝트는 비지니스로직이 있는 플러그인 입니다.
일반적인 실행은 jetty로 수행합니다.
com.xxx.rap.monitor-tomcat 프로젝트는 wtp에서 사용할 web 프로젝트 이구요. 그래서 톰켓으로 올려서 테스트 해야하면 이 프로젝트를 사용합니다.
com.xxx.rap.monitor.feature 프로젝트는 tomcat으로 실행하기위해 빌드하는 프로젝트입니다.
com.eclipse.rap.demo.feature 프로젝트를 모태로해서 수정한 것이구요. 수정 이유는 제 블로그 글 중에 있으니 읽어보면 되겠습니다.
나머지 프로젝트는 feature빌드하기 위한 부분 플러그인입니다.
사실 글로 적으니 몇줄 안되니 무엇인가 많이 빠지 느낌입니다.
RAP의 장점은 실제로 개발을 주도하는(?) EclipseSource에
Why RAP 주재로 다음과 같은 소개글이 있습니다.
Single Source RCP Desktop and Web Applications
Eclipse Developers are up to the speed in web development quickly
RAP enable reuse
RAP works on all popular browsers
RAP로 제가 좀 독특한 프로젝트를 했는지 몰라도 Single Source 라는 주재는 납득하기 힘든면이 있습니다.
금요일, 4월 10, 2009
SWT RCP/PlugIn 테스트에 관한 글입니다.
http://swarmy.free.fr/wordpress/?p=66
테스트해보지 않았지만, 상당히 자세한 글이라 그리 염려스럽지 않을듯 합니다.
독일분 가튼데, 대문에 아래와 같은 글이 있네요. 글 보면서 한참을 웃었는데요. 어찌나 내 이야기 같던지 말이죠.
테스트에 관심있는 분들 댓글 부탁들요.
자세히 보지 못했지만, 글중에 다른 커뮤니티의 테스트 이야기등도 나오니 더 좋더군요.
100 little bugs in the code, debug one, recompile, 101 little bugs in the code
테스트해보지 않았지만, 상당히 자세한 글이라 그리 염려스럽지 않을듯 합니다.
독일분 가튼데, 대문에 아래와 같은 글이 있네요. 글 보면서 한참을 웃었는데요. 어찌나 내 이야기 같던지 말이죠.
테스트에 관심있는 분들 댓글 부탁들요.
자세히 보지 못했지만, 글중에 다른 커뮤니티의 테스트 이야기등도 나오니 더 좋더군요.
100 little bugs in the code, debug one, recompile, 101 little bugs in the code
목요일, 4월 09, 2009
Desktop Application 개발자의 어려움
어제 문득 Spring 기본서를 뒤적이고 있는 나를 보았습니다.
변방(?)에 있는 나로서는 비주류다 보니 무엇이든 개념이 부족합니다.
잘 구현된 Spring자료를 보다보면 아이디어가 많이 떠 오릅니다.
Web Application개발자들이 부러울때가 많이 있습니다.
풍부한 읽을거리와 리드하는 많은 개발자들이 많이 있고, 한글자료도 나름 풍부하여, 의지만 있다면 얼마든지 가능하겟습니다.
체계적인 방법론부터 시작해서 프로젝트 종료까지 일의 순차는 참 부러운듯합니다.
그에비해 Desktop Application 개발자들이 보기에는 자료가 많이 부족한 듯 합니다.
길은 서울로 통한다지만, 역시나 Desktop Application 개발에 맞게 커스텀된 자료들을 찾아보기 힘드네요.
좀더 원론적으로 접근할수 있는 자료들이 많이 있었으면 좋겠습니다.
이런 의미에서 EclipseCon과 같은 세미나는 더없는 부러움이었습니다.
Web Application개발과 같은거 아니냐고 생각할수도 있겠습니다만, 나름 Web Application개발과는 또 다른 Something이 있습니다.
그런다고 외국의 좋은 블로거들과 사이트를 들여다 보는것도 한개는 분명합니다.
이미 정점에 올라선 Platform 자료들과 그 완성된 자료들을 봐야하는 나로서는, 외 그렇게 디자인 했는지가 궁금할 뿐입니다. 정점에 올라선 소스는 보는것은 그리 궁금치가 않습니다.
적다보니 나도 맨토가 필요하다는 생각이 듭니다.
새벽까지 끙끙거리며 자료를 보는것도 힘들고,.. 함께 이런부분을 좀더 고민하는 동료가 많이 있었으면 좋겠습니다.
염치가 없지만, 허접한 나의 현실 입니다.
변방(?)에 있는 나로서는 비주류다 보니 무엇이든 개념이 부족합니다.
잘 구현된 Spring자료를 보다보면 아이디어가 많이 떠 오릅니다.
Web Application개발자들이 부러울때가 많이 있습니다.
풍부한 읽을거리와 리드하는 많은 개발자들이 많이 있고, 한글자료도 나름 풍부하여, 의지만 있다면 얼마든지 가능하겟습니다.
체계적인 방법론부터 시작해서 프로젝트 종료까지 일의 순차는 참 부러운듯합니다.
그에비해 Desktop Application 개발자들이 보기에는 자료가 많이 부족한 듯 합니다.
길은 서울로 통한다지만, 역시나 Desktop Application 개발에 맞게 커스텀된 자료들을 찾아보기 힘드네요.
좀더 원론적으로 접근할수 있는 자료들이 많이 있었으면 좋겠습니다.
이런 의미에서 EclipseCon과 같은 세미나는 더없는 부러움이었습니다.
Web Application개발과 같은거 아니냐고 생각할수도 있겠습니다만, 나름 Web Application개발과는 또 다른 Something이 있습니다.
그런다고 외국의 좋은 블로거들과 사이트를 들여다 보는것도 한개는 분명합니다.
이미 정점에 올라선 Platform 자료들과 그 완성된 자료들을 봐야하는 나로서는, 외 그렇게 디자인 했는지가 궁금할 뿐입니다. 정점에 올라선 소스는 보는것은 그리 궁금치가 않습니다.
적다보니 나도 맨토가 필요하다는 생각이 듭니다.
새벽까지 끙끙거리며 자료를 보는것도 힘들고,.. 함께 이런부분을 좀더 고민하는 동료가 많이 있었으면 좋겠습니다.
염치가 없지만, 허접한 나의 현실 입니다.
RAP with GEF
RAP e4에 GEF소식이 있네요.
http://www.architexa.com/labs/#gef
http://www.eclipse.org/newsportal/article.php?id=6023&group=eclipse.technology.rap#6023 글의 글타래를 보면 더 정확한 정보를 얻을수 있습니다.
http://www.architexa.com/labs/#gef
http://www.eclipse.org/newsportal/article.php?id=6023&group=eclipse.technology.rap#6023 글의 글타래를 보면 더 정확한 정보를 얻을수 있습니다.
수요일, 4월 08, 2009
RAP(RCP) 시작위치 조절(ApplicationWorkbenchWindowAdvisor#postWindowOpen() 고찰)
이것은 RCP도 동일하게 적용됩니다.
RAP가 처음 시작했을 때 보통 왼쪽 가장 자리에서 시작하게됩니다.
브라우저 제일 왼쪽에 딱 붙어서 시작하게 되는거지요.
이것을 화면 가운데로 혹은 원하는 곳으로 뛰어주게 하고 싶을 것 입니다.
이렇게요.
이것을 조절하고 싶을때는 WorkbenchWindowAdvisor를 상속받은 클래스 즉 보통 자동으로 생성되는 ApplicationWorkbenchWindowAdvisor#postWindowOpen() 메소드를 수정해 주면 되겠습니다. WorkbenchWindowAdvisor는 아는 것처럼 초기 원도우의 시작과 끝을 지정하고 어떻게 화면이 open되어야 하는지 조절하는 역할을 합니다.
그중 preWindowOpen() 메소드는 원도우가 어떻게 구성되어야 하는 것인지 정의하고(화면의 크기와 쿨바의 보이기 유무등), postWindowOpen()는 원도우가 오픈된 이후의 부가 적인 것들을 정의하게 되어 있습니다. 우리가 하려고하는 초기 위치 설정이라던가, 아래에 있는 것처럼 Preference 중에 우리가 원하는 것만 오픈한다 던가, RCP 일 경우 tray icon을 설정한다던가요.
진행하는 프로젝트의 코드는 다음과 같습니다.
위의 코드의 설명은 대락 Preference중에 ID가 com.mantech으로 시작하는 Preference만을 관리 하겠다는 것입니다. 나중에 Preference화면을 열었을때 com.mantech으로 시작하는 것만 열리겠지요. 이 코드를 사용하는 이유는 확장점중에 에디터나 ui를 사용할 경우 그 확장점에서 정의 preference도 나타나는데 이것을 지워주기 위함입니다.
그리고 두번째는 초기 시작 위치를 조절하는 것이지요. 시작 위치는 75,25만큼 이동해서 오픈되겠습니다. 중앙에 오픈하려면 창의 크기 자신의 크기를 계산한 다음에 이동해도 되겠지요. 자신의 초기 크기는 preWindowOpen에서 정의한 크기가 되겠구요.
마지막 세번째는 window가 오픈된 이후에 시작해 주어야할 Thread를 시작해 주었습니다. job을 이용해도 되겠습니다만... 혹은 ui와 상관없는 것이라면 확장점 org.eclipse.ui.startup를 사용해도 되겠습니다.
쓰다보니 굉장히 길어 졌네요. 이 부분도 좀더 안정적이고 멋진 제품을 만들기 위해서는 알아야 할 내용입니다. 위에서 설명한 것 이외에도 설명해야 할 부분이 많이 있습니다만 차차 하나씩 적어 보도록 하겠습니다.
RAP가 처음 시작했을 때 보통 왼쪽 가장 자리에서 시작하게됩니다.
브라우저 제일 왼쪽에 딱 붙어서 시작하게 되는거지요.
이것을 화면 가운데로 혹은 원하는 곳으로 뛰어주게 하고 싶을 것 입니다.
이렇게요.
이것을 조절하고 싶을때는 WorkbenchWindowAdvisor를 상속받은 클래스 즉 보통 자동으로 생성되는 ApplicationWorkbenchWindowAdvisor#postWindowOpen() 메소드를 수정해 주면 되겠습니다. WorkbenchWindowAdvisor는 아는 것처럼 초기 원도우의 시작과 끝을 지정하고 어떻게 화면이 open되어야 하는지 조절하는 역할을 합니다.
그중 preWindowOpen() 메소드는 원도우가 어떻게 구성되어야 하는 것인지 정의하고(화면의 크기와 쿨바의 보이기 유무등), postWindowOpen()는 원도우가 오픈된 이후의 부가 적인 것들을 정의하게 되어 있습니다. 우리가 하려고하는 초기 위치 설정이라던가, 아래에 있는 것처럼 Preference 중에 우리가 원하는 것만 오픈한다 던가, RCP 일 경우 tray icon을 설정한다던가요.
진행하는 프로젝트의 코드는 다음과 같습니다.
위의 코드의 설명은 대락 Preference중에 ID가 com.mantech으로 시작하는 Preference만을 관리 하겠다는 것입니다. 나중에 Preference화면을 열었을때 com.mantech으로 시작하는 것만 열리겠지요. 이 코드를 사용하는 이유는 확장점중에 에디터나 ui를 사용할 경우 그 확장점에서 정의 preference도 나타나는데 이것을 지워주기 위함입니다.
그리고 두번째는 초기 시작 위치를 조절하는 것이지요. 시작 위치는 75,25만큼 이동해서 오픈되겠습니다. 중앙에 오픈하려면 창의 크기 자신의 크기를 계산한 다음에 이동해도 되겠지요. 자신의 초기 크기는 preWindowOpen에서 정의한 크기가 되겠구요.
마지막 세번째는 window가 오픈된 이후에 시작해 주어야할 Thread를 시작해 주었습니다. job을 이용해도 되겠습니다만... 혹은 ui와 상관없는 것이라면 확장점 org.eclipse.ui.startup를 사용해도 되겠습니다.
쓰다보니 굉장히 길어 졌네요. 이 부분도 좀더 안정적이고 멋진 제품을 만들기 위해서는 알아야 할 내용입니다. 위에서 설명한 것 이외에도 설명해야 할 부분이 많이 있습니다만 차차 하나씩 적어 보도록 하겠습니다.
EclipseCon 2009 Demographics
이클립스콘 참가자들 통계라고 합니다.
외국에서는 이클립스 개발자들의 68%이상이 3년이상 이클립스를 사용했다고 합니다.
참여자들의 역할은 40% 개발자, 4% 테스터가 참여했네요.
음, 한국 같으면 90%가 개발자일(?)텐데..
자세한 내용은 http://eclipse.dzone.com/articles/eclipsecon-2009-demographics를 참고하세요
외국에서는 이클립스 개발자들의 68%이상이 3년이상 이클립스를 사용했다고 합니다.
참여자들의 역할은 40% 개발자, 4% 테스터가 참여했네요.
음, 한국 같으면 90%가 개발자일(?)텐데..
자세한 내용은 http://eclipse.dzone.com/articles/eclipsecon-2009-demographics를 참고하세요
부러운 소식
어제 eclipse community에서는 커미터 선거가 있었나 봅니다.
부럽습니다.
앞으로 이클립스에 관한 팁이나 글을 적을때는 되도록이면 영어로 작성해야겠습니다.
물런 될런지나 모르겠습니다.
부럽습니다.
앞으로 이클립스에 관한 팁이나 글을 적을때는 되도록이면 영어로 작성해야겠습니다.
물런 될런지나 모르겠습니다.
RAP로 Log in 부분 작성하기 2
어제 로그인 소스에는 정작 로그인 다이얼로그에 대한 설명이 없었습니다.
로그인 다이얼로그는 일반적인 로그인 창으로 작성하면 되겠습니다.
중요 포인트는 로그인 후에 세션을 설정해 주는것에 있습니다.
이유는 아래에서 설명했던것처럼 시스템이 비정상적으로 종료되었을때를 대비하기 위함입니다. 물런 사용자가 적고, 리소스를 많이 사용하지 않는 시스템에서는 아무 문제가 없겠지만 말입니다. 정작 문제가 되면 처음으로 살펴봐야할 부분이지요.
개발환경 설정이 약간은 복잡하므로(개발 테스트는 jetty, 운영은 tomcat)로 하므로, 저는 로그인 후에 세션 타임아웃을 지정하는 코드로 작성 했습니다.(일반 web은 web.xml에 세션 타임아웃을 지정할 수 있습니다)
코드의 중요한 부분은 다음과 같습니다.
대략 디비에서 조회한 아이디/패스워드가 맞다면 다음과 같은 코드를 추가해 주어야 합니다.
// 로그인이 정상적으로 됐다고 생각한다.
if( seMasterInfo != null ) {
ISessionStore sessionStore = RWT.getSessionStore();
final String sessionId = sessionStore.getId();
logger.info("[New RAP Session creation ] [session id]" + sessionId + "[login id]" + txtID.getText());
ISessionStore ss = RWT.getSessionStore();
HttpSession hs = ss.getHttpSession();
hs.setMaxInactiveInterval( 24 * 60 * 60 ); // 24시간동안 세션설정한다.
이렇게 하면 세션이 expire될때에는 ApplicationWorkbenchWindowAdvisor#postWindowClose()가 호출 될 것입니다.
그리고 정상적인 종료를 눌렀을 경우에선 ApplicationWorkbenchWindowAdvisor#preWindowShellClose()가 호출 되겠지요.
로그인 다이얼로그는 일반적인 로그인 창으로 작성하면 되겠습니다.
중요 포인트는 로그인 후에 세션을 설정해 주는것에 있습니다.
이유는 아래에서 설명했던것처럼 시스템이 비정상적으로 종료되었을때를 대비하기 위함입니다. 물런 사용자가 적고, 리소스를 많이 사용하지 않는 시스템에서는 아무 문제가 없겠지만 말입니다. 정작 문제가 되면 처음으로 살펴봐야할 부분이지요.
개발환경 설정이 약간은 복잡하므로(개발 테스트는 jetty, 운영은 tomcat)로 하므로, 저는 로그인 후에 세션 타임아웃을 지정하는 코드로 작성 했습니다.(일반 web은 web.xml에 세션 타임아웃을 지정할 수 있습니다)
코드의 중요한 부분은 다음과 같습니다.
대략 디비에서 조회한 아이디/패스워드가 맞다면 다음과 같은 코드를 추가해 주어야 합니다.
// 로그인이 정상적으로 됐다고 생각한다.
if( seMasterInfo != null ) {
ISessionStore sessionStore = RWT.getSessionStore();
final String sessionId = sessionStore.getId();
logger.info("[New RAP Session creation ] [session id]" + sessionId + "[login id]" + txtID.getText());
ISessionStore ss = RWT.getSessionStore();
HttpSession hs = ss.getHttpSession();
hs.setMaxInactiveInterval( 24 * 60 * 60 ); // 24시간동안 세션설정한다.
이렇게 하면 세션이 expire될때에는 ApplicationWorkbenchWindowAdvisor#postWindowClose()가 호출 될 것입니다.
그리고 정상적인 종료를 눌렀을 경우에선 ApplicationWorkbenchWindowAdvisor#preWindowShellClose()가 호출 되겠지요.
화요일, 4월 07, 2009
저번 주부터 거의 EclipseSource, Bugzilla에서 놀고있습니다.
Eclipse RAP소스를 통째로 받아서, 나름이해해 보려고 시도 중이기도 합니다.
RAP팀의 고통이 보이는 코멘트와 소스가 보이기도합니다.
예를 들어서 코멘트중에 'Equnox코드는 너무 복잡해서 다 이해하기 힘들다. 그렇지만, Equnox 버그인듯하다' 라던가....
영어가 어렵네요.
Eclipse 소스는 이제 볼만 하네요. 어디서부터 봐야하나, 시작해야하나.. 이런건 이제 내 안에 어느정도 정리가 된듯합니다.
그렇지만, 영어는 먼산인듯... 계획을 가지고 다시 시작해야할듯합니다.
Go to basic.
Eclipse RAP소스를 통째로 받아서, 나름이해해 보려고 시도 중이기도 합니다.
RAP팀의 고통이 보이는 코멘트와 소스가 보이기도합니다.
예를 들어서 코멘트중에 'Equnox코드는 너무 복잡해서 다 이해하기 힘들다. 그렇지만, Equnox 버그인듯하다' 라던가....
영어가 어렵네요.
Eclipse 소스는 이제 볼만 하네요. 어디서부터 봐야하나, 시작해야하나.. 이런건 이제 내 안에 어느정도 정리가 된듯합니다.
그렇지만, 영어는 먼산인듯... 계획을 가지고 다시 시작해야할듯합니다.
Go to basic.
일요일, 4월 05, 2009
RAP로 Log in 부분 작성하기
RAP프로그램에서 로그인을 부분을 작성하는 방법을 설명하도록하겠습니다.
RCP라면 보통 "org.eclipse.ui.splashHandlers" 확장점을 이용하거나 합니다.
그렇지만 불행히도 RAP는 이 확장점이 존재 하지 않습니다.
그래서 Eclipse3.2에서 사용하던 방법으로 처리해야 합니다.
RCP가 처음 시작하는 확장점은 "org.eclipse.core.runtime.applications"인 것 처럼 RAP는 "org.eclipse.rap.ui.entrypoint"를 시작점으로 하여 프로그램이 출발합니다. 이 시작점에서는
그래서 로그인 코드는 시작점(IEntryPoint은 RCP에서의 IApplication과 같은 용도)에 정의하면 되겠습니다.
RAP에서 로그인부분이 좀 틀린점이라면 로그인을 정상적으로 하고 난 후에 세션을 정의해 주는 부분입니다. 아래게시물에도 있었지만, 시스템자원을 반납해야하는등의 시스템에서 마무리 해야하는 코드를 넣어야 할 경우에 사용하기위해서 말입니다.
RCP라면 보통 "org.eclipse.ui.splashHandlers" 확장점을 이용하거나 합니다.
그렇지만 불행히도 RAP는 이 확장점이 존재 하지 않습니다.
그래서 Eclipse3.2에서 사용하던 방법으로 처리해야 합니다.
RCP가 처음 시작하는 확장점은 "org.eclipse.core.runtime.applications"인 것 처럼 RAP는 "org.eclipse.rap.ui.entrypoint"를 시작점으로 하여 프로그램이 출발합니다. 이 시작점에서는
그래서 로그인 코드는 시작점(IEntryPoint은 RCP에서의 IApplication과 같은 용도)에 정의하면 되겠습니다.
RAP에서 로그인부분이 좀 틀린점이라면 로그인을 정상적으로 하고 난 후에 세션을 정의해 주는 부분입니다. 아래게시물에도 있었지만, 시스템자원을 반납해야하는등의 시스템에서 마무리 해야하는 코드를 넣어야 할 경우에 사용하기위해서 말입니다.
목요일, 4월 02, 2009
수요일, 4월 01, 2009
RAP
widget이 종료될때 dispose()를 호출해 줍니다.
뷰파 트가 닫힐 경우라던가 이럴때 dispose를 호출해 주어서 사용하던 자원을 반납할수 있게 됩니다. 이미지도 반납해 주고, 사용하던 thread도 종료해주고요.
종료버튼을 눌러주면 dispose()메소드를 잘 호출해 주었습니다.
오늘 무심코 browser의 x버튼을 눌러서 종료했더니 dispose()를 호출해 주지 못했습니다.
버그 질라를 통해, 다음과 같이 해결 했습니다.
이런 경우는 session의 timeout을 이용해서 처리 해야 합니다.
Session을 설정하면 Session이 expire될때 RAP가 WorkbenchWindowAdvisor#postWindowClose() 를 콜백 줍니다.
그래서 꼭 없어져야 하는 자원이 있다면 postWindowClose에 코드를 집어 넣어야 합니다.
Login시에 session을 설정하고 sessiontimeout시간을 지정합니다.
//
// http session time을 정한다.
//
ISessionStore ss = RWT.getSessionStore();
HttpSession hs = ss.getHttpSession();
hs.setMaxInactiveInterval( 24 * 60 * 60 ); // 24시간동안 세션설정한다.
// 종료될때 호출해 주어야 하는 자원을 아래 처럼 기록해줍니다.
@Override
public void postWindowClose() {
................
}
뷰파 트가 닫힐 경우라던가 이럴때 dispose를 호출해 주어서 사용하던 자원을 반납할수 있게 됩니다. 이미지도 반납해 주고, 사용하던 thread도 종료해주고요.
종료버튼을 눌러주면 dispose()메소드를 잘 호출해 주었습니다.
오늘 무심코 browser의 x버튼을 눌러서 종료했더니 dispose()를 호출해 주지 못했습니다.
버그 질라를 통해, 다음과 같이 해결 했습니다.
이런 경우는 session의 timeout을 이용해서 처리 해야 합니다.
Session을 설정하면 Session이 expire될때 RAP가 WorkbenchWindowAdvisor#postWindowClose() 를 콜백 줍니다.
그래서 꼭 없어져야 하는 자원이 있다면 postWindowClose에 코드를 집어 넣어야 합니다.
Login시에 session을 설정하고 sessiontimeout시간을 지정합니다.
//
// http session time을 정한다.
//
ISessionStore ss = RWT.getSessionStore();
HttpSession hs = ss.getHttpSession();
hs.setMaxInactiveInterval( 24 * 60 * 60 ); // 24시간동안 세션설정한다.
// 종료될때 호출해 주어야 하는 자원을 아래 처럼 기록해줍니다.
@Override
public void postWindowClose() {
................
}
피드 구독하기:
글 (Atom)