현장 실습을 뭐라도 해보자라는 기세로 지원했다.

혹시라도 최종선발까지 된다면 근처에 두 달 정도 살 곳을 구해야 하는 게 제일 어려운 점.

해당 백준 문제는 아래와 같다.

https://www.acmicpc.net/problem/10989

메모리에 신경쓰지 않고 그대로 제출하려고 했던 코드는 아래와 같다.

import sys
def LocalInput():
    with open("input.txt") as file:
        datas = file.read().strip().splitlines()
    return datas
def BaekjoonInput():
    datas = sys.stdin.read().strip().splitlines()
    return datas

# datas = LocalInput()[1:]
datas = BaekjoonInput()[1:]

datas.sort()
for data in datas:
    print(data)

인풋 단계에서 메모리를 낭비하지 말자는 아이디어는 있었지만, 어떻게 하면 좋을지 모르겠고 그 외 방도도 떠오르지 않아 GPT에 물어보고, 해당 내용을 학습해보려고 한다.

그 내용은 아래와 같다.

메모리를 초과하는 문제는 주로 정렬 시 사용되는 메모리, 데이터 저장 방식, 또는 출력 방식에서 발생할 수 있습니다. 아래에서는 코드의 메모리 사용량을 줄이고 효율적으로 개선할 수 있는 방법을 제시하겠습니다.

문제 분석

• datas = sys.stdin.read().strip().splitlines(): 이 코드는 입력을 한꺼번에 메모리로 읽어와 모든 줄을 리스트로 저장합니다.
• datas.sort(): 정렬 과정에서 추가적인 메모리 사용이 발생할 수 있습니다.
• for data in datas: print(data): 출력할 때도 리스트의 전체 요소를 메모리에 유지한 상태에서 하나씩 출력합니다.

개선 방향

1. 입력 처리 방식 최적화: 한꺼번에 메모리로 읽지 않고, 줄 단위로 읽으며 즉시 처리하는 방식으로 변경합니다. 이렇게 하면 메모리 사용을 줄일 수 있습니다.
2. 정렬을 메모리 효율적으로 수행: 메모리 사용량을 줄이기 위해 외부 정렬(external sorting)처럼 동작하게 만들거나, 파일을 사용하는 방법을 고려할 수 있습니다. 그러나 Python에서는 sorted()를 사용하여 한 줄씩 정렬하는 방식으로도 효과적으로 처리할 수 있습니다.
3. 입력과 정렬을 동시 처리: 입력을 받을 때마다 즉시 처리하여 메모리를 덜 사용하게 합니다.

개선된 코드 예시

import sys
import heapq

def LocalInput():
    with open("input.txt") as file:
        datas = file.read().strip().splitlines()
    return datas

def BaekjoonInput():
    return sys.stdin

# 메모리 초과 방지를 위해 제너레이터를 사용하여 입력 처리
def process_input_and_sort(input_source):
    min_heap = []

    # 첫 번째 줄은 개수 정보이므로 제외하고, 입력을 한 줄씩 처리
    next(input_source)

    # 각 줄을 힙에 추가 (메모리를 효율적으로 사용)
    for line in input_source:
        heapq.heappush(min_heap, line.strip())

    # 힙에서 하나씩 꺼내면서 출력 (정렬된 순서로 출력)
    while min_heap:
        print(heapq.heappop(min_heap))

# main 함수 호출부
# process_input_and_sort(LocalInput())  # 로컬 테스트용
process_input_and_sort(BaekjoonInput())  # 백준 제출용

개선 포인트 설명

1. 제너레이터 사용: 입력을 한꺼번에 메모리에 로드하지 않고, sys.stdin 제너레이터를 사용하여 한 줄씩 읽어 메모리를 절약합니다.
2. 힙 정렬 (heapq) 사용: 메모리 사용량을 줄이기 위해 힙 자료구조를 사용해 점진적으로 정렬된 데이터를 출력합니다. heapq는 파이썬 표준 라이브러리에서 제공하는 힙 자료구조로, 효율적인 메모리 사용과 정렬을 동시에 제공합니다.
3. 지연된 출력 처리: 정렬된 데이터를 즉시 출력하여, 리스트에 모든 데이터를 담고 있지 않도록 합니다.

