• 음 죄송합니다. 다시 장문의 글을 쓰게 되었네요 ㅎㅎ 기획자분들과 개발자분들에게 부탁드리고 싶은 부분이 있습니다. 해당 프로젝트를 기존 고객 발주 프로젝트와는 다르게 봐주셨으면 좋겠습니다. base계열의 프로젝트들은 개발자들이 아이디어 및 기획 전반으로 참여할 요소들이 많죠, 예를 들면 지금 base-spirngboot의 경우 스케줄링 작업관리나 에러 로그관리 같은 것들은 기획자분들이 기획하시기보다는 개발자들이 더 생각을 잘 해낼 수 있는 요소라고 봅니다. 그리고 라이나 프로젝트를 진행할 때도 그런 경우가 종종 있었는데, 개발자 측면에서 보면 분명 데이터 구조가 이상하게 들어가게 되는데, 고객의 요구이기 때문에 잘못된 구조로 개발을 해야만 하는 경우 들이 생깁니다. 해당 프로젝트는 고객이 요구하는 프로젝트가 아닐 뿐더러 기획자분들께서 요청해주시는 기획에 개발자들의 피드백이 더해지면, 더 안정적이고 고객에게도 더 나은 프로그램이 제시되어 질수 있다고 봅니다. 그리고 현 프로젝트를 통해 여러가지 써보지 못했던 기술들을 적용 시켜보고 시도해보는 토대가 된다고 생각합니다. 이 또한 예를 들어보면, 사실 저는 C# ASP.NET에서는 웹소켓을 다루어 본 적이 있으나 스프링에서는 한번도 다루어보지 못했습니다. 웹 소켓, 채팅에 사용되는 기술입니다. 혼자서 베이스 프로젝트를 만들면서 넣어봐야지 하는 기능 중에 하나가 관리자 채팅입니다. 그리고 front 개발기술인 Vue 개발환경도 지금 현재 이미 세팅 되어져 있는데요, 이 또한 새로운 개발 기술들을 연마하는 토대가 될 수 있을 것이고, 프론트 개발자 분들이 react에 대한 니즈가 많은데 front 분들께서도 해당 프로젝트에 함께 참여하셔서 react를 연마하는 장이 될 수도 있을 것입니다. 요약 해보겠습니다.
    1. base 프로젝트는 개발자들이 기획에 참여할 수 있는 요소가 많다. 기능을 제안하고, 함께 기획에 참여하자
    2. 기획자분들의 기획에 개발적인 부분에 대한 피드백을 주고 받아서 함께 기능을 완성하자
    3. 새로운 기술들을 연마하는 토대로 생각되며, 해보지 못했던 시도들을 많이 해보자 위와 같이 이루어 지려면, 기존에 진행했던 프로젝트 진행방식과는 달라야 한다고 봅니다. 예를 들면 ‘약관 기능은 4월 15일까지 끝낸다.’ ‘연혁은 4월 20일까지 끝낸다’ 라고 일정을 못 밖아 버리면, 완성된 기획이 주어진 상태에서 개발을 몇일 만에 끝낸다는 개념이죠, 이렇게 되면 개발자들은 기획자가 주는 일만 한다라는 스탠스가 생겨납니다. 개발자의 피드백은 기대하기 힘들어지고, 개발적으로 잘못된 기획이라도 그냥 가는겁니다. 이럴 때는 진행방식이 2가지가 있을 것 같습니다.
    4. 기획단계에서 개발자와 기획자들이 충분히 시간을 가지고 기획에 대해 논의 후 어느정도 충분한 기획이다 판단되면 개발일정을 어느정도 픽스하고 스프린트 한다.
    5. 대략 기획과 개발이 구두라도 상의되고 기획서가 만들어지지 않더라도, 아니면 설익은 기획이라도 나오면 일단 개발한다. 개발하고 피드백을 거치며 재수정을 가해서 완성한다. - 제가 알기론 이런식의 개발이 애자일 방식이죠? (예를 들면 제가 위에 언급한 관리자 채팅 기능을 머리속에 있는 저와 기획자분들에게 구두로라도 설명하고 어느정도 만들어 본 뒤 피드백을 거쳐 재수정 한다 정도 되겠네요) 1번은 기획단계에서 개발자들과의 피드백을 주고 받는 시간에는 개발일정을 픽스하면 안되는 방식이고, 2번은 설익은 기획에서 바로 개발에 들어가는 것이므로 개발단계에서는 어느정도 일정을 서로 이야기 해볼 수 있지만, 피드백 후 재수정에 이루어지는 기간들이 생긴다는 부분에 대해서 PM과 회사의 이해가 필요할 것 같습니다. 마지막으로 PM, 기획자분들에게 드리고 싶은 이야기가 있는데요, 제가 만들면서 워드프레스처럼 몇가지의 설정으로 사이트가 완성되는 류의 프로그램을 만들려고 만들기 시작했다는 이야기를 했었는데, 워드프레스와 base-springboot를 비교하면 하늘과 땅차이 입니다. 워드프레스는 수많은 개발자들이 붙어서 만들고, 테스트하고 수많은 플러그인들과 디자인템플릿들을 추가해서 사용할 수 있는 전세계 웹사이트 트래픽 30프로가까이되는 어마어마한 프로그램이죠. 워드프레스와 차별점은 우리가 주로하는 도메인들관련 기능들을 넣을 수 있고, 우리가 자주 넣는 기능들을 미리 넣을 수 있는 강점은 있을 수도 있겠습니다. base-wp와 비교해서 base-wp처럼 지금 바로 실 프로젝트에 바로 투입해서 효과를 바라는 마음은 충분히 이해되지만 base-wp는 태생적으로 수많은 프로그래머들이 만들어 놓은 기능 위에서 커스터마이징 한 프로젝트입니다. 태생부터가 다릅니다. 전부 만들어줘야합니다. base-springboot에서는..이러한 부분을 base-springboot을 바라보실때 이해해주시면 좋을듯 합니다.

제가 2-3일 동안 많은 이슈와 글들을 쏟아내고 있는데요.. 개인 프로젝트였던 프로젝트를 회사프로젝트로 이관하는 작업이라고 이해해주시면 좋을 것 같습니다. 정리할 것들은 정리한것 같고..이야기 드리고픈 이야기들은 대충 다 전달한 것 같습니다 ㅎㅎ

  1. 모듈을 바라보는 시각이 모두 다를 것이다. 어떠한 분은 프로젝트를 빨리 끝낼수 있는 도구 정도로 보는 분들도 있겠지만, 자바모듈은 솔루션이라고 생각해서 개발 중에 있고, 최종적으로는 몇개의 디자인이 미리 새팅이 되어 있을 것이다. 그리고 세팅된 디자인 이외에 커스텀한 디자인들도 개발을 빨리할 수 있는 토대가 될 것이다.

  2. 솔루션으로 접근하면 만들 수 있는 기능들이 참 무궁무진하다. 개발적으로도 여러가지 재미있는 시도가 가능하다. 예를 들면, 관리자들 끼리 채팅할 수 있는 기능, 웹 푸시, PWA(프로그레시브 웹 앱 이라고 웹페이지를 앱처럼 보이게 해주는기능) 웹프로젝트 내에 데이터베이스 백업 기능, 챗봇 등등등

    그리고 일반적인 기능들에서도 프로젝트를 진행하다보면 촉박한 시간으로 인해 개발적으로 합당하지 않은 형태의 개발이 이루어 질때가 있다. 라이나의 경우 결제 테이블이 강좌에만 국한해서 결제가 가능하도록 설계가 되어 있고, 대관의 경우 공간을 지정하는 기능이 없고, 시간을 잘라서 3개를 선택하도록 되어 있는데 3개를 선택할게 아니라 타임 피커로 하나의 시간 범위만 선택할 수 있게 하는게 좋지 않았나 생각한다.

    개발자인 제가 기획을 검토할때도 여러가지 개발적으로도 추후 다른 개발을 연계해서 더 합당한 기획이 될수 있게 기획에 대한 여러가지 코멘트를 달 것이고 기획 수정을 요청드릴수도 있겠다.

    그리고 위 이야기 처럼 여러가지 새로운 기능들에대한 기획을 요청 드리거나 아니면 제가 아에 만들어서 보여드리는 경우도 생길 수 있으리라 본다.

  3. 회사 프로젝트들을 둘러볼때 아쉬웠던 점 중에 하나가 관리자 페이지 디자인이 늘 제 각각에다가 어떤 페이지들은 너무 허술해보였다. 사실 솔루션 회사라면, 외국 회사들 이야기 들어보면 조그만한 외국 솔루션회사의 관리자 페이지는 개발자가 디자이너 퍼블없이 대충대충 개발자가 개발해서 정말 디자인 적으로 별거 없다는 이야기를 듣기는 했다만, 사이트를 납품하는 회사에서 관리자 페이지가 이건 아니지 않나 라는 생각이 들었다. 관리자 페이지의 동일한 디자인이 어떻게 보면 하나의 브랜딩이지 않나 생각 된다.궁극적으로는 관리자 페이지도 디자인 되어야하며 모든 프로젝트에서 동일 디자인으로 나갈 수 있어야 한다고 생각함. 당장에 급하게 할 건은 아니라고 본다. 더 급한 일도 많으니깐..디자이너 분들도 바쁘고…

