<img src="https://image.until.blog/steady/article/1727346269489.png" alt="until-1565"><h2>어디에 쓰이나?</h2><hr>한 서비스를 개발할 때 여러 플랫폼의 소셜 로그인 기능을 구현하다가 로그인 플랫폼에 상관없이 각 유저별로 서로를 특정할 수 있는 공통의 값이 필요하게 되었고 나는 닉네임을 필수로 입력받아 이 부분을 처리하려고 했다.하지만 회원을 등록할 때 닉네임을 직접 입력받게 되니 회원가입의 과정이 부자연스러웠고, 닉네임을 입력하지 않고 중간에 이탈할 경우의 데이터 처리가 모호해져 우선 무작위 닉네임을 지정하고 추후 변경하는 프로세스를 생각하게 되었다.그때 필요했던 기능이 이 무작위 닉네임 생성 기능이었다.<h2>개발 과정</h2><hr>가장 먼저 떠올랐던 예시는 썸네일에 사용한 블리자드의 무작위 작명이었다. 무작위로 주어진 단어들을 조합하여 특정한 닉네임을 만들어내는 단순한 기능이였다.우선 내가 개발하는 서비스는 반려동물과 관련된 서비스였기 때문에 동물과 관련된 닉네임을 생성하기로 했고 앞쪽에는 형용사를 뒤쪽에는 동물 이름을 사용해 닉네임을 만들어 보았다.<pre spellcheck="false"><code class="language-java">public class NicknameGenerator {

 // 형용사 배열
 private static final String[] adjectives = {
 "귀여운", "발랄한", "사랑스러운", "똑똑한", "활발한", "졸린", "장난꾸러기", "용감한", "상냥한", "행복한",
 "느긋한", "온화한", "믿음직한", "애교 많은", "웃음 가득한", "엉뚱한", "당당한", "재빠른", "고요한", "부드러운"
 };

 // 동물 이름 배열
 private static final String[] animals = {
 "강아지", "고양이", "햄스터", "토끼", "앵무새", "거북이", "고슴도치", "말티즈", "푸들", "치와와",
 "골든리트리버", "페르시안", "스피츠", "요크셔테리어", "러시안블루", "코뉴어", "페럿", "다람쥐", "이구아나", "비글"
 };

 // 랜덤 닉네임 생성 함수
 public String generateNickname() {
 Random random = new Random();

 // 배열의 길이에 맞춰 랜덤으로 배열 값을 조회
 String adjective = adjectives[random.nextInt(adjectives.length)];
 String animal = animals[random.nextInt(animals.length)];
 // 추가적으로 닉네임 중복을 방지하기 위해 1~999까지의 무작위 숫자 조회
 int number = random.nextInt(1000);

 return adjective + animal + number;
 }
}</code></pre>위 처럼 간단한 무작위 닉네임 생성기를 만들어 보았다.하지만 이걸로는 유저의 닉네임 중복을 완벽히 막을 수는 없어서 DB를 통해 해당 닉네임이 존재하는 지 확인 후 재생성하는 과정도 포함시켜야 한다.<h2></h2><h2>돌아보며</h2><hr><blockquote>개발 후 코드를 보면 간단하지만 차근차근 생각해 나가는 과정이 중요한 것 같다.코드 자동화 기술이 워낙 많이 발전해서 이 정도는 간단하게 작성해주겠지만 백지 상태에서 스스로 생각하면서 만들어봐야 더 기억에 오래 남아 추후에 시간을 절약하게 되는 것 같다.모든 코드를 백지에서 부터 천천히 만들 순 없겠지만, 미래를 위해 자동으로 작성된 코드라면 천천히 작동 방식을 생각해보며 머릿속에 남기며 공부해 나가보자</blockquote>

어디에 쓰이나?한 서비스를 개발할 때 여러 플랫폼의 소셜 로그인 기능을 구현하다가 로그인 플랫폼에 상관없이 각 유저별로 서로를 특정할 수 있는 공통의 값이 필요하게 되었고 나는 닉네임을 필수로 입력받아 이 부분을 처리하려고 했다.하지만 회원을 등록할 때 닉네임을 직접 입력받게 되니 회원가입의 과정이 부자연스러웠고, 닉네임을 입력하지 않고 중간에 이탈할 경우

