1. 개념 파악 먼저 크롤링과 스크래핑의 개념에 대해 알고가자. 나는 이 두 방법이 똑같은 기법이라고 알고 있었는데 어떻게 데이터를 추출하냐에 따라 개념이 달라진다고 볼 수 있다. 크롤링 개인 혹은 단체에서 필요한 데이터가 있는 웹(Web) 페이지의 구조를 분석하고 파악하여 긁어온다. 여기서 긁어온다는 의미는 모두 그대로 가져오는 것. 이것은 데이터를 추출한다로 설명할 수 있고, 크롤링이라는 행위를 하는 소프트웨어(혹은 프로그램)를 크롤러(Crawler)라고 부른다. 스크래핑 웹 크롤링과 마찬가지로 특정 웹 사이트에서 원하는 데이터를 자동으로 추출하는 것이지만, 웹 크롤링은 웹 페이지의 링크를 통해 계속해서 정보를 찾아 나가지만, 웹 스크래핑은 특정 웹 사이트에서만 데이터를 추적한다. 2. Puppete..

카테고리 없음 2024. 4. 1. 03:23

HTTP 메서드란? get: 리소스 조회 post: 등록, 요청 데이터처리 put: 리소스 덮어쓰기, 해당 리소스가 없으면 생성 patch:리소스 부분 변경(put은 전체 변경이지만 patch는 일부 변경) delete: 리소스 삭제 head: get과 동일하나 body부분을 제외하고 상태 줄과 헤더만 반환 options: 대상 리소스에 대한 메서드를 주로 설명 주로 CORS에서 사용 connect: 대상 자원으로 식별되는 서버에 대한 터널 설정 trace: 대상 리소스에 대한 경로를 따라 메시지 루프 백 테스트 수행 GET, POST의 개념과 함께 데이터 흐름에 대해서 두 방식은 클라이언트와 서버 간의 데이터 교환을 위한 HTTP 메서드로 사용됨 하지만 데이터의 위치와 사용 목적에서 차이가 있음 GET..

[TIL] 2024. 3. 29. 02:16

프로그램 프로세스 작업을 하기 위해 실행할 수 있는 파일 실행되어 작업중인 컴퓨터 프로그램 파일이 있지만 메모리에는 공유되어 있지 않은 정적인 상태 메모리에 공유되고 자원을 할당받아 프로그램이 실행된 상태 코드 덩어리 코드 덩어리를 실행한 것 프로세스와 쓰레드 프로세스는 운영체제로부터 자원을 할당받아 독립적으로 실행됨. 총 4개의 코드, 데이터, 메모리공간, 파일 리소스를 포함하고 있고 독립적인 주소 공간을 가지고 있어 다른 프로세스 영역에 직접적으로 접근 불가 쓰레드는 프로세스 '내'에서 실행되는 단위. 한 프로세스 내에서 쓰레드가 동작함 쓰레드는 프로세스 내에서 코드, 데이터, 메모리 공간을 공유해 공유 메모리 방식으로 통신을 함 차이점: 프로세스는 독립적 자원공간이라 서로의 영역에 침범 불가, 쓰레..

[TIL] 2024. 3. 27. 22:44

1. flowChart 2. Wireframe 기존 기획은 응모가 가능한 사이트를 크롤링해 응모하기 버튼을 누르면 자동으로 응모를 해주는 '드로우 봇'을 만들기로 해서 방법을 찾아보고 물어봤었다 그에 따른 의문에 대한 답변은? Q. 드로우 봇을 만들 수 있을까요? A. 가능하지만 매우 어렵다 응모한 사람이 해당 사이트에 ID, PASSWORD를 준다면 가능할지도 모르겠지만 응모가 가능한 모든 사이트의 인증 인가 방식을 확인해보는데 매우 많은 시간이 걸린다. 즉, 봇은 쉽지 않다. Q. 드로우 봇을 만들지 않고 기존 서비스와 차별점은 어떻게 두어야 좋을까요? A. 차별화를 줄만한 아이디어를 팀원끼리 브래인스토밍하면서 추가하면된다. ps) 기본적으로 고려할 것이 많은 아이디어이다. 데이터를 얼마마다 저장해야..

[TIL] 2024. 3. 27. 00:57

Keep: 체계적인 깃 사용, 즉각적인 소통, 원활한 소통이 되어 좋았다. 팀 내에서 기술적인 부분 말고도 잡담?도 하면서 분위기를 이끌 수 있지만, 우선순위를 잘 고려해서 프로젝트에 대한 회의가 중심이 되어서 좋았다. / 파트에 대해 이해할 수 있게 팀장님 중심으로 코드리뷰하는게 좋았다 팀원들간의 코드 피드백 서로 모르거나 팀원의 코드에 이해가 가지 않는 부분에 대해서 서로 리뷰를 통해 이해할수 있었던 부분이 좋았다 Problem: 기존에 설계했던 API와 ERD, 팀원들이 짜놓은 코드에 최대한 간섭 되지 않게 하려고 하다보니 생각했던 만큼 재밌는 로직을 구현하지 못한게 아쉽다 기존에 필수적으로 구현해야만 하는 파트를 제외하고 좀 더 도전적으로 보너스 파트까지 구현을 해보았다면 각자의 기술적인 부분이 ..

[TIL] 2024. 3. 25. 21:56

스크레이핑을 통해 각 응모 페이지들의 데이터를 수집 - 10 ~ 20개 정도 응모가 가능한 페이지를 리스팅후 분석 - http패킷 (Network tab)에서 확인 가능 - get post 메서드를 비교하는게 첫번째 관점 - 스크레핑 기술은 crontab이나 cron 성격을 가진 batch system을 활용해서 구현 그렇다면 20개 정도의 페이지를 최적화 하는데 필요한 요구 조건은 뭘까? 1개의 페이지마다 3~5초가 걸린다면 20개의 사이트를 스크래핑한다면 100초 이상이 걸림 이 부분을 병렬적 즉 비동기적으로 처리해줘야함 이 부분을 처리할 수 있는 기술 목록으로는 아래와 같다 .- promise와 async await - 노드의 Worker Threads, 큐잉시스템(레디스를 활용하여 구현가능) - ..

[TIL] 2024. 3. 25. 09:38

기존 초대 방식은 userId를 통해 초대해주며 초대받은 유저는 승낙과 거절 버튼을 통해 초대에 응하는 시스템이였는데 nodemailer를 통해 이메일로 유저를 초대하고 유저가 초대할지 거절할지 정하는 걸 버튼으로 만들어서 연결해줘야겠다는 생각이 들음 그래서 utils/mail 폴더를 만들어 module, service, controller를 만들어 메일 메서드를 활성화해주고 기존 inviteBoard 로직을 바꿀 생각이다.

카테고리 없음 2024. 3. 22. 02:23

초대 승낙 거절 API를 만들었다 UseGaurds로 로그인이 된 유저인지 확인하고 그 로그인 된 유저의 UserInfo를 받아와 userId를 찾아 초대 메시지가 온 userId면 share 테이블에 있는 status 엔티티에 accepted 문자열을 줘 권한을 확인하는 로직이다 반대로 거절하는 API는 refuse를 담아준다 status의 기본 값은 pending으로 설정해줬다. 이제 보드를 수정할 수 있는 권한이 제대로 갖춰졌다. 거절한 user에게 뜨는 메시지 승낙을 한 유저가 업데이트 진행시 나오는 반환값

[TIL] 2024. 3. 21. 02:08