posted by bluelimn 2010.12.19 15:33

import java.awt.*;
import java.awt.event.*;
import javax.swing.*;

public class AlphaImage implements AdjustmentListener
{
 private JFrame frame;
 private Canvas canvas;
 private JScrollBar jsp;
 private Image image;
 private AlphaComposite alphaComposite;
 private Label label;
 
 public AlphaImage()
 {
  image = Toolkit.getDefaultToolkit().getImage("1.jpg"); //원하는 이미지
  frame = new JFrame();
 
  jsp = new JScrollBar();
  jsp.addAdjustmentListener(this);
  jsp.setMaximum(265);
  jsp.setMinimum(0);
  image = Toolkit.getDefaultToolkit().getImage("1.jpg");
  label = new Label("alpha = " + jsp.getValue());
 
  canvas = new Canvas(){
   public void paint(Graphics g)
   {   
    alphaComposite = AlphaComposite.getInstance(AlphaComposite.SRC_OVER, (float)jsp.getValue()/255); //alpha값
    Graphics2D g2 = (Graphics2D)g;
    g2.setComposite(alphaComposite);
    g2.drawImage(image, 0, 0, this);   
   }
  };
  frame.add(canvas, BorderLayout.CENTER);
  frame.add(jsp, BorderLayout.EAST);
  frame.add(label, BorderLayout.SOUTH);
  frame.setSize(300,300);
  frame.setVisible(true);
 }

 public void adjustmentValueChanged(AdjustmentEvent e)
 {
 
  if(label != null)
   label.setText("alpha = " + jsp.getValue());
  if(canvas != null)
   canvas.repaint();
 }

 public static void main(String[] args)
 {
  new AlphaImage();
 }
}


'Projects > 얼굴특징점추출' 카테고리의 다른 글

java 투명도(alpha)조절  (0) 2010.12.19
tip : YCbCr to RGB, RGB to YCbCr  (0) 2010.07.04
posted by bluelimn 2008.08.28 09:04

정말 막 만든 것 같다.
그래도 datagridview를 프린트할수 있게 되서 한가지는 얻었다.

그런데 마지막에 세마포어 갯수가 넘친다는 오류는 못잡겠다.
전체를 catch해도 나오지 않는다.. 대체 어디서 해야하는거지?

===========================================================

아무튼 요구사항도 정확치 않고 대략적인 엑셀파일만 받아 시작한 내용
만드는 것보다 Test가 훨씬 힘들다는 사실을 실감했다.
사실 기자재부분은 test해봤지만 시약부분은 어떻게 돌아가는지 확인조차 정확히 안해봤다.
오류가 있는 프로그램을 그대로 보내버린 것은 자존심 상하는 일이지만
지금 그걸 잡고 있자니 시간이 너무 부족하다. 이것도 예상보다 커져서 더 오래 잡고 있었는걸..( 원래 2주만에 끝낼려고 했는데 중간에 피서가는 바람에 일주일이 더 소비되었다.. )

'Projects > 실험실기자재관리' 카테고리의 다른 글

사람들이란..  (2) 2008.09.17
실험실 자재관리  (0) 2008.08.28
아~ MySQL  (2) 2008.08.18
2008.05.02 16:26

보호되어 있는 글입니다.
내용을 보시려면 비밀번호를 입력하세요.

posted by bluelimn 2008.02.27 13:15

방학 중 lab에서 교수님의 권유로 시작한 프로젝트. 연구생들 모두 언어처리에 관련된 프로젝트를 시행해 보라는 반 강제적인 권유였다.
그 중에서 한국어 분석분야인 상품평 분석은 주제 자체가 어렵고 시스템의 완성도를 평가하기가 힘들다는 이유로 다들 기피했고 결국 나와 진호가 해보자고 붙었다.
한국어라 하더라도 기사나 발표자료 같이 문법에 맞는 글을 할만하지만 은어와 신조어 사용이 빈번한 인터넷 상품평을 분류하고 분석한다는 것은 정말 끔찍한 일이었다.
하지만 제대로 되기만 한다면 상당히 좋은 자료가 될 것 같다.
2007년 여름방학 때 시도학 프로젝트였는데 그때 lab에서는 스크립트 언어를 공부해보자면서 ruby언어 책을 사고 공부를 막 시작하고 있었다. 문자열처리에 상당히 강력한 ruby를 이용하여 구현시간을 많이 단축하였으나 알고리즘이 없어 시도가능한 방법은 다 사용해봤다. 나중엔 지쳐서 어떻게든 중간 결과가 눈에 보이도록만 하자는 심정으로 결과를 JSP로 출력하도록 했다.