[Java] 무작위 닉네임 생성기

📚 BOOK

<blockquote>책 내용을 정리하는 것이 아니라, 해당 범위에서 특별히 정리하고 싶은 내용이나 책을 읽으면서 들었던 궁금한 부분을 작성한다.<blockquote>읽다가 갑자기 정리하고 싶은 내용을적기도 한다. 꼬꼬무,,,(꼬리에 꼬리를 무는 공부)</blockquote>궁금한 부분에 대한 답변은 의문이 해소된 후에 작성한다 (영원히 작성되지 않을수도..)</blockquote><h2>정리</h2><h3>팩토리 패턴이란?</h3><ul><li>객체를 사용하는 코드에서 객체 생성 부분을 따로 떼어내 추상화한 패턴</li><li>상속관계에 있는 두 클래스에서 상위 클래스가 중요한 뼈대를 결정하고, 하위 클래스에서 객체 생성에 관한 구체적인 내용을 결정하는 패턴</li></ul><pre spellcheck="false"><code class="language-javascript">class CoffeeFactory {
 static createCoffee(type) {
 const factory = factoryList[type]
 return factory.createCoffee()
 }
} 
class Latte {
 constructor() {
 this.name = "latte"
 }
}
class Espresso {
 constructor() {
 this.name = "Espresso"
 }
} 
 