추가 고려사항

• 파일 기반 정렬: 입력 크기가 매우 클 경우, 파일 기반 외부 정렬(External Sorting) 기법을 사용할 수도 있지만, 이는 보통 경쟁 프로그래밍에서 사용하지 않는 방법입니다.
• Python 버전 및 최적화: 최신 Python 버전에서는 메모리 관리가 조금 더 효율적일 수 있으므로, Python 3.8 이상을 사용하는 것도 고려해볼 만합니다.

이 방법을 사용하면 메모리 사용을 최적화하여 메모리 초과 문제를 해결할 수 있습니다.

전체적으로 생소한 내용이라 바로 학습.

https://arca.live/b/developers

각 항목에 대한 진행상황은 댓글로 주로 작성

이전 글) [1인 개발자 채널] 유니티 프로빌더랑 NonConvexMeshCol 에셋을 처음 써봤다

기어에 토크를 조금만 세게 주려고 해도 바아로 콜라이더끼리 통과해 헛돌게 되어버린다.

에디터 인스펙터와 프로그램 세팅 등에서 해볼 수 있는 건 다 해 본 것 같은 상황.

그래서 예전에 지나가다 들었던 방법이 ECS(엔티티 컴포넌트 시스템).. 얘인지는 모르겠는데, 지금 아무튼 Monobehavior 방식에서 ECS로 스크립팅하여 사용하는 Unity Physics/DOTS 와 Havok물리엔진을 다시 한 번 추천받아(GPT4o), DOTS에 Havok 이 포함되어있다고 하나 어쩌나 무튼 잘 모르겠지만 더 진행한다면 이 녀석들을 이용 해 보아야겠다.

해당하는 클래스 별로 주어진 문제들을 해결하면 진행도가 오르는 컨텐츠가 있길래 일단 Class1 문제 모두 해결

난이도는 새싹5 ~ 브론즈2

클래스 2는 브론즈3~실버2 난이도

확인 문서 : https://docs.unity3d.com/ScriptReference/UIElements.VisualTreeAsset.html

new VisualTreeAsset() 등으로 아무리 시도해도 안되더니만

Note: You can't generate a VisualTreeAsset from raw UXML at runtime.

미리 준비된 UXML을 써야 한다고 한다.

내용을 기억할 수 있도록 하기 위해서 API로는 한계가 있기 때문에 다시 셀레니움에 착수.
굳이 셀레니움이 아니더라도 웹브라우저를 컨트롤 할 수 있다면 상관 없지만 일단 셀레니움으로 접근 해 보자.

이전 진행하던 프로젝트를 다시 참고하여 갈피를 잡자.

https://ecchi.kr/429#comment23290134

현재 시도하고픈 내용 중 하나는 GPT끼리의 대화가 계속 이어지도록 구현하는 것이다.
방향을 잘 잡는다면 한 명은 개발 어시스턴트, 다른 한 명은 개발자의 포지션에서 프로젝트의 진척도를 끌어올릴 수 있지 않을까 생각이 든다.
무척 이상적인 이야기이고 추상적인 부분이 많아 일단은 명확한 목표는 아니다.
그리고 시도한 사람이 무척 많을 것으로 예상되는데, 이렇다 할 결과를 본 적이 없어 아무래도 한계가 크기 않을까 일단 생각한다.

이전 도중 개발을 멈췄던 사이트의 상태

API키를 이용해 해당 계정의 캐릭터정보를 모음

Todo

• 여러 계정 모아보기
• 이름 외 정보 표시

8월 3일 업데이트

배포 페이지 : https://www.lalainfo.kr/account

