2013년 9월 26일 목요일

SNS 개발하기 #4. 네이버 지도 붙이기

문화행사 공지를 하면서 지도 표시 기능을 구현하였다.

검색해보면 많이 나오기도 하지만, 참 간단하면서 요긴한 것 같아서 포스팅 해본다.

1. 네이버 지도 API 참조
2. 관리자 기능에서 행사 등록시 지도 표시 및 위/경도 값 저장
3. 사용자 기능에서 행사 조회시 지도 표시 위치 조회

자...
1. 네이버 API
- 일단 지도 API 키를 등록하자.
이 키는 호스트 장비 하나당 하나씩이다 보니, 내 PC, 개발장비, 배포장비 모두 키를 등록해야만 하더라...

- API 참조문서에 보면 예제가 자세히 나와있다.
http://developer.naver.com/wiki/pages/MapAPI
여기와 기타 등등 참조하고...

- 페이지 상에 아래와 같이 네이버 맵 js 를 포함하면서 키값을 줘야 한다.



2. 자.. 어드민에서 관리자 화면에 지도를 붙여보자.
- 붙이고자 하는 화면

- 지도보기 버튼을 누르면 다음과 같이 뿅~
- 소스를 보면...
A 에서 지점을 하나 선언하고, (A' 은 지점의 위경도 좌표값이다.)
B 에서 Map 객체를 생성하면서 지점정보와 기타 옵션들을 같이 등록한다.
 맵객체가 표시될 HTML 객체 (여기서는 div) 에 뿌려주게 한다.
 나머지 아래는 슬라이더바, 콘트롤 바 (지도상의 확대/축소표시, 일반/위성 표시) 이다.

- 이제 실제로 지도상에 클릭을 했을때, 지도상의 좌표값을 저장하는 것이 최종 목표이므로,

제일 마지막줄에 addClickEvent() 함수는 페이지 로딩 후에 등록시켰다.

제일 중요한 클릭 이벤트 clickEvent 함수를 보면
좌표 X, Y 값을 가져오고,

미리 선언한 oMarker 객체가 이미 값을 갖고 있으면 삭제(다른 지점을 눌렀다는 의미).

그리고, 현재 클릭 지점 값을 저장.
oPoint 객체를 새로 생성해서 oMarker (마커 객체, 표시되는 지점) 에 세팅한다.
oMarker 마커 객체를 맵객체 oMap 에 추가한다.

그러면, 아래와 같이 화면에 나온다. 여기 저기 눌렀을 때...


- 마지막으로 확인 버튼을 누르면 저장해준다.



3. 사용자에서 조회하기.
- 그럼, 사용자 쪽에서는 등록된 지점만 조회 하면 되므로 더 쉽겠다.
등록한 지점을 중심으로 해서 마커가 움직이지 않고, 고정되게만 하면 된다.
(그냥 움직일 수 있는 옵션을 주지 않으면 그만이다.)

관리자용 소스와 거의 똑같고, 다만 최초로딩시 등록 지점 (oPoint) 를 변수로 받아서 표시해야 하므로 위와 같이 jsp 변수 처리했다.

- 실제로 로딩된 화면

아... 간단하기도 해라...

끝!!


2013년 9월 15일 일요일

Sns 개발하기 #3. 구성도

#2에서 언급했던 몇가지를 간단히 그려보았다.

단순한 구성도인데, 참고삼아 그려보았다.











다음카페에서도 확인 할 수 있음

http://cluster1.cafe.daum.net/_c21_/bbs_read?grpid=1JDNF&fldid=Fv9Q&contentval=00002zzzzzzzzzzzzzzzzzzzzzzzzz



2013년 9월 14일 토요일

Sns 개발하기 #2. 기획, 아키텍처

후덜덜 아이패드에서 작성하다가 사진찾으러 나가갔다가 와보니 글 쓰던거 다 날라갔네...

기획에대해...

거두 절미하고, 
sns 는 단순해 보이지만,  한페이지 안에  많은 개발요소가 존재하기 때문에 기획 단계에서 세심한 배려가  필요하다. 그렇지 않으면 개발자가 자칫 구현해야할 기능을 오해하거나 심지어 개발을 안해버릴수도 있다.

실전에서 문제가 발생한 사례로,
기획자가 나름 디테일하게 정의하는 과정에 초안은 심플했지만,
갈수록 디테일을 추가하다보니 처음 30장이던 기획서가 거의 세배가 되어버렸다.
게다가 기능이 여기저기 엉키다 보니 1페이지에서 못다 기술한 내용이 40, 50 페이지에 나오기도하고
이정도는 예측하겠지 하고, 생략하거나, 카피앤 페이스트로 넘겨버린 뒷페이지에서 혼동을 발생하기도 했다.

내 생각은 이렇다.
큰 기획페이지를 보여주고, 디테일한 기능이 있다면 체크 표시를 해주고 인덱싱을 했더라면 좋았을 것같다.

아래 캡쳐를 예로들어서,



1, 2 는 바보가 아닌 이상 누구나 예상할 수 있다.

3, 4, 5 는 별것 아닌것 같아서 기획자로 기능이 있다고 표시까진 해주지만 사실 개발자 입장에서는 의외로 생각할게 많은 기능이다. 생각이 많이 필요하다는 것은, 성능, 구조 즉 아키텍처와 직결된다.

6,7 은 정말 자세히 명기해주지 않으면 개발자가 모르거나 잘못구현할수 있는 기능이다.
그것도 몰랐냐고 하면 할말없구... ㅋㅋ  난 몰랐으니까능...

A 의 경우도 저런 기능이 있다는 표시만 해놓으면 개발자는 참으로 난감하다.


아키텍처 얘기로 넘어가보자.

3번의 좋아요를 얘로 들어보자.
sns 라는건 개인대 개인의 이슈 드리븐이다. (이건 그냥 내 표현이다.)
기존의 게시판 개발로 생각한다면 굳이 개발할 수 없지는 않겠지만, 역시 뭔가 찜찜하다.
a가 b한테 좋아요를 했는데 관계형 db의 좋아요 테이블에 넣었다 뺐다 해야 할까?

내가 했던 프로젝트에서는 유저 폴더에 파일을 떨구기로 했다 (내 아이디어는 아니었다)
정확히는 좋아요는 아니었고, 알람이나 공지가 왔을 때 그리 하기로 했다.
그러다보니 회원마다의 폴더 생성하는 메카니즘이 회원 가입 시점에 들어가야 했고, 관련 정보를 가져올때 db와 폴더를 같이 조합해야하는 조회 매카니즘이 필요했다. 이건 바른걸까?

내가 처음 제안했던 방식은 회원별 이슈테이블이었다.
똑같이 회원 가입 시점에 회원고유 테이블 생성 메카니즘이 필요했고, 조회시 관련내용을 조합하는 메카니즘이 필요하게된다. 하지만, db-파일 조합 메카니즘과, db-db 조합 메카니즘... 둘중에 후자가 좀더 낫지 않을까?

내가 가장 하고싶은 이야기는 윗부분이다.
그외에 필요했던 몊가지 아키텍처를 붙여본다.

- 데이터 비동기 로딩 처리 (요즘 뭐 많이하는...)
- html 과 js 바인딩 (jstl 없는 바인딩)
- ui 어플리케이션과 api 어플리케이션 분리
- java web restful service
-node.js 로 알람, 채팅 실시간 양방향 처리

이정도...

다음에는 아키텍처 그림 몇장을 넣어볼까한다.

2013년 9월 13일 금요일

sns 개발 이야기 (개발자 입장에서) #1. 방향 설정

* prologue
이 글은 모 대학 sns 개발에 참여한 경험을 회상하면서  3개월여만에 기획부터 시험, 배포까지 짧은 기간 개발후,  최대한 감이 사라지기 전에 경험재산을 공유하고자 정리하는 글이다.
그간 나는 sns 를 비롯한 스마트폰 기반 기술에는 별 관심이 없었고, 개발자라는 한계가 있기에 기획, 디자인, 퍼블 등에대해서는 자세히 다루지 못할거라는아쉬움이 있다.


1. 개발방향 잡기
sns 에 대한 충분한지식이 없는고로 빠른  개발과 조금이라도 덜 고민하기 위해. 페북을 모델로 잡았다.
기본 기능은 페북을 지향하고 디테일에서 고민하자는 것.

페북을 기본으로한다해도 첨부터 다 개발하지는 못하고, 특히나 발주처 요구사항 이상을 개발할 필요도 없겠다. 고로 기본 필수 기능을 정리해보면
- 글쓰기 : 타임라인, 댓글, 좋아요
- 글취합 : 뉴스피드 (타라와 뉴피를 구분하는데 몇주가 걸렸다능...ㅋㅋ)
- 그룹 : 공지, 뉴스피드, 그룹원관리 (초대/수락/탈퇴),
- 채팅 : 개설, 메세지 등 일반채팅
- 프로필 : 사진, 배경, 알람설정
- 친구관리 : 초대, 수락, 검색, 쪽지
- 알람
이정도.... 근데 적고보니 꽤많네...

여기에 업체에서 특성화해서 추가한 기능
- 선물하기 (+머니)
- 모바일 학생증
- 문화캘린더

정도 되겠다.


2. 개발스펙
- java spring3
- iBatis, jQuery, Json
- html5, css3
- MS-SQL DB
- node.js

다음글에는 기획과 아키텍처를 써볼까한다.