개발은 전투다

Spring 에서 restful 하게 작성하기 위해 @Controller 내에 @ResponseBody 사용하거나 혹은 @RestController 을 사용할 수 있습니다.

스프링 MVC 프레임 워크와 REST

일반적인 Spring MVC 컨트롤러와 RESTful 웹 서비스 컨트롤러의 주요 차이점은 HTTP 응답 바디가 생성되는 방식이다. 일반적인 MVC 컨트롤러는 View 기술을 사용하지만, RESTful 웹 서비스 컨트롤러는 객체를 반환하기 만하면(!) 객체 데이터는 JSON / XML 형식의 HTTP 응답에 직접 작성되게 됩니다.

▲ 일반적인 Spring MVC 흐름

@ResponseBody 와 @RestController 두가지 차이점을 알아보기 전에 우선 스프링에서 REST하게 데이터가 송수신 되는 과정은 다음과 같다.

1. 클라이언트에서 웹서비스에 요청을 보냄.
2. Handler Mapping과 그 타입을 찾는 Dispatcher Servlet에 의해 요청이 가로채짐.
3. 요청은 Controller에 의해 처리되고 응답은 Dispatcher Servlet으로 반환되고 Dispatcher Servlet은 다시 View로 보내게 됩니다.

@RestController

Spring 4.0은 @Controller와 @ResponseBody 을 합쳐놓은것 이상의 역할을 수행하는@RestController를 추가했습니다. 컨트롤러 클래스에 @RestController 어노테이션을 작성함으로써 더 이상 @ResponseBody를 모든 요청 매핑 메소드에 추가 할 필요가 없습니다. @ResponseBody 어노테이션은 이제 기본으로 작동..!

결론

스프링을 restful하게 만들 때, 앞으로는 스프링 4.0 부터 추가된 @RestController을 활용하므로써 기존의 @ResponseBody in @Controller 방식을 벗어나 좀 더 쉽게 restful한 코드를 작성할 수 있습니다.

출처: http://highcode.tistory.com/24 [HighCode]

* Ajax 란?

 - 비동기 JavaScript 와 XML 을 말한다. 간단히 말하면, 서버측 Scripts 와 통신하기 위한 XMLHttpRequest 객체를 사용하는 것을 말한다

서버측으로 다양한 형식(JSON, XML, HTML 및 일반 텍스트 형식들)의 정보를 주고 받을 수 있다. 

비동기성을 통해 페이지 전체를 리프레쉬 하지 않고 사용자의 Event가 있으면 전체 페이지가 아닌 일부분만을 업데이트 할 수 있다.

서버로부터 받은 데이터로 작업을 한다

* Asynchronous JavaScript And Xml

1) 기존 방식의 사이트

 - 웹 어플리케이션의 기존 구현 방식의 특징

 - 웹브라우저가 웹 서버에 요청을 전송한다

 - 웹서버는 JSP/PHP/ASP 등의 서버측 어플리케이션을 사용해서 사용자의 요청을 처리한 뒤, 처리 결과를 HTML로 생성해서 웹 브라우저에 전송한다.

 - 웹 브라우저는 응답으로 받은 HTML을 분석한 뒤 그 내용을 화면에 그려준다.

 - 웹 브라우저가 웹 서버와 통신을 하고, 요청 결과는 HTML로 생성되고, 사용자의 입장에서는 페이지 이동이 발생하게 된다.

2) Ajax 방식의 사이트

 - 제시어 기능이 있다. 이는 '사용자에게 즉각적인 반응과 풍부한 UI 경험을 제공'한다는 것이다.

 - Ajax 는 ActiveX 와 같이 특정한 웹 브라우저에서만 제공하는 기능에 의존하지 않는다. 어떤 브라우저를 사용하든지 상관없이 웹 어플리케이션을 사용할 수 있게 된다.

3) Ajax 의 주요 구성요소

 - XMLHttpRequest : 웹 서버와 통신을 담당한다. 사용자의 요청을 웹 서버에 전송하고, 웹 서버로부터 받은 결과를 웹 브라우저에 전달한다.

 - DOM : 문서의 구조를 나타낸다. 폼 등의 정보나 화면 구성을 조작할 때 사용한다.

 - CSS : 글자색, 배경색, 위치, 투명도 등 UI 와 관련된 부분을 담당한다.

 - JavaScript : 사용자가 마우스를 드래그하거나 버튼을 클릭하면, XMLHttpReqeust 객체를 사용해서 웹 서버에 요청을 전송한다. 

