잉여개발자

좋았던 애자일 경험

일하면서 좋았던 애자일 경험일전에 스타트업에서 일하면서, 좋았던 경험/프로세스를 잊어먹기 전에 남겨본다. 프로세스1. 스프린트 (2주) 간 작업 진행2. 스프린트 회고 (스프린트 마지막 금요일) 진행- 소요시간 약 1시간- 다같이 모여서 이번 스프린트 간 구현 된 기능을 확인한다. (시연한다)- 시연은 파트별 (FE든, BE든) 진행 3. 시연 간 보완 점 및 개선 아이디어를 발굴한다. - 페이지마다 피드백 / 요구사항 miss 종합 -> 약 2~4개- TODO 보완 사항 -> 약 2~4개 - 거의 10개 미만의 추가 티켓이 나온다.- 우선순위를 정해서 다음 스프린트에 반영할 일부 티켓을 골라내고, 나머지는 백로그로 옮긴다.- 최종 PM은 티켓으로 만들고, 그 자리에서 대충 업무 정리를 끝낸다. (길어지..

API Router 중첩 사용하기 1만약 redoc에서 main, main/sub1 , main/sub1/sub2의 아코디언을 분리하여 사용한다고 할 때 다음과 같이 작성하여야 한다.- tags를 붙이면 redoc에서 아코디언이 생성된다.- prefix를 중복해서 작성해 주어야 한다.main_router = APIRouter(tags=["메인 라우터"])sub1_router = APIRouter(tags=["서브1 라우터"])sub2_router = APIRouter(tags=["서브2 라우터"])app.include_router(main_router, prefix="/api/main")app.include_router(sub1_router, prefix="/api/main/sub1")app.includ..

개요초기 단계의 간단한 프로젝트의 경우에는 데이터베이스 구조가 자주 변하지 않거나, 작업자가 히스토리를 잘 아는 경우직접 SQL 쿼리를 실행하거나, ORM을 사용해 수작업으로 데이터베이스를 업데이트하는 방법으로 DB Migration을 관리 할 수 있다. 하지만 여러 명의 개발자가 동시에 작업하거나, 빈번한 스키마 변경(모델 자주 수정, 새로운 테이블 등 추가), 다양한 환경(개발, 스테이징, 프로덕션 등)에서 데이터베이스를 관리해야 하는 경우, DB Migration 히스토리를 관리하는 것은 DB 상태를 관리하는데 중요하다. 이를 잘 관리하기 위해 다양한 마이그레이션 도구가 존재한다. 마이그레이션 도구 사용시 장점1. 스키마(모델) 자동 관리- 테이블, 컬럼, 인덱스, 키 등의 추가, 수정, 삭제 같은..

이미지 리사이징 서비스 설명서비스 소개 및 설명은 아래에 나와있다. https://yubi5050.tistory.com/332 파일 관리 서비스 3 - S3 이미지 리사이징 서비스 만들기 (by. CloudFront, Lambda@Edge)개요웹 페이지 서비스에서 스토리지(S3)에 가지고, 사용하고 잇는 원본 이미지 크기가  720 x 360 라고 가정하자하지만 페이지에 따라 640x360, 1200x600 등등 출력할 화면이 있다고 가정할 때.. (추후 2:yubi5050.tistory.com 구현 순서 (1~2) 1. S3 이미지 만들고 & S3 캐싱하는 CloudFront 만들기2. Lambda (chalice) 코드 작성- chalice의 lambda function 사용하여 구현- edge 환경..

개요웹 페이지 서비스에서 스토리지(S3)에 가지고, 사용하고 잇는 원본 이미지 크기가  720 x 360 라고 가정하자하지만 페이지에 따라 640x360, 1200x600 등등 출력할 화면이 있다고 가정할 때.. (추후 2:1 비율의 다양한 이미지 사이즈가 추가 될 수 있음) 어떻게 효율적으로 관리 할 수 있을까? 접근 및 방법1. 그냥 720x360 이미지를 활용하자니-> 더 작은 이미지(320x160)를 호출하는 곳에서는 더 큰 이미지(720x360)를 불필요한 호출 리소스가 사용된다.  2. 각 사이즈의 이미지를 만들어 올려놓자니-> 크기가 바뀔 때마다 매번 관리(업로드) 해야 하고, 스토리지(S3)에 저장하는 것도 부담일 수 있음 관리 비용도 적게 들고, 스토리지도 효율적으로 사용하면서, 확장에도..

Schema 란 스키마(schema)는 데이터베이스 내에서 객체(테이블, 뷰, 함수, 인덱스 등)를 논리적으로 구분 한 컨테이너이다. 하나의 데이터베이스 안에 여러 스키마를 포함하며, 스키마를 활용해  여러 namespace 공간을 제공하고, 각각의 공간에서는 동일한 이름의 객체를 가질 수 있다. public과 service1이 다른 schema라는 가정하에 다음과 같이 정의 할 수 있다.ex) public.user_table / service1.user_table Mysql mysql 에서 스키마(Schema)는 Database와 동일한 의미로 사용된다.즉, MySQL의 스키마(Schema)는 데이터베이스(Database) 하나 자체를 지칭하며,필요시 다른 데이터베이스(Database)를 활용하여 논리..

