[데이터 엔지니어링 데브코스 2기] TIL-5주차-파트05 [프로젝트]크롤한 웹데이터로 만들어보는 웹사이트(4)

이재호·2023년 11월 9일
0

1. 진척사항

  • 코디숍 및 코디맵에 대해서 크롤링과 스크래핑 작업 코드를 완성하였다.
  • 현재 위 코드에서 임시로 csv 파일로 저장하는 식으로 작성했지만, 추후에 팀원과 상의하여 DB Write하는 코드로 수정할 예정입니다.
  • 크롤링 및 스크래핑 코드를 실행할 때, log를 기록하기 위해서 logger를 이용하였고, "코디숍_날짜.log" 형식으로 저장되게 포맷을 정하였습니다.
  • 코디숍에 대해서 크롤링 및 스크래핑 작업 진행 중입니다.
  • 기존에는 time.sleep(1)로 하여 크롤링을 하였으나, 현재는 time.sleep(0.5)로 진행 중이며, 아직까지 문제는 없어 보입니다.



2. 추후 계획

  • 코디숍에 대해서 작업이 끝나면, 코디맵에 대해서 작업 수행.
  • 기존의 csv 파일로 저장하는 코드를 삭제하고, DB Write하는 코드로 수정.
  • DB 연동을 위해 PostgreSQL 설치 및 config 설정



3. 회의 내용

  • 시각화 그래프에 대한 토의(예, 꺾은선 그래프).
  • 추가 기능 관련 토의(예, 스타일별 조회수 탑 10).
  • log 기록 및 DB Write 관련 토의.



4. 몰랐던 내용

  • github 관련)

  • 무신사 페이지의 일부 데이터는 'utf-16' 방식의 인코딩으로 되어 있어, 해당 데이터를 Write 시에 문제가 발생할 수 있다. => 따라서, csv파일로 저장할 때 encoding='utf-16'으로 설정해 주어야 한다. (utf-8 , euc-kr, ansi, cp949 ansi 모두 안 된다.. ) + 인코딩 BOM 관련: https://brownbears.tistory.com/124

  • python의 logging module. 로그를 기록할 때 매우 유용하다 !..

  • github 현업 시의 규칙)

    • 브랜치 관련)

      브랜치 전략으로 Git-Flow를 사용한다.
      
      			main branch
      			: 배포 가능한 상태만을 관리한다.
      
      develop branch
      : 기능 개발을 위한 브랜치들을 병합하기 위해 사용한다.
      모든 기능이 추가되고 버그가 수정되어 배포 가능한 안정적인 상태라면 해당 develop 브랜치를 master 브랜치에 merge한다.
      평소에는 이 브랜치를 기반으로 개발을 진행한다.
      
      feature branch
      : 기능을 개발하는 브랜치로, 새로운 기능 개발 및 버그 수정이 필요할 때마다 develop 브랜치로부터 분기한다.
      feature 브랜치에서의 작업은 기본적으로 공유할 필요가 없기 때문에 자신의 로컬 저장소에서 관리한다.
      개발이 완료되면 develop 브랜치로 merge하여 팀원과 공유한다.
      더 이상 필요하지 않은 feature 브랜치는 삭제한다.
      
      release branch
      : 배포를 위한 브랜치로, 최종적인 버그 수정이나 문서 추가 등 배포와 관련된 작업을 수행한다.
      배포 관련 작업 이외에는 release 브랜치에 새로운 기능을 추가로 merge하지 않는다.
      
      hotfix branch
      : 배포한 버전에 긴급하게 수정을 해야 할 필요가 있을 경우, master 브랜치에서 분기한다.
      문제가 되는 부분을 수정 후에 master 브랜치에 merge하고 배포한다.
      hotfix 브랜치에서의 변경 사항은 develop 브랜치에도 merge한다.
      
      중심이 되는 master와 develop 브랜치를 제외한 나머지 feature, release, hotfix 브랜치는 merge되면 삭제하도록 한다.
      
      🌿 Naming Rule
      master와 develop 브랜치는 본래 이름을 사용하도록 한다.
      
      feature 브랜치는 feature/기능요약 형식을 사용하도록 한다.
      
      release 브랜치는 release-버전 형식을 사용하도록 한다.
      
      hotfix 브랜치는 hotfix-버전 형식을 사용하도록 한다. 
    • Commit 관련)

    프로젝트를 진행하면서 커밋 메시지를 작성할 때, 다음의 원칙을 따르도록 한다.
    
    ⭐ Structure
    type: title (필수)
    
    body (선택)
    - 작업한 내용
    
    footer (선택)
    🌙 Type
    타입은 소문자로 작성한다.
    
    feat - 새로운 기능 추가
    
    fix - 버그나 코드 수정
    
    docs - 문서 수정 (README.md, Issue Template, 라이센스 등)
    
    style - 코드 포맷팅, 세미콜론 누락 등 코드의 변경이 없는 경우
    
    refactor - 코드 리팩토링
    
    test - 테스트 코드, 리팩토링 테스트 코드 추가
    
    chore - 빌드 업무 수정, 패키지 매니저 수정 등 설정 변경 (.gitignore 포함)
    
    ☀ Title
    제목은 총 50자 이내이며, 마지막에 마침표를 붙이지 않는다.
    
    영어와 한글을 자유롭게 사용하되, 영어 사용 시 대문자로 시작하며 명령어로 작성한다.
    
    ⚡ Body & Footer
    본문의 내용은 커밋의 이유나 무엇이 왜 변경되었는지 간단히 작성한다.
    
    본문과 꼬리말은 선택적으로 작성하며, 다른 부분과 구분하기 위해 한칸을 띄우고 작성하도록 한다.
    
    💫 Example
    feat: OO 기능 구현
    
    - OO을 위해 OO 기능을 구현
    
    Resolves #10
    See also #11, #13
profile
천천히, 그리고 꾸준히.

0개의 댓글