nota's story

리눅스 서버 부팅시각 확인 방법 1. last 로그 확인

리눅스 서버 부팅시각 확인 방법 2. dmesg 로그 업데이트 시각 확인

이 외의 자세한 내용은 /var/log 밑에서 찾아보면...

현재 설정된 크론탭 조회

크론탭 추가/수정

자바(JAVA) 형 변환(String과 Date)

String to Date

Date to String

자바(JAVA) 형 변환(String과 int)

Strinig to int

int to String

역방향 DNS 조회 방법

(윈도우 사용시, cmd로 실행 창을 켜서 진행)

SPF 레코드 조회 방법

(윈도우 사용시, cmd로 실행 창을 켜서 진행)

완전 기초적인건데, 안 써버릇 하니깐 가끔 까먹기도 하는 MySQL 기본 명령문

1. SELECT

SELECT [컬럼명] FROM [테이블명] WHERE [조건]

ex) SELECT * FROM tbl_userinfo WEHRE height > 180 ;

ex) SELECT username FROM tbl_userinfo WHERE height < 180 ;

2. UPDATE

UPDATE [테이블] SET [컬럼]=[값] WHERE [조건]

ex) UPDATE tbl_userinfo SET height = 180 WHERE height > 179.5 ;

3. DELETE

DELETE FROM [테이블] WHERE [조건]

ex) DELETE FROM tbl_userinfo WHERE height < 100 ;

LoL에 관심을 갖게 된건 작년 초쯤부터였다. 요즘에도 간간히 심심할 때마다 즐겨하는데, LoL을 만든 라이엇게임즈는 정말 천재인가 하는 생각이 들 정도로 대단한 게임인 것 같다.

그래서 생각난 김에 LoL이 잘 만들었고, 잘 운영된다고 생각되는 이유를 적어봐야겠다. LoL을 해보지 않았더라도 이해할 수 있을만한 내용으로 최대한 뽑아서 적어본다.

1. 게임 자체의 밸런스

- 게임을 해봐야 알겠지만, 꾸준한 업데이트로 인해 밸런스가 잘 맞는다. 어떤 챔피언이 좋은거 같다고 생각되면 얼마 후에 너프(안 좋아짐) 된다.

2. 수준 맞춰주는 시스템

- 일반 게임이나 랭겜(랭크 게임)을 해보면, 상대와 우리팀의 수준이 정말 적절하다. 물론 가끔 트롤(게임을 실수로든 고의로든 망치는 사람)이 있긴 하지만, 계속 이기면 더 어려운 상태를 만나고, 계속 지면 더 쉬운 상대를 만나는 등 연승과 연패가 힘들도록 팀밸런스를 맞춰준다. 이는 정말 게임에서 핵심적인 요소로, 어떤 게임도 계속해서 이기거나 계속해서 졌을 때 재밌는 경우는 없다. LoL의 매칭 시스템은 이를 방지해준다. 심지어 세컨 아이디로 게임을 할 경우에도 어느 정도 밸런스가 맞는 경우가 많다.

3. 다양한 챔피언과 각종 스킨

- LoL에는 수많은 챔피언이 있고, 마침 어제도 쟈크라는 신규 챔피언이 나왔다. 챔피언들을 살펴보면 멋진 챔피언, 우락부락한 챔피언, 괴물 챔피언, 예쁜 여자 챔피언, 귀여운 챔피언 등등 정말 다양한 챔피언이 있다. 이는 특정 캐릭터에 끌리는 다양한 유저들을 전부 모을 수 있는 요소인 듯 하다. 그리고 여기에 더해서 각종 스킨(챔피언 생김새를 바꿔준다)은, 이 많은 챔피언에 다양성을 더해준다. 

4. 현질해도 게임에 영향은 ㄴㄴ

- 보통 게임들은 현질(돈을 써서 게임에서 아이템 등을 구입)을 하면 게임이 더욱 쉬워진다. 그러나 LoL의 경우에는 현질이 게임 한판한판 자체에 영향을 끼치는 경우는 거의 없다.(가끔 스킨에 따라서 좀 영향이 있을 경우는 있지만, 미미하다고 본다) 현질로는 더 다양한 챔피언을 구매할 수 있고, 스킨을 구매할 수 잇고, 그 외 각종 아이템을 구매할 수 있다. 이는 대부분 개인의 취향(?)에 맞는걸 구매하는거지, 게임에 긍정적 영향을 주는 경우는 많이 없다.

