이제까지 내 기억으로는 Date 관련 클래스를 아래처럼 점차 바꿔써온걸로 기억이 난다. java.util.Date > java.util.Calendar > org.joda.time 그런데 java 8 버전에서 기존에 있었던 문제들을 개선해서 나왔다고 한다. (네이버 HellowWorld 포스팅 참고) JSR-310 이라는 표준명세로. 지금부터는 JAVA 8 에서 제공하는 API로 날짜 연산을 어떻게 하는지에 대해 알아보고자 한다. (물론 수많은 날짜 연산 방법을이 있지만 자주 쓰이는 부분들 위주로 정리해보자.) Date > String (format) LocalDateTime.now().format(DateTimeFormatter.ofPattern("yyyy-MM-dd")); String > Date (format) LocalDateTime.parse("2017-01-01 12:30:00", DateTimeFormatter.ofPattern("yyyy-MM-dd HH:mm:ss")); 날짜/시간 증감 LocalDateTime localDateTime = LocalDateTime.of(2017, 1, 1, 10, 0, 0); localDateTime.plusDays(1); // 일 localDateTime.plusMonths(1); // 월 localDateTime.plusHours(1); // 시간 localDateTime.plusWeeks(1); // 주 localDateTime.minusYears(1); // 년 localDateTime.minusMinutes(1); // 분 더 다양한 내용들은 아래 URL 에서 확인이 가능하다. https://docs.oracle.com/javase/tutorial/datetime/iso/overview.html

지난번에는 트랜잭션의 설정값에 대해 알아본 바 있다. [ Spring Transaction 옵션 ] 이번 포스팅에서는 실제로 스프링 환경에서 어떤식으로 설정해야 @Transactional 어노테이션을 사용할수 있는지, 그리고 어떤 속성들이 있는지에 대해 알아보고자 한다.설정 기존 xml방식에서는 다음과 같이 설정을 한다. <bean id="transactionManager" class="org.springframework.jdbc.datasource.DataSourceTransactionManager"> <property name="dataSource" ref="dataSource"/> </bean> <tx:annotation-driven transaction-manager="transactionManager" proxy-target-class="true"/> 혹, JavaConfig 방식으로 설정하기 위해서는 다음과 같이 설정한다. @EnableTransactionManagement public class AppConfig { ... @Bean public PlatformTransactionManager transactionManager() throws URISyntaxException, GeneralSecurityException, ParseException, IOException { return new DataSourceTransactionManager(dataSource()); } } 위와같이 설정을 해주면 트랜잭션을 설정하고자 하는 곳 어디서든 @Transactional 어노테이션을 지정해서 적용이 가능하다. public class UserService{ @Transactional public boolean insertUser(User user){ ... } } 주요속성 @Transactional 어노테이션의 주요속성은 다음과 같다. 속성 설 명 사용 예 isolation Transaction의 isolation Level. 별도로 정의하지 않으면 DB의 Isolation Level을 따름. @Transactional(isolation=Isolation.DEFAULT) propagation 트랜잭션 전파규칙을 정의 , Default=REQURIED @Transactional(propagation=Propagation.REQUIRED) readOnly 해당 Transaction을 읽기 전용 모드로 처리 (Default = false) @Transactional(readOnly = true) rollbackFor 정의된 Exception에 대해서는 rollback을 수행 @Transactional(rollbackFor=Exception.class) noRollbackFor 정의된 Exception에 대해서는 rollback을 수행하지 않음. @Transactional(noRollbackFor=Exception.class) timeout 지정한 시간 내에 해당 메소드 수행이 완료되지 않은 경우 rollback 수행. -1일 경우 no timeout (Default = -1) @Transactional(timeout=10) 마치며 자칫 잘못했다가는 원치않는 트랜잭션으로 잘못된 결과를 초래할수 있기때문에 기본값은 숙지하는게 좋을것 같다.

