오늘 알게된것

1기가 나왔을 때부터  간간이  소식을 접했던  ssafy ( Samsung  software academy for youth) 이번에는 내가 직접 지원부터 온라인 테스트, 면접까지 경험해 보았다. 우선 지원 시 자소서 문항은 매년  비슷한 것  같고, 난이도도 무난하다. 다만 해당 자소서를 바탕으로 1분 자기소개, 인터뷰 예상질문 등  여러 가지를  작성할 계획이라서 자소서를 신중히  작성하는 게  중요하다. 이미 작성한 후라면  어느 부분을  보완하여  인터뷰 때   보여줄  지  정하는 게   우선순위다 . 수리/추리 논리 - 이건 진짜 간단한 수학문제였다. 주로 금액, 거리, 확률과도 같은 그냥 그런 문제들이 나오는데 온라인  테스트 때  옆에 펜과 종이만 잘  갖춰  놓으면 문제에 잘 설명돼  있어서  풀면 된다. CT(Computational Thinking) 문제 - 이건  코테를  연습한 사람이면 뭔가 익숙하면서  낯선 게  그런 알고리즘 문제에서 주는 예시들을 손으로 푸는 느낌이다. 다만 "과정"이 아닌 "답"만 적으면 된다. 으레 그렇듯 규칙성이 있고 이것만 발견하면 손으로 빨리 풀면 된다. 고난도의 문제는  아니지만, 온라인  30분  일 때에도  후의 오프라인  12분일 때도  시간이  꽤  부족했다. 다만 합격자들의 이야기를 들어보면 꼭 다 맞춰야  하는 건  아니니 최대한  푸는 걸로  만족하면 된다. 인터뷰 - 가장  걱정됐었고 , 유일하게 연습을 한 과정이다. 방식이 매년 조금씩 바뀌고 내용유출이 금지인지라 다들  건너  들은 이야기를  토대로 연습했다 ....

 약 한달 전 조회 조건을 추가해달라는 요청이 왔고 대수롭지 않게 추가했던 적이 있다. LEFT JOIN tb_review re ON re.care_no = ca.care_no AND re.delete_yn = 'N' AND re.reg_type = '0' 이게 전체 조회량을 늘리고 늘려서 화면을 다운시킨다는 것을 알게 되었는데, 일반적으로는 join에 and조건을 걸으면 이런 현상이 일어난다고 한다. 그래서 사수님은 이걸 1차적으로 분리해서 작성했고, 시간이 12초에서 1초 내로 줄어드는 효과를 보았다.  LEFT JOIN tb_review re ON re.care_no = ca.care_no  WHERE 1=1  AND re.delete_yn = 'N' AND re.reg_type = '0' 아니 근데 이건 다시 확인하니까 조회 대상이 바뀌는 변화인 것. 전과 같은 결과를 위해 다시 쿼리를 돌려야 했고 EXPLAIN 명령어로 해당 쿼리를 조사해보자 review 테이블에서 care_no를 인덱싱 없이 ALL로 조회하고 있음이 나왔다. 여기에 인덱스를 추가해줘서 결국 같은 결과를 1/10 이하의 시간으로 조회가 가능케 했는데 이에 너무 신기해서 인덱스에 대해 살짝 정리해볼까 한다. 

 해시 > 위장 스파이가 여러 종류의 옷을 가지고 총 몇가지의 위장을 할 수 있냐는 문제다. 이건 수학문제중에 경우의 수에서 자주 볼 수 있는 문제인데 중간까지 그걸 파악못하고 혼란을 겪었다.  map 에 중복되는 요소들을 넣기 위해 이전 테스트에서 배운 getOrDefault 메소드를 사용했고, entrySet으로 모든 요소들을 가져와서 경우의 수 공식에 대입했다.  스택/큐 > 다리를 지나는 트럭 이 문제는 시간이 정말 오래걸렸다.. 실제 테스트에 나왔으면 이거 하나 풀고 다른거는 건들지도 못하거나 이문제를 건들지도 못하거나 ... 생각 할 요소가 많은게 처음에는 가장 효율 적인 시간을 구해야 하는 지 알았다. 예를 들어 8, 3, 1, 7 무게 10 이렇게 있으면 8다음 3은 들어갈 수 없으니 뒤에 들어갈 수 있는 1을 찾아서 들어가서 시간을 단축내는 ? 이렇게 풀다보니 너무 어려워져서 다시금 그냥 주어진 순서만 지키면 된다는걸 알게 되었다. 해서 나온게 아래의 경우 while 조건에서 요구하는 sum과 다리위에 들어가기 위한 sum이 달라서 afterSum/beforeSum으로 나눴는데, 이걸 구하는 과정이 너무 반복이라 효율성에서 실패 하였다. 마지막 추가 되는 상황에서만 sum에 해당 요소를 더해주니 간신히 통과...! 

