오늘 알게된것

데이터베이스에서 사용되고 있는 테이블에 대하여 컬럼을 추가 또는 수정 될 때가 있다. 이게 기존 회사에서는 큰 작업 사항으로 여겨지지 않았는데 이번에 바뀐 환경에서는 해당 작업을 굉장히 신중하게 진행 하기에 해당 부분을 찾아보았다. invalid Object? Object에는 프로시저, 함수, 트리거 등등이 포함된다. 테이블 컬럼의 변경으로 해당 작업들의 컴파일이 해제된 상태가 되고 진행되지 못한다. 작업 자체가 이루어 지지 않는 상황이라는 것을 알았다. 구글링해서 얻은 정보로는 일반적인 상황에서 쿼리를 통해 invalid 상태인 오브젝트 들을 검색하고 해당 작업을 재 컴파일 해주면 된다고 한다.  현재 우리 회사에서 사용하고 있는 SQL gate 기준으로는 도구>개체 재컴파일 에서 유효하지 않은(invalid) 상태인 개체를 검색하고 해당 작업이 무엇인지 살펴봐야 한다. 왜 오라클만?  구글에 "오라클 invalid object" 이라고 검색하면 관련된 결과가 여러가지 나오지만, "mysql invalid object" 이라고 검색하면 관련해서 나오지 않는다. 여기에 대해서는 조금 더 찾아봐야 할듯 ... 왜 이전 회사에서는 큰 이슈가 아니었을까? 오라클 요금제의 차이라고 하는데 오라클 공식에서도 관련해서 상세히 설명된 부분이 없다. 일단 현재 시스템 내에서는 아래 일련의 과정을 거쳐서 테이블 컬럼을 추가한다. 개발 DB 에서 바꾸고자 하는 테이블의 컬럼을 추가한다.  도구 > 개체 재컴파일에서 유효하지 않은 상태 개체 검색 해당 개체들이 운영 상 치명적인(회원, 주문, 결제 관련) 로직 이거나 재컴파일 시 시간이 과하게 오래 걸리는 부분이면 컴파일 이전 시간 진행  유효하지 않은 개체가 검출되지 않거나 해당 개체들이 치명적이지 않은 경우 서비스 운영 시간에 반영 가능  이런 식으로 진행한다. 

실용주의 프로그래머(20주년 기념판)  데이비드 토머스•앤드류 헌트 2장 - 실용주의 접근법 (~Topic 9)

실용주의 프로그래머(20주년 기념판)  데이비드 토머스•앤드류 헌트 유명한 책이라고 계속 들어온 몇몇 책이 있다. 이펙티브자바, 클린코드 그리고 실용주의 프로그래머, 이 중 실용주의 프로그래머가 정말 공통적으로 도움이 될만하다고 추천받아서 이를 간단히 정리 해보고자 한다. 처음 읽는 만큼 간단히 읽고 넘어가는 부분도 많고, 주관적인 의견이 들어간 정리일 수도 있는 정리이다 (그 앞에는 "개인적인 생각으로는"이 들어가게 적는다.) 1장 - 실용주의 철학

시작 당시 사용하려 했던 기술을 사용해서 웹게임을 구현했고, 3일간 싱글게임 약 400회 멀티게임 약 250회가 플레이 되었다. 애시당초 구현하려던 충돌 멀티엔진은 실패 했지만 문서화나 사람들의 플레이 후기가 썩 괜찮았던 만족스러운 프로젝트 시작 때 사용하려 했던 기술들에 대해 다시 한번 짚으려고 한다.  webSocket 과 STOMP  컨트롤러에서 어노테이션으로 간단하게 연결가능 했으며 sub한 유저들에게 pub 해준다 라는 다소 난해한 설명과 달리 http 요청과 흡사하게 사용할 수 있었던 것 같다. 해당 기능으로 다른 유저의 방 접속 여부, ready 여부, 움직임 등을 공유해서 멀티 플레잉을 구현했으며 채팅과 달리 키입력을 모두 주고 받았음에도 동시에 5명 정도는 매우 매끄럽게 통신이 가능했다. 물론 규모가 커지면 내부 simplebroker를 외부 브로커로 적용 시키고, 서버를 따로 두는 등의 노력을 해야한다.  + 소켓이 연결 및 해제될 때 중간 중간 잡아주는 ChannelInterceptor 가 있는데, 해당 부분에서 메세징 보내는걸 몇번이나 실패했다.  gradle  시작할 때 건들고 이후 몇번 implementation 을 추가한 것 이외에는 별로 접해보지 않았다. 빌드 속도나 편리성에서 사실 maven 보다 월등한 점은 모르겠다. 다만 eclipse 기준으로 import 해오는 방식이 굉장히 복잡하고 문제가 발생할 여지가 많은 것 같은 기분, 이름이 겹치기만 해도 프로젝트를 자바프로젝트로 인식 하지 못하는 문제가 존재한다. 이번에 이를 겪으며 트러블 슈팅한 경험은 다행. 이클립스에서 import할 때 여기 이름이 일치하는지도 살펴보자 Redis Redis repository 로 JPA 와 비슷하게 사용하였다.  save()를 이용하여 저장할 경우 데이터가 hash로 저장되며 이때의 key는 "Object:id" 의 형태가 된다. 우리의 경우 Access 라는 객체에 sessionId를 @id로 저장했기 때문에 "a