수많은 블로거분들의 도움을 받고자 구글링을 해서 적용을 해봤지만 너무많은 삽질을 했다.(해봤던 방식은 jsonViewResolver 를 따로 설정해보거나, @RequestMapping 옵션을 바꿔보는 수준..) 특히나 Spring설정방식이 예전 방식이였던 xml이 아닌 javaconfig였기 때문에 더욱더 자료가 없었고.. 한참을 삽질하다 해결을 하여 포스팅하게 된다. 우선 환경은 spring 4.3.4.RELEASE, Maven, jdk8임을 밝힌다. pom.xml jackson-mapper-asl을 이용해서 하라는 블로거들도 있었지만, 아무리해도(뭔가 Spring버전과 맞지 않는듯 했다.) 잘 안되어 아래와 같은 dependency를 주었다. <dependency> <groupId>com.fasterxml.jackson.core</groupId> <artifactId>jackson-databind</artifactId> <version>2.5.1</version> </dependency> Controller 아래와같이 @ResponseBody 어노테이션을 설정해주고 리턴은 해당 모델을 넘기면 된다. @RequestMapping(value="/test") @ResponseBody public Map<String, Object> test(){ Map<String, Object> map = new HashMap<String, Object>(); map.put("1", "111"); map.put("2", 222); return map; } 그리고 호출을 해보면 기대했던것처럼 이쁘게 json형태로 나온다. { "1": "111", "2": 222 } 물론, list 나 array, 일반 객체도 가능하다. 정리 삽질을 끝에 알게된 사실(?)을 정리해보자. 다른측면에서 분석을 해보면. @ResponseBody을 이용하여 view 에 json 형태로 나타내고자 할 경우 가능한 상황은 toString으로 했을때 json형태로 나올수 있으면 가능하다. 예로들어 아래처럼 클래스에 Lombok 어노테이션인 @Data가 붙으면 자동으로 toString을 오버라이딩 해주기 때문에 해당 클래스를 리턴하게되면 자동으로 json 처리가 된다. @Data public Student{ private String id; private String name; ... } @ResponseBody을 붙이고 List<Student>를 리턴하게 되면 에러가 나는데, 이럴경우 별도 라이브러리를 추가해줘야 자동으로 변환되어 json 형태로 나올수 있게 된다. (list.toString을 하면 json형태가 아닌 이상한 문자형태로 나오기 때문… Map같은것도 마찬가지 이유로 별도 라이브러리를 추가해줘야 정상적으로 나온다.) 마치며 단순히 @ResponseBody를 사용해서 json으로 리턴하려면 어떤 라이브러리를 추가해야한다 로 생각했던것에서, 이것저것 테스트 한 결과 toString을 할수 있어야 하고 그 값이 json형태이면 가능하다 로 결론이 지어졌다. 확실히 장님 코끼리 만지듯이 ‘그런가보다’하고 넘어가면 삽질이 진짜 불필요한 삽질이 되는것 같다. 구글링을 해보고, 테스트를 해봐서, 결론적으로 내것으로 만드는 습관을 가져야 겠다.

1. 디렉티브방식 <%@ include file="~~"%> 정적 include 방식, 인클루드 되는 내용이 단순하게 텍스트로 포함되어 컴파일이 된다. (복사된다는 느낌) 주의할점은 비록 포함되는 페이지라 하더라도 한글을 제대로 처리하기 위해서는 포함되어지는 jsp파일 상단에 인코딩 명시를 해줘야 한다. 포함되어지는 jsp 내용이 변경이 될 경우 해당 jsp를 사용하는 jsp를 강제로 변경(touch) 해줘서 다시 컴파일이 되게 해야하는 불편함이 있다. 정적 방식이기 때문에 예로들어 전역변수를 인클루드 되는 jsp에서 지정하게 되면 상위jsp에서 사용이 가능하게 된다. 2. 액션태그 방식 <jsp:include page="~~"/> 동적 include 방식, 포함하는 문서와 상관없이 동적으로 컴파일 된다. (완전히 별도로 동작하기 때문에 변수를 동시에 사용하려면 따로 파라미터로 넘겨줘야 한다.) flush 옵션은 요청흐름이 넘어가면서 현재까지 페이지의 결과를 출력할 것인지 말것인지를 결정하는것이다. 일반적으로 false로 설정한다. <jsp:param>를 이용하여 파라미터를 전송할수 있다. <jsp:include page="..." flush="false"> <jsp:param name="name" value="이름" /> <jsp:param name="pageName" value="페이지이름"/> </jsp:include> 3. JSTL 방식 <c:import url="~~" /> JSTL(JSP Standard Tag Library) 태그중의 하나 컴파일 되고 동작하는 방식은 액션태그<jsp:include page="~~"/>와 같음 현재 컨테이너 안에 있는 자원외에 다른 외부 자원도 포함이 가능하다. <c:import url="http://www.google.com/"/> 아래와 같이 보다 더 다양한 옵션이 제공된다 <c:import! url="읽어올 URL" var="읽어올 데이터를 저장할 변수명" scope="변수의 공유 범위" varReader="리소스의 내용을 Reader 객체로 읽어올 때 사용" charEncoding="읽어온 데이터의 캐릭터셋 지정" />