네트워크를 통해 자료를 가져오는데 시간이 상당히 걸린다. 자료를 분석하고 분류하는데도 시간이 걸리지만 페이지의 내용을 가져오는데 걸리는 시간을 단축하면 시스템의 효율이 많이 높아질 것 같다. (이 부분은 희용이형이 만든 프로그램을 사용했다. 여러 페이지의 내용을 가져와야 하기 때문에 한번에 하나의 페이지를 가져오는 것이 아니라 여러 페이지의 내용을 동시에 가져올 수 있으면 훨씬 빨라질 것으로 보인다.)

우선 중간 결과까지 데모했지만 자연어처리의 문제점들만 잔뜩 찾아내고 진전이 없었다. 하지만 어떠한 문제들이 있는지 알았으니 다음 프로젝트에서는 그것을 기반으로 다시 일어설 수 있을 것이다.
이 프로젝트를 이어서 시작한 것이 CommentScop다. 하지만 여러가지 이유로 진행시키지 못하고 있다는...

TAG
posted by bluelimn 2008.02.27 12:55

지도API가 자바스크립트로 되어 있었기 때문에 클릭, 더블클릭 이벤트와 연동해서 각종 이벤트들을 발생시킬 수 있었다. 지원하는 기능들만으로도 꽤 쓸만했기 때문에 다른 내용을 거의 추가하지 않았지만 필요한 경우 얼마든지 자바스크립트로 수정할 수있다. 그런데 지도API를 사용하려면 사용하려는 계정주소를 입력하고 받은 ID를 넣어야 하기 때문에 해당 사이트에서만 구현된다. 만약 다른 곳에서 사용하려면 다시 ID를 받고 소스에서 ID를 바꿔야 한다. 나중에 ID를 넣는 부분도 한번에 지정할 수 있도록 바꾸려고 했는데 어떻게 되었는지 기억이 잘 나지 않는다.
웹 디자인도 팀원이 직접 그린 그림에다가 CSS를 이용한 스타일 지정. 역시 색상분류에 따르는 색상 선택 등으로 꽤 이쁘게 되었다.
많이 어설픈 부분도 있었지만 나름 만족스러운 프로젝트였다.
이 프로젝트는 구현은 빨리 끝났지만 데모를 위해 DB에 내용을 입력하는 작업이 오래걸렸다. 실제 버스노선을 조회해서 해당 위치에 정류장을 입력하고 이름을 똑같이 넣었다.
그리고 보고서에는 정류장끼리 직선으로 이어져 있지만 데모에서는 길을 따라 가도록 해 놓았다.
기존에 있는 것을 전산화 하면 자료를 입력하는 것도 엄청난 일이구나 하는 생각이 들었다.

'Projects > BusFinder' 카테고리의 다른 글

버스노선조회시스템  (0) 2008.02.27
버스노선조회시스템  (0) 2008.02.27
TAG
posted by bluelimn 2008.02.27 12:37
개발언어 : JSP, naver 지도API
DB : MySQL

자유 팀 구성 방식이었는데 팀을 구성할 때부터 다른 팀들의 질투를 받았던 팀이었다. 같은 LAB에 속한 구성원들끼리 팀을 이루었는데 팀원 모두 해당학기 성적이 10등내에 들었다.
처음에 지도를 사용하느냐 아니면 text로 보여주기만 할 것이냐를 두고 팀 내부에서 갈등이 많았으나 text로 보여주면 너무 허술해 보일 것 같아서 지도와 관련된 부분은 모두 내가 구현하기로 합의하고 지도를 넣어 발표하기로 했다.

팀 구성이 좋아 진행 속도도 빠르고 맡은 부분이 확실하니 별로 한다는 느낌도 없이 어느 새 완성되어가고 있었다. 다른 팀들이 중반부분까지 갈 즈음에는 이미 완성하고 이미지작업과 편의를 위한 기능들을 추가하고 있었다.

