Spring batch를 Parallel로 돌려보자

Monolithic 아키텍처 환경에서 가장 잘 돌아가는 어플리케이션 가운데 하나가 배치 작업이다. 모든 데이터와 처리 로직들이 한군데에 모여있기 때문에 최소한의 비용으로 빠르게 기능을 돌릴 수 있다. 데이터 존재하는 Big Database에 접근하거나 Super Application Server에 해당 기능의 수행을 요청하면 된다. 끝!!! 하지만 요즘의 우리가 개발하는 어플리케이션들은 R&R이 끝없이 분리된 Microservices 아키텍처의 세상에서 숨쉬고 있다. 배치가 실행될려면 이 …

Continue reading ‘Spring batch를 Parallel로 돌려보자’ »

Frontend crossdomain issue in IE

최근에 서비스를 오픈하면서 겪은 경험담 하나 정리해볼려고 한다. 백엔드 개발자로써 격는 크로스도메인 이슈를 통칭해서 CORS와 관련된 문제라고 이야기한다. API에 대한 요청이 동일 도메인이 아닌 경우에 발생할 수 있는 이슈다. 대부분 정책적인 문제와 관련된 것이라 도메인에 대한 접근 제어 혹은 권한 제어를 통해 해결의 실마리를 찾는다. 이 비슷한 문제가 Frontend쪽에서도 발생할 수 있다는 걸 작업 과정에서 …

Continue reading ‘Frontend crossdomain issue in IE’ »

좋은 코드에 대한 생각 – 3: 작업에 대한 기록

개발이라는 건 기록의 작업이다. 코드 한줄을 작성하더라도 이유없는 코드가 없다. 이런 이유로 코드를 작성할 때 그 근거를 기록으로 남길려고 하고 권장한다. 당신은 어떤 방식으로 기록하고 있나? Jira와 같은 티켓 관리 시스템을 이용할 수도 있겠고, 혹은 Confluence에 일지를 쓸수도 있겠다. 하지만 당신이 개발자라면 이 문제를 개발자스럽게 풀고 있을 것이라고 생각한다. 코멘트? 가장 흔하게 생각할 수 있는 …

Continue reading ‘좋은 코드에 대한 생각 – 3: 작업에 대한 기록’ »

변수명으로 Readability 높이기?

코드 리뷰를 하다보면 약간 복잡한 expression 혹은 statement의 결과를 변수로 치환한 다음에 아래에서는 그 변수를 사용하는 경우가 있다.  변수의 값 참조가 여러번 이뤄지면 문제가 아니지만 갸우뚱하게 되는 케이스는 한번만 사용하는 경우다.  대부분의 자동화 분석 도구는 이런 경우에 대해 고치라는 처방전을 준다.  하지만 나는 기계가 아니라 사람이고 사람이 보기에 복잡해보이는 걸 두는 것보다는 “변수가 의미를 설명해주는데 …

Continue reading ‘변수명으로 Readability 높이기?’ »

좋은 코드에 대한 개인적인 생각 – 2

개발자는 코드를 작성해야한다.  그리고 코드들이 엮이고 엮여 시스템이 만들어진다.  시스템은 필요를 요청한 사용자에게 기능을 제공한다.  물론 시스템을 구성하기 위해 필요한 노력을 개발자만 하는 건 아니다.  인프라 엔지니어는 장비와 네트워크를 준비하고, 데이터베이스 엔지니어는 데이터를 보관할 수 있는 저장소를 준비한다.  최근에는 Data Scientist가 데이터를 분석하고 빅데이터 도구를 통해 적절한 값들을 생성해낸다. 이외에도 다양한 노력들이 합쳐져 시스템이 만들어진다. …

Continue reading ‘좋은 코드에 대한 개인적인 생각 – 2’ »

PathVariable에 Slash(/)가 값으로 처리하기

RESTful 방식에서 URI는 Resource에 대한 접근을 어떤 방식으로 허용할지를 결정하는 중요한 요소이다.  당연히 특정 리소스의 구성 요소를 지정하는 방식으로 PathVariable을 사용해야한다. 대부분의 경우에는 별 문제없이 사용할 수 있지만 PathVariable에 특수문자가 들어오는 경우에 예상외의 오류가 발생하는 경우가 있다.  이런 대표적인 특수 문자가 Slash(/)이다.  Slash가 문제가 되는 이유는 짐작하겠지만, 이걸로 인해서 URI의 Path Separation이 발생하기 때문이다. API …

Continue reading ‘PathVariable에 Slash(/)가 값으로 처리하기’ »

NamedApiEndpoint: 마이크로서비스를 더욱 더 마이크로하게!

마이크로서비스 아키텍처가 개발자에게 주는 가장 좋은 점 가운데 하나는 배포의 자유로움이다. 일반적으로 마이크로서비스를 지향하는 서비스 시스템은 Monolithic 서비스과 대조적으로 제공하는 기능의 개수가 아주 작다.  따라서 고치는 것이 그만큼 훨씬 더 자유롭다.  Jenkins의 Build now 버튼을 누르는데 주저함이 없다고나 할까… 하지만 얼마나 잘게 쪼갤 것인가? 큰 고민거리다. QCon 컨퍼런스에서도 이야기가 있었지만, 최선의 방식은 가능한 작게 쪼개는 …

Continue reading ‘NamedApiEndpoint: 마이크로서비스를 더욱 더 마이크로하게!’ »

QCon 컨퍼런스를 다녀와서

3월 6일부터 8일까지 3일 동안 영국 런던에서 있었던 QCon 컨퍼런스에 다녀왔다. 컨퍼런스라는걸 다녀볼 수 있는 기회가 없었다.  국내 컨퍼런스는 몇번인가 다녀봤지만 기대했던 것에 비해서 얻는게 너무 없었다.  그렇다고 해외 컨퍼런스를 회사 다니면서 가볼 기회가 쉽게 주어지지 않았다.  사실 기회가 한번인가 있긴 했지만 “치사하고 더러워서” 포기하고 말았었다.  회사를 이직 한 후 작년 4월에 O’Reilly Architecture 컨퍼런스에 …

Continue reading ‘QCon 컨퍼런스를 다녀와서’ »

좋은 코드에 대한 개인적인 생각 – 1

사람들과 코드 리뷰를 하거나 면접을 보거나 하면서 다양한 코드를 접한다. 좋은 코드도 많이 봤다.  하지만 그보다 더 많은 나쁜 코드들도 봤다.  더구나 그런 코드들을 작성하는 분들이 경력 10년차 이상이라는 사실이 더 사람을 참담하게 만들었다. 경력이 비래해서 공통적으로 IT, 개발 사상에 대한 나름의 기준을 정립한 분들이다.  아마도 다른 곳에서는 본인이 다른 사람을 리딩하는 역할도 하고, 멘토링도 …

Continue reading ‘좋은 코드에 대한 개인적인 생각 – 1’ »

Springboot에서 Exception을 활용한 오류 처리

Java를 가지고 개발하는 오류 처리는 Exception을 활용하는 것이 정석이다.  개인적으로 값을 오류 체크하고 어떻게든 값을 만들어 반환하기보다는 오류가 발생하면 “오류다!” 라고 떳떳하게 선언하는 것이 좋은 방법이라고 생각한다. RESTful API를 구현한 경우,  오류의 상태를 알려주는 가장 정석적인 방법은 HTTP Status Code를 활용하는 방법이다.  Exception을 통해서 이 응답 코드를 반환해주는 건 아주 쉽다. 이것과 관련해서 약간 말을 …

Continue reading ‘Springboot에서 Exception을 활용한 오류 처리’ »