쑥로그

사용스펙 Kotlin, MongoDB 왜 찾게 되었을까? 자원관리 모듈을 맡아 API를 만드는 중에 '자원은 검색이 용이해야하지 않을까?' 라는 생각을 했다. 방식을 찾을 때 염두한 것은 세 가지가 있다. 보수 비용이 적게 들 것 개발이 보다 쉬울 것 Restful할 것 그러면 어떻게 검색하면 좋을까? 첫 번째, 모든 필드들을 query parameter로 받는다. 예) GET ?a=b&c=d&e=f&page=0&size=10 장점 타입을 별도로 체크할 필요 없다. 예를 들어서 a는 int이고 c는 string이 명확하기 때문에 확인할 필요 없이 타입변환하면 된다. 필드 수가 적으면 개발이 빠르다. 체크하는 로직이 추가될 필요 없이 query parameter로 받겠다고 선언만 해놓으면 바로 쓸 수 있다..

관련 개념 Reactive stream Mono, Flux 목적 DB에 값이 있으면 while문을 빠져나오는 코드를 작성하자. 이로 인해 무한으로 돌 수 있는 사항은 제외 구현 webflux를 6개월 동안 다뤘지만 아직도 많이 어렵다. 기존 스프링의 동작 방식에 너무 익숙해져서 웹플럭스에 익숙해졌다고 생각할 때쯤 의외로 이상한 곳에서 또 기존으로 돌아가는 것이다. 제일 먼저 작성했던 코드는 아래와 같다. while(check) { println(1) 디비 가져오는 함수.flatMap { println(2) check = false Mono.just(check) } println(3) } 예상했던 안은, 1번 ) 1->2->3, 2번) 1->3(무한). 그런데 의외롭게도 1만 무한으로 출력되는 상황이 벌어..

간단히 에러 해결 방안을 기록하려 한다. mariadb, liquibase를 쓰면서 중간에 로그와 sql이 꼬이고 말았다. event_scheduler가 disabled되어있기 때문에 create event 할 수 없다는 에러가 출력됐다. 그러면 다시 abled 시켜주면 되지 하고 세팅해주기로 했다. SET global event_scheuler=on; 안된다.. 1,0,대문자, 소문자 다 써봤지만 되지 않았다. 디비를 지우고 다시 생성해봤다. 마리아db도 지우고 다시 설치해봤다. 그래도 저 설정은 계속 유효하다. 설정 정보가 남아있나?해서 yum remove mariadb yum uninstall mariadb 전부 다 해봤다. 그래도 계속 disabled다.. 그러던 중 반가운 글을 발견했다. htt..

bmuschko 플러그인을 사용해서 gradle 파일 안에 도커파일과 빌드를 작성했다. 그리고 remote api url을 쓰게 되었는데 전혀 처음보는 포트에서 connection refused가 떴다. 이를 해결하기 위해 접근했던 방식들은, 1. 방화벽 확인 2. 포트 리스닝 확인 가 있다. 절대적으로 포트가 닫혀있을 것이라고 생각하고 하루 종일 방화벽 설정만 확인했다. 잘 안쓰는 맥을 쓰게 되어서, 맥에 설정이 되어있을거라고 생각한거다. 그러다가 2375라는 숫자가 이상하게 마음에 걸려서 찾아본 결과, 2375는 도커에서 사용하고 있는 포트였다!! 먼저, remote api url은 로컬에 도커가 설치되어있지 않더라도 외부의 도커를 사용할 수 있게 한다. 외부의 도커에 tcp 소켓으로 curl로 re..

이 설정을 하면서 가장 어려웠던 점은 서브 프로젝트들이 한 레파지토리에 있었기 때문에 1. 빗버킷 커밋을 하면 모든 서브 프로젝트들이 한 푸쉬를 받는 다는 것 2. 한 레파지토리를 서브 프로젝트 아이템들이 전부 받게 된다는 것(불필요하게) 였다. 기존 소스가 그렇게 되어있기도 해서 레파지토리를 따로 파야하나 싶었다. 각 서브 프로젝트별로 나누려고 하다보니 공통 모듈들이 또 각 서브프로젝트 레파지토리에 전부 들어가게 생겼다. 이걸 또 빼서 의존성을 주자니 기존 소스를 많이 안건드리고 싶었다. 그래서 젠킨스에서 어떻게든 해주지 않을까 하고 폭풍 검색했다. 결론은.. 있었다!!! 1. 소스 코드 관리에서 Sparse Checkout paths로 2번 문제를 해결한다. 이렇게 하면 path에 적은 디렉토리 혹은..

oauth 2.0 인증서버와 리소스 서버를 개발해보면서 개념만 알고 섣부르게 덤빈 걸 느꼈다.. 아무리 까봐도 어딜 어떻게 고쳐야 할지 감이 잘 안와서 문서를 번역해서 따라가보기로 했다. 1차 번역은 끝났다. https://github.com/mychum1/shelf/blob/master/com.ksko.learning-ref/spring-framework/oauth/developer_guide.md

기존에는 깃랩에 커밋하면 젠킨스가 빌드&배포하게 되어있는 흐름이었고, 다른 분께서 직접 구축까지 해놓으셨는데, 이번에 빗버킷을 쓰게 되면서 직접 구축을 해야하는 상황이 되었다. 빗버킷에 대한 이해와, 젠킨스와의 연동, 도커파일 실행과 배포까지 꼬박 4일이 걸렸다. 연동은 금방 끝났는데 도커가 의외의 복병이었다. 도커파일이 동작은 하는데 이미지가 원하는 데로 만들어지지 않아서 정말 애를 많이 먹었다. 목표 : 빗버킷에 소스 커밋 -> 젠킨스 실행 -> 도커 이미지 빌드 -> 도커허브에 푸쉬 과정 1. 빗버킷에서 소스파일 커밋 감지와 웹훅 빗버킷의 Repository settings > Post Webhooks 에서 웹 훅을 생성한다. 1. title은 임의로 설정한다. 2. URL은 본인의 젠킨스 url ..

페이징 관련 강의는 들어도 들어도 어렵다. 강의를 들으며 배우게 된 것을 정리해보았다. 아직 명확하진 않다. 더 기회가 되면 살을 붙여야겠다. https://github.com/mychum1/shelf/blob/master/com.ksko.learning-ref/computer/PagingAndPagingFault.md