관리자 페이지 디자인 여부에 대한 고민

  1. 자바 모듈을 주로쓰는데가 공공기관으로 한다면 해당 모듈을 전자정부 기반으로 만들었어야 했나?

  2. 후원 기능을 살펴볼만한 프로젝트는 있는가

  3. 한번 만들고 마는 프로젝트가 아니다. 계속 업그레이드 시킬것이며 기능을 추가할 것이며, 문제점은 보완해야하는 프로젝트다.

  4. 오로지 기능 구현에만 매달릴 프로젝트가 아니다 늘 했던 방식으로만 개발하지는 않을 것이다. 개발자로써 이것저것 해보고 싶었던 것들을 넣어 볼수 있는 것들을 시도 해볼 것이다. 만약에 그렇게 하지 못한다면 내가 개인시간 투자해서 이걸 개발하고 있을 이유가 없다.

  5. 프로젝트를 배포하면 여러가지 운영에서 필요한 로그를 주기적으로 지워주는 기능은 이미 넣었고, DB를 백업 관리하는 기능까지 넣어 볼 수 있으리라 기대한다. 이러한 기능을 기획자가 시키는 것만 하는 구조로 일을 진행한다면 넣을 수 있을까?

  6. 여러가지 프로젝트 하면서 아쉬웠던것 문제가 있었던것을 미리 대비하는 기능들을 넣을 수 있다.
    • 일단 제가 만들어놓은 에러를 확인하는 기능을 미리 만들어둘수 있을것이고,
    • 아직은 만들어지지 못했지만, 해킹 시도 미리 패스워드 무한 대입하는 IP에대해서 미리 차단 하는 기능도 만들어지는게 가능하고
    • 관리자에서 특정 IP대역만 접속 가능하게 하는 기능도 마련 해볼 수 있을 것
    • XSS 공격도 라이나 운영하면서 경험했던것을 미리 녹일 수 있는 것이다.
    • 로그 180일 제한 기능도 로그가 쌓여 서버가 뻣어 버리는 경험을 해보았기때문에 미리 180일로 제한하고 제거하는 기능을 미리 넣어 둘 수 있다.
    • 이런 경험들을 base 프로젝트들에 녹여야 하고 새로운 프로젝트에서는 같은 문제를 반복 하면 안된다.
  7. 템플릿 프로젝트를 운영하면 생겨날 단점,
    • 프로젝트가 반복적이게 되고 개발자로써의 기계가된 느낌을 받게 될것이다.
  8. 한스님이 걱정하시는 것처럼 고객의 요구사항은 늘 다르다. 비즈니스 로직들은 다를 수 있다. 요구사항이 달라지는 것 이외에 공통적인 것들도 있다. 로그처리 에러 관리, 그리고 달라진다는 그런 요구사항들도 우리가 준비를 해놓는 기능을 선 제안 할 수도 있다. 기획서보다 동작하는 기능을 보여주는것은 더 명확하다. 굳이 고객의 불확실한 머리속에서 나오는 요구사항 보다 우리가 만들어놓은 기능을 보여줌으로써 OK싸인 받거나 여기서 조금 수정해달라고 하는 것이 훨씬 서로 명확하고 좋다고 생각함

  9. 베이스 레일즈와 베이스 스프링부트는 출발이 다르다.
    • 베이스 레일즈는 새로운 프로젝트를 할 때 쉽게 만들기 위한 도구 정도로 사용하는 목적으로 만들어졌고,
    • 베이스 스프링부트는 몇가지 설정만하면 기본적인 디자인과 사이트가 완성되도록 하는 목적으로 만들어졌다. 그래서 사이트 설정과 메뉴설정 기반으로 돌아가고 디자인 템플릿을 선택하는 기능도 넣었다.
      • db에 값만 세팅 되면 개발자는 손댈일이 거의 없도록 하고 싶다 라는 생각으로 만듬..
    • 레일즈 방식이 맞는지 스프링 부트방식이맞는지..
    • 이러한 차이점이 있는데 사이트 설정과 메뉴 설정이 있는 기반의 사이트가 프로젝트에 적합할거라고 생각하는지에 대한 의견을 듣고 싶다.

이런것들 이외에 프로젝트를

