August 2, 2023

2023-08-02 TIL

2023-08-02 TIL CNN Convolution: 두 함수를 적당히 섞어주는 연산 한 개의 필터만 있는 것이 아닌, 여러 필터를 통해 여러 출력을 만들어 낼 수 있음 Convolutional Layer, Pooling layer, FC layer 등으로 CNN은 구성이 됨 FC layer는 줄이는 추세, 파라미터의 수가 너무 많기 때문 Stride: 한 번에 필터를 옮기는 step의 크기 Padding: 원래 데이터의 가장자리의 외곽에 값을 채워 넣음 이때 채워 넣는 값의 크기를 padding size라고 함 1 * 1 convolution: 파라미터를 줄이는 효과가 있음 Modern CNN AlexNet GPU의 성능이 부족해서, 두 개의 GPU에서 나눠서 학습을 진행 5개의 convolutional layert과 3개의 dense layer 사용 RELU activation function 사용, Gradient가 1 혹은 0이기 때문에 vanishing gradient problem 일부 해결 Data augmentation을 사용 Dropout 사용 VGGNet 3 * 3 convolutional filter을 사용 5 * 5 하나와 3 * 3 두개는 결과는 같지만 후자가 파라미터 수가 더 적음 GoogLeNet 1 * 1 convolution을 활용해서 parameter를 줄임 같은 크기지만 채널만 줄이는 방향으로 mapping 가능 상기 두 개의 모델에 비해 parameter가 적음 ResNet Parameter의 수가 많으면, overfitting이 발생 Identity map (skip connection)을 추가, 학습이 더 잘 되는 현상을 확인 입력과 출력의 차원이 다를 수 있으므로, 1 * 1 colvolution 사용 3 * 3 앞단과 뒷단에 1 * 1을 붙임.

August 1, 2023

2023-08-01 TIL

2023-08-01 TIL 신경망 신경망: 시작은 인간의 뇌를 모방했으나, 현재 트렌드는 인간의 뇌를 모방한 처음과는 굉장히 많이 달라져 있음 신경망: 함수를 근사하는 모델, 그 과정에서 행렬 곱셈 및 비선형 변환이 수행됨 가장 단순한 형태: Model이 y = wx + b 형태인 linear neural network 최적의 w와 b를 찾는 것이 목표 이 경우 MSE를 사용하면, 최적의 w 와 b에 대해 analytic function이 존재하긴 함 그러나 데이터가 아주 많은 경우 사용할 수 없음 Loss function을 이용해, gradient의 반대 방향으로 w와 b를 업데이트 (학습) 하면 됨 이 과정에서 step size를 잘 조정해야 함.

July 28, 2023

2023-07-28 TIL

2023-07-28 TIL 백엔드 개발자를 위한 보안 강의 시큐어 코딩 버그 없는 서비스는 없음, 언어, 플랫폼, 환경에 종속 모든 버그를 프레임워크가 다 해결해주지는 않음, 보안 버그에 대해 잘 알 필요가 있음 XSS 특정 페이지에 공격자가 임의의 코드를 삽입해서 원하는 코드를 실행시키는 형태 개발자가 할 수 있는 모든 행위를 할 수 있음, 쿠키 및 세션을 탈취해 사용자의 계정을 탈취 가능 Reflected XSS 사용자가 어떤 값을 입력하면 해당 값이 응답 페이지에서 실행되는 취약점 최근 많이 사용하는 Shorten URL이 위험 Stored XSS 공격자가 코드를 게시글 등에 저장해 두고, 다른 사람이 해당 글을 볼 때 실행되는 취약점 DOM-Based XSS URL 주소의 해쉬값을 처리하는 과정에서 발생하는 취약점 Universal XSS 브라우저 취약점으로 인해 불특정 사이트에 XSS 공격하는 취약점 대응 방안 XSS Escape: 사용자 입력한 값을 그대로 실행하면 문제가 되므로, <, >등 특수 문자를 치환.

July 27, 2023

2023-07-27 TIL

