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: 작업에 대한 기록’ »

Slack as a slack – 슬랙을 슬랙답게 쓰자

일상 생활에서 여러 메신저 어플을 사용하지만, 업무용 메신저도 따로 있다. 다른 분들은 카톡이나 라인 같은 어플을 업무용으로도 사용할지도 모르겠다. 하지만 개인용 메신저 어플에게 회사의 정보를 믿고 맞긴다는건 말이 안된다. 항상 “사고”는 존재하기 때문이다. 업무용 메신저는 따로 사용해야한다. 큰 기업인 경우 자체적으로 사내 메신저를 만들어서 사용하는 케이스를 본다. 네이버의 경우에도 사내 메신저를 PC부터 모바일까지 죄다 자체적으로 …

Continue reading ‘Slack as a slack – 슬랙을 슬랙답게 쓰자’ »

다중 도메인을 위한 HTTPS Certification 생성 방법

HTTP 환경에서 서비스를 제공하는건 여러모로 불안하다.  단순한 Packet sniffing에도 데이터가 탈취되니 말이다.  이렇게 말하지만 이 사이트 자체도 https를 사용하지 않으니 할말은 없다. 그럼에도 불구하고 회사를 통해 제공되는 서비스는 안전함을 우선해야 한다. 그렇기 때문에 HTTPS 방식으로 서비스를 제공해야하고.  개별 장비에 대한 인증서 생성을 위해서는 Certification 생성을 위해서는 CSR과 KEY 파일을 생성해야 한다.  한 도메인에 대한 생성은 …

Continue reading ‘다중 도메인을 위한 HTTPS Certification 생성 방법’ »

Reading note for Summary of Drive

간만에 책을 읽긴 읽었는데, 제대로 읽은건 아니고… 사고보니 이게 Summary 북이네? Conference에서 Leadership 관련된 세션을 듣다가 이 책은 꼭 읽어야 한다는 이야기를 들었는데, Summary라고 하더라도 왜 그렇게 추천을 했는지 이해가 갈만한 것 같다. Motivation 1.0 – the early operating system(started fifty thousand years ago) which means that we work because we were trying to physically …

Continue reading ‘Reading note for Summary of Drive’ »

Kafka를 이용한 메시징 시스템 구성하기

최근의 개발 경향은 확실히 마이크로서비스를 지향한다.  가능하면 작은 어플리케이션을 만든다.  그리고 이 어플리케이션들의 소위 콜라보(Collaboration)로 하나의 시스템이 만들어진다.  혹은 만들어지게 구성을 한다.  이와 같은 마이크로서비스 모델이 주는 이점은 나도 몇 번 이야기를 했고, 많은 사람들이 장점에 대해서 구구절절하게 이야기하기 때문에 말을 더 하지는 않겠다. 여기에서 급질문!!  작은 어플리케이션… 근데 작은 어플리케이션을 지향하는 마이크로서비스의 문제점은 없을까? …

Continue reading ‘Kafka를 이용한 메시징 시스템 구성하기’ »

Docker를 활용한 Singlepage 웹앱(WebApp) 구현 환경 구성하기

최근의 개발은 Single page 웹앱 형태로 웹 페이지를 개발하고 있다.  이전 회사에서는 웹앱이라는 개념도 제대로 몰랐는데… 장족의 발전이다. 웹앱 개발 방식이 개발자 관점에서 좋은 점은 Frontend와 Backend를 명백하게 구분할 수 있다는 점이다. 백엔드는 Business Logic을 중심으로 Restful API 방식으로 개발한다.  UI를 배제하고 로직에 집중할 수 있고, 테스트 케이스도 작성할 수 있기 때문에 제대로 개발한다라는 느낌을 …

Continue reading ‘Docker를 활용한 Singlepage 웹앱(WebApp) 구현 환경 구성하기’ »

Pair Programming을 위한 준비 사항

간만에 짝 프로그래밍(Pair Programming)을 해보고 있다. (이후부터는 그냥 페어 프로그래밍) 이 방법을 에자일과 XP 책들을 읽으면서 “아, 이런 방법도 있구나~” 하고 배웠다.  그러고 보면 이 시절에 페어 프로그래밍과 TDD를 포함해 새로운 지식들이 넘쳐나던 시절이었다.  어줍잖은 자신감으로 진행했던 프로젝트의 실패와 더불어 회사의 자금 사정 악화로 경제적으로 빈궁한 시절이었다. 하지만 실패를 곱씹는 과정에서 챙긴 지적 호기심은 이후에 …

Continue reading ‘Pair Programming을 위한 준비 사항’ »

개발자의 missing commitments에 대해.

한다고 한것들(commitments)을 못했을 때(missing)의 것들을 어떻게 받아들여야 할지 애매해서 좀 찾아봤는데 재미있는 링크를 찾았다. Agile team missing commitments regularly and complaining about no trust 어떻게 보면 개발자들이 똘똘 뭉쳐서 에자일이라는 것을 해석해버리면 이런 식도 될 수 있겠구나 하는 생각도 든다. 질문의 요지는 스프린트 4개를 하는 동안 개발자들이 40~60% 정도를 빵구를 내고 있다. 하지만 MVP를 만들어낼때까지 …

Continue reading ‘개발자의 missing commitments에 대해.’ »