JooSing님 글 목록 - mysetting

JooSing

System Software Developer@Contec

대전

Joined on 2021년 06월 13일

5:09 6/13

velog.io

mobile screenshot relative

5:09

velog.io

mobile screenshot

Joo's Work
https://velog.io/@joosing

People and Device Interactive Developer

저작도구: velog

최종 피드 수집: 2023-05-28 18:45

전체 (402)

3d

비지니스 로직과 오케스트레이션 역할 분리하기

단위테스트 책에서 단일책임원칙을 적용하는 사례로 비지니스 로직과 오케스트레이션 역할을 분리하는 케이스를 설명해 준다. 오케스트레이션 이란 비지니스 로직을 수행하면서 협력하는 객체들과 커뮤니케이션하는 역할을 하는 코드를 말한다.

000

5d

이력서, '단순함'과 '구체적' 사이의 절묘한 경계

이력서를 쓰면서 도움이 될 것 같아 '한 문장으로 말하라'는 책을 읽고 있다. 책에서 단순함을 강조하는 KISS (Keep It Simple, Stupid!)라는 원칙 대신, KISS (Keep it Simple and Speci

000

5d

개발 주기에 통합된 테스트

“테스트 코드가 개발 주기에 통합되어 있어야 한다. 실제로 사용되는 테스트만 가치가 있다. 사용되지 않는 테스트는 의미가 없다.” - 단위테스트 (저자, 블라디미르 코리코프) -
이게 생각보다 잘 실천되지 않았던 것 같다. 개

000

12d

개발일기 #124 : 도커와 씨름

오늘 한 작업 목록이다.
도커 Java 애플리케이선 이미지 만들기
도커 이미지 컨테이너로 실행하기
도커 컴포즈로 컨테이너 실행하기
이전 회사에서 도커를 썻으면 운영 서버 하나씩 늘릴 때 마다 하던 작업을 안해도 되었겠다. 쿠버네

000

13d

개발일기 #123 : Docker 재활용되는 삽질의 기쁨

1. Docker 재활용되는 삽질의 기쁨
도커 컨테이너 위에서 서비스를 띄우기 위해 이런 저런 삽질을 하고 있다. 처음 마주한 도커가 던져주는 사소한 문제 해결이 쉽지 않다. 그래도 감사한 것은 이런 삽질을 통해 얻은 경험과 결과

000

14d

개발일기 #122 : 큰 목표를 향한 매일의 동적 계획과 지속

큰 목표를 향한 매일의 동적 계획과 지속
해야할 일들의 목록을 틈틈히 만들고 그것에서 안정감을 얻곤 했던 것 같다. 신기하게도 계획만 보고 어떤 안정감을 얻기도 하고, 반대로 큰 그림이 그려지지 않을 때는 불안해 하기도 한다. 그

000

15d

가치를 위해 행동하는 사람들 (클라우드 유랑단 대전 후기)

클라우드 유랑단 대전 세미나를 다녀왔다. 가까운 곳에서 열리는 기술 관련 세미나라 가벼운 마음으로 참석했다. 출발하려고 네비를 찍었는데 1시간 가까이 걸린다는 사실을 알고 살짝 고민했지만, 그래도 약속한 거니까 출발했다. 돌아보니

000

16d

개발일기 #121 : 스파크 프로젝트, 오픈소스의 축복

스파크 프로젝트 이슈를 다시 읽어본다. 문제가 뭔지 제대로 이해하기 위해서다. 두 번째 읽으니 문제와 해결책이 정확히 이해가 된다. 지난번에는 이 프로젝트에서 문제를 약간 어설프게 해결했다고 생각했는데 그게 아니었다.
이 글(S

000

17d

개발일기 #120 : Readme

Readme
토이 프로젝트 Readme 파일에 대해 고민해 본다. 첫 단락에 이 프로젝트가 어떤 문제를 해결하는지 기술하면 가장 좋다고 생각된다. 대충 뭔가 하게는 만들었는데 무슨 문제를 해결하는지 정확히 모르겠다. 다시 돌아가야

000

17d

개발일기 #119 : 잘되고 있는 일을 바라보고 감사하자

잘되고 있는 일을 바라보고 감사하자
이 글(Appreciating Your Way to XP)을 읽고 정리합니다.
“절망은 변화를 막는다. 변화는 감정적인 에너지를 필요로 한다. 그래서 잘되고 있는 일을 찾고 감사하는 일에도 소홀

000

19d

개발일기 #118 : 방망이 깍던 노인

1. 좋은 테스트 코드
오늘 리팩토링을 하며 중간중간 어제 작성한 테스트 코드를 실행시켰다. 한 번은 코드를 고치고 테스트를 돌렸는데 성공하던 테스트가 실패했다. 확인해 보니 경로에 실수로 “././”이런 문자가 들어가 있었다.

002

20d

개발일기 #117 : 테스트 통과 시키기

1. 테스트 통과 시키기
파일 전송 서비스(토이 프로젝트)에 파일 업로드 기능을 추가했다. 코드가 단지 테스트를 통과했음을 표현하기 위해 커밋 메시지를 ‘Pass the file upload test case’ 처럼 작성해 보았다

000

20d

개발일기 #116 : 훨씬 느리게

1. 꼭 닮은 기술
빅데이터 병렬 처리를 돕는 스파크에 대한 책을 슥슥 읽고 있다. 책을 읽다보니 자바의 병렬 스트림이 생각난다. 둘이 무척 닮아 있다. 자바 병렬 스트림은 하나의 노드(컴퓨터) 안에서 CPU 코어를 병렬로 사용해

000

23d

피할 수 없는 클라우드 물결 (AWS Summit 2023 후기)

계획에 없었는데 AWS 서밋 둘째 날도 참석하게 되었다. 아무것도 준비해오지 않아 급히 서울에 숙소를 잡고 다이소에서 속옷과 양말을 구매했다. 티셔츠는 오늘 받은 굿즈로 해결. 하루 더 남길 잘했다고 생각한다.
진짜 원인이 뭐지?

000

26d

개발일기 #115 : 문제를 만나자 (AWS Summit 2023)

AWS 서밋을 다녀왔다. 접해본적 없는 낯선 것들이 스프링 캠프 때 보다 더 많았다. 저녁이 되어 오늘 들은 것들을 정리하다 보니 정말 많은 기술적인 지원들이 우리 앞에 펼쳐져 있다는 생각이 든다. 정말 점점 비지니스 가치를 만드

000

27d

개발일기 #114 : 아직은 마음대로 주무를 수 없는 HTTP

1. 아직은 마음대로 주무를 수 없는 HTTP
HTTP multipart 타입으로 파일을 보내면 TCP로 전송할 때 보다 훨씬 느렸다. 네트워크 패킷을 까서 보면 궁극적으로 데이터 전송률이 떨어졌다. 한 번에 보내는 데이터 크기도

000

29d

개발일기 #113 : 러닝커브만 넘어서면 단순해 진다 (feat. 첫 웹 API 개발 경험)

1. 러닝커브만 넘어서면 단순해 진다 (feat. 첫 웹 API 개발 경험)
파일 다운로드 클라이언트의 REST API를 구현해 코어 파일 클라이언트 모듈과 연결했다. 그리고 RestAssured를 사용해 통합 테스트를 작성해 보

000

1M

개발일기 #112 : 사용자가 되어보아야 안다

1. 사용자가 되어보아야 안다
사용자와 맞닿은 부분부터 구현했어야 했다. 거꾸로 하고 보니엉망이 되어 있다. 공급자 위주의 구현이 되어 사용이 편리하지 않다. 사용되지 않는 인터페이스들도 생각 보다 많이 만들어져 있어 유연성을 떨

000

1M

개발일기 #111 : HTTP라는 추상화된 표준의 힘

1. HTTP라는 추상화된 표준의 힘
TCP로 구현한 파일 서버-클라이언트를 HTTP로 감싸서 미들웨어 처럼 동작하게 구현하고 있다. 서비스를 HTTP로 한겹 감싸는 것만으로 다양한 도구들의 도움이 눈 앞에 펼쳐지는 것 같다. 직

000

1M

개발일기 #110 : 균형있는 테스트에 대한 엔지니어링 의견

단위 테스트(저자, 블라디미르 코리코프) 책을 조금씩 읽고 있다. 여기서 단위 테스트 스타일을 1)출력기반 테스트, 2)상태기반 테스트, 3)통신기반 테스트로 나눈다.
1. 3가지 단위 테스트 스타일
1) 출력기반 테스트는 간결하