class LatteFactory extends CoffeeFactory{
 static createCoffee() {
 return new Latte()
 }
}
class EspressoFactory extends CoffeeFactory{
 static createCoffee() {
 return new Espresso()
 }
}
const factoryList = { LatteFactory, EspressoFactory } 
 
 
const main = () =&gt; {
 // 라떼 커피를 주문한다. 
 const coffee = CoffeeFactory.createCoffee("LatteFactory") 
 // 커피 이름을 부른다. 
 console.log(coffee.name) // latte
}
main()</code></pre><h3>팩토리 패턴의 장점</h3><ul><li>느슨한 결합을 가진다<ul><li>상위 클래스와 하위 클래스가 <code spellcheck="false">분리</code>되기 때문</li></ul></li><li>유연성이 좋다<ul><li>인스턴스 생성 방식에 대해 전혀 알 필요가 없기 때문</li></ul></li><li>유지보수성이 증가한다<ul><li><code spellcheck="false">객체 생성 로직이 따로 떼어져 있어</code> 코드를 리팩터링하더라도 한 곳만 고칠 수 있기 때문</li></ul></li></ul><h2>고민하고 기억하기</h2><blockquote>p. 24</blockquote><h3>Q. 팩토리 패턴이 등장하게 된 이유가 뭘까?</h3><ul><li>객체 생성 로직의 복잡성과 유연성을 관리하고, 코드의 유지보수성을 높이기 위해</li></ul>(팩토리 패턴이 등장하게 된 이유는, 어떤 상황에서 사용하는 것이 좋을까 와 같다고 생각함)<blockquote>자바스크립트 + 리액트 디자인 패턴</blockquote><h3>Q. 팩토리 패턴은 어떤 상황에서 사용하는 것이 좋을까?</h3><ul><li>객체나 컴포넌트의 생성 과정이 높은 복잡성을 가지고 있을 때</li><li>상황에 맞춰 다양한 객체 인스턴스를 편리하게 생성할 수 있는 방법이 필요할 때</li><li>같은 속성을 공유하는 여러 개의 작은 객체 또는 컴포넌트를 다뤄야 할 때</li><li>덕 타이핑 같은 API 규칙만 충족하면 되는 다른 객체의 인스턴스와 함께 객체를 구성할 때</li><li>디커플링 상황</li></ul>Q. 덕타이핑과 구조적 타이핑, 동적 타이핑<ul><li>동적 타이핑은, 값이 담길 때 타입이 정해지기 때문에, <code spellcheck="false">동적으로 변한다</code></li><li>덕 타이핑은, 객체의 변수, 메소드의 집합이 객체의 타입을 결정한다</li></ul><img src="https://image.until.blog/fc0o0ce/article/1733820853066.png" data-width="100%" data-align="center" alt="2527"><ul><li>구조적 타이핑은, 구조 안에 같은 속성의 타입이 있는지를 체크하는 것이다.<ul><li>때문에, 의도하지 않았지만 동일한 타입을 가지는 경우 <code spellcheck="false">동일한 유형으로 간주될 수 있다</code></li></ul></li></ul><img src="https://image.until.blog/fc0o0ce/article/1733820892623.png" data-width="100%" data-align="center" alt="2528">둘 다 객체의 변수, 메소드 같은 필드를 기반으로 타입을 체크(혹은 안할수도)하지만,덕 타이핑은 '런타임'에 체크하기 때문에 동적 타이핑에서, 구조적 타이핑은 '타입 체커'에서 체크하기 때문에 정적 타이핑에서 쓰인다.Q. JS는 왜 동적 타입 언어로 설계된 것일까?주로 유연성과 간편성을 제공하기 위해서이다<ul><li><code spellcheck="false">동적 타입 언어</code>란, 변수에 타입을 지정하지 않고 코드가 실행되는 런타임에 변수 값이 할당될 때 해당 값의 타입에 따라 변수 타입이 결정되는 언어이다</li><li>자바스크립트는 원래 웹 브라우저 내에서 동적으로 실행되는 스크립트 언어로 설계되었는데, 웹 페이지는 빠른 속도로 변화하는 동적 콘텐츠를 처리해야 했다</li><li>동적 타이핑으로 설계된 자바스크립트는 <code spellcheck="false">유연성</code> 덕분에 복잡한 설정 없이 다양한 데이터 타입을 처리할 수 있으며, 다양한 웹 브라우저 환경에서 원활하게 작동할 수 있다</li></ul>Q. TS는 왜 등장한걸까?<ul><li>JS는 동적 타입 언어로, <code spellcheck="false">런타임에 실제 코드의 값이 평가될 시점에서야</code> 변수에 들어올 값과 타입을 알 수 있다</li><li>때문에, 개발자의 의도와 다르게 동작할 수 있다. (ex: 숫자 a,b의 합을 구하는 함수에서 문자열의 합을 구할 수 있음)</li><li>TS는 정적 타입 언어로, <code spellcheck="false">컴파일 타임에 변수의 타입을 결정</code>한다</li><li>이로써 TS는 타입 에러를 사전에 방지해 안정성을 보장한다</li></ul>Q. JS는 왜 싱글스레드를 사용할까?<ul><li>JS는 원래 웹 브라우저에서 동적 동작을 위해 설계되었기 때문이다</li><li>주로 DOM을 조작하는 데 주로 사용되는데, 여러 스레드가 동시에 DOM을 수정한다면 충돌이 발생할 수 있다</li><li>싱글 스레드에서는 한 번에 하나의 작업만 수행하므로, DOM 업데이트가 안전하게 순차적으로 이루어진다 (비동기)</li><li>그러나 이벤트 루프를 통한 비동기 처리로 동시성을 지원한다.</li><li>이벤트 루프는 <code spellcheck="false">콜 스택</code>과 <code spellcheck="false">태스크 큐</code>를 사용해, 비동기 작업이 완료되면 해당 콜백 함수를 콜 스택으로 보내 실행한다</li></ul>Q. 이벤트 루프의 동작 과정은 어떻게 진행되나?<ol><li>콜 스택에 현재 실행 중인 컨텍스트가 있는지, 테스크 큐에 대기 중인 함수가 있는지 반복하며 확인</li><li>만약 콜 스택이 비어있고, 테스크 큐에 대기중인 함수가 있다면 순차적으로 콜스택으로 이동 후 실행</li><li>태스크 큐와 마이크로 태스크 큐에 대기 중인 함수가 있다면, 마이크로 테스크 큐를 우선적으로 처리 후 테스크 큐 처리</li></ol><h3>Q. 팩토리 패턴을 사용하면 안되는 상황은 뭘까?</h3>객체 생성 인터페이스 제공이 작업 중인 라이브러리나 프레임워크의 설계 목표가 아닐 때<ul><li>잘못된 상황에 팩토리 패턴을 적용하면 <code spellcheck="false">애플리케이션의 복잡도</code>가 크게 증가할 수 있다</li><li>객체 생성 과정이 복잡할 경우 <code spellcheck="false">단위 테스트의 복잡성</code> 또한 증가시킬 수 있다<ul><li>팩토리 패턴은 객체 생성 과정을 인터페이스 뒤에 추상화하기 때문</li></ul></li></ul>