완주하지 못한 자 map 부분에서 가장 낮은 난이도에 있는 문제다. 입출력 예 participant completion return ["leo", "kiki", "eden"] ["eden", "kiki"] "leo" ["marina", "josipa", "nikola", "vinko", "filipa"] ["josipa", "filipa", "marina", "nikola"] "vinko" ["mislav", "stanko", "mislav", "ana"] ["stanko", "ana", "mislav"] "mislav" 배열 두개를 비교해서 단 하나의 차이점 데이터를 찾으라는 건데, 처음 드는 생각은 물론 이중 for문 이었다. 하지만 "1명 이상 100,000명 이하입니다." 라는 조건에 걸려 최대 100억번의 반복 비교를 해보는건 너무 비효율이라고 생각. 두번째로 든 생각은 현재 문제의 특수성, 참가자와 완주자는 무조건 한명의 차이점 외에 다른점은 없다. 그래서 두개의 배열을 정렬 시키고 다른 데이터가 있으면 그냥 그대로 반환 시켜 주기로 하였다.  for문을 한번만 사용하기 때문에 최대 10만번 이내에서 연산을 끝낼 수 있어서 그런지 일단 정확도와 효율성 둘다 테스트는 통과 했지만, 다른 답안지를 보고 아차 했던 것은 이건 hash(map)에 관련된 알고리즘 문제였다. 해시 맵에 참가자 데이터를 넣으며 getOrDefault 메소드를 통해 +1을 넣어주고 완주자 목록을 이용해서 -1을 ...

API 문서를 정리하면서.... 우리는 swagger나 restdocs 같은 자동화 api 문서툴을 사용하지 않기 때문에 구글 스프레드 시트에 직접 만들고 있다. 그나마도 정형화 되지않은 형식 + 대충 기입하는 req, res 때문에 조금 난항을 겪고있는데 .... 그걸 조금은 정리하려고 하다보니 사용자 지정함수나 기존 시트의 함수에 대해서 알게되고 좀 재미를 느끼고 있다. 엑셀도 결국 간단한 수식으로 보니까 메서드랑 다를게 없네 라는 생각. 전혀 개발적인 내용은 아니지만 오늘 새로이 알게돼서 재밌는 점.  1. http 메소드 put과 patch     put: 리소스를 전부 업데이트      patch: 리소스의 일부만 업데이트      즉 put 에서 일부 데이터만 보낸다면 보내지 않은 값에 대해서는 null이 입력되는 것과 같다. (실제로는 구현하기 나름이지만 이런 방향성을 가지고 구현하는 것이 좋다.)      put은 엔티티를 전송한다는 느낌으로 기존의 값이 없다면 생성도 된다. 2. 웹브라우저 주소 입력 후 이뤄지는 과정 주소창에 URL 입력  웹브라우저(chrome, IE ...)가 URL을 해석 한다.      scheme: // user:password@host[:port][/]path[?query][#fragment] 일반적으로 url형식에 맞지 않는다면 "검색"으로 형식에 맞는다면 HSTS 목록을 로드해서 확인한다. (https or http) DNS 조회해서 IP를 이용해 접속한다.  해당 웹서버는 요청받은 파일과 파라미터값을 이용해 결과를 웹브라우저에 다시 전달하고 웹브라우저는 결과를 해석해서 사용자에게 보여준다.  3. 객체 지향설계 (+ SOLID 원칙)     객체지향은 4대특성을 가진다.      캡슐화 -  데이터구조...

 - redis, memcached > nosql  - mongodb > nosql  Redis 와 Memcached 는 모두 nosql 중 key-value 형 데이터베이스로 빠른 속도가 장점인 데이터 베이스다. 메모리 데이터 저장소. 캐시 형태로 데이터를 사용한다.  Memcached 는 문자열의 데이터구조만 처리한다. 백업 불가능. 메모리 재사용 Redis 는 싱글쓰레드. 스프링의 세션 클러스터링. 메모리와 디스크. 속도차이를 감수 하고도 운영적 기능에 중점 mongodb는 도큐멘트 지향 데이터 베이스로 json 데이터 구조로 저장한다. 스키마가 없다.  물리디스크에 저장. - get post put delete > http , restful - restful, msa REpresentational State Transfer,  MSA(Micro Service Architecture) - 람다 vs for문 선호 하는거 >  람다는 자원소모가 크고, 일부 상황에 따라 처리 속도가 느리다. but 깔끔한 코드 스크립트 언어 기술이라 아직 자바에서는 조금 최적화가 덜 된편 - 자바 메모리관리에 대해 고민해본적잇는지 - garbage collection     아직 그렇게 큰 규모의 프로젝트는 진행하지 않아서 gc 믿고 한다. - java 1.8 특징, 자바 특징 Lambda Expression (람다표현식) Method Reference (메소드 참조) Stream (스트림)   Default Method  - interface의 모호함 제거 Optional - null처리  Joda Time - localdatetime - 자바 메모리영역   heap vs non-heap  - git (rebase, cherrypick) merge가 브랜치 자체를 합치는 거라면  rebase 는 깃트리 관리를 위...

