대머리개발자

대학 생활 왜 쓰지도 않는 포트란, 코볼을 살짝스하게 배우는지......뜬금포 연관성 없지만 생각났다. 언어는 발전해 간다.. 근데 왜 어떻게 발전해 가냐????? 스프링만 배운 친구는 스프링에 고마움을 모른다.. EJB를 써봤어야지.... 스트럿쳐1,2를 써봤야지... 나는 대머리 꼰대라서 ㅠㅠ 어쨋거나 스프링의 모토는 without EJB다. 본론으로 가자.ㅋ SPA는 하나의 페이지에서 모든것을 랜더링한다. 호랑이 담배 피던 시절.. JSP에 제이쿼리 조합 시절에는 상상도 못했지..쉬바 가상돔이 왠말이냐 고객의 니즈는 심플했지만 구현하기는 낫 심플했다. RFP1) 페이지 인덱스 상태를 가지고 있어야 한다. 3페이지에서 게시판을 조회하고 뒤로가니를 하거나 목록보기 버튼을 클릭하면 3페이지에 머물러 있어..

게시글 중 특정 게시글을 "상단 고정" 해야 하는 기능이 요건이다. 쉽게 말에서 공지글이다. 기본적으로 공지글은 정렬값 컬럼을 두고 해당 컬럼으로 order by을 하면 상단 고정 할 수 있다. 문제는 상단 고정 했던 글들을 내리면 해당 카테고리(메뉴)에서 원래 자리로 돌아 가는 것이 아닌 상단 고정 했던 글들만 별도로 보여줘야 한다. 그리고 내린 글을 다시 공지글로 수정하면 해당 게시판에 상단고정이 되어야 하고 왔다갔다.. 내 머리도 왔다갔다... 요구사항이 추가될 때마다 코드를 수정하는 것이 아니라 범용적으로 사용할 수 있도록 만들자!!! 게시판에 옵션을 가지고 있는 카테고리를 만들었다. 모든 게시판은 카테고리를 가져야 한다. 해당 카테고리의 옵션이 게시판의 특성이 되는것이다. 확실히 뭔가 flow ..

안되는 것은 안 되는데.. 될 수도 있지 않을까?? 하는 희망으로 오늘도 삽질을 시작한다. 현재 만들어 놓은 oauth 서버에서 유일하게 블로킹 코드가 존재한다. 전체 Flow를 보자면. 1.네이버에게 인증을 하고 콜백으로 돌아온 code 값을를 가지고 네이버 동의된 개인정보를 가지고 와서 2.자체적인 토큰을 만들고 3.우리 내 프론트 페이지에게 전달하면 된다. token을 가져오는데 JDBC로 연결해서 쿼리의 결과를 받아 오는 블락킹 코드이다...가즈아!! public HttpResponse redirect(ServiceRequestContext ctx){ //.. 생략 .. // // 1~2 - 네이버 콜백을 처리 하고 토큰 Oauth2Token oauth2Token = ServiceUtil.getN..

reactive 리팩토리.. 모든 비지니스 로직이 하나의 흐름에 들어가야 하는 것이 맞는건가?? 결과는 같지만 정확한 이해를 위해서 다시 한번 곱씹어 봤다. 반년전에 작성했던 코드를 다시 보니.. @.@ 1. 적절한 리액티브 hcnmy.tistory.com 기존 작성했던 부분에 이어서 추가적으로 보완하려고 작성하는 부분이다. 오퍼레이터를 많이 쓴다고 좋은것은 아니다. 허세 부리지 말고 잘 이해한 녀석만 쓰자!! 클린하고자 하는 대상코드이다. 내부 isOK라는 친구를 사용하지 않아서 flatMap() -> then() 으로 변경했고 동일한 닉네임이 있는 경우 하위 연결된 흐름이 실행되는지 체크해보았다. flatMap() 안에 있는 getSimpleUser()는 호출 되지 않았지만 then()안에 있는 ge..

우리 내 서버는 기본적으로 인증서버에서 발급받은 JWT로 접근 통제 하도록 설계 했다. 인증(JWT) 없이 즉, 로그인 없이 사용해야 하는 CASE가 생겼다. (생각지도 못했다.) 애초에 이미 고려 했다면 당황하지 않았을것이다. 근데... 생각해 보면 처음부터 모든 것을 다 고려하고 나서 하나식 쌓아 올라가는 과정으로 프로젝트를 진행하는 곳은 경험에 비추어 봤을때 거의 없을듯 하다. 그래서 다들..애자일..애자일 하는구만.. 로그인 없이 사용 할 수 있다는 생각 자체를 못했던 근본적이유는 일단 나한테 있다. 내 머리속은 지금까지 B2B 비지니스 바탕으로 한계가 명확히 그어져 있었다. 그랬기에 생각지도 못했지.ㅠ 기본적으로 코드상에서도.. 유연하게 처리할 수 있도록... 확장 가능하도록 설계를 한다지만...

URI 컨벤션 중... 되도록 소문자를 사용하자라는 부분이 있다. 도메인을 제외한 나머지는 대/소문자를 구분하기 때문이다. 혼란을 야기 할 수 있는 있다고 한다. https://로또대박.co.kr/goodNumber https://로또대박.co.kr/GoodNumber 다른 엔드포인트를 가진다. 그렇기 때문에 하이픈으로 처리하는 것이 깔끔스하다는 https://로또대박.co.kr/good-number But 나는 enum을 사용하면서... enum type을 그대로 바인딩하고 싶다. @PostMapping("/countStat/{targetID}/{type}") fun saveComment(@PathVariable("targetID") targetID:Long, @PathVariable("type") t..

font-end : 리액트로 만든 관리자 페이지 올리고 gateway : 콩 gatewap 올리고 oauth : 아르메리아를 이용한 grpc로 만든거 올리규 back-end : 코틀린 Boot ...게시판 올리규!! 가즈아!!! 하기 전에 ( CI / CD) 를 해보자. 모든 리소스는 변화무쌍하다.. 왜? 요구사항이 계속적으로 변화니깐! 변덕스러운 고객s 리소스(코드)가 잘 변화지 않는다면 굳이 CI/CD가 필요 없제... 모든것을 유연하게 UI/UX로 처리 할 수 있는 구조로 만든다면? ㅋㅋ 가능허냐? 즉 빠르게 머지하구 반영해야 한다 (CI / CD) ant로 빌드 하던 시절을 생각하면.... 맛있는 "라떼"의 언급이 불가필할 정도로 쉬워졌다.. 어렵다 어렵다 하지마라.. 하면 길은 있다. !!

해당 부분을 제대로 활용하고 있는 개발자가 있는지 의구심이 든다. 나 또한 성공이든 실패든 대충 200 OK 예기치 못한 부분은 500 Internal Server Error 응답 코드를 세분화의 필요성을 느끼지 못한다. 당연한 응답 코드지만 지금까지 그렇게 사용하지 않았기 때문에 진짜 세분화 한다면 오히려 혼란 발생할 듯 싶다.ㅋ 결론 : 고민할 포인트가 있나 싶다. 실패에 대한 에러 메시지에 더 집중한다! 유지보수 차원에서 해당 에러 메시지를 보고 빠르게 문제를 파악할 수 있도록!! => key Point 응답코드를 한번 생각했던 고민했던 실제 이유는 "응답코드"가 본문에 있었기 때문이다... 코드를 표현 할거면 본문(body)에 중복으로 사용하지 말고 응답코드로 바인딩하자!! 얼마 차이 나지는 않겠..