물론 모든 것이 순조롭게만 이어지는 것은 아니었다. 시스템의 기능을 정하고 분류하는 단계에서 모두 고집이 있어서 자신의 생각을 양보하지 않았다. 기능이 오락가락하니 DB schema도 덩달아 오락가락 했다.

주의해야 했던 것은 버스회사의 DB라면 버스정보가 중심에 있어야 하는데 시(市)에서 공개한 것과 같이 버스와 무관하게 버스노선과 배차시간만 보여주고 관리하는 시스템이었기 때문에 버스에 대한 정보를 넣지 않았다.
예를 들어 57번 버스가 있다고 하면 그 버스의 번호판이나 좌선 수 같은 부분은 신경쓰지 않는다는 말이다. 실제로 같은 노선(번호)의 버스라고 하더라도 좌석 수가 다르며 저상버스일 경우도 있다. 이처럼 버스에 대한 정보는 일치될 필요가 없으며 노선에 대한 정보만 정확하면 된다. 깊이 생각해보지 않은 상태에서 버스정보가 DB에서 누락되었다고 주장하는 교수님을 설득하느라 꽤 고생했었다.

'Projects > BusFinder' 카테고리의 다른 글

버스노선조회시스템  (0) 2008.02.27
버스노선조회시스템  (0) 2008.02.27
TAG
posted by bluelimn 2008.02.27 12:13
DB: MySQL
개발언어 : JSP

다시는 하고 싶지 않은 프로젝트였다. 두명이 팀을 이뤘는데 이 프로젝트마저 본의아니게 팀장을 맞게 되었다. 소프트웨어공학 프로젝트와 겹쳐있었기 때문에 자연히 시간이 많이 부족했으며 같은 팀원은 소공프로젝트에 몰입한 상태라 내가 아무리 시켜도 도망다니기 바빴다. 다른 팀들이 중반을 넘어갈 때까지도 아무런 진행이 없자 나는 프로젝트의 무산을 진지하게 생각했다. 프로젝트는 이런 식으로 넘어가는 것이 아니다. 나중에 과목은 재수강하면 되니 이번 프로젝트는 이대로 무산시키자 하고 이야기했더니 열심히 하겠다면서 매달린다.
JSP는 그때까지도 내겐 생소한 분야였고, 지금 생각하면 다른 프로그래밍 언어와 구조적으로 다를 것이 없으며 그냥 JAVA라고 생각하면 될 부분들도 소심해져서 제대로 보지 못하고 있었다. 안되면 혼자서라도 진행하자는 심정으로 사용될 것 같은 DAO(Database Access Object)를 무작정 만들기 시작했다. 분류도 없고 오락가락 하는 것이 정말 프로그래밍을 처음 해보는 사람 같이 만들어버렸다. 나도 소공프로젝트가 바빠써 주의깊에 고민할 시간이 부족했다는 핑계..
그렇게 해서 만든 DAO를 던져주며 페이지를 만들라고 했으나 팀원은 그것도 안했음.
결국 프로젝트의 핵심 내용은 내가 다 만들어놓고 꾸미라고 했으나 그것도 못하겠다고 함.
나중에 화가나서 다 구현해놨으니 일정을 달력에 표시하는 것은 알아서 하고 그 부분은 발표시간까지 구현 못하더라도 손대지 않겠다고 선언했음.
결국 팀원이 구현했으나 발표 시 그 부분만 지적받음.
채점은 다른 팀원들의 평가가 많은 부분을 차지하고 교수님의 평가가 추가되는 방식으로 점수는 후하게 받았으나 스스로 만족할 수 없는 프로젝트였다. 최악의 팀이었으며 최악의 프로젝트였다.
스스로 하려는 의지가 적은 사람과는 팀을 이루지 마라. 차라리 팀을 해체하고 다른 팀을 만들거나 혼자하는 편이 더 좋을 때가 있다.

'Projects > WebDiary' 카테고리의 다른 글