– 설명 – 화면 대략 설명 -> 실행 설명 -> 패키지 구조 설명

  1. 사용자 화면 - 메뉴 정보에 따른 메인 메뉴 노출, 푸터 메뉴 노출, 로그인 페이지

  2. 관리자 페이지
    • 사이트 관리
      • 사이트 설정 : 사이트의 기본정보 사항과 디자인 템플릿을 지정한다.
      • SEO 설정 : 구글 검색, 네이버 검색,
      • 외부 서비스 설정 : Google Analytics, 소셜 공유를 위한 Facebook, Kakao 키 값
      • 스케줄 작업 관리 : 백그라운드 작업현황을 볼 수 있고, 백그라운드 작업을 켜고 끌수 있도록 제어할 수 있도록 되어있다. DB장애 Job도 구현되어 있으나 이는 표시되지 않는다.
      • 에러 로그 관리 : AOP를 통해서 전역적으로 에러를 관리하며 에러 슬랙으로 알림 및 DB에 에러 로그를 쌓도록 되어 있다. 관리자 화면은 미구현 상태
      • 추가적으로 설정 메뉴가 분리될 수 있다. 메뉴는 나눠져있지만 테이블은 하나이고 값은 한줄이다.
      • 사이트 설정 값과 메뉴 설정 값은 캐쉬로 잡혀 있다.
    • 메뉴 관리
      • 메인 메뉴 설정 : 메인 메뉴 2depth구조(탑메뉴, 서브메뉴)로만 구분됨
      • 푸터 메뉴 설정 : 하단에 들어가는 메뉴, 현재 그룹핑 하는 기능은 없지만 하단 메뉴를 Grouping 하는 기능도 넣을 계획이 있다.
      • 기타 메뉴 : 메인과 푸터 메뉴에 포함되지 않고 단독으로 들어갈 수 있는 메뉴들을 추가하고 설정함

      • 메뉴 상세 설정 :
        • 메뉴 이름을 설정
        • 메뉴 URL을 지정한다. /site라는 프리픽스가 들어가 있다. 초기 개발에는 없었으나 여러가지 부딪히는 부분이 많아서 prefix를 넣었다.
        • 컨텐츠 타입 설정 :
          • 컨텐츠 그룹이라는 개념이 있는데 이부분에 그룹핑되어 있다.
          • 컨텐츠에 따라 작업해야하는 view 파일 경로가 정해진다.
          • 컨텐츠 그룹에 따라 - 추가 설정 항목 들이 나오는 경우가 있다. 게시판, 개발함에 따라 추가로 나오는 설정항목들은 추가되거나 바뀔 수 있다.
          • 컨텐츠 그룹에 따라 주요 Domain파일들과 연결이 된다.
        • 댓글 설정 : 댓글들은 모든 페이지에 들어갈 수 있다. 댓글 타입도 설정할 수 있다.
        • 모든 상세 페이지에는 소셜 공유 기능을 켜고 끌 수 있다.
      • 메뉴 정보 테이블에 있는 MenuUid존재 모든 메뉴들은 menuUid에 의해 데이터가 나뉜다.
      • id 대신에 menuUid를 도입한 이유는 사용자 화면에서 단순한 menuid 숫자로 주고 받을 경우 문제가 생길 우려를 고민해 복잡한 Uid로 주고 받음
      • 게시판 테이블은 하나지만 menuUid정보로 나뉘어 화면에 노출된다.
      • 강좌메뉴가 여러개 있다고 가정한다면, 강좌도, 강사도 menuUid정보로 나뉘게 된다.
    • 메뉴들
      • 관리자에서 메뉴에 설정된 정보를 바탕으로 컨텐츠 그룹기준으로 그룹핑되고, 해당하는 메뉴의 관리들이 개별적으로 나타난다.
      • 메뉴 설정에 따라서 개별 관리자 메뉴들 항목 들이 달라진다. 사용자 화면도 달라진다 관리자 게시판, 게시판 카테고리, 파일 첨부 설정에 따른 변화 모습 보여주기
      • 여러가지 도메인 파일들을 라이나에서 가져왔다. 라이나에서 검증된 로직들이기도하기때문에 모든것을 새롭게 구현할 이유가 없었음
      • 하지만, 라이나의 특유의 것들이라고 생각되는 부분들이나 라이나에서 고쳐야 되겠다고 생각했던 부분들은 변경함(캠페인 타입은 2가지만 존재, 강좌에 학기 개념 제거, 대관및 강좌의 강의실관련 구조를 기존과는 변경하고) 새롭게 만든 캘린더라는 도메인에 의존하도록 만듬
      • 아직 작업은 덜되었지만 기존에 강좌 테이블과 강좌 주문테이블이 있었지만, 주문테이블을 중립적으로 만들기 위해 재설계함, 주문테이블에서 강좌를 결제할 수 도 있고 상품을 결제할 수 있도록함
      • 아임포트 API기준으로 주문관련 도메인영역 로직들은 작성되어 있는데, 이부분도 고민 필요함
      • 대부분 회원도메인 영역을 의존 하지만, 강좌는 캘린더를 의존하고, 주문을 의존하기도함
      • 캘린더 내부일정 등록 및 반복일정 등록 기능이 있다.(인트라넷 개념으로까지 관리자 페이지 확장 가능)
  3. 실행
    • Java 1.8, Maven, Spring boot 2.2.5, h2, mysql 데이터베이스를 사용, Freemarker 템플릿 사용(타임리프를 초창기 도입했다가 컴포넌트 기능이 너무 없는듯 보여서… 변경함.. 라이나에서 가져다쓰기 편한면도 있고.., 프리마카의 null 입력시 500에러 뜨는 단점도 해결함)
    • front :
      • 기본적으로 gulp로 빌드 되도록 되어 있음
      • 디자인템플릿에 따라 디렉토리를 구분하도록 되어 있음
    • front-vue : vue를 통해 admin페이지를 만들용도로 vue 개발환경을 구성함
    • frontend-maven-plugin 을 통해서 빌드시 front와 front-vue를 Maven 빌드 과정에서 함께 빌드를 실시하고 front-vue 테스트 코드와 ApiController 테스트를 함께 실시하도록 환경 구성
    • mvn clean package시 테이블을 초기화하고 테스트 데이터를 입력하도록 되어 있음, 현재 기본 설정은 h2 데이터베이스로 파일형 데이터 베이스로 따로 DB설정할 필요 없음
    • 스키마 생성하는 부분이 라이나와 다른점이 있는데, JPA Entity파일에 ERD정보가 다들어가 있다고 생각되어, ERD파일을 만들지 않고 Entity파일에 테이블명, 칼럼명, 인덱스 까지 모두 기술함, 테스트 코드실행시 테이블 초기화 후 JPA정보 기반으로 생성하도록 설정되어 있음
      • ERD관리 하지 않아도 되는 장점이 있지만 불편한점은 칼럼 순서를 마음대로 조정할 수 없음
      • application-test-h2.properties와 application-test-mysql.properties spring.jpa.hibernate.ddl-auto=validate로 되어있지만 아래 설정에 의해 테스트 코드 실행시 테이블이 생성됨

        spring.jpa.properties.javax.persistence.schema-generation.database.action=create spring.jpa.properties.javax.persistence.schema-generation.create-source=metadata spring.jpa.properties.javax.persistence.schema-generation.scripts.action=create

    • mysql

    • 예제데이터는 TestDataConfig.java 파일에 존재
    • 인텔리 J 실행 설정 화면 공유, 아래 값들을 입력해야 소셜 로그인이 될것임, active profile = dev

    -Dspring.mail.username= -Dspring.mail.password= -Dsite.kakaoClientId= -Dsite.facebookClientId= -Dsite.facebookClientSecret= -Dsite.naverClientId= -Dsite.naverClientSecret= -Dsite.iamportMartCode= -Dsite.iamportKey= -Dsite.iamportSecret=

    • Visual Studio Code 사용시 실행하면 아마 될것임…

      mvn spring-boot:run -Dspring-boot.run.profiles=dev -Dspring.mail.username= -Dspring.mail.password= -Dsite.kakaoClientId= -Dsite.facebookClientId= -Dsite.facebookClientSecret= -Dsite.naverClientId= -Dsite.naverClientSecret= -Dsite.iamportMartCode= -Dsite.iamportKey= -Dsite.iamportSecret=

  4. 패키지 구조 및 주요 파일 구조
    • SiteConfig -> 1테이블 설정값이 많지만 1테이블 1레코드로 모든 설정값을 가지고 있는다, 캐시를 사용중이다.
    • MenuInfo -> 메뉴 테이블, 상위 메뉴 하위 메뉴로 테이블을 구분할까 하다가 1개의 테이블과 MenuType으로 구분한다.
    • MenuType -> TOP_MENU(“탑메뉴”), SUB_MENU(“서브메뉴”), FOOTER_MENU(“푸터메뉴”), ETC(“기타”) 4개로 구분
    • ContentType -> 컨텐츠 타입명, 컨텐츠 그룹정보, view파일경로 정보가 포함되어 있다.
    • ContentGroup -> 컨텐츠타입을 그룹핑할수 있는 정보와 관리자 아이콘, 링크 정보가 포함된다. -> ContentGroup 정보를 기반으로 특성화된 도메인(데이터베이스)에 연결된다.
    • ContentType과 ContentGroup을 DB에 값으로 만들지 않고 enum 으로 만든 이유는 ContentGroup을 통해 특정 도메인과 연결되는데 컨텐츠 그룹이 추가되면 어차피 관련 코드 추가가 필요하다.
    • MenuController
      • list, detail, addForm, detailForm메소드를 가지고 분리되어 있고, Url정보를 기반으로 메뉴정보를 찾고 컨텐츠 그룹정보를 통해 분기된다.
      • 코드가 지저분한편… 깔끔하게 분리하는 방안이 필요.
    • 만약 새로운 도메인 로직을 추가 한다면?
    • 만약 새로운 디자인 템플릿을 추가 한다면?
  5. 기타
    • 사이트 설정과 메뉴 정보는 캐시가 잡혀 있고 관리자가 설정값을 변경하면 캐시를 제거하도록 되어 있다.
    • 로그가 상대 경로로 잡혀 있으며, maven 빌드시 초기화한다. 로그보관기간이 설정되어 있는데 180일이다.
    • Vue 개발을 위한 vue 개발환경과 Jwt 인증구현이 포함되어 있다.
    • 하나의 도메인안에 컨트롤러는 최대4개, 서비스는 한개로 유지하려고 한다.
    • 컨텐츠 그룹 추가 또
  6. 고민점
    • 개발할 수 있는 꺼리, 수정해야하는 부분, 추가해야하는부분 엄청 많다.
    • MenuController가 지저분하다.
    • 메인 모듈 서브 모듈을 멀티프로젝트 고민중 https://github.com/arawn/building-modular-monoliths-using-spring
    • 데이터베이스 형상관리를 약간의 꼼수로 하고 있다.(JPA정보를 기반으로 Liquibase정보를 생성해주는 플러그인 적용 실패)
    • 데이터베이스를 핸들링 하기 위해서, repository3개, predicate, projection dto 등을 만들어야한다.만드는게 좀 많다. 코드 generate 또는 구조 조정이 필요함

    http://pf.kakao.com/_BUlwu /assets/images/banner-kakao.png /assets/images/[email protected]

관리자

  1. 강좌 관리 - 강좌, 강사, 강좌 그룹 등록 수정 삭제 등 작업
  2. 캘린더 관리 - 강좌 등록과 연동, 내부 공간 겹치지 않게 validation, 반복일정 등록
  3. 회원 관리, 휴면회원 추가
  4. 스케줄링 작업 - 회원 배치 잡(휴면회원 처리, 회원 정보 삭제 처리 등, 휴면회원 알림 배치작업에 포함되어 있으나 이메일 발송은 연결되어있지 않음), DB 장애 알림 잡 통계잡은 파일만 생성 사이트 관리 -> 스케줄 관리, 로그 확인 및 on off
  5. FAQ 관리 기능(리스트 및 카테고리 등록 수정 삭제)
  6. QnA 관리 기능(리스트 및 카테고리 등록 수정 삭제)
  7. 외부 서비스 설정 - 기존 GA 설정을 사이트 설정에서 분리하고, 페북, 카카오톡 공유 키 설정항목 추가
  8. SEO 설정 - 관련항목들을 사이트설정과 분리하고, meta 태그에 들어갈 항목들을 추가함
  9. 에러로그 관리 - 서버 내부에 발생하는 에러 항목들을 표시 해줌
  10. 메뉴 정보 입력 및 변경시 breadcrumb 정보 반영
  11. 관리자 엑셀 다운로드

사용자

  1. 기존 기본 디자인 템플릿의 html css를 걷어 내고 bootstrap4기준으로 변경하고, basewp의 화면을 많이 가져옴
  2. 사용자 게시판 기능 붙임, 관리자의 메뉴 설정의 게시판 관련 항목 설정에 따라 파일첨부, 카테고리 사용여부, 관리자, 승인, 회원 게시판으로 변경처리
  3. 관리자 SEO 설정 및 상세페이지 내용을 기반으로 기본 메타 태그, OG태그, twitter 태그 생성되도록 작업
  4. 게시판 댓글 작업, 메뉴 설정에따라 기본 대댓글, 평가 대댓글로 작업
  5. 공유 기능 - 메뉴 설정 및 외부 서비스 설정에따라 변경됨
  6. 관리자에서 입력된 정보에 따르 breadcrumb 정보 생성

기타

  • Vue 개발 환경 세팅

tf-rava 의 시작에 대해서 모르시는 분이 기획직군에도 있으실듯 하여.. 이렇게 시작되었구나 하고만 아시면 될것 같습니다.

base-springboot는 라이나하면서 기반도 없이 너무 처음부터 새로 개발하는 느낌이 들어서 새로운 프로젝트할 때 기반으로 만들어서 쓸 프로젝트가 필요하겠구나라는 생각으로 작년 5월에 첫 커밋을 했던 프로젝트네요 사실 라이나때문에 바빠서 5월에만 첫커밋을 했을 뿐.. 실상 제대로 커밋하기 시작한건 라이나가 오픈하고 그 이후에도 한 두달 바빳었는데 9월부터 제대로 작업을 시작했던 것 같습니다.

시작부터 그랬고, 사실 어제까지도 사실상 개인 프로젝트였습니다.

