지금의 기록이 미래의 자산이 된다.

A Steadily Growing Developer

크롬 북마크에 있는 파비콘이 제대로 안보이는 경우

2023-01-27

devfancy

E.T.C
- Macbook에서 최신버전으로 업데이트를 한 이후에 크롬을 들어가봤더니 다음과 같이 파비콘이 제대로 인식을 못하는 경우가 발생했다.
- 여러 설정들을 봐도 간단하고 쉽게 해결방안을 찾지 못했다.
- 어쩔 수 없이 노가다 전략으로 해당 문제를 해결했다.
- [1] 북마크 폴더에서 마우스 오른쪽 버튼 -> 북마크 관리자를 클릭한다.
- [2] 원하는 폴더를 지정해서 마우스 오른쪽 버튼 -> 모두 열기 / 새 창에서 모두 열기 / 시크릿 창에서 모두 열기 중 원하는 것을 클릭한다.
- [3] 새로고침을 하고 나면, 이제는 북마크에 있는 파비콘이 제대로 보이게 된다. (guest-book-homepage는 파비콘이 원래부터 없었기 때문에 기본 상태로 같다)
- 이 방법보다 더 좋은 방법이 있으면 추가적으로 업로드를 하자.
Read All

[Programmers] 42889. 실패율

2023-01-26

devfancy

Algorithm

성능 요약
구분
Answer Code1(23.01.26)
문제풀이

문제 링크

성능 요약

메모리: 78.8 MB, 시간: 0.67 ms

구분

코딩테스트 연습 > 2019 KAKAO BLIND RECRUITMENT

Answer Code1(23.01.26)

import java.util.ArrayList;
import java.util.Collections;
import java.util.List;

class Solution {
  public int[] solution(int N, int[] lastStages) {
    int nPlayers = lastStages.length;
    int[] nStagePlayers = new int[N + 2];
    for (int stage : lastStages) {
      nStagePlayers[stage] += 1;
    }

    int remainingPlayers = nPlayers;
    List<Stage> stages = new ArrayList<>();
    for (int id = 1 ; id <= N; id++) {
      double failure = (double) nStagePlayers[id] / remainingPlayers;
      remainingPlayers -= nStagePlayers[id];

      Stage s = new Stage(id, failure);
      stages.add(s);
    }
    Collections.sort(stages, Collections.reverseOrder());

    int[] answer = new int[N];
    for (int i = 0; i < N; i++) {
      answer[i] = stages.get(i).id;
    }
    return answer;
  }

  class Stage implements Comparable<Stage> {
    public int id;
    public double failure;

    public Stage(int id_, double failure_) {
      id = id_;
      failure = failure_;
    }

    @Override
    public int compareTo(Stage o) {
      if (failure < o.failure ) {
        return -1;
      }
      if (failure > o.failure ) {
        return 1;
      }
      return 0;
    }
  }
}

문제풀이

실패율이 높은 stage부터 내림차순으로 stage의 번호가 담겨있는 배열을 출력하는 문제이다.
실패율 = stage에 도달했으나 아직 클리어하지 못한 플레이어의 수 / stage에 도달한 플레이어 수
실패율을 구한 다음 내림차순으로 정렬하여 반환하는 것이 목표다.
흐름 구성
- 각 스테이지에 머무르고 있는 사람의 수를 카운팅한다.
- 각 스테이지를 플레이한 사람의 수를 카운팅한다.
- 각 (스테이지에 머무르고 있는 사람 / 각 스테이지를 플레이 한 사람) * 100으로 실패율을 계산한다.
- 실패율 순으로 정렬하여 스테이지의 번호를 반환한다.
중요한 조건
1. 실패율이 같을 경우 스테이지가 작은 번호가 우선
2. 스테이지에 도달한 유저가 없는 경우 해당 스테이지의 실패율은 0

Read All

HTTP 웹 기본 지식 : HTTP 헤더2 - 캐시와 조건부 요청

2023-01-25

devfancy

HTTP
이 글의 코드와 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.

Contents
- 다음 순서에 맞게 보시는 것을 권장해드립니다.
캐시 기본 동작
- 캐시가 없을 때 요청을 하는 경우
  - 데이터가 변경되지 않아도 네트워크를 통해 계속 데이터를 다운로드 받아야 한다. -> 인터넷 네트워크는 매우 느리고 비싸다.
  - 브라우저 로딩 속도가 느리다. + 느린 사용자 경험
- 캐시를 적용할 경우
  - cache-control: max-age=60 : 캐시가 유효한 시간(초)
  - 캐시 가능 시간 동안 네트워크를 사용하지 않아도 된다 -> 비싼 네트워크 사용량을 줄일 수 있다.
  - 브라우저 로딩 속도가 빠르다. + 빠른 사용자 경험
  - 만약 캐시 유효 시간이 초과되면, 서버를 통해 데이터를 다시 조회하고 캐시를 갱신한다.
    
    이때 다시 네트워크 다운로드가 발생한다.
검증 헤더와 조건부 요청1
- 캐시 유효 시간이 초과해서 서버에 다시 요청하면 두 가지 상황이 발생한다.
  1. 서버에서 기존 데이터를 변경함
  2. 서버에서 기존 데이터를 변경하지 않음
서버에서 기존 데이터를 변경하지 않는 경우
- 캐시 유효 시간이 초과해도 서버의 데이터를 변경(갱신)하지 않는다. -> 저장해두었던 캐시를 재사용 할 수 있다.
  - 단, 클라이언트의 데이터와 서버의 데이터가 같다는 사실을 확인할 수 있는 방법이 필요하다.