또한, XMLHttpRequest 객체로부터 응답이 오면 DOM, CSS 등을 사용해서 화면을 조작한다.

4) 이벤트 발생 과정

 - 사용자가 이벤트를 발생시키면 JavaScript는 DOM을 사용해서 필요한 정보를 구한 뒤, XMLHttpRequest 객체를 통해서 웹 서버에 요청을 전달한다.

 - 웹 서버는 XMLHttpRequest로부터의 요청을 알맞게 처리한 뒤, 그 결과를 XML 이나 단순 텍스트로 생성해서 XMLHttpRequest 에 전송한다.

 - 서버로부터 응답이 도착하면 XMLHttpRequest 객체는 JavaScript에 도착 사실을 알리게 되고, JavaScript는 응답 데이터와 DOM을 조작해서 사용자 화면에 반영한다

5) Ajax 가 기존과 다른 차이점

 - 웹 브라우저가 아닌 XMLHttpRequest 객체가 웹 서버와 통신한다.

 - 웹 서버의 응답 결과가 HTML이 아닌 XML 또는 단순 text이다

 - 페이지 이동 없이 결과가 화면에 반영된다.

* 서버로의 비동기 통신 기술과 동적 클라이언트 스크립팅 기법을 하나로 묶은 것.

* 웹 브라우저가 직접 웹 서버와 통신하며 데이터를 주고 받는 것과 다르게 자바스크립트가 DOM을 이용해서 XMLHttpRequest 객체를 통해서 웹 서버에게 요청을 전달한다. 웹 서버는 요청을 처리하고 그 결과를 XML 이나 text로 생성해서 다시 XMLHttpRequest에게 넘긴다.그리고 그 결과는 다시 자바스크립트가 받아서 DOM을 이용해 조작해서 화면에 반응한다.

출처: http://smiler.tistory.com/entry/Ajax란?category=615519 [아직은 내가 쓴 글보다 퍼온 글이 훨씬 많음]

1. 구글 검색의 원리에 관하여

- 이 웹페이지는 키워드를 몇번 반복해서 포함하는가
- 이 단어가 제목, URL에 포함되어 있는가, 직접 연결되어 있는가
- 페이지에 키워드의 동의어가 포함되어 있는가
- 웹사이트의 품질이 어떤가
- 웹페이지의 Page Rank(페이지 랭크)는 어떠한가

2. 구글 검색엔진 최적화에 관하여

- 경쟁력있고, 유용하며, 독창성있는 컨텐츠는 모든 것을 압도한다. 사용자는 이를 보고 자연스럽게 입소문을 낼 것이다.
- 읽기 편안한 내용과 구성. 직관성을 고려해야 한다. 이미지만 그대로 넣는 형태는 검색엔진이 인식하지 못한다.
- 주제에서 벗어나지 않는 논리적 구성, 계층적 연결 및 정보 제공 중심의 글이 필요하다.
- 검색엔진의 키워드용이 아닌 사용자를 위한 컨텐츠를 만들어라, 검색엔진만을 위한 컨텐츠는 '웹스팸'으로 간주한다.

3. 앵커 텍스트에 관하여

- 크롤링하는 검색 로봇이 편한 검색을 할 수 있도록 앵커 텍스트(링크)를 사용해라

- a href 로 연결되는 링크 컨텐츠에는 그에 적절한 내용으로 설명하라
- 내용을 함축하라. 짧지만 명확해야 한다.
- 링크는 사용자가 쉽게 인지할 수 있도록 설정해야 하고 주소는 짧을수록 좋다.
- 구글 크롤러는 링크가 많은 글을 좋아하며 특정 글에 링크가 많은 글을 높게 평가한다.
- 내부 컨텐츠 링크에도 적극 활용하라. 로봇을 링크를 타고 여행을 한다.

4. 최적화 이미지에 관하여

- 본문에 사용되는 사진 및 이미지는 양질의 최적화 이미지를 사용하는 것이 좋다.