회사가 여러모로 어려워지고, basecamp가 합쳐지고, 키튼님이 개발팀 리더를 하셨었죠, 개발팀이 오프라인으로 종종 모이는 일이 있었고, 식사자리에서 프로젝트 시작 시에 뼈대로 쓸만한 프로젝트를 만들어 보고 있다. 만들고 있던 base-springboot에 대해서 잠깐 언급을 했었습니다. 그 이후에 키튼님과 시스님께서 보여달라고 요청하셨었고, 지금보다도 더 보여드릴게 없어서 보여드리지 못했습니다.

시간이 조금 더 지나서 지금 확인해보니 11월 18일이군, ‘베이스 워프, 레일즈 공유’ 시간이 있었습니다. 그 때 저 혼자만든 것도 살짝 보여드리고, 방향성도 이야기드려보고 피드백을 받아보고 싶어 해당 시간에 만든데까지 보여드린적이 있습니다.

그 이후에 계속 키튼님과 시스님에게서 소스를 회사 Git으로 올려달라고 부탁을 받았습니다. 하지만 저는 고민을 많이했었습니다. 해당 프로젝트를 회사프로젝트화하는 것이 부담스러웠습니다. 부담스러웠던 첫번째 이유는 아직 만든지 얼마되지 않은 초기 상태였고, 두번째 이유는 회사 프로젝트화하면 제가 제 스스로 여유시간마다 틈틈이 재밌게 코딩을 할수 있을지 의문이 들었습니다. 다들 아시겠지만 취미로 하던 것도 일로하면 재미가 없어지니까요..그래서 부탁을 수차례 거듭 받았지만, 앞선 이유로 밍기적거리며 올리지 않았습니다.

그러다가.. 어느순간 12월 4일이군요, 갑자기 ‘회의, 모듈화논의’ 라는 이름으로 회의자리가 만들어졌네요, 제가 만들고 있는것도 발표하라고 하시네요.. 얼떨껼에 발표를 했고, 발표를 한 후 아 이제는 회사 Git에 올려야겠구나 라는 생각이 들어 그 회의가 있던 다음날 처음으로 Git으로 올렸습니다.

그 이후에 tf-rava라는 이름으로 회의체가 만들어지고 지금까지인거죠.

base-rails는 시작부터 시스님이 만들고 그 이후에, 안태님이 조금씩 함께했고, 최근에는 소유님이 주도적으로 커밋하고 게십니다.

base-wp는 시작은 시스님, 누니님, 칼디님, 진성님이 시작했고, 중간부터 칼디님 누니님이 주도해서 현재까지 왔죠,

base-springboot는 개인 프로젝트로 시작해서 얼떨껼에 화사 프로젝트화했지만, 어제까지도 개인프로젝트나 다름없었습니다. 기획자 분들에게도 2월 6일에 만든데 까지 설명을 드리고, 했었으나 방향에 대해서 질문을 주시거나 피드백 주신 분이 게시지 않았구요, 개발자 분들에게도 지난주 금요일에 설명을 드렸지만, 아직 알아가는 과정이실 거구요. 여태 혼자 덩그러니 개발하고 있었고, 회의에서는 개발진척상황에대해서 지지부진함을 이야기하고 있어야 하는 상황이네요 ㅎㅎ

일단은 저부터도 개인프로젝트라는 생각을 멈추기위해서 개인프로젝트와 회사프로젝트를 분리해서 대할 생각입니다. 재미로 개발하는것과 일로써 개발은 다르니까요, base-springboot는 이제 다른 개발자들도 함께 해야하는 프로젝트이며, 다깉이 만들어주셔야되는 프로젝트가 되었습니다. 기획자분들도 의문이 나는 부분이나 왜 이렇게 만들었는지에대해 궁금함이나 피드백을 주시면 더 좋을것 같구요(만들어진게 별로 없어서 피드백하실게 없으신 것일 수도 있겠지만요..)

  • 이슈 검토 하는 시간

  • 여러가지 개발 코드들을 수요일 부터 틈틈이 자세하게 살펴보는 시간

  • maven 빌드 과정
  • 인증
  • 에러핸들링과 AOP
  • 로깅
  • 캐쉬, 페이지 캐쉬를 찾아보고 있다.
  • 퍼포먼스 체크
  • 암호화 부분
  • 스케줄잡
  • db를 다루는 repository를 변경할 것이다. 작업중이신분이 있을지

캐쉬 이중화 문제 이중화 서버에서는 캐시

  • 이중화 고려는 후순위로 미루자
  • 브랜치 feature, bug fix 등으로 브랜치를 따고 풀리퀘스트
  • database : h2
  • ERD 사용할지 정해야

메뉴 설정이 있으므로써 각각 메뉴가 단편적인 모습이 아니라 복합적인 모습의 구현이 가능하다 그래서 문의하기도 하나의 모습으로 기획이 될것이 아니라 다변화한 모습이 가능하다. 단 다변화의 모습을 구현할 수 있다고 했을때 사용자화면에서의 커스텀 디자인 적용시 공수가 늘어날 부분이 있을 수 있다는 것을 고려가 필요하다.

캐시 2중화 문

  • github권한
  • 브랜치 관리 룰 안태님한테 확인
  • Postgresql 12버전이 나왔는데 Dialect는 10까지 밖에 없다.
  • POstgresql 은 Lob가 먹히지 않는다. longtext 지원되지 않는다. columndefinition =text를 주는 방법이 있으나 mysql에서의 text는 용량이 65000제한이 있다..

docker run -d –name my-oracle
-p 1521:1521 -p 5500:5500
-e ORACLE_PWD=1
-v $PWD/mount/data:/opt/oracle/oradata
oracle/database:18.4.0-xe

QuerydslJpaRepository deprecate된 @AllArgsConstructor(staticname = “of”) 를 사용할 수 없다. static of 는 제거 필요. ProjectionHandler에서 아래와 같이 변경해야 했는데, 이게 제가 잘못가져다쓴건지..잘 모르겠습니다. Type type = value.getClass().getGenericSuperclass(); -> Type type = value.getClass().getSuperclass().getGenericSuperclass()

BaseRepositoryImpl 에 주입이 안된다고 빨간줄이 그임..

Projection 부분을 파라미터로 받는 것이 어떨까함. 공통화 하더라도 선택적으로 API 사용자가 공통화 하는것이 좀더 좋아보임

0413 논의해야할 사항

  • 연혁이 메뉴 관리의 설정이 추가되었다 해당 항목들을 고려해서 개발하는 것에 대해서..
  • 스케줄링
  • 레포지토리 변경사항
  • 기획자분들이 여러가지 구체적으로 논의하면서 함께 살펴봐야할 사항들(연혁, qna)
  • JPA가 아닌 db관련 API 사용법

  • 데이터 지우지 않는 것이 기준이 되나 데이터 지우는것들이 카테고리 쪽에는 좀 있다 지우는것도 있고 status로 관리하는 것도 있다.
  • 각각 메뉴 개발하는데 살짝 가이드, 프론트 쪽 view파일들 나뉘는 부분과 sass쪽도 살짝

  • icecream 에서 LogDto 안에 UserDto가 있는데 ProjectionHandler에서 expressionMap 넣는 부분에서 에러가 발생한다.
  • 댓글 컴포넌트 뷰파일 위치 레이아웃에 넣을지 개별 컴포넌트에 넣을지..

  • rails 변경사항에 대해서도 공유해보는시간..

  • Jpa관련 추가
    • Converter, 암호화 컨버터
    • where정리 위치, projection 정리 위치
    • findBy로 만들어지는 것들
  • dto 유효성 검증

  • Spring Security 및 인증 -
  • restdoc
  • icecream gradle에 대해서 설명 부탁, 프로젝트를 조금씩 멀티 프로젝트를 위해 gradle로 변경해볼까 함.
  • base-wp 회의는?
  • 다른분들 소스 파악어느정도 되셨을것 같은데 소감..

settings gradle

클라이언트 키 6Le_g-wUAAAAADvf-5ovLsrhGbro4fkoZYldWLjj

서버키 6Le_g-wUAAAAAGMszf937-t5MVggnWMxa24_tkee

recaptcha 클라이언트 구현 recaptcha 서버 구현

개발적인 이야기 자바관련 내지 기타 백엔드 관련 이야기만 하고 회의를 종료하자, 프로젝트진행과 기타 이야기들은 다른 회의에서 따로 진행하자

recapcha, 프리마커 컴포넌트, 뷰파일 세분화, RestTemplate h2database

form post BindingResult 에러 처리 csrf 태그

BadRequestException 에 대한 질문, errorCode는 쓰이는데가 없는것 같다.

서비스는 도메인에 한개, 컨트롤러는 4개(관리자, 사용자, API, 페이지)

사용자와 약관을 이어주어야함 투게더스 약관 정

term agree를 등록할때 동일 카테고리 등록 정보가 있는지 체크해주자.

save action

전부 서버 랜더링 하는 방식으로..

웹소켓 개발중 이야기, 웹소켓은 일반적인 http프로토콜은 신호를 request하고 연결을 유지하지 않는특성이 있으나 웹소켓 프로토콜은 다른 방식의 개발을 가능하게 한다.

이미지 슬라이더 브랜치 따로 개발

// TODO 여기서 오류 발생시 로그 X querydsl에서 오류가 생기면 로그가 안찍히는데 이부분 물어봐야됨..