000

1M

병렬 스트림(Parallel Stream)을 활용한 성능 향상

Sprint icons created by Freepik - Flaticon
Stream의 parallel() API를 사용하면 쉽게 병렬 작업을 구현할 수 있습니다. 병렬 스트림은 내부적으로 common ForkJoinPool을

000

1M

개발일기 #109 : 부하 테스트와 모니터링 시도

1. 부하 테스트
부하 테스트란 걸 처음 시도해 보았다. 일단은 내 컴퓨터에 있는 CPU 코어들을 풀로 활용해서 2048개의 클라이언트를 CompletableFuture를 사용해 최대한 동시 접속 처럼 되도록 시도해 보았다. 생각

000

1M

스프링 캠프 2023 후기

강의 전반적으로 모르는 용어, 기술들을 많이 접하게 되었다. 후기를 쓰고 싶었는데 그 날의 강의만 듣고 확실히 이해하지 못한 것들이 많아 후기를 블로그에 남기기가 곤란하다. 그래서 인상깊은 몇 가지만 기록으로 남겨본다.
1. 글로

000

1M

개발일기 #108 : 답변 받고 싶은 프레임 버리기

1. 상대적 복잡함
인프콘 이후로 오랜만에 코엑스에 다녀왔다. 서울이 너무 복잡하게 느껴졌다. 코엑스 안에 있는 테라로사 커피를 찾으며 미로에 갖힌 느낌, 밥을 먹는데도 커피를 마시는데도 길게 줄을 서야 했다. 오후 쯤 되니 복잡