- alt 속성을 사용하면, 엑스박스가 뜰때도 사용자가 내용을 이해하기 쉬우며 검색 로봇도 하나의 단어로 생각한다.
- 이미지를 특정 디렉토리에 몰아넣으면 URL을 간소화되어 검색 로봇이 좋아한다.
- 파일 제목 역시 이미지를 설명하는 제목으로 설정해라. 단순 일련번호나 관계없는 단어를 쓰는 경우 무시된다.
- 파일 제목, alt 속성은 모두 설명적이되 간결해야 하며 이미지(사진)만 넣지말고 반드시 이미지 제목을 부기하면 좋다.
- 이미지를 사이트맵으로 제공하면 검색엔진이 당신의 페이지를 더 잘 이해할 수 있다.
- 사진은 직접 찍은 사진정보가 있는 것을 사용하며 이미지 앨범이 아닌 경우 최대폭에 알맞는 크기를 사용해라.
- 한 카테고리 내에서 사용되는 이미지는 가능한 규격이 통일된 크기를 사용하는 것이 좋다.

5. 포스팅 최적화에 관하여

- 블로그에 올려지는 모든 글은 본인의 노력으로 얼마든지 좋은 글이 될 수 있다.

- 글과 이미지는 조합이 요구되며 글-그림-글-그림-글-동영상-글-지도 등의 배열과 3~7줄의 글편성을 참고하라.
- <h1>~<h6>으로 구성되는 제목 태그는 직관성을 높여진다.
- 긴 글이라면 제목을 붙여가며 글의 내용을 분류하여 체계적, 계층적인 글의 구성이 논리적이고 양질의 글로 판정된다.
- 검색용 키워드 중심이 아닌 그리고 쓰는 사람 중심이 아닌 읽는 사람 중심의 정보를 중시한다.
- 주요 키워드는 앞쪽에서 강조하고, 키워드는 10개 이내를 사용하고, 동일 단어는 2~3회까지만 강조한다.
- 본문에 포스팅 되는 글은 직관성, 가독성, 접근성, 연관성을 중시고 글꼴, 크기, 색 등을 변화하며 꾸며야 한다.
- 구글 크롤러에 의한 검색 우선 순위는 충분한 긴 글, 인용이 많은 글, 독창성과 정보성이 인정된 글을 상위 등재 시킨다.
- 포스팅 된 글은 가능한 수정하지 않되 수정 된 글을 검색엔진이 다시 검색할 때 구글은 포스팅 내용의 수정을 중시한다.
- 구글봇은 오래된 블로그, 글 수가 많은 블로그, 자주 포스팅되는 블로그의 글을 상위로 등재시킨다.

출처: http://smiler.tistory.com/entry/구글봇-검색에-검색-잘되는-방법 [아직은 내가 쓴 글보다 퍼온 글이 훨씬 많음]

◼︎ 슬랙의 장점

1. 파일공유 

메신저로 협업 커뮤니케이션 시 가장 어려운점은 메신저에서 공유한 파일을 다시 찾는 것. 

이 부분을 쉽게 해결해 준 점이 슬랙의 가장 큰 장점이다. 

파일을 쉽게 공유하고, 그 파일에 대한 커뮤니케이션도 별도로 가능하게 했다.

2. 기존에 사용 중인 서비스의 알림 통합

메신저 뿐이었다면 이렇게 전 세계적인 열풍이 일진 않았을 것이다. 

슬랙의 열풍은 기존에 사용 중이던 도구들을 버리지 않고, 그대로 사용하면서 각 도구들의 알림을 통합해 준 부분이 Killing Spec 이었다.

국내 서비스들 중에서는 적용할 수 있는 서비스가 많지 않지만, 그럼에도 많이 사용하고 있는 Mailchimp, Github, JIRA, Asana, Trello 등의 알림을 슬랙에서 받아볼 수 있다. 

3. 개발자들이 원하는 서비스로의 확장

그 외에도, 슬랙은 파워풀한 API를 제공한다. 

이 API를 통해, 전 세계의 개발자들은 본인이 원하는 정보를 슬랙을 통해 알림을 받을 수 있도록 자기만의 서비스를 개발한다. 