faq catename index를 유니크로 해도 될지도? menuUid는 index를 잡자 사용자 화면에 FaqCategory, Faq menuUid를 검색해오자, 테스트코드 추가시 메뉴 uid에 따라서 분리되는지 확인

관리자 faq 화면에서 정렬이 서로 다르다.(faq와 faq-form에 나타나는..)

팝업 정보도 캐시화 하자, 팝업 전체 정보를 캐시화하고 메뉴 컨트롤러에서 불러와서 해당 메뉴 정보를 넘겨주자.

모든 url을 메뉴 정보화해야할까? 홈, 로그인페이지 등등 모두…

pointer-event 라는 css

슬랙 키값도 설정값으로 빼자 gradle 이관 - TestDataConfig 삭제 - RecaptchaAspect 삭제 - MenuController - TestDataconfig에 의존하고 있는 상수들

MenuController 분리 방안 - ContentGroup별 url prefix를 붙인다. - 도메인별 컨트롤러로 분리

TestDataConfig 를 순서를 조절해서 여러개로 나눈다.도메인 디렉토리로 분산 시킨다.

  1. Popup 작업
  2. 소셜 로그인 변경
  3. Gradle로 변경 시도 하고 확인한점

  4. 메인 포탈 관리 구현 방식에 대한 고민 - 페이지 캐시
  5. primitive type

  6. schema 쿼리를 만들지 않는 이유
    • 동일한 정보를 가진 2개의 파일을 관리할필요가 없다고 판단.
    • ERD프로그램이 exerd의 경우 유료, mysql workbench는 MYSQL에만 종속적임
    • erd가 필요한 경우 erd프로그램에서 reverse engineering 사용할수 있음
    • intellij에서도 jpa 를 통한 ERD작성이 가능
    • 생쿼리는 되도록 지양, TestDataConfig에서도 예제데이터를 lina프로젝트에서 가져오면서 예제데이터를 JDBCTEMPLATE으로 생쿼리가 들어가 있으나 변경하는 방향으로 가려고함

doMenu에RequestMapping을 해야할까?

채팅방 입장 INFO 테이블을 만들어야 한다.

채팅방 유저 카운트는 서버 재시작등으로 제대로 카운트되지 않을 소지가 있다. 이부분 해결해야한다. 채팅방 세션에서 채팅방 카운트를 새는 방법 모색

super를 안쓰는 방향, Httpservlet request 방향 requestmappinghandler requestmappinghandler

qna 풀리퀘스트 숙경님 모임

  • 워프 레일즈 대체
  • 표준 기획에 따른 표준 구현 -> 커스터마이징이 들어가면 시간 비용 증가 javascript jquery 플러그인 방식으로 공통처리 사회 공헌 센터에서는 sloform

HttpSessionConfig 라이나와 비교 질문 server.servlet.session.cookie.secure=true 주의 사항 알리기 아만다님에게.. 패키징시 테스트 데이터를 모두 돌리는 것으로 변경

css-copy-watch, js-copy-watch를 보면 resources쪽에는 카피하지 않는데 이유는? 무엇인가? 나중에 커밋할때 빠뜨릴 소지가 있지 않나? gradle 빌드시 에러 intellij build-info.properties 를 못찾는다. -> 해결은 했는데 intellij settings -> build, excution, deploy..-> gradle 에서 Build and Run Using을 intellij 대신 gradle로 변경

build 디렉토리와 out 디렉토리의 차이는? 인텔리J