URL shorteing  간단하게 입력할 수 있는 jsp 단과 프론트 검증 및 기능 작업까지 방금 막 끝냈다. 다 만들고 보니 가장 중요한 기능적인 부분은 처음 생각 그대로 만들었고, 결국 db에서 CRUD 하는 느낌이라 조금 허접해 보이긴 하지만 ... 또 생각보다 많은 작업이 프론트에서 이뤄졌다. 기본적으로 바뀐 key값을 http://localhost/ 뒤에 붙여서 사용하기 때문에 전용 입력창에 입력하거나 주소창에 입력했을 때 모두 작동하게 해야했다. 관련으로 기능을 붙이고 버튼 클릭 또는 엔터에도 기능을 넣었다. 이 때 주소창에 입력하면 리다이렉트 시키는 부분에서 꽤나 헤매었다. 이걸 구현하려다 보니 안쓴 지 한참되었던 modelAndView 까지 꺼냈는데 이게 컨트롤 부분을 프론트에 떠넘기는 느낌이라 요즘에는 잘 안쓴다고 들었는데 결국 이렇게 구현하는게 내 한계점이었다.  제이쿼리가 속도가 느리고 무겁다고 해서 최대한 자중 하려고 초반에는 일부러 document를 사용했는데 프론트를 전혀 모르는 나는 제이쿼리를 사용해서 코드를 작성하는 수 밖에 없었다... 그나마 거창한 기능들이 아니니까 속도적인 문제는 전혀 없는 듯 하다. url 정규식 부분에서 나는 정형화된 한가지 모양이 있을 줄 알았는데, 사람들마다 엄청 다른 모양새 였다. 그리고 요즘에는 인터넷 주소가 엄청나게 다양하다. bitly의 단축 주소만 보더라도 j.mp 이런식으로 기존 www 으로 시작하던 모양과는 천지차이고 주소에 한글이 들어가는 경우도 종종 볼 수 있다. 나는 중간점 정도로 타협하기로 해서 식에 .가 있는가? 한글이 있는가? 정도만 걸러내는 정규식을 사용했다.   기능 외적인 요소에서는 swagger를 처음 써봤는데 관련 컨트롤러만 잘 만들고 어노테이션을 달아주면 이미 만들어진 html에서 깔끔한 ui로 api문서를 확인할 수 있다. 기가 막히고 코가막히는 기능인데 우리회사의 기존 프로젝트에 적용하기에는 그 모든 controller api에 어...