네티 프로젝트에 올라온 Q&A를 읽다가 최근에 공부하고 있는 부분과 관련된 질문을 만났다. 우버에서 스파크를 활용해 RemoteShuffleService 라는 오픈소스 프로젝트를 하며 문제를 격고 있었다. 그리고 유사한 이슈가 아파치 스파크 프로젝트에도 있어서 함께 접
오늘 작은 코드를 작성하고 개선해 나가면서 느낀점. 가능하다면 처음부터 잘 만들어 두는 것이 좋다. 나중에 개선해야지 생각하고 너무 쉽게 부채처럼 쌓아두었는데 부족하게 완성된 코드 베이스에서 수정하고 테스트하는데 비용이 생각보다 많이 들었다.처음 경험하는 것을 만들기
최근에 현업에서 바쁘게 일하다보니 확실히 알고 넘어가지 못한 기술적인 궁금증들을 하나씩 해결해 가고 있다. 지난주부터는 네티와 관련된 것들을 깊이 살펴보며 정리했다. 이런 궁금증들을 해결하며 기쁘지만 내심 조금씩 불안하다. 내가 가진 좁은 기술 스펙트럼에서 깊이만을 더
몇 일 작업을 디지털로 쪼개려 하면(예를 들면 변경사항을 세세한 커밋으로 나누어 가면서 코드를 작성하는)일이 잘 진행이 안된다. 그냥 아날로그로 쭉 작성하다(여러 변경이 섞이지만)가 나중에 분류하거 나 안되면 그냥 통째로 커밋한다는 마음으로 하니 집중이 잘 되었다.또
지난 몇 년 동안 네티 프레임워크를 사용하여 우주 지상국 소프트웨어를 개발했습니다. 개발을 진행하면서 저와 동료들이 네티의 특징을 제대로 이해하지 못해 실수 했던 몇몇 경험들이 있는데 그 경험들을 바탕으로 네티의 중요한 구조적 특징들에 대해 나누어 정리해 보려고 합니다
1. “Hello World”로 간단히 빠르게 사용법 익히기 2. 서비스를 만들며 만나는 문제를 깊이 있는 학습 가이드 삼기 3. 테스트 코드로 분명하게 이해하기
계속해서 1시간 이내에 문제 해결이 안되었다. 오랜 시간 고민하고 학습하며 문제를 해결했다. 처음 문제에 접근하며 몇몇 복잡한 조건들이 생각났는데 이미 문제에서 제약 조건을 주고 있었다. 한 번 문제를 읽는 것으로 완
자바의 인터럽트 기능(Thread.Interrupt())을 사용하면 Blocking 동작이 있는 대상 쓰레드의 동작을 안전하게 중단시킬 수 있다. 그러나 인터럽트 기능은 요청자 주도로 대상 쓰레드 실행을 임의로 중단시킬 수 있는 기능이 아니다. 인터럽트는 단지 대상 쓰
비동기적으로 동작하는 코드를 테스트 하기 위해서는 시간이라는 변수를 다룰 수 있어야 합니다. 크게 아래 3가지 범주의 요구가 있습니다.
몇 년 전까지만 해도 직접 쓰레드를 생성하고 해제 해야하는 책임을 가지는 플랫폼에서 주로 개발을 했습니다. 자바 언어로 넘어오면서 쓰레드 풀이라는 개념을 접하게 되었는데, 처음 쓰레드 풀을 접하고 사용 상의 문제는 없었지만 내부 동작을 모르니 어딘지 모르게 찝찝한 부분
Java Stream을 사용해 이렇게 작성된 코드를 보며 의문점이 생겼습니다. 제 생각에는 코드가 다음과 같이 동작할 것 같았습니다.filter 연산에서 스트림의 모든 항목을 순회하며 3보다 작은 항목을 추출한다. findFirst 연산에서 추출된 항목 중 첫 번째 항
어떻게 해결할지 보다, 문제 자체를 바르게 이해하지 못해서 혼란을 겪은 부분이 컸던 것 같다. 크게 아래 3가지 내용에 혼돈을 겪어 문제를 어렵게 바라보게 되었다.파일들이 근접(위, 아래, 대각선 방향)해 있지 않
몇 일 전에 트위터에 올라온 글 덕분에 유튜브에서 영상을 하나 찾아보게 되었다. 연예인 이지혜씨와 프로그래머 출신 남편의 에피소드를 담고 있었다. 개발자인 나에게 뭔가 익숙한 장면이었는데 이지혜씨의
2년차 주니어 개발자의 사수가 되어 보았다. 새로운 회사에 오셔서 완전히 다른 프로그래밍 언어와 프레임워크를 사용해야 했기에 처음에 쉽지 않아 하셨던 것 같다. 동료가 회사에 업무적으로 적응하도록 도운 과정을 회고하며 느끼고 배운 점들을 기록해 본다. 동료는 참고로 (
특정 하드웨어 시스템을 제어하기 위해 Netty 기반 메시징 서버를 개발중입니다. 시험 중 특정 조건이 되면 타겟 시스템에서 일부 메시지를 처리하지 못하는 문제가 발생했는데요. 문제를 해결하기 위해 메시징 서버의 구조를 개선한 사례를 소개합니다.문제가 발생한 서버 시스
개발한 시스템에서 문제가 발생하면 우리가 가장 먼저 만나는 것은 문제의 표면적인 현상입니다. 우리는 문제를 해결해야 하는 엔지니어로서 문제의 현상 이면에 숨겨진 진짜 원인을 찾아야 합니다. 그래야 문제를 해결할 수 있습니다. 어느날 동료에게 전화 한 통을 받았습니다.