2023-07-27 TIL Devops 강의 Devops: Development + Operation의 약자 개발과 운영을 통합 개발팀이 배포 파일을 넘겨주면, 운영 팀이 배포하는 것이 전통적 방식 커뮤니케이션 비용 발생 및 원인 파악의 어려움, 배포 주기가 길어짐 DevOps는 개발자가 서비스 개발 및 운영을 같이 수행, 짧은 주기로 배포, 자동화를 통해 운영 공수를 줄임 기존에는 서비스 운영에 개발만큼 많은 지식이 필요 했음 그러나 클라우드 환경이 보편화되고, 자동화 및 모니터링 도구 등의 등장으로 이제는 훨씬 적은 부담으로 가능 Devops의 범위: CI / CD / 모니터링 및 알림 CI: Continuous Integration 코드 병합 및 퀄리티 유지를 위해 다음과 같은 작업 수행 테스트 코드 작성 PR이 올라오면 코드 리뷰 (리뷰 자체는 자동화가 힘듦) 코드 컴파일 및 테스트 코드 실행 (자동화) 코딩 컨벤션 준수 확인 (자동화) 잠재 결함 분석 (자동화) DevOps는 운영 공수를 경감하기 위한 것이고, CI를 통해 문제 있는 코드를 배포하지 않게 하면 이런 운영 공수가 굉장히 줄어듦 CI 도구: Jenkins, GitHub Actions Jenkins: 오래되었고, 다양한 플러그인을 제공하지만, 이 플러그인들의 충돌이나 서버 단의 관리가 필요 GitHub Actions: 준 설치형 CI도구, GitHub와 높은 수준으로 연동되지만, 외부 액션을 바로 사용은 불가 CI 도구의 역할: 컴파일, 빌드, 테스트 코드 실행, 코딩 컨벤션 준수 확인, 잠재 결함 분석 하나라도 실패하면 코드가 병합되지 않도록 해야!

July 26, 2023

2023-07-26 TIL

2023-07-26 TIL Git 협업 강의 Github Flow 진행 순서 브랜치 생성: checkout 대신 역할이 명확한 switch 권장 변경사항을 만들고 커밋: Gitmoji와 같은 커밋 컨벤션도 존재하고, 팀마다 다름 원격 저장소에 브랜치를 push후 main branch에 PR을 보냄 PR에 대한 피드백 반영 최종적으로 Main Branch에 병합 Git Flow 여기에서 유래된 브랜치를 만드는 전략 메인 브랜치와 수명이 유한한 서포팅 브랜치 두 가지 존재 master: production-ready인 코드만 존재하는 메인 브랜치 develop: 다음 릴리즈를 위한 최신 기술이 반영된 메인 브랜치 feature: 병렬적으로 새로운 기능 추가를 위한 서포팅 브랜치, develop에만 merge 가능 release: production 릴리즈를 위한 서포팅 브랜치, develop으로부터 생성해서 master에 merge hotfix: 프로덕션의 문제를 긴급하게 수정하는 서포팅 브랜치 master에서 생성해서 master에 merge master에 merge한 후 develop에도 merge해야 함 Git 기초 강의 git merge는 항상 코드가 반영될 branch에서!

July 23, 2023

Item 7