올해도 어김없이(?) 1월 1일이 되어 해맞이(해돋인지 해맞인지 햇갈리지만, 새해 첫날부터 복잡해지기 싫당 =ㅁ=)를 다녀오고 까페에서 새해 계획을 세워본다. 정말 지킬수 있는 계획들, 현실적인 부분들만 고려해서 써내려 가보자. 절반 이상만이라도 지킬수만 있다면 그나마 다행이라고 생각! 기술블로그 운영하기 : 월 2회 posting 내가 아는지식이 얼만큼인지, 보여주기식이 아닌 내 머릿속에 자리잡고 있는 부분들을 정리해서 기록화 하는 이름하야 기술블로그를 작성하는거다. 2주에 최소 하나씩, 이렇게 되면 한달에 최소 2post, 1년이면 약 20post. 작다고 해도 마냥 작게만 느껴지지 않을 분량이다. 사소한거 하나라도. 이를테면 서버 설치나 스프링의 기본 설정 관련된 것들도. 글쓰는 연습도 하고 좋은 기회가 될것 같다. 4대강 종주 : 영산강, 1박2일코스 2014년에 한강(북한강, 남한강), 2015년에 금강, 2016년에는 못갔다. 4대강 종주의 목표가 갑자기 시들어진 작년이라 생각이 든다. 우여곡절 산전수전 다겪은 내 자전거 붕붕이에게 미안하지 않기위해서라도 올해 여름에는 꼭 영산강이나 낙동강 하나를 계획잡아 1박2일 코스로 다녀와야겠다. 음, 대략 5월? 아마 영산강을 가게될것같다. 이번에는 무리하지 않고 1박2일코스로.. 독서 : 월 전공1권, 전공외1권 작년에 내 입에서 나왔던 이야기들중에 한심스럽게(?)나온 멘트중 가장 많이나왔던 책좀읽자 올해에는 정말 많이는 아닐지라도 자주읽는 습관을 길러야겠다. 한달에 전공책 한권, 기타서적 한권. 얇은책+읽고싶은책 부터 읽기 시작해서 내년 1월1일때는 내 책상 한켠에 자리잡고있는 책장을 가득 메워보고싶다. 아, 물론 다 읽은 책들로만. 여행+사진 : 한달에 한번이상 여행가기 해외든 국내든, 올해는 정말 많이 다녀와야겠다. 가볍게 당일치기부터 시작해서 갈수만 있다면 해외여행도. 물론 올해도 야근과의 싸움은 계속될테지만 주말 잠깐이라도 시간을 내서 두달에?아니 한달에 한번이라도 휴가를 써서라도 가까운곳에 힐링하러 다녀오고 싶다. 가서 작년에 산 카메라로 사진도 이것저것 많이 찍고 좋은추억 많이 만들고오고 싶다. 저축+a : 근검절약의 생활화, 경제공부 나름 월급의 60%이상을 저축하는 중이다. 그치만 상황이 상황인지라 지금도 만족하지 못한다. 천장에 굴비 달아놓고 간장찍어 먹는다는게 아니라 아낄수 있는 부분들은 최대한 아끼면서 살자는거다. 아침에 택시 타지말고 조금 일찍 일어나서 버스를 탄다던지, 버스를 타지말고 조금일찍 일어나서 자전거를 탄다던지(사실 자전거를 타면 퇴근할때 더 빠르고 편하게 올수 있으니) 생활속에서 절약할수 있는 부분들을 찾고, 몸에 베도록 습관화 시켜야겠다. 그리고 주식이나 펀드 등 투자에 대해서도 이제 공부를 해봐야겠다. (독서하자는거랑 비슷한 이야기) 저금리시대 마냥 저축만 하다보면 힘든건 누구나 다 아는이야기. 일에 치여 생활에 치여 핑계대지말고 배워가면서 챙겨보자. 운동 : 자유형마스터, 몸짱 항상 하는 이야기지만 건강보다 중요한건 없다고 생각한다. 올해에도 병원가지 않는 나를 만들기 위해 헬스 + 배드민턴 + 라이딩 은 필수고 가능하면 수영도 배워서 자유형 정도는 할수있는 나를 만들고 싶다. 그래서 다들 말하는 몸짱도 되보고 싶고 자신있게 해변가에서 상의를 탈의할수있는(?!) 건강한 내가 되도록 노력해야겠다. 봉사활동하기 : 연탄배달, 자원봉사 작년에 하려다가 못한 봉사활동 올해는 꼭 해야겠다. 가깝게 할수있을법한게 연탄배달, 이건 1월달 내로 꼭! 해서 봉사라는것과 나눔이라는 행복을 느껴보고 싶다. 지금 생각나는건 자원봉사 같은것도 해보고 싶고 무보수 알바(?) 같은것도 해보고싶다. 나이들면 못할, 언제 해보겠나. 가까운, 먼 사람들 만나기 마지막으로, 잊고있었던 중요한 행동. 바로 사람들 만나기다. 바쁘다는 핑계 하나만으로 등한시한 내 소중한 사람들. 아무리 연봉을 많이 받고 일을 잘한다고 회사에서 잘나간다 할지라도, 내 곁엔 나를 생각해주는 소중한 사람들이 있기에 내가 있을수 있는것 같다. 가까운 사람들부터 시작해서 오랬동안 못봤던 사람들도 하나둘씩 연락하면서 지내는 여유를 가져야 겠다. 할수 있을까? 라는 생각보다 하나둘씩 잊지말고, 놓치지 말고 하루를, 이번주를, 이번달을 점검하고 실천해 나가보자. 올 한해도 열심히 최선을 다해 살것!