드디어 뷰어로써 기능을 하게 됨. 상기의 Todo 목록 모두 구현.

필터, 표시설정, 정렬 기능 구현.

의도치는 않았지만, 자연스러운 캐릭터 겹치기가 되는 것을 확인했다

Q.

sha256을 통해 아이디용으로도 salt를 만들어서 아이디도 암호화하고
로그인 체크에서 사용자와 입력한 아이디와 ID-salt를 조합하여 아이디 체크를 하도록 하여 혹여나 DB가 털릴 시에 ID도 노출되지 않도록 하고 싶은데, 연산에 많은 시간이 걸리려나?
그리고 ID도 암호화할 시에 관리자 입장에서 난처한 상황이 많이 발생하려나?

A.

아이디를 해싱 및 솔트 처리하여 저장하는 방법은 보안을 크게 향상시키지만, 몇 가지 고려사항이 필요합니다. 이런 방식으로 아이디를 처리할 경우의 장단점과 고려사항을 설명하겠습니다.

장점

1. 보안 강화: 데이터베이스가 유출되더라도 아이디와 비밀번호가 해시 처리되어 있기 때문에 평문 아이디와 비밀번호를 알아내기 어렵습니다.
2. 프라이버시 보호: 유저의 아이디가 노출되지 않으므로 개인정보 보호에 유리합니다.

단점 및 고려사항

1. 관리의 복잡성: 관리자 입장에서 사용자의 아이디를 직접 확인할 수 없으므로 문제 해결이 어려울 수 있습니다. 예를 들어, 특정 사용자를 찾거나 문제가 발생했을 때 사용자를 식별하는 데 어려움이 있습니다.
2. 성능: 해싱 알고리즘은 비교적 빠르지만, 사용자 수가 많아질수록 로그인 처리에 시간이 조금 더 걸릴 수 있습니다. 하지만 일반적인 사용 환경에서는 크게 문제되지 않을 것입니다.
3. 복구 불가능: 해싱된 아이디는 복구가 불가능하므로 사용자가 아이디를 잊어버리면 새로운 아이디를 생성해야 할 수 있습니다.

Option 열고, Additional Connection Parameters 에 아래와 같은 구문 입력 후 Connect

TrustServerCertificate=True

Post, Put, Patch의 사용을 결정하는 것은 HTTP 메서드의 의미와 의도에 따라 결정됩니다. 각각의 메서드는 특정한 목적과 사용 사례를 가지며, 이를 이해하면 적절한 메서드를 선택하는 데 도움이 됩니다.

HTTP 메서드의 의미와 사용 사례

1. POST:

   • 의미: 새로운 리소스를 생성합니다.
   • 사용 사례:
     • 새로운 사용자 계정을 생성할 때
     • 새로운 게시글을 작성할 때
     • 새로운 항목을 데이터베이스에 추가할 때
   • 특징:
     • 멱등하지 않음: 같은 요청을 여러 번 보내면 여러 리소스가 생성될 수 있습니다.
     • 일반적으로 리소스의 URI는 서버가 생성합니다.
   • 예시:

     @app.post("/users/")
     async def create_user(user: User):
         # 사용자 생성 로직

2. PUT:

   • 의미: 리소스를 생성하거나, 전체 리소스를 대체합니다.
   • 사용 사례:
     • 사용자의 전체 정보를 업데이트할 때
     • 특정 리소스를 전체적으로 대체할 때
   • 특징:
     • 멱등함: 같은 요청을 여러 번 보내도 결과는 동일합니다.
     • URI가 지정된 리소스를 대상으로 합니다.
   • 예시:

     @app.put("/users/{user_id}")
     async def update_user(user_id: int, user: User):
         # 사용자 정보 대체 로직