Slack API는 귀찮았던 부분들을 조금의 노력을 들여 쉽게 해결할 수 있어, 개발자들에게 더 없이 좋은 도구가 되었다, 

◼︎ 슬랙의 불편한 점

이렇게 큰 장점을 가지고 있음에도 불구하고 슬랙만으로는 협업 커뮤니케이션에 어려움을 느낀다.

많은 슬랙 사용자들은 슬랙과 히스토리를 정리하기 위한 도구, 메일을 함께 사용한다. 

1. 메신저 플랫폼의 한계

메신저는 <대화 상대>와 <대화 창>을 통해 커뮤니케이션 하는 플랫폼이다. 

모든 정보의 전달은 대화상대가 있어야 하며, 주제와 관련없이 대화창을 통해 정보가 구분된다. 

이슈(주제)가 아닌 대화창(대화상대)으로 정보를 구분

사람들은 자료를 찾을 때 머리 속에, 파일의 제목이나 이미지, 이슈 자체, 혹은 내가 했던 일이나 의사결정 중 하나를 먼저 떠올리게 된다. 

떠올렸던 정보를 기준으로 연관된 자료를 찾는다.

메신저는 대화상대를 기준으로 대화창을 열어 자료를 찾을 수 밖에 없다보니, 지난 히스토리나 정보를 찾는데 한계가 있다. 

다행히 슬랙은 "파일"에 있어서는 따로 모아주지만, 파일이 아닌 정보의 전달이나 의사결정 과정 등은 여전히 한계를 가진다. 

이슈의 혼재 + 일상대화까지 혼재

또한, 대화창을 기준으로 모든 대화가 오가다 보니, 하나의 대화창 안에서 너무 많은 주제로 대화하게 된다. 

중요한 정보와 일상적인 대화가 섞여 결국 원하는 내용을 찾으려면 대화내용을 모두 읽을 수 밖에 없다.

슬랙에서는 검색을 통해 이 부분을 해결한다고 하지만, text 검색의 한계는 극복하기 어려운 것이 사실이다.

같은 맥락을 가진 내용도 사람마다 다른 단어를 사용하게 되는데, 자유도가 높은 메신저 대화에서는 단어 사용의 자유도 역시 높아 검색이 쉽지 않다. 

가령, 팀내 대화에서도, '콜라비 리뉴얼 버전'을 누군가는 "서비스"라고 칭하고, 또 다른 사람들은 "제품", "리뉴얼", "PC버전", "데스크탑", "PC웹" 등 너무 많은 단어들로 지칭되고 있는 현상을 보였다. 

(이 부분은 메신저 플랫폼의 한계라기 보다, text searching 자체의 한계라고 볼 수 있다.)

2. 실시간 커뮤니케이션의 비효율성

실시간 커뮤니케이션은 즉답을 얻을 수 있다는 큰 효과가 있다.

다만, 말을 거는 사람이 원하는 타이밍에 커뮤니케이션이 시작된다. 

이는 메시지를 받는 사람으로 하여금 집중하던 일에 방해요소가 될 수 있다. 이 부분이 업무 효율을 크게 떨어뜨린다. 

(실시간 커뮤니케이션과 비실시간 커뮤니케이션의 장단점은 별도의 글에서 따로 다룰 예정이다.)

또한, 단체창의 경우 대화에 꼭 필요하지 않은 사람까지 알림을 받게 되고, 이 알림 역시 주제별로 걸러낼 수 없다. 

단체창은 너무 괴롭지만, 혹시 중요한 정보를 놓칠세라 결국 하나하나 다 읽어보게 된다. 

위에서 언급했다시피 메신저는 <대화창>을 기준으로 정보가 전달되고 구분되기 때문이다. 

출처: http://blog.collabee.co.kr/45 [콜라비 블로그 :: 협업툴 collabee]

2018년임에도 불구하고, 스마트폰은 충전하지 않으면 24시간 이상 버티기 힘들다. 더 나은 배터리 기술은 아직 등장하지 않았기 때문에 한정된 전력으로 가능한 한 오랫동안 사용할 수 있는 소프트웨어 및 설정이 필요하다.