000

1M

개발일기 #107 : 진짜 필요한 일인가?

1. 진짜 필요한 일인가?
파일 서버 응답 테스트를 하다가 저수준의 쓰기 함수는 8MB를 한번에 썻다는 결과를 주는데 TCP 송신 버퍼는 64KB인 걸 발견했다. 쓰기 함수가 TCP 송신 버퍼에 데이터를 쓰고 실제 버퍼에 기록한

000

1M

서버의 응답을 지연시키는 2가지 외부 요인

서버 프로그램을 개발하고 운영하다 보면 서버의 응답이 지연되는 문제를 만날 수 있습니다. 다양한 문제의 원인이 있을 수 있지만, 이 글에서는 서버 외부에서 발생하는 문제의 원인에 집중해 보려 합니다. 모든 설명은 TCP 프로토콜

000

1M

개발일기 #106 : 네트워크 프로그래밍에 대한 소소한 배움들

오늘 실험하고 배운 것들을 소소하게 기록해 봅니다.
1. 네트워크 프로그래밍
네티에서 FieRegion을 통해 네트워크로 파일 쓰기를 요청하면 최종적으로 sun.nio.ch.SocketDispatcher 클래스에서 native

000

1M

개발일기 #105 : 지금부터 'Born to Global'

1. Born to Global
세계적인 네트워크 프로그래머, 테스트 엔지니어가 되고 싶다는 꿈이 생겼다. 만들고 있는 코드의 주석이나 커밋 메시지를 영어로 작성하기 시작하는 것 부터 해야겠다. 예전에 창업 교육을 들으며 Born

001

1M

대용량 파일 서버 성능 개선기 (1) : 작은 청크로 분할 전송

시작하며
네티(Netty) 프레임워크를 사용해 대용량 파일을 처리할 수 있는 서버를 구현했습니다. 그리고 클라이언트에서 대용량 파일(1GB) 패치를 요청하고 패치된 파일이 로컬에 저장되기 까지의 시간을 측정함으로 서버의 성능을 측

000

1M

개발일기 #104 : 선언적으로 일하기

1. 유창한(fluent) 코드
Lombok의 Accessors 어노테이션의 fluent 속성을 사용해서 Getter, Setter 생성을 최적화 할 수 있었다. fluent 속성을 true로 설정하면 some이라는 멤버의 get

001

1M

UDP(Message oriented) vs TCP (Stream oriented)