2016년, 내겐 정말 수많은 일들이 있었고 그 어느때보다 (전역 후로) 미친듯이 회사에 집중했던 시간들로 기억난다. 무작정 다가오는 새해를 맞이하는것도 좋지만 올 한해를 되돌아보는 시간을 갖고, 나를 다시 점검해보는 차원에서 일명 ‘회고’를 해볼까 한다. 회사 정말 열심히 했다. 잘했는지는… 잘 모르겠다. 난 잘한것 같다. 물론 내 하루중에 가장많은 시간을 쏟은것도 있지만 작년에 많이 하지 못하던것을 ‘날씨’라는 서비스를 홀로 맡으면서 정말 많은것을 배우고 결과물도 후회하지 않을만큼 나온것 같다. 지나고보면 구지 하지 않아도 월급은 똑같이 나올테고, 시키지도 않았는데 그시간에 잠을 더 잤으면 하는 생각도 들지만 후회하지 않는다. 아무도 없는 사무실 나혼자 12시넘어서 퇴근을 해도 즐거웠으니까, 그거면 됬다. 모바일 개편이라는 큰 업무를 무사히(?) 해쳐내고는 사내에서 조직(서비스)을 변경할수 있는 기회가 되어 나홀로 지원, 다행스럽게도 합격을 해서 지금은 네이버페이 와 관련된 일을 하고있는 중이다. 기존 서비스운영을 하면서 느끼지 못했던, 초기 설계부터 시작하여 어떤 기술스택을 쓸것인가에 대한 선택부터 다양한 시행착오를 통해 이제 한 두달 되었는데 정말 많이 배우고 있다. 너무 힘들지만 너무 행복하다. 돌이켜보면 작심삼일로 개발 관련된 공부를 등한시 한게 너무 후회가 된다. 바쁘다는 이유하나만으로 (솔직히 바쁘다는건 핑계다) 기능구현에만 신경을 써왔는데, 내년부터는 할수만 있다면 업무 외적으로 나만의 개발트리를 세워보고 싶다. 건강 일주일에 한번 이상 오전엔 배드민턴, 저녁엔 헬스장엘 가려고 노력했다. 그 결과였을까, 사랑니 뺀거 말고는 병원을 단한번도 안갔다. 감기조차 걸리지 않는게 다행이라고 생각하지만, 요즘들어(야근이 많아져서인지) 책상에 앉아있는 자세가 불량해서 거북목이 되가고 있다. 폼롤러도 구비했고 어깨 펴지라고 밴드도 구입해서 사용은 하는데 잘 실천이 안되는 중이다. 작년에 자전거를 잃어버리다 되찾고는 자전거를 등한시 하게 되는것 같다. 이또한 핑계겠지. 내년엔 꼭 4대강중 하나 잡고 종주한번 해야겟다. 기필코.. 아맞다 수영도. ㅠㅠ 물에 뜨질 않으니 큰일이다… 사람관계 학교선후배동기 및 동아리 사람들, 군대 동기들 및 소대원들 과 선임 장교분들, 기타 등등… 올해 들어서인지. 연락에 너무 무색할만큼 잊고 살았던것 같다. 지나고보면 다른곳에 신경쓴다고 연락을 못했다고 핑계를 대고 있는 나이지만, 또 한편으로는 그 연락 10분 시간이 없다는건 … 역시나 핑계다. 나를 도와주고 나를 믿어주고 나를 생각해주는 사람들을 조금이라도 더 신경써서 연락하고 찾아 뵙는 시간을 내년부터서라도 가져야겠다. 마치며 일단 첫번째로 내년부터 할일은, 기술 블로그를 운영하는것이다. 솔직히 두달전 이 gitHub 를 이용해서 블로그를 만들긴 했지만 그닥 포스팅도 못했고 방치 수준이였으니… 적어도 한달에 한두개 정도는 포스팅 해보려고 노력해야겟다. 글쓰는게 힘들고 시간이 많이 들어가는 작업이지만, 돌이켜 생각하면 다 내 자산이고 나를 다시 바라볼수 있는 기회니까. 꼭 기술블로그만이 아닌, 하루를 기록하는 무언가를 해야겠다. 막상 한해를 돌이켜보니 그때는 뭐했는지 기억도 안나네.. 두번째로는 지킬수 있는 계획을 잡는것이다. 올 한해 목표중에 이룬건 10개중에 단 두개… (그중에 노래대회나가기, 스쿠버다이빙 하기, 자유형 마스터하기도 있다;;) 부끄럽다.. 2016년, 나라도 뒤숭숭 하고 정신없던 한해였지만 나름 의미있던 시간들을 보낸것 같아 다행이라 생각한다. 음,. 10점만점에 8점?? 2017년! 다시한번 일어서자! 화이팅!!

