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 는 깃트리 관리를 위해서 Rebase는 기존의 커밋을 그대로 사용하는 것이 아니라 내용은 같지만 다른 커밋을 새로 만듭니다. cherrypick은 특정 커밋한
URL shorteing 간단하게 입력할 수 있는 jsp 단과 프론트 검증 및 기능 작업까지 방금 막 끝냈다. 다 만들고 보니 가장 중요한 기능적인 부분은 처음 생각 그대로 만들었고, 결국 db에서 CRUD 하는 느낌이라 조금 허접해 보이긴 하지만 ... 또 생각보다 많은 작업이 프론트에서 이뤄졌다. 기본적으로 바뀐 key값을 http://localhost/ 뒤에 붙여서 사용하기 때문에 전용 입력창에 입력하거나 주소창에 입력했을 때 모두 작동하게 해야했다. 관련으로 기능을 붙이고 버튼 클릭 또는 엔터에도 기능을 넣었다. 이 때 주소창에 입력하면 리다이렉트 시키는 부분에서 꽤나 헤매었다. 이걸 구현하려다 보니 안쓴 지 한참되었던 modelAndView 까지 꺼냈는데 이게 컨트롤 부분을 프론트에 떠넘기는 느낌이라 요즘에는 잘 안쓴다고 들었는데 결국 이렇게 구현하는게 내 한계점이었다. 제이쿼리가 속도가 느리고 무겁다고 해서 최대한 자중 하려고 초반에는 일부러 document를 사용했는데 프론트를 전혀 모르는 나는 제이쿼리를 사용해서 코드를 작성하는 수 밖에 없었다... 그나마 거창한 기능들이 아니니까 속도적인 문제는 전혀 없는 듯 하다. url 정규식 부분에서 나는 정형화된 한가지 모양이 있을 줄 알았는데, 사람들마다 엄청 다른 모양새 였다. 그리고 요즘에는 인터넷 주소가 엄청나게 다양하다. bitly의 단축 주소만 보더라도 j.mp 이런식으로 기존 www 으로 시작하던 모양과는 천지차이고 주소에 한글이 들어가는 경우도 종종 볼 수 있다. 나는 중간점 정도로 타협하기로 해서 식에 .가 있는가? 한글이 있는가? 정도만 걸러내는 정규식을 사용했다. 기능 외적인 요소에서는 swagger를 처음 써봤는데 관련 컨트롤러만 잘 만들고 어노테이션을 달아주면 이미 만들어진 html에서 깔끔한 ui로 api문서를 확인할 수 있다. 기가 막히고 코가막히는 기능인데 우리회사의 기존 프로젝트에 적용하기에는 그 모든 controller api에 어노테이션을 달아주기가 어려울거 같아
URL Shortening URL을 입력받아 짧게 줄여주고, Shortening된 URL을 입력하면 원래 URL로 리다이렉트하는 URL Shortening Service 문제를 딱 봤을 때 약간혼란스러움을 느꼈다. 쉬운건가? 어려운건가? 최근에 적용시킨 서비스중에 url shortening api를 쓴적 있지만 그건 bitly의 이미 구현된 api를 가져다 쓴거라 bitly를 직접 만들라는 이경우와는 조금 다른 케이스 였다. 최근 만든 작업은 https://abc.com?key=77 이라는 우리 사이트가 있다고 가정하자 이 때 77은 회원이 접수한 건에 주어지는 고유한 일련번호이고 이게 노출되면 보안적으로 위험한 상황이었다. 그래서 이숫자를 먼저 해쉬로 암호화 해서 숨겨주었다. https://abc.com?key=77 => https://abc.com?key=qwkmcx0+1dmxa1dsdsd 이걸 기존의 단축 api 를 가져다가 써서 짧게 만들어서 고객에게 보내주려고 했다. 처음에는 네이버의 me2.do 를 쓰려 했는데 이게 bitly 보다 무료로 단축할 수 있는 갯수도 압도적으로 많고 단축된 모양도 깔끔할거 같아 선택했었다. 하지만 ... 네이버는 +와 같은 특수문자를 api에 태우는 순간 무조건 변환시켜버린다. %~로 바꿔버리고 이건 내가 의도한 바가 아니었기 때문에 bitly api를 사용하기로 했다. https://abc.com?key=qwkmcx0+1dmxa1dsdsd => https://bitly.com/demx6xqpa 그런데 j.mp 또한 bitly가 구매한 주소라고 한다. 이왕이면 더 줄여보자 라는생각에 이걸 한번 더 줄였다. https://bitly.com/ demx6xqpa => h ttps://j.mp/ demx6xqpa 최종적으로 위와 같은 주소를 받은 고객이 여기로 접속하면 bitly가 원래 주소를 반환해주고 난 해당 주소를 받으면 뒤
인텔리 제이가 좋다라는건 처음 자바를 배울 때부터 들었지만 그간 금액적인 부분때문에 이클립스만 쭈욱 써왔었다. 이클립스를 계속 쓰면서도 새로운 기능도 발견하고 새로운 단축키를 발견하면서 만족하고 신기해하면서 사용했는데, 이제 회사에서 지원도 해주겠다 + 툴 통합하자 라는 계획으로 인해 인텔리 제이를 처음 접하고 있다. 지금 막 접하고 난 느낌은 일단 1. 처음에 설정 해야만 하는 것이 이클립스보다 적다. - 이클립스는 익숙해져서 그렇지 처음에 설정해야하는게 진짜 많다. 인텔리제이도 물론 헤매긴 했지만 옆에서 선배가 도와주는걸 보니 이클립스에 비해는 적은 느낌 2. 위치자유도가 이클립스보다 덜하다. - 이클립스는 로그창을 떼서 위에 붙이든 옆에 붙이든 심지어 따로 보든 상관이 없다. 다른창도 마찬가지 근데 이런 자유도 면에서 인텔리제이가 고정돼 있는 창이 많아서 오히려 신기했다. 3. 각진 UI 느낌 - 이클립스가 둥글둥글한 느낌이라면 대체적으로 각진 느낌을 준다. 아직은 어색한 부분 마지막으로 단축키가 너무나도 다르다 ..... 이클립스에서 많이 썼던 단축키중 ctrl + H 는 검색인데 ctrl + shift + F 로 대체해서 쓴다. 그런데 모든 내용이 휙휙 나오는 느낌이 아니라 약간 다르다. ctrl + shift + R 이었던 파일 찾기는 ctrl + shift + N 으로 대체 이건 빈화면에서도 항상 나와있고 기능적으로 같아서 금방 익숙해 질거같다. 많이 썼던 한줄복사는 아직 모르겠고 줄바꿈도 조금 어렵다. 한줄 삭제는 대부분 검색하면 ctrl + y 로 나오는데 이건 redo 란 말이죠. 그래서 해보니 shift + Delete 로 같은 기능을 사용할 수 있다. 자동완성도 너무 다르다.... 나는 ctrl + space 누르는게 일상인 사람인데 특히 아직까지 찾지못한 향상된 for문의 자동완성... 이클립스에서는 for를 치고 자동완성의 4번째에 있었다. 근데 인텔리제이는 뭔가 다른모양으로 나와서 저걸 쓰는건
언뜻 듣기로 update문은 delete을 사용하는것보다 더 위험하기 때문에 사용을 지양해야 한다는 이야기를 본적이 있다. 근데 만들어 놓은 기능을 어떻게 안쓰고만 있겠나. 이걸 이리 저리 사용하는데 좀 새로이 알게된 정보들이 존재한다. 워크벤치에서 다수의 데이터가 나오게끔 update나 delete를 하면(unique값이 아닌 키값으로) safe_mode에 걸려서 에러가 뜬다. 그래서 이걸 각각 유니크 값으로 기능하게 하고 이걸 한 api 안에서 리스트로 돌려서 하는 식이 있다고 하는데, 사실 이렇게 사용안해도 자바에서는 그냥 되는경우가 있더라. 이번에 그룹원 수정_삭제 쪽을 이렇게 구현했는데, 만들고 나서 까먹고 있다가 이걸 프로시저를 사용해야 하나... 어째야하나 고민을 했는데 그냥 아무일도 없이 되고 있더라. 업데이트문 안에서 해당 테이블의 데이터를 다시 이용해서 키값을 넣을때가 있다. 이번에 날짜와 금액을 변경하는 update문을 짰었는데, 대충 아래와 같은 모양이었다. 이 때 내가 노린것은 아래의 date는 기존 tb_test 테이블의 date 값이었는데 위에서 바뀐다음에 date가 들어간 것이었다. 전체문장이 한번에 바뀌는게 아니라 위에서부터 순차대로 바뀌는 그런 순서를 가진듯 하여 3번 문장과 4번 문장의 순서를 바꿔주자 내가 의도한대로 작동하는걸 확인할 수 있었다. 지금 정산관리 쪽을 살펴보며 평소에 오류가 나면 직접 db데이터를 바꿔서 해결했던 아주 나쁜 문제들을 보고 고쳐나가고 앞으로의 해결책을 만들어야 하는데 이과정에서 update를 자주 쓰게 될것 같다. (지금 추가로 만들어 달라는 기능중에 관리자 페이지에서 데이터를 변경하게 해달라는 기능이 많다....)