프로젝트에서 적어도 안 써본 기술 하나는 써보자 라는 다짐하에 2학기 3번째 프로젝트, 자율 프로젝트가 시작되었다. 이번에는 유행했던 점프킹과 같은 장애물을 피해 올라가는 게임을 구현하려고 하는데 이걸 멀티접속이 가능하게 하려고 한다. 당연히 웹소켓이 필요하고 지금 껏 룸을 나누지 않고 단순 웹소켓만 사용해본 나로써는 새로운 도전이라고 할 수 있다. socket 과 websocket 일반적으로 socket 이라고 하면 tcp/ip socket을 의미한다. 그래서 이론적으로 가장 큰 차이점은 websocket은 http 레이어에서 작동하는 소켓으로 레이어가 다르다 라고 볼 수 있다.  기본적으로 http는 요청 후 응답을 보내는 단방향 통신인데 이걸 socket 처럼 쓰고 싶어서 만들어진 기술이라고 한다. 나같은 웹개발자는 그냥 이걸 쓰는게 맞는거 같고, 다만 브라우저 별로 못 쓰는 상황이 나와서 socket.io나 socketJS 같은 기술을 사용해서 이를 보완한다. STOMP  simple text oriented messaging protocol의 약자이며, 텍스트 기반의 프로토콜이다. websocket은 연결된 socket에게 data처리를 직접 다하는 반면, stomp는 subscriber, sender, broker를 따로 두어 처리를 하게 된다. subscriber(receive socket) : 채팅방에 입장하여 해당 채팅창을 구독, 즉 참여하고 있는 채팅창에 오는 메시지를 실시간으로 받아볼 수 있으려면 먼저 구독이 되어있어야 한다. sender(send socket) : 참여하고 있는 채팅창에 글을 써서 해당하는 주소로 메시지를 전달한다. broker : 연결된 socket들의 세션 관리를 해준다. 즉 subscriber를 구독한 채널에 연결시켜주고, sender가 그 채널에 메시지를 보내면 subscriber에게 전달해주는 중간 다리 역할을 한다. ChatController 에서 @MessageMapping("") @Send

OAuth 인터넷 사용자들이 비밀번호를 제공하지 않고 다른 웹사이트 상의 자신들의 정보에 대해 웹사이트나 애플리케이션의 접근 권한을 부여할 수 있는 공통적인 수단으로서 사용되는, 접근 위임을 위한 개방형 표준 쉽게 말해서 카카오, 네이버, 구글 등의 아이디로 나의 서비스를 이용할 수 있게 하는 서비스인데 이는 편리함을 위해 만들었다.  상기 서비스의 계정정보가 처음 보는 서비스에 넘어가지 않을까 하는 우려도 있지만 이는 꽤 복잡한 과정을 통해서 보호되어 전달된다. 비밀번호입력으로는 안전하지 않으니 액세스 토큰을 발급 하여 해당 계정의 정보를 사용하게 하는데 일단 용어를 정리하고 가야한다. OAuth 에서는 용어를 아래와 같이 정의한다. client  -  개발자의 서버  resource owner - 사용자  resource server - 계정 정보 서버 (구글, 네이버, 카카오 등) authorize server - 계정 인증을 위한 서버  클라이언트는 resource server 에 사전 등록을 해야한다.  client ID, client secret, authorized redirect URIs 데이터가 일반적으로 필요하고 서비스에 따라 요구하는게 조금씩은 다르다고 한다. resuorce owner 가 server 로그인을 하면 해당 범위에 대한 확인이 다시 들어오면서 client 가 해당 범위에 토큰을 부여받는 형식으로 먼저 client id와 함께 넘어간다. 이후 authorization code 를 resource server가 resource owner 에게 전송되고  owner는 이것을 client에게 넘긴다. (이는 물론 사용자는 모르는 빠른 시간내로 이루어진다.) client는 이제 code와 client sercet을 resource server에 넘기고 이로서 최종적으로 token을 발급 받게 되는것이다.  이 token안에는 해당 사용자에 대한 고유 번호와 허용 범위가 담겨 있고 이를 통해 우리는 회원을 식별할 수 있을뿐만 아니라 해당