5. 악성유저 대응

- 이런 류의 게임의 고질적인 문제는 악성 유저이다. LoL은 악성유저를 대응하기 위해 여러가지 방법을 쓴다. 우선 게임에서 무단이탈하면 재접속해도 다시 그 게임으로 들어갈 수 밖에 없고(다른 방으로 못들어간다.), 그 게임이 끝난 후에 접속하면 5분 정도 게임을 못 하게 된다. 그래서 죽이되든 밥이되든 그 게임은 끝내는게 좋다. 그리고 게임을 고의적으로 망치거나 욕설을 하는 유저들을 신고하거나, 매너 좋은 유저를 칭찬하는 제도가 있다. 그리고 판정단이라고 하여 매너 좋은 유저들이 직접 신고 들어온 내역을 보고 판단하여 유저에게 패널티를 주는 제도이다. 이 외에도 게임 로딩 중간중간에 게임에서 매너를 지키는 것에 대한 팁을 주어, 악성유저를 은근히 막고 있다.

6. 쩌는 고객응대

- 가끔 페이스북 등에서, LoL에 불만을 접수했는데 선물이 택배로 왔다든지, Q&A게시판에 게임관리자가 되고싶다는 질문을 올렸는데 거기에 상세히 답변해줬다든지 하는 사연을 종종 본다. 내가 직접 질문을 하거나 접수를 해본적은 없지만, 고객응대가 쩐다는 말은 많이 들어왔다.

7. 들어올땐 맘대로 들어왔지만, 나갈땐 못나가

- 디테일한 거긴 하지만, LoL을 끊을 수 없는 작은 장치들이 몇 개 있다. 우선 계정을 삭제하면 바로 삭제되는게 아니고, 한 달 동안 접속을 하지 않아야만 계정이 삭제된다. 이를 꾹 참고 계정을 삭제하는 사람은 별로 없는 것 같다. 그리고 일반적인 인스톨 게임과 다르게, 언인스톨이 없다. 제어판 들어가서 직접 삭제해야함... 또한 LoL 창을 킨 상태에서 종료 버튼을 누르고, 엔터를 치면 '아니오' 버튼이 눌려서 다시 게임으로 돌아온다. 보통은 엔터를 치면 '예'가 눌리는데... ㄷㄷ

뭐 직접 게임을 해보면 다른 무엇보다도, 게임이 정말 재미있기 때문에 떴다고 생각이 들지만, 그래도 이런 디테일한 점들이 있기 때문에 LoL이 국민게임이 되고 잇는 것 같다.

4일차는 코딩 위주로 수업해서 생략

#
URL에 따라서 다른 서블릿을 호출하게 되면 서블릿을 여러개 만들어야 하니까,
DisPpatcher Servlet 하나만 사용하고
URL 자체를 명령어로 인식해서, cmd라는파라미터에 따라 액션을 다르게 한다.
어떤 URL이 어떤 명령어인지는 Handler Mapping이 알아서 해주고,
여기서 어떤 명령어인지를 판단하여 Controller를 부른다.
Controller에서는 직접 코딩하여 모델을 만드는게 아니고,
Controller에서는 의지하는 객체를 가지고 있는거...
의지하고 있는 객체는 모델이 되겠지?
이 모델은 또 구현클래스로 두지 말고,
인터페이스를 만들어 추상화하여 loose coupling을 한다.
=> 결합도가 낮아져서 다형성을 가진다.
이때 단순히 인터페이스만 가지고 있는다고 결합도가 낮아지는건 아니고,
팩토리 패턴을 생성하여 어떤 케이스에 따라 어떤 구현 클래스를 사용할지를 결정.