Item 7 다 쓴 객체 참조를 해제하라 자바에서는 가비지 컬렉터가 존재하고, 이는 다 쓴 객체를 알아서 회수해 감 프로그래머의 생산성을 높임 그러나 이는 메모리 관리를 하지 않아도 된다는 뜻은 아님 더 이상 사용하지 않는 객체가 있어도, 참조를 남겨둔다면, gc의 대상이 되지 않음 Stack 예시 보통 stack을 pop 할때 다음과 같이 구현 public Object pop() { if (size == 0) { throw new EmptyStackException(); } return elements[--size]; } 이 방법을 수행하면, 원래 element[size] 위치에 존재하던 객체는 사용되지 않음 그러나 element 배열에서 객체에 대한 참조 자체는 남아있게 됨 따라서 gc가 객체를 회수해 가지 못하게 됨 다음과 같이 참조를 해제하는 코드를 추가 public Object pop() { if (size == 0) { throw new EmptyStackException(); } Object result = elements[--size]; elements[size] = null; // 객체 대신 null을 넣어 객체에 대한 참조를 해제 return result; } 이 방법을 사용하면 잘못된 객체를 참조하려고 하는 경우, NullPointerException을 통해 확실하게 예외를 던질 수 있음 주의 사항 그러나 이렇게 null 처리를 매번 할 필요는 없음 null 처리는 프로그램을 필요 이상으로 지저분하게 만드므로, 예외적인 경우에만 수행하면 됨 위 stack 예제와 같이 직접 메모리를 관리하는 클래스에서는 수행해 줘야 함 캐시 역시 메모리 누수를 일으킬 수 있음 객체 참조를 캐시에 넣은 후, 오랜 기간 방치될 수 있기 때문 WeakedHashMap을 통해 캐시를 만들면 엔트리가 살아 있는 동안만 참조하고(약한 참조), 다 쓰이면 gc가 수거해 감 Listener 혹은 Callback 역시 메모리 누수의 원인 콜백을 등록하고 해지하지 않으면, 콜백이 계속 쌓이게 됨 콜백을 약한 참조로 설정하면, gc의 수집 대상이 되어 수거해 감 메모리 누수는 겉으로 잘 드러나지 않기 때문에, 늘 예방법을 잘 알아야 함 꼼꼼한 코드 리뷰 및 디버깅 도구를 잘 사용하는 것도 중요 References 조슈아 블로크 - Effective Java 3/E

July 22, 2023

Item 6

Item 6 불필요한 객체 생성을 피하라 불필요하게 객체를 생성하는 과정을 줄이는 것이 좋음 만약 똑같은 기능의 객체를 여러번 사용해야 한다면, 매번 생성하기보다 객체 하나를 재사용하는 편이 나을 때가 많음 특히 불변 객체는 재사용이 쉬움 다음과 같은 여러 예시 존재 불필요한 객체 생성 예시 - String 다음 코드는 생성자에 인자로 넘겨진 "bikini" 와 생성된 s가 완전히 똑같음 // 불필요한 객체 생성의 예시 String s = new String("bikini"); 따라서, 불필요한 객체 생성을 수행할 필요 없이 다음과 같이 쓰면 됨 // 다음과 같이 쓰면 됨 String s = "bikini"; 비싼 객체 생성 예시 다음 코드는 매 번 함수가 호출될 때마다 String.

July 21, 2023

Item 5

Item 5 자원을 직접 명시하지 말고 의존 객체 주입을 사용하라 클래스는 내부적으로 하나 이상의 자원 (다른 클래스)에 의존하는 경우가 많음 이 자원에 따라 사용하는 동작이 달라지는 경우가 존재 가능 이 때는 정적 유틸리티 클래스 혹은 싱글턴을 사용하는 것은 좋은 선택이 아님 또한 클래스가 직접 자원을 만들게 하는 것도 좋은 방법이 아님 (유연성이 떨어짐) 이를 해결하기 위해 의존 객체 주입 방식을 사용하면 됨 대표적인 의존 객체 주입 방식은 인스턴스를 생성할 때, 생성자에 필요한 자원을 넘겨주면 됨 혹은 생성자에 자원의 팩터리를 넘겨주는 방법이 존재 그러나 이렇게 의존성을 주입하는 방식은 코드를 과하게 복잡하게 만들 수 있음 Dagger, Guice, Spring 등의 의존 객체 주입 프레임워크를 활용하면 이 문제를 해결 가능 References 조슈아 블로크 - Effective Java 3/E

July 19, 2023

Item 3

Item 3 Private 생성자나 열거 타입으로 싱글턴임을 보증하라 싱글턴이란 인스턴스를 하나만 생성할 수 있는 클래스 그러나 이렇게 싱글턴으로 만든 경우 이를 사용하는 클라이언트를 테스트하기 힘듦 각 테스트마다 독립적인 인스턴스를 만들 수 없기 때문 싱글턴 인스턴스는 정확히 하나만 존재하기 때문에, mock으로 대체할 수 없음 싱글턴 인스턴스를 만들기 위해서는 private 생성자를 사용하거나 열거 타입을 사용 가능 Private 생성자 - public 필드 사용 public class Demian { // 싱글턴 인스턴스, 이 값을 초기화 할 때 딱 한번만 생성됨 public static final Demian instance = new Demian(); // private 생성자이므로, 외부에서 이 클래스의 인스턴스를 생성 불가능함 private Demain() { .

July 18, 2023

Item 2

Item 2 생성자에 매개변수가 많다면 빌더를 고려하라 생성자에 매개변수가 아주 많고, 대부분의 경우 각 필드의 기본 값이 있는 경우, 점층적 생성자 패턴 사용 가능 이 패턴은 사용이 불가능한 것은 아니나, 매개변수가 많아질 수록 코드를 작성하고 읽기 어려움 생성자에 각 필드의 기본값을 세팅하고 이후 setter를 사용하는 방법 자바빈즈 패턴도 존재 이 패턴은 객체 하나를 만들려면 setter 메서드를 여러 개 호출해야 함 또한 객체가 완전히 생성되기 전에 일관성이 깨진 상태로 존재할 수 있다는 점이 문제 또한 클래스를 immutable로 만들 수 없음 이런 방법들의 대안으로 나온 것이 빌더 패턴 필수 매개변수만으로 생성자를 호출해 빌더 객체를 획득 이후 빌더 객체가 제공하는 메서드들을 호출해서 매개변수를 설정 마지막으로 매개변수가 없는 build 메서드를 호출해서 목표한 (불변) 객체를 획득 읽고 쓰기 쉬우며, 유연하게 여러 타입의 객체를 만들 수 있음 코드 예시 빌더 public class User { private final String name; private final int id; private final int level; private final int itemCount; private final int power; // 클래스 내부에 public한 static 빌더 클래스를 넣음 public static class UserBuilder { // 필수 매개변수는 초기화 하지 않음 private final String name; private final int id; // 선택 매개변수만 기본 값으로 초기화 private int level = 0; private int itemCount = 0; private int power = 0; // 생성자는 필수 매개변수만 public UserBuilder(String name, int id) { this.