Non-Tech 관련코드 리뷰코드 리뷰에 관한 생각 정리 : 코드 리뷰에 대한 가치관 및 좋은 견해 개발자, 커리어주니어/중니어/시니어의 역할 정리 : 주니어, 중니어  의 역할을 비교해보며 나는 어디쯤 속해있나 돌아보기 좋은 글. 팀프로젝트테크스펙으로 모두 함께 성장하기 , 링크2 : 개발 기간 산출 전 테크 스펙 확인하기 기타사용자 행동 로그국내의 UX/UI 모바일 패턴 수집 Tech 관련PythonPython과 FastAPI로 지속 성장 가능한 웹서비스 개발하기Fastapi 콜 한줄한줄 따라가기CPython 3.13버전에서 기대되는 기능(A Per-Interpreter GIL)Python @Dataclass 이해하기파이썬과 인터페이스: 프로토콜에서 ABC까지메타 프로그래밍이란? 설계 / 배포uvic..

상황서버 CPU나 메모리가 일정 임계선을 넘어 서, 서비스에 장애가 생기는 경우 복구를 위해 서비스 재부팅 + 알림 메일이 오게 설정해두었는데, 3일 연속 자정에 서버가 임계선을 넘어가 재부팅 되었다는 알림 경보 메일을 받게 되어, 3일차에 문제 해결에 들어가게 되었다.(처음 1일 때는 일시적인 현상으로 지켜보면서 모니터링 만 하다가, 2~3일 때 반복적인 발생하는 이슈로 보았음) 문제 파악다른 시간대에는 문제가 없고, 자정에만 문제가 생기는 것으로 보아, 자정에 실행되는 이벤트 들에 문제가 있다고 생각하여 해당 크론들을 파악하게 되었다.(아래 AWS 지표를 볼 때, AWS는 기본 5분 단위로 평균을 집계(옵션 및 추가 비용을 내면 1분마다 집계 가능) 하여 그래프로 나타내준다. 23시 55분 ~ 00시..

배경 복잡한 if-else  중첩 구조에 대한 수정  과정👉 리팩토링 전 - api.py 의 함수에 다음과 같은 조건문이 적혀있었고, 유지보수와 이해(가독성)에 매우 어려움이 존재# 리팩 전if a: if b: if c: return '성공' else: raise ApiError(에러c) else: raise ApiError(에러b)else: raise ApiError(에러a) 👉 리팩토링 후- 부정 문으로 상위 조건인 경우 return(raise)를 진행함 . early-return 을 통해 가독성 개선# 리팩 후if not a: raise ApiError(에러a)if not b: raise ApiError(에러b)if n..

Timeout 에러 timeout 에러 발생시, 다양한 이유에서 Timeout 504 에러가 발생 할 수 있다. ConnectTimeOut 연결 수립 과정(Connection TimeOut) 에서의 에러해당 서버로 아예 연결 수립 과정에서 막히는 경우timeout=0.0001 : 0.0001 초 안에 연결 수립 되어야 한다고 가정import requestsfrom requests.exceptions import ReadTimeout, ConnectTimeout############## Error - ConnectTimeout 에러! ##############url = "https://alden-kang.tistory.com/20"try: # 의도적으로 매우 짧은 타임아웃으로 연결 수립 조차 못하게 ..