면접을 위한 CS 전공지식 노트 / 1장. 디자인 패턴과 프로그래밍 패러다임

면접을 위한 CS 전공지식 노트: 디자인 패턴: 팩토리 패턴

<img src="https://image.until.blog/steady/article/1727427951503.jpeg" alt="until-1588"><h2>어디에 쓰이나?</h2><hr>서버 개발을 하다보면 트래픽을 생각하지 않을 수가 없게 된다. 이때 단순 텍스트로 이루어진 데이터들은 크게 문제가 되지 않지만 이미지나 동영상이 끼게 되면 아무래도 복잡해진다. 트래픽은 다 서버 비용을 늘리는 주된 범인이니 해결 방법을 찾아야했다.그래서 우선적으로 이미지의 용량을 줄이는 방법을 생각하게 되었다.<h2>이미지 용량 줄이는 법</h2><hr>이미지의 용량을 줄이는 방법은 크게 두 가지가 있는데<h3>1. 해상도 줄이기</h3>높이와 너비 픽셀 수를 조정하여 이미지의 사이즈 자체를 줄여버리는 방법으로 확장자와 상관없이 사용 가능하고 일정 크기까지는 그렇게 불편하게 보이지는 않는다.<h3>2. 압축률 조정하기</h3>이미지 파일들은 확장자 별로 2가지 방식의 압축 방식을 가지고 있다.손실 압축 (ex. JPG)손실 압축을 사용하는 확장자의 경우에는 압축률을 줄일수록 다양한 색상이나 디테일을 포기하는 대신 용량이 확연히 줄어들게 된다. 하지만 압축률에 따른 이미지가 정말 이상해진다.비손실 압축 (ex. PNG)비손실 압축을 사용하는 확장자의 경우에는 압축률에 따른 이미지 손상이 크게 눈에 띄진 않지만, 용량의 변화가 크지 않다.<h2>어떻게 할까?</h2><hr>내가 개발하는 기능의 경우에는 다양한 확장자의 이미지 파일을 다뤄야 하고 용량을 최대한으로 줄여 트래픽을 줄여야 하는 상황이라 해상도를 줄이는 방법을 선택하기로 했다.(사실 JPG 압축률을 한번 줄여보긴 했는데 압축률을 많이 줄여서 그런지 내 기준으로 못 쓸만한 이미지가 되었다.)<h2>개발 과정</h2><hr>개발 하다 보니 1:1 비율로 이미지를 자르는 기능도 필요해 추가하게 되었다.<pre spellcheck="false"><code class="language-java">public class ImageUtil {

 // POST WEB 통신을 통해 전달받는 데이터 포맷이 MultipartFile 이었다.
 public MultipartFile resizeAndCrop(MultipartFile file, float quality) throws IOException {

 // 원본 이미지 읽기
 BufferedImage originalImage = ImageIO.read(file.getInputStream());

 // 해상도 낮추기(0.0 ~ 1.0 까지의 실수를 받아 얼마나 줄일지를 결정했다.)
 BufferedImage resizeImage = resizeImage(originalImage, quality);

 // 이미지를 1:1 비율로 변환
 BufferedImage croppedImage = cropImage(resizeImage);

 // 이미지를 스트림에 저장
 // ImageIO.write 부분을 변경해 파일을 직접 저장할 수도 있다.
 ByteArrayOutputStream byteArrayOutputStream = new ByteArrayOutputStream();
 ImageIO.write(croppedImage, "jpg", byteArrayOutputStream); // format: "jpg", "png" 등

 // ByteArrayInputStream을 사용하여 MultipartFile로 변환
 ByteArrayInputStream byteArrayInputStream = new ByteArrayInputStream(byteArrayOutputStream.toByteArray());
 MultipartFile resultFile = new MockMultipartFile(
 file.getName(), // 원본 파일 이름
 file.getOriginalFilename(), // 원본 파일 이름 그대로 사용
 "image/jpeg", // MIME 타입 설정
 byteArrayInputStream // 입력 스트림으로 변환
 );

 // 결과 파일을 반환
 return resultFile;
 }

 // 해상도를 낮추는 메서드
 private BufferedImage resizeImage(BufferedImage originalImage, float quality) {

 // 너비와 높이를 quality 값에 맞는 비율로 조정해 임시 이미지 파일 생성
 int targetWidth = (int)(originalImage.getWidth() * quality);
 int targetHeight = (int)(originalImage.getHeight() * quality);
 BufferedImage resizedImage = new BufferedImage(targetWidth, targetHeight, originalImage.getType());

 // 사이즈에 맞춰 이미지를 실제로 그려낸다.
 Graphics2D g2d = resizedImage.createGraphics();
 g2d.setRenderingHint(RenderingHints.KEY_INTERPOLATION, RenderingHints.VALUE_INTERPOLATION_BILINEAR);
 g2d.drawImage(originalImage, 0, 0, targetWidth, targetHeight, null);
 g2d.dispose();

 return resizedImage;
 }

 // 중앙을 기준으로 1:1 비율로 크롭하는 메서드
 private BufferedImage cropImage(BufferedImage image) {
 int width = image.getWidth();
 int height = image.getHeight();

 // 가로와 세로 중 짧은 쪽으로 1:1 비율 만들기
 int newSize = Math.min(width, height);

 // 중심 좌표 계산
 int x = (width - newSize) / 2;
 int y = (height - newSize) / 2;

 // 중앙을 기준으로 크롭
 return image.getSubimage(x, y, newSize, newSize);
 }
}</code></pre><h2>돌아보며</h2><hr><blockquote>단순한 기능이라 생각했지만 나름 시간을 많이 잡아먹었다.결과적으로 사용은 하진 않았지만, 압축률을 조정해 보며 직접 테스트해 본 건 좋은 경험이었던 것 같다. 이 기억이 남아있다면 다음에는 시간을 절약할 수 있길 바라본다.추가로 곧 동영상도 다루게 될 것 같은데 시간이 된다면 동영상을 다루는 것도 작성해 보도록 하겠다.</blockquote>