tf-rava회의

  • 모든 기능 설정만으로 완성된 기능의 홈페이지가 동작하는 것이 1차 목표
  • 약관 관련 피드백 논의
  • 케익 형틀,
  1. 프로세스 회의 온라인 참석, 진성님과 한스님만 온라인 참석으로 되어 있는 것, 저도 온라인 참석할 계획
  2. 디자인 ui ux 적인 요소들이 조금씩 다른것들은 후순위 작업, 일단전반적인 기능 원하는 동작이 되게끔 하는 것이 1순위
  3. 관리자 페이지의 최종그림 중 하나는 SPA 구현, 사실 혼자서 개발할때는 SPA로 하려다가 시간이 너무 거릴것 같아 전환한거라서..
  4. SloAjax -> SloUtil
  5. sloform -> 이중 클릭 방지
  • 우리회사는 식당이나 빵집으로 치면 골목식당, 아파트 단지주변에 있는 자영업자 빵집과 같다. 이런 식당이나 빵집에서 준비할 것은 식당이라면 미리 세팅된 음식에다가 손님이오면 국물만 부어서 빨리 나가야된다. 동네가게 빵집도 주문제작으로 케익을 만들기도하나 대부분 진열된 빵들은 미리 대량 빵을 빨리 많이 찍어낼 준비들을 어느정도 갖추고 있고 나름 소규모 기계에서 많은 양을 미리 세팅해놓고 판다.

  • 한스님이 이야기 하신대로 자바 프로젝트에는 다양한 요구사항들이 있을 테지만, 이또한 최소한의 준비된 템플릿에서 복사해서 프로젝트를 써야 한다고 생각한다. 빵집에서 주문제작으로 빵을 받더라도 어느정도의 준비된 규격과 빠르게 대응할 수 있는 준비된 상태여야 한다.

  • 준비된 규격이 없거나 제안하지 않는다면 늘 고객의 요구사항만 만드는 일이 될 것이고 고객의 요구 사항만 만드는 일은 고객의 성향에 우리 업무가 너무 크게 좌지우지되고 개발자인 우리가 겪는 괴로움의 문제는 해소되지 않을 것이다.

  • 새로운 기술들 공부한 것들을 새로운 프로젝트할 때 적용할 것이 아니라 템플릿 프로젝트에다가 적용하고 복사해서 써야한다.

  • 어제 라이나 작업에서 이런 작업이 있었다 카카오를 통해 가입한 회원의 경우 카카오에서 내려받은 프로필 이미지가 http://카카오 cdn 주소로 되어 있어서 브라우저에서 주의 요함이라고 뜨는 문제가 있었는데 이를 수정했다. 아마도 이 문제는 라이나에서는 해결했지만, 아마도 새프로젝트를 하는 다른 누군가는 동일한 문제를 나중에 또 반복 할것이고, 아마 이 문제를 경험한 나조차도, 시간이 어느 정도 지나 새로운 다른 프로젝트를 한다면 그리고 템플릿프로젝트 없이 새롭게 프로젝트를 만들고 시작한다면 아마 이 문제를 동일 반복할 것이다. 어느정도 문제를 여러번 겪다보면 기억해서 해결은 하겠지만… 불필요한 문제의 반복을 없애기 위해서는 문제점을 템플릿 프로젝트에서 카카오 가입시 이미지 경로를 https로 변경해놓는 방법이다. 그리고 새로운 프로젝트를 할 때 템플릿프로젝트를 가져다 쓰는 방법이다.

  • 베이스 프로젝트가 여러분들이 이야기하신대로 문제가 많다. 일단 시작할때 사용하지 않는 소스 코드는 지워야하는 문제부터 많은 요구사항에 대응하기 힘들다는 지적까지 이러한 문제들 또한 프로그래밍으로 산을 넘어야 한다고 생각한다. gradle의 멀티프로젝트를 통한 방법도 해결방법이 될 것이고, Source generator(예시: https://www.jhipster.tech/) 를 개발을 통한 스캣폴딩도 방법이 되지 않을까 생각한다. 소스를 넘어 서버관리, 배포까지도 자동화할 수 있는 무언가들을 가이드가 아닌 개발로서 풀어나가면 더욱 좋을듯 하다.

  • 일반 동네 미용실에가도 어떤 헤어스타일로 해줄수 있는지 책자를 제시해준다. 우리는 어떤걸 만들 수 있는지를 제시할 수 있는게 있었나? base-wp를 만들기전에는?

  • 템플릿 프로젝트를 사용해야하는 이유중에 하나는 품질의 문제다. 미리테스트가 누적되어 수행을 시켜놓을 수가 있다. 현재는 테스트가 충분하지 않지만..

  • 우리 회사의 프로젝트 관리 수준을 생각한다면 사실 워프나 레일즈이상 크기의 프로젝트는 적합하지 않다고 생각함..SI에 단가 높은 프로젝트들을 진행한다면 더 높은 관리 수준의 인력이 필요하고, Si회사들이 가지는 조직체계들을 가져야하지 않을까 상객됨.. PM이 있고 개발PL들도 프로젝트 아키텍쳐만 설정해주고..

  • 베포 쉘 스크립트,

그리고 불필요한 기능을 위해서 지우는 경우가 많다 라고 하는 부분이 있는데 이는 넘어야할 산이라고 생각함. 최근에 gradle을통한 멀티 프로젝트도 방법이 될 것이고, generator를 통한 스캣폴딩도 하나의 방법이 될거라고 생각함

라이나 유튜브 5개 순차 재생…

  1. faq 화면에서 캠페인 카테고리 선택 -> 취소 후 메뉴링크를 누르거나 카테고리를 저장하거나 하는 등의 화면 리로드를 하면 카테고리는 대관에 선택된 상태에서, 검색결과는 캠페인 결과가 나옵니다. 취소시에 저장된 부분을 제거해야할듯 합니다.
  2. 리스트 화면에서 노출순서를 저장할때 순서가 바뀌는 경우는 저장되었음이 인지가되는데 순서가 바뀌는 경우는 저장되었나 라는 생각이 들더군요, 순서가 안바뀌면 그다지 상관 없을 것 같기도 한데.. 음 일단 꼭 고쳐야될 것 같지는 않은데 의견을 남겨봅니다.

https://stackoverflow.com/questions/12744303/intellij-idea-java-classes-not-auto-compiling-on-save

  1. 로그인 : 아이디와 비밀번호 입력시 오류와 관련하여, ID와 패스워드 중 어느 쪽이 틀렸는지 알려주는 것은 보안적인 측면에서 좋치 않으므로 동일한 에러메세지를 내보냈으면 합니다.
  2. 로그인 : 소셜 버튼을 가로 나열 보다는 세로 나열.. 빠지는 플랫폼이 있을 수 있으므로..
  3. 회원가입 : 016은 공식적으로 없어짐.. 011 017은 내년 종료 확정
  4. 비밀번호 찾기 : 비밀번호 찾기를 요구하는 사용자를 식별하기 위해 토큰 발행을 할 것인데, 하루의 유효기간을 두겠습니다.
  5. 비밀번호 변경시 토큰 삭제, 토큰 유효기간 지났을 시 처리 하루 정도

저장하고 리로드 하는 방식으로 개발하다가 막판에 저장 후 상태 유지 문제 때문에 리로드 하지 않는 것으로 바꾸면서 문제가… 중간년도 제거 후 다시 추가하면 index가 꼬이는 문제

  • 제거한 index를 저장하는 방법
  • delete실행시 화면을 리로드하는 방법
  • max idx 구하

리뷰 사항 수정 완료 리베이스 머지의 장점 sloForm jquerySerializeObject가 체크박스 데이터를 가져오지 못하는 문제 form 객체내에서 체크박스 엘리멘트를 찾아서 붙여 default 값,

, findMaxPlusOne 메서드 초기월 값이 없는 경우 max값을

autocomplete=”off”로 인해 기간 검색이 뒤로가기시에 값이 유지되지 않는 현상

파일 업로드 다운로드 권한 체크

https://stackoverflow.com/questions/19782389/playing-m3u8-files-with-html-video-tag

ehcache 분산 캐시 관련 적용 시도, 멀티 캐스트 주소가 준비되어야하고, 맥에서는 먼가 따로 처리 되어야 https://javacan.tistory.com/entry/133

ehcache 공식문서 ehcache + terracotta(인메모리서버) https://www.ehcache.org/documentation/3.7/clustered-cache.html

redis도 고민하다가.. 일단 따로 database를 설치 관리 해야한다는 부분

https://docs.hazelcast.org/docs/latest-dev/manual/html-single/index.html#integration-with-hibernate-second-level-cache

hazelcast 4버전대가 있는데 적용 실패하였다. 3버전대 적용함

메뉴 정보 수정시 unregisterMapping, registerMapping을 실시 하는 부분에서 서버가 2대 이상인 경우 문제 레디스 사용 여부 레디스 캐시가 느리기는 하다..hazelcast에 비해서.. 레디스 캐시 devtools 충돌 문제, 커스텀 설정을 하면 에러 발생 기본 값은 괜찮음, devtools를 지우면 괜찮음 레디스 세션 레디스에는 TTL 35분이네?

spring session timeout 이 적용되지 않는다. https://www.it-swarm-ko.tech/ko/java/spring-boot%ec%97%90%ec%84%9c-%ed%95%84%ed%84%b0-%ed%81%b4%eb%9e%98%ec%8a%a4%eb%a5%bc-%ec%b6%94%ea%b0%80%ed%95%98%eb%8a%94-%eb%b0%a9%eb%b2%95/1043023122/

//관리자 채팅방 chatService .createChatRoom(ChatRoomCreateDto.of(ChatService.ADMIN_CHATROOM_SUB_URL, “관리자 채팅방”));

부탁하기.. 테섭에 등록..

ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABAQDn7PUIc7IqFQSSJFHwer6sCRnaW4WgdUjh9qao/Q2ysbe8zvN/Lrj/c3ib7++eIyLEzT6UiCzi4jTD5UXhQvntNjw3b56nF9IPQWByoGOs6/avMKBXWkN4wTQk1KtxxU4yIPzY8NgeLqDKXBc72o7QFTqfm1H22nU8d5xk0PMb7xY5KS+Gn6l6UD31ea+Mjx4HfH+dfrPCfGjM8pWxjYqb7BswqWc6IYWvfgMWK8bcNZgknO/dtLgB0k4PSVsLjULVSuP2oUtSUEEZhPFSs9lJ89FVSt6ddbZI1RqkR24YifOUkljyoUS7ItWJscYgcnmWeW6+MB6H8y6XqF0wqBOf [email protected]

테스트서버에 여러가지 다른버전의 was가 올라갈 개연성…cluster cache우려사항..

nginx 클러스터링 설정 시도

무중단 스크립트 재시도 baseboot-url.inc 파일에 로드발랜서 부분을 넣자 nginx 로드 밸런스 기능으로 헬스체크만 하고 배포해보자

hazelcast 기본 포트를 프로젝트 별로 다르게 해야한다. 테스트서버로 인해서… 클러스터 동작되는 것과 안되는 경우에 대한 설명 테스트 코드의 경우 별도 포트를 사용해야되나 아니면 테스트 동작시에는 클러스터를 끄는 것으로 해야할지도.

2개다 헬스 체크 하고 2개가 살아 있다면 2번을 끄고, 1개가 살아있다면 반대편을 끄고 배포한다.

/home/ufofactory/deploy/base-springboot_script.sh: 23: [: active: unexpected operator http://blog.naver.com/PostView.nhn?blogId=semidex37&logNo=221202535363&categoryNo=41&parentCategoryNo=0&viewDate=&currentPage=1&postListTopCurrentPage=1&from=postView

라이브러리 보안사항 체크 모듈 snyk 소개,

템플릿프로젝트를 만들어 놓으면 얻을 수 있는 장점 중에 하나가 선테스트된 프로젝트를 기반으로 프로젝트를 쌓아 올린다. 테스팅 코드 전반적으로 정리 및 추가 작성중, 컨트롤러테스트, 기획이 확정된 feature테스트, 여유되면 selenium테스트까지 작업해볼 계획 코드 커버리지 80퍼센트 이상이 목표 테스트 코드 커지면 빌 돌릴때 귀찮은 면이 있기때문에 테스트 그룹핑까지.. 어제 작업 분은 메뉴정보가 등록된 데이터를 기반으로 관리자페이지 컨트롤러 테스트를 추가함

maven 감사 플러그 57 7/23

  • 테스트 코드추가 작업
  • ApiController 테스트에서 상태 변경값들 검증하는 코드가 필요할지
  • Controller 테스트의 경우에는 원하는 동작으로 돌아가고 있는지 점검이 필요하다.

getQnaMenuList getCalenaderMenuList -> MenuService에 하나 만들자

내일 오전 모임에서 한번 먼저 작업되어야할 것들에 대해서 논의해보면 좋을 것 같습니다. - 템플릿 프로젝트가 가지는 장점으로 충분한 테스트 코드를 가지고 있는 것이 장점이라 생각하기때문에, - 프로젝트 시작 시에 지워 내야할 것들 준비 해야할 것들 정리 또는 툴 - 그리고 분야에서는 강좌, 결제, 대관,

slo-datatable수정도

저는 일단 관리자 bootstrap4로 이관하는 작업을 한다는 것은 adminlte 2버전대에서 adminlte3로 버전 변경하는 것으로 생각하고, html 요소를 관리자페이지에서 상당한 양으로 고쳐야한다고 생각했고, 그에 따라 자바스크립트 수정

사용자와 관리자에서 서로 다른 문서를 참고해야 하는 점 -> 백엔드의 경우, 관리자 페이지의 레이아웃을 잡게되는 경우는 있어도, 사용자쪽은 상관 없지 않는지? adminlte 3버전을 사용하지 않은 문제는 단순히 디자인 문제…bootstrap4는 기반의 관리자 디자인 템플릿은 전반적으로 ui가 크고 뿌옇다라는 느낌.. 이번에 adminlte3 document를 살펴보았는데, 그곳에 2.4 -> 3으로 업그레이드 가이드가 있던데 생각보다는 html요소들을 수정할 것들이 적었다 하지만

라이나 보안 지적사항 확인

  • 컨트롤러 테스트
  • Api 컨트롤러 테스트
  • 테스트 상속 클래스 작성 및 적
  • 테스트 태깅 분류
  • Rest docs 문서 포맷 작업
  • 테스트 코드를 추가하면서 발견한 수정들..(삭제 API DeleteMapping 일원화 등등)

base-springboot 계속 끌고 갈것인가? 자바를 좋아하는 사람이 없다.

테스트가 transaction은 걸려 있어 데이터는 원복되지만 RequestMappingHandlerMapping 변경 부분은 원복되지 않는다. 모킹으로 해결시

한스님이 생각하시는 퇴사 이유가 여러가지 있을수 있겠지만.. base-springboot 작업 자체가 해결책으로 생각지 않으신게 퇴사의 원인중 하나일 수도 있겠다. base-springboot 효용성에 대한 의문은 늘 있다. 사실 효용성이 없다면, 효용성 없는 것에 시간 투자할 필요는 없을 것이다. 지금 소유님과, 아만다님이 하고 있는 프로젝트 종료후 프로젝트의 방향성을 논의 해보면 좋지 않을까 싶음

그리고 두번째 문제는 현재 참여하고 있는 자바개발자들 중에 자바개발을 좋아하는 사람들이 거의 없다. 아에 없다(?) 일수도.. 저도 마찬가지라서..

베이스 기획 현재 베이스의 방향은 일종의 사이트 빌더인데 우리와 같은 개발 프로세스에는 템플릿이 보다 적합하지 않을까 하는 의문이 있음. 사용자가 구매, 설치해서 사용하는 사이트 빌더에서는 메뉴 생성 등을 프러덕션에서 한번에 끝내지만, 우리는 개발 환경에서 생성하고 코드화해서 배포하거나 두세번 반복하는 작업이 필요함. 방법이 정립되었으면 좋겠음. 퍼블리싱을 위한 페이지 작업시 백엔드 개발자가 미리 생성이 필요. (레일즈의 경우 routes.rb 를 고쳐가며 작업 가능.) 메뉴 관리 기능을 보강 및 확장해 메뉴에 표시되지 않는 세부페이지 작성과 추후 사이트맵 연동까지 노려보면 어떨지. 하지만 추후 메뉴 항목과 관련된 운영 작업이 보다 번거로워 지거나 제약이 발생하는 것이 아닌지에 대한 우려가 있음. 모든 템플릿 작업이 BASIC_DESIGN(혹은 CUSTOM_DESIGN)에서 이뤄짐. 파일 중복으로 인한 혼란이 있고, IDE의 지원을 받지 못하는 불편도. 관련 이슈 대시보드가 기획된 영역이 아니다 보니 나중에 대시보드를 제거하고 기본 페이지를 바꾸는 작업이 있었음. 관련 이슈 대시보드 기획이 필요할 수도 있지만, 첫 페이지를 무엇으로 할지 정하는 체크항목을 체크리스트에 포함시키는게 우선일 수 있음. 관련 이슈1 관련 이슈2 FAQ. 메뉴 관리에 Alias 같은 기능이 필요. (카테고리별로만 보여주는 페이지 + 전체를 보여주는 페이지) 삭제된 전체 카테고리 선택 기능 다시 되살려야 함. 회원 정책 동작 방식을 설명해주기 위해 코드를 검토하는 시간이 있었음. 어차피 소스 파악이 필요한 부분이긴 했지만 보다 쉽게 개발자와 기획자가 확인 가능하다면 좋을 것. 관련 이슈 배치 동작 점검은 역시 체크리스트에 포함되어야 할 듯. 관리자 페이지 공통화 ㅇㅇ를 수정했습니다. 같은 메시지는 유형화하거나 항목으로 일원화해 공통화 가능. 관련해 추가한 코드 일부 페이지는 편의를 위해 상단 타이틀(ㅇㅇ관리) 옆에도 버튼이 들어갔는데, 더 나은 UX에 대한 제안이라면 베이스와 함께 논의되고 반영되는 구조가 필요하지 않을지. 관리자 목록 페이지의 버튼들을 모아둔 열은 한국언론학회는 동작, 조작, 사회공헌센터는 목업만 봤을때 들어갈 버튼들을 열거하는 방식(삭제하기, 자세히보기, 수정 및 삭제)등으로 상이한데 통일하면 일을 줄일 수 있음. 테이블 셀의 가운데 정렬. 관리자 테마 제작 및 적용과 함께 이뤄질 수 있음. 베이스와 협업 소스 코드 통합의 어려움. 초반에는 베이스를 기준으로 리베이스를 했는데 강제푸시가 반드시 전제되기 때문에 지속될 수 없는 방식이었음. 현재는 체리픽을 하고 있으나 그래프상 원본 커밋과 무관해지는 문제가 있음. 리모트 트래킹 브랜치를 따로 두고 메인 브랜치에서는 해당 브랜치로부터 머지해오는 방식이 보다 적합할 듯 보이나 언론학회 쪽에서는 삭제된 기능도 많아(강좌, 나눔, 공간, 강사, 캠페인, 등등…) 매번 충돌하는 관계로 프로젝트 모듈화가 선행되거나 이용 방식이 모듈을 Disable해서 쓰는 형태로 달라져야 할 듯. (다만 그렇게 기존 기능을 남겨서 쓴다고 해도, 변경된 기능(대표적으로 User 도메인)의 충돌 관리 문제는 남음). 깃헙의 경우 지라와 달리 이슈 키에 프로젝트 이름이 붙지 않기 때문에, 체리픽 할 때 엉뚱한 프로젝트 이슈에 연결되는 문제가 있음. 리스크 관리. 베이스에 Hazelcast 적용되었을 때 바로 적용시 여러 이슈가 있을거라 판단했고, 추후 안정화를 기다려 여러 커밋을 한꺼번에 체리픽함. 안정 브랜치 혹은 개발 브랜치 같은게 필요할 수 있지만, 버전이나 브랜치 관리의 어려움을 생각하면 PR 및 리뷰를 보다 활용하고 업스트림에 버그가 보고되었을 때 작업 우선순위가 조정되는 것이 보다 가능한 방안일 수 있음. ATOM, RSS 기능은 검수(권한) 포인트가 많아지는 관계로 삭제함. 소셜 로그인 기능을 제거했는데, 관련 사용자 컬럼도 삭제한 관계로 이후 매번 충돌을 겪음. 현 구조상으론 소셜 지원 추가시마다 컬럼 추가가 필요하다는 점을 고려할 때, 별도 테이블화가 필요할 듯. 관련 이슈 공통 기능을 최소로 넣어두느냐 아니면 최대한의 가능한 기능을 넣어두느냐는 논의 필요. 현재 방향은 전자로 보이나, 프로세스가 아닌 필드에 있어서는 삭제가 구현보다 편한 것 같음. (예 : 사용자 가입시의 사진 첨부) 진행중인 프로젝트를 고려한 로드맵 관리 회원관리쪽 페이지는 베이스 자바에서 요청해 수워니님이 작업하신 것을 가져올 수 있었음. 베이스에 기능 구현 요청을 해도 되는지에 대한 모호함과 부담이 있음. 사내 중복 작업을 방지하고 효율을 높이기 위해서는 베이스 로드맵과 작업가능 상황을 확인하는 것이 자연스러워져야 하지 않을지. 현재는 메인 슬라이드 관리(관련 이슈)가 필요한데 사회공헌센터에도 있고 프로보노에서도 개발했다고 알고 있음(부트스트랩 4 이전이 선행되야 할 듯). 개발 환경 부스스트랩 버전 이원화로 인한 불편과 마이그레이션시 재작성 우려, 구버전 학습에 필요한 의욕 저하 등의 이유로 중간에 부트스트랩 4 적용. 관련 이슈 레일스와 같은 모델 수정 및 마이그레이션 도구가 기본 포함된 상태가 아니다 보니 불편이 있음. 프로젝트 초반에 Liquibase를 적용하기 위해 시간을 썼지만, 레일스처럼 해당 언어로 데이터를 넣거나 JPA와 통합하는 것은 잘 되지 않았고 체인지셋 정도만 한 상태. 관련 이슈 JPA 사용시 Best Practice는 XML로 스키마를 선언하고 메이븐 플러그인으로 변경사항을 추적하는 것일텐데 이는 현재 베이스에서 사용하는 SQL 제너레이션 방식과 상이하고, 다른 이슈가 없을지에 대해 의구심이 있음. VSCode 관련 설정은 제대로 문서화 될 필요가 있어 만들었음. 관련 위키 문서 바로 사용하고자 했을때 인텔리제이는 종종 느린 이슈(2013 맥북 13인치 i5, 16GB), 프론트 개발자가 익숙하지 않은 문제, 라이선스 요구되는 등의 문제. VSCode를 계속 사용한다면 백엔드 개발자가 사용하는 인텔리제이와 스타일 공통화가 필요할 듯 함. 개발 환경은 도커를 필수로 했다가 도커 설정이 부담일 듯 하여 중간에 제외시킴. 레일즈 퍼블리싱에 이미 DB 세팅을 필수로 하고 있어서 퍼블리싱 난이도에 대한 우려는 없었음. H2와 MySQL의 차이로 인한 잠재적인 오류가 우려되어 H2 지원은 사실상 삭제함. 변환된 자바스크립트가 여러 곳에 있어서 파일 열어보기나 파악에 불편. 최종 생성본은 target 혹은 dist(가칭) 같은 생성된 디렉터리에 들어가서 IDE에서 참고되지 않게 해야 할 듯. 테스트 환경과 테스트 서버 환경을 이원화할 수 없어 해결이 어려운 문제. 단기적으로는 테스트 서버를 도커나 델 서버로 옮기면 해결 될 것으로 예상.관련 이슈 고민하지 않고 바로바로 사용할 수 있는 변수명 규칙 정립 필요. 관련 이슈 필드 유형별로 바로바로 참고할 수 있는 레퍼런스 필요. 관련 이슈 페이지명, 내부 변수명 등을 가능한 그대로 복사 붙여넣기 가능한 방식으로 작업. 예: 컨트롤러의 메서드는 get(), getList() 등으로 도메인 명을 생략하고, 페이지명도 list.ftlh, form.ftlh 등으로 정의. 베이스에도 일반화되면 좋겠음. 관련 슬랙 논의 팀내 커밋 메시지 작성 스타일 상이(EDIT-, -수정, -합니다). 공통 스타일 없어도 될지? 기타 기존 데이터를 엑셀로 받았는데, 컬럼 형식이 제대로 지정되지 않은 문제로 발생하는 예외가 너무 많음.(전화번호의 경우 Number 포맷으로 지정되면 010…의 0이 삭제됨. 우편번호, 아이디 등도 마찬가지) 엑셀로 받은 것 자체가 드문 사례고 예상할 수 있는 문제이긴 하지만 어쩔 수 없는 상황이라면 데이터형에 대한 주장을 강하게 해야 할 듯.

베이스 스프링부트 프로젝트 방향성

오늘은 어떤 방향으로 갈 것인가 논의가 될 것 같고 오늘 논의가 정해지면, 구체적으로 어떻게 갈것인가는 다시 논의가 될듯 하다.

  1. 사이트 빌더 형태를 지향하고 있는데, 새 프로젝트 진행에 불편한 요소들이 많다. 템플릿 프로젝트 형태로 변경해야하는지 여부 논의
  • 현재 base-rails처럼 기본적인 예제들 나열되 형식의 기초 프로젝트가 있고,
  • base-springboot는 워프 처럼 몇가지 설정만하면 기본적인 사이트가 나오는 것을 지향하고 있다 이 둘중에서 슬로워크에서 새로운 프로젝트를 준비하기 위해 알맞은 프로젝트는 어떤 것인가?

  • 아만다 : 예제를 만들어둔게, base-rails 형태가 맞을 거 같다.
  • 소유 : 기획적인 부분이 서로 반영이 잘안되는 것 같다,사이트 빌더 형태든 예제 형태든 문제는 아닌듯 하다. 현재 방식에서 개선하는 방식이 좋다.
    • 사이트 빌더 형태의 어려움을 정리할 수 있는 이슈 생성
  • 예제를 필요한 이슈는 스프링 쪽을 경험해보고 싶은 분들 하고 간단하게 진행하는 게 좋을 것 같음

기타. 프로젝트 진행 리딩 변경

  • 제가 개인적으로 만들기 시작하다 회사프로젝트화가 되면서 여러가지로 초반 틀을 제가 만들게 되어 소유님이 여러가지로 이슈를 제기하시고 제가 검토하고 수락하는 형태가 되어 버렸는데, 경험도 부족한 제가 경험 많은 분의 의견을 수락하는 형태는 무언가 잘못된 느낌을 받습니다. 이 부분을 좀 역전시켰으면 하는데요, 이제 저보다도 더 프로젝트 구조에대해서 파악을 하셨고, 현 프로젝트가 가지고 있는 문제점들에 대해서 파악을 하고게시기에 소유님이 현 프로젝트를 소유님이 주도하시고, 결정권을 가져가시는게 맞지 않을까 싶습니다. 반대로 제가 의견을 내고 소유님이 여러가지로 선택하시는게 맞는 모습이지 않을까 생각합니다.
  1. 이슈 레이블 중요도 관리

  2. 로드맵관리
    • 다음주 목요일
    • 프론트엔드 프레임워크
  3. 프로세스 관리 배포
    • 프로세스 기획, 디자인 배포 등등 현안 논의

프로젝트 관리나 이런것들 제가 주도한다는 생각때문인지 제 색깔을 유지하려는 경향성이 있는데 제가 좀 고집 피우는 경향도 있고, 사실 피드백에서도 그런 글이 나왔고 해서, 다른분이 리딩해주시면 다른 사람스타일을 잘 따라가는 편이어서 이 시점에서 바꾸는것이 좋지 않을까 싶습니다. 그리고 소유님이 전반적인 base-springboot 리딩을 하시는 것이 좋지 않을까 싶습니다.

base-springboot

다음주 목요일 27일 - 로드맵 먼저 해야할 것들 우선 순위 정하기, 프론트프레임워크 선정

자바 웹개발의 미래

  • 매년 버전이 갱신되는 자바 API 현재 jdk 14버전
  • 코틀린 언어 자바와 혼용 가능 -> 코틀린을 함께 쓰는 업체들 증가
  • spring webflux - non blocking 모델 https://woowabros.github.io/experience/2019/03/18/tech-toby-reactive.html

베이스 모듈 - 다음주목(27) 논의 작업 우선순위, 프론트 프레임워크 관련 논의

  1. 작업 우선 순위
  • 테스트 코드 완성 - 작업하다가 중단한.. 미리 준비해둘 수 있는 템플릿 프로젝트가 가질 수 있는 장점
  • 프로젝트 셋업 툴(?) 또는 시작 방식 개선
  1. 프론트프레임워크
  • 사실 현재 작업과 관련한 부분을 코멘트해보면, 사실 현재 작업하는 부분에서 한스님이 만드신 slo-form, slo-table 적용 그리고 bootstrap 3 기반으로 admin이 되어 있었는데 bootstrap4로 바꾸자고 논의 되는 부분 등 저는 사실 조금은 시간낭비라고 생각함, 개인적으로는 그냥 빠르게 기능적으로 동작하고 사용할 수 있는 관리자나 기능을 완성하고, SPA방식의 ADMIN을 선 도입하려 했던 생각이 있었음, slo-form, slo-datatable등 bootstrpa4로의 변화같은 경우 내부적으로 여러가지 개선하는 행위들은 개발자 눈에는 개선되어지고 있다고 생각할지 모르나, 기획자나 외부에서 보기에는 그냥 기능 변화 없는 것이라고 생각될 수 있음, 그리고 지난 회의에서 기획자가 base-springboot를 반영하지 않고 고려하지 않는 경우에 대한 이야기도 있었는데, 눈에 띄는 기능 변화와 보여질 수 있는 부분들을 보여줘야 기획자분들도 호응을 하리라고 봄 코드상 여러가지 아쉬운 부분이 있더라도, 눈으로 보여지는 변화가 더 필요하지 않을까 생각함.
  • 어떤 것으로 결정되어져도 상관 없다고 생각하고 있으나, 배우기에 쉽고 간단한 것들이 추후 유지 보수면에서 조금 더 좋지 않을까 생각함 Vue나 Svelte의 선택에 조금더 좋은점수

  • 프로젝트가 하나로 되어 있는데 나누는 것도 방법도 고려해봄직
  1. 관리자 프론트 프레임워크를 통한 프로젝트 분리
  2. 프로젝트 시작시 세팅을 빠르게 가져가기 위한 툴 또는 gradle 이관
  3. 기획 및 작업이 덜된 domain 작업
  4. 테스트 코드
  5. 리펙토링 관련 니즈가 많은데 이부분을 모른채 넘어가면 기술 부채로 쌓일 수도 있지만, 크리티컬 한게 아니면 일단 넘어가자 눈에 보이는 기능이 빨리 되어야 기획자들하고 이야기하기도 좋다. 일단 기능이나 동작이나 프로젝트 개선이 우선이다. 부트스트랩 3 -> 4 로

  6. 소유
    • 아만다님의 회고 공유 부탁
    • 베이스를 실제 프로젝트를 어떤식으로 진행할것인가 프로세스 같은 것이 적립되었으면 좋겠다. - 예를 들면 기획자가 URL 같은 것을 정해줬으면 좋겠다. - 프로젝트 시작할때, 페이지를 만든다.

    • cli 툴 보다는 결합된 구조를 풀어 놓는 부분이 먼저지 않을까 한다.
    • 메뉴
  7. 수워니
    • 프로젝트
  8. 기획적인 기획 모듈을 기준으로 작업하게 한다.
  9. 체크 리스트, 레퍼런스가 필요하다. 예시 모듈이 필요하다. 클라이언트 기술을 통합하는 것(데이트 피커, vue.js), 데이터 베이스 형상관리 도구, 메뉴 관리 기능, 디자인 템플릿을 제거하는 방향에 대한 논의, slo-strap, 관리자

LOGIN_ID IN (‘0325A51720D1B1709506E3FFEF7228C6’, ‘66D3566A021499F9DDF0F7CF1F9177BB’)

slowalk.net 에 mysql5.7 설치 root pass : [email protected]

Package: mysql-server Pin: version 5.7.31-1ubuntu18.04 Pin-Priority: 1001

Package: mysql-client Pin: version 5.7.31-1ubuntu18.04 Pin-Priority: 1001

Package: mysql-community-server Pin: version 5.7.31-1ubuntu18.04 Pin-Priority: 1001

Package: mysql-community-client Pin: version 5.7.31-1ubuntu18.04 Pin-Priority: 1001

Package: mysql-apt-config Pin: version 0.8.12-1 Pin-Priority: 1001

https://medium.com/webeveloper/%EC%9E%90%EB%B0%94-%EC%9B%B9-%ED%81%AC%EB%A1%A4%EB%A7%81-web-scraping-1f606994e618

http://blog.naver.com/PostView.nhn?blogId=battle50&logNo=220216222487&parentCategoryNo=&categoryNo=10&viewDate=&isShowPopularPosts=false&from=postView

https://www.vogella.com/tutorials/RSSFeed/article.html

페스트캠퍼스 정리 -> 노드교과서 정리

페캠 -> 박준영 익스프레스 sequalize, promise, 크롤, graph, 배포, docker -> 정민우