- 예) 캐시 시간이 초과되는 경우(순서: 1 -> 2 -> 3 -> 4)
- 클라이언트의 데이터와 서버의 데이터가 같고, 수정(변경)되지 않았다면 저장해두었던 캐시를 재사용 할 수 있다.
- 수정되지 않았기 때문에, HTTP Header 부분만 전송한다. (304 Not Modified + 헤더 메타 정보만 응답(바디X))
- 클라이언트는 캐시에 저장되어 있는 데이터 재활용한다.
- 브라우저에 있는 캐시를 재사용할 수 있다.
- 결과적으로 네트워크 다운로드가 발생하지만 용량이 적은 헤더 정보만 다운로드된다.
검증 헤더와 조건부 요청2
- 검증 헤더란 캐시 데이터와 서버 데이터가 같은지를 검증하는 데이터이다.
- 종류에는 Last-Modified, ETag가 있다.
- Last-Modified와 ETag를 활용해서 클라이언트에서 서버로 요청을 할 때 조건부 요청 헤더를 만들어서 보내면 된다.
- 조건부 요청 헤더는 검증 헤더로 조건에 따른 분기를 의미한다.
- If-Modified-Since는 Last Modified를 사용하고, If-None-Match는 ETag를 사용한다.
- 조건이 만족하면 200 OK가 나오고, 만족하지 않으면 304 Not Modified가 나오게 된다.
- 예) If-Modified-Since: 이후에 데이터가 수정되었을 경우
  - 데이터 미변경 예시
    - 캐시 : 2023년 1월 1일 12:30:00 vs 서버 : 2023년 1월 1일 12:30:00
    - 304 Not Modified, 헤더 데이터만 전송(BODY 미포함)
    - 전송 용량 0.1M(헤더 0.1M, 바디 1.0M)
  - 데이터 변경 예시
    - 캐시 : 2023년 1월 1일 12:30:00 vs 서버 : 2033년 1월 1일 12:30:00
    - 200 OK, 모든 데이터 전송(BODY 포함)
    - 전송 용량 1.1M (헤더 0.1M, 바디 1.0M)
Last-Modified, If-Modified-Since 단점
- 1초 미만 단위로 캐시 조정이 불가능하고 날짜 기반의 로직만을 사용한다.
ETag, If-None-Match
- ETag(Entity Tag)란 캐시용 데이터에 임의의 고유한 버전 이름을 달아둔다.
  - 예) ETag: “v1.0”, ETag: “a2jiodwjekjl3”
- 데이터가 변경되면 이름을 바꾸어서 변경하는데, 이때 Hash를 다시 생성한다.
  - 예) ETag: “aaaaa” -> ETag: “bbbbb”
- 정리)
  - 클라이언트가 ETag만 서버에 보내서 같으면 유지하고, 다르면 다시 받는ㄴ다.
  - 캐시 제어 로직을 서버에서 완전히 관리한다.
  - 클라이언트는 단순히 이 값을 서버에 제공한다.(클라이언트는 캐시 메커니즘을 모른다)
캐시와 조건부 요청 헤더
- 캐시 제어 헤더
  - Cache-Control : 캐시 지시어
  - Pragma : 캐시 제어(하위 호환)
  - Expires : 캐시 유효 기간(하위 호환)
Cache-Control

캐시 지시어
- Cache-Control: max-age : 캐시 유효 시간, 초 단위
- Cache-Control: no-cache : 데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용한다.
- Cache-Control: no-store : 데이터에 민감한 정보가 있으면 저장하면 안된다. (메모리에서 사용하고 최대한 빨리 삭제해야 한다)
프록시 캐시
- 프록시는 클라이언트와 서버 사이에 대리로 통신을 수행하는 것을 말하며, 중계 기능을 하는 서버를 프록시 서버라고 한다.
- 클라이언트에서 저장하는 캐시를 private 캐시라고 하며 프록시 캐시 서버는 public 캐시라고 한다.
캐시 무효화
- Cache-Control: no-cache : 데이터는 캐시해도 되지만, 항상 origin 서버에 검증하고 사용한다.
- Cache-Control: no-store : 데이터에 민감한 정보가 있으면 저장하면 안된다. (메모리에서 사용하고 최대한 빨리 삭제해야 한다)
- Cache-Control: must-revalidate : 캐시가 만료된 이후에 최초 조회시 원(origin) 서버에 검증을 해야한다.
  - 만약 원 서버 접근이 실패하게 된다면 반드시 오류가 발생한다. (504 Gateway Timeout)
no-cache 기본 동작

no-cache vs must-revalidate
- no-cache 경우 원 서버에 접근할 수 없는 경우 캐시 서버 설정에 따라 캐시 데이터를 반환할 수 있다.
- Error or 200 OK
- 반면에, must-revalidate 경우 원 서버에 접근할 수 없는 경우 항상 오류가 발생하게 된다.
- 504 Gateway Timeout
Reference
- 모든 개발자를 위한 HTTP 웹 기본 지식
Read All
HTTP 웹 기본 지식 : HTTP 헤더1 - 일반 헤더

2023-01-25

devfancy

HTTP
- Contents
이 글의 코드와 정보들은 강의를 들으며 정리한 내용을 토대로 작성하였습니다.

Contents
- 다음 순서에 맞게 보시는 것을 권장해드립니다.
Read All
Spring 핵심원리 - 기본편 : 빈 스코프

2023-01-24

devFancy

Spring
- Contents
이 글의 코드와 정보들은 [스프링 핵심원리 기본편] 강의를 들으며 정리한 내용을 토대로 작성하였습니다.

Contents
- 다음 순서에 맞게 보시는 것을 권장해드립니다.
Read All