UDP와 TCP 프로토콜은 여러가지 차이점이 있지만 프로그래밍을 할 때 필수적으로 이해해야 할 숨겨진 개념이 있습니다. 그것은 UDP는 메시지를 기반(Message-oriented)한 프로토콜이고 TCP는 스트림을 기반(Strea

000

1M

개발일기 #103 : 더 나은 코드로 개선

1. 더 나은 코드로 개선
오늘은 어제 설계 컨셉 검증을 위해 급히 작성한 파일 패치 코드를 정리했다. 지금은 파일 패치라는 하나의 요청만 처리하지만 추후 확장이 용이하도록 구조를 잡는데 집중했다. 잘 마무리.
2. 걸으며 생각하

001

1M

개발일기 #102 : 대용량 파일 패치, 68초 → 5초로 성능 개선

1. 대용량 파일 패치, 68초 → 5초로 성능 개선
학습 목적으로 작성한 네티 파일 서버로 1GB 파일을 전송하면 68초의 시간이 걸렸다. 과하다 싶어 내 코드와 네티 코드를 함께 분석해 보았다. 네티의 말단에서 네트워크로 전송

000

1M

try-with-resources에 의해 닫히지 않는 AutoCloseable 인스턴스

Closed icons created by Smashicons - Flaticon
아래와 같은 코드에서 try 블럭 내에서 생성되어 BufferedInputStream에게 전달되는 FileInputStream 인스턴스는 try-w

000

1M

JPA 트랜잭션 내에서 엔티티를 변경할 때 마다 flush 해야하나요?

Data transfer icons created by juicy_fish - Flaticon
JPA 영속성 관리에 대해 공부했다. 예전에 팀에서 백엔드 엔지니어(DB를 다루는)들이 모여서 이것과 관련해서 옥신각신 하던 일이 생각

000

1M

파일 서버에 1GB 파일 패치 요청 실패 (간단한 JVM 튜닝으로 해결하기)

1GB 파일 패치 실패
네티 프레임워크를 사용해 간단한 파일 서버를 구현하고 있습니다. 파일 서버의 성능을 테스트하기 위해 다양한 크기의 파일 패치(Fetch)를 서버에 요청하고 패치된 파일을 로컬 스토리지에 저장하기 까지의 시간

000

1M

개발일기 #101 : 동일한 원리, 다양한 구현

1. 동일한 원리, 다양한 구현
가장 간단한 파일 I/O에서 버퍼 I/O가 캐싱을 활용해서 성능을 높인다고 한다. 디스크(상대적으로 느린)에서 한 번에 많이 가지고 와서 메모리(상대적으로 빠른)에 저장하고 있다가 다음 요청에서는

000

1M

개발일기 #100 : 시작은 미약하지만 끝은 창대하리라

오늘 AWS와 JPA책을 펼쳤다. 작은 시작.
JPA 책을 읽다 보니 SQL 공부도 같이 해야할 것 같음을 직감했다.
이력서를 적을 준비도 시작했다. 이것도 작은 시작.
“Your beginnings will seem humb

000

1M

개발일기 #99 : 새로운 기술을 만나는 여행

1. 미래에 만날 문제를 준비하는 시간
늘 문제를 해결하기 위한 문제 주도의 학습을 강조해 왔지만, 그 반대도 의미 있다. 문제는 아직 만나지 못했지만 기술을 쌓아가는 것이다. 이 과정은 초등교육부터 대학교육까지 많이 받아와서

000

1M

테스트 코드 자체보다, 테스트 코드를 통해 학습한 것이 중요한 경우

Image by pikisuperstar on Freepik
각 단계를 테스트하는 유용함
하나의 큰 기능을 구현하면서 단계 단계 내부 구현을 테스트 코드로 만들어 검증해 보았다. 확실히 큰 덩어리를 테스트 하는 것 보다 일이 단순

000

1M

개발일기 #98 : 나와 러버덕 디버깅

1. 내일의 나에게
오랜만인 것 같다. 오늘을 마치는 컨텍스트를 내일의 나에게 기록해 둔다. 차분하게 하루 하루를 연결해 가야겠다.
2. 나와 러버덕 디버깅
코드를 계획하며 문제를 마주하면 일단 문제에 대해 표현해 보며 문제 해

000

1M

개발일기 #97 : 점점 분명해지고, 점점 커지는 현업의 문제

1. 설명해야 하는 코드
누군가에게 설명해야 되는 코드라고 생각하니 계속해서 단순한 코드를 유지하려 노력하게 된다. 나누는 일도, 합치는 일도 ‘다른 사람에게 설명하기 쉬운가?’ 라는 기준을 적용하니 나아갈 방향이 조금 더 분명해

002

1M

개발일기 #96 : 그냥 하자 직업이니까

1. 그냥 하자 직업이니까
어제 오늘 슬럼프란 느낌이 들었다. 왠지 모르게 일이 잘 풀리지 않았고 하기도 싫은 느낌이 들었다. 직업으로 삼은 나의 일이 대부분 재미있고 흥미로운데 오늘 같은 날은 오랜만이다. 아마도 혼자 공부하는

001

1M

개발일기 #95 : 균형있는 멋진 사람

1. 적당히 일하기
조급한 마음이 내게 있는 것이 사실이다. 이것이 나를 힘들게도 하고 나를 나아가게도 하는 것 같다. 오늘은 코드로 문제를 해결하는 연습을 했다. 그리고 문제를 해결하는 과정을 회고하고 부족한 부분을 매우는 시간

000

1M

코드로 문제해결 연습 > 프로그래머스 > 공원 산책

문제
링크 : 프로그래머스 > Level 1 > 공원 산책
해결 코드
public int[] solution(String[] park, String[] routes) {
// 시작 지점
Point startPoint

000

1M

상상하지 못한 커리어 전환

Photo by Josh Hild on Unsplash
내 손 안의 일
내 커리어는 어떤 면에서 내가 할 수 있는, 내 손 안에 있는 일들의 연속이었다. 내가 할 수 없는 내 손 밖 일들을 지나치게 생각할 때 걱정이 생겼고 때때로

000

1M

개발일기 #94 : 네티 그리고 새로운 길

네티 프로젝트에 올라온 Q&A를 읽다가 최근에 공부하고 있는 부분과 관련된 질문을 만났다. 우버에서 스파크를 활용해 RemoteShuffleService 라는 오픈소스 프로젝트를 하며 문제를 격고 있었다. 그리고 유사한 이슈가 아

000

1M

개발일기 #93 : 중첩에 중첩을 제거하기

1. 가능하면 처음부터 잘만들자
오늘 작은 코드를 작성하고 개선해 나가면서 느낀점. 가능하다면 처음부터 잘 만들어 두는 것이 좋다. 나중에 개선해야지 생각하고 너무 쉽게 부채처럼 쌓아두었는데 부족하게 완성된 코드 베이스에서 수정하

002

2M

개발일기 #92 : 오래 달리기

최근에 현업에서 바쁘게 일하다보니 확실히 알고 넘어가지 못한 기술적인 궁금증들을 하나씩 해결해 가고 있다. 지난주부터는 네티와 관련된 것들을 깊이 살펴보며 정리했다. 이런 궁금증들을 해결하며 기쁘지만 내심 조금씩 불안하다.
내가

000

2M

개발일기 #91 : 쭉 해보고 정리하고 쭉 해보고 정리하고

몇 일 작업을 디지털로 쪼개려 하면(예를 들면 변경사항을 세세한 커밋으로 나누어 가면서 코드를 작성하는)일이 잘 진행이 안된다. 그냥 아날로그로 쭉 작성하다(여러 변경이 섞이지만)가 나중에 분류하거 나 안되면 그냥 통째로 커밋한다

000

2M

Netty 구조적 특징 (3) : 이벤트 루프

Loop icons created by Freepik
지난 몇 년 동안 네티 프레임워크를 사용하여 우주 지상국 소프트웨어를 개발했습니다. 개발을 진행하면서 저와 동료들이 네티의 특징을 제대로 이해하지 못해 실수했던 몇몇 경험들이

000

2M

Netty 구조적 특징 (2) : 비동기

This icon created by Freepik - Flaticon
지난 몇 년 동안 네티 프레임워크를 사용하여 우주 지상국 소프트웨어를 개발했습니다. 개발을 진행하면서 저와 동료들이 네티의 특징을 제대로 이해하지 못해 실수했

000

2M

Netty 구조적 특징 (1) : 쓰레드 모델

Thread icons created by smalllikeart - Flaticon
지난 몇 년 동안 네티 프레임워크를 사용하여 우주 지상국 소프트웨어를 개발했습니다. 개발을 진행하면서 저와 동료들이 네티의 특징을 제대로 이해하

000

2M

(예제와 함께 보는) 기술을 학습하는 3단계

Image by freepik
기술을 학습하는 3단계
1. “Hello World”로 간단하고 빠르게
프레임워크가 제공하는 특정 기술을 처음 학습할 때 간단한 샘플 코드를 작성하곤 하는데 이를 “Hello World”를 찍는다고

000

2M

코드로 문제해결 연습 > 프로그래머스 > 당구 연습

1. 문제
링크 : 프로그래머스 > Level 1 > 당구 연습
2. 해결 시간
1시간 이내에 문제 해결이 안되었다. 오랜 시간 고민하고 학습하며 문제를 해결했다.
3. 문제 해결 코드
import org.junit.jupite

001

2M

(서비스 제공자가 주도하는) 자바 인터럽트

Image by pixabay
자바의 인터럽트 기능(Thread.Interrupt())을 사용하면 Blocking 동작이 있는 대상 쓰레드의 동작을 안전하게 중단시킬 수 있다. 그러나 인터럽트 기능은 요청자 주도로 대상 쓰레드 실

000

2M

제품을 만들며 『Hello World』 이상의 코드 만들기

Image by pixabay
Hello 프레임워크!
보통 프레임워크의 특정 기능을 처음 학습하며 샘플 코드를 작성해 볼 때 “Hello World”를 찍어봤다고 표현하곤 합니다. 요즘 프레임워크들이 워낙 추상화가 잘 되어 있다보

000

2M

비동기 코드의 타이밍 테스트 하기 (with Awaitility)

Image by Freepik
타이밍을 테스트하는 요구사항
비동기적으로 동작하는 코드를 테스트 하기 위해서는 시간이라는 변수를 다룰 수 있어야 합니다. 크게 아래 3가지 범주의 요구가 있습니다.
특정 시간 이내에 조건을 만족하는지

000

2M

Java Thread Pool 동작 원리 (테스트 코드와 함께)

몇 년 전까지만 해도 직접 쓰레드를 생성하고 해제 해야하는 책임을 가진 환경에서 주로 개발을 했습니다. 자바 언어로 넘어오며 쓰레드 풀이라는 개념을 접하게 되었는데, 사용 상의 문제는 없었지만 내부 동작을 모르니 어딘지 모르게 찝

000

2M

Java Stream: 좋은 설계 표본

변하는 것과 변하지 않는 것
오늘 Java Stream에 대해 조금 더 이해하게 되었습니다. Stream은 변하지 않는 템플릿 코드를 추상화된 연산으로 제공하고 (map, filter, etc) 변하는 코드는 동작 파라미터화를 통

000

2M

게으른(Lazy) Java Stream

1. 어설프게 작성된 코드
// 3보다 작은 첫 번째 항목을 찾는다.
return IntStream.of(10, 5, 2, 20, 1)
.filter(num -> num < 3)

000

2M

코드로 문제해결 연습 > 프로그래머스 > 바탕화면 정리

문제
링크 : 프로그래머스 > Level 1 > 바탕화면 정리
문제 해결 코드
import java.util.Arrays;
import java.util.stream.IntStream;
import java.util.stream.

000

2M

프로그래머의 동상이몽

‘인텔리’ 문재완, 검색왕 이지혜 위해 자동 검색 프로그램 선물★ #동상이몽2 #YouareMyDestiny #SBSenter
몇 일 전에 트위터에 올라온 글 덕분에 유튜브에서 영상을 하나 찾아보게 되었다. 연예인 이지혜씨와 프로

000

2M

주니어 개발자의 온보딩을 도운 경험

2년차 주니어 개발자의 사수가 되어 보았다. 새로운 회사에 오셔서 완전히 다른 프로그래밍 언어와 프레임워크를 사용해야 했기에 처음에 쉽지 않아 하셨던 것 같다. 동료가 회사에 업무적으로 적응하도록 도운 과정을 회고하며 느끼고 배운

000

2M

메시지 큐를 활용한, 유연한 전송 구조 만들기

특정 하드웨어 시스템을 제어하기 위해 Netty 기반 메시징 서버를 개발중입니다. 시험 중 특정 조건이 되면 타겟 시스템에서 일부 메시지를 처리하지 못하는 문제가 발생했는데요. 문제를 해결하기 위해 메시징 서버의 구조를 개선한 사

000

2M

Simple Made Easy

강연 영상 : Simple Made Easy - Rich Hickey (2011)
원문 및 번역 : Simple Made Easy
이 글을 읽어서 좋습니다. 강연의 시작에 "Simplicity is a prerequisite fo

000

3M

문제 현상 이면에 숨겨진 원인 찾기: TCP 통신 트러블슈팅

개발한 시스템에서 문제가 발생하면 우리가 가장 먼저 만나는 것은 문제의 표면적인 현상입니다. 우리는 문제를 해결해야 하는 엔지니어로서 문제의 현상 이면에 숨겨진 진짜 원인을 찾아야 합니다. 그래야 문제를 해결할 수 있습니다. 어느

000

3M

좋은 코드를 만드는 이유, 좋은 코드를 만드는 방법

1. 코드를 만드는 이유
개발자가 코드를 작성하는 기본적인 이유는 어떤 기능을 구현한 제품을 만들기 위해서입니다. 그런데 종종 우리는 좋은 코드를 만들어야 한다는 말을 듣습니다. 기능을 똑같이 구현하는데 좋은 코드를 만들어야 하는

000

3M

문제 해결 연습 > 프로그래머스 > 과일장수

문제
링크 : 프로그래머스 > Level 1 > 과일장수
소요 시간
오랜 시간이 걸려서 천천히 학습하면서 문제를 풀었습니다.
문제 해결 코드
import org.junit.jupiter.api.Assertions;
import

000

3M

지식 공유 모델: 넘치는 그릇과 요란한 깡통

지식을 공유하는 일과 관련된 몇 가지 모델이 떠오릅니다.
넘치는 그릇 모델
먼저 그릇에 물이 점점 채워지다 넘쳐 흐르는 모습을 상상해 볼 수 있습니다. 그릇은 부어지는 물을 담아냅니다. 그리고 넘치는 물이 자연스럽게 주변으로 흘

000

3M

Heap 메모리 누수 이슈: 문제의 원인을 찾는 연역적 과정

Image by vectorjuice
문제에 접근하는 두 방향
소프트웨어에 문제가 발생했을 때, 가장 어렵고 오랜 시간이 걸리는 작업은 정확한 원인을 찾는 일이라 할 수 있습니다. 원인만 찾는다면 고치는 일은 크게 어렵지 않은 경

000

3M

쓰레드 누수 이슈: 문제의 원인을 찾는 귀납적 과정

Image by vectorjuice
소프트웨어에 문제가 발생했을 때, 가장 어렵고 많은 시간이 드는 작업은 문제의 정확한 원인을 찾는 일이라 할 수 있습니다. 정확한 원인만 찾는다면 고치는 일은 크게 어렵지 않은 경우가 많습니다

001

3M

시스템이 로그 없이 재부팅됩니다 (연역적 vs 귀납적 접근)

Image by vectorjuice
개발을 시작한지 얼마되지 않았을 때는 프로그램에 버그가 생기면 관련된 부분에 로그를 찍거나, 디버그 모드를 통해 코드를 추적해서 원인을 찾아갔다. 돌이켜 보면 근거가 되는 구체적 사실로부터 문

000

3M

성공하는 코드 서비스들의 숨겨진 철학 (대신하고, 숨기고, 드러나게)

Image by Freepik
성공하는 코드 서비스들은 사용자가 복잡해 하는 기술적인 영역을 대신 구현하고, 그것을 구현한 자신은 서비스 뒤에 숨기며, 사용자가 자신의 비지니스 로직 구현에 집중하고, 비지니스 로직만 코드에 드러

000

3M

왜 비동기 코드를 작성하시나요?

Image by Freepik
왜 비동기 코드를 작성하시나요?
질문에 바르게 답하기 위해서 먼저 동기식, 비동기식에 대한 개념을 정리하고, 코드 구현 상에 어떤 차이가 있는지 직접 Java 예제 코드를 작성해 봅니다. 그리고 두

000

3M

비지니스 로직에 집중하는, 비동기 테스트 코드 만들기 (Awaitility)

최근 몇 년 간 비동기 시스템에서 코드를 작성하고 테스트하는 일이 많아졌습니다. 어느 날 테스트 코드를 작성하고 있는데 테스트 코드에서 비지니스 로직을 표현하는 코드 보다 비동기적인 처리를 위한 기술적인 코드들이 더 많은 것이 눈

000

3M

비동기 시스템 테스트 코드 개선기 (until Awaitility)

이 글에서는 비동기 시스템의 테스트 코드를 개선해 나간 과정을 소개합니다. 이 과정의 끝에는 Awaitility 라는, 스스로를 테스트 라이브러리가 아닌 DSL(Domain-specific language)이라 소개하는 기술이 있

000

3M

테스트할 수 없는 코드 테스트하기 : 서비스 추상화와 목(Mockito) 프레임워크 활용

기술 블로그에 글을 쓰기 위해 샘플 코드를 만들던 중에 콘솔에 로그를 남기는 모듈을 검증하는 코드를 언뜻 작성할 수 없었습니다. 외부 API 서버라면 통신 시뮬레이터라도 만들텐데 콘솔은 그럴 수도 없고, 어떻게 콘솔에 로그를 남기

000

3M

Mock 프레임워크(Mockito)의 핵심 기능 학습 테스트

Java의 대표적인 Mock 프레임워크인 Mockito에서 제공하는 핵심 기능들에 대한 학습테스트 코드를 작성합니다.
학습 테스트 준비
우선 테스트를 위해 테스트 대상 클래스(TestTarget)와 목킹 대상이 될 협력 클래스(C

000

3M

새로운 기회를 향한 이동 (교보문고 리드잇 6호 기고글)

교보문고에서 발간하는 리드잇zine 6호에 회사를 나와서 창업에 기웃거리다 다시 취직을 했던 2019년도 저의 이야기를 기고해 보았어요. 담당자분께 여쭈어보니 블로그에 올려도 괜찮다고 하더라구요. 아래 원고를 공유합니다.
회사와

000

3M

API 통신 컴포넌트 설계와 SOLID 원칙

좋은 기회였던 것 같습니다. 특정 도메인에서 다양한 외부 API 서버와 통신하는 컴포넌트를 연이어 개발할 수 있었습니다. 1년 동안 7개 정도의 통신 컴포넌트를 개발했네요. 통신 프로토콜은 모두 달랐지만 처리하는 구조는 유사했기

000

3M

회사를 떠나며, 매니지먼트에 대한 회고

회사를 떠나며 그 동안 해왔던 일들을 글로 정리하고 동료들에게 가르쳐 주는 일을 2개월 가량 했습니다. 인수인계 과정을 진행해 나가며 동료들이 제 공백을 잘 매꾸어 줄 수 있겠단 생각이 들었습니다. 그런데 몇 일 전 문득 매니지먼

001

3M

문제 해결 연습 | 신고 결과 받기

문제
링크 : 프로그래머스 > Level 1 > 신고 결과 받기
소요 시간
40분
최종 리팩토링된 코드
이름 개선
Map 자료구조의 이름은 keyAndValueMap 형태로 짓는게 코드를 읽고 이해하기 좋은 것 같습니다.
Rep

000

4M

문제 해결 연습 : 성격 유형 검사하기

문제
링크 : 프로그래머스 > Level 1 > 성격 유형 검사하기
소요 시간
70분
해결과정 회고
처음에 문제의 조건을 제대로 이해하지 못하고 문제를 풀었다. choices 입력을 질문지에 대한 응답자의 선택이 아니라 점수라고

000

4M

위기를 기회로 바꿔서 바라보기

익스트림 프로그래밍이라는 책을 작년에 부분부분 읽었다. 몇 장 읽지 않은 책의 내용 중에 "위기를 기회로 바라보라"는 말이 요즘 자주 맴돈다. 다들 위기라고 하는데 나는 기회로 바꾸어 바라볼거다. 이 말이 다만 말이 아니라, 약

000

4M

함께 하고, 나누며 성장하기

인수인계를 진행하며 배우는게 많다. 내가 잘 알고 있다고 느끼던 지식을 다른 사람(특히 완전 초보자)에게 가르쳐 주기 위해 고민하고 설명하다 보니 지식이 훨씬 견고하고 확실해 짐을 느낀다. 이 보다 더 좋은 배움의 길이 없다는 생

000

4M

문제 해결 연습 | 기사단원의 무기

링크 : 프로그래머스 > Level 1 > 기사단원의 무기
문제
숫자나라 기사단의 각 기사에게는 1번부터 number까지 번호가 지정되어 있습니다. 기사들은 무기점에서 무기를 구매하려고 합니다. 각 기사는 자신의 기사 번호의 약수

000

4M

다 쓴 객체 참조에 항상 null 값을 할당해야 하나요?

이런 코드가 있네?
어제 팀에서 작성된 코드 중에 이런 패턴의 코드가 있어서 Effective Java 책의 내용(아이템 7 다 쓴 객체 참조를 해제하라)을 살펴보았습니다.
public void command(String json

000

4M

문제 해결 연습 | 개인정보 수집 유효기간

링크 : 프로그래머스 > Level 1 > 개인정보 수집 유효기간
문제
고객의 약관 동의를 얻어서 수집된 1~n번으로 분류되는 개인정보 n개가 있습니다. 약관 종류는 여러 가지 있으며 각 약관마다 개인정보 보관 유효기간이 정해져

000

4M

꾸준히, 자유롭게, 즐겁게 (도전과 점진적인 개선, 그리고 변화에 열린 마음 : 이희승님)

Netty 프로젝트를 만드신 이희승님의 이야기가 담긴 “꾸준히, 자유롭게, 즐겁게’란 책을 우연히 접하게 되어 구매해서 읽게 되었다. 모르고 샀는데 2013년에 출판된 오래된 책이었다. 책을 읽으며 인상적인 내용들을 기록해 본다.

000

4M

주석을 달지 않는 이유, 달아야 하는 이유

동료와 주석을 달아야 하는지, 달지 말아야 하는지 대화를 하다가 생각난 것들을 정리해봅니다.
1. 주석을 달지 않는 이유
(X) 변수 이름을 그대로 주석으로
예를 들면 이런 주석이 있습니다. frequency 라는 변수명에 주파

000

4M

개발일기 #88 : 어디 이런 일은 없나?

한 두달 내가 작성한 코드와 일들을 공유하기 위해 정리하고 문서화해서 가르쳐주는 일을 반복하게 될 것 같다. 신기한게 일주일 정도 했는데 업무에 만족도가 꽤 높다. 어디 이런 일은 없나 모르겠다.

000

4M

더 나은 테스트 코드 : 일관성, 속도, 가시성

1. 허술한 테스트 코드
연동 모듈의 상태 변경을 요청하고, 상태가 정상적으로 변경되었는지 테스트하는 코드를 작성한다고 합시다. 우리가 원하는 시나리오는 연동 모듈에서 상태 변경 처리가 완료되면, 모듈의 상태를 가져와서 결과를 확

000

4M

크리스찬 삶

교회의 부부모임에서 성경을 읽고 생각을 나누곤 합니다. 거기에서도 개발자의 회고 처럼 한 해를 돌아보는 시간을 가졌는데 한 해 이룬 성과에 대한 이야기를 나눌 시간이 있었습니다. 개발자로서 많은 일을 했는데 크리스찬으로서 내가 믿

000

4M

개발일기 #87 : Java Reflection의 유용함

Reflection
어떤 제약으로 클래스에 some1, some2, some3 처럼 List 없이 쭉 펼쳐진 멤버들이 있었는데 루프를 돌 수 없어 괴로웠다. 현업에서 Reflection을 제대로 사용해 본적이 없었는데 getMet

000

4M

개발일기 #86 : 코딩 테스트와 현업이 다른 점

코딩 테스트와 현업이 다른 점
코딩테스트 연습하듯 현업의 코드 작성을 해보았다. 주석으로 문제를 쪼개서 단계적으로 접근하니 복잡한 문제가 쉽게 보여서 좋았다. 그러나 확실히 다른점은 현업에서는 문제 자체와 오늘 해결할 문제의 크기

000