전화, 운영체제, 심지어 프로세서 제조업체들도 모두 전력 소모를 줄이기 위해 노력하고 있다. 최신 퀄컴 칩은 그 어느 때보다 에너지 효율이 높으며, 공개 베타 버전이 출시될 안드로이드 P(Android P)에서는 거의 사용하지 않는 앱들의 전력 사용량을 제한하는 어댑티브 배터리(Adaptive Battery) 모드가 있다.

불행히도 크고 밝은 화면과 와이파이, 블루투스, GPS, 4G 등으로 인해 게임이나 동영상 스트리밍을 배제하고서라도 일주일을 사용하지 못한다. 이번 기사에 소개하는 내용을 따라 스마트폰의 설정을 약간 변경한다면 배터리 사용 시간을 늘릴 수 있을 것이다.

요즘은 이동 중에도 스마트폰을 충전할 수 있는 휴대용 예비 배터리가 있어 아주 좋다. 또한 인기있는 스마트폰의 경우, 배터리 일체형으로 나와 조금 더 많은 배터리 용량을 제공한다.

스마트폰 배터리 수명을 늘리고자 사용을 자제하라는 터무니없는 얘기는 하지 않는다. 이번 기사에서는 사용자의 전력 소비를 줄이지 않고도 소비 전력을 줄이는 방법을 보여주고자 한다. 스마트폰 배터리 수명을 늘릴 수 있는 10가지 방법과 전혀 도움이 되지 않는 배터리 절약 미신을 소개한다.

1. 화면 밝기를 어둡게 하거나 자동 밝기 조절 기능을 사용하라 

스마트폰의 크고 화려한 화면을 좋아하지만 이는 배터리의 치명적인 적이다. 화면은 스마트폰의 다른 구성 요소보다 가장 많이 배터리 전력을 소비하는 요소다. 대부분의 전화기에는 자동 밝기 기능이 있는데, 주변 밝기에 맞게 화면 밝기를 자동으로 조정한다. 
이 모드는 전체 밝기로 화면을 계속 실행하는 것보다 적은 전력을 사용하지만, 화면 밝기를 허용할 수 있는 가장 낮은 설정으로 낮추면 더 좋은 결과를 얻을 수 있다. 화면 밝기만 제대로 조정하면 뒤에서 제안하는 것 모두를 하지 않더라도 배터리 소모를 크게 줄일 것이다.

2. 화면 자동꺼짐 시간을 짧게 유지하라 

스마트폰의 디스플레이 설정 메뉴에서 화면 자동 꺼짐 시간과 비슷한 옵션을 찾아보자(아이폰의 경우, 일반 설정 메뉴에서 자동 잠금을 찾아라). 이 설정은 탭과 같은 입력을 받고 난 이후, 화면이 켜져 있는 시간을 제어한다. 
매초마다 계산할 수 있는데, 시간을 가능한 한 가장 짧은 시간으로 설정하라. 대부분 안드로이드 스마트폰에서는 최소 15초다. 화면 자동 꺼짐 시간이 현재 2분으로 설정된 경우, 해당 수치를 30초 이하로 줄이는 것이 좋다.

3. 블루투스 끄기 
핸드프리 헤스셋, 무선 스피커, 스마트워치, 또는 활동 추적기 등 블루투스를 사용하는 것을 좋아하더라도 추가 무선 장치를 켜놓으면 외부 신호를 끊임없이 수신한다. 자동차 내부에 있지 않거나 음악을 무선으로 재생하지 않는 경우 블루투스를 꺼놓자. 이를 통해 스마트폰 배터리를 한 시간 이상 더 사용할 수 있다.


4. 와이파이 끄기 
블루투스와 마찬가지로 스마트폰의 와이파이는 심각한 배터리 소모를 유발한다. 인터넷 접속 및 기타 데이터 서비스를 위해 3G 또는 4G가 아닌 집이나 사무실의 와이파이 연결을 사용해야 하는 경우가 있지만, 언제 어디서든 와이파이를 켜두는 것은 그리 중요하지 않은 기능이다. 문 밖으로 나갈 때 끄고 와이파이 네트워크 범위 내에서 데이터 서비스를 사용할 계획인 경우에만 다시 켜도록 하자.