웹 다이어리 - 힘든 여정  (0) 2008.02.27
TAG
posted by bluelimn 2008.02.27 11:57
구현부분은 소스를 공개할 수가 없다.
C#은 객체의 속성들을 hardcoding할 수도 있지만 대부분 속성창에서 클릭으로 설정해버린다. 그런 경우 다른 곳에서 같은 설정을 할 경우 다시 클릭해야 하기 때문에 불편했다. 그래서 설정들을 모두 코딩한 다음 복사해서 바로 사용할 수 있도록 통일시켰다.
DB와 연동하는 부분이 어려웠다.
특히 실제 사용하는 사람들이 순서에 맞추어 사용하지 않기 때문에 유연성이 가장 문제가 되었다. 가령 사물함을 신청하고 제거할 때 수강기간이 만료되고 회원이 탈퇴하면 사물함이 비는 것이 정석이다. 하지만 실제로는 그렇지 않은 경우가 있다. 회원은 탈퇴하였으나 그 속에 짐들이 그대로 들어 있어 관리작 짐을 따로 보관하거나 혹은 그대로 얼마간 보관해주는 경우가 그러하다. DB에 회원이 없지만 사물함에서는 회원ID가 외래키(foreign key)로 지정되어 있었기 때문에 함부러 삭제할 수가 없었다. 어쩔 수 없이 꼼수로 해결하긴 했지만 지금 생각해보면 회원ID를 살려두면 된다는 생각이 든다. DB는 엄청난 자료를 가지고 있는 것이 보통이다. 회사 입장에서도 회원이 탈퇴를 하더라도 한번 수강한 회원이라면 우선순위가 높은 잠정적 고객이므로 정보를 유지하는 것이 더욱 유리하다. 그리고 회원ID를 그대로 살려두면 나중에 그 물건이 어떤 회원의 물건인지 알 수 있고 연락을 취할 수도 있다.
생각이 한쪽으로 굳어지면 고민 끝에 악수를 두는 경우가 많다.

구현만 하고 최종보고서를 작성하지 않은 것이 조금 아쉽다.
최종보고서는 시스템의 성능을 측정한 결과가 들어가야 할 것이다.
TAG
posted by bluelimn 2008.02.27 11:41
프로젝트도 중반이 되자 프로젝트 자체의 어려움보다 팀원 관리가 힘들었다. 팀이 원하는 사람들끼리 하면 잘하는 사람들끼리 모인다는 불만이 많아서 랜덤으로 모았더니 의욕이 없는 사람이 많았다. 의욕적인사람 4명 + 의욕없는 사람 2명으로 6명이서 작업하는 것보다 의욕있는 사람 3명이서 작업하는 것이 훨씬 진행도 빠르고 의욕적이다.
한명은 아예 나오지 않았는데 팀에 속해있다는 것만으로 의욕이 저하되었다.
만약 실무였다면 다 제거하고 3명이서 작업했을 것이다.

이 작업은 중심이 시스템구조도였다. 이건 DFD에서 지적받은 내용을 수정하고 DFD대로 설계만 하면 되는 작업이라 비교적 쉽게 했다.(물론 시간은 많이 걸렸다. 밤을 새면서도 다 끝내지 못해 발표하기 직전까지 작업했던 내용이다. 구조도를 그리기위해 A4를 약 4권가량 허비했던 기억이 난다.)

모듈설명서는 program language만 알고 있으면 누구든 보고 구현할 수 있을 정도까지 만들었다. 뿐만 아니라 구현 한 후에도 함수들에 대한 설명서가 될 수 있도록 만들었다.
하지만 모듈설명서를 발표 직전에 만들었으며 내가 작성하는 요령을 가르쳐주고는 알아서 하라고 던져줬기 때문에 양식과 내용이 부분적으로 일치하지 않는다.
더욱 심각한 문제는 기껏 다 만들어놓고서도 막상 구현할 때는 엉뚱하게 해버렸다는 것이다. 이유는 우리가 작업한 언어는 C#으로 객체지향언어였으며 구현할 때도 객체지향적 사고에 맞추어 구현했기 때문이다. GUI환경은 객체지향 프로그래밍이 훨씬 자연스럽기 때문이다. 만약 콘솔환경의 프로그램이었다면 모듈설명서대로 작업하지 않았을까 하는 생각이 든다. (이 작업을 하면서 객체지향 소프트웨어공학을 수강해야 겠구나 하는 생각이 들었다. 하지만 수강하기 전에 휴학을 했다는...)

