새로운걸 공부하고 기록하는 것을 좋아합니다.

DevLog

Hey SlackBot, 업무 처리해줘

Hey SlackBot, 업무 처리해줘

Lambda@Edge로 서버 비용 다이어트하기

Lambda@Edge로 서버 비용 다이어트하기

더 나은 테스트 방식에 대한 생각

Given-When-Then

더 나은 테스트 방식에 대한 생각

Given-When-Then

멀티 모듈 간의 DI(Dependency Injection)

멀티 모듈 간의 DI(Dependency Injection)

Spring Batch 톺아보기

Spring Batch 톺아보기

Lock으로 DeadLock과 맞서 싸우기

Lock으로 DeadLock과 맞서 싸우기

Pinpoint로 하는 모니터링 구축

Pinpoint로 하는 모니터링 구축

Prometheus와 Grafana로 하는 모니터링 구축

Prometheus와 Grafana로 하는 모니터링 구축

Pre-Signed URL과 Signed URL로 S3 안전하게 사용하기

Pre-Signed URL과 Signed URL로 S3 안전하게 사용하기

Java로 PDF 그리기

Java로 PDF 그리기

Docker로 Local 개발 환경 세팅 with IntelliJ

Docker로 Local 개발 환경 세팅 with IntelliJ

Multipart/form-data와 Validation의 관계

Multipart/form-data와 Validation의 관계

FCM으로 App Push 구현하기

FCM으로 App Push 구현하기

Docker를 타고 EC2에서 ECS로

Docker를 타고 EC2에서 ECS로

Github Labels와 함께하는 CI/CD 리팩토링

Github Labels와 함께하는 CI/CD 리팩토링

OAuth2.0(카카오, 애플) 도입

OAuth2.0(카카오, 애플) 도입

S3 Object에 대한 FE 캐싱 issue

S3 Object에 대한 FE 캐싱 issue

LifeLog

유저에서 직원으로, 변화를 두려워하지 않았으면 좋겠어요.

유저에서 직원으로, 변화를 두려워하지 않았으면 좋겠어요.

스타트업에서 주니어 개발자 혼자서 살아남기

스타트업에서 주니어 개발자 혼자서 살아남기

Book

후기

제일 처음 저는 C언어를 공부했기 때문에 절차지향적 언어에 익숙해져 있었습니다.

자바를 갓 공부하고 난 후 객체지향에 대한 개념을 완벽하게 이해할 수 없었고 '토끼책'으로 유명한 이 책을 접했습니다.

260페이지쯤의 가벼운 분량과 이상한 나라의 앨리스를 통한 비유는 책에 대한 거부감을 말끔히 없애주었습니다.

초반엔 책을 읽으며 답답한 느낌이 들었습니다.

스스로 생각하도록 뇌를 계속해서 찌르지만 정작 코드는 단 한 줄도 없었기 때문에 무엇을 말하는건지 이해하기 어려웠습니다.

하지만 읽다보니 자연스럽게 객체지향에 대한 개념들이 뇌 속으로 녹아 들어왔고

자바를 공부할 때 배운 '붕어빵틀과 붕어빵' 에서 벗어나 객체들을 협력의 관점에서 바라볼 수 있었습니다.

깨달음을 얻은 이후엔 책의 내용이 재밌었습니다. 심지어 놀라웠습니다.

객체지향에 대한 매력을 제대로 느낄 수 있었으며 코드 한 줄 없던 내용으로 머릿 속에서 코드가 상상되기 시작했습니다.

때마침 스프링 공부를 시작하게 되며 객체지향의 진가를 더욱 느낄 수 있었습니다.

객체지향의 사실과 오해

1장. 객체 생성과 파괴

아이템8. finalizer와 cleaner의 사용을 피하라

자바에서 제공하는 두 가지의 객체소멸자 (느리고 위험하고 불필요하다)

