jQuery

네이버 지도 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에서 해결됬다고 댓글 하나 달아주는 책임감좀 있었으면....