푸시 발송을 FCM 레거시 API로 발송하고 있어서, 최신 SDK를 이용해서 푸시가 발송되도록 코드를 수정했다. 페이로드 형태가 약간 변했는데, 호환될것 같은 형태로 코드를 수정했다. 당시 가지고 있던 아이폰으로 발송 테스트는 잘 했다. 그러나 배포 다음날 대량 푸시발송을 했을 때, 안드로이드폰의 지표가 이상한것을 확인했다. 확인해보니 푸시는 발송되었지만, 푸시 랜딩과 푸시를 수신했다고 하는 로그를 저장하는 기능이 동작하지 않았다. 안드로이드 개발자의 도움을 받아 원인은 파악했다. 원인은 페이로드 형태가 이전과 호환되지 않는 것이었고 호환되도록 수정해서 바로 배포했다. 이 오류로 안드로이드로 발송된 푸시가 정상동작하지 않았고, 고객은 특정 메시지의 푸시를 눌렀지만 앱만 켜지고 아무것도 안하는 경험을 했다..
돈(금원)과 관련된 기능은 중요하다. 문제가 발생했을 때, 금전적 손실을 일으킬 수 있다. 만약 작은 회사라면 금전적 손실이 회사 전체의 리스크가 될 수 있다. 돈과 관련된 기능을 다룸에 있어서 다른 여타 기능들 보다 더 면밀하게 살필 필요가 있다. 돈과 관련된 기능을 어떻게 다뤄야할 지 동료들과 회고한 내용을 좀 적어두려고 한다. 1. 이상 상황을 곧바로 탐지할 수 있는 장치가 있어야한다. 문제는 언제든 발생할 수 있다. 문제를 빨리 감지하는 것이 중요하다. 간단하게 비즈니스 메트릭을 구축하고 임계치가 벗어났을 때 알람을 주게 한다던지, 특정 에러상황에서 에러 알림이 오게 한다던지, 이상 탐지 장치를 꼭 구축해야한다. 2. 이상 상황의 문제를 빠르게 식별하고 차단 및 해결할 수 있는 장치가 있어야한다...
휴일에 버그를 발견했다. 한동안 존재하던 버그였다. 발견하자 마자 바로 고쳤다. 바로 공유할까 하다가 휴일 끝나고 공유해야지 라고 생각하고 휴일을 보냈다. 그리고 평일에 까먹었다. 다른 동료가 데이터를 보던 도중에 그 버그가 있었다는 것을 발견했다. 다음 부터는 문제가 있으면 바로 공유해달라는 피드백을 받았다. --- 개발자가 자의적으로 어떤 버그는 큰 영향이 없는 버그라고 판단하고 공유를 하지 않을 수도 있다. 그러나 데이터를 기반으로 의사결정하는 경우에 (공유받지 못한) 그 이벤트를 통해서 영향받은 데이터가 팀의 의사결정이 올바르지 않은 방향으로 가도록 할 수 있다. 버그가 있었고 그 버그가 데이터를 왜곡했고 팀은 왜곡된 데이터로 잘못된 의사결정을 할 수 있다는 뜻이다. 공유를 하지 않은 개발자의 판..
문제 상황 직접 http 요청(curl)을 할 경우에는 응답에 CORS 관련 헤더가 적절하게 내려오는데, 하이브리드 앱 웹 뷰에서 그 API를 호출하면 CORS 오류가 발생 실제 요청을 수행하는 backend 서버 까지 여러 레이어가 있는 상황 (사용자 요청 --> NGINX --> GATEWAY --> BACKEND SERVER) 문제 접근 CORS 문제라고 판단하고 관련 헤더가 잘 세팅이 되는 지 확인 잘 되는 것 확인 후 로그 분석했지만 딱히 문제 없음 CORS에 집중해서 직접호출과 웹뷰에서 API 호출을 비교 특정 시스템 웹뷰에서 특정 문제가 있는지 확인 결국 못찾음... 실제 문제 CORS랑 전혀 상관없는 nginx의 request body 크기 제한 이슈 사이즈가 큰 파일을 request bo..
보호되어 있는 글입니다.
보호되어 있는 글입니다.
상황. 참 잘 돌아가는 소스코드이지만, 웹 상품 리스트 쪽 레거시 코드가 참 맘에 안들었습니다.첫째로 맘에 들지 않았던 것은 뷰단의 jsp 코드가 제 마음에 너무 들지 았았습니다. 스크립틀릿으로 중복되고 복잡한 로직이 있는 것도 맘에 들지 않았고, 스크립트와 스크립틀릿이 섞여서 이해하기 어렵고 수정하기 어렵고, 스크립트와 html간의 의존성이 높은 코드도 맘에 들지 않았습니다.둘째는 같은 비즈니스 로직인데 앱쪽과 웹쪽이 다른 식으로 구현된 것도 맘에 들지 않았습니다.셋째도 비슷한데 같은 화면인데 다른 로직과 다른 파일들로 구현된 것이 맘에 들지 않았습니다.그래서 이 부분을 꼭 수정하리라 벼르고 별렀습니다. 신규 프로젝트가 시작되었습니다. 이번 기회에 맘에 안드는 부분을 뜯어 고치기로 계획했습니다. 사실 ..
호출된 URL을 가지고 PV를 집계하는 솔루션이 있습니다. 그런데 어느 날 부터 모바일의 특정 페이지 PV가 평상시의 세배 이상으로 증가했습니다. 아무리 원인을 찾아봐도 3배로 증가할 외부적인 요인이 없었습니다. 팀장님께서 혹시 img태그나 script태그의 SRC에 빈문자열이 들어가있는지 확인해보라고 하셨습니다. 크롬에서 콘솔을 열고 jQuery를 이용하여 찾아봤지만 그런것은 없었습니다. 피들러를 이용해서 한번 호출시에 여러번 URL을 호출하는지 확인해보았지만 그런 것도 없었습니다. 참 답답했습니다. 그런데 이미지의 크기를 변경시키는 스크립트 함수 중에서 이미지 URL을 사이즈 별로 계산하여서 SRC에 삽입하는데, 생각보다 빈 문자열이 되는 상황이 많았습니다. 그 부분이 가장 의심스럽긴 하지만 피들러로..
이번에는 웹 프로젝트를 진행했습니다. 상품리스트를 가져와서 그려주면 되는 간단한 프로젝트였지만, 3가지 영역에 광고 상품이 있어서 신경쓸 필요가 있었죠.이번 프로젝트를 진행하면서도 실수가 있었고, 그 실수들을 정리해보고자 합니다. 1. 지운줄 알았던 코드광고는 보통 해당 광고가 없을 경우에 '대체로직' 이 있습니다. 이번 프로젝트에서 그 대체로직의 변경이 있었습니다. 기존의 로직 변경된 로직 - 해당 광고- 대체로직 1 : 수동 입력 광고- 대체로직 2 : 정렬 순서 상위 상품 - 해당 광고- 대체로직 1 : A 광고- 대체로직 2 : 정렬 순서 상위 상품 기존에는 대체로직이 도메인(DAO, Service) 쪽에 존재해서 저도 그 곳에 수정을 했습니다. 그런데 사정 상 그 로직을 Controller(Ac..
오늘은 XPER 모임이 있는 날입니다. 그런데 프로젝트 때문에 참여하지 못했네요. 너무 아쉽습니다. 그래도 배포하기전 저의 문제에 대해서 정리를 좀 해보고 싶었습니다. 이번 프로젝트를 통해서 부족한 점이 많이 드러났기 때문입니다. 1. 기술적인 문제 - 인코딩 / 디코딩 지식 부족 - 앱 스킴 (app Scheme) ??? - 자바스크립트 인라인으로 onclick function 삽입과 addEventListener를 이용한 function 삽입에 대한 차이. - 자바스크립트 setTimeout의 의미 - Exception을 어디에서 Catch할지에 대한 결정 - 우리 배포 툴 사용법 - WEB VIEW 란 무엇인가 2. 태도의 문제 - 기획서를 자세하게 보지 않는다. (근데 너무 복잡해 ㅠㅠ) - 일의..
- Total
- Today
- Yesterday
- Bali
- Clean code
- 사누르
- AWS
- 웹
- 한달살기
- javascript
- 발리
- 도커
- 독후감
- ChatGPT
- 개발자
- spring
- springboot
- container
- ecma6
- ES6
- sanur
- spring boot
- 회고
- 컨테이너
- 객체지향
- 웹을 지탱하는 기술
- S68
- hands-on
- Docker
- AWSKRUG
- rest
- 실수노트
- html
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | 5 | ||
6 | 7 | 8 | 9 | 10 | 11 | 12 |
13 | 14 | 15 | 16 | 17 | 18 | 19 |
20 | 21 | 22 | 23 | 24 | 25 | 26 |
27 | 28 | 29 | 30 | 31 |