iOS의 경우, 블루투스와 와이파이를 켜고 끄는 것이 상당히 쉬워졌다. 간단하게 화면 하단에서 제어센터까지 위로 올려보자. 다만 위치 서비스에 대해서는 예외다. 와이파이가 스마트폰이 적은 전력으로 GPS 수정값을 얻을 수 있도록 도와주기 때문이다(자세한 사항은 미신 부분에서 설명).

5. 위치 서비스와 GPS에서 쉽게 전환하라

또 다른 배터리 소모 요인 가운데 하나는 GPS, 와이파이, 모바일 데이터를 사용해 위치를 모니터링하는 앱들이다. 사용자는 위치 서비스에 대한 앱 접속을 취소하거나 안드로이드에서 수준을 설정해 사용하는 전력 수준을 결정할 수 있다. 설정 > 연결 > 위치에서 필요할 때 높은 정확도를 선택하거나 그렇지 않은 경우 배터리 절약을 선택할 수 있다. 
각 앱에서 접속하도록 허용하는 것에 대해서는 현명하게 대처해야 한다. 앱에서 내 위치, 카메라 또는 SD 카드와 통합하도록 허용하는 것이 편리할 수 있지만, 보통의 경우는 불필요하다. 자주 사용하지 않는 앱에 너무 많은 권한을 부여하면 배터리만 소모될 뿐 아무런 이점이 없다.

6. 백그라우드에서 앱을 실행하지 마라 
한번에 두개 이상의 앱을 실행할 수 있는 멀티태스킹(Multitasking)은 스마트폰의 강력한 기능이다. 또한 실행하는 모든 앱이 스마트폰의 프로세서 사이클을 사용하기 때문에 많은 전력을 소모할 수 있다(하지만 모든 앱이 다 그런 것은 아니다. 아래 미신 부분 참조).
실제 사용하지 않는 애플리케이션을 종료하면 CPU의 작업 부하를 대폭 줄이고 전력 소비를 줄일 수 있다.

안드로이드에서는 멀티태스킹 버튼(일반적으로 화면 하단의 세 개의 아이콘 가운데 가장 왼쪽에 있는 버튼)을 탭한 후, 앱들을 닫을 수 있다. iOS에서는 홈 버튼을 두번 탭해 멀티태스킹 화면이 나타나면 위로 올려 앱을 닫을 수 있다.
iOS와 안드로이드 모두 배터리 모니터가 있어 각 앱이 사용하는 전력의 양을 정확히 확인할 수 있으며, 너무 많은 전력을 사용하는 앱을 쉽게 찾을 수 있다. 그런 다음 제거하거나 실제 사용하지 않을 때에는 종료할 수 있다.

7. 진동을 사용하지 마라
걸려오는 전화 알림을 벨소리보다 진동 방식을 선호하는 경우가 많다. 이런 상황을 이해한다. 하지만 진동 모드는 벨소리를 재생하는 것보다 훨씬 많은 전력을 사용한다.
벨소리는 스마트폰 스피커의 미세한 막을 울림으로써 소리를 낼 수 있다. 반대로 진동 모드에서는 아주 작은 모터가 회전해 전체 휴대 전화를 흔든다. 이 과정에서 훨씬 더 많은 전력을 필요로 한다.

벨소리를 듣고 싶지 않다면 모든 알림을 끄고 전화 보기 상태를 유지해 새로운 통화가 들어왔을 경우에만 확인할 수 있도록 하자. 이 방법은 배터리뿐만 아니라 친구나 동료에게도 정중한 방식이다.

8. 불필요한 알림 끄기 
거의 모든 앱이 업데이트, 뉴스, 메시지, 및 기타 정보를 검색해 인터넷을 조사하는 것처럼 보인다. 무언가 발견하면 앱이 알림을 하고 화면을 밝게 해 메시지를 표시하거나 LED를 깜박이거나 설명한 모든 작업을 수행할 수 있다. 이런 모든 것들이 에너지를 소비한다.
새로운 문제 메시지나 부재 중 전화에 대한 알림은 해제하고 싶지 않을 수도 있지만, 불필요한 알림을 끄면 배터리 수명은 길어지고 주의를 분산시키는 것을 막을 수 있다.