잭슨은 JSON -> Java 클래스로 Deserialize, Java 클래스 -> JSON으로 Serialize 할 때 매우 유용한 라이브러리다.
하지만 잭슨이 나온 이후에 자바 8이 나왔는지 모르겠는데 LocalDate, LocalTime, LocalDateTime 등등의 클래스를 기본적으로 깔끔하게 처리해주지 못한다.
따라서 이번에는 어렵지는 않지만 새로 프로젝트 구성할 때마다 매번 까먹어서 찾아 헤매던 케이스들을 정리해봤다.
또한 예제의 설명은 스프링 부트를 기준으로 설명하겠다.
우선 Deserialize를 안 본 사람은 해당 내용에서 이어지는 포스트이기 때문에 보고 오도록 하자.
잭슨은 JSON -> Java 클래스로 Deserialize, Java 클래스 -> JSON으로 Serialize 할 때 매우 유용한 라이브러리다.
하지만 잭슨이 나온 이후에 자바 8이 나왔는지 모르겠는데 LocalDate, LocalTime, LocalDateTime 등등의 클래스를 기본적으로 깔끔하게 처리해주지 못한다.
따라서 이번에는 어렵지는 않지만 새로 프로젝트 구성할 때마다 매번 까먹어서 찾아 헤매던 케이스들을 정리해봤다.
또한 예제의 설명은 스프링 부트를 기준으로 설명하겠다.
이 글을 본 다음에는 후속작인 Serialize를 보도록 하자.
이미지 출처: <박상문의 Photo & Essay>평양 육아원의 모습
DB의 테이블과 매칭이 되는 개념이라고 보면 된다.
그렇다면 왜 이름이 Table이 아니라 Entity일까…?
만약 DB에 member라는 테이블이 있고, 해당 테이블의 스키마가 아래와 같다고 해보자.
이 글은 Typescript + TSLint + Mocha + Chai + ts-node + NYC로 모던한 프론트 엔드 테스트 환경 구축하기,
rollup.js를 통해 모듈 번들링하기에서 이어지는 내용이며,
여러 주제를 다루다보니 깊게 다루지는 않고 각각이 무엇을 하는 것인지만 간단하게 설명과 예제를 곁들여 진행하고 있습니다.
또한 예제 진행은 IntelliJ를 통해 진행했습니다.
WebStorm으로 진행해도 상관 없고, VS Code와 진행하면 더 짱짱맨일지도 모르겠습니다.
각 단계 별 깃헙 저장소 브랜치를 제공하고 있고, 이 포스트의 최종 결과물은 front-test-setting 저장소에서 확인 가능합니다.
이 글은 Typescript + TSLint + Mocha + Chai + ts-node + NYC로 모던한 프론트 엔드 테스트 환경 구축하기에서 이어지는 내용이며,
이 글을 본 이후에 travis-ci와 coveralls를 이용하여 좀 더 안전하게 협업하기를 보는 걸 추천드립니다.
여러 주제를 다루다보니 깊게 다루지는 않고 각각이 무엇을 하는 것인지만 간단하게 설명과 예제를 곁들여 진행하고 있습니다.
또한 예제 진행은 IntelliJ를 통해 진행했습니다.
WebStorm으로 진행해도 상관 없고, VS Code와 진행하면 더 짱짱맨일지도 모르겠습니다.
각 단계 별 깃헙 저장소 브랜치를 제공하고 있고, 이 포스트의 최종 결과물은 rollup-umd 브랜치에서 확인 가능합니다.
typescript 컴파일러나, ES2015+ to ES5 트랜스파일러인 바벨의 경우에는 모듈 간의 의존관계를 알지 못한다.
따라서 Webpack이나 Rollup, parcel과 같은 모듈 번들러로 번들링해야한다.
이 글은 rollup.js를 통해 모듈 번들링하기, travis-ci와 coveralls를 이용하여 좀 더 안전하게 협업하기을 읽기 전에 읽어야할 포스트이며
여러 주제를 다루다보니 깊게 다루지는 않고 각각이 무엇을 하는 것인지만 간단하게 설명과 예제를 곁들여 진행하고 있습니다.
또한 예제 진행은 IntelliJ를 통해 진행했습니다.
WebStorm으로 진행해도 상관 없고, VS Code와 진행하면 더 짱짱맨일지도 모르겠습니다.
각 단계 별 깃헙 저장소 브랜치를 제공하고 있고, 이 포스트의 최종 결과물은 nyc 브랜치에서 확인 가능합니다.
ts 브랜치에 예제 파일이 올라가있습니다.
이 포스트는 2017 GDG Seoul에서 Github와 CloudFlare를 이용한 무료 고성능 웹 어플리케이션 호스팅을
주제로 발표하신 박병진 님의 세션을 듣고 삘이 꽂혀서 바로 실행에 옮긴 삽질을 포스팅했습니다.
기본적으로 github page는 지킬이 내장돼있다.
따라서 지킬에서 사용한 템플릿들은 별도의 static html 파일로 빌드하지 않아도 서비스가 가능하다.
하지만 지킬을 설치하기 어려운 환경이거나 윈도우 유저(과거엔 윈도우에서 지킬 설치가 좀 힘들었다.), 비 지킬 유저(hexo, hugo, etc.)의 경우에는
웹 개발을 배울 때 항상 나만의 도메인을 가지고 싶었다.
github.io 라는 간지나는 도메인을 가지고 있긴 했지만, 지킬 내장이라 hexo를 쓰는 나로선 조금의 불편함이 존재했다.
따라서 io 도메인을 사려고 했지만 6만원이 넘어갔다…
그래서 값은 싸지만 나름 구리지 않은 닷컴 도메인을 사기로 마음 먹고 가장 저렴한 곳을 찾았다.
우선 기본적으로 회원가입을 진행해야 한다.
나는 귀찮아서 소셜 로그인(페북)을 이용했다.
그 이후에 메인 페이지로 가서 도메인을 검색하자.
똑같은 도메인이라 하더라도 사람들이 많이 찾는 단어일 수록 가격이 높으니 적당한 단어(자신을 알릴 수 있는?)를 선택하자.
MySQL의 데이터를 Elasticsearch로 마이그레이션 할 때 다음과 같은 방법이 존재한다.
logstash-input-jdbc 같은 경우에는 다음과 같은 단점이 존재한다.
자바스크립트 알고 쓰자. (잘 쓰자는 의미도 담겨있다.)
자바스크립트라는 언어 자체는 내 기준에서는 설계 상 미스가 참 많다.
함수 단위의 스코프, 호이스팅, 동적 타입 등등
자바와 같은 깐깐(?)한 언어를 배우고 바라본 자스는 허점 투성이처럼 보였다.
애초에 자바스크립트는 어떠한 프로그램을 만들기 위해서 탄생했다기 보다는
웹 페이지에 입력값에 대한 유효성 검사(데이터가 공란인지 아닌지 등등)와 같은
페이지의 동적 제어가 주된 목적 + 짧은 개발 기간(넷 스케이프 사의 새로운 브라우저에 탑재 예정) 때문에
설계 상에 미스가 있을 수 밖에 없다고 나는 생각된다.
일종의 안전 장치가 없어서 개발자가 일일이 구현해주고, 신경써야 하는 느낌이었다.
그렇다고 해서 자바스크립트를 극혐하거나 그런 것은 아니고 매우 사랑한다.
또한 그 허점을 아는 사람은 허점을 보완해서 요리조리 피해서 잘 쓰겠지만…
잘 모르는 부분들은 잘못 써도 동작이 잘 되기 마련이다.
이는 지금 당장에는 큰 문제가 안 될지 모르겠지만, 추후에 대규모 웹 어플리케이션을 만들거나
직면할 문제로부터 미리 해방시키기 위해 처음부터 좋은 습관을 들여가는 것이 좋다고 생각한다.
그 열 네 번째 시리즈는 call by value vs call by reference를 주제로 진행하겠다.
Call by 뭐시기 하는 것은 평가 전략(Evaluation Strategy) 중에 하나이며 위키피디아에서는 아래와 같이 서술하고 있다.