상황 스프링 환경에서 일반적으로 DAO 나 BO 레벨에서 다음과 같이 코딩을 하게 된다. @Transactional(isolation = Isolation.READ_COMMITTED, propagation = Propagation.REQUIRED, rollbackFor = Exception.class) public int method(int i) throws Exception { return sqlMapClient.delete("~~~~"); } 무분별하게 Ctrl+C,V 신공으로 트랜잭션 어노테이션을 가져다가 사용할수도 있겠으나, 각 값들이 어떤 역활을 아는지에 대해 알고 넘어갈 필요성이 있다. @Transactional 우선 해당 어노테이션을 적용하면 적용된 클래스 또는 메소드에 트랜잭션이 적용된다. 따라서 로직 흐름에 맞추어 전체적으로 트랜잭션을 적용할것인지, 아니면 특정 메소드에 적용할것인지 전략을 잘 세워야 한다. isolation 격리수준이라는 옵션이다. 트랜잭션에서 일관성이 없는 데이터를 허용하도록 하는 수준을 말하는데 옵션은 다음과 같다. READ_UNCOMMITTED (level 0) 트랜잭션에 처리중인 혹은 아직 커밋되지 않은 데이터를 다른 트랜잭션이 읽는 것을 허용 어떤 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 B라는 아직 완료되지 않은(Uncommitted 혹은 Dirty) 데이터 B를 읽을 수 있다. Dirty read : 위와 같이 다른 트랜잭션에서 처리하는 작업이 완료되지 않았는데도 다른 트랜잭션에서 볼 수 있는 현상을 dirty read 라고 하며, READ UNCOMMITTED 격리수준에서만 일어나는 현상 READ_COMMITTED (level 1) dirty read 방지 : 트랜잭션이 커밋되어 확정된 데이터만을 읽는 것을 허용 어떠한 사용자가 A라는 데이터를 B라는 데이터로 변경하는 동안 다른 사용자는 해당 데이터에 접근할 수 없다. REPEATABLE_READ (level 2) 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정이 불가능하다. 선행 트랜잭션이 읽은 데이터는 트랜잭션이 종료될 때까지 후행 트랜잭션이 갱신하거나 삭제하는 것을 불허함으로써 같은 데이터를 두 번 쿼리했을 때 일관성 있는 결과를 리턴함 SERIALIZABLE (level 3) 완벽한 읽기 일관성 모드를 제공 데이터의 일관성 및 동시성을 위해 MVCC(Multi Version Concurrency Control)을 사용하지 않음(MVCC는 다중 사용자 데이터베이스 성능을 위한 기술로 데이터 조회 시 LOCK을 사용하지 않고 데이터의 버전을 관리해 데이터의 일관성 및 동시성을 높이는 기술) 트랜잭션이 완료될 때까지 SELECT 문장이 사용하는 모든 데이터에 shared lock이 걸리므로 다른 사용자는 그 영역에 해당되는 데이터에 대한 수정 및 입력이 불가능하다. propagation ( 전파옵션) REQUIRED : 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 새로운 트랜잭션을 생성 REQUIRES_NEW : 부모 트랜잭션을 무시하고 무조건 새로운 트랜잭션이 생성 SUPPORT : 부모 트랜잭션 내에서 실행하며 부모 트랜잭션이 없을 경우 nontransactionally로 실행 MANDATORY : 부모 트랜잭션 내에서 실행되며 부모 트랜잭션이 없을 경우 예외가 발생 NOT_SUPPORT : nontransactionally로 실행하며 부모 트랜잭션 내에서 실행될 경우 일시 정지 NEVER : nontransactionally로 실행되며 부모 트랜잭션이 존재한다면 예외가 발생 NESTED : 해당 메서드가 부모 트랜잭션에서 진행될 경우 별개로 커밋되거나 롤백될 수 있음. 둘러싼 트랜잭션이 없을 경우 REQUIRED와 동일하게 작동 no-rollback-for - 예외처리 (기본값 : 없음) 특정 예외가 발생하더라도 롤백되지 않도록 설정 스프링 배치에서의 트랜잭션 (내가 당했던(?) 문제) 스프링 배치에서는 Tasklet 에서 기본적으로 step 단위 트랜잭션을 지원하고 있다고 한다. 기본적으로 job이 하나의 tasklet 의 step 으로 실행하다보니 명시적이진 않지만 내부적으로 전체 트랜잭션으로 걸려있게 된다. 나같은 job 내 DAO delete 메소드에서 @Transactional 설정을 하고 그 DAO 메소드를 반복문에 의해 delete 하는 로직을 수행하는 부분이 있었는데 부모의 트랜잭션(tasklet에서 설정된 트랜잭션)으로 인해 dao 를 몇번 호출하던 job단위로 트렌젝션이 걸리게 되었다. (결국 트랜잭션은 반복문이 다 끝나야 적용이 된다는점.) 그러다보니 가끔 DB Query Lock이 걸렸는데 DB레벨에서 undolog를 남기는게 너무 무거워져 lock이 발생 따라서 전파옵션을 수정해서 해당 문제를 해결하였다. # 기존 begin delete < for 반복문 commit # 전파옵션 수정 (기존 REQUIRES 에서 REQUIRES_NEW 으로 수정) for begin delete commit for end

