코딩짜는 일상

현재 우리 회사는 웹으로 작업한 페이지를 앱을 통해 보여줌으로써 일부 서비스를 제공하고 있다. (특히 이벤트 페이지) 그중 룰렛 이벤트 페이지를 내가 만들어 제공했는데, 이상하게도 ios에서만 버튼이 동작하지 않는 오류가 있었다. 테스트 모달 처음에는 div type="button"이 안 먹히나보다~ 했다. 마침 디자인이 태그랑 비슷하겠다 a태그로 수정해 봤다. 테스트 모달 결과는 여전히 무반응... 다른 모달 팝업 버튼은 다 먹히는데 왜 얘만 안될까 해서 봤더니 다른 버튼은 button으로 되어있길래 태그로 바꿨다. 디자인을 a태그랑 비슷하게 가져가야 해서 스타일에 라인과 백그라운드를 투명으로 해줬다. ** 최종 ** 테스트 모달 ** 후기 ** 여전히 왜 이런 이슈가 있었는지 모르겠다. 마침 ios ..

오늘 장장 2일에 걸쳐 야근까지 하고서야 겨우 고객 클레임건 정리를 끝냈다... 정확히는 클레임 읽고 어떤 기능을 개발해야 할지 정리한 거니까 일종의 이슈 정리라고나 할까... 작년 9월부터 현재까지 약 7개월 정도 되는데 그 양이 무려 500여 건 이더라... 다시 생각해도 아득;; 근데 가만 보면 같은 내용 중복, 재문의 필요 건이 많아서 여기서 끝난 게 아닌가 싶다. 재문의 건은 회신도 없었으니까. 그 이슈가 사용자의 착각이었던 건지, 해결했는데 기록만 없을 뿐인지, 다른 클레임들에 묻혀 잊혀졌는지, 나로선 알 길이 없다. 이런 클레임만 제대로 소화했다면 더 많은 회원을 유치하지 않았을까, 짐작만 할 뿐... 실제 반년이 넘도록 개선 안 된 건이 있는데... 요게 최근에 '이야기한 지 몇 달이 지났..

어제 2주정도 붙잡고 있었던 array를 POST로 전달하는 문제를 해결했다. 개발 유지보수를 용이하게 하기 위함이었는데... 들인 노력에 비해 코드는 적용도 못 되고 사라져야 했다. 이유인 즉슨... 조회 결과를 배열로 만들어 주고받으면 조회된 rows가 많을 수록 배열 크기도 커지고 사용될 서버 메모리도 늘어날 것이라는 점이었다. 덤으로 전달받을 녀석에겐 필요한데 조회해서 넘겨줄 녀석에겐 필요없는 칼럼의 경우... 필요없는 칼럼까지 조회함으로써 시간을 더 소모할 수 있다는 단점도 추가된다. 크~ 이걸로 백엔드가 갖춰야 할 관점에 대해 한 수 배웠다. 진짜 많이 생각해야되넹;; 뭐... 일단 해결책으로는 1. 배열 말고 쿼리를 주고받는 걸로 바꾸고... 2. 기능 on하면 GET이든 POST든 변수A를..