어디에 쓰이나?서버 개발을 하다보면 트래픽을 생각하지 않을 수가 없게 된다. 이때 단순 텍스트로 이루어진 데이터들은 크게 문제가 되지 않지만 이미지나 동영상이 끼게 되면 아무래도 복잡해진다. 트래픽은 다 서버 비용을 늘리는 주된 범인이니 해결 방법을 찾아야했다.그래서 우선적으로 이미지의 용량을 줄이는 방법을 생각하게 되었다.이미지 용량 줄이는 법이미지의 용

[Java] 이미지 용량을 줄여보자

⚛️ React

<img src="https://image.until.blog/morethanmin/article/1716115237924" alt="until-88">react-query에서 useQuery를 사용하면 staleTime과 gcTime 을 이용해 데이터를 효율적으로 다룰 수 있다. 둘의 차이점을 알아보자.<h2>staleTime</h2><blockquote><ul><li>The time in milliseconds after data is considered stale. This value only applies to the hook it is defined on.</li><li>If set to <code spellcheck="false">Infinity</code>, the data will never be considered stale</li></ul></blockquote><code spellcheck="false">staleTime</code>은 불러온 데이터가 fresh한 시간을 나타낸다. defaultValue는 0으로, 리액트 쿼리에서는 기본적으로 불러온 데이터는 fresh하지 않다고 간주한다.기본 값을 사용하게 된다면 해당 hook을 사용하는 컴포넌트가 mount 될 때마다 data fetching을 시도할 것이다.데이터의 stale여부에 따라서 적절하게 조절해줌으로써 최적화 해줄 수 있다.아래 예시는 until.lbog 에서 사용하는 특정 블로그 정보를 가져오는 훅이다.<pre spellcheck="false"><code class="language-typescript">import { useSuspenseQuery } from '@tanstack/react-query'
import { GetBlogResponse, createGetBlog } from 'src/apis/blog/[username]'
import { queryKeys } from 'src/constants/queryKeys'

const useBlogQuery = () =&gt; {
 const username = useUsername();
 const { data } = useSuspenseQuery&lt;GetBlogResponse&gt;({
 queryKey: queryKeys.blog.username.body(username),
 queryFn: createGetBlog(username),
 staleTime: Infinity,
 })
 return data
}