GC가 이미 충분히 그 기능을 해주고 있다.

직접 객체를 소멸시키려면 AutoClosable을 구현하고 try-resources 또는 close()를 호출하자

finalizer와 cleaner는 2차 안전망 같은 것 (GC가 놓친걸 언제가 될지 모르나 처리해줌)

아이템9. try-finally보다는 try-with-resource를 사용하라

try-finally를 중첩하여 사용하게 되면 두번째 예외에 의해 첫번째 예외가 무시돼 디버깅이 어려워질 수 있다

try-with-resource를 사용하면 무시되는 예외는 suppressed가 붙어서 표시된다.

이펙티브 자바 3판

자바 ORM 표준 JPA 프로그래밍

Chapter 1. 코드 품질

소프트웨어는 코드로 만들어진다.

코드가 의도한 대로 작동하고 기존의 기능이 여전히 잘 작동한다고 확신하기 위한 다양한 과정과 점검이 이루어진다.

이러한 과정을 종종 소프트웨어 개발 및 배포 프로세스라고 부른다.

개발자가 코드베이스의 로컬 복사본을 가지고 작업하면서 코드를 변경한다

작업이 끝나면 코드 검토를 위해 변경된 코드를 가지고 병합 요청을 한다

다른 개발자가 코드를 검토하고 변경을 제안할 수 있다

작성자와 검토자가 모두 동의하면 코드가 코드베이스에 병합된다

배포는 코드베이스를 가지고 주기적으로 일어난다.

테스트에 실패하거나 코드가 컴파일되지 않으면 코드베이스에 병합되는 것을 막거나 코드가 배포되는 것을 막는다.

고품질 코드는 일반적으로 좀 더 신뢰할 수 있고 유지보수가 쉬우며, 버그가 적은 소프트웨어를 생산한다.

좋은 코드, 나쁜 코드

Chapter1. 도메인 모델 시작하기

도메인이란?

개발자 입장에서 바라보면 온라인 서점은 구현해야 할 소프트웨어의 대상이 된다.

온라인 서점 소프트웨어는 온라인으로 책을 판매하는 데 필요한 상품 조회, 구매, 결제, 배송 추적 등의 기능을 제공해야 한다.

이때 온라인 서점은 소프트웨어로 해결하고자 하는 문제 영역, 즉 도메인에 해당한다.

한 도메인은 다시 하위 도메인으로 나눌 수 있다.

예를 들어 온라인 서점 도메인은 몇 개의 하위 도메인으로 나눌 수 있다.

특정 도메인을 위한 소프트웨어라고 해서 도메인이 제공해야 할 모든 기능을 직접 구현하는 것은 아니다.

많은 온라인 쇼핑몰이 자체적으로 배송 시스템을 구축하기 보다는 외부 배송 업체의 시스템을 사용하고 배송 추적 정보를 제공하는 데 필요한 기능만 일부 연동한다.

도메인 전문가와 개발자 간 지식 공유

요구사항은 개발의 첫 단추와 같다.

첫 단추를 잘못 끼우면 모든 단추가 잘못 끼워지듯이 요구사항을 올바르게 이해하지 못하면 요구하지 않은 엉뚱한 기능을 만들게 된다.

도메인 주도 개발 시작하기

1부. 소개

설계와 아키텍처란?

설계란 무엇인가? 아키텍처는? 둘 사이에는 어떤 차이가 있는가?

아키텍처는 저수준의 세부사항과는 분리된 고수준의 무언가를 가리킬 때 흔히 사용되는 반면, 설계는 저수준의 구조 또는 결정사항 등을 의미할 때가 많다.

하지만 이러한 구분은 무의미하며 저수준의 세부사항과 고수준의 구조는 모두 소프트웨어 전체 설계의 구성요소다.

소프트웨어 아키텍처의 목표는 필요한 시스템을 만들고 유지보수하는데 투입되는 인력을 최소화하는데 있다.