#
SPRING에서는 forward가 디폴트
forward는 url은 그대로 두고, 버퍼의 내용만 변경
다른 컨트롤러 쪽을 호출하기 위해서는 url이 변경돼야 하기 때문에 redirect를 사용
다시 정리해보자면,
action에서 바로 뷰를 보여줄 때는 forward로 가면 되는데
action에서 다른 action으로 가려면 redirect로 가야한다.

#
ORM, AOP, DI 등의 개념은 확실히 알아둡시다.

#
AOP(Aspect Oriented Programming)
관점 지향 프로그래밍. Aspect가 키워드!!!
OOP를 날려버리자 하고 나온게 AOP가 아님
(AOP가 도입된다고 OOP가 사라지는게 아님)

OOP의 장점은 재사용성(중복코드가 줄어듬)
OOP의 단점은 필요없는거까지 상속받는다.
OOP에서는 재사용하기 위해서는 주종관계로 묶여져야 한다는 단점이 있음.

AOP에서는 바라보는 관점에 따라서 핵심코드와 공통소스가 캡슐화되게 해서,
주종관계를 맺지 않고 재사용이 가능.
이때 관점이라는걸 정의하기 위해서 아키텍쳐가 필요.
핵심과 공통을 분리하기 위함이 AOP의 목적.
분리를 하게 되면 뭐가 뭔지 모르기 때문에 이 핵심코드와 공통소스 캡슐화 등을 알아서 해주는걸 각종 프레임웍에서 문법에 의해 해준다.

운전을 예로 들면, 운전을 하기 위해 차를 빼고 다시 주차하는게 공통소스
운전을 해서 여행을 가든 출퇴근을 하든 하는게 핵심코드
운전자가 원하는건 운전을 하는거지, 차를 빼고 주차하는게 아니다.
이 차를 빼고 주차하는걸 공통소스로 관리.

밥먹는걸 예로 들면, 밥을 먹기 위해 상을 차리고 다먹고나서 설거지를 하는게 공통소스
밥을 어떻게 잘 먹는게 핵심코드
식충이가 원하는건 밥을 먹는거지, 상을 차리고 설거지를 하는게 아니다.
이 상을 차리고 설거지를 하는걸 공통소스로 관리

*advice : what과 when이 결합된 것
공통관심 사항을 핵심로직에 언제 적용할 것인가를 정의

*joinpoint : where의 의미
공통관심사항을 적용할 수 있는 애플리케이션의 실행지점
advice를 적용하는 지점

*pointcut : advice가 실제로 적용되는 jointpoint

#
오늘 MVC Spring, DB적용
다음시간에 DI적용하여 어플만듬
그다음시간에 AOP 등 마무리

#
ORM은 Object Relation Mapping : 즉, 다른 프레임워크와 연동하는 것.

#
Spring MVC
Model : 모델 자체가 컴퍼넌트, 컴퍼넌트 자체가 자바로 코딩한 비즈니스 로직.
View
Controller
모델과 뷰를 구분하고자 하는 형식이 MVC
여기서 모델이 주코드와 부코드로 나뉘게 됨.

#
<Spring MVC의 큰 흐름>

1.
Client에서 Dispatcher Servlet으로 가는건, web.xml에서 설정
(.do일때 이 서블릿으로 가라는걸 설정.)
서블릿은 요청을 처리해주고, 전체 관리하는 역할을 함.
Dispatcher 서블릿은 Spring에서 제시하는 서블릿.

2.
이때 .do로 통일하면 하나의 서블릿이기 때문에, 어떤 서비스를 해야할지 단서를 붙여서 호출해야 하는데
이걸 해주는게 Handler Mapping(기존 MVC에서는 'list.do?cmd=login' 이런식으로 처리했음)

3.
Dispatcher 서블릿에서 이 호출이 어떤 요청인지 Handler Mapping을 통해서 판단
(커맨드와 비즈니스 로직을 맵핑)

4.
 Controller는 기존MVC의 Action과 같은 역할.
컨트롤러에서 비즈니스 로직 등을 구현.
DI를 적용시켜서 로직, DB 등과 관련된걸 불러오고 처리.

5.
ActionForward를 통해서 ModelAndView를 설정하여 Dispatcher Servlet으로 넘김

6.
Dispatcher Servlet에서 ViewResolver를 불러서 어떤 뷰를 불러올지 결정