export default useBlogQuery</code></pre>staleTime을 <code spellcheck="false">Infinity</code>로 설정한 이유는 무엇일까?기본적으로 블로그 정보는 서버사이드에서 불러온 이후 변경되는 경우가 거의 없다. 해당 훅은 블로그에서 전반적으로 사용하고 있기 때문에 staleTime이 0일 경우에는 화면을 전환될 때마다 비효율적인 데이터 패칭이 계속해서 일어날 것이라고 판단하였다.프로필 수정, 팔로우, 팔로잉와 같이 데이터가 더이상 fresh하지 않은 경우에는 <code spellcheck="false">queryClient.invalidateQuery</code>를 통해 명시적으로 갱신해줌으로써 해결할 수 있다.물론 위 방식의 경우 외부적인 요인에 의해 특정 블로그 정보가 변경되는 경우에는 해당 블로그에 재 접속하지 않는 이상 갱신되지 않을 수 있다는 점은 감안해야한다.아래 예시는 게시글 리스트를 가져오는 훅이다.<pre spellcheck="false"><code>import { useSuspenseInfiniteQuery } from '@tanstack/react-query'
import { queryKeys } from 'src/constants/queryKeys'
import {
 GetArticlesParams,
 createGetUserArticles,
} from 'src/apis/blog/[username]/articles'
import useBlogData from 'src/blog/hooks/useBlogData'
import useArticleParams from './useArticleParams'

const useArticlesInfiniteQuery = () =&gt; {
 const blogData = useBlogData()
 const { order, query, tag } = useArticleParams()

 const params: GetArticlesParams = {
 order: order || undefined,
 query: query || undefined,
 tagSlug: tag || undefined,
 }

 const { data, ...infiniteQuery } = useSuspenseInfiniteQuery({
 queryKey: queryKeys.blog.username.articles.list(blogData.username, params),
 queryFn: async ({ pageParam }) =&gt; {
 const getUserArticles = createGetUserArticles(blogData.username)

 return await getUserArticles({ page: pageParam, ...params })
 },
 initialPageParam: 0,
 getNextPageParam: (data) =&gt; (data.hasMore ? data.page + 1 : undefined),
 })

 if (!data) throw new Error('Suspense Error')

 return { data, ...infiniteQuery }
}

export default useArticlesInfiniteQuery
</code></pre>위 훅에서는 반대로 <code spellcheck="false">staleTime</code>을 설정하지 않고 기본값(0)을 사용했다.그 이유는 훅의 영향 범위가 <code spellcheck="false">useBlogQuery</code> 와 같이 전반적인 블로그 페이지에서 사용되는 것이 아닌 하나의 특정된 페이지에서만 사용하기에 때문이다<h2>gcTime (cacheTime)</h2><blockquote><ul><li>The time in milliseconds that unused/inactive cache data remains in memory. When a query's cache becomes unused or inactive, that cache data will be garbage collected after this duration. When different garbage collection times are specified, the longest one will be used.</li></ul></blockquote><code spellcheck="false">gcTime</code> 은 데이터가 사용되지 않는 상황에서 memory에 유지될 수 있는 시간을 의미하고, defaultValue는 클라이언트 사이드에서는 5분, 서버사이드에서는 Infinity로 지정된다.일반적으로 클라이언트 사이드에서 해당 값을 변경하는 경우는 크게 없었던 것 같다.데이터 패칭에 직접적인 영향을 주지 않기 때문이다.다만 서버사이드에서는 Infinity로 설정되기 때문에 얘기가 달라진다. 메모리에 계속해서 데이터가 누적되는 경우에는 해당 값을 적절히 지정해 주는 것이 필요할 것 같다.<h2>결론</h2>어떻게 잡아주더라도 http 통신을 하는 웹페이지 안에서 데이터는 불일치하는 경우는 발생할 수 밖에 없다.데이터의 특성에 따라 적절한 캐싱 시간을 조절함으로써 불일치하는 경우를 최소화 할 수 있도록 하는것이 최선인 것 같다.

react-query에서 useQuery를 사용하면 staleTime과 gcTime 을 이용해 데이터를 효율적으로 다룰 수 있다. 둘의 차이점을 알아보자.staleTimeThe time in milliseconds after data is considered stale. This value only applies to the hook it is define