해당하는 클래스 별로 주어진 문제들을 해결하면 진행도가 오르는 컨텐츠가 있길래 일단 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 서버 외의 공간에 저장하는 게 좋겠지만 스케일이 커지고 힘들어질 듯 하여 일단 서버에 데이터를 보관한다.

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

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

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

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

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

게임 서버를 구축할 때 Python을 사용하는 것은 충분히 가능하며, Node.js와 마찬가지로 여러 장점이 있습니다. 언어 선택은 주로 프로젝트의 요구사항, 팀의 기술 스택, 성능 요구사항, 개발자의 선호도에 따라 결정됩니다. 다음은 Python을 게임 서버에 사용하는 것의 장단점과 Node.js와의 비교입니다.

Python을 사용하는 장점

1. 사용이 쉬움: Python은 문법이 간단하고 직관적이어서 빠르게 개발할 수 있습니다.
2. 풍부한 라이브러리: 다양한 라이브러리와 프레임워크(예: Flask, FastAPI, Django 등)를 통해 웹 서버와 API를 쉽게 구축할 수 있습니다.
3. 강력한 커뮤니티 지원: 풍부한 문서와 커뮤니티 지원을 받을 수 있습니다.
4. 데이터 처리 및 AI: 게임 데이터 분석, 통계 처리, 머신러닝 등과 같은 작업에 매우 적합합니다.

Python을 사용하는 단점

1. 동시성 문제: Python의 GIL(Global Interpreter Lock)로 인해 CPU 집약적인 작업에서는 성능이 떨어질 수 있습니다. 그러나 asyncio, gevent, concurrent.futures 등을 활용하면 많은 동시성 문제를 해결할 수 있습니다.
2. 성능: Node.js에 비해 일부 네트워크 IO 작업에서 느릴 수 있습니다. 이는 주로 Node.js가 비동기 이벤트 기반 모델을 사용하기 때문입니다.

Node.js를 사용하는 장점

1. 비동기 처리: Node.js는 비동기 이벤트 기반 아키텍처를 사용하여 높은 처리량과 확장성을 제공합니다.
2. 성능: V8 엔진을 사용하여 빠른 자바스크립트 실행 속도를 제공합니다.
3. 풀스택 자바스크립트: 프론트엔드와 백엔드 모두 자바스크립트를 사용할 수 있어 코드 공유와 유지보수가 용이합니다.
4. 실시간 처리: WebSocket 등을 통한 실시간 데이터 처리에 매우 적합합니다.

Node.js를 사용하는 단점

1. 단일 스레드: Node.js는 단일 스레드 모델이므로 CPU 집약적인 작업에서는 성능이 저하될 수 있습니다.
2. 콜백 지옥: 비동기 코드를 많이 작성할 경우 콜백 지옥(Callback Hell)에 빠질 수 있으나, async/await를 사용하여 이를 해결할 수 있습니다.

결론

Python과 Node.js 모두 게임 서버 구축에 적합하며, 선택은 주로 다음 요소에 따라 결정됩니다:

1. 팀의 기술 스택: 팀이 이미 Python에 익숙하다면 Python을 선택하는 것이 효율적입니다.
2. 프로젝트 요구사항: 실시간 처리와 높은 동시성 요구사항이 있다면 Node.js가 더 적합할 수 있습니다.
3. 개발 속도와 편의성: Python은 간단한 문법과 풍부한 라이브러리로 인해 빠른 개발을 도울 수 있습니다.

예시

게임 서버의 간단한 예시로 Python의 FastAPI와 Node.js의 Express.js를 사용한 예제를 비교해 보겠습니다.

Python (FastAPI)

from fastapi import FastAPI

app = FastAPI()

@app.get("/")
async def read_root():
    return {"message": "Hello, world!"}

@app.post("/score/")
async def post_score(score: dict):
    # 점수 저장 로직
    return {"message": "Score saved!", "score": score}

if __name__ == "__main__":
    import uvicorn
    uvicorn.run(app, host="0.0.0.0", port=8000)

Node.js (Express.js)