UI는 경남이가 담당했다. 색상디자인 책까지 뒤지며 건강과 관련된 프로그램은 푸른 색 계열로 하는 것이 좋다며 색상과 모양까지 모두 디자인했다. 확실히 요즘 프로그램은 기능도 중요하지만 그에 못지않게 디자인도 중요하니까.. 이쁜 디자인과 거리가 먼 나로서는 부러운 능력이다. 실제 구현에서는 UI의 디자인이 제출 자료보다 더 이쁘게 완성되었다.
기능적인 부분으로 가면 디자인이 좀 불편하게 되었다. 입력부분은 한곳에 모으는 것이 좋은데 자료를 검색후 리스트에서 클릭으로 하는 것으로 많이 해놨기 때문에 익숙한 유저는 불편함을 느낄 수도 있다.
사용자가 입력하는 부분은 한곳에 모으는 것이 좋다. 한국의 경우 참고사항은 왼쪽, 입력사항은 오른쪽에 하는 것이 일반적이다. 자료를 검색 후 입력해야 한다면 다양한 방법으로 입력하는 것을 지원하라. 검색 후 클릭으로 입력, 검색 없이 입력, 검색 후 키보드로 입력 등 모든 사항을 고려해주는 것이 좋다.

DB schema는 별로 고민할 필요도 없이 혼자서 주욱 써서 내려갔고 ER diagram은 모두들 포기해서 역시 혼자서 작업했다. 그룹화는 가능한 피하려고 했으나 결국 그룹화가 나와버렸다. DB시간에 나름대로 열심히 공부했으나 역시 ERD는 경험이 많이 필요한 것 같다.
TAG
posted by bluelimn 2008.02.27 11:06
고생은 고생대로 하고 만족도는 떨어졌던 요구분석 명세서..
제약사항을 제대로 이해하지 못해 어떤 내용을 적어야 하는 지 고민했었다. 결국 이런저런 자료들 찾아보고 적긴 했는데 엉뚱한 내용들이었다. 실질적인 내용들이 공개된 곳도 없을 뿐더러 자세한 설명도 제대로 찾기 힘들었다.

DFD(Data Flow Diagram)는 정말 끔찍하게 고생했다. 팀원은 6명이었으나 벌써 2명은 나가 떨어지고 실질적인 작업은 4명이서 하고 있었다. 그나마도 나중에 한명이 안해서 3명이서 구현했다는 슬픈 전설이 이어져 내려온다.

그 중에서 DFD는 우리 팀이 처음으로 부딧힌 장벽이었다. 며칠동안 매일 모여서 밤늦게까지 회의했지만 사공은 많고 체계는 없어서 오락가락하다가 결국 원점으로 돌아가길 반복했다. 결국 다 엎어버리고 며칠동안 밤새면서 DFD를 혼자 A4에 그리고 그 내용을 권순형이 모두 PPT로 옮겼다. 그렇게 하니 진도가 빨라졌다.
의견도 내지 않으면서 문제점만 지적하는 것은 팀의 속도와 의욕을 떨어뜨린다.

DFD에서 대부분의 팀인 심한 감점을 당했는데 우리 팀은 거의 감점이 없었다.
2점이 감점되었는데 하나는 제약사항이 부실하다는 점에서 감점당했고, 1점은 DFD에서 중심 process가 호출하는 process를 기록하는 것은 맞지만 중심 process를 호출하는 caller까지 기록해버려서 감정당했다. (여기서 말하는 중심process란 대항 페이지에서 표현하고자하는 process다.)



TAG
posted by bluelimn 2008.02.27 10:24
개발언어 : C#
DB :  MySQL

소프트웨어공학1(이하 소공1) 과목에서 term project로 작업한 내용이다. 개인 과제만 받아오다가 처음으로 team report를 시작했고 팀장으로 있으면서 배우는 것도 많았다. 소공 1에서는 구조적 프로그래밍 기법에 의한 프로젝트를 했다. 아직까지도 구조적 기법을 많이 사용하고 있고 담당 교수님의 전문 분야가 구조적 프로그래밍과 DB였으니 한번 배울만 하긴 했다.

