네이버 지도 V3 REST API 개발을 최근 진행하였으며 요청에 따라 반경 3000M (=3Km)에 해당하는 Radius를 실시간으로 이벤트처리하여 구현할 수 있도록 개발 NAVER MAP 과 DAUM MAP 을 동등한 조건으로 REST API를 모두 비교했으나 왠지 기원과 뿌리가 같다고 느껴지는 느낌아닌 느낌을 받음. 그냥 감으로.. 아니면 서로 벤치마킹을 했거나... 굉장히 많은 쿼리허용량을 주는 관대함이 있으나 다시 생각해보니 하루 허용량을 저렇게까지 다 소비하는 앱/웹이 존재할까 생각이 되기도 함.... 하루 허용량이 모자를 정도라면 그냥 독립 GIS (Geographic Information System) 구현하는게 좋을 듯. 네이버 지도 V3 REST API에서 버그아닌 버그라면 Setmap 으로 오버레이를 다 지우는 과정에서 상식적으로 map 상에서 오버레이를 다 지우고 오버레이를 한 펑션안에서 쓰면 먼저 지우고 오버레이를 그린다 해도 오버레이는 그냥 지워지고 안뜸. 펑션밖으로 빼서 따로 따로 실행시켜줘야 반영이 됨. 난 지리정보에서 클릭을 했을 때 맵위에 오버레이를 지우고 다시 3km 반경 원을 그리고 싶은데 처리는 그냥 다 지워버리는 걸로 끝내는 버그아닌 버그가 있음. 아니면 네이버쪽 개발자들은 그냥 1펑션 1프로세스로 오버레이를 보는 걸지도... 내가 당사자가 아니니 알 길이 없고 그냥 답답해서 다른방식으로 해결 * 네이버 지도 v3에 대한 레퍼런스를 정말 답답하고 구글 디벨로버 포럼같은 건 기대하기 힘드니 알아서 응용처리 하는 걸 강력추천.

Cubrid SQL 문법에서 기존의 SQL 문법과 규칙으로 PK등을 만들때 INSERT가 되지 않거나 튕기는 문제가 있어 굉장히 애를 먹었다. 결국 찾아낸 이유는 Cubrid 9.2~9.3 버전대에서는 버그가 있다는 것. 문제해결이 되면 댓글을 달아준다고 했던 몇년전 글을 봤으나 결국엔 댓글을 달아주지 않고 어느덧 버전 10.x 에서 슬그머니 해결 된 듯.. 개발자라면.. 최소한 과거 자기가 속한 개발 산출물에 대한 책임감이 있었으면.. 댓글하나로 버전 10.x에서 해결됬다고 댓글 하나 달아주는 책임감좀 있었으면....

CMS 개발완료 주된 기술은 Cors (Cross Origin Resource Sharing)와 함께 IE11 전용으로 만드는것이 가장 핵심. JQuery로 개발하여 추후 어떤 플래폼 OS라도 소화 가능할 수 있게 개발하였으며 추후 CORS에 대한 대응이 브라우저에서 모두 가능 할 시점에 모든 브라우저에서 처리 가능 할 수 있게 미래지향적으로 개발 현재 브라우저 보안설정으로는 IE에서 도메인 원본간 데이터 전달 옵션사용으로 처리가능하도록 구현 그리고 호스트되는 서버에서 Access-Control-Allow-Origin처리 함으로써 호환이슈를 미연에 방지하였다.