시세 표에서 값을 뽑아야 해서 브라우저를 띄워 구조를 확인했다. 클래스도 식별자도 붙어 있지 않아서 위치 기반 선택자밖에 쓸 수 없는 상태였다.
Table of contents
Open Table of contents
위치 대신 내용으로
위치로 지정하는 선택자는 행 순서가 바뀌면 그대로 깨진다. 대신 전 행을 순회하면서 첫 셀 내용으로 대상 행을 찾게 했다.
const rows = [...document.querySelectorAll('tr')];
const target = rows.find(tr => /RDIMM|UDIMM/i.test(tr.cells[0]?.textContent));행 순서가 바뀌어도 되고 표가 하나 더 생겨도 된다. 내용으로 찾는 것이 위치로 찾는 것보다 구조 변경에 덜 민감하다.
세어 본 셀 순서
행을 찾았으니 어느 셀을 쓸지를 정해야 했다. 셀 내용을 전부 출력해 보니 값이 이전 값과 함께 두 번씩 나오는 구조였다.
앞에서 몇 개를 자르면 되겠거니 했으면 고가와 저가를 가져왔을 텐데 내가 필요한 것은 여섯 번째의 평균이었다. 셀 순서를 세어 보지 않으면 다른 값을 적재하게 되고 그것도 숫자여서 티가 안 난다.
파싱과 시간대
값에 통화 기호와 천 단위 구분자가 붙어 있어서 그대로 숫자로 변환하면 실패한다. 기호를 제거하고 변환하게 했다.
표 근처의 갱신 시각이 다른 시간대 기준이라 그대로 저장하면 우리 시각과 어긋난다는 것도 확인했다. 이 값은 주간 갱신이라 매일 수집해도 대부분 같은 값이 나온다.
중복 적재와 추정치 표기
주간 갱신인데 매일 적재하면 같은 값이 일곱 번 쌓인다. 갱신 시각이 직전 관측과 같으면 새 관측으로 넣지 않게 해서 값이 바뀐 시점만 남게 했다.
필요한 용량 라인이 무료 범위에 없어서 다른 용량 값을 환산해 채운 것이 하나 있었다. 용량당 단가가 선형이 아니므로 정확한 값이 아니고 그래서 추정 여부와 산출 근거를 별도 필드로 함께 저장했다. 추정치를 실측치와 같은 필드에 그냥 넣으면 나중에 구분할 방법이 없다.
재현 확인과 절차 기록
추출한 값을 다른 날짜의 기존 기록과 대조하니 완전히 일치했다. 값이 맞는지 확인할 다른 방법이 없는 상황에서 독립적인 기록과의 일치가 파싱이 맞다는 근거가 됐다.
이 과정을 저장소에 문서로 남겼는데 셀 순서와 파싱 규칙과 시간대와 갱신 주기와 추정 표기를 적었다. 문서 없이 코드만 있으면 왜 여섯 번째 셀인지를 알 수 없고 표가 바뀌었을 때 무엇이 달라졌는지도 대조할 수 없다.
정리
- 안정적인 선택자가 없으면 전수 순회와 내용 매칭을 쓴다
- 내용 매칭이 구조 변경에 덜 민감하다
- 셀 순서를 세어 보면 값이 두 번씩 나오는 경우가 있다
- 잘못 잘라도 숫자라서 티가 안 난다
- 통화 기호와 구분자를 제거하고 변환한다
- 갱신 시각의 시간대와 갱신 주기를 확인한다
- 갱신 시각이 같으면 적재하지 않아야 시계열이 깔끔해진다
- 추정치는 실측치와 구분되게 표기한다