ANMIAN

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

개발언어 : JSP, naver 지도API
DB : MySQL

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

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

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

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

DB: MySQL
개발언어 : JSP

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

invalid-file

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

구현만 하고 최종보고서를 작성하지 않은 것이 조금 아쉽다.
최종보고서는 시스템의 성능을 측정한 결과가 들어가야 할 것이다.