수업 내용만으로 프로젝트를 진행시킨 다는 것은 무리가 많았다. 수업시간이 짧아서 제대로 배울 수도 없을 뿐 아니라 직접 해보지 않고서는 무슨 이야기를 하는지 감이 오질 않아서 더욱 그랬다. 2주에 한번 진행과정을 발표했는데 발표가 다가오면 항상 밤을 새고 있었고 팀원들과 매일 만나서 의논하고 이틀에 A4한권 분량을 날렸다.
보고서 작성이 엄청 힘들게 느껴졌는데 작성하고 있을 시간도 부족했을 뿐 아니라 지식에 체계가 잡히지 않았으며 내가 생각하기에 조금 불필요하다 싶은 내용들도 다 보고서에 포함시켜야 했기 때문에 더욱 힘들었다.(내용 자체가 불필요하다는 것이 아니라 참여인원도 적고 프로젝트 규모도 적은 경우엔 필요하지 않은 내용도 있었단 말이다.)

처음 발표는 별 준비없이 시작한 주제발표였다. 선배들의 이야기를 들으니 다들 관리 프로그램만 만든다고 해서 우린 뭔가 새로운 것을 시도하려고 했으나 새로운 분야의 기술을 끌어들이면 그것을 공부해야 하는 시간도 들고 발표준비까지 하려면 시간이 부족해서 반도 못할 것 같아 결국 관리 시스템으로 정했다. 어떠한 관리 시스템이건 다 비슷했던 것 같다.
만약 지금 했다면 웹과 연동시켜 좀더 확장된 프로젝트를 했겠지만 그당시엔 실력 부족때문에 많이 소극적이었다.
TAG
posted by bluelimn 2008.02.27 10:12
아직 프로젝트는 시작하지 않았고 사전 자료 수집과 준비작업 중이다.
아래는 보컬로이드라는 소프트웨어인데 설명에 나오는 것처럼 일본 애니애니메이션 음악 생성기란다.
오타구들을 15750엔이라는 부담스런 가격에도 일본아마존에서 판매 1위였다는 내용이 언뜻 보인다.

이 SW는 기본적으로 발음을 하나씩 입력해두는 방식을 채택하여 음성합성을 하고 있다.
이러한 방식은 우리나라에서도 음성안내 시스템에서 적용하고 있는 것으로 알고있다.
각 발음들을 독립적으로 녹음하여 그러한 발음들을 이어붙여서 말을 만들어내는 것이다.

거기에 음의 높낮이를 선택하여 노래를 만든다...
이러한 기술도 연재 대량생산용 가수들에게 많이 사용되고 있는 것으로 알고 있다. 불안정한 음을 기계적으로 맞추어 주는 기술이다.

결국 SW는 음이 변하지 않으면서 발음도 변하지 않는 것을 기준으로 나누어야 하고 발음이나 음의 높이중 하나라도 바뀌면 그곳을 기준으로 다시 나누어줘야 한다. 각 객체는 발음, 음의 높이, 길이를 속성으로 가지고 있으며 대부분은 그것을 사실감있게 재생하는 코드로 예상된다.

노래를 부르는 소프트웨어라... 꽤 효율적인걸..

=================================================================================================================

VOCALOID 2: The Japanese Anime Song Generator

otakusong.jpg