3. PATCH:

   • 의미: 리소스의 일부를 수정합니다.
   • 사용 사례:
     • 사용자의 특정 필드를 업데이트할 때 (예: 이메일 주소 변경)
     • 리소스의 부분적인 업데이트가 필요할 때
   • 특징:
     • 멱등하지 않을 수 있음: 부분 업데이트는 여러 번 보내도 결과가 동일하지 않을 수 있습니다.
     • URI가 지정된 리소스를 대상으로 합니다.
   • 예시:

     @app.patch("/users/{user_id}")
     async def partial_update_user(user_id: int, user: PartialUser):
         # 사용자 정보 부분 수정 로직

결정 기준

• 새로운 리소스 생성: POST

  • 예: 새로운 블로그 게시글 작성
  • 예: 새로운 주문 생성

• 전체 리소스 대체 또는 생성: PUT

  • 예: 사용자 프로필 전체 업데이트
  • 예: 특정 ID의 제품 정보 전체 대체

• 리소스의 일부 수정: PATCH

  • 예: 사용자 이메일 업데이트
  • 예: 주문 상태 변경

구체적인 예제

사용자 정보를 관리하는 API를 예로 들어보겠습니다.

• POST: 새로운 사용자 생성

  from fastapi import FastAPI
  from pydantic import BaseModel
  
  app = FastAPI()
  
  class User(BaseModel):
      name: str
      email: str
  
  @app.post("/users/")
  async def create_user(user: User):
      # 새로운 사용자 생성 로직
      return {"message": "User created", "user": user}

• PUT: 사용자 정보 전체 업데이트

  @app.put("/users/{user_id}")
  async def update_user(user_id: int, user: User):
      # 사용자 정보 전체 대체 로직
      return {"message": "User updated", "user_id": user_id, "user": user}

• PATCH: 사용자 정보 부분 업데이트

  class PartialUser(BaseModel):
      name: Optional[str] = None
      email: Optional[str] = None
  
  @app.patch("/users/{user_id}")
  async def partial_update_user(user_id: int, user: PartialUser):
      # 사용자 정보 부분 수정 로직
      return {"message": "User partially updated", "user_id": user_id, "user": user}

이렇게 HTTP 메서드의 의미와 사용 사례를 명확히 이해하고, 각 메서드의 특징을 고려하여 적절한 메서드를 선택하면, API 설계가 명확하고 일관성 있게 됩니다.

Json 데이터를 서버에 전달하여 파일로 저장하거나, 데이터를 읽고, 폴더 내 전체 데이터의 리스트를 클라이언트에서 전달받아 확인하는 등 테스트를 진행 중

데이터는 API 서버 외의 공간에 저장하는 게 좋겠지만 스케일이 커지고 힘들어질 듯 하여 일단 서버에 데이터를 보관한다.

현재 클라우드타입에서 배포를 하고 있는데, 서비스를 중단하면 그간 저장된 데이터가 사라지기 때문에 클라우드타입을 계속 사용한다면 외부에의 데이터 저장은 필수이기는 하다.

엔드포인트에 적절한 이름을 부여하고 싶은데 딱 맞는 게 떠오르지 않아 계속 바뀌는 중.

아무튼 클라우드타입의 계속적인 사용을 위해서는 서비스 중단 시에 파일 전체를 어딘가로 백업하는 등의 꼼수를 통해 해결해야만 한다.

현재 떠오르는 아이디어는 깃허브 리포지토리를 새로 하나 데이터 보관용으로 새로 작성하여, 저장된 플레이어 데이터를 해당 리포지토리에 백업하고, 서비스를 다시 시작할 때 리포지토리에 저장된 내용을 클론하여 가져오는 방법 등을 생각할 수 있다.

여담으로 디스코드에도 서버를 하나 작성하여 앨범 데이터를 위한 채팅채널을 하나 작성하여 길드 앨범으로 활용하고 있는데, 어느샌가 그 채팅채널의 내용이 스멀스멀 지워지고 있어 대체할 스토리지가 필요한 참이다. 이쪽은 크기가 꽤 커 깃허브를 활용하기에는 조금 부담이 되는 케이스.