디자인 패턴중에 가장 잘 알려진 싱글톤 에 대해서 알아보고자 한다. 멀티 스레드 환경에서 자주 이용되는 패턴이라고만 들었는데 이번 기회를 통해 제대로 정리해보자 싱글톤이 무엇인가 싱글톤(Singleton)은 정확히 하나의 인스턴스만 생성되는 클래스이다. 라고 이펙티브 자바에서 정의되어있다. 즉, 딱 하나만 생성하고 이를 여기저기서 사용하는 패턴이라 생각하면 될듯 하다. 싱글 스레드 환경에서는 당연히 인스턴스를 공유할 상황이 없겠지만 대부분 멀티 스레드 환경이기 때문에 싱글톤 패턴은 아주 중요한 부분이다. 아주 고전적인 방법 (위험한 방법) public class Singleton { private static Singleton uniqueInstance; private Singleton(){} public static Singleton getInstance(){ if (uniqueInstance == null){ uniqueInstance = new Singleton(); } return uniqueInstance; } } 위와 같은 상황에서 if절을 도달하는 시점이 각 스레드마다 다를경우 문제가 발생할 수 있다.(교묘한 시점에 객체가 1개 이상 반환될 여지가 있음) 이를 해결하기 위해서는 다음과 같이 getInstance()를 동기화 해주면 된다. 하지만 불필요하게 동기화 하는 오버헤드만 증가하게 된다. public class Singleton { private static Singleton uniqueInstance; private Singleton(){} public static synchronized Singleton getInstance(){ if (uniqueInstance == null){ uniqueInstance = new Singleton(); } return uniqueInstance; } } public static 인스턴스로 생성 public static final LocalCache sharedObject = new LocalCache(); private LocalCache() { } 이코드는 간단하다는 장점이 있는 반면에 유연하지 못한 부분이 있다. (아래 이어서 설명) private static final 인스턴스로 생성 private static final LocalCache sharedObject = new LocalCache(); private LocalCache() { } public static LocalCache getInstance() { return sharedObject ; } 이렇게 하면 factory 메소드를 통해 객체를 반환받고, 반환 받는 시점에 다양한 작업들을 할수 있다. enum 으로 생성 public enum LocalCacheEnum { LocalCache; //etc another functions } 잘 사용하지는 않지만 가장 좋은 세번째 방법인 enum으로 클래스를 만드는 방법이라고 한다. 복잡한 직렬화나 리플렉션(reflection) 상황에서도 직렬화가 자동으로 지원되고, 인스턴스가 여러개 생기지 않도록 확실하게 보장해준단다. (by effective java) 그럼 어디서 사용될까 static 으로 선언해서 공통적으로 사용되는 부분이나 환경설정 내용이 변경되면 다른 클래스에서도 그 부분이 똑같이 적용되어 실행되어야 할때 자주 사용되는 부분을 싱글톤으로 만들어 생성되는 시간을 줄일때 스프링에서의 DB커넥션 로직

개요 이전포스팅 에서 이야기 한것과 같이 어느곳에서든지(집 또는 회사 등) 블로그 포스팅을 할수 있는 환경을 만들고 싶었다. (git을 이용해서.) 그래서 git repository 를 두개를 만들었고, 하나는 실제 블로그서버로 이용하고 하나는 블로그를 포스팅하는 hexo 환경을 저장하게 된다. 지금부터 이야기 할 내용은 hexo환경을 git repository 에서 pull 받아서 환경구성하는 부분을 이야기 하려고 한다. 환경구성 hexo설치와 git설치는 되어있다고 가정. 먼저 구성할 폴더를 생성하고 이 폴더에 hexo 환경을 구성하겠다고 초기 셋팅을 한다 mkdir blog hexo init blog 그리고 hexo환경을 저장해둔 repository를 가져와야 하므로 git설정을 한다 cd blog/ git init git remote add origin https://github.com/taetaetae/hexo.git git fetch 필요없는초기셋팅이 되는 파일은 지우고 rm source/_posts/hello-world.md rm -r themes/landscape/ #해당 테마를 사용하고 있다면 지울필요가 없다. hexo환경 repository 를 pull받는다 git reset --hard origin/master git pull origin master hueman테마의 검색 기능을 사용한다는 가정하에 필요한 플러그인과, 나중에 deploy 할때 필요한 플러그인을 설치해준다 npm install hexo-deployer-git --save npm install -S hexo-generator-json-content 이렇게 되면 기존처럼 환경설정이 마무리 되고, 포스팅을 할수 있게 된다. 추가 canonical 속성 npm install –save hexo-auto-canonical 사이트맵 속성 npm install hexo-generator-seo-friendly-sitemap –save feed 속성 npm install hexo-generator-feed –save

들어가기에 앞서 예전부터 블로그를 운영해야지 하구서 tistory, naver blog 등 다양한 플랫폼으로 시작을 했었지만 이렇다할 운영이 안되었고 사실 열정이 부족했었다. 직접 홈페이지를 만들기에는 너무 많은 허들이 있다보니 (서버구축, 호스팅, 도메인 등 …) 계속 차일피일 미루고 있었다. 그러다 github에서 제공하는 pages라는 걸 이용해서 무료로 도메인과 웹호스팅을 할수 있다는 부분을 알게되었고, 거기에다 jekyll을 이용하면 설치형 블로그를 운영할수 있다는것에 놀라웠다. 하지만 jekyll을 적용해보려고 이것저것 하다보니 ruby라는 언어로 만들어져있고 커스터마이징이 어렵다는 부분을 확인, 좀더 알아보다 hexo 라는 걸로 해당 블로그를 만들게 되었다. 필자처럼 남들과는 다른 블로그를 만들고 싶거나, git command 공부도 하면서 블로그를 운영해볼 사람들은 해당 글을 천천히 따라오면 좋을것 같다. hexo 시작하기 hexo 라는걸 시작하기 위해 몇가지 준비물이 있다. node 설치 git 설치 github에 블로그로 사용할 빈 repository 생성 github에 hexo 설정을 저장할 빈 repository 생성 위 4가지(?!)가 전부 설치 되었다고 가정을 하고 시작을 해보겠다. hexo 설치 간단하다. hexo 페이지에도 나와있는것처럼 아래 명령어를 실행해주면 된다. $ npm install -g hexo-cli 블로그로 운영할 폴더 hexo 초기화 폴더 구조로 구성이 되기 때문에 임의의 폴더를 하나 만들고 해당 폴더를 hexo 명령어로 초기화 시켜준다. $ mkdir <디렉토리명> $ hexo init <디렉토리명> 로컬서버 띄워보기 이제 로컬에서 서버를 띄워서 블로그가 어떻게 나오는지 확인을 해보면 된다. $ hexo s (or server) 간혹 서버가 실행이 안되거나 오류가 발생, 수정한 부분이 반영이 안된다면 clean 명령어를 한번 해준 다음에 다시 서버를 실행해주면 되는 경우도 있다. $ hexo clean $ hexo s (or server) http://localhost:4000 을 접속해서 정상적으로 페이지가 나오는지 확인을 해보자. 페이지가 정상적으로 나온다면 성공! 글 작성 아래 명령어를 실행하면 /source/_post/ 아래에 .md 파일이 생성이 된다. $ hexo new <글 제목> 해당 파일을 사용하기 편한 에디터로 열어서 마크다운 문법에 맞추어 수정을 하면 끝! 왜 두개의 repository가 필요한가 아래에서 이야기 하겠지만, 하나는 실제 블로그 내용이 올라갈 저장소이고 다른 하나는 블로그를 운영하고 있는 hexo 자체를 저장할 저장소이다. hexo 정보를 가지고 있지 않을꺼라면(필자처럼 다양한 PC에서 업로드 환경을 구축하지 않을꺼라면) 하나의 레파지토리만 필요할수도 있다. github 셋팅 지금부터가 알짜배기다. 즉 이글을 포스팅 하는 의미. 다른 글들에서도 hexo 사용법을 친절하게 알려 주셨으나 github와의 연동, 그리고 어떤식으로 운영해야할지는 찾기 힘들었다. 필자는 감으로 그런가보다(?)하고서 터득한 바를 공유하려한다. (이게 정답은 아니지만, 나는 이렇게 사용하는게 맞겠다 싶어..) 일반적으로 github에서 블로그로 사용할 repository를 만들게 되면 http://(github아이디).github.io/(repository이름) 으로 블로그가 만들어 지는데 뭔가 조금 이상해서 간지가 안나서 찾고 찾아서 아래와 같은 방식으로 하게 되었다. 필자의 github 아이디는 taetaetae 이고 도메인은 아이디 그대로를 사용하여 http://taetaetae.github.io 으로 사용하고 싶었다. 따라서 github에 repository이름을 taetaetae.github.io로 만들어야 한다. 여기까지만 하면 일단 github에 배포할수 있는 준비가 되어있는 상태 hexo로 배포하기 포스팅한 글이 정상적으로 등록이 된 것을 로컬서버에서 확인이 되었으면 이 상태를 조금전 만든 github repository으로 배포(정확히 말하면 git push)해줘야 한다. 그전에 최상위 폴더에 있는 _config.yml 파일을 열어서 github 정보를 입력해 줘야 한다. 하단 영역 Deployment 부분에 다음과 같이 작성하고 저장한다. # Deployment deploy: type: git repo: https://github.com/taetaetae/taetaetae.github.io branch: master 그 다음 hexo 에서 github로 배포할수있는 플러그인을 설치해준다. $ npm install hexo-deployer-git --save 이제 설정한 github에 배포를 하면 끝! $ hexo deploy 1분~3분 뒤에 도메인을 접속하여 정상적으로 페이지가 나오는지 확인하고, github에 파일들이 push가 잘 되었는지를 확인한다. 향후 관리 hexo 정보 저장 나중에 다른 PC에서도 블로그를 포스팅 할 경우가 있으니 hexo를 이용하여 포스팅 한 환경 자체를 저장 해야할 필요가 생겼다. 따라서 만들었던 폴더 또한 github에 업로드를 해놓는게 좋을것 같다 (지극히 개인적인 생각) git command 설명은 따로 정리하지 않겠다.