본문 바로가기

All

(92)
[개발생각] 공포의 주간랭킹 개발하기 프로젝트에서 주간랭킹을 개발해야했다...이게 공포가 될줄이야... 생각할께 너무 많아서 머리가 아픈적은 처음이네 ㅠ 여러 이벤트를 이용해 경험치를 유저가 획득하고,주간으로 획득한 경험치 순으로 주간 랭킹을 구해야 한다는 개발요건이다.(쉽지??...ㅎㅎ)그런데... 여기서 끝나는게 아니고, 조건이 몇가지 더있다!!! 1) 회원 전체 대상 랭킹이 아닌, 소규모로 그룹을 나누고 그 그룹안에서의 랭킹.2) 소규모 그룹을 나누는 기준은 랜덤.3) 해당 기준은 주마다 매번 달라야함 (즉, 주마다 랜덤을 섞여야함) 이렇게 3가지 조건이다. 물론, 단순하게 생각을 하면 뭐 이게 뭔 고민을 할꺼리인가? 라고 생각할수도있다.하지만, 이 기능은 고민을 하지않고 만들게 되면, 큰 성능상의 문제를 발생할 여기가 다분하게 있다...
[개발생각] 블리자드..이래서 망한건가??? 주말에 스타크래프트, 와우, 오버워치로 유명한 블리자드에서 Battle.net API를 제공하는것을 알았다. OAuth2 API로 구성되어있고, 다름 데이터가 많아서,랭킹 리스트와 프로필등을 한눈에 볼수있는 서비스를 하나 만들면 어떨까?하고 API의 연동을 시도해봤다... 그런데!!!글로벌기업, 그리고 한떼는 모든 게이머들에게 선망의 대상이었던,갓 블리자드가 API를 이렇게 만드는게 현실인가??? 라는 생각이 들기 시작했다. 우선 API는 문서가 없다.문서라고는 api url들과 필요한 요청파라미터만 기술되어있다.해당 API의 응답 필드가 문서로 정리되어 제공하고 있지않아서, 직접 API를 호출해보고, 응답값을 보고, 유추하여 사용해야한다 ㅠㅠ(하... 내가 알던 블리자드 맞나???)https://com..
[개발생각] AI시대에 프로그래머로 사는법? 예전에는 프로그래머의 실력을 가늠하는 기준중에 하나가 경험에서오는 노하우, 그리고 지속적인 스터디를 통한 지식으로 확연하게 실력을 가늠할수있었다. 예외인경우도 있었지만, 연차가 그 개발자의 실력을 가늠해주는 척도로 자주 사용을 했었다. (짬밥 어디안간다!! 이런 느낌이지..ㅋ) 이런 연차를 무시못하는것이 연차만큼 여러 문제글 경험하고, 해당 문제를 해결하기위해 노력했던 사람이라면,그 노하우가 무시못할 지식이기 때문이다.이런 경험들이 쌓이면, 일부 예언도 가능하다(이건 아마 이래서 문제가 있을꺼야 같은 예언...) 예전에 윈도우 개발을 할때도, 레퍼런스가 많이 없어서, 커뮤니티를 수없이 들락거리며, 질문하고 답을 얻으며 개발자로서 시간을 보냈다.문제를 당면하고 그 해답을 얻는 방식이였기 때문에, 해당 문제..
[개발생각] JPA에서 soft delete 관리하기 JPA에서 soft delete관리를 어떻게 해야하나를 고민했었는데.. 방법이 있었네 ㅠ 진행하는 프로젝트에서 jpa에서 row delete를 할때, soft delete방법을 사용하고 있다.delete_dtm필드가 null인지 아닌지에 따라 삭제여부를 판단하여 사용하는것으로,delete로 실제 row를 삭제하지 않는 방법을 사용한다.(이부분은 여러 장점이 있기에 이렇게 하기로 결정했다.) 그런데 하나 귀찮은점이 있다.바로 항상 조회시 deleteDtm is null을 붙여야 실제 삭제되지 않은 값을 가져와서 사용할수있기에, 아래 JpaRepository와 같이 항상 조건에 DeleteDtmIsNull스펙을 넣어야한다. fun findAllByDeleteDtmIsNull() : Listfun findO..
[개발생각] 시스템의 정리 - 코드 컨벤션과 분류 요즘은 좀 집착하는게 있다, 컨벤션과 분류라고 해야할까? 현재 진행하는 프로젝트가 아무래도 오래된 년차가 있는 시스템을 신규로 개발을 해야하는 프로젝트다보니,기존의 레거시 시스템을 우선적으로 파악해야하는 경우가 많다.(레거시를 파악하고 이해해야, 신규 시스템도 만들수있으니) 여기서 어려운점이 무엇이었냐하면 (아직 프로젝트는 끝나지 않았지만..ㅎ)기존의 시스템,서버들, 즉 인스턴스들의 분류가 명확하지 않고, 관리가 잘안되는 느낌이었다.인스턴스들이 동작하고 있는 정보를 한눈에 볼수가 없고, 파편화되여, 여러서버들에 인스턴스가 떠있는 느낌이 들었다.따라서 명시적으로 어떤 기능이 어떤 서버에 몇개의 인스턴스로 동작하는지를 파악하는게 어려웠고,파악을 하더라도, 이게 정확한것인지를 확신하기가 어렵다는 것이였다. 이..
[개발생각] 리더의 역할이 구성원에 대한 기대와 어떤 관계가 있을까? 요즘 가장 많이 드는 생각이 있다. 리더의 역할이 구성원에 대한 기대와 어떤 관계가 있을까? 리더는 기본적으로 구성원을 잘 이끌어야한다고 누구나 생각한다. 이건 누구나 알고있는 만고의 진리같은것이라고 생각된다.하지만, 실제로 리더의 생활(?)을 경험을 해보면, 여기서 많은 괴리감이 생김을 알수있다.바로, 리더가 어미새, 코치, 선생님이 되어야하는가? 라는 생각이다. 구성원들의 모든 부분에 대해 파악을 하고, 누구와 사이가 좋은지, 좋지않은지를 알고, 어떤 업무를 싫어하는지 알아야하고, 왜 기분이 좋지않는지를 파악해야하는것... 이런것을 리더의 역할이라고 생각을 하는 구성원들이 많다는 것이다. 이런 부분을 해결해주지 않는 리더는 리더의 역할을 잘하지 못한다고 판단을 실제로 많이한다.(참 무섭지... ) 물..
[개발생각] ActiveMq에서 Topic을 Queue방식으로 컨슘하기 이번주에 삽질을 한부분을 글로 남겨둔다.ㅠ 셋팅문제긴했지만, ActiveMq는 사실 십몇년전에 레포트만들때 잠깐 사용한게 전부, ActiveMq에 Topic을 컨슘을 해야했다. 컨슘을 했고, 컨슈머를 이제 늘려서 성능을 높이려고 늘려서 테스트를 하는데,같은 데이터가 컨슈머 갯수만큼 들어왔다. 이상하다라고 생각이 들어서, 확인해보니,ActiveMq에서의 Topic은 Fan-Out방식으로 동작을 한다는것을 알았다.(하나의 이벤트를 여러 컨슈머가 동일하고 소비하는 방식)즉, 같은 이벤트를 동일하게 컨슘하는 방식이고, 여러 컨슈머가 서로 다른 이벤트를 소비하려면,Queue방식으로 컨슘을 해야한다는것을 알았다. 참... 토픽, 큐 정의 명확히 통일좀 시켜주면 안될까..ㅋㅋ카프카, 레빗엠큐, 액티브엠큐에서 의미하는..
[개발생각] Bloomfilter에서 삭제가 가능하다면? BloomFilter는 확률적으로 원소가 존재하는지를 확인하는 확률기반 알고리즘이다. 작은 메모리로 원소 존재여부를 확인할수있다. BloomFilter는 많은곳에서 활용이 가능하다. 공지/글등의 읽음표시여부에 사용할수도 있고 (내가 적용했지 후후..),디비의 조회를 줄이기위한 필터링으로도 사용가능하다 (HBASE가 정말 BloomFilter를 적극적으로 사용했지..) 하지만 이런 좋은 기능이지만, 단점이 하나있다.바로!!! 한번 저장한 원소(값)은 삭제를 할수없다는 것이다.이게 당연한것이,BloomFilter는 해시값을 비트버킷에 저장을 하는 방식이기에, 원본 데이터를 저장하지 않는다.따라서 원본 데이터를 알수없기에 삭제도 할수없는 것이다.따라서, 삭제가 필요하다면,BloomFilter 버킷을 새롭게..
[개발생각] jpa에서 조인 Entity를 사용하는 신박한 방법 JPA에서 엔티티에 관계설정을 하지 않고, 조인을 유연하게 사용하는 방법은 뭐가있을까? 정답은 아니지만, 오늘 좀 신박한 방법을 하나 생각해내서, 공유를 해본다. User, Group 엔티티가 존재한다고 해보자!User의 id와 Group의 userId로 조인해서, User정보와 Group정보를 합쳐서 사용해야한다.(Jpa에서 관계설정 방법은 지양하는 전제조건이다) 이럴때, 아래와 같이도 할수있겠다고 생각했다.(이런생각 한사람이 많을까? ㅋ.. 좀 정상아닌것 같기도 하지만.. 구현해보니 나름 장점이 많다)//UserRepository.ktinterface UserRepository : JpaRepository { @Query(" SELECT u, g FROM User u, Group g..
[개발생각] API 패키지를 어떻게 관리하면 될까? 클린코드에서든 레거시에서든, 어떻게 해야할까?라는 생각이 잠깐씩 들때가 있다. 바로 API패키지를 어떻게 가져가야하지? 생각이다. UserGetUsecase, OrderGetUsecase, ProfileGetUsecase가 있다고 하자!앱내의 My탭에서 정보조회를 해야하는데, 여러 이유때문에 User, Order, Profile정보를 하나의 API로 제공을 해야한다.또는 앱에서의 여러번의 API호출을 줄이기위해, API를 묶어서 한번에 조회하는 API를 제공해야한다면..이런경우, Facade를 만들거나, 컴포지트 Service를 만들어서 여러개를 조회해서, DTO로 내려주면 되기에, 큰 고민은 없는뎅... 고민은 DTO와 Package명, api경로가 영 너무 맘에 안들게 된다.예를 들면) /api/v..