#
211.63.89.30

#
샘플로 만든 MVC프로젝트에서,
jsp에서 .do?cmd=login url 이동
=> web.xml에서 읽고 Action Servlet으로 가서 service 메서드 호출
=> ActionServlet에서 cmd를 받아서, getAction 호출
=> Action Factory의 getAction에서 cmd 값에 따라서 어떤 모델을 부를건지 결정
=> 이 받은 action을 가지고 action.execute 실행
=> execute를 ActionForWard가 받아서, true면 sendRedirect// false면 requestDispatcher 호출

#
객체를 속성과 기능과 함께 인스턴스화 할 때(OOP) 한계가 있다
그래서 객체를 만들어서 서로 협업(조립)시킨다 => Framework

설계도(클래스, 객체)를 만드는 이유 : 재사용성을 위함

Spring에서의 협업 : Extend가 아니라, POJO(평범한 자바)로 가지고 있는(haser) 개념으로 가고, 이를 이용해 협업한다. 이때 코드를 분리하고 조립(factory)하게 된다.

메인부에서 객체를 선언하고, 어떤걸 만들지 조립하고, 호출하는게 일반적인 개발의 흐름
근데 이렇게 하면 개발자가 공식대로 다 만들고, 일정한 패턴으로 코딩해야함
프레임워크에서는 IOC 컨테이너를 서비스해서, 얘네 문법만 익히면 기본적인 패턴이나 문법이 적용된 상태로 코드를 분리할 수 있고 조립할 수 있다

Spring 모듈중에 Core가 있고, 그 안에 DI가 있음. 이는 협업하는 객체를 wiring해줌. => 코드의 분리 + 확장성 향상

문법에서 set은 집어넣고, get은 반환하는 건데..
@Required를 하면 반드시 DI를 하도록 한다.
@Autowired를 하면 자동으로 묶어준다.(DI해준다)

xml을 보면 bean으로 객체를 만들고, property를 만듬.
예시에서 person이 book을 가지고 있다.
book이 1개뿐이면 person과 book이 같은 타입이니까 잘 가져오게 되는데(book을 person에 DI시키는데),
book이 2개라면 타입이 겹치니까 이름으로 가져올 수밖에 없음. => annotation으로 해결 가능

setBook에 @Requried만 쓰면 에러가 남(DI를 안 해놨으니까)
거기에 @Autowired를 추가하면 에러가 사라짐(하나하나 bytype으로 DI가 되니까)
참고로, 바로 bean에 접근하는 resource 개념이 있음
그리고 bean에 안 만들어줘도 다른 annotaion을 이용해서 가능하도록 할 수 있다.

내가 primitive 자료형(기본자료형) 혹은 레퍼런스 자료형(오픈 api)를 가지고 있을 수 있는데,
이를 DI시켜서 루즈 커플링해서 사용하는게 spring framework의 핵심

spring에서는, xml뿐만 아니라 java 소스만으로 DI를 시켜줄 수 있도록 제공한다(@bean).
기존의 방식인 xml로 DI시키는 것도 있고, java 소스로 DI시키는 것도 있고 함께 사용할 수 있음.

#
@Qualifier를 사용하면 값을 넣을 수 있음
setBook 메서드 위에다가 쓰면 객체가 하나라면 괜찮은데 여러개일 경우 여러개에 모두 한 value만 들어가게 되니까, 파라미터에다가 하나씩 붙여주면 값을 넣을 순 있음.

# MVC
- 웹은 전부 MVC로 되어있음(Spring, 전자정보 등등)
- 모델과 뷰를 분리함

# Spring MVC
- Client가 Dispatcher Servlet을 호출(요청을 위해)
=> 이때 Spring에서는 url 전체를 command로 본다.
- 서블릿이 호출되면 Handler Mapping이 불러와짐(키, 밸류 형태로 어떤 액션을 할지 맵핑)
- 핸들러맵핑이 확인해서 관련된 컨트롤러를 불러옴
- 컨트롤러가 ModelAndView를 디스패쳐 서블릿에 넘겨줌
- 확인해서 ViewResolver를 불렀다가 View를 볼러옴