설계 품질을 재는 척도는 고객의 요구를 만족시키는데 드는 비용을 재는 척도와 다름없다.

새로운 기능을 출시할 때마다 엔지니어링 직원 수는 증가하지만 코드 라인 수는 증가가 더뎌진다.

이걸 통해 코드 라인당 비용이 증가한다는걸 알 수 있고 이러한 비용 곡선은 사업 모델의 수익을 엄청나게 고갈시키며, 회사의 성장을 멈추게 하거나 심지어는 완전히 망하게 만든다.

클린 아키텍처

운영체제

메모리 관리 전략

가상 메모리

캐시 메모리

네트워크

네트워크 계층

기술 면접 대비 CS전공 핵심요약집

1장. 사용자 수에 따른 규모 확장성

웹 계층의 확장

수직적 규모 확장 vs 수평적 규모 확장

소위 스케일 업이라고도 하는 수직적 규모 확장 프로세스는 서버에 고사양 자원(CPU, RAM)을 추가하는 행위를 말한다.

반면 스케일 아웃이라고도 하는 수평적 규모 확장 프로세스는 더 많은 서버를 추가하여 성능을 개선하는 행위를 말한다.

서버로 유입되는 트래픽의 양이 적을 때는 수직적 확장이 좋은 선택이며, 이 방법의 가장 큰 장점은 단순함이다.

그러나 불행하게도 이 방법에는 몇 가지 심각한 단점이 있다.

수직적 규모 확장에는 한계가 있으며, 한 대의 서버에 CPU나 메모리를 무한대로 증설할 방법은 없다.

가상 면접 사례로 배우는 대규모 시스템 설계 기초 1

1. 소개

역사는 1979년 스웨덴의 TcX라는 회사의 터미널 인터페이스 라이브러리인 UNIREG로부터 시작된다.

버전 1.0은 TcX 사내에서만 사용되다가, 1996년 일반인에게 공개됐다.

그리고 2000년 TcX에서 MySQL AB라는 회사로 독립함과 동시에 FPL 라이센스 정책으로 바뀌고, 2006년 최종적으로 현재와 같은 두 가지 라이센스 정책을 취하게 된다.

이후에 썬마이크로시스템즈에 인수되고, 다시 오라클에 인수됐다.

MySQL의 라이센스 정책은 엔터프라이즈 에디션과 커뮤니티 에디션으로 두 가지이며, 두 에디션의 소스코드는 동일하고 오픈소스로 공개된다.

MySQL 5.5 이전버전까지는 얼마나 자주 패치 버전이 릴리즈되느냐의 차이였고, 5.5 버전부터는 엔터프라이즈 에디션의 소스코드는 공개되지 않도록 바뀌었다.

오라클로 인수된 이후부터 MySQL 서버의 소스코드 레벨부터 리팩토링이 시작됐고, 5.5 버전부터 5.7 버전까지는 안정성과 성능 개선에 집중했으며, 8.0 버전부터는 상용 DBMS가 가지고 있는 기능들이 장착되기 시작했다.

“어떤 DBMS를 사용해야 할지 모르겠습니다. 어떤 DBMS가 좋은가요?” 라는 질문에 항상 “자기가 가장 잘 활용할 수 있는 DBMS가 가장 좋은 DBMS입니다.” 라고 답변한다.

답변을 듣고도 아직 고민된다면 안정성, 성능과 기능, 커뮤니티나 인지도 순서로 고려하라.

Lecture

•

[운영체제] 컴퓨터 공학 전공 필수 올인원 패키지

•

[시스템 프로그래밍] 컴퓨터 공학 전공 필수 올인원 패키지

•

[네트워크] 외워서 끝내는 네트워크 핵심이론 - 기초

•

[네트워크] 외워서 끝내는 네트워크 핵심이론 - 응용

Study

Back-End

6

DataBase

2

Infra

3

Etc

2