const express = require('express');
const app = express();
app.use(express.json());

app.get('/', (req, res) => {
    res.send({ message: 'Hello, world!' });
});

app.post('/score', (req, res) => {
    const score = req.body;
    // 점수 저장 로직
    res.send({ message: 'Score saved!', score: score });
});

app.listen(8000, () => {
    console.log('Server is running on http://0.0.0.0:8000');
});

결론적으로, Python과 Node.js 모두 강력한 게임 서버를 구축할 수 있는 도구입니다. 프로젝트의 요구사항과 팀의 기술 스택에 따라 적절한 언어와 프레임워크를 선택하세요.

UXML 탬플릿을 생성하고 UI Builder에서 내용을 작성하는 방법

각 레이어들을 구성하고 스타일을 편집, 스타일 시트를 작성하여 클래스를 사용하는 방법

트랜지션을 사용하고 스크립트와 연계하는 방법 등을 학습하였다.

원래는 가챠형 게임을 생각하고 버튼을 통해 '캐릭터 뽑기 씬'으로 전환 할 생각이었는데, 연습 겸 먼저 위와 같이 작성 해 보았다.

참고한 강의는 아래와 같다. 1~3편으로 구성되어있다.

https://www.youtube.com/watch?v=eeDjeziVEbA

UI Builder에서 VisualElement를 추가한 후 Height를 Auto에서 300px로 바꾸었지만 반영이 되지 않는 문제

도움 페이지 : https://issuetracker-mig.prd.it.unity3d.com/issues/ui-builder-visualelement-height-cannot-be-changed-with-ui-builder-window

Inlined Styles - Flex 탭에서, 1로 설정되어있던 Grow 설정을 Initial로 바꿔준다

현재 디코봇에서 사용중인 앨범 기능에 대해 개선이 필요하다.

!업로드(!업) 과 함께 이미지를 첨부하거나 저거(저)라는 키워드를 함께 붙여 최근 이미지를 봇이 읽도록 하고있는데

그 대략적인 순서는 아래와 같다.

1. 명령과 함께 어떤 메시지가 주어졌는지 확인('저 or 저거', '야 or 야식')

2. 어떤 앨범에 저장할지, 업로드된 이미지 URL 확인

3. URL로부터 이미지를 바이너리 형식으로 추출

4. 추출한 이미지를 앨범 채널에 전송

예전에는 업로드된 이미지를 다운로드 받아, 그 파일을 다시 첨부하여 앨범 채널에 전송했는데, 배포 서비스에서 파일 다운로드를 지원하지 않을 것을 가정하고(예: 깃허브) 바이너리 분석 및 그대로 업로드를 하도록 바꿨었다.

여기에서 발생하는 문제점 두가지.

1. 처리 속도가 매우 늦어졌다. 분석 또는 전송에 시간이 많이 걸리는 듯 하다.

2. 움짤이나 동영상을 지원할 수 없게 되었다. 정지이미지만 가능한 방법이었다.

현재 배포 서비스인 Cloudtype은 파일 다운로드를 지원하고 있기 때문에, 다시 이전 방식으로 되돌려야 더 좋은 편의성을 가질 수 있을 것이다.

아쉽게도 예전 버전의 소스가 남아있지 않아 새로 작성해야한다.

그리고 현재 앨범 폴더의 대용으로 디스코드 채팅채널을 사용하고 있는데, 업로드한 지 오랜 시간이 지나면 내용이 사라지는 현상을 목격한 것 같아 데이터 소실 우려가 커졌다. 이에 대해서도 대안을 찾아야한다.

__ _

파일 가져오는 방식의 변경을 완료하였다.

파일을 다운로드. 현재 시간을 파일명으로 하고 싶었는데, 제대로 된 년도 대신 다른 기준의 숫자가 기재된다.
별로 상관 없나 싶어서 유지했다.

파일을 다운로드 하고, 그대로 앨범 채팅 채널에 업로드 후 다운로드했던 파일을 삭제한다.

속도 향상도 되었고, 이미지 외의 파일에도 적용되는 것을 확인했다.