ThinkGarageband for otakus. This Japanese software suite lets you plug inlyrics and melody and generates an "authentic-sounding" song via itsmusic and vocal synthesizers. As you can see above, the softwarefeatures a 16-year- old "Virtual Singer," which croons out whateverdisgustingly sweet (or just disgusting) lyrics you enter in (Japaneseonly, we're assuming). It's so popular in Nippon that it's actually the#1 selling software on their Amazon. And for good reason—the songs theygenerate actually sound like it could have come from a generic teenagedanime. Hit the jump for two videos.

TAG
posted by bluelimn 2008.02.27 10:12

플렉스 센서와 3축 가속도 센서를 이용한 cyberglove를 만들고 그것을 demo할 software를 만들고자 했었다.
SW는 간단한 이미지 편집기..
하지만 무산됐다. 시작도 못했다.
두명의 팀원..
혼자서 시작은 했다. 간단히 메뉴를 나누고 UI를 디자인했다.
어설프지만 form을 만들어놓고 바쁘다는 팀원을 위해 기다렸다.
지난 주 월요일부터 박차를 가하려고 했으나 오늘까지 연락이 없어서 관두고 나중에 술이나 하자고 문자를 보냈다.
어차피 전화를 해도 잘 안받으니까..
답장도 없다.
정말 그럴듯한 아이디어도 아니고 다 해봐야 그냥 프로젝트 하나 해놔서 한학기 좀 편하게 지낼 정도의 수준밖에 되지 않는 프로젝트였다. 그런 프로젝트를 진행하면서 제발 좀 하자고 매달려서 애걸복걸하기 싫다. 지금 상태로는 끝날 때까지도 혼자서만 안달날것 같아서 일찍 포기했다.
어차피 이 프로젝트에 큰 애정이 없었다. 다만 사람에게 실망한 마음이 크다.
한사람 두사람.. 나에게 실망을 안겨주는 사람들.. 이젠 사람들 믿기가 어렵다.

이렇게 해서 첫번째 시스템개발 프로젝트는 무산되었다.
이제는 개별적으로 시스템개발 프로젝트를 진행하려고 한다. 1인 프로젝트..

TAG
posted by bluelimn 2008.02.27 10:10
프로젝트에만 매달리고 있을 시간이 부족하다.
역시 프로그램화 하는 것은 알고리즘만 확실하면 금방 해낼 수 있는 것 같다.
알고 있는 부분까지는 이틀만에 왔지만 그 다음 어떤 아이디어로, 어떤 방법으로 문제를 해결해야 하는지 모르니까 영 진도가 안나간다.
2월이 시작하면 다시 프로젝트에 집중해봐야 겠다.
TAG
posted by bluelimn 2008.02.27 10:09
이제 수집한 평가들을 제목과 내용을 다른 파일에 나누어 저장했다.
한 사이트에서 디지털 카메라에 대한 내용이 2150건 문장이 7972건으로 나왔다. 정확하게 counting되었다고 볼수는 없다. 하지만 대략적인 갯수는 알 수 있다.
이제 이것을 형태소 분석기를 거쳐나온 결과를 분석해야 한다. 형태소 분석기는 국민대 강승식 교수님의 KMA로 시도했다. 그런데 이사람 2007년 이후에는 새로운 결과물을 반드시 낼 것이라고 생각했는지 2008년에는 결과가 안나오도록 조정해놨다. 그래서 귀찮지만 형태소 분석기를 사용할 때는 시스템 시간을 과거로 맞춰놓고 사용한다. 나중에 이 문제는 해결해야 겠다.
예전에 프로젝트를 할 때는 아무런 옵션도 주지 않고 그대로 사용해서 많이 지저분했는데 옵션 몇개만 추가하니 비교적 깔끔한 결과가 나왔다.
이것을 중요한 형태소(N, K, V)만 따로 분류하여 각각 파일에 저장하였다. 이 부분은 현재 if문으로 되어 있는데
방향을 좀더 생각해보고 case- when 구문으로 수정할 계획이다.
지금부터가 문제다. 분석된 N,K의 명사들을 가지고..(참 C도 복합명사로 분류해야 겠다...)

이 부분까지는 쉽게 왔다. 이제부터가 새로운 시작이다. 예전의 프로젝트는 쓰기 곤란할 정도로 엉망이었다. 억지로 사전을 만든 다음 거기에 운좋게 걸리면 분석하는 식이었다. 지금부터는 관심 단어를 추출하는 것부터 시작해야 겠다. 그 다음엔 동사의 극성화 분석.
마지막으로 명사와 동사로 일부 구문분석을 하는 것이다.
1. 핵심단어(명사) 추출
2. 동사의 극성화
3. 극성화를 토대로 한 구문분석

이중 1번만 제대로 되어도 활용할 분야가 많다. 웹상에서 각 페이지의 관심단어들을 추출해서 웹검색에 활용하는 것, 여러 페이지들의 주제를 분석하여 해당 부분, 사이트, 기간 별로 관심주제를 추출하는 것, 관심이 집중되는 내용들을 수집하여 다시 검색한 다음 사용자에게 자동으로 RSS를 보내주는 것등 다양한 방면으로 활용이 가능하다. (이런 식으로 취업에 관한 사이트들을 등록시키고 취업에서 중요시하는 단어들을 가져올 수도 있다.)
일단 1번을 향해서 나가자
TAG
posted by bluelimn 2008.02.27 10:08
개발언어 : ruby
DB : text file

프로젝트 이름을 CommentScope로 정했다. 대략 '평가관찰기'정도의 뜻이 되겠다.
예전에 해봤던 일이니 그 수준까지 따라가는데는 시간이 얼마 걸리지 않을 것이라고 생각했다.
다만 그때까지 나누어 작업하던 것들을 모조리 내가 다시 작업해야 하니까 그 부분에서는 시간이 좀 걸렸다.
개발언어는 script language인  Ruby로 정하고 output은 웹(jsp)로 정했다. jsp를 사용하기 위해서 ruby를 java로 실행해야 하는 것을 감안해야 한다.

이틀만에 2주간 한 작업을 모두 따라갔다. 그동안의 프로젝트가 거의 내 아이디어로 나왔었고 핵심부분은 내가 다 작성했기 때문에 따라가는데 얼마 걸리지 않았다. 다만 그당시엔 제품ID를 넣으면 그 상품에 대한 평가들이 수집되는 것만 만들었기 때문에 이번에는 전체 분류에서 제품ID를 수집하고 수집된 ID를 가지고 다시 상품평을 받아오는 것으로 바꿨다. (나중에 사전을 만들기 위함이다.)
꽤 많은 상품평이 받아졌다. 참.. 결과를 보여주기 위해 수집된 상품평이 몇개인지는 기록해야 겠다. 좀 손봐야 겠군..

(고치고 있는 중..)


파일의 마지막에 count를 기록하는 방식으로 우선 해결했다. 형태소분석기를 거칠 때 빼줘야 정확하지만 무시해도 될 한 문장이기에 그냥 넣기로 했다.

이로써 상품평의 수집은 어느정도 해결된 것 같다. 문제는 지금부터다. 지금까지는 문제를 해결하기 위해 문제를 가져오는 것밖에 되지 않는다.
TAG
posted by bluelimn 2008.02.27 10:07
기본적으로 자연어중 한국어를 대상으로 자동 의미분석을 통해 상품평을 분류한다는 개념이다.
이 프로젝트는 2007년 여름 lab에서 시작한 프로젝트로 진호와 내가 거의 둘이서 진행한 프로젝트다.
당시 의욕도 없었고 진행상황도 좋지 않아서 방학이 끝남과 동시에 종결되었던 불운의 프로젝트였다.
그런데 2007년 10월에 서울대에서 같은 프로젝트로 논문이 나왔다.
분석률이 88%이상이라는데 분석 대상 문장이 64건 밖에 없었다.
(참고로 우리가 프로젝트 할 당시 분석한 대상만 해도 5000건이 넘었고 자동분석이 아니라 사람이 직접 분석을 한다고 해도
오타와 분석 불가능한 단어들을 무시하면 분석률이 50%가 되지 않는다.
개인적인 생각으로 맞춤법을 정확히 지키지 않는 상품평에서 분석률이 80%가 넘는다는 것은 사기행위이며 결과조작이다.)

뭐 그렇다는 이야기고.. 어쩌면 필요 없을지도 모르는 프로젝트를 다시 손대기 시작했다. 물론 제한사항이 많다.
형태소분석기를 국민대에서 개발한 것으로 끌어다쓰고 상품평 수집도 bb.co.kr사이트 하나로 제한하고 있다.
하지만 그것은 어디까지나 부수적인 내용일 뿐.. 상품평 수집은 어떠한 것을 하더라도 상관 없도록 일단 txt파일로 저장하기로 했다.
형태소 분석기는 일단 프로젝트가 어느정도 수준으로 올라가면 API를 이용해 다른 곳에서도 이용 가능하도록 시스템을 바꿔보도록 해야겠다.

문제는 프로젝트의 진행 방향이다. 상품평을 단순히 분석하는 것은 이미 서울대에서 선수를 쳤기 때문에 아무런 의미가 없다.
동사의 양극화 분류도 논문이 많이 있다. 내가 아직 거기까지 이해하지는 못하지만 참고해서 따라하면 많은 도움이 될 것 같다.
지금 발표된 자료는 구문분석을 통해서 문장에서 의미를 분석해 분류하는 방식인데 구문분석을 통하지 않고 하도록 노력해봐야 겠다. 구문분석기는 정확도가 떨어지기 때문이다.
(지금까지 발표되 구문분석기의 성능은 정확도 3~40%대로 알고 있다. 또다시 서울대의 사기성 분석률이 떠오른다.)
TAG